On 22/04/2012, AntC anthony_clay...@clear.net.nz wrote:
Matthew Farkas-Dyck strake888 at 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 Farkas-Dyck strake888 at 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 to follow.
Gábor Lehel illissius at 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
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 a summary
Matthew Farkas-Dyck strake888 at 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 anthony_clay...@clear.net.nz 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
Matthew Farkas-Dyck strake888 at 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
Isaac Dupree ml at 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.
Show
Gábor Lehel illissius at 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.)
Isaac Dupree ml at 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.
Thanks Isaac, hmm:
AntC anthony_clayden at clear.net.nz writes:
Gábor Lehel illissius at 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.
J. Garrett Morris jgmorris at cs.pdx.edu writes:
On Wed, Feb 29, 2012 at 11:05 PM, AntC anthony_clayden at 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,
On Wed, Feb 29, 2012 at 11:58 PM, AntC anthony_clay...@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 they don't take parameters, so they're
J. Garrett Morris jgmorris at cs.pdx.edu writes:
On Wed, Feb 29, 2012 at 11:58 PM, AntC anthony_clayden at 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,
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,
On Thu, Mar 1, 2012 at 8:38 AM, Ian Lynagh ig...@earth.li 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
Ian Lynagh igloo at 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
On Thu, Mar 01, 2012 at 08:52:29PM +, AntC wrote:
Ian Lynagh igloo at 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
Ian Lynagh igloo at 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. (I
AntC anthony_clayden at clear.net.nz writes:
Ian Lynagh igloo at 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,
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
behaviour
On Thu, Mar 01, 2012 at 11:32:27PM +, AntC wrote:
AntC anthony_clayden at clear.net.nz writes:
Ian Lynagh igloo at 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
Ian Lynagh igloo at earth.li writes:
On Thu, Mar 01, 2012 at 11:32:27PM +, AntC wrote:
AntC anthony_clayden at clear.net.nz writes:
Ian Lynagh igloo at earth.li writes:
But I think you are agreeing that (leaving aside the issue of whether
the design is
On Fri, Mar 2, 2012 at 1:06 AM, Ian Lynagh ig...@earth.li 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
Ian Lynagh igloo at 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
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 ig...@earth.li 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
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 }
...
module U
On 03/01/2012 01:46 AM, AntC wrote:
Isaac Dupreemlat 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
Isaac Dupree ml at 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
On 2/28/12 3:57 AM, AntC wrote:
wren ng thorntonwrenat 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
On 2/29/12 10:51 PM, wren ng thornton wrote:
On 2/28/12 3:57 AM, AntC wrote:
wren ng thorntonwrenat 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
On 02/28/2012 06:40 AM, AntC wrote:
Oliver Batchelorsaulzarat 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
Isaac Dupree ml at 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 flexibility,
wren ng thornton wren at 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:
someFunction ::
On Wed, Feb 29, 2012 at 11:05 PM, AntC anthony_clay...@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 Thu, Sep 15, 2011 at 7:51 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Yes, it would,
Barney Hilken b.hilken at 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
wren ng thornton wren at 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
wren ng thornton wren at 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
Barney Hilken b.hilken at 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
Isaac Dupree ml at 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
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 can't
Barney Hilken b.hilken at 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
Gábor Lehel illissius at gmail.com writes:
2012/2/25 Gábor Lehel illissius at 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:
Henrik Nilsson nhn at 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
J. Garrett Morris jgmorris at 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
Barney Hilken b.hilken at 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
Greg Weber greg at 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.
Oliver Batchelor saulzar at 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.
Oliver Batchelor saulzar at 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
Greg Weber greg at 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 about
On Mon, Feb 27, 2012 at 4:52 PM, AntC anthony_clay...@clear.net.nz 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
Greg Weber greg at 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 that?
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
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
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
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,
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
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
On Sun, Feb 26, 2012 at 2:00 AM, wren ng thornton w...@freegeek.org 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
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 automatically
2012/2/25 Gábor Lehel illiss...@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:
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
On Sat, Feb 25, 2012 at 3:54 PM, Barney Hilken b.hil...@ntlworld.com 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
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
On Sat, Feb 25, 2012 at 10:09 PM, Isaac Dupree
m...@isaac.cedarswampstudios.org 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
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 each
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
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 instance
On 2/25/12 10:18 AM, Gábor Lehel wrote:
On Sat, Feb 25, 2012 at 3:54 PM, Barney Hilkenb.hil...@ntlworld.com 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
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
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
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
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
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 has
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
On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken b.hil...@ntlworld.com 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
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 automatically
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
Hi Barney,
On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken b.hil...@ntlworld.com 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 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 their =
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
On Fri, Feb 24, 2012 at 3:07 PM, Barney Hilken b.hil...@ntlworld.com 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
On Fri, Feb 24, 2012 at 4:15 PM, Johan Tibell johan.tib...@gmail.com 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
On Fri, Feb 24, 2012 at 11:40 PM, Johan Tibell johan.tib...@gmail.com wrote:
Hi Barney,
On Fri, Feb 24, 2012 at 2:00 PM, Barney Hilken b.hil...@ntlworld.com wrote:
Every one of your messages about records stresses your dislike for
polymorphic projections, and your insistence that the Has
Greg Weber greg at 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
On Thu, Feb 23, 2012 at 4:25 PM, AntC anthony_clay...@clear.net.nz wrote:
Greg Weber greg at 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
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
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
On 1/02/2012 12:26 AM, AntC wrote:
Simon Peyton-Jonessimonpjat 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
John Lask jvlask at 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 related,
On Thu, Jan 26, 2012 at 8:02 PM, AntC
anthony_clay...@clear.net.nz wrote:
Ryan Newton rrnewton at 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
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.
However, in general, exposing an internal implementation to a user is
an idea that should give great pause. It makes it
Ryan Newton rrnewton at 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!
Regarding extension: In trying to read through all this material I don't
see a lot of love for lacks constraints a la TRex.
Cheers,
Ryan Newton rrnewton at 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!
Regarding extension: In trying to read through all this material I don't
see a lot of love for lacks constraints a la TRex.
Cheers,
-Ryan
Ryan Newton rrnewton at 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!
Regarding extension: In trying to read through all this
material I don't
see a lot of love for lacks constraints a la TRex.
Cheers,
Ryan Newton rrnewton at 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!
Regarding extension: In trying to read through all this material I don't
see a lot of love for lacks constraints a la TRex.
Cheers,
-Ryan
Thank you Nils for those excellent links.
Yitz would like Agda's module/record setup which allows for multiple
modules in a single file.
Records are yet another local module.
The neat thing is, that like any module you can open it, or put it
into the scope of your current module for convenient
2012/1/18 Simon Peyton-Jones simo...@microsoft.com:
| Has *is* a type class. It can be used and abused like any other.
| Record members with the same key ought to have the same semantics; the
| programmer must ensure this, not just call them all x or the like.
|
| Weak types these are
2012/1/18 Simon Peyton-Jones simo...@microsoft.com:
| Has *is* a type class. It can be used and abused like any other.
| Record members with the same key ought to have the same semantics; the
| programmer must ensure this, not just call them all x or the like.
|
| Weak types these are
Sorry to pick on your post in particular Matthew, but I have been seeing a lot
of this on the Haskell lists lately.
I find it completely unreasonable for a reply to a very long post to quote the
entire text, only to add a single line at the bottom (or worse, embedded in the
middle somewhere).
1 - 100 of 239 matches
Mail list logo
