Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #60025 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-29 20:47 +0100 |
| Last post | 2017-05-30 11:03 -0700 |
| Articles | 20 on this page of 94 — 13 participants |
Back to article view | Back to comp.lang.forth
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
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-06-18 16:47 +0200 |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <oi63q0$8eg$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #60964 |
In article <2017Jun18.142939@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >JennyB <jennybrien@googlemail.com> writes: >>On Saturday, 17 June 2017 16:49:51 UTC+1, Anton Ertl wrote: >>> This assumes that the xt2 produced by NAME>COMPILE is either the xt of >>> EXECUTE or the xt of COMPILE,. That is pretty natural for >>> NAME>COMPILE, especially if you also want to implement FIND. >>> >> >>It's natural, but it's not currently specified. I've seen implementations t= >>hat have the interpretation xt as the second item on the stack (I don't kno= >>w how common that is, but it is currently allowed.) > >NAME>COMPILE ( nt -- x xt ) > >You mean, x represents the interpretation semantics, and xt (called >xt2 above) first drops x, and then performs the compilation semantics? >That's possible, but makes it harder to implement FIND, because xt >would not be directly usable for FIND. > >> If we want user-defined= >> NDCS: words then we need to standardise, and the obvious thing it to have = >>the extra semantics represented by a single and devise some other syntax fo= >>r it to call the interpretation xt if needed. > >You lost me here. There is certainly a connection between the code >after NDCS: and NAME>COMPILE, but the Forth system can implement NDCS: >and NAME>COMPILE so that they fit together, and there are probably several >ways to do that. Do you suggest standardizing on one? > >>A more strict specification of FIND then would be: >> >> If the flag =3D -1 the xt returned=20 >> Or the flag =3D1 and interpreting=20 >> the xt returned represents the interpretation semantics > >Not necessarily. In the standard there are some words without >interpretation semantics and with default compilation semantics, such >as >R. For them, in compile state you typically want to return -1 and >the xt representing the execution semantics; in interpret state, you >might return the xt of a word producing an error message. I'm happy that gForth doesn't do that. Using >R is occasionally useful in interpret mode. ~$ gforth Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit 12 >R S" we go to ROME " TYPE R> CR . we go to ROME 12 ok <SNIP> >- anton Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-17 10:20 +0000 |
| Subject | Re: pre-Rfd for smart word definition mechanism (was: Another ...) |
| Message-ID | <2017Jun17.122047@mips.complang.tuwien.ac.at> |
| In reply to | #60861 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2017-06-15 13:01 -0700 |
| Message-ID | <65ead0bd-1e02-40d3-b47d-18e02eb5cd9b@googlegroups.com> |
| In reply to | #60788 |
On Thursday, June 15, 2017 at 10:50:14 AM UTC-7, Alex wrote:
>
> This may be a spectacularly dim observation, but is that not exactly
> what the recognizer proposal does?
>
> ( edited to simplify )
> : interpreter ( -- )
> begin
> parse-name dup
> while
> forth-recognizer recognize
> state @ cells- @ execute
> repeat 2drop ;
>
> where recognize provides a pointer to 3 actions; interpret, compile and
> postpone.
>
Not as dim as me not responding to the original post. But as long as we're traversing a stack of recognizers, supposing NUMBER is one kind of recognizer and FIND-NAME is another (FIND-NAME is at the top), I suppose the NUMBER recognizer would return a list of XTs that push a number to the stack or compile the number. Where does the "number pusher" get the number? I assume from the list. So, that makes 4 items in the array returned by the recognizer: xtE, xtC, xtP and W. BL would have W=32, for example.
I looked at the proposal, but I have dumb it down so it makes sense to me. Here's my version of an interpreter based on recognizers:
8 CONSTANT MAX-RECOGNIZERS
MAX-RECOGNIZERS CELLS BUFFER: RECOG_LIST
VARIABLE RECOGNIZERS \ top of zero-terminated list
: ADD-RECOGNIZER ( xt -- )
RECOGNIZERS @ ! CELL RECOGNIZERS +!
;
: NO-RECOGNIZERS ( -- )
RECOG_LIST RECOGNIZERS ! \ clear the list
0 ADD-RECOGNIZER \ add zero terminator
;
: BINT ( -- ) \ Brad's INTERPRET
BEGIN PARSE-WORD DUP WHILE
RECOGNIZERS @
BEGIN
CELL- DUP >R @ ( xt )
DUP IF EXECUTE ( c-addr u | ... 0 )
ELSE NIP NIP ( 0 )
THEN R> OVER 0=
UNTIL 2DROP
REPEAT 2DROP
;
: ECHO ( c-addr u -- 0 | c-addr u )
CR ." *** " 2DUP TYPE SPACE \ echo to console
;
: STOP ( c-addr u -- 0 | c-addr u )
2DROP 0 ." done" \ can't see a thing
;
NO-RECOGNIZERS
' STOP ADD-RECOGNIZER
' ECHO ADD-RECOGNIZER
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-16 16:55 +0000 |
| Message-ID | <2017Jun16.185542@mips.complang.tuwien.ac.at> |
| In reply to | #60788 |
Alex <alex@rivadpm.com> writes:
>On 6/15/2017 18:18, Stephen Pelc wrote:
>> Describe the words needed to make a word with separate
>> interpretation and compilation actions is what I need. In
>> such a way there can be standardisation of them.
>
>This may be a spectacularly dim observation, but is that not exactly
>what the recognizer proposal does?
Ok, you could define a recognizer that recognizes, e.g., S", and
produces a table for the component actions, but then you cannot work
with S" as a word (e.g., not FIND it), and the mechanism is a bit too
heavyweight for what we want to achieve.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-16 17:40 +0000 |
| Message-ID | <5944169e.141007338@news.eternal-september.org> |
| In reply to | #60788 |
On Thu, 15 Jun 2017 18:50:11 +0100, Alex <alex@rivadpm.com> wrote: >This may be a spectacularly dim observation, but is that not exactly >what the recognizer proposal does? > >( edited to simplify ) >: interpreter ( -- ) > begin > parse-name dup > while > forth-recognizer recognize > state @ cells- @ execute > repeat 2drop ; > >where recognize provides a pointer to 3 actions; interpret, compile and >postpone. Recognisers are in one proposal. When I make another for a notation for non-default compilation semantics (NDCS) words, I want the proposals to be independent. What matters for this dicussion is to move to some agreement that we should a) permit NDCS words with separate actions b) define a notation to describe them. At present both gForth and VFX have (incompatible) ways to define NDCS words. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-16 16:47 +0000 |
| Message-ID | <2017Jun16.184727@mips.complang.tuwien.ac.at> |
| In reply to | #60786 |
stephen@mpeforth.com (Stephen Pelc) writes:
>>On Wednesday, June 14, 2017 at 9:36:43 AM UTC-7, Stephen Pelc wrote:
>>>
>>> Let us at least see if we can find a way to describe a correct
>>> interpreter and the additional words required.
...
[interpreter elided]
...
>Describe the words needed to make a word with separate
>interpretation and compilation actions is what I need. In
>such a way there can be standardisation of them.
Maybe if you specified what you want, not something else, you would
get what you want. Anyway, Gforth has
interpret/compile: ( xti xtc "name" -- )
Execution: Define "name" with the semantics below:
"name" interpretation: ( i*x -- j*x )
Perform the semantics identified by xti
"name" compilation: ( i*x -- j*x )
Perform the semantics identified by xtc
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2017-06-15 10:34 -0700 |
| Message-ID | <81e33c08-c4d1-43b2-b19b-5bc24f5240a0@googlegroups.com> |
| In reply to | #60784 |
On Thursday, June 15, 2017 at 9:48:31 AM UTC-7, Brad Eckert wrote: > NIP STATE @ IF I'd change that to "NIP DUP NT ! STATE @ IF". NT may be needed downstream to get more stuff from head space. No reason not to have it a global variable.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-17 17:35 +0000 |
| Message-ID | <2017Jun17.193535@mips.complang.tuwien.ac.at> |
| In reply to | #60784 |
Brad Eckert <hwfwguy@gmail.com> writes:
> FIND-NAME OVER IF [...]
...
>where FIND-NAME ( c-addr u -- 0 nt | c-addr u ) gives you your (not counted) string back if not found.
That may be a better stack effect than ( c-addr u -- nt | 0 ), but
unfortunately FIND-NAME with the latter stack effect has been around
for quite a while, so we would need a different name for that. It's
also unclear if the benefit/cost ratio is good enough for such a
change. The stack effect also does not follow an established pattern,
so readers and writers may have to look it up when encountering it,
which somewhat counterbalances the convenience factor.
> There should be a NAME>IMMEDIATE
: name>immediate name>compile nip ['] execute = ;
>NAME>COMP and NAME>EXEC have the same semantics as in gForth.
I guess you mean the standard words NAME>COMPILE and NAME>INTERPRET.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | peter.m.falth@gmail.com |
|---|---|
| Date | 2017-06-17 15:24 -0700 |
| Message-ID | <d82fbc67-539b-443a-87bb-6db6f5a8fd25@googlegroups.com> |
| In reply to | #60917 |
On Saturday, 17 June 2017 19:46:18 UTC+2, Anton Ertl wrote: > Brad Eckert <hwfwguy@gmail.com> writes: > > FIND-NAME OVER IF [...] > ... > >where FIND-NAME ( c-addr u -- 0 nt | c-addr u ) gives you your (not counted) string back if not found. > > That may be a better stack effect than ( c-addr u -- nt | 0 ), but > unfortunately FIND-NAME with the latter stack effect has been around > for quite a while, so we would need a different name for that. It's > also unclear if the benefit/cost ratio is good enough for such a > change. The stack effect also does not follow an established pattern, > so readers and writers may have to look it up when encountering it, > which somewhat counterbalances the convenience factor. > > > There should be a NAME>IMMEDIATE > > : name>immediate name>compile nip ['] execute = ; Would you not also need to check that the interpretation and compile xts are the same? It is not specified that name>compile must return execute, is it? my system uses a nt-execute Peter > > >NAME>COMP and NAME>EXEC have the same semantics as in gForth. > > I guess you mean the standard words NAME>COMPILE and NAME>INTERPRET. > > - 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/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-18 12:00 +0000 |
| Message-ID | <2017Jun18.140029@mips.complang.tuwien.ac.at> |
| In reply to | #60927 |
peter.m.falth@gmail.com writes:
>On Saturday, 17 June 2017 19:46:18 UTC+2, Anton Ertl wrote:
>> > There should be a NAME>IMMEDIATE
>>
>> : name>immediate name>compile nip ['] execute = ;
>
>Would you not also need to check that the interpretation and
>compile xts are the same?
There are two meanings of immediacy:
1) The meaning from 2.1:
|A Forth word whose compilation semantics are to perform its execution
|semantics.
2) The meaning that the traditional user-defined text interpreter
(from, e.g., A.6.2.0945) assumes when FIND returns 1 (immediate): That
the result of FIND should be COMPILE,d if the flag says "not immediate",
and EXECUTEd if it says "immediate".
If we want meaning 1, we have to check that they are the same, and
compare xt1 with the xt returned by NAME>INTERPRET as a way to
approximate this check (in theory, there could be two different xts
that implement the same semantics).
If we want meaning 2, then there is no need to check that.
For most practical uses of such a word, meaning 2 is probably what is
wanted (e.g., when implementing FIND).
>It is not specified that name>compile must return execute, is it?
No. I think it leads to the best factoring if you also implement
FIND, but you are free to implement it differently. So the
NAME>IMMEDIATE above may not work as intended on all systems.
Anyway, NAME>INTERPRET and NAME>COMPILE provide access to all of the
interpretation and compilation semantics; there is no need for
NAME>IMMEDIATE; and if we still want it, we can derive it from the
date produced by these words, in a system-specific way.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-16 12:29 +0000 |
| Message-ID | <2017Jun16.142900@mips.complang.tuwien.ac.at> |
| In reply to | #60729 |
minforth@arcor.de writes:
>Do non-immediate compile-only words have an xt?
If they have, there is no standard way to get at them.
OTOH, there seems to be consensus that FIND should be usable for
writing a user-defined interpreter. In that case, if you FIND such a
word in compilation state, FIND should return an xt and 1 (immediate);
when you EXECUTE the xt, the compilation semantics should be
performed. So, with this requirement of FIND, such words have at
least one xt.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-16 07:35 +0000 |
| Message-ID | <2017Jun16.093513@mips.complang.tuwien.ac.at> |
| In reply to | #60723 |
stephen@mpeforth.com (Stephen Pelc) writes:
>There's an important point of philosophy
>and/or design here, which is that the XT was *intended* to be
>the single point of contact with a word - the XT is all you need.
You may believe that repeating this again and again will make it true.
It doesn't.
>Most systems optimise XTs for EXECUTE
>but there's no requirement for this to be so.
There is certainly a requirement: The requirement is called
"performance". 0.5% of all executed primitives in
<https://www.complang.tuwien.ac.at/forth/peep/sorted> are EXECUTE, so
making EXECUTE slower has a small, but significant influence on
performance. Of course, if other requirements are more important, we
may decide not to satisfy this requirement, but I have yet to see a
more important requirement.
>While an XT is an opaque type (system dependent) there
>is no point in trying to impose meaning on it.
If an XT had no meaning, we would not need it. The meaning is the
operations we can use on it: EXECUTE COMPILE, >BODY DEFER@ DEFER!. So
its meaning is that it represents an EXECUTEable thing, and if that
thing is associated with data, a way to access the data.
> Adding NT, a second
>opaque type for the same thing, is verging on the absurd.
The NT is not for the same thing. The NT is for named words; you can
get the name string of the word out of it, the interpretation
semantics and the compilation semantics of the named word.
Sure, if there was a 1:1 correspondence between named words and
EXECUTEable things, we could use the same token for both purposes, but
there isn't, thanks to :NONAME, SYNONYM and having several xts
associated with a name (e.g., for S").
On Monday I heard a talk about code obfuscation. One of the
techniques used for that is to combine several opaque types into one,
with a combined set of fields and operations. Normally one would call
that bad factoring or bad design, because it makes the code harder to
understand (and therefore also harder to maintain), but in code
obfuscation that is the point.
>In this discussion, it is perfectly appropriate to suggest that Gforth
>should enhance the functionality of its XTs.
From you that surprises me, because in the past you were very keen on
not prescribing implementation, and wielded words like
"disenfrenchize" in such discussions. I am happy to read that you
will no longer be doing that.
I am happy to discuss any such suggestions, but I have yet to see
them.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-11 10:39 +0000 |
| Message-ID | <593d1a33.325401143@news.eternal-september.org> |
| In reply to | #60573 |
On Sat, 10 Jun 2017 16:28:26 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>There is another way to look at it: problems with FIND and "XTs being >>too simple" are a side effect of some techniques (other than >>IMMEDIATE) for implementing words with non-default compilation >>semantics. If you use IMMEDIATE, there is nothing at all wrong with >>FIND, and there is certainly nothing too simple about an XT. > >The xt still does not represent interpretation and compilation >semantics; you still need to know the immediacy of the word in order >to perform its compilation semantics. The xt should be the single point of reference to a word. If you cannot determine immediacy from it, the implementation is broken. Most systems have a word such as IMMEDIATE? ( xt -- flag ) which permits this operation. In modern systems you also need NDCS? (Non-Default Compilation Semantics) to deal with what the standard permits. >A remaining problem is [: ... ;], which a number of people want to use >interpretively, so [: is a word with non-default non-immediate >compilation semantics in Gforth. I don't have a good idea how to fix >that, yet. It seems to take about 20 years for people to explore all the corners of wording changes. This one is just an example of Non-Default Compilation Semantics being used. Instead of ignoring such words, we should perhaps provide tools to detect them and set them. By sticking to the xt as a single point of reference, and exposing immediacy and Non-Default Compilation Semantics words with words to determine and set these states, we will recognise that the wording changes of ANS-94 are being implemented in systems. Trying to limit the ingenuity of Forth programmers exposed to changed wording is a futile action. We need to deal with reality rather than dogma. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Richard Owlett <rowlett@cloud85.net> |
|---|---|
| Date | 2017-06-11 07:19 -0500 |
| Message-ID | <fcmdnR1QwqP1qKDEnZ2dnUU7-fXNnZ2d@supernews.com> |
| In reply to | #60605 |
On 06/11/2017 05:39 AM, Stephen Pelc wrote: > [snip] > > Trying to limit the ingenuity of Forth programmers exposed to > changed wording is a futile action. We need to deal with reality > rather than dogma. <chuckle> Having passed my allotted three score and ten, I don't expect to see "dealing with reality ..."
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-13 14:04 +0000 |
| Message-ID | <2017Jun13.160403@mips.complang.tuwien.ac.at> |
| In reply to | #60605 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Sat, 10 Jun 2017 16:28:26 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>There is another way to look at it: problems with FIND and "XTs being
>>>too simple" are a side effect of some techniques (other than
>>>IMMEDIATE) for implementing words with non-default compilation
>>>semantics. If you use IMMEDIATE, there is nothing at all wrong with
>>>FIND, and there is certainly nothing too simple about an XT.
>>
>>The xt still does not represent interpretation and compilation
>>semantics; you still need to know the immediacy of the word in order
>>to perform its compilation semantics.
>
>The xt should be the single point of reference to a word.
Not in ANS Forth.
>If you
>cannot determine immediacy from it, the implementation is broken.
Not in ANS Forth nor in Forth-2012. There is no word in these
standards for getting the immediacy out of the xt. And immediacy is
inadequate for specifying words like S", anyway; for that we need to
determine interpretation semantics and compilation semantics. And in
Forth-2012, we have words for getting at those: NAME>INTERPRET and
NAME>COMPILE.
>Most systems have a word such as
>IMMEDIATE? ( xt -- flag )
>which permits this operation.
Among Gforth, iForth, SwiftForth, and VFX, only VFX and Gforth have
"IMMEDIATE?", and in Gforth the stack effect of IMMEDIATE? is ( nt --
flag ). And at least in Gforth, immediacy is associated with the name,
not with the xt; and thanks to SYNONYM and ALIAS, the same xt can have
multiple names, and these names can have different immediacies:
create a ok
synonym b a
*terminal*:4:9: redefined b ok
immediate ok
s" a" find-name immediate? . 0 ok
s" b" find-name immediate? . -1 ok
Because different systems behave differently when applying IMMEDIATE
to a synonym, doing that is an ambiguous condition in Forth-2012.
> In modern systems you also need
>NDCS? (Non-Default Compilation Semantics) to deal with what
>the standard permits.
We already have NAME>COMPILE, no NDCS? or IMMEDIATE? necessary. How
would you use "NDCS?"?
>It seems to take about 20 years for people to explore all the corners
>of wording changes. This one is just an example of Non-Default
>Compilation Semantics being used. Instead of ignoring such words,
>we should perhaps provide tools to detect them and set them.
Gforth has had INTERPRET/COMPILE:, NAME>INT and NAME>COMP
(standardized as NAME>INTERPRET and NAME>COMPILE), and FIND-NAME for
about 20 years, and they have worked fine. And NAME>INTERPRET,
NAME>COMPILE, and FIND-NAME can be implemented in every existing
standard and close-to-standard system.
As for the direction to take: Yes, there are too many Forthers who
like such words to get the genie back in the bottle. So maybe we
should bite the bullet and provide a standard way of letting users
write such words.
Personally, I have not found much use in writing such words, but
others have embraced it whole-heartedly.
>By sticking to the xt as a single point of reference, and exposing
>immediacy and Non-Default Compilation Semantics words with words to
>determine and set these states, we will recognise that the wording
>changes of ANS-94 are being implemented in systems.
>
>Trying to limit the ingenuity of Forth programmers exposed to
>changed wording is a futile action. We need to deal with reality
>rather than dogma.
The reality is that the xt is not a single point of reference (in your
sense), neither in ANS Forth, nor is there common practice for that in
existing and maintained systems.
Forth-2012 exposes compilation semantics through NAME>COMPILE
(independent of whether it is default, immediate, or non-default
non-immediate compilation semantics). What is missing is FIND-NAME
and SEARCH-NAME.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-14 12:50 +0000 |
| Message-ID | <5941223c.589602455@news.eternal-september.org> |
| In reply to | #60695 |
On Tue, 13 Jun 2017 14:04:03 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >stephen@mpeforth.com (Stephen Pelc) writes: >>On Sat, 10 Jun 2017 16:28:26 GMT, anton@mips.complang.tuwien.ac.at >>(Anton Ertl) wrote: >>>The xt still does not represent interpretation and compilation >>>semantics; you still need to know the immediacy of the word in order >>>to perform its compilation semantics. >> >>The xt should be the single point of reference to a word. > >Not in ANS Forth. > >>If you >>cannot determine immediacy from it, the implementation is broken. A Forth system is much more than its compliance to a standard. The base problem is that the standard describes words in terms that cannot be implemented or explored in a standard way. In particular, we have no way to explore separate interpretation and compilation actions - the ones with non-default compilation semantics. Once we fix that, all the hassle of STATE-smart words goes away because we have tools to implement equivalent behaviour in a standard way that works with POSTPONE. Until we can do that, people will write STATE-smart words because there is no alternative. The standard needs to provide an alternative. >Not in ANS Forth nor in Forth-2012. There is no word in these >standards for getting the immediacy out of the xt. And immediacy is >inadequate for specifying words like S", anyway; for that we need to >determine interpretation semantics and compilation semantics. And in >Forth-2012, we have words for getting at those: NAME>INTERPRET and >NAME>COMPILE. That's not enough and is biased to NT-centric systems. >Among Gforth, iForth, SwiftForth, and VFX, only VFX and Gforth have >"IMMEDIATE?", and in Gforth the stack effect of IMMEDIATE? is ( nt -- >flag ). And at least in Gforth, immediacy is associated with the name, >not with the xt; and thanks to SYNONYM and ALIAS, the same xt can have >multiple names, and these names can have different immediacies: Gforth should let NTs be the point of contact with a word and then you can call them XTs. All you need is a dummy header for immediate :NONAMEs. And how about :NONAMEs with separate interpretation and compilation behaviour? There's nothing in the standard to prohibit them, only no standard tools to implement them. The issue here is that we need to set the language philosophy and design (as expressed in the standard) rather than to focus on corner cases. The big trouble with NTs is that they were introduced to fix a problem in TRAVERSE-WORDLIST before any consequences were discussed. Now NTs are opeing the fig-Forth can of worms again. >> In modern systems you also need >>NDCS? (Non-Default Compilation Semantics) to deal with what >>the standard permits. > >We already have NAME>COMPILE, no NDCS? or IMMEDIATE? necessary. How >would you use "NDCS?"? You invented it! You reminded me that words such as IF may return values at compile time so cannot be compiled with COMPILE, - in other words they have to be IMMEDIATE. Similarly words such as S" parse at compile time, so so have non-default compilation semantics. We have no standard tools to implement words with Non-Default Compilation Semantics and we need them. If we do not provide these tools then the standard is guilty of burying its tools. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-15 16:19 +0000 |
| Message-ID | <2017Jun15.181935@mips.complang.tuwien.ac.at> |
| In reply to | #60721 |
stephen@mpeforth.com (Stephen Pelc) writes:
stephen@mpeforth.com (Stephen Pelc) writes:
>On Tue, 13 Jun 2017 14:04:03 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>stephen@mpeforth.com (Stephen Pelc) writes:
>>>On Sat, 10 Jun 2017 16:28:26 GMT, anton@mips.complang.tuwien.ac.at
>>>(Anton Ertl) wrote:
>>>>The xt still does not represent interpretation and compilation
>>>>semantics; you still need to know the immediacy of the word in order
>>>>to perform its compilation semantics.
>>>
>>>The xt should be the single point of reference to a word.
>>
>>Not in ANS Forth.
>>
>>>If you
>>>cannot determine immediacy from it, the implementation is broken.
>
>A Forth system is much more than its compliance to a standard. The
>base problem is that the standard describes words in terms that
>cannot be implemented or explored in a standard way. In particular,
>we have no way to explore separate interpretation and compilation
>actions - the ones with non-default compilation semantics. Once
>we fix that, all the hassle of STATE-smart words goes away because
>we have tools to implement equivalent behaviour in a standard way
>that works with POSTPONE. Until we can do that, people will
>write STATE-smart words because there is no alternative. The
>standard needs to provide an alternative.
So what you mean here is that we need a standard way to define words
with arbitrary combinations of interpretation and compilation
semantics. Gforth has had the following for about two decades:
interpret/compile: ( interp-xt comp-xt "name" –- )
A simple example of that is:
:noname ' defer@ ;
:noname postpone ['] postpone defer@ ;
interpret/compile: action-of ( interpretation "name" -- xt;
( compilation "name" -- ;
( run-time -- xt )
>>Not in ANS Forth nor in Forth-2012. There is no word in these
>>standards for getting the immediacy out of the xt. And immediacy is
>>inadequate for specifying words like S", anyway; for that we need to
>>determine interpretation semantics and compilation semantics. And in
>>Forth-2012, we have words for getting at those: NAME>INTERPRET and
>>NAME>COMPILE.
>
>That's not enough
It's enough to get interpretation and compilation semantics, i.e.,
what we are discussing here. But if you are missing functionality,
please let me know what it is.
>and is biased to NT-centric systems.
Just because it does not exclude (what you call) NT-centric systems
does not mean it's biased to them. On a system where you can get at
everything from the xt, you should have no problem implementing these
words; and looking at VFX, you have implemented them already.
>>Among Gforth, iForth, SwiftForth, and VFX, only VFX and Gforth have
>>"IMMEDIATE?", and in Gforth the stack effect of IMMEDIATE? is ( nt --
>>flag ). And at least in Gforth, immediacy is associated with the name,
>>not with the xt; and thanks to SYNONYM and ALIAS, the same xt can have
>>multiple names, and these names can have different immediacies:
>
>Gforth should let NTs be the point of contact with a word and then you
>can call them XTs. All you need is a dummy header for immediate
>:NONAMEs.
Actually, in the development version of Gforth, the nt and xt of many
words is the same:
s" +" find-name cr . ' + cr .
140309735259024
140309735259024 ok
And in this version you can apply the NAME>... words to xts and you
will get a valid result (but not necessarily the one *you* expect):
:noname ; cr dup . name>string cr . .
140309735823352
0 140309735823328 ok
So a :NONAME word has a 0-length string as name.
And as long as we live in the simple world of simple Forth
definitions, you can use xts and nts interchangeably in the
development version of Gforth.
But once you get into stuff like SYNONYMS and INTERPRET/COMPILE:
words, you no longer have a 1:1 relation between nts and xts, and this
shows up in getting different xts from nts for the same word, and when
you (try to perform) xt operations on nts and vice versa:
: foo ." foo" ; ok
synonym bar foo ok
' foo cr . ' bar cr . s" foo" find-name cr . s" bar" find-name cr .
140309735823416
140309735823416
140309735823416
140309735823560 ok
s" foo" find-name execute foo ok
s" bar" find-name execute
*the terminal*:13: error: Invalid memory address
s" bar" find-name >>>execute<<<
' foo name>string type foo ok
' bar name>string type foo ok
: flip ." flip" ; ok
: flop ." flop" ; ok
' flip ' flop interpret/compile: flipflop ok
flipflop flip ok
: test flipflop ; flop ok
' flip cr . ' flipflop cr . ' flop cr . s" flipflop" find-name cr .
139666024978584
139666024978584
139666024978728
139666024978872 ok
' flipflop name>string type flip ok
s" flipflop" find-name execute
*the terminal*:17: error: Invalid memory address
s" flipflop" find-name name>compile cr . cr . ' flop cr .
139666024411520
139666024978728
139666024978728 ok
s" flipflop" find-name name>compile cr name>string type cr name>string type
execute
flop ok
As you can see here, even in a system that tries to have xt=nt, there
is a difference in a number of cases. One might implement a nicer
behaviour in those cases where EXECUTEing an nt produces an "Invalid
memory address" exception (at a cost in complexity), but the other
cases are a natural consequence of the requirements.
>And how about :NONAMEs with separate interpretation and compilation
>behaviour?
You can create such a word in development Gforth with
' flip ' flop noname interpret/compile:
However, at the moment there is no good way to get at the nt nor any
of the xts of this word.
But anyway, what's the point of such a word? Interpretation semantics
and compilation semantics are there for text interpretation of a word,
but without a name you cannot use it directly in text interpretation
(nor in POSTPONE or ').
>The issue here is that we need to set the language philosophy and
>design (as expressed in the standard) rather than to focus on corner
>cases.
A design that does not work in corner cases is a mis-design.
>The big trouble with NTs is that they were introduced to
>fix a problem in TRAVERSE-WORDLIST before any consequences were
>discussed. Now NTs are opeing the fig-Forth can of worms again.
We discussed the consequences at the time and you expressed that
concern at the time, very insistently, but you were eventually
convinced that NTs are necessary.
NTs are necessary because of features that fig-Forth does not have,
and therefore have nothing to do with fig-Forth. These features are
SYNONYMs, separate headers, and INTERPRET/COMPILE:. If we remove all
these features from our Forth systems, then yes, there will be a 1:1
relation between NTs and XTs, and we can unify these two concepts.
Note that in the Gforth examples above, the xt<>nt cases are those
where the features mentioned above come into play (except separate
headers; we don't have that in Gforth).
>>> In modern systems you also need
>>>NDCS? (Non-Default Compilation Semantics) to deal with what
>>>the standard permits.
>>
>>We already have NAME>COMPILE, no NDCS? or IMMEDIATE? necessary. How
>>would you use "NDCS?"?
>
>You invented it! You reminded me that words such as IF may return
>values at compile time so cannot be compiled with COMPILE, - in
>other words they have to be IMMEDIATE. Similarly words such as
>S" parse at compile time, so so have non-default compilation
>semantics. We have no standard tools to implement words with
>Non-Default Compilation Semantics and we need them.
Maybe we need INTERPRET/COMPILE:, but that still does not tell me how
you would use "NDCS?"; and I certainly did not invent "NDCS?". As far
as I can tell, you did.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-02 07:59 +0000 |
| Message-ID | <2017Jun2.095932@mips.complang.tuwien.ac.at> |
| In reply to | #60147 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Alex <alex@rivadpm.com> wrote:
>> FIND is dead. An XT is too simple.
>
>LOL! Forth is too simple as well, I guess.
On the contrary, Forth is too complex to represent a word completely
with an ANS Forth xt. This complexity is reflected in the
specification of FIND: If an ANS Forth xt was sufficient, FIND would
have the stack effect ( c-addr -- xt|0 ) and would always return the
same xt when finding the same word. Instead, FIND returns a flag that
indicates immediacy in order to support both normal and immediate
words; and it can return different xts depending on STATE in order to
support words like S".
Now we could simplify Forth to make the ANS Forth xt sufficient; i.e.,
get rid of S", and all the other words with non-default non-immediate
compilation semantics in order to get rid of the STATE-dependence of
FIND. And get rid of all words with non-default compilation semantics
(e.g., IF) in order to eliminate the need for the immediate flag. But
I don't think we will find a consensus on these measures.
The alternative is to actually reflect the complexity of named Forth
words in the tokens that represent them. The nt achieves this, and it
allows simplifying the uses of the token. With the nt, we can have
FIND-NAME ( c-addr u -- nt|0 )
and the dictionary part of a text interpreter can look like
2dup find-name ?dup if
nip nip state @ if
name>compile
else
name>interpret
then
execute
else
... deal with numbers etc. ...
then
whereas the FIND-based interpreter loop (as presented by Mitch Bradley
in an email) is:
| ( c-addr )
| 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
You can also try to combine some of the IFs, as attempted by Stephen
Pelc <55991d60.337125477@news.eternal-september.org>:
> find dup if
> state @ 0< and if
> compile,
> else
> execute
> then
> else
> drop count undefined
> then
But the complexity rears its ugly head, as demonstrated by the fact
that this code is buggy.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2017-06-02 11:48 +0200 |
| Message-ID | <86zidqk9dr.fsf@molnjunk.nocrew.org> |
| In reply to | #60184 |
Anton Ertl writes: > the FIND-based interpreter loop (as presented by Mitch Bradley > in an email) is: > > | ( c-addr ) > | 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 > > You can also try to combine some of the IFs, as attempted by Stephen Pelc > >> find dup if >> state @ 0< and if >> compile, >> else >> execute >> then >> else >> drop count undefined >> then > > But the complexity rears its ugly head, as demonstrated by the fact > that this code is buggy. In my (biased and subjective) opinition, it's possible to do better than both of these. My version has no IFs at all. It's quite simple. But really, the implementation details of the interpreter aren't that important, are they?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-02 10:24 +0000 |
| Message-ID | <2017Jun2.122445@mips.complang.tuwien.ac.at> |
| In reply to | #60185 |
Lars Brinkhoff <lars.spam@nocrew.org> writes:
>Anton Ertl writes:
>> the FIND-based interpreter loop (as presented by Mitch Bradley
>> in an email) is:
>>
>> | ( c-addr )
>> | 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
>>
>> You can also try to combine some of the IFs, as attempted by Stephen Pelc
>>
>>> find dup if
>>> state @ 0< and if
>>> compile,
>>> else
>>> execute
>>> then
>>> else
>>> drop count undefined
>>> then
>>
>> But the complexity rears its ugly head, as demonstrated by the fact
>> that this code is buggy.
>
>In my (biased and subjective) opinition, it's possible to do better than
>both of these. My version has no IFs at all. It's quite simple.
Please show it.
>But really, the implementation details of the interpreter aren't that
>important, are they?
Some people claim to write a lot of user-defined text interpreters,
and for them the issue may be of direct relevance. My guess is that
they use it as a pattern, so as long as the treatment of immediacy and
STATE is the same for all of them, the only effect will be that the
code is a little longer.
However, I used them for demonstrative purposes. One side claims that
we should have only the xt as a word representation, and justifies
this with simplicity. These text interpreters, which were not written
by clueless newbies, demonstrate that this position ("dogma" is
apparently not PC) leads to more complexity in the code.
- 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/
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web