Re: [commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)

: Austin Seipp aus...@well-typed.com Date: Tue Sep 24 23:20:35 2013 -0500 Add fmapCoerce to Functor class. This allows coercions to work under functors that are not locally known. Authored-by: Edward Kmett ekm...@gmail.com Signed-off-by: Austin Seipp aus...@well-typed.com

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

Am I correct in understanding your issue arises from manually rolled instances of Generic, not from Generic itself? Wouldn't then perhaps the better fix be to resurrect the old rule for derived Typeable instances and apply it to Generic and Generic1 instead? The new rule would be that if you

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

wrote: On Mon, Oct 7, 2013 at 10:22 AM, Edward Kmett ekm...@gmail.com wrote: Am I correct in understanding your issue arises from manually rolled instances of Generic, not from Generic itself? Exactly. Wouldn't then perhaps the better fix be to resurrect the old rule for derived Typeable

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

, -Ryan On Mon, Oct 7, 2013 at 12:44 PM, Edward Kmett ekm...@gmail.com wrote: I'd much rather have code that can compile as Safe rather than Trustworthy. Trustworthy code is a pain to annotate the safety of correctly. A one line change to GHC to ensure the safety of GHC.Generics

Re: small improvement to roles mechanism

I have to agree that I'm somewhat disturbed by the fact that we're pushing this out and we're still finding issues with it this close to release. =( It strikes me that the role machinery is going to be the cause of the majority of the pain users have upgrading to 7.8, and if I try to pretend to

Re: More GND + role inference woes

of GND in the code I maintain has something in it that causes it to run afoul of the new roles machinery. I'd say the problem is more widespread than we thought. -Edward On Sun, Oct 13, 2013 at 5:26 PM, Edward Kmett ekm...@gmail.com wrote: Ben Gamari was trying to update my linear package

Re: Wither Haskell Platform 2013.4.0.0

As I do most of my development on a Mac I confess I currently live in fear of accidentally clicking on the XCode 5 upgrade button and winding up in an unsupported configuration. That makes me very leery of option C, where developers like me are treading on egg-shells around system updates for the

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

The issue with such an explicit false is that it requires more magic on behalf of the compiler. It would have to be filled in whenever an explicit `instance Eq Blah` was written. Recall that deriving instance Eq Blah can occur after the data type declaration site and may have to be used for

Re: small improvement to roles mechanism

. In any case, as in my last email, I think we know how to fix the issues that are paining you. I agree that it is worth doing this before the release. Does that sound ok? Simon From: Edward Kmett [mailto:ekm...@gmail.com] Sent: 12 October 2013 18:25 To: Simon Peyton-Jones Cc

Re: More GND + role inference woes

If this forced me to write those instances by hand, I could accept that as a tax for correctness. It means you can't GND any of the HasFoo dictionaries that lens builds, but meh. My original objection was for the existing solution with type classes themselves having their arguments be

Re: More GND + role inference woes

email that the change to the GND check will not solve *all* your problems? That is, there will be some derived instances you will have to hand-write, but (I think) for good reason. Richard On Oct 16, 2013, at 12:46 PM, Edward Kmett wrote: On Oct 16, 2013, at 9:28 AM, Simon Peyton-Jones

Re: Why do we put GMP allocations on GHC heaps?

Not suggesting we actually switch, but there is one strong 'why': You can't link Haskell code with any library that uses GMP internally internally without switching to using integer-simple. I've been trying with very limited success to get good MPFR bindings for Haskell for ~3 years now as a

Re: Why do we put GMP allocations on GHC heaps?

microscopes, spectrographs, etc. -Edward On Wed, Oct 23, 2013 at 9:45 AM, Gergely Risko gerg...@risko.hu wrote: On Tue, 22 Oct 2013 20:26:53 -0400, Edward Kmett ekm...@gmail.com writes: Not suggesting we actually switch, but there is one strong 'why': You can't link Haskell code with any

Re: More GND + role inference woes

Correct. With 7.8 we'll need to hand-implement those instances rather than derive them. On Sat, Dec 14, 2013 at 7:59 PM, Ben Gamari bgamari.f...@gmail.com wrote: Richard Eisenberg e...@cis.upenn.edu writes: Yes, I believe that's right. As far as I can figure out, these classes really

Re: Renaming Void#

The change makes sense to me. Others? On Tue, Dec 17, 2013 at 1:28 PM, Krzysztof Gogolewski krz.gogolew...@gmail.com wrote: Hello, Small bikeshedding: I propose to rename recently added Void# (in GHC.Prim) to Unit#, and void# to unit#. As far as I understand, this type is the unboxed

Re: PLT Redex definition of STG as per fast curry paper

Neat! I wish we'd had this a couple of years ago when Dylan Lukes was playing around with his STG-like toy. -Edward On Wed, Jan 15, 2014 at 4:34 PM, Edward Z. Yang ezy...@mit.edu wrote: For those of you who aren't following the commit list, I've just pushed a PLT Redex

Re: Standalone Deriving, GND and roles in 7.8.1-rc2

As usual I'm the source of more headaches for Richard. ;) -Edward On Wed, Mar 5, 2014 at 3:57 PM, Sergei Trofimovich sly...@gmail.com wrote: On Wed, 5 Mar 2014 15:40:27 -0500 Richard Eisenberg e...@cis.upenn.edu wrote: I think those should be the same and that you've discovered a bug.

Re: Proposal: Partial Type Signatures

Clearly given that term-level holes are called TypeHoles, the extension to enable these should be called KindHoles. =) Er.. I'll show myself out. -Edward On Wed, Mar 12, 2014 at 9:35 AM, Thomas Winant thomas.win...@cs.kuleuven.be wrote: Dear GHC developers, Together with Tom Schrijvers,

Re: Proposal: Partial Type Signatures

I'd just like to echo that I really like Austin's suggestion as well, as it very nicely unifies the two usecases, while simultaneously *not *dramatically increasing scope. -Edward On Thu, Mar 13, 2014 at 4:56 PM, Richard Eisenberg e...@cis.upenn.eduwrote: First of all: Yay! I've been wanting

Re: FFI: c/c++ struct on stack as an argument or return value

I spent some time hacking around on this from a library perspective when I had to interoperate with a bunch of Objective C on a 64-bit mac as many of the core library functions you need to FFI out to pass around pairs of Int32s as a struct small enough by the x64 ABI to get shoehorned into one

Re: FFI: c/c++ struct on stack as an argument or return value

On Fri, Mar 14, 2014 at 2:00 PM, Yuras Shumovich shumovi...@gmail.comwrote: On Fri, 2014-03-14 at 09:08 -0400, Edward Kmett wrote: I spent some time hacking around on this from a library perspective when I had to interoperate with a bunch of Objective C on a 64-bit mac as many

Re: FFI: c/c++ struct on stack as an argument or return value

I don't care enough to fight and try to win the battle, but I just want to point out that Storable structs are far more brittle and platform dependent than borrowing the already correct platform logic for struct passing from libffi. I do think the existing FFI extension made the right call under

Re: Haddock strings in .hi files

One strong reason for considering at least including the haddocks in the .hi files is build times. Currently if you have cabal configured to build and document every package running hackage requires you to recompile your entire source tree a second time to get information that we just dropped on

Re: Haddock strings in .hi files

/whatever it needs the rest of the GHC API I'd be totally open that as well. -Edward On Thu, Mar 20, 2014 at 12:18 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: On 20/03/14 16:08, Edward Kmett wrote: One strong reason for considering at least including the haddocks in the .hi files

Re: Haddock strings in .hi files

On Fri, Mar 21, 2014 at 7:38 AM, Simon Marlow marlo...@gmail.com wrote: Ok, I buy the argument that if we're already compiling everything, we shouldn't have to re-typecheck it all in Haddock. Of course if you're *not* already compiling everything, then the argument doesn't apply: Haddock does

Re: [commit: packages/template-haskell] master: Make Pred a type synonym of Type (issue #7021) (57b662c)

Thanks. That'll let me make it clearer in my patches to work around the this on my side that the source of the workarounds is the changes to the template-haskell package. -Edward On Sun, Mar 23, 2014 at 5:37 AM, Herbert Valerio Riedel hvrie...@gmail.comwrote: On 2014-03-23 at 04:40:14 +0100,

Re: We need to add role annotations for 7.8

Mark, We're currently planning to retain the existing behavior of GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe Haskell and GND still won't mix in 7.8 due to these same security concerns. I think a key observation with regards to GeneralizedNewtypeDeriving is with

Re: We need to add role annotations for 7.8

Personally, looking at it 10 years on, having a nominal default would look pretty terrible to me. I'd be stuck annotating everything I write. Nothing easy could just be easy. The 10 years on crowd is a reasonable argument for a real type role syntax, and it was indeed that argument that won me

Re: Trac seems to think I'm a spambot...?

What is Simon's middle name? Is Peyton not part of his surname? Oh crap. I'm a bot. Sent from my iPad On Apr 7, 2014, at 10:53 AM, Daniel Trstenjak daniel.trsten...@gmail.com wrote: On Mon, Apr 07, 2014 at 09:27:32PM +0700, Kim-Ee Yeoh wrote: What if we replace captcha with a short,

Re: [core libraries] RE: Avoiding bumping the major version of base in every release

The current plan with breaking up base is mostly to push it out until we get the lower hanging fruit out of the way for 7.10, and to start moving forward more aggressively on that around 7.12. Back at ICFP we made the call to more or less take greater ownership of base upon the release of 7.8.

Re: Proposal - Foreign enum support

-1 from me. Your first example even provides a counter-example. typedef enum { IMG_INIT_JPG = 0x0001, IMG_INIT_PNG = 0x0002, IMG_INIT_TIF = 0x0004, IMG_INIT_WEBP = 0x0008 } IMG_InitFlags; Those are defined as powers of two because

Re: Relocating (some of) GHC's core-libraries to github.com/haskell

I would really like that as well. My experience is it is rather easy to get users to put together a pull request through github. It is rather more like pulling teeth to get them to use git properly and put together a traditional patch. This would greatly open up the workflow for end users

Re: GHC status report

On Thu, May 1, 2014 at 5:30 PM, Simon Marlow marlo...@gmail.com wrote: We should fix this (or at least make it a lot less likely). Is there a ticket? Not yet. I just converted to 7.8.2 the other day (I'd been running the release candidate) and wanted to duplicate the problem first. I haven't

Re: GHC status report

the library being loaded. If your C++ practices there forbid static initializers -- some places do -- that may be why you aren't seeing the issue. -Edward On Fri, May 2, 2014 at 9:47 AM, Simon Marlow marlo...@gmail.com wrote: On 02/05/2014 14:28, Edward Kmett wrote: Perhaps. We actually tried

Re: GHC status report

On May 2, 2014, at 9:05 AM, Simon Marlow marlo...@gmail.com wrote: On 02/05/2014 00:46, Edward Kmett wrote: With the old custom linker we weren't able to get our custom MPFR linked in properly on all platforms for use in ghci. On Macs we ran into some rather interesting problems. We

Re: Bugsquashing at ZuriHac

I'll be there, and more than willing to help on the open core library issues for base and the like. -Edward On Wed, May 7, 2014 at 10:54 PM, Joachim Breitner m...@joachim-breitner.dewrote: Dear fellow deverlopers, I’ll be attending ZuriHac in a month time, without a project of my own that

Re: Adding atomic primops

I'd be pretty comfortable relying on the existing implementation for now as long as we know it is the sort of thing we should shore up before too long. Ultimately Threads Cannot Be Implemented As a Libraryhttp://www.cs.nmsu.edu/~scooper/CS574/papers/threads-library.pdfbut you can fake it for a

Re: Question about Roles and the AMP work

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

Parallelizing the Weak Pointer Lock

How hard *would* it be to replace the global weak pointer lock with something that scales better? I'm looking at switching some of my older BDD code into Haskell. To do so I'd love to be able to use an intuitive weak-pointer based cache management scheme, but I have to confess the notion of a

Re: Parallelizing the Weak Pointer Lock

bad. -Edward On Thu, May 29, 2014 at 3:38 AM, Simon Marlow marlo...@gmail.com wrote: On 28/05/2014 12:16, Edward Kmett wrote: How hard /would/ it be to replace the global weak pointer lock with something that scales better? I'm looking at switching some of my older BDD code into Haskell

Fwd: Regression in the typechecker in GHC 7.8.2

Forwarding to haskell-infrastructure. -- Forwarded message -- From: Simon Peyton Jones simo...@microsoft.com Date: Mon, Jun 16, 2014 at 8:59 AM Subject: RE: Regression in the typechecker in GHC 7.8.2 To: o...@okmij.org o...@okmij.org, ghc-devs@haskell.org ghc-devs@haskell.org

Re: New GHC feature proposal: Pattern families

the proposal with Edward Kmett who suggested an example with | prisms and that I contact you two for comments. The syntax is still in | flux. | | Some motivating examples for your consideration. | | PRISM PATTERNS | | Edward suggested a pattern to match a prism which would look like

Re: GHC silently turns off dynamic output, should this be an error?

I wonder if this is the source of the problem I had with ^C'ing parallel rebuilds. I'll often build, realizing I should be doing something differently, ^C out, tweak something start a build again, etc. but if I have -j on then I find that doing so occasionally causes me to start missing dyn_hi

Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code

That has a high chance of backfiring and requiring everyone to use do { ...; ... } with explicit braces and semis. ;) -Edward On Wed, Jul 2, 2014 at 4:08 AM, Simon Marlow marlo...@gmail.com wrote: Agreed, let's do it. Thanks for the well-argued proposal. Next up: consistent style :-)

Re: Broken Data.Data instances

Philip, Alan, If you need a hand, I'm happy to pitch in guidance. I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used to be built this way before I convinced the authors to switch to safer versions of Data. Using virtual smart constructors

Re: Broken Data.Data instances

it resolved, it is a huge hindrance for HaRe. Alan On Sun, Jul 27, 2014 at 7:27 PM, Edward Kmett ekm...@gmail.com wrote: Philip, Alan, If you need a hand, I'm happy to pitch in guidance. I've had to mangle a bunch of hand-written Data instances and push out patches to a dozen packages that used

Re: Overlapping and incoherent instances

Now if only we could somehow find a way to do the same thing for AllowAmbiguousTypes. :) I have a 2500 line file that I'm forced to turn on AllowAmbiguousTypes in for 3 definitions, and checking that I didn't accidentally make something else ambiguous to GHC's eyes is a rather brutal affair. (I

Re: [core libraries] RE: Core libraries bug tracker

Hi Simon, If you don't mind the extra traffic in the ghc trac, I'm open to the plan to work there. I was talking to Eric Mertens a few days ago about this and he agreed to take lead on getting us set up to actually build tickets for items that go into the libraries@ proposal process, so we have

Re: Random maintainership -- Was: [core libraries] RE: Core libraries bug tracker

/*” stuff with “Core Libraries”. Thanks Simon From: haskell-core-librar...@googlegroups.com [mailto: haskell-core-librar...@googlegroups.com] On Behalf Of Edward Kmett Sent: 19 August 2014 16:23 To: Simon Peyton Jones Cc: core-libraries-commit...@haskell.org; ghc-devs

Re: [commit: ghc] master: Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` (f636faa)

Hrmm. I wonder if that is in part caused by the inefficient use of sequence in https://github.com/ghc/nofib/blob/master/spectral/fibheaps/Main.lhs#L234 If that sequence . map is swapped for a traverse, what happens? -Edward On Mon, Sep 29, 2014 at 3:44 AM, Joachim Breitner

Re: [core libraries] RE: Is USE_REPORT_PRELUDE still useful?

I could definitely see moving the code to comments. Sent from my iPad On Oct 29, 2014, at 4:45 AM, Simon Peyton Jones simo...@microsoft.com wrote: Adding core-libraries, whose bailiwick this is. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David Feuer Sent:

Re: Is USE_REPORT_PRELUDE still useful?

Ack! That -is- a somewhat scary invisible backdoor dependency. :/ We ripped out a lot of unused and untestable ifdefs for other compilers from base a couple of years back, I'd be curious if this was already affected. Any idea where the code for the report generation lies? -Edward On Oct 29,

Re: [core libraries] RE: Core libraries bug tracker

Alternately, I can make a blanket decree that anyone can feel free to steal any ticket from me at any time as I mostly work through hvr, dfeuer, and thoughtpolice anyways to chip away at these. I lack a strong preference either way. -Edward On Sun, Nov 2, 2014 at 5:19 AM, Thomas Miedema

Re: [core libraries] RE: Core libraries bug tracker

Of *Edward Kmett *Sent:* 02 November 2014 14:49 *To:* Thomas Miedema *Cc:* core-libraries-commit...@haskell.org; ghc-devs@haskell.org *Subject:* Re: [core libraries] RE: Core libraries bug tracker Alternately, I can make a blanket decree that anyone can feel free to steal any ticket from me

Re: Concrete syntax for pattern synonym type signatures

One note on the syntax front, 'pattern type' was mentioned as annoyingly trying to shoehorn the word 'type' in to lean on an existing keyword, even though its about a term level construction rather than a type level one. We do have some perfectly serviceable keywords available to us that indicate

Re: Concrete syntax for pattern synonym type signatures

On Sun, Nov 9, 2014 at 2:11 PM, Simon Peyton Jones simo...@microsoft.com wrote: On this thread: * I'm strongly of the opinion that pattern signatures should start pattern P :: ...blah... Just like value signatures, the pattern name comes first, then a double colon. This has

Re: Concrete syntax for pattern synonym type signatures

Note though, it doesn't mean the same thing to say (Foo a, Bar a b) = ... as it does to say Foo a = Bar a b = ... The latter can use Foo a when working on Bar a b, but not Bar a b to discharge Foo a, which makes a difference when you have functional dependencies. So in some sense the 'pattern

Re: Windows breakage

David recently added a new -Wall flag for Trustworthiness. The reasoning is if it is in -Wall, it can actually get seen and will be used by folks to improve more things from 'Trustworthy' to 'Safe'. After all, everything that is merely `Trustworthy` needs to live in the trusted computing base.

Re: how to write a ghc primop that acts on an unevaluated argument?

Maybe test for laziness in the argument by just putting something in that goes boom when forced, e.g. 'undefined'? On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey All, as part of trying to get some fixups for how prefetch works into 7.10, i'm adding a

Re: help wrt semantics / primops for pure prefetches

My general experience with prefetching is that it is almost never a win when done just on trees, as in the usual mark-sweep or copy-collection garbage collector walk. Why? Because the time from the time you prefetch to the time you use the data is too variable. Stack disciplines and prefetch don't

Re: help wrt semantics / primops for pure prefetches

real speedups in Haskell, I will be less sceptical from now on :) Cheers, Simon On 27/11/2014 10:20, Edward Kmett wrote: My general experience with prefetching is that it is almost never a win when done just on trees, as in the usual mark-sweep or copy-collection garbage collector walk. Why

Re: Arrow notation and GHC 7.10 freeze

We typically have a year between releases, so in the absence of anything contradictory I'd expect the freeze for that to be about this time next year. -Edward On Wed, Dec 3, 2014 at 9:17 AM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Dienstag, den 02.12.2014, 13:27 + schrieb

Re: are patterns synonyms definable in GHCI?

ghci also accepts a number of other things. You can define data types, type synonyms, classes, instances, so pattern synonyms would seem to fall into scope. On Thu, Dec 18, 2014 at 5:51 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: On Thu, 18 Dec 2014, Carter Schonwald wrote: Hey all,I was trying

Re: GHC support for the new record package

On Fri, Jan 23, 2015 at 5:06 PM, Adam Gundry a...@well-typed.com wrote: Thanks for the feedback, Iavor! On 23/01/15 19:30, Iavor Diatchki wrote: 2. I would propose that we simplify things further, and provide just one class for overloading: class Field (name :: Symbol)

Re: GHC support for the new record package

everyone. # is not that common of an operator. I would much rather upset a few people by taking that operator back when they opt-in to turning the extension on than having a worse records implementation. On Fri, Jan 23, 2015 at 2:23 PM, Edward Kmett ekm...@gmail.com wrote: On Fri, Jan 23, 2015

Re: GHC support for the new record package

On Wed, Jan 21, 2015 at 1:06 PM, Adam Gundry a...@well-typed.com wrote: Also, I'd add fields with higher-rank types to the list of missing features. From a user's perspective, it might seem a bit odd if data T = MkT { foo :: forall a . a } was fine but data T = MkT {| foo ::

Re: GHC support for the new record package

On Wed, Jan 21, 2015 at 4:34 PM, Adam Gundry a...@well-typed.com wrote: I'm surprised and interested that you view this as a major source of complexity. From my point of view, I quite liked how the ability to overload fields as both selector functions and arbitrary lenses turned out. Compared

Re: GHC support for the new record package

I'm generally positive on the goal of figuring out better record support in GHC. That said, it isn't clear that Nikita's work here directly gives rise to how the syntax of such a thing would work in GHC proper. Simon's original proposal overloaded (.) in yet more ways that collide with the uses

Re: GHC support for the new record package

Personally, I think the two proposals, ORF and Nikita's record approach address largely differing needs. The ORF proposal has the benefit that it doesn't require GHC itself to know anything about lenses in order to work and is mostly compatible with the existing field accessor combinators.

Re: GHC support for the new record package

On Wed, Jan 21, 2015 at 4:36 AM, Simon Marlow marlo...@gmail.com wrote: On 20/01/2015 23:07, Edward Kmett wrote: It is a long trek from this is plausible to hey, let's bet the future of records and bunch of syntax in the language on this. Absolutely. On the other hand, this is the first

Re: GHC support for the new record package

On Thu, Jan 22, 2015 at 4:31 AM, Adam Gundry a...@well-typed.com wrote: Actually, the simplifications I recently came up with could allow us to make uses of the field work as van Laarhoven lenses, other lenses *and* selector functions. In practice, however, I suspect this might lead to

Re: Seeking an active maintainer for 'directory'

(if the involved parties aren't opposed). I'm also somewhat more familiar with the POSIX side of things, though it wouldn't hurt me to brush up on my Win32. -- Elliot Robinson GPG Key: 9FEDE59A On 02/17/15, Edward Kmett wrote: And we have a winner. Thanks, Phil. If you need any help from

Seeking an active maintainer for 'directory'

The 'directory' package could use an active maintainer. Currently, the package falls to the Core Libraries Committee for maintenance, but we've had a number of issues accrete for the directory package over the last six months or so, which need some attention to detail and a good understanding of

Re: GHC support for the new record package

, the solution there feels quite heavy, though. -Edward Adam On 27/01/15 00:59, Edward Kmett wrote: I'm also rather worried, looking over the IV proposal, that it just doesn't actually work. We actually tried the code under Haskell 98 records back when Gundry first started his proposal and it fell

Re: GHC support for the new record package

On Tue, Jan 27, 2015 at 6:12 AM, Simon Peyton Jones simo...@microsoft.com 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

Re: [core libraries] tyConHash -- quick fix?

I like your idea of using tyConHash for the Int version and tyConFingerprint to refer to the Fingerprint. The former fits more closely with the usage elsewhere e.g. hashUnique, hashStableName. -Edward On Wed, Mar 11, 2015 at 5:39 AM, Simon Peyton Jones simo...@microsoft.com wrote: data TyCon

Re: HP 2015.2.0.0 and GHC 7.10

On Mon, Mar 23, 2015 at 4:35 AM, Sven Panne svenpa...@gmail.com wrote: 2015-03-23 6:13 GMT+01:00 Mark Lentczner mark.lentcz...@gmail.com: [...] exceptions multipart - needed by cgi - is exceptions now subsumed by something in transformers? [...] Coincidentally, Edward Kmett pointed me

Re: traverse_

We deliberately took no more symbols than we needed in 7.10 from Prelude as part of the Foldable/Traversable Proposal. There are multiple combinators in Data.Foldable and Data.Traversable that we do not export. traverse_ is one of them as, strictly speaking, traverse_ was a symbol we didn't have

Re: wither the Platform

On Fri, Mar 27, 2015 at 10:09 AM, Mark Lentczner mark.lentcz...@gmail.com wrote: But that is true of GHC as well. We need to stop having the attitude of Platform is for newcomers / GHC is for heavyweights. It is perfectly fine to announce GHC 7.10.1 is out - you can install it from Platform

Re: HP 2015.2.0.0 and GHC 7.10

I'm personally a rather vocal proponent of the new OpenGL API changes. I'd also in general favor a policy of greater trust when it comes to library authors factoring out bits of their packages even once they become part of the platform. We all want our code to work together. The hand-wringing

Re: Delaying 7.10?

I personally would rather see this issue given the time to be resolved correctly than rush to release 7.10 now because of a self-imposed deadline. An unsafeCoerce bug, especially one which affects SafeHaskell, pretty much trumps all in my eyes. -Edward On Thu, Jan 29, 2015 at 2:54 PM, Austin

Re: Tracking bugs for libraries

Hoopl didn't exist when the page was first created. I'm not sure if it should be considered a core library or not, honestly. If so, then it probably belongs on that page. If not, then it is probably worth documenting more clearly somewhere where its issues are tracked. -Edward On Wed, May 6,

Re: Tracking bugs for libraries

On May 5, 2015, at 7:30 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I just noticed that bugs for several of our libraries can either be tracked on Trac (there is a corresponding entry in the Component field) or on github (issue tracking for that library is enabled in the repo).

Re: MonadFail proposal (MFP): Moving fail out of Monad

+1 from me for both the spirit and the substance of this proposal. We've been talking about this in the abstract for a while now (since ICFP 2013 or so) and as concrete plans go, this strikes me as straightforward and implementable. -Edward On Tue, Jun 9, 2015 at 10:43 PM, David Luposchainsky

Re: MonadFail proposal (MFP): Moving fail out of Monad

I can give a couple of rather academic issues that the status quo causes: An example of where this has bit us in the hindquarters in the past is that the old Error class based instance for Monad (Either a) from the mtl incurred a constraint on the entire Monad instance in order to support 'fail'.

Re: MFP updates: ideas worth discussing

There is a bit of a knee-jerk reaction that we should go to something simpler than Monad as a superclass constraint for MonadFail, but I think most of those reasons fall apart or at least lose much of their weight upon deeper inspection. Ultimately, I'm a not concerned about interactions between

Re: Abstract FilePath Proposal

Worse there are situations where you absolutely _have_ to be able to use \\?\ encoding of a path on Windows to read, modify or delete files with impossible names that were created by other means. e.g. Filenames like AUX, that had traditional roles under DOS cause weird interactions, or that were

Re: Handling overflow and division by zero

You should be able to reduce the bit-twiddling a great deal IIRC in the word case. SW a + SW b | c - a + b, c = min a b = SW c | otherwise = throw Overflow There is a similar trick that escapes me at the moment for the signed case. On Sun, Jun 28, 2015 at 6:15 PM, Nikita Karetnikov

Re: ArrayArrays

On Fri, Aug 21, 2015 at 9:49 AM, Ryan Yates fryguy...@gmail.com wrote: Hi Edward, I've been working on removing indirection in STM and I added a heap object like SmallArray, but with a mix of words and pointers (as well as a header with metadata for STM). It appears to work well now, but

ArrayArrays

Would it be possible to add unsafe primops to add Array# and SmallArray# entries to an ArrayArray#? The fact that the ArrayArray# entries are all directly unlifted avoiding a level of indirection for the containing structure is amazing, but I can only currently use it if my leaf level data can be

Re: ArrayArrays

. -Edward On Thu, Aug 20, 2015 at 9:01 PM, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: That’s an interesting idea. Manuel Edward Kmett ekm...@gmail.com: Would it be possible to add unsafe primops to add Array# and SmallArray# entries to an ArrayArray#? The fact

Re: Unlifted data types

The idea of treating !S as a subtype of S and then relying on the potential for new impredicativity machinery to let us just talk about how !S <= S makes me really happy. data Nat = Z | S !Nat Pattern matching on S could give back the tighter type !Nat rather than Nat for the argument, and if we

Temporarily pinning a thread to a capability

Would anything go wrong with a thread id if I pinned it to a capability after the fact? I could in theory do so just by setting tso->flags |= TSO_LOCKED and then disabling this later by restoring the TSO flags. I can't think of anything but I figured folks here might be able to think of

Re: Unlifted data types

On Wed, Oct 28, 2015 at 9:19 AM, Richard Eisenberg <e...@cis.upenn.edu> wrote: > I don't have terribly much to add, but I do want to counter one point: > > On Oct 28, 2015, at 5:48 AM, Edward Kmett <ekm...@gmail.com> wrote: > > There are situations where we are truly

Re: Temporarily pinning a thread to a capability

, 2015 at 4:28 PM, Ryan Yates <fryguy...@gmail.com> wrote: > A thread with TSO_LOCKED can be migrated if the number of capabilities > decreases. > > Ryan > > On Tue, Oct 27, 2015 at 11:35 PM, Edward Kmett <ekm...@gmail.com> wrote: > >> Would anythin

Re: Unlifted data types

On Wed, Oct 28, 2015 at 5:05 AM, Simon Peyton Jones wrote: > I'm out of bandwidth at the moment, but let me just remark that this is > swampy territory. It's easy to mess up. > > A particular challenge is polymorphism: > > map :: forall a b. (a->b) -> [a] -> [b] > map

Re: too many lines too long

Heck, I've been able to use 132 columns since my VT-220 days. ;) -Edward On Mon, Nov 9, 2015 at 5:45 PM, Simon Peyton Jones wrote: > In my view 80 chars is too short. It was justified in the days of > 80-column CRTs, but that just isn't a restriction any more. I

Re: Pre-Proposal: Introspective Template Haskell

In practice I find that almost every piece of template-haskell code I've written gets broken by something every other release of GHC, so it hasn't exactly been a shining beacon of backwards compatibility thus far. Invariably it is always missing _something_ that I need, and anything that ties it

Re: Pre-Proposal: Introspective Template Haskell

That would be a sufficient "horrible backdoor" for me. :) -Edward > On Nov 11, 2015, at 3:03 PM, Richard Eisenberg <e...@cis.upenn.edu> wrote: > > >> On Nov 11, 2015, at 2:25 PM, Edward Kmett <ekm...@gmail.com> wrote: >> >> As a data point, in

Re: Pre-Proposal: Introspective Template Haskell

On Wed, Nov 11, 2015 at 12:50 PM, Richard Eisenberg wrote: > > This is a very good point. We would want to bless some API that would > remain stable. Then, clients that go around that API get what they deserve. > A starting point for the stable API would be today's

  1   2   >