minforth <minforth@arcor.de> writes:
>But I am still struggling with finding good applications

Don't struggle! If the need does not come to you on its own, you
don't need them.

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

Anton Ertl schrieb am Freitag, 7. April 2023 um 14:17:54 UTC+2:
> minforth <minf...@arcor.de> writes:
> >But I am still struggling with finding good applications
> Don't struggle! If the need does not come to you on its own, you
> don't need them.

That zero investment so far suits me well. ;-)

"Look, Ma, I have a clever solution! All I need now is a nice problem!"

On Friday, April 7, 2023 at 8:08:15 AM UTC-5, minforth wrote:
> Anton Ertl schrieb am Freitag, 7. April 2023 um 14:17:54 UTC+2:
> > minforth <minf...@arcor.de> writes:
> > >But I am still struggling with finding good applications
> > Don't struggle! If the need does not come to you on its own, you
> > don't need them.
> That zero investment so far suits me well. ;-)
>
> "Look, Ma, I have a clever solution! All I need now is a nice problem!"

The application for closures/partial application/whatever you want
to call it in Forth that I have had is if I want to associate an address
of a data structure or an ID associated with a peripheral with a handler
word (e.g. an interrupt handler) without hard-coding it within the handler
(case in point, what if you have a word for handling multiple different
peripherals, each with their own IRQ?). Before I added support for
closures/partial application/etc. what I had to do was to manually write
words that hard-code the associated data and then call the actual
handler; if I ever revisit that code I will change it to use closures/partial
application/etc.

Travis

Travis Bemann schrieb am Freitag, 7. April 2023 um 18:38:07 UTC+2:
> On Friday, April 7, 2023 at 8:08:15 AM UTC-5, minforth wrote:
> > Anton Ertl schrieb am Freitag, 7. April 2023 um 14:17:54 UTC+2:
> > > minforth <minf...@arcor.de> writes:
> > > >But I am still struggling with finding good applications
> > > Don't struggle! If the need does not come to you on its own, you
> > > don't need them.
> > That zero investment so far suits me well. ;-)
> >
> > "Look, Ma, I have a clever solution! All I need now is a nice problem!"
> The application for closures/partial application/whatever you want
> to call it in Forth that I have had is if I want to associate an address
> of a data structure or an ID associated with a peripheral with a handler
> word (e.g. an interrupt handler) without hard-coding it within the handler
> (case in point, what if you have a word for handling multiple different
> peripherals, each with their own IRQ?). Before I added support for
> closures/partial application/etc. what I had to do was to manually write
> words that hard-code the associated data and then call the actual
> handler; if I ever revisit that code I will change it to use closures/partial
> application/etc.
I think lots of applications for closures comprise some capturing of context
(data) and using that captured context later. Starting and stopping a task in
"my" world for example. Things one could also achieve with OO methods.

Although using closure xt's (aka anonymous functions) can make you code
rather concise. But can make it also read-only, unless there is a commonly
understood syntax.

On Friday, April 7, 2023 at 12:32:01 PM UTC-5, minforth wrote:
> Travis Bemann schrieb am Freitag, 7. April 2023 um 18:38:07 UTC+2:
> > On Friday, April 7, 2023 at 8:08:15 AM UTC-5, minforth wrote:
> > > Anton Ertl schrieb am Freitag, 7. April 2023 um 14:17:54 UTC+2:
> > > > minforth <minf...@arcor.de> writes:
> > > > >But I am still struggling with finding good applications
> > > > Don't struggle! If the need does not come to you on its own, you
> > > > don't need them.
> > > That zero investment so far suits me well. ;-)
> > >
> > > "Look, Ma, I have a clever solution! All I need now is a nice problem!"
> > The application for closures/partial application/whatever you want
> > to call it in Forth that I have had is if I want to associate an address
> > of a data structure or an ID associated with a peripheral with a handler
> > word (e.g. an interrupt handler) without hard-coding it within the handler
> > (case in point, what if you have a word for handling multiple different
> > peripherals, each with their own IRQ?). Before I added support for
> > closures/partial application/etc. what I had to do was to manually write
> > words that hard-code the associated data and then call the actual
> > handler; if I ever revisit that code I will change it to use closures/partial
> > application/etc.
> I think lots of applications for closures comprise some capturing of context
> (data) and using that captured context later. Starting and stopping a task in
> "my" world for example. Things one could also achieve with OO methods.
>
> Although using closure xt's (aka anonymous functions) can make you code
> rather concise. But can make it also read-only, unless there is a commonly
> understood syntax.

The unfortunate thing about using closures/partial application in zeptoforth
is that it can be rather cumbersome. For starters, you have to allot/allocate
storage for them which will remain available when they are actually called.

In the case of downwards funargs the most expedient approach is to use
WITH-ALIGNED-ALLOT at the moment. However, now that I think of it,
because this is a common use-case, I could create the following words:

WITH-CLOSURE ( x bound-xt passed-xt -- )
WITH-2CLOSURE ( d bound-xt passed-xt -- )
WITH-NCLOSURE ( xn ... x0 count bound-xt passed-xt -- )

where a closure is created temporarily in the dictionary which passes
x, d, or xn ... x0 on the data stack and then calls bound-xt when called and
is placed on the data stack and is valid for the scope of passed-xt, which
is then called. These would be more convenient than the current way of
doing things.

In the case of upwards funargs other approaches would be necessary, which
would be more inconvenient. The main approach would be to plan out all the
upwards funargs one would need, and pre-allot/allocate space for them;
e.g. if one had a closure which bound the address to a data structure, a
convenient place to put the closure would be in the data structure itself.

Travis

Travis Bemann schrieb am Freitag, 7. April 2023 um 21:38:17 UTC+2:
> The unfortunate thing about using closures/partial application in zeptoforth
> is that it can be rather cumbersome. For starters, you have to allot/allocate
> storage for them which will remain available when they are actually called.

IOW a closure is a data instance of upvalues with an anonymous function.
If you don't want garbage collection, you could hide a destructor within the
function. But then, why not use OO in the first place?

On Friday, April 7, 2023 at 3:39:35 PM UTC-5, minforth wrote:
> Travis Bemann schrieb am Freitag, 7. April 2023 um 21:38:17 UTC+2:
> > The unfortunate thing about using closures/partial application in zeptoforth
> > is that it can be rather cumbersome. For starters, you have to allot/allocate
> > storage for them which will remain available when they are actually called.
> IOW a closure is a data instance of upvalues with an anonymous function.
> If you don't want garbage collection, you could hide a destructor within the
> function. But then, why not use OO in the first place?

With OO (which zeptoforth supports) the obvious approach is to make the
closure a member in the object which it passes to the handler itself, so it has
the same lifetime as said object itself. Even if one is not using the OO layer
per se, the same goes for storing a closure in a structure which it itself binds.
This is less flexible, however, than the garbage-collected closure approach
that is perennial in the functional programming world, which uses closures
far more pervasively. Garbage collection, though, is not an option in
zeptoforth as it is designed for embedded control; while zeptoforth does
have support for heaps, even heaps are completely optional, having to be
deliberately constructed by the user (and also there is no "the heap" - heaps
are just another data structure, so the user can be more than one of them),
the only heap that is supported "out of the box" is a small one used for
storing history for the line editor. Yes, the likes of MicroPython and eLua
use garbage-collected heaps, these hurt their real-time characteristics,
and make them unsuitable for actual real-time operation.

Travis

On Friday, April 7, 2023 at 4:52:32 PM UTC-5, Travis Bemann wrote:
> On Friday, April 7, 2023 at 3:39:35 PM UTC-5, minforth wrote:
> > Travis Bemann schrieb am Freitag, 7. April 2023 um 21:38:17 UTC+2:
> > > The unfortunate thing about using closures/partial application in zeptoforth
> > > is that it can be rather cumbersome. For starters, you have to allot/allocate
> > > storage for them which will remain available when they are actually called.
> > IOW a closure is a data instance of upvalues with an anonymous function..
> > If you don't want garbage collection, you could hide a destructor within the
> > function. But then, why not use OO in the first place?
> With OO (which zeptoforth supports) the obvious approach is to make the
> closure a member in the object which it passes to the handler itself, so it has
> the same lifetime as said object itself. Even if one is not using the OO layer
> per se, the same goes for storing a closure in a structure which it itself binds.
> This is less flexible, however, than the garbage-collected closure approach
> that is perennial in the functional programming world, which uses closures
> far more pervasively. Garbage collection, though, is not an option in
> zeptoforth as it is designed for embedded control; while zeptoforth does
> have support for heaps, even heaps are completely optional, having to be
> deliberately constructed by the user (and also there is no "the heap" - heaps
> are just another data structure, so the user can be more than one of them),
> the only heap that is supported "out of the box" is a small one used for
> storing history for the line editor. Yes, the likes of MicroPython and eLua
> use garbage-collected heaps, these hurt their real-time characteristics,
> and make them unsuitable for actual real-time operation.

Correction - the user can "have" more than one heap, not "be" more than one
heap. Also, there should be a "but" before "these hurt their real-time
characteristics".

Travis

Travis Bemann schrieb am Freitag, 7. April 2023 um 23:52:32 UTC+2:
> ... the likes of MicroPython and eLua
> use garbage-collected heaps, these hurt their real-time characteristics,
> and make them unsuitable for actual real-time operation.

muPython is rather flexible there:

https://docs.micropython.org/en/latest/library/gc.html

but it wouldn't be my choice either on slow hardware.

On 2023-04-07 11:20, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
[...]
>> As I already mentioned [1], this idea is actually the
>> conception of partial application, which is completely independent of
>> local variables.
>
> Or of currying; from the caller's perspective the difference is small
> <https://en.wikipedia.org/wiki/Currying#Contrast_with_partial_function_application>.

This difference depends on the language. E.g., in Haskell it's small,
since "f(a,b,c)" is equivalent to "f(a)(b)(c)".

In Forth the difference is significant.

Partial application itself fixes n parameters *at once* for a function.
But currying produces a function that fixes n parameters in n *steps*.

The process of implementing them brings better understanding.

Let the word "pa1" partially applies xt to one parameter x. It can be
defined as:

: pa1 ( 1*x xt -- xt ) 2>r :noname r> r> lit, compile, postpone ; ;

Then "pa2", "pa3", "pa4" can be defined as follows:

: pa2 ( 2*x xt -- xt ) pa1 pa1 ;
: pa3 ( 3*x xt -- xt ) pa2 pa1 ;
: pa4 ( 4*x xt -- xt ) pa3 pa1 ;

NB: identical data type identifiers (without indices) in a stack diagram
don't mean identical parameters.

Test cases:

: noop ; : 'noop ['] noop ;
: se ( i*x xt x -- j*x ) swap execute ;

t{ 1 'noop pa1 10 se -> 10 1 }t
t{ 2 1 'noop pa2 10 se -> 10 2 1 }t
t{ 3 2 1 'noop pa3 10 se -> 10 3 2 1 }t

The number 10 is placed on the stack just to test that the parameters
are correctly taken from the stack.

Curry (for particular number of fixed parameters) can be defined via
partial application as follows:

: cu0 ( xt -- xt ) ;
: cu1 ( xt -- xt ) ['] pa1 pa1 cu0 ;
: cu2 ( xt -- xt ) ['] pa2 pa1 cu1 ;
: cu3 ( xt -- xt ) ['] pa3 pa1 cu2 ;
: cu4 ( xt -- xt ) ['] pa4 pa1 cu3 ;

Each of this word cu{n} produces a definition that fixes n parameters in
n steps.
Test cases:

t{ 'noop cu1 1 se 10 se -> 10 1 }t
t{ 'noop cu2 1 se 2 se 10 se -> 10 2 1 }t
t{ 'noop cu3 1 se 2 se 3 se 10 se -> 10 3 2 1 }t

NB: we apply "execute" n times to fix n parameters.

A definition of a word "ncu ( xt u.n -- xt )" that produces xt that
fixes arbitrary n parameters in n steps — is a puzzle for the reader (I
already posted a solution with its proof in 2018).

Partial application can be also defined via curry as follows:

synonym e execute

: pa1 ( 1*x xt -- xt ) cu1 e ;
: pa2 ( 2*x xt -- xt ) cu2 e e ;
: pa3 ( 3*x xt -- xt ) cu3 e e e ;
: pa4 ( 4*x xt -- xt ) cu4 e e e e ;

From the information theory point of view, partial application is a
reduction, since the produced function "contains" less information than
the original one. But currying is a lossless transformation — the
produced function "contains" as much information as the original one.

> Plus, I had not known the term before, although it sounded familiar:
> <https://en.wikipedia.org/wiki/Partial_application> starts by saying:
>
> |Not to be confused with partial evaluation
>
> and so I found out that I was thinking about "partial evaluation" when
> you wrote "partial application".

Oh, I see. Moreover, partial evaluation is a specific case of partial
application, I think. And partial application can contain partial
evaluation under the hood, but it's not necessary.

[...]

--
Ruvim

On 2023-04-07 11:20, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2023-04-05 07:33, Anton Ertl wrote:
>>> We would have missed this idea if we had rejected everything
>>> to do with locals from the start.
>>
>> I cannot agree.
>
> You were not involved.

Yes, sorry I wasn't.

Well, I awkwardly expressed my thought. I wanted to say, you probably
would eventually come to this idea as the conception of partial
application anyway (independently of local variables).

[...]

>> — A closure (a lexical closure) is created by binding *named* objects
>>from the lexical environment.
>
> In Forth we do not have a lexical environment.

Sure, we have. Formally, it depends on particular definition of
"lexical environment" term.

Intuitively, lexical environment is a set of information that is used to
recognize lexemes (or, on which recognizing of lexemes depends on).

> So we use the term
> "closure" to refer to the thing that is used for the purposes that
> closures are used for in languages that have a lexical environment.
> You may prefer to call it a "partially-applied colon definition", but
> "closure" has the advantage of being much shorter.

"colon definition" is an informal notion.

Formally, we have "Forth definition" (not necessary a colon definition,
and even not necessary a named definition), that is often abbreviated to
just "definition", when it's clear from the context that we talk about a
Forth definition.

BTW, the notion of "anonymous definition" in Forth and "anonymous
function" in other programming languages mean the same, I think. Then,
*ordinary* named definitions in Forth and named functions in other
languages also mean the same.

Therefore, it's pretty clear what "partially applied function" means in
the context of Forth.

Concerning "execution" — it corresponds better not to "function
application", but to "function evaluation" (in mathematical sense). Then
I was wrong in my previous message that "partial evaluation is a
specific case of partial application".

Well, if we call a partially applied definition "closure", how we will
call a real closure (which binds lexical environment including local
variables)?

>> So a problem is how to create a partially applied function dynamically,
>> and how to free resources of an already unneeded function
>
> It's pretty straightforward using "carnal knowledge", and as you
> demonstrate, pretty messy if you want to use currently standard means;
> so I think the better question is: What is missing from standard
> Forth?

> Is there something that is currently "carnal knowledge", but
> should be standardized, or should we standardize nothing at a lower
> level, and intead standardize the partial application word. (Probably
> at the present time the answer is that there is not enough common
> practice to standardize anything, but let's assume that at some point
> this will change.)

I think, we need them all — some things on a lower level and some things
on a higher level.

For example, there is a general need for dynamic compilation, execution
of the resulting definitions, and then freeing them (freeing the
resources that were taken doing compilation).

And such means can be used to implement partial application too.

In the same time we can consider words like:

1apply ( x xt -- xt )
napply ( i*x u.i xt -- xt )
1fapply ( xt -- xt ) ( F: r -- )
nfapply ( u.i xt -- xt ) ( F: i*r -- )
free-definition ( xt -- )
\ it may throw an exception if xt
\ is not from the "apply" family words
\ or was already freed.

--
Ruvim

On 2023-04-07 11:20, Anton Ertl wrote:
[...]

> So we use the term
> "closure" to refer to the thing that is used for the purposes that
> closures are used for in languages that have a lexical environment.

In general, it's a bad argument.

If different tools are used for the same purpose, it doesn't mean that
each of this tools should be called by the same name, just because they
all occasionally are used for the same purpose.

--
Ruvim

Ruvim schrieb am Samstag, 8. April 2023 um 17:07:36 UTC+2:
> On 2023-04-07 11:20, Anton Ertl wrote:

> > In Forth we do not have a lexical environment.
> Sure, we have. Formally, it depends on particular definition of
> "lexical environment" term.
>
> Intuitively, lexical environment is a set of information that is used to
> recognize lexemes (or, on which recognizing of lexemes depends on).

I use a header cell containing the FNV1a hash-value of the word's/local's name.
This accelerates recognizing/searching for words/locals significantly.

Target overlays/binaries do not contain plain-text names but the hash values.
With this information "lexemes" can be recognized nevertheless.

On 2023-04-07 11:51, Anton Ertl wrote:
[...]

>> Without local variables in general, or without *ability* to bind the
>> outer local variables, closures are trivial. I'm not sure it's still
>> correct to call such functions "closures". Therefor, in Factor, Joy,
>> Cat, Forth, such functions are intentionally called "quotations".
>>
>> If we don't call quotations "closures", then we rather shouldn't call
>> partially applied functions "closures" too.
>
> That does not follow. Quotations neither are closures nor do they
> serve the purpose of closures.

Yes. But sometimes they can be used to solve a problem for which
closures are also used.

> What Gforth calls closures is intended
> to be used for the purpose that closures (as well as curried and
> partially-applied functions) are used for in Scheme; and if we have
>
> [n:d + ;]
>
> (what I call a pure-stack closure), it's not a partially-applied (or
> partially-EXECUTEd?) colon definition, because no partial
> application/execution has happened, and it's not a colon definition.

Partial application happens when a new xt is returned by this construct.

The construct

[n:d + ;]

is actually a sugar over

[: + ;] partial1

Where "partial1 ( x1 xt1 -- xt )" performs partial application.

> It might be called a curried quotation if you are unhappy with
> "closure", but I am happy with "closure" (but a also call the
> resulting xt the xt of a closure, so I am quite loose in terminology
> here.
>
>> Also, if the outer local variables are not bound in a function, it's
>> probably confusing if this function would be called "closure".
>
> About as confusing as calling a colon definition a "function".
>
>> Well, if we still want to call partially applied functions "closures",
>> they shouldn't be "lexical closures", but some other kind of closures.
>
> "Flat closure" or "Gforth closure" is fine with me.
>
>> And "pure-stack closures" is not well suited either, I think.
>
> "Pure-stack" contrasts with the closures that have locals on the
> inside:
>
> pure-stack closure: [n:d + ;]
> other Gforth closure: [{: n :}d n + ;]

Closures that are created in the same lexical environment, share the
same external variables (their state).

For example, see in JavaScript:

x = (function (){
var a ; a = 0;
return [ ()=>{ a+=1; return a}, ()=>{ a+=10; return a} ]
})();

x[0]() // "1"
x[1]() // "11"
x[0]() // "12"
x[0]() // "13"
x[1]() // "23"

Gforth "closures" does not provide this functionality. Because actually
they are partially applied functions (partially applied definitions, if
you like), which are defined in special syntax.

--
Ruvim

Ruvim schrieb am Montag, 10. April 2023 um 15:37:50 UTC+2:
> Closures that are created in the same lexical environment, share the
> same external variables (their state).
>
> For example, see in JavaScript:
>
> x = (function (){
> var a ; a = 0;
> return [ ()=>{ a+=1; return a}, ()=>{ a+=10; return a} ]
> })();
>
> x[0]() // "1"
> x[1]() // "11"
> x[0]() // "12"
> x[0]() // "13"
> x[1]() // "23"
>
>
> Gforth "closures" does not provide this functionality. Because actually
> they are partially applied functions (partially applied definitions, if
> you like), which are defined in special syntax.

"Sharing" external free variables, or getting an independent copy of them
(the lexical environment) at time of closure creation means a huge difference.
Each somewhat functional language seems to have cooked its own recipe
for closures, and IMO Javascript has overdone it here.

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2023-04-07 11:51, Anton Ertl wrote:
>> What Gforth calls closures is intended
>> to be used for the purpose that closures (as well as curried and
>> partially-applied functions) are used for in Scheme; and if we have
>>
>> [n:d + ;]
>>
>> (what I call a pure-stack closure), it's not a partially-applied (or
>> partially-EXECUTEd?) colon definition, because no partial
>> application/execution has happened, and it's not a colon definition.
>
>Partial application happens when a new xt is returned by this construct.

Yes. So the construct itself can be called a curried definition, or a
definition with two-stage parameter passing.

>The construct
>
> [n:d + ;]
>
>is actually a sugar over
>
> [: + ;] partial1
>
>Where "partial1 ( x1 xt1 -- xt )" performs partial application.

Except that we don't have PARTIAL1.

>Closures that are created in the same lexical environment, share the
>same external variables (their state).
>
>For example, see in JavaScript:
>
>x = (function (){
> var a ; a = 0;
> return [ ()=>{ a+=1; return a}, ()=>{ a+=10; return a} ]
>})();
>
>x[0]() // "1"
>x[1]() // "11"
>x[0]() // "12"
>x[0]() // "13"
>x[1]() // "23"

>Gforth "closures" does not provide this functionality.

[: ( -- addr )
align here >r 0 ,
here
r@ [n:h 1 over +! @ ;] ,
r> [n:h 10 over +! @ ;] ,
;] execute constant x

x @ execute . \ 1
x cell+ @ execute . \ 11
x @ execute . \ 12
x @ execute . \ 13
x cell+ @ execute . \ 23

Here I used assignment conversion, which has been described by Dybvig
in the Scheme literature in 1987. Each invocation of the quotation
produces a new instance of the variable in the dictionary with ",",
and the address of this variable is then passed to the two closures,
both of which then access the same variable. Section 5 of
<http://www.euroforth.org/ef18/papers/ertl.pdf> describes the
application of assignment conversion to Forth. The closures are
allocated on the heap here, to make the allocation of the array in the
dictionary convenient.

The code above uses only stack stuff. A highly locals-oriented
version is:

[: ( -- addr )
0 <{: w^ a :}d a ;> drop {: a :}
here
a [{: a :}h 1 a +! a @ ;] ,
a [{: a :}h 10 a +! a @ ;] ,
;] execute constant x

x @ execute .
x cell+ @ execute .
x @ execute .
x @ execute .
x cell+ @ execute .

Here the <{: ... ;> syntax is used for producing home locations for
variables that you need to share, because they are changed. It
provides a common syntax for doing this for the different allocation
methods; of coures for each allocation method you can do it with
conventional means, but the syntax for the different allocation
methods is quite different.

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

minforth <minforth@arcor.de> writes:
>Ruvim schrieb am Montag, 10. April 2023 um 15:37:50 UTC+2:
>> Closures that are created in the same lexical environment, share the
>> same external variables (their state).
>>
>> For example, see in JavaScript:
>>
>> x = (function (){
>> var a ; a = 0;
>> return [ ()=>{ a+=1; return a}, ()=>{ a+=10; return a} ]
>> })();
>>
>> x[0]() // "1"
>> x[1]() // "11"
>> x[0]() // "12"
>> x[0]() // "13"
>> x[1]() // "23"
>>
>>
>> Gforth "closures" does not provide this functionality. Because actually
>> they are partially applied functions (partially applied definitions, if
>> you like), which are defined in special syntax.
>
>"Sharing" external free variables, or getting an independent copy of them
>(the lexical environment) at time of closure creation means a huge difference.
>Each somewhat functional language seems to have cooked its own recipe
>for closures, and IMO Javascript has overdone it here.

This kind of sharing is an old concept already present in Algol 60,
exercised in the Man-or-Boy test (in the variables k and B) and in
Jensen's device; and of course you can use it in Scheme. It's not
needed in pure functional languages, because they don't change the
values of variables; so you can just replicate the value, no need to
worry about another user getting a stale value.

While (some) Scheme compilers use assignment conversion as a compiler
technique, we decided to leave this job to the programmer in order to
simplify the implementation of closures. I think that this is the
right choice:

* The need for assignment conversion rare; I think we have only used
it for proof-of-concept examples yet. So leaving it to the
programmer is not very burdensome.

* It makes the costs of things much more obvious. In the original
(Algol 60) man-or-boy program it's not obvious that k has this extra
cost, while in the Forth version it is quite easy to see.

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

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>[: ( -- addr )
> 0 <{: w^ a :}d a ;> drop {: a :}
> here
> a [{: a :}h 1 a +! a @ ;] ,
> a [{: a :}h 10 a +! a @ ;] ,
>;] execute constant x

There are 4 definitions of a local A here, each within its own scope,
but still humans may find it hard to see which use of A refers to
which definition. So I have varied this so that each local gets a
unique name:

[: ( -- addr )
0 <{: w^ a1 :}d a1 ;> drop {: a2 :}
here
a2 [{: a3 :}h 1 a3 +! a3 @ ;] ,
a2 [{: a4 :}h 10 a4 +! a4 @ ;] ,
;] execute constant x

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

On 2023-04-07 11:20, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
[...]
>> So a problem is how to create a partially applied function dynamically,
>> and how to free resources of an already unneeded function
>
> It's pretty straightforward using "carnal knowledge", and as you
> demonstrate, pretty messy if you want to use currently standard means;

I have implemented this idea as a PoC (a proof of concept prototype)
[1]. It took about 50 lines of code.

Since in Standard Forth we cannot create a new xt (new definition) in
any particular moment, and cannot remove a particular definition, I
create a pool of definitions (a pool of thunks [2]) in advance, which
can be reused many times.

This implementation is not quite efficient — I use only cons-based
dynamic lists. A more efficient way is to use a stack to store the pool
of idle items (which are available for hiring), and use a hash-table to
get the data address from a thunk xt (or use create-does and ">body",
but then I have to provide a dummy name for each definition in the pool).

The cons-based cells and lists is a very easy tool for prototyping. It's
provide simple memory management, and I even don't need to create usual
data structures.

Also, the linking between an xt and the corresponding data field is a
useful thing by itself (without connection to a named definitions).

What about a word like "bind-here ( xt1 -- xt2 )", which partially
applies xt1 to the value of the data-space pointer? An important
requirement is that ">body" should be applicable to xt2.

Test cases:

t{ ' 2@ bind-here ( xt ) 1 , 2 , execute -> 2 1 }t
t{ [: dup . @ . ;] bind-here >body here = -> true }t

It's a more basic tool than "create-does", and it allows to better
optimize the code since the bound parameter cannot be changed (unlike in
create-does).

Another thing concerning dynamic partially applied functions
(definitions) is that if you create chains of such definitions, it's
cumbersome to manually release them.

Probably some helper tool would be useful to define a kind of domain,
and release all definitions (or resources in general) that are bound to
this domain.

[1]
https://github.com/ruv/puzzle-in-forth/blob/main/extension/partial-application.fth

[2] https://en.wikipedia.org/wiki/Thunk_(functional_programming)

--
Ruvim

Anton Ertl schrieb am Dienstag, 11. April 2023 um 10:32:56 UTC+2:
> minforth <minf...@arcor.de> writes:
> >Ruvim schrieb am Montag, 10. April 2023 um 15:37:50 UTC+2:
> >> Closures that are created in the same lexical environment, share the
> >> same external variables (their state).
> >>
> >> For example, see in JavaScript:
> >>
> >> x = (function (){
> >> var a ; a = 0;
> >> return [ ()=>{ a+=1; return a}, ()=>{ a+=10; return a} ]
> >> })();
> >>
> >> x[0]() // "1"
> >> x[1]() // "11"
> >> x[0]() // "12"
> >> x[0]() // "13"
> >> x[1]() // "23"
> >>
> >>
> >> Gforth "closures" does not provide this functionality. Because actually
> >> they are partially applied functions (partially applied definitions, if
> >> you like), which are defined in special syntax.
> >
> >"Sharing" external free variables, or getting an independent copy of them
> >(the lexical environment) at time of closure creation means a huge difference.
> >Each somewhat functional language seems to have cooked its own recipe
> >for closures, and IMO Javascript has overdone it here.
> This kind of sharing is an old concept already present in Algol 60,
> exercised in the Man-or-Boy test (in the variables k and B) and in
> Jensen's device; and of course you can use it in Scheme. It's not
> needed in pure functional languages, because they don't change the
> values of variables; so you can just replicate the value, no need to
> worry about another user getting a stale value.
>
> While (some) Scheme compilers use assignment conversion as a compiler
> technique, we decided to leave this job to the programmer in order to
> simplify the implementation of closures. I think that this is the
> right choice:
>
> * The need for assignment conversion rare; I think we have only used
> it for proof-of-concept examples yet. So leaving it to the
> programmer is not very burdensome.
>
> * It makes the costs of things much more obvious. In the original
> (Algol 60) man-or-boy program it's not obvious that k has this extra
> cost, while in the Forth version it is quite easy to see.

Thanks for your explanations! Really appreciated!

(repeated message due to a problem with delivery)
On 2023-04-11 06:54, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2023-04-07 11:51, Anton Ertl wrote:
>>> What Gforth calls closures is intended
>>> to be used for the purpose that closures (as well as curried and
>>> partially-applied functions) are used for in Scheme; and if we have
>>>
>>> [n:d + ;]
>>>
>>> (what I call a pure-stack closure), it's not a partially-applied (or
>>> partially-EXECUTEd?) colon definition, because no partial
>>> application/execution has happened, and it's not a colon definition.
>>
>> Partial application happens when a new xt is returned by this construct.
>
> Yes. So the construct itself can be called a curried definition, or a
> definition with two-stage parameter passing.

I like the variant "curried definition". My rationale: when it's
performed (i.e., at run-time), it creates a new definition using partial
application, and returns the corresponding xt — and it's similar to what
a curried function does.

The fragment:

[n:d + ;]

is equivalent to:

[: + ;] partial1

that is equivalent to:

[ [: + ;] curry1 compile, ]

that is equivalent to:

curried1(+)

where "curried1(+)" is defined as:

[: + ;] curry1 alias curried1(+)

Also, a curried function returns a partially applied function, and it
has nothing to do with lexical closures at all. And it's true for this
construct too (e.g. "[n:d + ;]").

>> The construct
>>
>> [n:d + ;]
>>
>> is actually a sugar over
>>
>> [: + ;] partial1
>>
>> Where "partial1 ( x1 xt1 -- xt )" performs partial application.
>
> Except that we don't have PARTIAL1.

Well, this construct is a sugar conceptually, and anyway, this construct
is equivalent to this code, regardless whether you have "partial1 (i.e.,
the implementation details don't matter).

>> Closures that are created in the same lexical environment, share the
>> same external variables (their state).
>>
>> For example, see in JavaScript:
>>
>> x = (function (){
>> var a ; a = 0;
>> return [ ()=>{ a+=1; return a}, ()=>{ a+=10; return a} ]
>> })();
>>
>> x[0]() // "1"
>> x[1]() // "11"
>> x[0]() // "12"
>> x[0]() // "13"
>> x[1]() // "23"
>
>> Gforth "closures" does not provide this functionality.
>
> [: ( -- addr )
> align here >r 0 ,
> here
> r@ [n:h 1 over +! @ ;] ,
> r> [n:h 10 over +! @ ;] ,
> ;] execute constant x
>
> x @ execute . \ 1
> x cell+ @ execute . \ 11
> x @ execute . \ 12
> x @ execute . \ 13
> x cell+ @ execute . \ 23

OK. My argument is not quite suitable. In your example the required
behavior is implemented without closures.

A closure is a function that *directly* (not by argument passing) refers
to identifiers defined in the environment in which the function is
defined, but not in the environment of the function call. If such a call
is not possible, the function is not a closure.

In a broad sense, even a function defined in a module is a closure over
the local identifiers of that module. In a narrow sense, a closure is a
nested function only (a function defined within another function) that
refers to identifiers defined in an enclosing function.

In the Forth terminology, a closure is an anonymous inner definition
that directly mention some names defined in some of enclosing definitions.

In your example, the inner definitions don't mention a *name* defined in
the containing definition. So, lexical closures are not involved.

> Here I used assignment conversion, which has been described by Dybvig
> in the Scheme literature in 1987.

Assignment conversion of a closure is one of possible ways to
*implement* supporting of closures in a language. Another way is
run-time code generation.

If you are forced to do closure conversion by hand, then the language
does not support closures.

> Each invocation of the quotation
> produces a new instance of the variable in the dictionary with ",",
> and the address of this variable is then passed to the two closures,
> both of which then access the same variable. Section 5 of
> <http://www.euroforth.org/ef18/papers/ertl.pdf> describes the
> application of assignment conversion to Forth.

| In most of the rest of this paper, closure
| refers to the data structure, and it’s
| Forth source code representation.

It looks like you consider only a back-end part to support closures in
Forth.

Without a front-end, — the ability to directly refer names defined in an
enclosing definition — I cannot say that closures are supported by a
language (in its syntax and semantics).

> The closures are
> allocated on the heap here, to make the allocation of the array in the
> dictionary convenient.
>
> The code above uses only stack stuff. A highly locals-oriented
> version is:
>
> [: ( -- addr )
> 0 <{: w^ a :}d a ;> drop {: a :}
> here
> a [{: a :}h 1 a +! a @ ;] ,
> a [{: a :}h 10 a +! a @ ;] ,
> ;] execute constant x

In this case too, no inner definition mentions a *name* defined in the
containing definition.

>
> x @ execute .
> x cell+ @ execute .
> x @ execute .
> x @ execute .
> x cell+ @ execute .
>
> Here the <{: ... ;> syntax is used for producing home locations for
> variables that you need to share, because they are changed. It
> provides a common syntax for doing this for the different allocation
> methods; of coures for each allocation method you can do it with
> conventional means, but the syntax for the different allocation
> methods is quite different.
>

--
Ruvim