gp and strings

[Nils-Peter Skoruppa <skoruppa@math.uni-siegen.de>]

Gerhard Niklasch wrote:
> 

> are far from PARI's native area of competence.  What do you need this
> string exploding for in gp?

Thank you for your extensive opinion about this subject.
Actually, this string story is only one of a long list of
wishes of more flexible capabilities for gp. After one semester
of teaching I can say that gp is (very unfortunately) far away
from being useful for longer or nested projects.

More specifically: The students wrote scripts e.g. for drawing in gp,
levelplotting, fractals and the like ...,
using another simple gp script which generates xpm-files
(Since we found that the pari-integrated plotting routines are
... ehm ... not very useful). Now, to tell the xpm script to generate
a xpm-file they needed to hand over a string with the name of the
desired xpm file
(typically something like "picture.xpm")
and the script had to let gp write
something like  "char *picture_xpm[] ..." to the xpm file ...
(since dots are not allowed ...)
Impossible to pull picture_xpm oout of picture.xpm ! ... it seems so
far.
(So I told them not to use dots in their file name but that caused other
nuisances).

Other things that we are missing very much and which prevent us
from using gp seriously for bigger projects with several persons sharing
programming work:

1/ own name spaces for scripts
(why isn't there the possibility to switch on the following
behaviour of gp:

        If N and func() are variables in the script pip.gp,
        then gp would read them in as  pip::N and pip::func()
        or similar.

Would be so simple and effective, no ?
(oh, I forgot that pari can't extract pip from pip.gp  ;)

2/ the possibility of generating different pari objects
   from one and the same script
   (better: the possibilty to declare "classes" in gp
   and to generate "objects" belonging to classes)

3/ the possibility to declare functions within functions
.....
.....
.....

During our trials to circumvent these problems we found several
sort of bugs:

Try
? f(x) = x; g(u) = return( u*x); return( g(5));
? f(1)
? a = f(2)

=8-[

(There would be useful applications of such a syntax !).

Or put this into a script called pipapo.gp

/* gp script trying to mimic object generation from classes */
class( a) =
{
eval(t=Str(
        a"__N=17;
 
 
        "a"__meth1(x) =
                return("a"__N*x^2);
 
        "a"__M = 88;
"));
}

and try
? read("pipapo.gp")
? class( obj)
? obj__N   ( ---> good behaviour og gp !)
? obj__meth1  (---> bad behaviour of gp !)

Why does gp not provide such a simple thing like
this sort of classes as above ? With the eval and
Str hacking hidden from the user, of course.

Greetings,
---Nils Skoruppa

PS: In the end we gave it up
and most of my students are running away now to the Maple class ...
buhuhu ... ;-)