[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO
- From: "Michael Rose" <michael.h.rose@...>
- Date: Wed, 15 Jun 2011 14:19:29 +0200 (CEST)
Von: "steve donovan" <email@example.com>
Gesendet: 15.06.2011 12:38:04
An: "Lua mailing list" <firstname.lastname@example.org>
Betreff: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO
>On Wed, Jun 15, 2011 at 12:25 PM, Michael Rose <email@example.com> wrote:
>> @123\n The often missed line directive for compiler generated code.
>> The next line would be line number 123 of the original file.
>Ah, but it's useful to go one step further, since the original file
>may have a different name; in fact the result may contain sections
>from several source files. So a way to capture all of the #line
>directives functionality is needed.
I agree with You.
I also was thinking about this. A natural extension would be
using a construct similar to the 'C' '#line' declaration, e.g.
This all is just now my own test environment and correct
line numbers are for me at the moment the most important thing to
see what's going on in the target code. Your suggestion would be a
natural enhancement for a general integration into Lua.
>As for @label>, it doesn't feel visible enough; here the old tradition
>of using 'goto' works fine.
Since I use my extension for compiler generated code, I also want to use generated
goto labels, which don't interfere with the user specified labels, or the labels of other
constructs. If the syntax 'goto <label>' is used, then <label> must be recognized by
the lexer on it's own. I prefer here to use the delimiters '@' and '>' or ':' respectively,
because then a generated label '@41.switch:' might be jumped onto with '@41.switch>'
instead of using 'goto @41.switch@', but this is of course only personal taste.
(A nasty user can always address compiler generated labels and identifiers in both cases,
but if the user restrains himself using labels like @asdf14: conflicts are safely avoided).
In addition the '@name>' syntax makes the visibility contest, that these extensions are
grouped together. One could even think of a compiler flag to enable/disable the '@'
extensions. Generally if I want to use 'goto name' then it would be more appealing to
have something like 'label name' as well. '@name:' and 'goto name' is somehow
inconsequent for my own astethic feeling.
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar