October 2013 - ghc-devs

Proposal: GHC.Generics marked UNSAFE for SafeHaskell
by Ryan Newton 07 Oct '13

07 Oct '13

Hi all, We had a discussion on haskell-cafe, which only confirmed the unreliability of "Eq" and "Ord". Fine. But if I instead want to define a SafeEq class and instances based on GHC.Generics, then I can't have users writing Generic instances that lie about the structure of their types. But as you can see this module is currently marked "Trustworthy": http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-G… I simply propose that this is changed to "Unsafe"! [1] *Context:* The bottom line is that I believe in the Safe-Haskell mission here, and I want to be able to deliver practical libraries that give a strong guarantee that types can't be broken. Currently, the LVish<http://www.cs.indiana.edu/~rrnewton/papers/2013_07_LVish_quasiDet_working_d…>library has one big hole in it because of this Eq/Ord limitation; the problem is documented here<http://www.cs.indiana.edu/~rrnewton/haddock/lvish/Control-LVish.html#g:1> . If we can provide incontrovertible Safe-Haskel guarantees, this is a huge, qualitative difference compared to what's possible in the C++, Java's and MLs of the world. There are plenty of libraries that provide guarantees like "deterministic parallelism" IFF the user does everything right and breaks no rules (CnC, Pochoir, etc). But we can do better! Best, -Ryan [1] Small detail... some of these bindings, like the class name "Generic" itself, will still need to be accessible from a Trustworthy library. I propose GHC.Generics.Safe for that, following existing precedent. On Sun, Oct 6, 2013 at 5:18 PM, Ryan Newton <rrnewton(a)gmail.com> wrote: > Thanks for the responses all. > > I'm afraid the point about GHC.Generics got lost here. I'll respond and > then rename this as a specific library proposal. > > I don't want to fix the world's Eq instances, but I am ok with requiring > that people "derive Generic" for any data they want to put in an LVar > container. (From which I can give them a SafeEq instance.) > > It's not just LVish that is in this boat.... any library that tries to > provide deterministic parallelism outside of the IO monad has some very > fine lines to walk. Take a look at Accelerate. It is deterministic (as > long as you run only with the CUDA backend and only on one specific GPU... > otherwise fold topologies may look different and non-associative folds may > leak). Besides, "runAcc" does a huge amount of implicit IO (writing to > disk, calling nvcc, etc)! At the very least this could fail if the disk if > full. But then again, regular "pure" computations fail when memory runs > out... so I'm ok grouping these in the same bucket for now. "Determinism > modulo available resources." > > A possible problem with marking "instance Eq" as an unsafe feature is that >> many modules would be only Trustworthy instead of Safe. >> > > My proposal is actually more narrow than that. My proposal is to mark > GHC.Generics as Unsafe. > > That way I can define my own SafeEq, and know that someone can't break it > by making a Generic instance that lies. It is very hard for me to see why > people should be able to make their own Generic instances (that might lie > about the structure of the type), in Safe-Haskell. > >> >> That would go against my "every purely functional module is automatically >> safe because the compiler checks that it cannot launch the missiles" >> understanding of Safe Haskell. >> > > Heh, that may already be violated by the fact that you can't use other > extensions like OverlappingInstances, or provide your own Typeable > instances. > > >> >> Actually, Eq instances are not unsafe per se, but only if I also use some >> other module that assumes certain properties about all Eq instances in >> scope. So in order to check safety, two independent modules (the provider >> and the consumer of the Eq instance) would have to cooperate. > > > I've found, that this is a very common problem that we have when trying to > make our libraries Safe-Haskell compliant -- often we want to permit and > deny combinations of modules. I don't have a solution I'm afraid. > > >

4 9

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
by Ryan Newton 07 Oct '13

07 Oct '13

> Here‘s a thought: doesn’t Generic already have an unused phantom type > that's only there “just in case we need to add something in the future”? > How about using that to track whether an instance was derived or not, and > enforce *that* with SafeHaskell? Your SafeEq can then use a Generic > Derived constraint or whatever. > Ah this sounds promising. You mean that 'x' param in from/to? So to use that, whereever I call to/from I would have to constrain that x to be "Derived". But do I understand correctly that GHC would have to modified so that its derived instances of Generic force that x param to be Derived?

1 0

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
by John Lato 07 Oct '13

07 Oct '13

Andres is right that it's not as evil as defining your own Typeable. The crux of the matter is that Generic essentially allows full access to the data type. Unfortunately it's easy to forget this... On Mon, Oct 7, 2013 at 1:43 AM, Andres Löh <andres(a)well-typed.com> wrote: > While I understand you all feel uncomfortable with this, I do not > think the problem demonstrated by John has anything to do with > Generic. > > I've made a fork here > > https://github.com/kosmikus/safe-bugtest > > that shows an (IMHO) similar problem using Show and Read instead of > Generic. (And something slightly different could certainly also > produced using Enum). > > If you're deriving Generic, then yes, you gain the functionality of > that class, which is to inspect the structure of the type, and then > yes, you can in principle construct any value of that type. So > deriving Generic for types that should be abstract is always going to > be risky. But this is no different than deriving any other class, only > that Generic gives you particularly fine-grained access to the > internals of a type. > > Also, at least in my opinion, it is entirely valid to define your own > Generic instances. It's more work, and while I haven't used it often > so far, I can imagine that there are good use cases. I don't think > it's anywhere near as evil as defining your own Typeable instances. > > Cheers, > Andres > > -- > Andres Löh, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com >

1 0

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
by Ryan Newton 07 Oct '13

07 Oct '13

On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam <ganesh(a)earth.li> wrote: > - Referential transparency: e.g. no unsafePerformIO > - Module boundary control: no abstraction violation like Template > Haskell and GeneralizedNewtypeDeriving > - Semantic consistency: importing a safe module can't change existing > code, so no OverlappingInstances and the like Is this change necessary to preserve the existing properties, or are you > hoping to add a new one? > I'm not currently aware of ways to break these invariants *just* with GHC.Generics. Hmm, but I would like to know why it is marked trustworthy and not inferred-safe... My argument is more that it is a violation in spirit to write bad Generic instances that in turn lead to bad fromRep and toRep conversions. (In a similar way to bad Typeable insteances leading to bad type conversions). Second, the usage intent of GHC.Generics as far as I can see, is that users 99.9% of the time will be using -XDeriveGeneric. Third, without making this change I know of no way to provide safe/correct Eq and Ord instances in a way that extends to user datatypes. And in LVish we have one example of what I think could be a valuable Safe-Haskell compliant parallel programming library (see the POPL'14 paper for more details<http://www.cs.indiana.edu/~rrnewton/papers/2013_07_LVish_quasiDet_working_d…>), but which will never be fully water-tight without vetted Eq and Ord instances. > > I also understand that you want to require 'standard' Generic instances > on types - will that mean that module authors are forced to expose > internals to use your library? > Great point! My intent was to short-circuit that by providing "TrustWorthy" SafeEq and SafeOrd instances for standard types. If you know any better ways to go forward, let me know! Also, if anyone uses SafeHaskell with non-derived Generic instances, please speak up! Cheers, -Ryan

3 6

FW: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell
by Simon Peyton-Jones 05 Oct '13

05 Oct '13

Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that'll trip if it breaks again? (I'm guessing that the latter might be hard.) Thanks Simon -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott <conal(a)conal.net<mailto:conal@conal.net>> wrote: > I'm polling to see whether there are will and expertise to reboot graphics > and GUIs work in Haskell. I miss working on functional graphics and GUIs in > Haskell, as I've been blocked for several years (eight?) due to the absence > of low-level foundation libraries having the following properties: > > * cross-platform, > * easily buildable, > * GHCi-friendly, and > * OpenGL-compatible. > > The last several times I tried Gtk2hs, I was unable to compile it on my Mac. > Years ago when I was able to compile, the GUIs looked and interacted like a > Linux app, which made them awkward and upleasant to use. wxHaskell (whose > API and visual appearance I prefered) has for years been incompatible with > GHCi, in that the second time I open a top-level window, the host process > (GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners, > and I tend to experiment a lot, using a full compilation greatly thwarts my > flow. For many years, I've thought that the situation would eventually > improve, since I'm far from the only person who wants GUIs or graphics from > Haskell. > > About three years ago, I built a modern replacement of my old Pan and > Vertigo systems (optimized high-level functional graphics in 2D and 3D), > generating screamingly fast GPU rendering code. I'd love to share it with > the community, but I'm unable to use it even myself. > > Two questions: > > * Am I mistaken about the current status? I.e., is there a solution for > Haskell GUI & graphics programming that satisfies the properties I'm looking > for (cross-platform, easily buildable, GHCi-friendly, and > OpenGL-compatible)? > * Are there people willing and able to fix this situation? My own > contributions would be to test and to share high-level composable and > efficient GUI and graphics libraries on top of a working foundation. > > Looking forward to replies. Thanks, > > -- Conal > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org<mailto:Haskell-Cafe@haskell.org> > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Regards, Paul Liu _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org<mailto:Haskell-Cafe@haskell.org> http://www.haskell.org/mailman/listinfo/haskell-cafe

6 8

Haskell package with dynamic library only
by Andreas Voellmy 05 Oct '13

05 Oct '13

Hi all, Is it possible to have a Haskell package that only includes a dynamic library and .dyn_hi files? I.e. it would omit the .o and .a files? I tried building a library using cabal and --enable-shared. It still includes the .o and .a files. Will builds with "-dynamic" and loading modules in ghci work correctly if I just delete the .o and .a files? I did a few experiments and it seems to work OK, although it seems that things break if I delete the .hi files, even though I'd expect only the .dyn_hi files would be used. -Andi

1 2

DEBUG is too slow
by Simon Peyton-Jones 04 Oct '13

04 Oct '13

Friends I build my stage1 compiler with DEBUG on, but it is very very slow. I think one of the DEBUG tests must be taking ages. But I don't know which one. Would anyone caser to build GHC with DEBUG and profiling enabled, and see where the time is going? Probably useful to also build with DEBUG disabled and profiling, so you can compare like with like. It would be v helpful. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

1 0

Detabbing patch and GHC developers Wiki
by p.k.f.holzenspies＠utwente.nl 03 Oct '13

03 Oct '13

Dear GHCers, Attached is a patch to detab the current HEAD. I've followed the GHC developers Wiki instructions on validation and patch generation. However, the Wiki seems to contain an error (or, at least, does not agree with my version of git). At [1], the wiki says I can submit patches using "git send-email". My git complains that it does not know this command. If this is indeed wrong, could someone in the know update the wiki? Can I consider my patch submitted for consideration or should I send it somewhere else? Regards, Philip

2 1

validate failure on Mac
by Richard Eisenberg 03 Oct '13

03 Oct '13

Sorry if this has been addressed recently, but I can't validate right now, due to a build failure from -Werror in C code in primitive: > "inplace/bin/ghc-stage2" -optc-Werror -optc-Wall -optc-Ilibraries/primitive/cbits -optc-O3 -optc-ftree-vectorize -optc-fomit-frame-pointer -optc-msse2 -optc-I'/Users/rae/Documents/ghc-cur/libraries/base/include' -optc-I'/Users/rae/Documents/ghc-cur/rts/dist/build' -optc-I'/Users/rae/Documents/ghc-cur/includes' -optc-I'/Users/rae/Documents/ghc-cur/includes/dist-derivedconstants/header' -static -H32m -O -Werror -Wall -H64m -O0 -package-name primitive-0.5.1.0 -hide-all-packages -i -ilibraries/primitive/. -ilibraries/primitive/dist-install/build -ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/dist-install/build -Ilibraries/primitive/dist-install/build/autogen -Ilibraries/primitive/cbits -optP-include -optPlibraries/primitive/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -O2 -Wall -XHaskell2010 -O2 -O -dcore-lint -fno-warn-amp -fno-warn-deprecated-flags -no-user-package-db -rtsopts -Wwarn -c libraries/primitive/cbits/primitive-memops.c -o libraries/primitive/dist-install/build/cbits/primitive-memops.o > cc1: warnings being treated as errors > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Word16’: > > libraries/primitive/cbits/primitive-memops.c:44:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Word32’: > > libraries/primitive/cbits/primitive-memops.c:45:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Word64’: > > libraries/primitive/cbits/primitive-memops.c:46:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Word’: > > libraries/primitive/cbits/primitive-memops.c:47:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Ptr’: > > libraries/primitive/cbits/primitive-memops.c:48:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Float’: > > libraries/primitive/cbits/primitive-memops.c:49:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > libraries/primitive/cbits/primitive-memops.c: In function ‘hsprimitive_memset_Double’: > > libraries/primitive/cbits/primitive-memops.c:50:0: > warning: dereferencing type-punned pointer will break strict-aliasing rules > make[1]: *** [libraries/primitive/dist-install/build/cbits/primitive-memops.o] Error 1 > make: *** [all] Error 2 I have not been playing around in this area lately (or ever), and I did a ./sync-all pull this morning. Any advice? Thanks! Richard

1 0

FW: Detabbing patch and GHC developers Wiki
by p.k.f.holzenspies＠utwente.nl 03 Oct '13

03 Oct '13

PS. Ignore my comments about git send-email. Ubuntu enjoys splitting everything up in minute sub-packages. I should have installed git-email. From: Holzenspies, P.K.F. (EWI) Sent: donderdag 3 oktober 2013 15:18 To: 'ghc-devs(a)haskell.org' Subject: Detabbing patch and GHC developers Wiki Dear GHCers, Attached is a patch to detab the current HEAD. I've followed the GHC developers Wiki instructions on validation and patch generation. However, the Wiki seems to contain an error (or, at least, does not agree with my version of git). At [1], the wiki says I can submit patches using "git send-email". My git complains that it does not know this command. If this is indeed wrong, could someone in the know update the wiki? Can I consider my patch submitted for consideration or should I send it somewhere else? Regards, Philip

1 0