quotations (was: Back & Forth - Co-routines)

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.

- 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: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/