Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54361
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Recognizers |
| Date | 2017-01-24 16:23 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2017Jan24.172324@mips.complang.tuwien.ac.at> (permalink) |
| References | <o61k4o$9he$1@dont-email.me> <2017Jan22.154253@mips.complang.tuwien.ac.at> <o668pq$gmt$1@dont-email.me> |
Bernd Paysan <bernd@net2o.de> writes:
>Am Sun, 22 Jan 2017 14:42:53 +0000 schrieb Anton Ertl:
>
>> OTOH, such programs probably are not fit for postpone state anyway, and
>> even if the standard would say that only -1 means compile state,
>> and the program was written as
>>
>> state @ case
>> 0 of int-state-stuff endof
>> 1 of comp-state-stuff endof
>> true abort" unknown STATE"
>> endcase
>
>No user-defined word sees postpone state, as the interpreter in postpone
>state postpones everything, until it finds [[.
Good point. Certainly the code occuring between ]] and [[ would not
see the unusual state.
However, the (user-defined) code for the postpone part of a recognizer
would see it. But that is new code that should know about the
existence of postpone state (if we implement it as a state) and know
how to deal with that. I also have trouble imagining an accidential
way in which a recognizer could call a state-smart word that would
produce something useful in interpretation and compilation state, and
fail in postpone state. So, as it stands, -2 as postpone state would
be acceptable by me, despite the exhaustive specification in
Forth-94/2012.
- 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
Recognizers Alex <alex@rivadpm.com> - 2017-01-22 01:42 -0500
Re: Recognizers Matthias Trute <matthias.trute@gmail.com> - 2017-01-22 03:06 -0800
Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-22 14:42 +0000
Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-22 17:26 -0500
Re: Recognizers Bernd Paysan <bernd@net2o.de> - 2017-01-24 00:57 +0000
Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-24 16:23 +0000
Re: Recognizers Bernd Paysan <bernd@net2o.de> - 2017-01-24 21:47 +0000
Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 08:30 -0500
Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 08:57 -0500
Re: Recognizers Matthias Trute <matthias.trute@gmail.com> - 2017-01-23 10:58 -0800
Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-23 14:45 -0500
Re: Recognizers JennyB <jennybrien@googlemail.com> - 2017-01-27 15:05 -0800
Re: Recognizers Alex <alex@rivadpm.com> - 2017-01-29 22:54 +0000
Re: Recognizers JennyB <jennybrien@googlemail.com> - 2017-01-30 09:11 -0800
Re: Recognizers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-30 16:34 +0000
Re: Recognizers Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-01-31 21:03 +0000
Re: Recognizers albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-01 12:37 +0100
csiph-web