Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?

Am 21.12.2011 14:10 schrieb "Ivan Perez" :

In general, I like haskell the way it is, but there are a few things that I would like to see: (I am no language designer, so I don't know about the theoretical implications that these might have. Also, let me know if there exists a clean way to do any of the following):

- Using subranges of instances of Ord in type definitions, a la Ada. For instance, saying:

type MyNumber = [2..6]

(maybe "data MyNumber" would be more appropriate, I don't know).

I really don't want to have to write data MyNumber = Two | Three | Four | Five | Six and implement all the necessary operations for them.

- Guards wherever I want, for instance:

myFunction = do monadicRes <- monadicOp | monadicRes == 1 || monadicRes == 7 = doA | monadicRes == 6 || monadicRes == 8 = doB | otherwise = doC

This is easily avoidable with an aux function, but sometimes there's just too many variables in the conditions and you don't want to carry them all in the aux function's signature. I could (painfully) live with

myFunction = do monadicRes <- monadicOp if monadicRes == 1 || monadicRes == 7 then doA elseif monadicRes == 6 || monadicRes == 8 then doB else doC

even though it's way too verbose and reminds me of java.

I often end up finding that the following construction is cleaner than the possible alternatives:

myFunction = do monadicRes <- monadicOp case () of _ | monadicRes == 1 || monadicRes == 7 = doA | monadicRes == 6 || monadicRes == 8 = doB | otherwise = doC

even though it's very ugly to have those useless () _ there.

Unfortunately, my proposal could give way to slightly ugly nested guards (which are cleaner than nested ifs, but not very nice anyway). myFunction arg | arg == 1 | arg == 7 = doA | arg == 8 = doB | otherwise = doC

- Function overloading without classes. If it's not done, there must be a good reason for it (many good reasons, probably), but I really miss it.

That does not play well with type inference. Also, see type-directed name resolution (TDNR)

Most other features I need, such as easy-to-use nested-record access methods, my own deriving definitions, compile-time expansion of expressions, etc. are covered by existing libraries and extensions.

I really have no problems with the monad/functor separation that somebody mentioned. Maybe Monad is not the best name for that class if it's not true that every Monad is a Functor, but it's not very confusing anyway.

Cheers, Ivan

On 19 December 2011 20:20, Robert Clausecker wrote:

...

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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe