Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
On Jul 26, 2006, at 6:44 PM, Sebastian Sylvan wrote: For example ... if :: Bool - a - a - a if True t _ = t if False _ e = e -- example usage myAbs x = if (x 0) (negate x) x I suppose there might also be a case for flipping the arguments about like this: if :: a - a - Bool - a if t _ True = t if _ e False = e This way it would follow foldr more closely, in recognition that the conditional is essentially the fold/cata/eliminator/... for booleans. But argument order is a pretty trivial thing, and I think the committee made the right choice with if-then-else as a language construct. -- Fritz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
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 [EMAIL PROTECTED] 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. Dan Doel's answer is closest to the truth: I imagine the answer is that having the syntax for it looks nicer/is clearer. if a b c could be more cryptic than if a then b else c for some values of a, b and c. except that there was also the simple desire to conform to convention here (I don't recall fewer parentheses being a reason for the choice). In considering the alternative, I remember the function cond being proposed instead of if, in deference to Scheme and to avoid confusion with people's expectations regarding if. A related issue is why Haskell does not have a single arm conditional -- i.e. an if-then form, which would evaluate to bottom (i.e. error) if the predicate were false. This was actually discussed, but rejected as a bad idea for a purely functional language. -Paul ___ 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
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
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. Wouldn't this cause a conflict with specialized knowledge the compiler has about if-then-else, e.g. for optimizations? Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
Niklas Broberg wrote:
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
You may not realize that if-then-else is just syntactic sugar like do. Read
the Haskell 98 Report
http://www.haskell.org/onlinereport/exps.html#conditionals
Translation:
The following identity holds:
if e1 then e2 else e3 = case e1 of { True - e2 ; False - e3 }
where True and False are the two nullary constructors from the type Bool,
as defined in the Prelude. The type of e1 must be Bool;
e2 and e3 must have the same type, which is also the type of the entire
conditional expression.
So you could easily create a patched compiler that allows for rebindable syntax.
The fundamental syntax of do and if/then/else and patterns or guards in
function definitions is always a case statement.
--
Chris
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
On Wed, 26 Jul 2006, Fritz Ruehr wrote: On Jul 26, 2006, at 6:44 PM, Sebastian Sylvan wrote: For example ... if :: Bool - a - a - a if True t _ = t if False _ e = e -- example usage myAbs x = if (x 0) (negate x) x I suppose there might also be a case for flipping the arguments about like this: if :: a - a - Bool - a if t _ True = t if _ e False = e This way it would follow foldr more closely, in recognition that the conditional is essentially the fold/cata/eliminator/... for booleans. I found the argument order of the first if (Bool - a - a - a) already useful for a 'case' with computed conditions: select = foldr (uncurry if_) http://www.haskell.org/hawiki/Case ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
On 2006-07-27 at 01:33EDT Paul Hudak wrote: Thanks for asking about this -- it probably should be in the paper. Dan Doel's answer is closest to the truth: I imagine the answer is that having the syntax for it looks nicer/is clearer. if a b c could be more cryptic than if a then b else c for some values of a, b and c. except that there was also the simple desire to conform to convention here (I don't recall fewer parentheses being a reason for the choice). In a sense, it explicitly wasn't: I suggested if _ then _ else _ fi -- something I was long used to from Algol68 -- but it was rejected on the ground that there wasn't a dangling else problem in Haskell. I probably muttered something about wanting things to be self-bracketing (I've certainly grumbled inwardly since about having to write (if _ then _ else _)¹ in some Haskell contexts), but since I'm quite slow witted, I expect that the discussion had moved on by then. In considering the alternative, I remember the function cond being proposed instead of if, in deference to Scheme and to avoid confusion with people's expectations regarding if. Did we talk about Dijkstra's fat bar, or was that a discussion I had elsewhere? Jón [1] which I find ugly, and besides, making all like constructs self-bracketing would have allowed a saner (to my mind) layout rule. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
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 bool: 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? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 syntax? | | 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 [EMAIL PROTECTED] 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. Dan | Doel's answer is closest to the truth: | | I imagine the answer is that having the syntax for it looks nicer/is | clearer. if a b c could be more cryptic than if a then b else c | for some values of a, b and c. | | except that there was also the simple desire to conform to convention | here (I don't recall fewer parentheses being a reason for the choice). | In considering the alternative, I remember the function cond being | proposed instead of if, in deference to Scheme and to avoid confusion | with people's expectations regarding if. | | A related issue is why Haskell does not have a single arm conditional | -- i.e. an if-then form, which would evaluate to bottom (i.e. error) | if the predicate were false. This was actually discussed, but rejected | as a bad idea for a purely functional language. | |-Paul | | ___ | 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
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
On Thu, Jul 27, 2006 at 10:22:31AM +0100, Jon Fairbairn wrote: On 2006-07-27 at 01:33EDT Paul Hudak wrote: Thanks for asking about this -- it probably should be in the paper. Dan Doel's answer is closest to the truth: I imagine the answer is that having the syntax for it looks nicer/is clearer. if a b c could be more cryptic than if a then b else c for some values of a, b and c. except that there was also the simple desire to conform to convention here (I don't recall fewer parentheses being a reason for the choice). In a sense, it explicitly wasn't: I suggested if _ then _ else _ fi -- something I was long used to from Algol68 -- but it was rejected on the ground that there wasn't a dangling else problem in Haskell. But because if-then-else is an expression, there is another problem. Consider: (if True then 0 else 1) + 2 -- 2 if True then 0 else 1 + 2 -- 0 let cond a b c = if a then b else c cond True 0 1 + 2 -- 2 -- different from if-then-else withouth parentheses It's quite easy to fall in this trap. I think it happened to me at least twice. It goes like this: first I have an expression that doesn't involve if-then-else, eg. a + b Then I realize that a has to be changed in some situations, so I replace it with a conditional expression: if c then a else a' + b or if c then f a else g a + b But now + b gets under the else branch. If I used a cond function, or if if-then-else had a different priority, it would be easier to avoid such a mistake. There is no problem with the first version: cond c a a' + b For an experienced Haskell programmer it's obvious that function application has a higher precendence than addition. In the second version, it would be clear that parentheses have to be added: cond c (f a) (g a) + b Could the cond function encourage other kinds of bugs? I think it's less likely, because it's a normal function. Also, after a few years of Haskell programming, I am still not sure how to indent if-then-else. Perhaps in Haskell' we could have some lightweight case-of version with no pattern matching, guards only (cond could be a good name). I think it was even discussed before. The usual case-of looks like this: case x of Left err | isEOFError e - ... Left err - ... Right result - ... cond would involve no pattern matching, or only as pattern guards. cond x == 0 - ... x == 1 - ... otherwise - ... currently it can be written as case () of _ | x == 0 - ... _ | x == 1 - ... _ | otherwise - ... which is a bit ugly. Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
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? /Niklas On 7/27/06, Simon Peyton-Jones [EMAIL PROTECTED] 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 bool: 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? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 syntax? | | 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 [EMAIL PROTECTED] 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. Dan | Doel's answer is closest to the truth: | | I imagine the answer is that having the syntax for it looks nicer/is | clearer. if a b c could be more cryptic than if a then b else c | for some values of a, b and c. | | except that there was also the simple desire to conform to convention | here (I don't recall fewer parentheses being a reason for the choice). | In considering the alternative, I remember the function cond being | proposed instead of if, in deference to Scheme and to avoid confusion | with people's expectations regarding if. | | A related issue is why Haskell does not have a single arm conditional | -- i.e. an if-then form, which would evaluate to bottom (i.e. error) | if the predicate were false. This was actually discussed, but rejected | as a bad idea for a purely functional language. | |-Paul | |
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
[Haskell-cafe] Re: if-then-else as rebindable syntax (was Re: Why does Haskell have the if-then-else syntax?)
On 7/27/06, Niklas Broberg [EMAIL PROTECTED] wrote: 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. :-) I have now added a trac ticket for this proposal: http://hackage.haskell.org/trac/ghc/ticket/836 Please update if anyone has something to add or comment. /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
[Haskell-cafe] [FGL] Works on ghc, not on Hugs?
[Warning: beginner with FGL, the Functional Graph Library.] My first program with Data.Graph.Inductive works fine on ghc but raises a type error with hugs, which strikes me as odd. % hugs -98 smalltest.hs __ __ __ __ ___ _ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2005 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs@haskell.org || || Version: 20050308 _ Hugs mode: Restart with command line option +98 for Haskell 98 mode ERROR smalltest.hs:7 - Type error in application *** Expression : mkGraph mynodes myedges *** Term : myedges *** Type : [(Integer,Integer,[Char])] *** Does not match : [LEdge [Char]] ghc works: % ghc --make smalltest.hs Chasing modules from: smalltest.hs Compiling Main ( smalltest.hs, smalltest.o ) Linking ... % ./a.out 0:Toto-[(Couic,1),(Crac,2)] 1:Tata-[] 2:Shadok-[] 3:Machin-[] Here is the code: import Data.Graph.Inductive mynodes = [(0, Toto), (1, Tata), (2, Shadok), (3, Machin)] myedges = [(0, 1, Couic), (0, 2, Crac)] graph :: Gr String String graph = mkGraph mynodes myedges main = do print graph ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
On 2006-07-27 at 13:01+0200 Tomasz Zielonka wrote: But because if-then-else is an expression, there is another problem. That was exactly my point when I made the muttering about self-bracketing (if ... fi, like everything else, is an expression in Algol68) all those years ago. I really regret not having been more forceful! Also, after a few years of Haskell programming, I am still not sure how to indent if-then-else. what I was alluding to in my footnote... Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ 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] Why does Haskell have the if-then-else syntax?
Jon Fairbairn wrote: On 2006-07-27 at 13:01+0200 Tomasz Zielonka wrote: Also, after a few years of Haskell programming, I am still not sure how to indent if-then-else. what I was alluding to in my footnote... I think there's really only one way when it needs to occupy more than one line: if c then t else f Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ 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
On Thu, 27 Jul 2006, Niklas Broberg wrote: 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. That's true, I would like to use it. I plead for adding it to Prelude, whether the if-syntax becomes rebindable or not. I like to use (zipWith cond) for composing two lists depending on a key, or (uncurry . cond) as a choice between fst and snd, or the already mentioned 'select' command (foldr (uncurry cond)). Does anyone have any better suggestions, or is cond the name of the day? I like the similarity to if. However if_ or if' are too un-preludish. :-) ifElseThen is probably too long. 'cond' is acceptable. 'provided' too. ___ 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
On Thu, 27 Jul 2006, Henning Thielemann wrote: That's true, I would like to use it. I plead for adding it to Prelude, whether the if-syntax becomes rebindable or not. I like to use (zipWith cond) zipWith3, of course :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: System.FilePath 0.9
Trying to design a consistent naming system, it helps if we all agree on what the various parts of a filepath are called, this is my draft of that: http://www-users.cs.york.ac.uk/~ndm/temp/filepath.png For what it's worth, the FSF's coding conventions uses path only for lists of directories (typically used for a search, e.g. MANPATH, PATH, LD_LIBRARY_PATH, load-path, ...), not for file names. In their convention, /foo/bar/baz is a file name, where bar is a file name element IIRC. Stefan ___ 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] Why does Haskell have the if-then-else syntax?
On 27/07/06, Brian Hulley [EMAIL PROTECTED] wrote: I think there's really only one way when it needs to occupy more than one line: if c then t else f Confusingly, if c then t else f Also works, although no-one really knows why. -- -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
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. ___ 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
[Haskell-cafe] Re: Why does Haskell have the if-then-else syntax?
Confusingly, if c then t else f Also works, although no-one really knows why. Actually, it doesn't work inside a `do' layout, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
David House wrote:
On 27/07/06, Brian Hulley [EMAIL PROTECTED] wrote:
I think there's really only one way when it needs to occupy more
than one line:
if c
then t
else f
Confusingly,
if c
then t
else f
Also works, although no-one really knows why.
Only if the if does not start a new layout line. Anyway, how about
changing the syntax to:
if exp { then exp ; else exp }
Then the layout rule + the offside rule would still allow (iiuc)
if x 0 then 5 else 6
but would force the then to be further indented than the if (and the
else to be indented at least as much as the then (indenting it more is
where the offside rule is needed to make things work))
In addition, if we followed Jon's suggestion to make constructs
self-bracketing, we could allow an optional keyword such as /if to
terminate the construct early thus:
a = if x 0 then 5 else 6 /if + 78
I'd also change the lambda syntax to:
\{x 2 - x+5; x y - x*y}
which again would, by the layout rule, still allow current lambda syntax as
a special case. The optional terminator could be /\ and if all constructs
were now aexp's (as suggested by the desire to make them self-bracketing)
instead of exp10's we could then write:
f \x y - y x /\ 6
instead of having to write
f (\x y - y x) 6
I'd be in favour of /if /case /let /\ etc instead of fi esac tel because it
looks more systematic and follows the usual XML conventions for end tags.
I'd suggest that floating point division should just be written `divide` -
it's just a very specialised arithmetic op so why waste a nice symbol on it?
(ditto ^ ^^ **) (I'd have thought integer division is used more often and
no-one seems to mind writing `div`.)
Anyway having said all this, I can't help feeling that explicit brackets, as
required at the moment, help to clarify the structure of the code, and that
removing the need for them may negatively impact on readability.
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
___
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 doesHaskell have the if-then-else syntax?)
Niklas Broberg wrote: 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? I suggest: if_then_else :: a - b - b - b as the name of the function so that cond could be used for the new construct suggested by Tomasz. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
On 27/07/06, Brian Hulley [EMAIL PROTECTED] wrote: I'd be in favour of /if /case /let /\ etc instead of fi esac tel because it looks more systematic and follows the usual XML conventions for end tags. I'd suggest that floating point division should just be written `divide` - it's just a very specialised arithmetic op so why waste a nice symbol on it? (ditto ^ ^^ **) (I'd have thought integer division is used more often and no-one seems to mind writing `div`.) Why I'd oppose this: 1. Decreases readability/clarity (brackets group things so much clearer) 2. No obvious benefits over brackets (just as many keystrokes, if not more) 3. Not at all backwards-compatible. I'd support your ideas to change the if syntax, if they weren't backwards-incompatible. I think something as basic as if statements can't really be changed now. It will always be a blot on the otherwise lovely Haskell syntax. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: ANN: System.FilePath 0.9
On Wed, Jul 26, 2006 at 04:02:31PM -0700, Andrew Pimlott wrote: I admit I don't know enough to say how the lpt1 issue should be handled. Is there any Win32 call I can make that will help me avoid accidentally opening these magic files? Say, if I call open with O_CREAT | O_EXCL? Unfortunately, I can find very little information on how one should handle this issue. Thanks to a suggestion from Bulat to use c_open, I was able to test O_WRONLY | O_CREAT | O_EXCL on Windows. In fact, Windows does allow files like nul to be opened (as many times as you like) with these flags, which I find dismaying. So I still don't know the proper way to handle them. Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: ANN: System.FilePath 0.9
On Wed, Jul 26, 2006 at 05:06:41PM -0400, David Roundy wrote:
cp(1), for example, treats paths with trailing separators differently
from paths without.
This doesn't apply uniformly to all programs--except that we can say
that any path with a trailing '/' is intended to be a directory, and
if it's not, then that's an error. But the trouble is that if you
silently drop the '/', then the only way for me to implement a correct
cp(1) in Haskell is to not use your proposed interface for pathname
handling, which drops this information.
I thought some more about this, and I think the right way to handle this
is on parsing and printing. After all, the trailing slash has no real
meaning for any intermediate processing you might do. So if the type
used by my path operations is Path, I might have something like
readPath :: String - (Path, Bool {- trailing delimiter -})
showPath :: Path - String
showPathTrailingSlash :: Path - String
This is far simpler than trying to figure out what the slash means for
every path operation.
Andrew
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: ANN: System.FilePath 0.9
Hi hahaha! I admit I don't know enough to say how the lpt1 issue should be handled. Is there any Win32 call I can make that will help me avoid accidentally opening these magic files? No, because its entirely possible to open these magic files, you'll just find that accidentally your output has appeared at your printer, rather than on disk. BTW, it appears that wget itself does not handle it. :-) I know, but my hope is that HsWget will :) BTW, I guess wget should truncate the path at some number of characters Fortunately if we have FilePath == String, take n can be used, or more likely joinDirectories . take n . splitDirectories Windows doesn't use UTF-16, NTFS does. I was under the impression that NT's Unicode support was conceived when it meant UCS-2. So it uses UCS-2 and not UTF-16, which would mean that you could in principle encounter lone surrogate characters or something equally nonsensical. Yep, true, it uses UCS-2. Windows has two sets of file system related functions, one for legacy 8-bit character sets, one for Unicode. What happens if I call the Unicode API on a FAT system that doesn't support it? Does it do a half-assed version of the locale specific encoding that we deem impossible and wrong here? Of course :) And if you use the ANSI API's on a NTFS system you'll also get some dodgy encoding. Ah, never mind, I get the strong feeling I really don't want to know all this. When even Windows 98 has been end-of-lifed we should rely on the Unicode API, if anything. Windows ME has not been end-of-lifed, and still has native 8-bit. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: ANN: System.FilePath 0.9
On Thu, 2006-07-27 at 11:07 -0700, Andrew Pimlott wrote: On Wed, Jul 26, 2006 at 04:02:31PM -0700, Andrew Pimlott wrote: I admit I don't know enough to say how the lpt1 issue should be handled. Is there any Win32 call I can make that will help me avoid accidentally opening these magic files? Say, if I call open with O_CREAT | O_EXCL? Unfortunately, I can find very little information on how one should handle this issue. Thanks to a suggestion from Bulat to use c_open, I was able to test O_WRONLY | O_CREAT | O_EXCL on Windows. In fact, Windows does allow files like nul to be opened (as many times as you like) with these flags, which I find dismaying. So I still don't know the proper way to handle them. Interestingly even Windows explorer doesn't handle these odd files consistently. Renaming a file to com1 is ignored with no error, though renaming to com1.txt gives an error about such a file already existing. Also, it seems that com1.txt.txt is not allowed either. I thought that the extension of com1.txt.txt was txt but it seems that it is txt.txt and so the base name is com1 and thus not allowed. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re[2]: Why Haskell?
Sebastian Sylvan-2 wrote: Well, why would you want a huge array of random numbers? In Haskell there are two big ways to gain efficiency, strictness and laziness. In this case I think laziness is a big candidate (the huge array part gives it away). Also there is no reason generating random numbers should be in the IO monad - in fact the built-ins for random numbers are mainly regular pure functions. You only need IO in the very beginning to get a seed. So basically, try to use the extra modularity options that Haskell gives you to separate things that *need* to be IO and things that can just be regular lazy structures (like an infinite list of random numbers occupying memory the size of a pointer). In your case you'd use newStdGen in the IO monad to get a generator, and then produce a huge (e.g. infinite) list of random numbers using that (in a pure non-side-effect way), where only the numbers actually needed will ever be computed. If however you do need to do actual IO actions and you find it takes too much space, you can add some extra laziness using unsafeIntereaveIO. It basically just postpones an action until its result is needed. This is what readFile uses, btw, to get lazy IO. I think that's the way to go (rather than unsafePerformIO) because it's still IO so you don't end up in the situation where you have a pure function returning different results everytime you call it, and you still get laziness. Be careful, though, that your particular IO action won't behave strangely if it gets called at some random time or not at all. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe This kind of sidesteps my question concerning the efficiency of sequence (which it seems could be improved.) You are however correct about how I generate my random numbers. I could have used randomR and stayed out of the IO monad altogether. Also you do bring up an interesting point with regards to whether laziness buys you something with regards to the use of random numbers in a simulation such as mine. The answer is rather complicated. What is going on is that physical processes are being modeled as random processes, which requires the generation of a noise field, which is usually added to the real data of interest. This sort of thing happens all the time in physics and engineering and even numerical computations (e.g. Monte Carlo integration or Markov Chain Monte Carlo evaluation of Bayesian posteriors.). In my case, I have matrix statistics that will be computed after averaging over large amounts of data. Those computations will have to be performed; lazy evaluation won't make them go away. Moreover, to gain efficiency it is usually better to exercise the numerical libraries, such as BLAS over large matrices. Hence I believe it is more efficient to generate all my statistics in advance if possible. In some cases it is possible to reason about the process analytically and thereby mitigate the need to actually generate the random numbers, or to at least generate the final answer as a 'compressed' result, with smaller amounts of data being generated. However in most cases this is intractable and so the brute force approach is the only practical alternative. -- View this message in context: http://www.nabble.com/Why-Haskell--tf1986013.html#a5527728 Sent from the Haskell - Haskell-Cafe forum at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] heap issues
Hello, Why would ghci run out of heap space (and crash) the second time I run a computation? More specifically, I have a ghci session which goes something like this: *Analysisrun [ ... print out of a very long list ...] *Analysisrun [ ... partial print out GHC's heap exhausted: current limit is 268435456 bytes; Use the `-Msize' option to increase the total heap size. Shouldn't the garbage collector free up everything in between my top-level function executions? Also, there doesn't appear to be a '-Msize' flag for ghc (I'm using 6.4.2 on windows xp). thanks, Jeff -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] heap issues
On 27/07/06, Jeff Polakow [EMAIL PROTECTED] wrote: Also, there doesn't appear to be a '-Msize' flag for ghc (I'm using 6.4.2 on windows xp). I'm sure there is. You must add following arguments: +RTS -Msize -RTS Note the rts magic. Regards, -- Intelligence is like a river: the deeper it is, the less noise it makes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] heap issues
ghci keeps the value of your last computation in a special variable called it. Therefore, the value of your last run can't be garbage collected until the current run is finished. Try print run or type in a dummy expression in between runs. Cheers, Spencer Janssen On 7/27/06, Jeff Polakow [EMAIL PROTECTED] wrote: Hello, Why would ghci run out of heap space (and crash) the second time I run a computation? More specifically, I have a ghci session which goes something like this: *Analysisrun [ ... print out of a very long list ...] *Analysisrun [ ... partial print out GHC's heap exhausted: current limit is 268435456 bytes; Use the `-Msize' option to increase the total heap size. Shouldn't the garbage collector free up everything in between my top-level function executions? Also, there doesn't appear to be a '-Msize' flag for ghc (I'm using 6.4.2 on windows xp). thanks, Jeff -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ 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
Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
Thanks for the answer. (And doubly thanks for giving the answer I hoped for!) I propose that ifThenElse and thenElseIf be added to the Prelude for Haskell'. While these names are a bit long, I think we want both functions and these names make the behaviors clear (to me, at least). Comments? -m Paul Hudak [EMAIL PROTECTED] writes: 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. Dan Doel's answer is closest to the truth: I imagine the answer is that having the syntax for it looks nicer/is clearer. if a b c could be more cryptic than if a then b else c for some values of a, b and c. except that there was also the simple desire to conform to convention here (I don't recall fewer parentheses being a reason for the choice). In considering the alternative, I remember the function cond being proposed instead of if, in deference to Scheme and to avoid confusion with people's expectations regarding if. A related issue is why Haskell does not have a single arm conditional -- i.e. an if-then form, which would evaluate to bottom (i.e. error) if the predicate were false. This was actually discussed, but rejected as a bad idea for a purely functional language. -Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
