• Compilation semantics and name>compile (was: Demonstration of Dual Sema

    From Ruvim@21:1/5 to Anton Ertl on Sat Oct 29 20:33:22 2022
    On 2022-10-29 13:41, Anton Ertl wrote:
    [...]


    : bar [ s" <word>" find-name name>compile execute ] ;

    is equivalent to

    : bar <word> ;

    Yes, they shall be equivalent according to the specification for "name>compile", but in Gforth v0.7.9_20221027 these expressions are not equivalent (in some cases, e.g. for immediate STATE-dependent words).

    For example:

    : foo state @ 0= lit, ; immediate

    : bar [ s" foo" find-name name>compile execute ] ; \ (1)
    bar . \ prints "-1" in Gforth

    : bar foo ; \ (2)
    bar . \ prints "0" in Gforth


    So, equivalence of the given expressions does not hold in Gforth.


    A practical question: do you have an example when you need the
    expression (1) to produce a different result than the expression (2)?


    --
    Ruvim

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ruvim@21:1/5 to Krishna Myneni on Sun Oct 30 08:17:31 2022
    On 2022-10-29 23:14, Krishna Myneni wrote:
    On 10/29/22 16:41, Ruvim wrote:
    On 2022-10-29 16:10, Krishna Myneni wrote:
    On 10/29/22 08:41, Anton Ertl wrote:
    Krishna Myneni <krishna.myneni@ccreweb.org> writes:
    What I should have said is that
    compilation of a word should not be done with '(tick) and
    "COMPILE," but
    start with the name token, e.g. S" <name>" FIND-NAME and then use
    NAME>COMPILE and EXECUTE to append the appropriate semantics.

    These are two different operations in general:

    : foo [ ' <word> compile, ] ;

    makes FOO perform the interpretation semantics of <word>.


    It is not true that FOO will perform the interpretation semantics of
    <word> in Gforth if SET-OPTIMIZER has been used to change the
    implementation of its compilation semantics. This is exactly my
    objection to SET-OPTIMIZER -- it changes what COMPILE, does.

    It's a weak argument, since it can be easily eliminated by a proper
    specification for "set-optimizer" (or a similar word).
    ...

    You can't unbreak "COMPILE," with a specification for SET-OPTIMIZER.
    I expect "COMPILE," per the standard, to append exactly the semantics
    given by xt,

    In what case does it append the semantics given by xt *inexactly*? Could
    you provide an example?

    Have a look:

    : tuck ( x2 x1 -- x1 x2 x1 ) swap over ;

    : compile-tuck-v1 ['] tuck compile, ;

    : compile-tuck-v2 ['] swap compile, ['] over compile, ;

    Are you agree that "compile-tuck-v1" and "compile-tuck-v2" both append
    the same semantics?





    in this case the xt corresponding to the interpretation
    semantics of the word.

    It makes impression that (according to your understanding) the
    interpretation semantics of this word and the execution semantics of
    this word are *not* the same in this case. It is right?

    If they are the same, could you provide an example when they are not the
    same?




    Although you are fixed on the term "execution
    semantics", for a dual-semantics system, '(tick) returns the
    interpretation semantics for the word.

    I just use the language of the standard, and the terminology of the
    standard.

    The language of the standard is agnostic on whether a system employs the dual-xt or single-xt approach. There is no one reason to expose the
    internal details of an dual-xt system when we talk about behavior of a
    system that is observable by a standard program.



    The user (or programmer) must rely on "COMPILE," appending exactly the semantics of the xt that is specified, and not substitute some other xt.

    6.2.0945
    COMPILE, “compile-comma” CORE EXT
    Interpretation: Interpretation semantics for this word are undefined. Execution: ( xt – – )
    Append the execution semantics of the definition represented by xt to
    the execution semantics of the current definition.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    BTW, take a look, during compilation of a definition, namely the
    execution semantics of this definition are created. And Tick returns an identifier namely of these semantics (this behavior).

    Please, don't tell me that in a dual-xt system it creates the
    interpretation semantics — it does not matter how your system
    intertwists things under the hood — it's its internal business.

    From a standard program point of view, this behavior is execution
    semantics of the word, which in some cases can be equivalent to the interpretation semantics of the word, of course. But there is no one
    case when it's incorrect to call this behavior "execution semantics".



    --
    Ruvim

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Krishna Myneni@21:1/5 to Ruvim on Sun Oct 30 15:02:58 2022
    On 10/30/22 03:17, Ruvim wrote:
    On 2022-10-29 23:14, Krishna Myneni wrote:
    On 10/29/22 16:41, Ruvim wrote:
    On 2022-10-29 16:10, Krishna Myneni wrote:
    On 10/29/22 08:41, Anton Ertl wrote:
    Krishna Myneni <krishna.myneni@ccreweb.org> writes:
    What I should have said is that
    compilation of a word should not be done with '(tick) and
    "COMPILE," but
    start with the name token, e.g. S" <name>" FIND-NAME and then use
    NAME>COMPILE and EXECUTE to append the appropriate semantics.

    These are two different operations in general:

    : foo [ ' <word> compile, ] ;

    makes FOO perform the interpretation semantics of <word>.


    It is not true that FOO will perform the interpretation semantics of
    <word> in Gforth if SET-OPTIMIZER has been used to change the
    implementation of its compilation semantics. This is exactly my
    objection to SET-OPTIMIZER -- it changes what COMPILE, does.

    It's a weak argument, since it can be easily eliminated by a proper
    specification for "set-optimizer" (or a similar word).
    ...

    You can't unbreak "COMPILE," with a specification for SET-OPTIMIZER.
    I expect "COMPILE," per the standard, to append exactly the semantics
    given by xt,

    In what case does it append the semantics given by xt *inexactly*? Could
    you provide an example?


    See

    https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/YQVN1g-kBAAJ


    ..

    in this case the xt corresponding to the interpretation semantics of
    the word.

    It makes impression that (according to your understanding) the
    interpretation semantics of this word and the execution semantics of
    this word are *not* the same in this case. It is right?

    If they are the same, could you provide an example when they are not the same?


    Even in a single-xt system with only one xt per word, it makes sense to
    talk of interpretation semantics and compilation semantics. Depending on
    the immediate flag, the compilation semantics are derived from either
    executing or compiling the xt. Both involve using the single xt as an
    argument to the xt of EXECUTE or COMPILE, . Thus tick can always simply
    return the single xt.

    For a dual-xt system, one must choose which xt, xt-interp or xt-comp is returned by '(tick). It makes sense for backwards compatibility to
    return xt-interp for application of '(tick) (and for [']). Here it makes
    no sense to say that '(tick) returns the "execution semantics" of the
    word. '(tick) specifically returns xt-interp. The language of the
    standard is insufficient (imprecise) to describe the action of '(tick)
    for a dual-xt system.

    6.1.0070
    6. CORE Word Set
    “tick”

    CORE
    ( “<spaces>name” – – xt )
    Skip leading space delimiters. Parse name delimited by a space. Find
    name and return xt, the execution token for name. An ambiguous condition
    exists if name is not found. When interpreting, ’ xyz EXECUTE is
    equivalent to xyz.




    Although you are fixed on the term "execution semantics", for a
    dual-semantics system, '(tick) returns the interpretation semantics
    for the word.

    I just use the language of the standard, and the terminology of the
    standard.

    The language of the standard is agnostic on whether a system employs the dual-xt or single-xt approach. There is no one reason to expose the
    internal details of an dual-xt system when we talk about behavior of a
    system that is observable by a standard program.


    It may be agnostic, but it is not sufficiently precise for a dual-xt implementation.



    The user (or programmer) must rely on "COMPILE," appending exactly the
    semantics of the xt that is specified, and not substitute some other xt.

    6.2.0945
    COMPILE, “compile-comma” CORE EXT
    Interpretation: Interpretation semantics for this word are undefined.
    Execution: ( xt – – )
    Append the execution semantics of the definition represented by xt to
    the execution semantics of the current definition.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    BTW, take a look, during compilation of a definition, namely the
    execution semantics of this definition are created. And Tick returns an identifier namely of these semantics (this behavior).

    Please, don't tell me that in a dual-xt system it creates the
    interpretation semantics — it does not matter how your system
    intertwists things under the hood — it's its internal business.

    From a standard program point of view, this behavior is execution
    semantics of the word, which in some cases can be equivalent to the interpretation semantics of the word, of course.  But there is no one
    case when it's incorrect to call this behavior "execution semantics".


    I've pretty much said all I have to say on both the matters of how I
    think "COMPILE," should behave, and why "execution semantics" is no
    longer an adequate term to use in the specification of some words, if
    the standard is to be applicable to both single-xt and dual-xt system.
    My views are expressed within my last three topical posts on c.l.f.

    There appears to be no immediate resolution for a consensus on these
    topics, which is fine. However, I won't engage in an endless discussion
    of these topics.

    --
    Krishna

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Krishna Myneni@21:1/5 to Ruvim on Tue Nov 1 04:10:33 2022
    On 11/1/22 03:18, Ruvim wrote:
    On 2022-10-30 20:02, Krishna Myneni wrote:

      | If SET-OPTIMIZER is used to alter
      | the compilation semantics of a word

    If "set-optimizer" is proper specified, it's impossible to use it to
    alter the compilation semantics for a word in a standard program.
    Concerning nonstandard programs — they are not in the scope of the
    standard at all.
    ...

    Anton corrected me earlier when I claimed SET-OPTIMIZER (in Gforth) is
    used to alter the compilation semantics of a word. Although it *can*
    alter the compilation semantics of a word, it is intended to be used to
    change the implementation of the compilation semantics, i.e. append the
    same semantics but which executes more efficiently. In Gforth,
    SET-COMPSEM is used to change the compilation semantics of a word in a dual-semantics system. Doing so may well be outside of the scope of the
    current standard, but, as we have seen it can be a useful tool to extend
    the capabilities of a Forth system.


    From my point of view,  "compile," and "execution semantics" are pretty adequate in the model that the standard describes.


    There appears to be no immediate resolution for a consensus on these
    topics, which is fine. However, I won't engage in an endless
    discussion of these topics.


    Thank you for the discussion, it was useful anyway :)



    Finding a commonly agreed-upon way of talking about topics like
    dual-semantics systems seems to be challenging. I have no doubt the
    discussion will come up again, but it's worthwhile to take a break from
    it too.


    --
    Krishna

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ruvim@21:1/5 to Krishna Myneni on Tue Nov 1 08:18:45 2022
    On 2022-10-30 20:02, Krishna Myneni wrote:
    On 10/30/22 03:17, Ruvim wrote:
    On 2022-10-29 23:14, Krishna Myneni wrote:
    On 10/29/22 16:41, Ruvim wrote:
    On 2022-10-29 16:10, Krishna Myneni wrote:
    On 10/29/22 08:41, Anton Ertl wrote:
    Krishna Myneni <krishna.myneni@ccreweb.org> writes:
    What I should have said is that
    compilation of a word should not be done with '(tick) and
    "COMPILE," but
    start with the name token, e.g. S" <name>" FIND-NAME and then use >>>>>>> NAME>COMPILE and EXECUTE to append the appropriate semantics.

    These are two different operations in general:

    : foo [ ' <word> compile, ] ;

    makes FOO perform the interpretation semantics of <word>.


    It is not true that FOO will perform the interpretation semantics
    of <word> in Gforth if SET-OPTIMIZER has been used to change the
    implementation of its compilation semantics. This is exactly my
    objection to SET-OPTIMIZER -- it changes what COMPILE, does.

    It's a weak argument, since it can be easily eliminated by a proper
    specification for "set-optimizer" (or a similar word).
    ...

    You can't unbreak "COMPILE," with a specification for SET-OPTIMIZER.
    I expect "COMPILE," per the standard, to append exactly the semantics
    given by xt,

    In what case does it append the semantics given by xt *inexactly*?
    Could you provide an example?


    See

    https://groups.google.com/g/comp.lang.forth/c/dh347IHLDtw/m/YQVN1g-kBAAJ


    | If SET-OPTIMIZER is used to alter
    | the compilation semantics of a word

    If "set-optimizer" is proper specified, it's impossible to use it to
    alter the compilation semantics for a word in a standard program.
    Concerning nonstandard programs — they are not in the scope of the
    standard at all.




    ..

    in this case the xt corresponding to the interpretation semantics of
    the word.

    It makes impression that (according to your understanding) the
    interpretation semantics of this word and the execution semantics of
    this word are *not* the same in this case. It is right?

    If they are the same, could you provide an example when they are not
    the same?


    Even in a single-xt system with only one xt per word, it makes sense to
    talk of interpretation semantics and compilation semantics. Depending on
    the immediate flag, the compilation semantics are derived from either executing or compiling the xt. Both involve using the single xt as an argument to the xt of EXECUTE or COMPILE, . Thus tick can always simply return the single xt.



    For a dual-xt system, one must choose which xt, xt-interp or xt-comp is returned by '(tick).


    In my dual-xt system one xt identifies the execution semantics of a
    word, and another one is used to perform the compilation semantics for
    the word. This way better fits the standard model.



    It makes sense for backwards compatibility to
    return xt-interp for application of '(tick) (and for [']). Here it makes
    no sense to say that '(tick) returns the "execution semantics" of the
    word. '(tick) specifically returns xt-interp.

    The language of the
    standard is insufficient (imprecise) to describe the action of '(tick)
    for a dual-xt system.

    The standard should not describe a particular dual-xt system. But the
    system, to be a standard system, should fit what the standard describes.
    If the system does not fit that, then the system just is not standard.



    [...]

    I've pretty much said all I have to say on both the matters of how I
    think "COMPILE," should behave, and why "execution semantics" is no
    longer an adequate term to use in the specification of some words, if
    the standard is to be applicable to both single-xt and dual-xt system.
    My views are expressed within my last three topical posts on c.l.f.


    If it is no longer adequate, it's unclear since what a moment (and what
    was changed in that moment).

    I still don't understand your grounds. And some simple closed questions (yes/no) have remained unanswered.

    From my point of view, "compile," and "execution semantics" are pretty adequate in the model that the standard describes.


    There appears to be no immediate resolution for a consensus on these
    topics, which is fine. However, I won't engage in an endless discussion
    of these topics.


    Thank you for the discussion, it was useful anyway :)


    --
    Ruvim

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)