Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56187
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: bug in VFX --- IF does't work |
| Date | 2017-03-23 12:23 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2017Mar23.132339@mips.complang.tuwien.ac.at> (permalink) |
| References | (1 earlier) <551bd2e8.431024070@news.eternal-september.org> <c73bb02b-badf-4da0-968f-2068da15314b@googlegroups.com> <oak95d$sr4$1@dont-email.me> <2017Mar19.115341@mips.complang.tuwien.ac.at> <oauvh5$5f5$1@dont-email.me> |
Bernd Paysan <bernd@net2o.de> writes:
>Am Sun, 19 Mar 2017 10:53:41 +0000 schrieb Anton Ertl:
>> 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).
>
>But these OO packages don't work with words like IF, let alone S" and TO
>in those places, but almost exclusively use :NONAME to define the xts
>used for these COMPILE,.
This is not just about S" and TO. If it was, we would just disallow
ticking S" (' TO is already disallowed), and refine FIND
appropriately, and not worry about it. But some people (e.g., you)
like to create new words with (approximations to) non-default
non-immediate compilation semantics at a high rate, and they even
create defining words that create such words.
And at some point somebody will need to use either the interpretation
or the compilation semantics of such a word in the form of an xt where
requirement 2 holds, and that's when the trap you want to set up for
all Forth users springs. Just as the trap set up by putting STATE @
IF in all kinds of places sprang when I demonstrated Forth's
metaprogramming capabilities to a student (who then chose to use a
different language for his master's project).
And it's not just OO. E.g., you wrote a word DEFERS that's compiles
the current xt contained in a deferred word into the current
definition (i.e., it resolved the deferred word during compilation
instead of at run-time), used for refining deferred words.
[undefined] defer@ [if]
cr .( warning: defer@ absent )
: defer@ >body @ ; \ works on SwiftForth
[then]
: Defers ( compilation "name" -- ; run-time ... -- ... )
\ Compiles the present contents of the deferred word @i{name}
\ into the current definition. I.e., this produces static
\ binding as if @i{name} was not deferred.
' defer@ compile, ; immediate
As an example, let's turn IF into a deferred word:
' if
defer if immediate
is if
[Ok, you might argue that a standard program cannot ' IF; in that
case, use FIND instead; and is that stance really compatible with the
"xt as universal token" dogma?]
Let's see if our new IF works as IF should:
: foo1
0 ?do
dup c@ [char] a [char] z 1+ within if
dup c@ emit then
1+ loop
drop ;
s" 123abcABC" foo1 cr
Let's have a variant that counts the number of total performed IF's and
which of those take the then-branch:
variable total-ifs
variable then-branches
: inc-total ( -- ) 1 total-ifs +! ;
: inc-thens ( -- ) 1 then-branches +! ;
:noname ( compilation -- orig ; run-time f -- )
postpone inc-total defers if postpone inc-thens ;
is if
Let's use our enhanced if in the same code:
: foo2 ( c-addr u -- )
0 ?do
dup c@ [char] a [char] z 1+ within if
dup c@ emit then
1+ loop
drop ;
s" 123abcABC" foo2 total-ifs ? then-branches ? cr
Ok, running this on SwiftForth, I get
IF isn't unique. abc
abc9 3
Apart from the "isn't unique" warning, as intended. Let's see what
Gforth (development version) does:
xxx.fs:5:5: redefined Defers
xxx.fs:11:5: IF is compile-only
xxx.fs:12:9: redefined IF with ifabc
abc9 3
A few redefinition warnings, a warning about ticking a compile-only
word, and then the expected output.
Now VFX:
IF is redefined
Err# -14 ERR: Attempt to interpret a compile only definition.
Source: "xxx.fs" on line 17
-> dup c@ [char] a [char] z 1+ within if
^sh: 1:
What is happening is this: In the definition of FOO, our IF calls the
system IF in a way that invokes the compile-only error. Ok, ticking
gets us an xt that has this behaviour, fair enough. In that case,
requirement 2 says that we should also see this behaviour when
compiling FOO2. So, after commenting FOO1 out, what do I get?
VFX reports the redefinition of IF and then hangs, consuming 100% of
one core. A little debugging reveals that the COMPILE, in DEFERS IF
performs the compilation semantics of IF (instead of appending the
compilation semantics, as intended), which has two problems:
A) The requirement 2) above is not satisfied. If it was, we would get
the same error, as can be easily verified by prepending
: compile, postpone literal postpone execute ;
B) The stack effect of VFX's COMPILE, is not standard-compliant when
you pass the xt of IF to it: ( xt -- orig ).
Back to the requirements: One of Forth's assets is that it has just
one class of words, unlike, e.g., Algol-family languages with their,
keywords, operators, and identifiers. You just have words, and you
can use them in any context. That's why people complained when Gforth
did not allow to tick compile-only words, and that's why we now allow
ticking compile-only words.
Dividing words into two classes, those where requirement 2 holds, and
those where it does not hold, makes Forth conceptually more complex,
and eliminates the advantage of having only one word class. So,
great, you now have a "universal token", but now you have two word
classes, and you can use the "universal token" of some words for OO
programming and DEFERred words, but not the "universal token" of
others words.
If you want to create words like S" and TO, this introduces
complexity, and it either shows up as conceptual complexity in the
form of traps and (usually after someone fell in) "don't do this"
rules, or as implementation complexity in properly implementing
interpretation and compilation semantics; and in the present case that
implementation complexity is actually relatively small.
>Fact is that by the word of the ANS Forth standard, dual-xt as
>implemented in Gforth later (which wasn't the way how dual-xt was
>implemented when they wrote the standard, and Gforth was purely state-
>smart at that time) is the only valid implementation technique according
>to a very literal reading of the standard. And of course, since the
>intelligent COMPILE, wasn't on the radar, the TC cold not define COMPILE,
>in a way that fits exactly with the way VFX uses it.
Nor would they have. Not everything that some system implementor
considers a good idea actually is. We see ample demonstration of this
in the way gcc deals with "undefined behaviour", but the way that VFX
defines IF in connection with EXECUTE and COMPILE, is another example.
- 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
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