On 2021-05-11 00:16, P Falth wrote:
> On Monday, 10 May 2021 at 20:34:52 UTC+2, Ruvim wrote:
>> On 2021-05-06 18:23, P Falth wrote:
>>> On Thursday, 6 May 2021 at 16:30:54 UTC+2, Ruvim wrote:
>>>> On 2021-05-06 17:07, Ruvim wrote:
>>>>> On 2021-05-06 14:38, P Falth wrote:
>>>> [...]
>>>>>> As an alternative to FIND I can suggest
>>>>>> FIND-INTERPRET ( addr u -- addr u 0 | xt2 xt1 -1 )
>>>>>> FIND-COMPILE ( addr u -- addr u 0 | xt2 xt1 -1 )
>>>>>> FIND-POSTPONE ( addr u -- addr u 0 | xt2 xt1 -1 )
>>>> They are quite close to FIND-NAME NAME>COMPILE
>>>
>>> Yes they are. But they also hide the NT and can thus accomodate
>>> also a system with dual NTs. Someone (Mark Williams?) described
>>> such a system that was simple and clean.
>> But why they are better than "FIND"? (except (c-addr u) string).
>
> When I developed the code generator for my forth (about 20 years ago)
> I needed a way to execute the generator for a word when it was compiled
> into a definition. I started with the CMFORTH style dual headers in different
> wordlists. This worked fine until I also needed wordlists for its intended
> purpose. That is when I added a compilation xt to the header.

Another option is to introduce different flags into the header and a
functionality to find words with given flags only. But if you need both
semantics in the same time, FIND should be performed twice in this approach.

> For some
> words ( normal words, created words) at compiletime was also needed
> the interpretation xt. FIND could not give me this. From this was born
> FIND-INTERPRET and FIND-COMPILE. They do what I needed!

I see. It's OK for internal or system-specific purposes.

But then for compatibility you could make xt=nt (and then it will be a
sing-xt system from the user's point of view).

Or at least FIND should return something like xt of
[: true abort" not implemented" ;]
and n value 1, or just n value 0, when FIND is applied to the "IF"
string in compilation state, and ['] IF with n value 1 — in
interpretation state.

>> In my recent iteration I introduced the word FIND-SEM
>>
>> FIND-SEM ( c-addr u -- xt flag-special true | c-addr u false )
>>
>> It is closer to classic "FIND", with only difference that it accepts a
>> string as the pair (c-addr u), and returns more convenient flag-special,
>> rather than -1|1 code.
>
> But that would not let me find both xts at the same time

Do you talk about your system or a program?

In your system you are free to use system-specific methods.

A standard program have to call FIND-SEM twice (in two different states)
for that — the same as with FIND.

>> And why do you need "FIND-POSTPONE"?
>
> I do not at the moment and it is not implemented. But might be
> useful for recognizers. It might serve to do words with non default
> postpone semantics (NDPS words!)
>
> That was a joke!

Oh, I see. After all, NDPS is non standard.

>>>>> If you can implement this, nothing prevent you to implement STATE
>>>>> dependent FIND
>>>> But only if for the cases FIND-INTEPRET and FIND-COMPILE, xt1 identify
>>>> either "EXECUTE" or "COMPILE," and nothing else.
>>>
>>> To require that XT1 be limited to "EXECUTE" or "COMPILE," would severely
>>> limit the possibilities of the system. Take for example a constant.
>>> XT2 could be the actual value of the constant and XT1 LITERAL for compiling.
>> It looks like you reinvent recognizers under the different name.
>
> Yes, just 20 years ago!

Then why don't use recognizers for such things?

As Anton pointed out, above approach is possible for single-cell numbers
only, when recognizers are suitable for any literals.

>>> My LXF64 compiles to tokenized code. XT1 of interpret could there be a call
>>> to a JIT compiler that compiles the tokens to native code and then executes it
>> Why cannot EXECUTE be who calls a JIT compiler (if a better code is not
>> generated yet) and then executes this better code?
>
> Yes that is how it can work. ON the stack will be
>
> NT JIT-compiler, coming from find-interpret

I mean that EXECUTE behaves in the following manner:

: execute ( i*x xt -- j*x )
xt>oxt if ( oxt ) oexecute exit then ( xt )
ocompiled ( oxt ) oexecute
;

> I am not there yet. Now I can call native code from the token code. But I also want to
> do the reverse.

>
>>>> Otherwise FIND cannot be implemented via these words.
>>>
>>> There is no requirements to implement FIND with these words.
>> For back-compatibility, the system should still provide FIND for a
>> while. And it should be clear how to implement FIND via new methods in
>> the case when a system doesn't provide FIND (to use programs/libraries
>> that rely on FIND).
>
> I do provide a FIND in my systems.

When you propose an alternative to FIND, it's not about your system.
It's about the standard and the Forth ecosystem.

> In lxf it is not possible to do a user defined
> interpreter with it, for 2 reasons. It is not state-smart. It only returns the
> interpretation XT. Words like IF with no defined interpretation semantics
> return an xt that print an error message and aborts. If needed i could change this
> but so far has not needed it.

As I understand, the second reason is that lxf cannot provide an xt that
identifies the following execution semantics:

[: postpone if ;]

>> A one shortcoming of NAME>* methods is that they don't guarantee that
>> FIND can be implementable via them. Moreover, FIND is not implementable
>> via these methods in a single-xt system, if this system allows to
>> perform compilation semantics in interpretation state.
>
> My lxf64 is still single-xt, FIND works just fine there. There is no requirement
> that find must be implemented by NAME>* methods
>
>>>>>
>>>>> But what for do you need FIND-POSTPONE ?
>>>>>
>>>>>
>>>>>> The result if found just needs to be executed to perform the
>>>>>> respective actions
>>>>>> It also hides the implementation details ( single-xt, dual-xt, dual
>>>>>> headers etc)
>>>>>
>>>>> It doesn't cover sing-xt systems. In these systems the corresponding
>>>>> action should be performed only in the corresponding STATE.
>>>> I missed that they return two xt-s. Then yes, they cover single-xt
>>>> systems too.
>>>>
>>>> But then what is a way to detect whether a word is an ordinary word?
>>>
>>> That is not needed!
>> I need that.
>>
>> See for exampe: https://forth-standard.org/standard/tools#reply-445
>>
>> Another example. A kind of portable SYNONYM should be able to detected
>> whether a word is an ordinary word, or not.
>
> I provide a completely compliant SYNONYM. Different NTs but same XTs
> There is no need to load another synonym.

Again, you talk about your system. But I talk about Forth ecosystem, and
broad variety of Forth systems.

If a standard system doesn't provide SYNONYM but provide a full-fledged
FIND, then SYNONYM (that preserves execution semantics as well as IS and
CS) can be implemented.

>>>> And what is a way to get xt of an ordinary word, that identifies the
>>>> execution semantics for this word?
>>>
>>> ' and ['] are still available for this.
>> They cannot be applied to any word. They cannot be used to words of
>> unknown kind.
>
> I do not understand this. Any word that has an XT could be ticked, or?

Tick returns xt that identifies execution semantics (ES) for the name in
argument, but ES are not specified for many standard words.

Therefore, 4.1.2 says that an ambiguous condition exists if a program
attempts to obtain the execution token of a definition with undefined
interpretation semantics (for all such cases ES are either unspecified,
or cannot be provided in many implementations).

Concerning other words with unspecified ES, it says that applying Tick
to the word is ambiguous, individually for each such word except FILE S"
and FILE S\".

My proposal is to remove individual cases and declare the single rule:
an ambiguous condition exists if a program attempts to obtaining the
execution token of a definition with non default interpretation semantics.

NB: my proposal of FIND clarification explicitly specifies in what case
the returned xt identifies ES for the name/word in argument.

--
Ruvim