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)
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)
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)
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)
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)
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: haskell@haskell.org
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 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: 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)
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 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)
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)
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[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)
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 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: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Am Montag, 21. November 2005 20:51 schrieb Henning Thielemann: On Mon, 21 Nov 2005, Wolfgang Jeltsch wrote: [...] Hmm, printing code on paper isn't good for the environment. But is quite the same argument for e-paper. :-) I already thought about this. But if your computer is turned on anyway (as usually is mine during my work time), it doesn't make any difference. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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: Re[4]: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Sat, 2005-11-19 at 15:40 +0300, Bulat Ziganshin wrote: my 15 CRT holds entire 100, even 102 chars in line and i don't want to lose even one of them! :) especially when comment to this function occupies another 7 lines :) The best argument I can come up with when advocating lines of 80 chars for most programming code is subtle, but important: Code is easier to read for me when it is printed on good old paper. a2ps(1) is magnificient, but it takes 80 chars only if you want two pages on a single A4. Quite a number of projects violates the 80 column principle with the result it is unreadable on print. The human eye is not good at scanning long lines. You tend to miss the beginning of the next column and has to scan longer for it when reading code. It helps quite a bit that code is indented though, so it is not entirely impossible. I tend to use rather big fonts and not maximize my emacs. I can cram 80 columns in, but no more. On the other hand, having long lines improves the chance that the grep(1) catches what you want when searching for context. You have some empty space in the end of lines to provide a helpful comment more often than in an 80 column setup. All in all, this is bikesheds on greener grass (google for bikeshed and Poul Henning Kamp). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Am Sonntag, 20. November 2005 12:28 schrieb Jesper Louis Andersen: [...] The best argument I can come up with when advocating lines of 80 chars for most programming code is subtle, but important: Code is easier to read for me when it is printed on good old paper. a2ps(1) is magnificient, but it takes 80 chars only if you want two pages on a single A4. Quite a number of projects violates the 80 column principle with the result it is unreadable on print. Hmm, printing code on paper isn't good for the environment. The human eye is not good at scanning long lines. This is a good argument. [...] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/21/05, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Sonntag, 20. November 2005 12:28 schrieb Jesper Louis Andersen: [...] The best argument I can come up with when advocating lines of 80 chars for most programming code is subtle, but important: Code is easier to read for me when it is printed on good old paper. a2ps(1) is magnificient, but it takes 80 chars only if you want two pages on a single A4. Quite a number of projects violates the 80 column principle with the result it is unreadable on print. Hmm, printing code on paper isn't good for the environment. The human eye is not good at scanning long lines. This is a good argument. Also that terminals etc. usually have 80 chars width. It may be time to stop worrying about code width, especially in languages like Haskell where you tend to use horizontal rather than vertical space to write your algorithms. But still, I always try to stick under 80 chars if possible to make it readible in terminals (and some email-clients etc.). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
You can change the project and update operators in the HList library to behave in exactly this way. At the moment they are constrained to not allow multiple identical labels in records. If this kind of access is considered useful, I can add it to the HList distribution. Keean. David Menendez wrote: Chris Kuklewicz writes: Would the record system describe at http://lambda-the-ultimate.org/node/view/1119 also be convertable into System Fw, GHC's existing, strongly-typeed intermediate language. ? Probably. Daan's current implementation uses MLF, which I believe is system F implemented for ML. (We're talking about the system in Daan Leijen's paper, Extensible Records With Scoped Labels. Good stuff.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Can this not be done with the HList code? I am pretty sure you should be able to map projections over HLists of HLists... (although the HList generic map is a bit ugly, requiring instances of the Apply class). Actually you should look in the OOHaskell paper (if you haven't already) where it discusses using narrow to allow homogeneous lists to be projected from heterogeneous ones... Keean. John Meacham wrote: another thing is that for any record syntax, we would want higher order versions of the selection, setting, and updating routines. A quick perusal of my source code shows over half my uses of record selectors are in a higher order fashion. (which need to be generated with DrIFT with the current syntax) I mean something like map (.foo) xs to pull all the 'foo' fields out of xs. (using made up syntax) or map (foo_s 3) xs to set all the foo fields to 3. (using DrIFT syntax) John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Mon, 21 Nov 2005, Wolfgang Jeltsch wrote: Am Sonntag, 20. November 2005 12:28 schrieb Jesper Louis Andersen: [...] The best argument I can come up with when advocating lines of 80 chars for most programming code is subtle, but important: Code is easier to read for me when it is printed on good old paper. a2ps(1) is magnificient, but it takes 80 chars only if you want two pages on a single A4. Quite a number of projects violates the 80 column principle with the result it is unreadable on print. Hmm, printing code on paper isn't good for the environment. But is quite the same argument for e-paper. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: I'm not saying it's impossible to make good use of (.), I'm saying that it's not crucial enough to warrant giving it the dot, which in my opinion is one of the best symbols (and I'd hand it over to record selection any day of the week!). I'm also saying that people tend to abuse the (.) operator when they start out because they think that less verbose == better, whereas most people, in my experience, tend to stop using (.) for all but the simplest cases (such as filte (not . null)) after a while to promote readability. I prefer adding a few lines with named sub-expressions to make things clearer. In case someone counts votes pro et contra of replacing (.) operator, I must say that find it one of the most useful and readable way for doing many different things (not only higher-order). And very compact too. And in my code it is very common operator. While if somebody, who at this moment counts my vote, will remove records from the language some day, I very likely wouldn't notice such a loss. And I can't say I'm very experienced haskell programmer. Actually I'm a beginner comparing my experience with other, particularly imperative OOP languages. And records with (.) as field selector (coupled with dumb constructors) will be the last thing i would miss in haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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) some list
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
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
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)
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 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)
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[2]: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Hello John,
Saturday, November 19, 2005, 2:25:47 AM, you wrote:
JM grep -o ' [-+.*/[EMAIL PROTECTED] ' GenUtil.hs | sort | uniq -c | sort -n
JM 30 .
JM one of the most common operators.
especially in comments ;) add the following filter to strip them:
import System.Environment
main = interact (noStream.(unlines.map noEnd.lines))
noStream ('{':'-':xs) = noInStream xs
noStream (c:xs) = c:noStream xs
noStream=
noInStream ('-':'}':xs) = noStream xs
noInStream (_:xs) = noInStream xs
noInStream=
noEnd ('-':'-':xs) =
noEnd (c:xs) = c:noEnd xs
noEnd=
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Hello Sebastian,
Friday, November 18, 2005, 6:35:13 PM, you wrote:
groupLen mapper combinator tester = length . takeWhile tester . scanl1
combinator . map mapper
SS This is a border line example of what I would consider being abuse of
SS the (.) operator.
SS First of all, that line is 96 characters long. A bit much if you ask
SS me.
my 15 CRT holds entire 100, even 102 chars in line and i don't want
to lose even one of them! :) especially when comment to this function
occupies another 7 lines :)
SS groupLen' mapper combinator tester xs
SS= length $ takeWhile tester $ scanl1 combinator $ map mapper xs
SS The difference is minimal, if anything I think that writing out the
SS list argument is actually clearer in this case (although there are
SS cases when you want to work on functions, and writing out the
SS parameters makes things less clear).
... including this one. i'm work with functions, when possible: build
them from values and other functions, hold them in datastructures,
pass and return them to/from functions. if function definition can be
written w/o part of its arguments, i do it in most cases
moreover, in some cases this leads to dramatic changes in speed. see:
-- |Test whether `filepath` meet one of filemasks `filespecs`
match_filespecs filespecs {-filepath-} = any_function (map match_FP filespecs)
function `match_FP` thranslates regexps to functions checking that
given filename match this regular expression:
match_FP :: RegExp - (String-Bool)
when definition of `match_filespecs` contained `filepath`, this
testing works very slow for large filelists. imho, for each filename
list of filespecs was retranslated to testing functions, each
function applied to filename and then results was combined by
`any_function`. it's a pity, especially cosidering that most common
case for regexps list was just [*], which must render to
(const True) testing function. so, in this case it was absolutely
necessary to write all this regexp machinery in point-free style, so that
it returns data-independent functions, which then optimized
(reduced) by Haskell evaluator before applying them to filenames
on the Wiki page RunTimeCompilation there is another examples of
building functions from datastructures before applying to input data
it is very possible that this point-free `groupLen` definition,
together with other point-free definitions, makes filelist processing
in my program faster - i just dont't checked it
SS I'm not saying it's impossible to make good use of (.), I'm saying
SS that it's not crucial enough to warrant giving it the dot, which in my
SS opinion is one of the best symbols (and I'd hand it over to record
SS selection any day of the week!).
SS I'm also saying that people tend to abuse the (.) operator when they
SS start out because they think that less verbose == better, whereas
SS most people, in my experience, tend to stop using (.) for all but the
SS simplest cases (such as filte (not . null)) after a while to promote
SS readability. I prefer adding a few lines with named sub-expressions to
SS make things clearer.
readability is not some constant factor for all people. it depends
on your experience. for you it is natural to work with data values.
for me, it's the same natural to work with function values, partially
apply and combine them. and in those definitions the variables
containing actual data is just looks as garbage for me
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Sebastian Sylvan wrote: How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That symbol actually does look better, but isn't on any English keyboards to the best of my knowledge. I can get it in my setup with compose-key o x, but not many people have a compose key assigned. Also, this may just be a bug, but currently, ghc gives a lexical error if I try to use that symbol anywhere, probably just since it's not an ASCII character. Hmm. On my keyboard it's Shift+4. Strange that it's not available on other keyboards. As far as I know that symbol means nothing particularly swedish. In fact, I have no idea what it means at all =) It's a generic currency symbol (the X11 keysym is XK_currency). It doesn't exist on a UK keyboard (where Shift-4 is the dollar sign). In any case, using non-ASCII characters gives rise to encoding issues (e.g. you have to be able to edit UTF-8 files). -- Glynn Clements [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Thu, Nov 17, 2005 at 06:56:09PM +0100, Sebastian Sylvan wrote: Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? I'm not so sure it is, and you can almost always write it using ($) without too much trouble. I really only ever use (.) for pretty simple things like filter (not . null). Again. I'm thinking () is a good operator. An intelligent editor would pull them together a bit more to make it look even more like a ring. I could see myself using and for dot and cross products in linear algebra, though, but I'm willing to sacrifice those operators for the greater good :-) /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
I always fancied () as a synonym for 'mappend' John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Fri, Nov 18, 2005 at 12:21:09PM +0100, Sebastian Sylvan wrote: On 11/18/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Thu, Nov 17, 2005 at 06:56:09PM +0100, Sebastian Sylvan wrote: Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? I'm not so sure it is, and you can almost always write it using ($) without too much trouble. I really only ever use (.) for pretty simple things like filter (not . null). Try not to look as if you wanted to _remove_ the composition operator, because that will make people angry (w...) :-) We are talking about _renaming_ the composition, not removing it, right? If you removed it from the Prelude, most people would write their own versions, with different names, and we rather don't want that. Anyway, is it realistic to expect that people will rewrite their programs to use the new operator? I thought that the new version of Haskell will be mostly downwards compatible with Hashell 98? Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Fri, Nov 18, 2005 at 12:21:09PM +0100, Sebastian Sylvan wrote: On 11/18/05, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Thu, Nov 17, 2005 at 06:56:09PM +0100, Sebastian Sylvan wrote: Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? I'm not so sure it is, and you can almost always write it using ($) without too much trouble. I really only ever use (.) for pretty simple things like filter (not . null). Try not to look as if you wanted to _remove_ the composition operator, because that will make people angry (w...) :-) We are talking about _renaming_ the composition, not removing it, right? Yes. I just don't think it's used enough to warrant giving it one of the best symbols. Anyway, is it realistic to expect that people will rewrite their programs to use the new operator? I thought that the new version of Haskell will be mostly downwards compatible with Hashell 98? Well the records proposal is unlikely to go in Haskell 1.5 anyway, so I'm mainly exercising wishful thinking here. In Haskell 2.0, which I understand to be more of a complete make-over, backwards-compability be damned!, this could be considered. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Friday 18 November 2005 02:59, you wrote: On Nov 17, 2005, at 1:52 PM, Benjamin Franksen wrote: ... Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists. Would you be happier if it were the yield operator for iterators? Yours lazily, Ok, ok, I tend to forget that Haskell lists are lazy streams, not just simple stacks... which makes them indeed a /lot/ more useful than the corresponding data type in strict languages. I still think all those nice short and meaningful names in the Prelude (map, filter, ...) should be type class members in some suitable standard collection library. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Fri, Nov 18, 2005 at 04:22:59PM +0100, Sebastian Sylvan wrote: Yes. I just don't think it's used enough to warrant giving it one of the best symbols. grep -o ' [-+.*/[EMAIL PROTECTED] ' GenUtil.hs | sort | uniq -c | sort -n 1 $! 1 * 8 + 10 == 12 - 17 -- 30 . 31 $ 39 ++ one of the most common operators. I think experienced haskell programers tend to use it a whole lot more often than beginning ones, and I am not even a point-free advocate. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. On 11/17/05, Joel Reymont [EMAIL PROTECTED] wrote: Don't get me started, please :-). I tried making each field a separate class but then needed to compose records of difference field instances which led to HList which led to GHC eating up all my memory and crashing, etc. I can see where you are going but if I have 250 records with shared fields then that's a whole lot of extra boiler plate code to marshall between the functions with prefixes to the class method implementations. The road to hell is paved with good intentions ;-). Thanks for the tip, though. On Nov 17, 2005, at 2:12 PM, Fraser Wilson wrote: To solve this problem I just made them all instances of a class with a gameId function. Still, not ideal. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit).Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal.On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. ===Gregory Woodhouse [EMAIL PROTECTED] "Interaction is the mind-body problem of computing." --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. === Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
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) some list if I want to print its elements each on a new line. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
So it sounds to me that momentum is building behind Simon PJ's proposal and that we are finally getting somewhere! Now, when can we actually get this in GHC? On Nov 17, 2005, at 5:56 PM, Sebastian Sylvan wrote: I've been wanting this for ages. It's SO much better than the current horribly broken records we have. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Would the record system describe at http://lambda-the-ultimate.org/node/view/1119 also be convertable into System Fw, GHC's existing, strongly-typeed intermediate language. ? On Thu, November 17, 2005 17:56, Sebastian Sylvan said: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Joel Reymont [EMAIL PROTECTED] wrote: I second this motion! I rather like Simon's proposal. On Nov 17, 2005, at 5:00 PM, Fraser Wilson wrote: Yeah, I thought you might have tried that at some point :-) I like http://research.microsoft.com/~simonpj/Haskell/records.html cheers, Fraser. == Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
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 Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote:
Isn't there a potential for confusion with function composition (f . g)?
Perhaps, but I always have spaces on either side when it's function composition. Isn't there already an ambiguity?
-- I bet there's a quicker way to do this ...
module M where data M a = M a deriving (Show)
data T a = T a deriving (Show)
module M.T where f = (+1)
import M
import qualified M.T
f = (*2)
v1 = M . T . f $ 5
v2 = M.T.f $ 5
main = do { print v1; print v2; return () }
Fraser.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 2005-11-17 at 13:21EST Cale Gibbard wrote: 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 Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Hear hear. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. Ought to be ∘, unicode 0x2218, but without defining some keyboard macros, that's even harder to type. On the other hand, I could define ctrl-. as (ucs-insert 2218), and then it would be no harder to type than . -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Thursday 17 November 2005 19:21, Cale Gibbard wrote: 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 Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists. For a hypothetical Haskell2 I'd propose to get rid of all special 'list' constructs and re-use the good symbols and names for /abstract/ interfaces to sequences and collections resp. (in case of the colon) for record selection. Just my 2 cent. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. Another option is to make application of a label to a record mean projection, somewhat like things currently are, though since labels aren't really functions anymore that is potentially confusing. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. IMO it really only works well for simple chains like foo . bar . oof . rab but as soon as you start working with functions that take more parameters it starts looking very unreadable and you'd be better off to just use $ or write out paranthesis and apply arguments explicitly, or better yet, introduce some temporary descriptive variables in a let or where clause. It's a matter of personal preference, but I certainly haven't found it used enough to warrant giving it perhaps the best symbol on the keyboard. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
--- Cale Gibbard [EMAIL PROTECTED] wrote: Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Actually, the fact that (!) is the array selector makes it all the more attractive as a record selector. (It does make you wonder if a record isn't a kind of a typed associative array, though...) Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. Well, yeah, but the arrows have such a fundamentally different meaning in Haskell. (I thought of that one, too). There's a triangle which is not taken, and isn't so hard to type (|). If we're not careful, though, Haskell will end up looking like APL. I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. Another option is to make application of a label to a record mean projection, somewhat like things currently are, though since labels aren't really functions anymore that is potentially confusing. Actually, I thought of that, too, or rather something like get label record or get record label (I haven't made up my mind which way the currying makes more sense. Do you have a generic function for getting records with a certain label, or do you apply get label, tget the field with this label, to record?) - Cale === Gregory Woodhouse [EMAIL PROTECTED] Interaction is the mind-body problem of computing. --Philip Wadler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I think both of those look crowded -- smashing operator punctuation up against symbols basically never looks good to me. The right amount of spacing isn't generally available without proper typesetting, but a full space is a lot closer than no space at all. Why not myPoint # x and myPoint . x? I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That symbol actually does look better, but isn't on any English keyboards to the best of my knowledge. I can get it in my setup with compose-key o x, but not many people have a compose key assigned. Also, this may just be a bug, but currently, ghc gives a lexical error if I try to use that symbol anywhere, probably just since it's not an ASCII character. That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. I disagree, there are plenty of cases where it's just what you want, and saves you from introducing a lambda term for nothing. This occurs very often in parameters to higher order functions. A simple example would be something like filter (not . null), or any ((`elem` consumers) . schVertex). More sophisticated examples come up all the time, and often the functions being composed have some parameters applied to them. I disagree that it's just for obfuscation. Using function composition puts emphasis on the manipulation of functions rather than on the manipulation of the elements those functions act on, and quite often in a functional language that's just what you want. IMO it really only works well for simple chains like foo . bar . oof . rab but as soon as you start working with functions that take more parameters it starts looking very unreadable and you'd be better off to just use $ or write out paranthesis
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 17/11/05, Benjamin Franksen [EMAIL PROTECTED] wrote: On Thursday 17 November 2005 19:21, Cale Gibbard wrote: 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 Function composition is a very important and fundamental operation on functions, and I use it all the time. Haskell is supposed to be a functional language. I'd vote against any motion to make it less convenient. Of course, it really shouldn't be (.) but a small circle centred on the line, which isn't on ordinary keyboards. (°) looks closer, but is much less convenient to type. (I need to type Compose 0 ^ in order to get that character.) Spelling it as (.) really is the best easy-to-type approximation. Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists. However, the way things are currently, all symbols starting with ':' are constructors of concrete data types, as that's how infix data constructors are distinguished. Also, I must point out that lists are a pretty important structure in lazy functional programming, taking the place of loops in an imperative language, and their importance shouldn't be taken so lightly. Given how much they are used, giving them a little syntax sugar and good looking data constructors doesn't seem all that far off. On the other hand, I would like to see list comprehensions generalised to monad comprehensions again. For a hypothetical Haskell2 I'd propose to get rid of all special 'list' constructs and re-use the good symbols and names for /abstract/ interfaces to sequences and collections resp. (in case of the colon) for record selection. However, you can't abstract data constructors. If cons was abstracted, then you couldn't use it in pattern matching, which is problematic. Just my 2 cent. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Cale Gibbard [EMAIL PROTECTED] wrote: On 17/11/05, Sebastian Sylvan [EMAIL PROTECTED] wrote: On 11/17/05, Greg Woodhouse [EMAIL PROTECTED] wrote: Isn't there a potential for confusion with function composition (f . g)? That being said, I like this idea (I just need to think it through a bit). I've been wanting this for ages. It's SO much better than the current horribly broken records we have. There could be confusion with function composition, but there's no ambiguity (compositon have spaces around the dot, while record accessors do not). 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 do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. I'd rather function composition was left out of the prelude alltogether (or defined as (#) or something). Anyway. The current records system is a wart. Actually, I didn't mention this in the other post, but why not the other way around? Make record selection (#) or (!) (though the latter gets in the way of array access), and leave (.) for function composition. Personally, I'd like something which looked like an arrow for record selection, but most of the good 2-character ones are unavailable. (~) is a bit hard to type and looks wrong in some fonts. There's a triangle which is not taken, and isn't so hard to type (|). I never really understood the attachment to (.) for record selection. There's no reason that we have to make things look like Java and C. This is going to be highly fuzzy and completely subjective. Here it goes. I find that for selections (records, or qualified modules etc.) I want the operator to be small and so that the important word groups become the module or the record. When I read the following two variants myPoint#x myPoint.x I think both of those look crowded -- smashing operator punctuation up against symbols basically never looks good to me. The right amount of spacing isn't generally available without proper typesetting, but a full space is a lot closer than no space at all. Why not myPoint # x and myPoint . x? Well, again this is just preference, but to me I'd like selectors to not have space between the record and the label, they still need to be connected, but with a symbol which is small enought to help you easily see what's what. I definatly prefer the latter. In the first one the operator is so large that it makes myPoint and x blend together as you read it (step away from the monitor and squint and you'll see what I mean), whereas in the second example the operator is small and makes the two operands naturally separate slightly when reading it, which makes it easier to tell which identifier is accessed. Also, it's certainly not a BAD thing if Haskell uses the same operators as other languages. With function composition, though, the operator is just as important to identify when reading as the operands are. So I don't think a big operator is a problem there - likewise I have no problems with ($) being large. How about (¤)? It looks like a ring to me, I'm not sure where that's located on a EN keyboard, but it's not terribly inconvenient on my SE keyboard. f ¤ g looks better than f . g for function composition, if you ask me. That symbol actually does look better, but isn't on any English keyboards to the best of my knowledge. I can get it in my setup with compose-key o x, but not many people have a compose key assigned. Also, this may just be a bug, but currently, ghc gives a lexical error if I try to use that symbol anywhere, probably just since it's not an ASCII character. Hmm. On my keyboard it's Shift+4. Strange that it's not available on other keyboards. As far as I know that symbol means nothing particularly swedish. In fact, I have no idea what it means at all =) That's my subjective view on why the dot-operator is so darn nice, anyway. Oh and to answer to your other post. I realise that function composition is a fundamental operation, but it's so fundamental that it's quite useless for most real-world cases unless your willing to seriously ubfuscate your code. I disagree, there are plenty of cases where it's just what you want, and saves you from introducing a lambda term for nothing. This occurs very often in parameters to higher order functions. A simple example would be something like filter (not . null), or any ((`elem` consumers) . schVertex). More sophisticated examples come up all the time, and often
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
another thing is that for any record syntax, we would want higher order versions of the selection, setting, and updating routines. A quick perusal of my source code shows over half my uses of record selectors are in a higher order fashion. (which need to be generated with DrIFT with the current syntax) I mean something like map (.foo) xs to pull all the 'foo' fields out of xs. (using made up syntax) or map (foo_s 3) xs to set all the foo fields to 3. (using DrIFT syntax) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Nov 17, 2005, at 1:52 PM, Benjamin Franksen wrote: ... Yes, yes, yes. I'd rather use a different operator for record selection. For instance the colon (:). Yes, I know it is the 'cons' operator for a certain concrete data type that implements stacks (so called 'lists'). However I am generally opposed to wasting good operator and function names as well as syntactic sugar of any kind on a /concrete/ data type, and especially not for stacks aka lists. Would you be happier if it were the yield operator for iterators? Yours lazily, Jan-Willem Maessen Just my 2 cent. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
Chris Kuklewicz writes: Would the record system describe at http://lambda-the-ultimate.org/node/view/1119 also be convertable into System Fw, GHC's existing, strongly-typeed intermediate language. ? Probably. Daan's current implementation uses MLF, which I believe is system F implemented for ML. (We're talking about the system in Daan Leijen's paper, Extensible Records With Scoped Labels. Good stuff.) -- David Menendez [EMAIL PROTECTED] | In this house, we obey the laws http://www.eyrie.org/~zednenem |of thermodynamics! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On 11/18/05, John Meacham [EMAIL PROTECTED] wrote:
another thing is that for any record syntax, we would want higher order
versions of the selection, setting, and updating routines. A quick
perusal of my source code shows over half my uses of record selectors
are in a higher order fashion. (which need to be generated with DrIFT
with the current syntax)
I mean something like
map (.foo) xs
to pull all the 'foo' fields out of xs. (using made up syntax)
Well I suppose this is just a section on the selection operator?
map (foo_s 3) xs
This is trickier I think. I think I can live with map (\r - {r | s =
3}), though.
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Fri, Nov 18, 2005 at 07:32:53AM +0100, Sebastian Sylvan wrote:
On 11/18/05, John Meacham [EMAIL PROTECTED] wrote:
map (.foo) xs
to pull all the 'foo' fields out of xs. (using made up syntax)
Well I suppose this is just a section on the selection operator?
So field labels are first-class citizens? Great!
map (foo_s 3) xs
This is trickier I think. I think I can live with map (\r - {r | s =
3}), though.
I think this special case could be treated specially, for example
(\r - {r | s = 3})
could be equivalent to
{|s = 3}
Best regards
Tomasz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
On Thu, Nov 17, 2005 at 06:56:09PM +0100, 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 just checked in two recent projects, and it's about one (.) in 100 lines of code. I wanted to disagree with you, but in the end I could accept pressing more keys when I wanted function composition, especially if I got something in return. BTW, I think there was some tool to calculate various metrics on Haskell code. It would be interesting to make some graphs showing how often you use various features of Haskell, how it changed with time. I use ($) way more often than (.). Me too, measurement shows it's about four times more often. However, I like my uses of (.) much more than uses of ($). I often turn $'s into parentheses, because I feel it looks better this way. Of course, there are cases where $ is indispensable. Some people do use it more often than I do, but I find that in most cases except simple pipelined functions it only makes the code harder to read. But this case is quite important, isn't it? Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
