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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-01 09:08 +0000 |
| Message-ID | <2017Jun1.110816@mips.complang.tuwien.ac.at> |
| In reply to | #60128 |
minforth@arcor.de writes:
>Am Donnerstag, 1. Juni 2017 08:22:34 UTC+2 schrieb Anton Ertl:
>
>> Anyway, there are Forth systems that have an xt for interpretation and
>> something independent for compilation, in order to implement words
>> such as S" (ANS Forth). On these systems you cannot get to the
>> compilation semantics from the interpretation semantics (or vice
>> versa).
>
>This is definitely not true.
If it was not true, you could demonstrate that by showing the code for
getting from the xt for interpretation semantics to the compilation
semantics in Gforth <=0.7.3. But it is true, so you cannot.
- 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 | minforth@arcor.de |
|---|---|
| Date | 2017-06-01 03:33 -0700 |
| Message-ID | <0f171ad4-18d3-43bf-801c-6875b0137b43@googlegroups.com> |
| In reply to | #60134 |
Am Donnerstag, 1. Juni 2017 11:15:36 UTC+2 schrieb Anton Ertl: > minforth@arcor.de writes: > >Am Donnerstag, 1. Juni 2017 08:22:34 UTC+2 schrieb Anton Ertl: > > > >> Anyway, there are Forth systems that have an xt for interpretation and > >> something independent for compilation, in order to implement words > >> such as S" (ANS Forth). On these systems you cannot get to the > >> compilation semantics from the interpretation semantics (or vice > >> versa). > > > >This is definitely not true. > > If it was not true, you could demonstrate that by showing the code for > getting from the xt for interpretation semantics to the compilation > semantics in Gforth <=0.7.3. But it is true, so you cannot. > Only for gforth zealots, apparently. ;-)
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-01 09:05 +0000 |
| Message-ID | <592fd139.668296177@news.eternal-september.org> |
| In reply to | #60126 |
On Thu, 01 Jun 2017 05:50:57 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >stephen@mpeforth.com (Stephen Pelc) writes: >>IMHO name tokens had a rationale for TRAVERSE-WORDLIST, but I was >>afraid that they would open the FIG-Forth can of worms that ANS >>nailed shut with the XT. Now we see that indeed NTs are rampant, but >>just replicating existing practice. > >Can you elaborate on that? Which can of worms do you mean? Do you >think that FIND-NAME/SEARCH-NAME opens it, and if so, why? I don't >understand what you mean with the last sentence at all. I mean exposing the whole header navigation word set. Internally, most systems have words to traverse dictionary headers. In FIG-Forth they were standardised, e.g. >NFA ( xt -- nfa ). From ANS onwards, these words were retired. I still see very little need to expose them again. >>The whole point of an XT was to provide a single point of reference to >>a word. an XT is an opaque type (anything the implementation wants it >>to be). In many systems it's the address of the interpretation >>behaviour of the word - it's optimised for EXECUTE. The cost of >>providing a link to a name field or name token is a single >>instruction on most desktop CPUs and even just one on most modern >>embedded CPUs. > >In Gforth <=0.7 there is no reliable way to get to the name field, if >one even exists. Do you want to disenfrenchise systems that are >implemented that way, and prescribe the implementation to provide a >link to the name field? To use one of your favourite phrases, it's a quality of implementation issue. MPE values the source management facilities provided by LOCATE and XREF enough to provide the access. If you make these tools using other techniques, you may not need direct access. I'm not trying to disenfranchise a system at all, I'm trying to retain the original ANS meaning of an XT. >>The ghastliness of multiple xts for compilation actions is just >>exposing internal structures that should not be exposed. The idea >>of the ANS XT applies today just as much as did in 1994. > >Your idea of xts is incompatible with ANS Forth. Have you fixed VFX's >COMPILE, to be ANS Forth compliant already? Remember, in ANS Forth >and Forth-2012 its stack effect is > >COMPILE, ( xt -- ) > >I can dig out the bug report again that I sent you two years ago. Your bug report was very helpful in clarifying my view of interpretation and compilation in Forth-2012. The report basically says that COMPILE, cannot be used for words that parse or have a stack effect, e.g. IF. These are the words that have non-default compilation semantics (NDCS). In VFX I can define NDCS, as the analogue for COMPILE, for these words. In practice, the definition for VFX is: : NDCS, ( i*x xt -- j*x ; may parse ) COMPILE, ; >Anyway, there are Forth systems that have an xt for interpretation and >something independent for compilation, in order to implement words >such as S" (ANS Forth). On these systems you cannot get to the >compilation semantics from the interpretation semantics (or vice >versa). Do you want to disenfrenchise these systems by prescribing the >implementation? These systems have already broken the idea of an XT. These systems are already broken. >An NT provides access to interpretation and compilation semantics, and >to the word name. That's an implementation issue for a system with a broken XT. >An XT can only be EXECUTEd and COMPILE,d; you cannot get the >interpretation and compilation semantics of a word from it in ANS >Forth or Forth-2012, nor the word name. That is reflected in the >definition of FIND (ANS Forth and Forth-2012): People regularly store XTs in variables and tables. See DEFER and IS. >|For a given string, the values returned by FIND while compiling may >|differ from those returned while not compiling. > >If the xt was the single point of reference to a word as you claim, >this sentence would make no sense. cmForth made little sense at the time. That sentence is just a concession to cmForth. It was a mistake in 1994 and it's still unnecessary in 2017. The dual wordlist approach is just a bad design decision in the long term. Building tables of XTs when you do not know whether you can use the XT with COMPILE, just forces you to build special tools and double the size of the table by having separate interpretation and compilation entries. The simple way: create atable \ -- addr ' foo , ' bar , ... The bad way: create atable \ -- addr 'interp foo , 'comp foo , 'interp bar , 'comp bar , ... Having two results from FIND disenfranchises simple techniques in Forth that have been available for a very long time. Multiple results from FIND is a mistake that leads to complexity. The XT as a single point of contact promotes simplicity. 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-01 15:05 +0100 |
| Message-ID | <ogp6oc$fbd$1@dont-email.me> |
| In reply to | #60132 |
On 6/1/2017 10:05, Stephen Pelc wrote: > On Thu, 01 Jun 2017 05:50:57 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: > >> stephen@mpeforth.com (Stephen Pelc) writes: >>> IMHO name tokens had a rationale for TRAVERSE-WORDLIST, but I was >>> afraid that they would open the FIG-Forth can of worms that ANS >>> nailed shut with the XT. Now we see that indeed NTs are rampant, but >>> just replicating existing practice. >> >> Can you elaborate on that? Which can of worms do you mean? Do you >> think that FIND-NAME/SEARCH-NAME opens it, and if so, why? I don't >> understand what you mean with the last sentence at all. > > I mean exposing the whole header navigation word set. Internally, > most systems have words to traverse dictionary headers. In FIG-Forth > they were standardised, e.g. >NFA ( xt -- nfa ). From ANS onwards, > these words were retired. I still see very little need to expose > them again. This isn't a proposal to do that, and I've not suggested it. I suspect this may be a peptic response to the original NAME>xxx words where I suspect you think they were snuck in under the radar (or at least, I got that feeling from the discussion at the time). Proposed is an analog to SEARCH-WORDLIST that returns the NT; and the number of Forth systems that seem to have NTs and a word that searches and returns an NT is quite significant. > >>> The whole point of an XT was to provide a single point of reference to >>> a word. an XT is an opaque type (anything the implementation wants it >>> to be). In many systems it's the address of the interpretation >>> behaviour of the word - it's optimised for EXECUTE. The cost of >>> providing a link to a name field or name token is a single >>> instruction on most desktop CPUs and even just one on most modern >>> embedded CPUs. >> >> In Gforth <=0.7 there is no reliable way to get to the name field, if >> one even exists. Do you want to disenfrenchise systems that are >> implemented that way, and prescribe the implementation to provide a >> link to the name field? > > To use one of your favourite phrases, it's a quality of implementation > issue. MPE values the source management facilities provided by LOCATE > and XREF enough to provide the access. If you make these tools using > other techniques, you may not need direct access. I'm not trying to > disenfranchise a system at all, I'm trying to retain the original > ANS meaning of an XT. The original meaning would imply that you can't do anything with it other than store, fetch, execute and compile. You certainly can't get its name or work out whether it's immediate or completely bent out of shape like S". In WF32, I prefix the XT address with a pointer to the NT (actually, it's encoded as a 5 byte JMP to stop the disassembler from barfing or getting out of sync). That also means having a dummy entry to support :NONAME and quotations for orthogonality. It also means that code fragments that don't start at XT boundaries can't be processed by some tools, especially an optimizer, since there's no way to tell if an address has an NT or not. And they need the NT, as they have the semantic information to help the optimizer. I'd say; a Heath Robinson collection of XT pieces to allow for quality tools. > >>> The ghastliness of multiple xts for compilation actions is just >>> exposing internal structures that should not be exposed. The idea >>> of the ANS XT applies today just as much as did in 1994. >> >> Your idea of xts is incompatible with ANS Forth. Have you fixed VFX's >> COMPILE, to be ANS Forth compliant already? Remember, in ANS Forth >> and Forth-2012 its stack effect is >> >> COMPILE, ( xt -- ) >> >> I can dig out the bug report again that I sent you two years ago. > > Your bug report was very helpful in clarifying my view of > interpretation and compilation in Forth-2012. The report basically > says that COMPILE, cannot be used for words that parse or have a > stack effect, e.g. IF. These are the words that have non-default > compilation semantics (NDCS). In VFX I can define NDCS, as the > analogue for COMPILE, for these words. In practice, the > definition for VFX is: > : NDCS, ( i*x xt -- j*x ; may parse ) COMPILE, ; I.e. not fixed? > >> Anyway, there are Forth systems that have an xt for interpretation and >> something independent for compilation, in order to implement words >> such as S" (ANS Forth). On these systems you cannot get to the >> compilation semantics from the interpretation semantics (or vice >> versa). Do you want to disenfrenchise these systems by prescribing the >> implementation? > > These systems have already broken the idea of an XT. These systems > are already broken. > >> An NT provides access to interpretation and compilation semantics, and >> to the word name. > > That's an implementation issue for a system with a broken XT. Actually, an NT is just like an XT. There is absolutely nothing stopping a system having all NTs as XTs and using : execute name>interpret xt-execute ; : compile, name>compile xt-compile, ; Where it falls down is the lack of support with SEARCH-WORDLIST and FIND to return an XT, when an NT analog SEARCH-NAME and FIND-NAME are required. > >> An XT can only be EXECUTEd and COMPILE,d; you cannot get the >> interpretation and compilation semantics of a word from it in ANS >> Forth or Forth-2012, nor the word name. That is reflected in the >> definition of FIND (ANS Forth and Forth-2012): > > People regularly store XTs in variables and tables. See DEFER and IS > >> |For a given string, the values returned by FIND while compiling may >> |differ from those returned while not compiling. >> >> If the xt was the single point of reference to a word as you claim, >> this sentence would make no sense. > > cmForth made little sense at the time. That sentence is just a > concession to cmForth. It was a mistake in 1994 and it's still > unnecessary in 2017. The dual wordlist approach is just a bad > design decision in the long term. > > Building tables of XTs when you do not know whether you can use the XT > with COMPILE, just forces you to build special tools and double the > size of the table by having separate interpretation and compilation > entries. The simple way: > create atable \ -- addr > ' foo , > ' bar , > ... > The bad way: > create atable \ -- addr > 'interp foo , 'comp foo , > 'interp bar , 'comp bar , > ... > Not a problem with NTs. Just make a table of them. > Having two results from FIND disenfranchises simple techniques in > Forth that have been available for a very long time. Multiple results > from FIND is a mistake that leads to complexity. The XT as a single > point of contact promotes simplicity. FIND is dead. An XT is too simple. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-01 10:05 -0500 |
| Message-ID | <hKydnVY_4s3asK3EnZ2dnUU7-WWdnZ2d@supernews.com> |
| In reply to | #60145 |
Alex <alex@rivadpm.com> wrote: > FIND is dead. An XT is too simple. LOL! Forth is too simple as well, I guess. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-01 16:32 +0100 |
| Message-ID | <ogpbsj$25a$1@dont-email.me> |
| In reply to | #60147 |
On 6/1/2017 16:05, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> FIND is dead. An XT is too simple. > > LOL! Forth is too simple as well, I guess. Well, you got me. It should have read (to paraphrase Anton) "An XT is too simple, and often wrong". Forth is simple, but it is increasingly obvious (to me) as I explore programs beyond filling & emptying washing machines, that the language has some corners that are a good deal uglier than I would like, and much uglier than many here are willing to admit. Some of the use cases that Anton discusses might seem like exotic edge cases, but that's the thing; being exotic and being an edge case aren't necessarily mutually exclusive. Hugh, for all his evil rants here, has made the case that FIND is broken. I wouldn't suggest for a moment that he's exercising the language anywhere near the edge; nor that he is writing exotic code. He's quite a traditional & stiffly formal programmer, and he's noticed the problem. I do however disagree with his analysis and solution. The fault lies not with FIND, but with a naked XT, and the assumption that it will do the right thing without any other context beyond immediacy. That is what makes XTs too simple, and often wrong. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2017-06-01 09:31 -0700 |
| Message-ID | <c82bf701-bd9a-42bb-8a96-54a5195c1d6f@googlegroups.com> |
| In reply to | #60148 |
On Thursday, June 1, 2017 at 8:32:54 AM UTC-7, Alex wrote: > I do however disagree with his analysis and solution. The fault lies not > with FIND, but with a naked XT, and the assumption that it will do the > right thing without any other context beyond immediacy. That is what > makes XTs too simple, and often wrong. > It's not necessarily a case of being wrong. The architecture might not be single-xt friendly. FIND has been proven over several decades of industry use so the "gotchas" are known. The more recent proposals aren't nearly so broken-in. The single point-of-contact xt is simple. Modern Forth systems aren't designed in a way that the xt (such as the execution address of native code) can easily be converted to an address in header space or a pointer to clever compile semantics. This is a good case for 64-bit Forths. You can pack compile and execution semantics into a single cell. To fix the single-xt problem in a 32-bit system, I'd compile to code space a 4-byte pointer to header space right before the executable code. "4 - @" would get me to the header space and carnal knowledge stuff.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-01 19:00 +0100 |
| Message-ID | <ogpkgn$7ma$1@dont-email.me> |
| In reply to | #60152 |
On 6/1/2017 17:31, Brad Eckert wrote: > On Thursday, June 1, 2017 at 8:32:54 AM UTC-7, Alex wrote: > >> I do however disagree with his analysis and solution. The fault >> lies not with FIND, but with a naked XT, and the assumption that it >> will do the right thing without any other context beyond immediacy. >> That is what makes XTs too simple, and often wrong. >> > It's not necessarily a case of being wrong. The architecture might > not be single-xt friendly. FIND has been proven over several decades > of industry use so the "gotchas" are known. The more recent proposals > aren't nearly so broken-in. It's the XT that's the problem, not FIND. > > The single point-of-contact xt is simple. Modern Forth systems aren't > designed in a way that the xt (such as the execution address of > native code) can easily be converted to an address in header space or > a pointer to clever compile semantics. For some XTs (like those that parse for example) there are no correct semantics for the XT under all conditions. It's nothing to do with cleverness, but a lot to do with correctness. > > This is a good case for 64-bit Forths. You can pack compile and > execution semantics into a single cell. Not for 64 bit addresses you can't. > > To fix the single-xt problem in a 32-bit system, I'd compile to code > space a 4-byte pointer to header space right before the executable > code. "4 - @" would get me to the header space and carnal knowledge > stuff. Which is what my Forth does; except it's a relative address, so DUP CELL- @ +. That only works for XTs with a name, so for XTs without a name (:NONAME [: DOES> etc) it returns a dummy NT. Although NAME>STRING returns something almost meaningful (the string ":NONAME"), NAME>INTERPRET and NAME>COMPILE (now, not in the current git version) return ABORT! and ABORT! EXECUTE respectively, since the header is shared by every anonymous XT. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-06-04 22:56 +0000 |
| Message-ID | <59348fd4.979250037@news.eternal-september.org> |
| In reply to | #60158 |
On Thu, 1 Jun 2017 19:00:09 +0100, Alex <alex@rivadpm.com> wrote: >> The single point-of-contact xt is simple. Modern Forth systems aren't >> designed in a way that the xt (such as the execution address of >> native code) can easily be converted to an address in header space or >> a pointer to clever compile semantics. > >For some XTs (like those that parse for example) there are no correct >semantics for the XT under all conditions. It's nothing to do with >cleverness, but a lot to do with correctness. Please expand on this. I've just been to visit a new grandchild, and my brain may still be in too primitive a mode to understand this. 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 | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-05 14:41 +0100 |
| Message-ID | <oh3mr4$lvf$1@dont-email.me> |
| In reply to | #60307 |
On 6/4/2017 23:56, Stephen Pelc wrote: > On Thu, 1 Jun 2017 19:00:09 +0100, Alex <alex@rivadpm.com> wrote: > >>> The single point-of-contact xt is simple. Modern Forth systems aren't >>> designed in a way that the xt (such as the execution address of >>> native code) can easily be converted to an address in header space or >>> a pointer to clever compile semantics. >> >> For some XTs (like those that parse for example) there are no correct >> semantics for the XT under all conditions. It's nothing to do with >> cleverness, but a lot to do with correctness. > > Please expand on this. I've just been to visit a new grandchild, and Now that's worth getting all mushy about. Congratulations. > my brain may still be in too primitive a mode to understand this. > > Stephen > http://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf see 4.2; in fact, see the whole paper. I know you will have already read it several times. I should really have said "For some XTs (like those that are state smart for example)...". I was thinking of S". Recognizers and this paper make for a fine example of why me might want to consider standardizing recognizers. I am really quite bowled over by their simple, consistent and almost foolproof extensibility, all while leaving the essence of the Forth interpret/compile word/number approach undisturbed. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-02 03:07 -0500 |
| Message-ID | <4v2dnYUzuLdLgazEnZ2dnUU7-RfNnZ2d@supernews.com> |
| In reply to | #60148 |
Alex <alex@rivadpm.com> wrote: > On 6/1/2017 16:05, Andrew Haley wrote: >> Alex <alex@rivadpm.com> wrote: >>> FIND is dead. An XT is too simple. >> >> LOL! Forth is too simple as well, I guess. > > Well, you got me. It should have read (to paraphrase Anton) "An XT > is too simple, and often wrong". > > Forth is simple, but it is increasingly obvious (to me) as I explore > programs beyond filling & emptying washing machines, that the > language has some corners that are a good deal uglier than I would > like, and much uglier than many here are willing to admit. > > Some of the use cases that Anton discusses might seem like exotic > edge cases, but that's the thing; being exotic and being an edge > case aren't necessarily mutually exclusive. Hugh, for all his evil > rants here, has made the case that FIND is broken. I wouldn't > suggest for a moment that he's exercising the language anywhere near > the edge; nor that he is writing exotic code. He's quite a > traditional & stiffly formal programmer, and he's noticed the > problem. > > I do however disagree with his analysis and solution. The fault lies > not with FIND, but with a naked XT, and the assumption that it will > do the right thing without any other context beyond immediacy. That > is what makes XTs too simple, and often wrong. 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. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-10 16:28 +0000 |
| Message-ID | <2017Jun10.182826@mips.complang.tuwien.ac.at> |
| In reply to | #60180 |
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.
But sure, if we only had normal and immediate words, we could remove
the provision from the standard that the results of FIND may depend on
STATE. Will you make a proposal for turning all words with
non-default compilation semantics (and all words with undefined
interpretation semantics) into either normal or immediate words? Will
such a proposal actually find consensus?
My impression is that there are significant parts of the Forth
community that are very much in love with "smart" words, and that goes
a long way back. Forth-83 gave us ' and ['] to avoid STATE-smartness,
and at around the same time several Forth systems (IIRC including F83)
introduced STATE-smart ASCII; Forth-94 split that into CHAR and
[CHAR], but in the same standard introduced S" and TO.
You may want your Forth (polyForth?) back, but we will not reach a
consensus for standardizing your Forth. And the result of obstructing
anything (including improvements over the present state) that's not in
the direction of your Forth is going to be a worse (even in your
sense) and also less relevant standard than we could otherwise
achieve.
In recent years we have taken steps in Gforth to get rid of undefined
interpretation semantics (most of these words are now immediate, some
are normal, a few (e.g., DOES>) are neither; they all can be ticked,
and interpreting or ticking most of them produces a warning). Also,
all standard words with non-default non-immediate compilation
semantics are now superfluous (except for writing standard programs):
Instead of S" and S\", one can use the string recognizer ("mystring");
instead of TO and IS, one can use the to-recognizer (->myvalue
->mydefer), and ACTION-OF has always been redundant thanks to DEFER@.
The interpretive use of DOES> could be replaced with SET-DOES>, and
DOES> be turned into an immediate word.
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.
Anyway, my point is that the complexity of non-default non-immediate
words is there because of requirements from some Forth users (enough
that all Forth systems have this crap in some form or other); we can
get rid of this complexity by providing alternative solutions, but we
do have to provide them. We won't get rid of it by pretending that
these requirements don't exist.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-11 02:14 -0500 |
| Message-ID | <06GdnQ7u4dVFcKHEnZ2dnUU7-f_NnZ2d@supernews.com> |
| In reply to | #60573 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> 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. Good point. > But sure, if we only had normal and immediate words, we could remove > the provision from the standard that the results of FIND may depend on > STATE. Will you make a proposal for turning all words with > non-default compilation semantics (and all words with undefined > interpretation semantics) into either normal or immediate words? Will > such a proposal actually find consensus? I don't expect that it would, so I won't, but the fact remains that the "problem" -- if there is one -- with XTs that makes them "too simple" is a property of some implementations, not of the language as such. > You may want your Forth (polyForth?) back, but we will not reach a > consensus for standardizing your Forth. Certainly not, no, and for that reason I wouldn't propose it, no matter how much better I thought it was. I wouldn't propose anything that I didn't think would be likely to achieve consensus. > And the result of obstructing anything (including improvements over > the present state) that's not in the direction of your Forth is > going to be a worse (even in your sense) and also less relevant > standard than we could otherwise achieve. Well, hold on: pointing out that there are simple solutions, and that the supposed problem is not a a failure of language design but a consequence of its misuse isn't being obstructive. > My impression is that there are significant parts of the Forth > community that are very much in love with "smart" words, and that goes > a long way back. Forth-83 gave us ' and ['] to avoid STATE-smartness, > and at around the same time several Forth systems (IIRC including F83) > introduced STATE-smart ASCII; Forth-94 split that into CHAR and > [CHAR], but in the same standard introduced S" and TO. ['] and [CHAR] came from polyFORTH II which didn't have STATE in any form. I don't know why S" and TO were allowed in; perhaps Elizabeth can remember. > 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. Why not just say "no"? Isn't the interpretive use of these words the same as :NONAME anyway? > Anyway, my point is that the complexity of non-default non-immediate > words is there because of requirements from some Forth users (enough > that all Forth systems have this crap in some form or other); we can > get rid of this complexity by providing alternative solutions, but we > do have to provide them. We won't get rid of it by pretending that > these requirements don't exist. We already have a clean solution: every state-smart word should provide its components. That's no more than a matter of good coding style. So, for every state-smart FOO there is a (FOO) and a [FOO]. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-11 10:55 +0000 |
| Message-ID | <2017Jun11.125542@mips.complang.tuwien.ac.at> |
| In reply to | #60599 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> But sure, if we only had normal and immediate words, we could remove
>> the provision from the standard that the results of FIND may depend on
>> STATE. Will you make a proposal for turning all words with
>> non-default compilation semantics (and all words with undefined
>> interpretation semantics) into either normal or immediate words? Will
>> such a proposal actually find consensus?
>
>I don't expect that it would, so I won't, but the fact remains that
>the "problem" -- if there is one -- with XTs that makes them "too
>simple" is a property of some implementations, not of the language as
>such.
S" is not a property of some implementations, it's part of the
language standard. It cannot be implemented correctly in a way that
FIND delivers the same xt in either state, unless we sacrifice the
requirement that FIND can be used to write a text interpreter.
More generally, interpretation and compilation semantics, and
arbitrary combinations of them are part of the language standard.
Even more generally, we get these kinds of words from the requirement
that code can be cut-and-pasted between interpreted and compiled code.
Where does this requirement come from? It's a property of a good part
of the language (normal words and numbers), so it's no wonder people
want to extend it to more or all of the language. The question is if
we do it properly or if we cut corners and then get unintended
behaviour in corner cases.
>> And the result of obstructing anything (including improvements over
>> the present state) that's not in the direction of your Forth is
>> going to be a worse (even in your sense) and also less relevant
>> standard than we could otherwise achieve.
>
>Well, hold on: pointing out that there are simple solutions, and that
>the supposed problem is not a a failure of language design but a
>consequence of its misuse isn't being obstructive.
I am not sure what you are referring to. Below you propose a
solution, but if you proposed this solution earlier in discussions on
this topic, I must have missed it. And what do you mean with "its
misuse" in the present context?
Anyway, rare occurences of misuse are not a reason to adjust the
language design (at least for Forth; and hypothetical misuses should
be even less of a reason to reject recognizers), but in the case of
S"-like words they pop up so regularly, that we should come to grips
with their existence, and adjust our implementations to implement them
properly. And for FIND that means to either accept the
state-dependent behaviour of Forth-94 (and it's coming from Chuck
Moore, after all) or replace it with FIND-NAME.
>> 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.
>
>Why not just say "no"?
Technically, we have solved the problem of implementing such words.
And as long as we have to implement S" etc., there is no reason to not
also have an interpretive "[:".
>Isn't the interpretive use of these words the
>same as :NONAME anyway?
Pretty much, yes. There is some small difference, but I forget what
it was. I think the main motivation is not this difference, but the
cut-n-paste requirement. I think that several people have asked for
this interpretive behaviour of [: in the RfD phase of the quotations
proposal, supporting the view that many consider the cut-n-paste
requirement important (the shortness of [: ... ;] compared to :NONAME
... ; may also contribute).
>> Anyway, my point is that the complexity of non-default non-immediate
>> words is there because of requirements from some Forth users (enough
>> that all Forth systems have this crap in some form or other); we can
>> get rid of this complexity by providing alternative solutions, but we
>> do have to provide them. We won't get rid of it by pretending that
>> these requirements don't exist.
>
>We already have a clean solution: every state-smart word should
>provide its components. That's no more than a matter of good coding
>style. So, for every state-smart FOO there is a (FOO) and a [FOO].
So your solution is to implement S" as STATE-smart word, adjust the
standard accordingly, and also provide (S") and [S"] as part of the
API? And likewise for all the other words of this kind.
A convention can be a solution to a technical problem, if it is
commonly accepted and followed. In the present case, I don't see that
happening: No such words are specified in Forth-94 or Forth-2012, and
AFAICS neither SwiftForth, VFX, iForth nor Gforth documents such
words. So while such a convention may in theory be able solve the
problem, in practice that has not happened yet.
I suggested this solution in 1998 (in
<https://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf>,
section 4.1), and there have been enough discussions about
STATE-smartness and enough mentionings of this paper (at least 53 in
Usenet articles by me) that everybody concerned should have come
across it; so if they have not picked it up, it seems they did not
find it compelling enough.
But maybe I just did not present it well enough, and if you propose
changing the standard accordingly, we will find consensus that this is
the way to go. But if we don't, it's not a general solution to the
problem.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-12 03:22 -0500 |
| Message-ID | <dbGdnW6EQMvJ0qPEnZ2dnUU7-X_NnZ2d@supernews.com> |
| In reply to | #60608 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> But sure, if we only had normal and immediate words, we could remove >>> the provision from the standard that the results of FIND may depend on >>> STATE. Will you make a proposal for turning all words with >>> non-default compilation semantics (and all words with undefined >>> interpretation semantics) into either normal or immediate words? Will >>> such a proposal actually find consensus? >> >>I don't expect that it would, so I won't, but the fact remains that >>the "problem" -- if there is one -- with XTs that makes them "too >>simple" is a property of some implementations, not of the language as >>such. > > S" is not a property of some implementations, it's part of the > language standard. It cannot be implemented correctly in a way that > FIND delivers the same xt in either state, unless we sacrifice the > requirement that FIND can be used to write a text interpreter. Maybe, but we've discussed that before, and It can be fixed by relaxing the specification of S" etc. to make it clear that a STATE-smart implementation is legal. I do not believe the the original ANS TC intended to make STATE-smart implementations of S" illegal. And I've not yet found an implementation of FIND that can't be used to write a text interpreter. >>> And the result of obstructing anything (including improvements over >>> the present state) that's not in the direction of your Forth is >>> going to be a worse (even in your sense) and also less relevant >>> standard than we could otherwise achieve. >> >>Well, hold on: pointing out that there are simple solutions, and that >>the supposed problem is not a a failure of language design but a >>consequence of its misuse isn't being obstructive. > > I am not sure what you are referring to. Below you propose a > solution, but if you proposed this solution earlier in discussions on > this topic, I must have missed it. I'm not proposing anything that is not already well-known and, at least to people skilled in the art, obvious. > And what do you mean with "its misuse" in the present context? STATE-smart words which can't be used as factors, such as S". It's a violation of the "Don't bury your tools" principle. >>We already have a clean solution: every state-smart word should >>provide its components. That's no more than a matter of good coding >>style. So, for every state-smart FOO there is a (FOO) and a [FOO]. > > So your solution is to implement S" as STATE-smart word, adjust the > standard accordingly, and also provide (S") and [S"] as part of the > API? And likewise for all the other words of this kind. It's not clear to me at this point whether we're discussing S" etc. or the use of STATE-smart words in application code. If there's a need to use S" and TO as factors, then it would make good sense to do that, yes. But that depends not on the general principle, but on whether anyone needs to use them as factors. I certainly would not want to add more dead wood to the standard. I have suggested clarifying the language which defines S" and TO in order to remove any doubt that STATE-smart versions of these words are legal. While I'm not convinced that such a change is actually necessary, it would remove some ambiguity. On the other hand, it would cost a fair bit of time without advancing anything very much. In the wider case, it makes sense for anyone contemplating writing a STATE-smart word to make its components available separately and to use a convention when naming them. But their first thought should not be "How shall I write this STATE-smart word?" but "Should I write this STATE-smart word?" > I suggested this solution in 1998 (in > <https://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf>, > section 4.1), and there have been enough discussions about > STATE-smartness and enough mentionings of this paper (at least 53 in > Usenet articles by me) that everybody concerned should have come > across it; so if they have not picked it up, it seems they did not > find it compelling enough. It seems obvious, and quite unremarkable. > But maybe I just did not present it well enough, and if you propose > changing the standard accordingly, we will find consensus that this is > the way to go. But if we don't, it's not a general solution to the > problem. I don't think that this follows. To the extent that the problem really exists, it's a solution that any programmer can use. In what sense does a committee need to be involved? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-13 15:21 +0000 |
| Message-ID | <2017Jun13.172153@mips.complang.tuwien.ac.at> |
| In reply to | #60647 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> But sure, if we only had normal and immediate words, we could remove
>>>> the provision from the standard that the results of FIND may depend on
>>>> STATE. Will you make a proposal for turning all words with
>>>> non-default compilation semantics (and all words with undefined
>>>> interpretation semantics) into either normal or immediate words? Will
>>>> such a proposal actually find consensus?
>>>
>>>I don't expect that it would, so I won't, but the fact remains that
>>>the "problem" -- if there is one -- with XTs that makes them "too
>>>simple" is a property of some implementations, not of the language as
>>>such.
>>
>> S" is not a property of some implementations, it's part of the
>> language standard. It cannot be implemented correctly in a way that
>> FIND delivers the same xt in either state, unless we sacrifice the
>> requirement that FIND can be used to write a text interpreter.
>
>Maybe, but we've discussed that before, and It can be fixed by relaxing
>the specification of S" etc. to make it clear that a STATE-smart
>implementation is legal. I do not believe the the original ANS TC
>intended to make STATE-smart implementations of S" illegal.
Yes, they probably wanted to allow such an implementation. However,
in the 18 years between Forth-94 and 2012 nobody, not even those with
STATE-smart implementations of S" have proposed relaxing the
specification of S", plus a new word S\" was introduced that cannot be
implemented in a STATE-smart way while being compliant with the
specification, either. So the implementors of STATE-smart systems are
apparently not interested very much in compliance in this area, so
maybe we should not be worrying about it, either.
>And I've
>not yet found an implementation of FIND that can't be used to write a
>text interpreter.
Yes, but in order to make that work, FIND is STATE-dependent in
Gforth. If you want to tighten FIND so that it cannot produce a
state-dependent result, the result would be that user-defined text
interpreters would no longer work in Gforth.
>> And what do you mean with "its misuse" in the present context?
>
>STATE-smart words which can't be used as factors, such as S". It's a
>violation of the "Don't bury your tools" principle.
[...]
>>>We already have a clean solution: every state-smart word should
>>>provide its components. That's no more than a matter of good coding
>>>style. So, for every state-smart FOO there is a (FOO) and a [FOO].
>>
>> So your solution is to implement S" as STATE-smart word, adjust the
>> standard accordingly, and also provide (S") and [S"] as part of the
>> API? And likewise for all the other words of this kind.
>
>It's not clear to me at this point whether we're discussing S" etc. or
>the use of STATE-smart words in application code.
First, the standard words, i.e., S" S\" TO IS ACTION-OF. If the
solution is to provide the STATE-independent factors, the standard
should set an example and provide such factors for all these words.
There is nothing the standard can do about user-written code except
give a good example itself.
>If there's a need to use S" and TO as factors, then it would make good
>sense to do that, yes. But that depends not on the general principle,
>but on whether anyone needs to use them as factors. I certainly would
>not want to add more dead wood to the standard.
I have certainly come across a case where I wanted to POSTPONE TO, and
having [TO] available in that case would have been beneficial.
And if you think that the solution is to provide such factors with a
standard naming convention, then you should go ahead and propose
providing them. The additional words cost very little in the
implementation (the functionality is there anyway).
And on the programmer side, it's easier when they are all available
instead of only some; even when it's not hard to work around the
absence of these words, as for IS (thanks to DEFER!), it's still
easier to directly use the factors when you want to POSTPONE and tick
such words, rather than working out how to program a workaround.
As for the all-important word count, you can see these additional
words as the cost of having such words, or as the cost of allowing
STATE-smart implementations.
>I have suggested clarifying the language which defines S" and TO in
>order to remove any doubt that STATE-smart versions of these words are
>legal.
TO, IS, and ACTION-OF already cannot be ticked or POSTPONEd.
>In the wider case, it makes sense for anyone contemplating writing a
>STATE-smart word to make its components available separately and to
>use a convention when naming them. But their first thought should not
>be "How shall I write this STATE-smart word?" but "Should I write this
>STATE-smart word?"
Unfortunately, the answer of many has been "yes". And they generally
have not provided the components, and certainly no naming convention
for these components has been established.
>> I suggested this solution in 1998 (in
>> <https://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf>,
>> section 4.1), and there have been enough discussions about
>> STATE-smartness and enough mentionings of this paper (at least 53 in
>> Usenet articles by me) that everybody concerned should have come
>> across it; so if they have not picked it up, it seems they did not
>> find it compelling enough.
>
>It seems obvious, and quite unremarkable.
And yet nobody does it.
>> But maybe I just did not present it well enough, and if you propose
>> changing the standard accordingly, we will find consensus that this is
>> the way to go. But if we don't, it's not a general solution to the
>> problem.
>
>I don't think that this follows. To the extent that the problem
>really exists, it's a solution that any programmer can use. In what
>sense does a committee need to be involved?
You propose implementing S" S\" TO IS ACTION-OF as STATE-smart words,
and that the solution for ticking and POSTPONEing is to provide
STATE-independent components. If the committee agrees with this
solution, then the committee should add the component words for these
words, both for direct use, and to set an example for other use.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-14 04:10 -0500 |
| Message-ID | <4Y2dnc3jhr7uYN3EnZ2dnUU7-aXNnZ2d@supernews.com> |
| In reply to | #60701 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> >>> S" is not a property of some implementations, it's part of the >>> language standard. It cannot be implemented correctly in a way that >>> FIND delivers the same xt in either state, unless we sacrifice the >>> requirement that FIND can be used to write a text interpreter. >> >>Maybe, but we've discussed that before, and It can be fixed by relaxing >>the specification of S" etc. to make it clear that a STATE-smart >>implementation is legal. I do not believe the the original ANS TC >>intended to make STATE-smart implementations of S" illegal. > > Yes, they probably wanted to allow such an implementation. However, > in the 18 years between Forth-94 and 2012 nobody, not even those with > STATE-smart implementations of S" have proposed relaxing the > specification of S", plus a new word S\" was introduced that cannot be > implemented in a STATE-smart way while being compliant with the > specification, either. So the implementors of STATE-smart systems are > apparently not interested very much in compliance in this area, so > maybe we should not be worrying about it, either. Exactly, and neither should we worry about whether such implementations of S" are legal or not: they exist, and real-world portable Forth programs have to cope with them. So the argument: >>> S" is not a property of some implementations, it's part of the >>> language standard. It cannot be implemented correctly in a way that >>> FIND delivers the same xt in either state, unless we sacrifice the >>> requirement that FIND can be used to write a text interpreter. is moot. Arguing that S" "cannot be implemented correctly..." is pointless. It can be implemented, and it is. >>And I've not yet found an implementation of FIND that can't be used >>to write a text interpreter. > > Yes, but in order to make that work, FIND is STATE-dependent in > Gforth. If you want to tighten FIND so that it cannot produce a > state-dependent result, the result would be that user-defined text > interpreters would no longer work in Gforth. I don't want to tighten FIND in that way. >>It's not clear to me at this point whether we're discussing S" etc. or >>the use of STATE-smart words in application code. > > First, the standard words, i.e., S" S\" TO IS ACTION-OF. If the > solution is to provide the STATE-independent factors, the standard > should set an example and provide such factors for all these words. > There is nothing the standard can do about user-written code except > give a good example itself. I agree with all of that -- its logic is irrefutable -- but the standard is already large, so I'm a bit more cautious than you about the "should set an example" conclusion. >>If there's a need to use S" and TO as factors, then it would make good >>sense to do that, yes. But that depends not on the general principle, >>but on whether anyone needs to use them as factors. I certainly would >>not want to add more dead wood to the standard. > > I have certainly come across a case where I wanted to POSTPONE TO, and > having [TO] available in that case would have been beneficial. Yes. But from what I remember locals can be neither ticked or POSTPONEd, so it's rather marginal unless that is fixed too. > And if you think that the solution is to provide such factors with a > standard naming convention, then you should go ahead and propose > providing them. The additional words cost very little in the > implementation (the functionality is there anyway). It's certainly a solution, but it would make little sense to propose a bunch of words without the general principle being accepted. > And on the programmer side, it's easier when they are all available > instead of only some; even when it's not hard to work around the > absence of these words, as for IS (thanks to DEFER!), it's still > easier to directly use the factors when you want to POSTPONE and tick > such words, rather than working out how to program a workaround. > > As for the all-important word count, you can see these additional > words as the cost of having such words, or as the cost of allowing > STATE-smart implementations. I agree entirely. >>In the wider case, it makes sense for anyone contemplating writing a >>STATE-smart word to make its components available separately and to >>use a convention when naming them. But their first thought should not >>be "How shall I write this STATE-smart word?" but "Should I write this >>STATE-smart word?" > > Unfortunately, the answer of many has been "yes". And they generally > have not provided the components, and certainly no naming convention > for these components has been established. Sure, and I was like that when I was an inexperienced Forth programmer too. But I got over it when I discovered that the applications (and the customers) were more interesting than futzing with the language and the more trickery I wrote the longer it took to debug the applications. >>> But maybe I just did not present it well enough, and if you propose >>> changing the standard accordingly, we will find consensus that this is >>> the way to go. But if we don't, it's not a general solution to the >>> problem. >> >>I don't think that this follows. To the extent that the problem >>really exists, it's a solution that any programmer can use. In what >>sense does a committee need to be involved? > > You propose implementing S" S\" TO IS ACTION-OF as STATE-smart words, > and that the solution for ticking and POSTPONEing is to provide > STATE-independent components. If the committee agrees with this > solution, then the committee should add the component words for these > words, both for direct use, and to set an example for other use. The problem is that other committee members ahve found their own workarounds for this problem, and understandably are wedded to their own solutions. It's a tempting proposition, though. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-06-15 10:43 +0000 |
| Message-ID | <2017Jun15.124349@mips.complang.tuwien.ac.at> |
| In reply to | #60714 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>
>>>> S" is not a property of some implementations, it's part of the
>>>> language standard. It cannot be implemented correctly in a way that
>>>> FIND delivers the same xt in either state, unless we sacrifice the
>>>> requirement that FIND can be used to write a text interpreter.
>>>
>>>Maybe, but we've discussed that before, and It can be fixed by relaxing
>>>the specification of S" etc. to make it clear that a STATE-smart
>>>implementation is legal. I do not believe the the original ANS TC
>>>intended to make STATE-smart implementations of S" illegal.
>>
>> Yes, they probably wanted to allow such an implementation. However,
>> in the 18 years between Forth-94 and 2012 nobody, not even those with
>> STATE-smart implementations of S" have proposed relaxing the
>> specification of S", plus a new word S\" was introduced that cannot be
>> implemented in a STATE-smart way while being compliant with the
>> specification, either. So the implementors of STATE-smart systems are
>> apparently not interested very much in compliance in this area, so
>> maybe we should not be worrying about it, either.
>
>Exactly, and neither should we worry about whether such
>implementations of S" are legal or not: they exist, and real-world
>portable Forth programs have to cope with them. So the argument:
>
>>>> S" is not a property of some implementations, it's part of the
>>>> language standard. It cannot be implemented correctly in a way that
>>>> FIND delivers the same xt in either state, unless we sacrifice the
>>>> requirement that FIND can be used to write a text interpreter.
>
>is moot. Arguing that S" "cannot be implemented correctly..." is
>pointless. It can be implemented, and it is.
One can also implement OR to mean XOR, and it has actually been done.
That does not make that implementation a correct standard-compliant
implementation, and does not make the specification of OR in the
standard moot. And no, Forth programs do not have to cope with all
kinds of implementation behaviour in the name of real-world
portability. They can specify that their program is
standard-compliant, and leave it to the users of systems that do not
comply with the standard to switch to a standard-compliant system; and
if the non-compliant system claims to be standard, they can also
report a bug, and, as you once told me, they can also take it to the
courts.
But if you were right, and Forth programmers just had to deal with
whatever non-compliance the system implementors throw at them, why
would we need a standard? Why are you on the committee.
>>>It's not clear to me at this point whether we're discussing S" etc. or
>>>the use of STATE-smart words in application code.
>>
>> First, the standard words, i.e., S" S\" TO IS ACTION-OF. If the
>> solution is to provide the STATE-independent factors, the standard
>> should set an example and provide such factors for all these words.
>> There is nothing the standard can do about user-written code except
>> give a good example itself.
>
>I agree with all of that -- its logic is irrefutable -- but the
>standard is already large, so I'm a bit more cautious than you about
>the "should set an example" conclusion.
Ah, the word count issue. There is an alternative: Make these words
obsolescent. Of course we need a replacement for this functionality,
and we have one: For S" and S\", the string recognizer ("bla bla");
for TO and IS, the TO-recognizer (->myvalue). For ACTION-OF, I would
just use a sequence involving DEFER@: instead of ACTION-OF FOO, have
['] FOO DEFER@.
>> I have certainly come across a case where I wanted to POSTPONE TO, and
>> having [TO] available in that case would have been beneficial.
>
>Yes. But from what I remember locals can be neither ticked or
>POSTPONEd, so it's rather marginal unless that is fixed too.
What is rather marginal?
As for defining ticking and POSTPONEing locals, sure, if you think
that is needed, make a proposal.
I have not encountered a need to tick or POSTPONE locals and there is
a technical reason for that. They are only valid inside a colon
definition.
So when doing normal programming, when you tick a local, you have to
EXECUTE it within the same colon definition; COMPILE,ing it makes no
sense (the result would be performed outside this colon definition);
likewise, POSTPONEing a local makes no sense. For the
tick-and-execute case, one can construct cases that are not complete
nonsense, but it's hard to find one where if offers anything that
cannot be done just as easily in a different way. E.g.
: foo {: a b :} ... if ['] a else ['] myconst then ... execute use ... ;
Writing
: foo {: a b :} ... if a else myconst then ... use ... ;
is shorter. At the moment, I cannot find an example that would be
shorter with ticking.
Outside normal programming, when writing a compiler (and probably also
for other meta-programming tasks), it could be useful to generate an
anonymous local, and get a handle to it (e.g., the xt or nt), store it
in the compiler's symbol table, and use it when generating the code
for the rest of the definition. But the current locals interface does
not give us that: (LOCAL) takes a name and produces a named local, and
you then have to refer to the local by name. If you have to deal with
name strings for locals anyway, there is no point in ticking or
POSTPONing the local. The way to go is to just EVALUATE the local
when you want to compile a read from it, and to EVALUATE "TO <local>"
when you want to compile a write to it (with appropriate precautions
so that the right TO is seen). Even with a handle, the TO-case cannot
be done in the current standard setting, so if we want to cover that
area, we would need to fix that, too.
>> And if you think that the solution is to provide such factors with a
>> standard naming convention, then you should go ahead and propose
>> providing them. The additional words cost very little in the
>> implementation (the functionality is there anyway).
>
>It's certainly a solution, but it would make little sense to propose a
>bunch of words without the general principle being accepted.
It's unlikely that the bunch of words is accepted without the
acceptance of the general principle, but in any case, it's a good idea
to phrase your proposal as proposing the general principle, and these
words as a consequence of that. Of course, it's not clear if such a
proposal will be accepted, but it will hopefully advance the
discussion.
>>>In the wider case, it makes sense for anyone contemplating writing a
>>>STATE-smart word to make its components available separately and to
>>>use a convention when naming them. But their first thought should not
>>>be "How shall I write this STATE-smart word?" but "Should I write this
>>>STATE-smart word?"
>>
>> Unfortunately, the answer of many has been "yes". And they generally
>> have not provided the components, and certainly no naming convention
>> for these components has been established.
>
>Sure, and I was like that when I was an inexperienced Forth programmer
>too. But I got over it when I discovered that the applications (and
>the customers) were more interesting than futzing with the language
>and the more trickery I wrote the longer it took to debug the
>applications.
It seems that the experiences have diverged in this area. I for one
would have been happy with DEFER@, but a committee member (not an
inexperienced programmer) insisted on adding ACTION-OF.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-06-15 09:11 -0500 |
| Message-ID | <-emdnUDf3ME4CN_EnZ2dnUU7-WHNnZ2d@supernews.com> |
| In reply to | #60776 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>
>>>>> S" is not a property of some implementations, it's part of the
>>>>> language standard. It cannot be implemented correctly in a way that
>>>>> FIND delivers the same xt in either state, unless we sacrifice the
>>>>> requirement that FIND can be used to write a text interpreter.
>>>>
>>>>Maybe, but we've discussed that before, and It can be fixed by relaxing
>>>>the specification of S" etc. to make it clear that a STATE-smart
>>>>implementation is legal. I do not believe the the original ANS TC
>>>>intended to make STATE-smart implementations of S" illegal.
>>>
>>> Yes, they probably wanted to allow such an implementation. However,
>>> in the 18 years between Forth-94 and 2012 nobody, not even those with
>>> STATE-smart implementations of S" have proposed relaxing the
>>> specification of S", plus a new word S\" was introduced that cannot be
>>> implemented in a STATE-smart way while being compliant with the
>>> specification, either. So the implementors of STATE-smart systems are
>>> apparently not interested very much in compliance in this area, so
>>> maybe we should not be worrying about it, either.
>>
>>Exactly, and neither should we worry about whether such
>>implementations of S" are legal or not: they exist, and real-world
>>portable Forth programs have to cope with them. So the argument:
>>
>>>>> S" is not a property of some implementations, it's part of the
>>>>> language standard. It cannot be implemented correctly in a way that
>>>>> FIND delivers the same xt in either state, unless we sacrifice the
>>>>> requirement that FIND can be used to write a text interpreter.
>>
>>is moot. Arguing that S" "cannot be implemented correctly..." is
>>pointless. It can be implemented, and it is.
>
> One can also implement OR to mean XOR, and it has actually been done.
> That does not make that implementation a correct standard-compliant
> implementation, and does not make the specification of OR in the
> standard moot.
That's hardly a similar situation.
> But if you were right, and Forth programmers just had to deal with
> whatever non-compliance the system implementors throw at them,
I didn't say that.
> why would we need a standard? Why are you on the committee.
>>> First, the standard words, i.e., S" S\" TO IS ACTION-OF. If the
>>> solution is to provide the STATE-independent factors, the standard
>>> should set an example and provide such factors for all these words.
>>> There is nothing the standard can do about user-written code except
>>> give a good example itself.
>>
>>I agree with all of that -- its logic is irrefutable -- but the
>>standard is already large, so I'm a bit more cautious than you about
>>the "should set an example" conclusion.
>
> Ah, the word count issue. There is an alternative: Make these words
> obsolescent. Of course we need a replacement for this functionality,
> and we have one: For S" and S\", the string recognizer ("bla bla");
> for TO and IS, the TO-recognizer (->myvalue). For ACTION-OF, I would
> just use a sequence involving DEFER@: instead of ACTION-OF FOO, have
> ['] FOO DEFER@.
Indeed. To every problem there is a recognizer solution!
>>> I have certainly come across a case where I wanted to POSTPONE TO, and
>>> having [TO] available in that case would have been beneficial.
>>
>>Yes. But from what I remember locals can be neither ticked or
>>POSTPONEd, so it's rather marginal unless that is fixed too.
>
> What is rather marginal?
Why would you want to POSTPONE TO other than with a local? TO's only
other use is for VALUEs, and there's scarcely a pressing need to use
VALUEs when metaprogramming.
> If you have to deal with name strings for locals anyway, there is no
> point in ticking or POSTPONing the local. The way to go is to just
> EVALUATE the local when you want to compile a read from it, and to
> EVALUATE "TO <local>" when you want to compile a write to it (with
> appropriate precautions so that the right TO is seen). Even with a
> handle, the TO-case cannot be done in the current standard setting,
> so if we want to cover that area, we would need to fix that, too.
Right, so my point is made, I think: I can't see much use for [TO] :
you might as well EVALUATE "to foo".
>>> And if you think that the solution is to provide such factors with a
>>> standard naming convention, then you should go ahead and propose
>>> providing them. The additional words cost very little in the
>>> implementation (the functionality is there anyway).
>>
>>It's certainly a solution, but it would make little sense to propose a
>>bunch of words without the general principle being accepted.
>
> It's unlikely that the bunch of words is accepted without the
> acceptance of the general principle, but in any case, it's a good
> idea to phrase your proposal as proposing the general principle, and
> these words as a consequence of that. Of course, it's not clear if
> such a proposal will be accepted, but it will hopefully advance the
> discussion.
I wonder. It seems to me that everyone has their own preferred
solution, and that they tend to stick to that solution. Practice
diverges very widely. I would like to know why simple compatible
solutions like this one haven't been accepted.
>>>>In the wider case, it makes sense for anyone contemplating writing a
>>>>STATE-smart word to make its components available separately and to
>>>>use a convention when naming them. But their first thought should not
>>>>be "How shall I write this STATE-smart word?" but "Should I write this
>>>>STATE-smart word?"
>>>
>>> Unfortunately, the answer of many has been "yes". And they generally
>>> have not provided the components, and certainly no naming convention
>>> for these components has been established.
>>
>>Sure, and I was like that when I was an inexperienced Forth programmer
>>too. But I got over it when I discovered that the applications (and
>>the customers) were more interesting than futzing with the language
>>and the more trickery I wrote the longer it took to debug the
>>applications.
>
> It seems that the experiences have diverged in this area. I for one
> would have been happy with DEFER@, but a committee member (not an
> inexperienced programmer) insisted on adding ACTION-OF.
I would have though that the experience of lying on one's back inside
a machine while trying to debug a control system would be quite enough
to cure people of such regrettable tendencies, but evidently not.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-06-14 02:55 -0700 |
| Message-ID | <e3fd170d-0d83-4c6c-b1cc-3a7c53685c60@googlegroups.com> |
| In reply to | #60701 |
Am Dienstag, 13. Juni 2017 18:30:58 UTC+2 schrieb Anton Ertl: > > TO, IS, and ACTION-OF already cannot be ticked or POSTPONEd. > I have read such statements now and then but haven't really thought it through: Now POSTPONE retrieves the compilation semantics of a word. But in dual-XT Forth systems retrieving the compilation semantics is a breeze, because the compilation token may be within the header structure. So ticking or postponing TO can be clear and bijective, but only in certain Forth implementations that can provide the compilation token of each word by some internal means. Or did I miss something?
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web