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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-28 23:30 -0800 |
| Message-ID | <a13f091f-2cb8-4fbe-a7b2-a379691e6ed0@googlegroups.com> |
| In reply to | #44408 |
On Tuesday, December 29, 2015 at 1:31:38 AM UTC-5, Paul Rubin wrote: > Chris Curl <cc..@gmail.com> writes: > > 0 CELL+ CONSTANT CELL > > 1 CELLS CONSTANT CELL -- Thing is ... in my implementation, CELL+ is a primitive, CELLS is not. > > > VARIABLE tStack 64 CELLS ALLOT > > : tStack.Reset tStack DUP ! ; > > I don't think that is safe. Maybe: > > VARIABLE tSP > CREATE tStack 64 CELLS ALLOT > : T.Reset tStack TSP ! ; -- Hmmm ... my implementation may not be ANS compliant here. Actually, I bet my implementation is not ANS Standard in many areas.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-12-29 02:47 -0800 |
| Message-ID | <22d7fab0-ef77-45d2-9f19-ef5a9f3d109e@googlegroups.com> |
| In reply to | #44409 |
marți, 29 decembrie 2015, 09:30:36 UTC+2, Chris Curl a scris: > On Tuesday, December 29, 2015 at 1:31:38 AM UTC-5, Paul Rubin wrote: > > Chris Curl <cc..@gmail.com> writes: > > > 0 CELL+ CONSTANT CELL > > > > 1 CELLS CONSTANT CELL > -- Thing is ... in my implementation, CELL+ is a primitive, CELLS is not. > > > > > > VARIABLE tStack 64 CELLS ALLOT > > > : tStack.Reset tStack DUP ! ; > > > > I don't think that is safe. Maybe: > > > > VARIABLE tSP > > CREATE tStack 64 CELLS ALLOT > > : T.Reset tStack TSP ! ; > -- Hmmm ... my implementation may not be ANS compliant here. Actually, > I bet my implementation is not ANS Standard in many areas. Some systems allow this. The problem is that in many other systems it just doesn't work. The area allot-ed is not exactly after the variable's cell. One other thing which is not obvious is what exact space you got, in your example is it 64 cells or 65? My advice is to implement CREATE as the "primitive" and the VARIABLE in terms of CREATE: : VARIABLE ( <name> -- ) CREATE 1 CELLS ALLOT ;
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-29 08:19 -0800 |
| Message-ID | <64c010c2-9c26-4ac8-9d94-0dd1243d1455@googlegroups.com> |
| In reply to | #44410 |
My VARIABLE allocates one cell and pushes that address at runtime. An ALLOT immediately after that allocates that number of bytes. So in my implementation, the code results in 65 adjacent cells, and tStack pushes the address of the first cell onto the stack.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-12-29 08:26 -0800 |
| Message-ID | <6d080be2-298b-401e-88d7-bb6e8f39babd@googlegroups.com> |
| In reply to | #44411 |
marți, 29 decembrie 2015, 18:19:11 UTC+2, Chris Curl a scris: > My VARIABLE allocates one cell and pushes that address at runtime. > > An ALLOT immediately after that allocates that number of bytes. > > So in my implementation, the code results in 65 adjacent cells, > and tStack pushes the address of the first cell onto the stack. And do you have a CREATE word? I've seen forths like yours, without a CREATE. The only "drawback" is that if you want exactly N bytes ... you have to calculate by hand. Especially for bytes. For example if you want a buffer of exactly 128 bytes you have to do: VARIABLE myBuffer 124 allot ( I suppose your variable is a 32bit one)
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-29 09:34 -0800 |
| Message-ID | <f4249693-547c-442a-a286-a7e93854cc53@googlegroups.com> |
| In reply to | #44412 |
On Tuesday, December 29, 2015 at 11:26:40 AM UTC-5, Raimond Dragomir wrote: > marți, 29 decembrie 2015, 18:19:11 UTC+2, Chris Curl a scris: > > My VARIABLE allocates one cell and pushes that address at runtime. > > > > An ALLOT immediately after that allocates that number of bytes. > > > > So in my implementation, the code results in 65 adjacent cells, > > and tStack pushes the address of the first cell onto the stack. > > And do you have a CREATE word? > I've seen forths like yours, without a CREATE. The only "drawback" is that > if you want exactly N bytes ... you have to calculate by hand. Especially > for bytes. For example if you want a buffer of exactly 128 bytes you have > to do: > VARIABLE myBuffer 124 allot ( I suppose your variable is a 32bit one) Well, yes and no ... I have a word "create-empty" which creates an entry in the dictionary that refers to the current HERE as address where the runtime implementation is located. So VARIABLE calls create-empty and then generates code (this is a p-code implementation) to push an address (essentially HERE + 5) on the stack, followed by an empty cell for the value: : VARIABLE word create.empty I_LITERAL C, HERE 0 , I_RETURN C, HERE SWAP ! 0 , ; Perhaps I should define a word "CREATE" that does the same thing without allocating the cell: : CREATE word create.empty I_LITERAL C, HERE 0 , I_RETURN C, HERE SWAP ! ; Then VARIABLE could be: : VARIABLE CREATE 0 , ;
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-12-29 10:22 -0800 |
| Message-ID | <21fb4d45-2fa2-47fc-9b5d-4dde185a7569@googlegroups.com> |
| In reply to | #44413 |
marți, 29 decembrie 2015, 19:34:52 UTC+2, Chris Curl a scris: > On Tuesday, December 29, 2015 at 11:26:40 AM UTC-5, Raimond Dragomir wrote: > > marți, 29 decembrie 2015, 18:19:11 UTC+2, Chris Curl a scris: > > > My VARIABLE allocates one cell and pushes that address at runtime. > > > > > > An ALLOT immediately after that allocates that number of bytes. > > > > > > So in my implementation, the code results in 65 adjacent cells, > > > and tStack pushes the address of the first cell onto the stack. > > > > And do you have a CREATE word? > > I've seen forths like yours, without a CREATE. The only "drawback" is that > > if you want exactly N bytes ... you have to calculate by hand. Especially > > for bytes. For example if you want a buffer of exactly 128 bytes you have > > to do: > > VARIABLE myBuffer 124 allot ( I suppose your variable is a 32bit one) > Well, yes and no ... I have a word "create-empty" which creates an entry > in the dictionary that refers to the current HERE as address where the > runtime implementation is located. > > So VARIABLE calls create-empty and then generates code (this is a p-code > implementation) to push an address (essentially HERE + 5) on the stack, > followed by an empty cell for the value: > > : VARIABLE word create.empty I_LITERAL C, HERE 0 , I_RETURN C, HERE SWAP ! 0 , ; > > Perhaps I should define a word "CREATE" that does the same thing without > allocating the cell: > > : CREATE word create.empty I_LITERAL C, HERE 0 , I_RETURN C, HERE SWAP ! ; > > Then VARIABLE could be: > > : VARIABLE CREATE 0 , ; You are implementing your forth in the most traditional way: "all code". Everything is code, it is executed. To have data in such a system you need code that when executed it will leave the data address on the stack. A modern way is "all data". Everything is an address. The address is left on the stack by the interpreter. Then the address is further processed according to it's class (you store a "class" number in dictionary along with the address). Usual classes are: (with the code associated) code : EXECUTE data : nothing (the address is left on the stack as is) constant : @ etc.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-12-30 12:15 +0000 |
| Message-ID | <5683caf3$0$23766$e4fe514c@news.xs4all.nl> |
| In reply to | #44410 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes: >mar=C8=9Bi, 29 decembrie 2015, 09:30:36 UTC+2, Chris Curl a scris: >> On Tuesday, December 29, 2015 at 1:31:38 AM UTC-5, Paul Rubin wrote: >> > Chris Curl <cc..@gmail.com> writes: >> > > 0 CELL+ CONSTANT CELL >> >=20 >> > 1 CELLS CONSTANT CELL >> -- Thing is ... in my implementation, CELL+ is a primitive, CELLS is not. >>=20 >> >=20 >> > > VARIABLE tStack 64 CELLS ALLOT >> > > : tStack.Reset tStack DUP ! ; >> >=20 >> > I don't think that is safe. Maybe: >> >=20 >> > VARIABLE tSP >> > CREATE tStack 64 CELLS ALLOT >> > : T.Reset tStack TSP ! ; >> -- Hmmm ... my implementation may not be ANS compliant here. Actually, >> I bet my implementation is not ANS Standard in many areas. >Some systems allow this. The problem is that in many other systems it just >doesn't work. The area allot-ed is not exactly after the variable's cell. >One other thing which is not obvious is what exact space you got, in your >example is it 64 cells or 65? >My advice is to implement CREATE as the "primitive" and the VARIABLE in=20 >terms of CREATE: >: VARIABLE ( <name> -- ) CREATE 1 CELLS ALLOT ; I think this is upside down. I have very few primitives in my Forth that are not useful outside of the kernel. Here is an example of why. My reasoning is that VARIABLE is more primitive as create, maybe more. It makes sense to have an entitlement to the behaviour of variable to alllow : ARRAY VARIABLE 1- CELLS ALLOT ; The underlying behaviour is even more primitive. So I introduced DATA which is basically (in terms of the old VARIABLE). : DATA VARIABLE -1 CELLS ALLOT ; But I go (of course) : VARIABLE DATA 1 CELLS ALLOT ; Now data structures like bags use DATA, which eliminates the overhead of CREATE and has no portability issues. If you miss it, you can always do 'CREATE ALIAS DATA . 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 | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2015-12-30 08:26 -0800 |
| Message-ID | <46c1edd4-b2ca-4bc8-a791-3a2f9806348b@googlegroups.com> |
| In reply to | #44436 |
On Wednesday, December 30, 2015 at 7:16:12 AM UTC-5, Albert van der Horst wrote: > ... > Now data structures like bags use DATA, which eliminates the > overhead of CREATE and has no portability issues. If you miss it, > you can always do 'CREATE ALIAS DATA . > How much overhead is there in CREATE, and what is that is the overhead?
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-12-31 16:10 +0000 |
| Message-ID | <56855361$0$23822$e4fe514c@news.xs4all.nl> |
| In reply to | #44438 |
Chris Curl <ccurl609@gmail.com> writes: >On Wednesday, December 30, 2015 at 7:16:12 AM UTC-5, Albert van der Horst wrote: >> ... >> Now data structures like bags use DATA, which eliminates the >> overhead of CREATE and has no portability issues. If you miss it, >> you can always do 'CREATE ALIAS DATA . >> >How much overhead is there in CREATE, and what is that is the >overhead? The obligatory DOES> pointer that is a data item. This becomes particularly annoying in REALLOT. REALLOT changes the data pointer to HERE and allows then to create a data structure there. This is useful in turnkey programs and I use it all the time. You don't want 10^9 worth of cells saved in an executable. So the overhead is mentally, as in debugging headaches around where the DOES> pointer goes nowm and how to fill it. I don't care much about speed. 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 | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-12-30 08:35 -0800 |
| Message-ID | <621454e6-3eb8-4fe2-aaf9-d5330bdc4144@googlegroups.com> |
| In reply to | #44436 |
> Now data structures like bags use DATA, which eliminates the
> overhead of CREATE and has no portability issues. If you miss it,
> you can always do 'CREATE ALIAS DATA .
>
> 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
I also have `data` (in ram space) and `const` (in rom space). In fact, my
LFTforth is structured with "$" primitives which get the name on the stack.
My primitives are:
$data \ adr len --
Makes a RAM data dictionary entry (data space).
$const \ adr len --
Makes a ROM data dictionary entry (code space).
Based on the above two primitves there are the other ones:
: data bl parse $data ;
: const bl parse $const ;
: allot here +! ;
: var data allot ;
: variable cell var ;
: cvariable 1 var ;
Examples:
const table 1 c, 2 c, 3 c, \ table in rom
128 var rxbuf \ 128 bytes buffer
variable x
cvariable cx
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-12-30 08:51 -0800 |
| Message-ID | <ccf979af-af3d-4ff2-81ac-3b4be9d43a61@googlegroups.com> |
| In reply to | #44440 |
"$" words are sometimes usefull, that's why I exposed them.
For example I have:
: variables
begin
bl parse \ adr len
dup 1 = if
over c@ ';' = if 2drop exit then
then
$data cell allot
again ;
This lets me write:
variables a b c d ;
Instead of:
variable a variable b variable c variable d
:D
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-12-30 12:21 -0800 |
| Message-ID | <87poxny9g3.fsf@jester.gateway.pace.com> |
| In reply to | #44442 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-30 10:46 -1000 |
| Message-ID | <B8SdnRCeAbYs3xnLnZ2dnUU7-cGdnZ2d@supernews.com> |
| In reply to | #44445 |
On 12/30/15 10:21 AM, 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. > Not sure exactly what you mean by "$" words, but low-level helper words are entirely dependent on implementation strategy, which the standards explicitly avoid, and string words are much dependent on the application needs. Many are utterly irrelevant in a lot of applications (e.g. microprocessor control apps) and for string-intensive applications programmers have their favorite approaches, which differ. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-12-30 13:15 -0800 |
| Message-ID | <87lh8by6wz.fsf@jester.gateway.pace.com> |
| In reply to | #44446 |
"Elizabeth D. Rather" <erather@forth.com> writes:
> Not sure exactly what you mean by "$" words, but low-level helper
> words are entirely dependent on implementation strategy, which the
> standards explicitly avoid,
Raimond's $DATA is basically a non-parsing version of CREATE.
So saying
s" FOO" $DATA
does the same as saying CREATE FOO . In fact CREATE is defined as
: CREATE BL PARSE $DATA ;
That seems very natural. Of course CREATE shouldn't be required to
use $DATA but something like $DATA should be available.
The standard makes sure to provide enough words to implement itself
except for a few very low level primitives. But it doesn't specify any
way to make an arbitrary dictionary entry. That seems like a bug. I
vaguely remember reading there was some discussion in the Forth-2012
group about how to do it, but it got mired in bikeshedding. Maybe one
of the participants could say more.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-30 13:11 -1000 |
| Message-ID | <zZ-dnRSYc7gO-RnLnZ2dnUU7-RGdnZ2d@supernews.com> |
| In reply to | #44447 |
On 12/30/15 11:15 AM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Not sure exactly what you mean by "$" words, but low-level helper >> words are entirely dependent on implementation strategy, which the >> standards explicitly avoid, > > Raimond's $DATA is basically a non-parsing version of CREATE. > So saying > s" FOO" $DATA > does the same as saying CREATE FOO . In fact CREATE is defined as > : CREATE BL PARSE $DATA ; > That seems very natural. Of course CREATE shouldn't be required to > use $DATA but something like $DATA should be available. > > The standard makes sure to provide enough words to implement itself > except for a few very low level primitives. But it doesn't specify any > way to make an arbitrary dictionary entry. That seems like a bug. I > vaguely remember reading there was some discussion in the Forth-2012 > group about how to do it, but it got mired in bikeshedding. Maybe one > of the participants could say more. AFAIK there has never been an intent to make it possible to write an implementation in Standard Forth. The objective has always been to standardize the interface between a system and an application. As soon as you start talking about a "standard way to make an arbitrary dictionary entry" you open a huge can of worms about exactly what needs to be incorporated in that dictionary entry, where it is, etc. None of these issues are really germane to using Forth to write applications, which its purpose. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-12-30 15:35 -0800 |
| Message-ID | <87h9izy0fv.fsf@jester.gateway.pace.com> |
| In reply to | #44449 |
"Elizabeth D. Rather" <erather@forth.com> writes: > as you start talking about a "standard way to make an arbitrary > dictionary entry" you open a huge can of worms about exactly what > needs to be incorporated in that dictionary entry, where it is, etc. I don't see how that can be, since otherwise CREATE would open the exact same can of worms. The idea is to just have a word like : $DATA ( addr u -- ) ... ; which takes a string as arg, and does the same thing as CREATE would do in parsing that string. Or gforth's NEXTWORD which pushes the word back onto the input stream (or equivalent). > None of these issues are really germane to using Forth to write > applications, which its purpose. IMO it's a useful word that I've wanted a few times. Look at Chris Curl's example of creating an auxiliary T stack. It would be nice to generalize that to something like : NEWSTACK ( "name" size ) ... ; so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T, and automatically create the words >T T> T@ and T.RESET that did the obvious things. I don't see any standard way to do that.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-30 15:00 -1000 |
| Message-ID | <HZWdnUO6u5Ch4xnLnZ2dnUU7-Yf46u6z@supernews.com> |
| In reply to | #44451 |
On 12/30/15 1:35 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> as you start talking about a "standard way to make an arbitrary >> dictionary entry" you open a huge can of worms about exactly what >> needs to be incorporated in that dictionary entry, where it is, etc. > > I don't see how that can be, since otherwise CREATE would open the > exact same can of worms. The idea is to just have a word like > > : $DATA ( addr u -- ) ... ; > > which takes a string as arg, and does the same thing as CREATE would > do in parsing that string. Or gforth's NEXTWORD which pushes the > word back onto the input stream (or equivalent). > >> None of these issues are really germane to using Forth to write >> applications, which its purpose. > > IMO it's a useful word that I've wanted a few times. Look at Chris > Curl's example of creating an auxiliary T stack. It would be nice to > generalize that to something like > > : NEWSTACK ( "name" size ) ... ; > > so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T, > and automatically create the words >T T> T@ and T.RESET that did the > obvious things. I don't see any standard way to do that. > Most implementers have their own sets of low-level tools, and their own approaches to internal design. Discussing them in a forum like this can be interesting and sometimes productive, but in 40 years of Forth application development they haven't been considered necessary tools that application developers need guaranteed access to, hence no great drive to standardize them. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-12-31 00:13 -0800 |
| Message-ID | <32bcab0c-f63a-418b-b3f7-6a5fbae5cfb5@googlegroups.com> |
| In reply to | #44451 |
> IMO it's a useful word that I've wanted a few times. Look at Chris
> Curl's example of creating an auxiliary T stack. It would be nice to
> generalize that to something like
>
> : NEWSTACK ( "name" size ) ... ;
>
> so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T,
> and automatically create the words >T T> T@ and T.RESET that did the
> obvious things. I don't see any standard way to do that.
Here is how a stack can be implemented in my LFTforth:
\ usage: 256 st:new S
: st:new \ <name> size --
| 0 name len ptr | \ local variables to store the original <name>
\ and pointer to the allocated area
bl parse to len to name \ original <name>
here @ to ptr \ ptr points to our memory area
name len $data \ <name> is just as any other var
cells cell+ allot \ allocate one cell more for the stack pointer
ptr cell+ ptr ! \ init the stack
\ name:reset will re-initialize the stack
[ @ cell+ dup cell- ! ] name len s" :reset" strcat $build
ptr ,
\ >name ( x -- )
[ @ tuck @ ! cell swap +! ] s" >________________" drop 1 name len strcat $build
ptr ,
\ name> ( -- x )
[ @ dup cell negate swap +! @ @ ] name len s" >" strcat $build
ptr ,
\ name@ ( -- x ) only for the top of our stack
[ @ @ cell- @ ] name len s" @" strcat $build
ptr ,
\ name! ( x -- ) only for the top of our stack
[ @ @ cell- ! ] name len s" !" strcat $build
ptr ,
;
This is exactly like you want.
It makes full use of another $ word, `$build`, which is my way instead
of CREATE DOES>. It takes a quotation for the DOES> part.
Of course, I have a regular `build` which is just
: build bl parse $build ;
It is intended for simpler things like:
: constant [ @ ] $build , ;
And some tests:
stacktest.f
hex
16 st:new S
S . cr
S 16 cells cell+ dump
0x12345678 >S
S@ .
0x55 S!
S> .
cr
8 st:new r
r . cr
r 8 cells cell+ dump
1 >r 2 >r 3 >r
r@ . r> . r@ . 100 r! r> .
include stacktest.f
60EE24
0060EE24 28 EE 60 00 00 00 00 00 00 00 00 00 00 00 00 00 (.`.............
0060EE34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060EE44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060EE54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060EE64 00 00 00 00 ....
12345678 55
60EE68
0060EE68 6C EE 60 00 00 00 00 00 00 00 00 00 00 00 00 00 l.`.............
0060EE78 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060EE88 00 00 00 00 ....
3 3 2 64 done
ok
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-12-31 10:09 +0000 |
| Message-ID | <n62un1$aav$1@dont-email.me> |
| In reply to | #44451 |
On 30/12/2015 23:35, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> as you start talking about a "standard way to make an arbitrary
>> dictionary entry" you open a huge can of worms about exactly what
>> needs to be incorporated in that dictionary entry, where it is, etc.
>
> I don't see how that can be, since otherwise CREATE would open the
> exact same can of worms. The idea is to just have a word like
>
> : $DATA ( addr u -- ) ... ;
>
> which takes a string as arg, and does the same thing as CREATE would
> do in parsing that string. Or gforth's NEXTWORD which pushes the
> word back onto the input stream (or equivalent).
>
>> None of these issues are really germane to using Forth to write
>> applications, which its purpose.
>
> IMO it's a useful word that I've wanted a few times. Look at Chris
> Curl's example of creating an auxiliary T stack. It would be nice to
> generalize that to something like
>
> : NEWSTACK ( "name" size ) ... ;
>
> so that "20 NEWSTACK T" would allocate 20 cells for a new stack named T,
> and automatically create the words >T T> T@ and T.RESET that did the
> obvious things. I don't see any standard way to do that.
>
I too have often wanted such a word and it can be done in standard ANS &
Forth 2012
1. using GForth's EXECUTE-PARSING which is defined using standard Forth e.g.
: $create ( caddr u -- ) ['] create execute-parsing ;
s" foo" $create
2. or use Forth 2012 SUBSTITUTE and REPLACES e.g.
create buf 100 allot
: $create ( caddr u -- )
s" name" replaces
s" create %name%" buf 100 substitute
1 <> abort" Failed"
evaluate \ See note below
;
s" foo" $create
This could be generalised so that the substitution string is:
s" %definer% %name$" substitute
and define a word called
$define (caddr1 u1 caddr2 u2 -- )
when $create would be
: $create s" create" $define ;
I'll leave definition of $define as an exercise for you.
Note: Anton won't like this as the right CREATE might not be executed by
EVALUATE.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-12-31 13:46 +0000 |
| Message-ID | <2015Dec31.144643@mips.complang.tuwien.ac.at> |
| In reply to | #44461 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>I too have often wanted such a word and it can be done in standard ANS &
>Forth 2012
>
>1. using GForth's EXECUTE-PARSING which is defined using standard Forth e.g.
> : $create ( caddr u -- ) ['] create execute-parsing ;
> s" foo" $create
>
>2. or use Forth 2012 SUBSTITUTE and REPLACES e.g.
> create buf 100 allot
> : $create ( caddr u -- )
> s" name" replaces
> s" create %name%" buf 100 substitute
> 1 <> abort" Failed"
> evaluate \ See note below
> ;
> s" foo" $create
The second variant uses SUBSTITUTE basically as glorified string
concatenation (and is pretty cumbersome for that), and uses EVALUATE
for getting the defining word to execute, and therefore has the same
problem as EVALUATE-based macros (as you noted further down): It
requires that the right CREATE must be in the search order and first
in the search order. You can then use the trick that I used in the
standard implementation of EXECUTE-PARSING to avoid that.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web