Re: RfD - Enhanced local variable syntax, v4 (long)

Bernd Paysan <bernd.paysan@xxxxxx> writes:
Anton Ertl wrote:
That conflicts with VFX and possibly other systems (John Hayes wrote
about the VFX-style meaning of the "|" already in SigForth Newsletter
4(2), Fall '92) and, more importantly, with programs written for these
systems, so there is no chance that your scoping syntax is going to be
standardized.

My syntax is from spring 1992, so it predates John Hayes.

Currently I have no access to the paper, but IIRC he wrote that (then)
existing systems support this syntax.

But anyway, the question is not about priority, but about how to
resolve this conflict. I see the following options:

1) "|" is standardized as proposed by Stephen.

a) You (and possibly other bigForth users) rewrite the programs
that use the old bigForth "|" to use a different syntax, e.g.,
SCOPE...ENDSCOPE.

b) bigForth supports both syntaxes, based on a switch; e.g., by
default it supports the old bigForth syntax, and after an
extension query for X:locals (or somesuch), it supports the
standard meaning.

2) "|" is not standardized.

a) Stephen selects a different separator. According to the RfD "\"
has some existing practice, but OTOH has a conflict with "\" as
a comment-starting character that can also be used in locals
definitions (e.g., in Gforth).

b) There was a b), but I forgot what it was:-).

I did put it into Gforth back then, as well, but then you wrote the better
(but more complex) automatic scoping package (my locals.fs is still there).
I prefer the automatic scoping, too, but won't recommend it for a standard
(too complex to implement).

I also don't think that it is standardizable in its current form.
There are too many implementation artifacts there.

A simpler form would be that locals are visible at least up to the
next word that accesses a control-flow stack item below the current
depth of the control-flow stack; i.e., the locals would not be visible
across control-flow words, except across complete control structures.
Some restrictions on programs would be necessary to allow systems that
have longer scopes (like Gforth).

In terms of implementation this would probably be hardly more effort
than SCOPE...ENDSCOPE, but probably more invasive. So it's probably
not going to fly as a proposal.

After having ported a number of my scoped locals constructs to VFX, my
opinion is now quite strong: I definitely want at least explicit scope (can
be with SCOPE ... ENDSCOPE), and one declaration of locals per scope.

I would prefer multiple declarations of locals per scope, otherwise I
would need to write a lot of SCOPE...ENDSCOPE wrappers.

I
don't see the point of uninitialized locals, they are only necessary due to
this limitation. I oppose the use of | as separator, breaks my syntax
(published first).

Do you have any idea how many programs were written that use that
syntax?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2008: http://www.euroforth.org/ef08.html
.

Relevant Pages

  • Re: The Promise of Forth
    ... not characters, you can't add characters, nor multiply them, ... It isn't standard, and it isn't used widely enough. ... Right, and no convenient syntax for local variables is standard, ... there is one standard syntax for locals. ...
    (comp.lang.forth)
  • Re: portable and fast word with many arguments?
    ... Create up to eight local identifiers by repeatedly skipping leading ... that the other system has the same syntax, because the standard doesn't ... force this syntax, as far as I understand it. ... and there would effectively be no locals. ...
    (comp.lang.forth)
  • Re: portable and fast word with many arguments?
    ... locals| res lparam wparam msg hwnd | ... at least the standard defines a syntax. ...
    (comp.lang.forth)
  • Re: OO ruminations
    ... S" is not intended to be the basis of a nice new syntax (actually, ... LOCALS| is also not intended to generate nice new syntax. ... But we don't have such a common library concept. ... New standard: http://www.forth200x.org/forth200x.html ...
    (comp.lang.forth)
  • Re: Program compression
    ... be interested in Seed7. ... syntax and semantic can be defined in Seed7: ... Are there standard packages available to provide these as ... Now the ability to define *variants* of those common operators ...
    (comp.programming)