Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #28625 > unrolled thread
| Started by | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| First post | 2014-02-20 16:30 -0500 |
| Last post | 2014-03-08 18:40 -0500 |
| Articles | 20 on this page of 36 — 16 participants |
Back to article view | Back to comp.lang.forth
top 10 words which should *not* be in a Forth dictionary? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-20 16:30 -0500
Re: top 10 words which should *not* be in a Forth dictionary? AKK <akk@nospam.org> - 2014-02-20 23:56 +0100
Re: top 10 words which should *not* be in a Forth dictionary? Coos Haak <chforth@hccnet.nl> - 2014-02-21 02:40 +0100
Re: top 10 words which should *not* be in a Forth dictionary? hughaguilar96@yahoo.com - 2014-02-20 21:17 -0800
Re: top 10 words which should *not* be in a Forth dictionary? Syd Rumpo <usenet@nononono.co.uk> - 2014-02-21 13:58 +0000
Re: top 10 words which should *not* be in a Forth dictionary? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-21 11:04 +0000
Re: top 10 words which should *not* be in a Forth dictionary? Hans Bezemer <the.beez.speaks@gmail.com> - 2014-02-22 17:10 +0100
Re: top 10 words which should *not* be in a Forth dictionary? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 13:15 -0600
Re: top 10 words which should *not* be in a Forth dictionary? "Alex McDonald" <blog@rivadpm.com> - 2014-02-22 21:46 +0000
Re: top 10 words which should *not* be in a Forth dictionary? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-23 15:42 +0000
Re: top 10 words which should *not* be in a Forth dictionary? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-23 15:46 +0000
Re: top 10 words which should *not* be in a Forth dictionary? Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-03-03 12:08 -0800
Re: top 10 words which should *not* be in a Forth dictionary? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-03 20:23 +0000
Re: top 10 words which should *not* be in a Forth dictionary? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-03 15:58 -0600
Re: top 10 words which should *not* be in a Forth dictionary? Coos Haak <chforth@hccnet.nl> - 2014-03-04 01:06 +0100
Re: top 10 words which should *not* be in a Forth dictionary? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:01 +0000
Re: top 10 words which should *not* be in a Forth dictionary? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-06 17:59 -0600
Re: top 10 words which should *not* be in a Forth dictionary? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 11:34 +0000
Re: top 10 words which should *not* be in a Forth dictionary? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-07 06:43 -0600
Re: top 10 words which should *not* be in a Forth dictionary? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:07 +0000
Re: top 10 words which should *not* be in a Forth dictionary? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-07 08:41 -0600
Re: top 10 words which should *not* be in a Forth dictionary? Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-03-07 10:17 -0800
Re: top 10 words which should *not* be in a Forth dictionary? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-07 13:10 -0600
Re: top 10 words which should *not* be in a Forth dictionary? Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-03-07 11:32 -0800
Re: top 10 words which should *not* be in a Forth dictionary? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-03-07 14:28 +0100
Re: top 10 words which should *not* be in a Forth dictionary? Assad Ebrahim <assadebrahim2000@gmail.com> - 2014-03-07 22:59 -0800
Re: top 10 words which should *not* be in a Forth dictionary? Coos Haak <chforth@hccnet.nl> - 2014-03-08 08:33 +0100
Re: top 10 words which should *not* be in a Forth dictionary? "Elizabeth D. Rather" <erather@forth.com> - 2014-03-07 23:21 -1000
Re: top 10 words which should *not* be in a Forth dictionary? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-08 04:30 -0600
top 10 words which should *not* be in a Forth dictionary? Mark Wills <markwills1970@gmail.com> - 2014-03-08 03:27 -0800
Re: top 10 words which should *not* be in a Forth dictionary? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-08 05:36 -0600
Re: top 10 words which should *not* be in a Forth dictionary? Mark Wills <markwills1970@gmail.com> - 2014-03-08 15:39 -0800
Re: top 10 words which should *not* be in a Forth dictionary? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-08 14:02 +0000
Re: top 10 words which should *not* be in a Forth dictionary? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-08 17:20 -0500
Re: top 10 words which should *not* be in a Forth dictionary? "Elizabeth D. Rather" <erather@forth.com> - 2014-03-08 12:36 -1000
Re: top 10 words which should *not* be in a Forth dictionary? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-08 18:40 -0500
Page 1 of 2 [1] 2 Next page →
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2014-02-20 16:30 -0500 |
| Subject | top 10 words which should *not* be in a Forth dictionary? |
| Message-ID | <op.xblncrex5zc71u@localhost> |
What would be a top ten list of commonly used Forth words that should NOT be part of a Forth dictionary? (And, why?) There are a variety non-standard Forth words that are commonly used. It's clear many of them should be defined since they're commonly used, but its' also clear some of them shouldn't be. E.g., ANS doesn't define CELL but it's commonly used and easy to define. The question is whether CELL should be defined or not. Are there valid reasons to not define CELL ? E.g., does using CELL encourage people to not use CELLS or CELL+ ? And, does that lead to errors? I'm sure there are other words that should be avoided in Forth too which are commonly implemented. Some of those are obsolete words from old Forth standards and fig-Forth. Recently, there was mention of DRIP DIP NUP TAKE or equivalents, but are thosed common enough to be top 10? Rod Pemberton
[toc] | [next] | [standalone]
| From | AKK <akk@nospam.org> |
|---|---|
| Date | 2014-02-20 23:56 +0100 |
| Message-ID | <53068833$0$9523$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #28625 |
Am 20.02.2014 22:30, schrieb Rod Pemberton: > > What would be a top ten list of commonly used Forth words that should > NOT be part of a Forth dictionary? (And, why?) > > There are a variety non-standard Forth words that are commonly used. > It's clear many of them should be defined since they're commonly used, > but its' also clear some of them shouldn't be. > > E.g., ANS doesn't define CELL but it's commonly used and easy to define. > The question is whether CELL should be defined or not. Are there valid > reasons to not define CELL ? E.g., does using CELL encourage people to > not use CELLS or CELL+ ? And, does that lead to errors? > > I'm sure there are other words that should be avoided in Forth too which > are commonly implemented. Some of those are obsolete words from old Forth > standards and fig-Forth. > > Recently, there was mention of DRIP DIP NUP TAKE or equivalents, but are > thosed common enough to be top 10? > > > Rod Pemberton OK I'll bite: ;-) TO because it shouldn't be ticked BASE because formatted I/O would be better, and it needs to be initialized and monitored STATE because users shouldn't tinker with it POSTPONE because it is weird SM/REM and FM/MOD because one of them is too much 2/ if all you want to do is shifting bits UNLOOP because the compiler should solve that automagically WORD because a space follows the string LOCALS| because locals are 1) in false order and 2) sneered at
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-02-21 02:40 +0100 |
| Message-ID | <1aieeoq9mj0rg.hzlmyq15cdr9$.dlg@40tude.net> |
| In reply to | #28628 |
Op Thu, 20 Feb 2014 23:56:55 +0100 schreef AKK: > UNLOOP because the compiler should solve that automagically How, does the compiler in advance know that I wrote one, two, more or no UNLOOPs in my DO-LOOP? > > WORD because a space follows the string No, because it leaves a counted string. PARSE-NAME leaves the address and count on the stack, pointing into the input buffer, so no CMOVE to a weird place is needed. According to Forth 2012 RC2 the space is not required anymore. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-02-20 21:17 -0800 |
| Message-ID | <d6d94244-a52a-4cda-8104-b27b095e9319@googlegroups.com> |
| In reply to | #28628 |
On Thursday, February 20, 2014 3:56:55 PM UTC-7, AKK wrote: > POSTPONE because it is weird All of my definers in the novice package use POSTPONE --- I don't use CREATE DOES> at all. YOU don't have to use POSTPONE though --- you can use the novice package and just use the definers that I have provided, without worrying about how they work under the hood.
[toc] | [prev] | [next] | [standalone]
| From | Syd Rumpo <usenet@nononono.co.uk> |
|---|---|
| Date | 2014-02-21 13:58 +0000 |
| Message-ID | <le7m13$t8n$1@dont-email.me> |
| In reply to | #28628 |
On 20/02/2014 22:56, AKK wrote: > Am 20.02.2014 22:30, schrieb Rod Pemberton: >> >> What would be a top ten list of commonly used Forth words that should >> NOT be part of a Forth dictionary? (And, why?) >> >> There are a variety non-standard Forth words that are commonly used. >> It's clear many of them should be defined since they're commonly used, >> but its' also clear some of them shouldn't be. >> >> E.g., ANS doesn't define CELL but it's commonly used and easy to define. >> The question is whether CELL should be defined or not. Are there valid >> reasons to not define CELL ? E.g., does using CELL encourage people to >> not use CELLS or CELL+ ? And, does that lead to errors? >> >> I'm sure there are other words that should be avoided in Forth too which >> are commonly implemented. Some of those are obsolete words from old >> Forth >> standards and fig-Forth. >> >> Recently, there was mention of DRIP DIP NUP TAKE or equivalents, but are >> thosed common enough to be top 10? >> >> >> Rod Pemberton > > OK I'll bite: ;-) > > TO because it shouldn't be ticked > > BASE because formatted I/O would be better, and it needs to be > initialized and monitored <snip> Absolutely. BASE is a potential disaster. Just as you use different versions of, say, * depending on the input types and what you want to achieve, so you should use different words to print numbers in different bases. And the number base should always be part of the number in the source, as in 0xB234 $B234 #1234 %1010 or whatever your convention is. Cheers -- Syd
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2014-02-21 11:04 +0000 |
| Message-ID | <le7bs5$4tl$1@dont-email.me> |
| In reply to | #28625 |
On 20/02/2014 21:30, Rod Pemberton wrote: > > What would be a top ten list of commonly used Forth words that should > NOT be part of a Forth dictionary? (And, why?) > > There are a variety non-standard Forth words that are commonly used. > It's clear many of them should be defined since they're commonly used, > but its' also clear some of them shouldn't be. > > E.g., ANS doesn't define CELL but it's commonly used and easy to define. > The question is whether CELL should be defined or not. Are there valid > reasons to not define CELL ? E.g., does using CELL encourage people to > not use CELLS or CELL+ ? And, does that lead to errors? > > I'm sure there are other words that should be avoided in Forth too which > are commonly implemented. Some of those are obsolete words from old Forth > standards and fig-Forth. > > Recently, there was mention of DRIP DIP NUP TAKE or equivalents, but are > thosed common enough to be top 10? > > > Rod Pemberton The whole of the Block word set, an anachronism. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2014-02-22 17:10 +0100 |
| Message-ID | <5308cc06$0$2857$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #28625 |
Rod Pemberton wrote: PICK, ROLL - for reasons Brodie mentioned CASE, OF, ENDOF ENDCASE - for reasons Brodie mentioned ?DUP - for leaving an uneven stack diagram WORD, FIND, C" - for being relics from the counted string era I'll overdo my 10 here: ?DO, DO, LOOP, +LOOP, LEAVE, UNLOOP For making such an incredible mess of simple looping. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-02-22 13:15 -0600 |
| Message-ID | <abWdnT3FpOHOapXOnZ2dnUVZ8nydnZ2d@supernews.com> |
| In reply to | #28690 |
Hans Bezemer <the.beez.speaks@gmail.com> wrote: > > PICK, ROLL - for reasons Brodie mentioned > CASE, OF, ENDOF ENDCASE - for reasons Brodie mentioned > ?DUP - for leaving an uneven stack diagram > WORD, FIND, C" - for being relics from the counted string era > > I'll overdo my 10 here: > > ?DO, DO, LOOP, +LOOP, LEAVE, UNLOOP > > For making such an incredible mess of simple looping. That's not a bad list, but I've always found ?DUP to be very useful and nice to read. A lot of people don't like it, I know. FIND is awkward, but you need something to search the dictionary. In the case of loops, I think DO is just badly-defined rather than being useless. I'd ditch RECURSE . Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2014-02-22 21:46 +0000 |
| Message-ID | <leb5qp$hs8$1@dont-email.me> |
| In reply to | #28694 |
on 22/02/2014 19:15:27, Andrew Haley wrote: > > FIND is awkward, but you need something to search the dictionary. I've implemented gforth's FIND-NAME ( c-addr u –- nt | 0 ) to get round the counted string requirement of FIND. One other advantage; it returns a name token instead of an xt.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-23 15:42 +0000 |
| Message-ID | <530a16de$0$9248$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #28695 |
In article <leb5qp$hs8$1@dont-email.me>,
Alex McDonald <blog@rivadpm.com> wrote:
>on 22/02/2014 19:15:27, Andrew Haley wrote:
>
>>
>> FIND is awkward, but you need something to search the dictionary.
>
>I've implemented gforth's FIND-NAME ( c-addr u –- nt | 0 ) to get round
>the counted string requirement of FIND. One other advantage; it returns a
>name token instead of an xt.
"gforth's FIND-NAME" was introduced 2001 march 11 in ciforth under the name
FOUND . It was present in RELEASE3CI of ciforth that was published on
2001 may 21 at the site below (see my sig.)
The concept of dea dictionary entry address ("name token") is much older
and goes back to the very first release of tForth (1993).
tForth is also published on the site below.
(A bit narcistic maybe, but I wanted to set the record straight...)
Groetjes Albert
>
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-02-23 15:46 +0000 |
| Message-ID | <530a17cd$0$9248$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #28694 |
In article <abWdnT3FpOHOapXOnZ2dnUVZ8nydnZ2d@supernews.com>, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: >Hans Bezemer <the.beez.speaks@gmail.com> wrote: >> >> PICK, ROLL - for reasons Brodie mentioned >> CASE, OF, ENDOF ENDCASE - for reasons Brodie mentioned >> ?DUP - for leaving an uneven stack diagram >> WORD, FIND, C" - for being relics from the counted string era >> >> I'll overdo my 10 here: >> >> ?DO, DO, LOOP, +LOOP, LEAVE, UNLOOP >> >> For making such an incredible mess of simple looping. > >That's not a bad list, but I've always found ?DUP to be very useful >and nice to read. A lot of people don't like it, I know. > >FIND is awkward, but you need something to search the dictionary. > >In the case of loops, I think DO is just badly-defined rather than >being useless. I'd say DO is bad but there seems to be no alternative. > >I'd ditch RECURSE . All thosed words have been ditched from yourforth, which is my attempt at a Reduced Instructions Forth. > >Andrew. -- 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 | Assad Ebrahim <assadebrahim2000@gmail.com> |
|---|---|
| Date | 2014-03-03 12:08 -0800 |
| Message-ID | <66b7f70d-4e82-4f25-8eb2-7f7eb3d2b6f5@googlegroups.com> |
| In reply to | #28694 |
On Saturday, February 22, 2014 7:15:31 PM UTC, Andrew Haley wrote: > > I'd ditch RECURSE . > Why would you ditch RECURSE? I'm going to assume there must be another way in Forth to write recursive algorithms without using RECURSE... If not, how would you code algorithms that are naturally recursive (e.g. BFS, DFS)? Assad
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-03-03 20:23 +0000 |
| Message-ID | <5314e4be$0$25048$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #28876 |
In article <66b7f70d-4e82-4f25-8eb2-7f7eb3d2b6f5@googlegroups.com>, Assad Ebrahim <assadebrahim2000@gmail.com> wrote: >On Saturday, February 22, 2014 7:15:31 PM UTC, Andrew Haley wrote: >> >> I'd ditch RECURSE . >> > >Why would you ditch RECURSE? I'm going to assume there must be another >way in Forth to write recursive algorithms without using RECURSE... If >not, how would you code algorithms that are naturally recursive (e.g. >BFS, DFS)? I can tell you why I don't have it in yourforth. It is for the same reason that there is no word like that in a very recursive language like LISP. If you're in PROC and you want to run PROC just say PROC. Either you recurse all the time and it is worth the effort to do something about it. Or it is incidental and then `` VECTOR @ EXECUTE '' is all you need, not a cludgy construct. > >Assad -- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-03-03 15:58 -0600 |
| Message-ID | <CKydnXPWBpSQZonOnZ2dnUVZ_oidnZ2d@supernews.com> |
| In reply to | #28876 |
Assad Ebrahim <assadebrahim2000@gmail.com> wrote:
> On Saturday, February 22, 2014 7:15:31 PM UTC, Andrew Haley wrote:
>>
>> I'd ditch RECURSE .
>>
>
> Why would you ditch RECURSE? I'm going to assume there must be
> another way in Forth to write recursive algorithms without using
> RECURSE...
I don't like RECURSE, partly because a phrase which uses it can't be
factored out of a definition. RECURSE is only needed for recursively
executing words that have no name, e.g. words created by :NONAME.
Usually, a recursive definition can use DEFER, and will read better
that way IMO. In other words, RECURSE only makes code worse.
> If not, how would you code algorithms that are naturally recursive
> (e.g. BFS, DFS)?
Here's DFS for a binary tree:
: inorder ( a)
0 swap
begin
begin ?dup while dup left @ repeat
?dup while
dup visit
right @
repeat ;
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2014-03-04 01:06 +0100 |
| Message-ID | <l2bit8bdaiaa$.10a1e16b9e97h$.dlg@40tude.net> |
| In reply to | #28880 |
Op Mon, 03 Mar 2014 15:58:37 -0600 schreef Andrew Haley: > I don't like RECURSE, partly because a phrase which uses it can't be > factored out of a definition. RECURSE is only needed for recursively > executing words that have no name, e.g. words created by :NONAME. > Usually, a recursive definition can use DEFER, and will read better > that way IMO. In other words, RECURSE only makes code worse. Like this: defer ! :noname dup if dup 1- ! * exit then 1+ ; is ! 6 ! . 720 -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-03-06 18:01 +0000 |
| Message-ID | <2014Mar6.190131@mips.complang.tuwien.ac.at> |
| In reply to | #28880 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Assad Ebrahim <assadebrahim2000@gmail.com> wrote:
>> On Saturday, February 22, 2014 7:15:31 PM UTC, Andrew Haley wrote:
>>>
>>> I'd ditch RECURSE .
>>>
>>
>> Why would you ditch RECURSE? I'm going to assume there must be
>> another way in Forth to write recursive algorithms without using
>> RECURSE...
>
>I don't like RECURSE, partly because a phrase which uses it can't be
>factored out of a definition. RECURSE is only needed for recursively
>executing words that have no name, e.g. words created by :NONAME.
>Usually, a recursive definition can use DEFER, and will read better
>that way IMO. In other words, RECURSE only makes code worse.
...
>: inorder ( a)
> 0 swap
> begin
> begin ?dup while dup left @ repeat
> ?dup while
> dup visit
> right @
> repeat ;
I miss the recursive call here.
- 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-03-06 17:59 -0600 |
| Message-ID | <2MOdnbgagstDloTOnZ2dnUVZ_qydnZ2d@supernews.com> |
| In reply to | #28935 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> Assad Ebrahim <assadebrahim2000@gmail.com> wrote: >>> On Saturday, February 22, 2014 7:15:31 PM UTC, Andrew Haley wrote: >>>> I'd ditch RECURSE . >>> >>> Why would you ditch RECURSE? I'm going to assume there must be >>> another way in Forth to write recursive algorithms without using >>> RECURSE... >> >> I don't like RECURSE, partly because a phrase which uses it can't be >> factored out of a definition. RECURSE is only needed for recursively >> executing words that have no name, e.g. words created by :NONAME. >> Usually, a recursive definition can use DEFER, and will read better >> that way IMO. In other words, RECURSE only makes code worse. >> >>> If not, how would you code algorithms that are naturally recursive >>> (e.g. BFS, DFS)? >> >> Here's DFS for a binary tree: >> >> : inorder ( a) >> 0 swap >> begin >> begin ?dup while dup left @ repeat >> ?dup while >> dup visit >> right @ >> repeat ; > > I miss the recursive call here. I do not understand what point you are trying to make. Are you asking a question, making a complaint, or what? Assad's question was "how would you code an algorithm that's naturally recursive (e.g. DFS) [without RECURSE]?" The question is not about how you would code a recursive definition, but a recursive algorithm. There are several valid ways of answering that. One is simply to use explicit recursion by using DEFER and :NONAME (I'd already explained that). A more interesting one is to show that Forth, because of the data stack, doesn't need recursion as often as some other languages do. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-03-07 11:34 +0000 |
| Message-ID | <2014Mar7.123439@mips.complang.tuwien.ac.at> |
| In reply to | #28939 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> Here's DFS for a binary tree:
>>>
>>> : inorder ( a)
>>> 0 swap
>>> begin
>>> begin ?dup while dup left @ repeat
>>> ?dup while
>>> dup visit
>>> right @
>>> repeat ;
>>
>> I miss the recursive call here.
>
>I do not understand what point you are trying to make. Are you asking
>a question, making a complaint, or what?
Something like that. Or pointing out a bug in your example. But it's
probably most productive if you treat it as question:
Where is the recursive call here?
> A more interesting one is to show that Forth, because of the
>data stack, doesn't need recursion as often as some other languages
>do.
Ok, if you wanted to show that, you totally failed to get that across,
by both writing obscure code, as well as not mentioning it at all in
the text.
- 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-03-07 06:43 -0600 |
| Message-ID | <gL6dnZ7lMJ6aIoTOnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #28950 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>> Here's DFS for a binary tree: >>>> >>>> : inorder ( a) >>>> 0 swap >>>> begin >>>> begin ?dup while dup left @ repeat >>>> ?dup while >>>> dup visit >>>> right @ >>>> repeat ; >>> >>> I miss the recursive call here. >> >>I do not understand what point you are trying to make. Are you asking >>a question, making a complaint, or what? > > Something like that. Or pointing out a bug in your example. But it's > probably most productive if you treat it as question: > > Where is the recursive call here? This question makes no sense. >>A more interesting one is to show that Forth, because of the data >>stack, doesn't need recursion as often as some other languages do. > > Ok, if you wanted to show that, you totally failed to get that across, > by both writing obscure code, as well as not mentioning it at all in > the text. Heh. I like the code. So there. Assad's question was "how would you code an algorithm that's naturally recursive (e.g. DFS) [without RECURSE]?" The example code above, being an implementation of a recursive algorithm without explicit recursion, is a valid answer to that question. It presumably is not the answer that you would have given, but that does not matter. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-03-07 13:07 +0000 |
| Message-ID | <2014Mar7.140704@mips.complang.tuwien.ac.at> |
| In reply to | #28951 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>> Here's DFS for a binary tree:
>>>>>
>>>>> : inorder ( a)
>>>>> 0 swap
>>>>> begin
>>>>> begin ?dup while dup left @ repeat
>>>>> ?dup while
>>>>> dup visit
>>>>> right @
>>>>> repeat ;
...
>> Ok, if you wanted to show that, you totally failed to get that across,
>> by both writing obscure code, as well as not mentioning it at all in
>> the text.
>
>Heh. I like the code. So there.
Ok, so you like undocumented code without stack comments, that call
unspecified words.
>Assad's question was "how would you code an algorithm that's naturally
>recursive (e.g. DFS) [without RECURSE]?" The example code above,
>being an implementation of a recursive algorithm without explicit
>recursion, is a valid answer to that question.
Sure, but an uncomprehensible answer is neither helpful for Assad nor
for everybody else.
- 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]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | comp.lang.forth
csiph-web