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/
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)