ty (except for undefined), in the second case inhabited by a
single element (Label :: Label "name")
There are several similar proposals for extensible records defined using
labels, all of which (as far as I can see) could be defined just as easily
using the kind String. There is
Hello,
I'm pleased to announce the release of my new library, named "has",
written to aim to ease pain at inconvinience of Haskell's build-in
records.
With the has, You can reuse accessors over records to write generic
function, combine records with another.
Repositor
While I agree with your general argument, I wonder if you realize
that functional dependencies have a strong, general, and elegant
mathematical foundation that long predates their use in Haskell?
If you want even a brief glimpse, there's s short article at
http://en.wikipedia.org/wiki/Functional_
Barney Hilken wrote:
I totally disagree. The great strength of Haskell is that, whenever
important design decisions have been made, the primary consideration has
not been practicality, but generality and mathematical foundation. When
the Haskell committee first started work, many people said la
Johannes Waldmann <[EMAIL PROTECTED]> has asked me to clarify my claims here.
But I say: why not to ask Chris Okasaki himself?
Manuel Chakravarty has recently published this:
http://www.cse.unsw.edu.au/~chak/papers/WC07.html so he might take the question
too.
>From my perspective there are too m
Barney Hilken wrote:
>> My rationale for these criteria goes like this: efficient access is
>> necessary if we want to compete with the much simpler record systems
>> in
>> mainstream languages. If records are not as light-weight
>> (syntactically as
>> well as
Dear Fellows,
It is obvious that Haskell takes its strength from well implemented abstract
concepts that made monadic programming natural and
threads cheap. However I believe that some top decisions have been made in the
wrong order, which is extremely important now to be
aware of when new featu
My rationale for these criteria goes like this: efficient access is
necessary if we want to compete with the much simpler record systems
in
mainstream languages. If records are not as light-weight
(syntactically as
well as wrt run-time performance) as 'normal' Haskell data types, t
>> can I read more about them?
>>
>> Hlist is one of the ones | was thinking of. Two more are "poor man's
>> records" a.k.a. Data.Record.hs, whose author certainly believes it
>> should be the basis for the new system, and my own system,
>> download
t is one of the ones | was thinking of. Two more are "poor man's
> records" a.k.a. Data.Record.hs, whose author certainly believes it
> should be the basis for the new system, and my own system,
> downloadable from http://homepage.ntlworld.com/b.hilken/files/Records.hs
&g
"poor man's
records" a.k.a. Data.Record.hs, whose author certainly believes it
should be the basis for the new system, and my own system,
downloadable from http://homepage.ntlworld.com/b.hilken/files/Records.hs
There is a discussion of the various possibili
[I replied on @cafe but didn't get any response. Trying again here.]
Barney Hilken wrote:
>> What about just implementing the cheapest solution that still gets
>> us most
>> of the way?
>
>> (3) If it is as cheap (to implement) as advertised then there is no
>> great
>> risk involved. If it turns
>
> 'x point
Say we go with 'x and allow it to pick the x field out of
records. All records. Then we have implicitly defined a function
'x that accepts things in the HasAnX class. This class is also
implicitly defined -- and things are added to it implicitly,
too, by giving them an
blue,
>getValue := getEntryValue,
>setValue := setEntryValue}
>
> e.display -- uses color/label properties
> e.saveToFile -- uses getValue property
I'm new to all this -- I can't figure out why we want to put
methods inside of records. W
What about just implementing the cheapest solution that still gets
us most
of the way?
(3) If it is as cheap (to implement) as advertised then there is no
great
risk involved. If it turns out the missing features are a great
show-stopper for some people (which I don't believe) then let them
Simon Peyton-Jones wrote:
> Since you are taking my name in vain, I had better respond! I wish I felt
> as confident of my good taste as you do. My last attempt to implement
> records (with Umut Acar, more or less the design in the "proposal for
> records" paper) invol
[hm. should this discussion move to -cafe?]
On Feb 8, 2008, at 20:15 , Jonathan Cast wrote:
On 8 Feb 2008, at 4:43 PM, Dan Weston wrote:
Ouch. How would a human parse [apple'*'pear]
In this context, `parse error, tricky syntax'.
I kinda have that problem anyway given ' being permitted in
On Fri, Feb 08, 2008 at 04:43:43PM -0800, Dan Weston wrote:
> Ouch. How would a human parse [apple'*'pear]
>
> If this doesn't immediately scan as [ (*') (apple') (pear) ] to you (it
> doesn't to me) then maybe allowing ' in infix operators may not be the best
> thing.
Oh, I was thinking they wo
On 8 Feb 2008, at 4:43 PM, Dan Weston wrote:
Ouch. How would a human parse [apple'*'pear]
In this context, `parse error, tricky syntax'.
In general? Not as sure.
jcc
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/list
Ouch. How would a human parse [apple'*'pear]
If this doesn't immediately scan as [ (*') (apple') (pear) ] to you (it
doesn't to me) then maybe allowing ' in infix operators may not be the
best thing.
John Meacham wrote:
On Tue, Feb 05, 2008 at 08:01:07AM -0500, Cale Gibbard wrote:
I also li
On Tue, Feb 05, 2008 at 08:01:07AM -0500, Cale Gibbard wrote:
> I also like this idea. Retaining the ability to treat selection as a
> function easily is quite important, and this meets that criterion
> nicely. Also, in which case does this cause a program to break? It
> seems that you're only rein
2. List the possible features that “records” might mean. For example:
· Anonymous records as a type. So {x::Int, y::Bool} is a
type. (In Haskell as it stands, records are always associated with
a named data type.
· Polymorphic field access. r.x accesses a field in any
On Feb 6, 2008 12:19 PM, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>So to clarify that statement. Honestly the number one problem I have
> with the current records system is that labels share the same namespace.
> This makes interfacing with any C library using structs quit
So to clarify that statement. Honestly the number one problem I have with the
current records system is that labels share the same namespace. This makes
interfacing with any C library using structs quite painful. This is why I say
that I don't really care which gets implemented. The cu
ry good) proposals get
> implemented, but I do have a strong opinion that the lack of "proper"
> records is hurting Haskell quite a bit.
>
>
>
> Any of them will do, just get it in there! I'm assuming that Simon {PJ,M}
> et al. won't make an obviously terrible
ndard by default.
This is the sort of situation where a "benign dictator" is needed. I have no
strong feelings about which of all of these (all very good) proposals get
implemented, but I do have a strong opinion that the lack of "proper" records
is hurting Haskell quite a
hesis.
One of the advantages of the systems with richer polymorphism and more
predicates is that they need less syntax. It is possible (once you
have solved the permutation/scoping problem) to use constructors as
labels, and define all the basic operators on records as standard
Haskell func
On 05/02/2008, John Meacham <[EMAIL PROTECTED]> wrote:
> choice 2: use ', declare that any identifier that _begins_ with ' always
> refers to a label selection function
>
> 'x point
>
> (snip)
>
> none are fully backwards compatible. I am still not sure which I like
> the best, ' has a lot of appe
blatant type error, and that (.) there doesn't mean function
> composition. :)
>
> On the matter of extensible records, I really like the semantics of
> Daan Leijen's proposal here:
> http://research.microsoft.com/users/daan/download/papers/scopedlabels.pdf
>
> How
nted, but I do have a strong opinion that the lack of "proper"
records is hurting Haskell quite a bit.
Any of them will do, just get it in there! I'm assuming that Simon {PJ,M} et
al. won't make an obviously terrible choice, and GHC seems to be the de
facto standard anyway, so if
> Everyone wants to add extensible records to Haskell.
well ... sure records are better than tuples ...
but interfaces (uh, classes) are still better IMHO
but anyway, is it possible to steal the
design of C#'s anonymous types (classes)?
if not, then why? (this might help
to clarify
The scoped labels paper has an interesting feature in this regard:
labels with different names can be swapped at will, but labels having
the same name (which is allowed) maintain their order.
- Cale
Yes, I know. The problem is that there are TOO MANY proposals, and
they are all fundamental
On 05/02/2008, Cale Gibbard <[EMAIL PROTECTED]> wrote:
> On 05/02/2008, Barney Hilken <[EMAIL PROTECTED]> wrote:
> >
> > Should {label := "Hi", color := blue} and {color := blue, label :=
> > "Hi"} have the same type?
> >
>
> The scoped labels paper has an interesting feature in this regard
On 05/02/2008, Barney Hilken <[EMAIL PROTECTED]> wrote:
>
> Should {label := "Hi", color := blue} and {color := blue, label :=
> "Hi"} have the same type?
>
The scoped labels paper has an interesting feature in this regard:
labels with different names can be swapped at will, but labels hav
Everyone wants to add extensible records to Haskell. The problem is
that, in a formally defined language like Haskell, we need to agree
how they should behave, and there are too many conflicting ideas.
I was involved recently in an attempt to try to sort out some of the
alternatives
On 05/02/2008, Cale Gibbard <[EMAIL PROTECTED]> wrote:
> Personally, I think pt{x} for extracting the x field of pt seems
> not-so-unreasonable, and meshes
> well with the existing syntax for record updates.
I should clarify -- this is only if we can't somehow keep the existing
function syntax fo
On the matter of extensible records, I really like the semantics of
Daan Leijen's proposal here:
http://research.microsoft.com/users/daan/download/papers/scopedlabels.pdf
However, the syntax could use some work. Using (.) as a record
selector is out of the question. Personally, I think pt{x} for
operty
of course, drawback of duck typing that when we forgot to setup some
field, this will be detected only at runtime - as usual for dynamic
typing
Haskell can provide benefits of both static and duck typing with type
inference by means of extensible records. type of 'e' in this
Now that I have a version of ghc with type classes, I have had a go
at implementing records based on the ideas I mentioned on this list a
few months ago. The code of my first attempt is available at http://
homepage.ntlworld.com/b.hilken/files/Records.hs
I am releasing this to get feedback
The HList library of strongly typed heterogenous lists, records,
type-indexed products (TIP) and co-products is now accessible via
DARCS
http://darcs.haskell.org/HList/
The library contains a new representation for open records. Previously
(Record.hs) a record is a Scheme-like
is the same as the type of 'r'.
This can't be typed in Hugs because you can only update particular
fields, but we can easily add it to (at least the quadratic version
of) AT-records.
Introduce a class 'subRecord r s' which means that every field of 's'
Manuel M T Chakravarty:
This is problematic as the instance heads are distinguished only by
the
context; ie, both instances are for `Lacks m (N a r)'. Haskell's
instance selection mechanism (with or without associated types)
selects
instances purely by looking at the arguments of the class;
Barney Hilken:
> Similarly, it Lacks all the fields which r Lacks, except for N
> itself. This is where we really need the ordering :<: to ensure that
> m is not equal to N. There are two cases, m :<: N:
>
> >instance m :<: N, Lacks m r => Lacks m (N a r) where
> >type Extend
The implementation of records using types data N a r = N a r might
well be inefficient, and I don't know enough about the workings of
the compiler to see whether it could be improved by unboxing and
strictness. But the real point of my post was the classes Contains,
Lacks and Dis
Of course, under Usage, I should have written:
The record {N1 = x1, ... Nn = xn} should be constructed as (extend N1
x1 $ ... $ extend Nn xn $ Empty).
Sorry about any confusion!
Barney.
___
Haskell mailing list
Haskell@haskell.org
http://www.haske
I'm sorry if this example has already been posted, but I couldn't
find it by searching the archives. If it's new (and works properly),
it provides more evidence that ATs are a good thing.
You can use associated type synonyms to implement polymorphic
ext
foo :: (Num v, HasField (Proxy PtX) r v) => r -> [Char]
David Roundy wrote:
> I guess I meant to say that it hadn't been implemented for "real" records,
> and there doesn't seem to be a consensus that it's the best approach.
There had been no argument about wh
nar Karttunen. Here's an example:
I guess I meant to say that it hadn't been implemented for "real" records,
and there doesn't seem to be a consensus that it's the best approach.
> > accessor r f = r # f
>
> *Test> :t accessor
> acces
How does pattern matching work with HList?
I would like to pass a HList to a function and only match if a
certain field had a certain value.
On Jan 6, 2006, at 7:14 AM, [EMAIL PROTECTED] wrote:
*Test> :t accessor
accessor :: (HasField l r v) => r -> l -> v
--
http://wager
David Roundy wrote:
> The only solution I can imagine
> would be to implement a class for each field name. i.e. the only reasonble
> type of f I can imagine is something like
>
> f :: Integral i, RecordHasField_foo i r => r -> r
>
> But that's a very complicated solution, and once one implemented
> This change "solves" the problem that different records in a single
> namespace cannot share field names in a simple manner.
As mentioned elsewhere, you'd also need to remove the functional update
feature to fix this namespace problem.
> In order to allow the writing
On Thu, 5 Jan 2006, S. Alexander Jacobson wrote:
> Much of the discussion here recently has been related to debate about
> complexifying the monad hierarchy. The fact that Haskell record syntax is
> abysmal and the verbosity of various possible solutions.
> They appear to interrelate.
>
> Would
Much of the discussion here recently has been related to debate about
complexifying the monad hierarchy. The fact that Haskell record
syntax is abysmal and the verbosity of various possible solutions.
They appear to interrelate.
Would it be possible/reasonable to get rid of data, class, and
i
On Wed, Jan 04, 2006 at 03:03:40PM -0800, John Meacham wrote:
> On Wed, Jan 04, 2006 at 08:55:39AM -0500, David Roundy wrote:
> > Ah, good point, I hadn't thought about that. My proposal was to keep
> > record updates which would indeed mean that we'd need to require that all
> > "foo"s in a given
On Wed, Jan 04, 2006 at 08:55:39AM -0500, David Roundy wrote:
> Ah, good point, I hadn't thought about that. My proposal was to keep
> record updates which would indeed mean that we'd need to require that all
> "foo"s in a given data type have the same type. Which I don't think is a
> bad thing e
what type would
f x = x { foo = "hello" }
have if there were multiple types with 'foo' as a field name?
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
the 'setFoo' function?
When you think about that, you are likely to run into the usual 'Has'
or 'Lacks' predicates in the types. I think the same pattern pops up
whenever you want to have labels access fields (for projection or
update) in records of different types, becaus
you can get by with the existing non-function update syntax, then you can
> also get by with pattern matching to access record contents.
I have a lot of code where I rarely need to update records but
frequently need to access them. For instance:
http://darcs.complete.org/hdbc/doc/Database-HDBC.h
On Tue, Jan 03, 2006 at 08:25:01PM -0500, Dylan Thurston wrote:
> On Mon, Jan 02, 2006 at 08:43:56AM -0500, David Roundy wrote:
> > data FooBar = Foo { foo :: Int } | FooBar = { foo :: Int, bar :: Int }
> >
> > desugars to something like
> >
> > data FooBar = Foo Int | FooBar Int Int
> >
> > foo
nt } | FooBar = { foo :: Int, bar :: Int }
>
> I would find this to be incredibly annoying. The fact that these
> accessor functions exist automatically is, IMHO, one of the very nice
> things about Haskell records. I have nightmares of manually coding up
> hundreds of get* and set* f
he fact that these
accessor functions exist automatically is, IMHO, one of the very nice
things about Haskell records. I have nightmares of manually coding up
hundreds of get* and set* functions in Java from your proposal ;-)
I also would consider it a bug to have something so annoying that a
code-
On Wed, Jan 04, 2006 at 11:53:59AM +0100, Ulf Norell wrote:
>
> On Jan 4, 2006, at 2:25 AM, Dylan Thurston wrote:
>
> >On Tue, Jan 03, 2006 at 02:41:40PM -0800, Ashley Yakeley wrote:
> >>David Roundy wrote:
> >>>On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
> >One open quest
On Jan 4, 2006, at 2:25 AM, Dylan Thurston wrote:
On Tue, Jan 03, 2006 at 02:41:40PM -0800, Ashley Yakeley wrote:
David Roundy wrote:
On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
One open question (in my mind) would be whether we'd allow
data Foo = FooInt { foo :: Int } |
On Tue, Jan 03, 2006 at 02:41:40PM -0800, Ashley Yakeley wrote:
> David Roundy wrote:
> >On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
> >>>One open question (in my mind) would be whether we'd allow
> >>>
> >>>data Foo = FooInt { foo :: Int } | FooChar { foo :: Char }
> >>>
> >>>I
On Mon, Jan 02, 2006 at 08:43:56AM -0500, David Roundy wrote:
> data FooBar = Foo { foo :: Int } | FooBar = { foo :: Int, bar :: Int }
>
> desugars to something like
>
> data FooBar = Foo Int | FooBar Int Int
>
> foo :: FooBar -> Int
> foo (Foo f) = f
> foo (FooBar f _) = f
> bar :: FooBar -> In
David Roundy wrote:
On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
One open question (in my mind) would be whether we'd allow
data Foo = FooInt { foo :: Int } | FooChar { foo :: Char }
In the "new" system, there's no reason this need be illegal.
How would this behave?
dat
On Mon, Jan 02, 2006 at 04:23:32PM -0800, Ashley Yakeley wrote:
> > One open question (in my mind) would be whether we'd allow
> >
> > data Foo = FooInt { foo :: Int } | FooChar { foo :: Char }
> >
> > In the "new" system, there's no reason this need be illegal.
>
> How would this behave?
>
>
In article <[EMAIL PROTECTED]>,
David Roundy <[EMAIL PROTECTED]> wrote:
> One open question (in my mind) would be whether we'd allow
>
> data Foo = FooInt { foo :: Int } | FooChar { foo :: Char }
>
> In the "new" system, there's no reason this need be illegal.
How would this behave?
data Fo
On 1/2/06, David Roundy <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'd like to humbly submit a conservative proposal for changes to the
> records mechanism for Haskell '06. The plan for Haskell '06 (to the extent
> that there is one) is to make it a conservative
On Mon, Jan 02, 2006 at 01:53:51PM +, Joel Reymont wrote:
> Say you turned automatic generation of accessor functions off. You would
> still need accessor functions, right? What would they look like if you
> were to write them by hand?
They could look identical if you wrote them by hand, but y
oblem that different records in a single
namespace cannot share field names in a simple manner. In order to
allow
the writing of records code with is both valid Haskell 98 and valid
Haskell
'06, I'd suggest a pragma that causes the Haskell '06 compiler to
generate
the acce
Hi all,
I'd like to humbly submit a conservative proposal for changes to the
records mechanism for Haskell '06. The plan for Haskell '06 (to the extent
that there is one) is to make it a conservative modification of Haskell
98, which is a good idea. As such, I don't thin
On 11/28/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
>
> As I already said, this approach may lead to mixing different concepts.
> Example:
>
> data Person = Person { name :: String }
> data File = File { name :: String }
>
> A field identifier has to be seen in context of the d
Am Sonntag, 27. November 2005 22:34 schrieb John Lask:
> correct me if I am wrong but ...
>
> 1. Field namespaces: solved by using type classes
>
> This would imply that the type of the field is the same between all
> instances of this common field.
>
> Under this proposal two fields with s
Good questions.
You can't have a polymorphic typecase like "`extQ` (show :: Show a => a
-> String )" because that's not really a *type*case. It is too
polymorphic.
You can have a polymorphic typecase like "`extQ` ( lshow :: [ a ] ->
String )" because that's covered by the SYB2 paper; you need ex
s?
Sure but by the same argument I wouldn't need records at all
because I could use tuples :-) I'd say it makes the intention
of the programmer more explicit, and this is what pragmatics
of programming languages is all about, isn't it ...
Also, for updates ( like x { foo =
;t you solve this by writing a fiunction to construct Foo with the
desired properties? I.e. something like
mkStdFoo f = Foo f (2*f)
Or is there other functionality you would get by using records in this
way?
-k
--
If I haven't seen further, it is by s
able to hide the "computed" component,
i. e. Foo { foo = 5, bar = 7 } could be forbidden.
And still better: if we could say later (i. e. outside the
definition of Foo) that the values of bar
should be "memorized" in the Foo records.
Of course this might be hard for separate c
option. The other option would be some sort of syntax to declare that a
particular record is unordered. Or I suppose to just give up on backward
compatibility. Any of these three alternatives would be fine with me.
> > > 7. Unordered records: yep (if I understand the problem correctly)
&g
:: String }, { name :: Int }
John
- Original Message -
From: "Rob Ennals" <[EMAIL PROTECTED]>
To: "Johannes Waldmann" <[EMAIL PROTECTED]>
Cc:
Sent: Wednesday, November 23, 2005 1:32 AM
Subject: Re: Records (was Re: [Haskell] Improvements to GHC)
bar :: String }
>
> there shouldn't be accessors of type
>
> foo :: FooBar -> String
> bar :: FooBar -> String
I did indeed misunderstand what you meant by "safe". Bottom is indeed
a nasty thing.
Perhaps such definitions should generate a warning? (banning them
eltsch wrote:
Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
[...]
7. Unordered records: yep (if I understand the problem correctly)
...
You can just omit the data constructors from the module&#x
On Wed, Nov 23, 2005 at 02:58:43PM +0100, Wolfgang Jeltsch wrote:
> Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
> > On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
> > [...]
>
> > > 7. Unordered records: yep (if I understand the problem co
Hello David,
Wednesday, November 23, 2005, 4:22:47 PM, you wrote:
>> 7. Unordered records: yep (if I understand the problem correctly)
DR> I don't think you understood correctly. What I'd like (and this is another
DR> one of those David-specific issues--I've never he
Am Mittwoch, 23. November 2005 14:22 schrieb David Roundy:
> On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
> [...]
> > 7. Unordered records: yep (if I understand the problem correctly)
>
> I don't think you understood correctly. What I'd like (and th
David Roundy <[EMAIL PROTECTED]> writes:
> > 7. Unordered records: yep (if I understand the problem correctly)
>
> I don't think you understood correctly. What I'd like (and this is another
> one of those David-specific issues--I've never heard anyone else
On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
> Since discussion has returned to records, it might be useful for me to
> post a link to a proposal that I knocked up a while back when this
> topic came up a few years ago:
>
> http://www.cambridge.intel-resear
Hi guys,
Since discussion has returned to records, it might be useful for me to
post a link to a proposal that I knocked up a while back when this
topic came up a few years ago:
http://www.cambridge.intel-research.net/~rennals/records.pdf
The basic idea is to keep records largely as they are
On records in Haskell - can we start by formulating requirements
(design goals). What do we want from a record system,
and what are non-goals.
Some of the proposals here sound like records should be more like
objects (with some kind of inheritance). Do we really want this?
We already have
2005/11/20, Georg Martius <[EMAIL PROTECTED]>:
> 7. Unordered records.
> I don' t understand it.
>
Consider this example:
data DataT = DataT (Int,String) (String,String)
if we treat records as tuples with labels, then we could write:
data DataR = DataR {tel::In
On Sun, Nov 20, 2005 at 08:54:35AM -0500, David Roundy wrote:
> As an aside, what's responsible for the insanity of pattern matching record
> fields being backwards? I'd bar = b to bind b to bar, not the other way
> around... why should record pattern matching use '=' in a manner opposite
> from th
On Sun, Nov 20, 2005 at 02:09:04PM -0500, David Roundy wrote:
> > [x,y,z]
> [...]
> > R { field1 = x, field2 = y, field3 = z }
> >
> > I think this is very consistent.
>
> I see, you're right that it's consistent, but I still don't like the use of
> '=' in this scenario.
I understand you
On Sun, Nov 20, 2005 at 03:43:08PM +0100, Tomasz Zielonka wrote:
> On Sun, Nov 20, 2005 at 08:54:35AM -0500, David Roundy wrote:
> > As an aside, what's responsible for the insanity of pattern matching
> > record fields being backwards? I'd bar = b to bind b to bar, not the
> > other way around...
Am Sonntag, 20. November 2005 13:40 schrieb Georg Martius:
> [...]
> 4. Getters for multiple data types with a common field.
Do we need this? Couldn't this have ugly consequences? Say, I have a
datatype with a field of a certain name and another datatype with a field of
the same name. Having
On Sun, Nov 20, 2005 at 08:54:35AM -0500, David Roundy wrote:
> As an aside, what's responsible for the insanity of pattern matching record
> fields being backwards? I'd bar = b to bind b to bar, not the other way
> around... why should record pattern matching use '=' in a manner opposite
> from th
On Sun, Nov 20, 2005 at 01:40:01PM +0100, Georg Martius wrote:
> 7. Unordered records.
> I don' t understand it.
It's just that I'd like to be able to write:
data FooBar = FooBar { foo, bar :: String }
such that you can't write
let f = FooBar "a"
Hi folks,
rather than discussing about which operator symbol to use for record access,
which is really a question of personal taste we should try to seriously
discuss the proposals and get to a solutions!
We all seem to agree that records are broken in Haskell. In order to fix that
we need a
(Apologies for previous incomplete post: Here's the whole thing)
One thing that bugs me about the named record syntax, is that with a datatype:
data T = T {
t_f1 :: X,
t_f2 :: X
};
the function t_f1 has the type of an "accessor", ie
t_f1 :: T -> X
but there doesn't any tidy wa
> DRiFT will let you do that, by deriving get_ and set_ methods, but other
> than that, no. THere was discussion about a year ago (I think) about
> this, with proposed syntax for something, but it never really got off the
> ground. You can probably google for it with my name and some other
>
DRiFT will let you do that, by deriving get_ and set_ methods, but other
than that, no. THere was discussion about a year ago (I think) about
this, with proposed syntax for something, but it never really got off the
ground. You can probably google for it with my name and some other
keywords -
1 - 100 of 130 matches
Mail list logo
