3 ms·

One thing I don't get (not knowing much about type theory, and only having implemented a toy C++ subset compiler in a university class once): Take a dynamicall

One thing I don't get (not knowing much about type theory, and only having implemented a toy C++ subset compiler in a university class once): Take a dynamically typed language, say, Python: a = 1 a = "foo" What disadvantage would you have if the language used type inference to set a to a static type of int when it encountered it? a = 1 a = "foo" # compile/interpretation time error, "a is an int" 1) You get the speed/optimizations + tooling of static typing. 2) You get the dynamic typing benefit of not messing with type definitions etc. Do people really do stuff like changing the type of a variable in normal Python use, anyway? Usually when I set something to something, I keep it in the same type. Is there a disadvantage, besides having to initialize every variable upfront? Polymorphism/Generics are orthogonal to this, no? Are there any languages that do it this way?

Groxx 15y ago
One problem I can see is that you lose the ability to define and use interfaces, unless you declare them explicitly every time you wish to make a variable which holds that type. There's nothing wrong with that, but what it does mean is that people are much more likely to simply use classes and inheritance trees for everything, to simplify the syntax. Laziness will win out often enough to make writing / finding good code a nightmare. edit: also, if you try to infer polymorphic changes / interface changes, then it gets harder and harder to figure out what's correct and what's not. Was the change earlier dropping your collection to an enumerable correct, or was it the hash you just tried to save? And what if you are interface or inheritance-happy, and have hundreds of possible options? It can probably be solved reasonably quickly, but not for free.
rst 15y ago
There are several languages with type inference, although most can't infer types in all cases: Haskell, ML variants (SML, CaML, etc.), and Scala are the most thorough. There are some common language features that make type inference tough, most notably mutable data. It's difficult to infer the element type of an array unless you know where it's been, which can be difficult or impossible to know in situations involving separate compilation. Some ML variants can infer all types for programs that avoid using mutable data.
DasIch 15y ago
Type Inference only works nicely if your have static and strong types. Heterogenous data structures are non-trivial in such a language, duck typing doesn't work anymore etc. In other words people do use these features, they use these features a lot and that is not a problem. You are just using an overly trivial example in which you make assumptions without considering all the consequences.
- dextorious 15y ago
  """Heterogenous data structures are non-trivial in such a language""" Why would they be? You just need a common parent type, like object, or something like Objective-C's "id" type, to indicate that a structure/method can accept any type. So: a = 1 # int b = "foo" # string c = Cat() # cat object d = Singer() #singer object you could have a built-in, say list, structure: mylist = [a, b, c]; mylist.append(d) or myadt = CustomDataType() myadt.add(c); myadt.add(d); """duck typing doesn't work anymore etc.""" Wikipedia: "duck typing is a style of dynamic typing in which an object's current set of methods and properties determines the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface". So, why would duck typing not work? Duck typing is about the ability to call methods on any type that implements them. It's irrelevant if the type is static, not? Say: foreach item in myadt: item.sound() Cat and Singer could be from totally different objects hierarchies, and the compiler/language would know that both implement "sound()" and let you call it. If an object on myadt doesn't implement sound() you get a runtime error. """You are just using an overly trivial example in which you make assumptions without considering all the consequences.""" Emm, the whole point of my comment was in me EXPLICITLY ASKING for possible consequences. Which you kinda missed, judging by this statement.

Groxx 15y ago

One problem I can see is that you lose the ability to define and use interfaces, unless you declare them explicitly every time you wish to make a variable which holds that type. There's nothing wrong with that, but what it does mean is that people are much more likely to simply use classes and inheritance trees for everything, to simplify the syntax. Laziness will win out often enough to make writing / finding good code a nightmare. edit: also, if you try to infer polymorphic changes / interface changes, then it gets harder and harder to figure out what's correct and what's not. Was the change earlier dropping your collection to an enumerable correct, or was it the hash you just tried to save? And what if you are interface or inheritance-happy, and have hundreds of possible options? It can probably be solved reasonably quickly, but not for free.

rst 15y ago

There are several languages with type inference, although most can't infer types in all cases: Haskell, ML variants (SML, CaML, etc.), and Scala are the most thorough. There are some common language features that make type inference tough, most notably mutable data. It's difficult to infer the element type of an array unless you know where it's been, which can be difficult or impossible to know in situations involving separate compilation. Some ML variants can infer all types for programs that avoid using mutable data.

DasIch 15y ago

Type Inference only works nicely if your have static and strong types. Heterogenous data structures are non-trivial in such a language, duck typing doesn't work anymore etc. In other words people do use these features, they use these features a lot and that is not a problem. You are just using an overly trivial example in which you make assumptions without considering all the consequences.

dextorious 15y ago
"""Heterogenous data structures are non-trivial in such a language""" Why would they be? You just need a common parent type, like object, or something like Objective-C's "id" type, to indicate that a structure/method can accept any type. So: a = 1 # int b = "foo" # string c = Cat() # cat object d = Singer() #singer object you could have a built-in, say list, structure: mylist = [a, b, c]; mylist.append(d) or myadt = CustomDataType() myadt.add(c); myadt.add(d); """duck typing doesn't work anymore etc.""" Wikipedia: "duck typing is a style of dynamic typing in which an object's current set of methods and properties determines the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface". So, why would duck typing not work? Duck typing is about the ability to call methods on any type that implements them. It's irrelevant if the type is static, not? Say: foreach item in myadt: item.sound() Cat and Singer could be from totally different objects hierarchies, and the compiler/language would know that both implement "sound()" and let you call it. If an object on myadt doesn't implement sound() you get a runtime error. """You are just using an overly trivial example in which you make assumptions without considering all the consequences.""" Emm, the whole point of my comment was in me EXPLICITLY ASKING for possible consequences. Which you kinda missed, judging by this statement.