Deprecating haskell98 module aliases

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

Deprecating haskell98 module aliases

Gwern Branwen
See http://hackage.haskell.org/trac/hackage/ticket/640

It seems to me that a warning on using the 'haskell98' package
wouldn't be a bad thing; those modules have since been split apart in
better modules, the names are ever more unfamiliar, etc.

But Duncan thinks it merits discussion.

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

Re: Deprecating haskell98 module aliases

wren romano-2
Gwern Branwen wrote:
> See http://hackage.haskell.org/trac/hackage/ticket/640
>
> It seems to me that a warning on using the 'haskell98' package
> wouldn't be a bad thing; those modules have since been split apart in
> better modules, the names are ever more unfamiliar, etc.
>
> But Duncan thinks it merits discussion.

I'm all for the warnings. And regarding guest's comments, doesn't the
Haskell 2010 standard[1] count as an "actual language standard"? If not,
then what is it and why isn't it one?


[1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html

--
Live well,
~wren
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating haskell98 module aliases

Gwern Branwen
On Mon, Mar 8, 2010 at 3:36 PM, wren ng thornton
<[hidden email]> wrote:

> Gwern Branwen wrote:
>>
>> See http://hackage.haskell.org/trac/hackage/ticket/640
>>
>> It seems to me that a warning on using the 'haskell98' package
>> wouldn't be a bad thing; those modules have since been split apart in
>> better modules, the names are ever more unfamiliar, etc.
>>
>> But Duncan thinks it merits discussion.
>
> I'm all for the warnings. And regarding guest's comments, doesn't the
> Haskell 2010 standard[1] count as an "actual language standard"? If not,
> then what is it and why isn't it one?
>
>
> [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html

Correct me if I'm wrong, but I thought 'HierarchicalModules' was an
extension which codifies the 'Foo.Bar' import syntax (as opposed to
'import FooBar'), and didn't address allocation of functions to
modules  or naming issues like 'Char' vs 'Data.Char' or splitting
'Foreign' up or whatever.

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

Re: Deprecating haskell98 module aliases

Henning Thielemann
In reply to this post by wren romano-2

On Mon, 8 Mar 2010, wren ng thornton wrote:

> Gwern Branwen wrote:
>> See http://hackage.haskell.org/trac/hackage/ticket/640
>>
>> It seems to me that a warning on using the 'haskell98' package
>> wouldn't be a bad thing; those modules have since been split apart in
>> better modules, the names are ever more unfamiliar, etc.
>>
>> But Duncan thinks it merits discussion.
>
> I'm all for the warnings. And regarding guest's comments, doesn't the Haskell
> 2010 standard[1] count as an "actual language standard"? If not, then what is
> it and why isn't it one?

Actually, when using GHCi I like to have the short Haskell98 module names.
In contrast to that when writing a package for real use, that is, when I
use Cabal, then Cabal might warn that the package haskell98 is deprecated.
Even more deprecating a package by a Cabal field would be a nice thing and
then haskell98 could be deprecated this way.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating haskell98 module aliases

wren romano-2
In reply to this post by Gwern Branwen
Gwern Branwen wrote:

> wren ng thornton wrote:
>> I'm all for the warnings. And regarding guest's comments, doesn't the
>> Haskell 2010 standard[1] count as an "actual language standard"? If not,
>> then what is it and why isn't it one?
>>
>> [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html
>
> Correct me if I'm wrong, but I thought 'HierarchicalModules' was an
> extension which codifies the 'Foo.Bar' import syntax (as opposed to
> 'import FooBar'), and didn't address allocation of functions to
> modules  or naming issues like 'Char' vs 'Data.Char' or splitting
> 'Foreign' up or whatever.

AFAIK, yes, the HierarchicalModules approval is just allowing dots in
module names, rather than discussing what goes where. I was bringing
haskell2010 up more to point out that the haskell98 standard is,
officially, not up to date.

Perhaps we should poke the haskell-prime committee to move the official
location of standard functions for the haskell2011 standard?

--
Live well,
~wren
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating haskell98 module aliases

wren romano-2
In reply to this post by Gwern Branwen
Gwern Branwen wrote:

> wren ng thornton wrote:
>> I'm all for the warnings. And regarding guest's comments, doesn't the
>> Haskell 2010 standard[1] count as an "actual language standard"? If not,
>> then what is it and why isn't it one?
>>
>> [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html
>
> Correct me if I'm wrong, but I thought 'HierarchicalModules' was an
> extension which codifies the 'Foo.Bar' import syntax (as opposed to
> 'import FooBar'), and didn't address allocation of functions to
> modules  or naming issues like 'Char' vs 'Data.Char' or splitting
> 'Foreign' up or whatever.

AFAIK, yes, the HierarchicalModules approval is just allowing dots in
module names, rather than discussing what goes where. I was bringing
haskell2010 up more to point out that the haskell98 standard is,
officially, not up to date.

Perhaps we should poke the haskell-prime committee to move the official
location of standard functions for the haskell2011 standard?

--
Live well,
~wren
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating haskell98 module aliases

Christian Maeder-2
In reply to this post by Gwern Branwen
Gwern Branwen schrieb:
> See http://hackage.haskell.org/trac/hackage/ticket/640
>
> It seems to me that a warning on using the 'haskell98' package
> wouldn't be a bad thing; those modules have since been split apart in
> better modules, the names are ever more unfamiliar, etc.
>
> But Duncan thinks it merits discussion.

The modules in haskell98 are just wrapper modules providing their
functions under different module names in order to support the (old)
currently documented haskell98 standard from Dec. 2002 (also used in
many teaching books).
http://www.haskell.org/onlinelibrary/

This documentation lists even modules that are not part of current ghc
installations like:
module PreludeList, module PreludeText, module PreludeIO

I don't miss these modules and I think we should eventually get rid of
haskell98 as a *core* package of ghc (and the haskell-platform).

Before omitting the haskell98 package we should warn about it!

Whoever still wants to use the haskell98 package may install it via
cabal (or use his/her own wrapper module(s)).

I would at least warn about a haskell98 dependency in .cabal files.
Maybe even a warning for every non-hierarchical module import should be
issued.

Cheers Christian
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating haskell98 module aliases

Malcolm Wallace
In reply to this post by wren romano-2
> And regarding guest's comments, doesn't the Haskell 2010 standard[1]  
> count as an "actual language standard"? If not, then what is it and  
> why isn't it one?

Haskell 2010 has been decided, but the Language Report itself has not  
yet been published.  So yes, it is a standard, but not one you can  
refer to (yet).

IIRC, H'2010 makes no changes to the Libraries section of the Report.  
There was a proposal for 2010 to update the names of the libraries, to  
their new hierarchical forms.  It was not accepted.  Thus, the  
Haskell'98 names are still part of the official 2010 language  
standard, if I am not mistaken.

There has been discussion about whether the Language Report should  
mandate any particular libraries at all.  No decision has yet been  
taken to remove the Libraries specification from the Report.

Perhaps some of these issues should be resolved for Haskell 2011, and  
I encourage those interested to develop a proposal on the haskell-
prime mailing list (which is open to all).

Regards,
     Malcolm

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

Re: Deprecating haskell98 module aliases

Gwern Branwen
In reply to this post by Gwern Branwen
On Mon, Mar 8, 2010 at 11:22 AM, Gwern Branwen <[hidden email]> wrote:
> See http://hackage.haskell.org/trac/hackage/ticket/640
>
> It seems to me that a warning on using the 'haskell98' package
> wouldn't be a bad thing; those modules have since been split apart in
> better modules, the names are ever more unfamiliar, etc.
>
> But Duncan thinks it merits discussion.

While removing haskell98 from packages last night, I found a few more
reasons to dislike it:

* it masks a whole grab-bag of split-base dependencies: random,
process, directory, old-locale, old-time, containers...
* 'import System' is extremely opaque - is the person using
System.Exit, System.Process, System.Environment or what?
* the exported haskell98 modules are out of date; I found Meachem
re-defining the functions repeatM and repeatM_ because a DrIFT module
imported Monad rather than Control.Monad.

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

Re: Deprecating haskell98 module aliases

Yitzchak Gale
In reply to this post by Henning Thielemann
Henning Thielemann wrote:
> Actually, when using GHCi I like to have the short Haskell98 module names.

I agree that the warning is less important in GHCi during
the deprecation stage.

However, for consistency, I think the Haskell98 names should
go away by default in GHCi when they go away in GHC.
You can always enable them manually if they are important
to you. Or use dot-ghci and/or :def commands to save
keystrokes when setting up your favorite GHCi environments.
That is probably a better idea anyway.

Regards,
Yitz
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating haskell98 module aliases

Neil Mitchell
In reply to this post by wren romano-2
Hi,

In discussion with Gwern I've raised a bug in HLint to make using
Haskell 98 modules a warning. It's not the same as a formal
deprecation of those modules, but it's a step in that direction. I
think deprecating haskell98 modules is a reasonable step to do at some
point in the future, but I don't think that point has arrived yet (we
should at least publish Haskell 2010 first).

Thanks, Neil

2010/3/8 wren ng thornton <[hidden email]>:

> Gwern Branwen wrote:
>>
>> wren ng thornton wrote:
>>>
>>> I'm all for the warnings. And regarding guest's comments, doesn't the
>>> Haskell 2010 standard[1] count as an "actual language standard"? If not,
>>> then what is it and why isn't it one?
>>>
>>> [1] http://www.haskell.org/pipermail/haskell/2009-November/021750.html
>>
>> Correct me if I'm wrong, but I thought 'HierarchicalModules' was an
>> extension which codifies the 'Foo.Bar' import syntax (as opposed to
>> 'import FooBar'), and didn't address allocation of functions to
>> modules  or naming issues like 'Char' vs 'Data.Char' or splitting
>> 'Foreign' up or whatever.
>
> AFAIK, yes, the HierarchicalModules approval is just allowing dots in module names, rather than discussing what goes where. I was bringing haskell2010 up more to point out that the haskell98 standard is, officially, not up to date.
>
> Perhaps we should poke the haskell-prime committee to move the official location of standard functions for the haskell2011 standard?
>
> --
> Live well,
> ~wren
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating haskell98 module aliases

Henning Thielemann-4
Neil Mitchell schrieb:
> Hi,
>
> In discussion with Gwern I've raised a bug in HLint to make using
> Haskell 98 modules a warning. It's not the same as a formal
> deprecation of those modules, but it's a step in that direction. I
> think deprecating haskell98 modules is a reasonable step to do at some
> point in the future, but I don't think that point has arrived yet (we
> should at least publish Haskell 2010 first).
>  
Maybe Cabal (or HLint) could at least warn about mixed use of haskell98
and base modules, but this would be certainly a hack in Cabal.

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

Re: Deprecating haskell98 module aliases

Bas van Dijk-2
In reply to this post by Gwern Branwen
For what's worth, here's the list of packages on hackage which depend
on haskell98:

http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/haskell98-1.0.1.1

regards,

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

Please don't deprecate Haskell 98 modules.

John Meacham
In reply to this post by Christian Maeder-2
Please don't deprecate these modules.

It is actively contributing to bitrot to deprecate a perfectly useful
and well defined API. When I write new code that only needs C, I don't
use C++ just because C is older. Likewise, when writing Haskell code
today that doesn't require anything more than haskell 98, I use haskell
98. Because it is a well defined standard that I know will be supported
by future and past compilers. Unlike writing to some current snapshot of
what the libraries look like.

Encouraging people to use bleeding edge APIs just contributes to the
already dicey problem of writing future and backwards compatible code in
Haskell, in fact, writing to haskell 98 is the _only_ option at the
moment with any ability to do so.

Haskell 98 should never be deprecated, because it is a stable, well defined
standard that useful programs can be written to if someone chooses to do
so and wants their code to have a chance of working down the road
without having to continually keep changing it to keep up with libraries
changes.

        John


--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Please don't deprecate Haskell 98 modules.

Christian Maeder-2
I'm all for supporting the haskell98 *language* (aka "portable" haskell
code) except wrt non-hierarchical module names.

Without hierarchical module names cabal and hackage are unperceivable.

In fact, the haskell98 modules are bit-rotten and the corresponding
hierarchical modules (like Data.List) are certainly no "bleeding edge
APIs", but the de-facto standard.

Christian

John Meacham schrieb:

> Please don't deprecate these modules.
>
> It is actively contributing to bitrot to deprecate a perfectly useful
> and well defined API. When I write new code that only needs C, I don't
> use C++ just because C is older. Likewise, when writing Haskell code
> today that doesn't require anything more than haskell 98, I use haskell
> 98. Because it is a well defined standard that I know will be supported
> by future and past compilers. Unlike writing to some current snapshot of
> what the libraries look like.
>
> Encouraging people to use bleeding edge APIs just contributes to the
> already dicey problem of writing future and backwards compatible code in
> Haskell, in fact, writing to haskell 98 is the _only_ option at the
> moment with any ability to do so.
>
> Haskell 98 should never be deprecated, because it is a stable, well defined
> standard that useful programs can be written to if someone chooses to do
> so and wants their code to have a chance of working down the road
> without having to continually keep changing it to keep up with libraries
> changes.
>
>         John
>
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Please don't deprecate Haskell 98 modules.

John Lato-2
In reply to this post by John Meacham
> From: John Meacham <[hidden email]>
>
> Please don't deprecate these modules.

> Encouraging people to use bleeding edge APIs just contributes to the
> already dicey problem of writing future and backwards compatible code in
> Haskell, in fact, writing to haskell 98 is the _only_ option at the
> moment with any ability to do so.

I was originally in favor of deprecating haskell98 but didn't care
enough to voice an opinion.  John's argument has convinced me
otherwise, so +1 to keeping haskell98.

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

Re: Please don't deprecate Haskell 98 modules.

Henning Thielemann-4
John Lato schrieb:

>
>> Encouraging people to use bleeding edge APIs just contributes to the
>> already dicey problem of writing future and backwards compatible code in
>> Haskell, in fact, writing to haskell 98 is the _only_ option at the
>> moment with any ability to do so.
>>    
>
> I was originally in favor of deprecating haskell98 but didn't care
> enough to voice an opinion.  John's argument has convinced me
> otherwise, so +1 to keeping haskell98.
>  
This would be compatible with the method "warn about packages that
depend on both haskell98 and base".

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

Re: Please don't deprecate Haskell 98 modules.

Jesper Louis Andersen-2
In reply to this post by John Lato-2
On Thu, Mar 11, 2010 at 11:25 AM, John Lato <[hidden email]> wrote:
>
> I was originally in favor of deprecating haskell98 but didn't care
> enough to voice an opinion.  John's argument has convinced me
> otherwise, so +1 to keeping haskell98.
>

In the Standard ML world, there was some traction on the idea of ML
Basis (MLB) files

http://mlton.org/MLBasis

The concept is, superficially, to support linkage and module work "in
the large" contrast to "in the small" which most module systems are
about.

As an example, you can pull a set of modules and in the process rename
them such that they do not conflict with yours. Or you can do the
opposite and export modules under different names than what you used
internally.

The real killer in this discussion is the ability to include a module
hierarchy from an older version of the standard library. Writing

local
  $(SML_LIB)/basis/basis-1997.mlb
in
  prog.sml
end

gives you the old (deprecated) SML Basis, whereas the declaration

local
  $(SML_LIB)/basis/basis.mlb
in
  prog.sml
end

gives you the newest basis hierarchy. Thus in effect, the system
supports the old code through a simple redeclaration of what library
to pull in.

More information is available at the link above, including examples of
how to support module import/export renaming.

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

Re: Please don't deprecate Haskell 98 modules.

John Lato-2
In reply to this post by Henning Thielemann-4
On Thu, Mar 11, 2010 at 12:18 PM, Henning Thielemann
<[hidden email]> wrote:

> John Lato schrieb:
>>
>>> Encouraging people to use bleeding edge APIs just contributes to the
>>> already dicey problem of writing future and backwards compatible code in
>>> Haskell, in fact, writing to haskell 98 is the _only_ option at the
>>> moment with any ability to do so.
>>>
>>
>> I was originally in favor of deprecating haskell98 but didn't care
>> enough to voice an opinion.  John's argument has convinced me
>> otherwise, so +1 to keeping haskell98.
>>
>
> This would be compatible with the method "warn about packages that depend on
> both haskell98 and base".
>

That seems sensible to me.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Please don't deprecate Haskell 98 modules.

Gwern Branwen
In reply to this post by John Meacham
On Wed, Mar 10, 2010 at 7:56 PM, John Meacham <[hidden email]> wrote:

> Please don't deprecate these modules.
>
> It is actively contributing to bitrot to deprecate a perfectly useful
> and well defined API. When I write new code that only needs C, I don't
> use C++ just because C is older. Likewise, when writing Haskell code
> today that doesn't require anything more than haskell 98, I use haskell
> 98. Because it is a well defined standard that I know will be supported
> by future and past compilers. Unlike writing to some current snapshot of
> what the libraries look like.
>
> Encouraging people to use bleeding edge APIs just contributes to the
> already dicey problem of writing future and backwards compatible code in
> Haskell, in fact, writing to haskell 98 is the _only_ option at the
> moment with any ability to do so.
>
> Haskell 98 should never be deprecated, because it is a stable, well defined
> standard that useful programs can be written to if someone chooses to do
> so and wants their code to have a chance of working down the road
> without having to continually keep changing it to keep up with libraries
> changes.
>
>        John

No one is talking about removing haskell98; my bug report is about
warning about use of it. You can go on using 'import Monad' if you
like - just like you can go on shadowing variables, omitting
pattern-matches & type sigs, naming unused variables, and defining
unused functions. Just like with haskell98, there are (contrived and
otherwise) scenarios where one actually wants to do those things,
which is why they aren't *errors*.

I don't think haskell98 meaningfully helps one write long-term code.
Something that helps long-term code is explicit imports, for example,
since it future-proofs one against added clashing function names and
makes it vastly easier for future programmers to update imports and
uses. But being able to write 'import List' versus 'import Data.List'?
No, I don't see that at all. What, are functions like 'isInfixOf'
going to be removed from Data.List though guaranteed to be in List?

Nor do you address the multiple strikes against haskell98 that I've
already adduced: that it encourages people (like you!) to duplicate
library code; that it leads to mixture of modern and old module names
(I'm not sure that I've yet run into a package which needed only
haskell98 and not also 'base'); that it hides the finer-grained
dependencies (reverse dependencies were linked; notice that each
package that depends on haskell98 may be screwing up the reverse
dependency list of process/random/containers/old-locale/...); etc.

--
gwern
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12