Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Michael Rose
I personally also favorize a non keyword based goto statement handling.
I mainly want to use goto statements for compiler generated code and
I have choosen per coincidence the same syntax for labels like
Roberto Ierusamlimschy used in the Beta release. I've just gone one step
further to also avoid a goto keyword at all. To have a full environment to
implement a METALUA like enhancement completely in Lua itself without
a cloned code generator, I've patched the following extensions in
Lua-5.2.0-alpha some weeks ago:

@@            stands for '@' (who knows for what this might be good for.
@string@   -> TK_NAME alas Lua identifier (this is useful for compiler generated identifiers
                      like @125.comment@ guaranteed not to interfere with user
                      choosen identifiers.
@123\n          The often missed line directive for compiler generated code.
                      The next line would be line number 123 of the original file.
                      A proposal to rearange compiler generated code with gotos to fit the
                      original line numbers is not feasible, because sometimes the same line number
                      can be used several times for subconstructs. This solution is also more clean IMHO.
@name:         The label statement (same semantics like the one in the beta release, jumps
                      are only allowed inside one function out of nested blocks and not crossing local
                      variable declarations from above. This is really sufficient even for compiler generated code
                      and I would not like to be trapped by non initialized local variables.
                      Label names have it's own namespace.
@name>        Means the same as "goto name" in the Beta release. On the one hand this is more
                     symmetric in my eyes, because both extensions use an '@' sign and I think it is a
                     good idea to have labels and gotos stich out of the code a bit. Note that the lexer fetches the ':' and
                     the '>'. Therefore there is no conflict with the standard operator '>' or the method call token ':'.
@[ statements @| expression @]    is a block like 'do' ... 'end', but returns an expression instead.
                    These statement expressions are quite nice in compiler generated code, because they
                    avoid a slower construct like "(function () ... return expr)()".

So in the end I used the '@' sign to introduce a couple of extensions to Lua mainly to supply compiler generated
code. On the lexical level they are all implemented in the 'llex.c' module very compactly giving new tokens
TK_NAME, TK_GOTO, TK_LABEL, TK_STATBEG, TK_STATEXPR, TK_STATEND ( the line directive is handled by the lexer
similar as comments are treated but changing the line number variable of course).
I was aware of the naming conflict (using an '@' sign as the first symbol in a chunk file), but I
don't bother. I think it would be appropriate to change the 'load()' procedures to use another symbol for that,
because the '@' sign is quite handy for extensions like the proposed ones or to leave just a space or so if the
first statement of a file chunk is an '@' extension like Roberto suggested earlier in this thread.

I already made some implementation tests for a Metalua and these entensions seem to be sufficient for this task.

If there is personal interest in these patches (of course under the same MIT license like Lua), send me an e-mail,
but I don't want to clobber this mailing list with patch files again.

Regards,

Michael Rose
___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

steve donovan
On Wed, Jun 15, 2011 at 12:25 PM, Michael Rose <[hidden email]> 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.

As for @label>, it doesn't feel visible enough; here the old tradition
of using 'goto' works fine.

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Michael Rose
In reply to this post by Michael Rose
-----Ursprüngliche Nachricht-----
Von: "steve donovan" <[hidden email]>
Gesendet: 15.06.2011 12:38:04
An: "Lua mailing list" <[hidden email]>
Betreff: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

>On Wed, Jun 15, 2011 at 12:25 PM, Michael Rose <[hidden email]> 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.

         @123 "filename"\n

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.

>
>steve d.
>

Regards,

Michael Rose
___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Pierre-Yves Gérardy
On Wed, Jun 15, 2011 at 14:19, Michael Rose <[hidden email]> wrote:
>          @123 "filename"\n

Good stuff here, but requiring a new line is a bad idea. In some
cases, the code of different lines in the source file could end up in
a single line of Lua. I have such a case ion a toy language I'm
playing with (in which I had already implemented a tail call based
goto with similar scoping rules as the ones proposed in Lua 5.2 beta
RC1.

@123 "filename"@ would not prevent @TK_NAME@ from existing either
(since the latter cannot start with a digit). BTW, the @TK_NAME@ would
also be very useful in my case. I currently append a long, random
string to all identifiers, but it is more a hack than anything else.

I also like the statement-expressions idea (but not its syntax... I
would prefer it in a dark red).

--Pierre-Yves

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Pierre-Yves Gérardy
In reply to this post by Michael Rose
On Wed, Jun 15, 2011 at 12:25, Michael Rose <[hidden email]> wrote:
> @name>        Means the same as "goto name" in the Beta release. On the one hand this is more
>                      symmetric in my eyes, because both extensions use an '@' sign and I think it is a
>                      good idea to have labels and gotos stich out of the code a bit. Note that the lexer
>                      fetches the ':' and
>                      the '>'.

@>name would be easier to parse. Otherwise, the parser has to fetch
the @ sigil, then the name, and only then the final sigil that
determines the branch to take.
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Michael Rose
In reply to this post by Michael Rose
-----Ursprüngliche Nachricht-----
Von: "Pierre-Yves Gérardy" <[hidden email]>
Gesendet: 15.06.2011 16:16:10
An: "Lua mailing list" <[hidden email]>
Betreff: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

>On Wed, Jun 15, 2011 at 14:19, Michael Rose <[hidden email]> wrote:
>>          @123 "filename"\n
>
>Good stuff here, but requiring a new line is a bad idea. In some
>cases, the code of different lines in the source file could end up in
>a single line of Lua. I have such a case ion a toy language I'm
>playing with (in which I had already implemented a tail call based
>goto with similar scoping rules as the ones proposed in Lua 5.2 beta
>RC1.
>
>@123 "filename"@ would not prevent @TK_NAME@ from existing either
>(since the latter cannot start with a digit). BTW, the @TK_NAME@ would
>also be very useful in my case. I currently append a long, random
>string to all identifiers, but it is more a hack than anything else.

In fact in the current implementation '@<digits>' accepts an immediate
newline (in that case the line number is valid for the next line) as well as
a space (in that case the line number is valid for the current line). I just
wanted to be brief. The second '@' for line declarations is not neccessary,
even in the (yet not implemented) case, a quoted string is following the space.

>
>I also like the statement-expressions idea (but not its syntax... I
>would prefer it in a dark red).

??? A joke I missed?

>
>--Pierre-Yves
>

Regards,

Michael Rose
___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Michael Rose
In reply to this post by Michael Rose
-----Ursprüngliche Nachricht-----
Von: "Pierre-Yves Gérardy" <[hidden email]>
Gesendet: 15.06.2011 16:20:45
An: "Lua mailing list" <[hidden email]>
Betreff: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

>...
>
>@>name would be easier to parse. Otherwise, the parser has to fetch
>the @ sigil, then the name, and only then the final sigil that
>determines the branch to take.

No it wouldn't. And a delimiter like '>' is appropriate because of constructions like
   @123.name>  or
   @123$name!> or even
   @12-34-5123> which are all allowed to enable more verbose information
   (e.g. for debugging compiler generated symbols).

Regards,

Michael Rose

___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Matthew Wild
In reply to this post by Michael Rose
On 15 June 2011 16:27, Michael Rose <[hidden email]> wrote:
> -----Ursprüngliche Nachricht-----
> Von: "Pierre-Yves Gérardy" <[hidden email]>
> Gesendet: 15.06.2011 16:16:10
> An: "Lua mailing list" <[hidden email]>
> Betreff: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO
>
>>On Wed, Jun 15, 2011 at 14:19, Michael Rose <[hidden email]> wrote:

>>
>>I also like the statement-expressions idea (but not its syntax... I
>>would prefer it in a dark red).
>
> ??? A joke I missed?
>

Yes, because it's meant to be teal: http://bikeshed.com/

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Pierre-Yves Gérardy
In reply to this post by Michael Rose
On Wed, Jun 15, 2011 at 17:32, Michael Rose <[hidden email]> wrote:
> Von: "Pierre-Yves Gérardy" <[hidden email]>
>>@>name would be easier to parse. Otherwise, the parser has to fetch
>>the @ sigil, then the name, and only then the final sigil that
>>determines the branch to take.
>
> No it wouldn't.

How do you discriminate between a label or a goto before reaching
either the column or the right angled bracket?

Not that it matters much, but it increments the cyclomatic complexity
of the "@" clause.

>    @123.name>  or
>    @123$name!> or even
>    @12-34-5123>

I understand the purpose of a terminator, but none of your examples
are valid goto labels. I assume that the first two would jump to
"name", but what about the third one?

Also, these examples create more convoluted clauses for the parser,
and duplicated code unless you use a goto. Here's the simplfied code
flow:

    name ? ( ":" ? label : goto )
    number ? ( "." ?  label with info : line number )

@!name,info> is clean and would allow the "@" section of the parser to
have only one conditional level. More straightforward, easier to read
and understand, and thus to maintain.

    name ? label  (with or without debug info)
    number ? line number
    "!" ? goto

-- Pierre-Yves

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

David Manura
In reply to this post by Michael Rose
On Wed, Jun 15, 2011 at 6:25 AM, Michael Rose <[hidden email]> wrote:
> @123\n   The often missed line directive for compiler generated code.
>                The next line would be line number 123 of the original file.
>                A proposal to rearange compiler generated code with gotos to fit the
>                original line numbers is not feasible, because sometimes the same line number
>                can be used several times for subconstructs. This solution is also more clean IMHO.

Do you allow this?

  @ 123 f()
  @ 124 g()
  @ 123 h()

lua-5.2.0-beta-rc1 doesn't allow the following analogue because label
"line123" is redefined in the same scope:

  @ line123: f()
  @ line124: g()
  @ line123: h()

(However, there is no need for Lua to care about this conflict because
there is no goto targeting any of these labels.)

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

David Manura
In reply to this post by Michael Rose
On Wed, Jun 15, 2011 at 8:19 AM, Michael Rose <[hidden email]> wrote:
>          @123 "filename"\n

or break into two statements:

  @ "filename"
  @ 123

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Michael Rose
In reply to this post by Michael Rose
-----Ursprüngliche Nachricht-----
Von: "David Manura" <[hidden email]>
Gesendet: 16.06.2011 03:22:41
An: "Lua mailing list" <[hidden email]>
Betreff: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

>On Wed, Jun 15, 2011 at 6:25 AM, Michael Rose <[hidden email]> wrote:
> ...
>
>Do you allow this?
>
> @ 123 f()
> @ 124 g()
> @ 123 h()

Yes, why not?
But in the current implementation the space between '@' and the linenumber is forbidden.
The linenumber correction has nothing to do with goto labels. Goto labels should be unique, but
compiler generated lines can be mapped arbitraryly to original source line numbers.
A possible generalization (not a big deal) as suggested in other e-mails would be

@123 "orig.lua"    or
@ 123 "orig.lua"   or even
@ 123
@ "orig.lua"

In contrast, labels shouldn't have embedded spaces and quote marks (") to be
distinguishable from line corrections:

@my-special-[goto]-label(123)>   (no space, no ("), printable characters)

Of course users should stick to labels like

@heretogo>
@entry1>

but as I already said previously, its handy to have more complex labels for
compiler generated ones just to help inspecting generated code.

>
>lua-5.2.0-beta-rc1 doesn't allow the following analogue because label
>"line123" is redefined in the same scope:
>
> @ line123: f()
> @ line124: g()
> @ line123: h()
>
>(However, there is no need for Lua to care about this conflict because
>there is no goto targeting any of these labels.)
>

Regards,

Michael Rose

___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Michael Rose
In reply to this post by Michael Rose
-----Ursprüngliche Nachricht-----
Von: "Pierre-Yves Gérardy" <[hidden email]>
Gesendet: 15.06.2011 20:04:12
An: "Lua mailing list" <[hidden email]>
Betreff: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

>On Wed, Jun 15, 2011 at 17:32, Michael Rose <[hidden email]> wrote:
>...
>
>How do you discriminate between a label or a goto before reaching
>either the column or the right angled bracket?
>
>Not that it matters much, but it increments the cyclomatic complexity
>of the "@" clause.

I don't think so. But because sometimes code might be more comprehensive then
describing it in discussion I attached the relevant part of 'llex.c' to the bottom of
this e-mail, showing the scanning of the '@' syntax by the lexer.

>
>> @123.name> or
>> @123$name!> or even
>> @12-34-5123>
>
>I understand the purpose of a terminator, but none of your examples
>are valid goto labels. I assume that the first two would jump to
>"name", but what about the third one?

We have to distinguish the current Lua beta and my suggestion.
In my '@' extension, such labels are perfectly legitim. They need not be
of identifier form to allow compiler generated labels being safely different
from user generated ones.

>
>Also, these examples create more convoluted clauses for the parser,
>and duplicated code unless you use a goto. Here's the simplfied code
>flow:
>
> name ? ( ":" ? label : goto )
> number ? ( "." ? label with info : line number )
>
>@!name,info> is clean and would allow the "@" section of the parser to
>have only one conditional level. More straightforward, easier to read
>and understand, and thus to maintain.
>
> name ? label (with or without debug info)
> number ? line number
> "!" ? goto
>
>-- Pierre-Yves
>

Just have a look in given code snipped. It is short and there is no issue
with maintainance. It covers scanning of labels, gotos, line number annotations
and statement block delimiters.

Regards,

Michael Rose

Extract from modified 'llex.c':
====================

static int llex (LexState *ls, SemInfo *seminfo) {
  luaZ_resetbuffer(ls->buff);
  for (;;) {
    switch (ls->current) {
      ...
      ...
      case '@': {
        save_and_next(ls);
        switch (ls->current) {
          case '@':  next(ls);  return '@';
          case '[':  next(ls);  return TK_STATBEG;
          case '|':  next(ls);  return TK_STATEXP;
          case ']':  next(ls);  return TK_STATEND;
        }
        if (lisdigit(ls->current)) {
          /* This could be a line number annotation: */
          do save_and_next(ls); while (lisdigit(ls->current));
          if (lisspace(ls->current) || ls->current == EOZ) {
            save(ls, '\0');
            if (!luaO_str2d(luaZ_buffer(ls->buff) + 1, &seminfo->r) ||
                seminfo->r >= (lua_Number)(MAX_INT))
              luaX_syntaxerror(ls, "line number annotation too high");
            lua_number2int(ls->linenumber, seminfo->r);
            luaZ_resetbuffer(ls->buff);
            ls->linenumber -= currIsNewline(ls);
            break;
          }
        }
        for (;;) {
          int cur = ls->current;
          if (cur == ':' || cur == '>' || cur == '@') {
            save_and_next(ls);
            seminfo->ts = luaX_newstring(ls, luaZ_buffer(ls->buff)+1,
                                         luaZ_bufflen(ls->buff)-2);
            switch (cur) {
              case ':':  return TK_LABEL;
              case '>':  return TK_GOTO;
              default:   return TK_NAME;
            }
          }
          if (!lisprint(ls->current) || lisspace(ls->current))
            lexerror(ls, "illegal character in '@' statement", 0);
          save_and_next(ls);
        }
        break;
      }
      ...
      ...
   }
}

...
...


___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Pierre-Yves Gérardy
On Thu, Jun 16, 2011 at 10:10, Michael Rose <[hidden email]> wrote:
> We have to distinguish the current Lua beta and my suggestion.
> In my '@' extension, such labels are perfectly legitim. They need not be
> of identifier form to allow compiler generated labels being safely different
> from user generated ones.

I got confused because you used "name" in your description, and I
undestood it is defined in the Lua grammar.
The implementation could be greatly simplified by slightly changing
the rules, though.

>       case '@': {
>         save_and_next(ls);
>         switch (ls->current) {
>           case '@':  next(ls);  return '@';
>           case '[':  next(ls);  return TK_STATBEG;
>           case '|':  next(ls);  return TK_STATEXP;
>           case ']':  next(ls);  return TK_STATEND;
>         }

You could hard code the "|" and "]" tokens in the parser and get rid
of the second and third @ which are bulky and redundant (they're not
needed for a non-ambiguous grammar).

var = @[ statements | expresion ]

>         if (lisdigit(ls->current)) {
>             ...
>         }
>         for (;;) {
>             ...
>         }
>     } // case '@'

That logic belongs to the parser.

With distinct initial tokens, and if you forbid spaces in labels, you
can get away with something like this (there are probably in the use
of next(), I havent played with the parser for some time):

       case '@': {
         save_and_next(ls);
         char c = ls->current;
         switch (c) {
           case '@':  next(ls);  return '@'; // I'm puzzled with this one.
           case '[':  next(ls);  return TK_STATBEG;  // @[ statements
| expresion ]
           case '(':  next(ls);  return TK_IDENTIFIER; // @( identifier )
           case '>':  next(ls);  return TK_GOTO; // @>valid lua names
numbers and "strings" 123>
           case '!':  next(ls);  return TK_LINENUMBER; // @!123"file.name"
           default:  return TK_LABEL; // to allow Lua 5.2
compatibility, assuming that the @ is kept for labels
          }
       }

That's it :-)
You can then add the relevant entries in the statement function in lparser.c.

If you restrict the labels and identifiers to valid Lua lexemes, you
can also reuse the lexer rather than rolling your own hand-made
solution.

The choice of the sigils is a matter of taste, but the initial tokens
simplify the implementation. Good luck to introduce a bug in this
code.

Regards,
-- Pierre-Yves

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Pierre-Yves Gérardy
Gmail broke my code...

case '@': {
    save_and_next(ls);
    char c = ls->current;
    switch (c) {
        case '@':  next(ls);  return '@'; // I'm puzzled with this one.
        case '[':  next(ls);  return TK_STATBEG;
        case '(':  next(ls);  return TK_IDENTIFIER; // @( identifier )
        case '>':  next(ls);  return TK_GOTO;
        case '!':  next(ls);  return TK_LINENUMBER; // @!123"file.name"
        default:  return TK_LABEL;
           /* to allow Lua 5.2 compatibility, assuming
            * that the @ is kept for labels
            */
      }
}


With the following syntax for "statements-expressions" :
    @[ statements | expresion ] */

and this one for gotos and labels
    @>valid lua names numbers and "strings" 123>
    @ same as previous :

Regards,
--Pierre-Yves

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Tony Finch
In reply to this post by David Manura
David Manura <[hidden email]> wrote:
>
> or break into two statements:
>
>   @ "filename"
>   @ 123

Neat!

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Southeasterly 5 to 7,
veering westerly 4 or 5 later in southwest Viking and South Utsire. Moderate,
occasionally rough later. Occasional rain, fog patches. Moderate, occasionally
very poor.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

Michael Rose
In reply to this post by Michael Rose
-----Ursprüngliche Nachricht-----
Von: "Pierre-Yves Gérardy" <[hidden email]>
Gesendet: 16.06.2011 11:36:51
An: "Lua mailing list" <[hidden email]>
Betreff: Re: [ANN] Lua 5.2.0 (beta-rc1) GOTO

>On Thu, Jun 16, 2011 at 10:10, Michael Rose <[hidden email]> wrote:
> ...
>
>You could hard code the "|" and "]" tokens in the parser and get rid
>of the second and third @ which are bulky and redundant (they're not
>needed for a non-ambiguous grammar).
>
>var = @[ statements | expresion ]

True. This could be done. But this would tighten the currently non-used '|' to this construct,
which is mainly used to support compiler generated code. There are only a few
nonused characters and we should be careful not to waste them.
If this construct should go into standard Lua, I would prefer keywords instead, e.g.

   stat <statements> expr <expr> end

For compiler generated code the '@[ ... @| ... @]' syntax doesn't hurt and has the
advantage, that only the '@' sign is needed to generate the extra tokens.

>
>Regards,
>-- Pierre-Yves
>

Regards,

Michael Rose
___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar