Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56512
| 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-31 09:45 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2017Mar31.114528@mips.complang.tuwien.ac.at> (permalink) |
| References | (3 earlier) <oak95d$sr4$1@dont-email.me> <2017Mar19.115341@mips.complang.tuwien.ac.at> <oauvh5$5f5$1@dont-email.me> <2017Mar23.132339@mips.complang.tuwien.ac.at> <obhs3b$mq9$2@dont-email.me> |
Bernd Paysan <bernd@net2o.de> writes:
>Am Thu, 23 Mar 2017 12:23:39 +0000 schrieb Anton Ertl:
>> 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?]
>
>Here is where your argument already breaks. We don't know what ' IF
>returns as xt, because that is left to the implementer - deliberately.
>We know what IF does when it is encountered by the text interpreter in
>compilation state.
And we know that COMPILE, has the stack effect ( xt -- ), that IF's
compilation semantics has the stack effect ( C: -- orig ), so a
standard system cannot perform the compilation semantics of IF through
COMPILE,. So if the intention of the TC was that the user-defined
text interpreter sketched in
<http://forth-standard.org/standard/rationale#rat:core:COMPILE,>
works, FIND must return xt 1 (immediate) for IF.
>You can know if you use FIND and check if it is
>immediate or not. So if it is immediate, you can bind it with IS IF to
>the new deferred IF. If it is non-immediate,
the system's COMPILE, is non-standard.
> you can't, so you probably
>need to define
>
>: IF postpone IF ; immediate
Actually, if VFX wants to be a standard system, it should define IF in
that way itself (along with a bunch of other words; S" is a harder nut
to crack, though).
>There is simply no place in the
>standard that says IF must be immediate, and that is on purpose.
It's a bit distributed (stack effect of COMPILE, and IF, what FIND
returns, and how FIND and COMPILE, are intended to be used in the
user-defined interpreter), but it's there. IF has to be immediate in
a Forth-94 and Forth-2012 system.
As for "on purpose": The purpose was to allow cmForth's FIND to
report, say, + as "immediate", so that the text interpreter call the
+-compiler instead of compiling a call to the + routine; i.e., the
idea was to be able to report some traditionally (and, looking at the
way immediacy is defined in Forth-94/2012, also there) non-immediate
words as "immediate", not to be able to report words with non-default
compilation semantics as non-immediate.
>"xt as universal token" doesn't work well on systems with immediate
>words, because the xt alone doesn't contain the information about
>immediacy.
>
>The "xt as universal token" doctrine only works on a system without
>immediacy at all, i.e. all compilation macro stuff is done through
>COMPILE,.
So this doctrine incompatible with Forth-94 and Forth-2012.
>> 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.
>
>The ANS Forth standard came into existence by making a survey what people
>did and tried to figure out how to write the standard in a way that made
>these different approaches fit.
Maybe in some cases. But in others they put down the hammer and
prescribed behaviour to an extent that would lead to an immediate "But
that prescribes implementation! That's against the spirit of ANS
Forth!" from some people here. E.g., the standard is written in a way
that makes the then-existing technique of having ] as compiler loop
(rather than just changing the STATE of an external interpreter loop)
non-standard.
>We of course can't know exactly what they would have, but judging from
>the Forth 200x effort, we try to bend over backwards to make sure even
>systems where one particular vendor did things all others think are
>stupid (like using curly brackets for multi-line comments when everybody
>else was using them for locals with a sane order), they certainly would
>have made it possible for VFX to be standard.
No, we don't bend over backwards for systems. It's about programs:
There are reportedly a lot of SwiftForth programs that use "{" for
comments, including within colon definitions. If we had standardized
on "{" for locals, that would have meant that SwiftForth will never
implement this locals syntax, that most SwiftForth users would not
load an implementation of the Forth-2012 locals syntax, and that most
SwiftForth users would not use libraries that use the new locals
syntax; the new locals syntax would have been a second-class citizen.
Of course, given that it's reportedly a "huge job" to include
extensions/locals.fs from
<http://www.forth200x.org/forth200x-code.zip> in SwiftForth (I could
do it in one line), it may still be that SwiftForth will never
implement the new locals syntax, but at least the other problems go
away with the new non-conflicting syntax, at the cost of having to
type two character more in every locals definition, and of quite a bit
of whining on c.l.f.
Anyway, back to the topic: They did not make the "]" compiler loop of
PolyForth standard-compliant, and there are a number of other cases
where they put down the hammer (e.g. CHAR and [CHAR] instead of
ASCII), and other cases where they were swayed by system implementors,
maybe too much (e.g., the not-required (but default) separate FP
stack).
Would they have been swayed by VFX? Maybe, but I doubt it; there seem
to have been a number of people there who cared quite a bit about this
stuff, and who would probably not have accepted this nonsense,
especially given that the remedy is as easy as
: IF postpone IF ; immediate
>The complexity of words with different interpretation and compilation
>semantics can be shifted around, and of course, it will never completely
>go away. Each solution has its drawbacks and advantages. "My solution
>is the only one" is not the way a standard that tries to build on common
>practice works.
Sorry, COMPILE, has already been standardized. There is no need to
find common practice there. This is just a question of whether VFX
complies or not. At the moment it doesn't.
>2. Words with only compilation semantics and no interpretation semantics
>can't be ticked meaningfully, because the user can't know whether they
>are immediate or not - using FIND gives you that answer, but you need to
>take it into account when you use that xt.
But the answer for IF can only be <xt-of-IF> 1.
>3. Words with both interpretation and compilation semantics, and we agree
>that they have the same problems as the second class, and therefore we
>also don't allow to ' them in a standard program
Even Gforth 0.4-0.7 did not go that far. And the fact that it did not
allow ' IF has been repeatedly criticized by several people (and
that's one reason why you now can ' IF in the development version).
And being able to ' IF, but getting a result that is not useful for
EXECUTEing and performs a non-standard stack effect when COMPILE,ing
is worse than producing an error on ticking.
>4. User-defined word with non-default compilation semantics. And this is
>not a problem, because the user knows how he did it, and what caveats
>that approach has. This is reproducible. If it's not the expected
>behavior, the user will do something about it.
This would not be a problem for reproducability, but a problem for
usability: Forth would turn into a language with problematic corner
cases in lots of places (this property of Perl was a reason why our
attempt at using automake failed). For every word that uses EXECUTE
or COMPILE,, you would have to document what kinds of xts are allowed;
and for every defining word, you would have to document how the xts of
that word can be used. For someone who dislikes documenting as much
as you do, it's surprising that you advocate such an approach. Of
course, you can also not document these things, and then blame the
user when he falls into the trap you set up.
>From a "avoid confusion" point of view, I'm for reducing the options.
>Now, in development Gforth, the user has three possibilities to define a
>word with non-default compilation semantics: state-smart, using set-
>optimize, and dual-xt with interpret/compile: or set-comp. For typical
>use, the user won't see a difference, as it's all fringe cases where you
>actually see the difference. You need to ' it, you need to start
>POSTPONE or COMPILE, it.
Ok, let's reduce options:
1) make STATE one of those words that are not included from the start
(at least not with that name), and that the user has to type in if
they want it.
2) Don't mention SET-OPTIMIZER in the documentation. To anyone who
uses it anyway, the name should be a hint as to its purpose (of
course, nowadays that "optimize" has reacquired the meaning "anything
goes" thanks to gcc, we cannot be sure about that).
3) Have a mode that uses
: compile, postpone literal postpone execute ;
instead of the stuff coming from SET-OPTIMIZER. If the program
behaves differently, it's likely a bug in the use of SET-OPTIMIZER.
BTW, there is no SET-COMP in Gforth. There is a SET->COMP, but it's
undocumented. So better use INTERPRET/COMPILE: for the moment.
- 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