help-flex
[Top][All Lists]
Advanced

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

Re: Locations suggest -- we're stupid


From: Hans Aberg
Subject: Re: Locations suggest -- we're stupid
Date: Tue, 8 Jan 2002 11:45:35 +0100

At 16:43 +0200 2002/01/07, Nikos Balkanas wrote:
>I am not a diehard. I do not write slow user code. A lineno++ instruction
>doesn't make for slower user code. Flex patterns are much faster than if
>statements, because flex uses tables. The exact code you wrote (thanks) is
>pretty identical except for the symbols that I used. It requires an if
>statement for every char in yytext. It is slower on theoritical grounds
>because it scans once more yytext. This delay is above and beyond any REJECT
>code. And it is measurable.

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.

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

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.

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.

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

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

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

> Its
>philosophy is fine for gui environments.

So do you mean that you use UNIX without X-windows installed?

> So what next? Make flex gui?

I already made Flex a plugin for my IDE. :-)

But the line numbers are only used for editors; the GUI uses the better
position  numbers, which need no parsing.

So the issue of line numbers does not have anything with what computers
want, but what humans are accustomed with.

> I
>believe strongly in the KISS philosophy. It makes for faster, leaner, and
>more maintainable tools.

I do not know about that, other that they do some kind of music. Isn't
Richard Simmons a member?

>Please make a strong case for the features you suggest for Unix.

The line number issue does not have anything with UNIX to do, or GUI's
even, but editors used by humans. Delete those two, and you do not need
line numbers, and not programming either.

> And keep
>flex lean and mean.

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.

> If you want please let's continue this discussion
>privately.

No, please do not do that.

  Hans Aberg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]