> I had a major brain-twisting problem in an immediate word I was writing
> that only went away after I stuck in a 'postpone ['.
>
> The problem came from the fact that inside an immediate word, I'm
> invoking a chain of other state sensitive immediate words.

> Question is, am I stepping into shark infested waters?

> Hi,

> I had a major brain-twisting problem in an immediate word I was writing
> that only went away after I stuck in a 'postpone ['.

> The problem came from the fact that inside an immediate word, I'm
> invoking a chain of other state sensitive immediate words.

> Here's the word in a working state, followed by an example:

> Hi,
>
> I had a major brain-twisting problem in an immediate word I was writing
> that only went away after I stuck in a 'postpone ['.
>
> The problem came from the fact that inside an immediate word, I'm
> invoking a chain of other state sensitive immediate words.
>
> Here's the word in a working state, followed by an example:
>
> \ parses text up til '"', and generates a BString object from it
> : b" ( "some text" -- bstr-object )
> state @ if
> \ compiling
> postpone [
> postpone s"
> BString -> new-from-str \ ( s-addr u -- bstr-object )
> ]
> postpone literal \ compile it in to the current word ...

>> The problem came from the fact that inside an immediate word, I'm
>> invoking a chain of other state sensitive immediate words.

>
> Oh, dear. Whenever that happens it's always a good idea to start asking
> some fairly fundamental questions.
> ..
> if you really need
> state-smartness I suggest that you make a non-immediate version of
> BString -> new-from-str and do something like
>
> : b" ( "some text" -- bstr-object )
> [char] " parse BString -> new-from-str
>
> state @ if
> postpone literal
> then
> ; immediate

> Andrew Haley wrote:

>>> The problem came from the fact that inside an immediate word, I'm
>>> invoking a chain of other state sensitive immediate words.

>

>> if you really need
>> state-smartness I suggest that you make a non-immediate version of
>> BString -> new-from-str and do something like

>

>> : b" ( "some text" -- bstr-object )
>> [char] " parse BString -> new-from-str

>

>> state @ if
>> postpone literal
>> then
>> ; immediate

> And what caused you trouble was that S" happens to be state-smart.
> When compiling, it parses a string and compiles a string literal that
> gives you the string when the new word executes. You didn't want that,
> you wanted to use the string right away to create your object. So you
> did [ to get the interpreted S" which left a temporary string's
> parameters address and count on the stack.
>
> A state-smart word was getting in your way, but it wasn't one you were
> building. It was one that was stuck into the standard at the last
> minute when the standards team was tired. It filled a need and there
> wasn't enough time and energy to argue about how to better fill that
> need.

> Jeff wrote:
> ...
>

>> A state-smart word was getting in your way, but it wasn't one you
>> were building. It was one that was stuck into the standard at the
>> last minute when the standards team was tired. It filled a need and
>> there wasn't enough time and energy to argue about how to better
>> fill that need.

>
> I generally agree with you, and I am no big fan of state-smart words,
> for all the excellent reasons that Anton cites. But the tale of how
> the state-smart S" got into the FILES wordset is a mite more
> complicated than you suggest.
>
> At the time of the standards meetings, virtually all Forths had a word
> that compiled a string, and it was called " . But, all the Forths we
> studied (and we tried very hard to look at them all) were evenly
> divided as to whether to return the address of a counted string, or
> return addr-len parameters for the actual string. To complicate ...