magicDict

Simon Peyton Jones simonpj at microsoft.com
Mon Apr 26 21:21:58 UTC 2021


You mean you like 'withDict' with that name,  as well as the argument order K suggests?   i.e. not reifyDict?

Simon

From: Edward Kmett <ekmett at gmail.com>
Sent: 26 April 2021 21:34
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Krzysztof Gogolewski <krz.gogolewski at gmail.com>; Spiwack, Arnaud <arnaud.spiwack at tweag.io>; GHC developers <ghc-devs at haskell.org>; Ryan Scott <ryan.gl.scott at gmail.com>
Subject: Re: magicDict

I like withDict a lot. It is direct, easy to chain/use, avoids fighting about direction completely, and even matches the argument order used by reify in the reflection library.

+1 from me.

On Mon, Apr 26, 2021 at 7:49 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
|  I would like to propose one more option:
|
|  withDict :: dt -> (ct => a) -> a

Ah, you mean simply: swap the argument order.   I can see your logic about chaining etc.  I'd be fine with this.

Simon

|  -----Original Message-----
|  From: Krzysztof Gogolewski <krz.gogolewski at gmail.com<mailto:krz.gogolewski at gmail.com>>
|  Sent: 26 April 2021 15:35
|  To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
|  Cc: Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>; Edward Kmett
|  <ekmett at gmail.com<mailto:ekmett at gmail.com>>; GHC developers <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
|  Subject: Re: magicDict
|
|  I would like to propose one more option:
|
|  withDict :: dt -> (ct => a) -> a
|
|  1. This is less symmetric than '(ct => a) -> dt -> a'
|     but in existing applications magicDict gets the arguments
|     in the reverse order.
|  2. Easier to chain 'withDict d1 (withDict d2 ...)'.
|  3. The name is similar to 'withTypeable' or 'withFile',
|     and avoids arguing which is reify or reflect.
|
|  On Mon, Apr 26, 2021 at 9:41 AM Simon Peyton Jones via ghc-devs <ghc-
|  devs at haskell.org<mailto:devs at haskell.org>> wrote:
|  >
|  > Can we just agree a name, then?   Please correct me if I'm wrong,
|  but
|  >
|  > I think Ed prefers 'reifyDict',
|  > That is compatible with the existing reflection library Arnaud
|  > disagrees but isn't going to die in the trenches for this one
|  > Virtually anything is better than 'magicDict'.
|  >
|  >
|  >
|  >
|  >
|  > So: reifyDict it is?
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  > From: Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
|  > Sent: 26 April 2021 08:10
|  > To: Edward Kmett <ekmett at gmail.com<mailto:ekmett at gmail.com>>
|  > Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; GHC developers
|  > <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
|  > Subject: Re: magicDict
|  >
|  >
|  >
|  >
|  >
|  >
|  >
|  > On Sun, Apr 25, 2021 at 2:20 AM Edward Kmett <ekmett at gmail.com<mailto:ekmett at gmail.com>>
|  wrote:
|  >
|  > I speak to much this same point in this old stack overflow response,
|  though to exactly the opposite conclusion, and to exactly the opposite
|  pet peeve.
|  >
|  >
|  >
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstac
|  >
|  koverflow.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkoverflow.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc489a190b534d771e8e08d908f2a2d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550660487039029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=p1oBeQtmxDH%2BRx%2FDNmIGeshz8PA0BEdiAcOk1faB0xc%3D&reserved=0>%2Fa%2F5316014%2F34707&data=04%7C01%7Csimonpj%40micro
|  >
|  soft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc489a190b534d771e8e08d908f2a2d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550660487049021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=N6k7M4FOB19jwAJVlx0y5WOxLwv7VUf58iihdwz2mhQ%3D&reserved=0>%7C87da21fdcc8e4ed6bef508d908c071fb%7C72f988bf86f141af91ab2d7c
|  >
|  d011db47%7C1%7C0%7C637550444930791696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
|  >
|  MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
|  >
|  sdata=VlRrIEROGj%2BE6%2FuLXBEdfa%2BPWVlHh50dahgjIrw4tQU%3D&reserve
|  > d=0
|  >
|  >
|  >
|  > :-)
|  >
|  >
|  >
|  > I do not feel that I chose the vocabulary without due consideration
|  of the precise meaning of the words used.
|  >
|  >
|  >
|  > I didn't mean to imply that you did. Sorry if I did so: written
|  communication is hard. For what it's worth, I didn't really think that
|  I would change your mind, either.
|  >
|  >
|  >
|  > Though it still seems to me that the name `ReifiedMonoid` uses the
|  word for a different thing than the `reifyMonoid` function does.
|  >
|  >
|  >
|  > To be explicit:
|  >
|  >
|  >
|  > Viewing a type as a space, 'reify' in the reflection library takes
|  some space 'a' and splits it into individual fibers for each term in
|  'a', finding the appropriate one and handing it back to you as a fresh
|  type 's' that captures just that singular value. The result is
|  significantly less abstract, as we gained detail on the type, now
|  every point in the original space 'a' is a new space. At the type
|  level the fresh 's' in s `Reifies` a now concretely names exactly one
|  inhabitant of 'a'.
|  >
|  >
|  >
|  > On the flip side, 'reflect' in the reflection library forgets this
|  finer fibration / structure on space, losing the information about
|  which fiber the answer came from, being forgetful is precisely the
|  justification of it being the 'reflect' half of the reify -| reflect
|  pairing.
|  >
|  >
|  >
|  > I confess I don't necessarily anticipate this changing your mind but
|  it was not chosen blindly, reflect is the forgetful mapping here,
|  reification is free and left adjoint to it, at least in the context of
|  reflection-the-library, where a quantifier is being injected to track
|  the particular member.
|  >
|  >
|  >
|  > I've got to admit that I have the hardest time seeing the `s` as
|  representing an inhabitant of `a`. I'm probably missing something
|  here.
|  >
|  >
|  >
|  > I also don't think that a free object construction embodies a
|  reify/reflect pair completely. It's probably fair to see `reify` as
|  being the natural mapping from the free object of X to X (the counit
|  of the adjunction). But reification will not be the unit of the
|  adjunction, because it's trivial. So there is still a piece missing in
|  this story.
|  >
|  >
|  >
|  > Anyway... I've made my point, and I am not too willing to spend too
|  much time proving Wadler's law correct. So I think I'll stop here,
|  fascinating a conversation though it is.
|  >
|  >
|  >
|  > Best,
|  >
|  > Arnaud
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.
|  > haskell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc489a190b534d771e8e08d908f2a2d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550660487049021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jb06dc8TTuyWU1YLju%2B3QaK7mj6XWYYVj1y%2FCzBJxs8%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=04%7C01
|  >
|  %7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbc489a190b534d771e8e08d908f2a2d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550660487059014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TKElWjsvplhVB%2B1Y27nnOo7LKLrCgLUcWrYX5ZOSwE0%3D&reserved=0>%7C87da21fdcc8e4ed6bef508d908c071fb%7C72f988
|  >
|  bf86f141af91ab2d7cd011db47%7C1%7C0%7C637550444930791696%7CUnknown%7CTW
|  >
|  FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
|  >
|  Mn0%3D%7C1000&sdata=4JfXyRNMjQKTSLqme2VJU9Dy0s6N4Y8t%2BINHYp38xJk%
|  > 3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210426/426d22d1/attachment.html>


More information about the ghc-devs mailing list