3 ms·

Or Python. What are you going to do with [1.0, "abc", True], besides throw a TypeError?

• dragonwriter 12y ago
  > What are you going to do with [1.0, "abc", True], besides throw a TypeError? for x in [1.0, "abc", True]: print(x) Of course, all the legitimate things you can do with it illustrate ways in which the collection isn't really heterogenous, its just as collection of elements which have different types that are all within the same sum type. The thing is that in dynamic languages, there's one universal sum type, and every function effectively takes arguments and returns results of that type. In Haskell, you have to plan more for the specific sum types you are going to be using, which in certain situations makes some things more complicated. Of course, it also means that things that would be in documentation or approximately verified in tests can be statically verified by the compiler, so there is a trade off.
  • kazinator 12y ago
    "The thing is that in dynamic languages, there's one universal sum type, and every function effectively takes arguments and returns results of that type." That is a reductionistic view, like saying that everything is ultimately ones and zeros. The storage place in a dynamic language, such as a variable, or array element or whatever, is not understood to have a type in that language. The machine language (or whatever) implementation kernel of that language understands that to have a type, but that's in a different language. That kernel knows that, say, if the least significant two bits of the storage location are 00, then it's a pointer to a heap object, and that kind of thing. That code must be written safely: like only if those two bits are 00 must it treat the value as a pointer, and otherwise not. This is all implementation detail, not accessible from the high level language (or not without special escape hatches). The type of the dynamic objects is their dynamic type; and when dynamic languages feature compile-time type inference, that inference works with those types, not with the fictitious "universal sum type".
    • dragonwriter 12y ago
      > That is a reductionistic view Maybe, so what? > like saying that everything is ultimately ones and zeros. Well, except that saying everything is ultimately ones and zeros isn't (at least in this context) a useful starting point for explaining anything. > The storage place in a dynamic language, such as a variable, or array element or whatever, is not understood to have a type in that language. I'm not talking about storage places, I'm talking about the logical design -- a function (regardless of the features of the language) is designed to operate on some set of values and return a result from some set of values. These sets can ar the types I'm interested in -- whether they are implemented as (static) types in a language, or as tags / dynamic types, or whatever, or even if the language had no concepts of types at all (and, in most real languages, and can be true true even withHaskell, as in the head function on lists). And to the extent that "heterogenous" collections are useful, they are useful specifically because they are not really heterogenous, even if the shared logical type to which the elements must belong is not coherently defined as a discrete "type" within the type system of the language.
  • Chattered 12y ago
    But how did you get the collection in the first place? If all you wanted to do was print the elements, you would have made it a collection of strings, and populated it by calling a "toString" function each time you added an element.
  • coolsunglasses 12y ago
    I'm pretty sure "Rank2 type + Show a =>" suffices for your "print" use-case.