local variable

[grobibi]

Hello,
There is something I don't understand with local variable with gforth.
A variable defined like this :

variable x 10

will have a general scope. How can I get a local scope for a variable
inside a word definition ? Is it possible ?

Is there a way to bypass this because, for me, a local variable has to
behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
will initialize lst to nil (but it can be initialized to anything.).
Maybe my lisp habitus drives me in a wrong way.

Thanks

[Elizabeth D. Rather]

Welcome to Forth! There are both short and long answers to your
questions. Do you have a Forth system to work with? There are good
quality free systems available, both evaluation versions of
professional-grade commercial Forths (such as SwiftForth from my
company, FORTH, Inc., url below) and free systems. There are also books
available on Forth from Amazon, some of which come in electronic form
with the evaluation versions of commercial Forths. This is the best way
to get the "long answer" to your question.

Forth is very different from Lisp, not only in programming style but
also in the "economics" of program design (what things are easier,
faster, smaller, etc.).

The preferred way of handling parameters in Forth is on the data stack,
so there is far less need for local variables. Although recent standards
have included provisions for handling local variables, doing so is
slower and somewhat more cumbersome, depending on what you're trying to do.

By the way, your definition above:
variable x 10
...will define a variable whose name is x and whose value is undefined,
leaving 10 on the stack. If you want a variable whose value is 10, it
would be:
variable x 10 x !
...where ! takes the value 10 on the stack and the address provided by x
and stores that value in the address.

There are a number of ways to define data structures in Forth, but they
cannot be used inside colon definitions (procedures). Although global
variables are discouraged in many languages, they are common and
accepted practice in Forth for values that need to be accessed in
multiple definitions or data structures.

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

[grobibi]

Thanks I discover forth since last week it's very interesting. You can
see I used lisp. So I wanted to see how to implement a word like apply.
I think the simplest way as mentioned previously in this group is for
instance with the + operator :

: { ;
: +} depth 1 ?do + loop ;
{ 3 4 5 6 7 8 +} . 33 ok

but I wanted to extend this to any word :

variable operator
: { ' operator ! compiled ;
: } depth 1 ?do operator @ execute loop ;
{ + 1 2 3 4 5 } . 15 ok
{ * 1 2 3 4 5 } . 120 ok

Looks to work well. But what about nesting this ?

{ + 1 2 { * 3 4 } 1 } . 24 ok
{ + 1 2 { * 3 4 } 0 } . 0 ok

I wanted to catch my "variable operator" inside

: } depth 1 ?do operator @ execute loop ;

so my "}" does the appropriate job.

It seems to be easy to write higher order functions (words) with forth
but there are some tricks I can get now.

[Bernd Paysan]

Just use local variables:

https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Gforth-locals.html

Gforth has both variable- and value flavored locals; the standard only has
value-flavored locals. Usually, value-flavored is fine, unless you need the
address of the variable dearly.

Example:

: foo 10 { x } x x * to x x x * . ;

should print 10000 - first square it, reassign to x, and then square it
again and print it.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

[Albert van der Horst]

In article <-cadnSbKDZx1RJnI...@supernews.com>,

In fact this is a bit of a bleak view of the capabilities of Forth.
I'd say that there is a total and fine grained control of namespaces.
Variables,other data and auxiliary words can be put in a namespace
(wordlists, vocabularies) and be inaccessable unless the subprogram
couples to the namespace.
However those variables / data structures are static, there will
not be a fresh set allocated upon a recursive execution of a Forth
word. This should not be surprising as they are defined separate
from those words. Also it is not Forth like to demand a feature --
like here re-entrancy -- unless it is specifically wanted. 1]

An example.
Suppose we want a prime table and expose only an initialisation
(necessary) and a word primes? that tells us whether n is prime.
VOCABULARY primes \ Or however wordlists are generated.
primes definitions
CREATE sieve ... \ data structure
... whatever auxiliary words are needed ...
: era ... ;
FORTH definitions
\ Now we define a couple of words usable from Forth, and
\ couple temporarily to the primes namespace
ALSO primes \ Or however wordlists are used
: init-primes .. era .. ;
: prime? sieve + c@ ;
PREVIOUS

This said, there are in general few data items in Forth, and
only for largish programs is it necessary to resort to
this somewhat cumbersome usage of Forth namespaces.
(Ok it is still nothing like Java.)

1] that is where locals come in.

>Cheers,
>Elizabeth

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[hughag...@gmail.com]

On Saturday, March 14, 2015 at 4:43:44 PM UTC-7, grobibi wrote:
> Hello,
> There is something I don't understand with local variable with gforth.
> A variable defined like this :
>
> variable x 10
>
> will have a general scope. How can I get a local scope for a variable
> inside a word definition ? Is it possible ?

VARIABLE defines a variable (called X in this case), but it doesn't initialize it, so your 10 will just sit on the stack --- the X will be initialized to whatever garbage-value happened to be in memory at the time of compilation.

You can define and initialize a variable like this:

CREATE X 10 ,

As you said though, X is a global variable, which is not what you want.

ANS-Forth provides (LOCAL) and LOCALS| for defining local variables inside of colon words that only have scope during the execution of the colon word.

In SwiftForth-v2 (that I bought for over $400), (LOCAL) would crash the system. This has supposedly been fixed in v3, but I wouldn't know because I refused to pay the $300 required to upgrade from v2 to v3. I recommend against using SwiftForth.

LOCALS| is badly designed because it defines the parameters backwards. The ANS-Forth standard was written without a reference compiler, so ANS-Forth was never tested at the time that it became the standard --- a lot of bad design decisions were standardized --- Elizabeth Rather was the chairperson of the ANS-Forth committee, so she will have to explain why the standard was never tested by anybody --- it should have been made available to the Forth community with a reference compiler for testing, and only after the bugs were worked out should it have been made ANSI (it can't be changed after it has the ANSI stamp).

There is a John Hopkins wrap-around for LOCALS| that defines the locals in the correct order using { as the definer. I have a version of this in my novice package:
http://www.forth.org/novice.html

My novice package uses singly linked lists as its primary data-structure (see LIST.4TH) --- this should be a good starting point for you given your background in Lisp --- I have "touchers" which are a kind of lambda function (see LIST.4TH --- the EACH function is an example of a higher-order function).

My novice package provides multitudes of work-arounds for the bugs in the ANS-Forth standard. Elizabeth Rather says that my novice-package "sucks" and was "written by a novice" --- this is because my work-arounds for the bugs in ANS-Forth tend to shine a spotlight on those bugs.

> Is there a way to bypass this because, for me, a local variable has to
> behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
> will initialize lst to nil (but it can be initialized to anything.).
> Maybe my lisp habitus drives me in a wrong way.

Anton Ertl wrote a wrap-around for LOCALS| for Forth-200x that also fixes the problem with LOCALS| defining the local variables backwards. He changed the name to {: rather than use { that was in the John Hopkins system. He did this because SwiftForth uses { for multi-line comments, and he doesn't want to clash with SwiftForth (Elizabeth Rather will kick him off the Forth-200x committee if he breaks SwiftForth legacy code) --- he would rather pull the rug out from under the entire Forth community who have been using { for 20 years.

Anton Ertl's {: also has a bug in that he doesn't initialize the locals to the right of | to zero (NIL as you said), but he initializes them to whatever happened to be in memory at the time. This is a very bad idea, because if the programmer forgets to explicitly initialize the locals and uses them, they will still have that garbage value. This may work sometimes, if the garbage-value happens to be reasonable, but may not work other times --- the colon word will do something different every time that it executes, depending upon what was in memory previously. Because of this bug, I recommend against using Forth-200x.

Good luck learning Forth!

[Stephen Pelc]

On Sat, 14 Mar 2015 20:45:28 -0700 (PDT), hughag...@gmail.com
wrote:

>On Saturday, March 14, 2015 at 4:43:44 PM UTC-7, grobibi wrote:
>> Hello,
>> There is something I don't understand with local variable with gforth.
>> A variable defined like this :

>>=20
>> variable x 10
>>=20
>> will have a general scope. How can I get a local scope for a variable=20

>> inside a word definition ? Is it possible ?

Grosbibi, if you have not realised it by now, Hugh Aguilar is a
regular author of incorrect (and ugly) diatribes about other people.
His knowledge of Forth history is very poor and usually wrong. He
is regularly corrected, but tends to ignore facts, repeating
untruths again and again. Occasionally, his posts contain
germs of good ideas.

>LOCALS| is badly designed because it defines the parameters backwards.

Many people here agree with you on this one.

>ANS-Forth standard was written without a reference compiler, so ANS-Forth w=

>as never tested at the time that it became the standard

There were lots of test implementations at the time, however they were
not released. Imagine Hugh's grief if Forth 200x had nominated a
specific implementation.

>There is a John Hopkins wrap-around for LOCALS| that defines the locals in =

>the correct order using { as the definer.

The { ... } notation was around in Don Colburn's Forths (AFAIR) long
before ANS.

>Anton Ertl wrote a wrap-around for LOCALS| for Forth-200x that also fixes t=
>he problem with LOCALS| defining the local variables backwards. He changed =
>the name to {: rather than use { that was in the John Hopkins system. He di=
>d this because SwiftForth uses { for multi-line comments, and he doesn't wa=
>nt to clash with SwiftForth

I was at that meeting. Leon Wagner came up with {: ... :} and we
adopted the notation. It has been a long tradition in the ANS and
Forth 200x committees to avoid breaking code.

In my own code, I find the {: ... :} notation to be visually
superior to { ... }.

> (Elizabeth Rather will kick him off the Forth-2=
>00x committee if he breaks SwiftForth legacy code) --- he would rather pull=
> the rug out from under the entire Forth community who have been using { fo=
>r 20 years.

Elizabeth has never been on the Forth 200x committee.

>Anton Ertl's {: also has a bug in that he doesn't initialize the locals to =
>the right of | to zero (NIL as you said), but he initializes them to whatev=
>er happened to be in memory at the time. This is a very bad idea, because i=
>f the programmer forgets to explicitly initialize the locals and uses them,=
> they will still have that garbage value. This may work sometimes, if the g=
>arbage-value happens to be reasonable, but may not work other times --- the=
> colon word will do something different every time that it executes, depend=
>ing upon what was in memory previously. Because of this bug, I recommend ag=
>ainst using Forth-200x.

I do not agree with Hugh's opinion. Bugs should be evident as soon as
possible. Defensive programming may be sensible in an operating
system, but not as part of a programming language and certainly
not part of Forth.

If you want to fix bugs, the mantra should be "Crash early and crash
often".

Stephen


--
Stephen Pelc, steph...@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

[Bernd Paysan]

Stephen Pelc wrote:

>>Anton Ertl's {: also has a bug in that he doesn't initialize the locals to
>>= the right of | to zero (NIL as you said), but he initializes them to
>>whatev= er happened to be in memory at the time. This is a very bad idea,
>>because i= f the programmer forgets to explicitly initialize the locals
>>and uses them,=
>> they will still have that garbage value. This may work sometimes, if the
>> g=
>>arbage-value happens to be reasonable, but may not work other times ---
>>the=
>> colon word will do something different every time that it executes,
>> depend=
>>ing upon what was in memory previously. Because of this bug, I recommend
>>ag= ainst using Forth-200x.
>
> I do not agree with Hugh's opinion. Bugs should be evident as soon as
> possible. Defensive programming may be sensible in an operating
> system, but not as part of a programming language and certainly
> not part of Forth.

The problem with uninitialized locals is that usually, when you test the
function, your locals stack is virgin, and therefore, chances are good that
your uninitialized local is zero.

Therefore, the Gforth implementation of these values is really doing what
Hugh wants, it's initializing the "uninitialized locals" with zero. IMHO
this is allowed ("uninitialized" is not formally explained; IMHO it should,
"uninitialized" means that a standard program may not read from this memory
before it has written to it).

Actually, Anton's locals never had uninitialized locals in mind, and when I
added the new Forth200x stuff, there wasn't anything to build upon to
implement truly uninitialized locals, so I just added code to push a zero
before the >L.

As usual, Hugh's postings consist of 1/3 useful stuff, 1/3 wrong stuff, and
1/3 hate and insults. The useful stuff is: Thou shalt have a deterministic
language, unless thy function is called "random". The wrong stuff is that
the standard does not permit a useful implementation - where "uninitialized"
actually is implemented as "zero-initialized". Or 0xdeadbeef-initialized;
as long as it is deterministic, all values are allowed.

And the insulting stuff is that he claims it's Anton's idea. If Anton would
have had the only say here, there wouldn't be an uninitialized local at all,
and there wouldn't be {: and :}.

For visual cuteness, we agreed that we have now smileys in Forth, and if
your eyesight isn't the best anymore, { a b -- c d } is too close to ( a b
-- c d ), so the {: :} is indeed a "win".

If you use a syntax highlighting editor, the colors of comments and locals
should be different.

[hughag...@gmail.com]

On Sunday, March 15, 2015 at 3:53:43 AM UTC-7, Stephen Pelc wrote:
> On Sat, 14 Mar 2015 20:45:28 -0700 (PDT), hughag...@gmail.com
> wrote:
> >ANS-Forth standard was written without a reference compiler, so ANS-Forth w=
> >as never tested at the time that it became the standard
>
> There were lots of test implementations at the time, however they were
> not released. Imagine Hugh's grief if Forth 200x had nominated a
> specific implementation.

I would be mighty upset if ANS-Forth had nominated a closed-source commercial Forth as their reference compiler --- as I was when I was under the impression that SwiftForth was the reference compiler for ANS-Forth, and before I found out that SwiftForth wasn't released until 1997 (3 years after ANS-Forth).

To not have a reference compiler at all however, is also quite upsetting --- this implies that ANS-Forth was forced on the Forth community without the Forth community having the chance to test it.

What I said (and what you edited out) was: "[the standard] should have been made available to the Forth community with a reference compiler for testing, and only after the bugs were worked out should it have been made ANSI (it can't be changed after it has the ANSI stamp)."

> >There is a John Hopkins wrap-around for LOCALS| that defines the locals in =
> >the correct order using { as the definer.
>
> The { ... } notation was around in Don Colburn's Forths (AFAIR) long
> before ANS.

Then why didn't it go into ANS-Forth? Where did the ridiculous LOCALS| come from?

I have always heard this to be called "John Hopkins format" meaning that it originated at John Hopkins University:
{ stack-initialized-locals... | zero-initialized-locals... }
This goes back at least 20 years --- it may predate ANS-Forth as you say --- it has been an unofficial standard for quite a long time.

> >Anton Ertl wrote a wrap-around for LOCALS| for Forth-200x that also fixes t=
> >he problem with LOCALS| defining the local variables backwards. He changed =
> >the name to {: rather than use { that was in the John Hopkins system. He di=
> >d this because SwiftForth uses { for multi-line comments, and he doesn't wa=
> >nt to clash with SwiftForth
>
> I was at that meeting. Leon Wagner came up with {: ... :} and we
> adopted the notation. It has been a long tradition in the ANS and
> Forth 200x committees to avoid breaking code.

You should be more honest and say: "It has been a long tradition in the ANS and Forth 200x committees to avoid breaking Forth Inc. code."

The reason why Leon Wagner required you to use {: ... :} is because SwiftForth was already using { ... } for multi-line comments. But who the hell cares??? I wrote COMMENT in the novice-package to provide multi-line comments, and this has the advantage of using a user-specified delimiter rather than use the same delimiter every time --- this took me maybe 10 minutes to implement --- this is trivial.

But you broke 20 years worth of legacy code that used { for defining locals (the John Hopkins format mentioned above) --- you didn't care though, because these were just ordinary Forth programmers such as myself --- you only care about Forth Inc. legacy code (God forbid that their multi-line comment should stop working, and they have to spend 10 minutes fixing the problem).

> > (Elizabeth Rather will kick [Anton Ertl] off the Forth-2=

> >00x committee if he breaks SwiftForth legacy code) --- he would rather pull=
> > the rug out from under the entire Forth community who have been using { fo=
> >r 20 years.
>
> Elizabeth has never been on the Forth 200x committee.

Leon Wagner is Elizabeth Rather's trained monkey --- he speaks on command, saying what she commands him to say, and he believes what she tells him to believe --- this is why she signs his paycheck.

Yourself, Anton Ertl, and everybody on the Forth-200x committee, are like sheep --- everybody in favor of doing what your shepherd Leon Wagner commands, say: "baaaaa!"

> >Anton Ertl's {: also has a bug in that he doesn't initialize the locals to =
> >the right of | to zero (NIL as you said), but he initializes them to whatev=
> >er happened to be in memory at the time. This is a very bad idea, because i=
> >f the programmer forgets to explicitly initialize the locals and uses them,=
> > they will still have that garbage value. This may work sometimes, if the g=
> >arbage-value happens to be reasonable, but may not work other times --- the=
> > colon word will do something different every time that it executes, depend=
> >ing upon what was in memory previously. Because of this bug, I recommend ag=
> >ainst using Forth-200x.
>
> I do not agree with Hugh's opinion. Bugs should be evident as soon as
> possible. Defensive programming may be sensible in an operating
> system, but not as part of a programming language and certainly
> not part of Forth.
>
> If you want to fix bugs, the mantra should be "Crash early and crash
> often".

And this is why you want to initialize variables to the garbage-value that happened to be in memory already???

You are not making any sense whatsoever.

This is why I say that ANS-Forth is a cult --- you try so hard to support Forth Inc., and you completely distort reality with these weird nonsensical arguments --- reread what you just wrote, and ask yourself:
"Is this so ridiculous that most readers are going to burst out laughing? Was I trying too hard to explain away an obvious mistake? Should I have just admitted that it was a bad design decision?"

[hughag...@gmail.com]

On Sunday, March 15, 2015 at 7:45:56 PM UTC-7, hughag...@gmail.com wrote:
> To not have a reference compiler at all however, is also quite upsetting --- this implies that ANS-Forth was forced on the Forth community without the Forth community having the chance to test it.
>
> What I said (and what you edited out) was: "[the standard] should have been made available to the Forth community with a reference compiler for testing, and only after the bugs were worked out should it have been made ANSI (it can't be changed after it has the ANSI stamp)."

The ANS-Forth committee should have written an open-source public-domain reference compiler for the standard. It wouldn't have to generate optimized code, as it is just for testing. The Forth community could have written programs for this compiler and discovered any bugs in the design of the language --- after everybody is happy that the language standard makes sense, THEN the language standard can be submitted to ANSI and written in stone.

This wasn't done for a couple of reasons:
1.) Forth Inc. employees are all sales people, not programmers, and nobody at Forth Inc. was capable of writing a compiler --- they are only capable of maintaining compilers originally written by Charles Moore in the 1970s --- they aren't capable of original programming.
2.) Elizabeth Rather wanted to force the standard through ANSI without anybody looking at it and noticing that it had myriad technical problems --- after it gets the ANSI stamp it can't be modified, and so she has imposed her will on the entire Forth community, and our complaints will do us no good as nothing can be changed.

ANS-Forth was just a marketing scheme to make Forth Inc. appear to be more important than they are --- Elizabeth Rather's goal with ANS-Forth was to make the world believe that Forth Inc. sets the standard for Forth and that ordinary Forthers (such as myself) are entirely dependent upon Forth Inc. for leadership.

The truth is that ordinary Forth programmers are succeeding at Forth projects (the MiniForth at Testra, that I wrote MFX for), but Forth Inc. is unable to succeed at anything (this is why Elizabeth Rather is still bragging up the Saudi airport project decades later, and not mentioning that it was Charles Moore who did that project on a PDP-11 prior to getting kicked out of Forth Inc.).

> I have always heard this to be called "John Hopkins format" meaning that it originated at John Hopkins University:
> { stack-initialized-locals... | zero-initialized-locals... }
> This goes back at least 20 years --- it may predate ANS-Forth as you say --- it has been an unofficial standard for quite a long time.

This was a typo --- I meant:
{ stack-initialized-locals... | zero-initialized-locals... -- comments... }

This is in the novice package, and there are abundant examples.

[grobibi]

I don't know what is the most interesting topic raised after my first
post. But it's very constructive seeing such divergences around the
conception of the forth language. I think studying this is sometime
rewarding experience that helps learning a lot of things. I remember the
pleasure I get reading The Evolution of Lisp (Gabriel & Steele). It's
similar here. I will study your proposition and come back later.
Thanks and have a nice week.

[Stephen Pelc]

On Sun, 15 Mar 2015 19:45:54 -0700 (PDT), hughag...@gmail.com
wrote:

>You should be more honest and say: "It has been a long tradition in the ANS=

> and Forth 200x committees to avoid breaking Forth Inc. code."
>

>The reason why Leon Wagner required you to use {: ... :} is because SwiftFo=
>rth was already using { ... } for multi-line comments. But who the hell car=
>es???

Your ability to miss the point is amazing. Under Forth2012, the
previous usages of { ... } are now undefined. SwiftForth and VFX
Forth can both behave as before. However, the usage of {: ... :}
is now standardised.

[Anton Ertl]

grobibi <tristanh...@free.fr> writes:
>Is there a way to bypass this because, for me, a local variable has to
>behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
>will initialize lst to nil (but it can be initialized to anything.).

In Gforth:

: foo { x -- ? }
0 { lst } ... ;

- 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 2014: http://www.euroforth.org/ef14/

[hughag...@gmail.com]

On Monday, March 16, 2015 at 12:51:38 AM UTC-7, Stephen Pelc wrote:
> On Sun, 15 Mar 2015 19:45:54 -0700 (PDT), hughag...@gmail.com
> wrote:
>
> >You should be more honest and say: "It has been a long tradition in the ANS=
> > and Forth 200x committees to avoid breaking Forth Inc. code."
> >
> >The reason why Leon Wagner required you to use {: ... :} is because SwiftFo=
> >rth was already using { ... } for multi-line comments. But who the hell car=
> >es???
>
> Your ability to miss the point is amazing. Under Forth2012, the
> previous usages of { ... } are now undefined. SwiftForth and VFX
> Forth can both behave as before. However, the usage of {: ... :}
> is now standardised.

Lets clarify the design decision of the Forth-200x committee:
1.) Everybody in the Forth community who has been using { ... } for local variable declarations (the John Hopkins format) for 20+ years will have to convert all of their legacy code over to use this new and ugly {: ... :} syntax instead --- that is quite a lot of work! --- we are likely to get carpal-tunnel syndrome in the right pinky finger. :-(
2.) SwiftForth will continue to use { ... } for multi-line comments. They won't convert their legacy code over to use my COMMENT instead, although doing so would be trivial --- because programming time costs money at Forth Inc. --- aloha!

Am I missing the point? I think I've pretty much nailed it down.

Also, you are dodging my point about {: having a bug --- it fails to zero out the local variables declared to the right of the | and it actually initializes them to whatever garbage-value happened to be in memory at the time. I read your manual (section 8.1) and you say nothing about what the local variables to the right of the | are initialized to, so I tested VFX and found that you have the bug too: they are initialized to whatever was in memory already, so if the programmer forgets to explicitly initialize them (a common bug), the function will do something different every time that it is executed (makes debugging difficult!). Also, on a related note, Forth-200x should define ALLOT so that it zeros out the memory that it allots, so VARIABLE etc. will be initialized to a known state rather than whatever garbage-value happened to be in memory at the time (different every time the program is compiled).

I read your manual (section 8.1) and found this:
For compatibility with previous implementations, { is accepted in place of {: and } in place of :}. The change to {: ... :} took place as a result of the Forth200x standard.

This just illustrates my point --- you yourself were one of the legion of Forth programmers who were using { for local variable definitions, but Leon Wagner told you to switch to {: because he was using { for multi-line comments, and you said: "Yes Master! Your every whim is my command! Would you also like me to shine your shoes while I'm on my knees?" If you were to contradict him, he would kick you off the committee --- the result is that now VFX code is a mish-mash of sometimes using { and sometimes using {: and the poor MPE customer is baffled as to why there are two words that appear to be doing the same thing and he wonders if there is some subtle difference that he is unaware of.

Really! Grow a spine and tell Leon Wagner that you aren't going to do what he commands until Forth Inc. starts signing your paycheck --- then walk away from Forth-200x like I did --- unless Forth Inc. is signing your paycheck (I was on the Forth-200x mailing list, and you never mentioned this, but maybe it is just something that you don't like to talk about in public).

[hughag...@gmail.com]

On Monday, March 16, 2015 at 8:37:48 AM UTC-7, Anton Ertl wrote:
> grobibi <tristanh...@free.fr> writes:
> >Is there a way to bypass this because, for me, a local variable has to
> >behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
> >will initialize lst to nil (but it can be initialized to anything.).
>
> In Gforth:
>
> : foo { x -- ? }
> 0 { lst } ... ;

Your code fails under VFX:

: foo { x -- ? } 0 { 1st } x . 1st . ;
Err# -421 Multiple local definitions in one word
-> : foo { x -- ? } 0 { 1st } x . 1st . ;

It should fail, because this is a violation of ANS-Forth. See the infamous section 13.3.3:

Immediate words in a program may use (LOCAL) to implement syntaxes for local declarations with the following restrictions:
- A program shall not compile any executable code into the current definition between the time (LOCAL) is executed to identify the first local for that definition and the time of sending the single required "last local" message;

[Alex McDonald]

It doesn't fail because of that section; you're misreading, and Anton
specifically said "In Gforth". It fails on

13.6.2.2550 ...
The following ambiguous conditions exist when:
..
– {: . . . :} is used more than once in a word.

This works in both Gforth and VFX.

: foo ( x -- ? ) 0 { x lst } ... ;

Replace { } with {: :} for modern notation.

[Alex McDonald]

on 16/03/2015 16:59:22, wrote:
> On Monday, March 16, 2015 at 12:51:38 AM UTC-7, Stephen Pelc wrote:
>> On Sun, 15 Mar 2015 19:45:54 -0700 (PDT), hughag...@gmail.com
>> wrote:
>>
>> >You should be more honest and say: "It has been a long tradition in the

> ANS> > and Forth 200x committees to avoid breaking Forth Inc. code."

>> >
>> >The reason why Leon Wagner required you to use {: ... :} is because Swif

> tFo> >rth was already using { ... } for multi-line comments. But who
> the hell car> >es???

>>
>> Your ability to miss the point is amazing. Under Forth2012, the
>> previous usages of { ... } are now undefined. SwiftForth and VFX
>> Forth can both behave as before. However, the usage of {: ... :}
>> is now standardised.
>
> Lets clarify the design decision of the Forth-200x committee:
> 1.) Everybody in the Forth community who has been using { ... } for

> local v ariable declarations (the John Hopkins format) for 20+ years
> will have to c onvert all of their legacy code over to use this new
> and ugly {: ... :} syn tax instead --- that is quite a lot of work!
> --- we are likely to get carpa l-tunnel syndrome in the right pinky
> finger. :-

No. Nothing changes since {: :} is an addition.

> ( 2.) SwiftForth will continue to use { ... } for multi-line

> comments. They w on't convert their legacy code over to use my COMMENT
> instead, although doi ng so would be trivial --- because programming

> time costs money at Forth In c. --- aloha!

Correct. Why on earth would they want to use your COMMENT? See your point
(1).

>
> Am I missing the point? I think I've pretty much nailed it down.

As in missed the nail and hit your thumb.

>
> Also, you are dodging my point about {: having a bug --- it fails to

> zero o ut the local variables declared to the right of the | and it
> actually initi alizes them to whatever garbage-value happened to be in

> memory at the time. I read your manual (section 8.1) and you say
> nothing about what the local variables to the right of the | are

> initialized to, so I tested VFX and fou nd that you have the bug too:
> they are initialized to whatever was in memor y already, so if the
> programmer forgets to explicitly initialize them (a co mmon bug), the

> function will do something different every time that it is e xecuted
> (makes debugging difficult!). Also, on a related note, Forth-200x s
> hould define ALLOT so that it zeros out the memory that it allots, so

> VARIA BLE etc. will be initialized to a known state rather than
> whatever garbage- value happened to be in memory at the time

> (different every time the progra m is compiled).

Both requirements are inefficent.

>
> I read your manual (section 8.1) and found this:
> For compatibility with previous implementations, { is accepted in
> place of {: and } in place of :}. The change to {: ... :} took place
> as a result of the Forth200x standard.
>
> This just illustrates my point --- you yourself were one of the legion

> of F orth programmers who were using { for local variable definitions,

> but Leon Wagner told you to switch to {: because he was using { for

> multi-line comme nts, and you said: "Yes Master! Your every whim is my
> command! Would you al so like me to shine your shoes while I'm on my
> knees?" If you were to contr adict him, he would kick you off the
> committee --- the result is that now V FX code is a mish-mash of

> sometimes using { and sometimes using {: and the poor MPE customer is

> baffled as to why there are two words that appear to b e doing the

> same thing and he wonders if there is some subtle difference th at he
> is unaware of.

See point (1). This contradicts what you say there, but hey, what's new?

>
> Really! Grow a spine and tell Leon Wagner that you aren't going to do
> what he commands until Forth Inc. starts signing your paycheck ---

> then walk awa y from Forth-200x like I did --- unless Forth Inc. is

> signing your paycheck (I was on the Forth-200x mailing list, and you

> never mentioned this, but m aybe it is just something that you don't

> like to talk about in public).
>

You walked? I thought you were forcibly ejected, since you didn't meet
the minimum requirements for membership in terms of civility.

[Rod Pemberton]

Well, I'm definately not up to date on locals, but I think
you posted something very different from what Anton posted.

You unconsciously fixed Anton's typing mistake, but Hugh didn't.
You changed the first set of curly braces to parenthesis, but
Hugh accepted them as-is, as what Anton meant. So, Anton posted
two sets of locals. It seems clear the first set is a typing
mistake and should actually be a set of parameters using
parenthesis. I.e., just how do you use two dashes and a
quotation mark as locals? ... Well, Hugh showed how, and
showed that it doesn't work.

So, it seems that it was you who misread, yet again ...

Of course, we'll probably never get a correction from
Anton, as is normal when he makes a mistake.


Rod Pemberton

--
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.

[HAA]

Stephen Pelc wrote:
> [...]

> His knowledge of Forth history is very poor and usually wrong.

He may not be the only one ...

> The { ... } notation was around in Don Colburn's Forths (AFAIR) long
> before ANS.

ANS:

"The syntax defined by this Standard and used in the systems of Creative Solutions, Inc.:

: LOCALS| ( "name...name |" -- )

"

> >LOCALS| is badly designed because it defines the parameters backwards.
>
> Many people here agree with you on this one.

But not Don apparently. LOCALS| peels values off the stack in the same order
as would a several 'local' VALUEs.

Forth employs a LIFO stack. Pretending it doesn't, isn't doing Forth's reputation
any favors.

> However, the usage of {: ... :}
> is now standardised.

The proof a Standard is whether anyone is using it. Do you use {: ... :} ?

[Stephen Pelc]

On Tue, 17 Mar 2015 13:47:59 +1100, "HAA" <som...@microsoft.com>
wrote:

>> The { ... } notation was around in Don Colburn's Forths (AFAIR) long
>> before ANS.
>
>ANS:
>
>"The syntax defined by this Standard and used in the systems of Creative Solutions, Inc.:
>
> : LOCALS| ( "name...name |" -- )
>"

The brace notation was complete and had usage history long before the
ANS locals process started. We added LOCALS| just for ANS compliance.

>The proof a Standard is whether anyone is using it. Do you use {: ... :} ?

Yes, we have implemented and used the brace notation since at least
since 1994. I say 1994 because that's when our current change note
system was adopted. Since the meeting at which Forth 200x adoped
{: ... :} I have used it.

As a side note, I once scanned the gforth sources and examples to
compare usage of the brace notation and LOCAL|. The brace notation
was used three times as often.

[Alex McDonald]

It's so different that it's identical.

>
> You unconsciously fixed Anton's typing mistake, but Hugh didn't.

Anton was quite clear that his code was for Gforth. Gforth supports
multiple declarations of locals, so I wasn't as unconscious as you
assume.

> You changed the first set of curly braces to parenthesis, but
> Hugh accepted them as-is, as what Anton meant. So, Anton posted
> two sets of locals. It seems clear the first set is a typing
> mistake and should actually be a set of parameters using
> parenthesis. I.e., just how do you use two dashes and a
> quotation mark as locals? ... Well, Hugh showed how, and
> showed that it doesn't work.
>

In Gforth (again!) the locals list can be represented in a
stack-diagram-like way. The double dash -- starts a comment inside the
locals declaration; anything between it and the closing brace } is
ignored.

http://www.public.iastate.edu/~forth/gforth_31.html

There are other Forths that support this format; Win32Forth for example.

> So, it seems that it was you who misread, yet again ...
>
> Of course, we'll probably never get a correction from
> Anton, as is normal when he makes a mistake.
>
>

Perhaps he has you both killfiled.

> Rod Pemberton
>

[Doug Hoffman]

On 3/16/15 7:00 PM, Rod Pemberton wrote:

> ... I.e., just how do you use two dashes and a quotation mark as
> locals? ...

This facet of the syntax is correct in Gforth's { ... } as Alex points
out and also correct use of the Forth 200x {: ... :} locals:

ref: http://www.forth200x.org/locals.html

Selected explanatory snippets from the URL:

"The items between -- and :} are outputs for formal comments only.

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

In the example below, a and b are local arguments, and c and d are local
values.

: foo {: a b | c d -- :}
a b + to c
a b * to d
cr c . d .
;

13.4.1.2 Ambiguous condition
{: ... :} is used more than once in a word."


Not exactly the same as Gforth's { ... } because use of multiple {: ...
:} declarations in the same definition is an ambiguous condition but in
Gforth multiple { ... } declarations are valid.

-Doug

[Anton Ertl]

"Rod Pemberton" <bu...@notnotnontnooatno.cmm> writes:
>On Mon, 16 Mar 2015 16:24:46 -0400, Alex McDonald <bl...@rivadpm.com> wro=

>te:
>> on 16/03/2015 17:09:36, wrote:
>>> On Monday, March 16, 2015 at 8:37:48 AM UTC-7, Anton Ertl wrote:
>
>>>> In Gforth:
>>>>
>>>> : foo { x -- ? }
>>>> 0 { lst } ... ;

...

>You unconsciously fixed Anton's typing mistake, but Hugh didn't.
>You changed the first set of curly braces to parenthesis, but
>Hugh accepted them as-is, as what Anton meant. So, Anton posted
>two sets of locals. It seems clear the first set is a typing
>mistake and should actually be a set of parameters using
>parenthesis.

There is no typo in the code I posted.

> I.e., just how do you use two dashes and a
>quotation mark as locals?

"--" starts a comment.

[Anton Ertl]

"HAA" <som...@microsoft.com> writes:
>The proof a Standard is whether anyone is using it. Do you use {: ... :} ?

I have used it more often than LOCALS|. However, most of the time I
still use { ... } for now, because {: ... :} is still recently
introduced, and more of the systems I use have { ... } than {: ... :}.
In the next few years that should change, as systems should pick up {:
... :}, including some that don't have { ... }.

[Stephen Pelc]

On Tue, 17 Mar 2015 12:06:34 GMT, "Alex McDonald" <bl...@rivadpm.com>
wrote:

>In Gforth (again!) the locals list can be represented in a
>stack-diagram-like way. The double dash -- starts a comment inside the
>locals declaration; anything between it and the closing brace } is
>ignored.

{: in1 in2 | loc1 ... locn -- o1 o2 :}

The stack diagram layout is deliberate and sometimes important. It
allows the programmer to define a full stack comment. Although what
is between '--' and ':}' is technically a comment, it is mostly a
formal notation for the output data. Not using the notation this way
is bad practice IMHO.

[Albert van der Horst]

In article <2015Mar1...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>"HAA" <som...@microsoft.com> writes:
>>The proof a Standard is whether anyone is using it. Do you use {: ... :} ?
>
>I have used it more often than LOCALS|. However, most of the time I
>still use { ... } for now, because {: ... :} is still recently
>introduced, and more of the systems I use have { ... } than {: ... :}.
>In the next few years that should change, as systems should pick up {:
>... :}, including some that don't have { ... }.

How complicated is the {: :} mechanism?

Would a prelude like
: { POSTPONE {: ; IMMEDIATE
: } POSTPONE :} ; IMMEDIATE
work, to have old programs compile under a 200x standard Forth?

>- anton

[Alex McDonald]

on 17/03/2015 16:24:31, wrote:
> In article <2015Mar1...@mips.complang.tuwien.ac.at>,
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>"HAA" <som...@microsoft.com> writes:
>>>The proof a Standard is whether anyone is using it. Do you use {: ... :} ?
>>
>>I have used it more often than LOCALS|. However, most of the time I
>>still use { ... } for now, because {: ... :} is still recently
>>introduced, and more of the systems I use have { ... } than {: ... :}.
>>In the next few years that should change, as systems should pick up {:
>>... :}, including some that don't have { ... }.
>
> How complicated is the {: :} mechanism?

In Win32Forth and my forth, they're the same.

>
> Would a prelude like
> : { POSTPONE {: ; IMMEDIATE
> : } POSTPONE :} ; IMMEDIATE
> work, to have old programs compile under a 200x standard Forth?

There probably isn't a :} word to postpone. { {: and LOCALS| are normally
handled by parsing, so {: } would work, but {: :} would not parse
correctly.

>
>>- anton
>
> Groetjes Albert

[Anton Ertl]

hughag...@gmail.com writes:
>On Monday, March 16, 2015 at 8:37:48 AM UTC-7, Anton Ertl wrote:
>> grobibi <tristanh...@free.fr> writes:
>> >Is there a way to bypass this because, for me, a local variable has to
>> >behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
>> >will initialize lst to nil (but it can be initialized to anything.).
>>
>> In Gforth:
>>
>> : foo { x -- ? }
>> 0 { lst } ... ;
>
>Your code fails under VFX:
>
>: foo { x -- ? } 0 { 1st } x . 1st . ;
>Err# -421 Multiple local definitions in one word
> -> : foo { x -- ? } 0 { 1st } x . 1st . ;
>
>It should fail, because this is a violation of ANS-Forth.

Not every non-standard program should fail. If every system was
allowed to only support standard programs, there would be no way to
establish new common practice.

In this particular case, I think that all systems should support
multiple locals definitions in one word.

[Alex McDonald]

on 17/03/2015 16:54:28, wrote:
> hughag...@gmail.com writes:
>>On Monday, March 16, 2015 at 8:37:48 AM UTC-7, Anton Ertl wrote:
>>> grobibi <tristanh...@free.fr> writes:
>>> >Is there a way to bypass this because, for me, a local variable has to
>>> >behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
>>> >will initialize lst to nil (but it can be initialized to anything.).
>>>
>>> In Gforth:
>>>
>>> : foo { x -- ? }
>>> 0 { lst } ... ;
>>
>>Your code fails under VFX:
>>
>>: foo { x -- ? } 0 { 1st } x . 1st . ;
>>Err# -421 Multiple local definitions in one word
>> -> : foo { x -- ? } 0 { 1st } x . 1st . ;
>>
>>It should fail, because this is a violation of ANS-Forth.
>
> Not every non-standard program should fail. If every system was
> allowed to only support standard programs, there would be no way to
> establish new common practice.
>
> In this particular case, I think that all systems should support
> multiple locals definitions in one word.
>
> - anton

Presumably outside of control structures and quotations.

[Bernd Paysan]

Stephen Pelc wrote:
> As a side note, I once scanned the gforth sources and examples to
> compare usage of the brace notation and LOCAL|. The brace notation
> was used three times as often.

The only place where we use LOCALS| in Gforth is in the testing code.

[Bernd Paysan]

Alex McDonald wrote:
>> Of course, we'll probably never get a correction from
>> Anton, as is normal when he makes a mistake.
>
> Perhaps he has you both killfiled.

I don't know about Anton, but I certainly have both idiots killfiled. Life
is too short to correct all their mistakes ;-).

[Stephen Pelc]

On Tue, 17 Mar 2015 18:55:38 +0100, Bernd Paysan <bernd....@gmx.de>

wrote:

>> As a side note, I once scanned the gforth sources and examples to
>> compare usage of the brace notation and LOCAL|. The brace notation
>> was used three times as often.
>
>The only place where we use LOCALS| in Gforth is in the testing code.

Sorry, I should probably have said Win32Forth.

[Bernd Paysan]

Anton Ertl wrote:

> "HAA" <som...@microsoft.com> writes:
>>The proof a Standard is whether anyone is using it. Do you use {: ... :}
>>?
>
> I have used it more often than LOCALS|. However, most of the time I
> still use { ... } for now, because {: ... :} is still recently
> introduced, and more of the systems I use have { ... } than {: ... :}.
> In the next few years that should change, as systems should pick up {:
> ... :}, including some that don't have { ... }.

I'm not sure why I should change to {: :}. The systems I'm using all
support { }, and quite likely won't change that. IMHO this was not the best
decision to change a word that is already in pretty common practice.

I think it's fair and a good idea to define *new* features with names that
don't conflict with existing systems, but { } is not a new feature. It is
older than ANS Forth.

[Bernd Paysan]

Alex McDonald wrote:
> Presumably outside of control structures and quotations.

The rule in Gforth is: You can use the locals if there is a guaranteed path
through control flow to be visible. E.g.

: foo { a } .. if { b } .. else { c } .. then .. ;

means that a is visible through the entire word, but b ends its life at
ELSE, and c ends its life at THEN.

: foo { a } .. begin { b } .. while { c } .. repeat .. ;

means that a is available after it is defined, b as well, and c is only
available between WHILE and REPEAT.

The compiler can't know whether a quotation outlives the function around it,
so the quotation can't use locals outside itself.

[WJ]

Bernd Paysan wrote:

> grobibi wrote:
>
> > Hello,
> > There is something I don't understand with local variable with gforth.
> > A variable defined like this :
> >
> > variable x 10
> >
> > will have a general scope. How can I get a local scope for a variable
> > inside a word definition ? Is it possible ?

> >
> > Is there a way to bypass this because, for me, a local variable has to
> > behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
> > will initialize lst to nil (but it can be initialized to anything.).

> > Maybe my lisp habitus drives me in a wrong way.
>
> Just use local variables:
>
> https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Gforth-locals.html
>
> Gforth has both variable- and value flavored locals; the standard only has
> value-flavored locals. Usually, value-flavored is fine, unless you need the
> address of the variable dearly.
>
> Example:
>
> : foo 10 { x } x x * to x x x * . ;
>
> should print 10000 - first square it, reassign to x, and then square it
> again and print it.

Oforth:

func: foo{|x| 10 ->x x x * ->x x x * println }

[HAA]

Stephen Pelc wrote:
> [...]

> The brace notation was complete and had usage history long before the
> ANS locals process started. We added LOCALS| just for ANS compliance.

The fact remains ANS TC voted for Colburn's LOCALS| over the braces
notation. They must have had their reasons.

> >The proof a Standard is whether anyone is using it. Do you use {: ... :} ?
>

> [...]

> Since the meeting at which Forth 200x adoped
> {: ... :} I have used it.

You must be the exception.

It's my observation {: ... :} is just as unpopular with brace users as was
LOCALS| . It suggests locals in Forth is as fractured as ever with
appearance over-ruling substance. ANS was ambivalent about introducing
locals. Their worst fears appear to have come true.

[Elizabeth D. Rather]

On 3/17/15 4:25 PM, HAA wrote:
> Stephen Pelc wrote:
>> [...]
>> The brace notation was complete and had usage history long before the
>> ANS locals process started. We added LOCALS| just for ANS compliance.
>
> The fact remains ANS TC voted for Colburn's LOCALS| over the braces
> notation. They must have had their reasons.

It was the most hotly and extensively debated issue of the entire
process. The TC was almost evenly divided on the issue. The argument in
favor of LOCALS| and its argument order was that it had been implemented
in MacForth for years and there were literally thousands of copies in
use, and much code dependent on it. At that time, no one on the
committee had more than experimental code using the other order.
Ultimately, the TC was unwilling to invalidate that much existing code.

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

[Bernd Paysan]

Elizabeth D. Rather wrote:

> On 3/17/15 4:25 PM, HAA wrote:
>> Stephen Pelc wrote:
>>> [...]
>>> The brace notation was complete and had usage history long before the
>>> ANS locals process started. We added LOCALS| just for ANS compliance.
>>
>> The fact remains ANS TC voted for Colburn's LOCALS| over the braces
>> notation. They must have had their reasons.
>
> It was the most hotly and extensively debated issue of the entire
> process. The TC was almost evenly divided on the issue. The argument in
> favor of LOCALS| and its argument order was that it had been implemented
> in MacForth for years and there were literally thousands of copies in
> use, and much code dependent on it. At that time, no one on the
> committee had more than experimental code using the other order.
> Ultimately, the TC was unwilling to invalidate that much existing code.

Like any non-standard code, that code isn't "invalidated" by a TC decision
for a different proposal. It is just the same non-standard stuff as it was
before. In so far one could say that the current {: :} standard
"invalidates" all the programs which actually use the { } braces notation
without colon, and doing that would be no way. The {: :} notation is a
compromise between all those people who used the braces notaion and Forth
Inc., which ignored the braces notation, and instead used braces for multi-
line comments. I don't think it will really catch on: The people who used
the braces notation on Forths who had it before, will continue to use it,
and the systems will continue to offer that.

I've implemented locals in bigForth in 1992, using the braces notation. In
1993, I added ANS locals; I did never use them. I haven't heard of the
locals| notation before ANS; however, I did hear of the braces notation,
must have been right here in comp.lang.forth.

The Forth200x committee wouldn't have accepted a proposal with only a slight
majority. That is way too far off consensus to be acceptable. Usually,
with two nays, we feel it's no longer acceptable. This is a conservative
strategy, and nobody forces us to be fast.

[Elizabeth D. Rather]

That was also the rule for the ANS Forth TC, but after 6 years during
which we failed to obtain a consensus on this issue while all other
outstanding issues had been resolved, we reluctantly accepted it.

[WJ]

grobibi wrote:

> Hello,
> There is something I don't understand with local variable with gforth.
> A variable defined like this :
>
> variable x 10
>
> will have a general scope. How can I get a
> local scope for a variable inside a word definition ? Is it possible ?
>

Oforth:

x is the local variable.

func: pair-with-squares(list)
{|x| list map( #[ -> x [x, x x *]])}


> [2,3,4] pair-with-squares println
[[2, 4], [3, 9], [4, 16]]
ok
> pair-with-squares([5,6,7,8]) println
[[5, 25], [6, 36], [7, 49], [8, 64]]
ok

[WJ]

HAA wrote:

> Stephen Pelc wrote:
> > [...]
> > The brace notation was complete and had usage history long before the
> > ANS locals process started. We added LOCALS| just for ANS compliance.
>
> The fact remains ANS TC voted for Colburn's LOCALS| over the braces
> notation. They must have had their reasons.

Even if they had their reasons, that does not mean that they
had good reasons.

Their reasons might have been atrocious.

[WJ]

hughag...@gmail.com wrote:

> I read your manual (section 8.1) and found this:
>
> For compatibility with previous implementations, { is
> accepted in place of {: and } in place of :}. The change to
> {: ... :} took place as a result of the Forth200x standard.
>
> This just illustrates my point --- you yourself were one of

> the legion of Forth programmers who were using { for local

> variable definitions, but Leon Wagner told you to switch to

> {: because he was using { for multi-line comments, and you

> said: "Yes Master! Your every whim is my command! Would you

> also like me to shine your shoes while I'm on my knees?" If
> you were to contradict him, he would kick you off the
> committee --- the result is that now VFX code is a mish-mash

> of sometimes using { and sometimes using {: and the poor MPE
> customer is baffled as to why there are two words that

> appear to be doing the same thing and he wonders if there is

> some subtle difference that he is unaware of.

Good points.

It seems that the bone-headed bullies of Forth, Inc. are the
worst enemies of Forth; they want to keep it crippled.

[Stefan Mauerhofer]

Regarding locals I will ignore the standard as much as I can.
The committee screwed it up with LOCALS| in the first place.
The new standard makes it even worse. The best solution IMHO would be
to ignore both standards regarding locals and continue using {..}

[Doug Hoffman]

If there were no standards I wouldn't be using Forth. The good people
who donate(d) so much of their time and effort towards the ANS and 200x
standards deserve our thanks and support, even if one might not agree
with every last detail. It's truly a thankless job.

-Doug

[Anton Ertl]

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>How complicated is the {: :} mechanism?
>
>Would a prelude like
> : { POSTPONE {: ; IMMEDIATE
> : } POSTPONE :} ; IMMEDIATE
>work, to have old programs compile under a 200x standard Forth?

}/:} may not be words, or they may be words in a special wordlist, so
no, this is unlikely to work.

You find an implementations in terms of (LOCAL) in

http://www.forth200x.org/reference-implementations/locals.fs

Looking at the code, it's not very complicated.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Anton Ertl wrote:
>
>> "HAA" <som...@microsoft.com> writes:
>>>The proof a Standard is whether anyone is using it. Do you use {: ... :}
>>>?
>>
>> I have used it more often than LOCALS|. However, most of the time I
>> still use { ... } for now, because {: ... :} is still recently
>> introduced, and more of the systems I use have { ... } than {: ... :}.
>> In the next few years that should change, as systems should pick up {:
>> ... :}, including some that don't have { ... }.
>
>I'm not sure why I should change to {: :}. The systems I'm using all
>support { }, and quite likely won't change that.

In that case, no need to change. I use SwiftForth for portability
testing, and it does not support { for locals, so I will be using {:
in the long run.

>I think it's fair and a good idea to define *new* features with names that
>don't conflict with existing systems, but { } is not a new feature. It is
>older than ANS Forth.

It's also a good idea for old stuff if there are naming conflicts.
E.g., there is a PARSE-WORD described (but not standardized) in
Forth-94, so that usage is obviously at least as old, but another word
with that name is also in wide use. So we decided to standardize the
word with the name PARSE-NAME, for which no conflicts are known.

Or take the classic example of NOT, 0=, and INVERT. This example also
shows that the old, divergent usage may never die out, so we may never
be able to ever standardize a word called NOT.

[Alex McDonald]

Ignoring programmers who ignore standards is the right of compiler
writers and hiring projects the world over.

[HAA]

Bernd Paysan wrote:
> ...

> The Forth200x committee wouldn't have accepted a proposal with only a slight
> majority. That is way too far off consensus to be acceptable. Usually,
> with two nays, we feel it's no longer acceptable. This is a conservative
> strategy, and nobody forces us to be fast.

Effectively reversing a decision made in a previous Standard for no other reason
than some didn't like the order of the arguments is a strategy that speaks of
self-interest above Forth's.

[Bernd Paysan]

HAA wrote:
> Effectively reversing a decision made in a previous Standard for no other
> reason than some didn't like the order of the arguments is a strategy that
> speaks of self-interest above Forth's.

We didn't throw out LOCALS|. We just added the way more popluar {, though
with a small change in the name.

A standard is about writing down what common practice is. Forth users are
usually pretty independent thinkers; if Forth would be the fad of the year,
we probably would have way more lemmings following whatever the standard
tells them. We don't. Therefore, the standard team isn't that much in a
position to force things down people's throat.

People simply didn't accept LOCALS|, and used the non-standard { notation
instead.

[Alex McDonald]

As someone who works on quite a lot of standards committees, I'm
fascinated by the casual observer's characterisation of how things work,
and the judgements that get made.

This is an interesting observation; someone (perhaps more than one) had a
strategy that put their self- interest above the interests of Forth.

Hmmm.

What is the interest of Forth? Does Forth have any interests, or even a
corpreal manifestation? When people say things like this, are they
meaning that others interests weren't aligned to their self- interests?
Or is this an attempt to protect the interests & position of the previous
standards committee?

Perhaps it's because it's difficult to say "I don't agree, and here's
why", and far easier to say "Blasphemy! You've placed yourself above
God's word!" and burn people for it.

[Anton Ertl]

>Presumably outside of control structures and quotations.

Also inside control structures and quotations (Gforth supports both).

Concerning quotations, the problem is not whether you can define them
inside (ok, there is a bit of implementation effort required to
support that), but whether locals defined outside are visible inside,
and you already have that with a single local definition at the
outermost level in combination with quotations. For now the locals
from outside are not visible inside in Gforth; making them visible
there in general requires garbage collection of the activation
records. There have been discussions on ways to support something
like this in a more limited way, but these ideas are still at the
conceptual stage.

Concerning control structures, as Bernd Paysan explained, Gforth uses
(an approximation of) control flow dominance for the visibility of
locals, i.e., a local is visible at all places that can *only* be
reached through the definition of the local [ertl94l].

A simpler approach would be to make the local visible from the
definition of the local to the end of the colon definition or
quotation; it would offer the programmer a way to shoot himself in the
foot by using a local without first initializing it, but 1) Forth
programmers are used to and value such freedom/lack of safety. 2)
Uninitialized locals were added as a "feature" in Forth200x already
(and are probably usually used as a workaround for the lack of
multiple locals definitions in some Forth systems), so this approach
would not increase the dangers.

@InProceedings{ertl94l,
author = "M. Anton Ertl",
title = "Automatic Scoping of Local Variables",
booktitle = "EuroForth~'94 Conference Proceedings",
year = "1994",
address = "Winchester, UK",
pages = "31--37",
url = "http://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz",
abstract = "In the process of lifting the restrictions on using
locals in Forth, an interesting problem poses
itself: What does it mean if a local is defined in a
control structure? Where is the local visible? Since
the user can create every possible control structure
in ANS Forth, the answer is not as simple as it may
seem. Ideally, the local is visible at a place if
the control flow {\em must} pass through the
definition of the local to reach this place. This
paper discusses locals in general, the visibility
problem, its solution, the consequences and the
implementation as well as related programming style
questions."

[WJ]

Yes.

It seems that the goal of Mrs. Rather and her flunkies
is to keep Forth as crude as possible, so that the
employees of Forth, Inc. won't have to learn anything
new and to add new, sophisticated features to "Swift" Forth.

They are doing their best to make is as difficult as possible
to program in Forth.

Forth is not ANS Forth, just as Lisp is not Common Lisp.

Here's what the well-known author of Lisp books
Paul Graham said about Common Lisp:

#|
A hacker's language is terse and hackable. Common Lisp is not.

The good news is, it's not Lisp that sucks, but Common Lisp.

Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988?
|#

Here is what one of the disigners of Common Lisp, Daniel Weinreb,
admitted:

#|
Having separate "value cells" and "function cells" (to use
the "street language" way of saying it) was one of the most
unfortunate issues. We did not want to break pre-existing
programs that had a global variable named "foo" and a global
function named "foo" that were distinct. We at Symbolics
were forced to insist on this, in the face of everyone's
knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all
the specific things like this, but if we had had fewer
compatibility issues, I think it would have come out looking
more like Scheme in general.
|#


We should try to make it as easy as possible to solve
complicated programming problems in Forth. We should
try to raise Forth to a higher level.

Do what is best for those who want to be productive in Forth.
Do not do what is best for Forth, Inc. and Mrs. Rather.

It's not Forth that sucks, but ANS Forth.

[WJ]

Doug Hoffman wrote:

> On 3/18/15 7:09 AM, Stefan Mauerhofer wrote:
> > Regarding locals I will ignore the standard as much as I can. The
> > committee screwed it up with LOCALS| in the first place. The new
> > standard makes it even worse. The best solution IMHO would be to
> > ignore both standards regarding locals and continue using {..}
>
> If there were no standards I wouldn't be using Forth.

That makes no sense.

It would only make sense if you were a slavish fanatic
who considers the "standard" his holy scriptures.

What if the "standard" didn't allow floats? Would you say
that using floating point math is evil?

What if the "standard" limited integers to 16 bits.
Would you then say that 32-bit integers are the work of the devil?

The number of people who seriously program in ANS Forth is miniscule
compared to the number that program in Perl or Python or Ruby,
languages which are not crippled by an obsolete, clunky ANS "standard".

Paul Graham, the well-known author of Lisp books, said this about
ANS Lisp: "The good news is, it's not Lisp that sucks, but Common Lisp."

The good news is, it's not Forth that sucks, but ANS Forth.

To strive to preserve the crippling ANS standard or to replace it
with another backward standard sanctioned by Forth, Inc., is to strive
to destroy Forth.

[Doug Hoffman]

On 3/20/15 1:31 PM, WJ wrote:
> Doug Hoffman wrote:
>
>> On 3/18/15 7:09 AM, Stefan Mauerhofer wrote:
>>> Regarding locals I will ignore the standard as much as I can. The
>>> committee screwed it up with LOCALS| in the first place. The new
>>> standard makes it even worse. The best solution IMHO would be to
>>> ignore both standards regarding locals and continue using {..}
>>
>> If there were no standards I wouldn't be using Forth.
>
> That makes no sense.

It means that I can easily make use of code written by someone else. It
also means that I can switch Forth compilers, such as if the creator of
the Forth I was using stops supporting it. I think that makes a lot of

sense.

> It would only make sense if you were a slavish fanatic
> who considers the "standard" his holy scriptures.

No one is forced to follow the standard. But it does provide stability
and a starting place. But trying new "non-standard" things and showing
them to the Forth community is one way to get positive change to the
standard. This has happened a lot. This is, in fact, exactly what
happened with the LOCALS| ... | vs { ... } syntax that you are
responding to above. Whether it should be { ... } or {: ... :} is still
being debated somewhat but that is a rather minor point in this case.

> What if the "standard" didn't allow floats? Would you say
> that using floating point math is evil?
>
> What if the "standard" limited integers to 16 bits.
> Would you then say that 32-bit integers are the work of the devil?

There are a world of ifs to live in. Neither of the two you mention exist.

> The number of people who seriously program in ANS Forth is miniscule
> compared to the number that program in Perl or Python or Ruby,
> languages which are not crippled by an obsolete, clunky ANS "standard".

Tell us what you think is wrong with it and feel free to offer
suggestions for improvement. Break your pattern of never responding to
a question put directly to you. Are you able to do that?

> Paul Graham, the well-known author of Lisp books, said this about
> ANS Lisp: "The good news is, it's not Lisp that sucks, but Common Lisp."
>
> The good news is, it's not Forth that sucks, but ANS Forth.
>
> To strive to preserve the crippling ANS standard or to replace it
> with another backward standard sanctioned by Forth, Inc., is to strive
> to destroy Forth.

Instead of just parroting the mantra that something is "bad", provide
reason and rationale. You might be surprised at the result if your
reasoning is sound and presented in a well thought out manner.

[hughag...@gmail.com]

On Friday, March 20, 2015 at 8:27:20 AM UTC-7, Anton Ertl wrote:
> For now the locals
> from outside are not visible inside in Gforth; making them visible
> there in general requires garbage collection of the activation
> records.

WTF????????

You do not need garbage collection of the activation records!!! Moron!!! The activation record (local-frame) is not on the heap. This is done in Lisp to allow the lambda function to execute after the parent function has gone out of scope (the local-frame is GC'd when there are no more pointers to the lambda function floating around that could be executed). I have said repeatedly that this is a solution to a non-problem, and is one of the major reasons why Lisp is too slow to be used in commercial software and hence languishes in academia. If you want an anonymous function that will be executable indefinitely, just use :NONAME for that (I've never used :NONAME as this isn't particularly useful) --- the whole point of lambda functions is that they can communicate with the parent function, but the parent function obviously has to still be in scope in order to communicate with it.

In my language I have the local-frame on the return-stack, similar to what is currently done in VFX (this local frame is built at the beginning of the function's execution, before any >R or any control-structures have executed). The xt of the lambda function is a double-cell value, containing the cfa of the lambda function and the local-frame pointer of the parent function (for the xt of a colon word, this has a dummy value of zero). When the lambda function executes, it uses the parent's local-frame pointer, so it has access to the parent's locals. The parent function has to still be in scope so its local-frame is still on the return-stack where this pointer is pointing. This is super-simple to understand and to implement! You should have been able to figure this out on your own --- do you need me to explain lambda functions to you further? --- how could I possibly make this simple subject any clearer?

You aren't any good at computer programming, Anton Ertl --- you are unable to figure out simple programming problems --- you are only capable of borrowing other people's ideas (in this case, Lisp's over-complicated nonsense using the heap and GC for the local-frame).

Gforth is grossly over-complicated --- it is a huge language, with useless features added willy-nilly, but useful features missing completely --- the same is true of Forth-200x. This is the result of design-by-committee, in which every member gets to add some doo-dad to the language to make himself feel like he's contributing something, but nobody is doing any thinking or leading, and so the language becomes grossly bloated but directionless like a cancerous tumor. Then the C.L.F. herd squelches any original thinking with outlandish insults (Alex McDonald saying that I have a "serious misunderstanding of how pointers work") --- it is like chemotherapy in reverse --- it kills the patient and saves the tumor.

I am extremely frustrated with the Forth standardization effort! --- I feel like the only sober crew-member on the Exxon Valdez --- I tell everybody that the shoreline is looming ominously ahead, but nobody listens to me, and you just party on (Bernd Payson giving :NONAME some syntactic sugar and claiming that he has implemented "quotations," which is like painting a turd and passing it off as a gold nugget).

Hopefully I haven't mixed my metaphors excessively in this post --- I'm just trying to articulate my frustration as best as I can. :-)

[Elizabeth D. Rather]

On 3/20/15 11:41 AM, Doug Hoffman wrote:
> On 3/20/15 1:31 PM, WJ wrote:
>> Doug Hoffman wrote:

...

>>> If there were no standards I wouldn't be using Forth.
>>
>> That makes no sense.
>
> It means that I can easily make use of code written by someone else. It
> also means that I can switch Forth compilers, such as if the creator of
> the Forth I was using stops supporting it. I think that makes a lot of
> sense.
>
>> It would only make sense if you were a slavish fanatic
>> who considers the "standard" his holy scriptures.
>
> No one is forced to follow the standard. But it does provide stability
> and a starting place. But trying new "non-standard" things and showing
> them to the Forth community is one way to get positive change to the
> standard. This has happened a lot. This is, in fact, exactly what
> happened with the LOCALS| ... | vs { ... } syntax that you are
> responding to above. Whether it should be { ... } or {: ... :} is still
> being debated somewhat but that is a rather minor point in this case.
>
>> What if the "standard" didn't allow floats? Would you say
>> that using floating point math is evil?
>>
>> What if the "standard" limited integers to 16 bits.
>> Would you then say that 32-bit integers are the work of the devil?
>
> There are a world of ifs to live in. Neither of the two you mention exist.
>

In fact, FORTH83, the predecessor of ANS Forth, didn't allow floats and
limited single-length integers (as well as addresses) to 16 bits. It
also mandated Indirect Threaded implementation. ANS Forth fixed all
those problems (and added the ability to handle OS files portably, as
well as other features).

[Bernd Paysan]

Doug Hoffman wrote:
>> The number of people who seriously program in ANS Forth is miniscule
>> compared to the number that program in Perl or Python or Ruby,
>> languages which are not crippled by an obsolete, clunky ANS "standard".
>
> Tell us what you think is wrong with it and feel free to offer
> suggestions for improvement. Break your pattern of never responding to
> a question put directly to you. Are you able to do that?

One funny thing about that is that both Perl and Python have made or tried
to made incompatible transitions recently to Perl 6 and Python 3, leaving
old and broken concepts behind. Perl 6 is released "when it's ready", which
means people are stuck with Perl 5. Python 3 is already released and a lot
of people still stick with Python 2.7. It's still the default in most Linux
distributions.

So we have two out of three cases, where a much more popular language is
"crippled" by an obsolete implementation which doesn't move forward, but is
the default for compatibility reasons.

Note that all these languages are mostly single-implementation languages.
There's a single person steering the development. AFAIK, Ruby has actually
the most implementations, and it's the language where no break towards an
incompatible spec happens.

[Alex McDonald]

on 20/03/2015 23:14:55, wrote:
> On Friday, March 20, 2015 at 8:27:20 AM UTC-7, Anton Ertl wrote:
>> For now the locals
>> from outside are not visible inside in Gforth; making them visible
>> there in general requires garbage collection of the activation
>> records.
>

> Th e activation record (local-frame) is not on the heap. This

> is done in Lisp to allow the lambda function to execute after the
> parent function has gone out of scope (the local-frame is GC'd when

> there are no more pointers to th e lambda function floating around
> that could be executed). I have said repe atedly that this is a
> solution to a non-problem, and is one of the major re asons why Lisp

> is too slow to be used in commercial software and hence lang uishes in
> academia.

Closures & lambdas are commonly used in Javascript. I have used them in
Python. I use them regularly in Forth where they've become known as
quotations.

> If you want an anonymous function that will be executab le
> indefinitely, just use :NONAME for that (I've never used :NONAME as
> this isn't particularly useful) --- the whole point of lambda
> functions is that they can communicate with the parent function, but

> the parent function obv iously has to still be in scope in order to
> communicate with it.
>

Uh, no. There's your problem. What I meant, and Anton replied to, was
this case. [: ;] is what we're calling a quotation; it's an anonymous
(lambda) function.

defer bar
: foo {: a -- :} ... [: a . ;] ;
20 foo execute

At the point where the quotation is executed, local A is out of scope. It
is possible to maintain the environment of FOO in the closure. A closure
is an anonymous (lambda) function with bound variables. In this case A is
the variable, and it's still available after FOO has terminated.

[Doug Hoffman]

On 3/20/15 8:26 PM, Elizabeth D. Rather wrote:
> On 3/20/15 11:41 AM, Doug Hoffman wrote:
>> On 3/20/15 1:31 PM, WJ wrote:

>>> What if the "standard" didn't allow floats? Would you say that
>>> using floating point math is evil?
>>>
>>> What if the "standard" limited integers to 16 bits. Would you
>>> then say that 32-bit integers are the work of the devil?

>> There are a world of ifs to live in. Neither of the two you
>> mention exist.

> In fact, FORTH83, the predecessor of ANS Forth, didn't allow floats
> and limited single-length integers (as well as addresses) to 16 bits.
> It also mandated Indirect Threaded implementation. ANS Forth fixed
> all those problems (and added the ability to handle OS files
> portably, as well as other features).

Thanks Elizabeth. I didn't know that bit of history. It clearly shows
a few, of the many, significant problems solved by having the current
standard.

-Doug

[Doug Hoffman]

On 3/20/15 9:49 PM, Bernd Paysan wrote:
> Doug Hoffman wrote:
>>> The number of people who seriously program in ANS Forth is
>>> miniscule compared to the number that program in Perl or Python
>>> or Ruby, languages which are not crippled by an obsolete, clunky
>>> ANS "standard".
>>
>> Tell us what you think is wrong with it and feel free to offer
>> suggestions for improvement. Break your pattern of never
>> responding to a question put directly to you. Are you able to do
>> that?
>
> One funny thing about that is that both Perl and Python have made or
> tried to made incompatible transitions recently to Perl 6 and Python
> 3, leaving old and broken concepts behind. Perl 6 is released "when
> it's ready", which means people are stuck with Perl 5. Python 3 is
> already released and a lot of people still stick with Python 2.7.
> It's still the default in most Linux distributions.
>
> So we have two out of three cases, where a much more popular language
> is "crippled" by an obsolete implementation which doesn't move
> forward, but is the default for compatibility reasons.
>
> Note that all these languages are mostly single-implementation
> languages. There's a single person steering the development. AFAIK,
> Ruby has actually the most implementations, and it's the language
> where no break towards an incompatible spec happens.

Interesting insight about standards and issues with these other
languages. Thanks.

-Doug

[hughag...@gmail.com]

This seems to imply that, without ANS-Forth, we would all still be using a 16-bit Forth, no floating-point, ITC, no OS files, etc. --- Elizabeth Rather has solved so many of our significant problems for use! --- so, everybody join the cult, as the dichotomy demands that doing otherwise requires a return to Forth-83! LOL

Certainly, Forth-83 was a screwed-up standard, but this doesn't imply that ANS-Forth is not also a screwed-up standard --- Forth Inc. is to blame in both cases, and this will also be true of Forth-200x.

[hughag...@gmail.com]

On Friday, March 20, 2015 at 8:27:20 AM UTC-7, Anton Ertl wrote:

> Concerning quotations, the problem is not whether you can define them
> inside (ok, there is a bit of implementation effort required to
> support that), but whether locals defined outside are visible inside,
> and you already have that with a single local definition at the
> outermost level in combination with quotations. For now the locals
> from outside are not visible inside in Gforth; making them visible
> there in general requires garbage collection of the activation
> records. There have been discussions on ways to support something
> like this in a more limited way, but these ideas are still at the
> conceptual stage.

I have real quotations here:
http://www.forth.org/FMITE.txt

I mean, not the Payson-faked quotations that are just :NONAME with syntactic sugar --- real quotations that have access to the parent function's local variables.

[Alex McDonald]

Does this work in FMITE?

: foo {: myloc :} [: myloc 1+ ;] ;
10 foo execute

[Raimond Dragomir]

if myloc is a "normal" local variable (on a stack, NOT on a heap) this
won't work in any forth. At the time of the execute, the myloc variable is
out of scope.

In what forth is it working?

In my system this doesn't work:
def foo { myloc } [ myloc @ 1+ ] ;

But this is working:
def foo { myloc } [ myloc @ 1+ ] execute ;
10 foo .
11 ok

[Alex McDonald]

on 05/07/2015 10:04:13, Raimond Dragomir wrote:

None, since garbage collection is not a feature (although gforth has an
experimental collector).

>
> In my system this doesn't work:
> def foo { myloc } [ myloc @ 1+ ] ;
>
> But this is working:
> def foo { myloc } [ myloc @ 1+ ] execute ;
> 10 foo .
> 11 ok
>
>

Then, as Hugh complains about Bernd's "faked quotations", his FMITE is no
more than :NONAME syntactic sugar. Perhaps worse, as from what I read
there the language does not permit use of the quotation outside of its
enclosing word.

[Raimond Dragomir]

I don't know the Bernd's quotations or Hugh's. Maybe it's time to do
some comparison between them? Some test cases like the above (but working).
I would implement the cases in my system if possible also.
It could be real instructive.

Which one is willing to start the competition? :D

[franck....@gmail.com]

Le dimanche 5 juillet 2015 11:04:18 UTC+2, Raimond Dragomir a écrit :
>
> if myloc is a "normal" local variable (on a stack, NOT on a heap) this
> won't work in any forth. At the time of the execute, the myloc variable is
> out of scope.
>
> In what forth is it working?
>

Hello,

This is working in Oforth.

: foo(x) { #[ x 1 + ] }
10 foo perform .
11 ok

: foo(x) { #[ x + ] }
10 12 foo perform .
22 ok

10 20 foo tuck perform swap perform .
50 ok

Franck

[Raimond Dragomir]

Oforth is a dynamic language :)

In a static system the locals are on a stack and loose their scope when the
parent exits. For these systems, such test cases should be all completed
in the parent:

def foo [{ x } x @ 1+ ] execute ;
foo reDef
ok

10 foo .
11 ok

def bar [{ x } x @ [{ y } y @ 1+ ] execute 1+ x @ + ] execute ;
bar reDef
ok
10 bar .
22 ok
def foobar { | x y } [ x ! x @ [ y ! y @ 1+ ] execute 1+ x @ + ] execute ;
foobar reDef
ok
10 foobar .
22 ok

[Raimond Dragomir]

On the other hand, if the quotations have their own locals, they work
outside the parent.

def xt+ [{ x y } x @ y @ + ] ;
ok
1 2 xt+ execute .
3 ok
def xt+2 { a b } a @ [{ x y } x @ y @ + ] swap b @ + swap execute ;
ok
100 1 2 xt+2 .
103 ok

Only that a quotation with own locals cannot "see" parent's locals, even
if they are different names.

[Raimond Dragomir]

> def xt+2 { a b } a @ [{ x y } x @ y @ + ] swap b @ + swap execute ;
> ok
> 100 1 2 xt+2 .
> 103 ok
>
> Only that a quotation with own locals cannot "see" parent's locals, even
> if they are different names.

This is the example with the quotation having locals with the same name
with parent's:

def xt+2 { a b } a @ [{ a b } a @ b @ + ] swap b @ + swap execute ;
xt+2 reDef

ok
100 1 2 xt+2 .
103 ok

And here we can see that the 'a' local in quotation is unknown. The
quotation local frame { x y } hides parent's frame { a b } regardless the
locals name.

def xt+2 { a b } a @ [{ x y } x @ y @ + a @ + ] swap b @ + swap execute ;
xt+2 reDef
stdin(1): Error: a : unknown word
ok

[Bernd Paysan]

Raimond Dragomir wrote:
> I don't know the Bernd's quotations or Hugh's. Maybe it's time to do
> some comparison between them? Some test cases like the above (but
> working). I would implement the cases in my system if possible also.
> It could be real instructive.

My quotations don't have access to the locals of the surrounding definition.
They have access to the stack. In fact, the quotations are just an unnamed
definition in the middle of another definition. The convention for higher
order functions is that they call the quotation with full access to the
stack underneath, so you can do things with that.

E.g. count the number of words in a wordlist with TRAVERSE-WORDLIST:

: count-words ( wid -- n ) 0 [: drop 1+ true ;] rot traverse-wordlist ;

forth-wordlist count-words . 1933 ok

--
Bernd Paysan
"If you want it done right, you have to do it yourself"

net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

http://bernd-paysan.de/

[franck....@gmail.com]

Le dimanche 5 juillet 2015 13:15:40 UTC+2, Raimond Dragomir a écrit :
> In a static system the locals are on a stack and loose their scope when the
> parent exits. For these systems, such test cases should be all completed
> in the parent:
>

Same in Oforth : locals are on stack too and loose their scope when the parent
exit.

What is dynamic is the quotation itself. When created (and if it uses locals),
it is created on the heap and store values of the locals used.
When executed, it creates its own local frame (on the stack) with values
initialized with those stored when created.

[Raimond Dragomir]

Here it is in my system:

def countwords ( wid -- n ) 0 [ ( nt ) drop 1+ true ] rot traversewordlist ;
ok
~quo countwords .
193 ok
~qlib countwords .
116 ok

I don't like the naming with '-' sign. I prefer the C's '_' but wherever
possible, nothing :-D

I sometimes use camelcase naming (only in applications). My system is case
sensitive, with all kernel words lower case.

[Raimond Dragomir]

Some versions of the same thing with locals:

def cw 0 [{ nt } 1+ true ] rot traversewordlist ;
ok
~quo cw .
193 ok
def cw { wid -- n } 0 [{ nt } 1+ true ] wid @ traversewordlist ;
cw reDef
ok
~quo cw .
193 ok
def cw { wid | nt -- n } 0 [ nt ! 1+ true ] wid @ traversewordlist ;
cw reDef
ok
~quo cw .
193 ok

nt local is not used, but very nice as a self documentation :)

[foxaudio...@gmail.com]

On Saturday, March 14, 2015 at 7:43:44 PM UTC-4, grobibi wrote:
> Hello,
> There is something I don't understand with local variable with gforth.
> A variable defined like this :
>
> variable x 10
>
> will have a general scope. How can I get a local scope for a variable
> inside a word definition ? Is it possible ?
>
> Is there a way to bypass this because, for me, a local variable has to
> behave like in lisp like this : (defun foo (x) (let ((lst)) ) ... It
> will initialize lst to nil (but it can be initialized to anything.).
> Maybe my lisp habitus drives me in a wrong way.
>
> Thanks

Hi Grobibi,

As the this thread indicates you have activated some vigorous discussion on a very live issue on comp.lang.forth.

My observation will attempt to bypass the internal issues and continue along the lines of assisting your understanding. I must add that I am a light-weight in this group intellectually and that perhaps allows me to see the challenge of trying Forth from a different perspective.

From your post, I am seeing that your Lisp knowledge is biasing your thinking about Forth.

The first thing to know is that Forth is a VERY primitive language at its heart.
The fundamental approach of Charles Moore was to remove all unneccessary parts of the language that he felt he could better coordinate as needed for the problem at hand.

This means that you do a lot of the work yourself where other languages provide assistance. Fortunately the language lets you crystallize your work into a lexicon of words that in fact create your own "domain specific language" that makes solving the problem somewhat elegant. (at least to the author) :-)

It is therefore important to get right down to the basic assumptions of the language and in that sense, it is a little like learning assembler for a specific processor.

From the Forth perspective the computer is little more than a parameter stack, a return stack, the ALU and RAM. Connected to that machine are the various I/O devices.

All of these components are accessed in a very direct way, un-protected, so to speak, compared to other "high level" programming approaches.

The net result is that many of our assumptions about how a programming language should work must go "out the window" when we begin to study Forth. For many of us here, that is part of the appeal.

I would recommend collecting the various books that have been written including my favourite called Thinking Forth, which gives you the 30,000 foot (10,000 M) overview of the Forth Philosophy of programming.

http://thinking-forth.sourceforge.net/

And the other wonderful aspect of learning forth is working with the interactive nature of the system. In that sense you have already experienced that in Lisp. Theory can be quickly validated or discounted. It's fantastic.

BF

[Bernd Paysan]

Raimond Dragomir wrote:
> Some versions of the same thing with locals:
>
> def cw 0 [{ nt } 1+ true ] rot traversewordlist ;

This sort of locals is doable with my quotations:

: cw ( wid -- n ) 0 [: { nt } 1+ true ;] rot traverse-wordlist ;
forth-wordlist cw . 1934 ok

(still running the same session)

The thing people like Hugh want is something like

: cw ( wid -- n ) 0 { n } [: drop n 1+ to n true ;] swap traverse-wordlist
n ;

[hughag...@gmail.com]

On Sunday, July 5, 2015 at 6:28:04 AM UTC-7, Bernd Paysan wrote:
> Raimond Dragomir wrote:
> > I don't know the Bernd's quotations or Hugh's. Maybe it's time to do
> > some comparison between them? Some test cases like the above (but
> > working). I would implement the cases in my system if possible also.
> > It could be real instructive.

I have abundant example code in my document --- rewrite any of that using the Payson-faked quotations --- this will only be possible with the bar-feature quotations, and in Forth-200x it will be a big inefficient mess.

> My quotations don't have access to the locals of the surrounding definition.
> They have access to the stack. In fact, the quotations are just an unnamed
> definition in the middle of another definition. The convention for higher
> order functions is that they call the quotation with full access to the
> stack underneath, so you can do things with that.

My quotations in FMITE have access to the locals of the parent function (what you call "surrounding definition" above).

If a bar-feature higher-order function is used, then the quotations have access to the data-stack of the parent function.

> E.g. count the number of words in a wordlist with TRAVERSE-WORDLIST:
>
> : count-words ( wid -- n ) 0 [: drop 1+ true ;] rot traverse-wordlist ;
>
> forth-wordlist count-words . 1933 ok

TRAVERSE-WORDLIST is the only higher-order function that you have in Forth-200x --- you trot this out as your example every time that the subject of quotations comes up --- you aren't showing the source-code for TRAVERSE-WORDLIST because it is a mess, and this messiness is also why you have never written any other higher-order function.

[hughag...@gmail.com]

On Sunday, July 5, 2015 at 2:36:05 AM UTC-7, Alex McDonald wrote:
> Then, as Hugh complains about Bernd's "faked quotations", his FMITE is no
> more than :NONAME syntactic sugar. Perhaps worse, as from what I read
> there the language does not permit use of the quotation outside of its
> enclosing word.

Alex McDonald is lying --- as usual.

[Raimond Dragomir]

def cw { wid | n -- n } [ drop 1 n +! true ] wid @ traversewordlist n @ ;

[Alex McDonald]

Have you read your own stuff?

"It is illegal to execute the xt of a quotation after the parent function
has gone out of scope (done its EXIT)."

[hughag...@gmail.com]

Alex McDonald purposely misrepresents everything --- twists people words around to mean the exact opposite of what they said, then plays dumb as if he didn't understand the original words.

Also, Alex McDonald will repeat the same lie over and over again, such as saying that my disambiguifiers don't work or that they require the word being disambiguified to be immediate --- he is just hoping that I won't respond every time and that a few of his lies will get through without being refuted --- once again, he plays dumb as if he doesn't know that what he is saying is untrue.

Alex McDonald is a liar --- he twists everything around and nothing he says is true --- I recommend that people ignore him.

If people want to know how the FMITE works, I recommend that they read my document: http://www.forth.org/FMITE.txt

I don't really want to discuss the FMITE with ANS-Forth promoters because ANS-Forth is a cult and the members routinely lie about everything (covering up ANS-Forth's failures, and projecting failure on competing ideas) --- discussing anything with ANS-Forth promoters is a waste of time, comparable to wrestling a pig (you end up covered in mud, and the pig enjoys it).

[Alex McDonald]

on 07/07/2015 03:59:28, wrote:
> On Monday, July 6, 2015 at 12:09:53 AM UTC-7, Alex McDonald wrote:
>> on 06/07/2015 03:57:53, wrote:
>> > On Sunday, July 5, 2015 at 2:36:05 AM UTC-7, Alex McDonald wrote:
>> >> Then, as Hugh complains about Bernd's "faked quotations", his FMITE is
> no
>> >> more than :NONAME syntactic sugar. Perhaps worse, as from what I read
>> >> there the language does not permit use of the quotation outside of its
>> >> enclosing word.
>> >
>> > Alex McDonald is lying --- as usual.
>> >
>>
>> Have you read your own stuff?
>>
>> "It is illegal to execute the xt of a quotation after the parent function
>> has gone out of scope (done its EXIT)."
>
> Alex McDonald purposely misrepresents everything --- twists people

> words ar ound to mean the exact opposite of what they said, then plays

> dumb as if he didn't understand the original words.

Ummm... what didn't I understand about the original words "It is illegal

to execute the xt of a quotation after the parent function has gone out

of scope?" This looks like a slam dunk to me.

>
> Also, Alex McDonald will repeat the same lie over and over again, such

> as s aying that my disambiguifiers don't work or that they require the
> word bein g disambiguified to be immediate --- he is just hoping that

> I won't respond every time and that a few of his lies will get through

> without being refut ed --- once again, he plays dumb as if he doesn't

> know that what he is sayi ng is untrue.

I couldn't get your code to work. I imagine most other people didn't try.

>
> Alex McDonald is a liar --- he twists everything around and nothing he
> says is true --- I recommend that people ignore him.
>

Point out my lies, or expect my lawyers (Butt, Hurt & Cox LLP) to be in
contact by the end of the week.

[Michael Barry]

On Tuesday, July 7, 2015 at 12:30:40 AM UTC-7, Alex McDonald wrote:
> ...

> Ummm... what didn't I understand about the original words "It is
> illegal to execute the xt of a quotation after the parent function
> has gone out of scope?" This looks like a slam dunk to me.
>

I read Hugh's document carefully at least once, and it's a bit too
advanced for me to understand it completely, but my impression is
that you are correct. If an orphaned quotation is called, it
would happily execute, but would likely corrupt the stack. Is
this some kind of catastrophic failure in the design, or just an
implementation decision that needs to be carefully followed?

> ...

> I couldn't get your code to work. I imagine most other people didn't
> try.
>

I was waiting for him to share his simulator with me before I tried
his code. Did you use his document to whip up your own simulator,
or are you executing it by hand (or in your head)? I know that
you're a pretty sharp cookie, but it puzzles me that you would
bother to expend the effort. I know that Hugh isn't interested in
your opinion, but I am. Could you share a few thoughts about what
you feel may be the merits and/or faults of his design? I, for
one, thought that it was kind of neat, and I don't feel eccentric
or ignorant enough to be the only one here who thought so.

Mike B.

[Raimond Dragomir]

Hi Mike,

Hugh's design is not faulty. The problem is that his saying is taken out of
context by Alex.
Indeed is not possible to run a quotation when its parent is not
running, because the paren't locals are out of scope.
But This is only the case when the quotation is using a parent local.
In all other cases it's definitely possible to run the quotation.
So a parent can 'return' a quotation xt on the stack
and this xt can be executed everywhere and anytime, as long as the quotation
is not using parent locals. If it uses parent locals it can be executed
only inside the parent.
That's what is Hugh saying. Alex took an afirmation out of context and wants
to proove something. It is totally unfair, not to say that he gave a non-
working example (in any system).
I made the point at that time, giving the correct example (that works in my
system (and Hugh's also, I'm sure).
Hugh's may have a simulator (a cross-compiler for the FMITE but FMITE is
not a real processor yet) but I have a working system on which I can test
for real. So I'm not talking here "in theory".

[Alex McDonald]

on 10/07/2015 08:35:39, Michael Barry wrote:
> On Tuesday, July 7, 2015 at 12:30:40 AM UTC-7, Alex McDonald wrote:
>> ...
>> Ummm... what didn't I understand about the original words "It is
>> illegal to execute the xt of a quotation after the parent function
>> has gone out of scope?" This looks like a slam dunk to me.
>>
>
> I read Hugh's document carefully at least once, and it's a bit too
> advanced for me to understand it completely, but my impression is
> that you are correct. If an orphaned quotation is called, it
> would happily execute, but would likely corrupt the stack. Is
> this some kind of catastrophic failure in the design, or just an
> implementation decision that needs to be carefully followed?

No, it's just that Hugh thinks he's fixed a problem. He tells anyone who
disagrees that they're idiots and they don't understand closures and
quotations, and documents the solution in FMITE. Only to have me point
out that that he hasn't actually fixed the problem, and his solution is
more limited than it need be and is stated in ambiguous language,
something he rails against in the ANS spec.

>
>> ...
>> I couldn't get your code to work. I imagine most other people didn't
>> try.
>>
>
> I was waiting for him to share his simulator with me before I tried
> his code. Did you use his document to whip up your own simulator,
> or are you executing it by hand (or in your head)? I know that
> you're a pretty sharp cookie, but it puzzles me that you would
> bother to expend the effort. I know that Hugh isn't interested in
> your opinion, but I am. Could you share a few thoughts about what
> you feel may be the merits and/or faults of his design? I, for
> one, thought that it was kind of neat, and I don't feel eccentric
> or ignorant enough to be the only one here who thought so.

The code Hugh was refering to was his "disambiguifiers". It's was an
attempt to get ANS Forth work the way Hugh wants it to.

I've done none of the things you mention apart from give his FMITE
document a brief read. I always have difficulty reading Hugh's stuff as
considerable chunks of it normally end up defaming named individuals and
accusing them of grandiose plans of world domination, and the same is
true in FMITE. I also find most of his technical stuff has similar
problems; it is discursive and not very illuminating windbaggery.

>
> Mike B.
>
>

[Alex McDonald]

Here's what Anton Ertl said re quotations.

|> Concerning quotations, the problem is not whether you can define them
|> inside (ok, there is a bit of implementation effort required to
|> support that), but whether locals defined outside are visible inside,
|> and you already have that with a single local definition at the
|> outermost level in combination with quotations. For now the locals
|> from outside are not visible inside in Gforth; making them visible
|> there in general requires garbage collection of the activation
|> records. There have been discussions on ways to support something
|> like this in a more limited way, but these ideas are still at the
|> conceptual stage.

Here's what Hugh claimed in response.

|I have real quotations here:
|http://www.forth.org/FMITE.txt

|I mean, not the Payson-faked quotations that are just
|:NONAME with syntactic sugar --- real quotations that
|have access to the parent function's local variables.

> Indeed is not possible to run a quotation when its parent is not
> running, because the paren't locals are out of scope.

But that was Anton's point to which Hugh was responding.

> But This is only the case when the quotation is using a parent local.
> In all other cases it's definitely possible to run the quotation.
> So a parent can 'return' a quotation xt on the stack
> and this xt can be executed everywhere and anytime, as long as the
> quotation is not using parent locals. If it uses parent locals it can
> be executed only inside the parent.
> That's what is Hugh saying.

Hugh was claiming much more and delivering a lot less. In fact, the
gyrations he proposes in section 16 of http://www.forth.org/FMITE.txt are
to avoid the dreaded "maybe/maybe not" ambguities that Hugh finds hard to
handle in the ANS Forth spec. Hugh isn't proposing to prevent quotations
that refer to out of scope locals at compile time, btw, but at run time
in what looks like a compute heavy process. Having read through it
briefly, I'm not even sure it's feasible, since it depends on a hidden
local on the return stack with the address of the parent, and it would
probably invalidate quotations inside quotations.

> Alex took an afirmation out of context and
> wants to proove something. It is totally unfair, not to say that he
> gave a non- working example (in any system).

Of course it's non-working, since it requires garbage collection as Anton
notes.

: foo {: myloc :} [: myloc 1+ ;] ;
10 foo execute

Because that was Anton's point, which Hugh missed.

> I made the point at that time, giving the correct example (that works
> in my system (and Hugh's also, I'm sure).
> Hugh's may have a simulator (a cross-compiler for the FMITE but FMITE
> is not a real processor yet) but I have a working system on which I
> can test for real. So I'm not talking here "in theory".
>

"It is illegal to execute the xt of a quotation after the parent function

has gone out of scope (done its EXIT)." Please show me where I've taken
Hugh out of context.

[Raimond Dragomir]

> |> Concerning quotations, the problem is not whether you can define them
> |> inside (ok, there is a bit of implementation effort required to
> |> support that), but whether locals defined outside are visible inside,
> |> and you already have that with a single local definition at the
> |> outermost level in combination with quotations. For now the locals
> |> from outside are not visible inside in Gforth; making them visible
> |> there in general requires garbage collection of the activation
> |> records. There have been discussions on ways to support something
> |> like this in a more limited way, but these ideas are still at the
> |> conceptual stage.
>

Anton Ertl is speaking "in general".
No, garbage collection and "activation records" are not required for a
static language (like forth). My implementation proves that. My forth is
as static as any other classical forth out there (not Oforth or Factor).
Are we talking of dynamic languages now? Since when?

Maybe that "limited way" would be the way that I and Hugh implemented?
(with the only "limitation" of the parent's locals going out of scope
when parent exits) Well, good news, it's not at a conceptual stage
anymore, it's implemented and working.

> Here's what Hugh claimed in response.
>
> |I have real quotations here:
> |http://www.forth.org/FMITE.txt
>
> |I mean, not the Payson-faked quotations that are just
> |:NONAME with syntactic sugar --- real quotations that
> |have access to the parent function's local variables.
>
>

That's completely true. Are you bothered by the "real" term? In a static
language locals are on a stack not on a heap. It's an inherent limitation
for them to go out of scope when their parent exits.

> > Indeed is not possible to run a quotation when its parent is not
> > running, because the paren't locals are out of scope.
>
> But that was Anton's point to which Hugh was responding.
>

If Anton is talking of dynamic languages (I didn't see the fact he is)
it's his problem if he cannot understand the quotations of a static
language. However he made some note about a "limited way" in a conceptual
stage.

The fact is that Gforth doesn't have what I and Hugh have, quotations which
can "see" locals of an outer level. Probably Hugh is proud of that and
calls his quotations "real". "Real" or "not real" but definetely better.

[Alex McDonald]

on 10/07/2015 15:13:06, Raimond Dragomir wrote:

>>
>
> If Anton is talking of dynamic languages (I didn't see the fact he is)
> it's his problem if he cannot understand the quotations of a static
> language. However he made some note about a "limited way" in a
> conceptual stage.

What is a static language or a dynamic language? They are terms I'm
unfamiliar with, unless you mean static vs dynamic typing, which is not
what we're taking about here. The discussion is about quotations in
relation to name scope and closure-like behaviour.

>
> The fact is that Gforth doesn't have what I and Hugh have, quotations
> which can "see" locals of an outer level. Probably Hugh is proud of
> that and calls his quotations "real". "Real" or "not real" but
> definetely better.

Why better? Do you have a use case you can show? I also support this
feature, but I haven't found a use for it.

[Raimond Dragomir]

> What is a static language or a dynamic language? They are terms I'm
> unfamiliar with, unless you mean static vs dynamic typing, which is not
> what we're taking about here. The discussion is about quotations in
> relation to name scope and closure-like behaviour.
>

A dynamic language is a language that needs a garbage collector.

> >
> > The fact is that Gforth doesn't have what I and Hugh have, quotations
> > which can "see" locals of an outer level. Probably Hugh is proud of
> > that and calls his quotations "real". "Real" or "not real" but
> > definetely better.
>
> Why better? Do you have a use case you can show? I also support this
> feature, but I haven't found a use for it.

It's about high order words (like "map", "filter", "apply", etc. see Oforth, see Factor) in strong relation with data structures.

What I'm trying to achieve is to have a as much as possible a classical forth
system but with support for general purpose data structures and high
order words + quotations at a level that will not require a garbage
collector.

Something like a "static" Oforth or a "static" Factor. :-D

[Alex McDonald]

on 10/07/2015 16:57:56, Raimond Dragomir wrote:
>
>> What is a static language or a dynamic language? They are terms I'm
>> unfamiliar with, unless you mean static vs dynamic typing, which is not
>> what we're taking about here. The discussion is about quotations in
>> relation to name scope and closure-like behaviour.
>>
> A dynamic language is a language that needs a garbage collector.

C++ has closures but no GC
http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
same is true of Rust http://doc.rust-lang.org/book/README.html.

>
>> >
>> > The fact is that Gforth doesn't have what I and Hugh have, quotations
>> > which can "see" locals of an outer level. Probably Hugh is proud of
>> > that and calls his quotations "real". "Real" or "not real" but
>> > definetely better.
>>
>> Why better? Do you have a use case you can show? I also support this
>> feature, but I haven't found a use for it.
>
> It's about high order words (like "map", "filter", "apply", etc. see
> Oforth, see Factor) in strong relation with data structures.

I get that, but I was wondering what the benefit of using outer locals in
quotations might be.

[Paul Rubin]

"Alex McDonald" <bl...@rivadpm.com> writes:
> C++ has closures but no GC
> http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
> same is true of Rust http://doc.rust-lang.org/book/README.html.

Yes but I think Lisp programmers would look at that and groan.
Traditionally such closures are allocated on the heap and garbage
collected, because of the upward funarg problem:
https://en.wikipedia.org/wiki/Funarg_problem

> I get that, but I was wondering what the benefit of using outer locals
> in quotations might be.

Here's a Python example:

def square(x): return x*x
def double(x): return x*2

def compose(f,g):
def c(x): return f(g(x)) # <--- uses outer locals
return c # <---- c uses upward funargs

double_square = compose(double, square)

print(double_square(3)) # prints 18 which is 2*(3*3)

[Mark Wills]

I was wondering what the benefit of quotations might be. They seem rather pointless to me. "Me too" features.

[Elizabeth D. Rather]

On 7/10/15 7:28 AM, Mark Wills wrote:
> I was wondering what the benefit of quotations might be. They seem rather pointless to me. "Me too" features.
>

Yes. I've asked that in the past, and the answers so far have been
unpersuasive.

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

[Alex McDonald]

on 10/07/2015 18:28:48, Mark Wills wrote:
> I was wondering what the benefit of quotations might be. They seem
> rather pointless to me. "Me too" features.
>

.. [: refill drop interpreter ;] catch ...

This is part of QUIT. It could have been

: quit-interpret refill drop interpreter ;

.. ['] quit-interpreter catch ...

I believe quotations to be clearer. They're also very simple to
implement.

[Elizabeth D. Rather]

Clarity is in the eye of the beholder. In my experience, the thing
you're most likely to want to CATCH is a lot more complicated than this
example, and deserves to be its own definition.

[Raimond Dragomir]

> > A dynamic language is a language that needs a garbage collector.
>
> C++ has closures but no GC
> http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
> same is true of Rust http://doc.rust-lang.org/book/README.html.
>

And your point is...? Did I say that a dynamic language is the one having
closures or lambda functions? Did I say that having quotations you need
a dynamic language? Did I say that C++ is a dynamic language?

> >
> >> >
> >> > The fact is that Gforth doesn't have what I and Hugh have, quotations
> >> > which can "see" locals of an outer level. Probably Hugh is proud of
> >> > that and calls his quotations "real". "Real" or "not real" but
> >> > definetely better.
> >>
> >> Why better? Do you have a use case you can show? I also support this
> >> feature, but I haven't found a use for it.
> >
> > It's about high order words (like "map", "filter", "apply", etc. see
> > Oforth, see Factor) in strong relation with data structures.
>
> I get that, but I was wondering what the benefit of using outer locals in
> quotations might be.

Comunicating or sharing state info between the levels. Basically it's all
about local variables, and I know, in forth this is kind of a shame to use
locals.

[hughag...@gmail.com]

On Friday, July 10, 2015 at 11:00:23 AM UTC-7, Elizabeth D. Rather wrote:
> On 7/10/15 7:28 AM, Mark Wills wrote:
> > I was wondering what the benefit of quotations might be. They seem rather pointless to me. "Me too" features.
> >
>
> Yes. I've asked that in the past, and the answers so far have been
> unpersuasive.
>
> Cheers,
> Elizabeth

The purpose of quotations, insofar as LOTD, is to allow people to write general-purpose data-structures. The idea is that the code-library writer writes a higher-order function that traverses the data-structure and executes a quotation for every node. The quotation is able to communicate with its parent function because it has access to the parent function's local variables.

If a bar-feature higher-order function is used, then the quotation can communicate with the parent function via the stack --- bar-feature higher-order functions are more complicated to write (they have to be written in assembly-language rather than in LOTD) and they tend to be slower because they are pushing all of their internal data to the return-stack every time they execute the quotation to get it off the data-stack and out of the way --- bar-feature higher-order functions can be convenient an efficient in some simple cases (linked lists), but it is idiomatic in LOTD to communicate via the parent function's local variables as this is can be written in LOTD rather than assembly-language, it makes for cleaner and more readable code, and in many cases is more efficient (especially with more complicated data-structures and/or more complicated quotations).

In the document (section-17) I quote you:
Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure.

I think the reason why you find quotations to be "unpersuasive" is because you are actively trying to prevent general-purpose data-structures from being written in Forth. Forth has such a bad reputation because of you that I changed the name of my language to LOTD (Language Of The Damned). For example, over here (https://embdev.net/topic/370139#4181561) I mentioned my design and I only got one response: "Bytecode stuff is interesting, but eventually people will care about robustness and how easy they can achieve their goal. Programming aspects DO count, and you'll get very little attention from the industry by using Forth.."

ANS-Forth has ruined Forth's reputation --- nobody wants to read anything new about Forth, because they assume that they already know everything there is to know about Forth from their study of ANS-Forth, and they believe that the Forth community is totally ignorant of how to write general-purpose reusable code-libraries.

[hughag...@gmail.com]

On Tuesday, July 7, 2015 at 12:30:40 AM UTC-7, Alex McDonald wrote:
> on 07/07/2015 03:59:28, wrote:
> > On Monday, July 6, 2015 at 12:09:53 AM UTC-7, Alex McDonald wrote:
> >> on 06/07/2015 03:57:53, wrote:
> >> > On Sunday, July 5, 2015 at 2:36:05 AM UTC-7, Alex McDonald wrote:
> >> >> Then, as Hugh complains about Bernd's "faked quotations", his FMITE is
> > no
> >> >> more than :NONAME syntactic sugar. Perhaps worse, as from what I read
> >> >> there the language does not permit use of the quotation outside of its
> >> >> enclosing word.

Alex McDonald is a liar. He said: "Hugh complains about Bernd's 'faked quotations', his FMITE is no more than :NONAME syntactic sugar."

He is totally lying --- my quotations have access to the parent function's local variables --- this wasn't an obscure point that he somehow missed; this is the point of the FMITE, so this was described repeatedly throughout the document.

He said: "Perhaps worse, as from what I read there the language does not permit use of the quotation outside of its enclosing word."

He is totally lying --- the quotation is passed into higher-order functions and they execute it --- once agin

> Ummm... what didn't I understand about the original words "It is illegal
> to execute the xt of a quotation after the parent function has gone out
> of scope?" This looks like a slam dunk to me.

Alex McDonald is not trying to understand --- he just wants to support ANS-Forth and Forth-200x by lying about competing ideas --- he wants to make a "slam dunk," but this is not a positive contribution from any perspective.

> Point out my lies, or expect my lawyers (Butt, Hurt & Cox LLP) to be in
> contact by the end of the week.

Alex McDonald is fishing for praise from Elizabeth Rather so that this will be a total "slam dunk" for him. So, we will give him what he wants (just substitute "Alex" for "John" in the following):

On Sunday, November 29, 2009 at 7:07:39 PM UTC-7, Elizabeth D Rather wrote:
> Hugh Aguilar wrote:
> > I ignored your lengthy post because of your vulgar mindset. Here are
> > some examples:
> > ...
> > Your use of the terms "sucks" and "ass" indicate that you are member
> > of a community of people that don't belong on comp.lang.forth. You
> > should already be well aware of my opinion of this community of
> > people, and you should not have used your community's terminology in a
> > post directed at a decent person such as myself. I suggest that you go
> > back to your own community, where such language is appreciated, and
> > stop posting vulgar messages on comp.lang.forth.
>
> Ok, Hugh, that's the last straw. You're in my "kill file" now. I have
> no interest in any further postings from you on any subject.
>
> Not because I have any great personal affinity for John -- I've never
> met him, and know him only through his posts here, which are unfailingly
> interesting, perceptive, and technically sound (even when we disagree).
> But I am *personally* offended by your homophobic bias and use of
> personal insults. I do not choose to converse with people of your
> intolerant mindset. John has made far more technical contributions to
> comp.lang.forth than you have.
>
> Bye.
>
> Elizabeth

[hughag...@gmail.com]

On Friday, July 10, 2015 at 9:21:45 PM UTC-7, Raimond Dragomir wrote:
> > > A dynamic language is a language that needs a garbage collector.
> >
> > C++ has closures but no GC
> > http://www.cprogramming.com/c++11/c++11-lambda-closures.html, and the
> > same is true of Rust http://doc.rust-lang.org/book/README.html.
> >
> And your point is...? Did I say that a dynamic language is the one having
> closures or lambda functions? Did I say that having quotations you need
> a dynamic language? Did I say that C++ is a dynamic language?

So far, Raimond is the only person on comp.lang.forth who has understood LOTD --- now we see poor Raimond getting his words twisted by Alex the word-twister --- and predictably Raimond gets frustrated and angry, which is Alex's greatest delight (what Alex refers to as a "slam dunk").

This seems to be the standard strategy of the ANS-Forth cult --- twist everybody else's words and tell blatant lies about them to make them appear stupid --- I don't think the ANS-Forth cult is fooling anybody; I think the Forth community is ignored in the real world because everybody is on to your tricks.

[Bernd Linsel]

Am 10.07.2015 um 17:29 schrieb Alex McDonald:
> on 10/07/2015 15:13:06, Raimond Dragomir wrote:
>

> [...]

>
> What is a static language or a dynamic language? They are terms I'm
> unfamiliar with, unless you mean static vs dynamic typing, which is not
> what we're taking about here. The discussion is about quotations in
> relation to name scope and closure-like behaviour.
>

"Static" and "dynamic" language references visibility/accessibility
(scope) of symbols and lifetime (extent) of [local] variables.

Static (better: lexical) scoping means, you can derive the visibility of
a symbol by examining the hierarchy in the source. The symbol is
accessible within the block (function) it is defined in, and all the
block's lexical children (functions in functions, local classes,
quotations), but not its siblings or parent. This is standard in all
newer languages that base on ALGOL. It can easily be implemented using
stack frames.

With dynamic scoping, not the source code, but the runtime call chain
determines visibility of symbols independently of their lexical
relation. A called function may access variables defined in the calling
function, even if they are defined in different locations.
Symbol accesses in such languages normally involve a symbol lookup at
runtime, if the name can not be statically resolved at compile time --
which is the case for all non-locally defined symbols.

The extent describes when during the program's execution a variable's
binding is retained. ALGOL-like languages have commonly *static extent*,
meaning that their variables contents are lost when they go out of scope
(the execution reaches their defining block's end). There are sometimes
alternatives, e.g. C's "static" variables (with static scope and
*infinite extent*), that have to be initialized when being defined and
retain their bindings until termination of the program. Anytime the
variable comes into scope (by execution of its containing block), you
can access it (scope), and get the last assigned value (extent). The
initialization is performed only once, at the first invocation.
Dynamic extent is still beyond this concept. With dynamic extent,
variables exist in "activation records" or "environments", which, once
created, persist as long as they could possibly be accessed, thus
requiring garbage collection if one wants to reclaim this memory. A
function with a living activation record becomes a closure, effectively
holding a state between calls to that function. Lips's lambda functions
and JavaScript's constructor functions are such closures.

I hope that makes the concepts and terms clearer.
Regards,
Bernd