Ilya Zakharevich on Fri, 15 Nov 2002 13:40:44 -0800 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: GP as a programming language |
[Subject changed; in the middle of composing the previous message I changed my mind what should the focus of the message, but forgot to change the subject.] On Fri, Nov 15, 2002 at 01:21:31PM +0100, Bill Allombert wrote: > On Thu, Nov 14, 2002 at 06:28:31PM -0800, Ilya Zakharevich wrote: > > 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). > > That is what of the point of writing GP2C. See the end of my previous message. gp2c is in the same ballpark as Math::Pari. Math::Pari did not help GP/PARI. I see no reason why gp2c would. > > 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) If do(SEQ) return the last value computed by SEQ like if(1,SEQ), Yes. > then I do not like the name, but I am OK otherwise. Anyone having a better suggestion for the name? > 2) If do() is to be used in control statement that take an expr > instead of a seq, then I believe it is better to fix those control > statement instead. This is essentially trivial. This is better. But the last time I raised the issue of some functions taking an expr, some taking a seq, it lead to introduction of new prototype letter instead of changing the C code... > > 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? > I would prefer all local variables must be lexical in GP. The current state is > misunderstood and create a lot of confusion. Also GP2C can hardly handle non > lexical variable. This a prolem that is not easy to fix, though. Giving backward compatibility, this laudable target is out of the question. > > 2) Is it OK to allow identifiers of the form prefix::prefix1::name? > > This would be a first step to namespaces... > The ':' is already used: > -- in 2.2 for GP2C 'tags' to specify type. : and :: have no reason to contradict each other. Yours, Ilya