On 02/02/2016 20:59, Anton Ertl wrote:
> Gerry Jackson <
ge...@jackson9000.fsnet.co.uk> writes:
>> Investigating quotations in GForth 0.7.9_20160113 reveals an inconsistency
>>
>> [: 12345 . ;] execute 12345 ok
>>
>> Similarly
>> : foo s" [: 12345 . ;]" evaluate ; ok
>> foo execute 12345 ok
>>
>> But
>> : bar ]] [: 12345 . ;] [[ ;
>> bar compiled
>> [ .s ] <0> compiled
>>
>> i.e. remains in compilation mode with an empty stack
>>
>> Perhaps quotations aren't required to work in interpretation mode but it
>> would be nice if GForth was consistent.
>
> Hmm, I wonder what this combination of ]]...[[ and quotations should
> mean.
I didn't give the best example. In the discussion about YC I gave an
example of a simple FSM using nested quotations. Then I wrote a word
that generated such an FSM from a string, this worked well in my system
but failed with Gforth. On investigating I found that this failed in
exactly the same way as the complex word.
: x 12345 ;
: foo postpone [: postpone x postpone . postpone ;] ;
failed in the way I described. When I made my last post I simplified to
the example using the Gforthism ]] ... [[ overlooking the fact that a
number shouldn't be postponed. Anyway it still failed in the same way so
that doesn't really matter.
My expectation, rightly or wrongly, was that the above FOO should
produce the same result as
[: x . ;]
which, when executed, works in Gforth.
>
> One way would be to consider the quotation as a kind of literal that
> is postponed into the definition that's being defined when BAR
> executes. And that seems to me the interpretation that's closest to
> the idea of ]] ... [[. I don't think that Gforth implements that, but
> at least the stack effect would not be at fault (the STATE after bar
> would).
>
> Another way would be to POSTPONE the individual words [:, 12345, .,
> and ;], and it seems to me that that's what Gforth is doing.
That's what I expected
> That seems to have the equivalent effect to what I described above (at
> least for this example), but is less efficient by building the
> quotation again each time BAR is performed.
Efficiency is irrelevant for what I was doing.
> The STATE when BAR is
> called in interpret state is still something that should be improved,
> though.
Yes, Gforth is currently left in a state where the only way out seems to
be by deliberately creating an error e.g. by typing ; or a non-existent word
--
Gerry