Re: [Haskell] Re: ANNOUNCE: GHC version 6.8.2
My experience with the mac stuff is that you are just better off building everything yourself. It runs in the background while you go eat dinner and then you are done. -Alex- Hugo Pacheco wrote: The binaries do work in Leopard, but it misses all library files, such as System.IO. How can I build them form the sources? I have no cabal-install as well. and the macports 6.6 is broken. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: GHC version 6.8.2
Will this also work with Tiger or do I have to upgrade? -Alex- Manuel M T Chakravarty wrote: 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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] recursive deriving
When you want automated deriving of show/read etc., you need all the components of your type also to be instances of show/read but you won't want to *require* them to be automatically generated verions. Standalone deriving does the wrong thing here. Standalone deriving should not cause an overlapping instance error if someone derives an instance manually. Instead, the manually derived instance should be treated as more specific and win out. The other part of this problem is that you can't do automatic recursive deriving and this results in a ridiculous amount of boilerplate. I know some people have a theory that they want to avoid accidentally creating instances for things that shouldn't have them, but the solution to that is probably to add some declaration for types that prohibits automatic deriving for those types. The 99% case is that automatic deriving is ok. Proposed syntax: derive instance Show T recursively data T = T no-deriving (Ord,Eq) -Alex- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] boilerplate boilerplate
Actually independent deriving would help a lot but am not sure of the syntax. could it be something like derive (Ord,Eq,Read,Show,Typeable) (BlogEntry Name Title Body Emai) Perhaps this is what Neil Mitchell was suggesting with Derive that I was not understanding. If I can use derive like this without a pre-processor that would be very nice. -Alex- Claus Reinke wrote: (For your second, desired code sample, I have a feeling this is where DrIFT or Data.Derive are going to come in... I'm not going to mention those external things!) it wouldn't help to get rid of deriving, but perhaps the new 'standalone deriving' might help to separate out all that deriving stuff, keeping the data type definitions themselves less cluttered? http://hackage.haskell.org/trac/ghc/wiki/Status/October06 claus ps why the odd mailing list address? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] boilerplate boilerplate
I'm not sure I understand how this solves my problem. Its possible that
I can use Derive not to need all the newtype declarations at all, but,
if I do need them, I'm not sure how Derive reduces the overall amount of
boilerplate here.
Perhaps I should define a TH function that takes
$(newtype' Name String)
And converts it to a
newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable)
-Alex-
Neil Mitchell wrote:
Hi
{-# OPTIONS -fglasgow-exts #-}
module Blog.Types where
import Data.Typeable
import Data.Generics
data BlogEntry = Entry EpochSeconds Name Email Title Body
deriving (Eq,Ord,Read,Show,Typeable)
newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable)
newtype Title = Title String deriving (Eq,Ord,Read,Show,Typeable)
newtype Body = Body String deriving (Eq,Ord,Read,Show,Typeable)
First off, never use OPTIONS, use OPTIONS_GHC instead. OPTIONS is the
old way of doing it.
Secondly, if you add {-# OPTIONS_DERIVE
--derive=Eq,Ord,Read,Show,Typeable #-} then running your code through
with Derive should give you the magic that you require. Plus it will
also work on Hugs, and not require your OPTIONS_GHC anyway.
Derive: http://www-users.cs.york.ac.uk/~ndm/derive/
Thanks
Neil
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] boilerplate boilerplate
Consider this module for a blog entry that I will want to put in various
generic collections that require Ord
{-# OPTIONS -fglasgow-exts #-}
module Blog.Types where
import Data.Typeable
import Data.Generics
data BlogEntry = Entry EpochSeconds Name Email Title Body
deriving (Eq,Ord,Read,Show,Typeable)
newtype Name = Name String deriving (Eq,Ord,Read,Show,Typeable)
newtype Title = Title String deriving (Eq,Ord,Read,Show,Typeable)
newtype Body = Body String deriving (Eq,Ord,Read,Show,Typeable)
It seems really unnecessarily verbose. Having to add the OPTION header
AND import Data.Typeable and Data.Generics just to derive Typeable is a
beat-down. It is even more of a beat-down to have to add a deriving
clause for every newtype to make this all work nicely. Is there a way
to make all types automatically derive everything unless there is an
explicit instance declaration otherwise?
{-# OPTIONS -fglasgow-exts -fgenerics -fderiving#-}
module Blog.Types where
data BlogEntry = Entry EpochSeconds Name Email Title Body
newtype Name = Name String
newtype Title = Title String
newtype Body = Body String
Isn't that much nicer?
-Alex-
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
