Re: Can we offer ~ without GADTs or type families?

As a user who frequently uses ~, but doesn't need the rest of GADTs or TypeFamilies, I'd really like to see a TypeEqualities extension! Eric On Fri, Aug 5, 2016 at 3:27 PM, Adam Gundry wrote: > On 05/08/16 19:08, David Feuer wrote: > > It seems to me that equality

Re: [commit: ghc] master: Replace some `length . filter` with `count` (02614fd)

Hi, Am Freitag, den 05.08.2016, 22:41 + schrieb g...@git.haskell.org: > commit 02614fd61f57b599c5e4fd5e85f00a4e1ce37bc7 > Author: Ömer Sinan Ağacan > Date:   Fri Aug 5 20:58:02 2016 + > > Replace some `length . filter` with `count` Well intended! I wouldn’t

Re: Can we offer ~ without GADTs or type families?

On 05/08/16 19:08, David Feuer wrote: > It seems to me that equality constraints could potentially be supported > by an implementation with neither GADTs nor type families. Type families > don't really seem to have much to do with it, and GADTs are strictly > heavier (GADTs ~=

Re: Can we offer ~ without GADTs or type families?

Good point, I hadn't considered the perspective of other compilers. In that case, I could be persuaded to introduce a separate pragma like -XTypeEqualities, and have -XGADTs and -XTypeFamilies imply -XTypeEqualities for backwards compatibility. Ryan S. On Fri, Aug 5, 2016 at 2:27 PM, Edward

Re: Deriving tweaking

Excellent! On Aug 5, 2016 2:32 PM, "Edward Kmett" wrote: > Done and done! Retroactively. How is that for service? =) > > -Edward > > On Fri, Aug 5, 2016 at 2:08 PM, David Feuer wrote: > >> I know there's been some discussion about letting users select

Re: Deriving tweaking

Done and done! Retroactively. How is that for service? =) -Edward On Fri, Aug 5, 2016 at 2:08 PM, David Feuer wrote: > I know there's been some discussion about letting users select the > deriving mechanism they want, but I'd like to propose a separate tweak to > the

Re: Can we offer ~ without GADTs or type families?

TypeOperators as a language extension doesn't require a whole lot on the behalf of implementors today. They basically just have to add fixity handling to types. This is a no-brainer for a compiler implementor. It is a simple elaboration and some extra cases to deal with in their parser. The

Re: Can we offer ~ without GADTs or type families?

Hi David, > Could we get a separate LANGUAGE pragma just for equality constraints? I think we should, and I don't think we'd even need to introduce a new pragma, since there's already a perfectly good one: -XTypeOperators! After all, there's nothing really that special about (~) other than some

Deriving tweaking

I know there's been some discussion about letting users select the deriving mechanism they want, but I'd like to propose a separate tweak to the defaults. Specifically, it's annoying to have to use three pragmas to let me write newtype Foo f a = Foo (f a) deriving (Functor, Foldable, Traversable)

Can we offer ~ without GADTs or type families?

It seems to me that equality constraints could potentially be supported by an implementation with neither GADTs nor type families. Type families don't really seem to have much to do with it, and GADTs are strictly heavier (GADTs ~= ExistentialQuantification + TypeEquality). Could we get a

Re: Request for feedback: deriving strategies syntax

Hi all, Shayan, have you written anything describing how things are going? Ben, thank you for reaching out. I am not sure about the history and the context of the discussions in this thread so far, but here is a brief description of what we intend to do and how far we have come so far. The

Re: Request for feedback: deriving strategies syntax

On 2016-08-05 11:06, Ben Gamari wrote: > Ryan Scott writes: > >> Sorry for not including the full context on that link. It's part of a >> Summer of Haskell 2016 project called Native Metaprogramming in >> Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to

RdrName and decorations

Hi all At the moment I am working through ghc-exactprint, adding a feature to add standard API annotations to any constructed AST so that it can be (pretty)-printed. One of the major headaches is the decorations on a RdrName. What I mean by this is that an item appearing in the AST as a RdrName

Re: Request for feedback: deriving strategies syntax

Ryan Scott writes: > Sorry for not including the full context on that link. It's part of a > Summer of Haskell 2016 project called Native Metaprogramming in > Haskell [1] (a.k.a. Introspective Template Haskell [2]), aiming to fix > Trac #11081 [3]. > On this note, it