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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-01-01 20:18 +0000 |
| Message-ID | <5686df17$0$23782$e4fe514c@news.xs4all.nl> |
| In reply to | #44495 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>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?
Simplicity wins the day. In ciforth a denotation word ("recognizer")
parses in the same way than CREATE, so I can use POSTFIX (recently
published). Remember the board with tools in Starting Forth?
sans paroles ...
WANT GET-ENV
OK
"e" GET-ENV TYPE
euler499 OK
: $ NAME GET-ENV ; PREFIX
$ : ISN'T UNIQUE
OK
$e TYPE
euler499 OK
WANT POSTFIX
OK
: GET-ENV-NEW POSTFIX $ ;
OK
"e" GET-ENV-NEW TYPE
euler499 OK
1]
------------------------ ------------------------------
Personally I'm not particularly fond of EXECUTE-PARSING.
What I tend to do is along this idiom using $/
: handle-line .... ;
"APE" GET-FILE \ now the file is on stack as a string.
BEGIN ^J $/ DUP WHILE handle-line REPEAT 2DROP
>- anton
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-12-31 22:19 +0100 |
| Message-ID | <n64604$otq$1@dont-email.me> |
| In reply to | #44445 |
Paul Rubin wrote: > Raimond Dragomir <raimond.dragomir@gmail.com> writes: >> "$" words are sometimes usefull, that's why I exposed them. > > I remember being surprised I couldn't find anything like them in the > ANS standard. It seems like a shortcoming. Gforth has NEXTNAME which > is like your $data, but it's non-standard. EXECUTE-PARSING ( i*x addr u xt -- j*x ) is a more generic solution to that problem. There's a standard implementation of it in compat/ in Gforth's sources. -- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-01-01 21:43 -0800 |
| Message-ID | <87bn94edue.fsf@jester.gateway.pace.com> |
| In reply to | #44483 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > EXECUTE-PARSING ( i*x addr u xt -- j*x ) > is a more generic solution to that problem. There's a standard > implementation of it in compat/ in Gforth's sources. I see, it works by copying the string to a temp buffer and using EVALUATE. So I guess CORE has enough machinery to do this using a few variables and a scratch array, though it seems somewhat roundabout. compat/execute-parsing.fs actually uses ALLOCATE and an extra word list, which avoids leaving junk around, but needs more optional words. Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2016-01-01 23:36 -0800 |
| Message-ID | <cd0467d9-3120-403c-9dc2-a6c5e901d31f@googlegroups.com> |
| In reply to | #44519 |
sâmbătă, 2 ianuarie 2016, 07:43:08 UTC+2, Paul Rubin a scris:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
> > EXECUTE-PARSING ( i*x addr u xt -- j*x )
> > is a more generic solution to that problem. There's a standard
> > implementation of it in compat/ in Gforth's sources.
>
> I see, it works by copying the string to a temp buffer and using
> EVALUATE. So I guess CORE has enough machinery to do this using a few
> variables and a scratch array, though it seems somewhat roundabout.
> compat/execute-parsing.fs actually uses ALLOCATE and an extra word list,
> which avoids leaving junk around, but needs more optional words.
>
> Thanks!
The standard exposes only "high" level words. This may be understandable,
it's the way of any other languages. Forth is supposed to be different
though, it is supposed to give the programmer the power of extending
the COMPILER. In this respect, standardizing a lower level set of words
sounds good.
This lower level words are in fact trivial. Just the version of the higher
level, but working on a given string. This is the most flexible way. I've
shown it before what this words are and how trivial is to make the "standard"
words on top of them.
I even have more such words, for example $HEADER:
$header \ adr len flags -- nt
Makes a dictionary entry. (adr len) is the name.
The dictionary header made is not linked!
link \ nt --
link this nt to the current last
This is in fact the basis of all the other words!
Let's see some other words from the LFT reference manual:
: \ "name" -- C: -- nt
$def \ adr len -- C: -- nt
Makes a dictionary entry (flags = 0).
Definition begin
i: \ "name" -- C: -- nt
$idef \ adr len -- C: -- nt
Makes an immediate dictionary entry (flags = DF_IMMED).
Immediate definition begin
build \ xt "name" --
$build \ xt adr len --
Builds the xt as a normal (non-immediate) building word
ibuild \ xt "name" --
$ibuild \ xt adr len --
Builds the xt as an immediate building word
chere \ -- adr code pointer variable
nhere \ -- adr name pointer variable (dictionary pointer)
here \ -- adr data pointer variable (in ram)
chere0 \ -- adr code start address variable
nhere0 \ -- adr name start address variable
here0 \ -- adr data start address variable
data \ "name" --
$data \ adr len --
Makes a RAM data dictionary entry (data space).
const \ "name" --
$const \ adr len --
Makes a ROM data dictionary entry (code space).
constant \ x "name" --
$constant \ x adr len --
Makes a constant dictionary entry
$code \ xt adr len --
Makes a code dictionary entry
I don't have a CREATE because it's not clear if it refers to flash (code)
space - for constant data tables - or to ram spaces for variables and
buffers.
This is essential for a flash microcontroller based system.
RAM and ROM qualifiers are just a workaround that will complicate the
single CREATE. In fact you will have two CREATEs one for flash and one
for ram, and a unified top one that will switch on either one...
Anyway, what's hard in having first a $CREATE which takes a string
and then defining : CREATE bl parse $create ;
To me, it seems the most natural way of doing the thing, and I suspect
that in many implementations it IS the way it's done, only that nobody
thought of exposing the "$" version.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-02 15:36 +0000 |
| Message-ID | <2016Jan2.163603@mips.complang.tuwien.ac.at> |
| In reply to | #44519 |
Paul Rubin <no.email@nospam.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> writes:
>> EXECUTE-PARSING ( i*x addr u xt -- j*x )
>> is a more generic solution to that problem. There's a standard
>> implementation of it in compat/ in Gforth's sources.
>
>I see, it works by copying the string to a temp buffer and using
>EVALUATE. So I guess CORE has enough machinery to do this using a few
>variables and a scratch array, though it seems somewhat roundabout.
>compat/execute-parsing.fs actually uses ALLOCATE and an extra word list,
>which avoids leaving junk around, but needs more optional words.
The extra wordlist is there to avoid the typical problems in EVALUATE.
As for limiting yourself to CORE, that's an exercise in puzzle-solving
that has the same appeal as programming in Brainfuck or in "C without
undefined behaviour", but like these other activities serves no useful
purpose. Anyway, I am happy that EXECUTE-PARSING can be implemented
in standard Forth at all.
The proper way to implement it is to do it with karnal knowledge, as a
factor of EVALUATE, not the other way 'round. E.g., in Gforth
EVALUATE is implemented as follows:
: evaluate ( ... addr u -- ... ) \ core,block
['] interpret execute-parsing ;
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-01-02 12:18 -0800 |
| Message-ID | <87vb7bd9bk.fsf@jester.gateway.pace.com> |
| In reply to | #44532 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > The extra wordlist is there to avoid the typical problems in EVALUATE. What are the typical problems in EVALUATE? I haven't used it before. Thanks!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-03 14:34 +0000 |
| Message-ID | <2016Jan3.153457@mips.complang.tuwien.ac.at> |
| In reply to | #44540 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> The extra wordlist is there to avoid the typical problems in EVALUATE.
>
>What are the typical problems in EVALUATE?
The names are interpreted at run-time, using the search order,
dictionary contents, and other context (e.g., BASE) at that time,
resulting in late binding, unlike the compile-time name binding
normally used in Forth, and therefore expected by Forth programmers.
https://www.complang.tuwien.ac.at/forth/why-evaluate-is-bad
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-03 19:57 -0800 |
| Message-ID | <1f4f207f-e7b9-45f3-8a1d-bd791af3b79c@googlegroups.com> |
| In reply to | #44532 |
On Saturday, January 2, 2016 at 8:43:14 AM UTC-7, Anton Ertl wrote: > Paul Rubin <no.email@nospam.invalid> writes: > >Bernd Paysan <bernd.paysan@gmx.de> writes: > >> EXECUTE-PARSING ( i*x addr u xt -- j*x ) > >> is a more generic solution to that problem. There's a standard > >> implementation of it in compat/ in Gforth's sources. > > > >I see, it works by copying the string to a temp buffer and using > >EVALUATE. So I guess CORE has enough machinery to do this using a few > >variables and a scratch array, though it seems somewhat roundabout. > >compat/execute-parsing.fs actually uses ALLOCATE and an extra word list, > >which avoids leaving junk around, but needs more optional words. > > The extra wordlist is there to avoid the typical problems in EVALUATE. > As for limiting yourself to CORE, that's an exercise in puzzle-solving > that has the same appeal as programming in Brainfuck or in "C without > undefined behaviour", but like these other activities serves no useful > purpose. Anyway, I am happy that EXECUTE-PARSING can be implemented > in standard Forth at all. > > The proper way to implement it is to do it with karnal knowledge, as a > factor of EVALUATE, not the other way 'round. E.g., in Gforth > EVALUATE is implemented as follows: > > : evaluate ( ... addr u -- ... ) \ core,block > ['] interpret execute-parsing ; > > - anton The last time I heard about EXECUTE-PARSING was in 2009 when I wrote :NAME and it was denounced on the basis that EXECUTE-PARSING was supposedly better because it works for CREATE as well as colon, but EXECUTE-PARSING wasn't ANS-Forth standard and :NAME is ANS-Forth (everything in the novice package is ANS-Forth). Now you are saying that EXECUTE-PARSING has been written in ANS-Forth. Maybe --- a lot of code is supposedly ANS-Forth but actually is compiler-specific --- weirdly enough, programmers can claim that their code is ANS-Forth although it is not portable between compilers that are also claimed to be ANS-Forth. Anyway, I don't have any use for EXECUTE-PARSING so I won't bother to look at how it is implemented --- it is ugly in the typical gForth way --- also, it doesn't allow the compiled word to be put in a specified wordlist. All in all, I just do my own thing --- threads like this aren't worth reading because I'm not learning anything --- the committee members seem to think that they are big leaders and everybody depends on them for this kind of code, but their code is just ugly and no good. I really recommend that all Forth programmers ignore the Forth-200x committee. The Forth-200x committee foist ugly code such as EXECUTE-PARSING on an innocent Forth community --- nothing that they say about Forth is worth listening to --- any novice should be able to write better Forth code than this (my :NAME was written in one day).
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-01-04 22:49 +0000 |
| Message-ID | <n6esp9$mee$1@dont-email.me> |
| In reply to | #44552 |
On 04/01/2016 03:57, hughaguilar96@gmail.com wrote: > On Saturday, January 2, 2016 at 8:43:14 AM UTC-7, Anton Ertl wrote: >> Anyway, I am happy that EXECUTE-PARSING can be implemented >> in standard Forth at all. >> >> The proper way to implement it is to do it with karnal knowledge, as a >> factor of EVALUATE, not the other way 'round. E.g., in Gforth >> EVALUATE is implemented as follows: >> >> : evaluate ( ... addr u -- ... ) \ core,block >> ['] interpret execute-parsing ; >> >> - anton > > The last time I heard about EXECUTE-PARSING was in 2009 when I wrote :NAME > and it was denounced on the basis that EXECUTE-PARSING was supposedly > better because it works for CREATE as well as colon, but EXECUTE-PARSING > wasn't ANS-Forth standard and :NAME is ANS-Forth (everything in the > novice package is ANS-Forth). Like you I wasn't keen on EXECUTE-PARSING but have come to accept it (but still don't like the name). I think it has always been written in standard ANS Forth. You can't compare it directly with :NAME because EXECUTE-PARSING is a more general word. It can be used to perform the same function as :NAME but has additional uses, for a trivial example see my post https://groups.google.com/forum/?hl=en#!msg/comp.lang.forth/G8U6V5JsdS0/nkBB-tkBCwAJ > > Now you are saying that EXECUTE-PARSING has been written in ANS-Forth. > Maybe --- a lot of code is supposedly ANS-Forth but actually is > compiler-specific --- weirdly enough, programmers can claim that their > code is ANS-Forth although it is not portable between compilers that > are also claimed to be ANS-Forth. Anyway, I don't have any use for > EXECUTE-PARSING so I won't bother to look at how it is implemented Well then you have no right to speculate about whether it is defined in ANS Forth or not > --- it is ugly in the typical gForth way --- also, it doesn't allow > the compiled word to be put in a specified wordlist. As EXECUTE-PARSING is a more general word why should it? It is trivial to put wrapper around it to set a compilation wordlist, call EXECUTE-PARSING, and restore the original wordlist. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-01-04 15:05 -0800 |
| Message-ID | <2efd250f-7820-4548-8436-36402a2e97d7@googlegroups.com> |
| In reply to | #44557 |
On Monday, January 4, 2016 at 4:49:48 PM UTC-6, Gerry wrote: > On 04/01/2016 03:57, hughaguilar96@gmail.com wrote: > > --- it is ugly in the typical gForth way --- also, it doesn't allow > > the compiled word to be put in a specified wordlist. > > As EXECUTE-PARSING is a more general word why should it? It is trivial > to put wrapper around it to set a compilation wordlist, call > EXECUTE-PARSING, and restore the original wordlist. Hugh thinks it should accept a wid because WID-HEADER in SwiftForth just happens to, and that's the "thing like :NAME" that Hugh copied the interface of. His novice forth only ever invokes it as GET-CURRENT :NAME -- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-04 20:36 -0800 |
| Message-ID | <397b2635-fac5-4757-a98d-bd3d8aad7b1b@googlegroups.com> |
| In reply to | #44559 |
On Monday, January 4, 2016 at 4:05:16 PM UTC-7, Julian Fondren wrote: > On Monday, January 4, 2016 at 4:49:48 PM UTC-6, Gerry wrote: > > On 04/01/2016 03:57, hughaguilar96@gmail.com wrote: > > > --- it is ugly in the typical gForth way --- also, it doesn't allow > > > the compiled word to be put in a specified wordlist. > > > > As EXECUTE-PARSING is a more general word why should it? It is trivial > > to put wrapper around it to set a compilation wordlist, call > > EXECUTE-PARSING, and restore the original wordlist. > > Hugh thinks it should accept a wid because WID-HEADER in > SwiftForth just happens to, and that's the "thing like > :NAME" that Hugh copied the interface of. His novice forth > only ever invokes it as GET-CURRENT :NAME > > -- Julian I am just trying to simplify everything. The way Forth works internally, something like :NAME is a natural (I was actually copying from HEADER in UR/Forth, but only later did I discover that SwiftForth had WID-HEADER that was pretty much the same). When you construct a header in the dictionary (a hash-table or whatever), you have to specify the vocabulary --- it is better factorization to have this provided as a parameter rather than to always do a GET-CURRENT internally (you don't want low-level words to access global variables such as CURRENT if they don't have to). In addition to :NAME being already available (because it is a natural aspect of how Forth is implemented internally), :NAME is also widely useful to the application programmer (it is used often in the novice package). By comparison, EXECUTE-PARSING is not a natural aspect of Forth implementation (despite what Anton said about EVALUATE being written in terms of it) and it is not useful to the application programmer (I can't think of any use for it). Also, btw, I don't like the idea of CREATE being different from colon words internally. It is much simpler if everything is a colon word --- CREATE would generate a colon word. The idea of having different kinds of words is a throwback to ITC systems in which the different kinds of words would have different pointers in their code-field --- in an STC system though, it is simpler if everything is just a function. I still think that CREATE is being overloaded because it can either be used on its own, or it can be used with DOES> --- it is much simpler if CREATE is only used on its own and it is defined as : CREATE HERE CONSTANT ; I said way back in 2009 that <BUILDS should be used with DOES> and it should be a compile-time error to have a <BUILDS without a corresponding DOES> --- this is much simpler both for the compiler-writer and for explaining to the student. To me, a standard should be all about simplicity, but EXECUTE-PARSING seems complicated, hard to use, and a bad fit. Everything in Forth-200x seems this way to me! I remember after my ALLOCATION got killed, the next thing discussed was N>R and NR> and they were accepted. I saw this as Leon showing everybody that he can say yes as well as say no --- but N>R and NR> are trivial to implement, and they are ugly and useless. Forth-200x is just getting increasingly complicated and growing without any plan, whereas I want Forth to be increasingly simple and well-designed --- there is a huge difference between my style of Forth and the committee's style of Forth --- my objection is that they get to instantly declare everything they do "Standard" (with a capital 'S') and instantly dismisses every other style of Forth as being non-standard and fringe (including styles such as mine that have been common practice since prior to ANS-Forth and that have proven successful in commercial applications).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-05 13:03 -0800 |
| Message-ID | <6cd3a598-05f9-4767-b336-4bed76a4237e@googlegroups.com> |
| In reply to | #44557 |
On Monday, January 4, 2016 at 3:49:48 PM UTC-7, Gerry wrote: > On 04/01/2016 03:57, hughaguilar96@gmail.com wrote: > > --- it is ugly in the typical gForth way --- also, it doesn't allow > > the compiled word to be put in a specified wordlist. > > As EXECUTE-PARSING is a more general word why should it? It is trivial > to put wrapper around it to set a compilation wordlist, call > EXECUTE-PARSING, and restore the original wordlist. The way that general-purpose code works, is that it takes parameters on the stack rather than obtain the parameters from the outside system. My :NAME takes the wid on the stack as a parameter, rather than obtain it internally with GET-CURRENT. Your method essentially involves passing a parameter into a function using a global variable. Your wrapper obtains the value of CURRENT and holds onto it, then it sets CURRENT with a new value, then it executes the colon, then it restores the original value of CURRENT again. You describe this as "trivial" but it is actually over-complicated --- in Forth the parameters are supposed to be passed into functions on the parameter stack --- passing the parameters into functions in global variables is what people did in BASIC and it is just over-complicated and inefficient. Also, my :NAME takes the string on the stack as a parameter, rather than obtain it internally with WORD or PARSE. My :NAME is a general-purpose function because the string can originate anywhere (the code that calls :NAME has to come up with the string somehow) --- by comparison, colon is a special-purpose function because it obtains the string from one specific place (the input stream). It makes sense to me that :NAME being a low-level general-purpose function should be in the standard so it can be written in assembly-language by the compiler writer. Colon can be in the standard too, but it would be defined in terms of :NAME --- the low-level words in the standard should be defined by what they do and they will typically be implemented in assembly-language, but the high-level words can be provided as Forth source-code and this will be their definition in the standard. Colon can be defined like this: c" :" get-current :name bl word get-current :name ; Special-purpose functions such as colon are very convenient if the user needs that special-purpose functionality. General-purpose functions such as :NAME are inconvenient if the user needs that special purpose functionality provided by colon, but they are useful in circumstances in which some other functionality is required (either the wid is not what is currently in the global variable CURRENT and/or the string is not coming from the input stream). Gerry, you are not dumb --- you must know that general-purpose code is supposed to get its parameters from the parameter stack rather than from global variables. Really, if I had been the one who wrote EXECUTE-PARSING and the Forth-200x committee had written :NAME, then you would be arguing in favor of :NAME and against EXECUTE-PARSING. Anyway, there is a huge difference between my style of Forth programming and the committee's style of Forth programming. EXECUTE-PARSING is their kind of code, and :NAME is my kind of code. What I find offensive is that the committee pompously declares their style of Forth to be Standard (with a capital 'S') and dismiss my style of Forth as non-standard. I think that Anton Ertl is purposely trying to make Forth as complicated as possible. As a college professor, he is accustomed to giving written exams to students, and he wants to get a bell-shaped curve on the exam grades. If Forth were simple, then everybody would get a 100% on the test. Anton wants the majority to get a 70-79% (a C grade), with the strivers getting 80-89% (a B grade) and the plodders getting 60-69% (a D grade), then of course we have the handful of smarties who get 90-100% (an A grade) and the handful of blockheads who get below 60% which is a fail. The problem with this plan, is that the majority of Forth programmers who obtain a passing grade will be understanding only about 3/4 of the material, but you can't write a program that works if you only understand 3/4 of the language --- you really have to understand pretty much all of the language to actually be a programmer in that language --- this is why I want Forth to be simple and understandable, so it will actually be used to write working programs. As I said before, I wrote :NAME in one day; it was trivial. Lets imagine that some other brave Forth program has written :NAME or something very similar for use in meta-compiling and has been using it to write Forth programs. He shows up on comp.lang.forth and tries to tell us about how he does meta-compiling but he is told that he "sucks," that his code is "crap," and that he "has a serious misunderstanding of how pointers work." Also, Elizabeth Rather tries to sell him a copy of "Forth Application Techniques" informing him that he needs to buy this book and read it as a first baby-step towards becoming a Forth programmer. He leaves comp.lang.forth and doesn't come back. He continues to write Forth programs for several years. Later on, he applies for a job as a Forth programmer, and the interviewer says to him: "Explain what EXECUTE-PARSING does and how it is used for meta-compiling." The guy says: "I don't know what EXECUTE-PARSING does. I use :NAME for meta-compiling." So the interviewer says: "I am an expert on Forth-200x and I know that there is no :NAME mentioned in the standards document. You are just making this stuff up!" All of the people who are involved in Forth-2012 (including yourself) are dreaming that they will be the guy who passes the job interview and get hired --- they want Forth to be full of complicated nonsense because they can study up on Forth-200x in preparation for the job interview and know about EXECUTE-PARSING and everything else that that Anton Ertl and Bernd Paysan wrote --- they want the guy who spends his time writing programs to fail the job interview and not get hired.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-05 14:30 -0800 |
| Message-ID | <355675db-aeac-42cf-a603-7ef737d7a755@googlegroups.com> |
| In reply to | #44598 |
On Tuesday, January 5, 2016 at 4:03:55 PM UTC-5, hughag...@gmail.com wrote: > ... > Also, my :NAME takes the string on the stack as a parameter, rather than obtain it internally with WORD or PARSE. My :NAME is a general-purpose function because the string can originate anywhere (the code that calls :NAME has to come up with the string somehow) --- by comparison, colon is a special-purpose function because it obtains the string from one specific place (the input stream). It makes sense to me that :NAME being a low-level general-purpose function should be in the standard so it can be written in assembly-language by the compiler writer. > ... I have a word that is just like :NAME ... I called it create-empty. It is written in assembly, and it took me maybe 1/2 hour max to write it. I think I'll call it :NAME instead. All my defining words use it.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-05 21:10 -0800 |
| Message-ID | <64b3e532-e706-422d-a60c-16ab16040b21@googlegroups.com> |
| In reply to | #44601 |
On Tuesday, January 5, 2016 at 3:30:53 PM UTC-7, Chris Curl wrote: > On Tuesday, January 5, 2016 at 4:03:55 PM UTC-5, hughag...@gmail.com wrote: > > ... > > Also, my :NAME takes the string on the stack as a parameter, rather than obtain it internally with WORD or PARSE. My :NAME is a general-purpose function because the string can originate anywhere (the code that calls :NAME has to come up with the string somehow) --- by comparison, colon is a special-purpose function because it obtains the string from one specific place (the input stream). It makes sense to me that :NAME being a low-level general-purpose function should be in the standard so it can be written in assembly-language by the compiler writer. > > ... > I have a word that is just like :NAME ... I called it create-empty. It is written in assembly, and it took me maybe 1/2 hour max to write it. I think I'll call it :NAME instead. All my defining words use it. :NAME does what colon does, which is set STATE to TRUE for compilation-mode, and also possibly put some control-flow data on the control-flow stack (which may or may not be the parameter stack) for semicolon to use. HEADER in UR/Forth didn't do all of this colon stuff --- it just created the header in the dictionary --- if colon was the function that called HEADER then colon had to do this colon stuff --- but it could have been other defining words that called HEADER (such as CODE or CREATE), none of which do this colon stuff. I think WID-HEADER in SwiftForth is similar to HEADER in UR/Forth in that it doesn't do all of this colon stuff (I'm not sure about this; I don't have the source-code for the kernel stuff handy, and I don't have time to figure out the lengthy disassembly). Anyway, if your CREATE-EMPTY is similar to HEADER in UR/Forth in that it just makes the header but doesn't do all the colon stuff, then you shouldn't call it :NAME --- you should write a :NAME in terms of CREATE-EMPTY that does the colon stuff so it can be used for meta-compiling in the same way that I use :NAME in the novice package. I'm glad that you are interested in this stuff. :-) You seem to be making good progress on your Forth system. Is this in assembly language? If so, I would be interested in looking at it.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-05 21:26 -0800 |
| Message-ID | <e8b65b64-dd12-48f2-866d-c2e9d831ddc6@googlegroups.com> |
| In reply to | #44609 |
On Tuesday, January 5, 2016 at 10:10:34 PM UTC-7, hughag...@gmail.com wrote: > Anyway, if your CREATE-EMPTY is similar to HEADER in UR/Forth in that it just makes the header but doesn't do all the colon stuff, then you shouldn't call it :NAME --- you should write a :NAME in terms of CREATE-EMPTY that does the colon stuff so it can be used for meta-compiling in the same way that I use :NAME in the novice package. You might want to rename CREATE-EMPTY to <:NAME> and then write :NAME that calls this --- it is my naming convention (maybe others as well) to put pointy brackets around the low-level version of a function --- this is often done with recursive functions because the low-level version is recursive but the high-level makes the initial call to it. As some examples, I have <ALLOCATION> and ALLOCATION, also <DSQRT> and DSQRT, also recursive functions generally have the pointy brackets and the high-level version makes the first call (I can't think of any examples of this off the top of my head) --- I'm not very consistent in this naming convention though because I also have <OPEN-FILE> which is a high-level version of OPEN-FILE.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-06 05:01 -0800 |
| Message-ID | <c3375799-8518-4f91-bf54-5346c5850634@googlegroups.com> |
| In reply to | #44609 |
On Wednesday, January 6, 2016 at 12:10:34 AM UTC-5, hughag...@gmail.com wrote: > ... > > :NAME does what colon does, which is set STATE to TRUE for compilation-mode, and also possibly put some control-flow data on the control-flow stack (which may or may not be the parameter stack) for semicolon to use. > > HEADER in UR/Forth didn't do all of this colon stuff --- it just created the header in the dictionary --- if colon was the function that called HEADER then colon had to do this colon stuff --- but it could have been other defining words that called HEADER (such as CODE or CREATE), none of which do this colon stuff. Yes, this sounds more like my create-empty. > Anyway, if your CREATE-EMPTY is similar to HEADER in UR/Forth in that it just makes the header but doesn't do all the colon stuff, then you shouldn't call it :NAME --- you should write a :NAME in terms of CREATE-EMPTY that does the colon stuff so it can be used for meta-compiling in the same way that I use :NAME in the novice package. Sounds good. > I'm glad that you are interested in this stuff. :-) You seem to be making good progress on your Forth system. Is this in assembly language? If so, I would be interested in looking at it. It is here. There are a few updates I have added recently that are not there at the moment. Any constructs you see that could be cleaned up or suggestions would be greatly appreciated. My x86 assembler is still very rusty, so I am sure there are more than a few areas where it could be cleaned up. https://github.com/CCurl/Forth-PCode-Asm
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-01-06 00:13 +0000 |
| Message-ID | <n6hm6m$6is$1@dont-email.me> |
| In reply to | #44598 |
hughaguilar96@gmail.com wrote: > Gerry, you are not dumb --- you must know that general-purpose > code is supposed to get its parameters from the parameter > stack rather than from global variables. Really, if I had been > the one who wrote EXECUTE-PARSING and the Forth-200x committee > had written :NAME, then you would be arguing in favor of :NAME > and against EXECUTE-PARSING. "The Masters cannot be wrong! The Masters must not be wrong! I would be so frightened without The Masters to guide and control me! They are God's Annointed!" -- Amazon bans book. After nearly a month on the site, all traces of the book and its 80 reviews have been removed. http://jamesfetzer.blogspot.com/2015/11/debunking-sandy-hook-debunkers-5.html https://www.youtube.com/watch?v=EEl_1HWFRfo
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-01-06 19:47 +0000 |
| Message-ID | <n6jqr9$1nb$1@dont-email.me> |
| In reply to | #44598 |
On 05/01/2016 21:03, hughaguilar96@gmail.com wrote:
> On Monday, January 4, 2016 at 3:49:48 PM UTC-7, Gerry wrote:
>> On 04/01/2016 03:57, hughaguilar96@gmail.com wrote:
>>> --- it is ugly in the typical gForth way --- also, it doesn't allow
>>> the compiled word to be put in a specified wordlist.
>>
>> As EXECUTE-PARSING is a more general word why should it? It is trivial
>> to put wrapper around it to set a compilation wordlist, call
>> EXECUTE-PARSING, and restore the original wordlist.
>
> The way that general-purpose code works, is that it takes
> parameters on the stack rather than obtain the parameters
> from the outside system. My :NAME takes the wid on the stack
> as a parameter, rather than obtain it internally with
> GET-CURRENT. Your method essentially involves passing a
> parameter into a function using a global variable. Your
>wrapper obtains the value of CURRENT and holds onto it,
> then it sets CURRENT with a new value, then it executes
> the colon, then it restores the original value of CURRENT
> again. You describe this as "trivial" but it is actually
> over-complicated --- in Forth the parameters are supposed
> to be passed into functions on the parameter stack --- passing
> the parameters into functions in global variables is what
> people did in BASIC and it is just over-complicated and
> inefficient.
>
You are jumping to the conclusion that I am arguing against :NAME which
is just not true. I have often wanted a word such as :NAME and, like
most if not all systems, mine has a word that performs a similar
function that the definition of : uses. My equivalent creates a
linked-in header, its a natural factor of defining words. The gist of my
response to you was not that EXECUTE-PARSING is better or worse than
:NAME but that it is a more general word that can be used for other
purposes requiring the input source to be parsed using words like PARSE
that only operate on the input source.
I take your point and agree about passing parameters in on the stack but
would point out that it is a common technique to specialise a general
purpose word to a more specific function and that is what I suggested
could be done. For example :NAME can be defined using the general
purpose word EXECUTE-PARSING but the opposite isn't possible.
: :name ( caddr u wid -- )
get-current >r set-current ['] : execute-parsing
r> set-current
;
Whether it's over-complicated (I don't believe that someone with your
ability finds that complicated), ugly or inefficient is beside the point
I was making.
> you must know that general-purpose code is supposed to get its
> parameters from the parameter stack rather than from global
> variables. Really, if I had been the one who wrote EXECUTE-PARSING
> and the Forth-200x committee had written :NAME, then you would be
> arguing in favor of :NAME and against EXECUTE-PARSING.
No I don't think I would do that. Why should I take sides. Elsewhere I
pointed out to Paul Rubin that the Forth 2012 SUBSTITUTE could be used
for defining words like :NAME but Anton dismissed the idea. But if
SUBSTITUTE were to be extended to use a top of the stack string it would
be p less cumbersome.
Anyway I don't think anyone is particularly trying to standardise
EXECUTE-PARSING, I don't think that an RfD has been issued for it and it
certainly isn't in the Forth 2012 standard.
> All of the people who are involved in Forth-2012 (including yourself)
> are dreaming that they will be the guy who passes the job interview
> and get hired
Don't include me in that, I'm not looking for work
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-07 21:43 -0800 |
| Message-ID | <90e2f61c-831f-44e4-b1a4-ebf18bc2e791@googlegroups.com> |
| In reply to | #44641 |
On Wednesday, January 6, 2016 at 12:47:25 PM UTC-7, Gerry wrote: > On 05/01/2016 21:03, hughaguilar96@gmail.com wrote: > I take your point and agree about passing parameters in on the stack but > would point out that it is a common technique to specialise a general > purpose word to a more specific function and that is what I suggested > could be done. For example :NAME can be defined using the general > purpose word EXECUTE-PARSING but the opposite isn't possible. > > : :name ( caddr u wid -- ) > get-current >r set-current ['] : execute-parsing > r> set-current > ; > > Whether it's over-complicated (I don't believe that someone with your > ability finds that complicated), ugly or inefficient is beside the point > I was making. Anytime that you write code that constructs a string of source-code and evaluates that string, you are admitting that your language has failed you. This is over-complicated because EXECUTE-PARSING is constructing source-code for colon to use, but colon is passing this source-code (the name of the function being defined) into something very similar to :NAME --- so, you are defining :NAME with code that calls :NAME internally --- it would be a lot simpler if :NAME were just exposed to the user. > Anyway I don't think anyone is particularly trying to standardise > EXECUTE-PARSING, I don't think that an RfD has been issued for it and it > certainly isn't in the Forth 2012 standard. When I wrote an RfD for :NAME it was killed on the basis that EXECUTE-PARSING does the job better --- this is effectively saying that EXECUTE-PARSING has already been accepted into the Forth-200x standard --- how else would you interpret this argument? The reason why nobody has written an RfD for EXECUTE-PARSING is that the committee is still looking for somebody to put their name on it. Forth-200x is all about "astro-turfing" (making a corporate product appear to be a grass-roots movement). This means that they need to find people who aren't members of the committee to put their names on the RfDs for stuff that has already been accepted into Forth-200x, for the purpose of making Forth-200x appear to be a collaborative effort of the whole Forth community. We already saw how Bernd Paysan was "assigned" to write the fake quotations, which he did, but he didn't put his name on the RfD and instead he had his lick-spittle Alex McDonald put his name on it. Now Alex McDonald has disappeared, so the RfD is hanging until they can find somebody else to put his name on it. EXECUTE-PARSING has already been accepted by the Forth-200x committee (that is why :NAME was killed in 2009) but they are still trying to find somebody who will put his name on it --- you are the only person who has ever shown any interest in EXECUTE-PARSING so you are the most likely candidate to write the RfD --- if you don't want to write the RfD though, then they will have to find somebody else to front it for them. It is inevitable that EXECUTE-PARSING will be accepted --- they could find a wino and give him a bottle of Night-Train in exchange for putting his name on the RfD --- it will be a slam-dunk from a ladder for whoever agrees to be their front man. > > All of the people who are involved in Forth-2012 (including yourself) > > are dreaming that they will be the guy who passes the job interview > > and get hired > > Don't include me in that, I'm not looking for work It is convenient that you aren't looking for a job as a Forth programmer, because there aren't any jobs for Forth programmers. I'm one of only a handful of people who have had a job as a Forth programmer --- my job interview didn't involve passing any written test to prove that I am familiar with code written by other people (that is what EXECUTE-PARSING is) because the job didn't involve any code written by other people (there are no other people in a small company) --- it is much more important to know the principles than the principals (in the unlikely event that a Forth job ever crops up, this will still be true just like 20 years ago).
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-08 05:54 -0800 |
| Message-ID | <8c6d785f-3433-43f9-9401-05a0aa837c1b@googlegroups.com> |
| In reply to | #44677 |
On Friday, January 8, 2016 at 12:43:41 AM UTC-5, hughag...@gmail.com wrote: > > Anytime that you write code that constructs a string of source-code and evaluates that string, you are admitting that your language has failed you. > Ouch. I was (am) planning on using this feature of Forth as the way my machine learns new definitions on the fly. It is still a pipe dream at this point.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web