chip@dartvax.UUCP (Brig ) (11/22/83)
Personally, I think that CLU and Alphard prove that "abstract types" are a very clumsy idea. Pascal began popularizing this trend, and the arguments over how to patch up varying-length arrays (etc) has still not ended. Ada, of course, more of less solves the problem, but look at how gargantuan and ugly it is! Something went wrong with how types are defined, since when carried to their logical conclusions they are clumsy and complicated. The actor languages perhaps have a nicer idea of types, since users can create their own types with somewhat less fuss than in languages like CLU etc. Still, I have not used Smalltalk (eg) so I can't really say. Can someone who uses actor languages regularly join the fray, and say whether or not types work out well in them? (Postscript--I do not advocate no-type-checking, as in Bliss or some versions of C. I just think that CLU and Alphard demonstrate that taking Pascal-ish types to their logical conclusion shows that the notion of types was not very well thought out...) Chip Elliott ...decvax!dartvax!chip
smh@mit-eddie.UUCP (Steven M. Haflich) (11/24/83)
The actor languages perhaps have a nicer idea of types, since users can create their own types with somewhat less fuss than in languages like CLU etc. Still, I have not used Smalltalk (eg) so I can't really say. Can someone who uses actor languages regularly join the fray, and say whether or not types work out well in them? Just a reminder that active object programming is available in Lisp as well as in smalltalk. The active objects are called `flavors' in keeping with the notion that new flavors may be created by mixing of existing ones. Lisp flavors are thought by some to be superior to Smalltalk actors (with which I have no personal experience) because Smalltalk method inheritance is strictly hierarchical. (Is this still true?) Lisp flavors have been extensively used, even for tasks which might be considered `system programming.' For instance, the window system for Lisp Machines is built upon the flavor system. Flavors are available on MIT Lisp Machines as well as those from Symbolics and (I presume) LMI. The MIT LM flavor code has been ported into Franz, although licensing restrictions on the code may prevent distribution. (Or maybe not -- I'm not sure anyone has actually checked.) An independent but largely compatible implementation is available from U-Maryland, as recently advertised in many of these same newsgroups. Finally, compatible flavors are an integral part of ylisp, an experimental (i.e. non-production) Lisp available from Hebrew University. Somewhat different active objects are a feature of T Lisp, available from Yale for Vaxex and 68000s. A comment on the subject of strong typing and variable array bounds: Even without flavors, many Lisps treat arrays as functional objects which carry pointers to their accessor functions. Thus even lowly arrays are defined in terms of their response (when evaluated) instead of in terms of their static storage and dimensions. While this is perhaps the `right' way to do things, almost all Lisps contain ugly alternative kinds of array-like objects (e.g. hunks or vectors) which avoid the extravagance in running time. Steve Haflich, MIT Experimental Music Studio
smh@mit-eddie.UUCP (11/24/83)
References: <411@dartvax.UUCP> Relay-Version:version B 2.10.1 6/24/83; site duke.UUCP Posting-Version:version B 2.10.1 6/24/83; site mit-eddie.UUCP Path:duke!decvax!genrad!mit-eddie!smh Message-ID:<957@mit-eddie.UUCP> Date:Thu, 24-Nov-83 09:09:41 EST Organization:MIT, Cambridge, MA The actor languages perhaps have a nicer idea of types, since users can create their own types with somewhat less fuss than in languages like CLU etc. Still, I have not used Smalltalk (eg) so I can't really say. Can someone who uses actor languages regularly join the fray, and say whether or not types work out well in them? Just a reminder that active object programming is available in Lisp as well as in smalltalk. The active objects are called `flavors' in keeping with the notion that new flavors may be created by mixing of existing ones. Lisp flavors are thought by some to be superior to Smalltalk actors (with which I have no personal experience) because Smalltalk method inheritance is strictly hierarchical. (Is this still true?) Lisp flavors have been extensively used, even for tasks which might be considered `system programming.' For instance, the window system for Lisp Machines is built upon the flavor system. Flavors are available on MIT Lisp Machines as well as those from Symbolics and (I presume) LMI. The MIT LM flavor code has been ported into Franz, although licensing restrictions on the code may prevent distribution. (Or maybe not -- I'm not sure anyone has actually checked.) An independent but largely compatible implementation is available from U-Maryland, as recently advertised in many of these same newsgroups. Finally, compatible flavors are an integral part of ylisp, an experimental (i.e. non-production) Lisp available from Hebrew University. Somewhat different active objects are a feature of T Lisp, available from Yale for Vaxex and 68000s. A comment on the subject of strong typing and variable array bounds: Even without flavors, many Lisps treat arrays as functional objects which carry pointers to their accessor functions. Thus even lowly arrays are defined in terms of their response (when evaluated) instead of in terms of their static storage and dimensions. While this is perhaps the `right' way to do things, almost all Lisps contain ugly alternative kinds of array-like objects (e.g. hunks or vectors) which avoid the extravagance in running time. Steve Haflich, MIT Experimental Music Studio
bhaskar@fluke.UUCP (K.S. Bhaskar) (11/29/83)
The problem with so-called "strongly typed" languages like Pascal is
that the typing is all wrong. They try to type identifiers. There are
situations where this is reasonable, but, in most cases, type
information should be attached to the value, not the identifier.
Languages like Smalltalk and Snobol4, therefore, have true strong
typing. Languages like Pascal have an apology for type checking (when
are we going to stop perpetuating the myth that they have strong
typing?). Languages like Ada are an abomination, and are best
forgotten...
K.S. Bhaskar {allegra,lbl-csam,microsoft,sb1,uw-beaver}!fluke!bhaskarkurt@fluke.UUCP (Kurt Guntheroth) (11/30/83)
Anti-strong typing? Flame city!
I agree with Mr Bhaskar that often it is necessary for the value to carry
type information since languages which attempt to do all type checking in
the compiler are inherently limited in power. We disagree over whether
languages like Snobol (where nearly any type may be coerced into another
with no warning from the language) are good examples of the usefulness of
typed values.
People who don't like strongly typed languages often are rebelling against
the amount of typing they impose to insure that type checking can be done.
I am sympathetic, but I am also strongly reminded of C.A.R Hoare's comment
in a recent Turing Lecture which reads approximately "Wouldn't it be
wonderful if your Fairy Godmother would wave her magic wand over your program
and make it correct, and all you had to do was type it in three times?"
Strong typing is a price you pay to have the compiler detect some of your
programming errors. Obviously if one never made a single programming error
strong typing would be unnecessary...
Strong typing as a concept is inescapable. Strong typing is a language's
ability to tell two things of dissimilar kind apart and without it a
language is braindamaged. Strong typing as implemented in Pascal or Snobol
is not optimal. Maybe lisp? Maybe smalltalk? You don't think they are
strongly typed languages? Think again.
By the way, a pet peeve of mine is languages which are ugly to support
compilation in a single pass through the input. When I write a program I
make several passes, why shouldn't my compiler. Makes the language more
concise and removes much of the garbage surrounding strong typing in a
language like Ada. Oh well...
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtmark@cbosgd.UUCP (12/01/83)
> The problem with so-called "strongly typed" languages like Pascal is > that the typing is all wrong. They try to type identifiers. There are > situations where this is reasonable, but, in most cases, type > information should be attached to the value, not the identifier. > Languages like Smalltalk and Snobol4, therefore, have true strong > typing. Languages like Pascal have an apology for type checking (when > are we going to stop perpetuating the myth that they have strong > typing?). Languages like Ada are an abomination, and are best forgotten... You apparently have a different notion of "strong typing" than I do. Normally, strong typing tries to catch your errors and point them out to you, by compile time checks. What Snobol4 does is quite different: it checks types at runtime and tries to figure out something reasonable to do given the types. While this is certainly more likely to lead to reasonable results than the C/Fortran/Assembly approach of passing the wrong type and getting garbage, it tends to let errors remain in the code undetected, with lots of superflous conversions going on at runtime. PL/1 and APL are like this too.
ka@hou3c.UUCP (Kenneth Almquist) (12/02/83)
Last I heard, Xerox was experimenting with compile time type checking in Smalltalk. The goal was to detect programmer errors at compile time and to use the type information to generate more efficient code. The type information could be incomplete or omitted so that it would still be possible to implement sets, sort routines, and the like. It is interesting that Ada took the concept of strong typing from Pascal and added features like overloading and generics which make it possible to come closer to an "object oriented" style of programming while Small- talk is moving in the direction of compile time type checking. Perhaps we are witnessing a convergence of ideas here? Kenneth Almquist
barmar@mit-eddie.UUCP (Barry Margolin) (12/03/83)
> ... with lots of superflous conversions going on at runtime. > PL/1 and APL are like this too. I have never heard of APL doing any automatic type conversions. The only types it has are character and numeric, unless you consider the different types of numeric representations (boolean, integer, and floating) different types, which APL does not (it just chooses the most convenient representation at any point). If you try to use a numeric operator (e.g. +) on a character value you will get a DOMAIN ERROR. PL/I does compile-time type checking. If it notices that a variable of one type is being used where another is supposed to it will compile code to do the conversion. On Multics, where we use PL/I as the primary systems programming language (those of you who thought that Dennis Ritchie pioneered this idea are forgetting the history of Unix(tm)) our compiler generates a warning message whenever it does one of these in an argument list, since PL/I is normally call-by-reference and this turns into a pass-by-value which could screw you if the parameter was an output parameter. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
cjl@iuvax.UUCP (12/04/83)
#R:dartvax:-41100:iuvax:11800004:000:3133
iuvax!cjl Dec 3 17:20:00 1983
From Abstract data type point of view, the data having the same
structure don't have to have the same type names. That sounds quite
reasonable. But from software engineering point of view, we cannot
ignore efficient implementation. In Modula-2, Wirth offers a good
solution. The language itself allows non-strong-type programming
(called low level programming) with strong warning to the user by
enforcing them to be imported from MODULE SYSTEM.
While Pascal may appear too restrictive and C irresponsible,
Modula-2 do resolve these conflicts quite beautifully. The low level
features in Modula-2 include :
(1) a low level type WORD and a complete set of type transfer func-
tions whenever the operands have the same storage.
(2) a low level type ADDRESS as the first class citizen with refer-
ence function ADR and dereference function ^ and all operations
derived from the CARDINAL type.
(3) a typeless dynamic storage allocation procedure ALLOCATE and
storage size functions SIZE(var) and TSIZE(type).
(4) a Sequence type called "open array" which follows the rule of
structure compatibility. As a low level feature, the open array is
more consistent then Ada's unconstraint arrays. Remember even we
have the same "sequence" structure, we may still want to give them
different type names !
Again these are low level features which should be used with
extreme care. So I think Modula-2 has resolved the problem now and we
can put C and Bliss to rest now.
From Chingmin Jim Lo
Dept. of Computer and Information Science
Indiana University-Purdue university at Indianapolis
CSNET : cjl@Indiana@Rand-relay
From Abstract data type point of view, the data having the
same structure don't have to have the same type name.
That sounds quite reasonable. But from software engineering
point of view, we cannot ignore efficient implementation.
In Modula-2, Wirth offers a good solution. The language itself
allows non-strong-type programming (called low level programming)
with strong warning to the user by enforcing them to be imported
from MODULE SYSTEM.
.pp
While Pascal may appear too restrictive and C irresponsible,
Modula-2 DO resolves these conflicts in a quite beautiful way.
The low level features include :
.np
a low level type WORD and a complete set of type transfer
functions whenever the operands have the same storage.
.np
a low level type ADDRESS as the first class citizen with
reference function ADR and dereference function ^ and
all operation of the CARDINAL type.
.np
a typeless dynamic storage allocation procedure ALLOCATE
and storage size functions SIZE(var) and TSIZE(type).
.np
a Sequence type called "ARRAY OF type" which follows the rule
of struture compatibility. As a low level feature, the open
array is more consistent then Ada's unconstraint arrays.
Remember even we have the same structure "sequence", we may
want to give them different type names !
.pp
Again these are low level features which should be used with
extreme care. So why do we need C except for UNIX ?mark@umcp-cs.UUCP (12/04/83)
I do agree that attaching types to values rather than identifiers
is an interesting idea, and that lots of languages already do it
(everything with runtime types rather than compile time).
But I definitely do not agree that everything with runtime types
is therefore strongly typed.
I would not say that Snobol4 and Smalltalk are strongly typed,
because the types are automatically coerced. A strongly typed
language would complain immediately if a type mismatch occurs.
Snobol4 and smalltalk both handle the situation as best they can,
and complain only as a last resort.
--
spoken: mark weiser
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs
ARPA: mark.umcp-cs@CSNet-Relayandree@uokvax.UUCP (12/05/83)
#R:dartvax:-41100:uokvax:9000008:000:1341 uokvax!andree Dec 3 14:27:00 1983 It sounds like what mark wants from his typing is something halfway between C/FORTRAN/Assembler/BCPL/etc and Snobol/LISP/Smalltalk. I.e. - something that will catch typos, but NOT force you to rebuild a tool for every type it would be usefull on. Let me propose the following: 1) A LISP-like expression structure: Everything is a function call. To avoid the Lots-of-Insidious-Single-Parens problem, lets add syntactic sugar for the common operations, so that `a + b' is identical to `add(a, b)'. This should work on user-defined types as well as the built-in types. 2) The type-checking gets done at the function call. The call `f(x, y)' only compiles if x and y are of the same type, and of a type handled by f. 3) The decleration of a function carries the typechecking information. A good example could be: sort = proc [t: type] (x: array[t]) where t has lt: proctype (t, t) returns (bool) which would declare a function to sort an array of arbitrary type, just so the type has an lt (less than) operator. I like this - which is one of the reasons I started using CLU. For a better and more complete description of how this works, see the Springer-Verlag `Lecture Notes in Computer Science', #114: `CLU Reference Manual' by Barbara Liskov et. al. CLU also has some other nice mechanisms that aren't in common use. <mike
tjt@kobold.UUCP (T.J.Teixeira) (12/06/83)
> ... with lots of superflous conversions going on at runtime. > PL/1 and APL are like this too. APL has the basic types character and numeric AND vectors and arrays of various sizes. For vector operations APL checkes the shapes of the arrays ("conformability") and will automatically convert scalars to vectors. -- Tom Teixeira, Massachusetts Computer Corporation. Westford MA ...!{ihnp4,harpo,decvax,ucbcad,tektronix}!masscomp!tjt (617) 692-6200
asente@decwrl.UUCP (Paul Asente) (12/07/83)
I find that CLU is my language of choice for writing programs. If I had anything to say about it, I'd never use anything else. (Well... almost never) When I'm writing a CLU cluster to implement something or other, it almost always turns out that with just a little bit more effort I get something that is several times more general. Like some other contributor to this debate, I also find the only thing I can think of to be concerned about with CLU is the question of whether assignments are really efficient. When people complain about strong typing, it seems to me that what they really are objecting to is the weak functionality that goes with it in languages like Pascal and, yes, Modula-2. -paul asente decwrl!asente
davidson@sdcsvax.UUCP (12/07/83)
Computer languages are a religious issue primarily because different languages can offer their programmers wildly differing views on the nature of programming. Let me give some examples. FALLACY: People who come from the mainstream, where types are associated with variables, think that languages like LISP and Smalltalk, where types are associated with objects, do not allow correctness checks at compile time. They also think that the meaning of ``types associated with variables'' means that a type tag is necessarily present at runtime. FACT: Correctness proofs were first done in LISP, and continue to be done. LISPs elegant semantics makes them much easier than in, say, Pascal. Implementations of functional languages often use runtime data tags to allow for easier debugging and generic operators. However, these tags correspond to a few primitive datatypes, not to the abstract datatypes in the mind of the programmer. Abstract datatypes are a metalinguistic concept used in program design and verification. (I remember back in the mid-70s how people kept thinking that Pascal's datatypes involved runtime overhead.) Similarly, while Smalltalk objects have class tags, these tags also do not necessarily correspond to the programmer's idea of their abstract datatype. WARNINGS: 1. The term object, as used in functional language terminology, is quite different from the term as used in object oriented language terminology. 2. The term functional language as used by LISP folks, is quite different from the term as used by folks like John Backus who study what THEY call functional programming. The latter bunch refer to LISP as an object oriented language (and not as a complement). 3. Correctness proofs are done with quite different methodologies and take quite different forms in different languages. For example, in Pascal, one proves assertions about the contents of variables. In LISP, one proves assertions about the result of a function as a function of its arguments. In FP, one manipulates the program algebraically until one arrives at an identity. In PROLOG, programs are their own correctness proofs (PROLOG programs have both a declarative and a procedural semantics). NOTE: By ``at compile time'', you should understand: ``from the text, independent of any particular run with any particular dataset''. Many languages are not always compiled in the conventional sense. As a language buff who can't resist learning new languages whenever possible (especially if they are in a new family), I have come to the conclusion that it is impossible to usefully criticise a language until you've not only learned it, but have immersed yourself in its worldview. Time and again, I've learned a new language, used it successfully, then discovered I didn't know it at all. Therefore, my advice to people who would criticise languages on any other basis, is DON'T. -Greg
bhyde@inmet.UUCP (12/10/83)
#R:vax2:-81700:inmet:4700013:000:1268 inmet!bhyde Dec 3 22:30:00 1983 It seems very reasonable that the compiler should be able to sweep over the input a couple times. Ada is full of stuff to avoid this, the form of an object must be bound in the same compilation unit as its first use. On this topic; Ada's elaboration before use rules are particularly interesting. The problem with not doing this is that at worst the entire program must be available to the compiler. Programs are big, and the data structures that compilers build to describe them are much bigger. Another problem is that the compiler then has to check for cyclic dependencies; records including instances themselves, generics including instances of themselves. The range of such a check can be very large, again the compiler may have to cover quite a scope to ckeck for them. Ada includes a few such checks, to make the check tractable the closure computation must be done incrementally as each compilation unit arrives and the program library is decorated with the partially completed computation. Quiz, is the rule that generics maynot contain instances of themselves required in any languages? It would be fun to attempt to design a production, modular (i.e. spec's and bodies seperated), strong typed language with out these kind of rules. ben hyde