On 2024-04-17, John Ames <commodorejohn@gmail.com> wrote:
> On Wed, 17 Apr 2024 21:52:06 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> I think that when finding the definition of a word, Forth just
>> searches back through the stack of definitions until it gets a hit.
>> And if that word definition uses other non-primitive words, it goes
>> backwards from where it currently is, looking only at definitions
>> from before the current word was defined. Is that right? And if so,
>> can you do "forward declarations", and mutual recursion somehow?
>
> That's my understanding, yes; essentially, it's a consequence of the
> fact that definitions are stored as a list of pointers, and re-
> definitions are simply appended to the dictionary without going back
> through the rest of it to update any pointers to the prior definition.
> A strange design choice, but they're consistent with it.

I don't know at all whether Forth does this or not, but this design
choice allows the list to be restored to a prior state, whereby the
recent definitions are forgotten, and the old ones revealed again,
similarly to shadowed lexicals being revealed again upon the terminaton
of an inner scope.

It sounds reminiscent of the assoc list representation of the lexical
environment in a rudimentary Lisp interpreter.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 18/04/2024 06:18, Kaz Kylheku wrote:
> On 2024-04-17, John Ames <commodorejohn@gmail.com> wrote:
>> On Wed, 17 Apr 2024 21:52:06 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> I think that when finding the definition of a word, Forth just
>>> searches back through the stack of definitions until it gets a hit.
>>> And if that word definition uses other non-primitive words, it goes
>>> backwards from where it currently is, looking only at definitions
>>> from before the current word was defined. Is that right? And if so,
>>> can you do "forward declarations", and mutual recursion somehow?
>>
>> That's my understanding, yes; essentially, it's a consequence of the
>> fact that definitions are stored as a list of pointers, and re-
>> definitions are simply appended to the dictionary without going back
>> through the rest of it to update any pointers to the prior definition.
>> A strange design choice, but they're consistent with it.
>
> I don't know at all whether Forth does this or not, but this design
> choice allows the list to be restored to a prior state, whereby the
> recent definitions are forgotten, and the old ones revealed again,
> similarly to shadowed lexicals being revealed again upon the terminaton
> of an inner scope.
>

I suppose it also makes it a great deal easier to have small local
functions. Forth programming, as I understand it (I've only done very
small tests in Forth - I've never written a "real" program) generally
involves breaking code down into very small pieces. So your
implementation of "foo" might involve defining words like "get_next",
"double", "set_x", or whatever. (In Forth style these would probably be
shorter names, and perhaps include symbols.) Your implementation of
"bar" might want to re-use these same names but with different
definitions. With the list of pointers design of Forth, you can just
redefine these "local" words as you need to, and ignore any previous
definitions.

> It sounds reminiscent of the assoc list representation of the lexical
> environment in a rudimentary Lisp interpreter.
>

On Thu, 18 Apr 2024 10:30:49 +0200, David Brown wrote:

> With the list of pointers design of Forth, you can just
> redefine these "local" words as you need to, and ignore any previous
> definitions.

So, they reinvented local variables, and thought it was some great
innovation ...

On 18/04/2024 10:36, Lawrence D'Oliveiro wrote:
> On Thu, 18 Apr 2024 10:30:49 +0200, David Brown wrote:
>
>> With the list of pointers design of Forth, you can just
>> redefine these "local" words as you need to, and ignore any previous
>> definitions.
>
> So, they reinvented local variables, and thought it was some great
> innovation ...

"word" in Forth terminology is more like "function" in common imperative
languages. (It is not exactly the same, since Forth "words" are much
more flexible - that is both a good thing and a bad thing.)

On 18/04/2024 10:31, David Brown wrote:
> On 18/04/2024 10:36, Lawrence D'Oliveiro wrote:
>> On Thu, 18 Apr 2024 10:30:49 +0200, David Brown wrote:
>>
>>> With the list of pointers design of Forth, you can just
>>> redefine these "local" words as you need to, and ignore any previous
>>> definitions.
>>
>> So, they reinvented local variables, and thought it was some great
>> innovation ...
>
> "word" in Forth terminology is more like "function" in common imperative
> languages.  (It is not exactly the same, since Forth "words" are much
> more flexible - that is both a good thing and a bad thing.)
>

Why not include c.l.forth?

In article <v08bu7$1kl1e$1@dont-email.me>,
Richard Harnden <richard.harnden@invalid.com> wrote:
>On 18/04/2024 10:31, David Brown wrote:
>> On 18/04/2024 10:36, Lawrence D'Oliveiro wrote:
>>> On Thu, 18 Apr 2024 10:30:49 +0200, David Brown wrote:
>>>
>>>> With the list of pointers design of Forth, you can just
>>>> redefine these "local" words as you need to, and ignore any previous
>>>> definitions.
>>>
>>> So, they reinvented local variables, and thought it was some great
>>> innovation ...
>>
>> "word" in Forth terminology is more like "function" in common imperative
>> languages. (It is not exactly the same, since Forth "words" are much
>> more flexible - that is both a good thing and a bad thing.)
>>
>
>Why not include c.l.forth?
>

And maybe change the Subject title?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/RepInsults

On 23/04/2024 15:09, Richard Harnden wrote:
> On 18/04/2024 10:31, David Brown wrote:
>> On 18/04/2024 10:36, Lawrence D'Oliveiro wrote:
>>> On Thu, 18 Apr 2024 10:30:49 +0200, David Brown wrote:
>>>
>>>> With the list of pointers design of Forth, you can just
>>>> redefine these "local" words as you need to, and ignore any previous
>>>> definitions.
>>>
>>> So, they reinvented local variables, and thought it was some great
>>> innovation ...
>>
>> "word" in Forth terminology is more like "function" in common
>> imperative languages.  (It is not exactly the same, since Forth
>> "words" are much more flexible - that is both a good thing and a bad
>> thing.)
>>
>
> Why not include c.l.forth?
>

Sure - if you would like to continue in this line, then you could bring
in some experts. I have no idea how popular c.l.forth is, or how much
more you'd learn from them that you wouldn't get from others here such
as John Ames.

For my own part, I think Forth is interesting to know about, but it's
not a language I am likely to use, and I've learned a little more now
(thanks to John), and I am satisfied. But if you or others want more
depth, it probably makes more sense to drop the "comp.unix" groups and
add "comp.lang.forth", and - as Kenny suggests - change the subject.
(Or even just start a new thread!)

On Wed, 24 Apr 2024 10:04:56 +0200
David Brown <david.brown@hesbynett.no> wrote:

> Sure - if you would like to continue in this line, then you could
> bring in some experts. I have no idea how popular c.l.forth is, or
> how much more you'd learn from them that you wouldn't get from others
> here such as John Ames.

Well, I'm certainly no expert myself (just someone who runs into a lot
of Forth enthusiasts in other communities,) and c.l.forth seems fairly
active; I s'pose the question is more whether anyone has things left to
discuss along this thread...