On 22/04/2012, AntC wrote:
> Matthew Farkas-Dyck gmail.com> writes:
>
>> I made another proposal for records in Haskell, meant to solve just
>> the namespace problem, and no more.
>> http://hackage.haskell.org/trac/ghc/wiki/Records/ExplicitClassyRecords
>>
>
Matthew Farkas-Dyck gmail.com> writes:
> I made another proposal for records in Haskell, meant to solve just
> the namespace problem, and no more.
> http://hackage.haskell.org/trac/ghc/wiki/Records/ExplicitClassyRecords
>
Thanks Matthew, I'm finding your wiki too sketchy t
Hello GHC users.
I made another proposal for records in Haskell, meant to solve just
the namespace problem, and no more.
http://hackage.haskell.org/trac/ghc/wiki/Records/ExplicitClassyRecords
In this system, record selectors are overloaded in
explicitly-user-declared type classes. Thus one can
Gábor Lehel gmail.com> writes:
>
> ..., but DORF actually requires less type system magic than
> SORF, and also already has a working prototype implementation, ...
>
> ... My main complaint against DORF is
> that having to write fieldLabel declarations for every field you want
> to use is onerou
>
> On Fri, Mar 02, 2012 at 01:04:13AM +, AntC wrote:
> >
> > Let me explain better what I mean by "two private namespaces", then we'll
> > try to understand how your proposal goes ...
>
Folks, it has been very difficult keeping up with all the twists and turns of
this thread.
So here's
On 06/03/2012, AntC wrote:
> Matthew Farkas-Dyck gmail.com> writes:
>> > Oh, and how do you deal with multiple record constructors as in H98:
>> >data T a = T1 { x :: a, y :: Bool }
>> > | T2 { x :: a }
>> >
>> Not sure what you mean. With an argument of such a multiconstructed
>>
Matthew Farkas-Dyck gmail.com> writes:
>
> > I think you don't want all those type vars in your record decls -- but only
> > vars for the mutatable types, like this:
> >
> > type R c = { X ::. Int, Y::. String, Z ::. c, ... }
> >
> > Then you don't need a Quasifunctor instance for every field,
On 03/03/2012, AntC wrote:
> Apart from the Quasifunctor bit, I think you'll find your proposal is a rather
> cut-down version of DORF, just using different syntactic sugar.
> (Oh, and with the arguments to Has in a different order, just to be
> confusing.)
Not so. I chose this order to make it
Matthew Farkas-Dyck gmail.com> writes:
>
> Hello all.
>
> I wrote a new proposal for the Haskell record system. It can be found
> at http://hackage.haskell.org/trac/ghc/wiki/Records/TypeIndexedRecords
>
> Records are indexed by arbitrary Haskell types. Scope is controlled as
> scope of key typ
Hello all.
I wrote a new proposal for the Haskell record system. It can be found
at http://hackage.haskell.org/trac/ghc/wiki/Records/TypeIndexedRecords
Records are indexed by arbitrary Haskell types. Scope is controlled as
scope of key types. No fieldLabel declarations needed (as in DORF).
Cheer
AntC clear.net.nz> writes:
>
> Gábor Lehel gmail.com> writes:
>
> > ...
> >
> > ... My main complaint against DORF is
> > that having to write fieldLabel declarations for every field you want
> > to use is onerous. If that could be solved, I don't think there are
> > any others. (But even if
Isaac Dupree isaac.cedarswampstudios.org> writes:
>
> >>
> >> In the meantime, I had an idea (that could work with SORF or DORF) :
> >>
> >> data Foo = Foo { name :: String } deriving (SharedFields)
> >>
> >> The effect is: without that "deriving", the declaration behaves just
> >> like H98.
> >
Gábor Lehel gmail.com> writes:
> ...
>
> ... My main complaint against DORF is
> that having to write fieldLabel declarations for every field you want
> to use is onerous. If that could be solved, I don't think there are
> any others. (But even if it can't be, I still prefer DORF.)
>
Thank you
Isaac Dupree isaac.cedarswampstudios.org> writes:
...
> > So under your proposal, a malicious client could guess at the fieldnames in
> > your abstraction, then create their own record with those fieldnames as
> > SharedFields, and then be able to update your precious hidden record type.
>
> Sho
Isaac Dupree isaac.cedarswampstudios.org> writes:
>AntC (in an unrelated reply to Ian) :
>> I prefer DORF's sticking to conventional/well-understood H98 namespacing
>> controls.
...
> I'm not sure yet that DORF's namespacing is well-understood by
anyone but you.
No of course I'm not saying DOR
On 03/01/2012 01:46 AM, AntC wrote:
Isaac Dupree isaac.cedarswampstudios.org> writes:
In the meantime, I had an idea (that could work with SORF or DORF) :
data Foo = Foo { name :: String } deriving (SharedFields)
The effect is: without that "deriving", the declaration behaves just
like H98
On Fri, Mar 02, 2012 at 01:04:13AM +, AntC wrote:
>
> Let me explain better what I mean by "two private namespaces", then we'll try
> to understand how your proposal goes ...
>
> module T where
> data FieldT = Field
> data RecT = RecT{ Field :: Int }
> ...
>
On Fri, Mar 02, 2012 at 01:44:45AM +0100, Gábor Lehel wrote:
> On Fri, Mar 2, 2012 at 1:06 AM, Ian Lynagh wrote:
> >
> > Right, but other people would prefer the SORF behaviour to the DORF
> > behaviour.
>
> Who and why? What's the use case?
>
> My main complaint against DORF is
> that having to
Ian Lynagh earth.li> writes:
>
> > * an extra arg to Has (how does the constraint sugar cope?)
>
> You can infer ft from the f.
>
Let me explain better what I mean by "two private namespaces", then we'll try
to understand how your proposal goes ...
module T where
data Fi
On Fri, Mar 2, 2012 at 1:06 AM, Ian Lynagh wrote:
> On Thu, Mar 01, 2012 at 11:32:27PM +, AntC wrote:
>> Yes-ish (leaving aside that issue). Under SORF you hve an extra behaviour:
>> - use String Kinds and your label is public-everywhere and
>> completely uncontrollable.
>> - (So someone wh
Ian Lynagh earth.li> writes:
>
> On Thu, Mar 01, 2012 at 11:32:27PM +, AntC wrote:
> > AntC clear.net.nz> writes:
> >
> > >
> > > Ian Lynagh earth.li> writes:
> > >
> > > >
> > > > But I think you are agreeing that (leaving aside the issue of whether
> > > > the design is reasonable) t
On Thu, Mar 01, 2012 at 11:32:27PM +, AntC wrote:
> AntC clear.net.nz> writes:
>
> >
> > Ian Lynagh earth.li> writes:
> >
> > >
> > > But I think you are agreeing that (leaving aside the issue of whether
> > > the design is reasonable) the above variant would indeed allow the user
> > > t
On Thu, Mar 01, 2012 at 10:46:27PM +, AntC wrote:
>
> Also this would be ambiguous:
>
> object.SubObject.Field.subField
Well, we'd have to either define what it means, or use something other
than '.'.
> In terms of scope control, I think (I'm guessing rather) you do get similar
> behav
AntC clear.net.nz> writes:
>
> Ian Lynagh earth.li> writes:
>
> >
> > But I think you are agreeing that (leaving aside the issue of whether
> > the design is reasonable) the above variant would indeed allow the user
> > to choose the behaviour of either SORF or DORF.
> >
>
> No, not the "us
Ian Lynagh earth.li> writes:
>
> On Thu, Mar 01, 2012 at 08:52:29PM +, AntC wrote:
> >
> > And you get "In my opinion, this is ugly, ...
>
> That comment was from strake888, not SPJ?
>
Thanks Ian, you're right. Specifically, it's 'igloo's tweak to the proposal
and 'strake888's comment.
> Thanks Evan, I've had a quick read through.
Thanks for reading and commenting!
> It's a bit difficult to compare to the other proposals.
>
> I can't see discussion of extracting higher-ranked functions and applying them
> in polymorphic contexts. (This is SPJ's `rev` example.)
>
> Putting h-r f
On Thu, Mar 01, 2012 at 08:52:29PM +, AntC wrote:
> Ian Lynagh earth.li> writes:
>
> >
> > On Thu, Mar 01, 2012 at 07:58:42AM +, AntC wrote:
> > >
> > > SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them
> because
> > > they're new-fangled, I'm opposed because I ca
Ian Lynagh earth.li> writes:
>
> On Thu, Mar 01, 2012 at 07:58:42AM +, AntC wrote:
> >
> > SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them
because
> > they're new-fangled, I'm opposed because I can't control the namespace.)
>
> I haven't followed everything, so ple
On Thu, Mar 1, 2012 at 8:38 AM, Ian Lynagh wrote:
> On Thu, Mar 01, 2012 at 07:58:42AM +, AntC wrote:
>>
>> SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them
>> because
>> they're new-fangled, I'm opposed because I can't control the namespace.)
>
> I haven't followed ever
On Thu, Mar 01, 2012 at 07:58:42AM +, AntC wrote:
>
> SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them
> because
> they're new-fangled, I'm opposed because I can't control the namespace.)
I haven't followed everything, so please forgive me if this is a stupid
question,
J. Garrett Morris cs.pdx.edu> writes:
> On Wed, Feb 29, 2012 at 11:58 PM, AntC clear.net.nz>
wrote:
> > SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them
> > because they're new-fangled, I'm opposed because I can't control the
> > namespace.)
>
> Nah, they have kinds, and
On Wed, Feb 29, 2012 at 11:58 PM, AntC wrote:
> SORF's whadyoumaycalls are at the Kind level. (I'm not opposed to them
> because they're new-fangled, I'm opposed because I can't control the
> namespace.)
Nah, they have kinds, and they don't take parameters, so they're
probably types. Whether you
J. Garrett Morris cs.pdx.edu> writes:
>
> On Wed, Feb 29, 2012 at 11:05 PM, AntC clear.net.nz>
wrote:
> > I repeat: nobody is using a "type-level string". You (or someone) is
> > making it up.
>
> It isn't clear where that idea came from.
>
> On Mon, Jan 2, 2012 at 4:38 AM, Simon Peyton-Jone
On Wed, Feb 29, 2012 at 11:05 PM, AntC wrote:
> I repeat: nobody is using a "type-level string". You (or someone) is
> making it up.
It isn't clear where that idea came from.
On Thu, Sep 15, 2011 at 7:51 AM, Simon Peyton-Jones
wrote:
> Yes, it would, and of course any impl of TDNR would need an
wren ng thornton freegeek.org> writes:
> >
> > That's what SORF does: the String Kind
> >
> > No proposal is using a _type_-level string. Barney's confused you.
>
> I was under the impression that all the working proposals were using the
> Has class, ...
Yes, but:
> a la:
>
> someFuncti
Isaac Dupree isaac.cedarswampstudios.org> writes:
>
> In the meantime, I had an idea (that could work with SORF or DORF) :
>
> data Foo = Foo { name :: String } deriving (SharedFields)
>
> The effect is: without that "deriving", the declaration behaves just
> like H98.
>
> (For super flexibi
On 02/28/2012 06:40 AM, AntC wrote:
Oliver Batchelor gmail.com> writes:
Perhaps this situation could occur though?
Module A
fieldLabel name String
Module B
import A -- unknowingly picking up the name label
data Foo = Foo { name :: String } -- uses the name label by accident
So there'd have
On 2/29/12 10:51 PM, wren ng thornton wrote:
On 2/28/12 3:57 AM, AntC wrote:
wren ng thornton freegeek.org> writes:
I'm not sure it's a good proposal, but it seems like the only way to
handle this issue is to (1) introduce a new kind for
semantically-oriented field names,
That's what SORF doe
On 2/28/12 3:57 AM, AntC wrote:
wren ng thornton freegeek.org> writes:
I'm not sure it's a good proposal, but it seems like the only way to
handle this issue is to (1) introduce a new kind for
semantically-oriented field names,
That's what SORF does: the String Kind
and (2) make the Has cl
Oliver Batchelor gmail.com> writes:
>
> I think the DORF approach is quite principled in it's namespacing. The
> labels are just normal functions which can be exported and imported
> between modules. I believe that is it's main strength - so I think to
> say "it only solves the narrow name-spaci
Oliver Batchelor gmail.com> writes:
>
> Hi,
>
> >
> > Wrong: You cannot use a fieldLabel `name` declared in module/namespace A to
> > access a record with a field `name` declared in module B. You'll get a 'no
> > instance' compile fail. Same familiar rules as for any instance resolution.
> >
>
Greg Weber gregweber.info> writes:
>
> I looked at the DORF implementers view
>
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields
/ImplementorsView
>
> It appears that we still have no solution for record updates that
> change the type of a polymorphic field.
The
Barney Hilken ntlworld.com> writes:
>
>
> > This should be used to generate
> > internal constraints and not be exposed to the end user and not
> > automatically abstract over fields.
>
Barney, I'm not going to try to defend or explain what Greg means by that
comment, but I do want to talk a
J. Garrett Morris cs.pdx.edu> writes:
>
> Has x f has no semantic content besides type x having an f field; Ord
> has (at least in the programmer's mind, even if the language can't check
> it) meaning beyond the simple presence of a compare function.
>
> /g
>
Note that under both SORF and DO
Henrik Nilsson Cs.Nott.AC.UK> writes:
>
> Hi,
>
> Just checking my understanding here as I have not followed this thread
> in all its details.
>
> So, with both DORF ''', am I correct in understanding
> that polymorphic fields, be it universally quantified as in
>
Good question Henrik! It's
Gábor Lehel gmail.com> writes:
>
> 2012/2/25 Gábor Lehel gmail.com>:
> > Please correct me if I've misunderstood or mischaracterized any aspect of
DORF.
>
> Okay, I did end up misunderstanding and mischaracterizing at least two
> aspects of DORF.
>
> Re-reading the wiki page:
>
>
http://ha
Barney Hilken ntlworld.com> writes:
>
> After more pondering, I finally think I understand what the DORFistas want.
Barney,
1) please don't personalise. I designed DORF, built a proof of concept, got it
running, asked for feedback (got some very useful thoughts from SPJ), built a
prototype,
Hi,
>
> Wrong: You cannot use a fieldLabel `name` declared in module/namespace A to
> access a record with a field `name` declared in module B. You'll get a 'no
> instance' compile fail. Same familiar rules as for any instance resolution.
>
> This is the crucial difference compared to SORF: which
Isaac Dupree isaac.cedarswampstudios.org> writes:
>
>
> Darn, I misinterpreted DORF. There was too much text and too many options.
>
Sorry! You might do better to stick to the implementor's page if you want a
less 'option-laden' description. Also better to skip the speculative bits
until y
Barney Hilken ntlworld.com> writes:
>
> > My objection is that I'm not sure if there is ever a case where "you
> > really want things to be polymorphic over all records".
>
> Well, I don't have a simple, really convincing example, but there are
certainly things I want to play with.
> More impo
wren ng thornton freegeek.org> writes:
>
> FWIW, this is the concern I alluded to earlier. Namely that we may want
> to have two (or more), er, 'classes' of records--- where a field is
> polymorphic over an individual class, but we don't want those classes to
> merge simply because they happen
wren ng thornton freegeek.org> writes:
>
> I'm not sure that I like the current proposals for how to control the
> non/automatic-ness of polymorphism (for reasons I can spell out later,
> if desired). But we definitely want to have something that's a bit more
> cultured than simply making all
Barney Hilken ntlworld.com> writes:
>
>
> > Please remember SPJ's request on the Records wiki to stick
> > to the namespace issue. We're trying to make something
> > better that H98's name clash. We are not trying to build
> > some ideal polymorphic record system.
>
> I must admit that this at
Greg Weber gregweber.info> writes:
>
> >
> > No, I don't think anybody has a satisfactory approach to
> > updating polymorphic/higher-ranked fields. (DORF mentions
> > one, but it's a ghastly hack.
>
> So are the proposals dead until this is tackled, or should SORF/DORF
> propose not to allow t
On Mon, Feb 27, 2012 at 4:52 PM, AntC wrote:
> And can use it, for example:
> getF lastName cust1
> getF fullName person2
>
> I don't think you can do this is SORF (but please check with SPJ). In
> particular, I don't think you could call this function and pass an argument
> into it for the
Greg Weber gregweber.info> writes:
>
> >
> > What on earth do you mean by "not automatically abstract
> > over fields"?
>
> Abstraction over fields is the ability to write a function that works
> on two records with the same field label.
>
Thanks Greg, I see you've put something on the wiki ab
On Sun, Feb 26, 2012 at 2:00 AM, wren ng thornton wrote:
> I haven't been following all the different proposals out there, but the ones
> I did see before tuning-out all took the stance that for each given field
> either (1) this field name is unique and always clashes, or (2) this field
> name is
Hi Greg,
(Apologies for second mail, I didn't include the list)
I think the DORF approach is quite principled in it's namespacing. The
labels are just normal functions which can be exported and imported
between modules. I believe that is it's main strength - so I think to
say "it only solves the
The DORF proposal is bringing to light some universal issues with
records, so I am glad they are being hashed out. However, at this
point it is premature optimization: we still don't have a proposal
that solves the narrow issue of record name-spacing with Haskell.
At this point SORF/DORF need a he
Barney Hilken :
Haskel is supposed to be a theoretically sound, cleanly designed language, and
if we lose sight of this we might as well use C++.
Well, since I have nothing to say about new records, I don't say
anything, but I have the impression that when we got to this level of
discussion, i
> Please remember SPJ's request on the Records wiki to stick
> to the namespace issue. We're trying to make something
> better that H98's name clash. We are not trying to build
> some ideal polymorphic record system.
I must admit that this attitude really gets my hackles up. You are effectively
>
> I'm not sure it's a good proposal, but it seems like the only way to handle
> this issue is to (1) introduce a new kind for semantically-oriented field
> names, and (2) make the Has class use that kind rather than a type-level
> string.
The second half of my message showed exactly how to
On 2/26/12 12:38 AM, Anthony Clayden wrote:
Wren/all
Please remember SPJ's request on the Records wiki to stick
to the namespace issue. We're trying to make something
better that H98's name clash. We are not trying to build
some ideal polymorphic record system.
I believe my concern is a namesp
Wren/all
Please remember SPJ's request on the Records wiki to stick
to the namespace issue. We're trying to make something
better that H98's name clash. We are not trying to build
some ideal polymorphic record system.
To take the field labelled "name": in H98 you have to
declare each record in a
Whoa! suddenly a deluge over the DORF proposal.
I don't have time to reply fully now, but I must say: Barney
you have got it all wrong.
No, DORF does not attach one class to each label. There is
only one class 'Has', with methods get and set. Each record
decl generates an instance for the combina
On 2/25/12 10:18 AM, Gábor Lehel wrote:
On Sat, Feb 25, 2012 at 3:54 PM, Barney Hilken wrote:
After more pondering, I finally think I understand what the DORFistas want.
Here is an example:
You want to define records which describe people, and include (among other things) a field called
"nam
On 2/24/12 5:40 PM, Johan Tibell wrote:
I share Greg's concerns about polymorphic projections. For example,
given a function
sort :: Ord a => ...
we don't allow any 'a' that happens to export a operator that's
spelled<= to be passed to 'sort'. We have the user explicitly create
an instanc
On 02/25/2012 05:10 PM, Gábor Lehel wrote:
Could you elaborate on this? (What's the way I don't want? What do you
mean by field-name-prefixes versus new-style overloading?) With DORF I
have control over which fields are polymorphic over which records,
very much like how I have control over which
> My objection is that I'm not sure if there is ever a case where "you
> really want things to be polymorphic over all records".
Well, I don't have a simple, really convincing example, but there are certainly
things I want to play with.
More importantly, DORF automatically attaches one class to e
On Sat, Feb 25, 2012 at 10:09 PM, Isaac Dupree
wrote:
> On 02/25/2012 10:18 AM, Gábor Lehel wrote:
>>>
>>> This seems to me a much simpler approach than building the mechanism in
>>> to the language as DORF does, and it's also more general, because it isn't
>>> hard linked to the module system. Do
On 02/25/2012 10:18 AM, Gábor Lehel wrote:
This seems to me a much simpler approach than building the mechanism in to the
language as DORF does, and it's also more general, because it isn't hard linked
to the module system. Does it have any disadvantages?
I can't tell offhand whether it has a
On Sat, Feb 25, 2012 at 3:54 PM, Barney Hilken wrote:
> After more pondering, I finally think I understand what the DORFistas want.
> Here is an example:
>
> You want to define records which describe people, and include (among other
> things) a field called "name". There might be several differe
After more pondering, I finally think I understand what the DORFistas want.
Here is an example:
You want to define records which describe people, and include (among other
things) a field called "name". There might be several different record types
with a name field, depending on whether the rec
2012/2/25 Gábor Lehel :
> Please correct me if I've misunderstood or mischaracterized any aspect of
> DORF.
Okay, I did end up misunderstanding and mischaracterizing at least two
aspects of DORF.
Re-reading the wiki page:
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecord
Hi,
Just checking my understanding here as I have not followed this thread
in all its details.
Gabor Lehel wrote:
> I agree completely. This is what I like about DORF: the D stands for
> "Declared", which is referring to the fact that the contracts are
> explicit. Record fields aren't automatic
On Fri, Feb 24, 2012 at 11:40 PM, Johan Tibell wrote:
> Hi Barney,
>
> On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken wrote:
>> Every one of your messages about records stresses your dislike for
>> polymorphic projections, and your insistence that the Has class should be
>> hidden from the user
On Fri, Feb 24, 2012 at 4:15 PM, Johan Tibell wrote:
> Aside: It is possible to have no scalar fields in records of course.
> data R = C { compare :: (a -> a -> Ordering) }
Has x f has no semantic content besides type x having an f field; Ord
has (at least in the programmer's mind, even if the la
On Fri, Feb 24, 2012 at 3:07 PM, Barney Hilken wrote:
> But the difference is that <= is (potentially) an arbitrary function, so we
> need to be careful that the instances make sense. A formally correct system
> would insist that all instances are (at least) reflexive and transitive. But
> in t
Sorry for getting offended!
I agree with your sentiment, which is why I thought having to write an
extra word in a Record declaration to get automatic abstraction over
fields was a good solution to the problem.
But now I am in the position of being the lone dissenter on automatic
abstraction over
> I share Greg's concerns about polymorphic projections. For example,
> given a function
>
>sort :: Ord a => ...
>
> we don't allow any 'a' that happens to export a operator that's
> spelled <= to be passed to 'sort'. We have the user explicitly create
> an instance and thereby defining that
Hi Barney,
On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken wrote:
> Every one of your messages about records stresses your dislike for
> polymorphic projections, and your insistence that the Has class should be
> hidden from the user. I've read all of your explanations, but I'm still
> totally
I'm sorry Greg, I didn't mean to be offensive. I just feel that all your
arguments in favour of this restriction are based on one particular application
of records, rather than a general notion of what records are. Obviously this
application is what motivates you to do all the valuable work you
>
> No, I don't think anybody has a satisfactory approach to
> updating polymorphic/higher-ranked fields. (DORF mentions
> one, but it's a ghastly hack.
So are the proposals dead until this is tackled, or should SORF/DORF
propose not to allow that?
>
> What on earth do you mean by "not automatica
On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken wrote:
>
>
>> This should be used to generate
>> internal constraints and not be exposed to the end user and not
>> automatically abstract over fields.
>
> Every one of your messages about records stresses your dislike for
> polymorphic projections,
> This should be used to generate
> internal constraints and not be exposed to the end user and not
> automatically abstract over fields.
Every one of your messages about records stresses your dislike for polymorphic
projections, and your insistence that the Has class should be hidden from the
> Actually, I looked at the SORF page again:
>
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
> There is now an 'Alternative Proposal' section that claims
> to solve polymorphic update.
> If anyone has comments on this please let us know!
Yes, Greg the quasifunctor stuff h
Actually, I looked at the SORF page again:
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
There is now an 'Alternative Proposal' section that claims to solve
polymorphic update.
If anyone has comments on this please let us know!
So my proposal would be to somehow use the S
I looked at the DORF implementers view
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/ImplementorsView
It appears that we still have no solution for record updates that
change the type of a polymorphic field.
I think this means we need to look to ways to solve this
On Thu, Feb 23, 2012 at 4:25 PM, AntC wrote:
> Greg Weber gregweber.info> writes:
>
>>
>> Thanks to Anthony for his DORF proposal, and spending time to clearly
>> explain it on the wiki.
>>
>> I have a big issue with the approach as presented - it assumes that
>> record fields with the same name
Greg Weber gregweber.info> writes:
>
> Thanks to Anthony for his DORF proposal, and spending time to clearly
> explain it on the wiki.
>
> I have a big issue with the approach as presented - it assumes that
> record fields with the same name should automatically be shared. As I
> have stated be
Thanks to Anthony for his DORF proposal, and spending time to clearly
explain it on the wiki.
I have looked over the main page:
http://hackage.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields
I have a big issue with the approach as presented - it assumes that
record fields with th
>
>> Simon Peyton-Jones microsoft.com> writes:
>
> >
>
> No! no! no! For records _don't_ put records in nested/sub-modules, and
_don't_ require them in separate modules (as currently). Here's how ...
>
I've put up my proposal for namespacein Records/fields in Haskell, as an extra
page link
On 2/11/12 9:47 AM, Greg Weber wrote:
What is the use case for changing the type of a record field on update?
I use it all the time. One may just as well ask: What is the use case
for changing the type of a Maybe on update? Or what is the use case for
changing only one of the types for a tupl
Hi,
Greg Wever wrote:
> What is the use case for changing the type of a record field on
> update?
Lots.
For example, I often use in the context of abstract syntax parametrised
on the type of some kind of "annotation". A transformation may then
take an abstract syntax tree with one type of anno
[snip]
>
> | So I propose we move forward with implementing Has constraints, but do
> | not expose it to the user (similar to TDNR). We don't add abstraction
> | over fields or virtual fields or any special capabilities that would
> | expose the implementation.
>
> Fair enough. I call this the "M
| The starting point a new records implementation was to be pragmatic
| and get something done. Simon has identified that Has constraints are
| required to implement records.
I think it'd be overstating it to say "required". But Has constraints do seem
to be a modest way to make progress that fi
John Lask hotmail.com> writes:
>
> On 1/02/2012 12:26 AM, AntC wrote:
> >
> > No! no! no! For records _don't_ put records in nested/sub-modules, and
_don't_
> > require them in separate modules (as currently). Here's how ...
> >
>
> namespace management and record systems are intimately relate
On 1/02/2012 12:26 AM, AntC wrote:
Simon Peyton-Jones microsoft.com> writes:
Beyond that, it would really help namespacing in general to appropriately
extend the module system to allow multiple modules to be declared within a
single file -- or, better yet, "submodules". [snip] the added exp
Simon Peyton-Jones microsoft.com> writes:
>
> Beyond that, it would really help namespacing in general to appropriately
extend the module system to allow multiple modules to be declared within a
single file -- or, better yet, "submodules". [snip] the added expressive power
should make namespa
> On Thu, Jan 26, 2012 at 8:02 PM, AntC
> wrote:
>
> > Ryan Newton gmail.com> writes:
> >
> > >
> > > I admit I'm a big fan of polymorphic extension. But I
> > don't love it enough
> > for it to impede progress!
> >
>
> Records proposals for Haskell have repeatedly foundered on
> the rocks of
1 - 100 of 284 matches
Mail list logo