as a separator

[Ilya Zakharevich <ilya@Math.Berkeley.EDU>]

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