Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!opal!wg From: wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp) Newsgroups: comp.lang.misc Subject: Re: Dynamic typing (part 3) Keywords: type inference static dynamic lisp ml Message-ID: <3092@opal.cs.tu-berlin.de> Date: 17 Apr 91 20:12:21 GMT References: <3073:Mar2820:38:5191@kramden.acf.nyu.edu> <1991Apr1.010526.26781@neon.Stanford.EDU> <1991Apr9.021700.2688@neon.Stanford.EDU> Sender: news@opal.cs.tu-berlin.de Reply-To: wg@opal.cs.tu-berlin.de Followup-To: comp.lang.misc Organization: Technical University of Berlin Lines: 100 Nntp-Posting-Host: troll.cs.tu-berlin.de [LANGUAGE WARNING: You might going to see a lot of spelling errors, notion errors, style errors, etc.] brm@neon.Stanford.EDU (Brian R. Murphy) writes: >My complaint about statically typed languages is that I _can't_ do >some things in them that I _do_ in dynamically typed languages (such >as Lisp). For example, I can't I write a function which returns >either a boolean or an integer in a complex way. I can't write my own >Y combinator. I can't write a function which allows either a sequence >of functions which range over numbers or a sequence of numbers as an >argument. Your examples are quite abstract. Maybe its missing phantasy -- but i cannot imagine the use of a function which returns either a boolean or an integer unless there is some relationship between this values, e.g. the boolean is an error value and normally an integer is expected, in which case either subsorting (multiple supersorts, of course) or parameterization is sufficient. And i see no need to write your own Y combinator, unless you use a language for a ground course in lambda calculus. (BTW, you can model it in strongly typed functional languages using recursive data types; of course a bit cumbersome). >Let's consider what a type system might do for me: >(1) It constrains the behavior of primitive functions so the program >doesn't do undefined things. >[ ... ] >[ This is essential, in my opinion, in either kind of type system. ] >(2) It constrains the use of procedures that I write so that they >aren't applied to things they weren't intended to apply to. Thus, I >might declare an argument to have a particular type, and applications >to objects not in that type are prevented. I do not see the difference between primitive functions, in which case you regard type safety as essential, and user defined onces. > [Thus] I want a type system which > (a) allows me to omit many type declarations (where unnecessary) > (b) allows me to be very specific in constraining some arguments Yes, i'am too. >With dynamic typing, I can simply write predicates to constrain >arguments/variables (Common Lisp, FL, some implementations of Scheme >do this). ... but i regard it as an abuse of notion to call such dynamic calculated predicates types. You can model them just using conditionals and an error halt function. What Common Lisp gives you here is simply syntactic sugar in an essential untyped environment, and some (rather restricted) kind of partial evaluation of this predicates. >You static typing advocates claim that a static type system can do >this for me, but I claim that it can't. A type language powerful >enough to constrain arguments anywhere near as precisely as I need >won't allow me to omit many types. My experience is the other way around. It would allow me to omit many types, and in some rare cases, if have to add declarations. However, unless I'am going to hack a one-night program, i would always declare signatures at least for the exported functions of a module even if they could be inferred. This seems to me a reasonable kind of documentation. >Type inference is only possible >for a limited class of type languages, and they tend to be fairly >weak. In addition, certain programs are forbidden simply because they >utilize types which can't be described by the type language used. This is theoretically right. But the question is, how often instances outside this limited, weak class are required in practice? For example, tell me an instance of practical evidence for the need of self application! Whats irritating me more and more in this discussion (as long as I'am following it; the last week) is that the advocates of dynamic typing claim for more expressivness, which *looks* like the arguments of practical men, but in fact seems to be more of philosophical nature. (This would be quite alright, but say it like it is.) I mean, the arguments often cummulate in some existential view to software development: anything a man is able to do should him be allowed to do ... pull down restrictions since they are restrictive ... redundancy is for softys ... etc. > -Brian Murphy > brm@cs.stanford.edu -- Wolfgang Grieskamp wg@opal.cs.tu-berlin.de tub!tubopal!wg wg%opal@DB0TUI11.BITNET