Can anybody provide examples of meaningful use of double DOES> ? I.e. when we have several in word definition:

: T CREATE DOES> DROP 1 DOES> DROP 2 DOES> DROP 3 ;

I always thought that this behaviour was not intended, but just a side effect of concrete implementation.

Nickolay Kolchin <nbkolchin@gmail.com> writes:
>Can anybody provide examples of meaningful use of double DOES> ?
>I.e. when we have several in word definition:
>
>: T CREATE DOES> DROP 1 DOES> DROP 2 DOES> DROP 3 ;

Looking at
<https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Advanced-does_003e-usage-example.html>, you can see the word

: define-format ( disasm-xt table-xt -- )
\ define an instruction format that uses disasm-xt for
\ disassembling and enters the defined instructions into table
\ table-xt
create 2,
does> ( u "inst" -- )
\ defines an anonymous word for disassembling instruction inst,
\ and enters it as u-th entry into table-xt
2@ swap here name string, ( u table-xt disasm-xt c-addr ) \ remember string
noname create 2, \ define anonymous word
execute latestxt swap ! \ enter xt of defined word into table-xt
does> ( addr w -- )
\ disassemble instruction w at addr
2@ >r ( addr w disasm-xt R: c-addr )
execute ( R: c-addr ) \ disassemble operands
r> count type ; \ print name

But note that here the second does> works on a word defined by the
first does>, not on the same word the first does> worked on.

If you are thinking of overriding one DOES> of a CREATEd word with
another DOES>, I only know of contrived examples. The reason is that
overriding works only on the most recently defined word (which has to
be CREATEd).

Some flash-based systems have decided to only support using DOES> once
(some requiring <BUILDS instead of CREATE).

>I always thought that this behaviour was not intended, but just a side effect of concrete implementation.

It's also a side effect of the two-step interface (that's why the
standard standardized overriding; the alternative would have been to
specify yet another ambiguous condition). If the CREATE step and the
DOES> step were performed in one go by the same word, overriding would
not be possible.

- 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 Saturday, November 20, 2021 at 7:47:37 PM UTC+3, Anton Ertl wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> >Can anybody provide examples of meaningful use of double DOES> ?
> >I.e. when we have several in word definition:
> >
> >: T CREATE DOES> DROP 1 DOES> DROP 2 DOES> DROP 3 ;
> Looking at
> <https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Advanced-does_003e-usage-example.html>, you can see the word
>
> : define-format ( disasm-xt table-xt -- )
> \ define an instruction format that uses disasm-xt for
> \ disassembling and enters the defined instructions into table
> \ table-xt
> create 2,
> does> ( u "inst" -- )
> \ defines an anonymous word for disassembling instruction inst,
> \ and enters it as u-th entry into table-xt
> 2@ swap here name string, ( u table-xt disasm-xt c-addr ) \ remember string
> noname create 2, \ define anonymous word
> execute latestxt swap ! \ enter xt of defined word into table-xt
> does> ( addr w -- )
> \ disassemble instruction w at addr
> 2@ >r ( addr w disasm-xt R: c-addr )
> execute ( R: c-addr ) \ disassemble operands
> r> count type ; \ print name
>
> But note that here the second does> works on a word defined by the
> first does>, not on the same word the first does> worked on.
>
> If you are thinking of overriding one DOES> of a CREATEd word with
> another DOES>, I only know of contrived examples. The reason is that
> overriding works only on the most recently defined word (which has to
> be CREATEd).
>
> Some flash-based systems have decided to only support using DOES> once
> (some requiring <BUILDS instead of CREATE).
> >I always thought that this behaviour was not intended, but just a side effect of concrete implementation.
> It's also a side effect of the two-step interface (that's why the
> standard standardized overriding; the alternative would have been to
> specify yet another ambiguous condition). If the CREATE step and the
> DOES> step were performed in one go by the same word, overriding would
> not be possible.
>
> - 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

Thank you. That makes sense.