🚀 go-pugleaf

>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