Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!dwp
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Domain of Forth
Message-ID: <1499.UUL1.3#5129@willett.pgh.pa.us>
Date: 10 Aug 90 04:24:08 GMT
References: <12218@sdcc6.ucsd.edu>
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 77

In <12218@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes:

[I must admit that I'm surprised to find myself mostly agreeing with
John Wavrik here.]

[JW gives example of cookbook method for computing when Easter is.
 Admits that a straight forward stack implementation is even worse.
 Shows solution using new EVALUATE" word from the "ALGEBRAIC" package.]

>                                                           However, the 
> "algorithm" is actually the set of ideas behind this recipe. If we 
> understood the algorithm, we might be able to express it well in Forth 
> (but not, of course, as a sequence of infix expressions).

I think this is an important point to remember.  I'm not sure I agree
with your solution (algebraic infix expressions _in strings_), but I
don't have a better one to offer.

> I should pause here to say something to people who feel that I have 
> somehow violated the purity of Forth by suggesting that words be 
> created to handle algebraic infix expressions. My view of Forth is 
> that its "niche" (if you want to call it that) is that it is more 
> flexible and universal than other languages. You can use Forth to 
> build anything that you want (and build it portably if the Standards 
> are any good). When we want to manipulate a certain type of data, we 
> first write words for handling this type of data and the relevant 
> operations on it. Then we write programs using these words. [When we 
> want to do a job, we first build tools designed for the kind of work 
> we want to do!] Algebraic expressions are a form of data -- and the 
> operation we want to perform is evaluation. So take the Forth 
> approach: build tools appropriate for the task. 

Aha!  You've hit the nail right on the head.  This is what I would like to
see (in the standard of course, but that is a different matter).  Start
with the right tool box, powerful and simple.  Have a standard set of tools
(built from the core tool box tools) available for loading so that I don't
have to build them from scratch myself.  Chuck Moore, from _Thinking Forth_,
by Leo Brodie, pp 196-197:

	If you choose to define the word ARRAY, you've done a
	decomposition.  You've factored out the concept of an array from
	all the words you'll later put back in.  And you've gone to
	another level of abstraction.

	Building levels of abstraction is a dynamic process, not one
	you can predict.

	...

	Of course I try to factor things well.  But if there doesn't
	seem to be a good way to do something, I say, "Let's just
	make it work."

	My motivation isn't laziness, it's knowing that there are
	other things coming down the pike that are going to affect
	this decision in ways I can't predict.  Trying to optimize
	this now is foolish.  Until I get the whole picture in front
	of me, I can't know what the optimum is.


One of the reasons I'm a minimalist is the above: "building levels of
abstraction is a dynamic process..." so I feel it is best not to try to
predict.  One of the reasons I like add on packages (sort of kitchen
sink-ist) is that since I don't know what is coming down the pike until it
gets to me anyway, I would rather work on the understanding rather than
wasting my time trying to grow an abstraction that is not going to be a
best fit.  I would just as soon throw in an off-the-shelf part and leverage
my way up to the whole picture.  Once there, then it makes sense to junk
the off-the-shelf part and grow the right abstraction.  But at least I've
not junked the time I put in on my own variant of the off-the-shelf part
that just has to be tossed anyway.

-Doug

---
Preferred: ( dwp@willett.pgh.pa.us  OR  ...!{sei,pitt}!willett!dwp )
Daily: ...!{uunet,nfsun}!willett!dwp  [last resort: dwp@vega.fac.cs.cmu.edu]