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
Hi
I think Henrik's criteria are pretty close to perfect.
As I have argued before on the committee list, I also think we should *not*
worry about backwards incompatible changes too much in cases where a simple
automatic translation from H98 to H' code is possible. Even for a large
project,
Hi all,
Manuel wrote:
As I have argued before on the committee list, I also think we should
*not* worry about backwards incompatible changes too much in cases
where a simple automatic translation from H98 to H' code is possible.
Yes, tools can and should help with migration, and we should
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
Hello Neil,
Thursday, April 24, 2008, 12:21:41 PM, you wrote:
Some questions:
don't forget about most complex part: does this tool will convert
human minds? :D
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
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
Manuel wrote:
As John Launchbury has said, given Haskell's current rise in
popularity, anything that we do not fix with H' will be much harder, if
not impossible, to fix in the future.
On Thu, 24 Apr 2008 09:21:41 +0100, Neil Mitchell wrote:
That is a very good point. Perhaps we're already a
| Iavor:
| the change is valid. I do believe that you can probably work around
| the problem in many situations but the question in my mind is why
| should we have to work around stuff when we have a system that already
| works? In other words, what problem do MBPs solve?
...
| Neil:
| Haskell
Chris Smith wrote:
I'm definitely not arguing for this ($)
associativity change, for example, and my objection is the backward
compatibility. But ultimately, it's more like a combination of
incompatibility and the lack of a really compelling story on why it
should be one way or the other. I
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
Iavor Diatchki wrote:
I should also point out that if we were to adopt the MBP rule, we
would have to adjust the definition of what pattern bindings mean.
For example, I think that this is how things are desugared at the
moment:
(x,y) = e
becomes
new_var = e
x = case new_var of (v,_) - v
y =
Am Freitag, 18. April 2008 11:54 schrieb Sittampalam, Ganesh:
Simon Peyton Jones wrote:
Not allowing infix functions on the LHS would be a notable simplification.
This would significantly weaken a useful property of Haskell, that
definitions and uses often share the same concrete syntax.
Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham:
On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
Is this the most up-to-date description of the proposal?
http://repetae.net/recent/out/classalias.html
There were a few changes proposed in the discussion that
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
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
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
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 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
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
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
Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard:
[…]
Rename fmap to map
This would be really great! There is no point in having a map just for lists
and a general map for functors since the list map is the same as the list
instance’s functor map. And identifiers with a single
2008/4/24 Wolfgang Jeltsch [EMAIL PROTECTED]:
Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard:
[…]
Rename fmap to map
This would be really great! There is no point in having a map just for lists
and a general map for functors since the list map is the same as the list
2008/4/24 Chris Smith [EMAIL PROTECTED]:
3. Don't get me wrong; I'm definitely not arguing for this ($)
associativity change, for example, and my objection is the backward
compatibility. But ultimately, it's more like a combination of
incompatibility and the lack of a really compelling
On Thursday 24 April 2008, Wolfgang Jeltsch wrote:
I don’t think that this is reasonable. (.) corresponds to the little
circle in math which is a composition. So (.) = () would be far better.
Were I building a library, this might be the direction I'd take things.
They're two incompatible
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:
2008/4/24 Dan Doel [EMAIL PROTECTED]:
On Thursday 24 April 2008, Wolfgang Jeltsch wrote:
I don't think that this is reasonable. (.) corresponds to the little
circle in math which is a composition. So (.) = () would be far better.
Were I building a library, this might be the direction
Cale Gibbard wrote:
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
2008/4/24 Twan van Laarhoven [EMAIL PROTECTED]:
Cale Gibbard wrote:
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
On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven [EMAIL PROTECTED] wrote:
Cale Gibbard wrote:
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
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
2008/4/24 David Menendez [EMAIL PROTECTED]:
On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven [EMAIL PROTECTED] wrote:
Cale Gibbard wrote:
Hello,
In keeping with my small but seemingly extremely controversial
suggestions for changes to the Prelude, here's a suggestion
31 matches
Mail list logo
