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 5 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-08 16:44 +0000 |
| Message-ID | <568fe758$0$23845$e4fe514c@news.xs4all.nl> |
| In reply to | #44690 |
Chris Curl <ccurl609@gmail.com> writes: >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. Don't worry. If you use that feature it just means you're into a.i. 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-08 16:27 -0800 |
| Message-ID | <2c5fd1e8-3c6b-402b-8aaa-133f39b7b55d@googlegroups.com> |
| In reply to | #44690 |
On Friday, January 8, 2016 at 6:54:31 AM UTC-7, Chris Curl wrote: > 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. I don't know how that would work --- let us know if you have any success with it. When I said that the language has failed, I meant that implementing features in the language by constructing strings of source-code and evaluating them, means that the language should have that feature built-in --- EVALUATE is a kludge --- this should not be the standard way of implementing the feature.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-08 17:18 +0000 |
| Message-ID | <2016Jan8.181803@mips.complang.tuwien.ac.at> |
| In reply to | #44677 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 08/01/2016 05:43, hughaguilar96@gmail.com wrote:
[...]
>I agree that it would be better if the language provided such defining
>words.
>
>If EXECUTE-PARSING is built in to a system it can be very efficient - as
>Anton Ertl demonstrated.
Passing a string by making it the input stream and letting a parsing
word pick it up again is a pretty roundabout way and not really a
model of efficiency. EXECUTE-PARSING is not intended to be used where
efficiency is paramount, but is intended as a way to cope with cases
where some other programmer (or in the case of :, the standard's
committee) has provided a parsing word and you want to pass a string
to it that you have on the stack.
However, if the parsing word is wrapped by a number of other words
that have their own data on the stack, passing the string through the
input stream may reduce the stack juggling quite a bit, maybe even to
the point where the overhead of using the input stream is less than
the overhead of stack juggling. But a global variable (as used in
NEXTNAME) is more efficient still.
>> 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.
>
>More likely that the concept of recognisers mostly supersedes the need
>for EXECUTE-PARSING
I have given the reason why there has been no RfD for EXECUTE-PARSING
in <2015Dec31.151312@mips.complang.tuwien.ac.at>, essentially that
there was resistance from a committee member. Recognizers do not
supersede the need for 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-01-08 17:00 +0000 |
| Message-ID | <n6oppb$s35$2@dont-email.me> |
| In reply to | #44677 |
On 08/01/2016 05:43, hughaguilar96@gmail.com wrote: > On Wednesday, January 6, 2016 at 12:47:25 PM UTC-7, Gerry wrote: >> On 05/01/2016 21:03, hughaguilar96@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. That's one way of looking at it; another way is to say that the language has served us by providing EVALUATE for situations that the language standardisers didn't foresee :) > > 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. I agree that it would be better if the language provided such defining words. If EXECUTE-PARSING is built in to a system it can be very efficient - as Anton Ertl demonstrated. Similarly if :NAME is built in. Anyway, according to Anton Ertl's reply to Andrew Haley it seems I was wrong with my definition of :NAME. But if you see my reply to Anton it looks as if :NAME suffers from the same problem. > >> 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? I don't remember the statement being made that "EXECUTE-PARSING does the job better". How can it? EXECUTE-PARSING is more general word than :NAME which is highly specific, they are not competing. > > 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. More likely that the concept of recognisers mostly supersedes the need for EXECUTE-PARSING -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-01-08 04:52 -0600 |
| Message-ID | <VN2dnXr8VPlNCRLLnZ2dnUU78eednZ2d@supernews.com> |
| In reply to | #44641 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>
> 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
> ;
Mmm, yes. But I think it really needs to be something like
: :name ( caddr u wid -- )
get-current >r set-current
['] : ['] execute-parsing catch
r> set-current
throw ;
That double indirection via EXECUTE-PARSING and CATCH is rather ugly.
Maybe a better factoring would be something like
: execute-parsing? ( i*x caddr u xt -- j*x n )
['] execute-parsing catch ;
: :name ( caddr u wid -- )
get-current >r set-current
['] : execute-parsing?
r> set-current
throw ;
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-08 11:27 +0000 |
| Message-ID | <2016Jan8.122706@mips.complang.tuwien.ac.at> |
| In reply to | #44684 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>>
>> 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
>> ;
>
>Mmm, yes. But I think it really needs to be something like
>
>: :name ( caddr u wid -- )
> get-current >r set-current
> ['] : ['] execute-parsing catch
> r> set-current
> throw ;
>
>That double indirection via EXECUTE-PARSING and CATCH is rather ugly.
>Maybe a better factoring would be something like
>
>: execute-parsing? ( i*x caddr u xt -- j*x n )
> ['] execute-parsing catch ;
>
>: :name ( caddr u wid -- )
> get-current >r set-current
> ['] : execute-parsing?
> r> set-current
> throw ;
The better factoring is to have a wrapper for CURRENT; this can also
be reused for other cases.
: current-execute ( ... wid xt -- ... )
get-current >r swap set-current catch r> set-current ;
and then use that wrapper in combination with EXECUTE-PARSING:
: :name ( c-addr u wid -- )
['] : ['] current-execute execute-parsing ;
However, note:
|16.3.3 Finding definition names
|
|[...] An ambiguous condition exists if a program changes the compilation
|word list during the compilation of a definition [...]
- 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-08 16:44 +0000 |
| Message-ID | <2016Jan8.174443@mips.complang.tuwien.ac.at> |
| In reply to | #44702 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>The better factoring is to have a wrapper for CURRENT; this can also
>be reused for other cases.
>
>: current-execute ( ... wid xt -- ... )
> get-current >r swap set-current catch r> set-current ;
>
>and then use that wrapper in combination with EXECUTE-PARSING:
>
>: :name ( c-addr u wid -- )
> ['] : ['] current-execute execute-parsing ;
And testing helps to get rid of bugs; here are tested and debugged
definitions of CURRENT-EXECUTE and :NAME:
: current-execute ( ... wid xt -- ... )
get-current >r swap set-current catch r> set-current throw ;
: :name1 ( c-addr u -- colon-sys )
['] : execute-parsing ;
: :name ( c-addr u wid -- colon-sys )
['] :name1 current-execute ;
- 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-08 21:17 +0100 |
| Message-ID | <n6p5cf$3nm$2@dont-email.me> |
| In reply to | #44704 |
Anton Ertl wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>The better factoring is to have a wrapper for CURRENT; this can also >>be reused for other cases. >> >>: current-execute ( ... wid xt -- ... ) >> get-current >r swap set-current catch r> set-current ; >> >>and then use that wrapper in combination with EXECUTE-PARSING: >> >>: :name ( c-addr u wid -- ) >> ['] : ['] current-execute execute-parsing ; > > And testing helps to get rid of bugs; here are tested and debugged > definitions of CURRENT-EXECUTE and :NAME: > > : current-execute ( ... wid xt -- ... ) > get-current >r swap set-current catch r> set-current throw ; > > : :name1 ( c-addr u -- colon-sys ) > ['] : execute-parsing ; This might be more useful than :NAME itself. If someone is serious about :NAME, this above should be called :NAME and the one below :NAME-IN (as in "define name in wid"). > : :name ( c-addr u wid -- colon-sys ) > ['] :name1 current-execute ; -- 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-01-08 16:57 +0000 |
| Message-ID | <n6opk9$s35$1@dont-email.me> |
| In reply to | #44702 |
On 08/01/2016 11:27, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: >>> >>> 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 >>> ; >> >> Mmm, yes. But I think it really needs to be something like >> >> : :name ( caddr u wid -- ) >> get-current >r set-current >> ['] : ['] execute-parsing catch >> r> set-current >> throw ; >> >> That double indirection via EXECUTE-PARSING and CATCH is rather ugly. >> Maybe a better factoring would be something like >> >> : execute-parsing? ( i*x caddr u xt -- j*x n ) >> ['] execute-parsing catch ; >> >> : :name ( caddr u wid -- ) >> get-current >r set-current >> ['] : execute-parsing? >> r> set-current >> throw ; > > The better factoring is to have a wrapper for CURRENT; this can also > be reused for other cases. > > : current-execute ( ... wid xt -- ... ) > get-current >r swap set-current catch r> set-current ; > > and then use that wrapper in combination with EXECUTE-PARSING: > > : :name ( c-addr u wid -- ) > ['] : ['] current-execute execute-parsing ; > > However, note: > > |16.3.3 Finding definition names > | > |[...] An ambiguous condition exists if a program changes the compilation > |word list during the compilation of a definition [...] I wasn't aware of that one. It makes my claim about using EXECUTE-PARSING to define :NAME wrong. But OTOH looking at Hugh's Novice package :NAME does exactly the same thing ... GET-CURRENT >R SET-CURRENT ( create a string and evaluate it ) R> SET-CURRENT so he's violating that ambiguous condition as well. Therefore both versions can only use the compilation wordlist so there is no point in passing a wordlist into :NAME -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-08 17:06 +0000 |
| Message-ID | <2016Jan8.180640@mips.complang.tuwien.ac.at> |
| In reply to | #44705 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 08/01/2016 11:27, Anton Ertl wrote:
>> However, note:
>>
>> |16.3.3 Finding definition names
>> |
>> |[...] An ambiguous condition exists if a program changes the compilation
>> |word list during the compilation of a definition [...]
>
>I wasn't aware of that one. It makes my claim about using
>EXECUTE-PARSING to define :NAME wrong. But OTOH looking at Hugh's Novice
>package :NAME does exactly the same thing
>
>... GET-CURRENT >R SET-CURRENT ( create a string and evaluate it ) R>
>SET-CURRENT
>
>so he's violating that ambiguous condition as well.
>Therefore both versions can only use the compilation wordlist so there
>is no point in passing a wordlist into :NAME
The question is what happens when CURRENT is different at : and at ;
(or wherever the new word is revealed). Let's see:
vocabulary v1 vocabulary v2 also v1 definitions
: bla [ v2 ] ;
cr .( v1) v1 words
cr .( v2) v2 words
vfxlin outputs:
cr ." v1" v1 words
v1
Words in V1
BLA ok
cr ." v2" v2 words
v2
Words in V2
sf outputs:
cr ." v1" v1 words
bla ok
cr ." v2" v2 words
ok
Gforth outputs:
cr ." v1" v1 words
v1
bla ok
cr ." v2" v2 words
v2
ok
iForth-2.1 outputs:
v2> cr .( v1) v1 words
v1
bla
ok
v1> cr .( v2) v2 words
v2
ok
So these systems put the word in the wordlist that is current during
:. Are there any systems that do something else? Maybe we can remove
this ambiguous condition?
- 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-01-08 20:24 +0000 |
| Message-ID | <n6p5oa$aqe$1@dont-email.me> |
| In reply to | #44706 |
On 08/01/2016 17:06, Anton Ertl wrote: > The question is what happens when CURRENT is different at : and at ; > (or wherever the new word is revealed). Let's see: > > vocabulary v1 vocabulary v2 also v1 definitions > : bla [ v2 ] ; > cr .( v1) v1 words > cr .( v2) v2 words But CURRENT isn't different at : and at ; in the definition of bla. So what are you proving? Did you mean? : bla [ v2 definitions ] ; which doesn't make any difference in most systems except for the version of iForth I have (4.0.380 Windows 32 bit, rather old) which gives v2> cr .( v1) v1 words v1 ok v1> cr .( v2) v2 words v2 bla ok which is different as BLA is in vocabulary v2. I wondered whether 16.3.3 (about finding definition names) was necessary. Looking at A.16.3.3 they seemed to be concerned about RECURSE ; and IMMEDIATE finding the correct name in the compilation wordlist, not about which list it compiles into. It quotes : FOO ... [ ... SET-CURRENT ] ... RECURSE ... ; as not guaranteed to work. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-09 17:05 +0000 |
| Message-ID | <2016Jan9.180521@mips.complang.tuwien.ac.at> |
| In reply to | #44710 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 08/01/2016 17:06, Anton Ertl wrote:
>> The question is what happens when CURRENT is different at : and at ;
>> (or wherever the new word is revealed). Let's see:
>>
>> vocabulary v1 vocabulary v2 also v1 definitions
>> : bla [ v2 ] ;
>> cr .( v1) v1 words
>> cr .( v2) v2 words
>
>But CURRENT isn't different at : and at ; in the definition of bla. So
>what are you proving?
>
>Did you mean?
>: bla [ v2 definitions ] ;
Yes, thanks.
> which doesn't make any difference in most systems except for the
>version of iForth I have (4.0.380 Windows 32 bit, rather old) which gives
>
>v2> cr .( v1) v1 words
>v1
>
> ok
>v1> cr .( v2) v2 words
>v2
>bla
> ok
>
>which is different as BLA is in vocabulary v2.
>
>I wondered whether 16.3.3 (about finding definition names) was
>necessary. Looking at A.16.3.3 they seemed to be concerned about RECURSE
>; and IMMEDIATE finding the correct name in the compilation wordlist,
>not about which list it compiles into. It quotes
>
>: FOO ... [ ... SET-CURRENT ] ... RECURSE ... ;
>
>as not guaranteed to work.
The main issue seems to me that, as Bernd Paysan has explained, there
are (and have been already before Forth-94) two ways of dealing with
the invisibility of colon definitions before the ";": Insert the word
in the CURRENT wordlist during :, but hide it (the SMUDGE approach,
used in fig-Forth), and insert the word in the CURRENT wordlist during
";" (the REVEAL approach, used in F83 AFAIK). This would lead to
different results, which is a frequent reason for a standards
committee to not standardize the behaviour in this situation.
RECURSE also has to work for :NONAME words, so most systems probably
don't implement it by going through CURRENT. IMMEDIATE might be
implemented as going through CURRENT, though. Interestingly they did
not mention 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-01-08 20:02 +0000 |
| Message-ID | <56901575.1989524072@news.eternal-september.org> |
| In reply to | #44705 |
On Fri, 8 Jan 2016 16:57:27 +0000, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: >> |16.3.3 Finding definition names >> | >> |[...] An ambiguous condition exists if a program changes the compilation >> |word list during the compilation of a definition [...] > >I wasn't aware of that one. It makes my claim about using >EXECUTE-PARSING to define :NAME wrong. But OTOH looking at Hugh's Novice >package :NAME does exactly the same thing > >... GET-CURRENT >R SET-CURRENT ( create a string and evaluate it ) R> >SET-CURRENT > >so he's violating that ambiguous condition as well. >Therefore both versions can only use the compilation wordlist so there >is no point in passing a wordlist into :NAME When the needs of people are not what the standard permits, perhaps it is time to change the standard. Remember that one purpose of a standard is to serve the needs of the current users. When it's wrong, change it. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-01-08 21:49 +0100 |
| Message-ID | <n6p78e$9h$1@dont-email.me> |
| In reply to | #44709 |
Stephen Pelc wrote: > On Fri, 8 Jan 2016 16:57:27 +0000, Gerry Jackson > <gerry@jackson9000.fsnet.co.uk> wrote: > >>> |16.3.3 Finding definition names >>> | >>> |[...] An ambiguous condition exists if a program changes the >>> |[compilation >>> |word list during the compilation of a definition [...] >> >>I wasn't aware of that one. It makes my claim about using >>EXECUTE-PARSING to define :NAME wrong. But OTOH looking at Hugh's Novice >>package :NAME does exactly the same thing >> >>... GET-CURRENT >R SET-CURRENT ( create a string and evaluate it ) R> >>SET-CURRENT >> >>so he's violating that ambiguous condition as well. >>Therefore both versions can only use the compilation wordlist so there >>is no point in passing a wordlist into :NAME > > When the needs of people are not what the standard permits, perhaps > it is time to change the standard. Remember that one purpose of a > standard is to serve the needs of the current users. > > When it's wrong, change it. Traditionally, Forth added a word to the current wordlist at definition, but kept it hidden (with SMUDGE). Only the ; revealed the word. So it's two stage: the first stage is at : where it is inserted in the list, the second stage is at ; to reveal the word. If you happen to change the current search order in between, this shouldn't affect where it gets revealed. So if you don't have a traditional implementation with a smudge bit, you at least should remember the current wordlist where to add the word. Most people who follow the traditional approach or at least want to be compatible with it, do anyhow. bigForth uses a non-traditional reveal, and doesn't keep track of the last current, so a word like vocabulary v1 vocabulary v2 also v1 definitions : bla [ v2 definitions ] ." in v1" ; actually ends up in v2. -- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-09 22:06 -0800 |
| Message-ID | <10af9ec2-abb6-4567-b695-8063364603e7@googlegroups.com> |
| In reply to | #44705 |
On Friday, January 8, 2016 at 9:03:23 PM UTC-7, Gerry wrote: > On 08/01/2016 11:27, Anton Ertl wrote: > > However, note: > > > > |16.3.3 Finding definition names > > | > > |[...] An ambiguous condition exists if a program changes the compilation > > |word list during the compilation of a definition [...] > > I wasn't aware of that one. It makes my claim about using > EXECUTE-PARSING to define :NAME wrong. But OTOH looking at Hugh's Novice > package :NAME does exactly the same thing > > ... GET-CURRENT >R SET-CURRENT ( create a string and evaluate it ) R> > SET-CURRENT > > so he's violating that ambiguous condition as well. > Therefore both versions can only use the compilation wordlist so there > is no point in passing a wordlist into :NAME I've been programming in ANS-Forth since 2009, but I still find unexpected pitfalls! This is actually yet another example of how ANS-Forth standardizes implementation rather than behavior. They made this an ambiguous condition because they are assuming that the only way to obtain the xt or nfa of the latest word is by looking in the CURRENT word-list to find the latest word there. Common practice has always been to store this in the LATEST variable, but ANS-Forth dropped that. It would make more sense to say that RECURSE and IMMEDIATE always work --- not that they work sometimes but other times will be ambiguous. ANS-Forth is just stupid in every way! Forth is really not very complicated --- it is just astounding how the ANS-Forth committee managed to screw up in so many different ways, what should have been an easy straight-forward job. Now 20 years later all of the ANS-Forth supporters are doggedly defending ANS-Forth and saying that I'm just a bad Forth programmer because I don't predict all of these ambiguities. I can remember a time (before 1994) when one of Forth's selling points was that it was easy to understand.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-01-10 07:46 -0600 |
| Message-ID | <b5udnZiEuNoB_Q_LnZ2dnUU78KWdnZ2d@supernews.com> |
| In reply to | #44702 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Maybe a better factoring would be something like >> >>: execute-parsing? ( i*x caddr u xt -- j*x n ) >> ['] execute-parsing catch ; >> >>: :name ( caddr u wid -- ) >> get-current >r set-current >> ['] : execute-parsing? >> r> set-current >> throw ; > > The better factoring is to have a wrapper for CURRENT; this can also > be reused for other cases. > > : current-execute ( ... wid xt -- ... ) > get-current >r swap set-current catch r> set-current ; > > and then use that wrapper in combination with EXECUTE-PARSING: > > : :name ( c-addr u wid -- ) > ['] : ['] current-execute execute-parsing ; OK; it's a bit obscure, but I wouldn't reject that solution. > However, note: > > |16.3.3 Finding definition names > | > |[...] An ambiguous condition exists if a program changes the compilation > |word list during the compilation of a definition [...] So, is there any way to do :NAME correctly on a standard system? I can't think of one, because SMUDGE (or UNSMUDGE) might end up modifying the wrong header. And this is bound to be true regardless of how :NAME is implemented: the only way around it would be to change the compler so that it keeps a pointer to the most recent definition as well as a pointer to the current wordlist. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-10 14:35 +0000 |
| Message-ID | <2016Jan10.153524@mips.complang.tuwien.ac.at> |
| In reply to | #44736 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> However, note:
>>
>> |16.3.3 Finding definition names
>> |
>> |[...] An ambiguous condition exists if a program changes the compilation
>> |word list during the compilation of a definition [...]
>
>So, is there any way to do :NAME correctly on a standard system?
You can implement it correctly, but using it without incurring the
ambiguous condition makes the wid parameter pretty useless if you want
a program without ambiguous conditions. However, one could remove
that ambiguous condition by remembering the CURRENT at the last : and
at the last CREATE and redefining ;, RECURSE, IMMEDIATE and DOES> to
temporarily use that CURRENT.
>I
>can't think of one, because SMUDGE (or UNSMUDGE) might end up
>modifying the wrong header. And this is bound to be true regardless
>of how :NAME is implemented: the only way around it would be to change
>the compler so that it keeps a pointer to the most recent definition
>as well as a pointer to the current wordlist.
Keeping a pointer to the most recent definition is a good idea and we
have done this in Gforth since forever. Implementing RECURSE, ;,
IMMEDIATE and DOES> by assuming that the head of the current wordlist
is the last defined word may have been a good idea when there was no
search order and all words had names, but since we now have these
features, it no longer is.
The other issue is REVEAL-based systems like bigForth and Gforth.
Gforth stores the CURRENT wordlist during : and uses that for
REVEALing the word in ";" (or RECURSIVE), and so the CURRENT during :
is relevant for Gforth. bigForth doesn't, and REVEALs into the
CURRENT wordlist during ";".
- 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-10 11:55 -0800 |
| Message-ID | <e7387f26-5bc0-48e6-864d-1bcb473ac761@googlegroups.com> |
| In reply to | #44737 |
On Sunday, January 10, 2016 at 7:48:30 AM UTC-7, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> However, note: > >> > >> |16.3.3 Finding definition names > >> | > >> |[...] An ambiguous condition exists if a program changes the compilation > >> |word list during the compilation of a definition [...] > > > >So, is there any way to do :NAME correctly on a standard system? > > You can implement it correctly, but using it without incurring the > ambiguous condition makes the wid parameter pretty useless if you want > a program without ambiguous conditions. However, one could remove > that ambiguous condition by remembering the CURRENT at the last : and > at the last CREATE and redefining ;, RECURSE, IMMEDIATE and DOES> to > temporarily use that CURRENT. This involves dumping the complexity onto the application programmer. It is totally unnecessary because internally there is a word like :NAME that takes the wid and the string and makes a header --- this is true in every Forth system --- it is just a matter of exposing this to the user (plus do the colon stuff such as setting STATE to TRUE and possibly putting some data on the control-flow stack for semicolon to find). > >I > >can't think of one, because SMUDGE (or UNSMUDGE) might end up > >modifying the wrong header. And this is bound to be true regardless > >of how :NAME is implemented: the only way around it would be to change > >the compler so that it keeps a pointer to the most recent definition > >as well as a pointer to the current wordlist. SMUDGE and UNSMUDGE are not ANS-Forth --- I don't know why they got removed --- they are necessary for cross-compilation. > Keeping a pointer to the most recent definition is a good idea and we > have done this in Gforth since forever. Implementing RECURSE, ;, > IMMEDIATE and DOES> by assuming that the head of the current wordlist > is the last defined word may have been a good idea when there was no > search order and all words had names, but since we now have these > features, it no longer is. Everybody has done this forever --- it is the LATEST variable --- I don't know why ANS-Forth dropped this, as it was common practice. Actually, using the head of the CURRENT wordlist to find the latest definition only works when there is a search-order --- you said "when there was no search order." > The other issue is REVEAL-based systems like bigForth and Gforth. > Gforth stores the CURRENT wordlist during : and uses that for > REVEALing the word in ";" (or RECURSIVE), and so the CURRENT during : > is relevant for Gforth. bigForth doesn't, and REVEALs into the > CURRENT wordlist during ";". I don't know what a REVEAL-based system is --- I don't care --- I don't think the Forth-200x committee have anything worth saying on the subject of Forth. All of this stuff is just soooooo depressing! Everything that was simple and easy in Forth becomes ambiguous in ANS-Forth. We need a new standard that is not based on ANS-Forth --- for a while there will be two standards in use, ANS-Forth and the new one that makes sense --- over time, ANS-Forth will be gradually phased out by everybody except Forth Inc..
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-12 13:26 +0000 |
| Message-ID | <2016Jan12.142659@mips.complang.tuwien.ac.at> |
| In reply to | #44742 |
hughaguilar96@gmail.com writes:
>On Sunday, January 10, 2016 at 7:48:30 AM UTC-7, Anton Ertl wrote:
[...]
>SMUDGE and UNSMUDGE are not ANS-Forth --- I don't know why they got removed=
> --- they are necessary for cross-compilation.
They were not in Forth-79 nor in Forth-83, so they did not get
removed. They were never added.
>> Keeping a pointer to the most recent definition is a good idea and we
>> have done this in Gforth since forever. Implementing RECURSE, ;,
>> IMMEDIATE and DOES> by assuming that the head of the current wordlist
>> is the last defined word may have been a good idea when there was no
>> search order and all words had names, but since we now have these
>> features, it no longer is.
>
>Everybody has done this forever --- it is the LATEST variable --- I don't k=
>now why ANS-Forth dropped this, as it was common practice.
>
>Actually, using the head of the CURRENT wordlist to find the latest definit=
>ion only works when there is a search-order --- you said "when there was no=
> search order."
Even without search order, a classical dictionary implementation has a
pointer to the last defined word. And with only one wordlist around,
it's ok to use that for LATEST.
fig-Forth implemented LATEST as CURRENT @ @, and IMMEDIATE and SMUDGE
by calling LATEST; so fig-Forth was a system where changing CURRENT
between : and : or IMMEDIATE had consequences that the programmer may
not have intended (SMUDGEing or IMMEDIATEing a different word than
intended).
>I don't know what a REVEAL-based system is
In a REVEAL-based system (e.g., F83), ":" creates a header without
putting it in a wordlist, and ";" then puts it in a wordlist by
calling REVEAL which performs that job.
In Gforth, all headers are created by HEADER outside of a wordlist,
and (if named) later put into a wordlist by REVEAL. E.g., the
definition of CREATE is
: Create ( "name" -- ) \ core
Header reveal dovar, ;
- 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 | peter.m.falth@gmail.com |
|---|---|
| Date | 2016-01-12 15:10 -0800 |
| Message-ID | <7c22bb3c-a866-4418-9534-912f59bc500b@googlegroups.com> |
| In reply to | #44781 |
On Tuesday, 12 January 2016 14:50:41 UTC+1, Anton Ertl wrote: > hughaguilar96@gmail.com writes: > >On Sunday, January 10, 2016 at 7:48:30 AM UTC-7, Anton Ertl wrote: > [...] > >SMUDGE and UNSMUDGE are not ANS-Forth --- I don't know why they got removed= > > --- they are necessary for cross-compilation. > > They were not in Forth-79 nor in Forth-83, so they did not get > removed. They were never added. > > >> Keeping a pointer to the most recent definition is a good idea and we > >> have done this in Gforth since forever. Implementing RECURSE, ;, > >> IMMEDIATE and DOES> by assuming that the head of the current wordlist > >> is the last defined word may have been a good idea when there was no > >> search order and all words had names, but since we now have these > >> features, it no longer is. > > > >Everybody has done this forever --- it is the LATEST variable --- I don't k= > >now why ANS-Forth dropped this, as it was common practice. > > > >Actually, using the head of the CURRENT wordlist to find the latest definit= > >ion only works when there is a search-order --- you said "when there was no= > > search order." > > Even without search order, a classical dictionary implementation has a > pointer to the last defined word. And with only one wordlist around, > it's ok to use that for LATEST. > > fig-Forth implemented LATEST as CURRENT @ @, and IMMEDIATE and SMUDGE > by calling LATEST; so fig-Forth was a system where changing CURRENT > between : and : or IMMEDIATE had consequences that the programmer may > not have intended (SMUDGEing or IMMEDIATEing a different word than > intended). > > >I don't know what a REVEAL-based system is > > In a REVEAL-based system (e.g., F83), ":" creates a header without > putting it in a wordlist, and ";" then puts it in a wordlist by > calling REVEAL which performs that job. > > In Gforth, all headers are created by HEADER outside of a wordlist, > and (if named) later put into a wordlist by REVEAL. E.g., the > definition of CREATE is > > : Create ( "name" -- ) \ core > Header reveal dovar, ; > I have REVEAL defined as : REVEAL ( -- ) last @ current @ ! ; Changing the current wordlist during compilation will cause the new word to be added to the changed to wordlist and all other words in that wordlist to be unfindable What do you want to achieve by changing the compilation wordlist during the compilation? BR Peter Fälth > - 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]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web