My issue is that there seem to be many cases where the syntax
extension does *almost* what I want, but not quite. And there isn't
any method to extend it, so you are left with two choices:
(1) Go back to unsugared syntax
(2) Hack your technique into the constraints of the existing syntax extension.
For example, "fail" is in the Monad class only because binding in "do"
needs to handle pattern-match failure. But a better syntax extension
wouldn't tie "do" to Monad only; it would allow pattern match failure
to be handled by a separate class if needed, and allow additional
extensions to deal with other cases where the existing syntax isn't
quite good enough. This is where lisp-style syntactic macros show
their real power.
I'd go to TH but there's no way to make TH transparent. I almost wish
that do ... and similar notations would just call a TH function to
decode the expression! Then, if I wanted a different decoding I could
just put a different "sugarDoNotation" function in scope.
On a related note, I hate the explosion of <*>, <$>, liftM, etc. when
working in monadic/applicative code. Often the code only typechecks
with these lifting operators present, so why am I explaining to the
compiler that I want it to use the applicative apply operator? When
is strong typing going to help me write *less* code instead of *more*?
We've solved the "type annotation" problem to my satisfaction via
inference, but there is still a lot of what I would call "source
annotation".
For example, which of these is easier to read?
f,g :: Int -> [Int]
h1 :: Int -> [Int]
h1 x = do
fx <- f x
gx <- g x
return (fx + gx)
h2 :: Int -> [Int]
h2 x = (+) <$> f x <*> g x
h3 :: Int -> [Int]
h3 x = f x + g x -- not legal, of course, but wouldn't it be nice if it was?
Of course this raises problems of order of evaluation, etc, but as
long as such things were well-defined, that seems fine. If you want
finer control, you can always go back to more verbose syntax. These
cases are dominated by the cases where you simply don't care!
This said, I don't want to sound overly negative; all of this pain is
*worth* the correctness guarantees that I get when writing in Haskell.
I just wish I could get the same guarantees with less pain!
-- ryan
2009/1/10 Peter Verswyvelen <bugf...@gmail.com>:
> Related to this issue, I have a question here.
> I might be wrong, but it seems to me that some Haskellers don't like
> writing monads (with do notation) or arrows (with proc sugar) because of the
> fact they have to abandon the typical applicative syntax, which is so close
> to the beautiful lambda calculus core. Or is it maybe because some people
> choose monads were the less linear applicative style could be used instead,
> so the choice of monads is not always appropriate.
> Haskell is full of little hardcoded syntax extensions: list notation
> syntactic, list comprehensions, and even operator precedence that reduces
> the need for parentheses, etc...
>
> Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written
> without the arrows syntax would be incomprehensible for the average
> programmer. But one could claim that this syntactic sugar hides what is
> really going on under the hood, so for newcomers these extensions might make
> it harder. It could also feel like a hack, a failure to keep things as
> simple as possible yet elegant.
> Some people I talked with like that about the Scheme/ & LISP languages: the
> syntax remains ultimately close to the core, with very little hardcoded
> syntactic extensions. And when one wants to add syntactic extensions, one
> uses syntactic macros.
> I'm not sure what others feel about the hardcoded syntax extensions in
> Haskell...
>
> Personally I'm not that much of a purist, I'm an old school hacker that
> mainly needs to get the job done. I like the syntax extensions in Haskell
> (and even C#/F# ;) because they let me write code shorter and clearer...
> On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander <wqeqwe...@hotmail.com>
> wrote:
>>
>> Ertugrul Soeylemez wrote:
>>>
>>> Hello fellow Haskellers,
>>>
>>> When I read questions from Haskell beginners, it somehow seems like they
>>> try to avoid monads and view them as a last resort, if there is no easy
>>> non-monadic way. I'm really sure that the cause for this is that most
>>> tutorials deal with monads very sparingly and mostly in the context of
>>> input/output. Also usually monads are associated with the do-notation,
>>> which makes them appear even more special, although there is really
>>> nothing special about them.
>>>
>>
>> Yea, i was the same way when i started learning Haskell. I understood how
>> Monads worked, and what the motivation was for them, but not why i would
>> want to restructure code to use them in specific instances.
>>
>> "Why should i care about monads when i can use Arrows or (.)" was also a
>> factor.
>>
>> Its kinda like getting advice from an adult as a child. You have no
>> particular reason to distrust the advice, but the value of it doesn't set in
>> until something happens to you first hand to verify it.
>>
>> For me the turning point was writing some code that needed to handle
>> running code locally/remotely in a transparent manner.
>>
>> Maybe having a list of real-world usage scenarios or exercises on the wiki
>> may help.
>>
>> ______________________________ _________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
