On Feb 12, 2016, at 12:17 PM, Dominik Bollmann
wrote:
>
> Hi,
>
> I'm currently trying to understand GHC's implementation of Template
> Haskell and I've had the following two questions when reading upon
> deSugar/DsMeta.hs and deSugar/dsExpr.hs (disclaimer: I'm a complete
> newbie to GHC and
4:31 PM, Joachim Breitner wrote:
> Hi,
>
> Am Freitag, den 12.02.2016, 14:04 -0500 schrieb Richard Eisenberg:
>> Ideally, there would be a way to run a portion of the testsuite and
>> have the testsuite tool aggregate performance characteristics and
>> report.
>
> i
On Feb 16, 2016, at 5:35 AM, Ben Gamari wrote:
> Indeed. I'll just say that I envision that a beginner's prelude would be
> for learning and nothing more. The goal is that it would be used in the
> first dozen hours of picking up the language and nothing more.
>
> I'd be interested to hear what
Hi Jonas,
Thanks for jumping in! It sounds like you're very much on the right track here,
and I appreciate your desire not to use the simplifier code in the linter.
I'm afraid I don't have good answers for your questions, however. Really, this
email is just to offer some gratitude and hope you
I, for one, would greatly welcome someone rewriting much of the TcErrors
module. (Almost all type errors are generated in that one module, rather
conveniently.) Even better would be to have some written-out theory behind the
design of the error-reporting mechanism. What we have now is incredibly
On Mar 8, 2016, at 7:17 PM, Evan Austin wrote:
> The wiki page for Phase I of Dependent Haskell describes an approach to
> constrained type families:
> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained
>
> Did that land in GHC 8.0 and, if so, is t
ly polykinded but where 90% of
> the instances instantiate that kind as *. The status quo prevents me from
> putting in a type default that would only be valid when the kind argument is
> *.
>
> -Edward
>
> On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg wrote:
>
> O
Hi devs,
Watching the files being compiled slowly scrolling by, as I too often do, led
me to this question: Is there a reason that my machine (an x86-based Mac) is
building modules in the SPARC or PPC directory? These absolutely need to be
compiled when validating on any machine, but if I'm on
On Mar 8, 2016, at 8:54 PM, Evan Austin wrote:
> I’d be happy to send you a follow up email tomorrow when I’m back at the
> office if you think this would be a good motivating use case for the feature.
Up to you. That feature isn't high on my priority list, and there are enough
things on that
Hi devs,
I'm working on some compiler performance bugs. I've implemented caching for
coercion kinds at Phab:D1992. But tests show a net slowdown, which I'm
currently investigating. I could abandon this work for 8.0, but it really
should show an improvement, and so I'm looking deeper.
A little
On Mar 11, 2016, at 12:04 PM, Simon Peyton Jones wrote:
> Profiling prevents optimisation!
I didn't know that. Why does it do this? It defeats the point of profiling a
bit if we can't optimize. I just assumed the optimizer looks through the SCCs,
preserving them, but that otherwise SCCs don
I'm happy to change the setting, but my logic was this: With
-XTypeApplications, there are no ambiguous types. Of course, there may be types
that are unambiguous locally but might be ambiguous in downstream modules that
don't use -XTypeApplications, and this is what Andrew is (quite validly)
ge
The TypeInType patch did relatively little to the abstract syntax.
HsImplicitBndrs no longer separates type variables and kind variables. And
there was some major surgery to the type/kind parser (discussed below). It's
that last bit that you probably want to know about. But check out
https://ph
You have made an invalid assumption that there exists a semantics for
type-level reduction in Haskell. There doesn't. Without such a well-defined
evaluation order, it's hard to talk about lifted kinds vs. unlifted kinds.
Perhaps another way of slicing this exists, though. Does #7259
(https://gh
Just to close the loop on this: I have made this change in GHC, and the
implication will be dropped in time for 8.0.
Thanks,
Richard
On Mar 15, 2016, at 4:11 PM, Adam Gundry wrote:
> On 15/03/16 14:53, Richard Eisenberg wrote:
>> I'm happy to change the setting, but my logic
Thanks for the heads up. I've pushed my fix to wip/rae and am waiting for
Travis to give me the OK.
Richard
On Mar 21, 2016, at 7:05 PM, Joachim Breitner wrote:
> Hi Richard,
>
> along with this or some other change it seems you broke the test suite
> when run with DEBUG:
>
> T2478.hs:1:41:
Hi devs,
Consider the following:
> data Proxy k (a :: k) = P
> deriving Functor
What should happen when this is compiled?
1. Issue an error saying that `deriving` cannot instantiate visible parameters.
2. Type error: cannot match `k` with `*`.
3. Successfully produce `instance (Proxy *)`.
I started this thread feeling uncomfortable about a `deriving` clause
instantiating `k` to `*`. But `deriving` *does* infer constraints. Perhaps it's
just inferring a `(k ~ *)` constraint. Thinking of it this way makes me prefer
(3).
Richard
On Mar 28, 2016, at 5:12 PM, Ryan Scott wrote:
>>
On Mar 29, 2016, at 3:58 PM, Ryan Scott wrote:
> I hope this is a bug and not a fundamental limitation.
As I posted in the ticket, this is a somewhat fundamental limitation. I qualify
by "somewhat" because it's a consequence of a design choice, but reversing the
design choice would be rather
Coercion holes (the payload of a HoleProv) get created for all wanted equality
constraints (and for nothing else). If you're working over only class
dictionaries, you won't encounter holes. But my guess is that your HasRep
somehow induces a wanted equality. If the solver fills the hole -- as it
return mr
> >
> > -- TODO: Try initTcForLookup or initTcInteractive in place of
> > initTcFromModGuts.
> > -- If successful, drop dflags and guts arguments.
> >
> > runDsMUnsafe :: HscEnv -> DynFlags -> ModGuts -> DsM a -> a
> > runDsMUnsafe env
Yes, that's correct. The RuntimeRep story generally allows for such
polymorphism in the future, but it's not implemented yet. One concern is that
doing this would require RuntimeRep to look like
> data Levity = Lifted | Unlifted
> data RuntimeRep = PtrRep Levity | IntRep | VoidRep | ...
The pro
; you think there's another route to zonking that could work for my
> circumstances? - Conal
>
>
> On Mon, Apr 4, 2016 at 2:00 PM, Richard Eisenberg wrote:
> Can't say anything about the setup to use unsafePerformIO, but I can say
> that, yes, you need a zonk.
>
&g
over ptry structures safely.
>
> @ed, does any of this have an impact or relevance to your structs lib
> experiment you were sharing at Icfp?
>
> On Tuesday, April 5, 2016, Richard Eisenberg wrote:
> Yes, that's correct. The RuntimeRep story generally allows for such
> pol
I actually don't think this would be all that hard to do.
Concretely, how would this work:
TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its
argument in the local typing environment available when addGroupFinalizer is
called. However, by the time the passed action i
Though there's still room for improvement, this one has gotten a lot better
since RC2:
> Scratch.hs:24:39: error:
> • Couldn't match type ‘k0 -> *’ with ‘*’
> Expected type: T W
> Actual type: T W
> Use -fprint-explicit-kinds to see the kind arguments
> • In the first
Hi all,
I now frequently run across ASSERTion failures triggered by the new
substitution invariant checks. This is surely a good thing, but it's gotten me
thinking about the need for InScopeSets in substitutions at all. It seems to me
that the only(?) use of the InScopeSet is in the uniqAway in
On Apr 11, 2016, at 6:39 PM, Simon Peyton Jones wrote:
> It's _nothing_ to do with whether the kind changes!
>
> It's everything to do with cloning the binder if it is already in scope. See
> "Secrets of the GHC inliner", the section called "The rapier", I think.
Ah yes. Silly me.
Thanks,
R
On Apr 12, 2016, at 5:35 PM, Facundo Domínguez
wrote:
> Hello Richard,
>
>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs
>> its argument in the local typing environment available when
>> addGroupFinalizer is called.
>
> When considering this approach, how could
I don't think this has to do with topological sorting so much as inferring the
order of undeclared (but written) kind variables. You could, with -XTypeInType,
always make the order explicit:
> data T :: forall j k l x y z. (j -> k -> l) -> (x, y, z) -> * where MkT :: T
> a b
The order of these
On Apr 12, 2016, at 10:44 PM, Ryan Scott wrote:
>
> It's a bit of a shame that type inference doesn't give you a reliable
> order, but I suppose if you rely on -XTypeApplications working a
> certain way, you're taking a risk by NOT using a forall.
Inference is meant to give you a reliable order
On Apr 13, 2016, at 5:17 AM, Simon Peyton Jones wrote:
> I thought that inferred foralls are Invisible binders (see Note [TyBinders
> and VisibilityFlags]); and you can't use visible type application for
> Invisible binders.
No. See that Note. A binder is Invisible only when it is completel
; fully type checked is perfectly safe.
>
> Best,
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
>
> On 13 April 2016 at 04:25, Richard Eisenberg wrote:
>> On Apr 12, 2016, at 5:35 PM, Facundo Domínguez
>> wrote:
>>
>>> Hello Richa
r?
>> * If part of the solution here is to use typed splices, how do we get
>> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
>> to be introducing a typed quasiquotation syntax, just like Geoff did
>> for much of the rest of Template Haskell?
>>
I'm happy to be overruled on this, but I vote against this change for GHC 8.
Personally, I like to have a policy of "no TH changes after the first RC". This
gives ample time for TH clients to update their code. Iavor's suggestion would
likely involve a new part of the InstanceD constructor, whic
On Apr 15, 2016, at 11:51 AM, Simon Peyton Jones wrote:
>
> Hang on! The design for typed splices, describe here,
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
> says "Unlike TH, the only way to construct a value of type TExp is with a
> quote. You cannot drop into do
On Apr 18, 2016, at 9:14 AM, Simon Peyton Jones wrote:
>
> My instinct is to make it less expressive, though, and only allow (TExp t) as
> the argument of $$.
>
> Does anyone care either way? I suppose we'd better open a ticket for this.
I don't see any harm that is introduced by having ac
Hi Carter,
Are you perhaps looking for the `flavours` subdirectory of `mk`? That should
contain what you're looking for.
Richard
On Apr 17, 2016, at 9:32 AM, Carter Schonwald
wrote:
> Hey all,
> I just did a checkout of the tip of ghc 8.0 branch and it looks like the
> build.mk files have s
On Apr 18, 2016, at 9:45 AM, Simon Peyton Jones wrote:
> Well, it opens up the entire issue of dependence on typechecking order and
> reification. Other things being equal, simple is good...
Of course that's true, but other things aren't equal -- losing Q decreases the
usefulness of typed TH
the end of
> the aforementioned wiki page, but does anyone else have a better way
> of doing this in mind?
>
> Best,
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
>
> On 16 April 2016 at 16:02, Richard Eisenberg wrote:
>>
>> On Apr 15, 2016,
Hi devs,
Over the weekend, I was pondering the Haskell course I will be teaching next
year and shuddered at having to teach Foldable at the same time as `length`. So
I implemented feature request #10963
(https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way for a
user to reque
e parameters to pass in next.
I have suggested :type-def for (1) and :type-spec for (2). I don't strongly
like either. :examples and :inst have been suggested for (1). Any other ideas?
Thanks!
Richard
On Apr 26, 2016, at 9:08 AM, Richard Eisenberg wrote:
> Hi devs,
>
> Ove
Hi devs,
I'm forwarding the following from a friend (cc'd) who was unable to register
for Trac. Can anyone help?
Hi. I tried to register with username "j6carey" and email "j6ca...@gmail.com"
to report a bug in GHC 8.0.1, and the system says there's a 97% chance I'm a
spammer. It asked
On May 31, 2016, at 9:54 AM, Bartosz Nitka wrote:
> I'd like to get feedback if this is an acceptable solution and if the problem
> is worth solving.
I don't have an opinion about "worth solving". While I understand your
description of the problem and believe you that it crops up in practice,
What about just using a new pragma?
> {-# SCC_FUNCTION f "f_scc" #-}
> f True = ...
> f False = ...
The pragma takes the name of the function (a single identifier) and the name of
the SCC. If you wish both to have the same name, you can leave off the SCC name.
It seems worth it to me to introdu
On Jun 2, 2016, at 7:12 AM, Simon Peyton Jones wrote:
>
> But why is NameU exposed to clients? GHC needs to know, but clients don’t.
> What use are these packages making of it?
>
singletons uses NameU in two places:
1. To generate unique numbers. It would be easy enough for me to put this
Hi devs,
I would like to download GHC 8 binaries for Arch Linux on an x86-64
architecture. I assume I'm looking for an unknown-linux build, and it looks
like what I want is a Tier 1 platform, according to
https://ghc.haskell.org/trac/ghc/wiki/Platforms Yet I don't see this release
in https:/
On Jun 5, 2016, at 10:46 PM, Austin Seipp wrote:
> On Linux, the builds are keyed by the OS name they were built on. This is
> because systems like CentOS have different versions of libgmp, glibc than
> e.g. Debian derivatives. So they actually refer to different paths, are built
> against di
It seems there are nice advantages to this approach, and so I'm fine requiring
support from TH. But here is a comment I just posted on D2286 requesting more
comments in the code:
---
I've just spent some time staring at GHCi/TH.hs and friends, and it's starting
to make sense. Would it be possib
On Jun 22, 2016, at 10:38 AM, Simon Marlow wrote:
> Thanks for the feedback Richard. It's helpful to know which parts of the
> implementation you found non-obvious. I will write some more Notes, but
> first:
I think what would help most is a place that describes the little state machine
th
On Jun 23, 2016, at 8:59 AM, Simon Peyton Jones wrote:
> Richard
>
> I have just spent an hour plumbing the torrid swamp of binder visibility.
> There is bad naming confusion.
>
> We have
>
> · Visible
>
> · Specified
>
> · Invisible
>
> The function isVisible ret
> * Required
> * Specified
> * Inferred
>
> I like that. Much more self-explanatory. Shall we go for it?
>
Sure. Now, who gets to do the work? :)
Are you in the middle of a refactor around this? If not, I can do this this
afternoon.
Richard___
Hi Simon,
Phab tells us that T8761 is failing for the ext-interp way, as of
d2006d050e7a9111c0c448d6262f8994ef5761b7 (Run all TH tests with
-fexternal-interpreter (#12219)). See https://phabricator.haskell.org/B10229
Thanks,
Richard
___
ghc-devs maili
Of the three options from Ryan's first email in this thread, only the third is
palatable to me (with the separate `deriving` clauses).
I would like to mention that I don't see any real obstacles to something like
> newtype ...
> deriving (Eq, default ToJSON, builtin Ord, newtype Monoid)
That i
> On Jul 18, 2016, at 2:54 AM, Andres Loeh wrote:
>
> There's nothing obviously wrong with option 3, but it seems relatively
> verbose (I'd prefer Richard's syntax), and feels more ad-hoc. I don't
> mind "builtin" to refer to the deriving mechanism, but again, I also
> don't mind Richard's sugge
> On Jul 18, 2016, at 9:59 AM, Ryan Scott wrote:
>
>> The one idea I can suggest in this space (somewhat tongue-in-cheek, but feel
>> free to take it seriously) is `bespoke`
>
> It might be a tongue-in-cheek suggestion, but I _really_ like it. It
> captures the intended semantics better than a
> On Jul 21, 2016, at 10:32 AM, Gershom B wrote:
>
> On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com) wrote:
>>
>> It makes sense to have
>> two committees only if we have multiple language implementations, but
>> it is not the case.
> I disagree. By the stated goals of
> On Jul 21, 2016, at 11:29 AM, Yuras Shumovich wrote:
>
> Unfortunately Haskell *is* implementation-defined language. You can't
> compile any nontrivial package from Hackage using Haskell2010 GHC.
Sadly, I agree with this statement. And I think this is what we're trying to
change.
> And
> th
> On Jul 21, 2016, at 2:25 PM, Yuras Shumovich wrote:
>
> It is hopeless. Haskell2020 will not include TemplateHaskell, GADTs,
> etc.
Why do you say this? I don't think this is a forgone conclusion. I'd love to
see these standardized.
My own 2¢ on these are that we can standardize some subset
> On Aug 3, 2016, at 8:50 PM, Ryan Scott wrote:
>
> * Template Haskell: Not portable. Staging issues make it hard to use
> as a drop-in replacement for the `deriving` keyword
I do not understand "not portable" here. Do you mean that some architectures
don't support TH?
What staging issues?
I
I tend to agree with Oleg that suggesting `ScopedTypeVariables` may be more
helpful to users, even though `ExplicitForAll` is more principled.
Richard
> On Aug 11, 2016, at 2:45 PM, Oleg Grenrus wrote:
>
> FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,
> yet my code doe
> On Aug 12, 2016, at 2:31 PM, Ryan Scott wrote:
>
> I can understand your reaction to the word "bespoke". I certainly
> never use it in daily conversation, and it's only from Richard's
> assurance (and from consulting a dictionary) that I feel confident
> about using it in this context.
Oh dea
Hi Ben,
Thanks for tackling this difficult issue -- I know you've been looking for a
better solution.
As I understand it, anyone will now need to add a public key to Phab in order
to upload patches. This (as you admit) will increase the barriers to
contributions. Are the instructions for how a
I feel like I must be missing something, but what's wrong with
> class Semigroup1 f where
> op :: f a -> f a -> f a
>
> default op :: Monoid (f a) => f a -> f a -> f a
> op = (<>)
? Does that do what you like?
Richard
> On Sep 1, 2016, at 11:15 PM, David Feuer wrote:
>
> On occasion,
Seems reasonable and useful to me. Is this a good use of the process here?
https://github.com/ghc-proposals/ghc-proposals
> On Sep 7, 2016, at 10:39 AM, David Feuer wrote:
>
> Currently, the only way to suppress custom warnings and deprecations is with
> -fno-warn-warnings-deprecations, which
Like many of you, I'm sure, I'm saddened by the occasional tone of the recent
exchange about contributions to GHC.
I'd like to move the conversation forward -- and I'd like to do so on a
technical basis.
So, I ask:
How, precisely, can we improve?
I think it would be best to have answers to thi
To sum up, this proposes the following:
1. Allow PRs on GitHub.
2. Michael Sloan to write a new utility, ghc-hub, which automates tasks
interfacing between GitHub and Phab. This utility would be used only by GHC HQ
and not by contributors.
3. Small GitHub PRs can be merged directly, by ghc-hub
Yes, I agree with Michael’s observations in the blog post. However, one thing
that’s easier about a wiki is that the editing process is much more lightweight
than making a PR.
But GitHub has a wonderful feature (that I have rarely used) that mitigates
this problem. Viewing a file in GitHub offe
that, though!
>
> Thoughts? I think it would be great for this to be proposed formally
> soon so that we can make it happen. I am eager to be able to use my
> normal git workflows, as my little experience with Arcanist induced
> some head-scratching. Not the fault of the tool,
t thinking about the real loss associated with moving away from
these features gives me pause.
Richard
> On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote:
>
> On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote:
>> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote:
>>&
+1 on `stock` from me. Though I was all excited to get my class next semester
jazzed for PL work by explaining that I had slipped a new keyword `bespoke`
into a language. :)
Richard
> On Sep 27, 2016, at 7:55 PM, Ryan Scott wrote:
>
> > This wouldn't eat up Stock as a data type or type classe
Here's a pre-proposal (which could be formalized into a proper proposal) to
address the wiki discussion:
- Configure the wiki to display the date of last edit prominently.
- If the date of last edit is sufficiently long ago (1 year?) loudly warn the
reader that the content may be out-of-date.
I have tried to gather the ideas from this thread into a formal proposal:
https://github.com/ghc-proposals/ghc-proposals/pull/11
Please feel free to make suggestions to improve this, especially if I've
captured anyone's contributions incorrectly.
-=-=-=-=-=-=-=-=-=-=-
Richard A. Eisenberg
Asst.
contribute.
>
> And if possible, they send update request with any way.
>
> We’ll preferentially update many requested pages.
>
>
>
> About (c):
>
>
> We have multiple wiki sites. Someone is unfamiliar about them.
>
> Github is one of the solutions for new
In a sweep to make sure that the concerns raised here get heard, I see this
great list of suggestions. I believe they have all been incorporated into
https://github.com/ghc-proposals/ghc-proposals/pull/9, so please check there.
Personally, I think these suggestions will get better discussion an
> On Sep 30, 2016, at 6:36 PM, Baldur Blöndal wrote:
>
> Shot in the dark: Would extensions like QuantifiedConstraints or
> ImplicationConstraints, if implemented, help with ImpredicativeTypes?
I don't think so. The challenge with ImpredicativeTypes is retaining
predictability of type inferen
By all means make the proposal -- I like this idea.
> On Oct 3, 2016, at 4:29 AM, Herbert Valerio Riedel wrote:
>
> Hi *,
>
> I seem to recall this was already suggested in the past, but I can't
> seem to find it in the archives. For simplicity I'll restate the idea:
>
>
>foo :: Int -> In
Hi Erik,
You're right that Template Haskell violates Safe Haskell guarantees, but that
should be independent of the Language.Haskell.TH.Syntax module. The problem is
the -XTemplateHaskell extension, not the module. So I think labeling the module
Trustworthy is OK.
Richard
> On Oct 4, 2016, at
he whole point of representation polymorphism
is to common up things with the same representation. And here we're
specifically taking two things with the same rep -- Type and Constraint -- and
separating them. What's wrong with ((->) LiftedPtrRep LiftedPtrRep (Ord Int)
Char)? Re
> On Oct 6, 2016, at 1:15 PM, Ben Gamari wrote:
>>> 1. Currently saturated (->) is treated differently to unsaturated
>>> (->), as witnessed by the special kinding rule for FunTy. The
>>> shortest path for TypeRep is to do the same: add TrFunTy.
>>
>> Will this be changed after Ben's work to gen
> On Oct 6, 2016, at 5:36 PM, Ben Gamari wrote:
>
> The motivation here isn't that we want to decompose this. It's that
> carrying the kind variable instantiations will shrink the size of your
> typical (non-kind-polymorphic) TypeRep and may actually simplify a few
> things in the implementation
Interesting problem & solution.
Here's a wacky idea, from a position of utter ignorance about your environment:
could you use color? Already, when I saw `b :: a` in the commentary there,
where `b` is in scope as a type variable, it seemed wrong to me.
In any case, I can answer your simpler ques
I have an unused machine in my department. It currently has 6GB of memory on
it, but memory is cheap enough these days, so this could be expanded if
necessary. (Is this necessary?) We would slap a basic Linux on it, give it a
hostname (xxx.cs.brynmawr.edu), and then make an account for you, Joac
I'm afraid I've lost track of where this discussion took place (does someone
else remember seeing it?), but I've advocated for faithful reproduction in the
past. In particular, the pretty-printers for HsSyn should, in my opinion, never
add or remove parentheses.
There is a problem here, though:
Jan’s question is a good one, but I don’t know enough about procs to be able to
answer. I do know that the answer can be found by looking for uses of
`tcSyntaxOp` in the TcArrows module but I just can’t translate it all to
source Haskell, having roughly 0 understanding of this end of the lan
I've thought about inequality on and off for years now, but it's a hard nut to
crack. If we want this evidence to affect closed type family reduction, then we
would need evidence of inequality in Core, and a brand-spanking-new type safety
proof. I don't wish to discourage this inquiry, but I als
> On Dec 14, 2016, at 10:07 AM, Carter Schonwald
> wrote:
>
> Possibly naive question: do we have decidable inequality in a meta
> theoretical sense? I feel like we have definite equality and fuzzy might not
> always be equal but could be for polymorphic types. And that definite
> inequality
/2015/equalities/equalities.pdf
[7]: https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
> On Dec 15, 2016, at 1:30 AM, Oleg Grenrus wrote:
>
> Out of curiosity: where's the current type safety proof, and is it
> mechanized?
>
> Oleg
>
>
> On 13.1
> On Dec 17, 2016, at 9:19 AM, Ross Paterson wrote:
>
> On Tue, Nov 29, 2016 at 12:41:53PM +, Simon Peyton Jones wrote:
>> Type checking and desugaring for arrow syntax has received Absolutely
>> No Love for several years. I do not understand how it works very well,
>> and I would not be at
I regularly use comment references on Trac, and I know others do, too. While
I'm not saying they need to be supported in a prototype before we elect to go
ahead with this route, I would say that preserving comment references is a
necessary part of this migration. Along similar lines, the comment
Hi Austin, Ben,
In trying to write a comment on Phab, I got this:
Unhandled Exception ("AphrontCSRFException")
You are trying to save some data to Phabricator, but the request your browser
made included an incorrect token. Reload the page and try again. You may need
to clear your cookies.
> On Dec 21, 2016, at 10:02 AM, Matthew Pickering
> wrote:
>
> Then looking at the culprits for some fun:
>
> (simonpj,192)
> (goldfire,123)
> (bgamari,116)
> (thomie,102)
> (nomeata,30)
> (rwbarton,28)
> (RyanGlScott,19)
> (simonmar,18)
Ha. I also use the long form comment:XX:ticket:YY somet
To clarify my comments in this thread around desugaring: I was referring to the
concrete Haskell code as written in GHC, not at all to an abstract desugaring
algorithm. The implementation of arrows in GHC uses fixM, which is a nuisance.
And I don't understand the code well enough to be able to u
On 1/3/17 6:32 PM, Matthew Pickering wrote:
The version field is not very useful as there are only two active
branches at once. Instead we want a project which marks tickets which
apply to the 8.0.2 branch for example. Tickets which refer to ancient
versions of GHC should be closed if they can't
> On Jan 4, 2017, at 5:18 AM, Matthew Pickering
> wrote:
>
> I am persuaded that component is useful. Richard makes the point that
> there is a murky divide between component and keywords. This is right
> and it indicates that we should keep the component field but also
> homogenise it was the
> On Jan 8, 2017, at 12:40 AM, Ben Gamari wrote:
>
> * Metadata: Custom fields are supported.
In agreement with your comments above, I'm glad to see this. Trac's metadata
currently is suboptimal, but I don't think this means we should throw out the
ability to have structured metadata in its e
> On Jan 8, 2017, at 8:33 PM, Thomas Jakway wrote:
>
> Currently I'm using trace & friends to do printf-style debugging but it's
> definitely not ideal.
I don't have an answer to your question, but I can tell you that this is
exactly what I do. It's not ideal at all. If you figure out how to
> On Jan 9, 2017, at 6:41 AM, Matthew Pickering
> wrote:
>
> Component -> Projects
> OS -> (Sub)Projects
> Arch -> (Sub)Projects
What is a (Sub)Project? I've been operating under the assumption that a Project
is just a tag. Do these tags have structure? My best guess from your discussion
is
> On Jan 9, 2017, at 11:03 AM, Simon Marlow wrote:
>
> The constraint-vs-type proposal seems a little bit weird in that it actually
> has a branch in the ghc-proposals repository itself, rather than being a pull
> request from a fork in @goldfire's account. Richard, was that intentional?
I l
This is correct behavior. The former has a CUSK, as all open type families have
CUSKs with un-annotated kinds defaulting to Type. The latter does not have a
CUSK, because the result kind is unknown. You therefore cannot specialize the k
variable in the definition of the latter.
There is a ticke
301 - 400 of 917 matches
Mail list logo
