December 2008 - Glasgow-haskell-users

Re: Weak pointers and STM
by Simon Marlow 08 Dec '08

08 Dec '08

Lennart Augustsson wrote: > Finalizers without guarantees, like what ghc implements, are totally > useless. Since there is no guarantee that the finalizer will ever run > attaching one is a no-op. It has bitten me several times. I wish ghc > implemented finalizers according to the ffi spec. We do plan to do that (I'm sure you're aware of bug #1364), however I'm sure you're also aware that GHC's finalizers are more general than the FFI spec requires in that finalizers can be Haskell computations, and it is this that leads to the lack of guarantees. Implementing the FFI-style finalizers requires us to treat C finalizers as a special case, rather than implementing them as foreign calls from Haskell finalizers, which is a bit of a pain. I disagree that finalizers are completely useless. They're just not useful for some of the things you might like them to be useful for, like guaranteed resource reclamation. > -- Lennart (iPhone) Cheers, Simon (MS natural keyboard and 28" LCD screen) > On Dec 7, 2008, at 13:12, "Claus Reinke" <claus.reinke(a)talk21.com> wrote: > >>> Adding finalizers to arbitrary objects was useful for the memo table >>> application we had in mind when weak pointers were introduced, but >>> for all the other applications I've come across since then, we really >>> want to add finalizers to objects whose lifetimes are under >>> programmer control. Notice how ForeignPtrs attach the finalizer >>> carefully to the MutVar# inside the ForeignPtr, not the ForeignPtr >>> itself. >> >> One application that was effectively killed by GHC's approach to >> finalizers was GHood (I lost interest when it became apparent that >> GHC was moving away from giving any kinds of guarantees about >> finalizers). The idea was that, just as unsafePerformIO gives us a >> way to instrument the evaluator, so finalizers could have given us a >> way to instrument garbage collection. Then GHood could not only >> have shown when which parts of which structure are first observed >> (how and when structures get unfolded) but also (roughly) when which >> parts of which structure become unreachable (how and when >> structures disappear again). That would have made a very nice tool. >> >> But it would have needed finalizers on arbitrary objects that are >> actually guaranteed to be run, preferably promptly, but not early. >> Given the application, I would have considered wrapping/annotating >> those objects in some transparent way, not visible to the original >> program, but forcing the memory manager to keep track of that object >> even if that means worse code. Only that there are no guarantees >> whatsoever on these finalizers anymore (there were some back then, but >> it emerged that they weren't backed up by the implementation). >> Which also hurts other, table-like, applications: I have an >> application where I need to keep track of synchronous communication >> channels, basically: advance each live channel at every step. Now, I >> would like to attach finalizers to the channels, so that when there >> are no more threads having references to a channel, the channel gets >> removed >> from the tracking table. But without finalizer guarantees, there is no >> guarantee that the table will not simply keep accumulating more and >> more of those dynamically created channels.. >> >> I, for one, would like to have good support for "adding finalizers to >> arbitrary objects with useful run guarantees". Actually, it is a bit hard >> to understand what finalizers without any guarantees (System.Mem.Weak) >> are supposed to achieve? >> >> Claus >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Weak pointers and STM
by John Meacham 07 Dec '08

07 Dec '08

Are there any caveats to using weak pointers and STM together? in particular, the two cases I am interested in are 1. is using 'deRefWeak' fully safe inside 'unsafeIOtoSTM'? As in, will it combine arbitrary STM actions with checking if a weak pointer is still valid atomically? 2. is using an atomically retry safe inside of a finalizer? Will it introduce any concurrency bottlenecks or can I just consider code run in a finalizer just like code run in any other thread? I just wanted to be sure before I base an integral component of a projects design on these working properly. thanks! John -- John Meacham - ⑆repetae.net⑆john⑈

4 6

Deriving Functor
by Twan van Laarhoven 06 Dec '08

06 Dec '08

Hello Ghc people, I have been working on adding support for "derive Functor" to ghc. I have a patch that mostly works, but there are some problems: 1. Ghc reports the correct instance when I use -ddump-deriv:, but that instance is not subsequenctly used. Instead I get a warning like: Warning: No explicit method nor default method for `fmap' In the instance declaration for `Functor (Cont r)' What could be going on here? The full output is attached. 2. As far as I understand the code, there would need to be three traversals of a data type T to derive an instance Functor T: - First to determine whether the deriving should be allowed at all (checkSideConditions) - Then to determine the constraints needed (mk_data_eqn) - Finally to make the body of the instance (gen_Functor_binds) This seems a bit redundant, and currently the code only does the last pass. It would make more sense to report any errors during this pass as well. I don't understand how the constraints are determined in TcDeriv, for instance for the type data T1 a b c = T1 a deriving (Eq) it seems as if Eq constraints are added for all of {a,b,c}, but somehow only a constraint Eq a ends up in the final instance. How does that work? The (experimental) patch was too large to attach, it can be found at http://twan.home.fmf.nl/files/deriv-functor-experimental1.patch.gz By the way: is there any advantage (besides readability) to generating the code "fmap f" instead of "\x -> fmap f x"? Twan E:\Dev\ghc\ghc-head3\testsuite\tests\ghc-regress\deriving\should_run>e:\dev\ghc\ghc-head3\ghc\stage1-inplace\ghc -c drvrun-functor2.hs -fforce-recomp -ddump-deriv ==================== Derived instances ==================== InstInfo: forall r_aff. GHC.Base.Functor (Main.Cont r_aff) { GHC.Base.fmap f_afU (Main.Cont a1_afW) = Main.Cont (\ b1_afY -> a1_afW (\ b2_ag0 -> b1_afY (f_afU b2_ag0))) } InstInfo: forall r_afj w_afk. GHC.Base.Functor (Main.ReaderWriter r_afj w_afk) { GHC.Base.fmap f_ag4 (Main.RW a1_ag6) = Main.RW (\ b1_ag8 -> case a1_ag6 b1_ag8 of { ((a1_aga, a2_agc)) -> (f_ag4 a1_aga, a2_agc) }) } drvrun-functor2.hs:8:14: Warning: No explicit method nor default method for `fmap' In the instance declaration for `Functor (ReaderWriter r w)' drvrun-functor2.hs:11:14: Warning: No explicit method nor default method for `fmap' In the instance declaration for `Functor (Cont r)'

1 0

hsc2hs problem
by Creighton Hogg 05 Dec '08

05 Dec '08

Hello, Since hsc2hs is distributed with GHC, I thought this might be a decent place to ask. I tried to run hsc2hs on a file that I know worked with my 6.8.3 installation, but now I'm getting the error /usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: HsFFI.h: No such file or directory Thanks, Creighton

2 4

Future kind system, closed type functions and type classes
by Philip K.F. Hölzenspies 05 Dec '08

05 Dec '08

Dear all, My apologies for the lengthy mail. There is a question at the end about whether all types in (of?) a kind closed under a type function can be concluded to be a member of a type class (i.e. whether kind classes are required for what I want to do). I have been trying to reserect Robert Dockins' TypeNats library [1], by pulling it out of the type classes / functional dependencies space and into the type family space. The current (discontinued) TypeNats has one Very Nice Thing to it; naturals are coded as bits, rather than as plain successors. Length annotations of vectors et al. now have a memory complexity of O(lg N) as opposed to O(N). A naïve implementation attempt runs into a rather obvious problem: data Z data I n data O n class Natural n where type Pred n toIntegral :: Integral i => n -> i toPred :: Natural n => n -> Pred n toPred _ = undefined instance Natural Z where type Pred Z = Z toIntegral _ = 0 instance Natural (I n) where type Pred (I n) = O n toIntegral n = let i = toIntegral (toPred n) in succ (i+i) instance Natural (O n) where type Pred (O n) = I (Pred n) toIntegral n = let i = toIntegral (toPred n) in i+i This should be interpreted as follows: Z denotes the empty bit string. I denotes a 1 and O denotes a 0. The bits are in reversed order, so 6 is coded as O(I(I Z)). One would expect the instance declaration of O to require a context "Natural n," because of "Pred n" and "toPred n," but the type checker allows for this. As a matter of fact, introducing the context "Natural n" to both the instance declarations of I and O raises the error: Could not deduce (Natural (Pred n)) from the context (Integral a) arising from a use of `natToIntegral' (in the instance declaration of O n) Leaving the context out, this implementation causes stack overflows when evaluating "toIntegral (undefined :: I Z)", because (O Z) is not reduced to Z. The FD solution is to introduce a class that describes the "canonical form" of a bit string (where the canonical form of O Z is Z): class Canonical n cfunctions for Haskell Tom Schrijv | n -> c Since we now have type functions, we can express this in a considerably more comprehensive manner. We can simply write: type family CanonicalNat c type family CanonicalNat_ c type instance CanonicalNat Z = Z type instance CanonicalNat (I n) = I (CanonicalNat n) type instance CanonicalNat (O n) = CanonicalNat_ (O (CanonicalNat n)) type instance CanonicalNat_ (O Z) = Z type instance CanonicalNat_ (O (O n)) = O (O n) type instance CanonicalNat_ (O (I n)) = O (I n) With the type function CanonicalNat, toPred can now be redefined to give a predecessor of a canonical type: toPred :: Natural n => n -> CanonicalNat (Pred n) toPred _ = undefined Unfortunately: Could not deduce (Natural (CanonicalNat_ (O (CanonicalNat n)))) from the context (Integral a) arising from a use of `natToIntegral' Adding a context to the definitions of I and O, viz. data Natural n => I n data Natural n => O n doesn't help very much. I'm no inference expert, but it seems that the problem is that inference goes up, not down (or vice versa, depending on how you interpret these words). Also, adding contexts to the results of type functions is a non-trivial thing [2]). In Schrijvers et al. [3], it is mentioned that work is being undertaken in the direction of closed type functions by using kind declarations. For this example, this would look something like: datakind NatNum = Z | I NatNum | O NatNum and type family CanonicalNat (c :: NatNum) :: NatNum Ideas for a new kind system for GHC is discussed on the wiki [4]. The interaction with type classes section shows this example (for Z/Succ represented Peano numbers): data kind Nat = Zero | Succ Nat class LessThanOrEqual (n1 :: Nat) (n2 :: Nat) instance LessThanOrEqual Zero Zero instance LessThanOrEqual n m => LessThanOrEqual n (Succ m) Aside from the fact that I would imagine that there is a missing case here instance LessThanOrEqual n m => LessThanOrEqual (Succ n) (Succ m) which is non-trivial because of the overlap with the second instance declaration, it is hard for me to see whether a checker with this new kind system could decide that all types in Nat have corresponding instances in LessThanOrEqual. It should be clear how this relates to my case described above; can it now be decided that the result of CanonicalNat will always have an instance of the Natural class? Regards, Philip PS. A possible purpose of a function such as toIntegral is to have a length implementation for fixed-length lists that is more lazy than the length function on a list, but that can be used in exactly the same way. [1] http://www.cs.princeton.edu/~rdockins/dist/typenats-0.2-source.tar.gz [2] http://content.ohsu.edu/cgi-bin/showfile.exe?CISOROOT=/etd&CISOPTR=227&file… [3] http://research.microsoft.com/~simonpj/papers/assoc-types/ifl2007.pdf [4] http://hackage.haskell.org/trac/ghc/wiki/KindSystem

1 0

Alex requirement for Setup.lhs
by Philip K.F. Hölzenspies 04 Dec '08

04 Dec '08

Dear all, Hopefully, you will excuse me for my lack of experience with Cabal. I have seen quite a few e-mails on this list that seem related to this issue, but my specific error, I did not find. Thus: Since installing 6.10.1, I can't perform Setup.(l)hs functions. The error message I get is: Setup.hs: alex is required but it could not be found. The problem is that I get this error also when I try to "runghc Setup.lhs build" alex (is the fact that "runghc Setup.lhs configure" does *not* produce this error significant?). I'm running an OpenSuSE 10.3 installation on which I can only install rpms from standard repositories. In these repositories, there is no binary distribution of alex. How do I install alex from source without requiring alex? Regards, Philip

2 3

ghci and user private groups
by Jason Dusek 03 Dec '08

03 Dec '08

User private groups are not an abnormal configuration, but GHCi has such strict security that they are not allowed! :; ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done.Loading package integer ... linking ... done.Loading package base ... linking ... done. *** WARNING: /Users/jsn/tmp is writable by someone else, IGNORING! *** WARNING: /Users/jsn/tmp/.ghci is writable by someone else, IGNORING! Prelude> :q Leaving GHCi. :; cd ../ :; ls -laR tmp/ tmp/: total 4 drwxrwx--- 2 jsn jsn 102 2008-12-02 10:19 . drwxr-x--- 49 jsn jsn 2890 2008-12-02 10:17 .. -rw-rw---- 1 jsn jsn 159 2008-12-02 10:20 .ghci I appreciate what you guys are trying to do, but I at the very least, it should be permitted to use a GHCi that is group readable/writable as long as the group name and user name are the same. It would be preferable, however, to do away with the restriction altogether. -- _jsn

2 2

Using Data Parallel Haskell
by Manuel M T Chakravarty 02 Dec '08

02 Dec '08

As previously announced, GHC 6.10.1 includes a technology preview of Data Parallel Haskell. However, so far, there was no documentation on how to use it. That is different now: http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell Please keep in mind that this is a very preliminary version of the system with limited functionality. However, we are very interested in feedback from interested users. Happy Vectorising! Manuel

1 0

gtk2hs and MacPorts
by Christian Maeder 01 Dec '08

01 Dec '08

Hi, recently (last Friday) I had a chance to use MacPorts to install gtk2hs. (Usually I do not have root permissions to do so.) Actually, I only wanted to install the libraries needed to run a gtk2hs application that I've created on another machine. On that other machine gtk was (painfully) installed using http://developer.imendio.com/projects/gtk-macosx/build-instructions and gtk2hs-0.9.13 was then compiled from source. sudo port install gtk2hs began at some stage to compile ghc-6.10.1 which I aborted, because I thought, gtk2hs would not work with ghc-6.10.1. ("port search ghc" on another mac lists ghc-6.8.3, though.) Therefore I tried to only install the needed libraries for the binary. (libglade2, gtk2, etc.) Finally my binary complained about a missing libgdk-quartz-2.0.0.dylib or libgtk-quartz-2.0.0.dylib and I had no idea how to get it from MacPorts. (Initially I did not even see the difference of the two library names "gtk" vs, "gdk".) I don't know if my binary is linked against too many libraries. Is this possible or is the linker smart enough to avoid this? Below is the list of libraries my binary needs. I've just found http://www.haskell.org/haskellwiki/Gtk2Hs#Mac_OS_X and the list of dependencies: glade3 libglade2 gstreamer gst-plugins-base gtksourceview cairo librsvg gtkglext firefox Which one contains "quartz"? Another problem have been the links lib{jpeg,png,tiff}.dylib. I had to remove them from my DYLD_LIBARRY_PATH in order to avoid an error in ApplicationServices: dyld: Symbol not found: __cg_jpeg_resync_to_restart Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO Are the libraries lib{jpeg,png,tiff}.dylib needed at all for gtk? Cheers Christian otool -L /home/maeder/gtk/inst/lib/libglade-2.0.0.dylib (compatibility version 1.0.0, current version 1.7.0) /home/maeder/gtk/inst/lib/libxml2.2.dylib (compatibility version 9.0.0, current version 9.32.0) /home/maeder/gtk/inst/lib/libgtk-quartz-2.0.0.dylib (compatibility version 1305.0.0, current version 1305.0.0) /home/maeder/gtk/inst/lib/libgdk-quartz-2.0.0.dylib (compatibility version 1305.0.0, current version 1305.0.0) /home/maeder/gtk/inst/lib/libatk-1.0.0.dylib (compatibility version 2210.0.0, current version 2210.1.0) /home/maeder/gtk/inst/lib/libgio-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libgdk_pixbuf-2.0.0.dylib (compatibility version 1305.0.0, current version 1305.0.0) /home/maeder/gtk/inst/lib/libpangocairo-1.0.0.dylib (compatibility version 2102.0.0, current version 2102.2.0) /home/maeder/gtk/inst/lib/libpango-1.0.0.dylib (compatibility version 2102.0.0, current version 2102.2.0) /home/maeder/gtk/inst/lib/libcairo.2.dylib (compatibility version 20.0.0, current version 20.5.0) /home/maeder/gtk/inst/lib/libgmodule-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libgthread-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libgobject-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libglib-2.0.0.dylib (compatibility version 1704.0.0, current version 1704.0.0) /home/maeder/gtk/inst/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.1.0) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.9.0) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

2 1

Platforms that GHC supports
by Simon Peyton-Jones 01 Dec '08

01 Dec '08

Friends Lots of the bug reports on the GHC bug tracker are platform-specific. We thought it'd help for us to articulate more clearly what platforms GHC supports, and what we'd like it to support. Look here: http://hackage.haskell.org/trac/ghc/wiki/Platforms What you'll notice is that we (GHC HQ) only guarantee to support a fairly narrow range of "Tier 1" platforms, albeit ones that cover a large fraction of our users. There's a much longer list of "Tier 2" platforms, that we'd love to have working, and know of no reason they can't work, but for which we need your help. We are actively looking for sponsors for Tier 2 platforms. If you think you could help, please let us know. Thanks. Simon & Simon

1 0