Hello again,
first of all, I'm not sure whether this is actually a bug-report
or a feature-request.
The three line summary is that in the following program, no
specialized version for ST s is created by at least 6.2.1,
6.4.20050304, and 6.4.20050308.
{-# OPTIONS -fno-implicit-prelude #-}
module MHashTable () where
import GHC.Base ( RealWorld, Monad, return )
import GHC.IOBase ( IO )
import Control.Monad.ST ( ST )
{-# SPECIALIZE bucketIndex :: ST s () #-}
{-# SPECIALIZE bucketIndex :: IO () #-}
bucketIndex :: Monad m = m ()
bucketIndex = return ()
Practically any other specialization, including Maybe, [] and ST RealWorld
_are_ actually performed.
What GHC has to say about it:
% /var/tmp/ghc/bin/ghc -O --make -ddump-rules MHashTable.hs
Chasing modules from: MHashTable.hs
Compiling MHashTable ( MHashTable.hs, MHashTable.o )
Top-level specialisations
SPEC MHashTable.bucketIndex __forall {$dMonad :: {GHC.Base.Monad
GHC.IOBase.IO}}
MHashTable.bucketIndex @ GHC.IOBase.IO $dMonad
= $sbucketIndex ;
In case anyone is wondering what's the point, it'll get inlined
anyway, I'm trying to enhance Data.HashTable to work both with
IO and ST s without duplicating the whole module or flushing
performance down the drain, and the real functions are quite a
bit bigger, hence won't be inlined.
Right now, I have four versions:
Data.HashTable, STHashTable (specialized for ST s), and
MHashTable which works with a typeclass for both IO and ST s.
The first two, and MHashTable instantiated on IO are about
equally fast, but as SPECIALIZE doesn't seem to have much effect
on ST s, MHashTable instantiated on ST s is about two times
slower.
Greetings,
Remi
--
Nobody can be exactly like me. Even I have trouble doing it.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
