15.6.2.2530.30 [DEFINED] bracket-defined TOOLS EXT

1. I think that, just as FIND may or may not return an xt, [DEFINED] may return true or false for this case; and I don't think that consistency between the choices for FIND and for [DEFINED] is required. I.e., [DEFINED] is based on the standard FIND, not necessarily on the system's FIND.

2. Again, I don't think that consistency is required. I also think that FIND should not throw in that case, but either return c-addr 0 or xt 1|-1. I also think that all systems behave that way.

3. I think that the intention of the committee is that applying [DEFINED] to any name is valid. I also think that all systems behave that way.

In any case, these are holes in the standard that should be fixed.

1. On which systems will FIND return 0 during interpretation for words with undefined interpretation?

   If a system has some way of distinguishing such words, say with a compile-only flag, what is the expectation when warnings are set?

   Shouldn't FIND distinguish between not found and found but compile-only?

2. Agreed. There is no need for either FIND or [DEFINED] to throw. Either they find a defined word, or they don't.

3. There is no reason why [DEFINED] shouldn't work on words with undefined interpretation. So, either:

   FIND , ' and ['] always return the execution token of the most recent match. If the definition has no interpretation semantics, then a Standard program should not execute that xt unless compiling. FIND may return a different xt when compiling than when interpreting.

   or if these do not find compile-only words, define [DEFINE] etc. using FIND-NAME

   : [DEFINED] parse-name find-name 0= ; IMMEDIATE

1. On cmForth. Note that e.g., Gforth 0.7 returns the xt of a word that produces an error.

   (The future) Gforth 1.0 defines the interpretation semantics of all words, and compile-only results in a warning in some cases. FIND just produces the xt for the interpretation semantics without outputting a warning.

   I don't think it is worth the effort to put such a requirement in FIND at this time. With FIND-NAME and NAME>INTERPRET, you can differentiate between these cases.

2. Yes

3. Yes, if a system implements [DEFINED] based on a FIND that returns 0 in interpret state for AGAIN, the following would not work as intended:

    [defined] again 0= [if] : again 0 postpone literal postpone until ; immediate [then]
   

   That would not be so great. Does someone want to write a proposal for fixing this flaw in [DEFINED] and [UNDEFINED]?

In Forth-2012 standard we have the following important clause: attempting to obtain the execution token of a definition with undefined interpretation semantics is an ambiguous condition (*).

I like this clause, — it allows to implement the definition with undefined interpretation semantics via recognizers in a Standard System. Also, [DEFINED] may return 0 for the corresponding names. And this system still be a Standard System.

Actually, I would to propagate the clause (*) to the definitions with dual semantics and to the definitions with special compilation semantics too.

1. cmForth is virtually extinct, and not Standard in many other ways. Perhaps we should stop trying to accommodate it. It seems that with all current Forths, FIND will return an xt in interpretation mode whether the definition has interpretation semantics are not.

2. So remove the option that FIND may return caddr 0 in interpretation mode for words with no interpretation semantics. If the word is in the search order, FIND will return an xt regardless of STATE. The implementation of [DEFINED] using FIND always works as intended.

   The xt returned is always the execution token except:

   1. If the system provides words with dual semantics that may be ticked or POSTPONEd, the xt found while interpreting represents the interpretation semantics and that found while compiling represents the compiling semantics.

3. If the system can mark words as compile-only, a system-defined xt may be returned for such words while interpreting.

cmForth's trick was to have a special COMPILER vocabulary where all definitions were immediate and found only at compile time. That's very useful for simple cross-compiling; it ensures that no compiler words are accidentally compiled in the target. But that's a wnole other topic.

Surely with recognizers youu would check by searching for the name of appropriate the recognizer word?

IIRC Mark Humphries' system does not find compile-only words when looking for interpreted words, but I don't know if it was published, and reconciling this system with NAME>COMPILE may be a challenge (NAME>INTERPRET should be ok thanks to the possible 0 result).

With the current recognizer proposal, if I want to check whether something is recognized, I do

s" $-5" forth-recognizer recognize

so I don't think that we should let [DEFINED] check recognized things outside the search order.

Given that, using the phrase "Parse /name/ delimited by space" is still appropriate.

As for having special versions in core and in the search-order wordset, this would spread from FIND to [DEFINED] [UNDEFINED] and FIND-NAME. I think the better approach is to define what "search order" means if there is no search-order wordset.

Don't you think that FIND should be declared as obsolescent sooner or later? I believe it should. At least due to its counted string argument — in favor of a word that takes (c-addr u) pair. From the perspective of FIND obsolescence it is better not to spread anything from it.

I agree that it is better to define what "search order" means in the specific cases.

Also, it is good to define non-parsing factor. For example: AVAILABLE ( c-addr u -- flag )

Regarding the recognizers.

I meant recognizable? example — it is a general method that should be able to also answer whether some word is defined (available) or not.

One use case for [DEFINED] looks like the following:

[defined] foo [if]
\ use foo
[else]
\ workaround
[then]

With recognizers the following situations can take place.

1. foo is not available via the search order, but it is available via a recognizer (for example, it is a word from SO library). The workaround actually should not be used.

2. foo is available via the search order, but the search order (the system's list of word lists) is not used due to the current recognizer sequence. Using foo will produce an error.

Therefore I doubt that only the search order should be checked. Actually, recognizers is a part of the search order in general sense.

There is no need for special AVAILABLE word (as non-parsing factor) if it is limited to the search order, since FIND-NAME (c-addr u -- nt|0 ) is enough.

The initial problem in [defined] was fixed by the proposal Remove the “rules of FIND”. Close.