RfD - Enhanced local variable syntax, v4 (long)

Doug Hoffman <dhoffman@talkamerica.net> writes:
>Anton Ertl wrote:
>> Doug Hoffman <dhoffman@talkamerica.net> writes:
>
>>> If the unified notation works equally well for separate or shared-stack,
>>> it makes me wonder why the standards document shows both.
>>
>> Maybe someone on the standards committee still remembers the reason?
>
>After digging deeper into the standard document I find what appears to
>be the reason:
>
>----------------------
>12.2.2.2 Stack notation
>
>Floating-point stack notation when the floating-point stack is separate
>from the data stack is:
>
>( F: before - after )
>-----------------------
>
>The way I read that is separate stack effect notation is to be used when
>there are separate integer and FP stacks. If the Forth uses unified
>stacks, then the unified notation is to be used. Seems logical.

Maybe it seems, but it isn't. The unified notation contains the
complete information. The separate notation can be generated
automatically from it, so specifying it is redundant.

However, having a separated notation in those cases where the stacks
are separate is consistent with the separate notation for the other
logically or physically separate stacks, e.g., the control-flow stack
or the return stack.

- 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

"Ed" <nospam@invalid.com> writes:
>
>"Doug Hoffman" <dhoffman@talkamerica.net> wrote in message
>news:d29a4$48af9661$c4b2db6$19448@DIALUPUSA.NET.. .
>> Given that, it seems difficult to explain the existence of the other
>> syntax in so many other Forths for so many years, and now the existence
>> of an RfD for the same.
>
>Not so hard to explain. Most grow up with computer languages
>that use infix notation. Infix abounds everywhere, including maths.
>It's easy to slip back into familiar or preferred territory.
>
>{ is an infix function with infix parameter ordering, disguised as
>a stack comment.

If { is infix, so is LOCALS|, which is in the same position.

If the order of the names in {...} is an infix order, then the infix
poison has been injected in Forth with the invention of stack effect
comments, which use the same ordering.

>Forth is a stack-based machine. The best functions, therefore,
>are those which use the stack most efficiently. That's it.

Face it: Locals are a way to avoid dealing with stacks. If you want
to be a stack purist, better eschew them completely. Pretending that
writing the names in the wrong order somehow preserves the use of the
stack is self-delusion.

- 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

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2008Aug27.214451@mips.complang.tuwien.ac.at.. .
> "Ed" <nospam@invalid.com> writes:
> >
> >"Doug Hoffman" <dhoffman@talkamerica.net> wrote in message
> >news:d29a4$48af9661$c4b2db6$19448@DIALUPUSA.NET.. .
> >> Given that, it seems difficult to explain the existence of the other
> >> syntax in so many other Forths for so many years, and now the existence
> >> of an RfD for the same.
> >
> >Not so hard to explain. Most grow up with computer languages
> >that use infix notation. Infix abounds everywhere, including maths.
> >It's easy to slip back into familiar or preferred territory.
> >
> >{ is an infix function with infix parameter ordering, disguised as
> >a stack comment.
>
> If { is infix, so is LOCALS|, which is in the same position.
>

LOCALS| is a simple iteration of the definer (LOCAL).
The syntax of LOCALS| is thus determined by (LOCAL).

In contrast { has a parameter list where each item can have
it's own meaning, rules, and ordering as determined by the
creator. The objects in the list may be expanded to include
almost anything.

No, they are quite different.

> If the order of the names in {...} is an infix order, then the infix
> poison has been injected in Forth with the invention of stack effect
> comments, which use the same ordering.
>
> >Forth is a stack-based machine. The best functions, therefore,
> >are those which use the stack most efficiently. That's it.
>
> Face it: Locals are a way to avoid dealing with stacks. If you want
> to be a stack purist, better eschew them completely. Pretending that
> writing the names in the wrong order somehow preserves the use of the
> stack is self-delusion.

I'll use whatever is most sensible for the task at hand. Should I
elect to use locals, I see no necessity to abandon forth convention
particularly as it produces consistent syntax. I like the idea that if
I use either global or local values that the name order ends up
the same.

LOCALS| has the correct ordering for a forth function. It's not a
stack comment, and doesn't pretend to be one. Forth already has
a mechanism for handling stack comments.

Ed wrote:
> [...]
>
> LOCALS| is a simple iteration of the definer (LOCAL).
> The syntax of LOCALS| is thus determined by (LOCAL).
>
> In contrast { has a parameter list where each item can have
> it's own meaning, rules, and ordering as determined by the
> creator. The objects in the list may be expanded to include
> almost anything.
>
> No, they are quite different.

I must say that when I use locals, it's always LOCALS|...|.
That's because I care about portability, maybe sometimes
obsessively.

I don't at all have a problem remembering that it's the wrong
order or keeping track when initializing locals.

But I would really, really prefer that standard locals use stack
comment order.* :-)

> [...]
>
> I'll use whatever is most sensible for the task at hand. Should I
> elect to use locals, I see no necessity to abandon forth convention
> particularly as it produces consistent syntax. I like the idea that if
> I use either global or local values that the name order ends up
> the same.
>
> LOCALS| has the correct ordering for a forth function. It's not a
> stack comment, and doesn't pretend to be one. Forth already has
> a mechanism for handling stack comments.

I'm not sure what's the natural meaning of "forth function". In
any case, whether or not LOCALS|...| was or should have been
intended to be like a stack comment, it seems that {...} *does*
aim to be like one, in a pretty interesting way.

-- David

*That's the order implemented for dynamic string arguments.

Anton Ertl wrote:
> 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.

b) is the more likely option. And there probably will be a flag to be set
and cleared depending on which sources you load - like the legacy flag for
C bindings.

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

My suggestion: '+' or '++'. As local name, '+' is very useless.

{ a b + c d -- e f }
{ a b ++ c d -- e f }

means "take a and b from the stack plus define c and d uninitialized". From
the look of it, I like ++ more.

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

Allow multiple declarations of locals, and the "problem" '|' tries to
address in the proposal goes away. I've rewritten parts of MINOS to use
only one place for local definitions, and the result was that for the first
time in my life I needed an uninitialized local ;-). Since bigFORTH doesn't
have those, I "emulate" them by putting zeros on the stack.

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

That's why I've chosen a one-letter syntax. You declare { locals | code }
and it's far less obtrusive than SCOPE { locals } code ENDSCOPE. From an
implementation point of view, having all closing structure words check if
there's an open scope seems to be trivial for me (they do something
like ?pairs or so to check if there's a valid CS-entry, anyway, just hook
it there; it will close all local scopes until it finds the CS-entry it
looks for), so a simpler version of Gforth's automatic scoping seems to be
feasible, too.

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

No. My own usage of locals is pretty limited, mostly MINOS and examples. And
half of that is now least-common-denominator due to the VFX-MINOS porting
effort.

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: RfD - Enhanced local variable syntax, v4 (long)

>mhx@iae.nl (Marcel Hendrix) writes:
>>Bruce McFarling <agila61@netscape.net> writes Re: RfD - Enhanced local variable syntax, v4 (long)
[..]
>>> This will get confusing if used with arrays ... better to make it a
>>> specialization of the generic "d:", "f:"?

>>> ... { nb d: quack -- u }
>>> ( F: -- r )
>>> 0e 0e 0e 0e {f: t0 t1 t2 t3 -- r }
>>> 0+1i 1+0i {f: z: a z: c }

>>or, even simpler:

>>... { s: nb -- u }
>> { d: quack -- }
>> 0e 0e 0e 0e { f: t0 t1 t2 t3 -- r }
>> 0+1i 1+0i { z: a c }

> Not a good idea. You already made one additional mistake (in addition
> to the reversal of a and c) above:

What a terribly condescending and suggestive remark (again). As you seem
to be encouraged in continuing this line of discussion when the opponent
tries to ignore your style, allow me a c+s-r of my own.

I count 0 uses of d: and 1 use of f: in the entire gforth 0.6.2 distribution
(excluding the two files that define locals). There seem to be no uses of
flocal and no uses of dlocal.

In bigforth (as far as needed for Minos/Theseus) I'm counting 59 occurences
of f: and no use of d:, dlocal or flocal.

In iForth I count (only in the examples directory) 1061 uses of
flocals| / flocal and 141 uses of dlocals| / dlocal. Apparently, in real use,
the "problems" of having to use a "wrong" stack order, or, FWIW, of making
errors with details of the existing standard locals (1305 uses) are not that
important. Unless I am some sort of language-masochist, I would have switched
to the "much easier" { notation already 15 years ago, or would have selected
it for the d/flocals extensions.

Of course, for this discussion it is only important what the many thousands
of users of gforth, bigforth and iForth are doing with locals. The only thing
I can contribute here is that I have never received a complaint in this direction,
and no requests to implement the "{" syntax natively. In fact, I never see any
support questions wrt locals at all.

> Doubles are on the same stack as singles, so you would have to write

> ... { d: quack } { s: nb }

Or the currently valid ... { d: quack } { nb }

> In general, this brings back the LOCALS| nightmare. It only works
> with separate FP locals definitions because they are on a separate
> stack (and it does not work for FP locals if they are on a shared
> stack).

It does not "bring it back," it's the only thing you can rely on *now*.

I guess it is now very convenient that unified stack systems exist :-)

-marcel

"Ed" <nospam@invalid.com> writes Re: RfD - Enhanced local variable syntax, v4 (long)
[..]
> LOCALS| is a simple iteration of the definer (LOCAL).
> The syntax of LOCALS| is thus determined by (LOCAL).
[.. etc. ..]

You formulate my thoughts (or should I say tastes) exactly.
I wholeheartedly agree with your arguments in this matter (in
the current and especially in your previous post).

For me, it would suffice when (FLOCAL) and (DLOCAL) were added,
or alternatively and even better, when the sizing factor of (LOCAL)
and the method table of TO were to be exposed. All the rest can be
defined in compatibility files at startup.

If an extended form of { comes through, I would applaud it if the
newly invented embellishments can be made to look like Forth
comments easily. And if the syntax replaces the now standard stack
comments, I hope the committee chooses a format that tells me what
to expect on which stack unambiguously.

-marcel

On Aug 28, 9:20*pm, m...@iae.nl (Marcel Hendrix) wrote:
> "Ed" <nos...@invalid.com> writes Re: RfD - Enhanced local variable syntax, v4 (long)
> [..]> LOCALS| *is a simple iteration of the definer *(LOCAL).
> > The syntax of *LOCALS| *is thus determined by *(LOCAL).
>
> [.. etc. ..]
>
> You formulate my thoughts (or should I say tastes) exactly.
> I wholeheartedly agree with your arguments in this matter (in
> the current and especially in your previous post).

This is also my view

> For me, it would suffice when (FLOCAL) and (DLOCAL) were added,
> or alternatively and even better, when the sizing factor of (LOCAL)
> and the method table of TO were to be exposed. All the rest can be
> defined in compatibility files at startup.

I agree to this also. I would also like to see a (LBUFFER) to define a
local buffer.

> If an extended form of { comes through, I would applaud it if the
> newly invented embellishments can be made to look like Forth
> comments easily. And if the syntax replaces the now standard stack
> comments, I hope the committee chooses a format that tells me what
> to expect on which stack unambiguously.

Mixing stack comment and locals make no sense to me. As proposed in
the buffer extension I would have to write

{ | [ 1024 ] BUF1 [ 2 cells ] BUF2 }

to declare 2 local buffers. What does this have to do with a stack
comment?

Peter Falth

> -marcel

David N. Williams wrote:
> [...]
>
> But I would really, really prefer that standard locals use stack
> comment order.* :-)

Josh Grams sent me a private email wondering why, since I yearn
for standard locals with stack comment order, I don't just use
the gforth standard implementation:

http://www.complang.tuwien.ac.at/forth/anslocal.fs

That inspired me to revisit an old modification which worked
across lines. FWIW, a new version is posted below.

It uses NEXT-INSTREAM-NAME, which is the parsing.fs library name
for Wil Baden's across line word NEXT-WORD, and
|S|-SEEK-INSTREAM, the parsing.fs word for seeking past a
whitespace delimited string across lines.

It also uses the dynamic string (dstring) word >$S-COPY, which
copies an ANS Forth string (fstring) into string space and
pushes it onto the string stack, as well as $S>, which pops a
dstring from the string stack and pushes it onto the data stack
as an fstring.

This works with gforth. It fails with pfe, as does anslocal.fs.
It's suspicious to me that pfe's (LOCAL) is immediate, but
changing only the immediacy doesn't help.

-- David


( Title: Stack-comment ordered locals across lines
File: aelocals-xl.fs
Author: David N. Williams
License: Public Domain
Version: 0.5.0
Revised: August 28, 2008
)

s" parsing.fs" required
s" dstrings.fs" required

(*
http://www-personal.umich.edu/~willi...ngs/parsing.fs
http://www-personal.umich.edu/~willi...gs/dstrings.fs

This code modifies Anton Ertl's anslocal.fs to work across lines.

Notation:
<ws> whitespace characters or line ends
<ws0> optional <ws>
<_--_text0> optional whitespace delimited "--" and text across lines
_}_ whitespace delimited "}"
*)


: get-locals ( "<ws0><name_1><ws>...<name_n><_--_text0>_}_" -- )
next-instream-name 2dup s" --" compare 0=
IF
2drop s" }" |s|-seek-instream
0= ABORT" ***locals } terminator not found" EXIT
ELSE
2dup s" }" compare 0= IF 2drop EXIT THEN
THEN
>$s-copy RECURSE $s> (LOCAL)
;


: { ( "<ws0><name_1><ws>...<name_n><_--_text0>_}_" -- ) \ compile
( p_1 ... p_n -- ) \ run
get-locals 0 0 (LOCAL)
; immediate


0 [IF]
\ broken-line version of Anton Ertl's test word
: test1-swap {
a
b
-- b a
}
.." xxx" b a ;

cr 1 2 test1-swap . . .s cr

\ version without "--"
: test2-swap { a
b }
.." xxx" b a ;

1 2 test2-swap . . .s cr
[THEN]

"David N. Williams" <williams@umich.edu> writes:
>It fails with pfe, as does anslocal.fs.
>It's suspicious to me that pfe's (LOCAL) is immediate, but
>changing only the immediacy doesn't help.

Yes, I defined

: (local) postpone (local) ;

to get rid of the immediacy, but that does not help. I also tried the
definition of LOCALS| given in section A.13 of the standard, and that
does not work on PFE, either. I guess that PFE's (LOCAL) is broken in
more ways.

- 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