> What if FIND (or its string-and-count replacement) were to give more
> information?

> I don't have a proposal thought out, only some beginning ideas. Anybody
> is welcome to build on them for whatever purpose, or to criticise them.

> Usually what we need is not IMMEDIATE words or state-smart words.
> IMMEDIATE was a quick simple hack that people have been working
> around for 30 years. It's usually adequate, but not good.

> Any word that includes POSTPONE or executes COMPILE, (or [COMPILE]
> ?) is compile-only, and recursively any word that executes a word
> that includes POSTPONE etc it compile-only.

> The complications of state-smart etc don't belong in the words
> themselves.

> The issue doesn't come up after you execute the words. The issue
> comes up in the interpreter/compiler, when you FIND words and decide
> what to do with them.

> What if FIND (or its string-and-count replacement) were to give more
> information? What if it were to give

> I don't have a proposal thought out, only some beginning ideas. Anybody
> is welcome to build on them for whatever purpose, or to criticise them.
>
> Usually what we need is not IMMEDIATE words or state-smart words.
> IMMEDIATE was a quick simple hack that people have been working around
> for 30 years. It's usually adequate, but not good.
>
> Any word that includes POSTPONE or executes COMPILE, (or [COMPILE] ?)
> is compile-only, and recursively any word that executes a word that
> includes POSTPONE etc it compile-only.
>
> The complications of state-smart etc don't belong in the words
> themselves. The issue doesn't come up after you execute the words. The
> issue comes up in the interpreter/compiler, when you FIND words and
> decide what to do with them.
>
> What if FIND (or its string-and-count replacement) were to give more
> information? What if it were to give
> ...

>> The complications of state-smart etc don't belong in the words
>> themselves.

> Semi-seriously: The complications of state-smart don't belong
> anywhere. Give it up; you'll feel much better. :-)

> I don't see how making state even more complicated is likely to
> simplify anything.

>> Wordlists don't clean up the IMMEDIATE mess, they make more messes
>> attempting to solve that. IMMEDIATE affects FIND . State-smart words
>> don't work because they try to fix something that ought to happen
>> while parsing with something that happens at execution time --
>> whenever execution happens.

> Hmmm. My version of FIND doesn't differentiate between IMMEDIATE words
> and non IMMEDIATE words, it simply finds the word I'm asking for.

> The behavior that you propose seems overly complex to me.

> In my system, the word I use for this is IMMEDIATE?

> Jean-François Michaud wrote:
>

>> Hmmm. My version of FIND doesn't differentiate between IMMEDIATE words
>> and non IMMEDIATE words, it simply finds the word I'm asking for.

>
> That doesn't fit the standard, but it might easily fit the new
> standard. Why shouldn't FIND be factored?
>

>> The behavior that you propose seems overly complex to me.

>
> Maybe. What I want to do doesn't seem complex to me. I want to be able
> to redefine any word and invisibly give it new behaviors, and have it
> still keep its old behaviors visible. Is that too much to ask?

> Andrew Haley wrote:
>

>>> The complications of state-smart etc don't belong in the words
>>> themselves.

>

>> Semi-seriously: The complications of state-smart don't belong
>> anywhere. Give it up; you'll feel much better. :-)

>
> I agree with you about state-smart words. Having two behaviors for one
> name is almost as bad as using two names for one behavior. :-)
>

>> I don't see how making state even more complicated is likely to
>> simplify anything.

>
> Well, I wanted to include the common practice and add something new so
> it wouldn't have to break existing code. Doing that almost inevitably
> means adding complication -- you can't get rid of the existing garbage
> but can only add something new and (hopefully) better.
> ...

> J Thomas wrote:

>> Jean-François Michaud wrote:

>>> The behavior that you propose seems overly complex to me.

>> Maybe. What I want to do doesn't seem complex to me. I want to be able
>> to redefine any word and invisibly give it new behaviors, and have it
>> still keep its old behaviors visible. Is that too much to ask?

> Hmmm. This completely depends on your definition of invisible. To whom?
> To the users? I'm not certain I understand clearly what you are trying
> to do:

> Jean-François Michaud wrote:

>> J Thomas wrote:

>>> Jean-François Michaud wrote:

>

>>>> The behavior that you propose seems overly complex to me.

>

>>> Maybe. What I want to do doesn't seem complex to me. I want to be able
>>> to redefine any word and invisibly give it new behaviors, and have it
>>> still keep its old behaviors visible. Is that too much to ask?

>

>> Hmmm. This completely depends on your definition of invisible. To whom?
>> To the users? I'm not certain I understand clearly what you are trying
>> to do:

>
> I mean, invisible to standard programs that don't already know about
> its extra function.
>
> If you were to redefine DUP so that it still did everything DUP is
> required to do, and it doesn't do anything else that shows (It uses ...