May 2006 - Haskell-prime

Exceptions
by John Goerzen 07 Sep '06

07 Sep '06

Hello, One thing that bugs me about Haskell is that exceptions are not extensible. I don't know how to craft a good solution, but perhaps if I explain the problem well, someone would come up with one. In a language such as Python or Java, and exception is an object. Let's consider Python for a quick example. Python has an IOError exception. So if I want to write a handler that deals with IOErrors, that's easy enough. Now maybe I want to do something like report socket errors specially. I could define a SocketError class that subclasses IOError. I could take this further, and define a URLError that subclasses SocketError. Now the beauty of it is that I can: * Have a handler that catches URLErrors only and does nothing special with SocketErrors or IOErrors. * Have a handler -- perhaps not even mine -- that catches and works with IOErrors. Since SocketError and URLError are descendants of IOError, that handler will *automatically* work if I raise a SocketError or a URLError. I can see no such mechanism in Haskell. Haskell's I/O exceptions have a certain defined set of errors that they can report, and I can't subclass them and make them more specific for my purposes if I want. Ditto for all the others. The Dynamic exception support is necessary and good to have, but it also under-documented and can be complex. And of course, they still suffer from the same lack of extensibility Are there any suggestions on how we might improve this situation in Haskell? -- John

6 12

RE: deeqSeq proposal
by Simon Marlow 06 Jul '06

06 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

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 17 May '06

17 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 16 May '06

16 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 12 May '06

12 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

termination for FDs and ATs
by Ross Paterson 10 May '06

10 May '06

To ensure termination with FDs, there is a proposed restriction that an instance that violates the coverage condition must have a trivial instance improvement rule. Is the corresponding restriction also required for ATs, namely that an associated type synonym definition may only contain another associated type synonym at the outermost level? If not, wouldn't the non-terminating example from the FD-CHR paper (ex. 6, adapted below) also be a problem for ATs? class Mul a b where type Result a b (.*.) :: a -> b -> Result a b instance Mul a b => Mul a [b] where type Result a b = [Result a b] x .*. ys = map (x .*.) ys f = \ b x y -> if b then x .*. [y] else y

7 30

FFI proposal: allow some control over the scope of C header files
by Duncan Coutts 09 May '06

09 May '06

One problem that people writing FFI bindings often run into is that they do not understand exactly where C header files are required to be available. The easy case is importing some C function defined in a well known and widely available C header file (eg gtk/gtk.h). In this case we just make sure that header is available for compiling every module in the package and add that header file to the package info file (or .cabal file) so that every module that uses the package will have the C header available. In this case there is no problem with C calls being inlined outside of the module which imported them since the C header file will be available everywhere. The tricky case is that people often use "private" header files that are #included when compiling a module/package but are not installed along with that package and so are not #included when compiling client modules. Most of the time this works, however the Haskell compiler is allowed to inline across modules and if it chooses to inline the C call into a client module then things will break. Sadly it still compiles and sometimes even works since C allows calling a C function without a prototype. However occasionally it's going to break horribly. Allowing us to limit where the C headers will be required would be very useful. Sometimes it is very convenient to have private header files that will not be installed with the package. It is also sometimes the case that it's much more convenient to not require that the user has a set of C header files installed to be able to use a library package. Examples of this include some windows packages, eg DriectX where it's rather inconvenient to require that users have the MS DirectX SDK installed. Currently GHC has a de-facto way of limiting the required scope of C header files to a module - by using the standard FFI syntax (!). I know people are already using this trick to allow the use of private header files. This issue also touches on the related issue that the way of specifying C header files in the FFI spec is not really optimal. GHC implements a couple other methods and these are probably used more that the method in the FFI spec. So I suggest that we briefly consider some possibilities for extending control over where C header files will be needed and perhaps also for specifying what C header files are needed in the first place. I think we'd want to be able to specify that a C header file not "escape" a module boundary and probably we'd also want to be able to ask that it not escape a package boundary (though this may be beyond the H' spec since Haskell does not talk about packages). It would also be convenient to be able to specify that a module needs a particular C header file rather than having to specify it in each foreign import decl. Currently this can be done by cabal in a compiler-specific way (it uses ghc's -#include command line mechanism) It's a reasonable question to ask if specifying a C header file should go in the module source code or elsewhere (eg a .cabal file) since afterall we don't specify search paths etc in the module. I'd say that it is right that the name of the header file be in the module source code and that the search paths etc be external. So some syntax off the top of my head: foreign import cheader module-local "foo/bar.h" I think there are 3 possibilities for the C header escape/scope setting (which should probably be manditory rather than optional): module-local package-local (extension for compilers that have a notion of a package) global this should allow us to automatically check what C headers are needed by client modules. Duncan

7 23