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

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

Re: CfV: Quotations

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: CfV: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-08-31 15:15 +0100
    Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-31 15:26 +0000
      Re: CfV: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-02 22:33 +0100
        Re: CfV: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-03 06:47 +0000

#50576 — Re: CfV: Quotations

On 10/08/2016 17:52, Anton Ertl wrote:
> Specification
> -------------
>
> New system-compilation type quotation-sys with an
> implementation-dependent size on the stack.  This type contains the
> data that needs to be saved for the enclosing colon definition and
> restored after the end of the quotation.  [Note: we use it in
> combination with colon-sys, because DOES> uses colon-sys during
> compilation.]
>
> [:         bracket-colon
>    Interpretation: Interpretation semantics for this word are undefined.
>
>    Compilation: ( -- quotation-sys colon-sys )

shouldn't this be
      Compilation: ( C: -- quotation-sys )
Why mention the colon-sys? There may be other control-flow items on the 
control-flow stack between the outer definition, which may be a colon 
definition or a quotation, and the quotation-sys. Similarly the 
specification for ;]

>
>    suspends compiling to the current definition, starts a new nested
>    definition with execution token xt, and compilation continues with
                      ^^^^^^^^^^^^^^^^^^
An execution token is not mentioned above, so why mention it here. It is 
sufficient and better to leave it as quotation-sys which may, of course, 
contain the xt. If an xt was specified, as with :NONAME, my system would 
have a problem with xt values with nested quotations e.g.

: foo [: ... [: ( -- xt1 ) .... ;] ( -- xt2 ) ... ;] ...;

because during compilation xt1 = xt2 because no executable code has been 
saved, the xt's are made correct when the terminating ;]'s are executed.

>    this nested definition. Locals may be defined in the nested
>    definition.  An ambiguous condition exists if a name is used that
>    satisfies the following constraints: 1) It is not the name of a
>    currently visible local of the current quotation.  2) It is the name
>    of a local that was visible right before the start of the present
>    quotation or any of the containing quotations.

I don't see a good reason why the specification for :NONAME states that 
it leaves an xt on the data stack as that constrains an implementation - 
it would be better to leave a noname-sys on the control stack. It is not 
easy for a user to access the xt during compilation so why not leave it 
open for system implementers. I realise it would slightly complicate the 
specification of ; because that would have to be changed to leave an xt 
at the end of a :NONAME definition.

-- 
Gerry

[toc] | [next] | [standalone]

#50578

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 10/08/2016 17:52, Anton Ertl wrote:
>> Specification
>> -------------
>>
>> New system-compilation type quotation-sys with an
>> implementation-dependent size on the stack.  This type contains the
>> data that needs to be saved for the enclosing colon definition and
>> restored after the end of the quotation.  [Note: we use it in
>> combination with colon-sys, because DOES> uses colon-sys during
>> compilation.]
>>
>> [:         bracket-colon
>>    Interpretation: Interpretation semantics for this word are undefined.
>>
>>    Compilation: ( -- quotation-sys colon-sys )
>
>shouldn't this be
>      Compilation: ( C: -- quotation-sys )
>Why mention the colon-sys?

As mentioned, above, because of DOES>.  I.e., the CfV proposes that

[: ... does> ... ;]

works, and because DOES> consumes a colon-sys and produces another
one, we have to have a colon-sys on the stack.

As for the C:, it is as redundant as the F:.  Control-flow stack items
always go on the control-flow stack, and floating-point values always
go on the FP stack.

> There may be other control-flow items on the 
>control-flow stack between the outer definition, which may be a colon 
>definition or a quotation, and the quotation-sys.

Sure, but they are below the quotation-sys, are not changed by [: or
;], and therefore don't play a role here.

>>    suspends compiling to the current definition, starts a new nested
>>    definition with execution token xt, and compilation continues with
>                      ^^^^^^^^^^^^^^^^^^
>An execution token is not mentioned above, so why mention it here.

To make it clear that this is the xt that is referred to below, in the
run-time semantics of ;].  Maybe that is not the best way to write it,
and maybe we will find a better way in the wordsmithing that's usually
done at the meeting, but I hope that's clear enough for CfV purposes.
However, if you have a problem with the way this is written, it's good
to point that out now, so that the chances are better that the
committee will not miss the point.

> It is 
>sufficient and better to leave it as quotation-sys which may, of course, 
>contain the xt. If an xt was specified, as with :NONAME, my system would 
>have a problem with xt values with nested quotations e.g.
>
>: foo [: ... [: ( -- xt1 ) .... ;] ( -- xt2 ) ... ;] ...;
>
>because during compilation xt1 = xt2 because no executable code has been 
>saved, the xt's are made correct when the terminating ;]'s are executed.

Actually the way it is specified does not make the xt explicit on the
stack, so that would not be a problem for your system.

>I don't see a good reason why the specification for :NONAME states that 
>it leaves an xt on the data stack as that constrains an implementation - 
>it would be better to leave a noname-sys on the control stack. It is not 
>easy for a user to access the xt during compilation so why not leave it 
>open for system implementers. I realise it would slightly complicate the 
>specification of ; because that would have to be changed to leave an xt 
>at the end of a :NONAME definition.

So here you have the answer.

Of course, as you point out, programs have a hard time to make access
of that xt before the ";", and are therefore unlikely to do that, so
you could declare an environmental restriction that disallows such
usage, and probably you would still be able to run most standard
programs that are out there.

- 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 2016: http://www.euroforth.org/ef16/

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

#50629

On 31/08/2016 16:26, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 10/08/2016 17:52, Anton Ertl wrote:
>>> Specification
>>> -------------
>>>
>>> New system-compilation type quotation-sys with an
>>> implementation-dependent size on the stack.  This type contains the
>>> data that needs to be saved for the enclosing colon definition and
>>> restored after the end of the quotation.  [Note: we use it in
>>> combination with colon-sys, because DOES> uses colon-sys during
>>> compilation.]
>>>
>>> [:         bracket-colon
>>>     Interpretation: Interpretation semantics for this word are undefined.
>>>
>>>     Compilation: ( -- quotation-sys colon-sys )
>>
>> shouldn't this be
>>       Compilation: ( C: -- quotation-sys )
>> Why mention the colon-sys?
>
> As mentioned, above, because of DOES>.  I.e., the CfV proposes that
>
> [: ... does> ... ;]
>
> works, and because DOES> consumes a colon-sys and produces another
> one, we have to have a colon-sys on the stack.
>
> As for the C:, it is as redundant as the F:.  Control-flow stack items
> always go on the control-flow stack, and floating-point values always
> go on the FP stack.
>
>> There may be other control-flow items on the
>> control-flow stack between the outer definition, which may be a colon
>> definition or a quotation, and the quotation-sys.
>
> Sure, but they are below the quotation-sys, are not changed by [: or
> ;], and therefore don't play a role here.

Sorry my mistake, I misunderstood something.

>
>>>     suspends compiling to the current definition, starts a new nested
>>>     definition with execution token xt, and compilation continues with
>>                       ^^^^^^^^^^^^^^^^^^
>> An execution token is not mentioned above, so why mention it here.
>
> To make it clear that this is the xt that is referred to below, in the
> run-time semantics of ;].  Maybe that is not the best way to write it,
> and maybe we will find a better way in the wordsmithing that's usually
> done at the meeting, but I hope that's clear enough for CfV purposes.
> However, if you have a problem with the way this is written, it's good
> to point that out now, so that the chances are better that the
> committee will not miss the point.
>
>> It is
>> sufficient and better to leave it as quotation-sys which may, of course,
>> contain the xt. If an xt was specified, as with :NONAME, my system would
>> have a problem with xt values with nested quotations e.g.
>>
>> : foo [: ... [: ( -- xt1 ) .... ;] ( -- xt2 ) ... ;] ...;
>>
>> because during compilation xt1 = xt2 because no executable code has been
>> saved, the xt's are made correct when the terminating ;]'s are executed.
>
> Actually the way it is specified does not make the xt explicit on the
> stack, so that would not be a problem for your system.

Yes I realised that, I just don't want an xt introduced in the stack 
diagram of [:. Perhaps just add a few words to say the run-time xt given 
by ;].

>
>> I don't see a good reason why the specification for :NONAME states that
>> it leaves an xt on the data stack as that constrains an implementation -
>> it would be better to leave a noname-sys on the control stack. It is not
>> easy for a user to access the xt during compilation so why not leave it
>> open for system implementers. I realise it would slightly complicate the
>> specification of ; because that would have to be changed to leave an xt
>> at the end of a :NONAME definition.
>
> So here you have the answer.

It's not very difficult to change ; to only leave an xt if terminating a 
:NONAME definition with an optional intervening DOES>

>
> Of course, as you point out, programs have a hard time to make access
> of that xt before the ";", and are therefore unlikely to do that, so
> you could declare an environmental restriction that disallows such
> usage, and probably you would still be able to run most standard
> programs that are out there.
>
> - anton
>


-- 
Gerry

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

#50634

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 31/08/2016 16:26, Anton Ertl wrote:
>> Actually the way it is specified does not make the xt explicit on the
>> stack, so that would not be a problem for your system.
>
>Yes I realised that, I just don't want an xt introduced in the stack 
>diagram of [:. Perhaps just add a few words to say the run-time xt given 
>by ;].

It is not in the stack diagram of "[:".  I'll present your concern if
somebody proposes adding it to the stack diagram of "[:" in the
committee (but I think that is unlikely).

>>> I don't see a good reason why the specification for :NONAME states that
>>> it leaves an xt on the data stack as that constrains an implementation -
>>> it would be better to leave a noname-sys on the control stack. It is not
>>> easy for a user to access the xt during compilation so why not leave it
>>> open for system implementers. I realise it would slightly complicate the
>>> specification of ; because that would have to be changed to leave an xt
>>> at the end of a :NONAME definition.
>>
>> So here you have the answer.
>
>It's not very difficult to change ; to only leave an xt if terminating a 
>:NONAME definition with an optional intervening DOES>

It may not be difficult to change in your private copy, but changing
it in the standard is a bit more involved.  It starts with a proposal,
and nobody has written one yet.  Also, in cases like this where a
feature that programs might rely on would be de-standardized, it takes
one standard period where the feature is still in the standard, but
obsolescent.

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [standalone]

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

csiph-web