On 21/01/2015 16:01, Johan Tibell wrote:
My thoughts mostly mirror those of Adam and Edward.
1) I want something that is backwards compatible.
Backwards compatible in what sense? Extension flags provide backwards
compatibility, because you just don't turn on the extension until you
want to use it. That's how all the other extensions work; most of them
change syntax in some way or other that breaks existing code.
2) Anonymous records are nice to have, but I don't want to have all
records be anonymous (and have to jump through newtype hoops to get back
non-anonymous records.)
So right now you have to say
data T = R { a :: Int }
and with anonymous records you could say
data T = R {| a :: Int |}
(or something similar). That doesn't seem like jumping through hoops,
it's exactly the same amount of syntax. If you're worried about the
extra layer of boxing (quite reasonable) then either (a) use a newtype,
if possible, or (b) we could consider automatic UNPACKing of records
used in a constructor argument.
3) I don't think it's a good idea to have lots of functions be
polymorphic in the record types of their arguments. If that falls out
for free (like it does both in ORF and Nikita's proposals) that's nice,
but I think anonymous records should be used sparsely.
There are stylistic issues with the use of anonymous records, I agree.
But I don't consider anonymous records to be the main feature here, it's
just a nice way to factor the design.
[..]
4) There are issues with strictness and unpacking.
Yes - probably the major drawbacks, along with the lack of type-changing
updates.
5) I don't know if I want to commit the *language* to a particular lens
type.
Fair point.
Cheers,
Simon
On Wed, Jan 21, 2015 at 2:11 PM, Edward Kmett <[email protected]
<mailto:[email protected]>> wrote:
Personally, I think the two proposals, ORF and Nikita's record
approach address largely differing needs.
The ORF proposal has the benefit that it doesn't require GHC itself
to know anything about lenses in order to work and is mostly
compatible with the existing field accessor combinators.
Nikita's proposal on the other hand builds a form of Trex-like
records where it has its own little universe to play in, and doesn't
have to contort itself to make the field accessors backwards
compatible. As its own little world, the fact that the ORF can't
deal with certain types of fields just becomes a limitation on this
little universe, and all existing code would continue to work.
I, too, have a lot of skin in the game with the existing ORF
proposal, but ultimately we're going to be stuck with whatever
solution we build for a long time, and it is, we both have to
confess, admittedly quite complicated, so it seems exploring the
consequences of a related design which has different constraints on
its design does little harm.
I'm mostly paying the work the courtesy it deserves by considering
to its logical conclusion what such a design would look like fleshed
out in a way that maximized how nice the result could be to use. I'm
curious, as mostly a thought experiment, how nice a design we could
get in the end under these slightly different assumptions.
If, in the end, having an anonymous record syntax that is distinct
from the existing one is too ugly, it is okay for us to recoil from
it and go back to committing to the existing proposal, but I for one
would prefer to "steelman
<https://themerelyreal.wordpress.com/2012/12/07/steelmanning/>"
Nikita's trick first.
Thus far, all of this is but words in a handful of emails. I happen
to think the existing ORF implementation is about as good as we can
get operating under the assumptions it does. That said, operating
under different assumptions may get us a nicer user experience. I'm
not sure, though, hence the thought experiment.
-Edward
On Wed, Jan 21, 2015 at 5:05 AM, Adam Gundry <[email protected]
<mailto:[email protected]>> wrote:
As someone with quite a lot of skin in this game, I thought it
might be
useful to give my perspective on how this relates to ORF.
Apologies that
this drags on a bit...
Both approaches use essentially the same mechanism for resolving
overloaded field names (typeclasses indexed by type-level strings,
called Has/Upd or FieldOwner). ORF allows fields to be both
selectors
and various types of lenses, whereas the record library always makes
them van Laarhoven lenses, but this isn't really a fundamental
difference.
The crucial difference is that ORF adds no new syntax, and solves
Has/Upd constraints for existing datatypes, whereas the record
library
adds a new syntax for anonymous records and their fields that is
completely separate from existing datatypes, and solves FieldOwner
constraints only for these anonymous records (well, their
desugaring).
On the one hand, anonymous records are a very desirable feature,
and in
some ways making them separate is a nice simplification.
However, they
are not as expressive as the existing Haskell record datatypes
(sums,
strict/unpacked fields, higher-rank fields), and having two records
mechanisms is a little unsatisfying. Do we really want to
distinguish
data Foo = MkFoo { bar :: Int, baz :: Bool }
data Foo = MkFoo {| bar :: Int, baz :: Bool |}
(where the first is the traditional approach, and the second is a
single-argument constructor taking an anonymous record in Edward's
proposed syntax)?
It might be nice to have a syntactic distinction between record
fields
and normal functions (the [l|...|] in the record library),
because it
makes name resolution much simpler. ORF was going down the route of
adding no syntax, so name resolution becomes more complex, but
we could
revisit that decision and perhaps make ORF simpler. But I don't know
what the syntax should be.
I would note that if we go ahead with ORF, the record library could
potentially take advantage of it (working with ORF's Has/Upd classes
instead of defining its own FieldOwner class). Then we could
subsequently add anonymous records to GHC if there is enough
interest
and implementation effort. However, I don't want to limit the
discussion: if there's consensus that ORF is not the right approach,
then I'm happy to let it go the way of all the earth. ;-)
(Regarding the status of ORF, Simon PJ and I had a useful
meeting last
week where we identified a plan for getting it back on track,
including
some key simplifications to the sticking points in the
implementation.
So there might be some hope for getting it in after all.)
Adam
On 20/01/15 21:44, Simon Marlow 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
>
> It had a *lot* of attention on Reddit:
> 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
> (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
>
> Cheers,
> Simon
--
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
ghc-devs mailing list
[email protected] <mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected] <mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
