Re: Operator overloading?

minforth@gmx.net (minforth) writes:

On Sat, 27 Jul 2024 15:35:55 +0000, Anton Ertl wrote:

minforth@gmx.net (minforth) writes:

[[: ;]] define closures, but unlike gforth's more flexible
flat closures, they capture simply all upvalues (here local a).

>
Gforth's flag closures can be considered lower-level (they come out of
implementation ideas in the Scheme community) and are easier to
implement, but emulating closures that capture outer locals is more
cumbersome.

>
In MF36 quotations already have read/write access to the locals of the
parent function. So closures became a simple by-product through
capturing
the parent's locals stack and injecting it at startup during closure
runtime. When the closure finishes, the captured stack is simply
updated.
>
I don't know if this would be good enough for a Lisp/Scheme programmer,
but it works for my needs. And look Ma, no garbage collection. :-)

But then, with

| : INIT { a }
|   [[: a ;]] \ read counter
|   [[: 1 +to a ;]] ; \ increment counter
| DEFER count IS count
| DEFER read IS read
| 5 INIT
| COUNT COUNT READ -> should give 7

is A not gone after INIT is finished, and COUNT and READ will do ...
interesting things?

One other aspect is that in Gforth's closures the
programmer decides whether closures are allocated in the dictionary,
on the locals stack, on the heap, or elsewhere.

>
In MF36 it is only the locals stack. AFAIU in other programming
languagues there are closures where the parent function can be seen as
constructor. IOW call the parent function twice and you get different
xts/addresses. From this perspective MF36 closures would perhaps only
qualify as 'half-closures'.

Your description sounds like MF36 can do downwards funargs (like
Pascal), but not upward funargs.

This raises the question of why you want to use closures for this
task.  Why not use one of the object-oriented Forth packages, some of
which support value-flavoured fields (Mini-OOF2 among them AFAIK).

>
MF36 VALUEs and LOCALs are already built with method VTs. TO et al
just call the method in the correct method slot.

Sure, but the point here is how to define an INIT that initializes
some data, and then you can call COUNT and READ on it, possibly with
different INITs for different types.  And you don't want to give names
to all the things that are produced by INIT.  That sounds like a job
for an object-oriented package.

- 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 2024: https://euro.theforth.net