Records (was Re: [Haskell] Improvements to GHC)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Records (was Re: [Haskell] Improvements to GHC)

Joel Reymont
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 <[hidden email] > 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Gregory Woodhouse
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 <[hidden email]> 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  <
[hidden email]>

"Interaction is the mind-body problem of computing."

--Philip Wadler



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Sebastian Sylvan
On 11/17/05, Greg Woodhouse <[hidden email]> 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 <[hidden email]> 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  <[hidden email]>
>
>
> "Interaction is the mind-body problem of computing."
>
> --Philip Wadler
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>


--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Joel Reymont
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

haskell-2
In reply to this post by Sebastian Sylvan
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 <[hidden email]> 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 <[hidden email]> 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  <[hidden email]>
>>
>>
>> "Interaction is the mind-body problem of computing."
>>
>> --Philip Wadler
>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>
>
> --
> Sebastian Sylvan
> +46(0)736-818655
> UIN: 44640862
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Fraser Wilson
In reply to this post by Gregory Woodhouse


On 11/17/05, Greg Woodhouse <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Cale Gibbard
In reply to this post by Sebastian Sylvan
On 17/11/05, Sebastian Sylvan <[hidden email]> wrote:

> On 11/17/05, Greg Woodhouse <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Sebastian Sylvan
On 11/17/05, Cale Gibbard <[hidden email]> wrote:

> On 17/11/05, Sebastian Sylvan <[hidden email]> wrote:
> > On 11/17/05, Greg Woodhouse <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Gregory Woodhouse
In reply to this post by Cale Gibbard


--- Cale Gibbard <[hidden email]> 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  <[hidden email]>


"Interaction is the mind-body problem of computing."

--Philip Wadler











_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Cale Gibbard
In reply to this post by Sebastian Sylvan
On 17/11/05, Sebastian Sylvan <[hidden email]> wrote:

> On 11/17/05, Cale Gibbard <[hidden email]> wrote:
> > On 17/11/05, Sebastian Sylvan <[hidden email]> wrote:
> > > On 11/17/05, Greg Woodhouse <[hidden email]> 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 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.

The best symbol on the keyboard is almost certainly space, which
currently goes to function application. :) Personally, I really like
the current syntax, which just makes the labels into projection
functions when that's appropriate.

 - Cale
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Sebastian Sylvan
On 11/17/05, Cale Gibbard <[hidden email]> wrote:

> On 17/11/05, Sebastian Sylvan <[hidden email]> wrote:
> > On 11/17/05, Cale Gibbard <[hidden email]> wrote:
> > > On 17/11/05, Sebastian Sylvan <[hidden email]> wrote:
> > > > On 11/17/05, Greg Woodhouse <[hidden email]> 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 the functions being composed have some parameters
> applied to them. I disagree that it's just for obfuscation.

Well, what I said was that for any more complex cases than that it
ends up being hard to read. In a lot of examples when peopl abuse
function compostion you really have to think for quite a while before
you can figure out what it does, whereas if they had just written out
everything in a few more steps it would've been immediatly clear.

"filter (not # null)" isn't in any way worse than "filter (not .
null)" IMO. Also, like I said earlier, I would even prefer a larger
operator for compositon since in that case you want spaces around the
operator (at least that's how I always use it in maths) and the dot is
perhaps a bit too small in that case (easy to miss it on a glance,
misstaking it for application).
How about (<>) for the ring operator? That's almost a circle. "filter
(not <> null)" looks pretty nice IMO.
At any rate, I think that the dot is such a good symbol that I'd
prefer to give it to a primitive operator (such as module or record
selection) rather than something which is user-defined (but in the
prelude). Plus, if the record system was halfway decent, I'm pretty
sure record selection would occur a few orders of magnitude more often
than function composition. So from a pure "popularity" standpoint
record selection would win (assuming it's agreed that three uses for
the dot operator is too much and one needs to go, that is).

/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

John Meacham
In reply to this post by Cale Gibbard
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Sebastian Sylvan
On 11/18/05, John Meacham <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Tomasz Zielonka
On Fri, Nov 18, 2005 at 07:32:53AM +0100, Sebastian Sylvan wrote:
> On 11/18/05, John Meacham <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Tomasz Zielonka
In reply to this post by Sebastian Sylvan
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Glynn Clements
In reply to this post by Sebastian Sylvan

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 <[hidden email]>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Records (was Re: [Haskell] Improvements to GHC)

Bulat Ziganshin
In reply to this post by Sebastian Sylvan
Hello Sebastian,

Thursday, November 17, 2005, 11:02:09 PM, you wrote:

SS> IMO it really only works well for simple "chains" like "foo . bar .
SS> oof . rab" but as soon as you start working with functions that take
SS> more parameters it starts looking very unreadable and you'd be better
SS> off to just use $ or write out paranthesis and apply arguments
SS> explicitly, or better yet, introduce some temporary descriptive
SS> variables in a let or where clause.

"are you don't like cats? you just don't know how to cook them right!" :)

-- |Returns length of initial segment of list, conforming to combined condition
-- F.e. "groupLen (fiSize) (+) (<16*mb) files" returns length of
-- initial segment of list, containing files with TOTAL size not exceeding 16 mb
groupLen mapper combinator tester  =  length . takeWhile tester . scanl1 combinator . map mapper

-- |Sort list by function result (use Schwarznegian transform)
sortOn  f  =  map snd . sortOn' fst . map (keyval f)
-- |Sort list by function result (don't use Schwarznegian transform!)
sortOn' f  =  sortBy (map2cmp f)

-- This defines filters for files, included in various operations on archives
  let arc_filter  =  andf [not.excluded_f cmd, not.overwrite_f cmd]
  let arc_filter  =  andf [included_f cmd, not.excluded_f cmd]
  let arc_filter  =  not.andf [included_f cmd, not.excluded_f cmd]
  let arc_filter  =  andf [included_f cmd, not.excluded_f cmd, not.overwrite_f cmd]
  let arc_filter  =  andf [included_f cmd, not.excluded_f cmd]


--
Best regards,
 Bulat                            mailto:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

Sebastian Sylvan
In reply to this post by Tomasz Zielonka
On 11/18/05, Tomasz Zielonka <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records (was Re: [Haskell] Improvements to GHC)

John Meacham
I always fancied (<>) as a synonym for 'mappend'
        John

--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Records

Ketil Malde-2
In reply to this post by Fraser Wilson
Fraser Wilson <[hidden email]> writes:

>                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.

Good for you.  Syntax that changes depending on spacing is my number
one gripe with the Haskell syntax.  And too many infix operators and
symbolic elements are on the list as well.

How about a pair of (magical, if necessary) functions called set and
get?  Letting you do something like

      x `set` first 4 `set` second "foo"
?

-k
--
If I haven't seen further, it is by standing in the footprints of giants

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
123