use dummy field as part of the goto label

[Kenneth Brody]

Quoting Jay R. Ashworth (Tue, 6 May 2008 12:42:27 -0400):

> On Tue, May 06, 2008 at 12:17:47PM -0400, Kenneth Brody wrote:
[...]
>> > If the handling of this issue was first-class,
>>
>> I'm not sure what you mean by "first-class" here.
>
> 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.

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

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

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

>> Again, the destination for goto and gosub must be resolvable at compile
>> time.  Could a future version of the filePro virtual machine (let's try
>> to stay buzzword-compliant here) be enhanced to allow these destinations
>> to be runtime-resolvable?  Yes, it would be possible.
>
> Ah.  Ok; I can see why you'd do it that way, and that would be a good
> reason to override (dummy) dereference for those particular commands.
>
> It seems to me that there are *other* places we might want to do that
> that we can't, but I can't remember one at the moment...

-- 
Read the truth behind the movie "Expelled" at <http://www.ExpelledExposed.com>
--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com