Hi,
One could also argue that a good email client should automatically hide
long quotes. In fact, I guess many people are not even aware of the problem
because their client does this.
Cheers,
Pedro
On Thu, Jan 19, 2012 at 11:14, Malcolm Wallace malcolm.wall...@me.comwrote:
Sorry to pick on
Hi,
On 01/19/2012 10:22 AM, Jos Pedro Magalhes wrote:
One could also argue that a good email client should automatically hide
long quotes. In fact, I guess many people are not even aware of the
problem because their client does this.
But then what is the point of including the text in the
On 19/01/2012, Malcolm Wallace malcolm.wall...@me.com wrote:
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). In this case, there are 7 pages of quotation
before
On January 19, 2012 05:14:30 Malcolm Wallace wrote:
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
___
On Wed, Jan 18, 2012 at 1:09 PM, Matthew Farkas-Dyck
strake...@gmail.com wrote:
On 18/01/2012, Greg Weber g...@gregweber.info wrote:
On Fri, Jan 13, 2012 at 8:52 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
But, the Has constraints MUST exist, in full glory, in the constraint
solver.
| 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 not. The selector type is well-defined. The value
| type
On 01/17/2012 03:59 AM, Yitzchak Gale wrote:
and whenever E imports M qualified without an
import list, as in:
import qualified M as Q
then the following implied imports would be
added to E:
import qualified M.T as Q.T
import qualified M.S as Q.S
Rather, those should be added whether or not
On Mon, Jan 16, 2012 at 2:32 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Johan, if you are serious, do add a new wiki page to describe the design.
I haven't thought trough the issues enough to describe the design just
yet. At the moment I prefer to discuss a little more to gain some more
On Wed, Jan 18, 2012 at 9:43 AM, Johan Tibell johan.tib...@gmail.com wrote:
On Mon, Jan 16, 2012 at 2:32 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Johan, if you are serious, do add a new wiki page to describe the design.
I haven't thought trough the issues enough to describe the
On 18/01/2012, Gábor Lehel illiss...@gmail.com wrote:
(I *am*, however, uncomfortable with using straight-up type level
strings, without consideration for any particular alternative. If
nothing else they should at least be opaque symbols which can be
passed around and used in the supported
On 18/01/2012, Simon Peyton-Jones simo...@microsoft.com wrote:
| 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
By the way, thanks to Greg for driving this discussion,
please keep up the good work!
Simon Peyton-Jones wrote:
Can you turn your proposal into a Wiki page?
OK I'll try to get to that later today.
It's different to Johan's.
Oh? I didn't realize that. OK, I'll look at it more closely.
I'm
On Tue, Jan 17, 2012 at 9:59 AM, Yitzchak Gale g...@sefer.org wrote:
By the way, thanks to Greg for driving this discussion,
please keep up the good work!
Simon Peyton-Jones wrote:
Can you turn your proposal into a Wiki page?
OK I'll try to get to that later today.
It's different to
On 2012-01-16 19:16, Yitzchak Gale wrote:
Allow nested modules. [...]
Perhaps Agda's module/record system can provide some inspiration:
http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Modules
http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceManual.Records
(I
I broke out the dot operator section of the proposal to its own page since
it is actually fairly independent of the different proposals.
http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator
On Sat, Jan 14, 2012 at 7:26 PM, wren ng thornton w...@freegeek.org wrote:
On 1/13/12 11:31 PM,
| But note what has happened: we have simply re-invented SORF. So the
| conclusion is this:
|
| the only sensible way to implement FDR is using SORF.
|
| An obvious question at this point: can records have unboxed fields?
| I'm worried a bit about the kinds that can appear in a has
-users@haskell.org
| Subject: Re: Records in Haskell
|
| On Fri, Jan 13, 2012 at 3:52 PM, Simon Peyton-Jones
| simo...@microsoft.com wrote:
| I know of no proposal that advocates only (A). It seems that we are agreed
| that we must make use of types to disambiguate common cases.
|
| I will try
Yitz: very helpful. Can you turn your proposal into a Wiki page? It's
different to Johan's.
Could you add examples? I don't fully understand your design.
| [This has the additional advantage of giving SPJ
| motivation to remain engaged, because he seems
| to prefer B. :)]
True: but that's
On Sat, Jan 14, 2012 at 12:52 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Complexities of (Plan B)
Proposal (Plan B) sounds innocent enough. But I promise you, it isn't.
There has ben some mention of the left-to-right bias of Frege type
inference engine;
That is a downside the Frege author had - one of the reasons he
abandandoned this style of implementation. It is listed on the wiki.
On Sat, Jan 14, 2012 at 3:28 PM, Jan-Willem Maessen
jmaes...@alum.mit.eduwrote:
On Fri, Jan 13, 2012 at 6:52 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
On Sun, Jan 15, 2012 at 01:38:20PM +0100, Greg Weber wrote:
The blocking issues are described on
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
a) Representation hiding (look for that heading)
How about
On Fri, Jan 13, 2012 at 6:52 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
[... good summary of the issues...]
But note what has happened: we have simply re-invented SORF. So the
conclusion is this:
the only sensible way to implement FDR is using SORF.
An obvious question at this
On Fri, Jan 13, 2012 at 3:52 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
I know of no proposal that advocates only (A). It seems that we are agreed
that we must make use of types to disambiguate common cases.
I will try to make the case for (A), just so it has been put on the table.
On Sat, Jan 14, 2012 at 13:38, Johan Tibell johan.tib...@gmail.com wrote:
On Fri, Jan 13, 2012 at 3:52 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
I know of no proposal that advocates only (A). It seems that we are
agreed
that we must make use of types to disambiguate common
On Sat, Jan 14, 2012 at 10:48 AM, Brandon Allbery allber...@gmail.com wrote:
On Sat, Jan 14, 2012 at 13:38, Johan Tibell johan.tib...@gmail.com wrote:
On Fri, Jan 13, 2012 at 3:52 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
I know of no proposal that advocates only (A). It seems
2012/1/14 Johan Tibell johan.tib...@gmail.com:
On Fri, Jan 13, 2012 at 3:52 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
I know of no proposal that advocates only (A). It seems that we are agreed
that we must make use of types to disambiguate common cases.
I will try to make the case
On Fri, 2012-01-13 at 15:16 +1100, Morten Brodersen wrote:
Unfortunately most unix/windows/tools/source controls/editors out
there are Ascii only.
So after about 20 years the unicode standard has been around, the
quantification most still applies? Maybe I'm using a
non-representative platform,
Let me suggest that a simple non-nuclear alternative would be for people
interested in Unicode symbols to use an editor that auto converts from
Haskell Ascii to Haskell Unicode when loading and (of course) back again
when saving. You can do that today. You can even pick your own Ascii
Thanks to Greg for leading the records debate. I apologise that I
don't have enough bandwidth to make more than an occasional
contribution. Greg's new wiki page, and the discussion so far has
clarified my thinking, and this message tries to express that new
clarity. I put a conclusion at the
On 13/01/2012, Simon Peyton-Jones simo...@microsoft.com wrote:
Thanks to Greg for leading the records debate. I apologise that I
don't have enough bandwidth to make more than an occasional
contribution. Greg's new wiki page, and the discussion so far has
clarified my thinking, and this
On 12/01/2012, Morten Brodersen morten.broder...@constrainttec.com wrote:
Even if Unicode is not required, there is still a fallout. Let's look at
a simple scenario:
Somebody uploads a nice useful Haskell module that include a number of
Unicode symbols.
Unfortunately most
On 13/01/2012, Herbert Valerio Riedel h...@gnu.org wrote:
On Fri, 2012-01-13 at 15:16 +1100, Morten Brodersen wrote:
Unfortunately most unix/windows/tools/source controls/editors out
there are Ascii only.
So after about 20 years the unicode standard has been around, the
quantification most
On 09/01/2012, Greg Weber g...@gregweber.info wrote:
Thank you for all your feedback! I updated the wiki page accordingly.
Let us stop and take note of what this feedback is about: the most
convenient syntax for manipulating records, and much of this feedback
applies to any records proposal.
On 09/01/2012, Isaac Dupree m...@isaac.cedarswampstudios.org wrote:
You mean this wiki page, right?:
http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
That is, there are no fundamental
objections to the implementation of this records implementation.
I think that might be overly
I added this and your Control.Category. to the wiki.
I am not sure about the tuple proposal - tuples normally imply an ordering,
which would imply that all record fields must be accounted for at least
with an empty comma or an underscore, particularly if updating the last
field in a record. For
On 01/12/2012 07:06 AM, Matthew Farkas-Dyck wrote:
On 09/01/2012, Greg Weber g...@gregweber.info wrote:
Note that a move to a different operator for function composition
(discussed in dot operator section) would make things easier to parse:
b~ .a
where the unicode dot might be even nicer.
On Thu, Jan 12, 2012 at 13:20, Isaac Dupree
m...@isaac.cedarswampstudios.orgwrote:
way***. If we use the proper Unicode operator ∘, then let's make a wiki
page for all the common OSes/input methods, saying how to input it (aside
from copy/paste). Is there anything on the Web somewhere
I told you so (^_^)
Unicode dot (∘) would be optimal, since that's what it's for. If to
type '∘' is awkward, then one can use (Control.Category.). We need
not (and, in my opinion, should not) define another operator.
Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.**
Quoth Evan Laforge qdun...@gmail.com,
...
... Groups that are reluctant to
make formatting changes for fear of confusing revision history are
really going to hate that one.
I think a lively discussion would also be possible over whether exotic
characters are suitable at all.
But this is a
But this is a more or less academic discussion, taking place on
ghc-users, nominally out of view of the general Haskell community,
right? So I don't need to intrude with mundane objections of
that nature.
True, true, there is that.
However, I think there's at least a little bit in the idea
On 12 Jan 2012, at 18:41, Evan Laforge wrote:
Unicode dot (∘) would be optimal, since that's what it's for.
Is ∘ (U+2218 RING OPERATOR)* in Prelude yet? We should propose that.**
However, changing the composition operator from (.) will involve huge
amounts of changes to source code.
Quoth Greg Weber g...@gregweber.info,
On Thu, Jan 12, 2012 at 6:23 PM, Malcolm Wallace
malcolm.wall...@me.comwrote:
So, who is up for proposing centred dot as the new record-field syntax?
We don't need to make this change overnight. The new records system will be
turned on by an extension.
On Thu, Jan 12, 2012 at 17:14, Donn Cave d...@avvanta.com wrote:
Spaces or unicode would be the worst idea yet, but hopefully that
isn't what you meant.
Thing is, I think the spaces idea is considered acceptable because it's
*already there*. Take a look at how GHC decides whether (.) is the
On 12/01/2012, Greg Weber g...@gregweber.info wrote:
I added this and your Control.Category. to the wiki.
Thanks.
I am not sure about the tuple proposal - tuples normally imply an ordering,
which would imply that all record fields must be accounted for at least
with an empty comma or an
Quoth Brandon Allbery allber...@gmail.com,
On Thu, Jan 12, 2012 at 17:14, Donn Cave d...@avvanta.com wrote:
Spaces or unicode would be the worst idea yet, but hopefully that
isn't what you meant.
Thing is, I think the spaces idea is considered acceptable because it's
*already there*. Take
On Thu, Jan 12, 2012 at 17:33, Donn Cave d...@avvanta.com wrote:
Quoth Brandon Allbery allber...@gmail.com,
On Thu, Jan 12, 2012 at 17:14, Donn Cave d...@avvanta.com wrote:
Spaces or unicode would be the worst idea yet, but hopefully that
isn't what you meant.
Thing is, I think the
Quoth Brandon Allbery allber...@gmail.com,
...
Seems obvious to me: on the one hand, there should be a plain-ASCII
version of any Unicode symbol; on the other, the ASCII version has
shortcomings the Unicode one doesn't (namely the existing conflict between
use as composition and use as
On Thu, Jan 12, 2012 at 18:15, Donn Cave d...@avvanta.com wrote:
Quoth Brandon Allbery allber...@gmail.com,
...
Seems obvious to me: on the one hand, there should be a plain-ASCII
version of any Unicode symbol; on the other, the ASCII version has
shortcomings the Unicode one doesn't
I also wish to note that I have never been a member of the anything beyond
plain ASCII is fundamental evil set; if we're going to think that way, just
go back to BAUDOT and punched cards.
Well, it's similar to the 80 columns debate. You have to draw the
line somewhere. It's not about
On Thu, Jan 12, 2012 at 22:32, Morten Brodersen
morten.broder...@constrainttec.com wrote:
Requiring unicode characters for the Haskell syntax to solve a
*relatively* simple problem is a bad bad idea.
Nobody said anything about requiring it.
--
brandon s allbery
Even if Unicode is not required, there is still a fallout. Let's look at
a simple scenario:
Somebody uploads a nice useful Haskell module that include a number of
Unicode symbols.
Unfortunately most unix/windows/tools/source controls/editors out there
are Ascii only.
So people who wants
I added your relevant previous notes to the wiki page. I have no idea if
what you said about type inference is right or wrong. I don't think that
record fields can be called scope resolution in a normal sense - the scope
is guaranteed to resolve without conflict (unless the user incorrectly
types
Am 11. Januar 2012 08:42 schrieb Isaac Dupree
m...@isaac.cedarswampstudios.org:
On 01/10/2012 05:06 AM, Greg Weber wrote:
Some of your comments seem to not fully recognize the name-spacing (plus
simple type resolution) aspect of this proposal that I probably didn't
explain well enough. Or
On 01/10/2012 05:06 AM, Greg Weber wrote:
Some of your comments seem to not fully recognize the name-spacing (plus
simple type resolution) aspect of this proposal that I probably didn't
explain well enough. Or maybe I don't understand your comments.
For record.field, field is under the record's
Thank you for all your feedback! I updated the wiki page accordingly.
Let us stop and take note of what this feedback is about: the most
convenient syntax for manipulating records, and much of this feedback
applies to any records proposal. That is, there are no fundamental
objections to the
You mean this wiki page, right?:
http://hackage.haskell.org/trac/ghc/wiki/Records/NameSpacing
That is, there are no fundamental
objections to the implementation of this records implementation.
I think that might be overly optimistic... I think there's a risk that
SPJ finds an irritating
2012/1/8 Greg Weber g...@gregweber.info:
2012/1/8 Gábor Lehel illiss...@gmail.com
Thank you. I have a few questions/comments.
The module/record ambiguity is dealt with in Frege by preferring
modules and requiring a module prefix for the record if there is
ambiguity.
I think I see why
2012/1/8 Gábor Lehel illiss...@gmail.com:
2012/1/8 Greg Weber g...@gregweber.info:
2012/1/8 Gábor Lehel illiss...@gmail.com
Thank you. I have a few questions/comments.
The module/record ambiguity is dealt with in Frege by preferring
modules and requiring a module prefix for the record
2012/1/8 Gábor Lehel illiss...@gmail.com
The second is that only the author of the datatype could put functions
into its namespace; the 'data.foo' notation would only be available
for functions written by the datatype's author, while for every other
function you would have to use 'foo data'.
2012/1/8 Ingo Wechsung ingo.wechs...@googlemail.com:
2012/1/8 Gábor Lehel illiss...@gmail.com
The second is that only the author of the datatype could put functions
into its namespace; the 'data.foo' notation would only be available
for functions written by the datatype's author, while for
2012/1/8 Gábor Lehel illiss...@gmail.com
Later on you write that the names of record fields are only accessible
from the record's namespace and via record syntax, but not from the
global scope. For Haskell I think it would make sense to reverse this
decision. On the one hand, it
2012/1/8 Gábor Lehel illiss...@gmail.com
2012/1/8 Ingo Wechsung ingo.wechs...@googlemail.com:
2012/1/8 Gábor Lehel illiss...@gmail.com
The second is that only the author of the datatype could put functions
into its namespace; the 'data.foo' notation would only be available
for
2012/1/8 Greg Weber g...@gregweber.info:
2012/1/8 Gábor Lehel illiss...@gmail.com
Later on you write that the names of record fields are only accessible
from the record's namespace and via record syntax, but not from the
global scope. For Haskell I think it would make sense to
On 08/01/2012, Gábor Lehel illiss...@gmail.com wrote:
2012/1/8 Greg Weber g...@gregweber.info:
2012/1/8 Gábor Lehel illiss...@gmail.com
Thank you. I have a few questions/comments.
The module/record ambiguity is dealt with in Frege by preferring
modules and requiring a module prefix for
On 12/28/11 1:34 PM, Donn Cave wrote:
Quoth Greg Weberg...@gregweber.info,
On Wed, Dec 28, 2011 at 2:12 PM, Donn Caved...@avvanta.com wrote:
...
I would think row polymorphism is a must-have.
Perhaps if you want *extensible* records. If you would like to make some
progress with records in
On 12/30/11 10:58 PM, Matthew Farkas-Dyck wrote:
On 30/12/2011, Andriy Polischukquux...@gmail.com wrote:
Consider this example:
quux (y . (foo. bar).baz (f . g)) moo
It's not that easy to distinguish from
quux (y . (foo. bar) . baz (f . g)) moo
Yeah, that's why I dislike dot as compose
I have updated the wiki - the entry level page [1] compares the different
proposals and points to a more fleshed out explanation of the Frege
proposal [2].
I think I now understand the differences between the existing proposals and
am able to provide leadership to move this forward. Let me
2012/1/8 Gábor Lehel illiss...@gmail.com:
Another thing that would be nice is lenses to solve the
nested-record-update problem - at least the room to add them later.
Most of the proposed syntax would be unaffected, but you'd need some
syntax for the lens itself... I'm not sure what it might
The Frege author does not have a ghc mail list account but gave a more
detailed explanation of how he goes about TDNR for records and how often it
type checks without annotation in practice.
A more general explanation is here:
: Greg Weber; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
The trouble is that I just don't have the bandwidth (or, if I'm honest, the
motivation) to drive this through to a conclusion. And if no one else does
either
| In regard to Labels versus Atom, etc., in my use case of converting
| between similar datatypes, it would be very reasonable to eventually
| add/remove prefixes/suffixes from these type-level reifications of
| constructor names. If type-level strings are not implemented as lists
| of characters,
Disclaimer: this use case for type-level string ops is still
hypothetical, so these are predictions.
Shooting for the moon, I foresee writing a type-level string
similarity metric. In my experience, that would involve nested
traversals, sliding of sequence windows, etc. In that case, I would
very
]
Sent: 31 December 2011 19:12
To: Simon Peyton-Jones
Cc: Greg Weber; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
The trouble is that I just don't have the bandwidth (or, if I'm honest, the
motivation) to drive
Subject: Re: Records in Haskell
On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
The trouble is that I just don't have the bandwidth (or, if I'm honest, the
motivation) to drive this through to a conclusion. And if no one else does
either, perhaps it isn't *that* important to anyone
On Mon, Jan 2, 2012 at 4:38 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Open questions:
· Is String (at the kind level) a synonym for [Char]? I’m inclined
*not* to do this initially, because it would require us to have promoted
character literals too -- and the
Hello,
On Mon, Jan 2, 2012 at 4:38 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
· I don’t know exactly what you have in mean by “the ability to
reflect the type-level string at the value level”.
This can be done using singleton types in exactly the same way that it
is done on
On Jan 2, 2012, at 8:05 PM, Iavor Diatchki wrote:
Hello,
On Mon, Jan 2, 2012 at 4:38 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
·I don’t know exactly what you have in mean by “the ability to
reflect the type-level string at the value level”.
This can be done using
Weber; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
The trouble is that I just don't have the bandwidth (or, if I'm honest, the
motivation) to drive this through to a conclusion. And if no one else does
either, perhaps
On Thu, Dec 29, 2011 at 12:00 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
| The lack of response, I believe, is just a lack of anyone who
| can cut through all the noise and come up with some
| practical way to move forward in one of the many possible
| directions.
You're right.
On Sat, Dec 31, 2011 at 3:28 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
Frege has a detailed explanation of the semantics of its record
implementation, and the language is *very* similar to Haskell. Lets just
start by using Frege's document as the proposal. We can start a new wiki
Frege has a detailed explanation of the semantics of its record implementation,
and the language is *very* similar to Haskell. Lets just start by using Frege's
document as the proposal. We can start a new wiki page as discussions are
needed.
If it's a serious proposal, it needs a page to
On Dec 31, 2011, at 1:28 PM, Simon Peyton-Jones wrote:
The trouble is that I just don't have the bandwidth (or, if I'm honest, the
motivation) to drive this through to a conclusion. And if no one else does
either, perhaps it isn't *that* important to anyone. That said, it clearly
is
Gershom Bazerman wrote:
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. I know that this introduces a
few corner cases that need to be thought through
It seems to me that there's only one essential missing language feature,
which is appropriately-kinded type-level strings
Isn't this possible now with type → kind promotion?
Cheers,
Gershom
Cheers, (and Happy New Year),
MFD
___
On Sun, Jan 01, 2012 at 01:22:31AM -0500, Matthew Farkas-Dyck wrote:
It seems to me that there's only one essential missing language feature,
which is appropriately-kinded type-level strings
Isn't this possible now with type → kind promotion?
Unfortunately, I believe promotion of built-in
On 30/12/2011, Andriy Polischuk quux...@gmail.com wrote:
Yet another idea:
Consider using '\' as record access operator. No conflicts with anything at
all, and,
moreover, it really looks like hierarchical access. Reminds of filesystems
though.
I hope this is a joke.
Matthew Farkas-Dyck
Certainly not no conflicts: lambda expressions.
On 30/12/2011, Colin Adams colinpaulad...@gmail.com wrote:
On 30 December 2011 15:55, Matthew Farkas-Dyck strake...@gmail.com wrote:
On 30/12/2011, Andriy Polischuk quux...@gmail.com wrote:
Yet another idea:
Consider using '\' as record
You're right, i should have written ambiguities instead.
That was not joke, just i somehow didn't notice Chris Smith answer.
However, I think, there are some drawbacks in using dot for that in
comparison with qualified imports access. The latter is easier to
distinguish from composition by eye,
On 30/12/2011, Andriy Polischuk quux...@gmail.com wrote:
You're right, i should have written ambiguities instead.
That was not joke, just i somehow didn't notice Chris Smith answer.
Hm. I though at first that if backslash were the selection operator,
then there must be programs of unclear
Simon, I think you are continuing to move forward admirably on this. Thank
you for contributing my suggestion to the wiki. I just edited the wiki with
some more commentary. In particular I added:
Frege has a detailed explanation of the semantics of its record
implementation, and the language is
| The lack of response, I believe, is just a lack of anyone who
| can cut through all the noise and come up with some
| practical way to move forward in one of the many possible
| directions.
You're right. But it is very telling that the vast majority of responses on
Yet another idea:
Consider using '\' as record access operator. No conflicts with anything at
all, and,
moreover, it really looks like hierarchical access. Reminds of filesystems
though.
Matthew Farkas-Dyck wrote
Another thought:
Perhaps bang as record selection operator. It would avoid
:* Re: Records in Haskell
** **
Are Records stalled out again? I am perfectly willing to leave the fate
of records up to a willing and capable implementer. That seems much better
than waiting another 5 years for perfection :)
** **
As an intermediate step, is it possible to put
Quoth Greg Weber g...@gregweber.info,
...
Many of the built-in record proposals seem more ambitious (create a new
record from an existing one, generalize in some other direction). More
power or generalization could be very useful, but it can wait for later -
Haskell's records are glaringly bad
On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote:
Quoth Greg Weber g...@gregweber.info,
...
Many of the built-in record proposals seem more ambitious (create a new
record from an existing one, generalize in some other direction). More
power or generalization could be very
Quoth Greg Weber g...@gregweber.info,
On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote:
...
I would think row polymorphism is a must-have.
Perhaps if you want *extensible* records. If you would like to make some
progress with records in the near future rather than keeping
On Wed, Dec 28, 2011 at 3:34 PM, Donn Cave d...@avvanta.com wrote:
Quoth Greg Weber g...@gregweber.info,
On Wed, Dec 28, 2011 at 2:12 PM, Donn Cave d...@avvanta.com wrote:
...
I would think row polymorphism is a must-have.
Perhaps if you want *extensible* records. If you would like to
and implementation?Volunteers, stand forth!
** **
Simon
** **
** **
*From:* Greg Weber [mailto:g...@gregweber.info]
*Sent:* 09 December 2011 19:38
*To:* Simon Peyton-Jones
*Cc:* Wolfgang Jeltsch; glasgow-haskell-users@haskell.org
*Subject:* Re: Records in Haskell
?
Volunteers, stand forth!
Simon
From: Greg Weber [mailto:g...@gregweber.info]
Sent: 09 December 2011 19:38
To: Simon Peyton-Jones
Cc: Wolfgang Jeltsch; glasgow-haskell-users@haskell.org
Subject: Re: Records in Haskell
Are Records stalled out again? I am perfectly willing to leave the fate
: Records in Haskell
** **
Are Records stalled out again? I am perfectly willing to leave the fate of
records up to a willing and capable implementer. That seems much better
than waiting another 5 years for perfection :)
** **
As an intermediate step, is it possible to put a warning
101 - 200 of 239 matches
Mail list logo
