Re: [Haskell-cafe] class default method proposal
Simon Peyton-Jones wrote: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now A better rule would be: If this search finds exactly one binding that is minimal in the partial ordering defined by the superclass hierarchy, use it, otherwise behave as now. Would that be much harder to implement? -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS 10.5 Leopard (Intel) - Configure fails
That was THE tip, thanks a lot! I've been using a tool called 'the unarchiver' to extract the tarball, apparently is does not do it's job very well... Manuel M T Chakravarty schrieb: Carsten Keßler: OK, now I get no GMP error any longer, instead, I got my good old OpenGL-error back... Installing: /Library/GHC/lib/ghc-6.8.1/lib/OpenGL-2.2.1.1 installPackage: Error: Could not find module: Graphics.Rendering.OpenGL.GL.PixelRectangles.PixelStorage with any suffix: [p_hi] make[1]: *** [install.library.OpenGL] Error 1 make: *** [install] Error 2 Did I miss more Libs that I need to install before running make install? IIRC I have seen this error before. The reason was that the zip archive un-compressor that was used to unpack the tar.bz2 ball was not working correctly. Please us the tar xjf name of tarball to unpack the archive. Manuel Right, you need to install gmp from MacPorts, too, because chakravarty's binary still depends on it. (although gmp was integrated?) Christian otool -L utils/ghc-pkg/ghc-pkg.bin utils/ghc-pkg/ghc-pkg.bin: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) otool -L compiler/stage2/ghc-6.8.1 compiler/stage2/ghc-6.8.1: /opt/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0, current version 5.2.0) /opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) -- Carsten Keßler Institute for Geoinformatics, University of Münster http://www.carstenkessler.de -- Carsten Keßler Institute for Geoinformatics, University of Münster http://www.carstenkessler.de ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
newtypes and optimization
Hi,
I have a statically-sized-list library that I use for linear algebra stuff.
It's got a vector type something like this:
data V a b = V a b
so that a 3D vector is
type Vec3 a = V a (V a (V a ()))
and I have type classes for operations on these things, like so:
class VZipWith a b c u v w | {-lots of fundeps-} where
vzipWith :: (a - b - c) - u - v - w
instance VZipWith a b c (V a ()) (V b ()) (V c ()) where
vzipWith f (V x ()) (V y ()) = V (f x y) ()
instance
VZipWith a b c (V a u) (V b v) (V c w)
= VZipWith a b c (V a (V a u)) (V b (V b v)) (V c (V c w))
where
vzipWith f (V x u) (V y v) = V (f x y) (vzipWith f u v)
so that vector addition is
vadd = vzipWith (+)
I put strictness annotations and INLINE pragmas all over the place, and GHC
does wonders with it. Using Storable instances something like the following,
instance Storable a = Storable (V a ()) where
sizeOf _ = sizeOf (undefined::a)
peek p = peek (castPtr p) = \a - return (V a ())
--etc
instance (Storable a, Storable v) = Storable (V a v) where
sizeOf _ = sizeOf (undefined::a) + sizeOf (undefined::v)
peek p =
a - peek (castPtr p)
v - peek (castPtr (p`plusPtr`sizeOf(undefined::a)))
return (V a v)
GHC can turn a loop like this,
forM_ [0..n] $ \i -
do a - peekElemOff aptr i
b - peekElemOff bptr i
pokeElemOff cptr i (vadd a b)
into something as fast as C, using no heap. You look at the core and its
nothing but readDoubleOffAddr#, +## and the like. I went so far as to generalize
this to matrices with things like vector-matrix and matrix-matrix
multiplication, determinants and all that and, when used in loops like above,
it's consistently as fast or even faster than C.
However when I do this:
newtype Quaternion = Q (Vec4 Double)
Everything is ruined. Functions like peek and vadd are no longer inlined,
intermediate linked lists are created all over the place. The Quaternion
Storable instance looks like this
instance Storable s = Storable (Quaternion s) where
sizeOf _ = 4*sizeOf (undefined::s)
peek p = peek (castPtr p :: Ptr (Vec4 s)) = \v - return (Q v)
with strictness annotations and INLINEs for everything. I also tried automatic
newtype deriving, with no luck. Why does a newtype defeat so much of the
optimization?
Thanks,
Scott
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] class default method proposal
Simon Peyton-Jones wrote: Concerning (b) here's a suggestion. As now, require that every instance requires an instance declaration. So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write instance Monad T where return = ... (=) = ... instance Functor T instance Applicative T Another alternative is to allow multiple classes in an instance declaration: instance (Monad T, Functor T, Applicative T) where return = ... (=) = ... The advantage is that this makes it more clear where the instances come from, especially if a class has multiple sub classes with different defaults. It also eliminates tricky issues with importing. Of course this needs some (albeit very little) new syntax. I wrote a proposal a while ago, http://haskell.org/haskellwiki/Superclass_defaults Twan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ANNOUNCE: GHC version 6.8.2
= The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 = The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.8.2/html/users_guide/release-6-8-2.html How to get it ~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Readline for Windows in the FAQ
Maybe I'm just too new at this, but the GCH FAQ entry for readline in GHCi is confusing for me. Especially since it ends with the sentence Instructions for GHC 6.2.2. are here. However, as the quote goes, there's no 'here' here. - the location of the instructions are missing. Could someone please clue me in to what I'm missing? That way, I could edit the Wiki page, to clue in others better. -- This signature intentionally left blank ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: newtypes and optimization
On Wed, Dec 12, 2007 at 11:02:15AM -0700, Scott Dillard wrote: with strictness annotations and INLINEs for everything. I also tried automatic newtype deriving, with no luck. Why does a newtype defeat so much of the optimization? Thanks, Scott (Not a GHC developer, but someone fairly familiar with how the Simons work) What version of GHC are you using? The implementation of newtypes was completely redone in the 6.7.x period. Do you have a fairly small complete working example? If so, link to or attach a tarball - will make their jobs much easier. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: newtypes and optimization
stefanor: On Wed, Dec 12, 2007 at 11:02:15AM -0700, Scott Dillard wrote: with strictness annotations and INLINEs for everything. I also tried automatic newtype deriving, with no luck. Why does a newtype defeat so much of the optimization? Thanks, Scott (Not a GHC developer, but someone fairly familiar with how the Simons work) What version of GHC are you using? The implementation of newtypes was completely redone in the 6.7.x period. Do you have a fairly small complete working example? If so, link to or attach a tarball - will make their jobs much easier. Stefan Yeah, this sounds like maybe a bug, or maybe something wrong. We need to investigate! An example please. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: newtypes and optimization
You can find an example at: graphics.cs.ucdavis.edu/~sdillard/newtype-maybe-bug.tar.gz Here's my session with it: ghc --make -O2 -DFAST Test time ./Test +RTS -tstderr ghc: 21120 bytes, 2 GCs, 32768/32768 avg/max bytes residency (1 samples), 1M in use, 0.00 INIT (0.00 elapsed), 7.52 MUT (8.70 elapsed), 0.00 GC (0.00 elapsed) :ghc real0m8.827s user0m7.520s sys 0m1.224s ghc --make -O2 -DSLOW Test -no-recomp time ./Test +RTS -tstderr Ctrl-C Test: interrupted ghc: 13476104656 bytes, 25762 GCs, 36864/36864 avg/max bytes residency (1 samples), 1M in use, 0.00 INIT (0.00 elapsed), 91.19 MUT (92.85 elapsed), 0.22 GC (0.36 elapsed) :ghc real1m33.232s user1m31.410s sys 0m1.020s If you do ghc -c -O2 -DFAST -ddump-simpl Test.hs | grep VecMath.V you won't find any occurrences/pattern matches on the constructor, but with ghc -c -O2 -DSLOW -ddump-simpl Test.hs | grep VecMath.V you'll see lots, due to a call to peek that is not inlined. This is with ghc-6.8.1 and ghc-6.8.2 (no difference) Thanks for any light you can shed on this, Scott On Dec 12, 2007 1:48 PM, Don Stewart [EMAIL PROTECTED] wrote: stefanor: On Wed, Dec 12, 2007 at 11:02:15AM -0700, Scott Dillard wrote: with strictness annotations and INLINEs for everything. I also tried automatic newtype deriving, with no luck. Why does a newtype defeat so much of the optimization? Thanks, Scott (Not a GHC developer, but someone fairly familiar with how the Simons work) What version of GHC are you using? The implementation of newtypes was completely redone in the 6.7.x period. Do you have a fairly small complete working example? If so, link to or attach a tarball - will make their jobs much easier. Stefan Yeah, this sounds like maybe a bug, or maybe something wrong. We need to investigate! An example please. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] class default method proposal
I had it pretty well worked out for single parameter type classes, but I couldn't see any nice extension to multiple parameters. On Dec 11, 2007 5:30 PM, Simon Peyton-Jones [EMAIL PROTECTED] wrote: | If it really would work ok we should get it fully specified and | implemented so we can fix the most obvious class hierarchy problems in a | nice backwards compatible way. Things are only supposed to be candidates | for Haskell' if they're already implemented. Getting it fully specified is the first thing. Personally I am not keen about a) coupling it to explicit import/export (independently-desirable though such a change might be) b) having instance declarations silently spring into existence Concerning (b) here's a suggestion. As now, require that every instance requires an instance declaration. So, in the main example of http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data type T you'd write instance Monad T where return = ... (=) = ... instance Functor T instance Applicative T The instance declaration for (Functor T) works just as usual (no explicit method, so use the default method) except for one thing: how the default method is found. The change is this: Given instance C T where ..., for any method 'm' not defined by ...: for every class D of which C is a superclass where there is an instance for (D T) see if the instance gives a binding for 'm' If this search finds exactly one binding, use it, otherwise behave as now This formulation reduces the problem to a more manageable one: a search for the default method. I'm not sure what is supposed to happen if the instance is for something more complicated (T a, say, or multi-parameter type class) but I bet you could work it out. All these instances would need to be in the same module: - you can't define Functor T without Monad T, because you want to pick up the monad-specific default method - you can't define Monad T without Functor T, because the latter is a superclass of the former It still sounds a bit complicated. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Alex, Lennart's suggestion makes me think: Why not make SearchPath
into a preprocessor? It could recognize a .ehs extension, and then do
some very simple preprocessing (adds pragmas according to user's
settings).
--
Robin Bate Boerop
On 22/11/2007, Lennart Augustsson [EMAIL PROTECTED] wrote:
Or use a preprocessor that inserts a LANGUAGE pragma. :)
On Nov 22, 2007 9:14 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Alex Jacobson wrote:
In any case, I'm pretty sure the correct answer is not 50 language
pragmas with arbitrary spellings for various language features at the
top of each source file.
You probably won't like any of these, but there are many ways to avoid
writing out all the pragmas at the top of each file.
1. Use Cabal's extensions field.
2. Use CPP
MyExtensions.h :
{-# LANGUAGE TemplateHaskell, FlexibleInstances,
OverlappingInstances, UndecidableInstances, CPP,
ScopedTypeVariables, PatternSignatures, GADTs,
PolymorphicComponents, FlexibleContexts,
MultiParamTypeClasses, DeriveDataTypeable,
PatternGuards #-}
MyModule.hs:
{-# LANGUAGE CPP #-}
#include MyExtensions.h
3. Use a shell alias
alias ghce='ghc -XTemplateHaskell -XFlexibleInstances ...'
4. use a script wrapper for GHC
#!/bin/sh
exec ghc -XTemplateHaskell -XFlexibleInstances ... $*
I'm sure there are more...
Cheers,
Simon
-Alex-
Simon Marlow wrote:
Alex Jacobson wrote:
I'm fine with that as well. I'm just opposed to being force to look
up the precise names the compiler happens to use for each language
extension I happen to use. Having -fglasgow-exts turned on by
default also works.
-fglasgow-exts is a historical relic. It's just an arbitrary
collection of extensions. It doesn't contain all the extensions
provided by GHC, as many of them steal syntax and you probably don't
want them all on at the same time. We're trying to move away from
-fglasgow-exts, which is why GHC 6.8.1 provides separate flags for all
the extensions we provide. Eventually we'll have a new standard
(Haskell' or whatever) that will collect many of the extensions
together, so you'll just have to write {-# LANGUAGE Haskell' #-}.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: suggestion: add a .ehs file type
Right now I have it automatically add -glasgow-exts unless the user explicitly turns it off. I prefer to have packages that are also cabal compatible If there is a way to get cabal also to preprocess .ehs correctly then we are good to go! -Alex- Robin Bate Boerop wrote: Alex, Lennart's suggestion makes me think: Why not make SearchPath into a preprocessor? It could recognize a .ehs extension, and then do some very simple preprocessing (adds pragmas according to user's settings). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.8.2
Ian Lynagh wrote: = The (Interactive) Glasgow Haskell Compiler -- version 6.8.2 = The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.1, including some significant performance fixes, so we recommend upgrading. A binary distribution for Mac OS X 10.5 (Leopard) is available from http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2 To use this binary distribution, you need to have readline from MacPorts installed. Manuel PS: This time around, there should be no dependency on MacPorts' gmp, but this is hard for me to test locally. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
