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

[Robert Clausecker]

Am 21.12.2011 14:10 schrieb "Ivan Perez" <ivanperezdominguez at gmail.com>:
>
> 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 <fuzxxl at gmail.com> 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 at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111221/b2bfcdd9/attachment.htm>