State smartness

Brad Eckert

unread,

May 21, 2013, 5:30:26 PM5/21/13

to

Is there a portable way to do this:

: U ( <number> -- n )
(U) STATE @ IF POSTPONE LITERAL THEN
; IMMEDIATE

without "STATE @" ?

U takes a specially formatted number from the input stream.

Elizabeth D. Rather

unread,

May 21, 2013, 6:31:42 PM5/21/13

to

No, that's pretty much what STATE exists for. If you don't want to do
that, your alternative is a pair of words U and [U] (like CHAR and [CHAR]).

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."
==================================================

Elizabeth D. Rather

unread,

May 21, 2013, 7:20:08 PM5/21/13

to

On 5/21/13 12:31 PM, Elizabeth D. Rather wrote:
> On 5/21/13 11:30 AM, Brad Eckert wrote:
>> Is there a portable way to do this:
>>
>> : U ( <number> -- n )
>> (U) STATE @ IF POSTPONE LITERAL THEN
>> ; IMMEDIATE
>>
>> without "STATE @" ?
>>
>> U takes a specially formatted number from the input stream.
>>
>
> No, that's pretty much what STATE exists for. If you don't want to do
> that, your alternative is a pair of words U and [U] (like CHAR and [CHAR]).

To clarify: your code above is portable. I interpreted your question as,
"is there *another* portable way..."

Albert van der Horst

unread,

May 21, 2013, 10:57:57 PM5/21/13

to

In article <3b27d020-72d1-4a58...@googlegroups.com>,

Are numbers state smart?
Yes, and that has always been an accepted practise.
So what you do is perfectly all right and portable too.

1 2 +

and

: test 1 2 + ;

not

: test [ 1 ] LITERAL [ 2 ] LITERAL + ;

or such nonsense.

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Anton Ertl

unread,

May 22, 2013, 9:01:30 AM5/22/13

to

Brad Eckert <hwf...@gmail.com> writes:
>Is there a portable way to do this:
>
>: U ( <number> -- n )
> (U) STATE @ IF POSTPONE LITERAL THEN
>; IMMEDIATE
>
>without "STATE @" ?

: U (U) ;
: [U] (U) POSTPONE literal ; immediate

- 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 2013: http://www.euroforth.org/ef13/

Anton Ertl

unread,

May 22, 2013, 9:02:35 AM5/22/13

to

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <3b27d020-72d1-4a58...@googlegroups.com>,
>Brad Eckert <hwf...@gmail.com> wrote:
>>Is there a portable way to do this:
>>
>>: U ( <number> -- n )
>> (U) STATE @ IF POSTPONE LITERAL THEN
>>; IMMEDIATE
>>
>>without "STATE @" ?
>>
>>U takes a specially formatted number from the input stream.
>
>Are numbers state smart?
>Yes, and that has always been an accepted practise.

How can you tell?

If we describe a number as we would describe a word, would we describe
it as:

|5 ( -- n )
|
|Place 5 on the stack

or as

|5 Compilation: Perform the execution semantics given below:
|
|5 Execution: ( -- n| )
|
|In intepret state, place 5 on the stack. In compile state, append the
|run-time semantics below. 5 is an immediate word.
|
|Run-time: ( -- n )
|
|Place 5 on the stack.

I would prefer the first description, because it's simpler and at
least as accurate. So, if I were to describe numbers like we decribe
words, I would describe them as normal words (default compilation
semantics), not as STATE-smart (which would be the second
description).

The typical use of STATE-smartness (as exemplified by Brad Eckert's U)
is to make parsing words behave mostly like normal (default
compilation semantics) words. This works as intended when the word is
text-interpreted, but it breaks down if the word is ticked or
postponed. Since numbers do not parse, there is no need to connect
them with STATE-smartness. And since they cannot be ticked or
POSTPONEd, there is no way to tell the difference.

Albert van der Horst

unread,

May 22, 2013, 10:37:01 AM5/22/13

to

In article <2013May2...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
<SNIP>

>
>The typical use of STATE-smartness (as exemplified by Brad Eckert's U)
>is to make parsing words behave mostly like normal (default
>compilation semantics) words. This works as intended when the word is
>text-interpreted, but it breaks down if the word is ticked or
>postponed. Since numbers do not parse, there is no need to connect
>them with STATE-smartness. And since they cannot be ticked or
>POSTPONEd, there is no way to tell the difference.

This is a very accurate description.

In an implementation where numbers do parse (as in ciforth) there is
a need to to connect them with STATE-smartness. That is probably
where my urge comes from.

>
>- anton

Elizabeth D. Rather

unread,

May 22, 2013, 2:11:37 PM5/22/13

to

The handling of numbers is a property of the compiler, not the number.
One describes defined words as "immediate", "state-smart" or normal
"non-immediate" because different words have certain of these
properties. Numbers aren't differentiated. Compilers, on the other hand,
may be described in terms of how they treat certain numbers: e.g.
converting some as FP, handling internal punctuation characters, etc.
Such handling is, again, attributable to the compiler rather than the
numbers themselves.