15.6.2.2530.30 [DEFINED] bracket-defined TOOLS EXT

Compilation:

Perform the execution semantics given below.

Execution:

( "<spaces>name ..." -- flag )

Skip leading space delimiters. Parse name delimited by a space. Return a true flag if name is the name of a word that can be found (according to the rules in the system's FIND); otherwise return a false flag. [DEFINED] is an immediate word.

Implementation:

: [DEFINED] BL WORD FIND NIP 0<> ; IMMEDIATE

ContributeContributions

ruvavatar of ruv [86] The case of undefined interpretation semanticsRequest for clarification2019-06-26 12:09:31

By this specification, [DEFINED] word checks whether a name can be found according to the rules in the system's FIND.

1. According to "4.1.2 Ambiguous conditions", the definitions with undefined interpretation semantics may be not found by FIND in a standard Forth system. In this case [DEFINED] shall return false flag on such definition names. Is it correct?

2. If FIND throws an exception on such definitions (as possible action on an ambiguous condition), [DEFINED] shall throw the same exception as well. Is it correct?

3. As a consequence, a standard program shall not apply [DEFINED] on such definition names as IF, EXIT, COMPILE,, etc — since it is an ambiguous condition. Is it correct?

AntonErtlavatar of AntonErtl

  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.

JennyBrienavatar of JennyBrien

  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

AntonErtlavatar of AntonErtl

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

ruvavatar of ruv

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.

JennyBrienavatar of JennyBrien

  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.

ruvavatar of ruvNew Version: [86] The case of undefined interpretation semantics

Hide differences

By this specification, [DEFINED] word checks whether a name can be found according to the rules in the system's FIND.

To avoid the flaw connected with FIND, the specification of [DEFINED] should not mention FIND at all. In such case we will have two (or maybe three) variants: the basic one, the updating by Search-Order word set, and the possible updating by Recognizer word set.

1. According to "4.1.2 Ambiguous conditions", the definitions with undefined interpretation semantics may be not found by FIND in a standard Forth system. In this case [DEFINED] shall return false flag on such definition names. Is it correct?

I would also suggest to define and use lexeme term (in 2.1) to have an easier specification text.

2. If FIND throws an exception on such definitions (as possible action on an ambiguous condition), [DEFINED] shall throw the same exception as well. Is it correct?

The following definitions are a subject for discussion.

3. As a consequence, a standard program shall not apply [DEFINED] on such definition names as IF, EXIT, COMPILE,, etc — since it is an ambiguous condition. Is it correct?

Basic variant

Parse a space-delimited lexeme. Return a true flag if the dictionary contains a definition name matching the lexeme; otherwise return a false flag.

Search-Order word set variant

Parse a space-delimited lexeme. Return a true flag if some word list from the search order contains a name matching the lexeme; otherwise return a false flag.

Recognizer word set variant

Parse a space-delimited lexeme. Return a true flag if the lexeme can be recognized by the system's recognizer sequence; otherwise return a false flag.

JennyBrienavatar of JennyBrien

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

AntonErtlavatar of AntonErtl

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.

ruvavatar of ruv

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.

ruvavatar of ruv

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.

Reply New Version

BerndPaysanavatar of BerndPaysan [115] Remove the “rules of FIND”Proposal2019-09-12 09:09:51

This contribution has been moved to the proposal section.

AntonErtlavatar of AntonErtl

This reply has been moved to the proposal section.

BerndPaysanavatar of BerndPaysan

This reply has been moved to the proposal section.

BerndPaysanavatar of BerndPaysan

This reply has been moved to the proposal section.

AntonErtlavatar of AntonErtl

This reply has been moved to the proposal section.

BerndPaysanavatar of BerndPaysan

This reply has been moved to the proposal section.

BerndPaysanavatar of BerndPaysan

This reply has been moved to the proposal section.

BerndPaysanavatar of BerndPaysan

This reply has been moved to the proposal section.
Accepted
Reply New Version