|Ilya Zakharevich on Thu, 14 Nov 2002 18:28:31 -0800|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|: as a separator|
I think that the principal reason for slow uptake of GP/PARI is how painful it is to extend it. When one extends in C, one needs to fight with PARI being so C-hostile [one essentially program in assembler, using (GEN)z[n] instead of z->array[n] - or at least VEC_elt(z,n) as in my recent patch; likewise for access to components of other types] and the API is so un-mneumonic. It is very hard to read existing code (to improve, or to model one's own code on an existing one). Extension in GP is also very complicated due to absense of namespaces, of lexical variables, of a way to duplicate in PARI the possible signatures of C functions, of the ways to introduce variables with appropriate precedence (to list a few). I often try deal with C part. (E.g., see 9 Nov 1998 D-000275 or my recent patches.) But let me concentrate on the GP part now. (*) 0) Is there an easier way to convert a seq to an expr than if(1,SEQ)? Is it acceptable to shorted this to do(SEQ)? 1) One needs lexical variables (a variable is a translator name ==> value; lexical variables are those visible from the enclosing function, but not from any other function, even when called from the enclosing function). What should be a proper syntax? I'm leaning on func(dynamic,'lexical) = local(dynamic1,'lexical1); SEQ What do you think? 2) Is it OK to allow identifiers of the form prefix::prefix1::name? This would be a first step to namespaces... 3) I cannot easily find it documented (except in anal.c ;-) that : is a valid statement separator. Can somebody direct me to the corresponding piece of docs so that I know how much backward-compatible do I need to be in (2)? Yours, Ilya (*) BTW, I started to deal with Perl to give a solid foundation to PARI, so that one can use a sane language as a substitute to GP; my expectations were that one could use Math::Pari as *the* front end to PARI. At the time GP (as opposed to PARI) was buggy to be almost unusable. Apparently, I was wrong; I do not see a *lot* of evidence of Math::Pari being used for extension of PARI. Nowadays GP is good for casual programming, but still lacks a solid foundation which would allow easy extension... So one needs to repeat all the effort to make GP language a better place to live...