RfD - Enhanced local variable syntax, v4 (long)

Stephen Pelc wrote:
> On Tue, 12 Aug 2008 11:11:57 -0400, Jonah Thomas <jethomas5@gmail.com>
> wrote:
>
>> stephenXXX@mpeforth.com (Stephen Pelc) wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
>>>
>>>> If you really want rest of the stack comment in the braces, put it
>>>> there:
>>>>
>>>> : front-string { c-addr1 u1 c-addr2 u2 ( -- c-addr3 u3 ) }
>>> Now we've got to change common practice, and rewrite any validation
>>> tools we may be using. In other words, this notation is a code
>>> breaker. One of the successful parts of the ANS process was the
>>> stringent effort to avoid breaking existing code.
>> I don't particularly advocate that change, but would it break much code?
>> You could rewrite a few vaidation tools to accept the new practice -- as
>> well as continue to accept what you already do. Or if you happen to
>> allow ( inside { then wouldn't the new code just work? Surely you don't
>> *require* every { to have a -- ending } addition, do you? If it's
>> commented out have you lost anything?
>
> The majority of existing systems will generate and extra local called
> '('. This will not be used. So I would expect most systems to survive.
> However, we have tools with clients that process stack comments with
> braces. These will have to be upgraded if they the client upgrades the
> compiler.
>
> We have to reserve '(', and presumably also '\'. Think of the
> firestorm about the '[' reservation. Win32Forth accepts '\' as well
> as '|' as the arguments/values separator. IMHO, staying with common
> practice avoids the law of unintended consequences.
>
>> It does make sense to stay with common practice as a general rule, and I
>> don't see that this change would be an improvement. But would it really
>> break existing code?
>
> Yes.

Excuse me, but the practice you're describing has been non-standard for
15 or 24 years (depending which statement you're referring to). No
reason why it can't continue to be if you prefer it. No code "broken"
that isn't already non-standard.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On Tue, 12 Aug 2008 07:06:19 -1000, Elizabeth D Rather
<erather@forth.com> wrote:

>Excuse me, but the practice you're describing has been non-standard for
>15 or 24 years (depending which statement you're referring to). No
>reason why it can't continue to be if you prefer it. No code "broken"
>that isn't already non-standard.

The guts of this proposal is a notation to add uninitialised
local values to Forth. There is common practice in the brace
notation, as indicated by implementation in:
gforth
Win32Forth
Neon
Yerk
PowerMops
VFX Forth and cross compilers
...

As I've heard you say many times, one function of a standard
is to codify common practice. This proposal codifies it. That's
all. The current ANS standard has no locals syntax with
uninitialised values. Common practice and postings here indicate
to me that this facility is required.

Gforth, iForth and MPE Forths include locals implementations with
more facilities than are in this proposal, which is thus a lowest
common denominator proposal. In the Forths that provide both the
brace notation and the LOCALS| ...| notation, the brace notation
is far more widely used, in one case by a factor of 20:1 or more.

Stephen


--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>'¦' (ASCII 0xA6)

That's not an ASCII character.

>The use of local types is contentious as they only become useful
>if TO is available for these.

That's nonsense. I hardly ever use TO with locals, but I do use F:
and D: now and then (and usually without using TO on those locals).
But it's ok if you don't want to deal with additional types in this
proposal; unlike some other people, I find proposals that propose
something useful acceptable even if they don't solve everything.

>Standardisation of operators with (for example) floats needs to
>be done before the local types extension can be incorporated into
>Forth200x.

No.

> More preparatory standardisation
>needs to be done before local types can be standardised.

No.

>Forth 200x text
>===============
>13.6.2.xxxx {
>brace LOCAL EXT
>
>Interpretation: Interpretation semantics for this word are undefined.
>
>Compilation:
>( "<spaces>arg1" ... "<spaces>argn" | "<spaces>lv1" ... "<spaces>lvn"
>-- )
>
>Create up to eight local arguments by repeatedly skipping leading
>spaces, parsing arg, and executing implementation defined actions.

Delete "up to eight". The limit is defined in Forth-94 13.3.3.2 f),
no need to repeat it here. (It's a bad excuse that this text is
modeled after the LOCALS| text; obviously LOCALS| is bad not just in
what it standardized, but also in how it was standardized.)

>The list of local arguments to be defined is terminated by "|",
>"--" or "}". Append the run-time semantics for local arguments
>given below to the current definition. If a space delimited '|' is
>encountered, create up to eight local values by repeatedly skipping

Delete "up to eight". Also, the total number should probably be 8 if
we consider 13.3.3.2 f).

>leading spaces, parsing the "lv" token,

I don't like the '"lv" token' language. Better make the stack comment

( "<spaces>name1" ... "<spaces>namem" | "<spaces>namem+1" ... "<spaces>namen" -- )

and always write 'parsing name'.

> and creating the local
>element. The list of local values to be defined is terminated by
>"--" or "}". Append the run-time semantics for local values
>given below to the current definition. If "--" has
>been encountered, further text between "--" and } is ignored.
>
>Local argument run-time: ( x1 ... xn -- )
>Local value run-time: ( -- )

There is just one run-time semantics for { with one stack comment:

( x1 ... xm -- )

The m here corresponds to the m in "namem" in my stack comment for
compilation.

>Initialize up to eight local arguments from the data stack

Delete "up to eight".

>Local argument arg1 is initialized with x1, arg2 with x2 up
>to argn from xn, which is on the top of the data stack. When
>invoked, each local argument will return its value. The value
>of a local argument may be changed using 13.6.1.2295 TO.
>
>Initialize up to eight local values. The initial contents of local
>values are undefined.

So they are uninitialized. I think these two sentences could be
deleted, or they should be reworded. Certainly delete "up to eight".

> When invoked, each local value
>returns its value. The value of a local value may be changed
>using 13.6.1.2295 TO. The size of a local value is a cell.
>The user may make no assumption about the order and contiguity of
>local values in memory.

The last sentence makes no sense. The user gets no address of local
values from the system, so there is no way they could make use of such
assumptions. Delete that sentence.

>
>Ambiguous conditions:
>a) The { ... } text extends over more than one line.
>b) { ... } is declared more than once in a word.

Replace "declared" with "used". Are there any systems that have this
restriction? Otherwise, I would suggest lifting it. Even if we want
to keep it, I would certainly not put it in this part; it's already in
13.3.3.2 (which may have to be suitably adapted).

>c) Parsing units '|', ']', '--' and '}' are not whitespace delimited.

What's the point of ']' here? A remnant of the old version?

If |, --, or } are not whitespace-delimited, they are not --, |, and
}, but funny local names. I don't think that one needs to specify
that explicitly.

OTOH, there is one thing you missed that should be specified explicitly:

c) Local names ending in ":" or "[" are an ambiguous condition.

>Reference implementation
>=========================
>(currently untested)

There is no need to put an untested implementation here that is based
on a horrible word that does not exist anywhere. We can have a tested
implementation based on the standard word (LOCAL). What is missing
and is more important than a reference implementation is tests. If
you put tests here, I'll update
<http://www.complang.tuwien.ac.at/forth/anslocal.fs> to support the
"|" part.

- 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

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>If you really want rest of the stack comment in the braces, put it
>there:
>
>: front-string { c-addr1 u1 c-addr2 u2 ( -- c-addr3 u3 ) }
....
>or here:
>
>: front-string { c-addr1 u1 c-addr2 u2 } ( -- c-addr3 u3 )
....

These are two wrong stack-effect comments that are situated in funny
places. They are wrong because they claim that FRONT-STRING takes no
items from the stack, whereas in reality it takes four. I guess
Stephen would fire you on the spot for writing lying stack-effect
comments.

>At least then it's immediately clear which part is the comment and
>which the initialization of locals.

That's also clear with the { ... -- ... } notation once you are
literate in that notation.

[About
: front-string ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 )
{ c-addr1 u1 c-addr2 u2 }
]
>> This is harder to read and write, and thus would discourage factoring.
>> Also, it adds redundancy, and that tends to lead to errors that are
>> relatively hard to find.
>
>There is no added redundancy,

The stack elements occur twice.

> it's *easier* to read

It's longer, and one has to check whether the items in the stack
effect correspond to the local names. That all makes it harder to read.

> and it's not
>significantly harder to write.

It is harder, and every hardship is significant.

>> >I thought that { a b -- c d } meant that the contents of the
>> >variables after the "--" would be automatically returned as the
>> >result
>
>> That would throw away some of the advantages of having a stack, and
>> would require using locals where they are not needed. It would also
>> make the code longer.
>
>It would. It's a despicable, dreadful idea.

Ah, so it's just a straw man argument.

> But it's what the
>comment suggests.

Maybe it does to you. It does not to the significant number of people
who implemented this syntax, and not to the even larger number of
people who have used it. Should we keep away from standardizing
common practice just because one person has a misconception? If so,
we will never get anything standardized.

- 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

stephenXXX@mpeforth.com (Stephen Pelc) wrote:
> Jonah Thomas <jethomas5@gmail.com> wrote:
> >stephenXXX@mpeforth.com (Stephen Pelc) wrote:
> >> Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> >>
> >> >If you really want rest of the stack comment in the braces, put it
> >> >there:
> >> >
> >> >: front-string { c-addr1 u1 c-addr2 u2 ( -- c-addr3 u3 ) }
> >>
> >> Now we've got to change common practice, and rewrite any validation
> >> tools we may be using. In other words, this notation is a code
> >> breaker. One of the successful parts of the ANS process was the
> >> stringent effort to avoid breaking existing code.
> >
> >I don't particularly advocate that change, but would it break much
> >code? You could rewrite a few vaidation tools to accept the new
> >practice -- as well as continue to accept what you already do. Or if
> >you happen to allow ( inside { then wouldn't the new code just work?
>
> The majority of existing systems will generate and extra local called
> '('. This will not be used. So I would expect most systems to survive.
> However, we have tools with clients that process stack comments with
> braces. These will have to be upgraded if they the client upgrades the
> compiler.

I still don't see that the " ( -- " notation is better, and I still
don't see why it should be a big deal to allow it.

When -- comments out to the end of the line, what harm would it do to
have ( be a comment too? In the case that -- starts a comment, it ought
to be very easy to have ( duplicate that.

And when -- starts a special tool to process stack comments, would it be
hard to have ( and ) in this special context be no-ops? You'd want to
extend your tools a very little bit in case some of your customers
started to use the new standard practice, but their old code needn't
break at all. It looks to me like the worst that would happen is that
some of your existing tools would not work with brand-new standard code.
Just like every Forth system in the world broke with POSTPONE and
ENVIRONMENT? and CS-PICK etc.

> We have to reserve '(', and presumably also '\'.

How likely is it that there's existing code which uses ( as a local
name?

> Think of the
> firestorm about the '[' reservation. Win32Forth accepts '\' as well
> as '|' as the arguments/values separator. IMHO, staying with common
> practice avoids the law of unintended consequences.
>
> >It does make sense to stay with common practice as a general rule,
> >and I don't see that this change would be an improvement. But would
> >it really break existing code?
>
> Yes.

I tend to think you're on the right side of this argument. It just looks
like you're arguing too hard, overstating your claims. Maybe I've
misunderstood.

Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Tue, 12 Aug 2008 05:50:11 -0500, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:

> >If you really want rest of the stack comment in the braces, put it
> >there:
> >
> >: front-string { c-addr1 u1 c-addr2 u2 ( -- c-addr3 u3 ) }

> Now we've got to change common practice, and rewrite any validation
> tools we may be using. In other words, this notation is a code
> breaker. One of the successful parts of the ANS process was the
> stringent effort to avoid breaking existing code.

On the one hand we've got a request for discussion and on the other
"we must not change established practice." What, then, is the point
of the request for discussion? Going through the motions for
appearance's sake?

> >: front-string { c-addr1 u1 c-addr2 u2 } ( -- c-addr3 u3 )

> Now you have broken code readability for those people (and they
> exist) who use double comments on name lines to indicate either
> compile and runtime actions of defining words, or to indicate data
> stack and return stack actions.

I don't understand this comment. How does this "break code
readability?

I take your point about existing practice, but there is a flaw in your
reasoning. It seems that if someone invents something for Forth and
manages to get several implementations to use it, then it must be
adopted by the standard -- no matter how awful -- because we must not
break existing code. Is that really the case, or am I perhaps
misunderstanding you?

Andrew.

On Tue, 12 Aug 2008 19:52:35 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>There is no need to put an untested implementation here that is based
>on a horrible word that does not exist anywhere. We can have a tested
>implementation based on the standard word (LOCAL).

See Forth200x, rev 2, 13.3.3.1 b) 2) which conflicts with
uninitialised locals. We certainly could produce a lower level
factor. Perhaps you would like to provide one.

Stephen


--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On Aug 12, 10:06*am, Elizabeth D Rather <erat...@forth.com> wrote:
>
> Excuse me, but the practice you're describing has been non-standard for
> 15 or 24 years (depending which statement you're referring to). *No
> reason why it can't continue to be if you prefer it. *No code "broken"
> that isn't already non-standard.
>
Two factions have emerged. Those that use braces for comments and
those that use braces for locals.

What about extending the LOCAL| syntax? I think an automated tool
could convert the extended { a b c } syntax to the LOCAL| c b a |
syntax.

-Brad

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>We have to reserve '(', and presumably also '\'.

That's a good idea, because at least some systems (at least Gforth)
already allow comments in locals definitions, and want to keep this
feature.

>Win32Forth accepts '\' as well
>as '|' as the arguments/values separator.

That's another reason to reserve '\'.

>>It does make sense to stay with common practice as a general rule, and I
>>don't see that this change would be an improvement. But would it really
>>break existing code?
>
>Yes.

You have programs that use '(' or '\' as a locals name? Even if you
do, reserving these names does not break these programs.

- 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

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Tue, 12 Aug 2008 19:52:35 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>There is no need to put an untested implementation here that is based
>>on a horrible word that does not exist anywhere. We can have a tested
>>implementation based on the standard word (LOCAL).
>
>See Forth200x, rev 2,

There is no rev 2. Do you mean Draft 07.2r?

> 13.3.3.1 b) 2) which conflicts with
>uninitialised locals.

Not at all. Any implementation that initializes with any value is an
implementation of an uninitialized local. It's certainly better than
an untested implementation based on a word that is (fortunately) not
implemented anywhere.

- 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