On 7/27/06, Doaitse Swierstra wrote:

Given the ever increasing complexity of Haskell as understood by the GHC, I think very few people are looking forward to see further complications that do not really add much.

We alreday are at a stage where first year students trying to master haskell get error messages like

"Bool is not an instance of the class Num"

if they accidently write 1 + True (or something equivalent, but less obvious).

I absolutely agree with you, making Haskell easy to understand for newcomers is a far more important goal than an esoteric feature like this. If this cannot be added in a transparent enough way, then it shouldn't be added. But I don't see why it couldn't be. Have you ever been bitten by the rebinding feature provided for the do-notation (without trying to use it that is)? Why should the if-then-else be any harder?

If you want to mess around why not call the function "provided" or something similar.

Not a bad suggestion.

In short: you will not make Haskell a lot more popular by attracting category theorists, but by making transitions from Java and C as smooth and surprise-free as possible (and this is already hard enough).

Agreed. A feature like this should certainly not be by default, but only for advanced users. There should be no surprises.

So I strongly suggest to leave this to the next major redesign of the language.

Well, if you want to redesign the core language, it is always easier to include features that have been tried out in practice. Hen or egg. I am not convinced that this is too complicated a feature to be added to GHC right now -- provided that it can be added in a transparent way. /Niklas

I'm all for making Haskell easy for beginners, but as Simon points out, this change shouldn't really affect them. Since I'm also a fan of using Haskell as the host for embedded DSL's, I think this would be a good addition, since it provides more flexibility with the syntax. -Paul Simon Peyton-Jones wrote:

Just to be clear, to get rebindable syntax in GHC today, you have to ask for it explicitly, via -fno-implicit-prelude

If you use that flag, you'd better know what it means. It already means that do-notation uses whatever (>>) and (>>=) are in scope, not Control.Monad.(>>) etc. This if-thing is just another example.

No beginner will encounter this complication; they'd have to ask for it.

Simon

On 27/07/06, David Roundy wrote:

Or perhaps (?:) or something like that, which could be used infix to evoke the idea of C's e1 ? e2 : e3 syntax. "provided" to me is less clear than "cond" since it has other meanings, and isn't borrowed from any language that I'm familiar with, like "cond" is.

This has come up a few times on #haskell, and the consensus is that a tertiary (?:) operator isn't possible because of the deep specialness of (:). However, you can simulate it pretty well: infixr 1 ? (?) :: Bool -> (a, a) -> a True ? (t, _) = t False ? (_, t) = t Then you call it like: length "hello" > 4 ? ("yes it is!", "afraid not") -- -David House, dmhouse@gmail.com

(Appologies to Malcolm for multiple copies. Say after me, Reply All!) On 7/28/06, Malcolm Wallace wrote:

"David House" wrote:

...

...

Or perhaps (?:) or something like that,

This has come up a few times on #haskell, and the consensus is that a tertiary (?:) operator isn't possible because of the deep specialness of (:). However, you can simulate it pretty well:

infixr 1 ? (?) :: Bool -> (a, a) -> a True ? (t, _) = t False ? (_, t) = t

length "hello" > 4 ? ("yes it is!", "afraid not")

HaXml has a lifted version of C's tertiary operator, which matches C's syntax even more closely:

data ThenElse a = a :> a infixr 3 ?>, :>

(?>) :: (a->Bool) -> ThenElse (a->b) -> (a->b) p ?> (f :> g) = \c-> if p c then f c else g c

You can drop it back down to the term level easily enough:

(?>) :: Bool -> ThenElse a -> a p ?> (t :> e) = if p then t else e

Because the operators are right associative, you don't need parens when you use it:

length "hello" == 4 ?> "yes it is!" :> "afraid not"

I've used this trick as well with a ThenElse data constructor, but that's just for aesthetical reasons, wanting the : first. You could just as easily say e.g. (?) :: Bool -> (a,a) -> a (?) p = if p then fst else snd (<:>) :: a -> a -> (a,a) a <:> b = (a,b) and use it like length "hello" == 4 ? "yup" <:> "nope" The benefit over Malcolm's version is that the (?) operator becomes useful in its own right, like David's version. /Niklas

"Doaitse Swierstra" writes:

We alreday are at a stage where first year students trying to master haskell get error messages like "Bool is not an instance of the class Num" if they accidently write 1 + True (or something equivalent, but less obvious).

Good! It will prepare them for C++ error messages of several pages because you forgot to write const next to a member function, thus make the transition from Haskell to something that pays the rent easier.

In short: you will not make Haskell a lot more popular by attracting category theorists, but by making transitions from Java and C as smooth and surprise-free as possible (and this is already hard enough).

Are we talking about the straw that broke the camel's back? Are you serious about making Java/C programmers transition to Haskell? What would be the purpose of that? Immanuel -- *************************************************************************** I can, I can't. Tubbs Tattsyrup -- Immanuel Litzroth Software Development Engineer Enfocus Software Antwerpsesteenweg 41-45 9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: Immanuell@enfocus.be web : www.enfocus.be ***************************************************************************

On Thu, 27 Jul 2006, David House wrote:

How about we drop the idea of an auxilary cond function, and instead just use a Boolean typeclass?

class Boolean b where isTrue :: b -> Bool isFalse :: b -> Bool

I suspect that then the Int instance for Boolean will quickly arise, http://repetae.net/john/recent/out/Boolean.html which flood us with (if 2+3 then "true" else "false"). This would take us a lot of type safety.

David House wrote:

How about we drop the idea of an auxilary cond function, and instead just use a Boolean typeclass?

class Boolean b where isTrue :: b -> Bool isFalse :: b -> Bool

I don't think this covers embedded languages. If everything lives in some monad it might be useful to rebind the if syntax at a type like DSLMonad Bool -> DSLMonad a -> DSLMonad a -> DSLMonad a Independent of how the if syntax works, an if function would still be handy. Maybe even both argument orders, a -> a -> Bool -> a for transforming booleans, and to follow the standard argument order on catamorphisms, and Bool -> a -> a where the conventional if order is good. Brandon