- ghc-devs - Haskell.org

#8276
by Andreas Voellmy 08 Oct '13

08 Oct '13

Is there a workaround for http://ghc.haskell.org/trac/ghc/ticket/8276. I haven't been able to build HEAD for a while due to this issue. -Andi

2 2

-dynamic: all or nothing?
by Andreas Voellmy 07 Oct '13

07 Oct '13

Hi all, >From what I gather, using "-dynamic" with "ghc --make" compiles an executable using dynamic linking for ALL dependent Haskell libraries. Is it possible to choose to link some dependent libraries to link statically and some to link dynamically? If so, how can I do this? -Andi

2 1

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

07 Oct '13

My understanding is that the > proposed changes to ghc/Generic would mean that all data used with > LVish would have to expose it's implementation to everybody through > the derived Generic instance. > Either that or they would have use TrustWorthy to mark a module containing custom equality/ordering operations as safe according to our definition, and take the proof obligations that come with that. In fact, this is what we would plan to do to "opt in" ADTs like bytestring, vector, containers. We can trust as many people/libraries as we like, but we want to retain the ability to run untrusted code with the right set of flags to ensure that it can't break our library. (And that's what we can't do without locking down the Generic backdoor.)

1 0

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell
by Edward Kmett 07 Oct '13

07 Oct '13

I have no particular opinions on the internals of LVish. I do have concern than your supplied Generic for Set seems rather borked though, so I felt I should explain the issue lest someone take it as a model for how to define a custom Generic! =) A real valid 'virtual' Rep (Set a) would be a fair bit more complicated with something like instance Generic Set where type Rep (Set a) = D1 D_Set (C1 C_fromList (S1 NoSelector (Rec0 [a])) to (M1 (M1 (M1 (K1 as))) = fromList as from as = M1 (M1 (M1 (K1 (toList as) instance Generic1 Set where type Rep1 Set = D1 D1_Set (C1 C1_fromList (S1 NoSelector (Rec1 [])) ... with a custom Datatype instances D_Set, D1_Set and custom virtual Constructor instances C_fromList and C1_fromList. Otherwise it won't deal correctly with any code out there that was written to assume a properly constructed Generic. Headaches like that are why few of us ever implement Generic or Generic1 by hand. ;) Actually, I can't think of anyone else who has bothered. I was forced to figure it out back when Generic1 deriving was broken. -Edward On Mon, Oct 7, 2013 at 3:28 PM, adam vogt <vogt.adam(a)gmail.com> wrote: > On Mon, Oct 7, 2013 at 1:33 PM, Ryan Newton <rrnewton(a)gmail.com> wrote: > > Again, my use-case (closed/safe Eq & Ord instances) is a few steps > removed > > from this Generics business and I don't feel strongly about how it gets > > done. But having *SOME* way of doing it will be a massive boon to my > lab's > > particular effort at maximizing the abilities of guaranteed-Safe > > deterministic parallelism in Haskell. Further, I think anyone else who > > tries to do something in SafeHaskell that depends on guaranteeing a > > closed/controlled set of instances (SafeEq, SafeOrd but also others) > based > > on GHC.Generics will *also* find this change useful. > > Hi, > > In containers we have Data instances "This instance preserves data > abstraction at the cost of inefficiency". Generic is a more modern way > to address the same problem. This Generic instance for Set is just a > more convenient way to use Set.toList/Set.fromList > <http://lpaste.net/94028>, which are -XSafe functions right? > > For your problem I suggest using template-haskell to write your > "SafeEq" "SafeOrd" instances. It will let you access unexported > constructors too, which means people using LVish can maintain their > abstractions for everybody except LVish. My understanding is that the > proposed changes to ghc/Generic would mean that all data used with > LVish would have to expose it's implementation to everybody through > the derived Generic instance. > > Regards, > Adam >

1 0

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