[Haskell-cafe] Re: List of exports of a module - are there alternatives?

2009-05-13 Thread Maurício 
I would like a keyword we could add to a single declaration,
like:

hidden a :: Int - Int
a = (...)

The 200 names is not the best example. It's more a question of
proportion: if you export 5 declarations in a module with 20,
it's OK, but if you export 19 declarations in a module of 20
maintenance can be painfull to your eyes, going up and down
into your file to check if the list is correct.

Maurício

 I would like to see this too. Maybe just a private keyword that would
 make everything after it invisible to the outside (or until a public
 keyword appeared)?
 
 Are there propositions to alternatives to that (I could not
 find one)? Like, say, add a do export or do not export
 tag to declarations we want to (not) export?

 (I think something like that could be nice when we have modules
 with 200 declarations and just a few are (not) going to be
 exported.)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: List of exports of a module - are there alternatives?

2009-05-13 Thread wren ng thornton 

Maurício wrote:

I would like a keyword we could add to a single declaration,
like:

hidden a :: Int - Int
a = (...)

The 200 names is not the best example. It's more a question of
proportion: if you export 5 declarations in a module with 20,
it's OK, but if you export 19 declarations in a module of 20
maintenance can be painfull to your eyes, going up and down
into your file to check if the list is correct.


It sounds like what you (may) want is a refactoring browser which can 
annotate definitions for whether they're exported or not. This would 
solve the maintenance issue without the need for a language change. I 
don't know whether Leksah[1] or Yi[2] can do this, but if not it should 
be easy to add and it's a reasonable feature to request.


Everyone agrees that the module system in Haskell98+HierarchicalModules 
is the weakest thing we could get away with at the time, and also that 
it's in need of serious redesign now that we have large scale projects 
which are straining those boundaries. However, as with the other folks 
on this thread, I don't think that a new keyword is the proper path for 
extending the design. Too ad-hoc, too Java/C++ like, it just doesn't 
have the feel of a fluent, principled, modular, extensible design.



[1] http://leksah.org/
[2] http://www.haskell.org/haskellwiki/Yi

--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe