Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!dwp
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Object Oriented Forth..
Message-ID: <2829.UUL1.3#5129@willett.pgh.pa.us>
Date: 29 May 91 15:00:02 GMT
Organization: (n.) to be organized.  But that's not important right now.
Lines: 63

In article <1991May28.203116.23910@ecst.csuchico.edu>,
	fish@ecst.csuchico.edu (Kevin Haddock) writes:
> Now how this relates to FORTH coding conventions and readability.  First
> thing I have against FORTH syntax and all the OOPS I have run across
> is they all have the syntax BACKWARDS!  The VERB COMES FIRST!!!!

I'm not sure what you are saying here.  Are you saying that having the
verb come first is backwards (SmallTalk has the object first) or that
having the object come first is backwards and the verb *should* be
first?

> The biggest problem I see with FORTH is that you have to make up
> so many names and concatenate all kinds of wierd 'jerry rigged' syntax
> around them to convey what they are.  Either that or you have
> to resort to long-hyphenated-names and the vertical code that
> goes along with it.  I have been working on a parser that I believe
> corrects that problem.  It works something like this: The verb is
> an object who's behavior when parsed/interpreted is to put it's
> selector object (the token that represents the message) on the stack.
> Whenever a noun is interpreted it's behavior is to send itself to
> the verb object on top of the stack (or does the second send itself to the
> first, I can't remember; it's been awhile since I played with this).
> At the end of the processing of a method the remaining objects on
> the stack are sent to each other until just 'inert' objects remain
> as results.  Those 'inert' objects are basically those that have had
> all their argument needs satisfied.

I very much dislike active message names.  They are too clumsy to pass
around as parameters.  Same goes for active object names (you have to
name every object or special case arrays and records/structures and...)

> With this type of parser/interpreter and an object oriented system,
> a FOOL could be very readable because you would re-use lots of little
> verbs, create a few short sweet nouns, and the source code would not
> look like some kind of reverse-polish-greek-form-of-hyphenated-pig-latin!

I don't think you've made the case for having to have long hyphenated
names.  And reverse polish is the nature of Forth.  

> Another quick note:  In a true object oriented system the objects are
> created unbound and float on the stack until they are either no longer
> needed (90% of the cases) or are bound to a name.  I haven't seen
> too many FORTH OOP's that do this (but then again I haven't seen too
> many FORTH OOPS!).

The question is really one of what OOP oughta look like in Forth.

OOP requires knowing the types of things.
	Forth is traditionally untyped.

OOP usually requires automatic memory management.
	Forth is traditionally very flexible in letting you roll
	    your own memory management.

Therefore adding OOP to Forth is _not_ just adding a few new defining
words (object, class, message, whatever), but requires an integrated
effort to achieve a typed _and_ memory managed system onto which an OOP
can be added.  That is, if you want to go the whole nine yards and have
a full blown OOP Forth.  (IMNSHO).

-Doug
---
Preferred:  dwp@willett.pgh.pa.us	Ok:  {pitt,sei,uunet}!willett!dwp