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),


> 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.