- Haskell-prime - Haskell.org

Re: [Haskell-cafe] Why does Haskell have the if-then-else syntax?
by Robert Dockins 28 Jul '06

28 Jul '06

On Jul 28, 2006, at 12:32 AM, Mike Gunter wrote: > 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? If we're planning on adding some boolean stuff to the Prelude, I'd like to suggest we add: bool :: a -> a -> Bool -> a bool f t b = case b of { False -> f; True -> t } Why? Because we already have the "maybe" and "either" functions in the prelude which are the catamorphisms on their respective types. While we're at it, we might as well throw in (ordering :: a -> a -> a -> Ordering -> a) as well. That would mean all the algebraic types defined in the Prelude also have their catamorphisms defined (eh, except for n-tuples where n>2, sigh... I guess one could add uncurry3, uncurry4, etc....). On an almost completely unrelated note, I've sometimes thought that it would be nice to be able to have the compiler auto-magicly generate catamorphisms for datatypes upon request. No, I haven't thought out the details. > -m > > > Paul Hudak <paul.hudak(a)yale.edu> 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 Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

2 1

[Fwd: Numeric Class reworking]
by isaac jones 26 Jul '06

26 Jul '06

Forwarding a message that was sent to me. Vivian, probably it bounced because you're not subscribed to the list? Thanks for sending it along. Anyone replying, please keep Vivian in the CC. peace, isaac

2 1

RE: deeqSeq proposal
by Simon Marlow 05 Jul '06

05 Jul '06

On 04 April 2006 19:53, Andy Adams-Moran wrote: > Andy Gill wrote: >> let xs' () = 1 : 2 : xs' () >> let xs2 = xs' >> >> let xs = 1 : 2 : xs >> >> So deepSeq xs2 ==> _|_, but deepSeq xs ==> xs Yes, and hence deepSeq isn't monotonic. That's bad. >> I appeal to the "morally correct reasoning" argument .. If the >> program terminates, then it is still correct. The deepSeq is an >> assertion about the ability to represent the result in finite space. > > I'm not convinced Simon's argument holds, as I don't think you can use > deepSeq to write a Haskell function that will distinguish cyclic > structures from infinite ones. If we can't do that, then we haven't > really added any new semantic observational capability to the theory, > so I think the "morally correct reasoning" argument holds. > > Simon? I think we should be able to rely on a bit more than "moral correctness" :-) Imagine writing a denotational semantics for deepSeq: you can't without talking about representations, and we don't want to talk about representations in denotational semantics, or in the Haskell language definition. The only thing you can do with non-functions is put them in the sin bin: deepSeq :: a -> IO () Cheers, Simon

4 4

Nested Guards
by Bas van Dijk 03 Jul '06

03 Jul '06

Hello, I would like to propose a feature from the FP language Clean[1] called Nested Guards. Example from [2]: example arg1 arg2 | predicate11 arg1 | predicate21 arg2 = calculate1 arg1 arg2 | predicate22 arg2 = calculate2 arg1 arg2 | otherwise = calculate3 arg1 arg2 | predicate12 arg1 = calculate4 arg1 arg2 I think the semantics are clear enough. Nested Guards should also be interoperable with Pattern Guards[3]. When a match on a pattern guard succeeds the environment is updated with the new bindings. Then the potential nested guards are matched in order in this new environment. What do you think? Bas van Dijk. [1] http://www.cs.ru.nl/~clean [2] ftp://ftp.cs.kun.nl/pub/Clean/Clean20/doc/CleanRep2.0.pdf (See 3.3 Guards) [3] http://hackage.haskell.org/trac/haskell-prime/wiki/PatternGuards

3 5

Regarding Class Aliases
by Christophe Poucet 23 May '06

23 May '06

Dear all, I have looked through the tickets of haskell-prime. I would like to bring up my own point of view concerning one specific ticket, namely Class Aliases. I have looked at the ticket and right now it's marked as a low priority with low probability of entering the standard. As I see it, class aliases have a low impact on most of the code, only requiring some syntactical changes and some extensions in .hi interface. However, they can be very empowering with regards to the modularisation of type classes. Often people on #haskell want to implement some subset of Num and reuse as much as possible that which exists but find themselves stuck because their type does not support all the semantics of Num. With the use of type-classes one can easily decompose Num into a set of subclasses without making it more difficult to use for the general user of Num. In addition it can be used for other modularisations as well, making them quite trivlal, for instance the proposal to split Enum. Just my two cents :) With regards, Christophe Poucet -- Christophe Poucet Ph.D. Student Phone:+32 16 28 87 20 E-mail: Christophe.Poucet(a)imec.be IMEC vzw – Register of Legal Entities Leuven VAT BE 0425.260.668 – Kapeldreef 75, B-3001 Leuven, Belgium – www.imec.be *****DISCLAIMER***** This e-mail and/or its attachments may contain confidential information. It is intended solely for the intended addressee(s). Any use of the information contained herein by other persons is prohibited. IMEC vzw does not accept any liability for the contents of this e-mail and/or its attachments. **********

3 2

Re: Class System current status
by Stephanie Weirich 16 May '06

16 May '06

So it looks like we're stuck at pretty much the same proposals for the class system. a) standardize on MPTC and FDs using rules from CHR paper. b) don't standardize anything, and wait for ATs to take over c) punt---standardize the library and exact form of FD for that library, but no more, or map out some longer timeline for this issue. For a while I thought (a) was the clear choice. The theory has been worked out, we have a lot of experience using them, and key libraries depend on them. However, not everyone is convinced by (a) because of the fear of too early standardization. We may end up with a lot of code that uses a feature that will eventually be deprecated. There are perhaps three counterarguments to this point of view: - We're already in that state. There *is* a lot of Haskell code that uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll still have to deal with this code. - It may be that all uses of MPTCs/FDs may be subsumed by ATs, and in fact there is (or will be) some automatic way of translating FD code to AT code. - It may not be all bad for a future Haskell standard to include both ATs and FDs. Certainly more complicated, but I haven't seen any evidence that these features interfere with eachother. Are there any merits to these counterarguments? More generally, our discussion about the class system seems to be stalled. How should we to come to a decision? --- Stephanie

9 17

Re: Class System current status
by John Hughes 15 May '06

15 May '06

Stephanie wrote: > Simon, > > Why is an Appendix is better than just a footnote in the Standard that > says "we aren't sure, one way or the other, whether FDs will stay in > the language for ever." Why do we need this extra structure? > > I'm worried that this extra structure could be confusing. In > particular, if someone says "this program is pure Haskell'" what will > that mean? In practice, will it be clear whether pure Haskell' > includes the Appendix? I don't like the appendix idea either--or a footnote for that matter. I don't think a language definition should be cluttered by remarks about whether or not the designers are sure they got each bit right. It should just define a language. It seems to me that Haskell' is gaining a status in our minds that it doesn't deserve--that the "main" language report should be a thing of permanence that will stand the test of time. Previous versions of Haskell haven't. There was no footnote in the Haskell 1.2 report indicating that the IO system might be replaced... yet that's exactly what happened in 1.3, a much more dramatic change than replacing FDs by ATs will be. Future versions of Haskell may change things--that's a given. The language will continue to evolve. We've even been discussing changing the semantics of pattern matching this time around--which shows that even basic parts of the language may be called into question in the future. Haskell' should define a standard language for use TODAY--and it should be 100% clear what that language is, with no pussy-footing around difficult choices. In my view it should include FDs. Then in the future they may be replaced--but it should then be clear that this IS a replacement, with no arguments of the sort "well it's not really an incompatible change because FDs were only in an appendix"! Let's face it, people ARE going to use FDs whatever the standard says, because they're just so godamn useful, and rewriting those programs if FDs are replaced by ATs is not going to be any easier because it's an appendix that's changing, rather than the main body of the report. John

2 1

Re: WordPtr,IntPtr,IntMax,WordMax
by John Meacham 12 May '06

12 May '06

On Fri, May 12, 2006 at 10:19:18AM +0100, Simon Marlow wrote: > >Especially since even: > > > > checking Haskell type for intmax_t... not supported > > checking Haskell type for uintmax_t... not supported > > > >aren't universal :) > > Well, yes. Any suggestions for what to do here? Make a best guess? What is the problem here? are intmax_t and uintmax_t not on all systems? there is a handy autoconf macro that generates an appropriate ISO compliant inttypes.h if one doesn't exist on a system. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

Re: WordPtr,IntPtr,IntMax,WordMax
by John Meacham 12 May '06

12 May '06

On Thu, May 11, 2006 at 02:57:30PM +0100, Simon Marlow wrote: > On the other hand, keeping intermediate Doubles to 80-bit precision is > both (a) non-portable and (b) unpredictable (the programmer doesn't know > which intermediates are going to be stored in 80 bits, and turning on > optimisation will probably make a difference). Indeed, not storing the intermediate values as 80 bits is one of the 'nicer' things I was refering to. :) though, this does bring up another standardish C type we should support __float128 and __complex as pointed out by Aaron. any idea what would be a good module to export them from? John -- John Meacham - ⑆repetae.net⑆john⑈

3 2

Re: WordPtr,IntPtr,IntMax,WordMax
by Duncan Coutts 11 May '06

11 May '06

On Thu, 2006-05-11 at 14:57 +0100, Simon Marlow wrote: > On the other hand, keeping intermediate Doubles to 80-bit precision is > both (a) non-portable and (b) unpredictable (the programmer doesn't know > which intermediates are going to be stored in 80 bits, and turning on > optimisation will probably make a difference). > > I suppose you might argue that "extra precision is always good". But I > like it when Haskell programs give the same results, regardless of the > platform, compilation strategy, and level of optimisation. > > > (And while I'm on the subject, Haskell should have a LongDouble type.) > > LongDouble would be fine, but storing intermediate Doubles in 80 bits is > bad. I agree. Note that if we did provide LongDouble that we would get the same problems because the IEEE long double types are not precisely specified. They specify minimum precision levels rather that fully specifying the bit layout as in the IEEE 32 & 64 bit formats. Apparently both the x87 80-bit format and various implementations of 128bit formats conform to the IEEE long double spec. Duncan

1 0