4 ms·

Willful or not, it makes the language more verbose.

masklinn 10y ago
I don't think it does, other syntactic decisions (e.g. C++/Java-style generic declarations, reference sigils) might, or at least make the language seem noisier, but with respect to function type declarations you'd get the exact same verbosity (in terms of tokens or characters), just split differently e.g. fn class(&mut self, s: &'a bstr) -> u16 versus class :: &mut, &'a bstr -> u16 fn class(self, s) all you get is repeating the function name.
- catnaroek 10y ago
  Think about `where` clauses.
  - masklinn 10y ago
    Where clauses don't go away and their verbosity doesn't change.
    - catnaroek 10y ago
      Trait constraints in Rust are syntactically more annoying than type class constraints are in Haskell. This is in spite of the fact that, semantically, both are exactly the same thing.
      - valarauca1 10y ago
        This is in spite of the fact that, semantically, both are exactly the same thing. Semantics is not practice. Rust is a compiled language. All Types/TypeClasses have to eventually be resolved down to concrete structures/tuples that can be statically or dynamically dispatched too, and in most cases allocated to the heap/stack. Haskell is NOT a compiled language. It compiles to a bytecode that is ran by the RTS (Run Time System) a ball of ~50,000SLOC in C/C++. Haskell TypeClasses are MAGIC managed by the run-time. They are not resolved to actual machine code. A compiled Haskell program is just the bytecode+source code+compiler+RTS bundled into an ELF. Yes some Haskell is translated into pure C, but all of it can't be. The pure C Haskell still depends on the run time heavily. Especially for managing type class dynamic dispatch.
        tome 10y ago
        > Haskell is NOT a compiled language Yes it is > It compiles to a bytecode that is ran by the RTS Nope, it's compiled to machine code. (We're talking about GHC here, of course)
        valarauca1 10y ago
        Read the GHC's docs because they disagree with you. https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Interpreter https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Interpr... https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage... https://hackage.haskell.org/package/vacuum https://hackage.haskell.org/package/vacuum https://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/index.htm https://research.microsoft.com/en-us/um/people/simonpj/paper... https://research.microsoft.com/en-us/um/people/simonpj/Papers/pj-lester-book/ https://research.microsoft.com/en-us/um/people/simonpj/Paper... Haskell is a complex hybrid. TypeClasses can't always be resolved to concrete statically sized types, Haskell does RTS Magic for you when this happens. Rust throws a compiler error in this case.
        jerf 10y ago
        Implementing an abstraction that requires indirection at runtime does not traditionally render the language "not compiled". Any definition of "not compiled" that includes the vast majority of real-world C++ is not a definition in common use. If you want to point out that "compiled" really ought to be a continuum rather than a binary property, and that by this definition Rust is "more" compiled than Haskell, I'll be right there with you (though the pre-existing word "static" probably fits better), but we'd be creating an idiosyncratic definition not shared by very many people. (Though perhaps it should be. The binary distinction of the ~1970s really isn't that useful anymore, in a world of scripting languages, JITs, and a greater focus on the costs of indirection.)
        catnaroek 10y ago
        > All Types/TypeClasses have to eventually be resolved down to concrete structures/tuples that can be statically or dynamically dispatched too, and in most cases allocated to the heap/stack. My original remark was strictly about surface syntax issues (verbosity). Surface syntax is handled by the compiler's front-end. I have no idea why this should affect the compiler's backend or the runtime system. But maybe you know something about compilers that I don't. > Haskell TypeClasses are MAGIC managed by the run-time. No. Haskell's type classes and constraints are typically implemented as vtables (although Haskellers normally call them “dictionaries”) and extra function arguments, which are resolved at compile time. (With higher-rank types, the compiler can determine that a given vtable has to be passed around between places, though.) The runtime system has no special support for type classes - a type class instance is a record (of methods) just like any other. Of course, Rust monomorphizes generic functions, and optimizes away the intermediate step of fetching methods from vtables whenever possible. But if you use trait objects (akin to Haskell's existentials), vtables will still be there.

I don't think it does, other syntactic decisions (e.g. C++/Java-style generic declarations, reference sigils) might, or at least make the language seem noisier, but with respect to function type declarations you'd get the exact same verbosity (in terms of tokens or characters), just split differently e.g. fn class(&mut self, s: &'a bstr) -> u16 versus class :: &mut, &'a bstr -> u16 fn class(self, s) all you get is repeating the function name.

catnaroek 10y ago
Think about `where` clauses.
- masklinn 10y ago
  Where clauses don't go away and their verbosity doesn't change.
  - catnaroek 10y ago
    Trait constraints in Rust are syntactically more annoying than type class constraints are in Haskell. This is in spite of the fact that, semantically, both are exactly the same thing.
    - valarauca1 10y ago
      This is in spite of the fact that, semantically, both are exactly the same thing. Semantics is not practice. Rust is a compiled language. All Types/TypeClasses have to eventually be resolved down to concrete structures/tuples that can be statically or dynamically dispatched too, and in most cases allocated to the heap/stack. Haskell is NOT a compiled language. It compiles to a bytecode that is ran by the RTS (Run Time System) a ball of ~50,000SLOC in C/C++. Haskell TypeClasses are MAGIC managed by the run-time. They are not resolved to actual machine code. A compiled Haskell program is just the bytecode+source code+compiler+RTS bundled into an ELF. Yes some Haskell is translated into pure C, but all of it can't be. The pure C Haskell still depends on the run time heavily. Especially for managing type class dynamic dispatch.
      - tome 10y ago
        > Haskell is NOT a compiled language Yes it is > It compiles to a bytecode that is ran by the RTS Nope, it's compiled to machine code. (We're talking about GHC here, of course)
        valarauca1 10y ago
        Read the GHC's docs because they disagree with you. https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Interpreter https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Interpr... https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage... https://hackage.haskell.org/package/vacuum https://hackage.haskell.org/package/vacuum https://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/index.htm https://research.microsoft.com/en-us/um/people/simonpj/paper... https://research.microsoft.com/en-us/um/people/simonpj/Papers/pj-lester-book/ https://research.microsoft.com/en-us/um/people/simonpj/Paper... Haskell is a complex hybrid. TypeClasses can't always be resolved to concrete statically sized types, Haskell does RTS Magic for you when this happens. Rust throws a compiler error in this case.
        jerf 10y ago
        Implementing an abstraction that requires indirection at runtime does not traditionally render the language "not compiled". Any definition of "not compiled" that includes the vast majority of real-world C++ is not a definition in common use. If you want to point out that "compiled" really ought to be a continuum rather than a binary property, and that by this definition Rust is "more" compiled than Haskell, I'll be right there with you (though the pre-existing word "static" probably fits better), but we'd be creating an idiosyncratic definition not shared by very many people. (Though perhaps it should be. The binary distinction of the ~1970s really isn't that useful anymore, in a world of scripting languages, JITs, and a greater focus on the costs of indirection.)
      - catnaroek 10y ago
        > All Types/TypeClasses have to eventually be resolved down to concrete structures/tuples that can be statically or dynamically dispatched too, and in most cases allocated to the heap/stack. My original remark was strictly about surface syntax issues (verbosity). Surface syntax is handled by the compiler's front-end. I have no idea why this should affect the compiler's backend or the runtime system. But maybe you know something about compilers that I don't. > Haskell TypeClasses are MAGIC managed by the run-time. No. Haskell's type classes and constraints are typically implemented as vtables (although Haskellers normally call them “dictionaries”) and extra function arguments, which are resolved at compile time. (With higher-rank types, the compiler can determine that a given vtable has to be passed around between places, though.) The runtime system has no special support for type classes - a type class instance is a record (of methods) just like any other. Of course, Rust monomorphizes generic functions, and optimizes away the intermediate step of fetching methods from vtables whenever possible. But if you use trait objects (akin to Haskell's existentials), vtables will still be there.