6 ms·

And this is where I decide the language is too far developed on the wrong foundation. I cannot put up with type systems that don't have complete or near-comple

And this is where I decide the language is too far developed on the wrong foundation. I cannot put up with type systems that don't have complete or near-complete type inference. I don't know why one would start a new project in a language that didn't support Hindley-Milner.

Locke1689 14y ago
Just to elaborate on what danking00 is saying, the extra syntax in this case is not adding any extra information (to the compiler). The left hand type of the expression can be completely inferred at compile time, in this case. What that required syntax is adding is pain, but no gain (except for imperceptibly faster compile time). In Haskell this would look like: TagDataMap = [ ("title", ((3, 30, stripnulls)), ("artist", ((33, 30, stripnulls)), ... Haskell will correctly infer that TagDataMap :: [(String, (Integer, Integer, String -> String)]. Ok, technically this is an associative list, not a Python dictionary, but it is a map and can be accessed like one. Hell, most people use dictionaries with less than 10 items, which are much slower than arrays most of the time
- fusiongyro 14y ago
  "the extra syntax in this case is not adding any extra information (to the compiler)." This actually isn't true in C++, because there could be many classes in scope that could take a list initializer like this. In Haskell, no literal with [] can "turn into" something besides a list, but that can happen in C++: vector<int> items = {1,2,3,4}; int[] items = {1,2,3,4}; These have different types, so how would C++ know which one you meant if you instead wrote: auto items = {1,2,3,4}; Again, in Haskell this isn't a problem because literals have essentially a single type. (Edge cases around integers and strings notwithstanding). Edit: Just to clarify, in a Hindley-Milner system you could maybe get away with something like that, but everything you name in an HM system you must use, and that isn't the case in C++: void foo() { auto items = {1,2,3,4}; return; } I can then make two classes with list constructors: struct FooClass { FooClass(std::initializer_list<int> list) { cout << "Made a Foo!" << endl; } }; struct BarClass { BarClass(std::initializer_list<int> list) { format_your_hard_disk(); } }; Obviously there are consequences to choosing the right type, but the type of that value never leaks out of the function. Nevertheless, because side-effects can happen anywhere, even in a constructor, C++ cannot optimize that out. This might be a convoluted example, and it may be flawed, but conjuring up others is not hard and demonstrates that C++ simply cannot ever have true HM type inferencing. Since the "real deal" is not possible, the language is complex and the standard is large, I would not expect to be able to live without annotations in C++-land. (Again, the FQA makes the horror of multiple non-orthogonal solutions to the same problems quite clear).
  - Locke1689 14y ago
    This is definitely true and demonstrates how competing design decisions can add huge complexity to a language. C++ made earlier design goals to allow heavily context-dependent overriding, which has side effects on what features it can add later.
  - Peaker 14y ago
    Integers and Strings aren't edge cases. Their literals are polymorphic and typed. C++ could also type its list initializers with some polymorphic type (similar to Haskell's Num) but didn't do so. This is not inherent.
    - fusiongyro 14y ago
      They're not worth discussing because they're a counterintuitive mess rather than a case study of the glory of HM. Maybe edge case isn't the right word, but they're definitely not something I would hail as a perfect resounding success. There are no polymorphic literals in ML, just polymorphic math operators, which is enough of a blight on the standard that OCaml discarded it and forces you to use different operators for real and integer arithmetic. And there's only one kind of string in both MLs. Haskell's Num hierarchy is troublesome. They traded usability for + with complexity for /. It's extremely unlikely that you could write a program in Haskell that does much arithmetic and have it build correctly on the first try without any manifest typing. This is one reason students of Haskell find things so confusing: type declarations are necessary at the top level simply because the extensions and complexity of modern Haskell break HM if you try using it everywhere. Also, the class system in there is not especially mathematically correct, which leads to the numerous replacement Preludes that try to do a better job but haven't caught on. Strings are edge cases because they are not polymorphic unless you enable OverloadedStrings. Once you do, you will either replace the built-in string with something else (ByteString or Text) or find yourself in the same kind of trouble you'd be in with Num. Let me be clear: I'm not saying that these problems are showstoppers. They're really minor annoyances once you're experienced, though they contribute to confusion for beginners. The point I'm trying to make is that you can't just drop HM into any old language and expect it to work. A greater point would perhaps be that all languages have warts simply because they're large, complex beasts (Haskell and C++ especially) and it's unproductive to point to a missing feature in one and demand some sort of perfected version of the other's.
daivd 14y ago
Even in Hindley-Miller type systems it is considered good practice to add types as documentation to top-level constructs (see Haskell). In Python it is also considered good practice to add argument and return type info in the doc string. In a dynamic language you would also have to add a unit test or two for cases for some of the things that the compiler can catch for you. Looking at the complete picture makes a language with local type inference (like C++11) more or less as verbose as one with complete type inference.
- longlivedeath 14y ago
  > it is considered good practice to add types as documentation to top-level constructs But with type inference your tools can do that for you (e.g. C-u C-c C-t in haskell-mode).
  - lmm 14y ago
    A good IDE can fill in the types in C++ too.
    - longlivedeath 14y ago
      Is there a C++ IDE that can figure out the function signature after you have written something like _ f(_ a, _ b, _ c) { YOUR; CODE; HERE; } ?
codewright 14y ago
Wrong foundation? No. Foundation you don't want? Sure. Try to remember that Hindley-Milner is very hard to do outside of functional languages like ML and Haskell.
- danking00 14y ago
  Yes type inference is harder with C++'s language design (OO comes to mind as a particular problem), thus my claim that it's the wrong foundation to build on. Of course, people like challenging problems and are working to bring more type inference to OO languages [1]. Furthermore, I assert that this truly is the wrong foundation. For new projects that must have OO, Scala provides local type inference and object orientation. If you're really hurting for some manual memory management, look at Rust [3] or Habit [2]. If we can recover the features we love on a new foundation that provides new features like type inference or memory-safety, then we've found a better foundation, IMHO. [1] http://www.cs.ucla.edu/~palsberg/typeflow.html http://www.cs.ucla.edu/~palsberg/typeflow.html [2] http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf [3] http://www.rust-lang.org/ http://www.rust-lang.org/
  - deleted 14y ago
    [deleted]
deleted 14y ago
[deleted]

Locke1689 14y ago

Just to elaborate on what danking00 is saying, the extra syntax in this case is not adding any extra information (to the compiler). The left hand type of the expression can be completely inferred at compile time, in this case. What that required syntax is adding is pain, but no gain (except for imperceptibly faster compile time). In Haskell this would look like: TagDataMap = [ ("title", ((3, 30, stripnulls)), ("artist", ((33, 30, stripnulls)), ... Haskell will correctly infer that TagDataMap :: [(String, (Integer, Integer, String -> String)]. Ok, technically this is an associative list, not a Python dictionary, but it is a map and can be accessed like one. Hell, most people use dictionaries with less than 10 items, which are much slower than arrays most of the time

fusiongyro 14y ago
"the extra syntax in this case is not adding any extra information (to the compiler)." This actually isn't true in C++, because there could be many classes in scope that could take a list initializer like this. In Haskell, no literal with [] can "turn into" something besides a list, but that can happen in C++: vector<int> items = {1,2,3,4}; int[] items = {1,2,3,4}; These have different types, so how would C++ know which one you meant if you instead wrote: auto items = {1,2,3,4}; Again, in Haskell this isn't a problem because literals have essentially a single type. (Edge cases around integers and strings notwithstanding). Edit: Just to clarify, in a Hindley-Milner system you could maybe get away with something like that, but everything you name in an HM system you must use, and that isn't the case in C++: void foo() { auto items = {1,2,3,4}; return; } I can then make two classes with list constructors: struct FooClass { FooClass(std::initializer_list<int> list) { cout << "Made a Foo!" << endl; } }; struct BarClass { BarClass(std::initializer_list<int> list) { format_your_hard_disk(); } }; Obviously there are consequences to choosing the right type, but the type of that value never leaks out of the function. Nevertheless, because side-effects can happen anywhere, even in a constructor, C++ cannot optimize that out. This might be a convoluted example, and it may be flawed, but conjuring up others is not hard and demonstrates that C++ simply cannot ever have true HM type inferencing. Since the "real deal" is not possible, the language is complex and the standard is large, I would not expect to be able to live without annotations in C++-land. (Again, the FQA makes the horror of multiple non-orthogonal solutions to the same problems quite clear).
- Locke1689 14y ago
  This is definitely true and demonstrates how competing design decisions can add huge complexity to a language. C++ made earlier design goals to allow heavily context-dependent overriding, which has side effects on what features it can add later.
- Peaker 14y ago
  Integers and Strings aren't edge cases. Their literals are polymorphic and typed. C++ could also type its list initializers with some polymorphic type (similar to Haskell's Num) but didn't do so. This is not inherent.
  - fusiongyro 14y ago
    They're not worth discussing because they're a counterintuitive mess rather than a case study of the glory of HM. Maybe edge case isn't the right word, but they're definitely not something I would hail as a perfect resounding success. There are no polymorphic literals in ML, just polymorphic math operators, which is enough of a blight on the standard that OCaml discarded it and forces you to use different operators for real and integer arithmetic. And there's only one kind of string in both MLs. Haskell's Num hierarchy is troublesome. They traded usability for + with complexity for /. It's extremely unlikely that you could write a program in Haskell that does much arithmetic and have it build correctly on the first try without any manifest typing. This is one reason students of Haskell find things so confusing: type declarations are necessary at the top level simply because the extensions and complexity of modern Haskell break HM if you try using it everywhere. Also, the class system in there is not especially mathematically correct, which leads to the numerous replacement Preludes that try to do a better job but haven't caught on. Strings are edge cases because they are not polymorphic unless you enable OverloadedStrings. Once you do, you will either replace the built-in string with something else (ByteString or Text) or find yourself in the same kind of trouble you'd be in with Num. Let me be clear: I'm not saying that these problems are showstoppers. They're really minor annoyances once you're experienced, though they contribute to confusion for beginners. The point I'm trying to make is that you can't just drop HM into any old language and expect it to work. A greater point would perhaps be that all languages have warts simply because they're large, complex beasts (Haskell and C++ especially) and it's unproductive to point to a missing feature in one and demand some sort of perfected version of the other's.

daivd 14y ago

Even in Hindley-Miller type systems it is considered good practice to add types as documentation to top-level constructs (see Haskell). In Python it is also considered good practice to add argument and return type info in the doc string. In a dynamic language you would also have to add a unit test or two for cases for some of the things that the compiler can catch for you. Looking at the complete picture makes a language with local type inference (like C++11) more or less as verbose as one with complete type inference.

longlivedeath 14y ago
> it is considered good practice to add types as documentation to top-level constructs But with type inference your tools can do that for you (e.g. C-u C-c C-t in haskell-mode).
- lmm 14y ago
  A good IDE can fill in the types in C++ too.
  - longlivedeath 14y ago
    Is there a C++ IDE that can figure out the function signature after you have written something like _ f(_ a, _ b, _ c) { YOUR; CODE; HERE; } ?

codewright 14y ago

Wrong foundation? No. Foundation you don't want? Sure. Try to remember that Hindley-Milner is very hard to do outside of functional languages like ML and Haskell.

danking00 14y ago
Yes type inference is harder with C++'s language design (OO comes to mind as a particular problem), thus my claim that it's the wrong foundation to build on. Of course, people like challenging problems and are working to bring more type inference to OO languages [1]. Furthermore, I assert that this truly is the wrong foundation. For new projects that must have OO, Scala provides local type inference and object orientation. If you're really hurting for some manual memory management, look at Rust [3] or Habit [2]. If we can recover the features we love on a new foundation that provides new features like type inference or memory-safety, then we've found a better foundation, IMHO. [1] http://www.cs.ucla.edu/~palsberg/typeflow.html http://www.cs.ucla.edu/~palsberg/typeflow.html [2] http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf http://hasp.cs.pdx.edu/habit-report-Nov2010.pdf [3] http://www.rust-lang.org/ http://www.rust-lang.org/
- deleted 14y ago
  [deleted]

deleted 14y ago

[deleted]