What is a type error?

[Chris Smith]

Marshall <marshall.spight at gmail.com> wrote:
> It's never been a strong point. Made worse now that my daughter
> is one of those up-at-the-crack-of-dawn types, and not old enough
> to understand why it's not nice to jump on mommy and daddy's
> bed while they're still asleep. But aren't you actually a time zone
> or two east of me?

Yes, I confess I'm one time zone to your east, and I was posting later 
than you.  So perhaps it wasn't really past your bedtime.

> The fields of an object/struct/what have you are often hidden behind
> a method-based interface (sometimes callled "encapsulated") only
> because we can't control their values otherwise.

I believe there are actually two kinds of encapsulation.  The kind of 
encapsulation that best fits your statement there is the getter/setter 
sort, which says: "logically, I want an object with some set of fields, 
but I can't make them fields because I lose control over their values".  
That part can definitely be replaced, in a suitably powerful language, 
with static constraints.

The other half of encapsulation, though, is of the sort that 	I mentioned 
in my post.  I am intentionally choosing to encapsulate something 
because I don't actually know how it should end up being implemented 
yet, or because it changes often, or something like that.  I may 
encapsulate the implementation of current tax code specifically because 
I know that tax code changes on a year-to-year basis, and I want to 
ensure that the rest of my program works no matter how the tax code is 
modified.  There may be huge structural changes in the tax code, and I 
only want to commit to leaving a minimal interface.

In practice, the two purposes are not cleanly separated from each other.  
Most people, if asked why they write getters and setters, would respond 
not only that they want to validate against assignments to the field, 
but also that it helps isolate changes should they change the internal 
representation of the class.  A publicly visible static constraint 
language that allows the programmer to change the internal 
representation of a class obviously can't make reference to any field, 
since it may cease to exist with a change in representation.

> However for a function, the "fields" are the in and out parameters.
> The specific values in the relation that the function is aren't known
> until runtime either, (and then only the subset for which we actually
> perform computation.)
> 
> Did that make sense?

I didn't understand that last bit.

> There are certainly syntactic issues, but I believe these are amenable
> to the usual approaches. The runtime/compile time question, and
> decidability seem bigger issues to me.

Well, the point of static typing is to do what's possible without 
reaching the point of undecidability.  Runtime support for checking the 
correctness of type ascriptions certainly comes in handy when you run 
into those limits.

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation