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/