Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #55921

Re: bug in VFX --- IF does't work

Show all headers | View raw

rickman <gnuarm@gmail.com> writes:
>On 4/1/2015 3:33 PM, hughaguilar96@gmail.com wrote:
>> On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote:
>>> On Tue, 31 Mar 2015 15:13:12 -0700 (PDT), hughaguilar96@gmail.com
>>> wrote:

[where does this thread necromancy come from? But anyway, I will bite]

>>>
>>>> : my-if [ ' if ] literal execute ; immediate  ok : ttt ( flag --
>>>> ) my-if ." true " else ." false " then ;=20 Err# -14 ERR: Attempt
>>>> to interpret a compile only definition. -> : ttt ( flag -- )
>>>> my-if ." true " else ." false " then ; ^ see my-if=20 MY-IF (is
>>>> IMMEDIATE)=20 ( 004C7A80    E89B23F4FF )            CALL
>>>> 00409E20        IF ( 004C7A85    C3 )                    NEXT, (
>>>> 6 bytes, 2 instructions ) ok
>>>
>>> It works fine. You compiled MY-IF to use the interpretation
>>> behaviour of IF. VFX compiled the interpretation behaviour of IF.
>>> You ran MY-IF and got the interpretation behaviour of IF. What are
>>> you complaining about?
>>
>> Well, you said "interpretation behavior" three times, so I felt
>> inspired to look this up in the ANS-Forth document section on IF
>> (6.1.1700): "Interpretation semantics for this word are undefined."
>> You ask what I'm complaining about, but then your explanation comes
>> to "undefined." That is funny! This is actually a familiar phrase, as
>> I recently ran into the same thing in this thread:
>> https://groups.google.com/forum/#!topic/comp.lang.forth/2OsjCUri9eY
>
>This is simple enough that even I can understand it.
>
>You exited compilation mode using [.  You ticked 'if'.  So what would 
>you expect to get other than an execution token for the interpretation 
>semantics of 'if'?

"Execution token for the interpretation semantics" is the dual-xt way
to think about it; in the dual-xt world view, some words have an xt
for the interpretation semantics and a different xt (or a two-cell
compilation token) for the compilation semantics.

Your variant of that view seems to be that it depends on the state
during ticking which of the two xts you get.  In Gforth, ticking
always gives you the xt for the interpretation semantics (or an error,
if there is none), and there is NAME>COMPILE for getting the
compilation token.

VFX implements a different view, though: A word has only one xt, and
you get the interpretation semantics if you EXECUTE it, and, for a
non-immediate word, you get the compilation semantics if you COMPILE,
it; words that would have different xts in a dual-xt system are
implemented as non-immediate in VFX.  This view works much of the
time, but fails in corner cases.  As a result, we get statements
such as this from Stephen Pelc:

>>> I have been saying for a couple of years now that the ANS
>>> standard's definition of compilation and interpretation is
>>> incomprehensible for mere mortals such as myself. Every time I
>>> reread the standard on this topic, the more I believe that the
>>> standard's description of compilation and interpretation needs a
>>> complete rewrite.

The problem is not in the standard, but in conflicting requirements:

1) The requirement to be able to cut and paste parsing words like S"
and TO between interpreted and compiled code.  And there are people
who invent more such stuff at every opportunity, as if it had no
downside.

2) The requirement of equivalence between COMPILE, and
POSTPONE LITERAL POSTPONE EXECUTE (used in various places in existing
code, e.g., in early-binding parts in OO packages).

3) The requirement of equivalence between performing the xt of a word,
or (through POSTPONE) the compilation semantics in interpretation and
in compilation state.  The standard makes an exception from this
requirement for TO, and we should probably also have exceptions for S"
S\" IS and ACTION-OF, but for other standard words this requirement
holds.

4) The requirement to have each named word be represented by a single
xt.  That is is not a standard requirement (explicitly not required
for FIND), but some people argue strongly in favour of having such a
requirement.

A system cannot satisfy all these requirements in all cases.  Let's
see at what different systems do:

SwiftForth satisfies requirement 2 and 4; 1 for only a few words (S"
and TO), and 3 for most words, except those where it satisfies 1.

VFX satisfies 1, 3, and 4; but it does not satisfy 2 for a number of
words (S", TO, but also, e.g., IF).

Gforth <=0.7 satisfies 1,2 and 3; but it does not satisfy 4 for a
number of words (S", TO, etc.).  The current development version
satisfies 1 and 3, maybe 2, and is somewhat closer to 4: It has nt=xt,
i.e., for most words, NAME>INTERPRET is a noop; but for others
NAME>INTERPRET gives a different xt, and none of the cells produced by
NAME>COMPILE is the original xt.

If we want to get rid of a requirement, my suggestion would be to get
rid of requirement 1 (by replacing most of its usages with
recognizers, and by making do without the other usages); that would
get us back to the good old times of a single xt plus immediate flag,
and all the newfangled concepts such as interpretation and compilation
semantics would go away.  We would make Forth great again!

But if you are one of those people who love the convenience of being
able to cut and paste, say, a quotation, from compiled to interpreted
code, then the way to go is to give up requirement 4.  And once you
have thrown the mental baggage of requirement 4 overboard, the
standard is doing pretty ok (not that it cannot be improved, but the
complaints I usually see have more to do with this mental baggage than
with real issues in the standard).

In any case, I don't think we have a consensus on dropping
requirements 1, 2, or 3, and not even a consensus on clarifying the
standard in a way that makes it clearer that 4 is not a requirement,
so I don't expect any rewrite attempts to be accepted, or even if
accepted, resulting in an an actual improvement.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2017-03-18 17:37 -0400
  Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-18 15:08 -0700
  Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-18 15:17 -0700
    Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-18 22:22 +0000
      Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2017-03-18 19:47 -0400
        Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-18 17:06 -0700
          Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2017-03-18 20:58 -0400
          Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-19 18:04 +0000
  Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-19 10:53 +0000
    Re: bug in VFX --- IF does't work Cecil Bayona <cbayona@cbayona.com> - 2017-03-19 12:57 -0500
      Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-19 13:39 -0500
      Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-19 14:48 -0700
        Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-19 22:05 +0000
    Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-19 17:57 +0000
    Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-19 12:18 -0700
    Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-03-22 22:57 +0000
      Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-22 17:18 -0700
      Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 04:03 -0500
        Re: bug in VFX --- IF does't work albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-23 15:01 +0100
          Re: bug in VFX --- IF does't work peter.m.falth@gmail.com - 2017-03-23 07:12 -0700
            Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-29 20:31 -0700
          Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-23 10:22 -0500
            Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-03-30 02:31 +0000
              Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-30 03:36 -0500
                Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-30 15:45 +0000
                Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-30 12:03 -0500
                Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-30 14:04 -0700
                Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-31 09:23 +0000
                Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-31 07:43 -0500
                Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-01 12:55 +0000
                Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-01 11:52 -0500
      Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 12:23 +0000
        Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-23 15:57 +0000
          Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 17:38 +0000
            Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-23 17:58 +0000
              Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-23 19:16 +0000
              Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-24 09:52 +0000
        Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-23 18:26 +0000
        Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-03-30 02:55 +0000
          Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-29 20:49 -0700
          Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2017-03-30 03:04 -0700
            Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-30 06:47 -0500
              Re: bug in VFX --- IF does't work Alex <alex@rivadpm.com> - 2017-03-30 12:56 +0100
                Re: bug in VFX --- IF does't work Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-30 09:41 -0500
              Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-30 13:59 -0700
              Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-05-01 01:33 +0000
                Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2017-04-30 15:50 -1000
                Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-04-30 19:34 -0700
                Re: bug in VFX --- IF does't work albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-01 23:53 +0200
                Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-05-01 18:54 -0700
                Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-05-02 15:01 +0000
                Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-05-02 11:30 -0700
                Re: bug in VFX --- IF does't work Cecil Bayona <cbayona@cbayona.com> - 2017-05-02 13:36 -0500
                Re: bug in VFX --- IF does't work Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:57 +0000
          Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-31 09:45 +0000
            Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2017-03-31 20:09 -0700

csiph-web