families.
>
> Can one give a standalone explanation of the fundep/type-family/overlap
> issue here?
> Or is it explained on a wiki page?
>
Neither is it specifically about the Overloaded Record Fields design,
nor anonymous records -- it's just that you need a meaty applica
>
> The labelled "birthday = ..." approach seems
> tantalisingly close to data constructors:
>( Name "Fred", Birthday $ Date 28 4 2016 )
>
> Which takes us (perhaps) to HLIst-style
> Type-Indexed Products.
> How could they fit with ORF?
> Perhaps introduce an implicit label spelled same as the
> Adam Gundry well-typed.com> writes:
> ...
>
> P.S. If you have any thoughts on the interaction between ORF and
> encodings of anonymous records, I'd be interested to hear them.
Are you sure you want to open up that question? ;-)
Nikita's record library has certainly given food for thought.
Be
| > I have been vacillating between type families and fundeps for the ORF
| > classes. I hadn't fully appreciated this point about overlap, but I
| > think it is a reason to prefer fundeps, which is the direction in
| > which I'm leaning. I'd be grateful for feedback on this issue though!
...
> > On 26/04/16 09:20, AntC wrote:
> > There's an intriguing comment here wrt anonymous records: ...
>
> I'm afraid the sentence on the wiki page is slightly misleading, ...
> with the change to functional dependencies,
> the overlapping instances solution works rather nicely,
> in that it works
Hi AntC,
On 26/04/16 09:20, AntC wrote:
> There's an intriguing comment here wrt anonymous records:
> https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/
> MagicClasses#Designextension:anonymousrecords
> (End of the section)
>
> "... this doesn't quite work, because the two inst
There's an intriguing comment here wrt anonymous records:
https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/
MagicClasses#Designextension:anonymousrecords
(End of the section)
"... this doesn't quite work, because the two instances overlap,
but it is possible with a bit more tr
+1 for the -XDotPostfixApply proposal
--
View this message in context:
http://haskell.1045720.n5.nabble.com/Overloaded-record-fields-tp5731998p5733121.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at
Nabble.com
+1 for orthogonal -XDotPostfixApply.
I'm in the absolutely-love-using-dot-for-records camp, but I also like "foo
s1.toUpper s2.toUpper".
We're already so lazy about parentheses -- e.g. the non-haskellers I show
code to are always appalled at $ ;-) -- and this helps scrap more parens!
On Mon, J
Hi all,
I have amended the plan [1] as a result of the ongoing discussion,
including leaving the syntax alone for the time being, so record
projections are written prefix.
Regarding Barney's suggestion of field declarations:
On 01/07/13 10:50, Barney Hilken wrote:
> All this extra syntax, whethe
(sorry, accidentally failed to send this to the list)
All this extra syntax, whether it's ., #, or {} seems very heavy for a problem
described as very rare.
Why not simply use a declaration
field name
whose effect is to declare
name :: r {name ::t} => r -> t
name = get
>
> Simon, Malcolm, here's a solution (at risk of more bikeshedding on syntax).
>
>e { foo }
>
> * The braces say 'here comes a record'.
> * Also say 'expect funny business with names'.
> * The absence of `=` says this is getFld, not update.
> * This is not currently valid syntax [**], s
> Malcolm Wallace me.com> writes:
>
> I believe Simon's point is that, if dot is special, we can infer
the "Has" type above, even if the compiler is
> not currently aware of any actual record types that contain a "foo"
field. ...
>
> (For the record, I deeply dislike making dot special, ...
S
at least on "foo" field in scope.
> >
> > I wanted to jot this point down, but I think it's a lesser evil than
> falling into the dot-notation swamp. After all, it must be vanishingly
> rare to write a function manipulating "foo" fields when there are no su
this point down, but I think it's a lesser evil than falling
> into the dot-notation swamp. After all, it must be vanishingly rare to write
> a function manipulating "foo" fields when there are no such records around.
> It's just a point to note (NB Adam: desi
> Malcolm Wallace me.com> writes:
>
> >>
> >> With the orthogonal proposal, f is equivalent to
> >>f r b = foo r && b
>
> I believe Simon's point is that, if dot is special, we can infer
the "Has" type above, even if the compiler is
> not currently aware of any actual record types that con
On 28 Jun 2013, at 12:16, AntC wrote:
> Thanks Simon, I'm a little puzzled what your worry is.
>
>> f r b = r.foo && b
>> With dot-notation baked in (non-orthogonally), f would get the type
>>
>> f :: (r { foo::Bool }) => r -> Bool -> Bool
>>
>> With the orthogonal proposal, f is eq
> Simon Peyton-Jones microsoft.com> writes:
>
> I have, however, realised why I liked the dot idea. Consider
>
> f r b = r.foo && b
>
Thanks Simon, I'm a little puzzled what your worry is.
> With dot-notation baked in (non-orthogonally), f would get the type
>
> f :: (r { foo::Bo
Hi Evan,
> 1 - Add an option to add a 'deriving (Lens)' to record declarations.
> That makes the record declare lenses instead of functions.
Well, no, that's exactly the kind of magic programming language hackery,
that Haskell shouldn't be part of.
Deriving should only add something, but not ch
age-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-
| users-boun...@haskell.org] On Behalf Of AntC
| Sent: 27 June 2013 13:37
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Overloaded record fields
|
| >
| > ... the orthogonality is also an important be
I'm reluctant to add yet another opinion, but, oh what the heck:
For me, lenses basically already solve the record problem. The only
missing thing is to integrate them better with record declaration
syntax. Having to rely on TH and then write a makeLenses splice is
just too much friction to have
duces backwards incompatibility for people who want overloaded record
fields in their existing code. Perhaps we can leave the arguments over
dot syntax for another thread?
There are a bunch of options for translating record fields into selector
functions:
* monomorphically, as in Haskell 98, which is s
Somebody claiming to be Dominique Devriese wrote:
I would prefer to have dot notation for a
general, very tightly-binding reverse application, and the type of the record
selector for a field f changed to "forall r t. r { f :: t } => r -> t"
instead of
"SomeRecordType -> t". Such a general revers
Somebody claiming to be Simon Peyton-Jones wrote:
It is kind of weird that
f . g means\x. f (g x)
but f.gmeansg f
Anything that makes f.g mean something different from f . g just makes the
code soup.
F . g being different from F.g is already *very* unfortunate. The
This (AntC's points 1-8) is the best plan yet. By getting rid of dot notation,
things
become more compatible with existing code. The only dodgy bit is import/export
in point 7:
> 7. Implement -XPolyRecordFields, not quite per Plan.
> This generates a poly-record field selector function:
>
>
On 6/27/13 8:37 AM, AntC wrote:
Folks, I'm keenly aware that GSoC has a limited timespan; and that there
has already been much heat generated on the records debate.
Perhaps we could concentrate on giving Adam a 'plan of attack', and help
resolving any difficulties he runs into. I suggest:
Adam
>
> ... the orthogonality is also an important benefit.
> It could allow people like Edward and others who dislike ...
> to still use ...
>
Folks, I'm keenly aware that GSoC has a limited timespan; and that there
has already been much heat generated on the records debate.
Perhaps we could c
> Adam Gundry strath.ac.uk> writes:
>
> I've started to document the plan on the GHC wiki:
>
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Pla
n
>
Thank you Adam, (Simon)
I like the approach for Representation hiding. (That was something I was
particularly trying to
On Thu, Jun 27, 2013 at 2:14 AM, AntC wrote:
> Does the lens approach meet SPJ's criteria of:
> * It is the smallest increment I can come up with that
>meaningfully addresses the #1 pain point (the inability to
>re-use the same field name in different records).
>
> * It is backward-comp
| Exactly! (I did tell you so:
|
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix
| billed as "optional syntactic sugar")
I confess that I had not fully taken in this suggestion; thank you for
reminding me. The last round exceeded my input bandwidth,
On Thu, Jun 27, 2013 at 2:14 AM, AntC wrote:
> > Edward Kmett gmail.com> writes:
> >
> > Let me take a couple of minutes to summarize how the lens approach
> tackles the composition problem today without requiring confusing changes
> in the lexical structure of the language.
>
> Thank you Edward
Simon,
Yes, your summary is exactly what I meant.
2013/6/26 Simon Peyton-Jones :
> In fact, your observation allows us to regard our proposal as consisting of
> two entirely orthogonal parts
> * Generalise the type of record field selectors
> * Introduce period as reverse function applicatio
> Edward Kmett gmail.com> writes:
>
> Let me take a couple of minutes to summarize how the lens approach
tackles the composition problem today without requiring confusing changes
in the lexical structure of the language.
Thank you Edward, I do find the lens approach absolutely formidable. And
> data T = MkT { f :: Int }
>
> foo :: [T] -> [Int]
> foo = map f xs
>
> because the field selector 'f' has the very general type you give, but the
> type signature would be enough to fix it. Or, if foo lacks a type
> signature, I sup
>
> person.lastName.toUpper-- <==> toUpper (lastName person)
>
Oops! that should be one of:
person.lastName.head.toUpper
person.lastName.(map toUpper)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
ht
> Simon Peyton-Jones microsoft.com> writes:
>
> | record projections. I would prefer to have dot notation for a
> | general, very tightly-binding reverse application, ...
> | Such a general reverse application dot would
> | allow things like "string.toUpper" and for me personally, it would
>
> Mateusz Kowalczyk fuuzetsu.co.uk> writes:
>
>
> On 24/06/13 11:04, Roman Cheplyaka wrote:
> > * Mateusz Kowalczyk fuuzetsu.co.uk> [2013-06-24
> > 10:47:09+0100]
> >> Restricting function composition to have spaces around it will
> >> require changing a large amount of existing code if one is
ogonal parts
> * Generalise the type of record field selectors
> * Introduce period as reverse function application
>
> Both have merit.
>
> Simon
>
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org [mailto:
> glasgow-haskell-users-
&g
e function application
Both have merit.
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Dominique Devriese
| Sent: 26 June 2013 13:16
| To: Adam Gundry
| Cc: glasgow-haskell-users@haskell.org
| S
it would
make a Haskell OO library that I'm working on more elegant...
But I guess you've considered such a design and decided against it,
perhaps because of the stronger backward compatibility implications of
changing the selectors' types?
Dominique
2013/6/24 Adam Gundry :
>
ote:
> On 06/24/2013 08:44 AM, Adam Gundry wrote:
>> Hi everyone,
>>
>> I am implementing an overloaded record fields extension for GHC as a
>> GSoC project. Thanks to all those who gave their feedback on the
>> original proposal! I've started to document the plan o
On 06/24/2013 08:44 AM, Adam Gundry wrote:
> Hi everyone,
>
> I am implementing an overloaded record fields extension for GHC as a
> GSoC project. Thanks to all those who gave their feedback on the
> original proposal! I've started to document the plan on th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/06/13 11:05, Mateusz Kowalczyk wrote:
> On 24/06/13 11:04, Roman Cheplyaka wrote:
>> * Mateusz Kowalczyk [2013-06-24
>> 10:47:09+0100]
>>> Restricting function composition to have spaces around it will
>>> require changing a large amount of ex
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/06/13 11:04, Roman Cheplyaka wrote:
> * Mateusz Kowalczyk [2013-06-24
> 10:47:09+0100]
>> Restricting function composition to have spaces around it will
>> require changing a large amount of existing code if one is
>> willing to use it.
>
> I a
* Mateusz Kowalczyk [2013-06-24 10:47:09+0100]
> Restricting function composition to have spaces around it will require
> changing a large amount of existing code if one is willing to use it.
I assume this semantics will be triggered only by an extension, so
there'd be no need to change existing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/06/13 08:44, Adam Gundry wrote:
> Hi everyone,
>
> I am implementing an overloaded record fields extension for GHC as
> a GSoC project. Thanks to all those who gave their feedback on the
> original proposal! I've started
| I am implementing an overloaded record fields extension for GHC as a
| GSoC project. Thanks to all those who gave their feedback on the
| original proposal! I've started to document the plan on the GHC wiki:
|
| http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/
|
Hi everyone,
I am implementing an overloaded record fields extension for GHC as a
GSoC project. Thanks to all those who gave their feedback on the
original proposal! I've started to document the plan on the GHC wiki:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
48 matches
Mail list logo
