stephenXXX@[EMAIL PROTECTED]
(Stephen Pelc) writes:
>On 21 Aug 2006 16:04:53 -0700, "Alex McDonald"
><alex_mcd@[EMAIL PROTECTED]
> wrote:
[Stephen Pelc]
>>> 6) { and } are visually confusing. Perhaps select another character or
>>> string, which would allow existing implementations to do their own
>>> thing unmolested.
>
>Common practice is to use { ... }. Is changing a name in common use
>because we need new gl***** or bigger monitors good enough reason
>for change?
No. Anoter solution to the gl***** problem is to use a colouring
editor. E.g., Emacs with gforth.el colours Forth comments in red by
default, and locals declarations in beige.
>>7) LOCALS| has the following restrictions on the use of the rstack;
>>
>>13.3.3.2 Syntax restrictions
>>c) Locals shall not be declared until values previously placed on the
>>return stack within the definition have been removed;
>
>Removing this restriction would break code. I will add it.
No need to. This is a general restriction on locals, not on LOCALS|.
It also applies to locals defined through (LOCAL).
Also I don't see that removing this restriction would break existing
programs, whether standard or not: Standard programs don't go there,
and I doubt that there are non-standard programs that rely on any
particular behaviour in that area. It might require changes to some
systems, though.
>>d) After a definition's locals have been declared, a program may place
>>data on the return stack. However, if this is done, locals shall not be
>>accessed until those values have been removed from the return stack;
>
>Do any current systems suffer if this restriction is removed?
Not Gforth. Gforth also does not have the restriction above.
>Implementers please respond! Current MPE systems will not suffer
>unless { ... } is used a second time - should this be an ambiguous
>condition?
It is already.
However, I find it very practical to be able to use { ... } several
times, rather than having to declare locals in places where I don't
have a value for them, and then using TO when I have a value for them.
>Similarly, many current systesms, including MPE's, will break
>if { ... } is used inside a control structure, e.g.
>
>: foo \ ...
> ... if
> { a b c -- }
> ...
> else
> ...
> then
>;
>
>I propose to add this as an amiguous condition as below.
It is already (13.3.3.2 b).
Followups set to c.l.f.
- 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 2006: http://www.complang.tuwien.ac.at/anton/euroforth2006/


|