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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#41104

on 04/08/2015 21:00:43, Bernd Paysan wrote:
> 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.
> 

Agreed. Even though I can support (2), I would vote against it on the
grounds that it's not generalyy useful, and it's expensive to implement.

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

#41106

On 04/08/2015 11:05, Alex McDonald wrote:
> 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.

I would rather it was defined and equivalent to :noname. It's easy 
enough to implement.


-- 
Gerry

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

#41109

on 04/08/2015 21:53:42, Gerry Jackson wrote:
> On 04/08/2015 11:05, Alex McDonald wrote:
>> 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.
> 
> I would rather it was defined and equivalent to :noname. It's easy
> enough to implement.
> 
> 

Would that obsolete :NONAME? If so, I think we should do it.


 

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

#41124

On 04/08/2015 23:22, Alex McDonald wrote:
> on 04/08/2015 21:53:42, Gerry Jackson wrote:
>> On 04/08/2015 11:05, Alex McDonald wrote:
>>> 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.
>>
>> I would rather it was defined and equivalent to :noname. It's easy
>> enough to implement.
>>
>>
>
> Would that obsolete :NONAME? If so, I think we should do it.
>

I'd support that. Despite much use of it I have never liked the name :NONAME

-- 
Gerry

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

#41125

on 05/08/2015 12:38:26, Gerry Jackson wrote:
> On 04/08/2015 23:22, Alex McDonald wrote:
>> on 04/08/2015 21:53:42, Gerry Jackson wrote:
>>> On 04/08/2015 11:05, Alex McDonald wrote:
>>>> 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.
>>>
>>> I would rather it was defined and equivalent to :noname. It's easy
>>> enough to implement.
>>>
>>>
>>
>> Would that obsolete :NONAME? If so, I think we should do it.
>>
> 
> I'd support that. Despite much use of it I have never liked the name
> :NONAME
> 

I'm minded to heed Anton's admonition that there are more than enough
state-aware words, and that we shouldn't be inventing another. I can't
write an immediate definition for [: . Since Anton didn't offer up an
example either, and he's smarter than your average bear, I suspect it may
not be possible.

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

#41127

"Alex McDonald" <blog@rivadpm.com> writes:
>I'm minded to heed Anton's admonition that there are more than enough
>state-aware words, and that we shouldn't be inventing another. I can't
>write an immediate definition for [: . Since Anton didn't offer up an
>example either, and he's smarter than your average bear, I suspect it may
>not be possible.

When I made the suggestion, I thought that it is possible, but on more
thought, I don't think it is, because the compilation semantics of [:
... ;] appends the xt to the current definition, and we would not want
that as interpretation semantics; instead, we want the interpretation
semantics to push the xt on the stack.  The solution in other such
cases is to use a recognizer, but I am not sure if that can work here;
the recognizer would have to call the text interpreter and consume
several lines.

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

#41136

Anton Ertl wrote:
> When I made the suggestion, I thought that it is possible, but on more
> thought, I don't think it is, because the compilation semantics of [:
> ... ;] appends the xt to the current definition, and we would not want
> that as interpretation semantics; instead, we want the interpretation
> semantics to push the xt on the stack.  The solution in other such
> cases is to use a recognizer, but I am not sure if that can work here;
> the recognizer would have to call the text interpreter and consume
> several lines.

No, that's too ugly for a recognizer... a recognizer should not do REFILL.

[: ;] for both interpretation and compilation have two parts: [: needs to be 
in some way state-aware (dual-xt, state-smart, whatever), and push a flag in 
wrap-sys so that ;] knows the state before [:, and acts accordingly.

Unlike :noname ; IMHO an interpretative [: ;] should revert the previous 
definition to be current.  I.e.

: bla do something ;
[: compile something ;] set-compiler

should assign the quotation to bla, not to itself, which :noname ... ; 
should do.

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

#41143

on 06/08/2015 01:12:51, Bernd Paysan wrote:
> Anton Ertl wrote:
>> When I made the suggestion, I thought that it is possible, but on more
>> thought, I don't think it is, because the compilation semantics of [:
>> ... ;] appends the xt to the current definition, and we would not want
>> that as interpretation semantics; instead, we want the interpretation
>> semantics to push the xt on the stack.  The solution in other such
>> cases is to use a recognizer, but I am not sure if that can work here;
>> the recognizer would have to call the text interpreter and consume
>> several lines.
> 
> No, that's too ugly for a recognizer... a recognizer should not do
> REFILL.

Agreed.

> 
> [: ;] for both interpretation and compilation have two parts: [: needs
> to be in some way state-aware (dual-xt, state-smart, whatever), and
> push a flag in wrap-sys so that ;] knows the state before [:, and acts
> accordingly.

That state-ness of [: is the issue. 

> 
> Unlike :noname ; IMHO an interpretative [: ;] should revert the
> previous definition to be current.  I.e.
> 
>: bla do something ;
> [: compile something ;] set-compiler
> 
> should assign the quotation to bla, not to itself, which :noname ... ;
> should do.
> 

AFAIK there are no words in the standard that act like SET-COMPILE (i.e.
know the last word defined) with the exception of IMMEDIATE. Yes, I know
a number of compilers support such a feature, but that doesn't make it
desirable.

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

#41145

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> When I made the suggestion, I thought that it is possible, but on more
>> thought, I don't think it is, because the compilation semantics of [:
>> ... ;] appends the xt to the current definition, and we would not want
>> that as interpretation semantics; instead, we want the interpretation
>> semantics to push the xt on the stack.  The solution in other such
>> cases is to use a recognizer, but I am not sure if that can work here;
>> the recognizer would have to call the text interpreter and consume
>> several lines.
>
>No, that's too ugly for a recognizer... a recognizer should not do REFILL.

My intuition certainly is that recognizers should be for what is
lexically one word, but already strings defeat this, and maybe we want
to support multi-line strings, too.

Anyway, a recognizer for [: ... ;] does not feel right, but for me the
call to the text interpreter is more of a problem than the REFILL; it
would subvert the Forth-94 principle of not nesting text interpreters
when interpreting from one input source (unlike "]" in some Forth
systems).

One could have just [: as a recognizer, to make use of its combination
of parse-time and run-time actions, but that does not feel right,
either.  My idea of a recognizer is that it acts as an automatically
defined word, and somehow [: does not quite fit that; maybe an
implicit literal with the additional effect of starting the
definition.

>Unlike :noname ; IMHO an interpretative [: ;] should revert the previous 
>definition to be current.  I.e.
>
>: bla do something ;
>[: compile something ;] set-compiler
>
>should assign the quotation to bla, not to itself, which :noname ... ; 
>should do.

Should :NONAME do that?  SET-COMPILER is not standardized, so one
could easily have :NONAME preserve the state that SET-COMPILER relies
on.  Two cases involving standard words are:

: foo does> ... ;
create x
:noname ... ; foo

is an ambiguous condition, so a system could decide to let DOES> act
on the last non-:NONAME word.

:noname ... ; immediate

Here the IMMEDIATE has no effect, so this probably does not occur in
real-world programs.

So we can probably change :NONAME ... ; to behave as you want
interpretive [: ... ;] to behave.  Alternatively, have something like
[{ ... }] to explicitly save and restore that state.

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

#41118

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 04/08/2015 11:05, Alex McDonald wrote:
>> 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.
>
>I would rather it was defined and equivalent to :noname.

If so, I would like to see a specification where interpretation
semantics and compilation semantics are the same (i.e., an immediate
word).  We don't need another word with non-default non-immediate
compilation semantics.

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

#41134

On 05/08/2015 09:15, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 04/08/2015 11:05, Alex McDonald wrote:
>>> 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.
>>
>> I would rather it was defined and equivalent to :noname.
>
> If so, I would like to see a specification where interpretation
> semantics and compilation semantics are the same (i.e., an immediate
> word).  We don't need another word with non-default non-immediate
> compilation semantics.
>
> - anton
>

I don't want to trigger another long discussion about words with 
non-default non-immediate compilation semantics as previous discussions 
have left me a bit confused. But I thought the problem was with words 
that parsed such as S". Can you give an example of code that would fail 
if [: was equivalent to :NONAME

-- 
Gerry

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

#41135

On Wednesday, 5 August 2015 21:31:42 UTC+2, Gerry  wrote:
> On 05/08/2015 09:15, Anton Ertl wrote:
> > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> >> On 04/08/2015 11:05, Alex McDonald wrote:
> >>> 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.
> >>
> >> I would rather it was defined and equivalent to :noname.
> >
> > If so, I would like to see a specification where interpretation
> > semantics and compilation semantics are the same (i.e., an immediate
> > word).  We don't need another word with non-default non-immediate
> > compilation semantics.
> >
> > - anton
> >
> 
> I don't want to trigger another long discussion about words with 
> non-default non-immediate compilation semantics as previous discussions 
> have left me a bit confused. But I thought the problem was with words 
> that parsed such as S". Can you give an example of code that would fail 
> if [: was equivalent to :NONAME
> 
> -- 
> Gerry

You could do the other way around, rename [: to [:NONAME and you have a
nice symmetry like [CHAR] and CHAR

:NONAME      ;       interpreting
[:NONAME     ;]      compiling

But honestly I have never liked :NONAME either, cam we find a better
name like :# and [:# ?

With some state-smartness it was no problem making [: and ;] work
also while interpreting

Peter

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

#41139

On 8/5/15 11:41 AM, peter.m.falth@gmail.com wrote:
> On Wednesday, 5 August 2015 21:31:42 UTC+2, Gerry  wrote:
>> On 05/08/2015 09:15, Anton Ertl wrote:
>>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>>> On 04/08/2015 11:05, Alex McDonald wrote:
>>>>> 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.
>>>>
>>>> I would rather it was defined and equivalent to :noname.
>>>
>>> If so, I would like to see a specification where interpretation
>>> semantics and compilation semantics are the same (i.e., an immediate
>>> word).  We don't need another word with non-default non-immediate
>>> compilation semantics.
>>>
>>> - anton
>>>
>>
>> I don't want to trigger another long discussion about words with
>> non-default non-immediate compilation semantics as previous discussions
>> have left me a bit confused. But I thought the problem was with words
>> that parsed such as S". Can you give an example of code that would fail
>> if [: was equivalent to :NONAME
>>
>> --
>> Gerry
>
> You could do the other way around, rename [: to [:NONAME and you have a
> nice symmetry like [CHAR] and CHAR
>
> :NONAME      ;       interpreting
> [:NONAME     ;]      compiling
>
> But honestly I have never liked :NONAME either, cam we find a better
> name like :# and [:# ?

:NONAME is a pretty ugly name, but in Forth the symbol # suggests 
numbers (as in <# # #S #> ). If you're going to do this stuff, [: and ;] 
aren't bad names.

> With some state-smartness it was no problem making [: and ;] work
> also while interpreting

Does that mean you could get rid of :NONAME?

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#41140

On Thursday, 6 August 2015 06:39:23 UTC+2, Elizabeth D. Rather  wrote:
> On 8/5/15 11:41 AM, peter.m.falth@gmail.com wrote:
> > On Wednesday, 5 August 2015 21:31:42 UTC+2, Gerry  wrote:
> >> On 05/08/2015 09:15, Anton Ertl wrote:
> >>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> >>>> On 04/08/2015 11:05, Alex McDonald wrote:
> >>>>> 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.
> >>>>
> >>>> I would rather it was defined and equivalent to :noname.
> >>>
> >>> If so, I would like to see a specification where interpretation
> >>> semantics and compilation semantics are the same (i.e., an immediate
> >>> word).  We don't need another word with non-default non-immediate
> >>> compilation semantics.
> >>>
> >>> - anton
> >>>
> >>
> >> I don't want to trigger another long discussion about words with
> >> non-default non-immediate compilation semantics as previous discussions
> >> have left me a bit confused. But I thought the problem was with words
> >> that parsed such as S". Can you give an example of code that would fail
> >> if [: was equivalent to :NONAME
> >>
> >> --
> >> Gerry
> >
> > You could do the other way around, rename [: to [:NONAME and you have a
> > nice symmetry like [CHAR] and CHAR
> >
> > :NONAME      ;       interpreting
> > [:NONAME     ;]      compiling
> >
> > But honestly I have never liked :NONAME either, cam we find a better
> > name like :# and [:# ?

Maybe :XT and [:XT

> 
> :NONAME is a pretty ugly name, but in Forth the symbol # suggests 
> numbers (as in <# # #S #> ). If you're going to do this stuff, [: and ;] 
> aren't bad names.
> 
> > With some state-smartness it was no problem making [: and ;] work
> > also while interpreting
> 
> Does that mean you could get rid of :NONAME?
> 

No not really, as [: is immediate it can not be used inside a definition
like :NONAME. Best solution is to find a better name to :NONAME

Honestly this is nothing I am interested to use myself. If the only difference
as stated in the RFD is to remove some definition names I prefer the names
and some ['] in the code instead of mixing 2 definitions into one.

Peter

> Cheers,
> Elizabeth
> 
> -- 
> ==================================================
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> FORTH Inc.                         +1 310.999.6784
> 5959 West Century Blvd. Suite 700
> Los Angeles, CA 90045
> http://www.forth.com
> 
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

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

#41144

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>I don't want to trigger another long discussion about words with 
>non-default non-immediate compilation semantics as previous discussions 
>have left me a bit confused. But I thought the problem was with words 
>that parsed such as S". Can you give an example of code that would fail 
>if [: was equivalent to :NONAME

The usual things:

\ 1)
: comp-[: postpone [: ; \ compilation semantics
: foo [ comp-[: ." hello" ;] ] ;
foo execute \ should print "hello"

\ 2)
: [int-[:] ['] [: execute ; immediate \ interpretation semantics
] [int-[:] ." hello" ;] [ execute \ should print "hello"

\ 3)
: compile, compile, ; \ give it proper interpretation semantics
: int-[: [ ' [: compile, ] ; \ interpretation semantics
int-[: ." hello ;] execute \ should print "hello"

1) and 2) fail on state-smart implementations of [:.  3) fails on an
implementation that implements non-default non-immediate compilation
semantics by misusing SET-COMPILER.

If we want these kinds of words, we should go for the implementation
techniques (i.e., dual-xt) that allow to implement them properly, even
in corner cases.  Alternatively, if we don't want to require systems
to use these implementation techniques, we should refrain from
specifying any more such words, and work on getting rid of the current
crop of such words.

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

#41173

On 06/08/2015 14:19, Anton Ertl wrote:
>> Can you give an example of code that would fail
>> >if [: was equivalent to :NONAME
> The usual things:
>
> \ 1)
> : comp-[: postpone [: ; \ compilation semantics
> : foo [ comp-[: ." hello" ;] ] ;
> foo execute \ should print "hello"
>
> \ 2)
> : [int-[:] ['] [: execute ; immediate \ interpretation semantics
> ] [int-[:] ." hello" ;] [ execute \ should print "hello"
>
> \ 3)
> : compile, compile, ; \ give it proper interpretation semantics
> : int-[: [ ' [: compile, ] ; \ interpretation semantics
> int-[: ." hello ;] execute \ should print "hello"
>
> 1) and 2) fail on state-smart implementations of [:.  3) fails on an
> implementation that implements non-default non-immediate compilation
> semantics by misusing SET-COMPILER.

Assuming your example 3 has a missing " after <." hello> my system works 
for 1 and 3 but for 2 it doesn't leave an xt on the stack to be 
EXECUTEd. That's because I hadn't allowed for ] to be executed before a 
quotation. But then my implementation isn't state-smart, it's just 
inadequate for example 2.

-- 
Gerry

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

#41174

On 07/08/2015 22:28, Gerry Jackson wrote:
> On 06/08/2015 14:19, Anton Ertl wrote:
>>> Can you give an example of code that would fail
>>> >if [: was equivalent to :NONAME
>> The usual things:
>>
>> \ 1)
>> : comp-[: postpone [: ; \ compilation semantics
>> : foo [ comp-[: ." hello" ;] ] ;
>> foo execute \ should print "hello"
>>
>> \ 2)
>> : [int-[:] ['] [: execute ; immediate \ interpretation semantics
>> ] [int-[:] ." hello" ;] [ execute \ should print "hello"
>>
>> \ 3)
>> : compile, compile, ; \ give it proper interpretation semantics
>> : int-[: [ ' [: compile, ] ; \ interpretation semantics
>> int-[: ." hello ;] execute \ should print "hello"
>>
>> 1) and 2) fail on state-smart implementations of [:.  3) fails on an
>> implementation that implements non-default non-immediate compilation
>> semantics by misusing SET-COMPILER.
>
> Assuming your example 3 has a missing " after <." hello> my system works
> for 1 and 3 but for 2 it doesn't leave an xt on the stack to be
> EXECUTEd. That's because I hadn't allowed for ] to be executed before a
> quotation. But then my implementation isn't state-smart, it's just
> inadequate for example 2.
>

Sorry I meant to add. Apart from trying to prove that a system is 
non-standard, why, in practice, would anybody write code such as
] foo bar baz [
when in interpreter mode outside a colon definition.

-- 
Gerry

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

#41211

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 07/08/2015 22:28, Gerry Jackson wrote:
>> On 06/08/2015 14:19, Anton Ertl wrote:
>>> \ 2)
>>> : [int-[:] ['] [: execute ; immediate \ interpretation semantics
>>> ] [int-[:] ." hello" ;] [ execute \ should print "hello"
...
>Sorry I meant to add. Apart from trying to prove that a system is 
>non-standard, why, in practice, would anybody write code such as
>] foo bar baz [
>when in interpreter mode outside a colon definition.

1) The classical reason would be as a shorthand for

' foo , ' bar , ' baz ,

but that assumes that the system uses threaded code in the classical
way.

2) Another use would be if you have state-smart words FOO BAR BAZ and you
want them to do whatever they do in compile state.

3) But the use here is just the shortest way to perform something in
compile state.  A more typical case is

: bla foo bar baz ; immediate
: boing bla ;

That is inside a colon definition, but a really nice interpretation
semantics of [: should work both inside and outside colon definitions
(a not-so-nice one will corrupt the enclosin colon definition if used
inside).  And in any case, there is still the possible use 2.

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

#41291

On 08/08/2015 16:53, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 07/08/2015 22:28, Gerry Jackson wrote:
>>> On 06/08/2015 14:19, Anton Ertl wrote:
>>>> \ 2)
>>>> : [int-[:] ['] [: execute ; immediate \ interpretation semantics
>>>> ] [int-[:] ." hello" ;] [ execute \ should print "hello"
> ....
>> Sorry I meant to add. Apart from trying to prove that a system is
>> non-standard, why, in practice, would anybody write code such as
>> ] foo bar baz [
>> when in interpreter mode outside a colon definition.
>

I should have added 'in a standard program'

> 1) The classical reason would be as a shorthand for
>
> ' foo , ' bar , ' baz ,
>
> but that assumes that the system uses threaded code in the classical
> way.

That's non-standard so irrelevant to my question.

>
> 2) Another use would be if you have state-smart words FOO BAR BAZ and you
> want them to do whatever they do in compile state.
>

I suppose so, but I would think that any such word is likely to compile 
something which, outside a colon definition, couldn't be executed or 
even accessed in a standard program. Therefore only useful if it has 
side effects like displaying a message e.g. for testing or debugging. 
But even that could be done with a simple test colon definition. Is it 
just an outdated relic from the 'old days' when it was used for your use 1?


-- 
Gerry

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

#41210

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 06/08/2015 14:19, Anton Ertl wrote:
>>> Can you give an example of code that would fail
>>> >if [: was equivalent to :NONAME
>> The usual things:
>>
>> \ 1)
>> : comp-[: postpone [: ; \ compilation semantics
>> : foo [ comp-[: ." hello" ;] ] ;
>> foo execute \ should print "hello"
>>
>> \ 2)
>> : [int-[:] ['] [: execute ; immediate \ interpretation semantics
>> ] [int-[:] ." hello" ;] [ execute \ should print "hello"
>>
>> \ 3)
>> : compile, compile, ; \ give it proper interpretation semantics
>> : int-[: [ ' [: compile, ] ; \ interpretation semantics
>> int-[: ." hello ;] execute \ should print "hello"
>>
>> 1) and 2) fail on state-smart implementations of [:.  3) fails on an
>> implementation that implements non-default non-immediate compilation
>> semantics by misusing SET-COMPILER.

\ 1)
: comp-[: postpone [: ; \ compilation semantics
: foo [ comp-[: ." hello" ;] ] ;
foo execute \ should print "hello"

\ 2)
: [int-[:] ['] [: execute ; immediate \ interpretation semantics
] [int-[:] ." hello" ;] [ execute \ should print "hello"

\ 3)
: compile, compile, ; \ give it proper interpretation semantics
: int-[: [ ' [: compile, ] ; \ interpretation semantics
int-[: ." hello" ;] execute \ should print "hello"

>Assuming your example 3 has a missing " after <." hello> my system works 
>for 1 and 3 but for 2 it doesn't leave an xt on the stack to be 
>EXECUTEd. That's because I hadn't allowed for ] to be executed before a 
>quotation.

What is the problem?

Gforth (current development version) fails on case 1, because ;] does
not restore the STATE, but sets it to compiling (and then compiles
"]").

>But then my implementation isn't state-smart, it's just 
>inadequate for example 2.

A state-smart implementation would fail on case 2, so it's inadequate
for that case, too.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web