There's no need to set the srt field of f_info if f_closure is the SRT,
since any reference to f_info in the code will give rise to a reference to
f_closure in the SRT corresponding to that code fragment. Does that make
sense?
The use of a closure as an SRT is really quite a nice optimisation actu
For reference, hadrian-util lives at:
https://gitlab.haskell.org/bgamari/hadrian-util
I quite like the idea of trying out improvements to the UX via an
external wrapper. For wider adoption, we'd have to distribute it in a
nicer way I suppose, but taking this one step at a time sounds good.
O
This looks really useful, and might bridge the gap between the UX I'm used to
and Hadrian, allowing me to adopt Hadrian sooner than I otherwise would.
However, I would be disappointed to see hadrian-util still in active use when
`make` is removed (#17527). I'm glad to see Ben's %Make removal mil
> On Jan 6, 2020, at 4:44 AM, Ben Gamari wrote:
> Try adding -dppr-debug to your command line. This may reveal the difference.
Also, I recommend `-fprint-explicit-kinds -fprint-explicit-coercions
-fprint-typechecker-elaboration -fprint-explicit-runtime-reps
-fprint-explicit-foralls` just for
You're absolutely right that improvement doesn't solve your problem. But what I
didn't say is that there is no real reason (I think) that we can't improve
improvement to produce givens. This would likely require a change to the
coercion language in Core (and thus not to be taken lightly), but if
I've read this thread, superficially so far. But I'm puzzled about the goal.
| type family F a b :: Constraint where
| F a a = ()
|
| eq :: F a b => a :~: b
| eq = Refl
This is rejected, and it's not in the least bit puzzling! You have evidence
for (F a b) and you need to pro
Derek Lam writes:
> Hi ghc-devs,
>
Hi Derek,
> I’m making a first attempt to make a frontend plugin, to resolve cabal
> packages in the GHC API. However I’m running into troubles with module
> resolution in the GHC API, because I can’t control where it will
> search for modules at all. I've atta
Omer,
I think I’m not understanding all the details, but I have a clear “big
picture”. Simon can correct me if I’m wrong.
·The info table for any closure (top-level or otherwise) has a
(possibly empty) Static Reference Table, SRT.
·The SRT for an info table identifies the st
> On Jan 6, 2020, at 2:52 PM, Simon Peyton Jones via ghc-devs
> wrote:
>
> | type family F a b :: Constraint where
> | F a a = ()
> |
> | eq :: F a b => a :~: b
> | eq = Refl
>
> This is rejected, and it's not in the least bit puzzling! You have evidence
> for (F a b) and
> On Jan 6, 2020, at 08:52, Simon Peyton Jones wrote:
>
> This is rejected, and it's not in the least bit puzzling! You have evidence
> for (F a b) and you need to prove (a~b) -- for any a and b. Obviously you
> can't. And in Core you could write (eq @Int @Bool (error "urk")) and you
> joll
We have:
* wiki:
https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts/storage/gc/cafs
* a huge Note in CmmBuildInfoTables:
https://gitlab.haskell.org/ghc/ghc/blob/master/compiler%2Fcmm%2FCmmBuildInfoTables.hs#L42
Maybe we need links to these from other places?
Omer's question is referring spec
> On Jan 6, 2020, at 12:05, Alexis King wrote:
>
>type family F a b where
> F a b = () -- regular (), not (() :: Constraint)
(Err, sorry, this should be `F a a = ()`. But I think you can understand what
I’m getting at.)
___
ghc-devs mailing l
> On Jan 6, 2020, at 05:29, Richard Eisenberg wrote:
>
> You're absolutely right that improvement doesn't solve your problem. But
> what I didn't say is that there is no real reason (I think) that we can't
> improve improvement to produce givens. This would likely require a change to
> the co
Aha, great. Well at least [Note SRTs] should point back to the wiki page.
Omer's question is referring specifically to the [FUN] optimisation described
in the Note.
Hmm. So is he asking whether f’s SRT should have an entry for itself? No,
that’ would be silly! It would not lead to any more C
| In this case, in core, we receive an argument of type `F a b ~ ()`, and we
| can force that to obtain a coercion of type `F a b ~# ()`. For reasons
| similar to the mechanisms behind injective type families, that equality
| really does imply `a ~# b`.
Ah, I see a bit better now. So you want a w
Hi Ben,
Thanks for the pointer. I looked for the error call and it does indeed look
like the path from the error in GhcMake.downsweep feeds from
GhcMake.summariseModule and then Finder.findImportedModule. A cursory look at
Finder seems to suggest that the importPaths retrieved in
findInstalled
Hi all,
> There's no need to set the srt field of f_info if f_closure is the SRT, since
> any reference to f_info in the code will give rise to a reference to f_closure
> in the SRT corresponding to that code fragment. Does that make sense?
Makes sense, thanks.
> The use of a closure as an SRT i
17 matches
Mail list logo
