[comp.lang.forth] objective forth

zs04+@andrew.cmu.edu (Zachary T. Smith) (07/26/89)

I'm looking for some info on objective Forth and existing implementations.

Does anyone know of any commercial implementations of an object-oriented
Forth, or of any books relating to the subject?

Thanks,

-Zach T. Smith (zs04@andrew.cmu.edu)

pmy@vivaldi.acc.Virginia.EDU (Pete Yadlowsky) (07/26/89)

In article <0Yn-Vly00WBn01=20j@andrew.cmu.edu> zs04+@andrew.cmu.edu (Zachary T. Smith) writes:

>I'm looking for some info on objective Forth and existing implementations.
>Does anyone know of any commercial implementations of an object-oriented
>Forth, or of any books relating to the subject?

JForth (for Amiga) comes with source for ODE (Object-oriented Development
Environment), which can be loaded only when needed or made a permanent
part of the JForth environment.
Objects can be instantiated statically on the dictionary or dynamically
in free RAM. ODE comes with a few basic object classes, such as OBJECT
(base object class) and ARRAY. Of course, the programmer may define new
object classes and methods. Early and late binding are both supported.


Peter M. Yadlowsky		| "Pay no attention to that man
Academic Computing Center	|	behind the curtain!"
University of Virginia		|
pmy@Virginia.EDU		|

aj-mberg@dasys1.UUCP (Micha Berger) (08/03/89)

I don't understand how a weakly typed language like FORTH can be fit into the
object-oriented mold. Nor am I sure why anyone would want to.

I don't understand the idea of adding an extra abstraction unles it:
	1- fits the intuitive description of the problem
	2-   "   "     "           "      "   "    "
        3- speeds up execution time
        4- reduces required memory space
Objects just present simething else to learn. FORTH already has most of the
advantages of OOP if you make good use of VOCABULARYs.

This doesn't really belong in a FORTH group, please reply by mail.
-- 
					Micha Berger

"Always should [the child of] Adam have awe of G-d in secret and in public,
admit the truth, and speak truth in his heart." 

pmy@vivaldi.acc.Virginia.EDU (Pete Yadlowsky) (08/05/89)

In article <10451@dasys1.UUCP> aj-mberg@dasys1.UUCP (Micha Berger) writes:
>I don't understand how a weakly typed language like FORTH can be fit into the
>object-oriented mold.

I'm not sure I see a necessary connection between strong typing and
OOP. Anyway, Forth, with its extensible compiler and innate abstraction
fits quite well with OOP. JForth's ODE is an excellent example.
Where do you see the problems?

>Nor am I sure why anyone would want to.

Well, for the same reasons one would use OOP models to approach a problem
in any language...data/process abstraction, instancing, inheritance, etc.

>I don't understand the idea of adding an extra abstraction unles it:
>	1- fits the intuitive description of the problem
>	2-   "   "     "           "      "   "    "

Yes and yes!

>        3- speeds up execution time

Probably not, but it sure as hell speeds up development time.

>        4- reduces required memory space

Depends.

>Objects just present simething else to learn.

So did Forth. Remember?

>FORTH already has most of the
>advantages of OOP if you make good use of VOCABULARYs.

No, not even close. Vocabularies, though useful, are not even
a crude approximation to OOP.

>This doesn't really belong in a FORTH group,

Sure it does. Why not?

Peter M. Yadlowsky		| "Pay no attention to that man
Academic Computing Center	|	behind the curtain!"
University of Virginia		|
pmy@Virginia.EDU		|

ZMLEB@SCFVM.BITNET (Lee Brotzman) (08/06/89)

>I don't understand how a weakly typed language like FORTH can be fit into the
>object-oriented mold. Nor am I sure why anyone would want to.

   Weak typing can be transformed into strong typing.  The inverse is not
possible (usually).  The question is whether strong or weak typing -- or
something in between -- is required and necessary.  The particular situation
overrides anything I can say in [network] isolation.

>Objects just present simething else to learn. FORTH already has most of the
>advantages of OOP if you make good use of VOCABULARYs.

   WRONG.  Forth has always had *some* of the advantages of OOP through the
use of CREATE DOES> (or <BUILDS DOES> ).  Vocabularies have always been
Forth's Achilles' heel, in my humble opinion.
   CREATE DOES> is the essence of OOP.  It defines a data structure (object)
and defines the primary operation on that data structure.  It allows
maximum freedom in data structure processing because it requires a mininum
of syntatic rules to access that data structure.

>                                        Micha Berger

-- Lee Brotzman (FIGI-L Moderator)
-- BITNET:   ZMLEB@SCFVM
-- Internet: zmleb@scfvm.gsfc.nasa.gov
-- The government and my company don't know what I'm saying.
-- Let's keep it that way.