Path: ...!fu-berlin.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: quotations (was: Back & Forth - Co-routines)
Date: Sat, 08 Feb 2025 11:41:32 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 191
Message-ID: <2025Feb8.124132@mips.complang.tuwien.ac.at>
References: <nnd$2fb29a8e$298ef3f8@23fe4f00fa62d734> <vnq10p$162l3$1@dont-email.me> <nnd$28e37865$1ff3c947@ec3118cc4d5fd42b> <874j1aycdt.fsf@nightsong.com> <nnd$68d49e22$0e1b270a@ce4705a037955a82> <3c3bdb056696f15c43fa512b5366002d@www.novabbs.com> <2025Feb6.135712@mips.complang.tuwien.ac.at> <3955434636b2a293c6a9c6d726ff6eae@www.novabbs.com> <ad7048513cca2117bb04396db85ef6196a257605@i2pn2.org> <2025Feb6.182051@mips.complang.tuwien.ac.at> <246bf746dbd7827c3e6edf3027f51ef8c416c39d@i2pn2.org>
Injection-Date: Sat, 08 Feb 2025 13:34:27 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2c90fdc368a2af26c94e5211bb5d26be";
	logging-data="65979"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19qMtZFq1Al2ug0uXnzrp83"
Cancel-Lock: sha1:dPi3Ldqx7pQKxapCDsY+Hc3ybdc=
X-newsreader: xrn 10.11
Bytes: 8211

dxf <dxforth@gmail.com> writes:
>On 7/02/2025 4:20 am, Anton Ertl wrote:
>> dxf <dxforth@gmail.com> writes:
>>> On 7/02/2025 12:59 am, minforth wrote:
>>>> On Thu, 6 Feb 2025 12:57:12 +0000, Anton Ertl wrote:
>>> AFAIR 200x nested definitions were justified on the grounds named
>>> definitions were neither needed nor wanted
>> 
>> Really?  There's a proposal to eliminate named definitions?  That's
>> news to me.
>
>I didn't but clearly those that argued for quotations did.

They did what?  Make a proposal for eliminating named definitions?
Where can I find that proposal?  I was one of the proposers of
quotations, so I certainly argued for them, and I am completely
unaware of a proposal like you claim, neither from me, nor Alex
McDonald (the first proposer of quotations), nor of anybody else
arguing for quotations.  Please present evidence of such a proposal.

>There's a case for having NONAME: which has no name and must pass an xt.

Let's look at an example from the proposal:

: hex. ( u -- )
  base @ >r
  [: hex u. ;] catch
  r> base ! throw ;

There is no good way for replacing the quotation here with NONAME:, so
NONAME: is a red herring.

>But that's not the same as saying there's a need for definitions without
>names.

"There's a need for definitions without names" is something completely
different than "named definitions were neither needed nor wanted".

And certainly :NONAME is there because there is a use for colon
definitions without names.  Whether these uses constitute needs is the
question; they often can be replaced relatively easily by using named
definitions.  That's also the case for quotations.  One could replace
the definition above with:

: hex.-helper ( u -- )
  hex u. ;

: hex. ( u -- )
  base @ >r
  ['] hex.-helper catch
  r> base ! throw ;

But would the result be easier to read, write, understand, or consume
fewer resources?  No.

>This only strengthened my view forth quotations had nothing to offer but
>namelessness.

They also offer nesting.

>If want to hide names of definitions I no longer need to
>reference I have BEHEAD for that.

Let's see if this is ang better:

| : hex.-helper ( u -- )
  hex u. ;

: hex. ( u -- )
  base @ >r
  ['] hex.-helper catch
  r> base ! throw ;

Not at all.

>Interesting but what are you saying - that quotations as we have them
>are little more than a gimmick?

Let's see what that means; according to
<https://en.wikipedia.org/wiki/Gimmick>:

|A gimmick is a novel device or idea designed primarily to attract
|attention or increase appeal, often with little intrinsic value.[1][2]
|When applied to retail marketing, it is a unique or quirky feature
|designed to make a product or service "stand out" from its
|competitors.

It is certainly intended to increase the appeal, but not primarily.
It's not a unique or quirky feature, many other languages have nested
nameless definitions.

And Forth has had them too, and some posters love to present the use
of return-stack manipulations to turn code pieces into nameless
definitions that are then called in another context, without any
protest from you.  I think Hans Bezemer does it in the video that he
advertised in the start of this thread (at least that's what the gist
of the discussion here seems to indicate; I usually don't watch
videos).  One example is from the quotations proposal:

: foo bar list> bla blub ;

where the part after LIST> is a separate definition that is called
once for every element in the list.  There is even such a word in
standard Forth (since Forth-79):

: D A does> B ;

Here the "B ;" is a separate definition (it's even specified that way
in Forth-94 f.) that is called whenever another word C to which the
DOES> has been applied is called.

The LIST>-like definition splitting has several disadvantages:

1) It's not obvious when reading the code that some arbitrary word
   splits a definition in that way.

2) There is no way to continue the original definition after the
   LIST>-like word.  E.g., the proposal contains the example

  : dofield ( -- )
  does> ( name execution: addr1 -- addr2 )
      @ + ;
  
  : dozerofield ( -- )
      immediate
  does> ( name execution: -- )
      drop ;
  
  : field ( align1 offset1 align size "name" --  align2 offset2 )
      \ name execution: addr1 -- addr2
      2 pick >r \ this uglyness is just for optimizing with dozerofield
      create-field
      r> if \ offset<>0
        dofield
      else
        dozerofield
      then ;

   Here the need for the separate words DOFIELD and DOZEROFIELD comes
   from the fact that there is no standard way to return to the
   original definition after the DOES>.  The quotations proposal
   <http://www.forth200x.org/quotations.txt> contains a variant that
   encloses DOES> in quotations, but I find it even nicer to use
   SET-DOES> which takes an xt and makes C (the defined word) execute
   the xt.  With that the example becomes:

  : field ( align1 offset1 align size "name" --  align2 offset2 )
      \ name execution: addr1 -- addr2
      2 pick >r \ this uglyness is just for optimizing with dozerofield
      create-field
      r> if \ offset<>0
        [: @ + ;] set-does>
      else
        immediate ['] drop set-does>
      then ;

3) LIST> and similar words are implemented using return-address
   manipulation, which has problems with inlining and tail-call
   elimination.  Either you do not implement inlining and tail-call
   elimination, or implement them only in a restricted way (incurring
   complications for determining whether you can use them), or you
   replace the use of LIST> with ways that do not use return-address
   manipulations.

Users could have written the FOO example above as

: foo-helper bla blub ;

: foo bar ['] foo-helper map-list ;

since at least Forth-83, but apparently they found the need for an
out-of-line definition repulsing enough that they accepted the
disadvantages of going for LIST>.  With quotations, they can write
the helper inline without the disadvantages:

: foo bar [: bla blub ;] map-list ;

And we certainly have a lot of uses of [: in Gforth.

If you prefer to program without quotations, that's fine.  If you
don't want to implement them in your system, your system can still
be standard (if you care about that); quotations are optional.  But
I usually don't brake for deprived systems when I program.

========== REMAINDER OF ARTICLE TRUNCATED ==========