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