Re: Records (was Re: [Haskell] Improvements to GHC)
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 datatype it belongs to.
> When used in conjunction with Person, name means a person's name while it
> means a filename (a notably different thing) when used in conjunction with
> File. With the typeclass approach, we would have a single function called
> "name" which deals with different things. Important details would just be
> camouflaged. This is not good. In fact, it is really bad in my opinion.
Hi Wolfgang,
I think you are right in that two similarly named fields should not be
automatically considered to be equivilent. Indeed that is why the
typeclass approach I proposed requires that one explicitly declare any
typeclasses, and explicitly declare when two similarly named fields
are part of the same typeclass -- one thus cannot have two fields been
considered equivalent without the programmer making a conscious
descision that this is correct behaviour.
> Maybe it would really be better to have functions like Person.name and
> File.name?
In the case you give, I think you are right. In this case, using
namespaces to distinguish fields is preferable to treating the same.
However I think there are also other cases in which it *is* desirable
to allow several datatypes to have the same field -- with the
programmer making a contious descision to do things this way.
[snip]
-Rob
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 same label and different type would
> not be possible
> eg { name :: String }, { name :: Int }
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 datatype it belongs to.
When used in conjunction with Person, name means a person's name while it
means a filename (a notably different thing) when used in conjunction with
File. With the typeclass approach, we would have a single function called
"name" which deals with different things. Important details would just be
camouflaged. This is not good. In fact, it is really bad in my opinion.
Maybe it would really be better to have functions like Person.name and
File.name?
> John
Best wishes,
Wolfgang
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
> It actually sounds a lot like pattern guards, since you're suggesting this
> sugar could be applied to any sort of object? So your desugarer would
> allow a function like
>
> islong :: [a] -> Bool
> islong {length = l} = l > 10
this looks like a hack that only works for one-argument functions,
and its only purpose seems to hide the argument.
I don't like the (local) looks of "length = 1" anyway.
Compare to "length [] = 0". You'd think the first one
is a typing error until you spot the surrounding "{ .. }"
While we're at it, I'd like to mention a feature that
I'd love to have in a record system (for a long time):
defaults, resp. initializer functions.
E. g. data Foo = Foo { foo :: Int, bar :: Int ; bar x = 2 * foo x }
Something like that (imagine that (*) is some expensive computation).
Note that default declarations in classes are vaguely similar.
Again, the concrete syntax problem is whether to hide the argument.
Perhaps data Foo = Foo { foo :: Int, bar :: Int ; bar = 2 * foo self }
with a reserved word "self" is better. - Are there semantic problems?
It might even be desirable 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 compilation
(if type definition and memorized functions are in different modules.
Again, this is vaguely similar to orphan instances.)
Best regards,
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/ ---
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On Sun, Nov 27, 2005 at 08:47:54PM +, Rob Ennals wrote:
> On 11/23/05, David Roundy <[EMAIL PROTECTED]> wrote:
> > > 3. "Safe" getters for multi-constructor data types: ditto
> >
> > I think either you misunderstood my meaning by "safe", or I misunderstood
> > your paper. I meant that if I write
> >
> > data FooBar = Foo { foo :: String } | Bar { 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
> outright would cause compatability issues)
Yeah, issuing a warning (which can become an error with -Werr) is a nice
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)
> >
> > I don't think you understood correctly.
>
> I was thinking along the same lines as Wolfgang : don't export the
> internal representation of the type, but do expose the field
> manipulator functions.
>
> This needn't prevent the use of pattern matching, provided the
> desugaring of patterns is consistent with the rest of the system.
>
> E.g. I was assuming that
>
> case e of { x = 3, y = 4} -> ...
>
> would desugar to
>
> case e of _ | x z = 3 && y z = 4 -> ...
>
> Note that this pattern matching syntax will continue to work, even if
> 'x' and 'y' are reimplemented as normal functions, rather than fields.
Indeed, it hadn't occurred to me to make pattern matching work this way.
It actually sounds a lot like pattern guards, since you're suggesting this
sugar could be applied to any sort of object? So your desugarer would
allow a function like
islong :: [a] -> Bool
islong {length = l} = l > 10
--
David Roundy
http://www.darcs.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 same label and different type would
not be possible
eg { name :: 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)
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, but add two
extensions:
- field getter functions are placed in type classes
- fields desugar to setter functions as well as getters
Useful features of this approach are:
- backward compatibility with existing code
- the existing type-class mechanism is used for shared field names
- setters can be redefined if a type is changed, just as getters can now
To go through Dave's issues:
1. Field namespaces: solved by using type classes
2. Multi-constructor getters: solved by desugaring to functions
3. "Safe" getters for multi-constructor data types: ditto
4. Getters for multiple data types with a common field: solved by
type-classes (no special "constains" feature required)
5. Setters as functions: yep
6. Anonymous records: not supported
7. Unordered records: yep (if I understand the problem correctly)
And Georg's points:
8. Subtyping: yep -using type classes
9. higher order versions for selecting, updateing ... : not sure what
is meant here
Of course, my proposal might very well not do what you want, but I
thought it was worth posting it again.
Hope people find this useful.
-Rob
On 11/22/05, Johannes Waldmann <[EMAIL PROTECTED]> wrote:
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 inheritance (for interfaces). Isn't that enough?
My main objection is that concrete data types (e. g. records)
should not be exposed by a module anyway,
and should definitely not be a base for derivations
(Compare the OO design pattern literature).
Still if they are exposed (or while we're inside a module),
what makes the current records quite impractical
is the namespace issue (for component names).
Sure, one thing would be to invent some ad-hoc solution
(automatic qualification by type name or something)
but another possibility is to allow ad-hoc polymorphisms
generally in the language.
Just my 2 cent (and none of them new, I'm afraid)
--
-- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 --
http://www.imn.htwk-leipzig.de/~waldmann/ ---
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
On 11/23/05, David Roundy <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 22, 2005 at 02:32:47PM +, Rob Ennals wrote:
[snip]
> > 1. Field namespaces: solved by using type classes
>
> But these classes are required to be manually specified, right? This avoids
> the problem of proliferation of typeclasses if one had one class per field,
> but does mean that coordination is necesary in order to avoid namespace
> clashes.
>
> As far as I can tell, this means that we'd have issues with
>
> data StupidDouble = StupidDouble { value :: Double }
> data StupidInt = StupidInt { value :: Int }
>
> unless we use multiparameter typeclasses or something.
You are indeed right.
My thinking was that fields should be thought of in much the same way
as functions. If two same-named fields are supposed to be used the
same way, then one should declare a type class, and if they are
supposed to be distinct, then one should use module namespaces.
As regards multiparameter typeclasses - I think that they should work
quite well with this proposal.
e.g.
class HasVal a b where
value :: a -> b
instance HasVal StupidDouble Double
instance HasVal StupidDouble Int
[snip]
> > 3. "Safe" getters for multi-constructor data types: ditto
>
> I think either you misunderstood my meaning by "safe", or I misunderstood
> your paper. I meant that if I write
>
> data FooBar = Foo { foo :: String } | Bar { 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
outright would cause compatability issues)
> > 7. Unordered records: yep (if I understand the problem correctly)
>
> I don't think you understood correctly.
I was thinking along the same lines as Wolfgang : don't export the
internal representation of the type, but do expose the field
manipulator functions.
This needn't prevent the use of pattern matching, provided the
desugaring of patterns is consistent with the rest of the system.
E.g. I was assuming that
case e of { x = 3, y = 4} -> ...
would desugar to
case e of _ | x z = 3 && y z = 4 -> ...
Note that this pattern matching syntax will continue to work, even if
'x' and 'y' are reimplemented as normal functions, rather than fields.
Hope this all makes sense.
-Rob
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
you can always do: case (field1 record,field2 record, field3 record ...) of (pat1,pat2,pat3) -> _ -> Which lets you pattern match on fields independantly of their position in the record. Keean. David Roundy wrote: 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 correctly) ... You can just omit the data constructors from the module's export list. Yes, you can do that if you don't want to allow pattern matching. That's an acceptable solution for truly "exported" (i.e. opaque) data, but for internal data structures I would like to allow pattern matching without allowing positional matching (or constructing). Too many times I've had to go through the entire code adding an extra "_" to each pattern match, and each time there's a possibility you'll add it in the wrong spot. I could do this with coding guidelines, but I'd prefer to have the compiler enforce this. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 correctly) ... > You can just omit the data constructors from the module's export list. Yes, you can do that if you don't want to allow pattern matching. That's an acceptable solution for truly "exported" (i.e. opaque) data, but for internal data structures I would like to allow pattern matching without allowing positional matching (or constructing). Too many times I've had to go through the entire code adding an extra "_" to each pattern match, and each time there's a possibility you'll add it in the wrong spot. I could do this with coding guidelines, but I'd prefer to have the compiler enforce this. -- David Roundy http://www.darcs.net ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[2]: Records (was Re: [Haskell] Improvements to GHC)
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 heard anyone else complain DR> about this) is to be able to create a data type that has no order. i think that this is very good thing, especially for library writers. it's just a Good Programming Style, not for bad guys like me ;) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 this is another
> one of those David-specific issues--I've never heard anyone else complain
> about this) is to be able to create a data type that has no order. If I
> write
>
> data FooBar = FooBar { foo, bar :: String }
>
> I can construct this (either with Haskell 98 or with your proposal, as I
> understand it) with either
>
> fb = FooBar { foo = "a", bar = "b" }
>
> or with
>
> fb = FooBar "a" "b"
>
> I'd prefer to at least optionally be able to make the second syntax fail to
> compile--which is what I mean by an unordered record. The same goes for
> pattern matching.
You can just omit the data constructors from the module's export list.
> [...]
Best wishes,
Wolfgang
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 complain
> about this) is to be able to create a data type that has no order.
FWIW, there are certainly other people out there who think the same
way. In the Blobs diagram editor for instance, there are lots of
instances of exported datatypes with exported field accessors/updaters,
but the constructors are not exported. e.g.
module M (FooBar(), emptyFooBar, getFoo, getBar, setFoo, setBar) where
data FooBar = FooBar { foo :: String, bar :: Bool }
emptyFooBar = FooBar {}
getFoo = foo
getBar = bar
setFoo f fb = fb {foo=f}
setBar b fb = fb {bar=b}
This gives you three-quarters of your desire, i.e. unordered
construction is possible, positional construction is not, and
positional de-construction (pattern-matching) is also unavailable.
The only thing lacking is the ability to do unordered pattern-matching,
which is impossible here because the accessors are pure functions,
not true field names.
Just as for you, the intent of the design pattern here is total data
encapsulation - to be able to change the internals of the FooBar type
without any of the importing modules needing to change as a result.
Regards,
Malcolm
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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-research.net/~rennals/records.pdf
Looks pretty nice.
> To go through Dave's issues:
>
> 1. Field namespaces: solved by using type classes
But these classes are required to be manually specified, right? This avoids
the problem of proliferation of typeclasses if one had one class per field,
but does mean that coordination is necesary in order to avoid namespace
clashes.
As far as I can tell, this means that we'd have issues with
data StupidDouble = StupidDouble { value :: Double }
data StupidInt = StupidInt { value :: Int }
unless we use multiparameter typeclasses or something. This is a stupid
example (thus the type names), but I think there are real cases where you'd
like to create constructors like this.
> 2. Multi-constructor getters: solved by desugaring to functions
> 3. "Safe" getters for multi-constructor data types: ditto
I think either you misunderstood my meaning by "safe", or I misunderstood
your paper. I meant that if I write
data FooBar = Foo { foo :: String } | Bar { bar :: String }
there shouldn't be accessors of type
foo :: FooBar -> String
bar :: FooBar -> String
which die when given bad input (e.g. calling (foo $ Bar "bar")). I'd
rather in this case either not have these functions generated (and require
that I use pattern matching) or have them have type
foo :: FooBar -> Maybe String
bar :: FooBar -> Maybe String
I just don't like bottom. Perhaps it wouldn't be so bad if we got decent
error messages, but when you call (foo $ Bar "bar") you get no hint as to
where the bug actually is.
> 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 complain
about this) is to be able to create a data type that has no order. If I
write
data FooBar = FooBar { foo, bar :: String }
I can construct this (either with Haskell 98 or with your proposal, as I
understand it) with either
fb = FooBar { foo = "a", bar = "b" }
or with
fb = FooBar "a" "b"
I'd prefer to at least optionally be able to make the second syntax fail to
compile--which is what I mean by an unordered record. The same goes for
pattern matching. This feature is orthogonal to almost all the other
record issues, and really a compiler warning would probably be enough to
satisfy me, although I'd prefer to have this in the language.
The point (in case I've been unclear again) is that I'd like to be able to
later change the definition to
data FooBar = FooBar { foo, bar :: String }
without the possibility of breaking the code. This is a silly example, and
noone would actually make this change, simply because it would be too hard
to go through the code and verify that all the patterns have been swapped
(and didn't get swapped twice).
It's something that one could implement with code policy, but on the other
hand, you could in principle say the same thing about static typing.
--
David Roundy
http://www.darcs.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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, but add two extensions: - field getter functions are placed in type classes - fields desugar to setter functions as well as getters Useful features of this approach are: - backward compatibility with existing code - the existing type-class mechanism is used for shared field names - setters can be redefined if a type is changed, just as getters can now To go through Dave's issues: 1. Field namespaces: solved by using type classes 2. Multi-constructor getters: solved by desugaring to functions 3. "Safe" getters for multi-constructor data types: ditto 4. Getters for multiple data types with a common field: solved by type-classes (no special "constains" feature required) 5. Setters as functions: yep 6. Anonymous records: not supported 7. Unordered records: yep (if I understand the problem correctly) And Georg's points: 8. Subtyping: yep -using type classes 9. higher order versions for selecting, updateing ... : not sure what is meant here Of course, my proposal might very well not do what you want, but I thought it was worth posting it again. Hope people find this useful. -Rob On 11/22/05, Johannes Waldmann <[EMAIL PROTECTED]> wrote: > 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 inheritance (for interfaces). Isn't that enough? > > My main objection is that concrete data types (e. g. records) > should not be exposed by a module anyway, > and should definitely not be a base for derivations > (Compare the OO design pattern literature). > > Still if they are exposed (or while we're inside a module), > what makes the current records quite impractical > is the namespace issue (for component names). > > Sure, one thing would be to invent some ad-hoc solution > (automatic qualification by type name or something) > but another possibility is to allow ad-hoc polymorphisms > generally in the language. > > Just my 2 cent (and none of them new, I'm afraid) > -- > -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- > http://www.imn.htwk-leipzig.de/~waldmann/ --- > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 inheritance (for interfaces). Isn't that enough? My main objection is that concrete data types (e. g. records) should not be exposed by a module anyway, and should definitely not be a base for derivations (Compare the OO design pattern literature). Still if they are exposed (or while we're inside a module), what makes the current records quite impractical is the namespace issue (for component names). Sure, one thing would be to invent some ad-hoc solution (automatic qualification by type name or something) but another possibility is to allow ad-hoc polymorphisms generally in the language. Just my 2 cent (and none of them new, I'm afraid) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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::Int,addr::String} {zip::String,state::String}
so we could have more records per sum-type case. It is also good
because constructor arity stays the same, in this case both DataT and
DataR have arity 2.
What do you think?
--
Gracjan
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 the rest of Haskell? Perhaps it's better to think of '=' as asserting equality, than as binding? Andrew ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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. I had the same feelings some time ago, I even have
them today to some degree. At least consistency helps to get used to it.
Best regards
Tomasz
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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... why should record pattern matching use '=' in a
> > manner opposite from the rest of Haskell?
>
> It just mimics the way (record) values are constructed, as in all
> pattern matching in Haskell. You can put a pattern variable everywhere
> you could put a value in a corresponding constructing expression. For
> example, all these "terms" can be used both as an expression and a
> pattern. In the first case x, y, z are expressions, in the second they
> are patterns.
>
> [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 don't really have a better idea, but something
like
R { field1 -:- x, field2 -:- y, field3 -:- z }
(where I don't like the -:- but can't think of anything better off the top
of my head) might be more intuitive, since '=' means bind the value on the
right to the name on the left everywhere else in haskell, but in record
syntax it's part of a constructor. It'd be nice to reuse an existing
haskell syntax ("->" ?), but I can't think of one that would fit. One
could perhaps use :=, which at least looks like a constructor rather than a
binding...
--
David Roundy
http://www.darcs.net
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 a single getter for both fields might be bad if the fields mean different things. For example, a "name" and a "name" can be quite different things. > [...] Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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 the rest of Haskell?
It just mimics the way (record) values are constructed, as in all
pattern matching in Haskell. You can put a pattern variable everywhere
you could put a value in a corresponding constructing expression. For
example, all these "terms" can be used both as an expression and a
pattern. In the first case x, y, z are expressions, in the second they
are patterns.
[x,y,z]
(x:y:z)
(x,(y,z))
(C x y, D z)
R { field1 = x, field2 = y, field3 = z }
I think this is very consistent.
Best regards
Tomasz
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: Records (was Re: [Haskell] Improvements to GHC)
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" "b"
but instead are forced to write
let f = FooBar { foo = "a", bar = "b" }
More importantly when you pattern match, you couldn't write
case f of FooBar _ b -> b
but instead would have to write
case f of FooBar { bar = b } -> b
The reason being that I'd like to be able to export constructors from a
module in such a way that I can later reorder or add or remove field from
that record without breaking any pattern-matching code, and if I'm only
reordering the fields, I shouldn't break any constructor code either.
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 the rest of Haskell?
--
David Roundy
http://www.darcs.net
signature.asc
Description: Digital signature
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Records (was Re: [Haskell] Improvements to GHC)
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 new and most probably incompatible solution. However, I think the
new solution should go in a new version of the Haskell standard (among other
things :-) ).
I would strongly disadvice to try to stick with the old system and improve it.
Just because there are lots of different opinions we should still try to find
a reasonable solution soon.
Desite the minor problem of '.' that dominated the discussion so far, what are
the REAL offences against Simons proposal [1] (denoted as SR in the
following)?
To me it sounds like a very reasonable starting point.
Which other proposals exist?
I quote David Roundy's list of problems [2] with a short annotation whether SR
solves them:
1. The field namespace issue.
solved by not sharing the same namespace with functions
2. Multi-constructor getters, ideally as a function.
not solved. only possible by hand
- As stated by Wolfgang Jeltsch [3] another datatype design might be
better
- I can image a solution is within SR example:
>data Decl = DeclType { name :: String, ... }
> | DeclData { name :: String, ... }
> | ...
> d :: Decl
in addition to
> d.DeclType.name
> d.DeclData.name
we provide (only if save, see 3.)
> d.name
3. "Safe" getters for multi-constructor data types.
not supported as it is
- with the above suggestion it could be possible (don't know if
desireable)
4. Getters for multiple data types with a common field.
- solved with contrains
> getx :: (r <: { x :: a }) => r -> a
5. Setters as functions.
doesn't seem to be supported, or I don't see it right now.
6. Anonymous records.
Supported
7. Unordered records.
I don' t understand it.
points added from me:
8. Subtyping
Supported, quite nicely
9. higher order versions for selecting, updateing ... [4]
not supported
seems important to me, any solutions?
Regards
Georg
[1] http://research.microsoft.com/~simonpj/Haskell/records.html
[2] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012226.html
[3] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012227.html
[4] http://www.haskell.org//pipermail/haskell-cafe/2005-November/012162.html
Am Donnerstag, 17. November 2005 19:08 schrieb Dimitry Golubovsky:
> Sebastian Sylvan wrote:
> >Personally I think that the dot is way to good of a symbol to be
> >"wasted" on function composition. I mean, how often do you really use
> >function composition in a way which doesn't obfuscate your code? I use
> >($) way more often than (.). Some people do use it more often than I
>
> I found it useful to use (mainly for debugging purposes)
>
> mapM (putStrLn . show)
>
> if I want to print its elements each on a new line.
>
> --
> Dimitry Golubovsky
>
> Anywhere on the Web
--
Georg Martius, Tel: (+49 34297) 89434
--- http://www.flexman.homeip.net -
pgpuroWJrVcBG.pgp
Description: PGP signature
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
