Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #28625 > unrolled thread

top 10 words which should *not* be in a Forth dictionary?

Started by"Rod Pemberton" <dont_use_email@xnohavenotit.cnm>
First post2014-02-20 16:30 -0500
Last post2014-03-08 18:40 -0500
Articles 20 on this page of 36 — 16 participants

Back to article view | Back to comp.lang.forth


Contents

  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 →


#28625 — top 10 words which should *not* be in a Forth dictionary?

From"Rod Pemberton" <dont_use_email@xnohavenotit.cnm>
Date2014-02-20 16:30 -0500
Subjecttop 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]


#28628

FromAKK <akk@nospam.org>
Date2014-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]


#28635

FromCoos Haak <chforth@hccnet.nl>
Date2014-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]


#28638

Fromhughaguilar96@yahoo.com
Date2014-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]


#28658

FromSyd Rumpo <usenet@nononono.co.uk>
Date2014-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]


#28648

FromGerry Jackson <gerry@jackson9000.fsnet.co.uk>
Date2014-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]


#28690

FromHans Bezemer <the.beez.speaks@gmail.com>
Date2014-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]


#28694

FromAndrew Haley <andrew29@littlepinkcloud.invalid>
Date2014-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]


#28695

From"Alex McDonald" <blog@rivadpm.com>
Date2014-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]


#28714

Fromalbert@spenarnc.xs4all.nl (Albert van der Horst)
Date2014-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]


#28715

Fromalbert@spenarnc.xs4all.nl (Albert van der Horst)
Date2014-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]


#28876

FromAssad Ebrahim <assadebrahim2000@gmail.com>
Date2014-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]


#28878

Fromalbert@spenarnc.xs4all.nl (Albert van der Horst)
Date2014-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]


#28880

FromAndrew Haley <andrew29@littlepinkcloud.invalid>
Date2014-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]


#28887

FromCoos Haak <chforth@hccnet.nl>
Date2014-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]


#28935

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2014-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]


#28939

FromAndrew Haley <andrew29@littlepinkcloud.invalid>
Date2014-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]


#28950

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2014-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]


#28951

FromAndrew Haley <andrew29@littlepinkcloud.invalid>
Date2014-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]


#28954

Fromanton@mips.complang.tuwien.ac.at (Anton Ertl)
Date2014-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