Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #60902
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Date | 2017-06-17 10:20 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2017Jun17.122047@mips.complang.tuwien.ac.at> (permalink) |
| References | (5 earlier) <5942c0ea.53530947@news.eternal-september.org> <ohuh5q$1te$1@dont-email.me> <5942dc09.60474427@news.eternal-september.org> <2017Jun16.190430@mips.complang.tuwien.ac.at> <59444ee9.155417743@news.eternal-september.org> |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Fri, 16 Jun 2017 17:04:30 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>stephen@mpeforth.com (Stephen Pelc) writes:
>>>One solution is provided and documented in VFX.
>>>: ." \ "ccc<quote>" --
>>>\ *G Output the text up to the closing double-quotes character.
>>> [char] " word $.
>>>;
>>>comp: ( xt -- ) drop postpone (.") ", ;
>>>
>>>The colon definition is the normal interpretation behaviour.
>>>
>>>COMP: sets the compilation behaviour of the last word compiled
>>>and whose xt is provided as a parameter. The action is what
>>>follows up to the semi-colon.
>>
>>I'll assume that you mean "semantics" (the standard term) when you
>>write "behaviour" (which otherwise might mean anything).
>
>>In VFX, COMP: does not set compilation semantics, it changes what
>>COMPILE, does. And in this case it changes COMPILE, to behave in a
>>non-standard way: when you COMPILE, the xt of .", it COMPILE, parses,
>>contrary to the standard specification of COMPILE,. Test at the end
>>of the posting.
>
>This discussion about notation would be more productive without your
>obsession to find errors in VFX Forth. Discuss the notation please.
You found me out! When I am done with my day job (paid for by
Elizabeth Rather) of disparaging Hugh Aguilar's code and ideas, I use
my spare time on my (now no-longer) secret obessesion of finding
errors in VFX Forth.
Seriously though, this is not about a bug in VFX Forth, this is about
the claim that the code above is a solution, and that COMP: sets the
compilation semantics. COMP: in VFX does not set the compilation
semantics, and I don't consider this to be a bug. So the bugs
discussed in my posting are entirely contained in the code and
explanation cited above.
My point is not bugs in VFX, but that there is a difference between
performing the compilation semantics of a word and COMPILE,ing the xt
of the word (not for every word, but for some, e.g., ."). And that we
need two mechanisms: a COMP:-like mechanism for
optimization/code-generation, and a different mechanism for specifying
the compilation semantics.
>I actually now agree with you that the standard says that COMPILE,
>should not have a stack effect other than ( xt -- ) and that it
>should not parse. It just so happens that the VFX implementation
>(and probably many others) work just fine in both of these cases.
In most (all?) user-defined text interpreters, the difference in
behaviour of such a changed COMPILE, from the standard COMPILE, does
not play a role (I can explain the reason for that if there is
demand). However, COMPILE, is also used for other things than text
interpreters, and there it makes a difference.
>I chose to call the version that works in these cases NDCS,
>
>Let's redefine ." to use NDCS,
>: ." \ "ccc<quote>" --
>\ *G Output the text up to the closing double-quotes character.
> [char] " word $.
>;
>ndcs: ( -- ) ['] (.") ndcs, ", ;
What does NDCS, do, and what's wrong with:
ndcs: ( -- ) postpone (.") ", ;
>Whether NDCS: needs an xt to be passed in will only
>be found with experience.
We have about two decades of experience with INTERPRET/COMPILE:, which
does not pass an xt, and we have not missed the xt.
Also, in many cases you can reason in advance about why you would or
would not need something. In this case: As long as you make every
NDCS: stanza a one-off for the specific word, you don't need the xt.
If you can use it for defining a whole class of words, you want to
pass the xt of the specific word in order to, e.g., access the body.
I don't see how NDCS: can be used for a whole class of words, but I
may be wrong (I have not seen more than a usage example of it yet).
If you introduce a new word anyway, why not just implement
INTERPRET/COMPILE:?
Just for completeness and elucidation: There is also a low-level word
in development Gforth:
set->comp ( xt -- )
\ xt replaces what NAME>COMPILE does for the last definition
A definition of a smart ." with SET->COMP looks like this:
: ."-comp ( compilation: "string<">" -- ; run-time: -- )
\ compilation semantics if ."
'"' parse postpone sliteral postpone type ; immediate
: ."-name>compile ( nt -- xt1 xt2 )
drop ['] ."-comp ['] execute ;
: ." ( "string<">" -- )
'"' parse type ;
' ."-name>compile set->comp
>>FIND must return xt 1 (i.e., immediate) for .", because the
>>compilation semantics of ." parses, it therefore has to be performed
>>through the EXECUTE branch of the text interpreter, not the COMPILE,
>>branch.
>
>No. It has to be handled by the NDCS handler. Why mandate the
>interpreter loop structure?
Why pose loaded questions? The text above is not about mandating the
interpreter loop structure, but about making the existing user-defined
text interpreters work with NDCS: words and getting the corner cases
right. Existing user-defined text interpreters look like:
\ from A.6.2.0945
FIND ?DUP IF ( xt +-1 )
STATE @ IF ( xt +-1 )
0> IF EXECUTE ELSE COMPILE, THEN ( ??? )
ELSE ( xt +-1 )
DROP EXECUTE ( ??? )
THEN
ELSE ( c-addr )
( whatever you do for an undefined word )
THEN
We cannot implement the compilation semantics of ." through COMPILE,
(because the compilation semantics consumes stuff from the input
stream, among other reasons), so if we want this text interpreter to
work, FIND has to return the xt of the NDCS: definition (or of
."-COMP) and 1 (immediate) in compile state, in order to work through
the EXECUTE case.
>The Gforth loop is so far from the
>classical and illustrative loop that you have no rights here.
What are you talking about? This is not about the Gforth text
interpreter (which does not use FIND at all), it's about the classical
and illustrative user-defined text interpreter.
>All I'm
>going to do is to add an NDCS flag and take account of it in the
>interpreter loop and POSTPONE.
If you want to support the existing user-defined text interpreters
that are out there, the way to go is to take account of the NDCS: part
in FIND and NAME>COMPILE.
- 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 2017: http://www.euroforth.org/ef17/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 20:47 +0100
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 20:57 +0100
Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-05-29 13:18 -0700
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-29 22:47 +0100
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 07:43 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-30 07:30 +0000
Re: Another recognizer discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-30 09:53 +0200
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-30 22:02 +0100
Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-05-31 01:27 -0700
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:12 +0100
Re: Another recognizer discussion minforth@arcor.de - 2017-05-31 03:43 -0700
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:03 +0100
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 16:46 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 11:28 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-31 12:17 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-05-31 15:10 +0100
Re: Another recognizer discussion mhx@iae.nl - 2017-05-31 11:01 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-05-31 22:55 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 05:50 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-05-31 23:57 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 09:08 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-01 03:33 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-01 09:05 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 15:05 +0100
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-01 10:05 -0500
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 16:32 +0100
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-01 09:31 -0700
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 19:00 +0100
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-04 22:56 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-05 14:41 +0100
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-02 03:07 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 16:28 +0000
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-11 02:14 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-11 10:55 +0000
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-12 03:22 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 15:21 +0000
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-14 04:10 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-15 10:43 +0000
Re: Another recognizer discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-15 09:11 -0500
Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 02:55 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-14 10:19 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 05:44 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 14:27 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-14 08:06 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 16:36 +0000
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 09:48 -0700
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-15 17:18 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-15 18:50 +0100
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-15 19:22 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-15 13:09 -0700
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 13:43 -0700
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-15 22:55 +0200
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-15 22:20 +0100
pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 17:04 +0000
Re: pre-Rfd for smart word definition mechanism (was: Another ...) stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 21:58 +0000
Re: pre-Rfd for smart word definition mechanism (was: Another ...) JennyB <jennybrien@googlemail.com> - 2017-06-17 00:26 -0700
Re: pre-Rfd for smart word definition mechanism (was: Another ...) minforth@arcor.de - 2017-06-17 01:18 -0700
Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 15:24 +0000
Re: pre-Rfd for smart word definition mechanism (was: Another ...) JennyB <jennybrien@googlemail.com> - 2017-06-17 12:29 -0700
Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-18 12:29 +0000
Re: pre-Rfd for smart word definition mechanism (was: Another ...) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-18 16:47 +0200
Re: pre-Rfd for smart word definition mechanism (was: Another ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 10:20 +0000
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 13:01 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 16:55 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 17:40 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 16:47 +0000
Re: Another recognizer discussion Brad Eckert <hwfwguy@gmail.com> - 2017-06-15 10:34 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-17 17:35 +0000
Re: Another recognizer discussion peter.m.falth@gmail.com - 2017-06-17 15:24 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-18 12:00 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 12:29 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-16 07:35 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-11 10:39 +0000
Re: Another recognizer discussion Richard Owlett <rowlett@cloud85.net> - 2017-06-11 07:19 -0500
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 14:04 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-14 12:50 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-15 16:19 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 07:59 +0000
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 11:48 +0200
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 10:24 +0000
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 13:04 +0200
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 13:30 +0000
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 16:36 +0200
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-02 15:51 +0000
Re: Another recognizer discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-02 21:09 +0200
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 15:55 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-01 14:21 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-04 23:07 +0000
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-10 15:49 +0000
Re: Another recognizer discussion stephen@mpeforth.com (Stephen Pelc) - 2017-06-11 11:14 +0000
Re: Another recognizer discussion minforth@arcor.de - 2017-06-11 08:24 -0700
Re: Another recognizer discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-13 15:07 +0000
Re: Another recognizer discussion Alex <alex@rivadpm.com> - 2017-06-01 12:11 +0100
Re: Another recognizer discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-30 11:03 -0700
csiph-web