Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!BRFAPESP.BITNET!UNBCIC From: UNBCIC@BRFAPESP.BITNET Newsgroups: comp.lang.forth Subject: OOF Message-ID: <9106140043.AA05031@ucbvax.Berkeley.EDU> Date: 13 Jun 91 16:45:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV Organization: The Internet Lines: 134 => Date: Sun, 9 Jun 91 19:16:46 GMT => From: Doug Philips => => 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 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.BITNET