[GHC] #700: Inconsistent typechecking of pattern match in function binding
#700: Inconsistent typechecking of pattern match in function binding
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.4.1
Severity: normal| Keywords:
Os: Unknown | Difficulty: Unknown
Architecture: Unknown |
-+--
{{{
f,g :: (forall a. Maybe a) - (forall a. a)
f x = case x of Just y - y
g (Just y) = y
}}}
f is accepted by 6.4.1, but g isn't. I think g should also be accepted.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/700
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell] GLUT gears speed
[ Sorry for the extremely slow reply, I'm just working through a mail backlog of about one month... ] Am Freitag, 6. Januar 2006 22:17 schrieb Wolfgang Jeltsch: what's the reason behind the HOpenGL gears only being about 2/3 as fast as glxgears on my computer? Since I don't use any 3D acceleration, I thought that most of the CPU's time is spend for rendering and displaying so that speed differences between Haskell and C shouldn't matter that much. An almost identical issue was discussed on the HOpenGL mailing list some time ago: http://www.haskell.org//pipermail/hopengl/2004-March/000476.html The net result is: There is no measurable speed difference compared to plain old C when using Haskell + HOpenGL. Another nice project to look at: http://www.haskell.org//pipermail/haskell/2005-November/016941.html Having said this, one should mention that there are plenty of reasons for bottlenecks when doing graphics in OpenGL in general: The application performance can be limited by the CPU, memory bandwidth, the GPU on the graphics card, pixel bandwidth, etc. The least thing I would worry about would be Haskell or the HOpenGL package. :-) Rendering terrain efficiently is a rather tricky topic, so one can find tons of books and papers on it, and I guess it still has enough potential to give material for several PhD dissertations. If your students are new to Haskell, OpenGL and terrain rendering algorithms, this might be a little bit too much IMHO. Regarding documentation: The OpenGL package documentation is admittedly sometimes a bit terse, it ranges from no comments at all (i.e. only things that Haddock can generate automatically) to rather elaborate, e.g.: http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-Points.html http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-LineSegments.html The OpenGL 1.5 spec is about 333 pages, and translating this into Haddock comments is a huge amount of work, so I comment only from time to time (a slow, but ongoing process). But the main idea here is that the OpenGL binding resembles the C API closely enough that everybody who knows the spec should have no problem at all writing OpenGL stuff in Haskell. Therefore the whole module structure and naming is designed to closely follow the spec, compare e.g. http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Rendering-OpenGL-GL.html with the index of the OpenGL 1.5 spec. Furthermore, the GLUT package has quite a few examples to get everyone started. If there are still problems, there is still the hopengl list and I'll happily clarify any unclear points. The GLUT package is structured similarly, but fully documented: http://www.haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics-UI-GLUT.html In general, I think it is a good idea for any binding to follow the structure of the original spec as closely as possible. Cheers, S. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GLUT gears speed
Am Montag, 16. Januar 2006 21:52 schrieb Wolfgang Jeltsch: Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan: or (better) vertex buffer objects. What's this? The basic idea behind buffer objects is a general mechanism which allows the driver to keep huge amounts of data on the extremely fast on-board memory of graphics cards, potentially in an already preprocessed form. Currently two kinds of data are standardised: Vertex arrays and indices into those arrays. This is a rather cool mechanism, making some more specialised extensions like compiled vertex arrays (= Quake :-) superfluous. Furthermore you should do some hierarchical culling on the terrain (using, e.g. a quad-tree) to avoid drawing things which are not visible. Too complicated for the practical course. Doesn't OpenGL already do something like this? OpenGL is intentionally designed as a *rendering* library, onto which higher-level libraries (e.g. Inventor) can be layered. Of course OpenGL throws away invisible primitives as fast as possible, but even this takes some time, so higher-level libraries can make OpenGL's life much easier. [...] To summarize: Drawing vast terrains quickly has much more to do with algorithmic cleverness rather than miniscule overheads from library bindings. I did not refer to the overheads of the binding but to the slowness of Haskell (compared to C, of course ;-) ). [...] I think this is one of the strengths of a Haskell binding for OpenGL: You can concentrate on the fun part (i.e. clever rendering algorithms etc.) much more easily than in C. Given the same amount of time, I imagine that one can implement much more elaborate stuff than in C, so you can actually get better performance. Cheers, S. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] libreadline dependency
Could you not simply install both? At least in Debian, I have both /lib/libreadline.so.4 (which is a symlink to 4.3) /lib/libreadline.so.5 (which is a symlink to 5.1) - Cale On 18/02/06, J. Scott Thayer, M.D. [EMAIL PROTECTED] wrote: Running Suse 9.3 64bit on Acer Ferrarri laptop. Haskell wants libreadline 4 while I have libreadline 5. Is there a definitive fix for this? The answers in archived messages were 'sub-optimal'. ___ 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
