On 20/01/2015 23:07, Edward Kmett wrote:
It is a long trek from "this is plausible" to "hey, let's bet the
future of records and bunch of syntax in the language on this".
Absolutely. On the other hand, this is the first proposal I've seen
that really hits (for me) a point in the design space that has an
acceptable power to weight ratio. Yes there are some corners cut, and
it remains to be seen whether, after we've decided which corners we want
to uncut, the design retains the same P2W ratio.
A couple of answers to specific points:
Re #1
The main term and type level bits of syntax that could be coopted
that aren't already in use are @ and (~ at the term level) and things
like banana brackets (| ... |), while that already has some other,
unrelated, connotations for folks, something related like {| ... |}.
We use such bananas for our row types in Ermine to good effect.
The latter {| ... |} might serve as a solid syntax suggestion for the
anonymous row type syntax.
Why not just use { ... } ?
Re #2
That leaves the means for how to talk about a lens for a given field
open. Under Adam's proposal that had evolved into making a really
complicated instance that we could extract a lens from. This had the
benefit over the current state of the `record` package that we could
support full type changing lenses. Losing type-changing assignment
would be a big step back from the previous proposal / the current
state of development for folks who just use makeClassy or custom lens
production rules with lens to get something similar, though.
But the thing we never found was a nice short syntax for talking
about the lens you get from a given field (or possibly chain of
fields); Gundry's solution was 90% library and almost no syntax. On
the other hand Adam was shackled by having to let the accessor be
used as a normal function as well as a lens. Nikita's records don't
have that problem.
Having no syntax at all for extracting the lens from a field
accessor, but rather to having it just be the lens, could directly
address that concern. This raises some questions about scope, where
do these names live? What happens when you have a module A that
defines a record with a field, and a module B that does the same for
a different record, and a module C that imports both, but, really, we
had those before with Adam's proposal, so there is nothing new
there.
Right. So either
(a) A field name is a bare identifier that is bound to the lens, or
(b) There is special syntax for the lens of a field name
If (a) there needs to be a declaration of the name in order that we can
talk about scoping. That makes (b) a lot more attractive; and if you
really find the syntax awkward then you can always bind a local variable
to the lens, or export the names from your library.
And for what it is worth, I've seen users in the wild using
makeLenses on records with several hundred fields (!!), so we'd need
to figure out something that doesn't cap a record at 24 fields. This
feedback came in because we made the lenses lazier and it caused some
folks a great deal of pain in terms of time spent in code gen!
Sure. We deal with large tuples by nesting, and I imagine something
similar could be done for records (I haven't worked through the details
though).
Cheers,
Simmon
It would also necessarily entail moving a middling-sized chunk of
lens into base so that you can actually do something with these
accessors. I've been trying to draw lines around a "lens-core" for
multiple years now. Everyone has a different belief of what it should
be, and trust me, I've heard, and had to shoot down basically all of
the pitches.
We're going to be stuck with the warts of whatever solution we build
for a very long time.
So with those caveats in mind, I'd encourage us to take our time
rather than rush into trying to get this 7.12 ready.
Personally I would be happy if by the time we ship 7.12 we had a plan
for how we could proceed, that we could then judge on its merits.
-Edward
On Tue, Jan 20, 2015 at 4:44 PM, Simon Marlow <[email protected]
<mailto:[email protected]>> wrote:
For those who haven't seen this, Nikita Volkov proposed a new
approach to anonymous records, which can be found in the "record"
package on Hackage: http://hackage.haskell.org/__package/record
<http://hackage.haskell.org/package/record>
It had a *lot* of attention on Reddit:
http://nikita-volkov.github.__io/record/
<http://nikita-volkov.github.io/record/>
Now, the solution is very nice and lightweight, but because it is
implemented outside GHC it relies on quasi-quotation (amazing that it
can be done at all!). It has some limitations because it needs to
parse Haskell syntax, and Haskell is big. So we could make this a
lot smoother, both for the implementation and the user, by directly
supporting anonymous record syntax in GHC. Obviously we'd have to
move the library code into base too.
This message is by way of kicking off the discussion, since nobody
else seems to have done so yet. Can we agree that this is the right
thing and should be directly supported by GHC? At this point we'd be
aiming for 7.12.
Who is interested in working on this? Nikita?
There are various design decisions to think about. For example, when
the quasi-quote brackets are removed, the syntax will conflict with
the existing record syntax. The syntax ends up being similar to
Simon's 2003 proposal
http://research.microsoft.com/__en-us/um/people/simonpj/__Haskell/records.html
<http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html>
(there are major differences though, notably the use of lenses for
selection and update).
I created a template wiki page:
https://ghc.haskell.org/trac/__ghc/wiki/Records/Volkov
<https://ghc.haskell.org/trac/ghc/wiki/Records/Volkov>
Cheers, Simon _________________________________________________
ghc-devs mailing list [email protected]
<mailto:[email protected]>
http://www.haskell.org/__mailman/listinfo/ghc-devs
<http://www.haskell.org/mailman/listinfo/ghc-devs>
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
