Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
David House [EMAIL PROTECTED] 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 Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
On Jul 27, 2006, at 1:35 PM, Niklas Broberg wrote: 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! 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). If you want to mess around why not call the function provided or something similar. 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). So I strongly suggest to leave this to the next major redesign of the language. Doaitse Swierstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
On 7/27/06, Doaitse Swierstra [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
| 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). | | If you want to mess around why not call the function provided or | something similar. 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
On Thu, Jul 27, 2006 at 02:57:20PM +0200, Doaitse Swierstra wrote: On Jul 27, 2006, at 1:35 PM, Niklas Broberg wrote: 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! Me too, this sounds really cool! 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 think this is not a language issue so much as a compiler issue, and I don't think it's a sound idea to limit the language or libraries based on the existing poor error messages. If the above gave a message like (+) requires an argument of class Num, but True is of type Bool, which is not in class Num. I don't think there would be a problem. In general, I think classes should be used more, rather than less, and if that means we need a SoC project to improve the clarity of error messages, then that's what needs to be done. (I'll admit, I'm unlikely to do this...) If you want to mess around why not call the function provided or something similar. 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. -- David Roundy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
(Apologies to Niklas for multiple copies, it was a Reply/Reply to all mixup.) On 27/07/06, Niklas Broberg [EMAIL PROTECTED] wrote: 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? 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 Then the semantics of if-then-else would change to something like this: if b then t1 else t2 b is required to be of a type which instantiates Boolean If isTrue b is True, then t1 is executed, otherwise if isFalse b is True, then t2 is executed, otherwise _|_ is returned. Then you get the benefit of being able to use arbitrary 'boolean-like' types in actual if statements, without messing around with -fno-implicit-prelude and rebindable syntax. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
On 27/07/06, David Roundy [EMAIL PROTECTED] 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, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
On 7/27/06, David House [EMAIL PROTECTED] 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 Then the semantics of if-then-else would change to something like this: if b then t1 else t2 b is required to be of a type which instantiates Boolean If isTrue b is True, then t1 is executed, otherwise if isFalse b is True, then t2 is executed, otherwise _|_ is returned. Then you get the benefit of being able to use arbitrary 'boolean-like' types in actual if statements, without messing around with -fno-implicit-prelude and rebindable syntax. It would be possible, sure, but I don't want to go in this direction. I don't only want to overload the if-then-else for different kinds of booleans, I would like to be able to change its behavior completely. One particular application of this that I have in mind is the JavaScript embedding that Joel Björnson is currently working on as his SoC project. There the embedding is actually a set of combinators for constructing an abstract syntax tree, so if-then-else would translate into the data constructor IfThenElse applied to its arguments. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
