Re: How to make Data.Set.Set a Functor
Lajos Nagy [EMAIL PROTECTED] writes: On the other hand, it seems intuitively natural to make Set an instance of fmap. Indeed. While I generally like the overloaded, qualified names, I find it annoying when, like 'map', they clash with Prelude imports. Which means that, in a module using Data.Set, I must either use it all qualified, or import it twice (qualified and hiding map), or explicitly import Prelude hiding map. (Better solutions wanted!) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: How to make Data.Set.Set a Functor
On 11 October 2005 17:16, Lajos Nagy wrote: While working on a toy compiler I realized that Data.Set.Set (Set) is not an instance of the Functor class. In other words: 'fmap' is not defined on it. I tried various ways of defining an instance but I failed. The reason is quite interesting: Set is a type constructor (* - *) so it should qualify it for being a Functor. (In a sense it is very similar to a Map or a list.) However, most Set functions require the elements of the Set to be an instance of Ord. The problem is that this constraint cannot be deduced from the instance declaration for Functor: instance Functor Data.Set.Set where fmap f s = Data.Set.map f s A nice way to do this would be: data FSet a where FSet :: Ord a = Set a - FSet a instance Functor FSet where ... if only GADTs worked with type classes :-) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use Data.Set.Set
Ketil Malde wrote: Indeed. While I generally like the overloaded, qualified names, I find it annoying when, like 'map', they clash with Prelude imports. Which means that, in a module using Data.Set, I must either use it all qualified, or import it twice (qualified and hiding map), or explicitly import Prelude hiding map. (Better solutions wanted!) I think, you should import qualified Data.Set as Set only and use Set.map rather than the deprecated mapSet (most other names from Data.Set make more sense with the Set. prefix) Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use Data.Set.Set
Christian Maeder [EMAIL PROTECTED] writes: I think, you should import qualified Data.Set as Set only and use Set.map rather than the deprecated mapSet (most other names from Data.Set make more sense with the Set. prefix) I can do this of course, but I think it would be nice to be able to use it unqualified in modules that only uses Sets (and doesn't use e.g. Maps or List.(null|map)). If I always have to qualify it, what is the advantage of Set.map instead of mapSet? (Oh, right, I can import qualified List as Set -- but then I still have to change member to elem etc etc.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use Data.Set.Set
Ketil Malde wrote: the advantage of Set.map instead of mapSet? Well, you know that the unqualified name is map, i.e. also for Data.Map it's not mapMap or mapFM but YourChoice.map. (Oh, right, I can import qualified List as Set -- but then I still have to change member to elem etc etc.) I think, that was discussed when including Data.Set and Data.Map (but only isEmpty became null). Replacing the import of Set by List does not work well, but Data.Set could be easily replaced by a different Set implementation with the same (or a similar enough) interface. Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC-6.4.1 on FreeBSD-amd64 still not ported
Simon Marlow [EMAIL PROTECTED] schrieb: On 25 September 2005 18:54, Wilhelm B. Kloke wrote: bash-2.05b$ (cd ghc/rts; gmake PrimOps.o ) ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c PrimOps.cmm -o PrimOps.o In file included from PrimOps.cmm:28: /home/wb/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/includes/Cmm.h:288:2: #error mp_limb_t != StgWord: assumptions in PrimOps.cmm are now false gmake: *** [PrimOps.o] Fehler 1 Similar messages for attemps to make other of the failing .hc files. Perhaps crossporting from a 64bit system is easier. I presume that once a working ghc is available, life is much easier, as Fedora Linux-64 does not report problems. GHC is correctly generating the .hc file from the .cmm file, and then attempting to compile the .hc file using gcc. This latter step fails, as expected, because the .hc code is intended to be compiled on the target system. We just need to get those .hc files and take them to the target. Just doing 'make -k' in ghc/rts should leave all the .hc files behind, because you already have the -keep-hc-files flag in your command line, so GHC won't delete the intermediate .hc files even when the subsequent compilation stage fails. This doesn't work. The commands don't leve a .hc file behind, even with make -k. I ieven tried using the command line alonei for Appy.hc. This did not work either. The I commented out the #error in line 288 of Cmm.h. After this I got the following error: ~/Haskell/fptools-i386amd64/ghc-6.4.1/ghc/rts 0$ ../../ghc/compiler/ghc-inplace -H16m -O -H32m -keep-hc-files -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint-O -fvia-C -keep-hc-files -c Apply.cmm -o Apply.o Cmm lint error: in proc stg_ap_0_ret in basic block c2 in assignment: R1 = I32[R1 + 8 + 0]; Compilation had errors so it looks as if there is a more severe problem remaining. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
