(Disclaimer: I have never used hs-to-coq before, so everything below is
merely an educated guess.)
Looking at the source code for hs-to-coq, I see this [1]:
addDerivedInstances :: GhcMonad m => TypecheckedModule -> m
> TypecheckedModule
> addDerivedInstances tcm = do
> let Just (hsgroup, a,
* Performance, optimisation and benchmarking
* Virtual machines and run-time systems
* Libraries and tools for development or deployment
Contact
---
* Ryan Scott
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman
Apologies, that should read *July* 16, not June 16, for the submission
deadline at the top of the email. (The body of the email contains the
correct date.)
Best,
Ryan
On Mon, Jul 10, 2023 at 6:34 PM Ryan Scott wrote:
> TL;DR: The submission deadline for the 2023 Haskell Implementors' Works
-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.
Program Committee
-
* Gergő Érdi (Standard Chartered Bank)
* Sebastian Graf (Karlsruhe Institute of Technology)
* Wen Kokke (University of Strathclyde)
* Ryan Scott
,
Ryan
On Mon, Jun 5, 2023 at 7:47 AM Ryan Scott wrote:
> The 2023 Haskell Implementors' Workshop deadline is just under one month
> away. We are looking forward to your talk submissions.
>
> Best,
>
> Ryan
>
> ==
>
> ACM SIGPLAN
of Strathclyde)
* Ryan Scott (Galois, Inc.)
* Rebecca Skinner (Mercury)
* Li-yao Xia (University of Edinburgh)
Contact
---
* Ryan Scott
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-
* Gergő Érdi (Standard Chartered Bank)
* Sebastian Graf (Karlsruhe Institute of Technology)
* Wen Kokke (University of Strathclyde)
* Ryan Scott (Galois, Inc.)
* Rebecca Skinner (Mercury)
* Li-yao Xia (University of Edinburgh)
Contact
---
* Ryan Scott
> One peculiarity with the ordering is that linkers only search static
> archives for existing undefined references. If the reference to `Cffi`
> actually comes first, then nothing should be required from it yet and
> *it shouldn't be linked* (absent options like GNU ld's
> `--whole-archive`).
://github.com/remiturk/libffi/issues/6
On Tue, Aug 9, 2022 at 9:58 AM Ryan Scott wrote:
> No, I'm using macOS 10.15.7 (BuildVersion 19H2) on an x86_64 machine.
>
> Ryan
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi
No, I'm using macOS 10.15.7 (BuildVersion 19H2) on an x86_64 machine.
Ryan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Possibly? I'm not familiar with the system cache you're referring to, but
it's a more solid lead than what I have currently. Do you know how one
would confirm if this is the case or not?
Ryan
___
ghc-devs mailing list
ghc-devs@haskell.org
I should clarify that I'm using a borrowed macOS on which I don't have
admin privileges, so I'm unable to install pkg-config. As a result, I'm
commenting out the pkgconfig-depends: line in libffi.cabal and manually
specifying the extra-lib-dirs and include-dirs via a cabal.project.local
file.
I'm trying to diagnose strange GHC linking behavior which, as far as I can
tell, only occurs on macOS. I feel a bit out of my league debugging this,
so I'm hoping someone knows what is causing this.
When building the Haskell libffi library [1], it will link pass -lffi to
GHC. Typically, most
One thing that wasn't included in the list but arguably should be is #21618
(Loading libc++ in ghci results in segfaults). As far as I am aware, this
renders GHC 9.4 unusable on Windows for libraries that link against C++.
(Or, at the very least, I haven't figured out a way to make it work.)
> I figured out that this compiles:
>
> data HKD (f :: Type -> Type) = Foo (F1 Int f) (F1 Double f)
> | Bar (F1 Bool f)
> deriving Generic1
>
> newtype F1 a f = F1 { unF1 :: f a }
Yes, that's a useful trick to keep in mind. For what it's worth, I think
your `F1` is the same thing as `Barbie`
but the applied type is not of kind * -> *, and
> Constructor ‘Bar’ applies a type to an argument involving the last
> parameter
> but the applied type is not of kind * -> *
> • In the data declaration for ‘HKD’
> |
> 7 | deriv
Hello,
I'm not quite sure I understand the issue you're hitting. Generic1 is
poly-kinded, so I would expect it to be able to handle data types where the
last type parameter has differing kinds. Can you post a complete example of
the program you expect to typecheck, but doesn't?
Best,
Ryan
Since yesterday, I haven't been receiving any e-mail notifications from
GitLab. Are other people having this problem too, or is it a problem on my
end?
Ryan S.
___
ghc-devs mailing list
ghc-devs@haskell.org
!2965 [1] seeks to improve the performance of derived Generic(1) instances
by heuristically annotating implementations of the from(1) and to(1) class
methods with INLINE[1] pragmas. For the most part, this results in
performance wins, as the generic intermediate representations of data types
can
> Ryan, the comment in GHC.Tuple seems to be misleading today, as
suggested by this SO post:
https://stackoverflow.com/questions/46412823/why-are-ghc-tuples-limited-to-size-62
> I was going to add it to the comment at some point but was hesitant as I
hadn’t verified the information myself.
For
/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170
On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari wrote:
> On September 25, 2020 6:21:23 PM EDT, Ryan Scott
> wrote:
> ...
> >However, I discovered recently that there are places where GHC *does*
> >
GHC imposes an upper bound of 62 on the size of tuples one can use [1].
Currently, this upper bound applies to both boxed and unboxed tuples alike.
For example, if you try to create an unboxed tuple of arity 64, then GHC
will throw an error:
error:
A 64-tuple is too large for GHC
I think that HsPragTick is unused as of [1]. In fact, I was under the
impression that [1] removed HsPragTick entirely (as the commit message)
would suggest, but upon further inspection, that doesn't appear to be the
case. Vlad, do you recall why HsPragTick was kept around?
Ryan S.
-
[1]
> And while Simon is the only
> one I'm aware of, for whom this breaks
For what it's worth, I am hitting the same issue when building GHC.
Ryan S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Just as an FYI, there appears to be some data loss from this migration. For
example, I pushed a commit to !3536 [1] that appears to have been dropped,
leading to confusion here [2]. To make things worse, I never received an
e-mail notification for this comment—I only discovered it by chance.
I
Thanks Ben!
For future reference, is there anything that we as ordinary GHC
developers can do to help Marge along when she gets stuck on stat
changes? You mentioned that you amended a Marge batch to accept the
changes before. Are there instructions on how to do this properly? For
instance, which
Something strange is still going on, since Marge now just opened an
empty merge batch [1].
Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3465
On Mon, Jun 8, 2020 at 9:37 AM Ben Gamari wrote:
>
> Ryan Scott writes:
>
> > Hello,
> >
> > I've b
Hello,
I've been receiving a flurry of e-mails all weekend about Marge Bot
failing to validate a batch on CI. Moreover, the failures appear to be
consistent each time. From the most recent one [1]:
Unexpected stat failures:
/builds/ghc/ghc/tmp/ghctest-mel1y5lo/test
No particular reason. There is an accepted GHC proposal to relax this
restriction [1], as well as an accompanying GHC issue [2], but it has not
yet been implemented.
Ryan S.
-
[1]
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-unrestricted-overloadedlabels.rst
[2]
Hi Simon,
As #18018 says, you need to use head.hackage to reproduce it. This
page [1] contains a rather short tutorial on how to use it, but Ben is
currently drafting a more detailed tutorial on its use here [2]. This
is what I use whenever building any Hackage library with GHC HEAD.
Ryan S.
There appears to be an account [1] that is submitting spam as GitLab
issues. I've noticed the following spam issues so far:
* https://gitlab.haskell.org/ghc/ghc/issues/17664
* https://gitlab.haskell.org/ghc/ghc/issues/17666
* https://gitlab.haskell.org/haskell/ghcup/issues/125
*
mpredicativeTypes. The whole example, therefore, is:
>
> {-#LANGUAGE ImpredicativeTypes, ConstraintKinds #-}
> module M where
> type F f = (Functor f, forall a. Eq (f a))
>
> --
> Best, Artem
>
> On Fri, 19 Jul 2019 at 09:18, Ryan Scott wrote:
>>
>> I have another
I have another interesting application of guarded impredicativity that
I want to bring up. Currently, GHC #16140 [1] makes it rather
inconvenient to use quantified constraints in type synonyms. For
instance, GHC rejects the following example by default:
type F f = (Functor f, forall a. Eq (f
Count me among the people who are eagerly awaiting this move. If I
understood Ben correctly when discussing this idea with him on #ghc, then
one of the benefits of having head.hackage on GitLab would be that the
head.hackage index would automatically regenerate any time a commit lands.
This would
The submodule linter appears to have been disabled in [1]. As Matthew notes
in [2], perhaps we should probably open a ticket to track how to restore it.
Ryan S.
-
[1]
https://gitlab.haskell.org/ghc/ghc/commit/a39a3cd663273c46cf4e346ddf3bf9fb39195c9d
[2]
Ben indicates (on the #ghc IRC channel) that he suspects something is
amiss with the lint-submods-marge job.
Ryan S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
I've noticed that Marge's most recent batch is consistently failing
after repeated attempts. Each time, the failure is only in the
lint-submods-marge job. Here is an excerpt from the most recent
failure [1]:
Submodule update(s) detected in 1cd22260c2467650dde8811cc58e89594a016f43:
Would this permit explicit impredicativity as described in [1]? Simon
mentions in [1] that explicit impredicativity is easier to implement than
guarded impredicativity, although it's not clear to me if the latter would
imply the former.
Ryan S.
-
[1]
Hi Iavor,
This is a feature in the sense that it is an expected outcome of the
OutsideIn(X) type inference algorithm (in particular, Section 5 of the
corresponding paper [1]). I'll try to explain the issue to the best of
my understanding.
The tricky thing about the Q3 data type:
data Q3 =
To be clear, your workaround is precisely what I used to do, but that is no
longer working after the GitLab upgrade. I can add myself as a reviewer,
but only to a group besides the default approvers list. Because Marge only
counts approvals from those who belong to the default approvers list, my
I would definitely appreciate changing Marge's behavior back to the old
one. As things stand currently, I am unable to approve anything that I'm
not explicitly listed as a reviewer for. See here [1] for an example of
where this has happened.
Ryan S.
-
[1]
The 8.8 Migration Guide can be found here:
https://gitlab.haskell.org/ghc/ghc/wikis/migration/8.8
Ryan S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
It depends on what you mean by "source Haskell". If you're willing to
consider including Template Haskell in your definition of "source", then
the answer is yes, since there is a reifyRoles function [1] which gives you
this information.
I'm not aware of another way to accomplish this (without
Ben Gamari wrote:
> Ryan Scott writes:
>
> > To be clear, the wip/dmd-arity is not the only branch I've received
> e-mails
> > about. I've also received "Remove mirror update failed" e-mails of a
> > similar caliber that warn about the w
t received these as well? They almost seem to happen any time any
commit is landed.
Ryan S.
On Sat, Apr 6, 2019 at 2:28 PM Ben Gamari wrote:
> Ryan Scott writes:
>
> > Almost every day now I receive an e-mail from GitLab titled "Remote
> > mirror update faile
> Did you mean "What is the TcHsSyn counterpart to TcMType.zonkTcTyVar"?
D'oh. Yes, I did.
> But it's never a bad idea to document more.
I've documented all the wisdom from here in this wiki page [1]! Feel
free to edit it if there are any corrections to be made.
Ryan S.
-
[1]
Almost every day now I receive an e-mail from GitLab titled "Remote
mirror update failed", which contains something like:
To
! [remote rejected] wip/dmd-arity -> wip/dmd-arity (cannot
lock ref 'refs/heads/wip/dmd-arity': is at
e1cc1254b81a7adadd8db77c7be625497264ab2b but expected
can look it up in the future if (when) I eventually forget it.
Ryan S.
On Thu, Apr 4, 2019 at 3:05 PM Richard Eisenberg wrote:
>
>
>
> > On Apr 4, 2019, at 2:55 PM, Ryan Scott wrote:
> >
> > Good to know, thanks. I assume that TcMType.zonkTcTypes is to
> > Tc
Good to know, thanks. I assume that TcMType.zonkTcTypes is to
TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to
TcHsType.zonkTyBndrs?
Also, what exactly is the optimization that ZonkEnv performs in types?
And why don't the functions in TcMType make use of this optimization?
Ryan S.
I've recently found myself wanting to add some pprTrace statements in
typechecker-related code but unable to do so, as the code would pull
on knot-tied TyCons (leading to an infinite loop if actually ran). In
particular, I want to print some code [1] in TcTyClsDecls.tcConDecl:
; (ze, tkvs)
oth
simultaneously (unless I'm missing something), which is why I thought it
worthwhile to ask you if this state of affairs would be inconvenient.
Ryan S.
-
[1] https://gitlab.haskell.org/ghc/ghc/merge_requests/650
[2] https://gitlab.haskell.org/ghc/ghc/merge_requests/639
On Tue, Apr 2,
On Tue, Apr 2, 2019 at 10:05 AM Ben Gamari wrote:
> Ryan Scott writes:
>
> > Thanks for writing these up! These will be handy references that I'm sure
> > I'll come back to many times.
> >
> > Question: once I've marked my MR as "backport-needed" (an
Thanks for writing these up! These will be handy references that I'm sure
I'll come back to many times.
Question: once I've marked my MR as "backport-needed" (and it is merged
into master), whose responsibility is it to ensure that it gets merged into
the latest release branch (e.g., ghc-8.8)? It
Things still appear not to work whenever I try to push a new branch:
fatal: unable to access 'https://gitlab.haskell.org/RyanGlScott/ghc.git/':
The requested URL returned error: 500
Ryan S.
___
ghc-devs mailing list
ghc-devs@haskell.org
If you're reinstalling the same template-haskell version, then I can't
immediately think of anything that would go wrong. Then again, I'm not
intimately familiar with all of the little details that might be relevant
here.
Out of curiosity, are you asking this question because you've tried
My (limited) understanding is that template-haskell is not reinstallable
for the same reasons that base and ghc-prim aren't reinstallable: the GHC
codebase directly wires in several definitions several functions, types,
and data constructors from template-haskell. See THNames [1]. If one were
to,
I do think something is afoot here. The current Haddock submodule commit is
at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6
[2]. It would be good if someone could update the ghc-head branch
accordingly.
Ryan S.
-
[1]
This is fantastic work! I'm looking forward to using this.
Are there plans to merge GitLab's fork of head.hackage back into the
upstream repo [1]? I ask since I regularly submit patches to upstream, but
if the GitLab CI is using the fork, then it may take some time for upstream
changes to make
As Vlad notes in [1], getting rid of FreeKiTyVars isn't as simple as it
would appear, as we still treat kinds and types differently in other
places, such as data type declarations. For instance:
data Proxy (a :: k) = Proxy -- k is brought into scope implicitly by
`extractDataDefnKindVars`
I
PM Richard Eisenberg
wrote:
>
>
> > On Feb 14, 2019, at 10:34 AM, Ryan Scott
> wrote:
> >
> > the answer [j,a,k,b]! Strictly speaking, this answer meets the
> specification of ScopedSort,
>
> I wish to point out that the specification of ScopedSort is
up with [j,a,k,b].
>
>
>
> Perhaps that’s an ergonomic reason for retaining the current rather
> cumbersome code. (Maybe it could be simplified.)
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Ryan Scott
> *Sent:* 14 February 2019 15:35
> *To:* ghc-d
Consider this function:
f :: Proxy (a :: j) -> Proxy (b :: k)
If you just collect the free type variables of `f`'s type in left-to-right
order, you'd be left with [a,j,b,k]. But the type of `f` is not `forall (a
:: j) j (b :: k) k. Proxy a -> Proxy b`, as that would be ill scoped. `j`
must
Yes, I agree. This will require sprinkling the codebase with EmptyCase due
to [1], but that's still a sight better than calling `panic`. After GHC
8.10 is released (and the minimum version of GHC that HEAD supports is
8.8), we can even remove these empty cases by making the empty data type
fields
> Yes, I have reported it while back. I don't know of the progress in
fixing this.
Reported what? #15884? [1] You do realize that there is a very simple
workaround for that issue, right? Instead of writing this, which is subject
to the pattern-guard completeness issues observed in #15753:
f
There appears to be some impedance mismatches between GitLab's formatting
and Trac's formatting in certain places. For example, see the bottom of
this issue [1], which has a long, hyperlinked line with the phrase:
You *can* put `LL` into a COMPLETE set, but under the stipulation that
you specify which type constructor it's monomorphized to. To quote the
wiki page on COMPLETE sets:
In the case where all the patterns are polymorphic, a user must
provide a type signature but we accept the definition
The fact that `LL` can't be used in a COMPLETE pragma is a consequence
of its current design. Per the users' guide [1]:
To make things more formal, when the pattern-match checker
requests a set of constructors for some data type constructor T, the
checker returns:
* The original set of
t; now, it’ll surely come back.
>
>
>
> If that is lexically tiresome, we could I suppose provide builtin-aliases
> for them, as if we had
>
> type NomEq# = (~#)
>
> type ReprEq# = (~R#)
>
>
>
> Simon
>
>
>
> *From:* Ryan S
This is likely caused by an old GHC bug that interacts poorly with newer
version of binutils (I can't remember the exact bug, unfortunately).
I personally use hvr's Ubuntu PPA [1] whenever installing GHC on Ubuntu.
This PPA backports patches to old versions of GHC to keep them working with
newer
nges. Making evidence strict would require
> no language changes to solve the original problem.
>
>
>
> Maybe this thread belongs with the proposal, unless I’m misunderstanding.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs *On Behalf Of *Ryan Scott
> *Se
These aren't mutually exclusive ideas. While I'm sure there's many ways we
could solve this problem, David's idea has the distinct advantage of being
dead simple. I'd rather not block his vision on some other large refactor
that may never materialize. (And if it _does_ materialize, we could revert
In case this wasn't clear, the context of this discussion in this GHC
proposal [1], where David is trying to work around the fact that data types
with existential Coercible constraints do not support unpacking. (By
"unpacking", I mean putting an {-# UNPACK #-} pragma in front of a field of
that
If we can gain some performance from this, then I'm generally supportive of
this idea.
I'm still of the belief that we could teach GHC to unpack boxed equality
constraints, but your idea would definitely be the simpler one to implement.
Ryan S.
___
.
On Sun, Aug 26, 2018 at 11:04 PM, David Feuer wrote:
> On Sunday, August 26, 2018 9:54:09 AM EDT Ryan Scott wrote:
> > I'm confused. base-4.12.0.0 hasn't been released yet, so can't we just
> make
> > this StableName change a part of 4.12.0.0?
> >
> > (Regardless of
I'm confused. base-4.12.0.0 hasn't been released yet, so can't we just make
this StableName change a part of 4.12.0.0?
(Regardless of what we choose, we should make sure to advertise this change
in base's changelog—currently it's unmentioned.)
Ryan S.
Presumably, you're compiling this program outside of a git repository,
and so the Template Haskell splice $(gitHash) evaluates to "UNKNOWN"
at compile time. Here is an even more minimal example, which does not
depend on gitrev:
f :: ()
f = case "UNKNOWN" of
"UNKNOWN" -> ()
? Constructing
> core like this is quite hairy.
>
> The "tuple" part doesn't really exist in core, a constraint tuple is
> curried. So foo :: (C1 a, C2 a) => ... desugars to `foo = /\ a . \
> $dC1 . \$dC2 -> ...`.
>
> Cheers,
>
> Matt
>
>
>
> On Tue,
a constraint tuple type
constructor?
Ryan S.
On Tue, Jun 19, 2018 at 10:07 AM Matthew Pickering <
matthewtpicker...@gmail.com> wrote:
> How about `tc_tuple`?
>
> On Tue, Jun 19, 2018 at 2:53 PM, Ryan Scott
> wrote:
> > I'm currently working on some code in which I nee
I'm currently working on some code in which I need to produce a Core Type
that mentions a constraint tuple. I thought that there must surely exist
some way to construct a constraint tuple using the GHC API, but to my
astonishment, I could not find anything. The closest thing I found was
mk_tuple
> Simon
>
> On 1 June 2018 at 11:57, Ryan Scott wrote:
>
>> One thing I forgot to mention is that these test failures only seem to
>> occur with the `quick` build flavor, and I couldn't reproduce them with
>> ./validate. Is -fghci-leak-check expected to have different
One thing I forgot to mention is that these test failures only seem to
occur with the `quick` build flavor, and I couldn't reproduce them with
./validate. Is -fghci-leak-check expected to have different behavior if
stage-2 GHC is built without optimization?
Ryan S.
I recently ran the testsuite and experienced a very large number of
testsuite failures, all of which seem to involve the new -fghci-leak-check
flag. Here is the list of tests that fail:
Unexpected failures:
ghci/prog001/prog001.runprog001 [bad stdout] (ghci)
I have one major feature planned: -XDerivingVia. I haven't made a
patch yet, since the idea itself is still technically going through
the proposal process at [1]. But the feedback seems pretty positive,
so I think I'll submit it to the committee next week for final
consideration.
There is an
Hi Peter,
> What does exactly happen if an extension is needed for a certain language
> element, but it is not present?
Generally, these manifest as runtime checks of the form (xopt
LangExt.TheLanguageExtensionName dflags). For an example, see [1],
where GHC checks if the TypeFamilyDependencies
I've submitted a Diff [1] for this.
Ryan S.
-
[1] https://phabricator.haskell.org/D4586
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
I've just landed a commit of Ben's [1] which should fix this issue.
Ryan S.
-
[1] Specifically,
http://git.haskell.org/ghc.git/commit/54acfbbf64f5fcb108836412e9be0cfabf0d7801
___
ghc-devs mailing list
ghc-devs@haskell.org
i" <b...@smart-cactus.org> wrote:
> Ryan Scott <ryan.gl.sc...@gmail.com> writes:
>
> > I did a smoke test of Stackage Nightly's libraries [1] this afternoon
> using
> > GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and
> > protolude-0.2
Trying to build a fresh copy of GHC HEAD (at commit [1]) today failed
for me with this error: [2]
/u/rgscott/Software/ghc4/libffi/build/missing: line 81: makeinfo:
command not found
WARNING: 'makeinfo' is missing on your system.
You should only need it if you modified a
I did a smoke test of Stackage Nightly's libraries [1] this afternoon using
GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and
protolude-0.2, due to a change where type signatures like `foo :: forall k.
forall (a :: k). ...` no longer compile without enabling TypeInType.
I only
Trying to conclude Typeable Foo (or, if expanded with
-fprint-explicit-kinds, Typeable ((forall a. a -> Maybe a) -> Type)
Foo) is beyond GHC's capabilities at the moment, as that would require
impredicative polymorphism. This problem has arose in other contexts
too—see Trac #13895 [1] for one
If you're willing to go a completely different route from
GHC.Generics, then you might be interested in the paper Generic
Programming with Multiple Parameters [1] (whose existence I just
learned of—thanks to Pedro, the author, for pointing it out to me). It
does present a single Generic class that
Several good points were brought up. Let me go through them and try to
make sense of what I can:
> When I looked at it the last time, there were some apparent leftovers in the
> form of types or type parameters never used.
Are you referring to the `p` type parameters that are found in most of
While we're on the topic, I'll mention that at one point I attempted
to modify the singletons [1] library so that it would automatically
generate promoted (i.e., type-level) and singled versions of Generic
instances for any data type that derived Generic. I wasn't successful,
since it turns out
Thanks for putting so much effort into this work, Tamar!
> When I do turn it on, by default you will get a large ~45min hit in compile
> time.
Yikes, that's really bad! Bad enough that I have to wonder: would it
be worth including genlib among the other executables that we bundle
with GHC?
assifying... perhaps print out the HsType before
> it's lost.
>
> Or, you could tackle #13737 and get rid of the knot altogether! :)
>
> Richard
>
> On Aug 3, 2017, at 6:21 PM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote:
>
> Recently, I've found myself wanting to make changes
Recently, I've found myself wanting to make changes to code that works
inside code where TyCons are knot-tied [1]. But I've found myself unable to
make much progress, since my ability to debug this code is severely limited
by the fact that I can't seem to trace anything. That is, if I try tracing
r order. His suggested improvement is
>
> liftCoercion :: Maybe (Coercion a b -> Coercion (f a) (f b))
>
>
>
> David Feuer
> Well-Typed, LLP
>
> ---- Original message
> From: Ryan Scott <ryan.gl.sc...@gmail.com>
> Date: 6/6/17 1:41 PM (GM
ge/profunctors-5.2/docs/Data-Profunctor-Unsafe.html#v:-35-
.
On Wed, May 31, 2017 at 7:25 PM, Richard Eisenberg <r...@cs.brynmawr.edu>
wrote:
>
> > On May 31, 2017, at 5:21 PM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote:
> > Does you know what might be going on here?
>
&g
Richard,
In an effort to figure out why programs with lots of type families have
become so much slower over the last few GHC releases, I've been looking at
GHC Trac #12545 [1], which provides a very self-contained test case that
became considerably slower to compile from GHC 7.10 to 8.0. Thanks
Alberto,
> I've manage to reproduce the CK bug without any external dependencies and
> opened a ticket with an attached module that fails to compile with
> 8.2.1-rc2 (w/o explicit KindSignature) but compiles fine with 8.0.2.
Thanks for doing this!
> Will hopefully follow up soon with the Cabal
1 - 100 of 168 matches
Mail list logo
