Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #42410 > unrolled thread
| Started by | Chris Curl <ccurl609@gmail.com> |
|---|---|
| First post | 2015-10-06 21:44 -0700 |
| Last post | 2016-01-02 02:25 -0800 |
| Articles | 20 on this page of 142 — 22 participants |
Back to article view | Back to comp.lang.forth
Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-10-06 21:44 -0700
Re: Boring for most of you, but I'm having fun ... :) Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-07 08:24 +0200
Re: Boring for most of you, but I'm having fun ... :) Mark Wills <markwills1970@gmail.com> - 2015-10-07 00:48 -0700
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-10-07 05:41 -0700
Re: Boring for most of you, but I'm having fun ... :) Jason Damisch <jasondamisch@yahoo.com> - 2015-10-07 12:05 -0700
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-27 18:04 -0800
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-27 18:12 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 13:33 +0100
Re: Boring for most of you, but I'm having fun ... :) humptydumpty <ouatubi@gmail.com> - 2015-12-28 00:54 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 12:32 -0800
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 12:43 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 22:13 +0100
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 13:21 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 23:47 +0100
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 13:13 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-28 23:50 +0100
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 15:33 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-28 15:37 -1000
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 22:18 -0800
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-28 22:31 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 23:30 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 02:47 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-29 08:19 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 08:26 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-29 09:34 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-29 10:22 -0800
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-30 12:15 +0000
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-30 08:26 -0800
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:10 +0000
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-30 08:35 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-30 08:51 -0800
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 12:21 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 10:46 -1000
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 13:15 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 13:11 -1000
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-30 15:35 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 15:00 -1000
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-12-31 00:13 -0800
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-31 10:09 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:46 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:56 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 17:24 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 14:23 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-01 20:24 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 22:38 +0100
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 13:24 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 15:32 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-02 16:41 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-03 14:43 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 13:13 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:57 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:41 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 14:13 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:27 +0100
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 13:38 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 18:46 +0100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 09:01 -1000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 22:35 +0100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 08:39 -1000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 21:01 +0100
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-01 20:18 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:19 +0100
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-01 21:43 -0800
Re: Boring for most of you, but I'm having fun ... :) Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-01 23:36 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-02 15:36 +0000
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-02 12:18 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-03 14:34 +0000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-03 19:57 -0800
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-04 22:49 +0000
Re: Boring for most of you, but I'm having fun ... :) Julian Fondren <julian.fondren@gmail.com> - 2016-01-04 15:05 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-04 20:36 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 13:03 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-05 14:30 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 21:10 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-05 21:26 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-06 05:01 -0800
Re: Boring for most of you, but I'm having fun ... :) "WJ" <w_a_x_man@yahoo.com> - 2016-01-06 00:13 +0000
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-06 19:47 +0000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-07 21:43 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-08 05:54 -0800
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-08 16:44 +0000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-08 16:27 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 17:18 +0000
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 17:00 +0000
Re: Boring for most of you, but I'm having fun ... :) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-08 04:52 -0600
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 11:27 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 16:44 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 21:17 +0100
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 16:57 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 17:06 +0000
Re: Boring for most of you, but I'm having fun ... :) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-08 20:24 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-09 17:05 +0000
Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2016-01-08 20:02 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 21:49 +0100
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-09 22:06 -0800
Re: Boring for most of you, but I'm having fun ... :) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-10 07:46 -0600
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-10 14:35 +0000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-10 11:55 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-12 13:26 +0000
Re: Boring for most of you, but I'm having fun ... :) peter.m.falth@gmail.com - 2016-01-12 15:10 -0800
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-12 13:23 -1000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-12 20:42 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-12 21:08 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-13 15:17 +0000
Re: Boring for most of you, but I'm having fun ... :) peter.m.falth@gmail.com - 2016-01-13 13:26 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2016-01-04 14:19 -0800
Re: Boring for most of you, but I'm having fun ... :) "WJ" <w_a_x_man@yahoo.com> - 2016-01-05 07:24 +0000
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2015-12-31 16:24 +0000
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-29 12:31 -1000
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2015-12-29 14:52 -0800
Re: Boring for most of you, but I'm having fun ... :) Coos Haak <chforth@hccnet.nl> - 2015-12-30 02:11 +0100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-29 23:46 -1000
Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-30 21:25 +1100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 09:17 -1000
Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-31 12:55 +1100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-30 16:26 -1000
Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2016-01-02 12:30 +1100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2016-01-01 16:31 -1000
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2016-01-01 21:31 -0800
Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2016-01-02 12:04 +0000
Re: Boring for most of you, but I'm having fun ... :) stephen@mpeforth.com (Stephen Pelc) - 2015-12-31 12:04 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 13:31 +0000
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-31 08:50 -1000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 14:13 +0000
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-31 14:34 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-31 22:39 +0100
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-01 10:05 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 18:16 +0100
Re: Boring for most of you, but I'm having fun ... :) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-01-01 17:49 +0000
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-01 19:23 +0100
Re: Boring for most of you, but I'm having fun ... :) Paul Rubin <no.email@nospam.invalid> - 2016-01-01 15:53 -0800
Re: Boring for most of you, but I'm having fun ... :) Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-02 14:20 +0100
Re: Boring for most of you, but I'm having fun ... :) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-02 16:34 +0000
Re: Boring for most of you, but I'm having fun ... :) Mikael Nordman <oh2aun@gmail.com> - 2016-01-02 14:08 -0800
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2015-12-30 20:40 -0800
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-30 08:28 -0800
Re: Boring for most of you, but I'm having fun ... :) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-12-30 11:11 +0000
Re: Boring for most of you, but I'm having fun ... :) Chris Curl <ccurl609@gmail.com> - 2015-12-28 15:40 -0800
Re: Boring for most of you, but I'm having fun ... :) "HAA" <someone@microsoft.com> - 2015-12-30 10:14 +1100
Re: Boring for most of you, but I'm having fun ... :) "Elizabeth D. Rather" <erather@forth.com> - 2015-12-28 15:35 -1000
Re: Boring for most of you, but I'm having fun ... :) hughaguilar96@gmail.com - 2015-12-30 20:58 -0800
Re: Boring for most of you, but I'm having fun ... :) Julian Fondren <julian.fondren@gmail.com> - 2016-01-02 02:25 -0800
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-12-31 13:56 +0000 |
| Message-ID | <2015Dec31.145651@mips.complang.tuwien.ac.at> |
| In reply to | #44451 |
Paul Rubin <no.email@nospam.invalid> writes:
> Or gforth's NEXTWORD which pushes the
>word back onto the input stream (or equivalent).
NEXTNAME stores the name somewhere and changes the header-creating
word to take that name for the next header it creates instead of using
the input stream; and after creating the header from the stored
string, the header-creating words resets itself to taking a name from
the input stream. There is also NONAME, which works in a simular way;
i.e.,
noname : ... ; lastxt
is equivalent to
:noname ... ;
but you can also use NONAME with other defining words, e.g., with
CREATE or CONSTANT.
NEXTNAME is older than EXECUTE-PARSING, and would probably not have
come into existence if we had EXECUTE-PARSING first, but it can do one
thing that cannot be done with EXECUTE-PARSING: we can pass arbitrary
data to it, including bytes that look like white space when
interpreted as string. That's useful when we want to use TABLEs (like
wordlists, but with literal comparison instead of case-insensitive
comparison on lookup) with binary data as lookup keys.
>IMO it's a useful word that I've wanted a few times. Look at Chris
>Curl's example of creating an auxiliary T stack. It would be nice to
>generalize that to something like
>
> : NEWSTACK ( "name" size ) ... ;
>
>so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T,
>and automatically create the words >T T> T@ and T.RESET that did the
>obvious things.
I have thought about such things sometimes, too, but I have always
come to the conclusion that we can just as well do it as a sequence of
words, i.e., in this case T >S, T S>, T S@, T RESET or somesuch.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-12-31 17:24 +0000 |
| Message-ID | <568564b8$0$23749$e4fe514c@news.xs4all.nl> |
| In reply to | #44468 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Paul Rubin <no.email@nospam.invalid> writes: >> Or gforth's NEXTWORD which pushes the >>word back onto the input stream (or equivalent). >NEXTNAME stores the name somewhere and changes the header-creating >word to take that name for the next header it creates instead of using >the input stream; and after creating the header from the stored >string, the header-creating words resets itself to taking a name from >the input stream. There is also NONAME, which works in a simular way; >i.e., That word is called POSTFIX in my book. The implementation in an indirect threaded Forth is interesting, instead of storing the string somewhere, the parsing action in NAME is suppressed: \ Have the original behaviour of DEA restored. : RESTORED DUP >PHA SWAP >DFA ! ; \ Do nothing for one call of ``NAME'' : NAME-NEW 'NAME RESTORED ; \ Make the following defining word postfix for one execution. \ The name must be a string constant on the stack \ Use only while compiling, or you crash the system : POSTFIX ( ?COMP ) 'NAME-NEW >DFA @ 'NAME >DFA ! ; It is a loadable extension. Don't want it? Don't load it! It works on all defining words that use NAME. >noname : ... ; lastxt >is equivalent to >:noname ... ; >but you can also use NONAME with other defining words, e.g., with >CREATE or CONSTANT. >NEXTNAME is older than EXECUTE-PARSING, and would probably not have >come into existence if we had EXECUTE-PARSING first, but it can do one >thing that cannot be done with EXECUTE-PARSING: we can pass arbitrary >data to it, including bytes that look like white space when >interpreted as string. That's useful when we want to use TABLEs (like >wordlists, but with literal comparison instead of case-insensitive >comparison on lookup) with binary data as lookup keys. So NEXTNAME is a gForth invention and has no older roots? >>IMO it's a useful word that I've wanted a few times. Look at Chris >>Curl's example of creating an auxiliary T stack. It would be nice to >>generalize that to something like >> >> : NEWSTACK ( "name" size ) ... ; >> >>so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T, >>and automatically create the words >T T> T@ and T.RESET that did the >>obvious things. >I have thought about such things sometimes, too, but I have always >come to the conclusion that we can just as well do it as a sequence of >words, i.e., in this case T >S, T S>, T S@, T RESET or somesuch. Or even better, have a stack object, make it current and do pop,push and get. TO-objects using TO and FROM would work also. >- anton -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-01 14:23 +0000 |
| Message-ID | <2016Jan1.152310@mips.complang.tuwien.ac.at> |
| In reply to | #44475 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>So NEXTNAME is a gForth invention and has no older roots?
I was not aware of anything in that direction in other systems when I
added it to Gforth, but I would not be surprised if someone else had
implemented such a feature earlier.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-01-01 20:24 +0000 |
| Message-ID | <5686e093$0$23782$e4fe514c@news.xs4all.nl> |
| In reply to | #44497 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>So NEXTNAME is a gForth invention and has no older roots? >I was not aware of anything in that direction in other systems when I >added it to Gforth, but I would not be surprised if someone else had >implemented such a feature earlier. While we're at it we could establish prioriy. This is the first mention of POSTFIX in my logs. " 2001 sep 26 we ... Idea about POSTFIX replace (WORD) by a NOOP for one call. Works. " >- anton -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-01 22:38 +0100 |
| Message-ID | <n66reu$tus$2@dont-email.me> |
| In reply to | #44508 |
Albert van der Horst wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > >>Albert van der Horst <albert@spenarnc.xs4all.nl> writes: >>>So NEXTNAME is a gForth invention and has no older roots? > >>I was not aware of anything in that direction in other systems when I >>added it to Gforth, but I would not be surprised if someone else had >>implemented such a feature earlier. > > While we're at it we could establish prioriy. > This is the first mention of POSTFIX in my logs. > > " > 2001 sep 26 we > ... > Idea about POSTFIX replace (WORD) by a NOOP for one > call. Works. > " According to git blame (with the CVS tree imported, where I am listed with the y/z swapped user name I had for historical reasons), nextname has been checked in by me in May 1998: b727d802 (pazsan 1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u -- ) \ gforth -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-02 13:24 +0000 |
| Message-ID | <2016Jan2.142417@mips.complang.tuwien.ac.at> |
| In reply to | #44511 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>According to git blame (with the CVS tree imported, where I am listed with
>the y/z swapped user name I had for historical reasons), nextname has been
>checked in by me in May 1998:
>
>b727d802 (pazsan 1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u
>-- ) \ gforth
That's the time kernel/comp.fs was checked in for the first time, but
unfortunately you don't see that with git blame (whereas a version 1.1
in cvs annotate is obvious); before that it was in kernel.fs, before
than in kernal.fs, and it was there in version 1.1, so it likely was
introduced even earlier, but I don't find the RCS repository at the
moment to determine the exact date.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-02 15:32 +0000 |
| Message-ID | <2016Jan2.163231@mips.complang.tuwien.ac.at> |
| In reply to | #44530 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>According to git blame (with the CVS tree imported, where I am listed with
>>the y/z swapped user name I had for historical reasons), nextname has been
>>checked in by me in May 1998:
>>
>>b727d802 (pazsan 1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u
>>-- ) \ gforth
>
>That's the time kernel/comp.fs was checked in for the first time, but
>unfortunately you don't see that with git blame (whereas a version 1.1
>in cvs annotate is obvious); before that it was in kernel.fs, before
>than in kernal.fs, and it was there in version 1.1, so it likely was
>introduced even earlier, but I don't find the RCS repository at the
>moment to determine the exact date.
Found the RCS repository:
revision 1.7
date: 1993/11/21 21:23:44; author: anton; state: Exp; lines: +76 -13
added: nextname noname inputstream lastxt ENDIF S+LOOP 2, 2VARIABLE 2CONSTANT
cleaned up a few things
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-01-02 16:41 +0000 |
| Message-ID | <5687fdb5$0$23777$e4fe514c@news.xs4all.nl> |
| In reply to | #44530 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Bernd Paysan <bernd.paysan@gmx.de> writes: >>According to git blame (with the CVS tree imported, where I am listed with >>the y/z swapped user name I had for historical reasons), nextname has been >>checked in by me in May 1998: >> >>b727d802 (pazsan 1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u >>-- ) \ gforth >That's the time kernel/comp.fs was checked in for the first time, but >unfortunately you don't see that with git blame (whereas a version 1.1 >in cvs annotate is obvious); before that it was in kernel.fs, before >than in kernal.fs, and it was there in version 1.1, so it likely was >introduced even earlier, but I don't find the RCS repository at the >moment to determine the exact date. Maybe I should change the name POSTFIX to NEXTNAME? (Though I like it.) >- 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 2015: http://www.rigwit.co.uk/EuroForth2015/ -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-03 14:43 +0000 |
| Message-ID | <2016Jan3.154316@mips.complang.tuwien.ac.at> |
| In reply to | #44536 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>According to git blame (with the CVS tree imported, where I am listed with
>>>the y/z swapped user name I had for historical reasons), nextname has been
>>>checked in by me in May 1998:
>>>
>>>b727d802 (pazsan 1998-05-02 21:28:41 +0000 159) : nextname ( c-addr u
>>>-- ) \ gforth
>
>>That's the time kernel/comp.fs was checked in for the first time, but
>>unfortunately you don't see that with git blame (whereas a version 1.1
>>in cvs annotate is obvious); before that it was in kernel.fs, before
>>than in kernal.fs, and it was there in version 1.1, so it likely was
>>introduced even earlier, but I don't find the RCS repository at the
>>moment to determine the exact date.
>
>Maybe I should change the name POSTFIX to NEXTNAME? (Though I like it.)
They do different things. POSTFIX changes what WORD does (according
to what you wrote), while NEXTNAME changes what HEADER (the
header-creating word) does.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-02 13:13 +0000 |
| Message-ID | <2016Jan2.141340@mips.complang.tuwien.ac.at> |
| In reply to | #44508 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>So NEXTNAME is a gForth invention and has no older roots?
>
>>I was not aware of anything in that direction in other systems when I
>>added it to Gforth, but I would not be surprised if someone else had
>>implemented such a feature earlier.
>
>While we're at it we could establish prioriy.
>This is the first mention of POSTFIX in my logs.
>
>"
>2001 sep 26 we
>...
>Idea about POSTFIX replace (WORD) by a NOOP for one
>call. Works.
>"
NEXTNAME was already in the sources when we switched from RCS to CVS
on 1994-02-11:
http://www.complang.tuwien.ac.at/cvsweb/cgi-bin/cvsweb/gforth/Attic/kernal.fs?rev=1.1;content-type=text%2Fx-cvsweb-markup
I mentioned it at the latest in clf on Mon Nov 25 18:58:57 1996.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-12-31 16:57 +0000 |
| Message-ID | <56855e8a$0$23749$e4fe514c@news.xs4all.nl> |
| In reply to | #44451 |
Paul Rubin <no.email@nospam.invalid> writes: >"Elizabeth D. Rather" <erather@forth.com> writes: >> as you start talking about a "standard way to make an arbitrary >> dictionary entry" you open a huge can of worms about exactly what >> needs to be incorporated in that dictionary entry, where it is, etc. >I don't see how that can be, since otherwise CREATE would open the >exact same can of worms. The idea is to just have a word like > : $DATA ( addr u -- ) ... ; >which takes a string as arg, and does the same thing as CREATE would >do in parsing that string. Or gforth's NEXTWORD which pushes the >word back onto the input stream (or equivalent). >> None of these issues are really germane to using Forth to write >> applications, which its purpose. >IMO it's a useful word that I've wanted a few times. Look at Chris >Curl's example of creating an auxiliary T stack. It would be nice to >generalize that to something like > : NEWSTACK ( "name" size ) ... ; >so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T, >and automatically create the words >T T> T@ and T.RESET that did the >obvious things. I don't see any standard way to do that. A standard way is to build up standard code in a text buffer. Then use EVALUATE on the buffer. Totally standard. I use it myself in my mini-OO. If I have declared a class APE in my OO package words like ^APE and BUILD-APE are present. You are aware that you cannot use a word like >T in an application at run time, unless you've defined your stack at compile time? So there is nothing actually dynamic about >T T> .. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-12-31 16:41 +0000 |
| Message-ID | <56855acd$0$23749$e4fe514c@news.xs4all.nl> |
| In reply to | #44449 |
"Elizabeth D. Rather" <erather@forth.com> writes: >AFAIK there has never been an intent to make it possible to write an >implementation in Standard Forth. The objective has always been to >standardize the interface between a system and an application. As soon >as you start talking about a "standard way to make an arbitrary >dictionary entry" you open a huge can of worms about exactly what needs >to be incorporated in that dictionary entry, where it is, etc. None of >these issues are really germane to using Forth to write applications, >which its purpose. Talking about ai where you may want the program to write a new program, it is clear that a couple of $ words don't do the job anyway. There is EVALUATE to the rescue with no restrictions whatsoever. "CREATE " PAD $! get-some-string PAD $+! PAD $@ EVALUATE \ Now we have a word with a name resulting from `` get-some-string '' \ in the dictionary. So I'd agree that we shouldn't add $-words to the standard. Let us not clutter up the standard with words with limited usage. We have an extensible language at our hands, but not all extensions belong in the standard. >Cheers, >Elizabeth Groetjes Albert >-- >================================================== >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." >================================================== -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-12-31 14:13 +0000 |
| Message-ID | <2015Dec31.151312@mips.complang.tuwien.ac.at> |
| In reply to | #44447 |
Paul Rubin <no.email@nospam.invalid> writes:
> But it doesn't specify any
>way to make an arbitrary dictionary entry. That seems like a bug. I
>vaguely remember reading there was some discussion in the Forth-2012
>group about how to do it, but it got mired in bikeshedding. Maybe one
>of the participants could say more.
Not sure what you are referring to, but I suggested EXECUTE-PARSING at
a meeting a number of years ago. Stephen Pelc claimed that this is
not general enough and that one would also introduce
EXECUTE-PARSING-FILE, EXECUTE-PARSING-BLOCK, EXECUTE-PARSING-FLASH and
millions of other words if we introduced EXECUTE-PARSING. In actual
usage, Gforth has EXECUTE-PARSING-FILE, but I have never used it. It
does not have EXECUTE-PARSING-BLOCK nor EXECUTE-PARSING-FLASH, and I
have not missed them at all.
But I do use EXECUTE-PARSING regularly. Everytime some idiot writes a
parsing word, EXECUTE-PARSING is to the rescue. In the meantime I
have come to the conclusion that it's actually not so dumb to write
parsing words, but one of the ways to reduce the stack load in Forth;
but it needs to be combined with a way to get back to a general
stack-based interface, and that way is EXECUTE-PARSING.
Anyway, back to the discussion at the standards meeting. There was a
suggestion from Stephen Pelc that we should generalize the text
interpreter such that we could arbitrarily plug together various input
stream sources, and various ways to process the input stream, as a
very generalized variant of the EXECUTE-PARSING idea. I worked out a
sketch of how that might look (I can dig it out if there is interest).
My own feelings about this were mixed, and the reaction of the
participants was negative or neutral (anyway, not supportive), so I
did not pursue it further. But I also did not pursue EXECUTE-PARSING
in the committee further.
Looking back, the general solution may inspire some new style or
something, but is certainly not something that comes out of existing
practice, and it might just end up as overgeneralization. In
contrast, EXECUTE-PARSING has quite a bit of existing practice (of
course not if you define "existing practice" as "what MPE and (to the
knowledge of Stephen Pelc) its customers do") and is just the right
level of generality. Maybe someone should make an RfD on that.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-12-31 22:27 +0100 |
| Message-ID | <n646g0$r7a$1@dont-email.me> |
| In reply to | #44469 |
Anton Ertl wrote: > Not sure what you are referring to, but I suggested EXECUTE-PARSING at > a meeting a number of years ago. Stephen Pelc claimed that this is > not general enough and that one would also introduce > EXECUTE-PARSING-FILE, EXECUTE-PARSING-BLOCK, EXECUTE-PARSING-FLASH and > millions of other words if we introduced EXECUTE-PARSING. In actual > usage, Gforth has EXECUTE-PARSING-FILE, but I have never used it. It > does not have EXECUTE-PARSING-BLOCK nor EXECUTE-PARSING-FLASH, and I > have not missed them at all. It's probably easier to use recognizers for parsing more than one word. The key thing for EXECUTE-PARSING is that it transforms s" <something>" ['] <parsing-word> execute-parsing into the equivalent of <parsing-word> <something> I've a use of execute-parsing-named-file in net2o-tools.fs (net2o sources in https://fossil.net2o.de/net2o), to implement the help system; and I plan to push that back to Gforth itself, as using your own help system for any kind of Forth program can be a good idea. Given that it contains a filter + an action if the filter matches, I should reimplement that as recognizer. The recognizer proposal needs a number of example cases to convince especially Stephen, anyways ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-01 13:38 +0000 |
| Message-ID | <2016Jan1.143837@mips.complang.tuwien.ac.at> |
| In reply to | #44484 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Not sure what you are referring to, but I suggested EXECUTE-PARSING at
>> a meeting a number of years ago. Stephen Pelc claimed that this is
>> not general enough and that one would also introduce
>> EXECUTE-PARSING-FILE, EXECUTE-PARSING-BLOCK, EXECUTE-PARSING-FLASH and
>> millions of other words if we introduced EXECUTE-PARSING. In actual
>> usage, Gforth has EXECUTE-PARSING-FILE, but I have never used it. It
>> does not have EXECUTE-PARSING-BLOCK nor EXECUTE-PARSING-FLASH, and I
>> have not missed them at all.
>
>It's probably easier to use recognizers for parsing more than one word.
Easier than what? EXECUTE-PARSING and recognizers do not solve the
same problems, so your sentence does not make sense in this context.
However, while we are at it, how do we solve the problem that
EXECUTE-PARSING solves for parsing words for recognizers?
Say, we have a recognizer for environment variables (for the pattern
"$<var>), but the programmer of the recognizer did not provide the
environment lookup as a factor, and now we want to look up an
environmental variable whose name we get from, say, a file. How do we
make use of the environment lookup buried in the recognizer?
One way would be to build a string "$<var>" and EVALUATE it, hoping
that the recognizer we are interested in is active and first among
those that might recognize the string (but the hex number recognizer
might be earlier).
Alternatively, we could pass some recognizer token to an
EXECUTE-RECOGNIZER ( c-addr u rt -- ... flag ) word that is the
recognizer equivalent of EXECUTE-PARSING, but if the programmer failed
to give us the environment lookup as a factor, he probably did not
export the recognizer token, either; sure, one could look it up in the
source code of the library, but that might change in the next version
of the library.
Any further ideas?
>The key thing for EXECUTE-PARSING is that it transforms
>s" <something>" ['] <parsing-word> execute-parsing
>into the equivalent of
><parsing-word> <something>
I put it the other word around: Given a <parsing-word> that is written
to be used as
<parsing-word> <something>
EXECUTE-PARSING allows you to pass the <something> as string on the
stack.
>The recognizer proposal needs a number of example cases to convince
>especially Stephen, anyways ;-).
Do you think that anything that is not in one of his paying client's
code bases is not dismissed by him as irrelevant because application
programmers don't need this.
- 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-01 18:46 +0100 |
| Message-ID | <n66dtg$blb$1@dont-email.me> |
| In reply to | #44495 |
Anton Ertl wrote:
>>It's probably easier to use recognizers for parsing more than one word.
>
> Easier than what? EXECUTE-PARSING and recognizers do not solve the
> same problems, so your sentence does not make sense in this context.
For EXECUTE-PARSING-FILE ("more than one word"). The current method is that
you need to provide your own version of READ-LOOP, so you do everything
including the REFILL. In most cases, the REFILL-style approach is perfectly
fine, you only want to replace the actual interpreter.
And that's what the recognizer stack can do.
> However, while we are at it, how do we solve the problem that
> EXECUTE-PARSING solves for parsing words for recognizers?
>
> Say, we have a recognizer for environment variables (for the pattern
> "$<var>), but the programmer of the recognizer did not provide the
> environment lookup as a factor, and now we want to look up an
> environmental variable whose name we get from, say, a file. How do we
> make use of the environment lookup buried in the recognizer?
Pass $<var> as string to that recognizer. It will return either a R:FAIL
(i.e. "no such variable exists") or something else, in which case you can
either interpret or compile the result, as you want it. Interpreting it
will end up with the content on the stack.
I.e.
s" $HOME" rec:env r>int execute type
should print "/home/anton" or whatever your $HOME is (and potentially fail).
You might want to use this when it conflicts with a hex number.
> Alternatively, we could pass some recognizer token to an
> EXECUTE-RECOGNIZER ( c-addr u rt -- ... flag ) word that is the
> recognizer equivalent of EXECUTE-PARSING, but if the programmer failed
> to give us the environment lookup as a factor, he probably did not
> export the recognizer token, either; sure, one could look it up in the
> source code of the library, but that might change in the next version
> of the library.
The recognizer lookup word needs to be exported as a factor; in theory you
could add just a :noname xt into the lookup stack, but that makes it
difficult to re-arrange that lookup stack later.
>>The recognizer proposal needs a number of example cases to convince
>>especially Stephen, anyways ;-).
>
> Do you think that anything that is not in one of his paying client's
> code bases is not dismissed by him as irrelevant because application
> programmers don't need this.
Given the huge amount of hooks in his outer interpreter, he's the one who
needs the recognizers most badly, but he doesn't yet know it. Each of the
hook went there due to a specific customer feature request. If he accepts
the recognizer proposal, all future feature requests in this area have been
handled.
Ok, thinking twice about this shows where my mistake is: I'm a free
software developer. Feature requests therefore are my costs, and not a
source of income for me. That means I want to handle feature requests in a
way that minimizes my workload. For a "pay per feature request" business
model, this is the wrong approach. You want to solve exactly the requested
feature request, but absolutely no other feature request, because that other
feature request will be another source of income.
The result is a mess of hooks in INTERPRET, which can't be left out, even
when a clean solution is available, because the customers don't want to
change their sources. The per-feature-request payment incentive
automatically generates maintenance nightmares.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-01 09:01 -1000 |
| Message-ID | <4KidnXp5EvB2URvLnZ2dnUU7-dmdnZ2d@supernews.com> |
| In reply to | #44499 |
On 1/1/16 7:46 AM, Bernd Paysan wrote: ... > Ok, thinking twice about this shows where my mistake is: I'm a free > software developer. Feature requests therefore are my costs, and not a > source of income for me. That means I want to handle feature requests in a > way that minimizes my workload. For a "pay per feature request" business > model, this is the wrong approach. You want to solve exactly the requested > feature request, but absolutely no other feature request, because that other > feature request will be another source of income. > > The result is a mess of hooks in INTERPRET, which can't be left out, even > when a clean solution is available, because the customers don't want to > change their sources. The per-feature-request payment incentive > automatically generates maintenance nightmares. That's a serious misunderstanding of how professional (i.e., for pay) software development works. Our clients are not paying for "features", they are paying to have problems solved, marketable products released for sale, and projects completed on time and on budget. "Features" are side effects, developed only in aid of achieving these goals. Companies such as MPE and FORTH, Inc. thrive on long-term relationships with our customers. This is only possible if we consistently meet their expectations for on-time, cost-effective delivery of reliable, working programs. That is the opposite of being in a "pay-per-feature" business! Speaking for FORTH, Inc., for the most part our customers maintain their programs, not us. Indeed, a typical relationship is that we provide various system-level functionality (drivers, communication protocols, etc.) and they write most of the higher layers of the application. They are the ones who will have to live with their systems year after year. We help them understand how to develop maintainable applications. Our customers consistently tell us that our products and services help them achieve their goals at a fraction of the cost of their colleagues and competitors using C and other languages. Forth enables them to do that because it makes the most efficient use of programmer's time and intelligence, making the development, testing, and long-term maintenance of their programs economical, so that they can maintain a profitable business. If our customers win, we win. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-01 22:35 +0100 |
| Message-ID | <n66rab$tus$1@dont-email.me> |
| In reply to | #44504 |
Elizabeth D. Rather wrote: > That's a serious misunderstanding of how professional (i.e., for pay) > software development works. I've done that. There's a serious misunderstanding on your side how incentives works: They just work. Whatever global minimum is there in the incentive space will be reached. It you have the incentive to get money for maintenance, those companies will survive who makes money by maintenance, and those who don't, because their product just works, will go out of business. The larger the scale, the more likely the global minimum will be reached by all players, which is why companies like Microsoft are the way they are. At no point in time there needs to be a conscious decision to do it that way, this is just a matter of evolution. Changing the incentive changes the outcome. Add free software to that: I, as developer, want to minimize my costs; some free software is financed by maintenance (e.g. GCC), most isn't. The projects which are financed by maintenance are maintenance nightmares, and they did become that during the time they were financed by maintenance. If they hadn't, the business model wouldn't have worked, and the pay-for-maintenance company would have been out of business. They didn't, they are the biggest company making exclusively money from free software now. On the other extreme of Linux distributions there is Debian, which is full of really ancient packages, because the package maintainer's incentive directs him towards doing absolutely nothing. There is not even a way to take over when the maintainer sits on ancient packages and doesn't release them. That's not good, either. So incentives matter. > Our clients are not paying for "features", > they are paying to have problems solved, marketable products released > for sale, and projects completed on time and on budget. "Features" are > side effects, developed only in aid of achieving these goals. Yes, and the other requirements you have listed probably press for a quick patch instead for a solution that's good in the long run, but requires more time to think about it and to get it right. > Companies > such as MPE and FORTH, Inc. thrive on long-term relationships with our > customers. This is only possible if we consistently meet their > expectations for on-time, cost-effective delivery of reliable, working > programs. That is the opposite of being in a "pay-per-feature" business! I'm sure, in the long run you want to follow the same approach of good engineering as I want. Actually, the magic of incentives take over, and when we have different incentives, we will optimize our strategies differently. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-01 08:39 -1000 |
| Message-ID | <KcKdnZGr7a5KWhvLnZ2dnUU7-QWdnZ2d@supernews.com> |
| In reply to | #44495 |
On 1/1/16 3:38 AM, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: ... >> The recognizer proposal needs a number of example cases to convince >> especially Stephen, anyways ;-). > > Do you think that anything that is not in one of his paying client's > code bases is not dismissed by him as irrelevant because application > programmers don't need this. It's not so much an issue of whether "paying clients" use something, although that's certainly an important consideration, but more importantly I think before standardizing something there should be a consideration of whether it's really needed in application programming. Too many things get proposed here because they're "cool" or "language X does it". 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-01 21:01 +0100 |
| Message-ID | <n66lp3$9oq$1@dont-email.me> |
| In reply to | #44503 |
Elizabeth D. Rather wrote: > On 1/1/16 3:38 AM, Anton Ertl wrote: >> Bernd Paysan <bernd.paysan@gmx.de> writes: > ... >>> The recognizer proposal needs a number of example cases to convince >>> especially Stephen, anyways ;-). >> >> Do you think that anything that is not in one of his paying client's >> code bases is not dismissed by him as irrelevant because application >> programmers don't need this. > > It's not so much an issue of whether "paying clients" use something, > although that's certainly an important consideration, but more > importantly I think before standardizing something there should be a > consideration of whether it's really needed in application programming. > Too many things get proposed here because they're "cool" or "language X > does it". Recognizers haven't been done by any other language, at least I don't know of it. Other languages usually have a much more fixed syntax and semantics, and are way less flexible than Forth, so adding more flexibility with recognizers is something unthinkable for them. One particular motivation for recognizer is that some Forth systems already provide an ample amount of special-purpose hooks (MPE's VFX as example), which apparently have been added one-by-one each for one particular feature, instead of looking for the more general picture how to make the interpreter flexible enough so that there's one hook to rule them all (all extensions). Years ago, we had some discussion about "let's standardize on interpreter hooks", and then we found out that there are about ten different interpreter hooks, most of them in one particular interpreter. There is no way to standardize on this mess, because the only general-purpose hook in the hook mess is the "replace the entire interpeter"-hook. On the other hand, the recognizer proposal got the most opposition from exactly these people who added hook after hook to their own outer interpreter. With the most funny "solution" to add a few more hooks instead... Maybe they are simply locked into their way of thinking about hooks in the interpreter. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web