- Glasgow-haskell-users

RE: using the Intel compiler (icc)
by Simon Marlow 05 Jun '05

05 Jun '05

There's a command line switch to change the C compiler: -pgmc icc. But I doubt whether you could use icc as the back-end for GHC without quite a lot of work, because the mangler is quite picky. Linking object files created by icc into a ghc-compiled program should work fine, though. Automatic vectorisation of loops won't help GHC (the code we generate doesn't have any loops). Cheers, Simon On 05 June 2005 19:17, Keean Schupke wrote: > Yes, thats exactly what I mean. Can I switch the compiler to use with > a command line switch? ICC is compatible with GCC and can use the same > libraries. The main advantage is the automatic vectorisation of loops, > to use SSE / MMX. > > Keean. > > Seth Kurtzberg wrote: > >> Keean Schupke wrote: >> >>> Is it possible to get GCC to use the intel C compiler (ICC) instead >>> of gcc? >>> >>> >> Do you mean is it possible to get /GHC/ to use /ICC/? Otherwise I >> don't understand the question. > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Set, Map libraries
by Serge D. Mechveliani 05 Jun '05

05 Jun '05

Dear GHC team, I am looking into the .html docs on the libraries of Map and Set. Here follow the questions and notices. 1. elems :: Set a -> [a] setToList :: Set a -> [a] These two look like synonyms, but have different comments. Am I missing something? 2. size :: Set a -> Int -- O(1) ... And for large sets, the user needs to program genericSize :: Set a -> Integer genericSize = genericLength . Data.Set.elems ? Is this possible to make it O(1) too? 3. Data.Map has lookup and findWithDefault. According to name correspondence, a natural name for the latter would be lookupWithDefault - ? 4. Data.Set.intersection. In old library, it was `intersect' -- if I recall correct. So, it is natural to include `intersect' to the `Obsolete' list. 5. Name resolution. ./Prelude0.hs:254:28: Ambiguous occurrence `null' It could refer to either `Data.Set.null', imported from Data.Set at ./Prelude0.hs:50:48-51 or `GHC.List.null', imported from Prelude at ./Prelude0 Could the compiler detect where null applies to list and where to Set ? For this is visible from the types in the user program. 6. My module applies Data.Set.null (s :: Set a), and null (xs :: [a]). Why ghc reports of the clash with GHC.List.null ? Is GHC.List same as old List library module? Should I write import GHC.List (genericLength, null) instead of import List (genericLength) ? With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

11 14

recompilation check in 6.4
by Serge D. Mechveliani 05 Jun '05

05 Jun '05

People, who knows, please, how to fix re-compilation in ghc-6.4 ? Porting my program dm from 6.2.2 to 6.4, I see that the 6.4 system re-compiles many modules when re-processing the Makefile to build dm. For example, let Foo.hs from dm contain an error "value v not in scope". Running make dm for the first time compiles all the modules before Foo in 50 seconds. Then, I fix an error in Foo.hs and repeat "make dm". The options are set so that ghc-6.2.2 gets to Foo.hs in less than 1 second when doing this repeated `make'. It does consider each module before Foo and each time decides that there is no need in recompilation. It keeps on going this way: -------- Considering whether compilation is required for Prelude0: Skipping Prelude0 ( ./Prelude0.hs, /foo/source/export/Prelude0.o ) -------- and so on, by the scheme "Considering ..XX -- {Checking usages .. --} Skipping XX". The compiler applies this way: -------------------- /foo/ghc/6.2.2/inst/bin/ghc -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances -fno-warn-overlapping-patterns -fwarn-unused-binds -fwarn-unused-matches -fwarn-unused-imports -idemotest -odir /home/mechvel/dm/1.02/dm/source/export -hidir /home/mechvel/dm/1.02/dm/source/export -ddump-hi-diffs --make DExport -package-name dm -------------------- Now, when ghc-6.4 does such a repeated `make', it re-compiles all the `previous' modules under the above options: --------- Chasing modules from: DExport Source file changed or recompilation check turned off Compiling Prelude0 ( ./Prelude0.hs, /.../source/export/Prelude0.o ) Interface file unchanged ... --------- (And when setting to Foo a _syntax_ error, 6.4 finds this error without compiling `previous' modules). Something has changed in 6.4, maybe, the default for the recompilation check, I do not know. 6.2.2 did what was intended in Makefile. Who knows, please, how to fix this recompilation point in 6.4 ? Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

docs on Set, Map
by Serge D. Mechveliani 04 Jun '05

04 Jun '05

Dear GHC developers, ghc-6.4 documentation specifies about Map.insertWith " insertWith :: Ord k => (a -> a -> a) -> k -> a -> Map k a -> Map k a O(log n). Insert with a combining function. " This description is not sufficient. For example, in insertWith (\ a1 a2 -> a1) k a3 mp the doc does not tell what value overrides on the key overlap, a3 or the one in mp. The usage of the GHC library for Set and Map will become much easier if you fix this documentation point on all updating functions for Set and Map which use a combining function. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Set & Int
by Serge D. Mechveliani 04 Jun '05

04 Jun '05

Date: Thu, 02 Jun 2005 10:29:03 -0400 People discussed the Map implementation in GHC: data Set a = Tip | Bin {-# UNPACK #-} !Size a !(Set a) !(Set a) type Size = Int ... I do not think that these strict fields can do a real harm, because they effect only a single level of data construction. And even if it was a strict language, operating with large sets would be all right. Still, I would prefer to remove `!' and UNPACK, in order to preserve a pure language. But what I really do not understand is: why not `Integer'? What difficulties may cause the design with size :: Set a -> Natural type Natural = Integer What will be the difference? With each insert envokation, recomputing size costs O(log n), the next call for size costs O(1). Right? Everything looks like for `Int' -- except that `Int' is a bug. "v :: Int" is a bug, if v can occur large. For example, we could imagine (there may appear, there may exist) a machine capable to process in a real time the number of cells much greater than maximal_Int. This depends on hardware architecture specifics. For such sets sS, size sS :: Int returns incorrect result. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Map, Set libraries
by Serge D. Mechveliani 03 Jun '05

03 Jun '05

Thanks to people for the explanations. To my question >> 1. elems :: Set a -> [a] >> setToList :: Set a -> [a] >> >> These two look like synonyms, but have different comments. >> Am I missing something? Jens Fisseler <jens.fisseler(a)fernuni-hagen.de> writes on 2 Jun 2005 > Both functions compute the same list, and IMHO the comments state the > same. I meant the description in the ghc-6.4 documentation. Data.Set.html says " elems :: Set a -> [a] O(n). The elements of a set. setToList :: Set a -> [a] O(n). Convert the set to a list elements. " What is the difference? If they are really equivalent, then, it is natural either to remove `elems' or to follow the general GHC policy and to move setToList to the `Obsolete' list section in documentation, like it was done with many other functions for Set and FiniteMap. - ? ----------------- Serge Mechveliani mechvel(a)botik.ru

5 7

addListToFM
by Serge D. Mechveliani 03 Jun '05

03 Jun '05

I used to apply FiniteMap.addListToFM. Now, what is its best expression in ghc-6.4 ? Is this \ mp pairs -> Map.union (Map.fromList pairs) mp ? (the order of the arguments in Map.union is essential). Thank you in advance for explanation. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

Map, Set
by Serge D. Mechveliani 03 Jun '05

03 Jun '05

On 2 Jun 2005 S. Alexander Jacobson <alex(a)alexjacobson.com> writes > Any reason the libaries don't define: > > class HasNull a where null::a->Bool > class HasEmpty a where empty::a > > I find that I sometimes switch between using lists, sets, or tables as > my collection type and the forced import qualifification for generic > collection operations seems annoying. Probably, it would be natural for the Map and Set GHC libraries to introduce some version of class SetLike where ... My programs also switch with similar operations between sets and various tables. To unify the interface, I defined the following: ------------------------------------------------------------------- class Cardinality a where card :: a -> Natural -- (Integer) instance Cardinality (Set.Set a) where card = genericLength . Set.elems instance Cardinality (Map.Map k a) where card = genericLength . Map.keys class Cardinality a => SetLike a where sEmpty :: a sIsEmpty :: a -> Bool sUnion :: [a] -> a sMinus :: a -> a -> a sIntersect :: [a] -> a sConcat :: [a] -> a sNub :: a -> a instance Ord a => SetLike (Set.Set a) where sEmpty = Set.empty sIsEmpty = Set.null sUnion = Set.unions sMinus = Set.difference sNub = id sConcat = sUnion sIntersect [] = error "sIntersect []\n" sIntersect (s:ss) = foldl Set.intersection s ss sIncluded :: SetLike a => a -> a -> Bool sIncluded s = sIsEmpty . sMinus s instance SetLike IdList where ... ------------------------------------------------------------------- This was as under ghc-6.2.2, and now it is edited to meet 6.4. About what Set and Map libraries could provide ---------------------------------------------- The candidates may be `any', `all' analogues for Set, Map (anyway, they are simply expressed by composing with toList). direct product of sets (can be simply expressed by composing with toList, fromList). composition of maps, inverse map. On standard ----------- It is very desirable to put the Map and Set libraries to future standard Haskell library. With this, our struggle with their interface changes will end. I wonder how the Haskell language and library are going on, whether Haskell-2 is coming. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

[ ghc-Feature Requests-1212959 ] Reading source files in encodings other than Latin-1
by SourceForge.net 03 Jun '05

03 Jun '05

Feature Requests item #1212959, was opened at 2005-06-01 18:53 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1212959&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: Reading source files in encodings other than Latin-1 Initial Comment: For GHC 6.4 on SuSE Linux 9.2 (installed from the GHC RPM). When including SOME non-ascii characters in character or string literals, in the source code, I get a "lexical error in string/character literal" error message. Examples are some french accents and german umlauts - é,Ü,Ä. However, with other characters from the same set (like üä) there is no problem, they are processed correctly I checked with Hugs and there were no problems, so it seems to be a GHC bug. For further questions send email to: Rainer Volz, mail at vrtprj.com ---------------------------------------------------------------------- >Comment By: Simon Marlow (simonmar) Date: 2005-06-03 08:29 Message: Logged In: YES user_id=48280 I don't know about wxHaskell, it's possible that it is using your system's default encoding. Thanks for the report anyway. I'll re-brand it as a feature request. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-06-02 16:24 Message: Logged In: NO Ah ok, I read so much about Haskell and Unicode that I didn't think about that. My system uses UTF-8 as standard encoding, so Emacs saves the source file also in that encoding. Using ISO-8859-1 as encoding to save the file helps with the lexical error. However the strings are still not displayed correctly. I tried it with texts in wxhaskell windows and with simple putStr "Üo" scripts. Do I have to change my system's encoding to IOS8859-1 to get proper results? ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-06-02 08:32 Message: Logged In: YES user_id=48280 It works fine for me. What encoding are you using? GHC only understands the Latin-1 (ISO8859-1) encoding for source files. If you are using Latin-1, then please attach a source file that we can test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1212959&group_…

1 0

doc on Map.insert
by Serge D. Mechveliani 02 Jun '05

02 Jun '05

The ghc-6.4 documentation says about Data.Map " insert :: Ord k => k -> a -> Map k a -> Map k a O(log n). Insert a new key and value in the map. " If this is to replace old addToFM, then it is better to remove the word "new". Right? ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0