Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

GForth - quotations in interpretation mode

143 views
Skip to first unread message

Gerry Jackson

unread,
Feb 2, 2016, 2:33:26 PM2/2/16
to
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.

--
Gerry

Anton Ertl

unread,
Feb 2, 2016, 4:17:15 PM2/2/16
to
Hmm, I wonder what this combination of ]]...[[ and quotations should
mean.

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
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. The STATE when BAR is
called in interpret state is still something that should be improved,
though.

: bar ]] [: 12345 . ;] [[ ; immediate \ ok
: bla bar ; \ ok
bla execute \ 12345 ok

- 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.rigwit.co.uk/EuroForth2015/

Gerry Jackson

unread,
Feb 3, 2016, 4:44:11 AM2/3/16
to
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

Anton Ertl

unread,
Feb 3, 2016, 12:14:31 PM2/3/16
to
POSTPONEing numbers works in the development version of Gforth.

>My expectation, rightly or wrongly, was that the above FOO should
>produce the same result as
>[: x . ;]
>which, when executed, works in Gforth.

I wonder why you expect that. POSTPONE and ]] ... [[ compiles the
compilation semantics of the words, so when you interpret FOO, you
perform the compilation semantics of these words, so that should
equivalent to

] [: 12345 . ;] [

which is quite different from

[: 12345 . ;]

Anyway, if you make FOO immediate, and use it in another colon
definition, it seems to work as expected; interpreting FOO results in
the STATE being compile state at the end, but otherwise probably does
what the ]...[ line above does. I.e.,, you can do

foo [

and that is equivalent to

] [: 12345 . ;] [

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

It's just plain old compile state, just use "[".

Gerry Jackson

unread,
Feb 3, 2016, 1:05:51 PM2/3/16
to
On 03/02/2016 16:59, Anton Ertl wrote:
> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>> On 02/02/2016 20:59, Anton Ertl wrote:
>>> Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>>
>>> 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.
>
> POSTPONEing numbers works in the development version of Gforth.
>
>> My expectation, rightly or wrongly, was that the above FOO should
>> produce the same result as
>> [: x . ;]
>> which, when executed, works in Gforth.
>
> I wonder why you expect that.

Because my system to behaves like that and [: ... ;] did work with
Gforth when interpreting, so I incorrectly assumed Gforth would do the
same with FOO - my mistake.

>>> 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
>
> It's just plain old compile state, just use "[".
>

OK, but that's not very nice

--
Gerry

Coos Haak

unread,
Feb 3, 2016, 5:37:15 PM2/3/16
to
Op Wed, 3 Feb 2016 18:05:58 +0000 schreef Gerry Jackson:
Why not make bar IMMEDIATE ? I find that logical, because ]] .. [[ works
as a multi-word POSTPONE. And definitions that contain POSTPONE are
almost always IMMEDIATE, perhaps COMPILE-ONLY too.

Gforth*) can have literals and strings between ]] and [[.

: bar ]] [: 100 . "is one hundred" type cr ;] [[ ; immediate
: foo bar ;
bar execute --> 100 is one hundred

Don't use S" or ." because they parse later, use "string" - strings.

*) My current CHForth knows this too, but different from recognizers.

groet Coos

Gerry Jackson

unread,
Feb 4, 2016, 3:37:45 AM2/4/16
to
Which is all very true but getting away from what I was trying to do
i.e. taking a string and compiling a series of nested quotations that
handle the individual characters. The workaround using Gforth is easy,
just replace postponing the outer quotation with

... postpone :noname ... postpone ;

--
Gerry

anders...@gmx.de

unread,
Feb 7, 2016, 5:32:48 AM2/7/16
to
I wonder whether this is another example of Forth having become too convoluted and therefore open to "vulnerability by improper design".

Gerry, this is not directed against your work, I appreciate it, really.

The old bag of state-smartness, "untickability" of some tricky words, undefined behavior of interpretation mode (compile and execute versus execution word by word) come to my mind. No surprise that building new constructs like quotations on such a floating platform brings other surprises ... and bugs.

0 new messages