Hi

I know the word ' : ' is using when need to pack group of other words into one (so after we can use just one word instead of typing many words). (so it looks like we create new word that is replacing group of many words for example

: OPENDOOR insert the key into the lock then turn the key then pull the handle ;
So here we just created new word OPENDOOR, right?

But I can not understund the word CREATE

This also seems creates new word is not? why is this necessary to use CREATE?

Thank you!

Timur

Orekhovo-Zouevo town
Russia

On 18/08/2021 18:16, Timur Aksenov wrote:
> Hi
>
> I know the word ' : ' is using when need to pack group of other words into one (so after we can use just one word instead of typing many words). (so it looks like we create new word that is replacing group of many words for example
>
> : OPENDOOR insert the key into the lock then turn the key then pull the handle ;
> So here we just created new word OPENDOOR, right?
>
>
> But I can not understund the word CREATE
>
> This also seems creates new word is not? why is this necessary to use CREATE?
>
> Thank you!
>
> Timur
>
> Orekhovo-Zouevo town
> Russia
>

CREATE gives name to the region of data space currently specified by HERE.
When name is later executed it returns the address of that data space.

Some applications of CREATE :

: VARIABLE CREATE 1 CELLS ALLOT ;

: CONSTANT CREATE , DOES> @ ;

CREATE allows you to create your own data structures. In combination with
DOES> new actions can be assigned to the data structure.

HTH

On 2021-08-18 11:16, Timur Aksenov wrote:
> Hi
>
> I know the word ' : ' is using when need to pack group of other words into one (so after we can use just one word instead of typing many words). (so it looks like we create new word that is replacing group of many words for example
>
> : OPENDOOR insert the key into the lock then turn the key then pull the handle ;
> So here we just created new word OPENDOOR, right?

Yes

>
> But I can not understund the word CREATE
>
> This also seems creates new word is not? why is this necessary to use CREATE?

It isn't necessary, but sometime it's useful. For example, if you need a
variable of arbitrary size:

create x 10 cells allot

The word "x" returns the address of reserved space for 10 cells.

In another case it can be arbitrary data array, for example:

create _crlf 13 c, 10 c,

: crlf ( -- c-addr u ) _crlf 2 ;

Some Forth systems (e.g. Gforth) support interpretive "does>"
and the above "crlf" word can be defined as following:

create crlf 13 c, 10 c, does> 2 ;

See also: https://stackoverflow.com/q/64919966/1300170

--
Ruvim

On 18/08/2021 20:46, Ruvim wrote:
>
> Some Forth systems (e.g. Gforth) support interpretive "does>"
> and the above "crlf" word can be defined as following:
>
> create crlf 13 c, 10 c, does> 2 ;
>
>
> See also: https://stackoverflow.com/q/64919966/1300170

There's a serious use that warrants confusing everyone with a ';'
that has no corresponding ':' ?

On 2021-08-19 06:27, dxforth wrote:
> On 18/08/2021 20:46, Ruvim wrote:
>>
>> Some Forth systems (e.g. Gforth) support interpretive "does>"
>> and the above "crlf" word can be defined as following:
>>
>>     create crlf 13 c, 10 c,   does> 2 ;
>>
>>
>> See also:  https://stackoverflow.com/q/64919966/1300170
>
> There's a serious use that warrants confusing everyone with a ';'
> that has no corresponding ':' ?

I don't know.

Anyway, such a confusion exists regardless of this case. Namely, when
':' doesn't have the corresponding ';', for example in the cases of
"buffer:", "field:", etc.

I also wrote about such confusions before:

https://forth-standard.org/standard/core/BUFFERColon#reply-248

https://groups.google.com/g/comp.lang.forth/c/gIiF2WaFVDw/m/HnQ1JUYrEAAJ

A common pattern was that a construction that starts with a name that
contains a colon (in the head or tail) ends with a name that contains a
semicolon. But some new names was introduced without this pattern in the
mind.

Concerning "does>", perhaps the following variants are less confused:

create crlf 13 c, 10 c, [: does> 2 ;] execute

create crlf 13 c, 10 c, :noname does> 2 ; execute

But they make impression of excessiveness.

A construct that can be used inside definitions and outside without any
confusion can look like the following:

create ... does{ ... }

And a more basic factor of that can be something like:

create ... [: ... ;] does

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-08-19 06:27, dxforth wrote:
>> On 18/08/2021 20:46, Ruvim wrote:
>>>
>>> Some Forth systems (e.g. Gforth) support interpretive "does>"
>>> and the above "crlf" word can be defined as following:
>>>
>>>     create crlf 13 c, 10 c,   does> 2 ;
>>>
>>>
>>> See also:  https://stackoverflow.com/q/64919966/1300170
>>
>> There's a serious use that warrants confusing everyone with a ';'
>> that has no corresponding ':' ?
>
>I don't know.

Whether you consider it serious, or too clever, two uses are found in
the lines following

http://git.savannah.gnu.org/cgit/gforth.git/tree/kernel/io.fs#n215

>Concerning "does>", perhaps the following variants are less confused:
>
> create crlf 13 c, 10 c, [: does> 2 ;] execute
>
> create crlf 13 c, 10 c, :noname does> 2 ; execute
>
>But they make impression of excessiveness.
>
>
>A construct that can be used inside definitions and outside without any
>confusion can look like the following:
>
> create ... does{ ... }
>
>
>And a more basic factor of that can be something like:
>
> create ... [: ... ;] does

Gforth (development) has SET-DOES> that behaves like this. With that
you could do:

2 constant 2
create crlf 13 c, 10 c, ' 2 set-does>

But I prefer the more straightforward

: crlf s\" \r\l" ;

- 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-19 18:08, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-08-19 06:27, dxforth wrote:
>>> On 18/08/2021 20:46, Ruvim wrote:
>>>>
>>>> Some Forth systems (e.g. Gforth) support interpretive "does>"
>>>> and the above "crlf" word can be defined as following:
>>>>
>>>>     create crlf 13 c, 10 c,   does> 2 ;
>>>>
>>>>
>>>> See also:  https://stackoverflow.com/q/64919966/1300170
>>>
>>> There's a serious use that warrants confusing everyone with a ';'
>>> that has no corresponding ':' ?
>>
>> I don't know.
>
> Whether you consider it serious, or too clever, two uses are found in
> the lines following
>
> http://git.savannah.gnu.org/cgit/gforth.git/tree/kernel/io.fs#n215

\ spaces-loop ( n addr -- )

create spaces ( u -- ) bl 80 times
does> spaces-loop ;

In general, I agree that the interpretive "does>" is quite confused and
it should not be encouraged.

A less confused approach could be:

here bl 80 times
: spaces ( u -- ) [ lit, ] space-loop ;

but it requires the control-flow stack be separate.

NB: I think that "[ lit, ]" is more clear than "literal" for newbies.
What do you think?

>> Concerning "does>", perhaps the following variants are less confused:
>>
>> create crlf 13 c, 10 c, [: does> 2 ;] execute
>>
>> create crlf 13 c, 10 c, :noname does> 2 ; execute
>>
>> But they make impression of excessiveness.
>>
>>
>> A construct that can be used inside definitions and outside without any
>> confusion can look like the following:
>>
>> create ... does{ ... }
>>
>>
>> And a more basic factor of that can be something like:
>>
>> create ... [: ... ;] does
>
> Gforth (development) has SET-DOES> that behaves like this. With that
> you could do:
>
> 2 constant 2
> create crlf 13 c, 10 c, ' 2 set-does>

But the following will not work, won't it?

create crlf 13 c, 10 c, [: 2 ;] set-does>

Since the most recent definition is not defined via "create".

In the example with "does" above I imply that the word "does" changes
the most recent *named* definition.

> But I prefer the more straightforward
>
> : crlf s\" \r\l" ;

Or even shorter via \m

But the considered problem is about interpretive create-does (and its
alternatives) in general, not about this particular example.

--
Ruvim

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2021-08-19 18:08, Anton Ertl wrote:
>> http://git.savannah.gnu.org/cgit/gforth.git/tree/kernel/io.fs#n215
>
> \ spaces-loop ( n addr -- )
>
> create spaces ( u -- ) bl 80 times
> does> spaces-loop ;
>
>In general, I agree that the interpretive "does>" is quite confused and
>it should not be encouraged.

Just a matter of getting used to.

>A less confused approach could be:
>
> here bl 80 times
> : spaces ( u -- ) [ lit, ] space-loop ;
>
>but it requires the control-flow stack be separate.

In development Gforth (but not in the cross compiler that compiles the
code above), you can do

here >r 80 0 [do] bl c, [loop] \ no TIMES in Gforth
: spaces ( u -- ) [ r> ]L spaces-loop ;

>NB: I think that "[ lit, ]" is more clear than "literal" for newbies.
>What do you think?

Immediacy for LITERAL is a mistake, yes.

>But the following will not work, won't it?
>
> create crlf 13 c, 10 c, [: 2 ;] set-does>

That works, too.

>Since the most recent definition is not defined via "create".

[: ... ;] restores the "most recent definition" at the ;], otherwise
IMMEDIATE would not work for:

: foo ... [: ... ;] ... ; immediate

The disadvantage of the solution with the quotation is that it costs
more at run-time.

- 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 19/08/2021 23:46, Ruvim wrote:
> On 2021-08-19 06:27, dxforth wrote:
>> On 18/08/2021 20:46, Ruvim wrote:
>>>
>>> Some Forth systems (e.g. Gforth) support interpretive "does>"
>>> and the above "crlf" word can be defined as following:
>>>
>>>     create crlf 13 c, 10 c,   does> 2 ;
>>>
>>>
>>> See also:  https://stackoverflow.com/q/64919966/1300170
>>
>> There's a serious use that warrants confusing everyone with a ';'
>> that has no corresponding ':' ?
>
> I don't know.
>
> Anyway, such a confusion exists regardless of this case. Namely, when
> ':' doesn't have the corresponding ';', for example in the cases of
> "buffer:", "field:", etc.
>
> I also wrote about such confusions before:
>
> https://forth-standard.org/standard/core/BUFFERColon#reply-248
>
> https://groups.google.com/g/comp.lang.forth/c/gIiF2WaFVDw/m/HnQ1JUYrEAAJ

Due to forth parsing rules there is no confusion between characters used
in a name and individually. Indeed, it has permitted greater flexibility
in naming than most languages allow. The exception would be 'c' which 200x
introduced. Breaking convention however, it hasn't been universally accepted
or implemented.

>
> Concerning "does>", perhaps the following variants are less confused:
>
> create crlf 13 c, 10 c, [: does> 2 ;] execute
>
> create crlf 13 c, 10 c, :noname does> 2 ; execute
>
> But they make impression of excessiveness.

That also may not work. It would need to be written:

:noname does> 2 ;
create crlf 13 c, 10 c,
execute

My first instinct OTOH would be to write:

here 13 c, 10 c, here over - 2constant crlf

dxforth <dxforth@gmail.com> writes:
>Due to forth parsing rules there is no confusion between characters used
>in a name and individually. Indeed, it has permitted greater flexibility
>in naming than most languages allow. The exception would be 'c' which 200x
>introduced.

I see no exception.

>Breaking convention however, it hasn't been universally accepted
>or implemented.

'c' .

prints 99 in Gforth, iForth, lxf, SwiftForth, and VFX.

- 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 20/08/2021 17:25, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>Due to forth parsing rules there is no confusion between characters used
>>in a name and individually. Indeed, it has permitted greater flexibility
>>in naming than most languages allow. The exception would be 'c' which 200x
>>introduced.
>
> I see no exception.
>
>>Breaking convention however, it hasn't been universally accepted
>>or implemented.
>
> 'c' .
>
> prints 99 in Gforth, iForth, lxf, SwiftForth, and VFX.
>

Small universe. When was your 'number prefix' proposal accepted - 2007 ?

By 2018 Forth Inc still hadn't implemented it as noted by yourself:

https://groups.google.com/g/comp.lang.forth/c/Dr4zTw3obTg/m/j8W7QbF-AQAJ

Forth Inc's action and opinion:

"I just recently added the missing number prefixes for character
literals (although I didn't personally support them)."

https://groups.google.com/g/comp.lang.forth/c/QaSDF_4-_pc/m/XRwMkgyuBgAJ

On 2021-08-20 01:47, dxforth wrote:
> On 19/08/2021 23:46, Ruvim wrote:
>> On 2021-08-19 06:27, dxforth wrote:
>>> On 18/08/2021 20:46, Ruvim wrote:
>>>>
>>>> Some Forth systems (e.g. Gforth) support interpretive "does>"
>>>> and the above "crlf" word can be defined as following:
>>>>
>>>>     create crlf 13 c, 10 c,   does> 2 ;
>>>>
>>>>
>>>> See also:  https://stackoverflow.com/q/64919966/1300170
>>>
>>> There's a serious use that warrants confusing everyone with a ';'
>>> that has no corresponding ':' ?
>>
>> I don't know.
>>
>> Anyway, such a confusion exists regardless of this case. Namely, when
>> ':' doesn't have the corresponding ';', for example in the cases of
>> "buffer:", "field:", etc.
>>
>> I also wrote about such confusions before:
>>
>> https://forth-standard.org/standard/core/BUFFERColon#reply-248
>>
>> https://groups.google.com/g/comp.lang.forth/c/gIiF2WaFVDw/m/HnQ1JUYrEAAJ
>
> Due to forth parsing rules there is no confusion between characters used
> in a name and individually.

Yes. But some special characters bear some additional connotation by
themself (due the corresponding words) and they bring this connotation
into the name where they are used.

For example, a comma "," means appending something into the dictionary
(the data space or code space). A dot "." often means printing.

A colon ":" (at the start or at the end of a name) means starting the
new definition (although, with exceptions now).

A semicolon ";" means ending of the current definition (although, in
some systems it might also mean "exit" as in ";then").

> Indeed, it has permitted greater flexibility in naming than most
> languages allow.  The exception would be 'c' which 200x introduced.
> Breaking convention however,

What a convention it breaks?

> it hasn't been universally accepted or implemented.
>
>
>>
>> Concerning "does>", perhaps the following variants are less confused:
>>
>>     create crlf 13 c, 10 c,   [: does> 2 ;] execute
>>
>>     create crlf 13 c, 10 c,   :noname does> 2 ; execute
>>
>> But they make impression of excessiveness.
>
> That also may not work.

Yes, you are right.

> It would need to be written:
>
>   :noname does> 2 ;
>   create crlf 13 c, 10 c,
>   execute

It's correct, but it also confused for a newbie.

> My first instinct OTOH would be to write:
>
>   here  13 c, 10 c,  here over - 2constant crlf

It's a solution for this particular example, but not for the considered
problem about interpretive "does>" and its alternatives in general.

--
Ruvim

On Wednesday, August 18, 2021 at 3:28:29 AM UTC-7, dxforth wrote:
> : CONSTANT CREATE , DOES> @ ;
>
> CREATE allows you to create your own data structures. In combination with
> DOES> new actions can be assigned to the data structure.

CONSTANT as defined above is inefficient because it is fetching a
non-mutable constant at run-time. This is inefficient in any ANS-Forth system,
whether it is SwiftForth or VFX or whatever.

This is kindergarten-level Forth programming. I would never do this!
If I were hiring a Forth programmer, I would make this an first-interview question.
Anybody who answers as DXforth answered, does not get a second interview.

I almost never use CREATE DOES> for defining words. I have :NAME for defining words.

This is sample code using :NAME in SwiftForth:
-------------------------------------------------------------------------------------------------
: my-const >r bl word get-current :name r> lit, ;, ; ok
123 my-const mmm ok
mmm . 123 ok

see mmm
49263F 4 # EBP SUB 83ED04
492642 EBX 0 [EBP] MOV 895D00
492645 7B # EBX MOV BB7B000000
49264A RET C3 ok
-------------------------------------------------------------------------------------------------

And this is DXforth's code:
-------------------------------------------------------------------------------------------------
: dx-const create , does> @ ; ok
456 dx-const ddd ok
ddd . 456 ok

see ddd
49269F 49267E ( dx-const +F ) CALL E8DAFFFFFF
ok
see dx-const
49266F 40FC6F ( CREATE ) CALL E8FBD5F7FF
492674 40AB2F ( , ) CALL E8B684F7FF
492679 40DB8F ( (;CODE) ) CALL E811B5F7FF
49267E 4 # EBP SUB 83ED04
492681 EBX 0 [EBP] MOV 895D00
492684 EBX POP 5B
492685 0 [EBX] EBX MOV 8B1B
492687 RET C3 ok
-------------------------------------------------------------------------------------------------

My code is significantly more efficient than the kindergarten code DXforth wrote.
Here on comp.lang.forth we have a lot of teachers of Forth programming
who can't program in Forth, or at least program at the kindergarten level.

BTW: Note that the SwiftForth disassembler has a bug in it.
We have this line: 49269F 49267E ( dx-const +F ) CALL E8DAFFFFFF
This says that DX-CONST + $0F is $49267E (our destination).
$49266F + $0F is actually $492677
Apparently nobody at Forth Inc. knows how to add and subtract integers!

On 20/08/2021 22:49, Ruvim wrote:
> On 2021-08-20 01:47, dxforth wrote:
>> ...
>> Due to forth parsing rules there is no confusion between characters used
>> in a name and individually.
>
>
> Yes. But some special characters bear some additional connotation by
> themself (due the corresponding words) and they bring this connotation
> into the name where they are used.
>
> For example, a comma "," means appending something into the dictionary
> (the data space or code space). A dot "." often means printing.
>
> A colon ":" (at the start or at the end of a name) means starting the
> new definition (although, with exceptions now).
>
> A semicolon ";" means ending of the current definition (although, in
> some systems it might also mean "exit" as in ";then").

The latter might also be seen as poor naming which breaks convention.
Breaking convention can sometimes be justified if there's enough
advantage and no better alternative.

> ...
>
>> My first instinct OTOH would be to write:
>>
>>   here  13 c, 10 c,  here over - 2constant crlf
>
> It's a solution for this particular example, but not for the considered
> problem about interpretive "does>" and its alternatives in general.

What problem does 'interpretive DOES>' solve that can't be done better
or equivalently using conventional means? For most systems such a DOES>
would require changes that could be difficult to justify.

On 21/08/2021 11:39, Hugh Aguilar wrote:
> On Wednesday, August 18, 2021 at 3:28:29 AM UTC-7, dxforth wrote:
>> : CONSTANT CREATE , DOES> @ ;
>>
>> CREATE allows you to create your own data structures. In combination with
>> DOES> new actions can be assigned to the data structure.
>
> CONSTANT as defined above is inefficient because it is fetching a
> non-mutable constant at run-time. This is inefficient in any ANS-Forth system,
> whether it is SwiftForth or VFX or whatever.
>
> This is kindergarten-level Forth programming. I would never do this!
> If I were hiring a Forth programmer, I would make this an first-interview question.
> Anybody who answers as DXforth answered, does not get a second interview.

When have you hired a Forth programmer?

On 2021-08-21 06:38, dxforth wrote:
> On 20/08/2021 22:49, Ruvim wrote:
>> On 2021-08-20 01:47, dxforth wrote:
>>> ...
>>> Due to forth parsing rules there is no confusion between characters used
>>> in a name and individually.
>>
>> Yes.  But some special characters bear some additional connotation by
>> themself (due the corresponding words) and they bring this connotation
>> into the name where they are used.
>>
>> For example, a comma "," means appending something into the dictionary
>> (the data space or code space).  A dot "." often means printing.
>>
>> A colon ":" (at the start or at the end of a name) means starting the
>> new definition  (although, with exceptions now).
>>
>> A semicolon ";" means ending of the current definition (although, in
>> some systems it might also mean "exit" as in ";then").
>
> The latter might also be seen as poor naming which breaks convention.
> Breaking convention can sometimes be justified if there's enough
> advantage and no better alternative.

Agreed.

>> ...
>>
>>> My first instinct OTOH would be to write:
>>>
>>>    here  13 c, 10 c,  here over - 2constant crlf
>>
>> It's a solution for this particular example, but not for the considered
>> problem about interpretive "does>" and its alternatives in general.
>
> What problem does 'interpretive DOES>' solve that can't be done better
> or equivalently using conventional means?

Problem 1: how to easy explain/understand for a newbie the behavior of
"does>".

I think, an interpretive "does>" is the most easy way to interactively
test it and understand it.

Problem 2: how to avoid to create a defining word when you need this
defining word only once.

When you need to use your defining word only once, it would be simpler
to use interpretive "does>" and avoid to create this defining word at all.

But due to absence of a standard interpretive "does>", and due to some
confusion with interpretive "does>" (including breakage of the
convention about colon-semicolon usage), we consider alternative methods
and how they could look like.

> For most systems such a DOES>
> would require changes that could be difficult to justify.

Is it difficult to implement the following word, what do you think?

DOES ( xt -- )
Alter the most recent definition in the compilation word list,
referred to as _name_, by appending the execution semantics identified
by xt to the execution semantics of _name_.
An ambiguous condition exists if _name_ is absent, or it was not
defined with CREATE, or it was already altered by DOES.
DOES may allocate memory in data space.

Rationale:
- Referring _name_ via the compilation word list allows users to
create intermediate anonymous definitions (or even named definitions in
other word lists).
- Allowing to alter _name_ only once provides to Forth systems some
additional ways for optimization.
- It seems, in this way it is far more easy to understand by users and
by implementors (compare with "does>").

- Perhaps, it's better to design a new mechanism that will not alter
any definition at all. I.e., xt is provided to a word like "create" at once.

--
Ruvim

On Friday, August 20, 2021 at 10:41:26 PM UTC-7, dxforth wrote:
> On 21/08/2021 11:39, Hugh Aguilar wrote:
> > On Wednesday, August 18, 2021 at 3:28:29 AM UTC-7, dxforth wrote:
> >> : CONSTANT CREATE , DOES> @ ;
> >>
> >> CREATE allows you to create your own data structures. In combination with
> >> DOES> new actions can be assigned to the data structure.
> >
> > CONSTANT as defined above is inefficient because it is fetching a
> > non-mutable constant at run-time. This is inefficient in any ANS-Forth system,
> > whether it is SwiftForth or VFX or whatever.
> >
> > This is kindergarten-level Forth programming. I would never do this!
> > If I were hiring a Forth programmer, I would make this an first-interview question.
> > Anybody who answers as DXforth answered, does not get a second interview.
> When have you hired a Forth programmer?

I have no need to hire a Forth programmer. I write the code myself.

This question about defining words was part of the job interview at Testra.
It was an easy question for me to answer because UR/Forth had a word
(called HEADER if I recall correctly) that was essentially the same as my
:NAME I have in the novice package. The purpose of interview questions
such as this is to weed out candidates whose knowledge comes from
reading a book (Leo Brodie's "Starting Forth" for Elizabeth Rather and
R.G. Loeliger's "Threaded Interpretive Languages" for you, afaik).

John Hart didn't know how to write an assembler for the MiniForth processor.
That was my job to figure out. Any job in which the employee is required
to do a job that the boss doesn't know how to do, is a bad job --- this will
end badly for the employee.

On 22/08/2021 08:30, Ruvim wrote:
> On 2021-08-21 06:38, dxforth wrote:
>> On 20/08/2021 22:49, Ruvim wrote:
>
>
> Problem 1: how to easy explain/understand for a newbie the behavior of
> "does>".
>
> I think, an interpretive "does>" is the most easy way to interactively
> test it and understand it.

How did you discover Gforth's DOES> worked 'interactively' - poking at the
keyboard, or seeing an example?

>
> Problem 2: how to avoid to create a defining word when you need this
> defining word only once.
>
> When you need to use your defining word only once, it would be simpler
> to use interpretive "does>" and avoid to create this defining word at all.

If only needed once it begs the question why use defining word mechanisms
at all. It may be clever to use DOES> for this but I'm not sure it's simpler
to understand - or to implement in the case of Gforth's.

>
> But due to absence of a standard interpretive "does>", and due to some
> confusion with interpretive "does>" (including breakage of the
> convention about colon-semicolon usage), we consider alternative methods
> and how they could look like.
>
>
>
>
>
>> For most systems such a DOES>
>> would require changes that could be difficult to justify.
>
> Is it difficult to implement the following word, what do you think?
>
> DOES ( xt -- )
> Alter the most recent definition in the compilation word list,
> referred to as _name_, by appending the execution semantics identified
> by xt to the execution semantics of _name_.
> An ambiguous condition exists if _name_ is absent, or it was not
> defined with CREATE, or it was already altered by DOES.
> DOES may allocate memory in data space.
>
>
> Rationale:
> - Referring _name_ via the compilation word list allows users to
> create intermediate anonymous definitions (or even named definitions in
> other word lists).
> - Allowing to alter _name_ only once provides to Forth systems some
> additional ways for optimization.
> - It seems, in this way it is far more easy to understand by users and
> by implementors (compare with "does>").
>
> - Perhaps, it's better to design a new mechanism that will not alter
> any definition at all. I.e., xt is provided to a word like "create" at once.

I have ( xt) BUILD however it was prompted by my need to isolate compile-
time code from run-time code in order to produce smaller turnkeys. I've
since learned to use it to do tricks e.g.

' count build CRLF 2 c, 13 c, 10 c,

OTOH such opportunities tend to be few and represent an insignificant
portion of any app. If true, then what's the harm of using more
conventional techniques when they are available. Forth may well benefit
from being less clever.

Ruvim <ruvim.pinka@gmail.com> writes:
>DOES ( xt -- )

Already exists under the name SET-DOES> in Gforth. andrew Haley has
reported that this word was called USE in early Forth.

> - Perhaps, it's better to design a new mechanism that will not alter
>any definition at all. I.e., xt is provided to a word like "create" at once.

In 2014-2016 there were discussions of the problems that
compile-to-flash systems have with DOES>. I suggested the word
DOES-CREATE (or <DOES-CREATE), to be used as follows:

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

However, SET-DOES> is not the only word that modifies an existing
definition; there is also IMMEDIATE, SET-OPTIMIZER and others. So I
suggested that we would have words like NEXT-DOES, NEXT-IMMEDIATE,
NEXT-OPTIMIZER that would set up the next header appropriately; CREATE
would then write the header into flash, complying with the write-once
rule. Example:

: +field ( n1 n2 "name" -- n3 )
[: @ + ;] next-does
[: >body @ ?dup if postpone literal postpone + then ;] next-optimizer
create over , + ;

However, there was little, if any, resonance to these ideas from the
compile-to-flash people to these ideas. I guess they had found
solutions to their problems by that time, and these ideas did not
allow sufficiently better solutions to make them worthwhile.

So I guess we are stuck with first creating words and modifying them
later.

- 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 22/08/2021 13:02, Hugh Aguilar wrote:
> On Friday, August 20, 2021 at 10:41:26 PM UTC-7, dxforth wrote:
>> On 21/08/2021 11:39, Hugh Aguilar wrote:
>> > On Wednesday, August 18, 2021 at 3:28:29 AM UTC-7, dxforth wrote:
>> >> : CONSTANT CREATE , DOES> @ ;
>> >>
>> >> CREATE allows you to create your own data structures. In combination with
>> >> DOES> new actions can be assigned to the data structure.
>> >
>> > CONSTANT as defined above is inefficient because it is fetching a
>> > non-mutable constant at run-time. This is inefficient in any ANS-Forth system,
>> > whether it is SwiftForth or VFX or whatever.
>> >
>> > This is kindergarten-level Forth programming. I would never do this!
>> > If I were hiring a Forth programmer, I would make this an first-interview question.
>> > Anybody who answers as DXforth answered, does not get a second interview.
>> When have you hired a Forth programmer?
>
> I have no need to hire a Forth programmer. I write the code myself.
>
> This question about defining words was part of the job interview at Testra.
> It was an easy question for me to answer because UR/Forth had a word
> (called HEADER if I recall correctly) that was essentially the same as my
> :NAME I have in the novice package. The purpose of interview questions
> such as this is to weed out candidates whose knowledge comes from
> reading a book (Leo Brodie's "Starting Forth" for Elizabeth Rather and
> R.G. Loeliger's "Threaded Interpretive Languages" for you, afaik).
>
> John Hart didn't know how to write an assembler for the MiniForth processor.
> That was my job to figure out. Any job in which the employee is required
> to do a job that the boss doesn't know how to do, is a bad job --- this will
> end badly for the employee.
>

So any candidates enrolling in your Novice course would be well advised not
to question the material supplied?

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>".

> andrew Haley has
> reported that this word was called USE in early Forth.

So this factorization is known from early Forth. It's interesting.

>> - Perhaps, it's better to design a new mechanism that will not alter
>> any definition at all. I.e., xt is provided to a word like "create" at once.
>
> In 2014-2016 there were discussions of the problems that
> compile-to-flash systems have with DOES>. I suggested the word
> DOES-CREATE (or <DOES-CREATE), to be used as follows:
>
> : const ( n "name" -- )
> ['] @ does-create , ;
>
> However, SET-DOES> is not the only word that modifies an existing
> definition; there is also IMMEDIATE, SET-OPTIMIZER and others. So I > suggested that we would have words like NEXT-DOES, NEXT-IMMEDIATE,
> NEXT-OPTIMIZER that would set up the next header appropriately; CREATE
> would then write the header into flash, complying with the write-once
> rule. Example:
>
> : +field ( n1 n2 "name" -- n3 )
> [: @ + ;] next-does
> [: >body @ ?dup if postpone literal postpone + then ;] next-optimizer
> create over , + ;
>
> However, there was little, if any, resonance to these ideas from the
> compile-to-flash people to these ideas. I guess they had found
> solutions to their problems by that time, and these ideas did not
> allow sufficiently better solutions to make them worthwhile.
>
> So I guess we are stuck with first creating words and modifying them
> later.

I didn't think about compiling to flash, but about optimization only.

Concerning compiling to flash, I don't see how it can be justified.
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).
But even if it's only one device, the approach with image seems to be
more robust and more forward-thinking. And you don't need to change
source codes to use NEXT-IMMEDIATE etc.

--
Ruvim

On 2021-08-22 07:40, dxforth wrote:
> On 22/08/2021 08:30, Ruvim wrote:
>> On 2021-08-21 06:38, dxforth wrote:
>>> On 20/08/2021 22:49, Ruvim wrote:
>>
>>
>> Problem 1: how to easy explain/understand for a newbie the behavior of
>> "does>".
>>
>> I think, an interpretive "does>" is the most easy way to interactively
>> test it and understand it.
>
> How did you discover Gforth's DOES> worked 'interactively' - poking at the
> keyboard, or seeing an example?

Concerning Gforth — I don't remember, but I saw examples in
comp.lang.forth too. This feature in Gforth looked natural to me, since
before that I wanted to use such a feature from time to time and had
experiments with that.

>>
>> Problem 2: how to avoid to create a defining word when you need this
>> defining word only once.
>>
>> When you need to use your defining word only once, it would be simpler
>> to use interpretive "does>" and avoid to create this defining word at
>> all.
>
> If only needed once it begs the question why use defining word mechanisms
> at all.

So the problem is also about what alternative ways we have.

[...]

--
Ruvim

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.

>> However, there was little, if any, resonance to these ideas from the
>> compile-to-flash people to these ideas. I guess they had found
>> solutions to their problems by that time, and these ideas did not
>> allow sufficiently better solutions to make them worthwhile.
>>
>> So I guess we are stuck with first creating words and modifying them
>> later.
>
>
>I didn't think about compiling to flash, but about optimization only.

Optimization is not really an issue, because you can only change a
word until you start the next word, and optimization only comes into
play once the next word has started. In Gforth there is a way to
change an earlier word, but then it's your responsibility to ensure
that it works out; we typically use it to add optimizations, and
optimizations do not change behaviour, only performance. So when you
compile a word before the optimization is added for that word, you get
slower code, when you compile it afterwards, you get faster code, but
other than that both behave the same.

>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? If you mean something Forth-like without
compiler, this is not Forth. Some users may find that it fits their
bill, just like cross-compiled C fits the bill of other users, but
that does not make it Forth.

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

>>> However, there was little, if any, resonance to these ideas from the
>>> compile-to-flash people to these ideas. I guess they had found
>>> solutions to their problems by that time, and these ideas did not
>>> allow sufficiently better solutions to make them worthwhile.
>>>
>>> So I guess we are stuck with first creating words and modifying them
>>> later.
>>
>>
>> I didn't think about compiling to flash, but about optimization only.
>
> Optimization is not really an issue, because you can only change a
> word until you start the next word, and optimization only comes into
> play once the next word has started. In Gforth there is a way to
> change an earlier word, but then it's your responsibility to ensure
> that it works out; we typically use it to add optimizations, and
> optimizations do not change behaviour, only performance. So when you
> compile a word before the optimization is added for that word, you get
> slower code, when you compile it afterwards, you get faster code, but
> other than that both behave the same.

Thanks, I see now.

>> 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.

So, all modification during compilation take place in RAM, and the
generated image is immutable.

In some cases the image can be be prepared on a one system/device, and
used on another device (that doesn't contain a compiler).

> If you mean something Forth-like without
> compiler, this is not Forth. Some users may find that it fits their
> bill, just like cross-compiled C fits the bill of other users, but
> that does not make it Forth.

--
Ruvim

On Saturday, August 21, 2021 at 10:59:50 PM UTC-7, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
> >DOES ( xt -- )
> Already exists under the name SET-DOES> in Gforth. andrew Haley has
> reported that this word was called USE in early Forth.
> > - Perhaps, it's better to design a new mechanism that will not alter
> >any definition at all. I.e., xt is provided to a word like "create" at once.
> In 2014-2016 there were discussions of the problems that
> compile-to-flash systems have with DOES>. I suggested the word
> DOES-CREATE (or <DOES-CREATE), to be used as follows:
>
> : const ( n "name" -- )
> ['] @ does-create , ;
>
> However, SET-DOES> is not the only word that modifies an existing
> definition; there is also IMMEDIATE, SET-OPTIMIZER and others. So I
> suggested that we would have words like NEXT-DOES, NEXT-IMMEDIATE,
> NEXT-OPTIMIZER that would set up the next header appropriately; CREATE
> would then write the header into flash, complying with the write-once
> rule. Example:
>
> : +field ( n1 n2 "name" -- n3 )
> [: @ + ;] next-does
> [: >body @ ?dup if postpone literal postpone + then ;] next-optimizer
> create over , + ;
>
> However, there was little, if any, resonance to these ideas from the
> compile-to-flash people to these ideas. I guess they had found
> solutions to their problems by that time, and these ideas did not
> allow sufficiently better solutions to make them worthwhile.
>
> So I guess we are stuck with first creating words and modifying them
> later.
> - anton

The Forth-200x committee does not know how to write a cross-compiler!
In 1994 I wrote MFX and did not have these problems.
I had <BUILDS DOES> for defining words. Defining words were HOST words
so the code prior to the DOES> was compiled onto the host system.
DOES> switched to TARG mode to compile its code and the ; switched back
to HOST mode again. The word defined with <BUILDS was modified by DOES>
to execute the DOES> run-time code, but this was easy because all that had
been compiled so far was the header on the host system. The <BUILDS word
(like all TARG words) was immediate and compiled the targ code.
This is very easy and obvious! In the year 2021 the Forth-200x committee
is still struggling with this basic Forth programming that I knew in 1994.

The reason why I used <BUILDS rather than CREATE is that I didn't want
CREATE to be overloaded with two purposes as done in ANS-Forth.
CREATE is just a HERE CONSTANT internally. Making it also work for
defining words seemed overly complicated --- "Thinking Forth" says to
let the dictionary do the deciding, meaning that different features are
different words rather than have one word that does a CASE internally
or gets modified by another word after it has been compiled.
<BUILDS and CREATE are obviously different features of the language
and so they are different words in the dictionary --- this is just good Forth
practice (a concept that the ANS-Forth committee knew nothing about).