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 larg
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://ww
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'. :(
Give
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, b
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 wha
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
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
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:
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 Ha
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 do
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
_
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
___
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,
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 roughl
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 type
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?
>
>
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
in
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 fu
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 ex
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
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
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 c
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
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
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 writt
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 h
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
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
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 pr
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 m
> 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
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 pi
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 br
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 h
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 mo
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 y
> 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 (archiveRea
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 alr
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
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 wor
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
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]
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-p
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
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 functio
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 p
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 fma
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
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 i
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 i
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 .
yetAnotherBlock
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 justificati
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
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 h
> 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
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 ot
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
>
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
> 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 mo
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
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 exam
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.
> >
>
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
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 t
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-p
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 shoul
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 m
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:
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
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
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
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:
+ ,Iss
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
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
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
___
75 matches
Mail list logo
