On Mon, Dec 19, 2011 at 8:20 PM, Robert Clausecker
Image you would create your own language with a paradigm similar to Haskell or have to chance to change Haskell without the need to keep any compatibility. What stuff would you add to your language, what stuff would you remove and what problems would you solve completely different?
Thanks in advance for all answers, yours
Robert Clausecker
A whole lot (a surprisingly very large amount) of things don't require breaking compatibility. Also a lot of things are really amazing but need smarter people than myself to invent them (the Constraint kind is a good example). And many things are trivial and superficial. I agree with everyone who mentioned it about giving things user-friendly names and leaving the mathematical connections to the documentation. I'm partial to Mappable/Sequenceable/Runnable for Functor/Applicative/Monad, but doubtless better ones are possible. I would define Monad in terms of join :p, and use (=<<) as the default bind. I also agree with name: Type instead of name :: Type. I would make : bind tighter. I would rename the * kind to Type, because (Type -> Constraint) looks less weird than (* -> Constraint). I would change some things to be just a little bit more C/Unix-like: != for inequality, allow (not require!) opening and closing braces on the same line, * instead of _ as the wildcard. Many things are in the realm of "this could definitely be done better, but I'm not sure how, either": tuples, records, and modules, in ascending order. Records would be lens-based because composability is nice, but that's about as far as I know. The operative principle with modules would be that after 'import Module' you should be good to go: manual intervention to avoid name clashes is a very nice feature, but you should only have to use it rarely. (In other words, much more control would be given to module authors over how things are exported.) Modules would be parametrizable on types - for example, for FRP libraries where every signature includes the Time type. (If I knew more about ML-style modules I might be advocating them.) I would make the whitespace around infix operators (and other punctuation like list literals) mandatory and significant. It's how you write it in most cases anyways, and how you should have in most of the rest. This frees up a lot of "syntax space" which could be used for various things: special built-in syntax, prefix/postfix operators, and you could have normal-looking array[and] record.access like every other language. (To be clear, list literals would still look [like, this], it's just the presence or absence of whitespace in between them and the preceding identifier which would be significant in this case.) Strictness types can be added as a language extension but either way I would add them. I would put greater emphasis on unboxed polymorphism by multiinstantiation over polymorphism by boxing and dictionary passing (it's not nice that abstract code is slower than monotyped code), but that's an implementation issue. I would add language support for mutating values without explicitly using an IORef, provided you're doing it in the right monad and the effects don't "leak", like what Disciple has but with better syntax. I would distinguish things which read from memory in an impure way from things which write to memory from things which Do Things In The Outside World like write a file. (Maybe by lifting Disciple's effect typing wholesale, but I'm attached to monads.)