Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven!ni.umd.edu!uc780.umd.edu!cs450a03 From: cs450a03@uc780.umd.edu Newsgroups: comp.lang.misc Subject: RE: Dynamic typing (part 3) Message-ID: <15MAR91.08310310@uc780.umd.edu> Date: 15 Mar 91 08:31:03 GMT References: <602@optima.cs.arizona.edu> <1991Mar13.010946.4536@engage.enet.dec.com> <13MAR91.00251986@uc780.umd.edu> <1991Mar13.163629.12630@engage.enet.dec.com> <14MAR91.22372006@uc780.umd.edu> <1991Mar15.062756.3781@engage.enet.dec.com> Sender: usenet@ni.umd.edu (USENET News System) Organization: The University of Maryland University College Lines: 120 Nntp-Posting-Host: uc780.umd.edu >In article <14MAR91.22372006@uc780.umd.edu>, cs450a03@uc780.umd.edu writes: > I don't see what point you're trying to make. If these aren't >take a look at most any object-oriented system designed in the last >decade or so with strong typing and parametrized types. The points I'm trying to make are that strong typing is a good thing, that dynamic type checking can be a good thing, and that two functions with different domains may have a subdomain in common. I'm claiming that a function's domain is the basis for typing. I'm claiming that there is no need for me to declare the type of result of function F if the result of function F is also the result of some other 'sub-function' G which has results of some known type (e.g. aggregates of 0 or more non-negative integers with a maximum value somewhere below a billion). I'm claiming that there is no need for me to declare that argument X to function F must have type K, if argument X is also an argument to function H which only accepts type K. I see no reason this couldn't be put into a compiler. Well, actually, I use a compiler which does this sort of thing. I rarely use it, unless I find code that's eating up cpu doing type checking/bounds checking. Also, there are cases where compiled code has worse performance than interpreted code (the interpreter has had some recent changes, since the release of the compiler). Incidentally, I have no objection to allowing declarations (e.g. restrict function F's argument X to single values, no aggregates). I prefer those declarations to be used sensibly, though. For example, if F is applied to datum Y, which has N single values, apply F n times and return an aggregate of n results). I do not see this as being in any way ambiguous. > (In direct answer, picking a syntax, perhaps "contains(y, x)", >"select_first_n(seq, 5)", "Object", huh? let's keep pointers out of this.., >assuming that the Table type is parametrized ala "Table[KeyType, >ValueType]", it's the type specified for KeyType when the particular >Table value instance was created.) Why keep pointers out of it? Why must I keep types independent of the typed information? You are going to waste my time issuing bean-certificates if you force me into that kind of situation. >|> Why should I limit assignment (name-association) based on the domain >|> of, for instance, addition? > > I don't know, why should you? I think you're trying to twist what I'm >saying somehow but I don't see your point. Perhaps it's your terminology. >I'll spell it out. > > If in some scope you have a variable, let's call it X, which is >declared to be of type "Number" (presuming all the types with >algebraic-type operations fall under there for the sake of argument,) >the compiler should ensure that any value I attempt to bind >X to is compatible with the type of X. Ok, let me restate myself. If X is going to be applied to function Y which only accepts numbers as arguments, then consider X to be declared type Y. If you are in an interpretive environment (reasonable if you are adding functionality on a day-to-day basis), it is more efficient to wait till X - Y closure to check type. In a compiler, you do not gain anything by REQUIRING that I declare that X can only be a number. > I can think of a better reason not to have runtime type checking for >log: if I'm doing it quite a bit, the runtime costs are high. Wasn't that >part of the whole original premise or why David Gudeman made his >original postings? They might be high, especially if you aren't working with aggragates. That's what compilers are for. That is, to eliminate redudant operations where possible, including redundant type checks. > I believe that Ada's model here is correct. No correct program may >depend on exceptions for its operation. (Implying that if you have >a correct program, you can turn off all the nice bounds-testing and >such and end up with a nice and *fast* program. Commercial Ada >compilers from both Rational and Digital do this.) I'd hate to have to do development work in Ada. I wouldn't mind having Ada available to RE-write time critical sections of code. Me: >|> >|> Finally, to Mr. Grier, who posed the rhetorical problem about trusting >|> >|> software in critical systems which might have latent bugs: would you >|> >|> really trust such software if it had never been tested? Would it make >|> >|> you feel safer if each type of data required seperate chunks of code, >|> >|> with the associated tests and branches and variant storage mechanisms? Grier: >|> > Yes and no. No first. >|> > >|> > "No", because that's why I think that subtyping and inheritance >|> >is so wonderful. If there's an obvious way to specialize an >|> >operation to a subtype, it *is* clearer and still absolutely >|> >statically correct to apply the supertype's operation to a value >|> >of the subtype. Me: >|> No this makes you feel safer? Or no it doesn't make you feel safer? Grier: > Beings I discusses my thoughts on both counts, does it matter other >than you wanting to pick nits? My apologies for being sarcastic. I keep forgetting how time and distance affect meaning. What I meant was, I asked a simple yes/no question (ok, somewhat rhetorical) and the first few paragraphs of answer did not address what I thought was the key issue. This apology also good for my remarks after the "Yes" half of the answer. .. >|> And how is a compiler supposed to prove that a program fulfills its >|> purpose? At best, the compiler can prove that the program can be >|> compiled. >|> > > Re-read my previous posting today. (well, yesterday at this time) I did not see anything that answers this question. Raul Rockwell