Re^4: "strong typing" is potentially ambiguous

The classical example (forgetting perl for the moment) is a statement like 3.14 + "dog". If we assume that 3.14 is a floating point number, "+" is the addition operator, and "dog" is a string, most people might agree that the statement is meaningless.

*thinks real hard about this*

So, if I'm understanding what you're saying and all the links that have been provided ... we could arrive at the following definitions:

A type is a set of values (with defined characteristics for inclusion) for which a set of meaningful operations is defined. (Whether or not the set of operations is closed over the set of values is indeterminate.)
A type system is a set of types. (Whether or not the various types overlap is indeterminate.)

So, in your example, the operation '+' isn't defined for the value "dog". However, let's say we had the operation '_' (string concatenation). It would be defined for "dog" ... it could also be defined for "3.14". So, the statement 3.14 _ "dog" could have meaning ... right?

I do understand what all the fuss is about re: types ... having a strong type system would eliminate whole classes of bugs, in the way that automatic memory management has eliminated a whole class of bugs. Arguably, it is the Lazier solution to do this. And, I think that some of the people on the lambda site are correct in saying that it's a sociological issue, not a technical one ... sort of.

I think I need to think on this topic some more ...

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Comment on Re^4: "strong typing" is potentially ambiguous

Replies are listed 'Best First'.
Re^5: "strong typing" is potentially ambiguous by hardburn (Abbot) on Dec 15, 2004 at 17:36 UTC
A type is a set of values Note that most type theorists say that type theory is based on Category Theory, not Set Theory. Category Theory is much broader and more ambitious than Set Theory. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]
Re^5: "strong typing" is potentially ambiguous by sleepingsquirrel (Chaplain) on Jan 27, 2005 at 05:38 UTC
I recently came across this paper which gives a nice introduction to some advanced type theory. -- All code is 100% tested and functional unless otherwise noted.	[reply]
Re^5: "strong typing" is potentially ambiguous by jdporter (Paladin) on Dec 15, 2004 at 16:12 UTC
A type is a set of values ... I'm glad you brought this up; it gives me a chance to take the flame war in a different direction. ;-) Under some ped^Wsemantic systems at least, what you've given, above, is a definition of "class", whereas "type" is defined in terms of behavior, not representation. If two objects can "do the same things", then they're the same type. (Usually this means having the same defined behavioral interfaces, irrespective of actual implementation. Sometimes the definition is made more strict: to "do the same thing", the objects must have idential implementations.) Of course, OO language vendors (who shall not be named, cough), prefer to use the terms "type" and "class" interchangeably, it seems. Stand by for updates as I'm forced to recant...	[reply]
Re^6: "strong typing" is potentially ambiguous by dragonchild (Archbishop) on Dec 15, 2004 at 16:40 UTC
blinks That's really funny, and shows how out of practice I am with formal definitions. I was trying to get at the "quacks-like-a-duck" definition for types. ponders Maybe this is better: A type T is the set of values for which any operation in a given set of operations O is closed over. I noticed on Lambda that some were complaining about defining types in terms of sets. I'm trying to figure out how you define types without sets ... As for the term "class" ... isn't a class a coder-defined aggregation of data and coder-defined behaviors? So, in some sense, it would be a coder-defined type, so long as the behaviors were closed over the class ... ? Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply]
Re^5: "strong typing" is potentially ambiguous by sleepingsquirrel (Chaplain) on Dec 15, 2004 at 16:50 UTC
So, in your example, the operation '+' isn't defined for the value "dog". However, let's say we had the operation '_' (string concatenation). It would be defined for "dog" ... it could also be defined for "3.14". So, the statement 3.14 _ "dog" could have meaning ... right? Yes, that could have meaning. If you're the person designing the type system, you get to decide which statements have meaning. So you weigh the trade-offs. On the one hand, allowing the use of '+' in a statement like `3.14 + "dog"` has the advantage of being short and sweet; easy for the programmer to type, and it reduces the number of operators/functions he has to learn. And if the programmer has a question about the semantics, he can look it up in the manual. On the other hand, you ask if it is really so much trouble to break that operator into two separate ones: `stringify(3.14) + "dog"` or `3.14 + numify("dog")` . Now the programmer is forced to make his intentions explicit in the code, rather than implicit (i.e. in the documentation). Is one method better/faster/cleaner/buggier than the other? You get to decide (but be forewarned, that's the stuff of holy wars). -- All code is 100% tested and functional unless otherwise noted.	[reply] [d/l] [select]


No such thing as a small change
	PerlMonks