<p><br>
Am 21.12.2011 14:10 schrieb "Ivan Perez" <<a href="mailto:ivanperezdominguez@gmail.com">ivanperezdominguez@gmail.com</a>>:<br>
><br>
> In general, I like haskell the way it is, but there are a few things<br>
> that I would like to see:<br>
> (I am no language designer, so I don't know about the theoretical<br>
> implications that these<br>
> might have. Also, let me know if there exists a clean way to do any of<br>
> the following):<br>
><br>
> - Using subranges of instances of Ord in type definitions, a la Ada.<br>
> For instance, saying:<br>
><br>
> type MyNumber = [2..6]<br>
><br>
> (maybe "data MyNumber" would be more appropriate, I don't know).<br>
><br>
> I really don't want to have to write<br>
> data MyNumber = Two | Three | Four | Five | Six<br>
> and implement all the necessary operations for them.<br>
><br>
> - Guards wherever I want, for instance:<br>
><br>
> myFunction = do<br>
> monadicRes <- monadicOp<br>
> | monadicRes == 1 || monadicRes == 7 = doA<br>
> | monadicRes == 6 || monadicRes == 8 = doB<br>
> | otherwise = doC<br>
><br>
> This is easily avoidable with an aux function, but sometimes there's just<br>
> too many variables in the conditions and you don't want to carry them<br>
> all in the aux function's signature. I could (painfully) live with<br>
><br>
> myFunction = do<br>
> monadicRes <- monadicOp<br>
> if monadicRes == 1 || monadicRes == 7<br>
> then doA<br>
> elseif monadicRes == 6 || monadicRes == 8<br>
> then doB<br>
> else doC<br>
><br>
> even though it's way too verbose and reminds me of java.<br>
><br>
> I often end up finding that the following construction is cleaner than<br>
> the possible alternatives:<br>
><br>
> myFunction = do<br>
> monadicRes <- monadicOp<br>
> case () of<br>
> _ | monadicRes == 1 || monadicRes == 7 = doA<br>
> | monadicRes == 6 || monadicRes == 8 = doB<br>
> | otherwise = doC<br>
><br>
> even though it's very ugly to have those useless () _ there.<br>
><br>
> Unfortunately, my proposal could give way to slightly ugly nested guards<br>
> (which are cleaner than nested ifs, but not very nice anyway).<br>
> myFunction arg<br>
> | arg == 1<br>
> | arg == 7 = doA<br>
> | arg == 8 = doB<br>
> | otherwise = doC<br>
><br>
> - Function overloading without classes. If it's not done, there must<br>
> be a good reason for it<br>
> (many good reasons, probably), but I really miss it.</p>
<p>That does not play well with type inference. Also, see type-directed name resolution (TDNR)<br>
> Most other features I need, such as easy-to-use nested-record access<br>
> methods, my own deriving definitions, compile-time expansion of<br>
> expressions, etc. are covered by existing libraries and extensions.<br>
><br>
> I really have no problems with the monad/functor separation that<br>
> somebody mentioned.<br>
> Maybe Monad is not the best name for that class if it's not true that<br>
> every Monad is a<br>
> Functor, but it's not very confusing anyway.<br>
><br>
> Cheers,<br>
> Ivan<br>
><br>
> On 19 December 2011 20:20, Robert Clausecker <<a href="mailto:fuzxxl@gmail.com">fuzxxl@gmail.com</a>> wrote:<br>
> > Image you would create your own language with a paradigm similar to<br>
> > Haskell or have to chance to change Haskell without the need to keep any<br>
> > compatibility. What stuff would you add to your language, what stuff<br>
> > would you remove and what problems would you solve completely different?<br>
> ><br>
> > Thanks in advance for all answers, yours<br>
> ><br>
> > Robert Clausecker<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Haskell-Cafe mailing list<br>
> > <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> > <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</p>