use dummy field as part of the goto label

[Jay R. Ashworth]

On Tue, May 06, 2008 at 01:30:43PM -0400, Kenneth Brody wrote:
> >I mean that, as nearly as I can model it, the parsing of (dummy) is not
> >being handled by the parser, it's being handled in each individual
> >lexer routine called by the parser.
> 
> No, there is one expression parser, and it is used whenever the syntax
> permits an expression.

Ah, ok.  But the parser makes that decision, not the individual
language element routines?

> >Generally, by "first-class", I mean that syntactical constructs -- of
> >which "put parens around (at least) the name of a variable (and
> >preferably 'an expression') and I'll let you use it where you would
> >normally need an unquoted literal, syntactically" should be handled by
> >the parser itself, and routines it calls, and not by individual lexer
> >routines (like the routine that handles the LOOKUP command and it's
> >arguments, for example).
> 
> The lookup parser uses the same expression parser as the rest of filePro.
> However, it only calls it if the filename or key starts with an open-paren,
> and if so, it compiles the lookup structure flagged such that the runtime
> engine knows to pull the result of the expression as the filename, rather
> than being hard-coded in the lookup structure itself.  This was needed in
> order to maintain both source and compiled code compatibility.

Oh yes.  P-code.  I always forget.

> >This guarantees that the same facility is available everywhere, and that
> >it works the same way everywhere
> 
> It already works that way.
> 
> >-- and that you guys only have to
> >maintain it once, incidentally.  :-)
> 
> Just curious...  Would you expect the following to be valid?
> 
>     xx = "gosub foo"
>     (xx)

I can envision a syntax definition -- which I don't *think* would break
any current syntax by collision -- which would permit that, at the
source level, though not necessarily, as you note...

> Yes, I know that some interpreted languages allow some sort of "eval"
> command to execute commands built at runtime, but filePro is compiled,
> and not interpreted.  (Okay, the old "filePro" was interpreted, but
> today's "filePro" is really what was formerly called "filePro Plus"
> way back when.)

at the P-code level.

Ignoring rcabe/clerk (which really don't seem to have any reason to
exist anymore, except source code privacy -- load time on any
reasonable machine dropped below human reflexes a *long* time back) for
the moment -- if it *is* compiled, it's JIT compilation, by which I
mean it's compiled at load time not at execution time.  Correct?

Cheers,
-- jra
-- 
Jay R. Ashworth                   Baylink                      jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com                     '87 e24
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274

	     Those who cast the vote decide nothing.
	     Those who count the vote decide everything.
	       -- (Joseph Stalin)