April 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

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

Re: WordPtr,IntPtr,IntMax,WordMax
by Manuel M T Chakravarty 09 May '06

09 May '06

Am Donnerstag, den 06.04.2006, 16:37 -0700 schrieb John Meacham: > On Thu, Apr 06, 2006 at 04:28:01PM -0700, John Meacham wrote: > > I was curious if ghc could support the following basic types, they will > > likely just be aliases of existing types. > > > > WordPtr uintptr_t > > WordMax uintmax_t > > IntPtr intptr_t > > IntMax intmax_t > > > > all these C types are defined by ISO C so should be available, > > otherwise, they are easy enough to generate in ghcs autoconf script. > > > > jhc provides these under these names in Data.Word and Data.Int. > > they would be useful for writing jhc/ghc portable low level code, and > > writing 32/64 bit safe code. > > oh, I forgot the all important conversion routines, > > ptrToWordPtr :: Ptr a -> WordPtr > wordPtrToPtr :: WordPtr -> Ptr a > > ptrToIntPtr :: Ptr a -> IntPtr > intPtrToPtr :: IntPtr -> Ptr a > > jhc makes these available in Jhc.Addr, but if ghc decides to provide > them in a common spot (Foreign.Ptr maybe?) > > then I will have jhc follow suit. > > I'd also propose these be added to the FFI standard. I collect additions to the FFI on the Haskell' wiki: http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignFunctionInterface I added a note about these types. Any other ISO C types that we should include? Manuel

3 3

Haskell' status & summary
by Isaac Jones 02 May '06

02 May '06

Greetings! I'll try to update the Haskell community periodically on the status of the Haskell' language standard. As mentioned previously, we are currently focusing on two topics, concurrency and the class system. If you feel that you have anything important to contribute to those topics, now is the time to review the proposals, join in the Haskell' mailing list and let us know what you know! Stephanie Weirich has posted a summary of the class system discussion here: http://hackage.haskell.org/trac/haskell-prime/wiki/ClassSystem Stephanie says: This page is important because it lists all of the proposals not related to MPTCs as well as trying to capture the big picture about where we stand with respect to MPTCs. I've been trying to not duplicate text that appears elsewhere in the wiki, but just provide a consistent picture of the state of the discussions on the mailing list. Please take a look at this page and help me fill it out. In particular, 've been trying to take a pulse of where we stand on some of these issues, and some of you may not agree! Tell me if I'm off the wall. Also, I've (mostly) concentrated on issues that have tickets, so I may have missed some issues that were only discussed in the mailing list. Please let me know if there is anything I've forgotten. Simon Marlow has posted a summary of the concurrency discussion here: http://hackage.haskell.org/trac/haskell-prime/wiki/Concurrency Simon says: I have tried to summarise the various points that have arisen during the discussion. If anyone feels they have been mis-paraphrased, or I have forgotten something, please feel free to edit, or send me some text for inclusion. I don't want to include long gobs of text in here, though: just summarise the main points, and if necessary link to relevant mailing list posts. Thanks, Simon & Stephanie for keeping things moving forward! peace, isaac

3 2

Class ATs Question
by Ashley Yakeley 30 Apr '06

30 Apr '06

You can do two-way fundeps. Can these be done with associated types? For instance: class HasSign u s | u -> s, s -> u where unsignedToSigned :: u -> s signedToUnsigned :: s -> u instance HasSign Word8 Int8 where ... It might not be a great loss if not. -- Ashley Yakeley, Seattle WA WWEWDD? http://www.cs.utexas.edu/users/EWD/

4 4

unsafePerformIO and cooperative concurrency
by Simon Marlow 29 Apr '06

29 Apr '06

Given that unsafePerformIO is (perhaps) to be part of the Haskell' standard, the combination of unsafePerformIO and cooperative concurrency introduces some interesting cases that will probably have to be declared to be undefined in the standard - what happens when you yield or do some I/O inside unsafePerformIO? I guess a concurrent foreign call executed from inside unsafePerformIO doesn't work either? What about a reentrant one? (I know that reentrant foreign calls currently don't work inside unsafePerformIO in Hugs, IIRC it can lead to a segfault). So does this mean that a foreign call that doesn't return an IO type cannot be declared concurrent? Cheers, Simon

6 9

concurrency guarentees clarification
by John Meacham 27 Apr '06

27 Apr '06

I have been twiddling some with the wording of the concurrency guarentees and want to run them by the list. the rules I am thinking of adding are: * every runnable thread is guarenteed to run in a finite amount of time if a program reaches a yield-point infinitly often. * Foreign concurrent calls, handle IO, and all IO actions that directly interact with the world outside the current process all must be yield-points. (in addition to any yield-points implied by the progress guarentee) The first rule is just to rule out completely brain-dead schedulers and give a fairly useful fairness guarentee. (in fact, I think it subsumes the preemptive fairness guarentee as written, as a preemptive implementation does reach a yield-point infinitly often independently of what the program is doing) I originally thought the progress guarentee implied the second, but I realize that is somewhat UNIX-centric in that all IO must be treated as potentially blocking. however in an embedded system where for instance you write directly to the screen buffer rather than a file descriptor this might not be the case so we should probably be more clear. I would like to avoid enumerating the yield points explcitly, except perhaps as a guide saying "these library routines are examples of those in the standard library that must be yield-points according to the standard". Coming up with a rule rather than a list will make it easier for users to think about and give guidance (though of course we can't guarentee) where yield-points should be placed in any implementation provided extensions. I don't intend to imply things like all memory access in case it is in an memory mapped IO region or anything that changes CPU load because someone might be looking at your CPU usage in /proc should be yield-points, just those IO actions that "explicitly" interact with the outside world. for the correct definition of explicitly. :) John -- John Meacham - ⑆repetae.net⑆john⑈

4 3

Concurrency, FFI status
by Simon Marlow 24 Apr '06

24 Apr '06

This is just a "heads up" that I'm currently collating the current state of the discussion re: concurrency and the FFI, with a view to enumerating all the current issues with rationale on the wiki. It's getting to a state where I can't keep it all in my head at one time, and I think this will help us to move forward, and give others a chance to identify issues they would like to comment on. So just in case anyone else was considering large changes to the concurrency page on the wiki, please hold for a while. I should have it up by the end of the day. Cheers, Simon

4 5