Re: GP as a programming language

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

On Fri, 15 Nov 2002, Ilya Zakharevich wrote:
> 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:
>> 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...

seq() are slightly slower than expr().

Current code:

(10:48) gp > sum(i=1,1000000,); \\ ERROR
(10:49) gp > sum(i=1,1000000,0);
time = 350 ms.
(10:49) gp > sum(i=1,1000000,1);
time = 460 ms.

Changing C code to use seq():

(10:50) gp > sum(i=1,1000000,)
time = 210 ms.
(10:50) gp > sum(i=1,1000000,0);
time = 390 ms.
(10:50) gp > sum(i=1,1000000,1);
time = 500 ms.

At worst, a 10% penalty. I believe "0" is the fastest parsable expr, also
leading to the fastest processing in 'sum'. And that 1 is the next fastest.
For a non-trivial summand, the penalty is not noticeable:

(11:40) gp > sum(i=1,10000,exp(i));
time = 260 ms. \\ both versions

So, I think using seq() everywhere is the correct thing to do after all.

If nobody protests, I shall make that change in the near future (making the
'E' prototype letter a synonym for 'I' in the process, for backward
compatibility).

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

I concur. Argument passing is expensive for large objects (by value, full
copy), so the following is a very frequent construct (in _my_ scripts at
least):

  main() = {
    local(bnf = ...) \\ allocate "global"
    f(); g();
    ... \\ in there, everybody uses "global" variable bnf
  }
  \\ ... but we clean up upon exit

or simply

  main(bnf) = ...

for the same effect using GP1-compatible syntax.

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

Sounds reasonable.

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathématiques, Bât. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas/
--
PARI/GP Home Page: http://www.parigp-home.de/