RE: Package with no dependencies causes GHC to mislay standard prelude
Unpacking the attached bundle and running the following with ghc=GHC6.2 (Linux, compiled from the ghc-6.2 tag), produces the following: # cd packagesbug /home/ger/test/packagesbug # CompileBug /home/ger/test/packagesbug/package1 Chasing modules from: CompileFlags.hs Compiling CompileFlags ( CompileFlags.hs, CompileFlags.o ) Reading package info from stdin... done. Expanding embedded variables... done. building GHCi library `/home/ger/test/packagesbug/package1/package1.o'... done. Saving old package config file... done. Writing new package config file... done. Chasing modules from: UseCompileFlags.hs Compiling UseCompileFlags ( UseCompileFlags.hs, UseCompileFlags.o ) /home/ger/test/packagesbug/package1/package1.o: unknown symbol `__stginit_Prelude_' Loading package package1 ... linking ... ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): can't load package `package1' The package is missing a dependency on 'base', and possibly other things. I don't see a bug - unless you're complaining about the error message (quite reasonable). Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
config.h namespace clashes
The inclusion of the GHC made config.h in HsFFI.h makes it extremely difficult to use autoconf with ones own projects without dealing with horrible name clashes everywhere. Is there some way this can be fixed? perhaps pre-generating the HsFFI.h. although I don't think it is stated explicitly by the FFI report, I would assume that HsFFI.h should not clash with anything that doesn't start with Hs, hs_ or HS_. also, it would be good if config.h could be renamed to something like ghc-config.h, because otherwise the conflict between the names can hide bugs where you get the incorrect config.h or make it tricky to get at the GHC one if it is actually the one you want. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Happy Question
My hand-written S-expression parser for HScheme is very very slow. Really quite a bit slower than it ought to be. So I'd like to switch to Happy instead. The problem is my parser should be monadic, but the monad type is generalised (basically of the form (context m) = m). Is there a way of switching on monadic-ness, so I can have a monadic happyError, but without giving type signatures to happyThen and happyReturn? Or else allowing a class context for the type signatures? -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Generics... no Tuples 2 either...
Tuples and Double are there in the HEAD build now -- but we're still thinking about how best to treat Ptr, which is essentially un-marshalable. | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of MR K P SCHUPKE | Sent: 26 February 2004 18:33 | To: [EMAIL PROTECTED] | Subject: Generics... no Tuples 2 either... | | | Any chance of Data instances for tuples of size | greater than 2... One of the nice things about generics is | you can use them by deriving Data on your datatypes - of | course this doesn't work if you all of a sudden have to | put a load of boiler-plate in just to use tuples... | | Regards, | Keean Schupke | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: config.h namespace clashes
The inclusion of the GHC made config.h in HsFFI.h makes it extremely difficult to use autoconf with ones own projects without dealing with horrible name clashes everywhere. Is there some way this can be fixed? perhaps pre-generating the HsFFI.h. although I don't think it is stated explicitly by the FFI report, I would assume that HsFFI.h should not clash with anything that doesn't start with Hs, hs_ or HS_. also, it would be good if config.h could be renamed to something like ghc-config.h, because otherwise the conflict between the names can hide bugs where you get the incorrect config.h or make it tricky to get at the GHC one if it is actually the one you want. Yes, we should definitely do that. I'm surprised this hasn't caused problems before (or maybe it has?). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: config.h namespace clashes
On Mon, Mar 01, 2004 at 11:55:05AM -, Simon Marlow wrote: Yes, we should definitely do that. I'm surprised this hasn't caused problems before (or maybe it has?). The reasons it has not been as much of an issue before are twofold as far as I can tell, 1. cpp only complains if you #define something to a different value than it was previously defined. chances are any autoconf tests will succeed similarly during the building of ghc and later. 2. autoconf only recently started #defining PACKAGE, VERSION, BUGREPORT and friends, which will almost definatly be different. so, they probably were conflicting a lot before, but the symtoms were hidden. At least that was what I determined from my post-mortem when figuring out why the compiler started horking on -Werrors with ghc 6.2. John -- --- John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED] --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: performance tuning Data.FiniteMap
Hello!
If indeed the read performance is at premium and updates are
infrequent, by bother with ternary etc. trees -- why not to use just a
single, one-level array. Given a reasonable hash function, the
retrieval performance is O(1). And still, no IO/ST are necessary.
{-# OPTIONS -fglasgow-exts #-}
module Foo where
import Data.Array
import Data.List
import Data.HashTable (hashString)
import Data.Int (Int32)
class Hashy a where
hash:: a - Int
data MyFM key val = MyFM { base:: Int
, purgatory:: [(key,val)]
, store:: Array Int [(key,val)]
} deriving Show
empty = MyFM {base = 41, purgatory = [],
store = listArray (0,base(empty)-1) $ repeat []}
lkup fm key = case lookup key (purgatory fm) of
t@(Just _) - t
_ - lookup key item
where item = (store fm)! hashv
hashv = (hash key) `mod` (base fm)
count = length . concat . elems . store
purgatory_limit = 10
ins fm key val
= rebuild_perhaps $ fm {purgatory = add_uniq (purgatory fm) key val}
where
rebuild_perhaps fm | length (purgatory fm) purgatory_limit
= rebuild fm
rebuild_perhaps fm = fm
rebuild fm | 2*(count fm) base fm = major_rebuild fm
rebuild fm = fm{purgatory = [], store = (store fm) // updates}
where
updates = map (retr . merge) $ groupBy gfirs $
sortBy sfirs $ map (\p@(k,v) - (hashk k,p)) $ purgatory fm
hashk k = (hash k) `mod` (base fm)
gfirs (k1,_) (k2,_) = k1 == k2
sfirs (k1,_) (k2,_) = compare k1 k2
merge x = (fst$ head x, map snd x)
retr (h,v) = (h, unionBy gfirs v ((store fm)!h))
-- reallocate the hash table to the bigger size
major_rebuild fm = undefined -- exercise for the reader
-- add association (key,val) to the list, replacing an old association
-- with the same key, if any. At most one such association could have
-- existed
add_uniq [] key val = [(key,val)]
add_uniq ((hkey,_):t) key val | hkey == key = (key,val):t
add_uniq (h:t) key val = h: add_uniq t key val
instance Hashy String where
hash = fromInteger . toInteger . hashString
test1 = foldl (\fm v - ins fm v v) empty $ map (:[]) ['a'..'h']
test2 = foldl (\fm v - ins fm v v) test1 $ map (:[]) ['a'..'o']
test3 = foldl (\fm v - ins fm v v) test2 $ map (:[]) ['a'..'o']
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
Simon Peyton-Jones wrote:
In Haskell today, you can at least tell what value is bound to each
identifier in the program, *without* first doing type checking.
I'm afraid I'm confused. In the following code
data Z
data S a
class Card c where c2int:: c - Int
instance Card Z where c2int _ = 0
instance (Card c) = Card (S c) where c2int _ = 1 + c2int (undefined::c)
foo = c2int (undefined::(S (S (S (S Z)
how can one tell the value of foo without first doing the
typechecking? Without typechecking, we can't use c2int and can't even
construct any meaningful value of class Card. For c2int, the type is
the ``value.'' Overlapping instances, polymorphic recursion -- all
seem to make the value determination even more uncertain.
Andre Pang wrote:
1) now I have to manually declare a class definition for every single
function, and I have to declare it in advance before any module defines
that function (most serious problem; see below),
However, declaring the instance first requires declaring the type
class itself, and that _is_ a problem, because that's exactly what I'm
trying to work around. Without 20/20 hindsight, you cannot say with
certainty what type signatures a generic function (like 'phase' or
even 'add') can support, because it's not a generic function,
But in the solution posted previously, for each ad hoc overloadable
function, the corresponding class *always* has the same
signature:
class HasAdd a b | a-b where add:: a-b
Therefore, we don't need clairvoyance to define an overloadable
function that way. If I need an overloadable function add, I can go
ahead and define the above class, and then add an instance. I can do
that without knowing all possible overloadable instances of add,
present or future. What if somebody else did the same in some other
module? If that somebody else followed the conventions, he would
introduce exactly the same class declaration. If GHC or its developers
could somehow be persuaded to overlook _exact_ duplicate class
declarations, then that part of the problem can be solved. The class
declaration itself could perhaps be generated by Template Haskell.
The discussed solution is quite related to some of the Records
proposals (which have been discussed here half a year ago). There too
we have the inconvenience of choosing unique names for field labels.
data Person = Person {_pname:: String, _paddress:: String}
data Computer = Computer {_cname::[String], _caddress:: Int}
class HasName a b | a-b where name:: a-b
class HasAddress a b | a-b where address:: a-b
instance HasName Person String where name = _pname
instance HasAddress Person String where address = _paddress
instance HasName Computer [String] where name = _cname
instance (HasName n r) = HasName (Maybe n) (Maybe r) where
name = fmap name
-- Alas, the following will break the dependency...
--instance (Num a) = HasName a String where name = show
-- But the following works: overlapping instances at work
instance (HasAddress a b) = HasName a b where name = address
instance HasAddress Int (Int-String) where address x y = show (x+y)
newtype W a = W a
instance (Num a) = HasAddress (W a) String where address (W a) = show a
test2 = let p = Person Anonymous N/A
c = Computer [FQDN,localhost] 10
in person named ++ (name p) ++ at a computer ++ (head (name c))
++ and another ++ (show$ name p1)
where p1 = (Nothing::Maybe Person)
The first few lines of the code is boilerplate and could be
automatically generated. As you can see, we can even handle a limited
form of polymorphism, and even do a hand off. For example, if some
thing doesn't have a name but has an address, we can use the address
as its name. Alas this ``backtracking'' isn't as general as we might
wish. At some point we have to introduce wrappers (like W a above) to
hand over the dispatch to another class. It's possible to do the
dispatch on a class, but it's a bit too painful. OTH, the wrappers
such as 'W' may be considered as an 'alternative view' of an object.
By wrapping an object, we can switch its behavior from the main one to
an alternative without any run-time penalty.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Per-type function namespaces (was: Data.Set whishes)
| In Haskell today, you can at least tell what value is bound to each | identifier in the program, *without* first doing type checking. | | I'm afraid I'm confused. In the following code | | data Z | data S a | | class Card c where c2int:: c - Int | | instance Card Z where c2int _ = 0 | instance (Card c) = Card (S c) where c2int _ = 1 + c2int (undefined::c) | | foo = c2int (undefined::(S (S (S (S Z) | | how can one tell the value of foo without first doing the | typechecking? What I meant was that you can always tell what executable code a value is bound to, without type checking. 'foo' is bound to the code for 'c2int (undefined::(S (S (S (S Z)'. 'c2int' is bound to code that extracts a method from it's first argument (which is a dictionary for Card). In any higher-order language, a function might invoke one of its arguments f x g = g x but I still say that it's clear what code is executed when f is called! It's true that with type classes the value of one of the dictionary argument is dependent on type checking, which certainly muddies the waters. But at least the type of 'c2int' isn't affected by which method is chosen, which is the real difficulty I was pointing out Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Incremental Array update (Re: performance tuning Data.FiniteMap)
Hi, Reading the recent discussions abount Array and FiniteMap, I want to know what people think about the current specification of the Array update. The Array implementaton of GHC effectively has this property (like FiniteMap): (arr // cs1) // cs2 == arr // (cs1 ++ cs2) -- allow duplicate indices Because (//) copies a whole array and slow, instead of the successive updates, I usually accumulate those changes to a list as many as I can in advance, and then give it to (//). As far as GHC is concerned, all we have to do is to concatenate the list of changes by (++) thanks to the propety. It generally results in a huge performance inprovement. However, Haskell Report reads (16.2): (As with the array function, the indices in the association list must be unique for the updated elements to be defined.) So, we must somehow (as oleg's add_uniq[1]) remove the preceding elements having the same index from the list to make the program comply Haskell 98 and support Hugs since Hugs does implement that check. The preconditioning (and also the check performed by the runtime system) causes no small amount of performance hit. I think it would be better if the above property of incremental updates of Array is guaranteed sometime hopefully in Haskell 2. Note: 0) Array give us O(1) read. 1) FiniteMap has the same property. 2) Array is more convenient than monadic arrays, e.g. STArray. 3) Array is faster than ST(U)Array in my experience, if the size of the array is no more than about 100 (when the updates can be combined). 4) The runtime optimization which converts (arr // cs1) // cs2 to arr // (cs1 ++ cs2) might be possible? [1] http://www.haskell.org//pipermail/haskell/2004-February/013724.html --- Koji Nakahara ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] System.Random
Hello, why is the Random module situated under System? Wouldn't something like Data be more adequate? Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: performance tuning Data.FiniteMap
On Fri, 27 Feb 2004 [EMAIL PROTECTED] wrote: If indeed the read performance is at premium and updates are infrequent, by bother with ternary etc. trees -- why not to use just a single, one-level array. Given a reasonable hash function Because updates are not so infrequent that I want to pay the cost of replicating the entire array every update (or every ten!). I'm willing to exchange *some* read time for faster update. Also, because small array copies may be sufficiently faster than tree traversals that I may pay very little extra for faster reads. FYI, my current code looks like this: type HTArray base elt = Array base (HT base elt) data HT base elt = HT (Maybe (HTArray base elt)) (Maybe elt) data MyMap base key elt = ArrMap (HTArray base elt) (key-[base]) (HT base elt) newMap minBase maxBase toBase = ArrMap proto toBase emptyHT where proto= array (minBase,maxBase) [(x,emptyHT) | x- [minBase..maxBase]] emptyHT=HT Nothing Nothing lookup (ArrMap _ toBase ht) key = lookup' ht $ toBase key lookup' (HT x y) [] = y lookup' (HT Nothing _) _ = Nothing lookup' (HT (Just ar) _) (k:ey) = lookup' (ar!k) ey insert (ArrMap proto toBase ht) key elt = ArrMap proto toBase newHT where newHT= insert' proto ht (toBase key) elt insert' _ (HT x _) [] = HT x insert' proto (HT Nothing y) key = insert' proto (HT (Just proto) y) key insert' p (HT (Just ar) y) (k:ey) = \val - HT (Just $ newArray val) y where newArray val = ar//[(k,insert' p (ar!k) ey val)] - testMap=newMap (chr 0) (chr 255) id main = do print $ lookup (insert testMap abc (Just def)) abc Make the difference between in minBase and maxBase larger in the call to newMap to prefer reads more. Note: This format seems awkward. I feel like I want to have the user to define an enumeration type e.g. data UpToFive = One | Two | Three | Four | Five instance Ix UpToFive where and have newMap::(Bounded base,Ix base)=(key-[base]) - MyMap base key elt But I can't figure out a nice way to auto-generate arbitrary size enumerations and manually doing so is too wearisome to contemplate. If you can generate these enumeration classes, then it would seem you could auto-derive functions that translate from an arbitrary key into [base]. -Alex- _ S. Alexander Jacobson mailto:[EMAIL PROTECTED] tel:917-770-6565 http://alexjacobson.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announce: buddha version 1.1
Announcing buddha version 1.1 - www.cs.mu.oz.au/~bjpop/buddha New in this release: - support for GHC 6.2 - better user interface - many bug fixes -- A declarative debugger for Haskell 98. It is based on program transformation and works with GHC 5.x and 6.x. buddha offers a declarative debugging algorithm and a browsing mechanism. It is useful for finding logical errors in programs and for exploring computations in a high-level manner. Version 1.1 is known to work on GNU/linux (x86). It _ought_ to work on any unix-like system including Mac OS X, and freeBSD. It does not work on Windows (as far as I know). buddha is released under the GPL license. Enjoy! Bernie. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ITCC 2004, April 5 -7 2004 - Call For Participation, Las Vegas, USA
My apologies if this is a duplicate email. CALL FOR PARTICIPATION - ITCC 2004 http://www.itcc.info International Conference on Information Technology- ITCC 2004 is going to be held in Las vegas, NV USA.ITCC is an international forum which brings together researchers and practitioners working on different aspects of Information Technology. It is a technical congregation where the latest theoretical and technological advances on Information Technology are presented and discussed. This year's conference will bring together the world's most respected authorities on Information Retrieval, Operating Systems, Networks,Image/Video Processing, Digital Library, Coding Data Compression,Watermarking, Simulation, Computer Graphics, Information Technology: Education, Curriculum Accreditation, Information/Website Security, Data Mining and plethora of IT related technologies.(Pls check the advanced Program at our website). Whether you are a speaker, tutorial presenter, and/or sponsor, you will find ITCC 2004 as the best forum to share and demonstrate your knowledge with the depth and breadth of Information Technology.For registration details,Visit our Website http://www.itcc.info/ Any questions/Comments may be forwarded to [EMAIL PROTECTED] We look forward to your participation and hope to see you in Las Vegas! If you do not wish to be included in this list, and/or do not wish to receive further announcements regarding ITCC, please reply at [EMAIL PROTECTED] Your email address will be removed immediately from the distribution list. With Best Regards Vasu Jolly The ITCC 2004 Conference Secretary ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
