goer@SOPHIST.UCHICAGO.EDU (Richard Goerwitz) (04/10/90)
I find that I don't make much use of automatic type conversion.
Even though this feature lies at the heart of the Icon implemen-
tation, I wonder how much it lies at the heart of the language's
conception.
Normally, if I think that a type conversion will occur, I make
the conversion explicit with a builtin function like string()
or cset() or integer(). I find that if conversions are occurring
where I don't know about them, they are *usually* indicative of
sloppy programming on my part.
If automatic type conversion disappeared, what sorts of ramifications
would it have? Would some aspect of the language that I haven't
considered be radically altered? Or would it permit greater
speed and allow for fuller implementation of things like operator
overloading (which some seem to want)?
What if we had optional static typing? Would this offer the best
of both worlds? How would such a feature be implemented and inte-
grated into the rest of the language (if in fact it is desirable
in the first place)? Would it be hard to do?
I don't claim to be a theoretician. Any discussion or clarification
would be much appreciated. Flames as well. I don't take this sort
of thing too personally.
-Richard L. Goerwitz goer%sophist@uchicago.bitnet
goer@sophist.uchicago.edu rutgers!oddjob!gide!sophist!goeralanf@bruce.OZ (Alan Grant Finlay) (04/11/90)
In article <9004100609.AA06171@sophist.uchicago.edu>, goer@SOPHIST.UCHICAGO.EDU (Richard Goerwitz) writes: > > I find that I don't make much use of automatic type conversion. > Even though this feature lies at the heart of the Icon implemen- > tation, I wonder how much it lies at the heart of the language's > conception. I call this kind of type conversion "type coercion" and if I can quote from T.W. Pratt's book (2nd Edition) "Programming Languages, Design and Implementation", p 57: "Coercions are an important design issue in most languages. Two opposed philosophies exist regarding the extent to which the language should provide coercions between data types." The two schools of thought Pratt refers to are: (i) only do essential coercions like int/real (Modula-2 goes even further and does none!), (ii) if there is a coercion that might make sense then do it (e.g. if a string looks like it could be a numeral then convert it). > > Normally, if I think that a type conversion will occur, I make > the conversion explicit with a builtin function like string() > or cset() or integer(). I find that if conversions are occurring > where I don't know about them, they are *usually* indicative of > sloppy programming on my part. Your philosophy is (i) above. > > If automatic type conversion disappeared, what sorts of ramifications > would it have? Would some aspect of the language that I haven't > considered be radically altered? Or would it permit greater > speed and allow for fuller implementation of things like operator > overloading (which some seem to want)? > From the point of view of implementation it is probably easier to do no coercions. There would be little difference in execution speed either way. It would probably be easy to provide a flag to turn this feature on or off when using Icon. Unfortunately this would mean two kinds of source code proliferating. In the functional language community a similar controversy surrounds the use of strict or lazy evaluation of procedure arguments. Lazy evaluation is more powerful but can enable some very arcane programming techniques. The functional language ML chose to use strict evaluation. Some people liked ML except for this one thing, hence LML was born. Imagine what it would be like if every language design decision was made an implementation variable! > What if we had optional static typing? Would this offer the best > of both worlds? How would such a feature be implemented and inte- > grated into the rest of the language (if in fact it is desirable > in the first place)? Would it be hard to do? > Static type checking is not realistically possible for a language such as Icon. Consider the expression: if x=0 then "small" else 1 The type of this expression may be impossible to determine until run time. In Icon as well as such expressions as these it is possible to check the type of a value at run time and act according to this information. I have used this myself to obtain the behaviour of variant types. For example: if type(x)=="integer" then x+1 else 0 Expression such as this are quite foreign to languages with static type checking. Perhaps what you need is some kind of "lint" program like that which the C programming language has. For programs which can be statically typed it could warn of any type clashes and coercions that will occur, for other programs it could just indicate that static type checking was not feasible.