Meta-point: backward compatibility

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

Meta-point: backward compatibility

Chris Smith-39
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 practically no one actually writes code in Haskell, if by
Haskell we mean the most recent completed language specification.  This
obviously argues strongly for a high degree of backward compatibility.

On the other hand, I am assuming everyone agrees that we don't want to
replicate Java, which (in my view, anyway) is rapidly becoming obsolete
because of an eagerness to make the language complex, inconsistent, and
generally outright flawed in order to avoid even the most unlikely of
broken code.

--
Chris

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

Re: Meta-point: backward compatibility

Johan Tibell-2
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 2:16 PM, Chris Smith <[hidden email]> wrote:

> 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 practically no one actually writes code in Haskell, if by
>  Haskell we mean the most recent completed language specification.  This
>  obviously argues strongly for a high degree of backward compatibility.
>
>  On the other hand, I am assuming everyone agrees that we don't want to
>  replicate Java, which (in my view, anyway) is rapidly becoming obsolete
>  because of an eagerness to make the language complex, inconsistent, and
>  generally outright flawed in order to avoid even the most unlikely of
>  broken code.
>
>  --
>  Chris
>
>  _______________________________________________
>  Haskell-prime mailing list
>  [hidden email]
>  http://www.haskell.org/mailman/listinfo/haskell-prime
>
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Meta-point: backward compatibility

Philippa Cowderoy
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 Haskell' is.
>

Current practice often involves removing certain warts anyway - the MR
being a great example.

--
[hidden email]

Ivanova is always right.
I will listen to Ivanova.
I will not ignore Ivanova's recomendations.
Ivanova is God.
And, if this ever happens again, Ivanova will personally rip your lungs out!
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re[2]: Meta-point: backward compatibility

Bulat Ziganshin-2
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 popularize.
and to develop next, more advanced language versions


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

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

Re: Meta-point: backward compatibility

Johan Tibell-2
In reply to this post by Philippa Cowderoy
On Wed, Apr 23, 2008 at 2:53 PM, Philippa Cowderoy <[hidden email]> wrote:
>  Current practice often involves removing certain warts anyway - the MR
>  being a great example.

I was more thinking of things like removing fail from the Monad class
and fixing the I/O libraries to use Unicode, etc.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
Reply | Threaded
Open this post in threaded view
|

Re: Meta-point: backward compatibility

Niklas Broberg
In reply to this post by Johan Tibell-2
> 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 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. Like you say, fail in the Monad class is one such issue that
would not be backwards compatible, and couldn't become a current
practice without some help. Chicken or egg first?

Cheers,

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

Re: Meta-point: backward compatibility

Johan Tibell-2
On Wed, Apr 23, 2008 at 4:52 PM, Niklas Broberg
<[hidden email]> 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. Like you say, fail in the Monad class is one such issue that
>  would not be backwards compatible, and couldn't become a current
>  practice without some help. Chicken or egg first?

You're of course right. Haskell' could be both. It probably should be
as the next Haskell standard (after Haskell') will probably be several
years in the future. It would be a shame to wake up the day after GHC
fully implements Haskell' and notice that nothing has changed and my
old annoyances are still there.

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

Re: Meta-point: backward compatibility

Chris Smith-39
In reply to this post by Niklas Broberg
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 which of the two Haskell' is.
>
> 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.  Like you say, fail in the Monad class is one such issue that
> would not be backwards compatible, and couldn't become a current
> practice without some help. Chicken or egg first?

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 never talk to each
other.  It's entirely possible to spend some time recommending against
using fail (as many people have been doing), and then eventually remove
it.  It doesn't need to break very much.  This is working in our favor,
so we may as well use it.  IMO, this argues strongly in favor of making
any backward compatible changes incrementally, instead of adopting a
"Python 3000" model of postponing them and then breaking everything at
once.

(This is ignoring technical issues in this particular example; like what
happens when a pattern match fails if there is no fail in Monad.  It's
entirely possible that discouraging use is the right answer in this case,
and that removal need not happen.  That's beside the point.)

--
Chris

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

Re: Meta-point: backward compatibility

Simon Marlow-7
In reply to this post by Johan Tibell-2
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 goal is still for Haskell' to be a language that is stable
and relevant for large-scale development for several years to come.

It is mainly a consolidation effort: that is, we aim to standardise
existing practice in the form of language extensions that are currently
implemented and widely used.  Having said that, the standardisation
process gives us the opportunity to critically assess the design of
these extensions, and the design of the system as a whole, and as a
result we may wish to make changes in order that the resulting language
does not have inconsistencies, design flaws, or critical omissions.

The language design process is also an opportunity to re-assess existing
language features in the light of the wealth of experience gained over
recent years.  A perfect example is the monomorphism restriction: we now
know that this aspect of the language really does surprise people in
practice, whereas this wasn't known, or at least wasn't as clear, at the
time that Haskell 98 was being designed.

As for the particular question of backwards-incompatible changes, here
are some criteria that Henrik Nilsson proposed early on, and I think are
still relevant (i'm sure he won't mind my reposting these from the
committee mailing list):

* If a proposed change breaks backwards compatibility, then it is
    acceptable only if either

    - very little existing code is likely going to be broken in
      practice, or
    - + it is widely agreed that not addressing the issue really
        would harm the long-term relevance of Haskell', and
      + it is widely agreed that attempting to maintain backwards
        compatibility would lead to an unwieldy language design, and
      + the proposed design and its implications are well understood,
        i.e. it has been implemented in at least one system and it has
        been used extensively, or a strong argument can be made on
        the grounds of, say, an underlying well-understood theory.

Libraries are another matter.  We have in place mechanisms for
versioning libraries and specifying precise dependencies, so changes to
libraries are in a sense less fundamental than changes to the language
itself.  We've already stated that libraries are to be standardised
separately, and I think it would also make sense for library standards
to be issued more regularly than standards for the language.

Cheers,
        Simon

>
> -- Johan
>
> On Wed, Apr 23, 2008 at 2:16 PM, Chris Smith <[hidden email]> wrote:
>> 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 practically no one actually writes code in Haskell, if by
>>  Haskell we mean the most recent completed language specification.  This
>>  obviously argues strongly for a high degree of backward compatibility.
>>
>>  On the other hand, I am assuming everyone agrees that we don't want to
>>  replicate Java, which (in my view, anyway) is rapidly becoming obsolete
>>  because of an eagerness to make the language complex, inconsistent, and
>>  generally outright flawed in order to avoid even the most unlikely of
>>  broken code.
>>
>>  --
>>  Chris
>>
>>  _______________________________________________
>>  Haskell-prime mailing list
>>  [hidden email]
>>  http://www.haskell.org/mailman/listinfo/haskell-prime
>>
> _______________________________________________
> Haskell-prime mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-prime

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

Re: Meta-point: backward compatibility

Dan Doel
In reply to this post by Chris Smith-39
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 never talk to each
> other.  It's entirely possible to spend some time recommending against
> using fail (as many people have been doing), and then eventually remove
> it.  It doesn't need to break very much.  This is working in our favor,
> so we may as well use it.  IMO, this argues strongly in favor of making
> any backward compatible changes incrementally, instead of adopting a
> "Python 3000" model of postponing them and then breaking everything at
> once.
>
> (This is ignoring technical issues in this particular example; like what
> happens when a pattern match fails if there is no fail in Monad.  It's
> entirely possible that discouraging use is the right answer in this case,
> and that removal need not happen.  That's beside the point.)

The thing is, fail isn't evil because it's intrinsically evil; it's evil
because it's in the wrong place. Many monads don't have a proper notion of
failure, so error just gets called, which is undesirable. (Even if they do
have a proper notion of failure, it's also easy to forget to define fail
appropriately, if you're defining your own monad.)

Discouraging people from ever using fail, or even monadic pattern matching is
also undesirable, because there are plenty of places where it is appropriate.
As an example, I saw a blog post that included code like so (I don't remember
the exact code, but this is comparable):

    f c l = length [ () | (c':'h':_) <- tails l, c == c' ]

In the comments of that blog, someone had written that the code was evil,
because it was an abuse of fail. But that isn't an abuse of fail (it doesn't
even use fail at all, technically, since list comprehensions have their own
desugaring in the report), it's appropriate use of fail. So clearly, people
are already getting the wrong idea from the "don't use fail" push, and may be
avoiding appropriate use of it, when it would make for clearer code.

So, if you ask me, the solution isn't "discourage all use of fail." There's
nothing wrong with failing in an arbitrary monad-with-failure. And we already
have a class for that, called MonadPlus (or MonadZero if you split them up as
in 1.4). If you move fail there, then you can encourage use of fail when
appropriate. Currently, it seems difficult to do that (witness the readM
thread on the libraries list, where it was proposed that fail be used
(because there are multiple ways to fail), but with type restricted to
MonadPlus; most people still seemed to dislike that because 'fail is evil').

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

Re: Meta-point: backward compatibility

Manuel M T Chakravarty
In reply to this post by Simon Marlow-7
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.
[..]

> As for the particular question of backwards-incompatible changes,  
> here are some criteria that Henrik Nilsson proposed early on, and I  
> think are still relevant (i'm sure he won't mind my reposting these  
> from the committee mailing list):
>
> * If a proposed change breaks backwards compatibility, then it is
>   acceptable only if either
>
>   - very little existing code is likely going to be broken in
>     practice, or
>   - + it is widely agreed that not addressing the issue really
>       would harm the long-term relevance of Haskell', and
>     + it is widely agreed that attempting to maintain backwards
>       compatibility would lead to an unwieldy language design, and
>     + the proposed design and its implications are well understood,
>       i.e. it has been implemented in at least one system and it has
>       been used extensively, or a strong argument can be made on
>       the grounds of, say, an underlying well-understood theory.

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, it is IMHO no big hardship to run a H98->H'  
translator over all Haskell sources.  After all, this is only needed  
for active projects that want to make use of H'.  For old code, I  
expect that compilers will still provide a -XHaskell98 flag or similar  
for the foreseeable future.

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.

Manuel

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

Re: Meta-point: backward compatibility

Neil Mitchell
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, it is IMHO no big hardship to run a H98->H' translator over all
> Haskell sources.

Some questions:

1) Will I (the programmer) have to mode switch in painful ways between
H98 and H'? Do I have to learn a pile of exceptions, or is there some
common rule that works? (i.e. removing n+k is fine since I just don't
learn it, changing the fixity of $ is not since I need to know both)

2) Will tool T (the translator) work on academic papers that have
previously been published.

3) Will tool T handle all of GHC's extensions.

4) Will tool T deal with things like CPP, hsc, trhsx, happy, alex
etc... - all these file formats which include embedded Haskell.

5) Will tool T ever exist.

I think the answer to 2-5 is nearly certainly going to be "No". I
don't think the relevance of a conversion tool should even be
considered until some person steps forward and says without doubt that
_they_ will write the converter. Even if they did there very best, it
still won't be trivial to use in all cases.

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

That is a very good point. Perhaps we're already a little too late.

Thanks

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

Re: Meta-point: backward compatibility

Henrik Nilsson
In reply to this post by Manuel M T Chakravarty
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 keep
that in mind. In particular, complicated language design to
incorporate new features while maintaining backwards compatibility
should be avoided where old code and new code easily can be
made to work together through a compiler compatibility flag.
(The discussion on records/labelled fields spring to mind.)

However, I still think it is important to be conservative when
it comes to breaking changes and either only consider them
when the impact really would be very small, or when it is agreed
it is a really important change.

Even if there are tools to help with code, effort is still involved
to fix the breaks, and thus it ought to be completely clear that the
effort is worth it.

And there is not only code: there are papers and books too!

And finally, unless we're fairly strict, we'll be bogged down in a flood
of discussion on gratuitous and ultimately rather superficial changes.
The associativity of "$" is a case in point.

So, the criteria I proposed still seem quite reasonable to me.
But I'm biased, of course! :-)

/Henrik

--
Henrik Nilsson
School of Computer Science
The University of Nottingham
[hidden email]

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

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

Re[2]: Meta-point: backward compatibility

Bulat Ziganshin-2
In reply to this post by Neil Mitchell
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,
 Bulat                            mailto:[hidden email]

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

Re: Meta-point: backward compatibility

Chris Smith-39
In reply to this post by Neil Mitchell
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 little too late.

In general, I truly hope that this is not the case.

Part of what makes Haskell such a great environment is the sense that the
language values doing things right, trying out new ideas and adopting
them when they work, and that the Haskell community takes pride in what
we have as a language.  I'm certainly willing to give up some effort
fixing my old code in order to use such a language.  Now, I realize that
me fixing my old Haskell code means something like ten thousand lines at
most, while for others it may mean a couple orders of magnitude more
work; maybe it's best just to ignore me.  But it would be a shame if, in
the course of trying to do the right thing for Haskell's large
popularity, we ended up diluting the things about the language that make
it popular.

So I'd argue that, in Haskell' and later on as well, it should be just a
fact of life that code will occasionally break as the language evolves.  
If there's a consensus that something is broken, it should be fixed.  If
people want their code from 10 years ago to work on today's latest
compiler, then there will be lots of intangible costs to achieving that
goal, and I'm not sure the current spirit of Haskell will survive those
costs.  Unfortunately, that cost, which might be expressed as "Haskell
won't be as nifty a language any more", is hard to take seriously; but
I'm nevertheless convinced that it has to be taken seriously.

That said, three caveats:

1. If the goal of Haskell' in particular is to codify existing practice,
that's quite the admirable goal given how far behind (10 years!) things
currently are in having a language standard.  So this is more about how
we should think about life after Haskell', rather than the current
Haskell' effort.

2. Nothing I said is an argument for intentionally making people's lives
painful.  For example, there's no need to take approaches that break
people's code between consecutive versions of Haskell with no easy way of
making the code work with both.  Neil said this better elsewhere, so I
won't repeat it.

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 story on why it
should be one way or the other.  I have a hard time calling this a "fix";
it's more like a change of personal taste.  If I saw this as really
broken, then I'd say we need to talk about how to fix it.

--
Chris

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

Re: Meta-point: backward compatibility

Heinrich Apfelmus
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 have a hard time calling this a "fix";
> it's more like a change of personal taste.

The $ problem is an interesting one, for it has the following properties:

  1) Someone who learns Haskell for the first time will not complain
     about either associativity. Whether it's left or right associative
     is rather unimportant, it is how it is and either way is fine.

  2) But once the decision has been made, it's nigh impossible to change
     it, simply because everybody has relied on one particular
     associativity of $ all the time.

  3) Assuming that this associativity is a matter of taste, it only
     sounds fair to experiment and try different tastes. So, Cale has a
     Prelude with left associative $ and Lennart has a different personal
     Prelude as well and I'm going too taste a sip of either one and
     brew my own functional coffee. But in that situation, the defining
     property of a standard, namely that everybody uses the same $ , is
     gone, everybody would have to check which one is used in which
     module.

It's like being forced to eat chicken only because chicken lay eggs.
Some may like it, some may not, but the eggs will hatch new chicken who
lay new eggs for all eternity :)


Regards,
apfelmus

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

Re: Meta-point: backward compatibility

Aaron Denney
In reply to this post by Simon Marlow-7
On 2008-04-23, Simon Marlow <[hidden email]> wrote:

> 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 goal is still for Haskell' to be a language that is stable
> and relevant for large-scale development for several years to come.
>
> It is mainly a consolidation effort: that is, we aim to standardise
> existing practice in the form of language extensions that are currently
> implemented and widely used.  Having said that, the standardisation
> process gives us the opportunity to critically assess the design of
> these extensions, and the design of the system as a whole, and as a
> result we may wish to make changes in order that the resulting language
> does not have inconsistencies, design flaws, or critical omissions.

Given a fairly limited goal of "consolidating current practice", not
much should change.  And this is a very useful thing to do.  The problem
is that many of us don't see any opportunity for large change after
this.  We expect any changes in the hypothetical Haskell 2 (or 201x) to
be resisted tooth and nail by the larger crowd as Haskell grows.  And
there is a lot that clearly isn't battle tested in a reasonable new
form, though the current practice is widely agreed upon to be broken.
Examples include all monads having fail, rather than only those in a
subclass, monad not being a subclass of functor, and the whole numeric
hierarchy issue (which I don't think can be properly designed unless we
know whether it's going to be FDs or ATs, though, of course, designing
it for either would provide valuable experience for the limitations of
both),  Many of these are "mere" library changes, but library changes
that are nearly as fundamental as language changes, because of how tied
in the prelude is currently.  It's still not entirely straightforward to
replace the prelude with a custom one, which makes it harder to test
some of these changes in real world use.  All of these factors combine
to make the ones who get annoyed with these problems to want to shoehorn
in changes right now.

--
Aaron Denney
-><-

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

Re: Meta-point: backward compatibility

Cale Gibbard
In reply to this post by Chris Smith-39
2008/4/24 Chris Smith <[hidden email]>:
>  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 story on why it
>  should be one way or the other.  I have a hard time calling this a "fix";
>  it's more like a change of personal taste.  If I saw this as really
>  broken, then I'd say we need to talk about how to fix it.

How about the argument that the right associative ($), in conjuction
with (.) is less expressive than that left associative one in
conjunction with (.)? That is, more parentheses can be avoided.
Everything you can do with chained right associative ($), you can do
with (.) and a single ($), whereas there are things you can express
with chained left-associative ($) which you need parentheses to
express without it.

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

Re: Meta-point: backward compatibility

Lennart Augustsson
In reply to this post by Neil Mitchell
I agree with Neil.  Translators are very difficult to do right, except for the most trivial transformations.
Changing tabs to spaces is about as far as I would trust an automatic translator.

  -- Lennart

On Thu, Apr 24, 2008 at 9:21 AM, Neil Mitchell <[hidden email]> wrote:
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, it is IMHO no big hardship to run a H98->H' translator over all
> Haskell sources.

Some questions:

1) Will I (the programmer) have to mode switch in painful ways between
H98 and H'? Do I have to learn a pile of exceptions, or is there some
common rule that works? (i.e. removing n+k is fine since I just don't
learn it, changing the fixity of $ is not since I need to know both)

2) Will tool T (the translator) work on academic papers that have
previously been published.

3) Will tool T handle all of GHC's extensions.

4) Will tool T deal with things like CPP, hsc, trhsx, happy, alex
etc... - all these file formats which include embedded Haskell.

5) Will tool T ever exist.

I think the answer to 2-5 is nearly certainly going to be "No". I
don't think the relevance of a conversion tool should even be
considered until some person steps forward and says without doubt that
_they_ will write the converter. Even if they did there very best, it
still won't be trivial to use in all cases.

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

That is a very good point. Perhaps we're already a little too late.

Thanks

Neil
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime


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

Re: Meta-point: backward compatibility

Ross Paterson
In reply to this post by Aaron Denney
On Thu, Apr 24, 2008 at 08:18:10PM +0000, Aaron Denney wrote:
> And there is a lot that clearly isn't battle tested in a reasonable new
> form, though the current practice is widely agreed upon to be broken.
> Examples include all monads having fail, rather than only those in a
> subclass, monad not being a subclass of functor, and the whole numeric
> hierarchy issue (which I don't think can be properly designed unless we
> know whether it's going to be FDs or ATs, though, of course, designing
> it for either would provide valuable experience for the limitations
> of both),

I don't think any of these need involve multi-parameter type classes
(we don't need vector spaces in the Prelude), but they're often presented
as use cases for things like class aliases.  Even then, the numeric
hierarchy is probably easier to fix that the others: one can define a
finer-grain hierarchy with the existing classes as a facade, and leave
clients untouched.  The change would be felt by the minority defining
instances of numeric classes, but they are exactly the people who find
the present hierarchy inadequate.
_______________________________________________
Haskell-prime mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-prime
12