Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #27952 > unrolled thread
| Started by | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| First post | 2014-01-19 13:15 -0500 |
| Last post | 2014-01-23 11:51 -0800 |
| Articles | 20 on this page of 65 — 15 participants |
Back to article view | Back to comp.lang.forth
quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 13:15 -0500
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-19 20:07 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-19 21:45 +0000
Re: quick review of <BUILDS and CREATE history Coos Haak <chforth@hccnet.nl> - 2014-01-19 22:02 +0100
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-19 17:24 -0600
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-19 14:54 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-19 22:37 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-19 18:01 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 00:27 -0500
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-19 20:54 -1000
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-19 21:19 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:14 -0500
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-20 12:07 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 11:37 -0500
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-21 17:41 +0000
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 08:30 -1000
Re: quick review of <BUILDS and CREATE history oh2aun@gmail.com - 2014-01-21 11:17 -0800
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 09:44 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 15:18 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 12:07 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-21 22:04 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-21 19:21 -1000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-22 13:38 +0000
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 08:50 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-23 17:17 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-23 13:46 -1000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:07 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-25 15:18 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-25 20:18 +0100
Re: quick review of <BUILDS and CREATE history Coos Haak <chforth@hccnet.nl> - 2014-01-25 20:44 +0100
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-25 21:41 +0100
Re: quick review of <BUILDS and CREATE history "Alex McDonald" <blog@rivadpm.com> - 2014-01-25 22:47 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:54 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 16:49 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 15:40 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-27 23:00 +0100
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-27 19:43 -0500
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-28 09:25 +0000
Re: quick review of <BUILDS and CREATE history Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-28 19:45 +0100
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:32 +0000
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:20 +0000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-25 15:28 +0000
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 13:51 -0600
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 15:34 +0000
Re: quick review of <BUILDS and CREATE history Lars Brinkhoff <lars.spam@nocrew.org> - 2014-01-24 08:11 +0100
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:28 -0800
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 05:00 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:32 -1000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:48 -0500
Re: quick review of <BUILDS and CREATE history "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 13:14 -1000
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:16 -0800
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-23 12:13 -0500
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-22 13:32 +0000
Re: quick review of <BUILDS and CREATE history Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-20 04:14 -0800
Re: quick review of <BUILDS and CREATE history Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-20 06:31 -0600
Re: quick review of <BUILDS and CREATE history Elizabeth D Rather <erather@forth.com> - 2014-01-20 08:04 -1000
Re: quick review of <BUILDS and CREATE history anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-21 14:09 +0000
Re: quick review of <BUILDS and CREATE history "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-20 16:14 -0500
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-22 17:44 -0800
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-22 18:24 -0800
Re: quick review of <BUILDS and CREATE history albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-23 14:00 +0000
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-23 11:06 -0800
Re: quick review of <BUILDS and CREATE history Paul Rubin <no.email@nospam.invalid> - 2014-01-23 11:33 -0800
Re: quick review of <BUILDS and CREATE history trebor.english@gmail.com - 2014-01-23 11:42 -0800
Re: quick review of <BUILDS and CREATE history Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 11:51 -0800
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-01-28 14:20 +0000 |
| Message-ID | <52e7bcbf$0$24947$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #28137 |
In article <lc6kth$jvl$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Anton Ertl wrote: >> Anyway, back to ['] RECURSE and friends: a RECURSE that always is a >> named reference to the latest word is a cute trick, but is so unusual >> and unlike the way the usual Forth words work that I wonder if it is a >> good idea or a bad one (it would not be the first cute trick in the >> Forth world that turned out to be a bad idea). I guess we will see. > >Having SYNONYM in the standard means that named references to something else >isn't unusual, it's a necessary feature. The definition of RECURSE >therefore is a simple > >' noop Alias recurse > >The next thing is then to give the address of the alias pointer of RECURSE a >name so that you can change that alias (the noop is just a dummy). The >POSTPONE RECURSE thing works, since in git Gforth, postpone is compiling the >name token as literal plus a word that performs the compilation action of a >name token. As we have introduced name tokens in the standard, too, this is >the obvious (generic) way to do it (name tokens on git Gforth are almost >identical to xts, with the exception that an alias has a name token of its >own). > >IMHO this is both the smallest possible and the most general implementation >of RECURSE. You're almost back to the c-solution, creating a preliminary definition that later is to be filled in. Remember that RECURSE only makes sense for colon definitions. The utter c-way to do recurse definitions would be. :F something ; \ forward definition. :R something . . . . . . something ..... ; \ Resolving definition. According to normal conventions the something compiled in the :R definitions is the :F definition. :R (apart from doing : ) patches up the previous definition and suppresses a redefinition warning. This has some advantages (the c people weren't crazy): 1. no name clutter 2. mutual recursion supported without hassle. 3. unobtrusive This is WANT-able in ciforth, but I only use it for mutually recursive definitions (that come up occasionally in non-trivial algorithms in the euler project.) > >-- >Bernd Paysan >"If you want it done right, you have to do it yourself" >http://bernd-paysan.de/ > -- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-25 15:28 +0000 |
| Message-ID | <2014Jan25.162801@mips.complang.tuwien.ac.at> |
| In reply to | #28043 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>If it were me, I'd simply declare that RECURSE won't work in :NONAME.
But :NONAME is the only thing where RECURSE really makes sense. For
named words, using RECURSIVE is preferable:
: sort ( ... ) recursive
partition sort sort ;
The only thing that RECURSIVE cannot handle is :NONAME. If RECURSE
would not work in :NONAME, we don't need it.
And doing a proper RECURSE is not that complicated:
: recurse latestxt compile, ; immediate
and set latestxt in a common factor of :noname and ":".
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-25 13:51 -0600 |
| Message-ID | <q-GdnaMP04JQiHnPnZ2dnUVZ_t-dnZ2d@supernews.com> |
| In reply to | #28090 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>If it were me, I'd simply declare that RECURSE won't work in :NONAME. > > But :NONAME is the only thing where RECURSE really makes sense. For > named words, using RECURSIVE is preferable: > > : sort ( ... ) recursive > partition sort sort ; We already have a perfectly good way of doing this by using a forward definition: defer sort :noname ( ... ) recursive partition sort sort ; is sort This also works with mutually recursive words. RECURSIVE is even more pointless than RECURSE . Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-27 15:34 +0000 |
| Message-ID | <2014Jan27.163418@mips.complang.tuwien.ac.at> |
| In reply to | #28094 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> But :NONAME is the only thing where RECURSE really makes sense. For
>> named words, using RECURSIVE is preferable:
>>
>> : sort ( ... ) recursive
>> partition sort sort ;
>
>We already have a perfectly good way of doing this by using a forward
>definition:
>
>defer sort
>:noname ( ... ) recursive
> partition sort sort ; is sort
That works, but is a little slower (direct call vs. memory fetch and
indirect call).
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2014-01-24 08:11 +0100 |
| Message-ID | <858uu57t21.fsf@junk.nocrew.org> |
| In reply to | #28042 |
"Rod Pemberton" <dont_use_email@xnohavenotit.cnm> writes: > The issue is my RECURSE uses LAST which in my system points to the > start of the dictionary header (not LFA) to find the CFA which is > my XT. [Which doesn't work with :NONAME.] You could make your RECURSE use the latest created xt instead. E.g. gforth has both LATEST, which returns a name token like your LAST, and LATESTXT, which returns an xt. http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Name-token.html http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Anonymous-Definitions.html
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2014-01-24 01:28 -0800 |
| Message-ID | <f8e6bfe8-2e47-49f8-8401-62bb2a1c3f5a@googlegroups.com> |
| In reply to | #28042 |
I think the RECURSE with :NONAME issue is fairly easy to work around, Rod. You currently read LATEST to get to the CFA of the last defined word (maybe you convert from a link field address to a CFA, no matter). That all seems correct to me. But with a small change to ; :NONAME and RECURSE you can solve the problem: Define an extra variable, called NoNameCFA. RECURSE will use this to determine if a :NONAME definition is currently being built. Modify ; to zero out the NoNameCFA variable: : ; 0 NoNameCFA ! <exisiting-code> ; IMMEDIATE Modify :NONAME such that it loads NoNameCFA with the CFA of the NONAME definition currently under construction, which will be easy to compute. It's probably just HERE. : :NONAME HERE @ NoNameCFA ! <existing-code> ; Now, RECURSE, which is IMMEDIATE, checks NoNameCFA before checking LATEST: : RECURSE ( -- ) NoNameCFA @ DUP IF , ELSE DROP LATEST @ >CFA , THEN ; IMMEDIATE Et voila. The new code in ; will zero out NoNameCFA at the end of the NONAME definition, so RECURSE will work in the next colon definition: : THING 1000 RND RECURSE ; See? When RECURSE (being immediate) executes in this colon definition, NoNameCFA was 0, because the terminating ; in the previous NONAME zero'd it. Thus RECURSE will use the ELSE leg of it's code, and compile a reference via LATEST. Hope my rambling makes sense! Mark
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-24 05:00 -0500 |
| Message-ID | <op.w96re5tr5zc71u@localhost> |
| In reply to | #28052 |
On Fri, 24 Jan 2014 04:28:46 -0500, Mark Wills <markrobertwills@yahoo.co.uk> wrote: > I think the RECURSE with :NONAME issue is fairly easy to work around, > Rod. > > You currently read LATEST to get to the CFA of the last defined word > (maybe you convert from a link field address to a CFA, no matter). That > all seems correct to me. But with a small change to ; :NONAME and > RECURSE you can solve the problem: > > Define an extra variable, called NoNameCFA. RECURSE will use this to > determine if a :NONAME definition is currently being built. > > Modify ; to zero out the NoNameCFA variable: > > : ; 0 NoNameCFA ! <exisiting-code> ; IMMEDIATE > > Modify :NONAME such that it loads NoNameCFA with the CFA of the NONAME > definition currently under construction, which will be easy to compute. > It's probably just HERE. > > : :NONAME HERE @ NoNameCFA ! <existing-code> ; > > Now, RECURSE, which is IMMEDIATE, checks NoNameCFA before checking > LATEST: > > : RECURSE ( -- ) > NoNameCFA @ DUP IF , ELSE DROP LATEST @ >CFA , THEN ; IMMEDIATE > > Et voila. > > The new code in ; will zero out NoNameCFA at the end of the NONAME > definition, so RECURSE will work in the next colon definition: > > : THING 1000 RND RECURSE ; > > See? When RECURSE (being immediate) executes in this colon definition, > NoNameCFA was 0, because the terminating ; in the previous NONAME zero'd > it. Thus RECURSE will use the ELSE leg of it's code, and compile a > reference via LATEST. > > Hope my rambling makes sense! Well, I was considering something like using LAST with LATESTXT. Perhaps it should be called LASTXT since I'm using LAST instead of LATEST ... ? Lars mentioned it for Gforth, but it was also mentioned in regards to Win32Forth by Alex. This was in the 2012 thread (June ?) where you brought up the issue with :NONAME and RECURSE. Without a header on :NONAME , it seems to really need another variable to keep track of the XT for RECURSE , if you want RECURSE to work with :NONAME . LATESTXT or somesuch variable ( LASTXT or perhaps RCRS) seems to be LAST , but it's also updated for the CFA to a :NONAME definition. For : , I was considering just copying LAST into the new variable. For :NONAME , I was considering copying HERE into the new variable. For RECURSE , I was considering changing it to use the new variable instead of using LAST. I think that would be sufficient. I can't attempt this for a while. I've got to back out and fix all the other stuff... HTH, Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-24 09:32 -1000 |
| Message-ID | <ZsqdnfkahN5MIn_PnZ2dnUVZ_qidnZ2d@supernews.com> |
| In reply to | #28056 |
On 1/24/14 12:00 AM, Rod Pemberton wrote: > On Fri, 24 Jan 2014 04:28:46 -0500, Mark Wills > <markrobertwills@yahoo.co.uk> wrote: > >> I think the RECURSE with :NONAME issue is fairly easy to work around, >> Rod. >> >> You currently read LATEST to get to the CFA of the last defined word >> (maybe you convert from a link field address to a CFA, no matter). >> That all seems correct to me. But with a small change to ; :NONAME and >> RECURSE you can solve the problem: >> >> Define an extra variable, called NoNameCFA. RECURSE will use this to >> determine if a :NONAME definition is currently being built. >> >> Modify ; to zero out the NoNameCFA variable: >> >> : ; 0 NoNameCFA ! <exisiting-code> ; IMMEDIATE >> >> Modify :NONAME such that it loads NoNameCFA with the CFA of the NONAME >> definition currently under construction, which will be easy to >> compute. It's probably just HERE. >> >> : :NONAME HERE @ NoNameCFA ! <existing-code> ; >> >> Now, RECURSE, which is IMMEDIATE, checks NoNameCFA before checking >> LATEST: >> >> : RECURSE ( -- ) >> NoNameCFA @ DUP IF , ELSE DROP LATEST @ >CFA , THEN ; IMMEDIATE >> >> Et voila. >> >> The new code in ; will zero out NoNameCFA at the end of the NONAME >> definition, so RECURSE will work in the next colon definition: >> >> : THING 1000 RND RECURSE ; >> >> See? When RECURSE (being immediate) executes in this colon definition, >> NoNameCFA was 0, because the terminating ; in the previous NONAME >> zero'd it. Thus RECURSE will use the ELSE leg of it's code, and >> compile a reference via LATEST. >> >> Hope my rambling makes sense! > > Well, I was considering something like using LAST with LATESTXT. > Perhaps it should be called LASTXT since I'm using LAST instead > of LATEST ... ? Sure. We have 3 suggestions now in this thread (and it's been discussed in other threads on this topic in the past) to keep a separate LASTXT variable, whose sole purpose AFAIK is to enable RECURSE in :NONAME. Personally, I have never used :NONAME or RECURSE, although I have seen a few worthwhile uses of RECURSE by others in normal colon definitions. I would be reluctant to complicate the compiler in this way to support such an unlikely requirement, especially since there's a very simple workaround should the need arise. Cheers, Eizabeth -- ================================================== 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 | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-24 17:48 -0500 |
| Message-ID | <op.w97qyza75zc71u@localhost> |
| In reply to | #28056 |
On Fri, 24 Jan 2014 05:00:31 -0500, Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote: > On Fri, 24 Jan 2014 04:28:46 -0500, Mark Wills > <markrobertwills@yahoo.co.uk> wrote: >> I think the RECURSE with :NONAME issue is fairly easy to work around, >> Rod. >> [...] > > [...] > > I think that would be sufficient. I can't attempt this for a while. > I've got to back out and fix all the other stuff... > Ms. Rather recommends *not* using an additional variable because of the impact and/or insignificance. Can't be done with less impact? E.g., save LAST on stack when entering :NONAME, update LAST to HERE (or appropriate value) for use by RECURSE within :NONAME, then restore LAST from stack when exiting :NONAME. Yes? I decided to check to see where LAST is used in my system in case adding LATESTXT or somesuch would cause problems with other words. In my system, it seems LAST is only used within words that modify a dictionary header, except for RECURSE. That could also imply RECURSE shouldn't be useable with :NONAME. The words where I use LAST are IMMEDIATE SMUDGE DOES> COLD WORDS (CREATE) and some custom words. COLD just sets an initial value for LAST. (CREATE) and DOES> modify the header. IMMEDIATE and SMUDGE sets bits in the header. WORDS uses LAST to find the last entry in the dictionary chain. It doesn't need to find :NONAMEs. So, since :NONAME isn't supposed to have a header, then none of those words should be used with :NONAME. I.e., IMMEDIATE shouldn't be used with :NONAME since it modifies a header. Correct? The question is whether it's legal for a :NONAME definition be marked with IMMEDIATE in Forth? Is that valid? If so, that's more indication that a header is needed for :NONAME. I hope the answer to that is: "No." since that would begin to confuse me on things, again... But, then again, it seems odd to me that I couldn't mark a :NONAME definition as IMMEDIATE. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-01-24 13:14 -1000 |
| Message-ID | <6oCdndZpGcdRbn_PnZ2dnUVZ_jWdnZ2d@supernews.com> |
| In reply to | #28079 |
On 1/24/14 12:48 PM, Rod Pemberton wrote: >... > So, since :NONAME isn't supposed to have a header, > then none of those words should be used with :NONAME. > I.e., IMMEDIATE shouldn't be used with :NONAME since > it modifies a header. Correct? The *purpose* of IMMEDIATE is to cause it to be executed when its *name* is *encountered* inside a colon definition. What does this tell you? 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 | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2014-01-24 16:16 -0800 |
| Message-ID | <d046a706-84e7-4ad6-9bb2-63a949f77988@googlegroups.com> |
| In reply to | #28079 |
A noname definition cannot be immediate. For Two reasons: 1) there's no header so no immediate flag can be set 2) the purpose of an immediate word is to have it execute while another definition is compiling. And how do we actually do that? by referring to the immediate word *by name* in the word under construction. Since the word has no name, you can't execute it in an immediate sense. In *some* systems you may be able to do this: :noname <some code> ; : thing <some code> [ execute ] <more code> ; But that would not be portable since systems are entitled to carry colon-sys data on the stack. At least in ANS. It's also obscenely torturous code, to say the least! HTH
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-23 12:13 -0500 |
| Message-ID | <op.xbqvg5s85zc71u@localhost> |
| In reply to | #28000 |
On Wed, 22 Jan 2014 00:21:23 -0500, Elizabeth D. Rather <erather@forth.com> wrote: > On 1/21/14 5:04 PM, Rod Pemberton wrote: >> Yes. Thanks. I'm thinking what you said earlier should work. > > Yay. I hope your code cleans up a lot as a result. > Fixed. Seems so. I hope. I corrected high-level definitions for CREATE :NONAME (and eventually for the high-level definitions of : colon and ; semis). I implemented (CREATE) based on my incorrect definition for :NONAME and parts from other related defs, and older versions in my backups. I found one bug too ... :NONAME's no longer have a dictionary header. Other words are correctly linked around :NONAME's dictionary space, don't overwrite it's space, etc. I implemented LATESTXT. LATESTXT is updated with LAST everywhere LAST is stored, and also set to HERE in :NONAME. I changed RECURSE to use LATESTXT instead of LAST and updated RECURSE to compile R> DROP to not overflow the return stack. This was caused from numerous ENTER (or DOCOL) from recursing without an EXIT (or SEMIS). I had that previously but backed it out at some point for reasons unknown now. I had hoped to not use LATESTXT by just temporarily updating LAST , but the value it needed to be preserved for too long. It would've had to have stayed set until ; semis and then reset to it's prior value. That appeared to lead to a coding mess. I.e., how do you know when to reset or leave it alone? ... I think Mark Wills was running into this. I did run into an issue with DOVAR. Actually, it affects DOVAR DODOES and ENTER (or DOCOL) or any other CFA field address. I can set them up as routines ((non-existant i.e., just returns address) or as constants. E.g., I can make DOVAR work for either of these def's, but not both: : CREATE (CREATE) COMPILE DOVAR ; \ DOVAR address as a routine : CREATE (CREATE) DOVAR , ; \ DOVAR address as a constant When setup as a constant, they don't crash my system when entered interactively. I *cannot* install a fake do-nothing routine for them when setup as a routine, i.e., they will crash if used interactively. They're only used when compiled or comma'd into a definition's CFA. Or, at least, I can't think of a non-CFA use for them ... So, I went with constants for now. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-22 13:32 +0000 |
| Message-ID | <2014Jan22.143231@mips.complang.tuwien.ac.at> |
| In reply to | #27998 |
"Rod Pemberton" <dont_use_email@xnohavenotit.cnm> writes:
>Ah, the CFA is not part of the header... So, words still have a CFA
>without the header.
The code field (if the system uses CFs) certainly is not part of the
body; some people call it the neck, some consider it part of the
header. In any case, whether you consider it part of the body or
not,, the code field (if the system uses CFs) is needed for a :NONAME
word, whereas name, link, etc. are not necessary for :NONAME 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2014-01-20 04:14 -0800 |
| Message-ID | <54fa7c6e-1e51-4a8d-be62-8d3984cf7236@googlegroups.com> |
| In reply to | #27967 |
On Monday, January 20, 2014 5:27:13 AM UTC, Rod Pemberton wrote: > In most Forths, : calls CREATE to build the header > and insert the name the word being defined. After > CREATE is finished, the colon definition continues > compiling until ; . > from :NONAME also. No. : et al will not use CREATE to build the header, because CREATE, in addition to building the header, associates a behaviour with the newly created entry. If it were a colon definition under construction, that would mean you would have to back up the current compilation address (HERE) to overwrite that (incorrect) behaviour. All words that create an entry in the dictionary use a word such as HEADER which creates the entry, and links it to the previous entry, and updates LATEST. That's it. No behaviour is (currently) associated with the word. That would be the next step. CREATE : VARIABLE CONSTANT VALUE et al all use HEADER to create the dictionary entry and link the dictionary. It's a very useful factor. If your system is not currently set up in such a way it may be worth revising it. HEADER is a very useful word indeed.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-20 06:31 -0600 |
| Message-ID | <maCdnYXz5qi3ikDPnZ2dnUVZ_g6dnZ2d@supernews.com> |
| In reply to | #27973 |
Mark Wills <markrobertwills@yahoo.co.uk> wrote: > On Monday, January 20, 2014 5:27:13 AM UTC, Rod Pemberton wrote: >> In most Forths, : calls CREATE to build the header >> and insert the name the word being defined. After >> CREATE is finished, the colon definition continues >> compiling until ; . >> from :NONAME also. > > No. : et al will not use CREATE to build the header, because CREATE, > in addition to building the header, associates a behaviour with the > newly created entry. If it were a colon definition under > construction, that would mean you would have to back up the current > compilation address (HERE) to overwrite that (incorrect) behaviour. So what? You have to allocate space for the code field (assuming it's a threaded implementation) and you can either do that by allotting an uninitialized cell or comma-ing the runtime behaviour of CREATE. It's a pretty minor optimization decision, and I'm not sure it's worth creating a special word HEADER for. YMMV, etc. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2014-01-20 08:04 -1000 |
| Message-ID | <W4GdnRlFD8Hb-EDPnZ2dnUVZ_qmdnZ2d@supernews.com> |
| In reply to | #27974 |
On 1/20/2014 2:31 AM, Andrew Haley wrote: > Mark Wills <markrobertwills@yahoo.co.uk> wrote: >> On Monday, January 20, 2014 5:27:13 AM UTC, Rod Pemberton wrote: >>> In most Forths, : calls CREATE to build the header >>> and insert the name the word being defined. After >>> CREATE is finished, the colon definition continues >>> compiling until ; . >>> from :NONAME also. >> >> No. : et al will not use CREATE to build the header, because CREATE, >> in addition to building the header, associates a behaviour with the >> newly created entry. If it were a colon definition under >> construction, that would mean you would have to back up the current >> compilation address (HERE) to overwrite that (incorrect) behaviour. > > So what? You have to allocate space for the code field (assuming it's > a threaded implementation) and you can either do that by allotting an > uninitialized cell or comma-ing the runtime behaviour of CREATE. It's > a pretty minor optimization decision, and I'm not sure it's worth > creating a special word HEADER for. YMMV, etc. FWIW, FORTH, Inc. has used such a factor for many years, called (CREATE) following our naming convention of (name) for a major factor of name. Depending on the implementation, this word may have a lot to do in addition to building the actual head: storing source data, wordlist linking, etc. But it is inherently implementation specific, and thus should be immune from standardization, IMO. This discussion is a good example of why it is advisable to examine other implementations before setting out to write one's own. 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-21 14:09 +0000 |
| Message-ID | <2014Jan21.150921@mips.complang.tuwien.ac.at> |
| In reply to | #27977 |
Elizabeth D Rather <erather@forth.com> writes:
>FWIW, FORTH, Inc. has used such a factor for many years, called (CREATE)
>following our naming convention of (name) for a major factor of name.
>Depending on the implementation, this word may have a lot to do in
>addition to building the actual head: storing source data, wordlist
>linking, etc. But it is inherently implementation specific, and thus
>should be immune from standardization, IMO.
Anything that has not been standardized is implementation-specific.
If the functionality occurs in several systems, it may be worth
thinking about standardizing it, albeit not necessarily with the
interface that a particular system exposes.
As an example, when the 16-bit guarantee was removed, the cell size
turned into an (inherently?) implementation specific feature. Various
systems implemented provided words like 2+ 2* or 4+ 4* to deal with
that, but these words were obviously too implementation-specific to be
standardized for address arithmetic (2* was still standardized as
shift-left); instead, CELL+ and CELL* were standardized.
- 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 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-01-20 16:14 -0500 |
| Message-ID | <op.w9z7y3y65zc71u@localhost> |
| In reply to | #27973 |
On Mon, 20 Jan 2014 07:14:31 -0500, Mark Wills <markrobertwills@yahoo.co.uk> wrote: > On Monday, January 20, 2014 5:27:13 AM UTC, Rod Pemberton wrote: >> In most Forths, : calls CREATE to build the header >> and insert the name the word being defined. After >> CREATE is finished, the colon definition continues >> compiling until ; . >> from :NONAME also. > > No. : et al will not use CREATE to build the header, because CREATE, in > addition to building the header, associates a behaviour with the newly > created entry. If it were a colon definition under construction, that > would mean you would have to back up the current compilation address > (HERE) to overwrite that (incorrect) behaviour. > > All words that create an entry in the dictionary use a word such as > HEADER which creates the entry, and links it to the previous entry, and > updates LATEST. That's it. No behaviour is (currently) associated with > the word. That would be the next step. > Hmm, it's been a while since I wrote the code, but I'm thinking I'm using :NONAME as both :NONAME and HEADER. Yes, I move the dictionary pointer to CFA and reset it's location. See my reply to Ms. Rather for more. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | trebor.english@gmail.com |
|---|---|
| Date | 2014-01-22 17:44 -0800 |
| Message-ID | <c7da9bd7-28b8-455f-958a-757e617db703@googlegroups.com> |
| In reply to | #27952 |
On Sunday, January 19, 2014 1:15:44 PM UTC-5, Rod Pemberton wrote: > Okay, let's see if I get this correct ... > > > > <BUILDS originally worked with DOES> . > > <BUILDS was defined as 0 CONSTANT in fig-Forth. > > CONSTANT used an early limited version of > > CREATE to build a dictionary header. > > Then, <BUILDS was obsoleted, and CREATE > > was enhanced to work in place of both the > > limited CREATE and <BUILDS. That gave rise > > to CREATE ... DOES> . Next, :NONAME was > > created to essentially do what the early > > limited CREATE did but without writing a name > > into the dictionary header. Many systems also > > have a non-standard word HEADER to do this too. > > Now, you guys are wanting to restore the original > > <BUILDS because the more powerful CREATE doesn't > > work as well in embedded systems that use flash > > memory, have limited writes, and separate address > > spaces. > > > > Is this correct? > > > > Why does it feel like I'm going around in circles? > > > > Is this a prime example of poor factoring? > > > > Can <BUILDS now be constructed with :NONAME ? > > > > > > Rod Pemberton Any mention of :NONAME is spurious. The purpose of CREATE and <BUILDS is to add a header to the dictionary. This means to put a byte count and some or all of the letters of the name into the dictionary. The new header is made findable by updating a word list to include the new header in the list of words. The point of :NONAME is to compile headless unfindable code leaving the XT on the stack. If you drop that XT there is no way to get it back. No name, no byte count, no link to the prior entry, no word list update to point to it. The new code can be indirect threaded code pointers or machine code, or tokens, or whatever. It is probably dumped into memory right after the previous definition. CREATE cannot be made out of :NONAME and :NONAME cannot be made out of CREATE.
[toc] | [prev] | [next] | [standalone]
| From | trebor.english@gmail.com |
|---|---|
| Date | 2014-01-22 18:24 -0800 |
| Message-ID | <a9515cf3-de28-462c-a9a1-18056d65b655@googlegroups.com> |
| In reply to | #27952 |
On Sunday, January 19, 2014 1:15:44 PM UTC-5, Rod Pemberton wrote: > Okay, let's see if I get this correct ... > > > > <BUILDS originally worked with DOES> . > > <BUILDS was defined as 0 CONSTANT in fig-Forth. > > CONSTANT used an early limited version of > > CREATE to build a dictionary header. > > Then, <BUILDS was obsoleted, and CREATE > > was enhanced to work in place of both the > > limited CREATE and <BUILDS. That gave rise > > to CREATE ... DOES> . Next, :NONAME was > > created to essentially do what the early > > limited CREATE did but without writing a name > > into the dictionary header. Many systems also > > have a non-standard word HEADER to do this too. > > Now, you guys are wanting to restore the original > > <BUILDS because the more powerful CREATE doesn't > > work as well in embedded systems that use flash > > memory, have limited writes, and separate address > > spaces. > > > > Is this correct? > > > > Why does it feel like I'm going around in circles? > > > > Is this a prime example of poor factoring? > > > > Can <BUILDS now be constructed with :NONAME ? > > > > > > Rod Pemberton Way back in the 1970s minicomputers like PDP8s, PDP11s, and Varian 620s used core memory. It is persistent. When you turn the machine on the memory still has the same stuff in it. It is rewriteable. You can write new data over the old data as much as you want. Forth Inc's microFORTH and FIG Forth, and many others built the dictionary using as little code as possible. Variables, constants, and colon definitions share a dictionary structure. The order of the building in these systems was to first put the name's byte count and some, maybe just three, or all of the bytes of the name at the end of the dictionary being constructed. A previously defined word like constant or variable did that virtually for free. Then, depending on the word being defined, things got changed to accommodate. For a colon definition the smudge bit was set to keep the name from being found until the definition was complete. The code field was reset to point to the code for entry into a colon definition. After compiling was complete the smudge bit was turned off. Now, fast forward 30 years, flash memory is plentiful and can't be rewritten. It is not possible to put the byte count in the flash then turn on the smudge bit then later turn off the smudge bit. It is not possible to point the code field to the run time code for constant then overwrite it with a pointer to the colon definition entry code. Similarly the IMMEDIATE bit can't be set to zero during the construction of a constant then later make it a one for an immediate colon definition. The standard requires a created word to behave as a variable, code field points to code to do that. DOES> is required to change it. The suggestion that started this discussion was to make a new order of compiling things so that rewriting isn't necessary. A new word modeled after the ancient, no longer standard, <BUILDS could be used to put things in flash only when the information is known and won't need to be changed. The writing of the code field could be delayed, not part of <BUILDS the way it is part of CREATE. DOES> could put in what it needs. ;CODE could put in what it needs. What has worked for me is to add the word to the word list when done, not use smudge to hide it. This works if you have a single linked list or a hash table to speed up searches. I prefer to have the immediate bit be 1 for regular words and cleared for immediate words. That way there is no need to change it from 0 to 1. The remaining hard part is the code field. CREATE must set it. My <BUILDS just steps over it. DOES> sets it once.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web