Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #7847 > unrolled thread
| Started by | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| First post | 2011-12-09 02:42 +0000 |
| Last post | 2011-12-11 10:50 +0000 |
| Articles | 20 on this page of 114 — 13 participants |
Back to article view | Back to comp.lang.forth
LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-09 02:42 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-09 03:43 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-09 13:12 +0000
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-09 13:26 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-09 12:41 -0600
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:24 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 12:04 -0600
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 11:02 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-11 12:21 -0600
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 17:35 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-13 05:19 -0600
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-13 15:12 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-13 11:55 -0600
Re: LatestXT Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-12-15 16:30 -0800
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:11 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-16 16:15 -0800
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-17 03:22 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-17 15:34 +0000
Re: LatestXT Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-12-17 08:04 -0800
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-17 17:20 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-17 12:38 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-18 04:01 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-17 22:06 -0800
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-18 11:47 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-18 08:51 -0800
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-19 01:14 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-18 18:59 -0800
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-18 04:40 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-18 11:31 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-18 06:21 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-18 12:55 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-19 03:27 -0600
Re: LatestXT Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-12-18 07:21 -0800
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-19 01:02 +0000
Re: LatestXT Krishna Myneni <krishna.myneni@ccreweb.org> - 2011-12-18 17:32 -0800
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-17 09:43 -0800
Re: LatestXT Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-19 20:40 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-17 09:38 -0800
Re: LatestXT Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-18 01:08 -0800
Re: LatestXT Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-18 01:38 -0800
Re: LatestXT Coos Haak <chforth@hccnet.nl> - 2011-12-18 13:13 +0100
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-18 08:55 -0800
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-09 09:36 -1000
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-10 03:24 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-09 20:12 -0800
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-09 18:15 -1000
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-10 10:18 +0000
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 11:39 +0000
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-10 16:31 +0000
Re: LatestXT Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-10 23:03 +0100
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-11 02:34 +0000
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-10 18:01 -1000
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-11 09:46 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-11 03:55 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-11 11:35 +0000
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 10:59 -1000
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 02:19 +0000
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 17:38 -1000
Re: LatestXT Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-12 13:22 +0100
Re: LatestXT stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-12 10:34 +0000
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 12:32 +0000
Re: LatestXT stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-12 14:55 +0000
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 16:18 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-12 09:09 -0800
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 17:51 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 12:03 -0600
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-12 10:51 -0800
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-13 12:16 +0000
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-13 15:11 +0000
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-13 08:00 -1000
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 18:18 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-11 13:26 -0800
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 03:51 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 11:14 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 05:37 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 12:54 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-11 11:05 -0800
Re: LatestXT Josh Grams <josh@qualdan.com> - 2011-12-11 23:25 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-11 16:58 -0800
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 17:21 +0000
Re: LatestXT Josh Grams <josh@qualdan.com> - 2011-12-12 21:50 +0000
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-13 16:44 +0000
Re: LatestXT Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-13 22:13 +0000
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-13 11:46 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-13 04:28 -0800
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-14 05:40 +0000
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-13 21:24 -1000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 04:05 -0600
Re: LatestXT Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-20 03:48 -0800
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-20 08:59 -0600
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-12 03:21 +0000
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 17:52 -1000
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 12:41 +0000
Re: LatestXT Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-12 15:00 +0100
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-12 09:37 -0800
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:43 +0000
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:21 +0000
Re: LatestXT Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-12 12:58 +0100
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-11 03:35 -0600
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:47 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 03:54 -0600
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-12 17:20 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-12 11:53 -0600
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-10 14:21 -0800
Re: LatestXT Arnold Doray <thinksquared@gmail.com> - 2011-12-11 02:37 +0000
Re: LatestXT BruceMcF <agila61@netscape.net> - 2011-12-11 11:13 -0800
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 11:25 +0000
Re: LatestXT "Elizabeth D. Rather" <erather@forth.com> - 2011-12-11 08:55 -1000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 02:49 -0600
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:06 +0000
Re: LatestXT Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 12:11 -0600
Re: LatestXT Josh Grams <josh@qualdan.com> - 2011-12-10 12:33 +0000
Re: LatestXT Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-10 18:52 +0000
Re: LatestXT anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 10:50 +0000
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2011-12-18 13:13 +0100 |
| Message-ID | <2zw1m0cl92aj$.1r8ebxxul1ped$.dlg@40tude.net> |
| In reply to | #8182 |
Op Sun, 18 Dec 2011 01:38:45 -0800 (PST) schreef Mark Wills: <snip> > I think the above would work on my own forth system, but one would > need a different terminator to ; since ; modifies the dictionary entry > (un-smudge) which of course isn't present. So... (very basic)... > >: ;; [ ; immediate > > Test: ... ... ... ;; > > Hopefully I'm on the right track with that... > > Mark Let :NONAME set a flag. Let ; test it and when set, do not modify the flag in a non-existing header. Reset the flag. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-18 08:55 -0800 |
| Message-ID | <53069d20-71ec-4430-ba9f-7367fb784269@p16g2000yqd.googlegroups.com> |
| In reply to | #8181 |
On Dec 18, 4:08 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote: > On Dec 17, 5:38 pm, BruceMcF <agil...@netscape.net> wrote: >> Aha, you're right ~ if DEPTH and PICK exist on the system, >> I think its something like the following: >> VARIABLE noname-xt >> : :noname >> DEPTH >R :noname DEPTH 1- R> - PICK noname-xt ! ; >> ... works on gforth. > Doesn't look correct to this novice. Where does the > compiler get switched on? By the original ":noname" in the definition. Including the original :noname in the definition means it inherits all the behavior of :noname, plus this additional behavior as well. If the original :noname does not turn on the compiler, its broken.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-09 09:36 -1000 |
| Message-ID | <HaednR9u2fuo_n_TnZ2dnUVZ_vqdnZ2d@supernews.com> |
| In reply to | #7854 |
On 12/9/11 3:26 AM, Anton Ertl wrote: > Andrew Haley<andrew29@littlepinkcloud.invalid> writes: >> Arnold Doray<thinksquared@gmail.com> wrote: >>> I'm beginning to appreciate Gforth's LATESTXT word. Is there a portable >>> implementation? >> >> No. Practice varies so much between Forths that it hasn't been >> possible to standardize it. > > This feature should be easy to insert into any standard Forth: AFAIK most if not all Forths have some method for knowing the latest definition, it's kinda necessary. The problem is, that they all do it differently (at different times, in different forms, etc.), which is why it hasn't been possible to standardize it. Although it's a system necessity, I haven't found this of much value in application programming. 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 | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-10 03:24 +0000 |
| Message-ID | <jbujdi$bk0$1@dont-email.me> |
| In reply to | #7854 |
On Fri, 09 Dec 2011 13:26:23 +0000, Anton Ertl wrote:
>
> This feature should be easy to insert into any standard Forth:
>
> Add a possibly (USERized) VALUE LATESTXT, and in every place where an xt
> is defined, add an "is latestxt".
>
Thanks.
To be honest, I could live with just better standardized behaviour
for :NONAME as it is called within a word. For example,
: def :noname .S ;
GForth and BigForth behave this way:
def ." rover" ; <5> 5015480 0 0 5015480 0 ok <-- GForth
def ." rover" ; <2> 268642316 0 ok <-- BigForth
These forths leave junk on the stack making retrieving the :NONAME's xt
"unportable".
But GForth has LATESTXT which is nicer than just a clean stack since the
xt is saved. And it also works for definitions made with CREATE.
VFX and SwiftForth are much better behaved:
def ." rover" ;
DATA STACK
top
134990068 080B:C8F4
ok-1 <-- VFX.
SwiftForth is the same. Both leave a clean stack with just the :NONAME's
xt on it.
I am *guessing* that GForth and BigForth don't serialize the execution
of :NONAME and .S , so .S sees the stack as the :NONAME is in partial
execution?
In any case, some standardization of this behaviour would be welcome.
Cheers,
Arnold
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-09 20:12 -0800 |
| Message-ID | <ff6ea5ae-a31e-4f43-84c7-fe8c981b2492@h5g2000yqk.googlegroups.com> |
| In reply to | #7869 |
On Dec 9, 10:24 pm, Arnold Doray <thinksqua...@gmail.com> wrote: > On Fri, 09 Dec 2011 13:26:23 +0000, Anton Ertl wrote: > > > This feature should be easy to insert into any standard Forth: > > > Add a possibly (USERized) VALUE LATESTXT, and in every place where an xt > > is defined, add an "is latestxt". > > Thanks. > > To be honest, I could live with just better standardized behaviour > for :NONAME as it is called within a word. For example, > > : def :noname .S ; > > GForth and BigForth behave this way: > > def ." rover" ; <5> 5015480 0 0 5015480 0 ok <-- GForth > def ." rover" ; <2> 268642316 0 ok <-- BigForth > > These forths leave junk on the stack making retrieving the :NONAME's xt > "unportable". > > But GForth has LATESTXT which is nicer than just a clean stack since the > xt is saved. And it also works for definitions made with CREATE. > > VFX and SwiftForth are much better behaved: > > def ." rover" ; > > DATA STACK > top > 134990068 080B:C8F4 > ok-1 <-- VFX. > > SwiftForth is the same. Both leave a clean stack with just the > :NONAME's xt on it. There's no telling what "colon-sys" from the specification actually means ~ it could be nothing, it could be notional, as in the stack depth is saved in a variable for checking on ";" but nothing is placed on the data stack, it could be a marker ... so what :noname normally leave on the stack is the xt underneath whatever ";" will be expecting to clean up. > > I am *guessing* that GForth and BigForth don't serialize the execution > of :NONAME and .S , so .S sees the stack as the :NONAME is in partial > execution? Far more likely that the xt is sitting underneath whatever their colonsys happens to be under the circumstance.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-09 18:15 -1000 |
| Message-ID | <6vadnZnxb5N0QX_TnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #7869 |
On 12/9/11 5:24 PM, Arnold Doray wrote: > On Fri, 09 Dec 2011 13:26:23 +0000, Anton Ertl wrote: > >> >> This feature should be easy to insert into any standard Forth: >> >> Add a possibly (USERized) VALUE LATESTXT, and in every place where an xt >> is defined, add an "is latestxt". >> > > Thanks. > > To be honest, I could live with just better standardized behaviour > for :NONAME as it is called within a word. For example, > > : def :noname .S ; > > GForth and BigForth behave this way: > > def ." rover" ;<5> 5015480 0 0 5015480 0 ok<-- GForth > def ." rover" ;<2> 268642316 0 ok<-- BigForth > > These forths leave junk on the stack making retrieving the :NONAME's xt > "unportable". > > But GForth has LATESTXT which is nicer than just a clean stack since the > xt is saved. And it also works for definitions made with CREATE. > > VFX and SwiftForth are much better behaved: > > def ." rover" ; > > DATA STACK > top > 134990068 080B:C8F4 > ok-1<-- VFX. > > SwiftForth is the same. Both leave a clean stack with just the :NONAME's > xt on it. > > I am *guessing* that GForth and BigForth don't serialize the execution > of :NONAME and .S , so .S sees the stack as the :NONAME is in partial > execution? > > In any case, some standardization of this behaviour would be welcome. Remember all the discussion about colon-sys and whether colon leaves stuff on the stack to be discarded by semi-colon? That's what you're seeing. :noname leaves a colon-sys, as does colon. On some systems that's nothing, on others it's stuff, and exactly what (if anything) it is implementation-dependent. Personally, I'm no big fan of :noname, and using it in a definition is, to me, rarely a good idea. 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 | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-10 10:18 +0000 |
| Message-ID | <jbvblu$mu5$1@dont-email.me> |
| In reply to | #7872 |
On Fri, 09 Dec 2011 18:15:37 -1000, Elizabeth D. Rather wrote: > On 12/9/11 5:24 PM, Arnold Doray wrote: >> On Fri, 09 Dec 2011 13:26:23 +0000, Anton Ertl wrote: >> >> >>> This feature should be easy to insert into any standard Forth: >>> >>> Add a possibly (USERized) VALUE LATESTXT, and in every place where an >>> xt is defined, add an "is latestxt". >>> >>> >> Thanks. >> >> To be honest, I could live with just better standardized behaviour for >> :NONAME as it is called within a word. For example, >> >> : def :noname .S ; >> >> GForth and BigForth behave this way: >> >> def ." rover" ;<5> 5015480 0 0 5015480 0 ok<-- GForth def ." rover" >> ;<2> 268642316 0 ok<-- BigForth >> >> These forths leave junk on the stack making retrieving the :NONAME's xt >> "unportable". >> >> But GForth has LATESTXT which is nicer than just a clean stack since >> the xt is saved. And it also works for definitions made with CREATE. >> >> VFX and SwiftForth are much better behaved: >> >> def ." rover" ; >> >> DATA STACK >> top >> 134990068 080B:C8F4 >> ok-1<-- VFX. >> >> SwiftForth is the same. Both leave a clean stack with just the >> :NONAME's xt on it. >> >> I am *guessing* that GForth and BigForth don't serialize the execution >> of :NONAME and .S , so .S sees the stack as the :NONAME is in partial >> execution? >> >> In any case, some standardization of this behaviour would be welcome. > > Remember all the discussion about colon-sys and whether colon leaves > stuff on the stack to be discarded by semi-colon? That's what you're > seeing. :noname leaves a colon-sys, as does colon. On some systems > that's nothing, on others it's stuff, and exactly what (if anything) it > is implementation-dependent. > Yes, I am aware that both : and :NONAME can leave "turds" on the stack while they are parsing input. That's acceptable. But I would have thought that the terminating ; in the input stream of : def ." rover" ; would have to run and clean up :NONAME's stack turds before the next word in DEF (ie, .S) executes. But from my example, it appears that this isn't necessarily the case. Certainly, GForth and BigForth behave as if the .S is executed before the :NONAME encounters the terminating ; in the input stream. IMO, this is a separate issue from the colon-sys discussion, and is really about :NONAME's runtime behaviour. If :NONAME's runtime behaviour were standardized, then actions could be taken at compile time (ie, in DEF) to save/manipulate/execute the anonymous function created by :NONAME. But you can't do that now, or at least have to rely on non-standard words like LATESTXT. > > Personally, I'm no big fan of :noname, and using it in a definition is, > to me, rarely a good idea. > I first saw the use of :NONAME in a definition in the '94 spec, and thought it was "Forth Way". Could you share your reasons for not liking :NONAME? How else to create words that can parse the input stream? Thanks, Arnold
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-10 11:39 +0000 |
| Message-ID | <2011Dec10.123907@mips.complang.tuwien.ac.at> |
| In reply to | #7874 |
Arnold Doray <thinksquared@gmail.com> writes:
>On Fri, 09 Dec 2011 18:15:37 -1000, Elizabeth D. Rather wrote:
>
>> On 12/9/11 5:24 PM, Arnold Doray wrote:
>>> : def :noname .S ;
...
>Yes, I am aware that both : and :NONAME can leave "turds" on the stack
>while they are parsing input. That's acceptable. But I would have thought
>that the terminating ; in the input stream of :
>
>def ." rover" ;
>
>would have to run and clean up :NONAME's stack turds before the next word
>in DEF (ie, .S) executes. But from my example, it appears that this isn't
>necessarily the case.
>
>Certainly, GForth and BigForth behave as if the .S is executed before
>the :NONAME encounters the terminating ; in the input stream.
Correct. :NONAME does not parse the input stream in a standard
system. It just starts a definition; then, in your code .S prints the
stack, then the text interpreter performs the compilation semantics of
'."' and ';'.
>How else to create words that can parse the input stream?
Just include parsing words in any colon definition (whether defined
with :NONAME or :). But it's usually a bad idea to create parsing
words.
- 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 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-10 16:31 +0000 |
| Message-ID | <jc01h1$12b$1@dont-email.me> |
| In reply to | #7879 |
On Sat, 10 Dec 2011 11:39:07 +0000, Anton Ertl wrote:
>>Certainly, GForth and BigForth behave as if the .S is executed before
>>the :NONAME encounters the terminating ; in the input stream.
>
> Correct. :NONAME does not parse the input stream in a standard system.
> It just starts a definition; then, in your code .S prints the stack,
> then the text interpreter performs the compilation semantics of '."' and
> '
Is this reasonable?
Firstly, the spec says that :NONAME should :-
Create an execution token xt,
Enter compilation state and
Start the current definition,
producing colon-sys.
Append the initiation semantics given
below to the current definition.
If the compilation state is entered, how can the next word after
the :NONAME (ie, .S) execute?
Secondly, if the text parser doesn't kick in immediately after the :NONAME
executes, this leads to all kinds of confusion, IMHO.
For example, consider:
: mdef :noname :noname ;
It *should* be easy to determine what MDEF does -- the first :NONAME
executes, kicks off the text parser which parses the inputstream until
a ; is encountered, resulting in an XT on the stack. Ditto for the
second :NONAME. This results in two XTs on the stack.
In actual fact, each forth I tested (VFX, Swift, Gforth, BigForth) has a
different runtime behaviour for MDEF.
Cheers,
Arnold
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-10 23:03 +0100 |
| Message-ID | <jc0l03$33t$1@online.de> |
| In reply to | #7895 |
Arnold Doray wrote: > On Sat, 10 Dec 2011 11:39:07 +0000, Anton Ertl wrote: > >>>Certainly, GForth and BigForth behave as if the .S is executed before >>>the :NONAME encounters the terminating ; in the input stream. >> >> Correct. :NONAME does not parse the input stream in a standard >> system. It just starts a definition; then, in your code .S prints the >> stack, then the text interpreter performs the compilation semantics >> of '."' and ' > > Is this reasonable? > > Firstly, the spec says that :NONAME should :- > > Create an execution token xt, > Enter compilation state and > Start the current definition, > producing colon-sys. > Append the initiation semantics given > below to the current definition. > > If the compilation state is entered, how can the next word after > the :NONAME (ie, .S) execute? You don't really understand this. When you write : test :noname .s ; the outer interpreter does the following steps: First it encounters ':'. It currently is in interpretation state, and : is a normal word, so it just executes it (no special interpretation or compilation semantics. : parses "test" and creates a definition named test, and puts the outer interpreter into compilation state (by setting the STATE variable and maybe doing some other things, the same actions ] does). Now, what : does *not* do is invoke some parsing loop. We are still in the same outer interpreter, the same parsing loop that parses the entire line. It's now in compilation state, and encounters :noname. It compile,s :noname's xt, because :noname is a normal word, no special compilation semantics. The same happens for .s. ; is different, it's immediate, it has special compilation semantics. ; reveals the definition test (which up to now was invisible), compiles EXIT or similar, and switches back to interpretation state (similar to [). When you execute test, the same thing happens: :noname inside only switches over the interpreter to compilation state, leaving an xt and colon-sys on the stack. colon-sys is just something implementation dependent, you don't know what it really is. All four systems you examined show something different, yes. IIRC, PolyForth had it the way you expect it - : and ] just started another parsing loop, but this eliminates some possibilities. E.g. I can write CONSTANT without CREATE DOES> that way: : Constant >r : r> postpone literal postpone ; ; This is a nice capability. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-11 02:34 +0000 |
| Message-ID | <jc14qu$p1u$1@dont-email.me> |
| In reply to | #7913 |
On Sat, 10 Dec 2011 23:03:46 +0100, Bernd Paysan wrote: > Arnold Doray wrote: > >> On Sat, 10 Dec 2011 11:39:07 +0000, Anton Ertl wrote: >> >>>>Certainly, GForth and BigForth behave as if the .S is executed before >>>>the :NONAME encounters the terminating ; in the input stream. >>> >>> Correct. :NONAME does not parse the input stream in a standard >>> system. It just starts a definition; then, in your code .S prints the >>> stack, then the text interpreter performs the compilation semantics of >>> '."' and ' >> >> Is this reasonable? >> >> Firstly, the spec says that :NONAME should :- >> >> Create an execution token xt, >> Enter compilation state and >> Start the current definition, >> producing colon-sys. >> Append the initiation semantics given >> below to the current definition. >> >> If the compilation state is entered, how can the next word after the >> :NONAME (ie, .S) execute? > > You don't really understand this. When you write > > : test :noname .s ; > > the outer interpreter does the following steps: > > First it encounters ':'. It currently is in interpretation state, and : > is a normal word, so it just executes it (no special interpretation or > compilation semantics. : parses "test" and creates a definition named > test, and puts the outer interpreter into compilation state (by setting > the STATE variable and maybe doing some other things, the same actions ] > does). > > Now, what : does *not* do is invoke some parsing loop. We are still in > the same outer interpreter, the same parsing loop that parses the entire > line. It's now in compilation state, and encounters :noname. It > compile,s :noname's xt, because :noname is a normal word, no special > compilation semantics. The same happens for .s. ; is different, it's > immediate, it has special compilation semantics. ; reveals the > definition test (which up to now was invisible), compiles EXIT or > similar, and switches back to interpretation state (similar to [). > Yes, this is exactly what I understand happens during the compilation of TEST. > When you execute test, the same thing happens: :noname inside only > switches over the interpreter to compilation state, leaving an xt and > colon-sys on the stack. colon-sys is just something implementation > dependent, you don't know what it really is. All four systems you > examined show something different, yes. > This is the part I have trouble understanding. When TEST executes, it executes :NONAME first, which puts the colon-sys on the stack and switches over to *compilation* state. This is crystal clear from the '94 Spec. Yes, I know the colon-sys is implementation dependent. Also clear from the spec. The issue I have is that now forth is in *compilation* state. Shouldn't the text parser parse the input stream *immediately*, before moving on to the next word in TEST? As an analogy, the words [ and ] immediately switch the forth between interpretative and compilation states. So I thought once you're in compilation state, the text-parser should be doing its thing immediately. Do you see? I'm saying it is non-intuitive if the text-parser does not kick in immediately after :NONAME executes. The system is already in compilation state. The forths I have tested are effectively behaving as if the text-parser starts after the TEST executes. Why then? This seems arbitrary to me and not at all a sensible choice. > IIRC, PolyForth had it the way you expect it - : and ] just started > another parsing loop, but this eliminates some possibilities. E.g. I > can write CONSTANT without CREATE DOES> that way: > > : Constant >r : r> postpone literal postpone ; ; > > This is a nice capability. Really? I don't think modern forths use CREATE DOES> to define constants. Also, doesn't your example rely on return stack fiddling which I understand is not portable? I would prefer a sensible :NONAME. You can do a lot with it. Portably. Cheers, Arnold
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-10 18:01 -1000 |
| Message-ID | <_cadnf6YzLeptnnTnZ2dnUVZ_rudnZ2d@supernews.com> |
| In reply to | #7919 |
On 12/10/11 4:34 PM, Arnold Doray wrote: > On Sat, 10 Dec 2011 23:03:46 +0100, Bernd Paysan wrote: > ... >> You don't really understand this. When you write >> >> : test :noname .s ; >> >> the outer interpreter does the following steps: >> >> First it encounters ':'. It currently is in interpretation state, and : >> is a normal word, so it just executes it (no special interpretation or >> compilation semantics. : parses "test" and creates a definition named >> test, and puts the outer interpreter into compilation state (by setting >> the STATE variable and maybe doing some other things, the same actions ] >> does). >> >> Now, what : does *not* do is invoke some parsing loop. We are still in >> the same outer interpreter, the same parsing loop that parses the entire >> line. It's now in compilation state, and encounters :noname. It >> compile,s :noname's xt, because :noname is a normal word, no special >> compilation semantics. The same happens for .s. ; is different, it's >> immediate, it has special compilation semantics. ; reveals the >> definition test (which up to now was invisible), compiles EXIT or >> similar, and switches back to interpretation state (similar to [). >> > > Yes, this is exactly what I understand happens during the compilation of > TEST. > >> When you execute test, the same thing happens: :noname inside only >> switches over the interpreter to compilation state, leaving an xt and >> colon-sys on the stack. colon-sys is just something implementation >> dependent, you don't know what it really is. All four systems you >> examined show something different, yes. >> > > This is the part I have trouble understanding. > > When TEST executes, it executes :NONAME first, which puts the colon-sys > on the stack and switches over to *compilation* state. This is crystal > clear from the '94 Spec. Yes, I know the colon-sys is implementation > dependent. Also clear from the spec. > > The issue I have is that now forth is in *compilation* state. Shouldn't > the text parser parse the input stream *immediately*, before moving on to > the next word in TEST? No. The fact that the system is in compilation state influences what the text interpreter will do when it runs, but doesn't immediately launch it. The text interpreter won't become active until TEST finishes executing. I can write a word like this: : mycolon : here . 100 0 do i . loop cr ." Hello world" ; ...and if I then say: mycolon foo ." Goodbye cruel world" ; ...then foo will compile perfectly normally, but a whole bunch of stuff will happen before the actual compilation commences. > As an analogy, the words [ and ] immediately switch the forth between > interpretative and compilation states. So I thought once you're in > compilation state, the text-parser should be doing its thing immediately. > > Do you see? I see that you have a mistaken impression of how the text interpreter works. It operates *either* when you explicitly invoke it with a word that parses *or* when everything that is executing is done and control passes to the text interpreter to process the input stream. :noname does not invoke the text interpreter explicitly. : does, but only long enough to get the name of the definition to be created. > I'm saying it is non-intuitive if the text-parser does not kick in > immediately after :NONAME executes. The system is already in compilation > state. > > The forths I have tested are effectively behaving as if the text-parser > starts after the TEST executes. Why then? This seems arbitrary to me and > not at all a sensible choice. That is exactly the way it works and the way it's described in, for example, the flow-chart in my books that describes the text interpreter. >> IIRC, PolyForth had it the way you expect it - : and ] just started >> another parsing loop, but this eliminates some possibilities. E.g. I >> can write CONSTANT without CREATE DOES> that way: >> >> : Constant>r : r> postpone literal postpone ; ; >> >> This is a nice capability. It drove people nuts. Suppose you typed: : foo ( -- ) doors 0 do ...and then thought to yourself, wait a minute, what's the value of doors again? So you type: doors . ...You will then be very confused because the system just says, "ok" without executing doors and . because what has happened is that the compiler kept right on compiling the definition foo including a reference to doors and . and is still compiling, and will continue until you type ; or an error occurs. It seemed nice at the time, but caused a lot of trouble. > Really? I don't think modern forths use CREATE DOES> to define constants. They can, and many do: : CONSTANT ( n -- ) CREATE , DOES> ( -- n ) @ ; > Also, doesn't your example rely on return stack fiddling which I > understand is not portable? I'm not wild about that example, myself. > I would prefer a sensible :NONAME. You can do a lot with it. Portably. It is intended to be, and is, exactly like : without a name for the compiled code. Why don't you tell us what you're trying to do, and maybe we can help find a way to do it? Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-11 09:46 +0000 |
| Message-ID | <jc1u52$r6j$1@dont-email.me> |
| In reply to | #7922 |
On Sat, 10 Dec 2011 18:01:54 -1000, Elizabeth D. Rather wrote: > > I see that you have a mistaken impression of how the text interpreter > works. It operates *either* when you explicitly invoke it with a word > that parses *or* when everything that is executing is done and control > passes to the text interpreter to process the input stream. :noname > does not invoke the text interpreter explicitly. : does, but only long > enough to get the name of the definition to be created. > Thanks. That's a very clear explanation of when the text parser executes. But I still think it's not the best way of doing things. It is much nicer for :NONAME to invoke the text parser before the next word runs. Because: A) You can do a lot more with :NONAME since the resulting xt is available to the following word. B) You can process multiple definitions at one go. Eg, : mdef :noname <do-something> :noname <do-something-else> ; This last definition doesn't even have a defined semantics in the current way of doing things. But it is trivial to understand what it does if :NONAME kicks off the text-parser immediately. I'm just curious why the behaviour I've outlined above isn't used, since it both simplifies the semantics of :NONAME and extends its usability. Cheers, Arnold
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-11 03:55 -0600 |
| Message-ID | <HJqdnedGLvCe43nTnZ2dnUVZ_qidnZ2d@supernews.com> |
| In reply to | #7926 |
Arnold Doray <thinksquared@gmail.com> wrote: > On Sat, 10 Dec 2011 18:01:54 -1000, Elizabeth D. Rather wrote: > >> >> I see that you have a mistaken impression of how the text interpreter >> works. It operates *either* when you explicitly invoke it with a word >> that parses *or* when everything that is executing is done and control >> passes to the text interpreter to process the input stream. :noname >> does not invoke the text interpreter explicitly. : does, but only long >> enough to get the name of the definition to be created. >> > > Thanks. That's a very clear explanation of when the text parser executes. > > But I still think it's not the best way of doing things. It is much nicer > for :NONAME to invoke the text parser before the next word runs. Because: > > A) You can do a lot more with :NONAME since the resulting xt is available > to the following word. > > B) You can process multiple definitions at one go. Eg, > > : mdef :noname <do-something> :noname <do-something-else> ; > > This last definition doesn't even have a defined semantics in the current > way of doing things. I think you'll find it does. MDEF creates two :noname definitions. > But it is trivial to understand what it does if :NONAME kicks off > the text-parser immediately. > > I'm just curious why the behaviour I've outlined above isn't used, since > it both simplifies the semantics of :NONAME and extends its usability. It's partly historical baggage, and partly how things have evolved. I think you have to bear in mind that other ways have been tried, and after a lot of experience and experimentation the current behaviour was adopted. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-11 11:35 +0000 |
| Message-ID | <jc24ie$30h$1@dont-email.me> |
| In reply to | #7927 |
On Sun, 11 Dec 2011 03:55:15 -0600, Andrew Haley wrote: >> B) You can process multiple definitions at one go. Eg, >> >> : mdef :noname <do-something> :noname <do-something-else> ; >> >> This last definition doesn't even have a defined semantics in the >> current way of doing things. > > I think you'll find it does. MDEF creates two :noname definitio No, it shouldn't. In the current behaviour, the first :NONAME sets the compilation flag and puts the <xt><colon-sys> on the stack. The second :NONAME does the same. When the text parser finally kicks in, it parses the input stream until ; which clears the top <colon-sys> and resets the compilation state to interpretation. This leaves <xt><colon-sys><xt'> on the stack. Only the top xt' works. Also, because the compilation flag is cleared, the system no longer parses the next definition. ( And even if it did, it would be wrong since the <xt><colon-sys> is below <xt'> ). Isn't this silly? I tested Swift, Gforth and BigForth, which all behave this way. VFX just gives an error. Can you see why I say it's much more sensible to just kick off the text parser immediately after :NONAME? Then you would indeed end up with two working XTs: : mdef :noname :noname ; mdef ." bingo" ; ." little" ; ok \ DOES NOT WORK! execute little ok \ DOES NOT HAPPEN! execute bingo ok \ DOES NOT HAPPEN! Cheers, Arnold
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-11 10:59 -1000 |
| Message-ID | <y7ednUSrys06hHjTnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #7938 |
On 12/11/11 1:35 AM, Arnold Doray wrote: > On Sun, 11 Dec 2011 03:55:15 -0600, Andrew Haley wrote: > >>> B) You can process multiple definitions at one go. Eg, >>> >>> : mdef :noname<do-something> :noname<do-something-else> ; >>> >>> This last definition doesn't even have a defined semantics in the >>> current way of doing things. >> >> I think you'll find it does. MDEF creates two :noname definitio > > No, it shouldn't. I agree, this time. It shouldn't because the effect is to nest definitions: the second :NONAME is executing while the system was prepared to construct something useful. Attempting to nest definitions is explicitly called out as an error in ANS Forth. > In the current behaviour, the first :NONAME sets the compilation flag and > puts the<xt><colon-sys> on the stack. The second :NONAME does the same. > When the text parser finally kicks in, it parses the input stream until ; > which clears the top<colon-sys> and resets the compilation state to > interpretation. This leaves<xt><colon-sys><xt'> on the stack. Only the > top xt' works. Also, because the compilation flag is cleared, the system > no longer parses the next definition. ( And even if it did, it would be > wrong since the<xt><colon-sys> is below<xt'> ). > > Isn't this silly? It depends on your definition of "silly". I think it's behaving exactly as specified, and attempting to put two :nonames in a colon definition is silly. IMO even putting one :noname in a colon definition is silly. That is not how these words are supposed to be used. What you're doing is silly in the same way that attempting to use a screwdriver to hammer nails is silly. Don't blame the screwdriver for your failure. 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 | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| Date | 2011-12-12 02:19 +0000 |
| Message-ID | <jc3oak$1uh$1@dont-email.me> |
| In reply to | #7949 |
On Sun, 11 Dec 2011 10:59:17 -1000, Elizabeth D. Rather wrote: > On 12/11/11 1:35 AM, Arnold Doray wrote: >> On Sun, 11 Dec 2011 03:55:15 -0600, Andrew Haley wrote: >> >>>> B) You can process multiple definitions at one go. Eg, >>>> >>>> : mdef :noname<do-something> :noname<do-something-else> ; >>>> >>>> This last definition doesn't even have a defined semantics in the >>>> current way of doing things. >>> >>> I think you'll find it does. MDEF creates two :noname definitio >> >> No, it shouldn't. > > I agree, this time. It shouldn't because the effect is to nest > definitions: the second :NONAME is executing while the system was > prepared to construct something useful. Attempting to nest definitions > is explicitly called out as an error in ANS Forth. > Exactly. If the text parser kicks off after the MDEF completes, then the definitions are indeed nested. But if the text parser is immediately triggered by :NONAME then the definitions are serialized. What I am trying to understand is the *rationale* behind the current behaviour. I'm sure that there is a good explanation, but it eludes me. >> In the current behaviour, the first :NONAME sets the compilation flag >> and puts the<xt><colon-sys> on the stack. The second :NONAME does the >> same. When the text parser finally kicks in, it parses the input stream >> until ; which clears the top<colon-sys> and resets the compilation >> state to interpretation. This leaves<xt><colon-sys><xt'> on the stack. >> Only the top xt' works. Also, because the compilation flag is cleared, >> the system no longer parses the next definition. ( And even if it did, >> it would be wrong since the<xt><colon-sys> is below<xt'> ). >> >> Isn't this silly? > > It depends on your definition of "silly". I think it's behaving exactly > as specified, and attempting to put two :nonames in a colon definition > is silly. IMO even putting one :noname in a colon definition is silly. > That is not how these words are supposed to be used. What you're doing > is silly in the same way that attempting to use a screwdriver to hammer > nails is silly. Don't blame the screwdriver for your failure. > I'm simply trying to understand the rationale behind the current behaviour. I've explained how you can simplify the semantics of :NONAME and extend its range of use at the same time, without impacting current code. Surely that's "Forth Way"? Cheers, Arnold
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-11 17:38 -1000 |
| Message-ID | <k8GdnflhfvKq6njTnZ2dnUVZ_gKdnZ2d@supernews.com> |
| In reply to | #7954 |
On 12/11/11 4:19 PM, Arnold Doray wrote: ... >>> In the current behaviour, the first :NONAME sets the compilation flag >>> and puts the<xt><colon-sys> on the stack. The second :NONAME does the >>> same. When the text parser finally kicks in, it parses the input stream >>> until ; which clears the top<colon-sys> and resets the compilation >>> state to interpretation. This leaves<xt><colon-sys><xt'> on the stack. >>> Only the top xt' works. Also, because the compilation flag is cleared, >>> the system no longer parses the next definition. ( And even if it did, >>> it would be wrong since the<xt><colon-sys> is below<xt'> ). >>> >>> Isn't this silly? >> >> It depends on your definition of "silly". I think it's behaving exactly >> as specified, and attempting to put two :nonames in a colon definition >> is silly. IMO even putting one :noname in a colon definition is silly. >> That is not how these words are supposed to be used. What you're doing >> is silly in the same way that attempting to use a screwdriver to hammer >> nails is silly. Don't blame the screwdriver for your failure. >> > > I'm simply trying to understand the rationale behind the current > behaviour. > > I've explained how you can simplify the semantics of :NONAME and extend > its range of use at the same time, without impacting current code. Surely > that's "Forth Way"? It's hard to imagine simplifying the semantics of :NONAME beyond what they are: "Create an execution token xt, enter compilation state and start the current definition, producing colon-sys." You would have it also actually start running the text interpreter. That would be inconsistent with virtually every system in existence. Moreover, if you're advocating permitting colon definitions to nest, that's a whole massive can of worms for which rules need to be defined that will cover ITC, DTC, compile-to-code, and optimizing compilers in some transparently consistent way. The mind boggles. As far as "extending the range of use" of :noname, no one but you seems to perceive a need, and I'm not sure what that is. Strings of nameless bits of code with xts floating around are a nightmare to manage. Truly, it's much easier to just make definitions with names and reference them when you want to. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-12 13:22 +0100 |
| Message-ID | <jc4rle$qtr$1@online.de> |
| In reply to | #7956 |
Elizabeth D. Rather wrote:
> Moreover, if you're advocating permitting colon definitions to nest,
> that's a whole massive can of worms for which rules need to be defined
> that will cover ITC, DTC, compile-to-code, and optimizing compilers in
> some transparently consistent way. The mind boggles.
It's actually not that bad. The implementations of [: ;] (nesting
unnamed definitions) are a few lines, and to make them work in VFX
requires a little bit other platform specific code than in bigForth or
Gforth. No big difference, only a small difference.
The way to go is to use AHEAD ... THEN to jump over the allocated memory
area of the nested function. And then to save and restore all the
internal state necessary for the compiler to proceed - that's the LATEST
variable or something similar, and some internal state of the locals.
And in VFX you have to tell the inliner, that this function should not
be inlined.
Stephen and I had some discussion about this sort of nesting a while
ago, and there are other places where you want to put some random data
inside a definition, similar to a string, but not identical - the i18n
wordset has this localized string constant, which is an opaque type, and
a sort-of database entry.
The IMHO "right" factors for this would be a word which postpones the
AHEAD and saves the compiler state, and another word which restores the
compiler state and postpones the THEN, let's call it save[ and ]restore
(both non-immediate, they are only building blocks). So
: [: save[ :noname ;
: ;] postpone ; >r ]restore r> postpone Literal ; immediate
could be defined portably, just as putting a string would be portable
with
: s" save[ [char] " parse tuck here swap move here swap dup allot
>r >r ]restore r> postpone literal r> postpone literal ;
immediate
Most of the time, named definitions are better, though.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2011-12-12 10:34 +0000 |
| Message-ID | <4ee5d766.311618580@192.168.0.50> |
| In reply to | #7954 |
On Mon, 12 Dec 2011 02:19:00 +0000 (UTC), Arnold Doray <thinksquared@gmail.com> wrote: >What I am trying to understand is the *rationale* behind the current >behaviour. I'm sure that there is a good explanation, but it eludes me. You are thinking of :NONAME in the form :NONAME .... ; Think of it as a constructor. e.g. : hex: \ -- xt :noname postpone base postpone @ postpone >r postpone hex ; : ;hex \ -- postpone r> postpone base postpone ! postpone ; ; The behaviour of :NONAME works very well in this situation. 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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web