Karim BELABAS on Thu, 5 Jun 2003 16:07:38 +0200 (MEST)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: .gprc

On Sat, 31 May 2003, Ilya Zakharevich wrote:

> On Sat, May 31, 2003 at 08:15:37PM +0200, Karim BELABAS wrote:
> > > d) It is possible to get an array [2,4,5] for GP/PARI version 2.4.5
> > >    from the GP/PARI API?  Then one could delegate version-dependent
> > >    processing to the read() directives...
> > It would clutter the name space,
> As will any other functionality; what is your point here?

Nothing crucial. Simply that introducing new common keywords like version()
breaks existing scripts [ C++ syndrom... it would break some of mine ], and
safer complicated keywords like pariversion() or derivatives are rather

As a rule, I'd rather keep the built-in routine set to a minimum unless

* there's a definite use for the new functionality
* it's inconvenient to replicate it from within gp.

Do you have a definite need for this version array which can't be addressed
by the gprc (admittedly quite limited) version handling ?


Btw, using default() would solve the keyword porblem, but I don't want to mix
user preferences and read-only variables. While I'm at it, I've always
thought that the optional flag

  default(d, val, 1)

was a ugly hack (I regret it dearly). Maybe something like

  default(d), default(d, val): as current [ set / print default value ]
  defaultget(d)              : as current default(d,,1) [ return a GP object ]

would be less cryptic. The defaultget()  [ or interface(), or whatever ]
routine could then be used to query for system variables in addition to
defaults, in particular version, etc ?

Anybody has a nice suggestion to handle the following 5 actions (possibly
across a few different GP routines) ?

1) set user preferences
2) print user preferences
3) get   user preferences in GP-usable form (vector, string, number, etc)
4) print (read-only) system settings
5) get   (read-only) system settings in GP-usable form
6) forgot something ?

I don't think having a single-purpose routine and binary flag would address
this adequately...



>> vers() =
>> {
>>   eval( Str("[",
>>           extern("gp --version-short 2>&1 |
>>               sed -e 's/\\./,/g' -e 's/^/\"/' -e 's/$/\"/'"),  "]") )
>> }
> ??? What use is it if it does not work everywhere?  E.g., command.com does
> not support 2>&1; sed is not guarantied to be present etc.

I'm sure you're more than able to concoct a perl alternative which will work
everywhere (provided perl is installed:-). Anyway, it was not a serious
suggestion. Just a fun hack ...
Karim Belabas                     Tel: (+33) (0)1 69 15 57 48
Dép. de Mathématiques, Bât. 425   Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud              http://www.math.u-psud.fr/~belabas/
F-91405 Orsay (France)            http://www.parigp-home.de/  [PARI/GP]