Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ub!dsinc!unix.cis.pitt.edu!pitt!willett!dwp
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: OOF
Message-ID: <2877.UUL1.3#5129@willett.pgh.pa.us>
Date: 14 Jun 91 17:00:17 GMT
Organization: (n.) to be organized.  But that's not important right now.
Lines: 95

In article <9106140043.AA05031@ucbvax.Berkeley.EDU>,
	UNBCIC@BRFAPESP.BITNET writes:

+Ok, ok. Forget about names. What I mean is that the *USER* should specify
+if an object must be created or not. In SmallTalk this can occur without the
+user knowing it. But, as I see, this is not necessary.

I think this may end up being a conceptual difference between "real"
OOP and "pragmatic" OOP.  It is central to memory management
philosophy.  SmallTalk considers explicit memory management to be
below the level of detail necessary or desirable for most
application's programmers.  Forth considers giving as much control as
possible over everything to the programmer as most desirable.  I
suspect that the amount of integration between OOP and Forth will in
part depend on this issue.  C++ claims to be a real OOP, but it doesn't
really have automatic memory management.  Given C++'s definition of OOP,
I think a similar OOF could be done.  I also don't see any theoretical
reason that an OOF couldn't be done with SmallTalk like memory management.
In either case you no longer have Forth, but OOF instead.  How much like
Forth it remains depends on how much (qualitatively) you add to it.

+"_write_ the operation" = Overload

Correct.  Overloading is only possible in the presence of types, a
requirement for the compiler to disambiguate the operation.  

+Not all operators work on all types. IN (Pascal operator) work on a single pair
+of types only. It's not overloaded. *BUT*, even in a language where you DON'T
+have overload you can have TYPEs. Type-casting and Type-checking make types in
+a language, not overload, not use the same operator for two different types.

I never (intended) to claim that overloading was necessary for types, only
that types are necessary for overloading.  And to point out that Forth
does not have that kind of overloading (i.e. the kind managed by the
compiler, not by the programmer.)

+N bytes + the label INTEGER + (optionally) how to convert an integer in another
+type. The most important part, anyway, it's the label. Are two "objects" of the
+same type? If, in a language, that can_be/is checked, in a way or another, then
+you have types.

+The set of operations don't makes types. The ALLOWABLE makes.

??? And just what does the label INTEGER mean?  Surely it must
indicate how the "N bytes" are to be interpreted, or, to say the same
thing a different way, what operations are defined for the type and
what their semantics are.  Yes, I understand that there are types systems
that are name based (pascal is like this, if I recall correctly) and some
that are structure based (C is sort of like this, but more like a hybrid).

+I explain. Imagine the following code:
+SERIAL KEY    ( Reads from serial port )
+KEYBOARD KEY  ( Read from keybord )

[Implementation examples elided...-dwp]

+You still doesn't understand? KEY could be +, SERIAL could be STRING and
+KEYBOARD could be INTEGER. My implementation of OOF is a combination of the
+DEFER and the VOCABULARY solution.

I have no problem with your particular implementation, as it does what
you want it to.   How would you handle something like:

: parse-foo  ( source-of-keys -- result )
    ???? KEY	( get the next key from the source passed in on the stack )
    ( process key ... this could involve using words that in turn
      use this word, which means that "source-of-keys" cannot be made
      "global state" )
;

You'd probably have that code in a loop, but that isn't relevant to my
question.

+I claim that a list of methods is a way of implementing a type mechanism, but
+it doesn't make TYPEs.

I don't seem to understand the distinction you are drawing.

+I can't see a type of something that don't have possible values. A VOID?

C has just that very type (well, they spell it with all lowercase
letters).  It basically stands for an unknown or non-existant
quantity.  When a C function returns "void", it doesn't really return
any value, and therefore cannot be assigned to any variable or used
in any value requiring expression.  When x is declared as "void *x;"
all that is known about it is that it is a pointer of some kind.  It
cannot be derefenced, but it can be tested for equality/inequality
with other pointers.

But this isn't really the issue.  I seem to be stuck on trying to
understand what you mean by "type".

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