4 ms·

1. Nonissue in real life. 3. Don't modify parameters. It makes code easier to test in any language. 5. GHC may as well be the standard. Are you really going t

1. Nonissue in real life. 3. Don't modify parameters. It makes code easier to test in any language. 5. GHC may as well be the standard. Are you really going to use a different compiler.

solomatov 13y ago
>3. Don't modify parameters. It makes code easier to test in any language. It's not about modifying parameters. It's about verbosity of the code. The type of the parameter is IO String. >5. GHC may as well be the standard. Are you really going to use a different compiler. It's a real issue. Different language extensions might modify how type inference works. If you add one more extension, you program might suddenly stop to compile. We need a fixed set of language extensions which are always available.
- sseveran 13y ago
  3. in general haskell is even terser then i like. 5. What on earth are you talking about? Conjecturing about type inference is not useful. While I may prefer some extensions to be on be default, in hundreds of thousands of lines of haskell code I am yet to see adding an extension break existing code. The worst I have seen is adding an extension slow down compilation. In haskell you have to forget most of what you have learned in order to be successful. Otherwise you will fight the language.
  - solomatov 13y ago
    > 3. in general haskell is even terser then i like. It's the same kind of terseness that languages like Perl have. It's write/only code.
    - sseveran 13y ago
      I have not found that to be true.
- quchen 13y ago
  > The type of the parameter is IO String. No, the type of the parameter is String. IO String is the type of the expression that gets that parameter when executed. There's a popular quote by shachaf, "getLine :: IO String contains a String in the same way that /bin/ls contains a list of files" that illustrates this nicely.
  - solomatov 13y ago
    I understand what a monad and IO monad is and what the types of the expressions are. I am just showing that the current monad syntax is ugly. connectToDb $ readParams "conf" can be transformed by a compiler into what you wrote.
    - gizmo686 13y ago
      readParams "conf" >>= connectToDb
- enigmo 13y ago
  > If you add one more extension, you program might suddenly stop to compile. Do you have some real examples of this happening with GHC extensions? I haven't run across one in the field. > We need a fixed set of language extensions which are always available. This sounds very much like a language standard. Haskell isn't much different than other languages here, though the language committee is slow to ratify generally accepted extensions into the standard. GHC at least makes them available to people who want to kick the tires. Then read about closures in Java. Look at C++11 revisions and notice that sometimes meant cutting features, even if they were previously implemented by some compilers (template exports) or prototyped (concepts).
  - solomatov 13y ago
    >Do you have some real examples of this happening with GHC extensions? I haven't run across one in the field. I am not that advanced in how GHC types work. However, I understand, that in any language extensions there are tradeoffs between how expressive a language is and how much type inference we have.
    - enigmo 13y ago
      Many (most?) of GHC's commonly used language extensions enable new functionality or syntax (DataKinds, GADTs, RankNTypes, KindSignatures, TypeFamilies, FunDeps, MPTCs, etc). Enabling such extensions and not using these newly enabled features shouldn't affect type inference.

1. Nonissue in real life. 3. Don't modify parameters. It makes code easier to test in any language. 5. GHC may as well be the standard. Are you really going to use a different compiler.

solomatov 13y ago

>3. Don't modify parameters. It makes code easier to test in any language. It's not about modifying parameters. It's about verbosity of the code. The type of the parameter is IO String. >5. GHC may as well be the standard. Are you really going to use a different compiler. It's a real issue. Different language extensions might modify how type inference works. If you add one more extension, you program might suddenly stop to compile. We need a fixed set of language extensions which are always available.

sseveran 13y ago
3. in general haskell is even terser then i like. 5. What on earth are you talking about? Conjecturing about type inference is not useful. While I may prefer some extensions to be on be default, in hundreds of thousands of lines of haskell code I am yet to see adding an extension break existing code. The worst I have seen is adding an extension slow down compilation. In haskell you have to forget most of what you have learned in order to be successful. Otherwise you will fight the language.
- solomatov 13y ago
  > 3. in general haskell is even terser then i like. It's the same kind of terseness that languages like Perl have. It's write/only code.
  - sseveran 13y ago
    I have not found that to be true.
quchen 13y ago
> The type of the parameter is IO String. No, the type of the parameter is String. IO String is the type of the expression that gets that parameter when executed. There's a popular quote by shachaf, "getLine :: IO String contains a String in the same way that /bin/ls contains a list of files" that illustrates this nicely.
- solomatov 13y ago
  I understand what a monad and IO monad is and what the types of the expressions are. I am just showing that the current monad syntax is ugly. connectToDb $ readParams "conf" can be transformed by a compiler into what you wrote.
  - gizmo686 13y ago
    readParams "conf" >>= connectToDb
enigmo 13y ago
> If you add one more extension, you program might suddenly stop to compile. Do you have some real examples of this happening with GHC extensions? I haven't run across one in the field. > We need a fixed set of language extensions which are always available. This sounds very much like a language standard. Haskell isn't much different than other languages here, though the language committee is slow to ratify generally accepted extensions into the standard. GHC at least makes them available to people who want to kick the tires. Then read about closures in Java. Look at C++11 revisions and notice that sometimes meant cutting features, even if they were previously implemented by some compilers (template exports) or prototyped (concepts).
- solomatov 13y ago
  >Do you have some real examples of this happening with GHC extensions? I haven't run across one in the field. I am not that advanced in how GHC types work. However, I understand, that in any language extensions there are tradeoffs between how expressive a language is and how much type inference we have.
  - enigmo 13y ago
    Many (most?) of GHC's commonly used language extensions enable new functionality or syntax (DataKinds, GADTs, RankNTypes, KindSignatures, TypeFamilies, FunDeps, MPTCs, etc). Enabling such extensions and not using these newly enabled features shouldn't affect type inference.