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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-12 13:23 -1000 |
| Message-ID | <LdydnTtT5sllFwjLnZ2dnUU7-TmdnZ2d@supernews.com> |
| In reply to | #44802 |
On 1/12/16 1:10 PM, peter.m.falth@gmail.com wrote: > 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? In a cross=compiler you sometimes need to switch between cross-compiler words and target words, for one example. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-12 20:42 -0800 |
| Message-ID | <606f9819-0061-4568-bc11-fe72e8494d73@googlegroups.com> |
| In reply to | #44803 |
On Tuesday, January 12, 2016 at 4:23:38 PM UTC-7, Elizabeth D. Rather wrote: > On 1/12/16 1:10 PM, peter.m.falth@gmail.com wrote: > > On Tuesday, 12 January 2016 14:50:41 UTC+1, Anton Ertl wrote: > >> hughaguilar96@gmail.com writes: > >>> 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 This makes sense to me. The new header can't be revealed (put in the search order) until semicolon because the definition may contain references to the old version (these are recursive calls to the new version, but they are calls to the old version). I had not heard of the function called REVEAL --- but that is a pretty good name for what it does --- I was aware of the concept. Now that I think about it, LATEST was defined like this: : LATEST LAST @ ; I had previously described it as being a variable, but that was incorrect --- LAST is the variable and is not accessible to the user --- LATEST provided the value of LAST, but there is no way to for the user to set the value of LAST (that would cause chaos). > > What do you want to achieve by changing the compilation wordlist > > during the compilation? > > In a cross=compiler you sometimes need to switch between cross-compiler > words and target words, for one example. As usual, Elizabeth Rather is incorrect. The cross-compiler is either in HOST mode or TARG mode when the new colon word gets defined. There is no reason why this would be changed by colon (or by semicolon or anything else) --- this is only changed by the directives HOST or TARG and these have to be done outside of any colon word (in interpretive-mode when STATE is FALSE). Most likely Elizabeth Rather is thinking about how the CONTEXT has to be changed by colon and will be changed back again by semicolon --- but she is totally confusing the discussion by mixing up CONTEXT and CURRENT --- she has only a vague idea of how a cross-compiler works. Once again: Shut up, stupid! Anyway, the ANS-Forth Standard is a bug-ridden mess --- section 16.3.3 says: "An ambiguous condition exists if a program changes the compilation word list during the compilation of a definition" --- this is just another one of Elizabeth Rather's many many screw ups. Why does she love the concept of "ambiguous condition" so much? Doesn't every programmer know that ambiguity is bad? Isn't the point of a Standard to eliminate ambiguity? ANS-Forth introduces ambiguity where none existed previously! This is why ANS-Forth failed, and brought down the entire Forth community with it.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-12 21:08 -0800 |
| Message-ID | <bcc07ea0-d9b2-4b39-aa05-46a2572e99ca@googlegroups.com> |
| In reply to | #44813 |
On Tuesday, January 12, 2016 at 9:42:34 PM UTC-7, hughag...@gmail.com wrote: > The new header can't be revealed (put in the search order) until semicolon because the definition may contain references to the old version (these are recursive calls to the new version, but they are calls to the old version). That was a typo --- I meant to say: "these are not recursive calls to the new version, but they are calls to the old version."
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-13 15:17 +0000 |
| Message-ID | <2016Jan13.161724@mips.complang.tuwien.ac.at> |
| In reply to | #44802 |
peter.m.falth@gmail.com writes:
>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
But the new CURRENT then also contains the words of the old CURRENT?
It should be relatively easy to let REVEAL do all of the list-insert
operation, and not just the second half.
>What do you want to achieve by changing the compilation wordlist=20
>during the compilation?
Good point. It's probably something very few people have tried.
That's probably why we have seen Forth implementations that exhibit
various interesting and puzzling behaviours when you do that, and
nobody has complained. And the variety of behaviours in the systems
has resulted in the ambiguous condition in Forth-94, and there was
little discussion about that.
OTOH, looking at the more popular Forth systems around, they behave
pretty sensibly
vocabulary v1 vocabulary v2 also v1 definitions
: foo ." foo" ;
also v2 definitions : bar ." bar" ;
v1 definitions : bla [ v2 definitions ] ." bla" ;
cr .( v1) v1 words
cr .( v2) v2 words
foo
bla
bar
SwiftForth, VFX, and Gforth all put both FOO and BLA in v1, and BAR in
V2, and they are all visible in the end.
iForth-2.1 is curious: according to WORDS, v1 contains FOO, v2
contains BLA and FOO (so I guess it works similar to your system), and
all three words (even BAR, which is not listed by WORDS) are findable
(probably through a hash table).
- 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-13 13:26 -0800 |
| Message-ID | <809d8820-8436-43b0-812b-a56895fd05d0@googlegroups.com> |
| In reply to | #44827 |
On Wednesday, 13 January 2016 16:44:41 UTC+1, Anton Ertl wrote:
> peter.m.falth@gmail.com writes:
> >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
>
> But the new CURRENT then also contains the words of the old CURRENT?
> It should be relatively easy to let REVEAL do all of the list-insert
> operation, and not just the second half.
Yes this should do that
: REVEAL ( -- )
current @ @ last @ cell- ! \ insert old link in header
last @ current @ ! ;
This will also honor a change of current during compilation
bla in your example below will go into v2 instead of v1
To have the same effect as the others I need another global variable
: REVEAL ( -- )
last @ last-current @ ! ;
last-current needs to be initialized at header creating with the active
current at that time
> >What do you want to achieve by changing the compilation wordlist=20
> >during the compilation?
>
> Good point. It's probably something very few people have tried.
> That's probably why we have seen Forth implementations that exhibit
> various interesting and puzzling behaviours when you do that, and
> nobody has complained. And the variety of behaviours in the systems
> has resulted in the ambiguous condition in Forth-94, and there was
> little discussion about that.
>
> OTOH, looking at the more popular Forth systems around, they behave
> pretty sensibly
>
> vocabulary v1 vocabulary v2 also v1 definitions
> : foo ." foo" ;
> also v2 definitions : bar ." bar" ;
> v1 definitions : bla [ v2 definitions ] ." bla" ;
> cr .( v1) v1 words
> cr .( v2) v2 words
> foo
> bla
> bar
>
> SwiftForth, VFX, and Gforth all put both FOO and BLA in v1, and BAR in
> V2, and they are all visible in the end.
>
> iForth-2.1 is curious: according to WORDS, v1 contains FOO, v2
> contains BLA and FOO (so I guess it works similar to your system), and
> all three words (even BAR, which is not listed by WORDS) are findable
> (probably through a hash table).
>
Yes it is the same as I see
If v2 was the forth wordlist it would be made unfindable
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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-04 14:19 -0800 |
| Message-ID | <ab1849ca-3e17-4752-8e06-9a89d59eaa45@googlegroups.com> |
| In reply to | #44483 |
On Thursday, December 31, 2015 at 2:19:30 PM UTC-7, Bernd Paysan wrote:
> EXECUTE-PARSING ( i*x addr u xt -- j*x )
There is a bug in the ANS-Forth standard that the control-flow stack may or may not be the same as the parameter stack. This means that a defining word such as colon may or may not put control-flow data on parameter stack. So, your i*x may or may not be the same as your j*x.
In the novice package whenever I use :NAME I am unable to hold data on the parameter stack because I don't know if :NAME (actually the colon inside of :NAME) is going to put control-flow data on top of my data or not. I have to hold data in local variables. Bernd Paysan is also aware of this problem because I've seen code of his in which he holds his data on the r-stack because control-flow data may or may not get put on top of his data if it were on the parameter stack. Everybody who programs in ANS-Forth has to learn the bugs in ANS-Forth and work around them --- ANS-Forth is full of ambiguities and inconsistencies --- it was submitted to ANSI without having ever been tested.
:NAME as written in ANS-Forth is really some goofy code! It calls colon internally, but colon (in every Forth system I've seen including SwiftForth) calls something very similar to :NAME internally. It would make a lot more sense of :NAME were standardized and then colon were defined in terms of :NAME --- you generally want to standardize the low-level code and then write the high-level code in terms of the low-level code --- this is why I proposed :NAME for Forth-200x way back in 2009.
The problem I see with Forth is that there is too much emphasis on standardization. We have a lot of people with little or no Forth programming experience who want to become big experts, so they go straight into the standardization business. Most if not all of the code in Forth-200x is over-complicated and sloppy. We have Anton Ertl's attempt at defining locals, but his code was no good because it didn't zero out the locals to the right of the | but instead initialized them to whatever happened to be in memory previously. Also, he called his word {: rather than { that has been in common use since the early 1990s. We have Bernd Paysan's fake quotations that fail to provide the quotation with access to the parent function's local variables. We also have this ugly EXECUTE-PARSING written by one or both of them. All of this code is horrible, but it goes straight into the Forth-200x standard because it was written by Forth-200x committee members. So, how does a person become a Forth-200x committee member? Well, Elizabeth Rather appoints the committee members --- Elizabeth Rather is the perpetrator of ANS-Forth though, which is why Forth-200x is mandated to be 100% compatible with ANS-Forth, and why Forth-200x is destined to fail in the same way as ANS-Forth failed.
There is just too much focus on people getting their code into the standard so that they can denounce everybody else as being non-standard. Most of this code (such as EXECUTE-PARSING) has never been used in any application program and it isn't useful. Also, there are a lot of people involved, all wanting their code in Forth-200x so they can claim to be a contributor to Forth-200x --- the result is a huge quantity of crappy code which is supposedly the standard for all Forthers everywhere to follow.
I think a lot of people involved in Forth-200x have a fantasy in which they go to a job interview and describe how they contributed to the standard, and so the interviewers hire them. Well, I have worked as a Forth programmer, and I can tell you that the interviewers won't care about your contribution to Forth-200x, because they won't care about Forth-200x.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-01-05 07:24 +0000 |
| Message-ID | <n6fr2h$8qp$1@dont-email.me> |
| In reply to | #44556 |
hughaguilar96@gmail.com wrote: > There is just too much focus on people > getting their code into the standard so that > they can denounce everybody else as being > non-standard. Most of this code (such as > EXECUTE-PARSING) has never been used in any > application program and it isn't useful. > Also, there are a lot of people involved, > all wanting their code in Forth-200x so they > can claim to be a contributor to Forth-200x > --- the result is a huge quantity of crappy > code which is supposedly the standard for > all Forthers everywhere to follow. +1 -- Amazon bans book. After nearly a month on the site, all traces of the book and its 80 reviews have been removed. http://jamesfetzer.blogspot.com/2015/11/debunking-sandy-hook-debunkers-5.html https://www.youtube.com/watch?v=EEl_1HWFRfo
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2015-12-31 16:24 +0000 |
| Message-ID | <568556a0$0$23822$e4fe514c@news.xs4all.nl> |
| In reply to | #44442 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>"$" 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
Let's see how that would look in ciforth:
WANT POSTFIX \ make next parsing word get the name from stack
WANT -LEADING \ like -TRAILING , removes leading blanks.
: variables ^J PARSE BEGIN -LEADING BL $/ DUP WHILE
POSTFIX VARIABLE REPEAT 2DROP ;
A totally different solution, reminiscent of EXECUTE-PARSING.
: variables ^J PARSE SAVE SET-SRC BEGIN NAME DUP WHILE
POSTFIX VARIABLE REPEAT 2DROP RESTORE ;
( NAME SET-SRC SAVE and RESTORE are kernel words and are
instrumental to regular parsing. Note how no tools are
loaded in this case.)
Funny how the tools that are available change your solutions.
(And I have a different style, I always parse to the end of
line in such cases, instead of inventing another sentinel.)
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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-29 12:31 -1000 |
| Message-ID | <rKGdnXkzJZgulB7LnZ2dnUU7-LGdnZ2d@supernews.com> |
| In reply to | #44409 |
The real issue is whether the heads of definitions are in the same address space as data. VARIABLE A 64 CELLS ALLOT ...will create a data space 65 cells in size, and A returns the address of the first. The data space is contiguous on all systems. However: VARIABLE A CREATE B 64 CELLS ALLOT ... will create two data spaces, a total of 65 cells in size, but B's space *may* be separated from A's by the header created for B (which will return the address of its first cell). Both implementations are perfectly standard; there are rules defining when you can and cannot count on data spaces being contiguous, but they boil down to whether data space and dictionary heads are integrated or segregated. On 12/28/15 9:30 PM, Chris Curl wrote: ... >> >>> VARIABLE tStack 64 CELLS ALLOT >>> : tStack.Reset tStack DUP ! ; This should produce a contiguous space 65 cells in size (one allocated by VARIABLE, the rest added on by ALLOT). tstack will return the address of the first cell. >> I don't think that is safe. Maybe: >> >> VARIABLE tSP >> CREATE tStack 64 CELLS ALLOT >> : T.Reset tStack TSP ! ; The only real difference here is that the data for tStack is not necessarily contiguous with tSP. Whether this matters or not depends on how you're using them. > -- Hmmm ... my implementation may not be ANS compliant here. Actually, > I bet my implementation is not ANS Standard in many areas. > I don't see a compliance issue here. I would have a concern, though, about having only 64 cells available for a data stack, if that is what this is intended. That isn't a compliance issue either, though, just a practical consideration. 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-29 14:52 -0800 |
| Message-ID | <871ta4lvfo.fsf@jester.gateway.pace.com> |
| In reply to | #44415 |
"Elizabeth D. Rather" <erather@forth.com> writes: > VARIABLE A 64 CELLS ALLOT > ...will create a data space 65 cells in size, and A returns the > address of the first. The data space is contiguous on all > systems. Is that guaranteed? It seeme possible to me that some code could be emitted after the first cell, depending on the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-12-30 02:11 +0100 |
| Message-ID | <1p3w2eoyc6g96.1pfwq74dqwbex$.dlg@40tude.net> |
| In reply to | #44417 |
Op Tue, 29 Dec 2015 14:52:11 -0800 schreef Paul Rubin: > "Elizabeth D. Rather" <erather@forth.com> writes: >> VARIABLE A 64 CELLS ALLOT >> ...will create a data space 65 cells in size, and A returns the >> address of the first. The data space is contiguous on all >> systems. > > Is that guaranteed? It seeme possible to me that some code could be > emitted after the first cell, depending on the implementation. I think you are right. VARIABLE reserves 'a cell of data space' while CREATE returns the address of 'the data-space pointer'. So the data in 'VARIABLE V 1 CELLS ALLOT' might create two not contiguous cells, but 'CREATE C 2 CELLS ALLOT' must allocate them against each other. But implementations that handle data space for VARIABLE different from CREATE are fairly unknown, I think. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-29 23:46 -1000 |
| Message-ID | <tbKdnUFL2p2RNR7LnZ2dnUU7-YP46u6z@supernews.com> |
| In reply to | #44426 |
On 12/29/15 3:11 PM, Coos Haak wrote: > Op Tue, 29 Dec 2015 14:52:11 -0800 schreef Paul Rubin: > >> "Elizabeth D. Rather" <erather@forth.com> writes: >>> VARIABLE A 64 CELLS ALLOT >>> ...will create a data space 65 cells in size, and A returns the >>> address of the first. The data space is contiguous on all >>> systems. >> >> Is that guaranteed? It seeme possible to me that some code could be >> emitted after the first cell, depending on the implementation. > > I think you are right. VARIABLE reserves 'a cell of data space' while > CREATE returns the address of 'the data-space pointer'. > So the data in 'VARIABLE V 1 CELLS ALLOT' might create two not > contiguous cells, but 'CREATE C 2 CELLS ALLOT' must allocate them > against each other. But implementations that handle data space for > VARIABLE different from CREATE are fairly unknown, I think. Yikes, you are right. Both ANS and Forth2012 contain this caution: 3.3.3.3 Variables The region allocated for a variable may be non-contiguous with regions subsequently allocated with , (comma) or ALLOT. For example, in: VARIABLE X 1 CELLS ALLOT the region X and the region ALLOTted could be non-contiguous. ------------- I've never encountered (or, indeed, heard of) such a system, but apparently they exist. However, if you write: CREATE tStack 65 CELLS ALLOT that is certainly contiguous, and everything else is fine. 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 | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2015-12-30 21:25 +1100 |
| Message-ID | <n60beo$tfq$1@speranza.aioe.org> |
| In reply to | #44432 |
Elizabeth D. Rather wrote:
> On 12/29/15 3:11 PM, Coos Haak wrote:
> > Op Tue, 29 Dec 2015 14:52:11 -0800 schreef Paul Rubin:
> >
> >> "Elizabeth D. Rather" <erather@forth.com> writes:
> >>> VARIABLE A 64 CELLS ALLOT
> >>> ...will create a data space 65 cells in size, and A returns the
> >>> address of the first. The data space is contiguous on all
> >>> systems.
> >>
> >> Is that guaranteed? It seeme possible to me that some code could be
> >> emitted after the first cell, depending on the implementation.
> >
> > I think you are right. VARIABLE reserves 'a cell of data space' while
> > CREATE returns the address of 'the data-space pointer'.
> > So the data in 'VARIABLE V 1 CELLS ALLOT' might create two not
> > contiguous cells, but 'CREATE C 2 CELLS ALLOT' must allocate them
> > against each other. But implementations that handle data space for
> > VARIABLE different from CREATE are fairly unknown, I think.
>
> Yikes, you are right. Both ANS and Forth2012 contain this caution:
>
> 3.3.3.3 Variables
> The region allocated for a variable may be non-contiguous with regions
> subsequently allocated with , (comma) or ALLOT. For example, in:
>
> VARIABLE X 1 CELLS ALLOT
>
> the region X and the region ALLOTted could be non-contiguous.
>
> -------------
>
> I've never encountered (or, indeed, heard of) such a system, but
> apparently they exist. However, if you write:
>
> CREATE tStack 65 CELLS ALLOT
>
> that is certainly contiguous, and everything else is fine.
>
> Cheers,
> Elizabeth
The full explanation is here.
E.4.1 Definitions
...
Only words defined with CREATE or with other defining words that call
CREATE have data fields. The other defining words in the Standard
(VARIABLE, CONSTANT, :, etc.) might not be implemented with CREATE.
Consequently, a Standard Program must assume that words defined by
VARIABLE, CONSTANT, : , etc., may have no data fields.
VARIABLE <name> n ALLOT was commonly used in FigForth which didn't
have a compatible CREATE.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-30 09:17 -1000 |
| Message-ID | <sIKdnbt4lsRKsBnLnZ2dnUU7-U-dnZ2d@supernews.com> |
| In reply to | #44433 |
On 12/30/15 12:25 AM, HAA wrote: > Elizabeth D. Rather wrote: >> On 12/29/15 3:11 PM, Coos Haak wrote: >>> Op Tue, 29 Dec 2015 14:52:11 -0800 schreef Paul Rubin: >>> >>>> "Elizabeth D. Rather" <erather@forth.com> writes: >>>>> VARIABLE A 64 CELLS ALLOT >>>>> ...will create a data space 65 cells in size, and A returns the >>>>> address of the first. The data space is contiguous on all >>>>> systems. >>>> >>>> Is that guaranteed? It seeme possible to me that some code could be >>>> emitted after the first cell, depending on the implementation. >>> >>> I think you are right. VARIABLE reserves 'a cell of data space' while >>> CREATE returns the address of 'the data-space pointer'. >>> So the data in 'VARIABLE V 1 CELLS ALLOT' might create two not >>> contiguous cells, but 'CREATE C 2 CELLS ALLOT' must allocate them >>> against each other. But implementations that handle data space for >>> VARIABLE different from CREATE are fairly unknown, I think. >> >> Yikes, you are right. Both ANS and Forth2012 contain this caution: >> >> 3.3.3.3 Variables >> The region allocated for a variable may be non-contiguous with regions >> subsequently allocated with , (comma) or ALLOT. For example, in: >> >> VARIABLE X 1 CELLS ALLOT >> >> the region X and the region ALLOTted could be non-contiguous. >> >> ------------- >> >> I've never encountered (or, indeed, heard of) such a system, but >> apparently they exist. However, if you write: >> >> CREATE tStack 65 CELLS ALLOT >> >> that is certainly contiguous, and everything else is fine. >> >> Cheers, >> Elizabeth > > The full explanation is here. > > E.4.1 Definitions > ... > Only words defined with CREATE or with other defining words that call > CREATE have data fields. The other defining words in the Standard > (VARIABLE, CONSTANT, :, etc.) might not be implemented with CREATE. > Consequently, a Standard Program must assume that words defined by > VARIABLE, CONSTANT, : , etc., may have no data fields. > > VARIABLE <name> n ALLOT was commonly used in FigForth which didn't > have a compatible CREATE. I totally understand this with respect to CONSTANT, :, and other words, but I don't remember and have trouble imagining an implementation of VARIABLE that wouldn't simply assign an allocated data space cell to a definition that could potentially be expanded. Most systems I'm familiar with have a definition-creating primitive (FORTH, Inc. systems call it (CREATE) ) used by CREATE and VARIABLE, and often the differences between VARIABLE and CREATE 1 CELLS ALLOT involve things like whether the cell is initialized and in initialized data space in cross-compilers, etc. I wonder if it's time to ask whether that restriction on VARIABLE is still critical in common practice. 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 | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2015-12-31 12:55 +1100 |
| Message-ID | <n621tk$les$1@speranza.aioe.org> |
| In reply to | #44443 |
Elizabeth D. Rather wrote: > ... > I totally understand this with respect to CONSTANT, :, and other words, > but I don't remember and have trouble imagining an implementation of > VARIABLE that wouldn't simply assign an allocated data space cell to a > definition that could potentially be expanded. Most systems I'm familiar > with have a definition-creating primitive (FORTH, Inc. systems call it > (CREATE) ) used by CREATE and VARIABLE, and often the differences > between VARIABLE and CREATE 1 CELLS ALLOT involve things like whether > the cell is initialized and in initialized data space in > cross-compilers, etc. I wonder if it's time to ask whether that > restriction on VARIABLE is still critical in common practice. Under what circumstances would you want to extend a VARIABLEs data space? Why isn't CREATE suitable? CREATE is required since Forth-79 so everyone has it.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-12-30 16:26 -1000 |
| Message-ID | <MMadnfUBg5DsDxnLnZ2dnUU7-QGdnZ2d@supernews.com> |
| In reply to | #44454 |
On 12/30/15 3:55 PM, HAA wrote: > Elizabeth D. Rather wrote: >> ... >> I totally understand this with respect to CONSTANT, :, and other words, >> but I don't remember and have trouble imagining an implementation of >> VARIABLE that wouldn't simply assign an allocated data space cell to a >> definition that could potentially be expanded. Most systems I'm familiar >> with have a definition-creating primitive (FORTH, Inc. systems call it >> (CREATE) ) used by CREATE and VARIABLE, and often the differences >> between VARIABLE and CREATE 1 CELLS ALLOT involve things like whether >> the cell is initialized and in initialized data space in >> cross-compilers, etc. I wonder if it's time to ask whether that >> restriction on VARIABLE is still critical in common practice. > > Under what circumstances would you want to extend a VARIABLEs > data space? Why isn't CREATE suitable? CREATE is required since > Forth-79 so everyone has it. Personally, I don't use VARIABLE that way, but some people do. Mostly, I was trying to clarify what these various words do and how they relate to each other. As Forth has evolved, the major differences between VARIABLE and CREATE (and CREATE's children) involve what data space they use: uninitialized RAM, initialized RAM, Flash, or ROM, for example. CREATE's data may go in any of these, and systems designed for such use have ways to specify (such as those described in the Cross Compiler Proposal), but VARIABLE's payload must go in initialized or uninitialized RAM. 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 | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-01-02 12:30 +1100 |
| Message-ID | <n6796m$m8v$1@speranza.aioe.org> |
| In reply to | #44455 |
Elizabeth D. Rather wrote: > On 12/30/15 3:55 PM, HAA wrote: > > Elizabeth D. Rather wrote: > >> ... > >> I totally understand this with respect to CONSTANT, :, and other words, > >> but I don't remember and have trouble imagining an implementation of > >> VARIABLE that wouldn't simply assign an allocated data space cell to a > >> definition that could potentially be expanded. Most systems I'm familiar > >> with have a definition-creating primitive (FORTH, Inc. systems call it > >> (CREATE) ) used by CREATE and VARIABLE, and often the differences > >> between VARIABLE and CREATE 1 CELLS ALLOT involve things like whether > >> the cell is initialized and in initialized data space in > >> cross-compilers, etc. I wonder if it's time to ask whether that > >> restriction on VARIABLE is still critical in common practice. > > > > Under what circumstances would you want to extend a VARIABLEs > > data space? Why isn't CREATE suitable? CREATE is required since > > Forth-79 so everyone has it. > > Personally, I don't use VARIABLE that way, but some people do. < ... Exactly how many variants of CREATE does Forth need? We've seen the incredibly trite BUFFER: make it past Forth's goalkeepers and now the bizarre VARIABLE ... n ALLOT is making a comeback from the dead. There was a time when Forth standards were about throwing out the trash and keeping the essentials. How things have changed.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-01 16:31 -1000 |
| Message-ID | <ypqdnQP0SaPsqxrLnZ2dnUU7-b_46u6z@supernews.com> |
| In reply to | #44516 |
On 1/1/16 3:30 PM, HAA wrote: > Elizabeth D. Rather wrote: >> On 12/30/15 3:55 PM, HAA wrote: >>> Elizabeth D. Rather wrote: >>>> ... >>>> I totally understand this with respect to CONSTANT, :, and other words, >>>> but I don't remember and have trouble imagining an implementation of >>>> VARIABLE that wouldn't simply assign an allocated data space cell to a >>>> definition that could potentially be expanded. Most systems I'm familiar >>>> with have a definition-creating primitive (FORTH, Inc. systems call it >>>> (CREATE) ) used by CREATE and VARIABLE, and often the differences >>>> between VARIABLE and CREATE 1 CELLS ALLOT involve things like whether >>>> the cell is initialized and in initialized data space in >>>> cross-compilers, etc. I wonder if it's time to ask whether that >>>> restriction on VARIABLE is still critical in common practice. >>> >>> Under what circumstances would you want to extend a VARIABLEs >>> data space? Why isn't CREATE suitable? CREATE is required since >>> Forth-79 so everyone has it. >> >> Personally, I don't use VARIABLE that way, but some people do. > < ... > > Exactly how many variants of CREATE does Forth need? We've seen the > incredibly trite BUFFER: make it past Forth's goalkeepers and now the > bizarre VARIABLE ... n ALLOT is making a comeback from the dead. > There was a time when Forth standards were about throwing out the trash > and keeping the essentials. How things have changed. Yeah, BUFFER: is trivial. But we keep hearing "Forth has no way to make an array." VARIABLE ... n ALLOT was the common practice way to make arrays in the 70's. After CREATE replaced <BUILDS, that became the preferred usage, but there are old timers still around. The major reason to remove the restriction on VARIABLE would be if, in fact, no common practice can be found that requires the restriction, then it's simply unnecessary. Unnecessary restrictions are always a bad thing. 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 | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-01 21:31 -0800 |
| Message-ID | <575d2a0d-9d03-4ad1-8735-56b1fa15995d@googlegroups.com> |
| In reply to | #44516 |
On Friday, January 1, 2016 at 8:30:02 PM UTC-5, HAA wrote: > ... and now the bizarre VARIABLE ... n ALLOT is making a comeback > from the dead. There was a time when Forth standards were about > throwing out the trash and keeping the essentials. How things > have changed. Wow. I simply posted my simple/stupid little example of an additional stack that I have found useful, that happened to use VARIABLE tStack 64 ALLOT, because that happened to be work with how I chose to implement my own personal Forth, and things have evolved into a firestorm. Then people pointed out that my approach might not work on some other Forths out there, so I changed it to something more likely to be more compatible with other Forths in existence. No big deal. Clearly, some of the folks here are passionate about this stuff, and I guess I inadvertently opened up an old wound.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-01-02 12:04 +0000 |
| Message-ID | <5687bc8a.1442472791@news.eternal-september.org> |
| In reply to | #44516 |
On Sat, 2 Jan 2016 12:30:13 +1100, "HAA" <someone@microsoft.com> wrote: >Exactly how many variants of CREATE does Forth need? We've seen the >incredibly trite BUFFER: make it past Forth's goalkeepers and now the >bizarre VARIABLE ... n ALLOT is making a comeback from the dead. >There was a time when Forth standards were about throwing out the trash >and keeping the essentials. How things have changed. BUFFER: was introduced for embedded systems in which it claims space in uninitialised RAM. 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]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web