Re: Locations suggest -- we're stupid

[Nikos Balkanas]

----- Original Message -----
From: Hans Aberg <address@hidden>
To: Nikos Balkanas <address@hidden>
Cc: <address@hidden>
Sent: Tuesday, January 08, 2002 12:45 PM
Subject: Re: Locations suggest -- we're stupid

[...snip...]

>
> You do not know that the scan over yytext to compute yylineno causes
> heavier overhead than the REJECT code, as Flex always imposes the latter,
> and nobody seems to have profiled without. So let's stick to facts.
>

Yes I have done tests. Duplicating the yytext scan has an overhead. Used
yy_scanbuffer and scanned input from the buffer twice or once.

> Then, the loop already has conditionals and some in it, so the question is
> how much overhead is caused relative to that.

The overhead is with rescanning yytext, not with the overall loop.
New features will do things above and beyond the overall loop.

> And for the efficiency of the code itself, the only thing that matter is
> how much time the computer spends it relative to the other code it does,
> and most parsers spend most time in their actions, not the parsing.

Processing time adds up. A slow lexxer can hog down the fastest parser.
One of the main advantages of flex is its speed. Let's keep it that way.

> So one should not wasting time on trying to write efficient code, but to
> write structured code, and optimize it wherever needed, if possible: Much
> more precious than computer time is programmer time, which forces this
> development.

Programming style. I like to write optimized code from the start, so that I
avoid going back at it later on. Development is very subjective. One person
can write code in 1/4 the time other people do. It is a question of how used
one is to the particular task. If you maintain lineno or the other error
tracking features, after a while you do it subconsciously.

> >Furthermore the if (do_yylineno) statement eats up processing at every
> >pattern, in runtime. I wished that if new features are implemented they
are
> >handled with precompiler statements (#ifdef do_yylineno ...) so that they
do
> >not penalize whoever doesn't use them. My suspicion is that they will
> >propably be implemented runtime and hog flex down.
>
> I am not sure what you are speaking about here, as do_yylineno is in Flex
> itself, not the parser it generates.

My apologies. See my reply to Millaway. Mixed up, thought that runtime code
was introduced each time in the generated lexxer.

> >Lastly, let's not forget flex's roots: Unix. In Unix there aren't many
> >editors that support columns.
>
> I think that the columns are just the number of characters on the line.

Yes. That's what I meant. Same argument.

> > Unix is not for fancy features. I know
> >CodeWarrior and it is a very fine compiler for Windows or Mac.
>
> You must live in the past: MacOS X+ now has BSD, and MacOS and MSOS (I
> think) both use the Mach kernel. The difference between these and UNIX
> become less and less.

Thanks for the info. I used Mac until OS 8.0. Pitty they used such a old
kernel. AIX used to use it until v 4.3.3, now they switched to a Linux
kernel. Do you mean that the Codewarrior IDE exists in other Unix platforms,
too? What is MSOS?

> > Its
> >philosophy is fine for gui environments.
>
> So do you mean that you use UNIX without X-windows installed?

I use dual boot Windows/SUSE linux, with X-windows running multiple
consoles. I run gcc and vim. Recently, I changed my video card to Kyro II,
for which no linux drivers exists yet. So I am back working with virtual
consoles. :-(

> > So what next? Make flex gui?
>
> I already made Flex a plugin for my IDE. :-)

That's nice. I actually meant why stop at these features? Add a few menu
items, buttons and an interactive pattern generator to make development even
faster! :-)

So, basically you want these features to work better with your IDE. Any idea
how many people use flex that way? Should you wait until the specifications
for the new GNU IDE you mentioned are in?

[...snip...]
>
> Well, as said before it is a feature that is already there, appreciated by
> its presence by many, even though not in its performance which we discuss
> in order to improve it.
>
> And it is deselectable.
>
> So I cannot see why those that do not want to use it simply don't, instead
> of burdening this list with emails that do not help improving on this
> already existing Flex feature.

Absolutely right. Never made a case about deleting yylineno. Made a
suggestion on how to avoid using it. Even used it as an example of how not
to implement the new features (turned out I misunderstood the
implementation).

Also please, let's just post in the list or just send personal emails. Not
both. Yesterday I got about 30 emails from this list (many from duplicated
emails) which vaguely reminded me of a flame war.

Nikos