Re: Bug in parsing of local()

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

On Mon, Jul 01, 2002 at 08:50:12PM +0200, Karim BELABAS wrote:
> On Mon, 1 Jul 2002, Ilya Zakharevich wrote:
> > ? f(x=11,y=x)=local(t=ff(),u=t);1
> >   ***   unknown function or error in formal parameters: f(x=11,y=x)=local(t=
> >   ***   ff(),u=t);1
> >         ^-----------
> 
> I had swapped two groups of statements: the ones parsing 'local' were not
> in "parsing function definition" context  [ hence were sensitive to
> "undefined function" syndrom ]
> 
> It's corrected.


With type I get:
? f(x)=local:int(k);x
? f(2)
  ***   expected character: '=' instead of: local:int(k);x

It is a bit streched, but I was  looking to a shortcut to
local(x:int,y:int,z:int). I hesitate between

local:int(x,y,z)
and 
local(x,y,z):int;

What do you prefer ? Better idea ?

Also
? z=[2,4];forstep(x=1,7,z:vec,x)
  ***   expected character: ',' instead of: z=[2,4];forstep(x=1,7,z:vec,x)
                                                                   ^-------
... which is currently neccessary for GP2C to know that this a wheel and not a step.

> P.S: When we'll be sure GP2C emulates completely the current GP behaviour, it
> will be a relief to dump that parser...

I believe the syntactic parser of the newparser branch does this. 
The lexical parser is not 100% compatible, but it should not be an issue
since its only role for GP is to recognize constants (integer,real,strings).
However there is a major issue if I allow automatic concatenation : I am no
more able to catch syntax errors correctly... By patching the generated C
parser, I am able to correctly report if there is at least one error but not
the correct error line.  


What should I do with % history reference in GP2C ? 

Cheers,

Bill.