Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-08-22 19:55, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-08-22 08:29, Anton Ertl wrote:
>>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>>> DOES ( xt -- )
>>>>
>>>> Already exists under the name SET-DOES> in Gforth.
>>>
>>> Yes, I see. I wonder whether it can be easily implemented in any Forth
>>> system that provides "does>".
>>
>> Not that I can see.
>
>I didn't mean in a standard way, but in some system specific way (using
>carnal knowledge).
>
>An inefficient straightforward implementation could be something like this:
>
> : does ( xt -- )
> >r :noname postpone does> r> compile, postpone ;
> get-current latest-name-in last !
> execute
> ;

And maybe change the section before and restore it afterwards. After
all, you want this to work:

: const ( n "name" -- )
create ['] @ does , ;

(and on many systems, DOES would put the noname definition between the
NAME header and the n deposited with ",").

Sure, system-specific implementations are possible and not
particularly hard. In Gforth we have replaced the original (dodoes)
routine (which performs a call to a threaded-code address) with one
that was originally called (dodoesxt) (which EXECUTEs an xt instead);
the latter has been renamed into (dodoes) after we removed the old
one. There is SET-DOES>, of course.

And there is an implementation of DOES> that is based on SET-DOES> and
quotations, and that's the most complicated part of the whole thing. Hmm, now I am wondering why we did not do it as follows:

: does>
lit compile, here >r 0 , postpone set-does> postpone ;
:noname lastxt r> ! ; immediate

Probably to support interpretive DOES>.

>>> Concerning compiling to flash, I don't see how it can be justified.
>>
>> There are lots of microcontrollers with lots of flash and little RAM.
>>
>>> AFAIK, a more often scenario is that you prepare one image that is
>>> written to many devices (and you don't have a compiler on each device).
>>
>> Not having a compiler is beyond the standard. In that case you can
>> also put restrictions on executions of DOES> (doing the standard thing
>> for DOES> won't bring you back under the standard umbrella).
>>
>>> But even if it's only one device, the approach with image seems to be
>>> more robust and more forward-thinking.
>>
>> What approach is that?
>
>I'm not an expert in this area. But just as far as I understand it.
>
>By the "approach with image" I meant that a Forth system compiles a
>program and prepares a completed image in RAM, and then this image is
>entirely written (by this Forth system, or by other means) into the
>flash memory, instead of incremental compiling the program into the
>flash memory at once.

I.e., the classical cross-compiling approach that C gives you, too.
This gets rid of a strength of Forth: Interactivity. Sure, you can
then have some text interpreter where you can type in commands, but
you no longer have full programmability at your fingertips; and every
time you want the slightest change to the program, you have to
terminate the session, recompile, and reflash, and start another
session, rather than, e.g., just adding a word and redirecting a hook
to use that word.

Gforth has such a cross compiler (and others, too, I guess), but we
only use it for bootstrapping (and others, too, I guess). For
experiencing the benefits of Forth, you need a proper Forth system,
either in the target (as, e.g., Mecrisp does), or distributed between
host and target (as the tethered/umbilical systems of commercial
vendors do).

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 2021-08-23 12:08, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-08-22 19:55, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>> On 2021-08-22 08:29, Anton Ertl wrote:
>>>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>>>> DOES ( xt -- )
>>>>>
>>>>> Already exists under the name SET-DOES> in Gforth.
>>>>
>>>> Yes, I see. I wonder whether it can be easily implemented in any Forth
>>>> system that provides "does>".
>>>
>>> Not that I can see.
>>
>> I didn't mean in a standard way, but in some system specific way (using
>> carnal knowledge).
>>
>> An inefficient straightforward implementation could be something like this:
>>
>> : does ( xt -- )
>> >r :noname postpone does> r> compile, postpone ;
>> get-current latest-name-in last !
>> execute
>> ;
>
> And maybe change the section before and restore it afterwards. After
> all, you want this to work:
>
> : const ( n "name" -- )
> create ['] @ does , ;
>
> (and on many systems, DOES would put the noname definition between the
> NAME header and the n deposited with ",").

Yes, it will break contiguity of the data field (if the system doesn't
support multiple sections/dictionaries, or "does" doesn't use it).

But according to my specification, it's allowed to do it: DOES may
allocate memory in data space. So, it's incorrect to perform DOES before
allocating the data filed.

A correct variant:

: const ( n "name" -- )
create , ['] @ does ;

So this "does" imposes some restrictions on programs that "does>"
doesn't impose (hence, without tightening the specification, it's
impossible to define the standard "does>" via this "does" in a standard
way).

OTOH, this "does" removes some other restrictions that "does>" imposes.

For example, the following should work:

create x 123 , [: ( addr -- ) @ . ;] does
x \ prints 123

Compared to "does>", this "does" has the following advantages: simpler
specification, easier comprehension, possibility to use outside of
definitions, better factoring, no ambiguity with "recurse".

> Sure, system-specific implementations are possible and not
> particularly hard. In Gforth we have replaced the original (dodoes)
> routine (which performs a call to a threaded-code address) with one
> that was originally called (dodoesxt) (which EXECUTEs an xt instead);
> the latter has been renamed into (dodoes) after we removed the old
> one. There is SET-DOES>, of course.
>
> And there is an implementation of DOES> that is based on SET-DOES> and
> quotations, and that's the most complicated part of the whole thing.
> Hmm, now I am wondering why we did not do it as follows:
>
> : does>
> lit compile, here >r 0 , postpone set-does> postpone ;
> :noname lastxt r> ! ; immediate

I implemented "does>" in a similar way (https://git.io/JEO7W).

The functionality to defer a literal is so useful sometimes that I
introduced a special word for that:

lit-deferred, ( -- addr )
Reserve one cell of data space and place its address on the stack.
Append to the current definition the following Run-time semantics.
Run-Time: place a single-cell number from addr on the stack.

In Gforth this word can be defined as

: lit-deferred, ( -- addr ) ['] lit compile, here 0 , ;

A more portable definition (but still non standard):

: lit-deferred, ( -- addr ) ( run-time: -- x )
postpone ahead here >r 0 , postpone then
r> dup lit, ['] @ compile,
;

>
> Probably to support interpretive DOES>.

Actually, the interpretation semantics are simpler than the compilation
semantics: you need just start the new anonymous definition and use its
xt for "set-does>":

: does>
state @ if postpone does> exit then
lastnt @ >r
depth >r :noname depth r> - 1- roll ( ... xt )
r> lastnt !
set-does>
; immediate

But in Gforth it requires to save and restore "lastnt", that is used by
"set-does>" and changed by ":noname". That's why I prefer to use the
compilation word list to find the latest word.

>>>> Concerning compiling to flash, I don't see how it can be justified.
>>>
>>> There are lots of microcontrollers with lots of flash and little RAM.
>>>
>>>> AFAIK, a more often scenario is that you prepare one image that is
>>>> written to many devices (and you don't have a compiler on each device).
>>>
>>> Not having a compiler is beyond the standard. In that case you can
>>> also put restrictions on executions of DOES> (doing the standard thing
>>> for DOES> won't bring you back under the standard umbrella).
>>>
>>>> But even if it's only one device, the approach with image seems to be
>>>> more robust and more forward-thinking.
>>>
>>> What approach is that?
>>
>> I'm not an expert in this area. But just as far as I understand it.
>>
>> By the "approach with image" I meant that a Forth system compiles a
>> program and prepares a completed image in RAM, and then this image is
>> entirely written (by this Forth system, or by other means) into the
>> flash memory, instead of incremental compiling the program into the
>> flash memory at once.
>
> I.e., the classical cross-compiling approach that C gives you, too.
> This gets rid of a strength of Forth: Interactivity. Sure, you can
> then have some text interpreter where you can type in commands, but
> you no longer have full programmability at your fingertips; and every
> time you want the slightest change to the program, you have to
> terminate the session, recompile, and reflash, and start another
> session, rather than, e.g., just adding a word and redirecting a hook
> to use that word.

I see, but it's not necessary.

New words can be compiled into RAM (i.e., just another
section/dictionary). And the corresponding image can be prepared and
written into the flash memory in the same interactive session too.

The difference is that in one approach you should use NEXT-IMMEDIATE and
other special words to generate immutable code at once (what about word
list structures?), in another approach you need to enter one special
command (SAVE-FLASH for example) when you are ready to save the result
of your interactive work. (Although, I guess, more often you will
recompile the whole program from the updated sources to update the flash
memory after your debugging session)

> Gforth has such a cross compiler (and others, too, I guess), but we
> only use it for bootstrapping (and others, too, I guess). For
> experiencing the benefits of Forth, you need a proper Forth system,
> either in the target (as, e.g., Mecrisp does), or distributed between
> host and target (as the tethered/umbilical systems of commercial
> vendors do).

Yes, certainly you need it.

The question is how to cope with the FLASH memory, that cannot be easy
writable.

--
Ruvim

On 24/08/2021 02:19, Ruvim wrote:
> On 2021-08-23 12:08, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-08-22 19:55, Anton Ertl wrote:
>>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>>> On 2021-08-22 08:29, Anton Ertl wrote:
>>>>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>>>>> DOES ( xt -- )
>>>>>>
>>>>>> Already exists under the name SET-DOES> in Gforth.
>>>>>
>>>>> Yes, I see. I wonder whether it can be easily implemented in any Forth
>>>>> system that provides "does>".
>>>>
>>>> Not that I can see.
>>>
>>> I didn't mean in a standard way, but in some system specific way (using
>>> carnal knowledge).
>>>
>>> An inefficient straightforward implementation could be something like this:
>>>
>>> : does ( xt -- )
>>> >r :noname postpone does> r> compile, postpone ;
>>> get-current latest-name-in last !
>>> execute
>>> ;
>>
>> And maybe change the section before and restore it afterwards. After
>> all, you want this to work:
>>
>> : const ( n "name" -- )
>> create ['] @ does , ;
>>
>> (and on many systems, DOES would put the noname definition between the
>> NAME header and the n deposited with ",").
>
> Yes, it will break contiguity of the data field (if the system doesn't
> support multiple sections/dictionaries, or "does" doesn't use it).
>
> But according to my specification, it's allowed to do it: DOES may
> allocate memory in data space. So, it's incorrect to perform DOES before
> allocating the data filed.
>
> A correct variant:
>
> : const ( n "name" -- )
> create , ['] @ does ;
>

Your spec includes a pointless dependency on CREATE

: const ( n "name" -- )
['] @ does , ;

Ruvim <ruvim.pinka@gmail.com> writes:
>But according to my specification, it's allowed to do it: DOES may
>allocate memory in data space. So, it's incorrect to perform DOES before
>allocating the data filed.

SET-DOES> does not have this restriction, and I think you should avoid
littering the Forth system with such restrictions. We see people fall
into such traps regularly.

>> Hmm, now I am wondering why we did not do it as follows:
>>
>> : does>
>> lit compile, here >r 0 , postpone set-does> postpone ;
>> :noname lastxt r> ! ; immediate
....
>> Probably to support interpretive DOES>.
>
>Actually, the interpretation semantics are simpler than the compilation
>semantics: you need just start the new anonymous definition and use its
>xt for "set-does>":
>
> : does>
> state @ if postpone does> exit then
> lastnt @ >r
> depth >r :noname depth r> - 1- roll ( ... xt )
> r> lastnt !
> set-does>
> ; immediate

Ugh! This is fugly, as Andrew Haley might express it.

More along the lines of:

: int-does>
latestxt >r noname : latestxt r> make-latest dup set-does> make-latest ;

: comp-does>
postpone lit here >r 0 , postpone set-does> postpone ;
noname : lastxt r> ! ; immediate

' int-does> ' comp-does> interpret/compile: does>

Which does not answer the question of why we implemented it with
quotations.

>New words can be compiled into RAM (i.e., just another
>section/dictionary).

These microcontrollers have very little RAM. This RAM is filled with
data for variables and such. No place for colon definitions. E.g.,
the MSP430G2553 has 16KB of Flash and 512B of RAM. Also, the transfer
to flash would incur extra complexity, in particular code relocation.

>The difference is that in one approach you should use NEXT-IMMEDIATE and
>other special words to generate immutable code at once

As mentioned, they solved it in other ways.

>(what about word
>list structures?)

What about them? I dimly remember that Mecrisp wordlists are chained
in the opposite way, but I don't remember why.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 2021-08-23 20:19, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> But according to my specification, it's allowed to do it: DOES may
>> allocate memory in data space. So, it's incorrect to perform DOES before
>> allocating the data filed.
>
> SET-DOES> does not have this restriction, and I think you should avoid
> littering the Forth system with such restrictions. We see people fall
> into such traps regularly.

This restriction can be removed. It just provides more options to
implementors.

>>> Hmm, now I am wondering why we did not do it as follows:
>>>
>>> : does>
>>> lit compile, here >r 0 , postpone set-does> postpone ;
>>> :noname lastxt r> ! ; immediate
> ...
>>> Probably to support interpretive DOES>.
>>
>> Actually, the interpretation semantics are simpler than the compilation
>> semantics: you need just start the new anonymous definition and use its
>> xt for "set-does>":
>>
>> : does>
>> state @ if postpone does> exit then
>> lastnt @ >r
>> depth >r :noname depth r> - 1- roll ( ... xt )
>> r> lastnt !
>> set-does>
>> ; immediate
>
> Ugh! This is fugly, as Andrew Haley might express it.
>
> More along the lines of:
>
> : int-does>
> latestxt >r noname : latestxt r> make-latest dup set-does> make-latest ;

Well, this variant just relies on more pieces of carnal knowledge.

In my framework (see https://git.io/JG12K) this definition could be
expressed even more elegant:

: int-does> :noname end{ end set-does } ;

> : comp-does>
> postpone lit here >r 0 , postpone set-does> postpone ;
> noname : lastxt r> ! ; immediate
>
> ' int-does> ' comp-does> interpret/compile: does>
>
> Which does not answer the question of why we implemented it with
> quotations.

Probably, the reason is that your implementation with quotations
(https://git.io/JEssF) doesn't require the trick with a deferred literal.

In my framework a quotation-based variant could be expressed as the
following:

: comp-does> postpone [: end{ end postpone set-does end } ;

>> New words can be compiled into RAM (i.e., just another
>> section/dictionary).
>
> These microcontrollers have very little RAM. This RAM is filled with
> data for variables and such. No place for colon definitions. E.g.,
> the MSP430G2553 has 16KB of Flash and 512B of RAM.

Oh, there is no chance to compile into RAM in such a case.

> Also, the transfer
> to flash would incur extra complexity, in particular code relocation.

AFAIK, this problem was already solved many times (if you have enough RAM).

>> The difference is that in one approach you should use NEXT-IMMEDIATE and
>> other special words to generate immutable code at once
>
> As mentioned, they solved it in other ways.

It's interesting how they do incremental compilation into Flash (if any).

>> (what about word list structures?)
>
> What about them?

I mean, how to update the head of the compilation word list, and the
pointer of the dictionary (data space)? (I suppose, they are kept in
flash memory).

If you can update them, then you can update a word header by usual
IMMEDIATE too.

> I dimly remember that Mecrisp wordlists are chained
> in the opposite way, but I don't remember why.

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
> I mean, how to update the head of the compilation word list, and the
> pointer of the dictionary (data space)? (I suppose, they are kept in
> flash memory).

I haven't looked, but I assumed that the system reserved a few ram cells
for stuff like that. I do think these sorts of processors are valid
Forth use cases, and it is worthwhile to find and maybe standardize good
approaches to them. Flashforth, Mecrisp, and I think Amforth all have
their own ways to deal with compiling to flash.

On 24/08/2021 17:06, Ruvim wrote:
> On 2021-08-23 20:23, dxforth wrote:
>> On 24/08/2021 02:19, Ruvim wrote:
> [...]
>>> But according to my specification, it's allowed to do it: DOES may
>>> allocate memory in data space. So, it's incorrect to perform DOES before
>>> allocating the data filed.
>>>
>>> A correct variant:
>>>
>>>     : const ( n "name" -- )
>>>       create , ['] @ does ;
>>>
>>
>> Your spec includes a pointless dependency on CREATE
>
> Since it was an alternative/replacement for "does>" only.

DOES> doesn't require an xt as a parameter

>
>
>>
>>      : const ( n "name" -- )
>>        ['] @ does , ;
>>
>
> It's better to use another name for such a word.
>
> But anyway, it's unclear to me why "does" ( xt -- )
> is better than "create-does" ( xt "name" -- )

It's not. What's unnecessary given xt, is CREATE to generate a
name and run-time with the behaviour of CREATE, and another word
to modify it to the required xt.

On 2021-08-24 11:04, dxforth wrote:
> On 24/08/2021 17:06, Ruvim wrote:
>> On 2021-08-23 20:23, dxforth wrote:
>>> On 24/08/2021 02:19, Ruvim wrote:
>> [...]
>>>> But according to my specification, it's allowed to do it: DOES may
>>>> allocate memory in data space. So, it's incorrect to perform DOES
>>>> before
>>>> allocating the data filed.
>>>>
>>>> A correct variant:
>>>>
>>>>     : const ( n "name" -- )
>>>>       create , ['] @ does ;
>>>>
>>>
>>> Your spec includes a pointless dependency on CREATE
>>
>> Since it was an alternative/replacement for "does>" only.
>
> DOES> doesn't require an xt as a parameter

It doesn't matter.
"does" can be implemented in such a way (without the mentioned
limitation on programs) that any use of:
does> ... ;
can be replaced by:
[: ... ;] does ;

>>>
>>>       : const ( n "name" -- )
>>>         ['] @ does , ;
>>>
>>
>> It's better to use another name for such a word.
>>
>> But anyway, it's unclear to me why "does" ( xt -- )
>> is better than "create-does" ( xt "name" -- )
>
> It's not.  What's unnecessary given xt, is CREATE to generate a
> name and run-time with the behaviour of CREATE, and another word
> to modify it to the required xt.

From an API point of view it's even better to take the name as an
argument from the stack:

created-does ( sd-name xt -- )

And then the pattern

... create xxx does> yyy ;

can be replaced by

... parse-name [: yyy ;] created-does xxx

But perhaps some use cases exist when "does>" or "does" cannot be
*easily* replaced by "created-does" ( sd-name xt -- ). Could anybody
provide such examples?

By the way, "created-does" can be implemented in a standard way as:

: created-does ( sd-name xt -- )
>r :noname postpone does> r> compile, postpone ; >r
['] create execute-parsing r> execute
;

And vise versa, "create" and "does" can be implemented in a standard way
via "created-does" (and "does>" via "does").

Certainly, such implementations are not so efficient as system-specific
variants can be.

--
Ruvim

On 24/08/2021 19:40, Ruvim wrote:
> On 2021-08-24 11:04, dxforth wrote:
>> On 24/08/2021 17:06, Ruvim wrote:
>>> On 2021-08-23 20:23, dxforth wrote:
>>>> On 24/08/2021 02:19, Ruvim wrote:
>>> [...]
>>>>> But according to my specification, it's allowed to do it: DOES may
>>>>> allocate memory in data space. So, it's incorrect to perform DOES
>>>>> before
>>>>> allocating the data filed.
>>>>>
>>>>> A correct variant:
>>>>>
>>>>>     : const ( n "name" -- )
>>>>>       create , ['] @ does ;
>>>>>
>>>>
>>>> Your spec includes a pointless dependency on CREATE
>>>
>>> Since it was an alternative/replacement for "does>" only.
>>
>> DOES> doesn't require an xt as a parameter
>
> It doesn't matter.
> "does" can be implemented in such a way (without the mentioned
> limitation on programs) that any use of:
> does> ... ;
> can be replaced by:
> [: ... ;] does ;

Apart from finding a use for quotations, what else does it do
that DOES> cannot?

>
>
>>>>
>>>>       : const ( n "name" -- )
>>>>         ['] @ does , ;
>>>>
>>>
>>> It's better to use another name for such a word.
>>>
>>> But anyway, it's unclear to me why "does" ( xt -- )
>>> is better than "create-does" ( xt "name" -- )
>>
>> It's not.  What's unnecessary given xt, is CREATE to generate a
>> name and run-time with the behaviour of CREATE, and another word
>> to modify it to the required xt.
>
>
> From an API point of view it's even better to take the name as an
> argument from the stack:
>
> created-does ( sd-name xt -- )
>
> And then the pattern
>
> ... create xxx does> yyy ;
>
> can be replaced by
>
> ... parse-name [: yyy ;] created-does xxx
>
> But perhaps some use cases exist when "does>" or "does" cannot be
> *easily* replaced by "created-does" ( sd-name xt -- ). Could anybody
> provide such examples?

First step is to provide examples of use - why it's in anybody's
interest to replace definers which have worked for 99% of users.

On 2021-08-24 14:46, dxforth wrote:
> On 24/08/2021 19:40, Ruvim wrote:
>> On 2021-08-24 11:04, dxforth wrote:
>>> On 24/08/2021 17:06, Ruvim wrote:
>>>> On 2021-08-23 20:23, dxforth wrote:
>>>>> On 24/08/2021 02:19, Ruvim wrote:
>>>> [...]
>>>>>> But according to my specification, it's allowed to do it: DOES may
>>>>>> allocate memory in data space. So, it's incorrect to perform DOES
>>>>>> before
>>>>>> allocating the data filed.
>>>>>>
>>>>>> A correct variant:
>>>>>>
>>>>>>     : const ( n "name" -- )
>>>>>>       create , ['] @ does ;
>>>>>>
>>>>>
>>>>> Your spec includes a pointless dependency on CREATE
>>>>
>>>> Since it was an alternative/replacement for "does>" only.
>>>
>>> DOES> doesn't require an xt as a parameter
>>
>> It doesn't matter.
>> "does" can be implemented in such a way (without the mentioned
>> limitation on programs) that any use of:
>>     does> ... ;
>> can be replaced by:
>>     [: ... ;] does ;
>
> Apart from finding a use for quotations, what else does it do
> that DOES> cannot?

I already wrote this yesterday (see news:sg0hqq$11l$1@dont-email.me)

Compared to "does>", this "does" has the following advantages:
- simpler specification,
- easier comprehension,
- possibility to use outside of definitions,
- better factoring,
- no ambiguity with "recurse".

[...]
>>>>
>>>> But anyway, it's unclear to me why "does" ( xt -- )
>>>> is better than "create-does" ( xt "name" -- )
>>>
>>> It's not.  What's unnecessary given xt, is CREATE to generate a
>>> name and run-time with the behaviour of CREATE, and another word
>>> to modify it to the required xt.
>>
>>
>>   From an API point of view it's even better to take the name as an
>> argument from the stack:
>>
>>     created-does ( sd-name xt -- )
>>
>> And then the pattern
>>
>>     ... create  xxx does> yyy ;
>>
>> can be replaced by
>>
>>     ... parse-name [: yyy ;] created-does xxx
>>
>> But perhaps some use cases exist when "does>" or "does" cannot be
>> *easily* replaced by "created-does" ( sd-name xt -- ). Could anybody
>> provide such examples?
>
> First step is to provide examples of use - why it's in anybody's
> interest to replace definers which have worked for 99% of users.

There is no any interest to replace them in old programs. An interest
can be to implement such new word in a system and use it in new
programs. Also, an interest can be to promote better practices.

The initial problems was about interpretive "does>" and about difficult
comprehension of "does>" for newbies (both users and implementers).
From this point of view a new word can be an alternative to classic
"does>".

I think, we should admit that "does>" is a bad designed thing (probably
it was invented with a close connection to some particular
implementation of threaded code). The specification for "does>" just
cries about it: https://forth-standard.org/standard/core/DOES

--
Ruvim

On 24/08/2021 22:48, Ruvim wrote:
> On 2021-08-24 14:46, dxforth wrote:
>> On 24/08/2021 19:40, Ruvim wrote:
>>> On 2021-08-24 11:04, dxforth wrote:
>>>> On 24/08/2021 17:06, Ruvim wrote:
>>> ...
>>> It doesn't matter.
>>> "does" can be implemented in such a way (without the mentioned
>>> limitation on programs) that any use of:
>>>     does> ... ;
>>> can be replaced by:
>>>     [: ... ;] does ;
>>
>> Apart from finding a use for quotations, what else does it do
>> that DOES> cannot?
>
> I already wrote this yesterday (see news:sg0hqq$11l$1@dont-email.me)
>
> Compared to "does>", this "does" has the following advantages:
> - simpler specification,
> - easier comprehension,
> - possibility to use outside of definitions,
> - better factoring,
> - no ambiguity with "recurse".

DOES> can be used outside a definition; and there's nothing stopping
DOES> ... ; executing a word that's recursive as unusual as that's been.
'Easy' isn't a tag I would apply to a definer that was originally a
mishmash of ideas and it's proposed to complicate further by forcing
users into quotations which they didn't need before.

> ...
> I think, we should admit that "does>" is a bad designed thing (probably
> it was invented with a close connection to some particular
> implementation of threaded code). The specification for "does>" just
> cries about it: https://forth-standard.org/standard/core/DOES

For all its quirks CREATE DOES> has been used in environments as demanding
as target compilation. So clearly it is usable. Short of a massive change
to how forth is currently being used, proposing new definers on theoretical
grounds is likely to fall on deaf ears. That's not to say you can't take
forth in a direction that suits you.

On 2021-08-25 06:20, dxforth wrote:
> On 24/08/2021 22:48, Ruvim wrote:
>> On 2021-08-24 14:46, dxforth wrote:
>>> On 24/08/2021 19:40, Ruvim wrote:
>>>> On 2021-08-24 11:04, dxforth wrote:
>>>>> On 24/08/2021 17:06, Ruvim wrote:
>>>> ...
>>>> It doesn't matter.
>>>> "does" can be implemented in such a way (without the mentioned
>>>> limitation on programs) that any use of:
>>>>     does> ... ;
>>>> can be replaced by:
>>>>     [: ... ;] does ;
>>>
>>> Apart from finding a use for quotations, what else does it do
>>> that DOES> cannot?
>>
>> I already wrote this yesterday (see news:sg0hqq$11l$1@dont-email.me)
>>
>> Compared to "does>", this "does" has the following advantages:
>>     - simpler specification,
>>     - easier comprehension,
>>     - possibility to use outside of definitions,
>>     - better factoring,
>>     - no ambiguity with "recurse".
>
> DOES> can be used outside a definition;

What do you mean?

Interpretive "does>" isn't standardized, and it breaks the convention
concerning colon-semicolon that we discussed.

> and there's nothing stopping
> DOES> ... ; executing a word that's recursive as unusual as that's been.

It's a workaround that just confirms the mentioned ambiguity, it doesn't
solve it.

> 'Easy' isn't a tag I would apply to a definer that was originally a
> mishmash of ideas

But the specification for "does" is really far simpler than for "does>".

> and it's proposed to complicate further by forcing
> users into quotations which they didn't need before.

It doesn't force users to use quotations. You can define a named or
anonymous definition and pass its xt to "does". Although, this way is
longer.

>> ...
>> I think, we should admit that "does>" is a bad designed thing (probably
>> it was invented with a close connection to some particular
>> implementation of threaded code). The specification for "does>" just
>> cries about it: https://forth-standard.org/standard/core/DOES
>
> For all its quirks CREATE DOES> has been used in environments as demanding
> as target compilation.  So clearly it is usable.  Short of a massive change
> to how forth is currently being used, proposing new definers on theoretical
> grounds is likely to fall on deaf ears.  That's not to say you can't take
> forth in a direction that suits you.

Perhaps you are right, but we had to try.

--
Ruvim

dxforth <dxforth@gmail.com> writes:
>Apart from finding a use for quotations, what else does it do
>that DOES> cannot?

Like many other bad factorings, DOES> can do everything that SET-DOES>
can do, it's just that it is more cumbersome and has other disadvantages.

One of the disadvantages of DOES> is that it ends the current
definition. This can result in cumbersome workarounds: E.g., consider
the following definitions from
<http://git.savannah.gnu.org/cgit/gforth.git/tree/compat/struct.fs?id=75fcf9e4159f4c7a71e5d191854e713a72517201>:

: 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 ;

With SET-DOES>, they can be replaced with:

: 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 ;

Or, if you prefer to do without the quotation, you can turn the
quotation into a separate named word, and still be shorter than the
DOES> version.

Another issue is that the implementation of DOES> is more complicated
and bug-prone. I remember at least one bug in DOES> having to do with
"knowing" that the threaded-code address to be stored in the CREATEd
word is so-and-so-many cells after the return address of the DOES>; of
course this offset changed during maintenance.

Another disadvantage of DOES> (at least for non-inlining systems) is
that it performs a call to the code behind the DOES>, and also need to
later return from that call with an explicit or implicit EXIT, even if
there is only a single word between DOES> and ";". With the current
gforth-fast implementation on AMD64, if we count the numbers of
instructions executed starting at the call to FIVE and ending before
the code compiled by the ";" behind, in

: const create , SOME-DOES-CODE ;
5 const five
: foo five ;

for different variants of SOME-DOES-CODE, we get:

insts SOME-DOES-CODE
25 does> @ ;
28 [: @ ;] set-does>
15 ['] @ set-does>

and this 10-instruction advantage over DOES> for calling single words
also applies to any other single word.

Concerning the 3-instruction disadvantage when having to wrap a
sequence of words in a colon definition (quotation or other), this can
be turned into a 3-instruction advantage (at the cost of two
additional threaded-code cells), i.e., 22 instructions for our
example, with a relatively easy optimization. The same
code (3 instructions less, 2 threaded-code cells more) can be produced
for the DOES> variant, though. The bottom line is that SET-DOES>
offers a performance advantage when there is only one word between
DOES> and ";".

>First step is to provide examples of use - why it's in anybody's
>interest to replace definers which have worked for 99% of users.

It's not. If it ain't broken, don't fix it. For new code, though
SET-DOES> can be advantageous, see above.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 25/08/2021 22:54, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>Apart from finding a use for quotations, what else does it do
>>that DOES> cannot?
>
> Like many other bad factorings, DOES> can do everything that SET-DOES>
> can do, it's just that it is more cumbersome and has other disadvantages.
> ...
>
>>First step is to provide examples of use - why it's in anybody's
>>interest to replace definers which have worked for 99% of users.
>
> It's not. If it ain't broken, don't fix it. For new code, though
> SET-DOES> can be advantageous, see above.

I'm not here to argue for or against DOES>. I mostly use something
else because my system is unconventional and it worked out simpler
for me. I can't remember when I last used FIELD. Perhaps luck,
as it seems a lot of trouble for what it does. Optimizing the zero
case is more effort than I'd be willing to expend.

On 25/08/2021 21:35, Ruvim wrote:
> On 2021-08-25 06:20, dxforth wrote:
>> On 24/08/2021 22:48, Ruvim wrote:
>>> On 2021-08-24 14:46, dxforth wrote:
>>>> On 24/08/2021 19:40, Ruvim wrote:
>>>>> On 2021-08-24 11:04, dxforth wrote:
>>>>>> On 24/08/2021 17:06, Ruvim wrote:
>>>>> ...
>>>>> It doesn't matter.
>>>>> "does" can be implemented in such a way (without the mentioned
>>>>> limitation on programs) that any use of:
>>>>>     does> ... ;
>>>>> can be replaced by:
>>>>>     [: ... ;] does ;
>>>>
>>>> Apart from finding a use for quotations, what else does it do
>>>> that DOES> cannot?
>>>
>>> I already wrote this yesterday (see news:sg0hqq$11l$1@dont-email.me)
>>>
>>> Compared to "does>", this "does" has the following advantages:
>>>     - simpler specification,
>>>     - easier comprehension,
>>>     - possibility to use outside of definitions,
>>>     - better factoring,
>>>     - no ambiguity with "recurse".
>>
>> DOES> can be used outside a definition;
>
> What do you mean?
>
> Interpretive "does>" isn't standardized, and it breaks the convention
> concerning colon-semicolon that we discussed.

I mean outside the stereotypical CREATE DOES> definition.

>
>> and there's nothing stopping
>> DOES> ... ; executing a word that's recursive as unusual as that's been.
>
> It's a workaround that just confirms the mentioned ambiguity, it doesn't
> solve it.

It's a trade-off. Few would argue :NONAME and quotations are ambiguous
relative to named definitions and EXECUTE a workaround. EXECUTE was the
price for namelessness.

A definer which uses xt as a parameter is almost certainly trading away space
compared to CREATE DOES> . This can be observed in the SwiftForth and VFX
implementations of BUILD which I posted some time ago. Accepting everything
comes with a cost, the inability to use RECURSE directly in DOES> ... ; is
one I would pay.

dxforth <dxforth@gmail.com> writes:
>A definer which uses xt as a parameter is almost certainly trading away space
>compared to CREATE DOES> .

Let's see:

: myconst1 create , does> @ ;
: myconst2 create , ['] @ set-does> ;

gforth 0.7.2 Gforth 0.7.9_20210819:
(no set-does>): (has set-does>)
simple-see myconst1 simple-see myconst2
$7FD0A592B1B0 call $7FC64B2EBD50 call
$7FD0A592B1B8 <Create> $7FC64B2EBD58 <Create>
$7FD0A592B1C0 call $7FC64B2EBD60 call
$7FD0A592B1C8 <,> $7FC64B2EBD68 <,>
$7FD0A592B1D0 lit $7FC64B2EBD70 lit
$7FD0A592B1D8 <140534107779576> $7FC64B2EBD78 @
$7FD0A592B1E0 call $7FC64B2EBD80 call
$7FD0A592B1E8 <(does>2)> $7FC64B2EBD88 <set-does>>
$7FD0A592B1F0 ;s $7FC64B2EBD90 ;s
$7FD0A592B1F8 <7378697629483820646>
$7FD0A592B200 <7378697629483820646>
$7FD0A592B208 @
$7FD0A592B210 ;s ok

I.e., DOES> costs 4 cells more.

Ok, you might say that's the best case for SET-DOES>, so let's compare
a best case for DOES>:

: mydefer1 create ['] noop , does> @ execute ;
: mydefer2 create ['] noop , [: @ execute ;] set-does> ;

gforth 0.7.2 Gforth 0.7.9_20210819:
(no set-does>): (has set-does>)
simple-see mydefer1 simple-see mydefer2 (and the quotation)
$7FD0A592B240 call $7FC64B2EBE40 call
$7FD0A592B248 <Create> $7FC64B2EBE48 <Create>
$7FD0A592B250 lit $7FC64B2EBE50 lit
$7FD0A592B258 noop $7FC64B2EBE58 noop
$7FD0A592B260 call $7FC64B2EBE60 call
$7FD0A592B268 <,> $7FC64B2EBE68 <,>
$7FD0A592B270 lit $7FC64B2EBE70 lit
$7FD0A592B278 <140534107779736> $7FC64B2EBE78 $7FC64B065CF8
$7FD0A592B280 call $7FC64B2EBE80 call
$7FD0A592B288 <(does>2)> $7FC64B2EBE88 <set-does>>
$7FD0A592B290 ;s $7FC64B2EBE90 ;s ok
$7FD0A592B298 <-7647121087922341905> $7FC64B065CF0 <(UValue)+$A8>
$7FD0A592B2A0 <-5283570396732524545> $7FC64B065CF8 $4048C8
$7FD0A592B2A8 @ $7FC64B065D00 @
$7FD0A592B2B0 execute $7FC64B065D08 execute
$7FD0A592B2B8 ;s ok $7FC64B065D10 ;s ok

So even in the best case for DOES>, DOES> uses the same threaded-code
space as SET-DOES>.

- anton

This can be observed in the SwiftForth and VFX
>implementations of BUILD which I posted some time ago. Accepting everything
>comes with a cost, the inability to use RECURSE directly in DOES> ... ; is
>one I would pay.

--
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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 26/08/2021 23:08, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>A definer which uses xt as a parameter is almost certainly trading away space
>>compared to CREATE DOES> .
>
> Let's see:
>
> : myconst1 create , does> @ ;
> : myconst2 create , ['] @ set-does> ;
>
> gforth 0.7.2 Gforth 0.7.9_20210819:
> (no set-does>): (has set-does>)
> simple-see myconst1 simple-see myconst2
> ...
>
> I.e., DOES> costs 4 cells more.
>
> Ok, you might say that's the best case for SET-DOES>, so let's compare
> a best case for DOES>:
>
> : mydefer1 create ['] noop , does> @ execute ;
> : mydefer2 create ['] noop , [: @ execute ;] set-does> ;
> ...
>
> So even in the best case for DOES>, DOES> uses the same threaded-code
> space as SET-DOES>.

Not quite what I meant but let's go with that.

Best case was where xt represented an existing function. For
the more common case you broke even at the expense of having to
reposition the quotation code after SET-DOES to make it do what
DOES> did naturally without the fuss.

dxforth <dxforth@gmail.com> writes:
>On 26/08/2021 23:08, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>A definer which uses xt as a parameter is almost certainly trading away space
>>>compared to CREATE DOES> .
....
>Not quite what I meant but let's go with that.

What did you mean?

>Best case was where xt represented an existing function. For
>the more common case you broke even at the expense of having to
>reposition the quotation code after SET-DOES to make it do what
>DOES> did naturally without the fuss.

No repositioning going on. The quotation is in a different section.
I appended the cells for the quotation in the posting to make
comparison easy.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 27/08/2021 17:22, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 26/08/2021 23:08, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>>>A definer which uses xt as a parameter is almost certainly trading away space
>>>>compared to CREATE DOES> .
> ...
>>Not quite what I meant but let's go with that.
>
> What did you mean?

Even my system, which has an efficient xt-based definer, the following
beats it for size:

: m1 constant does> c@ c, ;

If I can't justify ditching DOES> what of systems that never needed
anything else. Indeed, they may count themselves lucky compared to
myself who had no choice but to implement another definer.

>
>>Best case was where xt represented an existing function. For
>>the more common case you broke even at the expense of having to
>>reposition the quotation code after SET-DOES to make it do what
>>DOES> did naturally without the fuss.
>
> No repositioning going on. The quotation is in a different section.
> I appended the cells for the quotation in the posting to make
> comparison easy.

So merely matching DOES> was conditional on quotations being located
somewhere out of the way.

dxforth <dxforth@gmail.com> writes:
>On 27/08/2021 17:22, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>>>On 26/08/2021 23:08, Anton Ertl wrote:
>>>> dxforth <dxforth@gmail.com> writes:
>>>>>A definer which uses xt as a parameter is almost certainly trading away space
>>>>>compared to CREATE DOES> .
>> ...
>>>Not quite what I meant but let's go with that.
>>
>> What did you mean?
>
>Even my system, which has an efficient xt-based definer, the following
>beats it for size:
>
> : m1 constant does> c@ c, ;

What's the point of this example? I have to guess what this means
(and my guess is that it does not work as intended on big-endian
systems). Is your point that on your system DOES> produces smaller
code than your efficient xt-based definer when combined with CONSTANT?

>If I can't justify ditching DOES> what of systems that never needed
>anything else. Indeed, they may count themselves lucky compared to
>myself who had no choice but to implement another definer.

Why did you have no choice?

>> No repositioning going on. The quotation is in a different section.
>> I appended the cells for the quotation in the posting to make
>> comparison easy.
>
>So merely matching DOES> was conditional on quotations being located
>somewhere out of the way.

For this example, yes. OTOH, looking at the FIELD example from
<2021Aug25.145416@mips.complang.tuwien.ac.at> on 64-bit systems.

Gforth 0.7.2 needs 424 bytes of dictionary for the code using DOES>.

Gforth 0.7.9_20210819 needs 240 bytes of dictionary (200 bytes in the
main dictionary and 40 bytes in the next section) for the code using
SET-DOES>.

And if you don't want to implement sections and quotations, you can
write it like this:

: dofield @ + ;

: 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 set-does>
else
immediate ['] drop set-does>
then ;

This costs 264 bytes of dictionary on Gforth 0.7.9_20210819.

The additional flexibility of SET-DOES> can lead to smaller code.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021