FW: Location revisited, column tracking...

[Valkanas Nikos]

Sorry unintentionally sent it only to John.

-----Original Message-----
From: Valkanas Nikos 
Sent: Wednesday, July 17, 2002 1:33 PM
To: 'John Millaway'
Subject: RE: Location revisited, column tracking...


I guess if you are not very used to it, or if you try to retrofit location info 
to an already completed scanner, may take more time than usually. Myself I 
build scanners with location info from the start, and it takes as much time as 
writing the original code without location. With some experience, I don't need 
debugging. Of course I have tried only lineno not columns. And single scanners 
not multiple or fancy (the kind that John might develop) lexers. And John is as 
experienced as it gets.

I will reiterate the major problem of simple, brilliant software. It eventually 
gets bloated and it disappears or gets replaced. Already flex has shown signs 
of bloating. Enough to justify the development of another little program that 
doesn't do as much, but it is faster at what it does. One can say that a 
program will get replaced if it doesn't offer new features. I don't consider 
that replacement. A new program might offer smt different than flex, that will 
not replace flex, as long as flex is the best at what it does. Flex will be 
replaced only when smt else becomes better at the same things.

I would be much happier if new features were added without sacrificing 
performance. In other words make it faster and use these savings to add new 
features.

Because the previous example shows that flex is already bloated, I think it 
would be appropriate making it a bit faster before adding anything new that's 
not essential.

Then again I am not the flex administrator,
Nikos 

> -----Original Message-----
> From: John Millaway [mailto:address@hidden
> Sent: Tuesday, July 16, 2002 6:43 PM
> To: flex list
> Cc: Suodenjoki Michael Jari
> Subject: Re: Location revisited, column tracking...
> 
> 
> > I would personally find it useful to have an extra option 
> e.g. named %option
> > yylocation that tells the scanner to keep track of the location.
> > ...
> > I'm aware that it may be difficult to implement - but I 
> dont think it's
> > impossible. 
> 
> It is very easy to implement. The debate was not over 
> locations, but whether or
> not flex should do your work for you, whether or not location 
> tracking is
> featuritis. I say flex should do it, and Akim says it shouldn't.
> 
> Case in point: I just added manual location tracking to a 
> scanner/parser last
> week. It took half a day, including debugging, to get all the 
> lines and columns
> correct across multiple files. What a waste of time. And 
> guess what? I used the
> default bison yylloc definition. That means if flex had an 
> option to perform
> column tracking, I would have been done in half a minute 
> instead of half a day.
> 
> > I'm also aware that even the todays implementation of %option
> > yylineno may be considered faulty - depending on how you 
> think it should
> > work. The current documentation states nothing about that 
> it will contain
> > the line number of where the returned token was found!. The 
> problem occurs
> > e.g. in cases where the look ahead is forwarding over a new 
> line character.
> > But yet again this could be corrected at the same time (for 
> the location at
> > least).
> 
> This is not true.  yylineno is not affected by lookahead or 
> backtracking.
> However, yylineno is wacky if you match tokens across 
> newlines (which is rare),
> e.g., if "foo\nbar" is matched, then yylineno will contain 
> the line number on
> which  "bar" is found, not "foo".
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Autos - Get free new car price quotes
> http://autos.yahoo.com
> 
> _______________________________________________
> Help-flex mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/help-flex
>