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
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
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
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,
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
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
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
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
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.
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 .
Wed Apr 23 09:47:02 PDT 2008 Simon Marlow [EMAIL PROTECTED]
* wiki link for the $ issue
M ./status.hs -1 +1
View patch online:
http://darcs.haskell.org/haskell-prime-status/_darcs/patches/20080423164702-8214f-f38f4a62db63708da38c8cabdb65bc8af8aea58c.gz
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
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
There appears to be some question as to the backward compatibility goals
of Haskell'. Perhaps it's worth bringing out into the open.
From conversations I've had and things I've read, I've always gathered
that the main goal of Haskell' is to address the slightly embarrassing
fact that
An interesting question. What is the goal of Haskell'? Is it to, like
Python 3000, fix warts in the language in an (somewhat) incompatible
way or is it to just standardize current practice? I think we need
both, I just don't know which of the two Haskell' is.
-- Johan
On Wed, Apr 23, 2008 at
On Wed, 23 Apr 2008, Johan Tibell wrote:
An interesting question. What is the goal of Haskell'? Is it to, like
Python 3000, fix warts in the language in an (somewhat) incompatible
way or is it to just standardize current practice? I think we need
both, I just don't know which of the two
Hello Philippa,
Wednesday, April 23, 2008, 10:53:54 PM, you wrote:
Current practice often involves removing certain warts anyway - the MR
being a great example.
it's already in ghc for a years and doesn't affect too much code. we
need a solid base of a language to write to, to learn, 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]
Hello,
Removing the MR seems reasonable. I am a little less certain about
the MPB rule though. I suspect that, as the wiki page points out,
many uses of pattern bindings are monomorphic but still, there seem to
be a number of examples on the wiki where people have run into this
problem. So I am
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,
An interesting question. What is the goal of Haskell'? Is it to, like
Python 3000, fix warts in the language in an (somewhat) incompatible
way or is it to just standardize current practice? I think we need
both, I just don't know which of the two Haskell' is.
I would hope it is both. Some
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
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
On Wed, Apr 23, 2008 at 4:52 PM, Niklas Broberg
[EMAIL PROTECTED] wrote:
I would hope it is both. Some changes simply cannot become current
practice since they would not be compatible with existing code, and
the only place that such changes *could* be made is in a new language
version.
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
On Wed, 23 Apr 2008 22:52:18 +0200, Niklas Broberg wrote:
An interesting question. What is the goal of Haskell'? Is it to, like
Python 3000, fix warts in the language in an (somewhat) incompatible
way or is it to just standardize current practice? I think we need
both, I just don't know
Hi
* remove the MR entirely
Finally!
* adopt Monomorphic Pattern Bindings (MPB)
There are 6 reasons on that page why we shouldn't adopt MPB - of those
number 5 I think is particularly compelling. There seems to be 1 main
reason to remove it, which is that it has a complex translation to
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
Johan Tibell wrote:
An interesting question. What is the goal of Haskell'? Is it to, like
Python 3000, fix warts in the language in an (somewhat) incompatible
way or is it to just standardize current practice? I think we need
both, I just don't know which of the two Haskell' is.
The stated
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
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
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
Hello,
In keeping with my small but seemingly extremely controversial
suggestions for changes to the Prelude, here's a suggestion which I
think is elegant and worth considering for the Haskell' Prelude:
Rename fmap to map (like it was in Haskell 1.4), and define (.) as a
synonym for it.
On Wednesday 23 April 2008, Chris Smith wrote:
I don't think I agree that fail in the Monad typeclass is a good example
here, or necessarily that there is a good example.
We should remember that there is a cohesive community of Haskell
programmers; not a bunch of unrelated individuals who
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
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
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
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
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
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
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
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
Simon Marlow:
Johan Tibell wrote:
An interesting question. What is the goal of Haskell'? Is it to, like
Python 3000, fix warts in the language in an (somewhat) incompatible
way or is it to just standardize current practice? I think we need
both, I just don't know which of the two Haskell' is.
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
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
45 matches
Mail list logo
