I'm sorry, I misunderstood the paper and thought the depth of the
instantiation and subsumption could be varied more independently.
That said, what about the seq example below? Does forcing any function
that is eta expanded like that sketchy to you? There is still a runtime
cost to the eta expansion, but think with more elbow grease that could
also be addressed (post-type-erasure optimization or new coercions).
John
On 6/18/21 3:56 PM, Simon Peyton Jones wrote:
Richard’s paper argues for lazy rather than eager instantiation.
It does *not* argue for deep rather than shallow subsumption and
instantiation; on the contrary, it argues for shallow. (That is, for
“simple subsumption”.) And it is simple subsumption that is the
focus of this conversation.
Simon
*From:*John Ericson <john.ericson@obsidian.systems>
*Sent:* 18 June 2021 16:56
*To:* ghc-devs <ghc-devs@haskell.org>
*Cc:* Simon Peyton Jones <simo...@microsoft.com>
*Subject:* Re: Is simplified subsumption really necessary?
On 6/16/21 12:00 PM, Simon Peyton Jones via ghc-devs wrote:
I’m sorry to hear that Chris. It’s exactly backwards from what
I would expect – the typing rules with simple subsumption are,
well, simpler than those for complicated subsumption, and so one
might hope that your intuition had fewer complexities to grapple
with.
In https://richarde.dev/papers/2021/stability/stability.pdf
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fricharde.dev%2Fpapers%2F2021%2Fstability%2Fstability.pdf&data=04%7C01%7Csimonpj%40microsoft.com%7C7655b09d06a54a4af03508d9327193cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637596286139778988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=R1quXKjsnEjusvX%2BSxhPT25t%2B%2Bwqwo7mTPhnulvctQ0%3D&reserved=0>
it is written
The analysis around stability in this paper strongly suggests that
GHC should use the lazy, shallow approach to instantiation. Yet
the struggles with lazy instantiation above remain. In order to
simplify the implementation, GHC has recently (for GHC 9.0)
switched to use exclusively eager instantiation.This choice
sacrifices stability for convenience in implementation.
I think the principles outlined in the paper are very good, and
explain the queasiness some users may feel in 9.0
But wouldn't it be possible to choose a desugaring with seq that
doesn't do so?
I just don’t know how to do that. Maybe someone else does.
Is it not
f `seq` \x -> f x
and similar? I haven't thought about the issue in a while or in very
much depth, but when I first discussed the proposal years back with
some other people at work, they spit-balled the same counter-proposal.
----
Having little "skin in the game" as I haven't yet ported any serious
programs over to 9.0, I suppose I am glad the experimentation with
QuickLook is happening, and OK that our accepting on-par fewer
programs now opens design space for later (i.e. we got the breakage
out of the way.) But I certainly think there are improvements in the
spirit outlined in Richard's paper to be done down the road.
John
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
