|
|
|
|
|
|
by msla
3255 days ago
|
|
|
My point is, types which specify low-level details about data size and representation but not the semantics of which operations are actually sensible to use on them and which types can be meaningfully used together are not really types, in that they don't make programs any easier to read or write. I also deny that autoconversion weakens a type system. For example, if you have a data type which holds a person's height, it is utterly uninteresting what units it's in most of the time, and it can save a lot of trouble if the runtime or compiler keeps track and converts automatically if you try to add a height currently being stored as inches to one currently being stored as centimeters, or adding centimeters to fractional centimeters rounded to the nearest millimeter, for example. There are any number of purely mechanical autoconversion tasks which can and should be done automatically and which don't change the type, in that they don't change which operations are valid for the value. And that autoconversion still wouldn't make adding height to age any more sensible, even if the two values were truly indistinguishable at the machine code level. |
|
|
Go lets you do this just fine. I think it would help if you used concrete examples to demonstrate what you mean.
> I also deny that autoconversion weakens a type system.
Deny it all you want. I don't really care to get into a definitional war with you. The definitions I use are the ones that have a consensus backing them[1]:
> in general, a strongly typed language is more likely to generate an error or refuse to compile if the argument passed to a function does not closely match the expected type. On the other hand, a weakly typed language may produce unpredictable results or may perform implicit type conversion.
If you read that article, you'll see that most of it is about describing what the terms mean. There is no precise definition, and I've been careful to embrace that fact in my comments. Nevertheless, in common usage, the terms "strong" and "weak" in the context of type systems typically demarcate the prevalence of implicit autoconversions between types.
> And that autoconversion still wouldn't make adding height to age any more sensible, even if the two values were truly indistinguishable at the machine code level.
Weaker type systems permit this form of autoconversion. Notice that "strong" and "weak" are properties of the type system itself, and that they refer to implicit autoconversions between types. Autoconversions that occur because of appropriate polymorphism defined by users of the language is an orthogonal concept.
I think the bottom line is that you aren't using "strong" and "weak" as they are commonly used. If you want to make up your own definitions for them, then please just say that so that we can stop wasting time. (I have no problem with you coming up with your own definitions, I just want you to acknowledge that you're doing it.)
[1] - https://en.wikipedia.org/wiki/Strong_and_weak_typing