Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #41088 > unrolled thread

RFD: Quotations V2 update

Back to article view | Back to comp.lang.forth

Contents

  RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-04 11:05 +0100
    Re: RFD: Quotations V2 update Mark Wills <markwills1970@gmail.com> - 2015-08-04 04:09 -0700
      Re: RFD: Quotations V2 update Lars Brinkhoff <lars.spam@nocrew.org> - 2015-08-04 13:35 +0200
        Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-04 13:54 +0100
          Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-04 14:01 +0100
      Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-04 13:38 +0100
        Re: RFD: Quotations V2 update Mark Wills <markwills1970@gmail.com> - 2015-08-04 07:37 -0700
    Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-04 14:23 +0000
      Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-04 16:09 +0100
        Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-04 15:38 +0000
          Re: RFD: Quotations V2 update Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-04 22:30 +0200
            Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-04 23:09 +0100
              Re: RFD: Quotations V2 update Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-05 01:45 +0200
                Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-05 07:23 +0000
                  Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-05 09:55 +0100
            Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-05 12:03 +0100
              Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-05 13:50 +0100
                Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-05 16:07 +0000
                Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-05 20:23 +0100
    Re: RFD: Quotations V2 update Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-04 22:00 +0200
      Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-04 21:07 +0100
    Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-04 21:53 +0100
      Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-04 23:22 +0100
        Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-05 12:38 +0100
          Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-05 13:41 +0100
            Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-05 12:46 +0000
              Re: RFD: Quotations V2 update Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-06 02:12 +0200
                Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-06 14:16 +0100
                Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-06 13:46 +0000
      Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-05 08:15 +0000
        Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-05 20:31 +0100
          Re: RFD: Quotations V2 update peter.m.falth@gmail.com - 2015-08-05 14:41 -0700
            Re: RFD: Quotations V2 update "Elizabeth D. Rather" <erather@forth.com> - 2015-08-05 18:39 -1000
              Re: RFD: Quotations V2 update peter.m.falth@gmail.com - 2015-08-05 23:22 -0700
          Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-06 13:19 +0000
            Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-07 22:28 +0100
              Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-07 22:34 +0100
                Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-08 15:53 +0000
                  Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-11 21:16 +0100
              Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-08 15:39 +0000
                Re: RFD: Quotations V2 update Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-10 12:55 +0100
                  Re: RFD: Quotations V2 update anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-10 12:08 +0000
    Re: RFD: Quotations V2 update hughaguilar96@gmail.com - 2015-08-04 18:09 -0700
      Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-05 09:22 +0100
      Re: RFD: Quotations V2 update "Alex McDonald" <blog@rivadpm.com> - 2015-08-05 09:53 +0100

Page 1 of 3  [1] 2 3  Next page →

#41088 — RFD: Quotations V2 update

For discussion. Tests for Annex F have not been developed yet.

------>

RfD: Quotations
---------------

Change history
--------------
28Jul2015 Alex McDonald v1 initial draft
04Aug2015 Alex McDonald v2 update
    added & extended "Rationale", "Discussion"
    formalised "Specification"
    corrected "Implementation"
    added "References"

Quotations
==========

The essence of quotations is to provide nested colon definitions,
in which the inner definition(s) are nameless. The expression

: foo ... [: some words ;] ... ;

is equivalent to

:noname some words ; Constant #temp#
: foo ... #temp# ... ;

A simple quotation is an anonymous colon definition that is defined
inside a colon definition or quotation.

Rationale
---------

There is no situation where quotations cannot be implemented by
existing Forth words. Specifcially, :NONAME and : provide all the
features proposed for quotations. Their advantage is as a syntactic
"sugar" that permits a nameless definition in close proximity to its
use; and that it avoids generating one-use names only for the purpose
of refering to the definition inside another word.

One example use of quotations is to provide a solution to the use
of CATCH in a form close to other languages' TRY ... EXCEPT
blocks.

: foo ( i*x -- j*x )
    setup
    [: fee fi fo fum ;] catch
    if ... then
    teardown
    ( throw again ) ;

Under the term "Phrases", quotations have been in MacForth since at
least 1987. They are documented in the infamous "missing chapter" of
the MacForth manual.

Implementations exist in (at least) VFX, Gforth and iForth, and in
the iForth case appear to have some significant use and history.

Discussion
----------

If quotations are to have the same privileges as words defined with :
and :NONAME they should be able to use local variables and use
RECURSE and DOES>.

RECURSE: Recursion is defined as recursing to the start of the
quotation, not the enclosing definition.

DOES>: As with a normal definition that closes the DOES> action with ;
(semi-colon), a DOES> in a quotation is closed at the terminating ;]

While implementing support for DOES> and RECURSE, it has been
proposed to remove the following inconsistency in the definition of 
6.1.2120 RECURSE; "An ambiguous condition exists if RECURSE appears in
a definition after DOES>." The proposal is to remoive that sentence
and permit a RECURSE to the start of the DOES> definition to be
consistent with :NONAME : and the proposed [: .

The above features are illustrated here.

: foo create [: , does> @ dup if . recurse then ;] swap 0= ;
^A           ^B   ^C    ^x                      ^D         ^E

There are 3 definitions: A-E, B-D and C-D.
 The definition of FOO is the code between A and E.
 The quotation returned by executing FOO is the code between B and D
 The DOES> clause is the code between C and D

RECURSE calls the code immediately after C (marked x) as it is the
latest definition, and not the DOES> as it is consumed during
compilation.

Locals: A quotation may not be able to access the locals of the outer
word because it has no knowledge of when it might be executed and
hence whether outer locals are still alive. It does permit defining and
accessing its own locals.

: foo ... [: {: a b :} a b + ;] ... ; \ unambiguous
: bar {: a b :} ... [: a b + ;] ... ; \ ambiguous

There has been some discussion about providing higher-order or
embedded functions that are able to refer to their parent's locals
during their execution. This is a middle ground between the proposal
here and full closures that (almost always) require garbage
collection, and it would permit execution of the quotation in the
execution scope of the parent; in the BAR example above, if the
quotation was executed prior to the return of BAR to its caller.

There are two schools of thought.

1. Define [: ;] such that a standard program may not access
   local variables of the outer definition inside the quotation.

2. Permit such a feature, but restrict valid execution of the
   quotation to the lifetime of the parent's execution.

Solution 2 requires some form of locals frame, and may be excessively
complex to implement; it appears to have few advantages over
the simpler quotations as proposed here.

Specification
-------------

The following notations have been seen in the wild, oldest first.
    :| ... |;
    :[ ... ]:
    [: ... ;]
    
The notation [: ;] appears to have popular support.

[: ( c: -- quotation-sys )
  Interpretation: Interpretation semantics for this word are undefined.
  Compilation: ( c: -- quotation-sys ) suspends compiling to the
  current definition, starts a new nested definition, and compilation
  continues with this nested definition. Locals may be defined in the
  nested definition. It is an ambiguous condition [note 1] if outer
  locals are visible and referred to in the nested definition.

;] ( c: quotation-sys -- ) ( s: -- xt )
  Interpretation: Interpretation semantics for this word are undefined.
  Compilation: Ends the current nested definition, and resumes
  compilation to the previous current definition. It appends the
  following run-time to the current definition:
  run-time: ( -- xt )
  xt is the execution token to execute the nested definition.

6.1.2120 RECURSE CORE
  Interpretation: Interpretation semantics for this word are undefined.
  Compilation: ( –– )
  Append the execution semantics of the current definition to the
  current definition.
  See: 6.1.1250 DOES>, 6.1.2120 RECURSE, A.6.1.2120 RECURSE.

Implementation
--------------

It is not possible to define quotations in ISO Forth. The following
is an outline definition, where save-definition-state and restore-
definition-state require carnal knowledge of the system and are left
to the implementor.

: [: ( c: -- quotation-sys )
  postpone ahead save-definition-state :noname ; immediate
: ;] ( c: quotation-sys -- ) ( s: -- xt )
  postpone ; >r restore-definition-state
  postpone then r> postpone literal ; immediate

Compliance Tests
----------------

tbd

References
----------

Stephen Pelc wrote this; see

http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html

I (Alex McDonald) have taken it and modified it as a proposed RfD,
and have removed the discussion of closures. http://www.forth200x.org/

The following notes on quotations and closures incorporate material
from several people, including Anton Ertl, Andrew Haley, Marcel
Hendrix, Ward Mcfarland, Bernd Paysan, and Elizabeth Rather. If you
have been left out and want acknowledgement, please let me know.

Additional contributors; Hugh Aguilar and Gerry Jackson.

[Note 1]
The phrase "ambiguous condition" has a specific meaning in Forth
standards. An ambiguous condition is "a circumstance for which this
standard does not prescribe a specific behavior". The RfD process
also states: "If you want to leave something open to the system
implementor, make that explicit, e.g., by making it an ambiguous
condition."

[toc] | [next] | [standalone]

#41089

On Tuesday, 4 August 2015 11:05:55 UTC+1, Alex McDonald  wrote:
> For discussion. Tests for Annex F have not been developed yet.
> 
> ------>
> 
> RfD: Quotations
> ---------------
> 
> Change history
> --------------
> 28Jul2015 Alex McDonald v1 initial draft
> 04Aug2015 Alex McDonald v2 update
>     added & extended "Rationale", "Discussion"
>     formalised "Specification"
>     corrected "Implementation"
>     added "References"
> 
> Quotations
> ==========
> 
> The essence of quotations is to provide nested colon definitions,
> in which the inner definition(s) are nameless. The expression
> 
> : foo ... [: some words ;] ... ;
> 
> is equivalent to
> 
> :noname some words ; Constant #temp#
> : foo ... #temp# ... ;
> 
> A simple quotation is an anonymous colon definition that is defined
> inside a colon definition or quotation.
> 
> Rationale
> ---------
> 
> There is no situation where quotations cannot be implemented by
> existing Forth words. Specifcially, :NONAME and : provide all the
> features proposed for quotations. Their advantage is as a syntactic
> "sugar" that permits a nameless definition in close proximity to its
> use; and that it avoids generating one-use names only for the purpose
> of refering to the definition inside another word.
> 
> One example use of quotations is to provide a solution to the use
> of CATCH in a form close to other languages' TRY ... EXCEPT
> blocks.
> 
> : foo ( i*x -- j*x )
>     setup
>     [: fee fi fo fum ;] catch
>     if ... then
>     teardown
>     ( throw again ) ;
> 
> Under the term "Phrases", quotations have been in MacForth since at
> least 1987. They are documented in the infamous "missing chapter" of
> the MacForth manual.
> 
> Implementations exist in (at least) VFX, Gforth and iForth, and in
> the iForth case appear to have some significant use and history.
> 
> Discussion
> ----------
> 
> If quotations are to have the same privileges as words defined with :
> and :NONAME they should be able to use local variables and use
> RECURSE and DOES>.
> 
> RECURSE: Recursion is defined as recursing to the start of the
> quotation, not the enclosing definition.
> 
> DOES>: As with a normal definition that closes the DOES> action with ;
> (semi-colon), a DOES> in a quotation is closed at the terminating ;]
> 
> While implementing support for DOES> and RECURSE, it has been
> proposed to remove the following inconsistency in the definition of 
> 6.1.2120 RECURSE; "An ambiguous condition exists if RECURSE appears in
> a definition after DOES>." The proposal is to remoive that sentence
> and permit a RECURSE to the start of the DOES> definition to be
> consistent with :NONAME : and the proposed [: .
> 
> The above features are illustrated here.
> 
> : foo create [: , does> @ dup if . recurse then ;] swap 0= ;
> ^A           ^B   ^C    ^x                      ^D         ^E
> 
> There are 3 definitions: A-E, B-D and C-D.
>  The definition of FOO is the code between A and E.
>  The quotation returned by executing FOO is the code between B and D
>  The DOES> clause is the code between C and D
> 
> RECURSE calls the code immediately after C (marked x) as it is the
> latest definition, and not the DOES> as it is consumed during
> compilation.
> 
> Locals: A quotation may not be able to access the locals of the outer
> word because it has no knowledge of when it might be executed and
> hence whether outer locals are still alive. It does permit defining and
> accessing its own locals.
> 
> : foo ... [: {: a b :} a b + ;] ... ; \ unambiguous
> : bar {: a b :} ... [: a b + ;] ... ; \ ambiguous
> 
> There has been some discussion about providing higher-order or
> embedded functions that are able to refer to their parent's locals
> during their execution. This is a middle ground between the proposal
> here and full closures that (almost always) require garbage
> collection, and it would permit execution of the quotation in the
> execution scope of the parent; in the BAR example above, if the
> quotation was executed prior to the return of BAR to its caller.
> 
> There are two schools of thought.
> 
> 1. Define [: ;] such that a standard program may not access
>    local variables of the outer definition inside the quotation.
> 
> 2. Permit such a feature, but restrict valid execution of the
>    quotation to the lifetime of the parent's execution.
> 
> Solution 2 requires some form of locals frame, and may be excessively
> complex to implement; it appears to have few advantages over
> the simpler quotations as proposed here.
> 
> Specification
> -------------
> 
> The following notations have been seen in the wild, oldest first.
>     :| ... |;
>     :[ ... ]:
>     [: ... ;]
>     
> The notation [: ;] appears to have popular support.
> 
> [: ( c: -- quotation-sys )
>   Interpretation: Interpretation semantics for this word are undefined.
>   Compilation: ( c: -- quotation-sys ) suspends compiling to the
>   current definition, starts a new nested definition, and compilation
>   continues with this nested definition. Locals may be defined in the
>   nested definition. It is an ambiguous condition [note 1] if outer
>   locals are visible and referred to in the nested definition.
> 
> ;] ( c: quotation-sys -- ) ( s: -- xt )
>   Interpretation: Interpretation semantics for this word are undefined.
>   Compilation: Ends the current nested definition, and resumes
>   compilation to the previous current definition. It appends the
>   following run-time to the current definition:
>   run-time: ( -- xt )
>   xt is the execution token to execute the nested definition.
> 
> 6.1.2120 RECURSE CORE
>   Interpretation: Interpretation semantics for this word are undefined.
>   Compilation: ( -- )
>   Append the execution semantics of the current definition to the
>   current definition.
>   See: 6.1.1250 DOES>, 6.1.2120 RECURSE, A.6.1.2120 RECURSE.
> 
> Implementation
> --------------
> 
> It is not possible to define quotations in ISO Forth. The following
> is an outline definition, where save-definition-state and restore-
> definition-state require carnal knowledge of the system and are left
> to the implementor.
> 
> : [: ( c: -- quotation-sys )
>   postpone ahead save-definition-state :noname ; immediate
> : ;] ( c: quotation-sys -- ) ( s: -- xt )
>   postpone ; >r restore-definition-state
>   postpone then r> postpone literal ; immediate
> 
> Compliance Tests
> ----------------
> 
> tbd
> 
> References
> ----------
> 
> Stephen Pelc wrote this; see
> 
> http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html
> 
> I (Alex McDonald) have taken it and modified it as a proposed RfD,
> and have removed the discussion of closures. http://www.forth200x.org/
> 
> The following notes on quotations and closures incorporate material
> from several people, including Anton Ertl, Andrew Haley, Marcel
> Hendrix, Ward Mcfarland, Bernd Paysan, and Elizabeth Rather. If you
> have been left out and want acknowledgement, please let me know.
> 
> Additional contributors; Hugh Aguilar and Gerry Jackson.
> 
> [Note 1]
> The phrase "ambiguous condition" has a specific meaning in Forth
> standards. An ambiguous condition is "a circumstance for which this
> standard does not prescribe a specific behavior". The RfD process
> also states: "If you want to leave something open to the system
> implementor, make that explicit, e.g., by making it an ambiguous
> condition."

<pedantry>
: foo ... [: some words ;] EXECUTE ... ; 

is equivalent to 

:noname some words ; Constant #temp# 
: foo ... #temp# ... ; 

(I added the word EXECUTE)
</pedantry>

[toc] | [prev] | [next] | [standalone]

#41090

Mark Wills wrote:
> <pedantry>
> : foo ... [: some words ;] EXECUTE ... ; 
>
> is equivalent to 
>
> :noname some words ; Constant #temp# 
> : foo ... #temp# ... ; 
>
> (I added the word EXECUTE)
> </pedantry>

And the second "foo"?

[toc] | [prev] | [next] | [standalone]

#41092

on 04/08/2015 12:35:34, Lars Brinkhoff wrote:
> Mark Wills wrote:
>> <pedantry>
>> : foo ... [: some words ;] EXECUTE ... ;
>>
>> is equivalent to
>>
>> :noname some words ; Constant #temp#
>> : foo ... #temp# ... ;
>>
>> (I added the word EXECUTE)
>> </pedantry>
> 
> And the second "foo"?
> 

The code is meant to demonstrate that the equivalent to a :NONAME
quotation has meaning outside of the enclosing definition. Neither needs
an EXECUTE.

[toc] | [prev] | [next] | [standalone]

#41093

on 04/08/2015 13:54:28, "Alex McDonald" wrote:
> on 04/08/2015 12:35:34, Lars Brinkhoff wrote:
>> Mark Wills wrote:
>>> <pedantry>
>>> : foo ... [: some words ;] EXECUTE ... ;
>>>
>>> is equivalent to
>>>
>>> :noname some words ; Constant #temp#
>>> : foo ... #temp# ... ;
>>>
>>> (I added the word EXECUTE)
>>> </pedantry>
>>
>> And the second "foo"?
>>
> 
> The code is meant to demonstrate that the equivalent to a :NONAME
> quotation has meaning outside of the enclosing definition. Neither
> needs an EXECUTE.

Sorry, that's one seriously tortured sentence. I sometimes don't write
what I mean, and don't read what I wrote. It should have said:

The code is meant to demonstrate that the imbedded quotation and an
externally defined :NONAME XT are equivalent.

[toc] | [prev] | [next] | [standalone]

#41091

on 04/08/2015 12:09:56, Mark Wills wrote:
> On Tuesday, 4 August 2015 11:05:55 UTC+1, Alex McDonald  wrote:

>> The essence of quotations is to provide nested colon definitions,
>> in which the inner definition(s) are nameless. The expression
>>
>> : foo ... [: some words ;] ... ;
>>
>> is equivalent to
>>
>> :noname some words ; Constant #temp#
>> : foo ... #temp# ... ;
>>

> 
> <pedantry>
>: foo ... [: some words ;] EXECUTE ... ;
> 
> is equivalent to
> 
>:noname some words ; Constant #temp#
>: foo ... #temp# ... ;
> 
> (I added the word EXECUTE)
> </pedantry>
> 

That's incorrect, and the original is correct. #TEMP# is a constant and
is not executed, but is returned from an execution of FOO.

[toc] | [prev] | [next] | [standalone]

#41096

On Tuesday, 4 August 2015 13:38:16 UTC+1, Alex McDonald  wrote:
> on 04/08/2015 12:09:56, Mark Wills wrote:
> > On Tuesday, 4 August 2015 11:05:55 UTC+1, Alex McDonald  wrote:
> 
> >> The essence of quotations is to provide nested colon definitions,
> >> in which the inner definition(s) are nameless. The expression
> >>
> >> : foo ... [: some words ;] ... ;
> >>
> >> is equivalent to
> >>
> >> :noname some words ; Constant #temp#
> >> : foo ... #temp# ... ;
> >>
> 
> > 
> > <pedantry>
> >: foo ... [: some words ;] EXECUTE ... ;
> > 
> > is equivalent to
> > 
> >:noname some words ; Constant #temp#
> >: foo ... #temp# ... ;
> > 
> > (I added the word EXECUTE)
> > </pedantry>
> > 
> 
> That's incorrect, and the original is correct. #TEMP# is a constant and
> is not executed, but is returned from an execution of FOO.

Ah of course. You're quite right. My bad. As you were!

[toc] | [prev] | [next] | [standalone]

#41095

"Alex McDonald" <blog@rivadpm.com> writes:
>Discussion
>----------
...
>: foo create [: , does> @ dup if . recurse then ;] swap 0= ;
>^A           ^B   ^C    ^x                      ^D         ^E
...
>RECURSE calls the code immediately after C (marked x) as it is the
>latest definition, and not the DOES> as it is consumed during
>compilation.
...
>Specification
>-------------
...
>6.1.2120 RECURSE CORE
>  Interpretation: Interpretation semantics for this word are undefined.
>  Compilation: ( –– )
>  Append the execution semantics of the current definition to the
>  current definition.

If that should have the effect described in the discussion, you need
to modify the compilation semantics of DOES> to specify that the DOES>
starts a new definition (currently this is stated only in the
rationale), e.g. as follows:

|6.1.1250 DOES> does CORE
|
|Compilation ( C: colon-sys1 -- colon-sys2 )
|
|Append the run-time semantics below to the current definition. Whether
|or not the current definition is rendered findable in the dictionary
|by the compilation of DOES> >>>or by the following ";"<<< is
|implementation defined.  >>>End the current definition and start a new
|definition<<<.  Consume colon-sys1 and produce colon-sys2. Append the
|initiation semantics given below to the current definition.

New stuff between >>> and <<<.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#41098

on 04/08/2015 15:23:19,  wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>>Discussion
>>----------
> ...
>>: foo create [: , does> @ dup if . recurse then ;] swap 0= ;
>>^A           ^B   ^C    ^x                      ^D         ^E
> ...
>>RECURSE calls the code immediately after C (marked x) as it is the
>>latest definition, and not the DOES> as it is consumed during
>>compilation.
> ...
>>Specification
>>-------------
> ...
>>6.1.2120 RECURSE CORE
>>  Interpretation: Interpretation semantics for this word are undefined.
>>  Compilation: ( –– )
>>  Append the execution semantics of the current definition to the
>>  current definition.
> 
> If that should have the effect described in the discussion, you need
> to modify the compilation semantics of DOES> to specify that the DOES>
> starts a new definition (currently this is stated only in the
> rationale), e.g. as follows:
> 
>|6.1.1250 DOES> does CORE
>|
>|Compilation ( C: colon-sys1 -- colon-sys2 )
>|
>|Append the run-time semantics below to the current definition. Whether
>|or not the current definition is rendered findable in the dictionary
>|by the compilation of DOES> >>>or by the following ";"<<< is
>|implementation defined.  >>>End the current definition and start a new
>|definition<<<.  Consume colon-sys1 and produce colon-sys2. Append the
>|initiation semantics given below to the current definition.
> 
> New stuff between >>> and <<<.
> 
> - anton

Noted.  

However, is this not preferable?

"End the current definition, allow it to be found in the dictionary, and
consume colon-sys1. Start a new definition, producing colon-sys2."

Rationale: definitions should have an XT, and if named definitions, it
should be findable at the end of a definition.

[toc] | [prev] | [next] | [standalone]

#41100

"Alex McDonald" <blog@rivadpm.com> writes:
>However, is this not preferable?
>
>"End the current definition, allow it to be found in the dictionary, and
>consume colon-sys1. Start a new definition, producing colon-sys2."

Looks good to me.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#41105

Anton Ertl wrote:

> "Alex McDonald" <blog@rivadpm.com> writes:
>>However, is this not preferable?
>>
>>"End the current definition, allow it to be found in the dictionary, and
>>consume colon-sys1. Start a new definition, producing colon-sys2."
> 
> Looks good to me.

Also allows to write the rare case where RECURSE after DOES> really meant 
calling the creator again.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41108

on 04/08/2015 21:30:05, Bernd Paysan wrote:
> Anton Ertl wrote:
> 
>> "Alex McDonald" <blog@rivadpm.com> writes:
>>>However, is this not preferable?
>>>
>>>"End the current definition, allow it to be found in the dictionary, and
>>>consume colon-sys1. Start a new definition, producing colon-sys2."
>>
>> Looks good to me.
> 
> Also allows to write the rare case where RECURSE after DOES> really
> meant calling the creator again.
> 

I may have stumbled across a problem where quotation-sys has to be the
equivalent to colon-sys, as DOES> has to cope with both.

: foo does> ; 
: bar [: does> ;] ; 

FOO DOES> has to handle ( colon-sys1 -- colon-sys2 ). BAR has to
accomodate ( quot-sys1 -- quot-sys2 ). We have ( -- orig ) somewhere on
the stack after [: but not after : .

It is possible but tricky. To make all x-sys orig and dest etc the same
size to support CS-ROLL and CS-PICK I require 5 cells (!!!)

[toc] | [prev] | [next] | [standalone]

#41111

Alex McDonald wrote:

> on 04/08/2015 21:30:05, Bernd Paysan wrote:
>> Anton Ertl wrote:
>> 
>>> "Alex McDonald" <blog@rivadpm.com> writes:
>>>>However, is this not preferable?
>>>>
>>>>"End the current definition, allow it to be found in the dictionary, and
>>>>consume colon-sys1. Start a new definition, producing colon-sys2."
>>>
>>> Looks good to me.
>> 
>> Also allows to write the rare case where RECURSE after DOES> really
>> meant calling the creator again.
>> 
> 
> I may have stumbled across a problem where quotation-sys has to be the
> equivalent to colon-sys, as DOES> has to cope with both.
> 
> : foo does> ;
> : bar [: does> ;] ;
> 
> FOO DOES> has to handle ( colon-sys1 -- colon-sys2 ). BAR has to
> accomodate ( quot-sys1 -- quot-sys2 ). We have ( -- orig ) somewhere on
> the stack after [: but not after : .
> 
> It is possible but tricky. To make all x-sys orig and dest etc the same
> size to support CS-ROLL and CS-PICK I require 5 cells (!!!)

If we specify DOES> explicitely to end one definition and start another, 
quot-sys should be really a ( nest-sys colon-sys ) tuple.  Then DOES> can do 
a ( colon-sys1 -- colon-sys2 ) inside a quotation.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41116

Bernd Paysan <bernd.paysan@gmx.de> writes:
>If we specify DOES> explicitely to end one definition and start another, 
>quot-sys should be really a ( nest-sys colon-sys ) tuple.  Then DOES> can do 
>a ( colon-sys1 -- colon-sys2 ) inside a quotation.

Yes, but call it wrap-sys or something, because nest-sys has a
different meaning (it is the return address).

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#41121

on 05/08/2015 08:23:42,  wrote:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>If we specify DOES> explicitely to end one definition and start another,
>>quot-sys should be really a ( nest-sys colon-sys ) tuple.  Then DOES> can do
>>a ( colon-sys1 -- colon-sys2 ) inside a quotation.
> 
> Yes, but call it wrap-sys or something, because nest-sys has a
> different meaning (it is the return address).
> 
> - anton

Both noted. Thanks.

[toc] | [prev] | [next] | [standalone]

#41123

On 04/08/2015 21:30, Bernd Paysan wrote:
> Anton Ertl wrote:
>
>> "Alex McDonald" <blog@rivadpm.com> writes:
>>> However, is this not preferable?
>>>
>>> "End the current definition, allow it to be found in the dictionary, and
>>> consume colon-sys1. Start a new definition, producing colon-sys2."
>>
>> Looks good to me.
>
> Also allows to write the rare case where RECURSE after DOES> really meant
> calling the creator again.
>

I'm not sure I agree with "allow it to be found in the dictionary". It 
would break code that redefines a word and calls the original definition 
after the DOES> e.g.

: foo ... ;
...
: foo create ... does> ... foo ... ;

With the above change that becomes recursive rather than calling the 
first foo.

I would guess that the occurrence of such cases is unlikely.
-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#41126

on 05/08/2015 12:03:10, Gerry Jackson wrote:
> On 04/08/2015 21:30, Bernd Paysan wrote:
>> Anton Ertl wrote:
>>
>>> "Alex McDonald" <blog@rivadpm.com> writes:
>>>> However, is this not preferable?
>>>>
>>>> "End the current definition, allow it to be found in the dictionary, and
>>>> consume colon-sys1. Start a new definition, producing colon-sys2."
>>>
>>> Looks good to me.
>>
>> Also allows to write the rare case where RECURSE after DOES> really meant
>> calling the creator again.
>>
> 
> I'm not sure I agree with "allow it to be found in the dictionary". It
> would break code that redefines a word and calls the original
> definition after the DOES> e.g.
> 
>: foo ... ;
> ...
>: foo create ... does> ... foo ... ;
> 
> With the above change that becomes recursive rather than calling the
> first foo.
> 
> I would guess that the occurrence of such cases is unlikely.

It also wouldn't be a standard program as currently understood since that
code utilises an ambiguous condition. Although I guess most compilers do
REVEAL or UNHIDE or whatever at the terminating semi-colon ; 

[toc] | [prev] | [next] | [standalone]

#41130

"Alex McDonald" <blog@rivadpm.com> writes:
>on 05/08/2015 12:03:10, Gerry Jackson wrote:
>>: foo ... ;
>> ...
>>: foo create ... does> ... foo ... ;
>> 
>> With the above change that becomes recursive rather than calling the
>> first foo.
>> 
>> I would guess that the occurrence of such cases is unlikely.
>
>It also wouldn't be a standard program as currently understood since that
>code utilises an ambiguous condition.

Nitpick: This is one of the few cases that is "implementation-defined"
rather than "ambiguous".  Not that it makes a difference for the issue
at hand.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

[toc] | [prev] | [next] | [standalone]

#41133

On 05/08/2015 13:50, Alex McDonald wrote:
> on 05/08/2015 12:03:10, Gerry Jackson wrote:
>> On 04/08/2015 21:30, Bernd Paysan wrote:
>>> Anton Ertl wrote:
>>>
>>>> "Alex McDonald" <blog@rivadpm.com> writes:
>>>>> However, is this not preferable?
>>>>>
>>>>> "End the current definition, allow it to be found in the dictionary, and
>>>>> consume colon-sys1. Start a new definition, producing colon-sys2."
>>>>
>>>> Looks good to me.
>>>
>>> Also allows to write the rare case where RECURSE after DOES> really meant
>>> calling the creator again.
>>>
>>
>> I'm not sure I agree with "allow it to be found in the dictionary". It
>> would break code that redefines a word and calls the original
>> definition after the DOES> e.g.
>>
>> : foo ... ;
>> ...
>> : foo create ... does> ... foo ... ;
>>
>> With the above change that becomes recursive rather than calling the
>> first foo.
>>
>> I would guess that the occurrence of such cases is unlikely.
>
> It also wouldn't be a standard program as currently understood since that
> code utilises an ambiguous condition. Although I guess most compilers do
> REVEAL or UNHIDE or whatever at the terminating semi-colon ;
>

Sorry, I overlooked that 'implementation defined' part of the DOES> 
specification.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#41103

Alex McDonald wrote:

> There are two schools of thought.
> 
> 1. Define [: ;] such that a standard program may not access
> local variables of the outer definition inside the quotation.
> 
> 2. Permit such a feature, but restrict valid execution of the
> quotation to the lifetime of the parent's execution.

I've found more problems with 2.  A lot of my quotation use (especially in 
MINOS) requires that the quotation outlives the lifetime of the parents.

Essentially, I create objects with actions attached (action = xt).  So the 
object initialization takes one or more xts.  These xts are quotations.  If 
we allow access to outer locals via local frames, we, at the same time, 
would disallow this use, because the local frame dies when the creator of 
the quotation exits (unless it is a real closure)

Typical use comes from converting Leo Brodie's DOER MAKE examples into 
DEFER/IS/quotations examples:

Defer type  ( a # -- )
: video   [: ( ...code for video...) ;] is type ;
: printer [: ( ...code for printer...) ;] is type ;

This only works if the quotation outlives its surrounding definition.  So it 
has to be either a real closure (with garbage collection and everything) if 
it can access outer locals, or it may not access outer locals.

I'm not against real closures, but would strongly advice *not* to use the 
normal locals and quotation syntax for closures.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web