Fair enough.
On 20/12/2011, Chris Smith cdsm...@gmail.com wrote:
On Tue, Dec 20, 2011 at 5:57 PM, Matthew Farkas-Dyck
strake...@gmail.com wrote:
Another thought:
Perhaps bang as record selection operator. It would avoid further
corner cases of dot, and it's not unprecedented in Haskell
Another thought:
Perhaps bang as record selection operator. It would avoid further
corner cases of dot, and it's not unprecedented in Haskell (e.g.
Data.Map.!).
If one wished to use dot, one could do this:
import Prelude hiding ((.));
import Control.Category.Unicode((∘));
(.) = (!);
On Tue, Dec 20, 2011 at 5:57 PM, Matthew Farkas-Dyck
strake...@gmail.com wrote:
Another thought:
Perhaps bang as record selection operator. It would avoid further
corner cases of dot, and it's not unprecedented in Haskell (e.g.
Data.Map.!).
We already have weird syntax rules for dot, and the
Am Montag, den 07.11.2011, 21:41 + schrieb Barney Hilken:
The problem with this approach is that different labels do not have
different representations at the value level.
I think this is an advantage, because it means you don't have to carry
this stuff about at runtime.
This
Am Montag, den 07.11.2011, 23:30 + schrieb Simon Peyton-Jones:
Wolfgang
Is there a wiki page giving a specific, concrete design for the
proposal you advocate? Something at the level of detail of
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields?
Well, I don’t
My stance is that it is possibly better if we do not try to include a
one-size-fits-it-all record system into the language, but if the
language provided support for basic things that almost all record
system *libraries* would need.
Agreed. To the extent that such libraries could be improved
I am unsure which of this list of proposals you are referring to. The
URL you quote is this
http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels
That sounds familiar, I think I wrote that when I was younger;-)
but it doesn't seem to actually contain a design, merely some
Am Montag, den 07.11.2011, 17:53 + schrieb Barney Hilken:
Here is my understanding of the current state of the argument:
Instead of Labels, there will be a new kind String, which is not a
subkind of *, so its elements are not types. The elements of String
are strings at the type level,
Am Montag, den 07.11.2011, 18:16 +0100 schrieb Claus Reinke:
I am unsure which of this list of proposals you are referring to. The
URL you quote is this
http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels
That sounds familiar, I think I wrote that when I was younger;-)
On Mon, Nov 7, 2011 at 1:33 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org
wrote:
Am Montag, den 07.11.2011, 18:16 +0100 schrieb Claus Reinke:
I am unsure which of this list of proposals you are referring to. The
URL you quote is this
The problem with this approach is that different labels do not have
different representations at the value level.
I think this is an advantage, because it means you don't have to carry this
stuff about at runtime.
This allows me to pattern match records, since I can construct record
On Mon, Nov 07, 2011 at 08:31:04PM +0200, Wolfgang Jeltsch wrote:
The problem with this approach is that different labels do not have
different representations at the value level. In my record system, I use
label definitions like the following ones:
data MyName1 = MyName1
data
Ian said
class Has (r :: *) (ft :: *) (f :: ft) (t :: *) where
(where ft stands for field type)?
class Has (r :: *) (f :: ft) (t :: *) where
would be my understanding of how it would be phrased under the current
polymorphic kind system.
This could also solve the representation-hiding
...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Wolfgang Jeltsch
| Sent: 07 November 2011 18:31
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Records in Haskell
|
| Am Montag, den 07.11.2011, 17:53 + schrieb Barney Hilken:
| Here is my
- let x.k = value in x))
On 20/10/2011, Simon Peyton-Jones simo...@microsoft.com wrote:
| Subject: Re: Records in Haskell
|
| I have added my proposal to the wiki.The only downsides to it that I can
see are:
Thanks to Barney for articulating a proposal for records in Haskell. Over
various plane
On 04/11/2011, Simon Peyton-Jones simo...@microsoft.com wrote:
| I really like Simon PJ's proposal for records in Haskell. Some
| reasons for this are:
Which one? You'll need to give your readers an explicit link
S
Sorry.
| Subject: Re: Records in Haskell
|
| I have added my proposal to the wiki.The only downsides to it that I can see
are:
Thanks to Barney for articulating a proposal for records in Haskell. Over
various plane rides and ICFP chats I've worked out some more details. It's not
as simple as I'd
* Simon Peyton-Jones:
Provoked the (very constructive) Yesod blog post on Limitations of
Haskell, and the follow up discussion, I've started a wiki page to
collect whatever ideas we have about the name spacing issue for
record fields.
On 16 September 2011 16:31, Ryan Newton rrnew...@gmail.com wrote:
I started playing around with Leksah and scion/emacs (searching for what's
the type of this expr support) and was a little disappointed that this
functionality doesn't seem to exist yet. Or am I wrong and it exists
On Fri, Sep 16, 2011 at 06:46:35AM +0100, Ganesh Sittampalam wrote:
On 15/09/2011 15:43, Ian Lynagh wrote:
On Thu, Sep 15, 2011 at 08:47:30AM +, Simon Peyton-Jones wrote:
Re TypeDirectedNameResolution, I would actually prefer it if it were
less general. i.e. if you were to write
On 15/09/2011 14:03, Barney Hilken wrote:
As formulated on the wiki page, the narrow issue is a problem without a good
solution. The reason the community rejected TDNR is because it's basically polymorphism
done wrong. Since we already have polymorphism done right, why would we want it?
I
I have added my proposal to the wiki.The only downsides to it that I can see
are:
1. If the types can be resolved at compile time, the compiler needs to optimise
away the dictionaries, otherwise there will be a performance cost. Since this
is always the case for type classes, I assume this is
One benefit of TDNR is to replicate the discoverability of APIs that OO
programming has - if x :: Foo then typing x. in an IDE gives you a
list of things you can do with a Foo. (Obviously it's not a complete lis
for various reasons, but it does allow the author of Foo and others to
design
I added my evaluation of the module-based approach to existing
records, but on second thoughts it's maybe inappropriate, so I'll post
it here. I saw that some people commented on the reddit discussion
that the solution is to put your types in separate modules but it
doesn't seem that anyone has
As formulated on the wiki page, the narrow issue is a problem without a good
solution. The reason the community rejected TDNR is because it's basically
polymorphism done wrong. Since we already have polymorphism done right, why
would we want it?
The right way to deal with records is first to
On Thu, Sep 15, 2011 at 6:03 AM, Barney Hilken b.hil...@ntlworld.com wrote:
The right way to deal with records is first to agree a mechanism for
writing a context which means
a is a datatype with a field named n of type b
then give the selector n the type
a is a datatype with
TRex is already mentioned on the wiki as coming at a too high
implementation cost.
2011/9/15 J. Garrett Morris jgmor...@cs.pdx.edu:
On Thu, Sep 15, 2011 at 6:03 AM, Barney Hilken b.hil...@ntlworld.com wrote:
The right way to deal with records is first to agree a mechanism for
writing a context
On Thu, Sep 15, 2011 at 08:47:30AM +, Simon Peyton-Jones wrote:
Provoked the (very constructive) Yesod blog post on Limitations of Haskell,
and the follow up discussion, I've started a wiki page to collect whatever
ideas we have about the name spacing issue for record fields.
J Garrett Morris asked me
| I also rather like the TDNR proposal, as it's rather similar to the
| approach we're taking in Habit (our pet language at Portland State).
| However, I'm curious as to why you don't want to quantify over name
| resolution constraints. For example, why shouldn't:
|
|
I personally really like the proposal here:
http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html
The wiki doesn't show any opposition to this system. If Haskell had
that record system now I would be very happy and would be fine with
leaving other record systems as purely
Chris, Thank you for the real word experience report. I had assumed (because
everyone else told me) that importing qualified would be much, much better
than prefixing. I had thought that in your case since you are big on model
separation that you would have liked having a separate file for each
On Thu, Sep 15, 2011 at 7:51 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
class Select (rec :: *) (fld :: String) where
type ResTy rec fld:: *
get :: rec - ResTy rec fld
data T = MkT { x,y :: Int }
instance Select T x where
get (MkT {x = v}) = v
And now we desugar
f.x
as
2011/9/15 Greg Weber g...@gregweber.info:
Chris, Thank you for the real word experience report. I had assumed (because
everyone else told me) that importing qualified would be much, much better
than prefixing. I had thought that in your case since you are big on model
separation that you would
I should be clear that in my counter point I am using Ruby, not Haskell on
those projects. In Ruby one can use a string for the name of a class (which
will be evaluated later) and other general dynamic typing tricks to avoid
cyclical dependencies.
I have worked on one large Yesod project. I felt
2011/9/15 Greg Weber g...@gregweber.info:
I should be clear that in my counter point I am using Ruby, not Haskell on
those projects. In Ruby one can use a string for the name of a class (which
will be evaluated later) and other general dynamic typing tricks to avoid
cyclical dependencies.
Ah,
Here is a simple concrete proposal:
Nonextensible records with polymorphic selectors.
=
1. Introduce a built-in class Label, whose members are strings at the type
level. We need a notation for them; I will use double single quotes, so
''string''
Typos in my last message: the identifier field should be Field throughout,
and undef should be undefined. Here is the corrected version:
Nonextensible records with polymorphic selectors.
=
1. Introduce a built-in class Label, whose members are
It ''also'' demonstrated, to me, that qualified imports are horrible
when used on a large scale. It happened all the time, that'd I'd
import, say, 10 different data types all qualified. Typing map
(Foo.id . BarMu.thisField) and foo Bar.Zot{x=1,y=2} becomes tedious
and distracting, especially
On 15/09/2011 15:43, Ian Lynagh wrote:
On Thu, Sep 15, 2011 at 08:47:30AM +, Simon Peyton-Jones wrote:
Provoked the (very constructive) Yesod blog post on Limitations of
Haskell, and the follow up discussion, I've started a wiki page to collect
whatever ideas we have about the name
201 - 239 of 239 matches
Mail list logo
