Path: utzoo!utgpu!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.lang.forth
Subject: Re: Thinking FORTH
Message-ID: <4424@cbmvax.UUCP>
Date: 5 Aug 88 03:54:48 GMT
References: <8807291946.AA14510@jade.berkeley.edu> <1552@crete.cs.glasgow.ac.uk>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 63

In article <1552@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes:
>>however.  At some point the overhead of a subroutine call makes smallness
>>impractical.  C's macro facility goes a long way toward alleviating
>
>This is a totally spurious point. The only differences between a forth
>subroutine call and a C call is that C has to make a stack frame
>(i.e., *allocate* a small amount of memory on the top of the stack),
>the parameters have to be put there in but languages, the return address
>has to be put in by both langnuages, the PC has to be set in both languages,
>in fact C calls are going to be at most 1usec slower than Forth ones,
>not in my opinion worth worrying about. This of course assumes that
>the forth program has been compiled onto a Forth microprocessor,
>if it's interpreted, well ...

	Wrong on multiple counts.  First, the use of a stack paradigm
reduces the amount of parameter pushing being done.  A lot of C-generated
code consists of retrieving values from the last stack fram and pushing
them onto the new one.  Good subroutine-threaded forth implementations
give up nothing to C on the same machine (for example, 68000).  Forth
can have optimizers too, no forth-chip needed.  I grant forth might be
a bit of a dog on a 8088, but it works well on a 68000 (auto-increment/
decrement, lots of registers to hold important values/stack ptrs, etc.)

>>that problem, though.  Yet even when I write what I feel is an
>>appropriately sized subroutine in C, it is still larger visually than
>>the corresponding FORTH program and therefore harder to grasp and
>>think about.  At this level we are talking about a small difference,
>
>:fact dup 0 gt else 1 then dup 1 sub fact if ;

 A few problems with that, try this:

 : fact		( n -- n!  - compute n!)
	dup >0 if
		dup 1- fact *
	else
		drop 1
	endif
 ;

More readable, isn't it?  Forth doesn't have to be unreadable, though
many old forth implementations which use blocks for source often are.

>vs
>int Fact ( n )
>{
>  if ( n > 0 )
>    return n*fact(n-1)
>  else
>    return 1 ;
>}
>
>If you find the former easier to understand, you've got a twisted
>mind! (PS apoligies for my forth, it has been a while since I wrote
>any, and after all it is not the most memorable syntax:^)

>who hadn't seen the program before. (If you really want to see Forth
>bite the dust, you could also compare the ease of understanding of the
>program to rookie programmers, hmmh...)

	Not if the "rookie" has ever used an HP calculator.
-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup