[Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does
Haskell have the if-then-else syntax?)
niklas.broberg at gmail.com
Thu Jul 27 07:35:37 EDT 2006
I would be happy to write up a trac-ticket for this - I could even try
to implement it in GHC. However, I'm surprised that you agree with it
so easily since it breaks some Haskell 98-ish stuff in un-nice ways.
First of all, programs that import names from the Prelude explicitly
would no longer be able to use if-then-else unless they also added
'cond' to that input list (or redefined it of course). This shouldn't
really be a problem, since the rebindable syntax is turned on by
adding some flag anyway, and if you add that flag you know you're no
longer H98. Still, it's going to break a lot of existing programs.
The second problem is that it would require the addition of the cond
function to the Prelude. This will probably not break too many
existing programs, but still it is a more serious problem since it
will have effect even without any flags to GHC. Or is it possible to
govern the contents of the Prelude based on flags?
I would really like to see this implemented, and I don't think the
above is serious enough that we shouldn't. There may be some that
don't agree though. Speak up now, or forever hold your peace!
Also, is cond the best name for the suggested function? If we don't
expect anyone to really use it without the sugar, we could name it
whatever weird thing so as to break as few existing programs as
possible. It would make explicit import a bit more akward though. But
I suspect that if this function did exist in the Prelude, people would
start using it a lot. Does anyone have any better suggestions, or is
cond the name of the day?
On 7/27/06, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
> GHC does indeed include the notion of "rebindable syntax". It would be
> straightforward to extend it to include if-then-else. In effect, that
> would mean that
> if e1 then e2 else e3
> would behave exactly like
> cond e1 e2 e3
> including from the point of view of typing. (You could choose a
> different name than 'cond'.) Then by importing a 'cond' with (say) type
> cond :: MyBool -> b -> b
> you could use a different kind of Boolean. You could even overload the
> cond :: Boolean a => a -> b -> b
> This could be done with a few hours work. But not a few minutes. Want
> to put a feature request in Trac?
> | -----Original Message-----
> | From: haskell-cafe-bounces at haskell.org
> [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Niklas
> | Broberg
> | Sent: 27 July 2006 09:01
> | To: Haskell-cafe
> | Subject: Re: [Haskell-cafe] Why does Haskell have the if-then-else
> | I often find myself at odds with this choice. The reason is that I use
> | Haskell as a host for embedded languages, and these often come with
> | their own control flows. So I find myself wanting to write my own
> | definition of the if-then-else construct that works on terms of some
> | other type, e.g. tests on values of type Exp Bool instead of Bool, and
> | at the same time make sure that the user doesn't use the built-in
> | if-then-else. Sure, I can (and do) call my own version if_, ifElse or
> | something else along those lines, but it's sure to be a constant
> | source of programmer errors, writing if-then-else instead of if_ by
> | habit.
> | A thought that has crossed my mind on several occasions is, why not
> | make the syntactic if-then-else construct rebindable, like the do
> | notation? I think I know the answer already -- the do notation is
> | syntactic sugar for >>= and company so it's easy to translate it into
> | non-prelude-qualified versions of functions with those names. This is
> | not the case for if-then-else. But it could be, the prelude could
> | define a function if_ (or whatever) that the if-then-else construct is
> | made to be sugar for, and thus also amenable to rebinding by not
> | prelude-qualifying.
> | /Niklas
> | On 7/27/06, Paul Hudak <paul.hudak at yale.edu> wrote:
> | > Mike Gunter wrote:
> | >
> | > >I had hoped the "History of Haskell" paper would answer a question
> | > >I've pondered for some time: why does Haskell have the if-then-else
> | > >syntax? The paper doesn't address this. What's the story?
> | > >
> | > >thanks,
> | > >-m
> | > >
> | > >
> | > Thanks for asking about this -- it probably should be in the paper.
> | > Doel's answer is closest to the truth:
> | >
> | > I imagine the answer is that having the syntax for it looks
> | > clearer. "if a b c" could be more cryptic than "if a then b else
> | > for some values of a, b and c.
> | >
> | > except that there was also the simple desire to conform to
> | > here (I don't recall fewer parentheses being a reason for the
> | > In considering the alternative, I remember the function "cond" being
> | > proposed instead of "if", in deference to Scheme and to avoid
> | > with people's expectations regarding "if".
> | >
> | > A related issue is why Haskell does not have a "single arm"
> | > -- i.e. an "if-then" form, which would evaluate to bottom (i.e.
> | > if the predicate were false. This was actually discussed, but
> | > as a bad idea for a purely functional language.
> | >
> | > -Paul
> | >
> | > _______________________________________________
> | > Haskell-Cafe mailing list
> | > Haskell-Cafe at haskell.org
> | > http://www.haskell.org/mailman/listinfo/haskell-cafe
> | >
> | _______________________________________________
> | Haskell-Cafe mailing list
> | Haskell-Cafe at haskell.org
> | http://www.haskell.org/mailman/listinfo/haskell-cafe
More information about the Haskell-Cafe