Bill Allombert on Wed, 3 Jul 2002 23:17:53 +0200

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Bug in parsing of local()

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


What do you prefer ? Better idea ?

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