wmb@MITCH.ENG.SUN.COM (08/30/90)
Supposing we agree that Forth needs some sort of a standard for object oriented programming: (If you don't agree, I don't want to hear about it. Consider this a thought experiment; a "what if" scenario.) There are 2 reasons why someone might agree with this: a) That person wants to participate in or direct the design of same, and thus achieve, fame, fortune (ha!), and personal satisfaction. b) That person wants to be able to use object-oriented techniques in Forth programs, with some degree of portability. From recent messages, I suspect that motivation (a) is widespread. More on this later... Now further suppose that we could manage to agree upon motivation (b) as our "marching orders", and we wish to proceed in the direction most likely to lead to our goal. In that case, we should dispense with design quibbles. We should evaluate *existing* OO Forth designs, particularly those which have already been "proven" to some extent and those which are in widespread (relatively speaking) use. If we could find a basically sound candidate, then we should work to make that a standard by writing articles, applications, and implementations. Here is a preliminary list: NEON, ODE (JForth; reportedly similar to NEON), Boron (an implementation of NEON, with some divergence and some extensions), FOOPS (HSForth), various implementation of Pountain's book. I have seen something for MacForth too, but I can't recall the name. If I have left some out, chalk it up to my ignorance and add to the list. I claim that if we REALLY care about the effective result (a standard OO extension for Forth), rather than about our personal research goals, then this is the approach we should take. Now, back to motivation (a) (research, personal fame). I think that a big proportion of the Forth community is motivated thus. (I do not claim to free of such leanings.) I once had a discussion about Unix with Chuck Moore. Chuck objected to Unix on the grounds that he thought that he could do a better job of writing many or all of the Unix utilities and drivers, and didn't I think so too. I replied that in a lot of cases I could, but that had neither the time nor the desire to rewrite every bit of software in the world. So what will it be? Shall we try to *select* an object oriented standard as opposed to inventing one? The existing ones are not all brain-damaged. Mitch Bradley, wmb@Eng.Sun.COM
dwp@willett.pgh.pa.us (Doug Philips) (09/04/90)
In <9008310101.AA27622@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > Supposing we agree that Forth needs some sort of a standard for > object oriented programming: [ ... ] > (relatively speaking) use. If we could find a basically sound candidate, > then we should work to make that a standard by writing articles, applications, > and implementations. [ ... ] > Here is a preliminary list: NEON, ODE (JForth; reportedly similar to NEON), > Boron (an implementation of NEON, with some divergence and some extensions), > FOOPS (HSForth), various implementation of Pountain's book. I have seen > something for MacForth too, but I can't recall the name. If I have left > some out, chalk it up to my ignorance and add to the list. Ok, so for those of us who aren't already familiar with all of those systems, could you (or anyone) post a reading/reasource list? (I would guess from your phrasing that you aren't fluent with all of them either.) > I claim that if we REALLY care about the effective result (a standard > OO extension for Forth), rather than about our personal research goals, > then this is the approach we should take. You presume that we all agree on what an OO extension for Forth is. Or rather, that any old system will do. I started a lot of this brouhaha by denouncing some forms of OOF; I never claimed to have done a survey of the field. There may be good OOF's out there and to *start* by doing a survey is reasonable. > So what will it be? Shall we try to *select* an object oriented standard > as opposed to inventing one? The existing ones are not all brain-damaged. To paraphrase: So what will it be? Do it now or do it right? [ 1/2 :-) ] Perhaps we don't need to take the ANSI approach to everything? :-) -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]
dwp@willett.pgh.pa.us (Doug Philips) (09/04/90)
In <9008310101.AA27622@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > a) That person wants to participate in or direct the design of same, > and thus achieve, fame, fortune (ha!), and personal satisfaction. > > Now, back to motivation (a) (research, personal fame). I think that > a big proportion of the Forth community is motivated thus. (I do not > claim to free of such leanings.) I once had a discussion about Unix > with Chuck Moore. Chuck objected to Unix on the grounds that he thought > that he could do a better job of writing many or all of the Unix utilities > and drivers, and didn't I think so too. I replied that in a lot of cases > I could, but that had neither the time nor the desire to rewrite every bit > of software in the world. I think you have hit upon an interesting dichomoty in the Forth community: Some people want to use Forth to further their own ends, whatever they may be. Forth's flexibility may make it ideal for that purpose. Some people want to use Forth as a base to write above. Forth's flexibility is less obviously a winning attribute here. The idea is to get above Forth, not tinker with it. There are those of us who fall into both groups at various times. (I add in passing that the GNU project is doing just what CM suggested, though that is more a side effect of their real goal.) One thing your last sentence points up: There is always a trade-off between spending amount of effort/time X into building a better tool so as to save effort/time Y when that tool is used. My personal experience is that investing effort/time in the X direction is a good thing not often done. I have seen a heck of a lot of "I would rather spend an extra 30 minutes a week fighting to cover the warts of the system than spend a day to remove them." The cost/benefit analysis ALWAYS favors the short term goals under such thinking. -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]
wmb@MITCH.ENG.SUN.COM (09/07/90)
> > So what will it be? Shall we try to *select* an object oriented standard > > as opposed to inventing one? The existing ones are not all brain-damaged. > > To paraphrase: So what will it be? Do it now or do it right? [ 1/2 :-) ] The paraphrase is wrong. I'm not suggesting "do it now", I'm suggesting "it has already been done; let's try to build upon existing work rather than starting from scratch". How do we know that what we invent will be more "right" than one that someone else has already invented, implemented, debugged, and which has already passed the "real world usefulness test"? Charles Duff and Phil Burk and Jim Callahan and Steve Lewis are not all idiots, so their work should not be rejected out-of-hand as being "wrong". There seems to be considerable disagreement on ForthNet about what is "right" and what is "wrong". My suspicion is that everybody who has an opinion is of the opinion that anything "not invented here" is "wrong". The smart businessperson carefully considers both sides of the "make or buy" decision, rather than jumping immediately to the "make" decision. Finally, I claim from personal experience that it is *extremely* difficult to achieve a critical mass of market acceptance. Starting with a ball that is already rolling increases the chances of success immeasurably. Mitch
dwp@willett.pgh.pa.us (Doug Philips) (09/07/90)
In <9009061817.AA23759@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > How do we know that what we invent will be more "right" than one that > someone else has already invented, implemented, debugged, and which > has already passed the "real world usefulness test"? Well, if you are going to accept any old thing as OOF then "how indeed"? My objection to the existing OOFs wasn't on the basis of implementation but on interface. Are they really the most convenient form of OOF? I think most of them are for simple problems. But toy problems aren't the domain I'm looking to have an OOF for. I have yet to be convinced, but am willing to be, that there is an existing OOF that doesn't have those problems/restrictions. > Charles Duff and Phil Burk and Jim Callahan and Steve Lewis are not all > idiots, so their work should not be rejected out-of-hand as being "wrong". No, I never claimed that the authors were idiots. I claim(ed) that their goals are not clean OOF systems. Anyone with information, references to FD (Vol and Issue), JFAR, FORML, Books, etc. please step forward. I *do* think a good survey of existing mechanisms is worthwhile. > There seems to be considerable disagreement on ForthNet about what is "right" > and what is "wrong". My suspicion is that everybody who has an opinion is > of the opinion that anything "not invented here" is "wrong". Well, I have never seen much consensus for any definition of OOP, let alone a Forth one, so if what you say is true it wouldn't be too surprising. In fact, I recall there are several object-active systems, one posted here, Pountains, Mike Patel's TILE (not fully revealed to us), etc. More consensus than you imply. I don't want to get into a moral judgement about right vs. wrong (although I may have failed to avoid it). I would rather set up criteria for what a good OOF would be and then evaluate existing implementations against that criteria. > The smart businessperson carefully considers both sides of the "make or > buy" decision, rather than jumping immediately to the "make" decision. Things have gotten muddied, but my original goal was to show that the existing (buy) option had flaws. I have yet to provide my own "make" decision and would rather try to define a way to evaluate existing and proposed systems for suitability, so that a fair consideration can be made. I hope at least to have planted some doubt in the minds of those who would otherwise jump immediately to the "buy" decision that it does have problems. I admit that I have probably not been very clear in expressing all of this before and have gotten caught up in the heat of the moment. > Finally, I claim from personal experience that it is *extremely* difficult > to achieve a critical mass of market acceptance. Starting with a ball > that is already rolling increases the chances of success immeasurably. Considering that there are serious questions about whether or not Forth itself has achieved critical mass, I'm not sure that I'm too worried about that aspect. Forth does seem to attract "my way or not at all" people, myself included. Hopefully there hasn't been so much OOF code written that we'll be quick-sank by existing practice. -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]
UNBCIC@BRFAPESP.BITNET (05/30/91)
=> Date: Wed, 29 May 91 15:00:02 GMT
=> From: Doug Philips
=> <cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett
!dwp@UCBVAX.BERKELEY.EDU>
=> Subject: Object Oriented Forth..
=> I don't think you've made the case for having to have long hyphenated
=> names. And reverse polish is the nature of Forth.
^^^^^^^^^^^^^^^
It is, in fact, one of it's strengths. It makes things simple.
=> > 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!).
Good point. But that's not part of the OOS, it's just an way of handling
things. I *really* prefer named objects, i.e., Objects would return already
known objects, instead of creating new ones.
=> The question is really one of what OOP oughta look like in Forth.
=>
=> OOP requires knowing the types of things.
=> Forth is traditionally untyped.
Knowing types? No. OOP requires that only methods defined for an object have
access to it's data fields. I handle this with vocabularies. A class is a
vocabulary. It's methods data fields are defined inside this class, so only
this methods can have access to the fields (Of course one could get-order, but
it doesn't matter). The fields are allocated with a special word, like ARRAY.
No types. What then happens?
MESSAGE -- Creates a word that gets an object from stack and search for himself
in this object, executing then the associated CFA. The object have it's value
saved.
OBJECT: -- Creates a vocabulary, initialize some variables, and creates a word
with these values. A VALUE will keep the address of this word so that the words
bellow can change the values.
METHOD: -- Get the following word (an already defined MESSAGE), and save the ID
of the message and the CFA (returned by START:) at HERE. (Changes OBJECT or
CLASS). Then it START:s.
When the object is executed, it leaves an value on the stack. When MESSAGE is
executed, it gets this value, saves it, and search for METHOD in a list
somewhere in Object. When Method is finally executed, all the references to the
object's data (just offsets) is added to the start of the data area of the
Object (whose value it's known). No types. It's just a complex DEFERred word.
=> OOP usually requires automatic memory management.
=> Forth is traditionally very flexible in letting you roll
=> your own memory management.
Automatic doesn't mean you can roll your owm memory management. In fact, if you
don't want one of the kinds I offer to you (static, dynamic and virtual), you
can do your own without changing anything else.
=> Therefore adding OOP to Forth is _not_ just adding a few new defining
=> words (object, class, message, whatever), but requires an integrated
Right.
=> 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
Wrong. The memory management system can be yours. And you don't need types.
Inheritance, hidden data fields and everything else can be obtained by just
another level between you and the machine. ALLOT won't just ALLOT, it will keep
the size and the offset of this. Things like that.
Maybe I can post some words (< 3Kb of source with documentation) that enables
you to use objects, although without Inheritance.
=> -Doug
=> ---
=> Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETdwp@willett.pgh.pa.us (Doug Philips) (06/05/91)
In article <9106020320.AA27050@ucbvax.Berkeley.EDU>, UNBCIC@BRFAPESP.BITNET writes: +Good point. But that's not part of the OOS, it's just an way of handling +things. I *really* prefer named objects, i.e., Objects would return already +known objects, instead of creating new ones. Well, not necessarily. Naming objects is not exactly the same as already known objects. Must the objects in an array have names? Must the objects in a list have names? If you have an OOF with "active" object names, then those have to be special cases... Very Inelegant. +Knowing types? No. OOP requires that only methods defined for an object have +access to it's data fields. I handle this with vocabularies. A class is a +vocabulary. It's methods data fields are defined inside this class, so only +this methods can have access to the fields (Of course one could get-order, but +it doesn't matter). The fields are allocated with a special word, like ARRAY. +No types. What then happens? [Example elided... -DWP] + No types. It's just a complex DEFERred word. Sigh. I should have KNOWN that would cause problems. OOP requires objects to have a type. Forth is traditionally untyped. The stack is just a stack of numbers. Forth traditionally requires the programmer to know which of + D+ F+ .. to use. In order to take that requirement away from the programmer, the objects on the stack must have a type associated with them (how that association is achieved is an implementation detail). +=> OOP usually requires automatic memory management. +=> Forth is traditionally very flexible in letting you roll +=> your own memory management. +Automatic doesn't mean you can roll your owm memory management. In fact, if you +don't want one of the kinds I offer to you (static, dynamic and virtual), you +can do your own without changing anything else. I was attempting to show that you would have to add those kinds of memory management to Forth, in addition to adding your new defining words. +=> Therefore adding OOP to Forth is _not_ just adding a few new defining +=> words (object, class, message, whatever), but requires an integrated +Right. +=> 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 +Wrong. The memory management system can be yours. And you don't need types. +Inheritance, hidden data fields and everything else can be obtained by just +another level between you and the machine. ALLOT won't just ALLOT, it will keep +the size and the offset of this. Things like that. I seem to have hit a magic button with my use of the word 'type'. If you don't have types you can't tell the class of an object, and therefore cannot do method lookup for that object. As for memory management... I suppose the key issue not some particular implementation, but the interface used by the OOP system. +Daniel C. Sobral +UNBCIC@BRFAPESP.BITNET -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
UNBCIC@BRFAPESP.BITNET (06/07/91)
=> Date: Tue, 4 Jun 91 17:15:03 GMT
=> From: Doug Philips
=> <cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett
!dwp@UCBVAX.BERKELEY.EDU>
=> Subject: RE: OOF
=> +Good point. But that's not part of the OOS, it's just an way of handling
=> +things. I *really* prefer named objects, i.e., Objects would return already
=> +known objects, instead of creating new ones.
=>
=> Well, not necessarily. Naming objects is not exactly the same as already
=> known objects. Must the objects in an array have names? Must the objects
=> in a list have names? If you have an OOF with "active" object names, then
=> those have to be special cases... Very Inelegant.
An array of objects. The array have name, right? That's ok. The whole problem
is that, in Smalltalk for example, when an object do something (2+2, for
example), it generates an object, allocating memory, creating links and lot's
of stuff. I think that Forth will *NEVER* be completly OO. So, the result of
operations, such as 2+2, will not be an object. Smalltalk will create an object
4, wich will be destroyed later, when it's not needed anymore. That's what I
call a nameless object.
=> +Knowing types? No. OOP requires that only methods defined for an object have
=> +access to it's data fields. I handle this with vocabularies. A class is a
=> +vocabulary. It's methods data fields are defined inside this class, so only
=> +this methods can have access to the fields (Of course one could get-order, b
ut
=> +it doesn't matter). The fields are allocated with a special word, like ARRAY
.
=> +No types. What then happens?
=> [Example elided... -DWP]
=> + No types. It's just a complex DEFERred word
.
=>
=> Sigh. I should have KNOWN that would cause problems. OOP requires objects
=> to have a type. Forth is traditionally untyped. The stack is just a stack
=> of numbers. Forth traditionally requires the programmer to know which of
=> + D+ F+ .. to use. In order to take that requirement away from the programme
r,
=> the objects on the stack must have a type associated with them (how that
=> association is achieved is an implementation detail).
TYPE, from what I've learned, it's the description of a data structure. A typed
language treats diferent types in diferent ways. A strongly typed language
assures an exact mach of types. But, in OO, you *HIDE* the structure. What you
put in the stack is an address to a record with a list of methods and data
space. (Well, it's usually more complex, but can be reduced to that). I just
can't see a type here! There is NO description of the data structure, just the
CFAs of methods that handle the object. There is no analysis, by the compiler,
or run-time, of ANYTHING. There is a search in the list of methods, and the
execution of a CFA. If you consider the list of methods a kind of type, ok. But
I consider this an object.
=> I seem to have hit a magic button with my use of the word 'type'. If you don
't
=> have types you can't tell the class of an object, and therefore cannot
=> do method lookup for that object. As for memory management... I suppose the
=> key issue not some particular implementation, but the interface used by the
=> OOP system.
+-.... Looks like what you don't like is having overloaded operators... I think
of overloaded messages as a vectored word. For me, it's like writing KEY and
knowing that in another place in my program I decided what KEY means. For
example: SERIAL KEY (object message) and KEYBOARD KEY. Maybe SERIAL is an
object with a pointer to the KEY that will be used. Maybe SERIAL is a word that
assigns a new CFA to KEY.
One more thing, remember that an object don't need to have data space. How can
you call something that DON'T HAVE any datum a typed thing?
=> +Daniel C. Sobral
=> +UNBCIC@BRFAPESP.BITNET
=>
=> -Doug
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETdwp@willett.pgh.pa.us (Doug Philips) (06/10/91)
In article <9106070453.AA08025@ucbvax.Berkeley.EDU>, UNBCIC@BRFAPESP.BITNET writes: >An array of objects. The array have name, right? That's ok. The whole problem >is that, in Smalltalk for example, when an object do something (2+2, for >example), it generates an object, allocating memory, creating links and lot's >of stuff. I think that Forth will *NEVER* be completly OO. So, the result of >operations, such as 2+2, will not be an object. Smalltalk will create an object >4, wich will be destroyed later, when it's not needed anymore. That's what I >call a nameless object. The array may not necessarily have a name, but it could. Do all your data types have to have names to be instantiated? What if the only place you use arrays is, for example, as elements of a list? Must you name them then? What about the nodes of a tree, do they all have to have names too? As for SmallTalk's "2+2", yes it makes a new object "4", but then Smalltalk treats small integers specially so that all the nonsense of creating memory and links and such doesn't happen. As for things that are created and destroyed later... In SmallTalk the most heavily allocated and freed objects are contexts (sort of like procedure call frames or closures). >TYPE, from what I've learned, it's the description of a data structure. A typed >language treats diferent types in diferent ways. A strongly typed language >assures an exact mach of types. But, in OO, you *HIDE* the structure. What you >put in the stack is an address to a record with a list of methods and data >space. (Well, it's usually more complex, but can be reduced to that). I just >can't see a type here! There is NO description of the data structure, just the >CFAs of methods that handle the object. There is no analysis, by the compiler, >or run-time, of ANYTHING. There is a search in the list of methods, and the >execution of a CFA. If you consider the list of methods a kind of type, ok. But >I consider this an object. Whether or not strongly typed languages implement operations on different types in different ways, they often let the programmer _write_ the operations the same. Forth and assembly languages are the only languages I know where you have lexically different operators for addition depending on the types of the operands. As for your view of type as a description of a data structure, I think you are being overly myopic. Whether the analysis is done at run time or at compile time is merely an implementation detail. Some languages let the programmer decide (i.e. C++). As to what I consider a type... What do you consider an integer to be? Just <n> bytes of memory? What about the allowable set of operations ( + - * / ... )? Which characterizes the type more? I would say that both are important. I consider an object an instance of a type. Whether or not that consists of a list of methods depends solely on the implementation. Presumably an object may also have some object specific piece of memory allocated to it too. >+-.... Looks like what you don't like is having overloaded operators... I think >of overloaded messages as a vectored word. For me, it's like writing KEY and >knowing that in another place in my program I decided what KEY means. For >example: SERIAL KEY (object message) and KEYBOARD KEY. Maybe SERIAL is an >object with a pointer to the KEY that will be used. Maybe SERIAL is a word that >assigns a new CFA to KEY. I haven't the foggiest what you are talking about here. I said nothing about overloaded operators. You claimed that all you needed for an object was a pointer to a list of methods. My claim was that you have just introduced a type mechanism. (That is not the only way to do so though). >One more thing, remember that an object don't need to have data space. How can >you call something that DON'T HAVE any datum a typed thing? Because it is not the data space which distinguishes types, it is the operations that distinguish types. How many different types can have objects with a data space of 4 bytes? Depending on the size of a byte and other machine specific things, you often have: Some kind of integer type, some kind of floating point type, an array of four bytes, an array of two 2-byte quantities, and array of one 4-byte quantity, a pointer, an offset and a length (two bytes each).... and on and on and on.... What makes those types different? It is certainly not the amount of data space allocated to them. It is the way in which that space is interpreted. I.e. what messages it understands and what those messages "mean." And that holds for objects that have no data space (i.e. stateless objects, pure functions, etc.) -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
UNBCIC@BRFAPESP.BITNET (06/13/91)
=> Date: Sun, 9 Jun 91 19:16:46 GMT
=> From: Doug Philips
=> <cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett
!dwp@UCBVAX.BERKELEY.EDU>
=> Subject: RE: OOF
=> The array may not necessarily have a name, but it could. Do all your
=> data types have to have names to be instantiated? What if the only
=> place you use arrays is, for example, as elements of a list? Must you
=> name them then? What about the nodes of a tree, do they all have to
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.
=> have names too? As for SmallTalk's "2+2", yes it makes a new object
=> "4", but then Smalltalk treats small integers specially so that all
=> the nonsense of creating memory and links and such doesn't happen. As
=> for things that are created and destroyed later... In SmallTalk the
=> most heavily allocated and freed objects are contexts (sort of like
=> procedure call frames or closures).
=>
=> >TYPE, from what I've learned, it's the description of a data structure. A ty
ped
=> >language treats diferent types in diferent ways. A strongly typed language
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=> Whether or not strongly typed languages implement operations on
=> different types in different ways, they often let the programmer
=> _write_ the operations the same. Forth and assembly languages are the
=> only languages I know where you have lexically different operators for
=> addition depending on the types of the operands.
"_write_ the operation" = Overload
=> As for your view of type as a description of a data structure, I think
=> you are being overly myopic. Whether the analysis is done at run time
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.
=> or at compile time is merely an implementation detail. Some languages
=> let the programmer decide (i.e. C++). As to what I consider a type...
=> What do you consider an integer to be? Just <n> bytes of memory?
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.
=> What about the allowable set of operations ( + - * / ... )? Which
The set of operations don't makes types. The ALLOWABLE makes.
=> characterizes the type more? I would say that both are important. I
=> consider an object an instance of a type. Whether or not that
=> consists of a list of methods depends solely on the implementation.
=> Presumably an object may also have some object specific piece of memory
=> allocated to it too.
=>
=> >+-.... Looks like what you don't like is having overloaded operators... I th
ink
=> >of overloaded messages as a vectored word. For me, it's like writing KEY and
=> >knowing that in another place in my program I decided what KEY means. For
=> >example: SERIAL KEY (object message) and KEYBOARD KEY. Maybe SERIAL is an
=> >object with a pointer to the KEY that will be used. Maybe SERIAL is a word t
hat
=> >assigns a new CFA to KEY.
=>
=> I haven't the foggiest what you are talking about here. I said
I explain. Imagine the following code:
SERIAL KEY ( Reads from serial port )
KEYBOARD KEY ( Read from keybord )
This can be to variables of different types (SERIAL and KEYBOARD) and an
overloaded operator. Also, this can be:
DEFER KEY
: SERIAL ['] S-KEY IS KEY ;
: KEYBOARD ['] K-KEY IS KEY ;
or
VOCABULARY SERIAL SERIAL DEFINITIONS
: KEY S-KEY ;
FORTH DEFINTIONS VOCABULARY KEYBOARD KEYBOARD DEFINITIONS
: KEY K-KEY ;
FORTH DEFINITIONS
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.
=> nothing about overloaded operators. You claimed that all you needed
=> for an object was a pointer to a list of methods. My claim was that
=> you have just introduced a type mechanism. (That is not the only way
=> to do so though).
I claim that a list of methods is a way of implementing a type mechanism, but
it doesn't make TYPEs.
=>
=> >One more thing, remember that an object don't need to have data space. How c
an
=> >you call something that DON'T HAVE any datum a typed thing?
=>
=> Because it is not the data space which distinguishes types, it is the
=> operations that distinguish types. How many different types can have
=> objects with a data space of 4 bytes? Depending on the size of a
=> byte and other machine specific things, you often have: Some kind of
=> integer type, some kind of floating point type, an array of four
=> bytes, an array of two 2-byte quantities, and array of one 4-byte
=> quantity, a pointer, an offset and a length (two bytes each).... and
=> on and on and on.... What makes those types different? It is
=> certainly not the amount of data space allocated to them. It is the
=> way in which that space is interpreted. I.e. what messages it
=> understands and what those messages "mean."
=>
=> And that holds for objects that have no data space (i.e. stateless
=> objects, pure functions, etc.)
I can't see a type of something that don't have possible values. A VOID?
=> -Doug
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETdwp@willett.pgh.pa.us (Doug Philips) (06/15/91)
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