RfD - Enhanced local variable syntax, v4 (long)

Stephen Pelc wrote:

> It's a standards proposal. The conceptual clarity comes from
> considering the brace notation as a formal comment that mirrors
> the conventional stack comment notation:
> ( a b c -- d e }
> This now extended to include local values by adding the '|'
> separator and changing the brackets to braces:
> { a b c | x y z -- d e }
> Since we permit the data stack and return stack to be manipulated
> between the closing '}' and ';' we chose 15+ years ago to ignore
> what is between the '--' and the closing brace.

I actually thought I responded to this almost 12 hours ago. But I
don't
see it. So apologies if this is redundant.

Stephen is right. Having the benign "-- d e" does no harm but can
help
significantly in having the locals declaration do double duty as the
stack effect comment. This applies to most cases for me. Where the
stack effect doesn't match the locals declaration, no problem. Just
declare them separately. For example:

: foo ( a b c -- d e ) { b c }
...


> The system is implemented in Win32Forth and gforth

It is also used in Neon, Yerk, and PowerMops: spanning 24+ years of
successful use.

-Doug

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>> However, all text between -- and } is
>> ignored. The facility is there to permit the notation to form a
>> complete stack comment. This eases documentation and current
>> users of the notation like this facility.
>
>No, this is vile. Mixing semantically significant code with comments
>in such an arbitrary way is a bad idea: it has no precedent in Forth,
>and it is unnecessarily confusing.

This has been used for many years in many systems, so there is ample
precedent. And the users have not found it confusing, and I don't
remember a complaint about that part of the notation as used in real
code.

Let's consider one example (the first use of locals in
<http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/libcc.fs?view=markup>

: front-string { c-addr1 u1 c-addr2 u2 -- c-addr3 u3 }
\ insert string c-addr2 u2 in buffer c-addr1 u1; c-addr3 u3 is the
\ remainder of the buffer.
assert( u1 u2 u>= )
c-addr2 c-addr1 u2 move
c-addr1 u1 u2 /string ;

Without the -- part we would have to write:

: front-string ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 )
\ insert string c-addr2 u2 in buffer c-addr1 u1; c-addr3 u3 is the
\ remainder of the buffer.
{ c-addr1 u1 c-addr2 u2 }
assert( u1 u2 u>= )
c-addr2 c-addr1 u2 move
c-addr1 u1 u2 /string ;

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.

>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. For the example above that would result in:

: front-string { c-addr1 u1 c-addr2 u2 -- c-addr3 u3 }
\ insert string c-addr2 u2 in buffer c-addr1 u1; c-addr3 u3 is the
\ remainder of the buffer.
assert( u1 u2 u>= )
c-addr2 c-addr1 u2 move
c-addr1 u1 u2 /string to u3 to c-addr3 ;

Not an improvement.

Anyway, that idea conflicts with the existing usage in many programs
and systems, so it wouldn't fly even if it was a good idea.

>In any case, it makes no sense to use the { } as the stack comment
>for a word since not every to a word need be placed into a local
>variable.

If you don't need every parameter as a local (that's what you meant,
right?), you are free to write an ordinary stack comment followed by a
locals definition without (or, if you want, with) "--".

- 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

Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Mon, 11 Aug 2008 11:10:06 -0500, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:

> >> The outputs are provided in the notation so that complete stack
> >> comments can be produced. However, all text between -- and } is
> >> ignored. The facility is there to permit the notation to form a
> >> complete stack comment. This eases documentation and current
> >> users of the notation like this facility.

> >No, this is vile. Mixing semantically significant code with
> >comments in such an arbitrary way is a bad idea: it has no
> >precedent in Forth, and it is unnecessarily confusing.

> You don't have to do it that way
> { a b | c d }
> is legal according to the proposal. There are, believe it or not,
> Forth systems out there that use '--' as a comment to end of line.

> To rephrase in a reductionist way:
> "Mixing semantically significant code with comments
> is a bad idea"
> So all comments are a bad idea?

No, of course not. Comments are *separated* from the surrounding code
by clearly visible comment markers.

> As you well know, the point of the '--' is to avoid having to write
> both a stack comment and a very similar locals declaration. As you
> well know, having those will be a source of error, so in the best
> Forth practice, we eliminate the source of error.

How can that be so? The locals declaration and the stack comment
aren't necessarily the same.

> After 15 years of use we and our clients know that this brace
> notation works well. That it also exists in a similar form in
> Win32Forth and gForth indicates utility.

> If you don't like the '--', don't use it, and write a stack comment
> as well as the locals declaration. Your choice.

There is a very good part to this proposal, the part that allows for
un-initialized locals. There is also some syntactic sugar. And in
this case it's pure syntactic sugar: the part of the clause after "--"
has no effect whatsoever.

I guess you could justify any extension to Forth, no matter how awful,
with "You don't have to use it." I already know I don't have to use
it: the question is not whether I have to use it but whether something
this nasty should be standardized. Just to turn your argument around,
if you want a comment, why not do:

{ a b | c d ( -- n m ) }

At least then it's immediately obvious where the comment is. Forth
already has two comment syntaxes -- one more than it needs -- and
you're adding yet another.

This proposal is like the famous Pork Barrel bills in the US where a
senator will add a rider to support his home state to an essential
finance bill. People then have a single choice: yea or nay to the
bill. If you want the finance bill passed, vote for the senator's
rider.

Dammit Steve, I really want to support this, but...

Andrew.

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> >Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> >> However, all text between -- and } is
> >> ignored. The facility is there to permit the notation to form a
> >> complete stack comment. This eases documentation and current
> >> users of the notation like this facility.
> >
> >No, this is vile. Mixing semantically significant code with comments
> >in such an arbitrary way is a bad idea: it has no precedent in Forth,
> >and it is unnecessarily confusing.

> This has been used for many years in many systems, so there is ample
> precedent. And the users have not found it confusing, and I don't
> remember a complaint about that part of the notation as used in real
> code.

> Let's consider one example (the first use of locals in
> <http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/libcc.fs?view=markup>

> : front-string { c-addr1 u1 c-addr2 u2 -- c-addr3 u3 }
> \ insert string c-addr2 u2 in buffer c-addr1 u1; c-addr3 u3 is the
> \ remainder of the buffer.
> assert( u1 u2 u>= )
> c-addr2 c-addr1 u2 move
> c-addr1 u1 u2 /string ;

> Without the -- part we would have to write:

> : front-string ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 )
> \ insert string c-addr2 u2 in buffer c-addr1 u1; c-addr3 u3 is the
> \ remainder of the buffer.
> { c-addr1 u1 c-addr2 u2 }
> assert( u1 u2 u>= )
> c-addr2 c-addr1 u2 move
> c-addr1 u1 u2 /string ;

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 ) }
\ insert string c-addr2 u2 in buffer c-addr1 u1; c-addr3 u3 is the
\ remainder of the buffer.
assert( u1 u2 u>= )
c-addr2 c-addr1 u2 move
c-addr1 u1 u2 /string ;

or here:

: front-string { c-addr1 u1 c-addr2 u2 } ( -- c-addr3 u3 )
\ insert string c-addr2 u2 in buffer c-addr1 u1; c-addr3 u3 is the
\ remainder of the buffer.
assert( u1 u2 u>= )
c-addr2 c-addr1 u2 move
c-addr1 u1 u2 /string ;

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

> 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, it's *easier* to read and it's not
significantly harder to write.

> >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. But it's what the
comment suggests.

Andrew.

On Tue, 12 Aug 2008 05:42:06 -0500, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>> As you well know, the point of the '--' is to avoid having to write
>> both a stack comment and a very similar locals declaration. As you
>> well know, having those will be a source of error, so in the best
>> Forth practice, we eliminate the source of error.
>
>How can that be so? The locals declaration and the stack comment
>aren't necessarily the same.

Experience shows that in the majority of cases, they are.

>There is a very good part to this proposal, the part that allows for
>un-initialized locals. There is also some syntactic sugar. And in
>this case it's pure syntactic sugar: the part of the clause after "--"
>has no effect whatsoever.

It aids readability. I happen to think that's important.

I have been reminded that this notation is also supported by
Neon, Yerks and PowerMops, and has been in use for 24+ years.
One part of writing a standard is to formalise common practice.
Common practice is here in conflict with language purity.

The notation is a reasonable compromise for those who need
local values. It is sufficiently widespread and has enough
history to say that it is common practice.

>At least then it's immediately obvious where the comment is. Forth
>already has two comment syntaxes -- one more than it needs -- and
>you're adding yet another.

It's not for text comments - it's for completing a stack notation.
Certainly using the facility for text comments is bad practice, but
avoiding duplicate and potentially conflicting entries is good
practice, even at the expense of minor impurity that does not have
to be used by ideologues.

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

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

Again, for a standard, common practice is important.

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

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?

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.

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, 11:11*am, Jonah Thomas <jethom...@gmail.com> wrote:
> stephen...@mpeforth.com (Stephen Pelc) wrote:
> > Andrew Haley <andre...@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?

It breaks on PowerMops:

: foo { a b c d ( -- e f ) }
a b + c d + ;

Error # 245 ')' read when '}' expected
: foo { a b c d ( -- e f ) }
^

It breaks on my Carbon MacForth implementation (based on Roelf
Toxopeus's code):

: foo { a b c d ( -- e f ) }
a b + c d + ;

1 2 3 4 foo .s

( 1 ) \ 5

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

I believe that adding parens inside the braces adds nothing. It does
break existing code, and to my eye the above could easily be misread
as meaning foo takes no parameters from the stack.

> It does make sense to stay with common practice as a general rule,

Agreed.

> and I don't see that this change would be an improvement.

Agreed.

> But would it really break existing code?

Yes.

-Doug

Stephen Pelc wrote:

> Well, it's that time of year again, so I'm in proposal mode.
> Don't forget to attend EuroForth 2008 and the Forth200x standards
> meeting in gorgeous glorious Vienna from 25-28 September 2008.
> http://www.euroforth.org
>
> I have separated the enhanced local variable syntax from the
> local buffer proposal. The main extension in this proposal
> is the separation of initialised local arguments from
> uninitialised local values.

Thanks. My comment:

bigFORTH provides scoped local declarations. Unlike Gforth's scoping,
bigFORTH's is explicit (bigFORTH's syntax is older). The syntax for scoped
locals is

{ local .. local | code using the locals }

so that would conflict with the proposal. There is some actual use of the
scoped locals, though not very often (if you factor correctly, you only
have one point where locals need to be defined ;-). If you declare locals
once with { locala localb }, then the scope closes at the end of the
definition.

Like in Gforth, when I use scoped locals, then to escape the "problem" of
needing uninitialized locals. Just define the locals after the value is
computed. Multiple local definitions are possible in bigFORTH and Gforth.
I've never encountered the need to use an uninitialized local, apart from
local buffers (which are by default uninitialized, anyway).

I'm using typed locals, too, for float with the prefix f: and for structures
(records) with the prefix r: <structure> (together with bigFORTH's
structure package, but since that just does >BODY @ to obtain the size,
it's compatible with many other structure packages). r: <struct> is thus
equivalent to [ sizeof <struct> ] in the proposal.

Gforth has more types, and allows W: for normal cell locals (D: for double,
F: for float, C: for char). It also has pointer locals, declared with W^,
D^, F^, C^, but (yet) no buffer locals.

I could also imagine adding an o: <class> local for object pointers
(initialized).

Bottom line: In general, the proposal is good. I don't see much need for
uninitialized locals, don't do that, also avoid "to <local>".

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/