Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Wolfgang Jeltsch]

Am Montag, 28. April 2008 06:29 schrieben Sie:
> Wolfgang Jeltsch:
> > Am Donnerstag, 24. April 2008 05:13 schrieb Manuel M T Chakravarty:
> > > […]
> > >
> > > Hence, anything that is *important* to change, we should change now.
> >
> > Although I can follow your arguments, I thought that the large and
> > disruptive changes should be done for Haskell 2.
>
> Depends what you mean by Haskell 2.  If it is an experimental language
> that shares some superficial similarities with Haskell, sure we may
> have Haskell 2.  If you mean a serious successor of Haskell with the
> expectation that many/most Haskell users will eventually move to
> Haskell 2, then no.  Haskell has been gaining a lot of momentum
> recently.  That's good and bad, but surely makes it hard to change the
> trajectory.  (This is, of course, just my personal opinion.)
>
> > If they should really be done now, we should also fix a lot of other
> > things.  For example, the Num hierarchy, the Functor/Applicative/Monad
> > hierarchy, the fact that there exist Alternative and MonadPlus although we
> > have Monoid, the fact that we cannot have contexts like (forall a. Monoid
> > (m a)) which is the source for the last problem, the fact that we don’t
> > have class aliases, ugly names like fmap and mappend, etc.
>
> As Lennart and Ganesh have argued, the amount of breaking changes that
> we we will be able to fit in without causing serious problems is
> limited.
>
> Manuel

Hello again (after a long time),

the things I proposed above are mostly library changes which could mostly be 
made non-disruptive if we had class aliases.  Would this make them acceptable 
for you?

Best wishes,
Wolfgang
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Johan Tibell]

On Mon, Apr 28, 2008 at 6:56 PM, Simon Marlow <[EMAIL PROTECTED]> wrote:
>  So I suggest we reject the proposal, and move any further discussion to
> haskell-cafe.  Ok?

Sounds good to me.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Simon Marlow]

Manuel M T Chakravarty wrote:

Lennart Augustsson:
So I still think changing $ is insane.  Why change?  If you want a new 
operator, make a new one.  Don't make a gratuitous change that will 
waste countless man hours.  For me it's a simple decision, if $ 
changes I cannot use Haskell'.  :(


Given that people can't even agree whether it makes sense to change $ at 
all, this is IMHO far away from a change that justifies breaking any code.


So I suggest we reject the proposal, and move any further discussion to 
 haskell-cafe.  Ok?


Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Manuel M T Chakravarty]

Lennart Augustsson:
Haskell has now reached the point where backwards compatibility is  
something that must be taken very seriously.
The motivation behind Haskell' was to bring the most common  
extensions into the standard, it was all going to be done in a year.
Haskell' is not a new language, but growing Haskell98 with common  
extension.
If there's something in Haskell' that will require a change every  
1000 lines, then I think it's acceptable.
If there's something in Haskell' that will require changing every  
other line, then it's not acceptable.  The existing Haskell codes  
bases are simply too big.


I completely agree.

So I still think changing $ is insane.  Why change?  If you want a  
new operator, make a new one.  Don't make a gratuitous change that  
will waste countless man hours.  For me it's a simple decision, if $  
changes I cannot use Haskell'.  :(


Given that people can't even agree whether it makes sense to change $  
at all, this is IMHO far away from a change that justifies breaking  
any code.


Manuel

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Manuel M T Chakravarty]

Wolfgang Jeltsch:

Am Donnerstag, 24. April 2008 05:13 schrieb Manuel M T Chakravarty:

[…]



Hence, anything that is *important* to change, we should change now.


Although I can follow your arguments, I thought that the large and  
disruptive

changes should be done for Haskell 2.


Depends what you mean by Haskell 2.  If it is an experimental language  
that shares some superficial similarities with Haskell, sure we may  
have Haskell 2.  If you mean a serious successor of Haskell with the  
expectation that many/most Haskell users will eventually move to  
Haskell 2, then no.  Haskell has been gaining a lot of momentum  
recently.  That's good and bad, but surely makes it hard to change the  
trajectory.  (This is, of course, just my personal opinion.)



 If they should really be done now, we
should also fix a lot of other things.  For example, the Num  
hierarchy, the
Functor/Applicative/Monad hierarchy, the fact that there exist  
Alternative
and MonadPlus although we have Monoid, the fact that we cannot have  
contexts
like (forall a. Monoid (m a)) which is the source for the last  
problem, the
fact that we don’t have class aliases, ugly names like fmap and  
mappend, etc.


As Lennart and Ganesh have argued, the amount of breaking changes that  
we we will be able to fit in without causing serious problems is  
limited.


Manuel

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Manuel M T Chakravarty]

Sittampalam, Ganesh:

Manuel Chakravarty wrote:

We should be careful about where we break existing code, and
we should try to support automatic translation of H98 to H' code,
but any changes that we do not make now will become even more
difficult in the future when there is even more Haskell code.
Look at what is happening now already, industrial users applying
pressure on the committee to not change the language too much
for the sake of legacy code.  A clear indication that anything
we don't change now, we will have to live with forever.


I wasn't arguing for special treatment as an "industrial" user,
just listing one datapoint that I have to counter any impression
that the only or main cost to the community as a whole is fixing
what's on hackage.


I agree with that.  However, maybe somewhat paradoxically, I think,  
given the resistance that changes to the language already invoke now,  
we should actually be fairly aggressive with changes this one time  
(ie, in Haskell').



Hence, anything that is *important* to change, we should change now.


Agreed. It's just in this case the pain of changing will be huge and
the benefits marginal at best.


Yes, I was not arguing for that particular change, my comment was of a  
general nature.



We should mitigate the pain by having a H98 to H' translator


Such a translator would have to maintain existing layout etc, and
produce reasonably nice looking code in places where it makes changes.
Do we have any infrastructure that would make writing one easy?


For H98, simple[1] changes might be possible with haskell-src if it  
would be modified to be able to preserve comments and layout.


Manuel

[1] For example, purely syntactic ones.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[David Menendez]

On Wed, Apr 23, 2008 at 6:21 PM, Niklas Broberg
<[EMAIL PROTECTED]> wrote:
> > I'm very suspicious about the power/weight ratio of this change.
>  >  Normally, for simple value-level stuff like this, provide both options:
>  >
>  > mapM / forM. =<< >>=
>  >
>  >  So how about, rather than break things, just provide an alternative to 
> ($).
>
>  Alright, I'm not sure what the proper channel for doing this is, but I
>  reckon here is as good as anywhere. I would like to propose that the
>  Haskell' Prelude includes the function
>
>  f $$ x = f x
>
>  with the same fixity level as $ (presumably 0) but being left
>  associative instead. And that $ is left as is.

It's a pity that @ isn't available for use as an operator. I've seen
it used to represent application in a few places, and its resemblance
to an "a" is a handy mnemonic. Is & still free?

-- 
Dave Menendez <[EMAIL PROTECTED]>

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Lennart Augustsson]

Haskell 2 (whatever it is), does not have the goals that were stated for
Haskell', so I can accept disruptive changes.

Haskell' has (had?) some very clear goals, and breaking every existing
program was not one of them.

On Thu, Apr 24, 2008 at 8:41 PM, Wolfgang Jeltsch <
[EMAIL PROTECTED]> wrote:

> Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson:
> > Haskell has now reached the point where backwards compatibility is
> something
> > that must be taken very seriously.
>
> Would you be opposed to a Haskell 2 which would break lots of things?
>
> > […]
>
> Best wishes,
> Wolfgang
> ___
> Haskell-prime mailing list
> Haskell-prime@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Johan Tibell]

On Thu, Apr 24, 2008 at 3:41 PM, Wolfgang Jeltsch
<[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson:
>
> > Haskell has now reached the point where backwards compatibility is something
>  > that must be taken very seriously.
>
>  Would you be opposed to a Haskell 2 which would break lots of things?

I would! No new language standard should break lots of things! It
could break some things and should provide easy rewrite rules for code
(or better yet a tool like Python's 2to3) to move from standard A to
standard B for most of the things that break.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[John Meacham]

On Thu, Apr 24, 2008 at 09:38:22PM +0200, Wolfgang Jeltsch wrote:
> Am Donnerstag, 24. April 2008 00:43 schrieb Ian Lynagh:
> > […]
> 
> > Please see
> > http://www.haskell.org/haskellwiki/Library_submissions
> >
> > > f $$ x = f x
> >
> > Note that this clashes with Text.PrettyPrint
> 
> I also doesn’t correspond to $!.  We should introduce $$! then.

I don't think either of these are necessary and eat up valuable
operator-space. 

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Wolfgang Jeltsch]

Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson:
> Haskell has now reached the point where backwards compatibility is something
> that must be taken very seriously.

Would you be opposed to a Haskell 2 which would break lots of things? 

> […]

Best wishes,
Wolfgang
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Wolfgang Jeltsch]

Am Donnerstag, 24. April 2008 00:43 schrieb Ian Lynagh:
> […]

> Please see
> http://www.haskell.org/haskellwiki/Library_submissions
>
> > f $$ x = f x
>
> Note that this clashes with Text.PrettyPrint

I also doesn’t correspond to $!.  We should introduce $$! then.

> […]

Best wishes,
Wolfgang
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Wolfgang Jeltsch]

Am Donnerstag, 24. April 2008 05:13 schrieb Manuel M T Chakravarty:
> […]

> Hence, anything that is *important* to change, we should change now.

Although I can follow your arguments, I thought that the large and disruptive 
changes should be done for Haskell 2.  If they should really be done now, we 
should also fix a lot of other things.  For example, the Num hierarchy, the 
Functor/Applicative/Monad hierarchy, the fact that there exist Alternative 
and MonadPlus although we have Monoid, the fact that we cannot have contexts 
like (forall a. Monoid (m a)) which is the source for the last problem, the 
fact that we don’t have class aliases, ugly names like fmap and mappend, etc.

> […]

> Manuel

Best wishes,
Wolfgang
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Wolfgang Jeltsch]

Am Mittwoch, 23. April 2008 10:06 schrieb Cale Gibbard:
> […]

> I believe that migrating code will be quite a task regardless of the
> outcome here, but at least for the packages that are in Hackage, the
> system helpfully reports build failures, so we'll know where the
> breakages are, and roughly what's left to be done.

Why not writing a tool which replaces all occurences of a $ b $ c $ d by
a . b . c $ d?

>  - Cale

Best wishes,
Wolfgang
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Wolfgang Jeltsch]

Am Mittwoch, 23. April 2008 09:58 schrieb Bulat Ziganshin:
> […]

> my main point is that considering space-less operators as having
> larger priority is our natural habit.

Really???  I‘ve never heard of people using spaceless operators for stating 
precedence before.  And it contradicts nice typesetting.  In my opinion, an 
operator needs space around it, otherwise it looks ugly.  And I don’t want to 
have lhs2TeX-typeset source code where infix operators sometimes have the 
nice TeX spacing and sometimes are not surrounded by spaces at all.

> […]

Best wishes,
Wolfgang
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Cale Gibbard]

2008/4/24 Wolfgang Jeltsch <[EMAIL PROTECTED]>:
> Am Mittwoch, 23. April 2008 01:20 schrieb Duncan Coutts:
>  > […]
>
>
>  > Surely there was a justification to having $ be the opposite
>  > associativity from application and not just a different precedence. Does
>  > anyone know what it was?
>
>  Probably the fact that you can write
>
>  > f $ g $ h $ u $ v $ w $ x
>
>  instead of
>
>  > f (g (h (u (v (w x)
>
>  and thereby avoid building forests of parantheses.
>
But of course, f . g . h . u . v . w $ x means the same thing, and has
nicer properties with regard to refactoring and formal reasoning due
to the associativity of (.), so probably not a whole lot of thought
went into the choice.

 - Cale
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Wolfgang Jeltsch]

Am Mittwoch, 23. April 2008 01:20 schrieb Duncan Coutts:
> […]

> Surely there was a justification to having $ be the opposite
> associativity from application and not just a different precedence. Does
> anyone know what it was?

Probably the fact that you can write

> f $ g $ h $ u $ v $ w $ x

instead of

> f (g (h (u (v (w x)

and thereby avoid building forests of parantheses.

> Duncan

Best wishes,
Wolfgang
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Steven Hazel]

On Wed, Apr 23, 2008 at 8:13 PM, Manuel M T Chakravarty
<[EMAIL PROTECTED]> wrote:
> We should be careful about where we break existing code, and we should try to 
> support automatic translation of H98 to H' code, but any changes that we do 
> not make now will become even more difficult in the future when there is even 
> more Haskell code.  Look at what is happening now already, industrial users 
> applying pressure on the committee to not change the language too much for 
> the sake of legacy code.  A clear indication that anything we don't change 
> now, we will have to live with forever.
>
> Hence, anything that is *important* to change, we should change now.  We 
> should mitigate the pain by having a H98 to H' translator and Haskell 
> compilers will surely support a Haskell98 compatibility mode as long as there 
> are enough users interested in such a feature.  (This is not unlike the 
> transition from K&R C to ANSI C.)

For ($), automatic translation could be as simple as changing a couple
module imports:
import Prelude hiding (($))
import Haskell98 (($))

-- 
Steven Hazel
[EMAIL PROTECTED]
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Sittampalam, Ganesh]

Manuel Chakravarty wrote:

> Care for legacy code is important, but H' will have to break 
> backwards compatibility in some places.  And especially where 
> you already rely on GHC extensions, you can't really expect 
> that H' will adopt features that have been available as GHC
> extensions in exactly the form that they were implemented in GHC.

Agreed. I was just motivating why we would want to upgrade code,
not arguing that we should be able to do that with no pain at all.

> We should be careful about where we break existing code, and 
> we should try to support automatic translation of H98 to H' code, 
> but any changes that we do not make now will become even more 
> difficult in the future when there is even more Haskell code.  
> Look at what is happening now already, industrial users applying 
> pressure on the committee to not change the language too much 
> for the sake of legacy code.  A clear indication that anything 
> we don't change now, we will have to live with forever.

I wasn't arguing for special treatment as an "industrial" user,
just listing one datapoint that I have to counter any impression
that the only or main cost to the community as a whole is fixing
what's on hackage.

> Hence, anything that is *important* to change, we should change now.


Agreed. It's just in this case the pain of changing will be huge and
the benefits marginal at best.

> We should mitigate the pain by having a H98 to H' translator

Such a translator would have to maintain existing layout etc, and
produce reasonably nice looking code in places where it makes changes.
Do we have any infrastructure that would make writing one easy?

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Adam Sampson]

Simon Marlow <[EMAIL PROTECTED]> writes:

>   * add ""Make $ left associative, like application"

I'm an end user of Haskell rather than an FP researcher, and I'm very
strongly against this change because I don't think of $ as being
function application; I think of it as the "brackets from here to the
end of the expression" operator. I've always assumed that it was
defined with the associativity it currently has in order to support
that use.

As it stands, it's one of my favourite features of Haskell. I find it
particularly useful when constructing nested data structures; at the
moment, it's very easy to write something like:

  Seq m $ Spec m var $ Only $ ProcCall m name args

In that case, $ clearly has the same meaning each time. If I put
something like that on a slide, I can explain the meaning of $ in a
few seconds, even to an audience who aren't familiar with functional
programming or Haskell. Forcing me to change the first two to . would
make the code harder to write, harder to understand, and harder to
explain.

If people want a left-associative application operator, then it ought
to be a new operator; please don't change the existing one.

-- 
Adam Sampson <[EMAIL PROTECTED]> 
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Lennart Augustsson]

Haskell has now reached the point where backwards compatibility is something
that must be taken very seriously.
The motivation behind Haskell' was to bring the most common extensions into
the standard, it was all going to be done in a year.
Haskell' is not a new language, but growing Haskell98 with common extension.
If there's something in Haskell' that will require a change every 1000
lines, then I think it's acceptable.
If there's something in Haskell' that will require changing every other
line, then it's not acceptable.  The existing Haskell codes bases are simply
too big.

So I still think changing $ is insane.  Why change?  If you want a new
operator, make a new one.  Don't make a gratuitous change that will waste
countless man hours.  For me it's a simple decision, if $ changes I cannot
use Haskell'.  :(

  -- Lennart

On Wed, Apr 23, 2008 at 9:42 PM, Niklas Broberg <[EMAIL PROTECTED]>
wrote:

> When I first saw this thread, my gut response was "Aw gawds no, don't
> touch my $ !!" I love $, I use it all the time, it really helps making
> code more readable and more nicely structured. I would really hate for
> someone to take that away from me.
>
> So when I came across this:
>
> >  > This wouldn't work, you'd have to rewrite it as:
> >
> >  > withSomeResource foo .
> >  >   withSomeOtherThing bar .
> >  > yetAnotherBlockStructured thing $ ...
> >
> >
> > it is very inconvenient - we should use either . or $ depending on
> >  that it's last block or not. imagine all the changes when editing the
> >  code
>
> ... my initial response to it was yeah, Bulat is right, that's rather
> inconsistent, and it would mean a lot of changes when editing (and
> it's ugly too!).
>
> But then I started questioning my own motives. What changes would that
> be? Changing a . to a $ if I decided to remove the previous last piece
> of the "pipeline"? Doesn't seem too hairy, and I have to do far worse
> than that already when refactoring. Inconsistent? Doesn't it actually
> make perfect sense that the actual application of the "pipeline" of
> functions to some value is handled differently? Like Cale said,
> wouldn't it actually be a Good Thing that we treated these things as
> composition chains instead of application chains? And I could no
> longer defend my own position, and so I started thinking for real.
>
> Refactoring doesn't become harder with this suggestion - it becomes
> easier in general, just as Dan points out in #1. And I know I've been
> bitten by his #2 a bunch of times, even if I haven't realized the
> source of the problem until I read this thread. It's messy having to
> use a lot of parenthesis just because some argument to a function
> isn't the last one, and I've found myself wishing for a way to get rid
> of them. I know I have at times refactored my function definitions,
> switching their arguments around just to get the one that would need
> the parenthesis to be the last one.
>
> So I dug through some of my code, picking large modules at random. As
> I said I use $ *a lot*, anywhere that I can get away with it. In the
> first 10 modules I looked at, I found one (1) place where I would need
> to change a $ to a . to make it work. So I went to look at a bigger
> module, and in what is possibly my largest self-contained module (1800
> loc including comments) I had 211 uses of $, and I would have had to
> change 23 of them into . instead to make it work with a
> left-associative version. All the ones where the left operand is just
> a function (like return) will still work. All the ones that are
> followed by a '\x -> ...' will still work. All the ones followed by a
> 'do ...' will still work. On the other hand, I found 10 places where I
> could immediately have gotten rid of some extra parentheses, and that
> just by searching for uses of fmap in the code!
>
> It should be said though that changing the associativity of $ doesn't
> make all code nice and clean. Consider for instance
>
> f (g (h x)) (k y)
>
> We could change that into one of
>
> f $ g (h x) $ k y
> f (g $ h x) $ k y
>
> but not get rid of the parenthesis altogether, i.e. uses of $ for
> different applications won't mix. But with right-associative $, the
> second one would be our only option, so at least we're no worse off
> than before, and perhaps it could be argued we are better off (in this
> kind of situation).
>
>
> I think it is reasonable to look closely at the motivations for
> wanting to retain the $ as is. Looking through this thread, I can find
> only a single complaint raised (albeit an important one), namely
> backwards compatibility. Yes, such a change would likely break quite a
> few my modules. But like Cale, I would never have expected H' to be
> fully backwards compatible with H98, and thus there would have to be
> some way to migrate anyway. This one seems pretty simple, just let the
> old Prelude be Haskell98.Prelude and import that in old code. Of
> course changes that break backwards compatibility sh

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Manuel M T Chakravarty]

Sittampalam, Ganesh:

Aaron Denney wrote:

On 2008-04-23, Sittampalam, Ganesh

<[EMAIL PROTECTED]> wrote:

There's plenty of code out there that doesn't have the benefit of a
vigilant user community ready to spring into action. For example,
Credit Suisse has several tens of thousands of lines of code written



by internal users who are not Haskell experts, and it would be

rather

hard to explain to them that they needed to go through it all and

fix

it.



What makes them need to update to Haskell' instead of sticking with

Haskell '98?

(a) the fact that the code already uses several GHC extensions that  
will

be in Haskell' and we would like to be closer to standard code
(b) the expectation that at some point implementations will stop
supporting
H98


Care for legacy code is important, but H' will have to break backwards  
compatibility in some places.  And especially where you already rely  
on GHC extensions, you can't really expect that H' will adopt features  
that have been available as GHC extensions in exactly the form that  
they were implemented in GHC.


We should be careful about where we break existing code, and we should  
try to support automatic translation of H98 to H' code, but any  
changes that we do not make now will become even more difficult in the  
future when there is even more Haskell code.  Look at what is  
happening now already, industrial users applying pressure on the  
committee to not change the language too much for the sake of legacy  
code.  A clear indication that anything we don't change now, we will  
have to live with forever.


Hence, anything that is *important* to change, we should change now.   
We should mitigate the pain by having a H98 to H' translator and  
Haskell compilers will surely support a Haskell98 compatibility mode  
as long as there are enough users interested in such a feature.  (This  
is not unlike the transition from K&R C to ANSI C.)


Manuel

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Manuel M T Chakravarty]

Lennart Augustsson:
I my opinion, anyone who suggest changing the associativity of $ is  
insane.
Or just hating every Haskell user.  Changing $ would make virtually  
every Haskell program uncompilable.


Just pick some other (Unicode?) operator, but leave $ alone.


I agree that the power/weight ratio for changing the associativity of  
$ is not convincing at all.[1]  Like the choice of (.) for function  
composition, it is something that Haskell will have to live with,  
forever.


Nevertheless, I think unicode for standard operators is also a no-go  
for Haskell'.  We discussed this on the committee list, and really,  
tool support for unicode is still very poor.  Even cut-copy-paste of  
unicode text between different apps on MacOS -which seems to support  
unicode comparatively well- often doesn't work.  Some applications,  
such as X11 for MacOS, don't seem to support unicode at all.  The  
situation on Linux is even worse.  Moreover, it is often difficult and  
definitely not uniform across platforms how to enter unicode characters.


Manuel

[1] Don't get me wrong, I also stumbled over the associativity of $  
before and I agree that it should be different.  I just don't think  
the gain is worth the hassle.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Chris Smith]

On Thu, 24 Apr 2008 01:43:36 +0100, Sittampalam, Ganesh wrote:
> Is there not a general expectation when a new language standard comes
> out that
> people will migrate to it (perhaps over time)?

I would hope so.  There's no chance that Haskell 98 would continue to be 
maintained with bug fixes and the like indefinitely into the future.  
It's a but futile, then, to suppose people can avoid Haskell' entirely 
for old code.

-- 
Chris

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Sittampalam, Ganesh]

Aaron Denney wrote:

> On 2008-04-23, Sittampalam, Ganesh
<[EMAIL PROTECTED]> wrote:
> > There's plenty of code out there that doesn't have the benefit of a 
> > vigilant user community ready to spring into action. For example, 
> > Credit Suisse has several tens of thousands of lines of code written

> > by internal users who are not Haskell experts, and it would be
rather 
> > hard to explain to them that they needed to go through it all and
fix 
> > it.

> What makes them need to update to Haskell' instead of sticking with
Haskell '98?

(a) the fact that the code already uses several GHC extensions that will
be in Haskell' and we would like to be closer to standard code
(b) the expectation that at some point implementations will stop
supporting
H98

Is there not a general expectation when a new language standard comes
out that
people will migrate to it (perhaps over time)?

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Dan Weston]

John Meacham wrote:

On Wed, Apr 23, 2008 at 09:52:11AM -0700, Simon Marlow wrote:

The problem with this is that

  f !x y

would associate differently in an expression than it does on the left hand 
side of an equation, where ! is the prefix bang-pattern operator. To make 
this consistent we'd have to make ! a prefix operator in expressions, or 
give it the same precedence as function application; both mean a new 
extension.


Hmm.. that is another possible solution to the ~ ! - thing, have ~ and !
be prefix operators in general. with ~ meaning 'negate' in expressions.
then parsing is the same everywhere.


Do prefix operators bind more or less tightly than infix operators? 
Either way, one of the two expressions (~2^3) or (~y$z) will parse 
somewhat unintuitively.


I would expect these to mean ~(2^3) and (~y) $ z respectively.

Dan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[John Meacham]

On Wed, Apr 23, 2008 at 09:52:11AM -0700, Simon Marlow wrote:
> The problem with this is that
>
>   f !x y
>
> would associate differently in an expression than it does on the left hand 
> side of an equation, where ! is the prefix bang-pattern operator. To make 
> this consistent we'd have to make ! a prefix operator in expressions, or 
> give it the same precedence as function application; both mean a new 
> extension.

Hmm.. that is another possible solution to the ~ ! - thing, have ~ and !
be prefix operators in general. with ~ meaning 'negate' in expressions.
then parsing is the same everywhere.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Jason McCarty]

Niklas Broberg wrote:
> ...
> It should be said though that changing the associativity of $ doesn't
> make all code nice and clean. Consider for instance
> 
> f (g (h x)) (k y)
> 
> We could change that into one of
> 
> f $ g (h x) $ k y
> f (g $ h x) $ k y
> 

If $ is left-associative, then

f (g (h x)) (k y) = (f . g . h $ x) (k y)
  = (f . g . h $ x) $ k y
  = f . g . h $ x $ k y

But perhaps composing a curried function this way is unintuitive.

-- 
Jason McCarty <[EMAIL PROTECTED]>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Ian Lynagh]

On Thu, Apr 24, 2008 at 12:21:26AM +0200, Niklas Broberg wrote:
> > I'm very suspicious about the power/weight ratio of this change.
> >  Normally, for simple value-level stuff like this, provide both options:
> >
> > mapM / forM. =<< >>=
> >
> >  So how about, rather than break things, just provide an alternative to ($).
> 
> Alright, I'm not sure what the proper channel for doing this is,

Please see
http://www.haskell.org/haskellwiki/Library_submissions

> f $$ x = f x

Note that this clashes with Text.PrettyPrint (which doesn't necessarily
mean it shouldn't be used anyway).


Thanks
Ian

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Sterling Clover]

I think there are some very valid concerns about this proposal, but  
just to add a small datapoint -- the associativity of $ was somewhat  
painful and counterintuitive to me when I was first learning Haskell,  
and the associativity of $! doubly so.


Code breakage issues aside, this seems very much the "right thing" to  
do. Haskell will *necessarily evolve* in a backwards-incompatible way  
at some point, with the move from Functional Dependencies. And  
meanwhile, changes to things such as the ByteString API have been  
taking place and causing breakage now for some time (although  
hopefully we've seen about the last of that). So the bigger issue  
seems to be -- if not Haskell', then when, precisely should a number  
of other issues with the core libraries be addressed, or should we  
let some things stay set in stone, even while other compatibility- 
breaking changes occur all around them?


--S

On Apr 23, 2008, at 4:42 PM, Niklas Broberg wrote:

When I first saw this thread, my gut response was "Aw gawds no, don't
touch my $ !!" I love $, I use it all the time, it really helps making
code more readable and more nicely structured. I would really hate for
someone to take that away from me.

So when I came across this:


This wouldn't work, you'd have to rewrite it as:



withSomeResource foo .
  withSomeOtherThing bar .
yetAnotherBlockStructured thing $ ...



it is very inconvenient - we should use either . or $ depending on
 that it's last block or not. imagine all the changes when editing  
the

 code


... my initial response to it was yeah, Bulat is right, that's rather
inconsistent, and it would mean a lot of changes when editing (and
it's ugly too!).

But then I started questioning my own motives. What changes would that
be? Changing a . to a $ if I decided to remove the previous last piece
of the "pipeline"? Doesn't seem too hairy, and I have to do far worse
than that already when refactoring. Inconsistent? Doesn't it actually
make perfect sense that the actual application of the "pipeline" of
functions to some value is handled differently? Like Cale said,
wouldn't it actually be a Good Thing that we treated these things as
composition chains instead of application chains? And I could no
longer defend my own position, and so I started thinking for real.

Refactoring doesn't become harder with this suggestion - it becomes
easier in general, just as Dan points out in #1. And I know I've been
bitten by his #2 a bunch of times, even if I haven't realized the
source of the problem until I read this thread. It's messy having to
use a lot of parenthesis just because some argument to a function
isn't the last one, and I've found myself wishing for a way to get rid
of them. I know I have at times refactored my function definitions,
switching their arguments around just to get the one that would need
the parenthesis to be the last one.

So I dug through some of my code, picking large modules at random. As
I said I use $ *a lot*, anywhere that I can get away with it. In the
first 10 modules I looked at, I found one (1) place where I would need
to change a $ to a . to make it work. So I went to look at a bigger
module, and in what is possibly my largest self-contained module (1800
loc including comments) I had 211 uses of $, and I would have had to
change 23 of them into . instead to make it work with a
left-associative version. All the ones where the left operand is just
a function (like return) will still work. All the ones that are
followed by a '\x -> ...' will still work. All the ones followed by a
'do ...' will still work. On the other hand, I found 10 places where I
could immediately have gotten rid of some extra parentheses, and that
just by searching for uses of fmap in the code!

It should be said though that changing the associativity of $ doesn't
make all code nice and clean. Consider for instance

f (g (h x)) (k y)

We could change that into one of

f $ g (h x) $ k y
f (g $ h x) $ k y

but not get rid of the parenthesis altogether, i.e. uses of $ for
different applications won't mix. But with right-associative $, the
second one would be our only option, so at least we're no worse off
than before, and perhaps it could be argued we are better off (in this
kind of situation).


I think it is reasonable to look closely at the motivations for
wanting to retain the $ as is. Looking through this thread, I can find
only a single complaint raised (albeit an important one), namely
backwards compatibility. Yes, such a change would likely break quite a
few my modules. But like Cale, I would never have expected H' to be
fully backwards compatible with H98, and thus there would have to be
some way to migrate anyway. This one seems pretty simple, just let the
old Prelude be Haskell98.Prelude and import that in old code. Of
course changes that break backwards compatibility should not be made
frivolously, but I find it hard to buy having only that as an argument
for a change that otherwise 

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Niklas Broberg]

> I'm very suspicious about the power/weight ratio of this change.
>  Normally, for simple value-level stuff like this, provide both options:
>
> mapM / forM. =<< >>=
>
>  So how about, rather than break things, just provide an alternative to ($).

Alright, I'm not sure what the proper channel for doing this is, but I
reckon here is as good as anywhere. I would like to propose that the
Haskell' Prelude includes the function

f $$ x = f x

with the same fixity level as $ (presumably 0) but being left
associative instead. And that $ is left as is.

Cheers,

/Niklas
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Neil Mitchell]

Hi

>  How many research papers have you seen which use chained ($)
>  applications? I can't recall a single one.

You should read my papers! :-)

http://www-users.cs.york.ac.uk/~ndm/downloads/paper-uniform_boilerplate_and_list_processing-30_sep_2007.pdf
- section 4.1, being just the first one I picked off the pile. Haskell
Workshop 2007.

Thanks

Neil
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Don Stewart]

ndmitchell:
> Hi
> 
> >  I think it is reasonable to look closely at the motivations for
> >  wanting to retain the $ as is. Looking through this thread, I can find
> >  only a single complaint raised (albeit an important one), namely
> >  backwards compatibility. Yes, such a change would likely break quite a
> >  few my modules. But like Cale, I would never have expected H' to be
> >  fully backwards compatible with H98, and thus there would have to be
> >  some way to migrate anyway. This one seems pretty simple, just let the
> >  old Prelude be Haskell98.Prelude and import that in old code. Of
> >  course changes that break backwards compatibility should not be made
> >  frivolously, but I find it hard to buy having only that as an argument
> >  for a change that otherwise seems highly reasonable.
> 
> I don't want to have to do a brain mode-change between "in a
> Haskell98.Prelude" module and "in a Prelude" module. I don't want to
> copy code between modules and have it do different things.
> 
> We also should remember that a large number of academic papers are
> written in Haskell, and unlike libraries, don't get "update releases"
> made. This is not a minor tweak - it will break a massive number of
> programs.
> 
> >  ps. Though to be honest I really don't see why we don't simply add
> >  another operator instead of changing an existing one... :-)
> 
> (£) anyone?* This seems a massively more sensible idea.


I'm very suspicious about the power/weight ratio of this change.
Normally, for simple value-level stuff like this, provide both options:

mapM / forM. =<< >>=

So how about, rather than break things, just provide an alternative to ($).

-- Don
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Cale Gibbard]

2008/4/23 Neil Mitchell <[EMAIL PROTECTED]>:
>  We also should remember that a large number of academic papers are
>  written in Haskell, and unlike libraries, don't get "update releases"
>  made. This is not a minor tweak - it will break a massive number of
>  programs.

How many research papers have you seen which use chained ($)
applications? I can't recall a single one.

 - Cale
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Neil Mitchell]

Hi

>  I think it is reasonable to look closely at the motivations for
>  wanting to retain the $ as is. Looking through this thread, I can find
>  only a single complaint raised (albeit an important one), namely
>  backwards compatibility. Yes, such a change would likely break quite a
>  few my modules. But like Cale, I would never have expected H' to be
>  fully backwards compatible with H98, and thus there would have to be
>  some way to migrate anyway. This one seems pretty simple, just let the
>  old Prelude be Haskell98.Prelude and import that in old code. Of
>  course changes that break backwards compatibility should not be made
>  frivolously, but I find it hard to buy having only that as an argument
>  for a change that otherwise seems highly reasonable.

I don't want to have to do a brain mode-change between "in a
Haskell98.Prelude" module and "in a Prelude" module. I don't want to
copy code between modules and have it do different things.

We also should remember that a large number of academic papers are
written in Haskell, and unlike libraries, don't get "update releases"
made. This is not a minor tweak - it will break a massive number of
programs.

>  ps. Though to be honest I really don't see why we don't simply add
>  another operator instead of changing an existing one... :-)

(£) anyone?* This seems a massively more sensible idea.

Thanks

Neil

* I appreciate that a lot of non-English users might find it a bit
difficult to hit this key!
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Dan Doel]

On Wednesday 23 April 2008, Bulat Ziganshin wrote:
> it's not refactoring! it's just adding more features - exception
> handler, progress indicator, memory pool and so on. actually, code
> blocks used as a sort of RAII for Haskell. are you wanna change all
> those ';' when you add new variable to your C++ code?
>
>   bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $
> \(archive,footer) -> do bad_crcs <- withList $ \bad_crcs -> do
>   doChunks arcsize sector_size $ \bytes -> do
> uiWithProgressIndicator command arcsize $ do
> or
> handleCtrlBreak  (ignoreErrors$ fileRemove arcname_fixed) $ do
> bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $
> \new_archive -> do withJIT (fileOpen =<< originalURL originalName arcname)
> fileClose $ \original' -> do
>
> is just two examples from my code

For what it's worth, both of these examples require no change.

However, with left-associative ($), you're free to change them to (sorry for 
the additional lines, but my mail client breaks at 80 characters. I think 
they're still valid code):


bracketCtrlBreak $ archiveReadFooter command arcname
 $ archiveClose.fst
 $ \(archive,footer) -> do
  bad_crcs <- withList $ \bad_crcs -> do
doChunks arcsize sector_size $ \bytes -> do
  uiWithProgressIndicator command arcsize $ do

handleCtrlBreak $ ignoreErrors (fileRemove arcname_fixed) $ do
bracketCtrlBreak $ archiveCreateRW arcname_fixed $ archiveClosed 
 $ \new_archive -> do
withJIT $ fileOpen =<< originalURL originalName arcname $ fileClose
$ \original' -> do

Or, for a simpler example I discovered earlier, you can write:

catchError $ do return 1
throwError $ strError "foo"
   $ \e -> return 2

Although I'm not sure how much better that is than the alternative:

do return 1
   throwError $ strError "foo"
`catchError`
\e -> return 2

-- Dan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Niklas Broberg]

> it's not refactoring! it's just adding more features - exception
>  handler, progress indicator, memory pool and so on. actually, code
>  blocks used as a sort of RAII for Haskell. are you wanna change all
>  those ';' when you add new variable to your C++ code?
>
>   bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $ 
> \(archive,footer) -> do
> bad_crcs <- withList $ \bad_crcs -> do
>   doChunks arcsize sector_size $ \bytes -> do
> uiWithProgressIndicator command arcsize $ do
>  or
> handleCtrlBreak  (ignoreErrors$ fileRemove arcname_fixed) $ do
> bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $ 
> \new_archive -> do
> withJIT (fileOpen =<< originalURL originalName arcname) fileClose $ 
> \original' -> do
>
>  is just two examples from my code

... and neither of those examples would be broken by changing the
associativity of $. If that kind of code had been broken, I would have
complained too. So what was your point again? ;-)

Cheers,

/Niklas
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Bulat Ziganshin]

Hello Niklas,

Thursday, April 24, 2008, 12:42:02 AM, you wrote:

> But then I started questioning my own motives. What changes would that
> be? Changing a . to a $ if I decided to remove the previous last piece
> of the "pipeline"? Doesn't seem too hairy, and I have to do far worse
> than that already when refactoring.

it's not refactoring! it's just adding more features - exception
handler, progress indicator, memory pool and so on. actually, code
blocks used as a sort of RAII for Haskell. are you wanna change all
those ';' when you add new variable to your C++ code?

  bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $ 
\(archive,footer) -> do
bad_crcs <- withList $ \bad_crcs -> do
  doChunks arcsize sector_size $ \bytes -> do
uiWithProgressIndicator command arcsize $ do
or
handleCtrlBreak  (ignoreErrors$ fileRemove arcname_fixed) $ do
bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $ 
\new_archive -> do
withJIT (fileOpen =<< originalURL originalName arcname) fileClose $ 
\original' -> do

is just two examples from my code

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Aaron Denney]

On 2008-04-23, Sittampalam, Ganesh <[EMAIL PROTECTED]> wrote:
> There's plenty of code out there that doesn't have the benefit
> of a vigilant user community ready to spring into action. For
> example, Credit Suisse has several tens of thousands of lines of 
> code written by internal users who are not Haskell experts, and
> it would be rather hard to explain to them that they needed to 
> go through it all and fix it.

What makes them need to update to Haskell' instead of sticking with
Haskell '98?

-- 
Aaron Denney
-><-

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Niklas Broberg]

When I first saw this thread, my gut response was "Aw gawds no, don't
touch my $ !!" I love $, I use it all the time, it really helps making
code more readable and more nicely structured. I would really hate for
someone to take that away from me.

So when I came across this:

>  > This wouldn't work, you'd have to rewrite it as:
>
>  > withSomeResource foo .
>  >   withSomeOtherThing bar .
>  > yetAnotherBlockStructured thing $ ...
>
>
> it is very inconvenient - we should use either . or $ depending on
>  that it's last block or not. imagine all the changes when editing the
>  code

... my initial response to it was yeah, Bulat is right, that's rather
inconsistent, and it would mean a lot of changes when editing (and
it's ugly too!).

But then I started questioning my own motives. What changes would that
be? Changing a . to a $ if I decided to remove the previous last piece
of the "pipeline"? Doesn't seem too hairy, and I have to do far worse
than that already when refactoring. Inconsistent? Doesn't it actually
make perfect sense that the actual application of the "pipeline" of
functions to some value is handled differently? Like Cale said,
wouldn't it actually be a Good Thing that we treated these things as
composition chains instead of application chains? And I could no
longer defend my own position, and so I started thinking for real.

Refactoring doesn't become harder with this suggestion - it becomes
easier in general, just as Dan points out in #1. And I know I've been
bitten by his #2 a bunch of times, even if I haven't realized the
source of the problem until I read this thread. It's messy having to
use a lot of parenthesis just because some argument to a function
isn't the last one, and I've found myself wishing for a way to get rid
of them. I know I have at times refactored my function definitions,
switching their arguments around just to get the one that would need
the parenthesis to be the last one.

So I dug through some of my code, picking large modules at random. As
I said I use $ *a lot*, anywhere that I can get away with it. In the
first 10 modules I looked at, I found one (1) place where I would need
to change a $ to a . to make it work. So I went to look at a bigger
module, and in what is possibly my largest self-contained module (1800
loc including comments) I had 211 uses of $, and I would have had to
change 23 of them into . instead to make it work with a
left-associative version. All the ones where the left operand is just
a function (like return) will still work. All the ones that are
followed by a '\x -> ...' will still work. All the ones followed by a
'do ...' will still work. On the other hand, I found 10 places where I
could immediately have gotten rid of some extra parentheses, and that
just by searching for uses of fmap in the code!

It should be said though that changing the associativity of $ doesn't
make all code nice and clean. Consider for instance

f (g (h x)) (k y)

We could change that into one of

f $ g (h x) $ k y
f (g $ h x) $ k y

but not get rid of the parenthesis altogether, i.e. uses of $ for
different applications won't mix. But with right-associative $, the
second one would be our only option, so at least we're no worse off
than before, and perhaps it could be argued we are better off (in this
kind of situation).


I think it is reasonable to look closely at the motivations for
wanting to retain the $ as is. Looking through this thread, I can find
only a single complaint raised (albeit an important one), namely
backwards compatibility. Yes, such a change would likely break quite a
few my modules. But like Cale, I would never have expected H' to be
fully backwards compatible with H98, and thus there would have to be
some way to migrate anyway. This one seems pretty simple, just let the
old Prelude be Haskell98.Prelude and import that in old code. Of
course changes that break backwards compatibility should not be made
frivolously, but I find it hard to buy having only that as an argument
for a change that otherwise seems highly reasonable.

We live in a beautiful statically typed world. If the proposed change
was such that existing code would still compile, but with a different
behavior, it would be really dangerous. That's clearly not the case
here, there's no way that code that uses $-chaining would still
compile if the associativity was changed, and any other use of $ would
still compile and work as before. The type checker is there to help
us, and it's literally a moment's work to clean up existing code to
meet these standards. (And it's even faster to import
Haskell98.Prelude if you're lazy).

So come on, give me an argument for why $ should be right-associative
instead of complaining about broken code (that I argue won't break
even half as bad as some of you would have it). Is there really no
reason at all why right-associative is to be preferred over
left-associative? And if there is, why don't we hear it? Are you truly
arguing this becaus

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Ian Lynagh]

On Wed, Apr 23, 2008 at 09:52:11AM -0700, Simon Marlow wrote:
> 
> The problem with this is that
> 
>   f !x y
> 
> would associate differently in an expression than it does on the left 
> hand side of an equation, where ! is the prefix bang-pattern operator. 
> To make this consistent we'd have to make ! a prefix operator in 
> expressions

But it's not a prefix operator in the sense that we could define it (in
a hypothetical language that allowed us to define prefix operators),
it's actually syntax, which makes it much less appealing to me.


Thanks
Ian

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Bulat Ziganshin]

Hello Lennart,

Wednesday, April 23, 2008, 11:38:50 PM, you wrote:

> Just pick some other (Unicode?) operator, but leave $ alone.

good said. i have my own version of &&/|| which i love more but they
are called &&&/|||


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Lennart Augustsson]

I my opinion, anyone who suggest changing the associativity of $ is insane.
Or just hating every Haskell user.  Changing $ would make virtually every
Haskell program uncompilable.

Just pick some other (Unicode?) operator, but leave $ alone.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[apfelmus]

Cale Gibbard wrote:

apfelmus wrote:


Unfortunately, the identity functor currently can't be overloaded,
although I think it would be unambiguous.



Unfortunately, it would be quite ambiguous -- the identity functor
overlaps with basically any other. Consider the case:

reverse . [[1,2,3],[4,5]]

which if (.) is fmap would normally mean [[3,2,1],[5,4]], but if the
identity functor is used instead would mean [[4,5],[1,2,3]].


Whoops, what I did think here? I somehow thought that the argument of 
the function applied ( reverse  in this case) would fix the functor. But 
this only works if the function is monomorphic:


  (reverse :: [[Int]] -> [[Int]]) .  [[1,2,3],[4,5]]
  (reverse :: [Int] -> [Int]) .  [[1,2,3],[4,5]]

not if it's polymorphic.


Regards,
apfelmus

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Simon Marlow]

Duncan Coutts wrote:

On Tue, 2008-04-22 at 21:02 -0400, Dan Doel wrote:

3) Left associative ($) is consistent with left associative ($!). The right 
associative version of the latter is inconvenient, because it only allows 
things to be (easily) strictly applied to the last argument of a function.


What about having ! as a left associative strict apply operator?

f !x !y !z

Isn't there already a proposal along these lines? There is certainly a
proposal to stop using ! for array indexing.


The problem with this is that

  f !x y

would associate differently in an expression than it does on the left 
hand side of an equation, where ! is the prefix bang-pattern operator. 
To make this consistent we'd have to make ! a prefix operator in 
expressions, or give it the same precedence as function application; 
both mean a new extension.


Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Simon Marlow]

Dan Doel wrote:

On Tuesday 22 April 2008, Simon Marlow wrote:

I'm hoping someone will supply some.  There seemed to be strong opinion
on #haskell that this change should be made, but it might just have been
a very vocal minority.


These are the arguments off the top of my head:


Thanks, I've put these points, and Josef's point, on the wiki:

http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity

(I should point out that I'm personally *not* in favour of this change, 
just making sure the arguments are documented)


Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Cale Gibbard]

2008/4/23 apfelmus <[EMAIL PROTECTED]>:
> Dan Doel wrote:
>
>  Note that setting (.) or ($) = fmap  subsumes function application, because
> we have
>
>   fmap :: (a -> b) -> a -> b
>
>  for the /identity functor/. In other words, the current ($) and (.) are
> just special cases of the general  fmap  . Unfortunately, the identity
> functor currently can't be overloaded, although I think it would be
> unambiguous.
>

Unfortunately, it would be quite ambiguous -- the identity functor
overlaps with basically any other. Consider the case:

reverse . [[1,2,3],[4,5]]

which if (.) is fmap would normally mean [[3,2,1],[5,4]], but if the
identity functor is used instead would mean [[4,5],[1,2,3]].

  - Cale
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[apfelmus]

Dan Doel wrote:

3) Left associative ($) is consistent with left associative ($!).

   (f $! x) y z
   ((f $! x) $! y) $! z

Left associative, these are:

   f $! x $ y $ z
   f $! x $! y $! z


Nice! Subconsciously, the fact that ($!) is currently not left 
associative has always bitten me.



In the light of Cale's plan to make (.) equivalent to  fmap , there is 
also the option to redefine ($) to mean  fmap  . This would eliminate 
the need for a special <$> for applicative functors.


Note that setting (.) or ($) = fmap  subsumes function application, 
because we have


  fmap :: (a -> b) -> a -> b

for the /identity functor/. In other words, the current ($) and (.) are 
just special cases of the general  fmap  . Unfortunately, the identity 
functor currently can't be overloaded, although I think it would be 
unambiguous.



Regards,
apfelmus

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Dan Doel]

On Wednesday 23 April 2008, Bulat Ziganshin wrote:
> Hello Dan,
>
> Wednesday, April 23, 2008, 1:42:20 PM, you wrote:
> > This wouldn't work, you'd have to rewrite it as:
> >
> > withSomeResource foo .
> >   withSomeOtherThing bar .
> > yetAnotherBlockStructured thing $ ...
>
> it is very inconvenient - we should use either . or $ depending on
> that it's last block or not. imagine all the changes when editing the
> code

Well, that may be inconvenient, but I don't know how much such block 
structured code is actually a composition of such functions. Off the top of 
my head, I'd expect most to involve lambdas or dos:

forM l $ \e -> ...
State $ \s -> ... (see also Reader, Cont, ...)
runST $ do ... (or 'flip runM arg' for most monads, I suppose)
callCC $ \k -> ... (shift)
forever $ do ...
withResource $ \r -> ...
local f $ do ...

Which still work with the flipped associativity. The one oddity I noticed 
looking at random code of mine is reset in Cont(T), which might currently be 
used like:

reset $ forM l $ \e -> ...

for inverting loops. It would have to become:

reset . forM l $ \e -> ...

Which might be a little weird (of course, in CC-delcont, that's

reset $ \p -> forM l $ \e -> ...

so it's moot there, but I suppose this affects all the functions that rely 
on 'do' to use repeated ($)s).

My code may well be abnormal, though (certainly, my infatuation with 
continuations probably is :)).

When I do have composition pipelines that don't fit on one line (like the 
initial example), I think I tend to write them like this:

pipe = foo
 . bar
 . baz
 . quux
 $ quuux

Which lets you slip new things in pretty naturally, I think.

There may be a lot of code out there that that all doesn't work for, though. I 
don't know.
-- Dan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Bulat Ziganshin]

Hello Dan,

Wednesday, April 23, 2008, 1:42:20 PM, you wrote:

> This wouldn't work, you'd have to rewrite it as:

> withSomeResource foo .
>   withSomeOtherThing bar .
> yetAnotherBlockStructured thing $ ...

it is very inconvenient - we should use either . or $ depending on
that it's last block or not. imagine all the changes when editing the
code


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Dan Doel]

On Wednesday 23 April 2008, Duncan Coutts wrote:
> withSomeResource foo $
>   withSomeOtherThing bar $
> yetAnotherBlockStructured thing $ ...
>
> Does that work?

This wouldn't work, you'd have to rewrite it as:

withSomeResource foo .
  withSomeOtherThing bar .
yetAnotherBlockStructured thing $ ...

But it seems like your second example is more likely to come up for 'with' 
type blocks:

> Or
>
> withSomeResource foo $ \x ->
>   withSomeOtherThing bar $ \y ->
> yetAnotherBlockStructured thing $ \z ->

That should work, because '\x ->' extends to the end of the expression. 
Similarly:

iWantMonadicValues $ do foo
bar
iAlsoWantMonadicStuff $ do ...

still works.

-- Dan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Duncan Coutts]

On Tue, 2008-04-22 at 16:21 -0700, Simon Marlow wrote:
> Chris Smith wrote:
> > On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote:
> >> Tue Apr 22 15:53:31 PDT 2008  Simon Marlow
> >> <[EMAIL PROTECTED]>
> >>   * add ""Make $ left associative, like application"
> > 
> > Is there a justification for this somewhere?
> 
> I'm hoping someone will supply some.  There seemed to be strong opinion 
> on #haskell that this change should be made, but it might just have been 
> a very vocal minority.

It true that (f $ g $ h $ x) might be nicer written (f . g . h $ x)

but I've always thought the point of $ is for things like

withSomeResource foo $
  withSomeOtherThing bar $
yetAnotherBlockStructured thing $ ...

Does that work?

Or

withSomeResource foo $ \x ->
  withSomeOtherThing bar $ \y ->
yetAnotherBlockStructured thing $ \z ->

Or does that case still work?

There must have been some justification for the original design or was
it just f $ g $ h $ x  ?

Duncan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Josef Svenningsson]

First I would like to remind everyone of Wadler's law of language design:
http://www.haskell.org/haskellwiki/Wadlers_Law
Having said that I'm now going to argue for yet another color for the bike shed.

I was a little surprised by the list of motivations for changing the
fixity of $ because it didn't contain the one argument I was in fact
expecting to hear.

0) $ was introduced as a combinator for function application.
Therefore we might expect that whenever we have a function application
we can stick a $ in there. But this is not the case. Consider the
following expression:
f x y
There are two applications here and if $ behaved like function
application we would be able to write:
f $ x $ y
But as it is now this expression means something completely different.
I expected this discrepancy between function application and $ to be
the major reason for changing the fixity.

That being said, this change would break a lot of my code as well and
I'm not a big fan of it.

Cheers,

Josef

On Wed, Apr 23, 2008 at 3:02 AM, Dan Doel <[EMAIL PROTECTED]> wrote:
> On Tuesday 22 April 2008, Simon Marlow wrote:
>  > I'm hoping someone will supply some.  There seemed to be strong opinion
>  > on #haskell that this change should be made, but it might just have been
>  > a very vocal minority.
>
>  These are the arguments off the top of my head:
>
>  1) Anything of the form:
>
> f $ g $ h $ x
>
>  with right associative ($) can instead be written:
>
> f . g . h $ x
>
>  where the associativity of ($) doesn't matter. It's not uncommon to want to
>  peel off the end of such a pipeline to eliminate a point. For the second
>  form, such a translation is:
>
> \x -> f . g . h $ x ==> f . g . h
>
>  However:
>
> \x -> f $ g $ h $ x ==> f $ g $ h
>
>  Is invalid, so one might argue that writing such pipelines with composition 
> is
>  a better habit to get into, as it allows easier cleanup of code in this way
>  (if you like somewhat point-free code, that is).
>
>  2) Left associative ($) allows you to eliminate more parentheses. Per #1, any
>  parentheses eliminated by right associative ($) can be eliminated by (.) and
>  a single ($). However, left associative ($) allows, for instance:
>
> f (g x) (h y) ==> f $ g x $ h y
>
>  3) Left associative ($) is consistent with left associative ($!). The right
>  associative version of the latter is inconvenient, because it only allows
>  things to be (easily) strictly applied to the last argument of a function.
>  Needing to strictly apply to other arguments gives rise to things like:
>
>(f $! x) y z
>((f $! x) $! y) $! z
>
>  Left associative, these are:
>
>f $! x $ y $ z
>f $! x $! y $! z
>
>  There may be more arguments, but those are the ones I've heard that I can
>  think of at the moment. #3 strikes me as the most likely to bite people (the
>  other two are more stylistic issues), but I suppose I don't know the relative
>  frequency of strict pipelines (f $! g $! x) versus strict applications at
>  non-final arguments.
>
>  And I suppose one has to weigh these arguments against breaking lots of code.
>
>  Cheers,
>  -- Dan
>
>
> ___
>  Haskell-prime mailing list
>  Haskell-prime@haskell.org
>  http://www.haskell.org/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Duncan Coutts]

On Tue, 2008-04-22 at 21:02 -0400, Dan Doel wrote:

> 3) Left associative ($) is consistent with left associative ($!). The right 
> associative version of the latter is inconvenient, because it only allows 
> things to be (easily) strictly applied to the last argument of a function.

What about having ! as a left associative strict apply operator?

f !x !y !z

Isn't there already a proposal along these lines? There is certainly a
proposal to stop using ! for array indexing.

Duncan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Sittampalam, Ganesh]

> I believe that migrating code will be quite a task
> regardless of the outcome here,

NonDecreasing indentation and the removal of n+k patterns are
the only accepted proposals I can see that might affect existing
code. The former is already standard practice and the latter
is unlikely to be that disruptive, as their use has been
discouraged for some time.

> but at least for 
> the packages that are in Hackage, the system helpfully 
> reports build failures, so we'll know where the breakages
> are, and roughly what's left to be done.

There's plenty of code out there that doesn't have the benefit
of a vigilant user community ready to spring into action. For
example, Credit Suisse has several tens of thousands of lines of 
code written by internal users who are not Haskell experts, and
it would be rather hard to explain to them that they needed to 
go through it all and fix it.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Neil Mitchell]

Hi

>  How would you propose supporting multiple preludes at once?

Unhappy. The Haskell Prelude is more than just a standard library.
Things like $, ., otherwise, >>= etc would be keywords in any other
language. As such, you expect their meaning to be consistent.

If you let other people define other Preludes you get very confused
very quickly. I can just imagine otherwise = False sneaking in
somewhere! I don't want to have to edit code and when I look at $
think "did Cale modify this code at any point in the past" :-)

Thanks

Neil
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Cale Gibbard]

2008/4/23 Sittampalam, Ganesh <[EMAIL PROTECTED]>:
> > but it also seems not to make much sense to standardise
>  > a Prelude which people strongly want to change.
>
>  I'm strongly against this change, both on its own merits
>  - in most cases when there is a real argument being passed, I find
>  chains of $s easier to think about than your alternative -
>  but most importantly because it would be enormously disruptive.
>  It's the kind of completely unnecessary thing that simply lends
>  ammunition to the people that claim Haskell is an academic
>  language unsuited to the real world.

Well, try the alternative for a while. It was a little strange at
first for me as well, but once you're used to it, it's extremely
natural. I'd argue it even helps your thinking in other places,
because you're constantly seeing composition chains (even if you still
feel more comfortable thinking of them as application chains for a
while), and this exceptionally simple change gets you into the spirit
of thinking about functions as values to be combined, not just
applied. I would argue that this mindset is an important one for
functional programming, and anything which helps usher people toward
it is a good thing.

>  > Also, the Haskell 98 Prelude has already been reported on, and
>  > probably should continue to be supported in some way or another.
>
>  How would you propose supporting multiple preludes at once? I have
>  a feeling most of the pieces are in place and it's just a question
>  of documenting the "best practice" properly, but it needs to be done
>  and we need to get experience with doing it and with a gradual
>  migration strategy before we even consider this kind of change.
>

I agree that support for this is very important. It would be nice to
simply be able to switch between base packages (and perhaps language
options, like 98/H') with a single simple flag.

I believe that migrating code will be quite a task regardless of the
outcome here, but at least for the packages that are in Hackage, the
system helpfully reports build failures, so we'll know where the
breakages are, and roughly what's left to be done.

 - Cale
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re[4]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Bulat Ziganshin]

Hello Cale,

Wednesday, April 23, 2008, 11:26:49 AM, you wrote:

> f x+y = (x+y)^2

> f x + y = x^2 + y

imho, it's easy to see what there are no spaces around + on first
line, but there are spaces at the second. imho, it's just our habits
- ignore spaces and split expression by operators

actually, shift from usual style of f(x+y,z*t) to f (x+y) (z*t) was no
less dramatic. i propose to go one step further and use spaces instead
of brackets as one more way to control precedence. this idea born from
my haskell programming practice - these additional parentheses are
rather common and avoiding them will make program reading easier. but
it needs to shift habits

> That's a pretty hard to see bug, and it sneaks right past the
> typechecker. I'm all for a certain amount of whitespace sensitivity,
> but that might be going too far.

my main point is that considering space-less operators as having
larger priority is our natural habit. consider this:

f   a*b   x+c

imho, my interpretation of this expression sounds more natural than
haskell's current one


>>  for now, wee need to standardize current haskell practice just for
>>  compilers interoperability and teaching purposes (noone wants to write
>>  book about ghc 6.8 or teach students to it)
>>

> Well, my point is that if we can see these changes that we want to
> make to the libraries, it makes little sense to let people write those
> books and then change all the libraries out from under them a few
> months down the road. Maybe it's what we'll end up doing anyway, but
> it's worth considering.

unfortunately, it will be not a few months. there are many important
things we may change in haskell. sometime ago it was said that
haskell' will just standartize existing haskell (ghc/hugs) state and
haskell 2 will be new, probably incompatible language. fixing just one
oddity in haskell' will give us worst of both worlds - broken
compatibility and lots of oddities still remaining


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Sittampalam, Ganesh]

> but it also seems not to make much sense to standardise
> a Prelude which people strongly want to change.

I'm strongly against this change, both on its own merits
- in most cases when there is a real argument being passed, I find 
chains of $s easier to think about than your alternative -
but most importantly because it would be enormously disruptive.
It's the kind of completely unnecessary thing that simply lends 
ammunition to the people that claim Haskell is an academic
language unsuited to the real world.

> Also, the Haskell 98 Prelude has already been reported on, and
> probably should continue to be supported in some way or another.

How would you propose supporting multiple preludes at once? I have
a feeling most of the pieces are in place and it's just a question
of documenting the "best practice" properly, but it needs to be done
and we need to get experience with doing it and with a gradual
migration strategy before we even consider this kind of change.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Cale Gibbard]

2008/4/23 Bulat Ziganshin <[EMAIL PROTECTED]>:
> Hello Cale,
>
>
>  Wednesday, April 23, 2008, 10:54:06 AM, you wrote:
>
>  > By the way, as Don suggests, I do strongly advocate this change, and
>
>  i agree that the change by itself is reasonable, but fixing all the old
>  issues and providing new beautiful language version should be project
>  of its own. for example, i will propose raising precedences when there
>  are no spaces around operator. this will significantly reduce amount
>  of parentheses/$s:
>
>  f a+b c*d
>
> f g(x) h(y)

I'm not sure that I'm convinced about that one -- consider the simple function:

f x = x^2

and the two programs:

f x+y = (x+y)^2

f x + y = x^2 + y

That's a pretty hard to see bug, and it sneaks right past the
typechecker. I'm all for a certain amount of whitespace sensitivity,
but that might be going too far.

>  for now, wee need to standardize current haskell practice just for
>  compilers interoperability and teaching purposes (noone wants to write
>  book about ghc 6.8 or teach students to it)
>

Well, my point is that if we can see these changes that we want to
make to the libraries, it makes little sense to let people write those
books and then change all the libraries out from under them a few
months down the road. Maybe it's what we'll end up doing anyway, but
it's worth considering.

 - Cale
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Bulat Ziganshin]

Hello Cale,

Wednesday, April 23, 2008, 10:54:06 AM, you wrote:

> By the way, as Don suggests, I do strongly advocate this change, and

i agree that the change by itself is reasonable, but fixing all the old
issues and providing new beautiful language version should be project
of its own. for example, i will propose raising precedences when there
are no spaces around operator. this will significantly reduce amount
of parentheses/$s:

f a+b c*d
f g(x) h(y)

for now, wee need to standardize current haskell practice just for
compilers interoperability and teaching purposes (noone wants to write
book about ghc 6.8 or teach students to it)


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Cale Gibbard]

2008/4/22 Aaron Denney <[EMAIL PROTECTED]>:
> On 2008-04-22, Simon Marlow <[EMAIL PROTECTED]> wrote:
>
> > Chris Smith wrote:
>  >> I know it would break
>  >> nearly every single piece of Haskell code I've ever written.  As such,
>  >> I'm biased toward thinking it's an extremely bad idea.
>  >
>  > Absolutely.  Given that, we'd need a *very* good reason to make the change.
>
>  Surely we don't expect the majority of Haskell code to work unchanged as
>  Haskell' code?
>

And if we're not going to break things in Haskell', then when *are* we
going to break them? Making all the little fiddly changes at once
seems like a better plan than standardising on one thing and then
changing things away from that in the implementations shortly
afterwards. It also seems like a better plan than forking the language
over what are essentially library issues. (This is a sort of minor
one, but there other things, like 'fail', which I certainly would hope
we don't just live with forever.)

If the only goal of Haskell' is to standardise current practices, then
I agree this change makes no sense, but it also seems not to make much
sense to standardise a Prelude which people strongly want to change.

Also, the Haskell 98 Prelude has already been reported on, and
probably should continue to be supported in some way or another.

By the way, as Don suggests, I do strongly advocate this change, and
Dan Doel has already given a very nice summary of why. With regard to
reason #1 in his list, I'd just like to add that due to the fact that
(.) is an associative operator, a composition chain written in terms
of (.) effectively has more subexpressions than one written in terms
of ($), and is thus at least marginally easier to refactor and reason
about. I've found that favouring (.) and being comfortable with
expressing things in terms of function composition very much puts one
in the right mindset for functional programming.

 - Cale
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Bulat Ziganshin]

Hello John,

Wednesday, April 23, 2008, 9:41:22 AM, you wrote:

>> i think this is some misinterpretation. haskell-prime should be,
>> afaik, simple standardization of current software practices, more or
>> less common subset of ghc/hugs language extensions.

> Haskell' will not be fully Haskell 98 compatible.

in particular, h' should break H98 compatibility no more that existing
ghc/hugs versions


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Bulat Ziganshin]

Hello John,

Wednesday, April 23, 2008, 9:41:22 AM, you wrote:

> Haskell' will not be fully Haskell 98 compatible. But it won't
> break things too much hopefully. And no doubt compilers will have
> strategies for mixing h98 and h' code.

aside compilers, there are people, too. are we really want to put
comments on each haskell snippet published - in which version of
language it's written, for a such small benefit?

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[John Meacham]

On Wed, Apr 23, 2008 at 09:32:11AM +0400, Bulat Ziganshin wrote:
> > I'm hoping someone will supply some.  There seemed to be strong opinion
> > on #haskell that this change should be made, but it might just have been
> > a very vocal minority.
> 
> i think this is some misinterpretation. haskell-prime should be,
> afaik, simple standardization of current software practices, more or
> less common subset of ghc/hugs language extensions. in particular, it
> should keep almost full bwd compatibility with H98 standard. it was
> haskell-2 to break up old things and build new perfect language from
> ground

Haskell' will not be fully Haskell 98 compatible. But it won't
break things too much hopefully. And no doubt compilers will have
strategies for mixing h98 and h' code.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re[2]: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Bulat Ziganshin]

Hello Simon,

Wednesday, April 23, 2008, 3:21:18 AM, you wrote:

> I'm hoping someone will supply some.  There seemed to be strong opinion
> on #haskell that this change should be made, but it might just have been
> a very vocal minority.

i think this is some misinterpretation. haskell-prime should be,
afaik, simple standardization of current software practices, more or
less common subset of ghc/hugs language extensions. in particular, it
should keep almost full bwd compatibility with H98 standard. it was
haskell-2 to break up old things and build new perfect language from
ground


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Aaron Denney]

On 2008-04-22, Simon Marlow <[EMAIL PROTECTED]> wrote:
> Chris Smith wrote:
>> I know it would break 
>> nearly every single piece of Haskell code I've ever written.  As such, 
>> I'm biased toward thinking it's an extremely bad idea.
>
> Absolutely.  Given that, we'd need a *very* good reason to make the change.

Surely we don't expect the majority of Haskell code to work unchanged as
Haskell' code?

-- 
Aaron Denney
-><-

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Dan Doel]

On Tuesday 22 April 2008, Simon Marlow wrote:
> I'm hoping someone will supply some.  There seemed to be strong opinion
> on #haskell that this change should be made, but it might just have been
> a very vocal minority.

These are the arguments off the top of my head:

1) Anything of the form:

f $ g $ h $ x

with right associative ($) can instead be written:

f . g . h $ x

where the associativity of ($) doesn't matter. It's not uncommon to want to 
peel off the end of such a pipeline to eliminate a point. For the second 
form, such a translation is:

\x -> f . g . h $ x ==> f . g . h

However:

\x -> f $ g $ h $ x ==> f $ g $ h

Is invalid, so one might argue that writing such pipelines with composition is 
a better habit to get into, as it allows easier cleanup of code in this way 
(if you like somewhat point-free code, that is).

2) Left associative ($) allows you to eliminate more parentheses. Per #1, any 
parentheses eliminated by right associative ($) can be eliminated by (.) and 
a single ($). However, left associative ($) allows, for instance:

f (g x) (h y) ==> f $ g x $ h y

3) Left associative ($) is consistent with left associative ($!). The right 
associative version of the latter is inconvenient, because it only allows 
things to be (easily) strictly applied to the last argument of a function. 
Needing to strictly apply to other arguments gives rise to things like:

   (f $! x) y z
   ((f $! x) $! y) $! z

Left associative, these are:

   f $! x $ y $ z
   f $! x $! y $! z

There may be more arguments, but those are the ones I've heard that I can 
think of at the moment. #3 strikes me as the most likely to bite people (the 
other two are more stylistic issues), but I suppose I don't know the relative 
frequency of strict pipelines (f $! g $! x) versus strict applications at 
non-final arguments.

And I suppose one has to weigh these arguments against breaking lots of code.

Cheers,
-- Dan
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Simon Marlow]

Chris Smith wrote:

On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote:

Tue Apr 22 15:53:31 PDT 2008  Simon Marlow
<[EMAIL PROTECTED]>
  * add ""Make $ left associative, like application"


Is there a justification for this somewhere?


I'm hoping someone will supply some.  There seemed to be strong opinion 
on #haskell that this change should be made, but it might just have been 
a very vocal minority.


I know it would break 
nearly every single piece of Haskell code I've ever written.  As such, 
I'm biased toward thinking it's an extremely bad idea.


Absolutely.  Given that, we'd need a *very* good reason to make the change.

Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Neil Mitchell]

Hi

>  I'm hoping someone will supply some.  There seemed to be strong opinion on
> #haskell that this change should be made, but it might just have been a very
> vocal minority.

I think the feeling was that it encourages a slightly different style
of programming, instead of:

f $ g $ h x

People should do:

f . g . h $ x

Then you can change the $ as suggested, and use it in other places.
For a while I was persuaded it was a better style, but now I'm not
convinced and have stuck to the first style. Either way, its a matter
of style whose elegance is certainly not worth breaking all my code to
improve.

Thanks

Neil
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Don Stewart]

marlowsd:
> Chris Smith wrote:
> >On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote:
> >>Tue Apr 22 15:53:31 PDT 2008  Simon Marlow
> >><[EMAIL PROTECTED]>
> >>  * add ""Make $ left associative, like application"
> >
> >Is there a justification for this somewhere?
> 
> I'm hoping someone will supply some.  There seemed to be strong opinion 
> on #haskell that this change should be made, but it might just have been 
> a very vocal minority.

It's just Cale. 
 
-- Don
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Neil Mitchell]

Hi Chris,

>  >   * add ""Make $ left associative, like application"
>
>  Is there a justification for this somewhere?  I know it would break
>  nearly every single piece of Haskell code I've ever written.  As such,
>  I'm biased toward thinking it's an extremely bad idea.

>From the patch:

+ ,Issue "Make $ left associative, like application" []
+ Undecided
+ Prelude

i.e. its Undecided - not accepted. Like you, I would be mildly enraged
if someone broke 100's of projects of mine simultaneously.

Thanks

Neil
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Duncan Coutts]

On Tue, 2008-04-22 at 23:13 +, Chris Smith wrote:
> On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote:
> > Tue Apr 22 15:53:31 PDT 2008  Simon Marlow
> > <[EMAIL PROTECTED]>
> >   * add ""Make $ left associative, like application"
> 
> Is there a justification for this somewhere?  I know it would break 
> nearly every single piece of Haskell code I've ever written.  As such, 
> I'm biased toward thinking it's an extremely bad idea.

Indeed. I think it would at least be worth testing a bunch of packages
from hackage and seeing how many break and when they do, how nice the
fixes are.

Surely there was a justification to having $ be the opposite
associativity from application and not just a different precedence. Does
anyone know what it was?

Duncan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Chris Smith]

On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote:
> Tue Apr 22 15:53:31 PDT 2008  Simon Marlow
> <[EMAIL PROTECTED]>
>   * add ""Make $ left associative, like application"

Is there a justification for this somewhere?  I know it would break 
nearly every single piece of Haskell code I've ever written.  As such, 
I'm biased toward thinking it's an extremely bad idea.


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

patch applied (haskell-prime-status): add ""Make $ left associative, like application"

[Simon Marlow]

Tue Apr 22 15:53:31 PDT 2008  Simon Marlow <[EMAIL PROTECTED]>
  * add ""Make $ left associative, like application"

M ./status.hs +5

View patch online:
http://darcs.haskell.org/haskell-prime-status/_darcs/patches/2008045331-8214f-8c2b7ec4a7666bfaa70b2514290172981bdebb50.gz
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime