Re: Spectre mitigation
> The only impacted code is the code which should already be engineered to be side channel resistant... which already need to be written in a way that has constant control flow and memory lookup. As far as I understand, that's not really true. If you have a process, which has secrets that you do not want to leak to arbitrary other code running on the same CPU, then not only do you need to avoid indirect branches in your side-channel resistent part (as is the case today) but the *rest* of the program also should not contain indirect branches (assuming the presence of gadgets which make memory leaking possible). So even if your crypto library uses no indirect branches and is side-channel resistant, that is no longer enough: if you link it into a program where other parts of the program have indirect branches, then you can use those branches to potentially leak the crypto keys. So in general, you need to apply mitigations for this attack if you, at any time, store secrets in the process memory that you do not want to be leaked (and being a hardware bug, leaking means that they can, potentially, be leaked to arbitrary users. Privilege-separation provided by the OS does not really matter here, so in theory it may be possible to leak it from JavaScript running in a browser sandbox for example.). Carter Schonwald schrieb am Fr., 5. Jan. 2018 um 00:07 Uhr: > Indeed. It’s worth noting that the discussed cases where you can recover > the perf benefits of branch / jump prediction only work in the context of a > first order and or whole program compilation approach. The ghc rts and > design is not compatible with those approaches today. > > I suspect you could get them to work in a whole program optimizing > compiler like MLTON, or a hypothetical compiler for Haskell that has a > different rts rep > > On Thu, Jan 4, 2018 at 4:25 PM Elliot Cameron wrote: > >> This may be relevant: https://support.google.com/faqs/answer/7625886 >> >> Note that both GCC and LLVM will be learning this Ratpoline technique. >> >> On Thu, Jan 4, 2018 at 1:55 PM, Carter Schonwald < >> carter.schonw...@gmail.com> wrote: >> >>> With the caveat of that I maybe have no clue what I’m talking about ;) : >>> >>> It’s a pretty epic attack/ side channel, but it still requires code >>> execution. >>> >>> The kernel side channel more of an issue for vm providers >>> >>> And the spectre one probably will most heavily impact security conscious >>> organizations that might be considering using tools like moby/ docker / >>> Linux containers / kubernetes / mesos/ etc which depend on OS level process >>> isolation etc for security. >>> >>> My fuzzy understanding is that one fix would be hardware support for >>> per process isolation of memory even in the context users / processes ... >>> which isn’t in any kit afaik. >>> >>> I do like my code not being slow. So it’s a dilemma :/ >>> >>> On Thu, Jan 4, 2018 at 11:51 AM Thomas Jakway wrote: >>> I'm gonna start reading through the spectre paper in a few minutes but... is this really the death knell for speculative execution on x86/64...? If so, GHC getting patched is going to be pretty low on everyone's list of priorities. On Jan 4, 2018 6:36 AM, "Carter Schonwald" wrote: > The only impacted code is the code which should already be engineered > to be side channel resistant... which already need to be written in a way > that has constant control flow and memory lookup. > > This is just a new and very powerful side channel attack. It would be > interesting and possibly useful to explore fascilities that enable marked > pieces of code to be compiled in ways that improve side channel > resistance. But there’s so many different approaches that it’d be > difficult to protect against all of them at once for general programs. > > I could be totally wrong, and I should read the spectre paper :) > > I guess I just mean that vulnerable Data should be hardened, but only > when the cost makes sense. Every security issue has some finite cost. The > sum of those security events cost must be weighed against the sum of the > costs of preventing them > > On Thu, Jan 4, 2018 at 9:08 AM Demi Obenour > wrote: > >> The recent “Spectre” bug requires that speculative execution of >> indirect branches be disabled. For GHC, this will require passing a flag >> to LLVM and fixing the NCG to emit suitable calling sequences. >> >> This will be a disaster for the STG execution model, because it >> disables CPU branch prediction for indirect calls and jumps. This is a >> big >> argument in favor of doing a CPS→SSA conversion in the backend. >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > __
Re: 8.2.1: Ord TyCon is gone?
Hi, Maybe you can use UniqFM for your map: https://hackage.haskell.org/package/ghc-8.2.1/docs/UniqFM.html Regards, Benno Hi Levent, > > that seems to be this commit, part of the making-ghc-deterministic effort: > > https://ghc.haskell.org/trac/ghc/ticket/4012#comment:213 > > CC @niteria who might be answer your question. > > Niklas > > On 29/07/17 08:12, Levent Erkok wrote: > > I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas > > I'm getting an error suggesting that TyCon is no longer an instance of > Ord: > > > > Data/SBV/Plugin/Analyze.hs:580:33: error: > > • No instance for (Ord TyCon) arising from a use of ‘M.lookup’ > > There are instances for similar types: > > instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’ > > • In the expression: k `M.lookup` tcMap > > In the expression: > > case k `M.lookup` tcMap of > > Just knd -> return knd > > Nothing -> unknown > > In a case alternative: > > Just k > > -> case k `M.lookup` tcMap of > > Just knd -> return knd > > Nothing -> unknown > > | > > 580 | Just k -> case k `M.lookup` tcMap of > > | ^^ > > > > I was using TyCon's as a key in a map, but that code is no longer > > compiling. I've looked through the release notes but couldn't find what > > the new mechanism is. > > > > I'd appreciate if someone can point me in the right direction regarding > > how to use TyCon as a map key.. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC tarballs for Windows 10 Creators Update
Ben Gamari schrieb am Sa., 15. Apr. 2017 um 12:37 Uhr: > Niklas Larsson writes: > > > Hi! > > > > That's great! I see that the download page at > > http://www.haskell.org/ghc/download still links to the old tarballs > > for 8.0.2. Will those links be updated? > > > Yes, they will in due time. > Looking at https://www.haskell.org/ghc/download_ghc_8_0_2#windows, I cannot find a GHC download compatible with the creators update. Has this been forgotten? Kind regards, Benno ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Exhaustiveness checking for pattern synonyms
An idea: could we perhaps use the same syntax as for MINIMAL pragmas also
for COMPLETE pragmas, since those two feel very similar to me? So instead
of multiple pragmas, let's have {-# COMPLETE (Pat1, Pat2) | (Pat3, Pat4)
#}, just like with {-# MINIMAL #-} ?
Regards,
Benno
Simon Peyton Jones via ghc-devs schrieb am Fr., 13.
Jan. 2017 um 16:50 Uhr:
> Thanks.
>
> | > * What if there are multiple COMPLETE pragmas e.g.
> | > {-# COMPLETE A, B, C #-}
> | > {-# COMPLETE A, X, Y, Z #-}
> | > Is that ok? I guess it should be!
> | >
> | > Will the pattern-match exhaustiveness check then succeed
> | > if a function uses either set?
> | >
> | > What happens if you use a mixture of constructors in a match
> | > (e.g. A, X, C, Z)? Presumably all bets are off?
> |
> | Yes this is fine. In the case you ask about then as neither COMPLETE
> pragma
> | will match then the "best" one as described in the error messages
> section
> | will be chosen.
>
> The wiki spec doesn't say this (presumably under "semantics"). Could it?
>
> | > * Note that COMPLETE pragmas could be a new source of orphan modules
> | > module M where
> | >import N( pattern P, pattern Q )
> | >{-# COMPLETE P, Q #-}
> | > where neither P nor Q is defined in M. Then every module that is
> | > transitively "above" M would need to read M.hi just in case its
> | > COMPLETE pragmas was relevant.
>
> Can you say this in the spec?
>
> | >
> | > * Point out in the spec that COMPLETE pragmas are entirely unchecked.
> | > It's up to the programmer to get it right.
>
> Can you say this in the spec? Ah -- it's in "Discussion"... put it under
> "Semantics".
>
> | >
> | > * Typing. What does it mean for the types to "agree" with each other.
> | > E.g A :: a -> [(a, Int)]
> | >B :: b -> [(Int, b)]
> | > Is this ok? Please say explicitly with examples.
> |
> | This would be ok as the type constructor of both result types is [].
>
> Can you say this in the spec?
>
> |
> | > * I didn't really didn't understand the "Error messages" section.
> | >
> | >
> |
> | I can't really help unless I know what you don't understand.
>
> "The pattern match checker checks each set of patterns individually"
>
> Given a program, what are the "sets of patterns", precisely?
>
> | The idea is simply that all the different sets of patterns are tried and
> | that the results are prioritised by
> |
> | 1. Fewest uncovered clauses
> | 2. Fewest redundant clauses
> | 3. Fewest inaccessible clauses
> | 4. Whether the match comes from a COMPLETE pragma or the build in set of
> | data constructors for a type constructor.
>
> Some examples would be a big help.
>
> Simon
>
> |
> |
> |
> | > Simon
> | >
> | > | -Original Message-
> | > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> | > | Matthew Pickering
> | > | Sent: 22 November 2016 10:43
> | > | To: GHC developers
> | > | Subject: Exhaustiveness checking for pattern synonyms
> | > |
> | > | Hello devs,
> | > |
> | > | I have implemented exhaustiveness checking for pattern synonyms.
> | > | The idea is very simple, you specify a set of pattern synonyms (or
> | > | data
> | > | constructors) which are regarded as a complete match.
> | > | The pattern match checker then uses this information in order to
> | > | check whether a function covers all possibilities.
> | > |
> | > | Specification:
> | > |
> | > | https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs
> | > |
> | > | https://phabricator.haskell.org/D2669
> | > | https://phabricator.haskell.org/D2725
> | > |
> | > | https://ghc.haskell.org/trac/ghc/ticket/8779
> | > |
> | > | Matt
> | > | ___
> | > | ghc-devs mailing list
> | > | ghc-devs@haskell.org
> | > |
> | > |
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
> | > | .haskell
> | > | .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | > |
> | > | devs&data=02%7C01%7Csimonpj%40microsoft.com
> %7C155eb2786cb040d8052908
> | > | d412c453
> | > | b5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636154081815249356&s
> | > | data=MkQ
> | > | FpwJWaTU%2BdEQSYEBjXLt80BrXLkBp9V8twdKB6BI%3D&reserved=0
> |
> | I updated the wiki page quite a bit. Thanks Simon for the comments.
> |
> | Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wither the Platform
I'd like the haskell platform to include all of LTS haskell. That includes a very broad set of packages so you don't need to install many other packages even as an advanced user. Maybe there could also be a nightly release which includes stackage instead? It would save a lot of time even for experienced users, since they get stackage precompiled. However, such a distribution should be designed such that cabal install just works, so it should probably be based on winghc on Windows. The only problem I can see with this is the size of such a package, not sure if it would be acceptable? Neil Mitchell schrieb am So., 22. Mär. 2015 10:18: > On Windows, the reason I used to use the Platform was that it came > with an installed network library, and installing the network library > on Windows is a real pain (and often fails). Unfortunately it was > incredibly brittle, a single attempt at upgrading network from some > newer package usually trashed my Haskell install and required a wipe > and restart. > > Nowadays I use https://github.com/fpco/minghc which can actually > install network, and I've had zero problems. I can get up to the > platform with one invoke of cabal, and if someone decides to require a > new network, it just works. > > I think the Platform now gives a worse user experience on Windows, so > the ideas (or names) probably need migrating around. > > Thanks, Neil > > > On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus > wrote: > > Mark Lentczner wrote: > >> > >> I'm wondering how we are all feeling about the platform these days > >> > >> I notice that in the new Haskell pages, the Platform is definitely not > the > >> recommended way to go: The main download pages suggests the compiler and > >> base libraries as the first option - and the text for the Platform > (second > >> option) pretty much steers folks away from it. Of the per-OS download > >> pages, only the Windows version even mentions it. > >> > >> Does this mean that we don't want to consider continuing with it? It is > a > >> lot of community effort to put out a Platform release - we shouldn't do > it > >> if we don't really want it. > >> > >> That said, I note that the other ways to "officially get" Haskell look, > to > >> my eye, very ad hoc. Many of the options involve multiple steps, and > >> exactly what one is getting isn't clear. It hardly looks like there is > now > >> an "official, correct" way to setup Haskell. > >> > >> The Platform arose in an era before sandboxes and before curated library > >> sets like Stackage and LTS. Last time we set direction was several years > >> ago. These new features and development have clearly changed the > landscape > >> for use to reconsider what to do. > >> > >> > >> I don't think the status quo for the Platform is now viable - mostly as > >> evidenced by waning interest in maintaining it. I offer several ways we > >> could proceed: > >> > >> *1) Abandon the Platform.* GHC is release in source and binary form. > Other > >> package various installers, with more or less things, for various OSes. > >> > >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > >> "essential" libs + tools. Keeps a consistent build layout and > installation > >> mechanism for Haskell. > >> > >> *3) Re-conceive the Platform.* Take a very minimal install approach, > >> coupled with close integration with a curated library set that makes it > >> easy to have a rich canonical, stable environment. This was the core > idea > >> around my "GPS Haskell" thoughts from last September - but there would > be > >> much to work out in this direction. > >> > >> Thoughts? > > > > > > Thanks a lot for your hard work on the platform! > > > > I myself am an avid user of the platform (OS X), because for me, it's the > > easiest way to install Haskell on a new machine; I just did so the other > > day. > > > > The only time when the platform seems to be a handicap is when a new > version > > of GHC is being released and I would have to update my packages. > Usually, I > > don't test them with the new version and rely on pull requests instead. > > > > > > Best regards, > > Heinrich Apfelmus > > > > -- > > http://apfelmus.nfshost.com > > > > > > ___ > > Libraries mailing list > > librar...@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > ___ > Libraries mailing list > librar...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC support for the new "record" package
Hi Simon,
One problem with the newtype approach is that you can no longer write a
single function that can work with all of lenses, traversals or other
optics. For example, in the current lens library, set can be used for
prism, lens, iso and traversal. That would just not be possible when using
a newtype.
Regards,
Benno
Simon Peyton Jones schrieb am Mi., 28. Jan. 2015
11:03:
> Ignoring lenses all together for the moment, I don't see how IV works.
>
>
>
> Could you take a look at the *current* version of
> https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Redesign
>
>
>
> and the give an example of something problematic. You may well be right,
> but it’s hard to know without something specific to bite on.
>
>
>
> You can make a data type
>
> data Lens s a = Lens (s -> a) (a -> s -> s)
>
>
>
> You could, but that would be very different to your lovely lenses today,
> and it is certainly not what I was suggesting. All I was suggesting was
>
>
>
> newtype Lens s t a b = L { unwrap :: forall f. Functor
>
> f => (a -> f b) -> s -> f t }
>
>
>
> Just a wrapper around the precise type you use today. So presumably
> anything whatsoever that you can do today, you can also do by saying
> (unwrap l).
>
>
>
> Yes, that means you can’t use ordinary function composition (.) for these
> wrapped lenses. I agree that’s a pity. Perhaps this single point is so
> important that it justifies breaking abstraction. But breaking
> abstractions comes with costs, to error messages, and to future evolution.
>
>
>
> Are there other costs to having the abstraction, or is it just (.)? After
> all, the lens combinators themselves can wrap and unwrap to their heart’s
> content; it’s just the clients of the library that we care about here.
>
>
>
> Simon
>
>
>
> *From:* Edward Kmett [mailto:ekm...@gmail.com]
> *Sent:* 27 January 2015 23:48
> *To:* Simon Peyton Jones
> *Cc:* Adam Gundry; ghc-devs@haskell.org
>
>
> *Subject:* Re: GHC support for the new "record" package
>
>
>
> On Tue, Jan 27, 2015 at 6:12 AM, Simon Peyton Jones
> wrote:
>
> | 1. What are the IV instances provided in base? These could give
> | selector functions, lenses, both or neither.
>
> My instinct: just selector functions. Leave lenses for a lens package.
>
>
>
> How do these selectors actually typecheck when composed?
>
>
>
> Ignoring lenses all together for the moment, I don't see how IV works.
>
>
>
>
>
> I still have not understood the argument for lenses being a function
> rather that a newtype wrapping that function; apart from the (valuable)
> ability to re-use ordinary (.), which is cute. Edward has explained this
> several time, but I have failed to understand.
>
>
>
> You can make a data type
>
>
>
> data Lens s a = Lens (s -> a) (a -> s -> s)
>
>
>
> or
>
>
>
> newtype Lens s a = Lens (s -> (a, a -> s))
>
>
>
> The latter is basically the approach I used to take in my old data-lens
> library.
>
>
>
> This works great for lenses that don't let you change types.
>
>
>
> You can write a Category instance for this notion of lens.
>
>
>
> You can make it compose the way functions normally compose (or you can
> flip the arguments and make it compose the way lenses in the lens library
> do, here you have an option.)
>
>
>
> Now, expand it to let you do type changing assignment.
>
>
>
> newtype Lens s t a b = Lens (s -> a) (s -> b -> t)
>
>
>
> Now we have 4 arguments, but Category wants 2.
>
>
>
> I've punted a way-too-messy aside about why 4 arguments are used to the
> end. [*]
>
>
>
> You can come up with a horrible way in which you can encode a GADT
>
>
>
> data Lens :: (*,*) -> (*,*) -> * where
>
> Lens :: (s -> a) -> (s -> b -> t) -> Lens '(s,t) '(a,b)
>
>
>
> but when you go to define
>
>
>
> instance Category Lens where
>
> id = ...
>
>
>
> you'd get stuck, because we can't prove that all inhabitants of (*,*) look
> like '(a,b) for some types a and b.
>
>
>
> On the other hand, you can make the data type too big
>
>
>
> data Lens :: * -> * -> * where
>
> Lens :: (s -> a) -> (s -> b -> t) -> Lens (s,t) (a,b)
>
> Id :: Lens a a
>
>
>
> but now you can distinguish too much information, GHC is doing case
> analysis everywhere, etc.
>
>
>
> Performance drops like a stone and it doesn't fit the abstraction.
>
>
>
> In short, using a dedicated data type costs you access to (.) for
> composition or costs you the ability to let the types change.
>
>
>
> -Edward
>
>
>
> [*] Why 4 arguments?
>
>
>
> We can make up our own combinators for putting these things together, but
> we can't use (.) from the Prelude or even from Control.Category.
>
>
>
> There are lots of ways to motivate the 4 argument version:
>
>
>
> Logically there are two type families involved the 'inner' family and the
> 'outer' one and the lens type looks like
>
>
>
> outer i is isomorphic to the pair of some 'complement' that doesn't depend
> on the index i, and
Re: docker GHC image for hacking
Hello, > Hacking on GHC for the first time is death by a thousand cuts. > Any one part of the process is not that bad, but as a whole the process is > very cumbersome for someone new. > With the docker image, would it be possible to distribute pre-built versions of the GHC source tarball? Maybe phabricator could do this? The biggest overhead for me always is that compiling the source the first time takes something like 2 hours (even without optimizations) on my machine. If there was a pre-built version, I could just change one file and only recompile what I changed. -- Benno ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Making GHCi awesomer?
2014-10-23 22:49 GMT+02:00 Luite Stegeman : > If stability/segfaults are a major factor in choosing to communicate with > the GHCi program, rather than using GHC as a library, then this really > should be addressed directly. Has anyone done investigation of the > situations that make ghc-mod/ghc-server, but not GHCi, crash? > The crashes tend to be related to linker problems (like duplicate symbols, often also in combination with TH) IME. I think the problem that projects like ghc-mod, hdevtools etc encounter is that the GHC API is quite lowlevel. For example, just look at the code for `:load`: https://github.com/ghc/ghc/blob/5bb73d79a83bca57dc431421ca1e022f34b8dec9/ghc/InteractiveUI.hs#L1343 . - First, I have no idea what abandonAll is doing here (and hdevtools isn't using it). I guess it is related to GHCi debugger, so that might not be a problem. - We then unload the active program and call doLoad. doLoad just resets some debugging related things (note that it calls discardActiveBreakPoints again, even though loadModule' already did that) and then calls GHC.load. After that, it calls `afterLoad`, which uses a foreign function calling into the RTS (!) to reset CAFs. As this function is only foreign import'ed in GHCi itself, I'm sure neither ghc-mod nor hdevtools call it. Needing to call a RTS function just to safely load a new module, replacing the old program, doesn't feel right to me. The problem here is that this `loadModule` function is only inside GHCi, and not exported through the GHC API. This was just one example, I'm sure there are more. There is just no highlevel GHC API function for most of GHCi's commands. Another reason for the crashes might be that ghc-mod and hdevtools tend to do many, many more reloads than GHCi, because they reload on every file save (or even after 0.5s idle time). Crashes that only appear very infrequent are thus much more likely to occur in ghc-mod. -- Benno ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Fwd: Question about Roles and the AMP work
I'm not familar with the internals of GHC, but maybe it would be possible
for GHC to just use the default definition for `join` in the case that
deriving fails because of roles? At least if the class to be derived has a
`MINIMAL` pragma, GHC could check if that is still satisfied even without
the method that failed to derive, and use the default definition if that's
the case.
2014-05-12 17:28 GMT+02:00 Edward Kmett :
As a straw man, if we went to a typeclass-driven 'next arg is
> representational' approach then we could possibly recover 'join' here.
>
> e.g.
>
> class Representational f where
> rep :: Coercion f g -> Coercion a b -> Coercion (f a) (g b)
>
> class Representational f => Phantom f where
> phantom :: Coercion f g -> Coercion (f a) (g b)
>
> When we look at for the constraint head Coercible (f a) (g b) we'd then
> check for Phantom f and if so look for Coercible f g, or fall back to
> Representational
> f, and look for Coercible f g and Coercible a b.
>
> Then to derive GND for C m it'd need to check Representational m due to
> the type of join needing m's next arg to be representational, find it and
> move on.
>
> The set of these instances can be left open like any other typeclass and
> users could supply their own for tricky conversions if need be.
>
> If you just wrote the existing role annotations, but let them request
> currently impossible roles you could use the desired role to infer the
> constraints involved.
>
> e.g.
>
> newtype StateT s m a = StateT { runStateT :: s -> m (a, s) }
>
> should be able to derive something like
>
> instance Representational (StateT s)
> instance Representational m => Representational (StateT s m)
> instance Phantom m => Phantom (StateT s m)
>
> If we put nominal or representational on the m argument
>
> type role StateT nominal nominal nominal
>
> then we could just elide the instances for anything lower in the nominal
> -> representational -> phantom lattice than the named role.
>
> The positional argument scheme isn't perfect, as in the above it'd fail to
> let you derive `instance Representational StateT` due to the s occurring
> under m, an argument later in the argument list, but it does fix most of
> the problems with Coercible and monad transfomers.
>
> There might be some fancier form that can cover all of the use cases, but
> I'm not seeing it off hand.
>
> -Edward
>
>
> On Tue, May 13, 2014 at 12:59 AM, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
>> This looks a bit awkward to me. Here's a small test case
>>
>> class C m where
>> ret :: a -> m a
>> bind :: m a -> (a -> m b) -> m b
>> join :: m (m a) -> m a
>>
>> newtype T m a = MkT (m a) deriving( C )
>>
>> This is accepted without the 'join' in the class, but rejected with it.
>>
>> So *all* uses of GND to do 'deriving( Monad )' will break when 'join' is
>> added to Monad.
>>
>> And this is because we don't know that 'm' ranges only over things that
>> have representational arguments; type variables always have nominal
>> arguments. The paper draws attention to this shortcoming, but now it's
>> becoming important.
>>
>> I can't think of an obvious workaround either, except not putting 'join'
>> in Monad.
>>
>> Simon
>>
>>
>>
>> | -Original Message-
>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
>> Austin
>> | Seipp
>> | Sent: 12 May 2014 13:53
>> | To: ghc-devs@haskell.org
>> | Subject: Question about Roles and the AMP work
>> |
>> | Hello all,
>> |
>> | While picking the AMP patch back up, it is almost ready to go, but I got
>> | quite a puzzling error when attempting to build 'haskeline' with the AMP
>> | changes. I don't seem to remember encountering this error before - but
>> | maybe my mind is hazy.
>> |
>> | The error in question is this:
>> |
>> | https://gist.github.com/thoughtpolice/6df4c70d8a8fb711b282
>> |
>> | The TL;DR is that the move of `join` into base has caused a problem
>> | here. The error really speaks for itself: GND tries to derive an
>> | instance of `join` for DumbTerm, which would have the type
>> |
>> | join :: DumbTerm m (DumbTerm m a) -> DumbTerm m a
>> |
>> | and be equivalent to join for StateT. But this can't hold: DumbTerm
>> | should unwrap directly to StateT (by newtype equality) and thus the
>> | third parameter to StateT in this case is `DumbTerm m a` if you expand
>> | the types - but because this argument is Nominal, it cannot unify with
>> | 'PosixT m', which is the actual definition of DumbTerm in the first
>> | place!
>> |
>> | With a little thought, this error actually seems reasonable. But it
>> | puzzles me as to what we should do now. One thing we could do is just
>> | write the instances manually, of course. But that's a bit annoying.
>> |
>> | Another alternative (and also unfortunate) change is to leave `join` out
>> | of Monad, in which case the GND mechanism is oblivious to it and does
>> | not need to worry about deriving these cases.
>> |
>> | I am not sure how many packages depend
GHC API: Using runGhc twice or from multiple threads?
Hello, is the following safe to do? main = do runGhc libdir $ do ... runGhc libdir $ do ... Or will this cause trouble? Is there state that is shared between the two calls? And what about this one: main = do forkIO $ runGhc libdir $ do ... forkIO $ runGhc libdir $ do ... ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
