Re: : as a separator

[Bill Allombert <allomber@math.u-bordeaux.fr>]

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.

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

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.

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

> 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.1 as an analog to ;
-- in 2.2 for GP2C 'tags' to specify type.

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

':' as a statement separator has been removed from 2.2.

> 
> (*) 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...

My PhD thesis Annex is automatically build with a Math::Pari script,
because it is much easier to handle database in Math::Pari that in PARI.

Also it could be possible to hack gp2c to produce Math::Pari code
in place of C code.

I see the GP language as the result of an unique design choice: make a
language usable by mathematicians that are not acustomed to programming. We have
end up with a language that is appalling to a programmer, but that has a lot of
non-programmer mathematicians as users.  Unfortunately I do not expect them to
learn perl and switch to Math::Pari.

Cheers,
Bill