Yes, I used the GHCJS code as a starting point for Remote GHCi - the
implementation of TH in Remote GHCi is very similar to GHCJS. Luite and
I have chatted about this in person, and I believe he intends to try to
merge them at some point.
Remote GHCi should make it possible to do TH with a cr
Correct, it's entirely dodgy. (I seem to remember a Note about this
somewhere, but I can't find it right now)
In any case, -fexternal-interpreter fixes this properly.
Cheers,
Simon
On 08/01/2016 05:21, Edward Z. Yang wrote:
Thanks!
In fact, I have just realized that Template Haskell does so
Hi Jan,
A few questions came up this morning while speaking Andres Loeh about
injective type families:
1. Should this feature be placed behind a LANGUAGE pragma? Afterall,
functional dependencies feel very similar and in this case we
require a pragma. Now would be the last opportunity
Ben,
> 1. Should this feature be placed behind a LANGUAGE pragma?
No, I don't think it should. I consider it a tiny addition to TypeFamilies that
is not worth
having its separate pragma. Injective TFs are fully backwards compatible, so no
existing code
will be broken.
> 2. Could you perha
Jan Stolarek writes:
> Ben,
>
>> 1. Should this feature be placed behind a LANGUAGE pragma?
>
> No, I don't think it should. I consider it a tiny addition to
> TypeFamilies that is not worth having its separate pragma. Injective
> TFs are fully backwards compatible, so no existing code
> will
Hi.
>> No, I don't think it should. I consider it a tiny addition to
>> TypeFamilies that is not worth having its separate pragma. Injective
>> TFs are fully backwards compatible, so no existing code
>> will be broken.
>>
> That being said, it does claim new syntax and consequently would be
> rath
> If I actually want to write backward-compatible type family code using
> GHC-8.0, I'd prefer
> to be able to enable TypeFamilies yet not InjectiveTypeFamilies, and have GHC
> check that I am in
> the common subset.
Good point. I wonder if others agree.
Janek
---
Politechnika Łódzka
Lodz Unive
| >> 1. Should this feature be placed behind a LANGUAGE pragma?
| >
| > No, I don't think it should. I consider it a tiny addition to
| > TypeFamilies that is not worth having its separate pragma. Injective
| > TFs are fully backwards compatible, so no existing code will be
| > broken.
|
| > If I actually want to write backward-compatible type family code
| using
| > GHC-8.0, I'd prefer to be able to enable TypeFamilies yet not
| > InjectiveTypeFamilies, and have GHC check that I am in the common
| subset.
| Good point. I wonder if others agree.
Yes I agree (see my last emai
> Is "InjectiveTypeFamilies" a good name for this? Or
> "TypeFamilyDependencies"? Or what?
My vote for "InjectiveTypeFamilies".
Janek
---
Politechnika Łódzka
Lodz University of Technology
Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej
I implemented the refactoring to run the renamer and TH splices all
first before doing any type-checking, but actually there's a problem:
Template Haskell splices can call 'reify', which needs the type
information in order to supply the information about the identifiers
in question. I can't think
I think I ran into this issue when we had the Safe Haskell annotation bug,
which is why I just disabled annotations for SH. I can't think of a way around
it unless we change the TH spec.
On 1/8/2016 8:40 PM, Edward Z. Yang wrote:
> I implemented the refactoring to run the renamer and TH splices
Bother. That's true. And it's a vital feature. Otherwise how do we do
data T = T1 | T2
$(makeLenses 'T)
So we can't separate the two after all. Sorry -- I totally forgot about that.
Very annoying.
Simon
| -Original Message-
| From: Edward Z. Yang [mailto:ezy...@mit.
13 matches
Mail list logo
