Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #50849 > unrolled thread
| Started by | Alex Dowad <alexinbeijing@gmail.com> |
|---|---|
| First post | 2016-09-11 06:12 -0700 |
| Last post | 2016-09-12 14:08 +0200 |
| Articles | 20 on this page of 96 — 19 participants |
Back to article view | Back to comp.lang.forth
Given a string, create word with that name (in ANS Forth)? Alex Dowad <alexinbeijing@gmail.com> - 2016-09-11 06:12 -0700
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-11 10:51 -0500
Re: Given a string, create word with that name (in ANS Forth)? Alex Dowad <alexinbeijing@gmail.com> - 2016-09-11 09:49 -0700
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-11 19:57 +0200
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-12 02:43 -0500
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-11 14:31 -0700
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-11 10:14 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 07:46 +0000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-12 01:10 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 09:01 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 14:02 +0200
Re: Given a string, create word with that name (in ANS Forth)? "HAA" <someone@microsoft.com> - 2016-09-20 12:06 +1000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-20 11:27 +0200
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-12 13:02 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-13 16:20 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-13 21:08 +0200
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-13 17:30 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-14 07:11 +0000
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-14 18:30 -0700
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-15 02:46 -0500
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-20 14:27 -0700
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-20 15:05 -0700
Re: Given a string, create word with that name (in ANS Forth)? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-20 22:19 +0000
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-21 12:26 +0000
Re: Given a string, create word with that name (in ANS Forth)? Coos Haak <htrofhc@gmail.com> - 2016-09-21 15:11 +0200
Re: Given a string, create word with that name (in ANS Forth)? mhx@iae.nl - 2016-09-21 10:06 -0700
Re: Given a string, create word with that name (in ANS Forth)? Coos Haak <htrofhc@gmail.com> - 2016-09-21 21:12 +0200
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-21 12:06 -1000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-21 15:40 -0700
Re: Given a string, create word with that name (in ANS Forth)? "HAA" <someone@microsoft.com> - 2016-09-22 13:04 +1000
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-22 07:40 +0000
Re: Given a string, create word with that name (in ANS Forth)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-22 15:46 +0100
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-22 11:08 -0700
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-22 22:04 +0200
Re: Given a string, create word with that name (in ANS Forth)? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-09-23 10:21 +0100
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-23 12:06 +0200
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-23 10:44 -0500
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-23 16:26 +0000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-24 03:46 -0500
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-24 10:13 +0000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-24 10:34 -0500
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-24 20:19 +0200
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-24 09:47 -1000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-24 14:29 -0700
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-24 13:00 -1000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-24 16:19 -0700
Re: Given a string, create word with that name (in ANS Forth)? jim.brakefield@ieee.org - 2016-09-24 19:02 -0700
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-24 21:23 -1000
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-25 19:08 -0700
Re: Given a string, create word with that name (in ANS Forth)? jim.brakefield@ieee.org - 2016-09-25 19:53 -0700
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-25 20:00 -0700
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-25 17:40 -0700
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-25 01:42 -0500
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-24 23:45 -0700
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-25 02:22 -0500
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 15:31 +0000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-26 10:42 -0500
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 15:57 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 19:11 +0200
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-24 21:28 -1000
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-25 18:55 -0700
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-25 09:35 +0200
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 15:38 +0000
Re: Given a string, create word with that name (in ANS Forth)? hughaguilar96@gmail.com - 2016-09-26 12:36 -0700
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-24 20:26 +0200
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-25 15:22 +0000
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-25 10:44 -0700
Re: Given a string, create word with that name (in ANS Forth)? Coos Haak <htrofhc@gmail.com> - 2016-09-25 19:55 +0200
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-25 20:15 +0200
Re: Given a string, create word with that name (in ANS Forth)? Coos Haak <htrofhc@gmail.com> - 2016-09-25 20:26 +0200
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-25 11:12 -0700
Re: Given a string, create word with that name (in ANS Forth)? Julian Fondren <julian.fondren@gmail.com> - 2016-09-25 11:30 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-26 14:51 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 14:16 +0200
Re: Given a string, create word with that name (in ANS Forth)? "Elizabeth D. Rather" <erather@forth.com> - 2016-09-23 07:52 -1000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-23 10:36 -0500
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 13:55 +0200
Re: Given a string, create word with that name (in ANS Forth)? Lars Brinkhoff <lars.spam@nocrew.org> - 2016-09-12 15:01 +0200
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-12 17:29 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 21:02 +0200
Re: Given a string, create word with that name (in ANS Forth)? Paul Rubin <no.email@nospam.invalid> - 2016-09-12 13:04 -0700
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 22:33 +0200
Re: Given a string, create word with that name (in ANS Forth)? lawrencedo99@gmail.com - 2016-09-16 18:38 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-17 05:33 +0000
Re: Given a string, create word with that name (in ANS Forth)? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-17 01:40 -0500
Re: Given a string, create word with that name (in ANS Forth)? lawrencedo99@gmail.com - 2016-09-16 23:47 -0700
Re: Given a string, create word with that name (in ANS Forth)? Julian Fondren <julian.fondren@gmail.com> - 2016-09-17 00:08 -0700
Re: Given a string, create word with that name (in ANS Forth)? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-17 17:03 +0000
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 22:35 +0200
Re: Given a string, create word with that name (in ANS Forth)? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-09-17 08:16 +0100
Re: Given a string, create word with that name (in ANS Forth)? Mark Wills <markwills1970@gmail.com> - 2016-09-12 02:49 -0700
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 14:04 +0200
Re: Given a string, create word with that name (in ANS Forth)? Cecil Bayona <cbayona@cbayona.com> - 2016-09-12 09:34 -0500
Re: Given a string, create word with that name (in ANS Forth)? Mark Wills <markwills1970@gmail.com> - 2016-09-12 08:10 -0700
Re: Given a string, create word with that name (in ANS Forth)? Cecil Bayona <cbayona@cbayona.com> - 2016-09-12 12:02 -0500
Re: Given a string, create word with that name (in ANS Forth)? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-12 14:08 +0200
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-09-20 14:27 -0700 |
| Message-ID | <9qGdnYbhwMJINHzKnZ2dnUU7-UWdnZ2d@supernews.com> |
| In reply to | #50908 |
On 9/12/16 1:02 PM, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>>> Gforth provides NEXTNAME ( c-addr u -- ), >>> Any chance of proposing standardizing it? >> Nobody is going to stop you from proposing it. Whether it is accepted >> by the committee is doubtful > > OK, that's basically what I was asking. You're saying that such a > proposal is unlikely to be successful. That's a sufficient answer. > Thanks. > >> Questions that might be asked are: How much common practice is there? > > It seems to me like many Forths must already have a mechanism like that > under the covers somewhere. They all do, but they're very different. There's not enough common practice to standardize. >> And is EXECUTE-PARSING not a better approach to the same problem? If >> not, why not? > > The implementation I looked at seemed painfully complicated. Yes. Andrew's comment is accurate. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-09-20 15:05 -0700 |
| Message-ID | <0ea91ef4-3ee7-49df-bc2e-1cf9bffecb36@googlegroups.com> |
| In reply to | #51137 |
On Tuesday, September 20, 2016 at 2:27:54 PM UTC-7, Elizabeth D. Rather wrote: > On 9/12/16 1:02 PM, Paul Rubin wrote: > > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > >>>> Gforth provides NEXTNAME ( c-addr u -- ), > >>> Any chance of proposing standardizing it? > >> Nobody is going to stop you from proposing it. Whether it is accepted > >> by the committee is doubtful > > > > OK, that's basically what I was asking. You're saying that such a > > proposal is unlikely to be successful. That's a sufficient answer. > > Thanks. > > > >> Questions that might be asked are: How much common practice is there? > > > > It seems to me like many Forths must already have a mechanism like that > > under the covers somewhere. > > They all do, but they're very different. There's not enough common > practice to standardize. Common enough practice where? You only are familiar with Forth Inc. --- the Forth Inc. "programmers" are just sales-people though, with little or no programming knowledge --- I use :NAME throughout the novice package, and I used something similar (HEADER from UR/Forth) throughout MFX when I was employed as a Forth programmer > >> And is EXECUTE-PARSING not a better approach to the same problem? If > >> not, why not? > > > > The implementation I looked at seemed painfully complicated. > > Yes. Andrew's comment is accurate. Andrew Haley --- employee of the month at Forth Inc. yet again! --- the office flunky loves to be praised by his boss...
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2016-09-20 22:19 +0000 |
| Message-ID | <nrscls$fm4$2@news.albasani.net> |
| In reply to | #51139 |
On 2016-09-20, hughaguilar96@gmail.com <hughaguilar96@gmail.com> wrote: > On Tuesday, September 20, 2016 at 2:27:54 PM UTC-7, Elizabeth D. Rather wrote: >> On 9/12/16 1:02 PM, Paul Rubin wrote: >> > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> >>>> Gforth provides NEXTNAME ( c-addr u -- ), >> >>> Any chance of proposing standardizing it? >> >> Nobody is going to stop you from proposing it. Whether it is accepted >> >> by the committee is doubtful >> > >> > OK, that's basically what I was asking. You're saying that such a >> > proposal is unlikely to be successful. That's a sufficient answer. >> > Thanks. >> > >> >> Questions that might be asked are: How much common practice is there? >> > >> > It seems to me like many Forths must already have a mechanism like that >> > under the covers somewhere. >> >> They all do, but they're very different. There's not enough common >> practice to standardize. > > Common enough practice where? You only are familiar with Forth Inc. --- > the Forth Inc. "programmers" are just sales-people though, with little or > no programming knowledge --- I use :NAME throughout the novice package, > and I used something similar (HEADER from UR/Forth) throughout MFX when I > was employed as a Forth programmer Learn to properly format text, first. Before starting to accuse others... Line that does not fits into 1920 pixels wide screen is anoying to read...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-09-21 12:26 +0000 |
| Message-ID | <2016Sep21.142608@mips.complang.tuwien.ac.at> |
| In reply to | #51137 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 9/12/16 1:02 PM, Paul Rubin wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>> Gforth provides NEXTNAME ( c-addr u -- ),
>>>> Any chance of proposing standardizing it?
>>> Nobody is going to stop you from proposing it. Whether it is accepted
>>> by the committee is doubtful
>>
>> OK, that's basically what I was asking. You're saying that such a
>> proposal is unlikely to be successful. That's a sufficient answer.
>> Thanks.
>>
>>> Questions that might be asked are: How much common practice is there?
>>
>> It seems to me like many Forths must already have a mechanism like that
>> under the covers somewhere.
>
>They all do, but they're very different. There's not enough common
>practice to standardize.
I am not aware that any other Forth system has anything like NEXTNAME,
but if they all have, please enlighten me.
And that would certainly be common practice; we have a standardization
process for overcoming the differences in the details; before the
Forth-94 effort, every hosted system had a way to open a file, all
different; the Forth-94 committee fortunately did not take the stance
that there was no common practice; instead, they standardized
OPEN-FILE, R/O, R/W, W/O, and BIN.
>>> And is EXECUTE-PARSING not a better approach to the same problem? If
>>> not, why not?
>>
>> The implementation I looked at seemed painfully complicated.
>
>Yes. Andrew's comment is accurate.
None of the many lines you quoted was written by anyone called Andrew
(unless Paul Rubin is also called Andrew; I definitely am not).
A better way to say what you mean is to reduce the quoted material to
that what you agree with, and then express your agreement. Of course,
the question remains if "I agree" postings really contribute something
useful.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2016-09-21 15:11 +0200 |
| Message-ID | <8y2v0vnos5ks$.goz3e7avo0fq$.dlg@40tude.net> |
| In reply to | #51148 |
Op Wed, 21 Sep 2016 12:26:08 GMT schreef Anton Ertl: > I am not aware that any other Forth system has anything like NEXTNAME, > but if they all have, please enlighten me. > > - anton ciforth and chforth call it POSTFIX groet Coos
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-09-21 10:06 -0700 |
| Message-ID | <3b931c64-8c10-4421-8176-5cc9a3bfe799@googlegroups.com> |
| In reply to | #51149 |
On Wednesday, September 21, 2016 at 3:11:39 PM UTC+2, Coos Haak wrote:
> Op Wed, 21 Sep 2016 12:26:08 GMT schreef Anton Ertl:
>
> > I am not aware that any other Forth system has anything like NEXTNAME,
> > but if they all have, please enlighten me.
> >
> > - anton
>
> ciforth and chforth call it POSTFIX
iForth:
FORTH> help POSTFIX
POSTFIX IFORTH
( -- a-addr )
a-addr is the address of POSTFIX . POSTFIX contains a flag that when
false causes ":" to determine the name for the new definition from a
address/length pair left on the stack.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2016-09-21 21:12 +0200 |
| Message-ID | <1n6jjdamhhigo$.byqiwbg3wy33$.dlg@40tude.net> |
| In reply to | #51154 |
Op Wed, 21 Sep 2016 10:06:11 -0700 (PDT) schreef mhx@iae.nl: > On Wednesday, September 21, 2016 at 3:11:39 PM UTC+2, Coos Haak wrote: >> Op Wed, 21 Sep 2016 12:26:08 GMT schreef Anton Ertl: >> >>> I am not aware that any other Forth system has anything like NEXTNAME, >>> but if they all have, please enlighten me. >>> >>> - anton >> >> ciforth and chforth call it POSTFIX > > iForth: > > FORTH> help POSTFIX > POSTFIX IFORTH > ( -- a-addr ) > a-addr is the address of POSTFIX . POSTFIX contains a flag that when > false causes ":" to determine the name for the new definition from a > address/length pair left on the stack. (The mechanism is different, but the result the same.) Now I'm pretty sure TFORTH has it too. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-09-21 12:06 -1000 |
| Message-ID | <ZPKdnVn_m9TxmX7KnZ2dnUU7-WvNnZ2d@supernews.com> |
| In reply to | #51148 |
On 9/21/16 2:26 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 9/12/16 1:02 PM, Paul Rubin wrote: >>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>>>>> Gforth provides NEXTNAME ( c-addr u -- ), >>>>> Any chance of proposing standardizing it? >>>> Nobody is going to stop you from proposing it. Whether it is accepted >>>> by the committee is doubtful >>> >>> OK, that's basically what I was asking. You're saying that such a >>> proposal is unlikely to be successful. That's a sufficient answer. >>> Thanks. >>> >>>> Questions that might be asked are: How much common practice is there? >>> >>> It seems to me like many Forths must already have a mechanism like that >>> under the covers somewhere. >> >> They all do, but they're very different. There's not enough common >> practice to standardize. > > I am not aware that any other Forth system has anything like NEXTNAME, > but if they all have, please enlighten me. > > And that would certainly be common practice; we have a standardization > process for overcoming the differences in the details; before the > Forth-94 effort, every hosted system had a way to open a file, all > different; the Forth-94 committee fortunately did not take the stance > that there was no common practice; instead, they standardized > OPEN-FILE, R/O, R/W, W/O, and BIN. All the Forths I'm familiar with (which is several) have a lower level of factoring than CREATE, segregating the functions of getting the string and constructing the head of the new definition. The problem is that the factoring itself differs, which means there is insufficient standard practice to standardize (the long form of what I was trying to say above). >>>> And is EXECUTE-PARSING not a better approach to the same problem? If >>>> not, why not? >>> >>> The implementation I looked at seemed painfully complicated. >> >> Yes. Andrew's comment is accurate. > > None of the many lines you quoted was written by anyone called Andrew > (unless Paul Rubin is also called Andrew; I definitely am not). > > A better way to say what you mean is to reduce the quoted material to > that what you agree with, and then express your agreement. Of course, > the question remains if "I agree" postings really contribute something > useful. Andrew responded to the same message I was responding to, and so his text was not available to include. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-09-21 15:40 -0700 |
| Message-ID | <87eg4cc1vz.fsf@jester.gateway.pace.com> |
| In reply to | #51161 |
"Elizabeth D. Rather" <erather@forth.com> writes: > All the Forths I'm familiar with (which is several) have a lower level > of factoring than CREATE, segregating the functions of getting the > string and constructing the head of the new definition. The problem is > that the factoring itself differs, which means there is insufficient > standard practice to standardize (the long form of what I was trying > to say above). As long as each Forth has a way to synthesize creating a name from those lower level factors, it should not be a big deal to standardize a high level interface, even if the low level implementations differ between Forths.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-09-22 13:04 +1000 |
| Message-ID | <nrvhlr$1bdh$1@gioia.aioe.org> |
| In reply to | #51162 |
Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > > All the Forths I'm familiar with (which is several) have a lower level > > of factoring than CREATE, segregating the functions of getting the > > string and constructing the head of the new definition. The problem is > > that the factoring itself differs, which means there is insufficient > > standard practice to standardize (the long form of what I was trying > > to say above). > > As long as each Forth has a way to synthesize creating a name from those > lower level factors, it should not be a big deal to standardize a high > level interface, even if the low level implementations differ between > Forths. Go ahead. Write the spec for HEADER it and see whether it can be done. A system with separated heads will need an xt in addition to the name string. IMO it's far easier to fake what needs to be done than the conformant approach which is nothing more than ideological. While everybody is engaging in the ego-tripping game of "what forth should be", forth is dying from lack of use. If 200x was at all serious about the future of forth, it would dissolve itself immediately. While this wouldn't stop c.l.f., it would stop the peddling of false hope on which c.l.f. thrives.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-09-22 07:40 +0000 |
| Message-ID | <2016Sep22.094048@mips.complang.tuwien.ac.at> |
| In reply to | #51161 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 9/21/16 2:26 AM, Anton Ertl wrote:
>> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> On 9/12/16 1:02 PM, Paul Rubin wrote:
>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>>> Gforth provides NEXTNAME ( c-addr u -- ),
...
>>>>> Questions that might be asked are: How much common practice is there?
>>>>
>>>> It seems to me like many Forths must already have a mechanism like that
>>>> under the covers somewhere.
>>>
>>> They all do, but they're very different. There's not enough common
>>> practice to standardize.
>>
>> I am not aware that any other Forth system has anything like NEXTNAME,
>> but if they all have, please enlighten me.
>>
>> And that would certainly be common practice; we have a standardization
>> process for overcoming the differences in the details; before the
>> Forth-94 effort, every hosted system had a way to open a file, all
>> different; the Forth-94 committee fortunately did not take the stance
>> that there was no common practice; instead, they standardized
>> OPEN-FILE, R/O, R/W, W/O, and BIN.
>
>All the Forths I'm familiar with (which is several) have a lower level
>of factoring than CREATE, segregating the functions of getting the
>string and constructing the head of the new definition. The problem is
>that the factoring itself differs, which means there is insufficient
>standard practice to standardize (the long form of what I was trying to
>say above).
Different factorings of defining words are not a problem for
implementing NEXTNAME (and only indirectly for POSTFIX): No matter how
the defining words are factored, at some point they get the name of
the word to be defined; and at that point you replace the code that
gets the name from the input stream with code that either gets the
name from the input stream or uses the name provided by NEXTNAME
(or, for POSTFIX, takes the name from the stack).
Implementable in any Forth system no matter how the defining words are
factored, although of course the usual suspects will say that they
don't dare to change their Forth system because they fear breaking
code, etc. As a serious customer of these systems, I would wonder if
I should be reassured by the dedication to not breaking code, or
alarmed that the system is so brittle that the system vendor does not
even try what happens when a piece of code is replaced with a piece of
code that does the same thing in the default case (when NEXTNAME is
not used).
The POSTFIX method also just hooks in the same place, but in order for
POSTFIX to be useful, the defining words all have to be factored such
that no internal data is on the stack when the get-the-name code is
performed. Unlike some other Forthers, I really, *really* dislike
introducing global or user state, but in this case passing the name on
the stack did look like the greater evil, and I bit the bullet and
introduced global/user state for this purpose.
Of course, later we discovered EXECUTE-PARSING, and that allows us to
use existing global/user state (the input stream), avoiding the need
for additional state, at least for the cases where EXECUTE-PARSING is
sufficient.
>>> Yes. Andrew's comment is accurate.
>>
>> None of the many lines you quoted was written by anyone called Andrew
>> (unless Paul Rubin is also called Andrew; I definitely am not).
>>
>> A better way to say what you mean is to reduce the quoted material to
>> that what you agree with, and then express your agreement. Of course,
>> the question remains if "I agree" postings really contribute something
>> useful.
>
>Andrew responded to the same message I was responding to, and so his
>text was not available to include.
In that case, the way to go would have been to followup on Andrews
post with your "I agree" post, if your agreement merits expressing at
all. Another way that burdens the reader more and is therefore worse
is to mention the Message-Id of Andrews post that you agree with.
Your method is worst, burdening the reader the most, referring to some
unspecified posting that may be among the read postings (and I
certainly won't ask my news server to show me all read messages,
because that takes 30+ minutes), or may not have arrived at the
reader's news server yet (in which case asking for the read messages
would not buy anything) and not even doing that clearly. Come on, you
are not a Usenet newbie, you should know how it works.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-09-22 15:46 +0100 |
| Message-ID | <ns0qrl$m96$1@dont-email.me> |
| In reply to | #51167 |
On 22/09/2016 08:40, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 9/21/16 2:26 AM, Anton Ertl wrote: >>> "Elizabeth D. Rather" <erather@forth.com> writes: >>>> On 9/12/16 1:02 PM, Paul Rubin wrote: >>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>>>>>>> Gforth provides NEXTNAME ( c-addr u -- ), > ... >>>>>> Questions that might be asked are: How much common practice is there? >>>>> >>>>> It seems to me like many Forths must already have a mechanism like that >>>>> under the covers somewhere. >>>> >>>> They all do, but they're very different. There's not enough common >>>> practice to standardize. >>> >>> I am not aware that any other Forth system has anything like NEXTNAME, >>> but if they all have, please enlighten me. >>> >>> And that would certainly be common practice; we have a standardization >>> process for overcoming the differences in the details; before the >>> Forth-94 effort, every hosted system had a way to open a file, all >>> different; the Forth-94 committee fortunately did not take the stance >>> that there was no common practice; instead, they standardized >>> OPEN-FILE, R/O, R/W, W/O, and BIN. >> >> All the Forths I'm familiar with (which is several) have a lower level >> of factoring than CREATE, segregating the functions of getting the >> string and constructing the head of the new definition. The problem is >> that the factoring itself differs, which means there is insufficient >> standard practice to standardize (the long form of what I was trying to >> say above). > > Different factorings of defining words are not a problem for > implementing NEXTNAME (and only indirectly for POSTFIX): No matter how > the defining words are factored, at some point they get the name of > the word to be defined; and at that point you replace the code that > gets the name from the input stream with code that either gets the > name from the input stream or uses the name provided by NEXTNAME > (or, for POSTFIX, takes the name from the stack). > > Implementable in any Forth system no matter how the defining words are > factored, although of course the usual suspects will say that they > don't dare to change their Forth system because they fear breaking > code, etc. As a serious customer of these systems, I would wonder if > I should be reassured by the dedication to not breaking code, or > alarmed that the system is so brittle that the system vendor does not > even try what happens when a piece of code is replaced with a piece of > code that does the same thing in the default case (when NEXTNAME is > not used). > > The POSTFIX method also just hooks in the same place, but in order for > POSTFIX to be useful, the defining words all have to be factored such > that no internal data is on the stack when the get-the-name code is > performed. Unlike some other Forthers, I really, *really* dislike > introducing global or user state, but in this case passing the name on > the stack did look like the greater evil, and I bit the bullet and > introduced global/user state for this purpose. > > Of course, later we discovered EXECUTE-PARSING, and that allows us to > use existing global/user state (the input stream), avoiding the need > for additional state, at least for the cases where EXECUTE-PARSING is > sufficient. > Surely a sensible Forth design would have :NAME ( caddr u -- ) - or whatever you want to call it - implemented and would use that as a factor of : But then, I suppose people would want similar words for defining VARIABLEs etc leading to a proliferation of defining words. Using a renamed EXECUTE-PARSING (not FEED please) would have the merit of not needing extra names for variables etc and a user can always define those in terms of EXECUTE-PARSING. Also ISTM that NEXTNAME and POSTFIX are worse than EXECUTE-PARSING because, as you say, they introduce extra state (to be tidied up after exceptions, the need introduce an ambiguous condition if not used immediately, not allowed to change the search-order before use etc). Also the name POSTFIX could lead to confusion with postfix notation -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-09-22 11:08 -0700 |
| Message-ID | <79259334-06f5-45b0-83e0-35c06a157471@googlegroups.com> |
| In reply to | #51171 |
On Thursday, September 22, 2016 at 7:46:22 AM UTC-7, Gerry wrote: > Surely a sensible Forth design would have :NAME ( caddr u -- ) - or > whatever you want to call it - implemented and would use that as a > factor of : But then, I suppose people would want similar words for > defining VARIABLEs etc leading to a proliferation of defining words. This is what I have in the novice-package: : :name ( str wid -- ) I don't want similar words of VARIABLE etc.. In Straight Forth I only have colon words and <BUILDS DOES> words (and <BUILDS DOES> words compile into colon words). Constants define into colon words (so they can be ticked), but they are tagged as constants in the dictionary header so the optimizer compiles them as literals (most of the optimization involves literals). : create ( -- adr ) here constant ; : variable ( -- adr ) create w zallot ; The compiler is much simpler when everything is a colon word. The business of having different kinds of words goes back to Charles Moore's ITC systems of the 1970s when we had DOCOLON DOCON DOVAR etc. that could be plugged into the cfa. ANS-Forth was supposed to standardize behavior rather than implementation --- this didn't work out well --- ANS-Forth is totally focused on the PDP-11 PolyForth because that is the only Forth system that Elizabeth Rather understood.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-09-22 22:04 +0200 |
| Message-ID | <8660pnhfbd.fsf@molnjunk.nocrew.org> |
| In reply to | #51171 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> Using a renamed EXECUTE-PARSING (not FEED please) would have the merit
> of not needing extra names for variables etc and a user can always
> define those in terms of EXECUTE-PARSING. Also ISTM that NEXTNAME and
> POSTFIX are worse than EXECUTE-PARSING because, as you say, they
> introduce extra state
I believe that EXECUTE-PARSING can't do everything POSTFIX and NEXTNAME
can do. (And vice versa of course, but that's more obvious.) E.g. this
definition is supposed to accept a string and make a new definition with
that string as its name:
: "CREATE ( a u -- ) ['] CREATE EXECUTE-PARSING ;
However, if my understanding of EXECUTE-PARSING is correct, this fails
with strings that contain whitespace.
I also have my reservations about the EXECUTE-PARSING name, but perhaps
it's apt because it points out the problem that the text interpreter is
involved.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-09-23 10:21 +0100 |
| Message-ID | <ns2s5d$rnu$1@dont-email.me> |
| In reply to | #51178 |
On 22/09/2016 21:04, Lars Brinkhoff wrote: > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: >> Using a renamed EXECUTE-PARSING (not FEED please) would have the merit >> of not needing extra names for variables etc and a user can always >> define those in terms of EXECUTE-PARSING. Also ISTM that NEXTNAME and >> POSTFIX are worse than EXECUTE-PARSING because, as you say, they >> introduce extra state > > I believe that EXECUTE-PARSING can't do everything POSTFIX and NEXTNAME > can do. (And vice versa of course, but that's more obvious.) E.g. this > definition is supposed to accept a string and make a new definition with > that string as its name: > > : "CREATE ( a u -- ) ['] CREATE EXECUTE-PARSING ; > > However, if my understanding of EXECUTE-PARSING is correct, this fails > with strings that contain whitespace. Yes I think that is true, but that's because the standard words for creating definitions parse the input stream for space delimited names. But do we want to open the possibility of having dictionary names with spaces? That would lead to inconsistencies because words such as FIND and SEARCH-WORDLIST would, presumably, be able to find 'NAMES WITH SPACES' in the dictionary but parsing words such as ', ['], POSTPONE, SYNONYM etc and the interpreter couldn't. There are such inconsistencies already in the standard e.g. INCLUDE can't include a 'filename with spaces' but INCLUDED can (at least it's permitted in the standard and works under Windows). Another point is that the xt passed to EXECUTE-PARSING can be a user defined word that is not limited to raw defining words. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-09-23 12:06 +0200 |
| Message-ID | <861t0bgcat.fsf@molnjunk.nocrew.org> |
| In reply to | #51182 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: > But do we want to open the possibility of having dictionary names with > spaces? That would lead to inconsistencies because words such as FIND > and SEARCH-WORDLIST would, presumably, be able to find 'NAMES WITH > SPACES' in the dictionary but parsing words such as ', ['], POSTPONE, > SYNONYM etc and the interpreter couldn't. Sure, that would be a point of contention. When I mentioned this before, I believe one or two people thought it was a bad idea to allow unrestricted names, and one that thought it was a good idea. I guess it comes down to whether you view the dictionary as strictly a symbol table for program identifiers, or if you want to be able to use it as a more generic hash table indexed by strings.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-09-23 10:44 -0500 |
| Message-ID | <Tr2dnT8q6sFm0HjKnZ2dnUU7-cGdnZ2d@supernews.com> |
| In reply to | #51184 |
Lars Brinkhoff <lars.spam@nocrew.org> wrote: > I guess it comes down to whether you view the dictionary as strictly > a symbol table for program identifiers, or if you want to be able to > use it as a more generic hash table indexed by strings. Ak, okay. Sorry, I didn't see this reply before my last posting. My take on it is that the dictionary is a very specific structure which is optimized for the job it does. It doesn't necessarily provide O(1) access, for example. Sure, some dictionary implementations might do, but if you are writing for a specific implementation then you might as well use a private interface to it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-09-23 16:26 +0000 |
| Message-ID | <2016Sep23.182601@mips.complang.tuwien.ac.at> |
| In reply to | #51186 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>My take on it is that the dictionary is a very specific structure
>which is optimized for the job it does. It doesn't necessarily
>provide O(1) access, for example.
So what? There are no performance guarantees anywhere in the Forth
standard[1], so why should there be for the dictionary?
>Sure, some dictionary
>implementations might do, but if you are writing for a specific
>implementation then you might as well use a private interface to it.
Just because some implementation is more efficient than others does
not mean that I am writing for that implementation; a portable program
also works on the others.
E.g., I just tried
<https://www.complang.tuwien.ac.at/forth/programs/taxi.fs> with
parameter 1290 on Gforth and VFX, and the biggest hurdle for running
it on VFX was having to resize the default dictionary size of VFX.
And that's a pretty extreme case, with >800k entries in the lookup
table for that parameter value. It also works on SwiftForth, but the
version I have does not allow resizing the dictionary, and therefore
runs out of dictionary when the parameter exceeds 831, but I am sure
you can change that on full-scale implementations of SwiftForth
(SET-MEMSIZE is documented for that).
Anyway, the command lines are:
sf "include $COMPAT/execute-parsing.fs 831 include taxi.fs bye"
vfx100M "include $COMPAT/execute-parsing.fs 1290 include taxi.fs bye"
gforth-fast -m 1G -e "1290 include taxi.fs bye"
and you have to set COMPAT to whereever you unpacked
<http://theforth.net/package/compat/current.zip>.
Why should I use a system-specific interface? Even if performance is
an issue, it is more likely that the slow systems will improve their
performance if the program actually runs on them and you can show hard
numbers for the performance difference.
In the taxi.fs program, a wordlist is used for storing numbers; these
numbers are converted to strings (in decimal format) in order to be
storable as standard words. If I had used a TABLE (a case-sensitive
wordlist) and NEXTNAME, I could have avoided the conversion, but the
program would not have been portable.
[1] And performance of Forth systems is really a matter of luck.
E.g., a small program like
create x 0 ,
: foo 10000000 0 do 1 x +! loop ;
can vary between 5.5 cycles/iteration and >350 cycles/iteration from
one release of a Forth system to the next. Or, as I discovered
recently, using floating-point literals can slow down returns from
colon definitions.
- 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/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-09-24 03:46 -0500 |
| Message-ID | <5IOdnRy0kb7IoHvKnZ2dnUU7-afNnZ2d@supernews.com> |
| In reply to | #51190 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>My take on it is that the dictionary is a very specific structure >>which is optimized for the job it does. It doesn't necessarily >>provide O(1) access, for example. > > So what? That was obvious from the context. > There are no performance guarantees anywhere in the Forth > standard[1], so why should there be for the dictionary? That was my point. That was obvious from the context. > Why should I use a system-specific interface? If the O(1) performance of a hash table is essential to your design, then you'll have to use a hash table; the dictionary might be a linear search. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-09-24 10:13 +0000 |
| Message-ID | <2016Sep24.121339@mips.complang.tuwien.ac.at> |
| In reply to | #51238 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>My take on it is that the dictionary is a very specific structure
>>>which is optimized for the job it does. It doesn't necessarily
>>>provide O(1) access, for example.
>>
>> So what?
>
>That was obvious from the context.
>
>> There are no performance guarantees anywhere in the Forth
>> standard[1], so why should there be for the dictionary?
>
>That was my point. That was obvious from the context.
Which context?
>> Why should I use a system-specific interface?
>
>If the O(1) performance of a hash table is essential to your design,
Where did you get the idea that it was essential? Nobody but you has
even mentioned O(1) performance, and even you did not put up the
"essential for the design" straw man before.
But even if I accepted your straw-man argument, the rest of your
argument does not make sense:
>then you'll have to use a hash table; the dictionary might be a linear
>search.
If average-constant access performance is essential, there are several
options:
1) I can use the dictionary, and choose one of the Forth systems that
provide average-constant access performance for that. Just because
there may be a few systems that do not provide the necessary
performance yet, does not mean it is a good idea or even recommended
to use a system-specific interfaces, because that would restrict usage
of the program to that one system; then I would not even notice that
other Forth systems provide average-constant access performance, maybe
in a later version.
2) If I want more performance portability, I can define the lookup
table myself in Forth, or use a library, e.g., the ffl. And in that
context a system-specific interface makes even less sense.
So you put up a straw man that does not even support your case.
- 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/
[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