- Haskell-prime - Haskell.org

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

09 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 08 May '06

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

08 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 01 May '06

01 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 29 Apr '06

29 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 26 Apr '06

26 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

need help again [loading bitmaps]
by enache alex 22 Apr '06

22 Apr '06

hello again ; I am writing again to ask you if you can please show me an example of loading a bitmap on a window ; I tried tu use the bitmap function from Graphics.Rendering.OpenGL.GL.Bitmap but it gives me an error ; I've called the function like this : bmp <- bitmap (Size (100,100)) (Vertex2 (0::GLfloat) 0) (Vector2 0 0 ) (Ptr "C:\1.bmp") ; and it sais ERROR file:.\ball.hs:43 - Undefined data constructor "Ptr" pls help ; I want to make my game look a little better ; thanks again ; --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.

2 1

need help please[HOpenGL]
by enache alex 22 Apr '06

22 Apr '06

hello ; I am learning to use to HOpenGL to complete an asignement for next week and I have some trouble ; I have found a tutorial on the internet ; in that tutorial it was an example of the Rubik's Cube ; anyway ; in that example it was used a function called matrixExcursion ; and when I try to run the example it sais that : " ERROR file:.\RubikFace.hs:9 - Undefined variable "matrixExcursion" " I don't know what to do ; please help ; I need to know immediatly how to fix this problem ; thanks for your time in reading this , and hope to hear from you soon ; I wish you all the best --------------------------------- How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.

2 1