public/private module sections (was Re[2]: Export lists in modules)

[Claus Reinke]

>>>> modules M exports
>>>> 
>>>> class Eq a where
>>>>   (==) :: a -> a -> Bool
>>>> 
>>>> data T :: * -> *
>>>> f :: T -> Int
>>>> mkT :: Int -> T
>>>> 
>>>> where -- implementation below here
>>>> --------------------------------------
> 
> SM> The main difference is that I'm doing away with parentheses, commas, and
> SM> export specifiers, and using layout and full declaration syntax instead.
> SM> (I don't really want to discuss this very rough idea any more though,
> SM> it's just a distraction, and I'm not sure I like it anyway).

let's have a closer look before we dump this again, shall we?-)

if you'd go one step further, you'd replace the public/private modifiers
with public/private module sections. I don't like the modifiers, and I'm 
uncertain about the intermediate form you suggested, but I might be 
able to live with two-section modules:

nothing is duplicated, the public and private items are clearly grouped.
if you like to make the public section look more like an interface, you 
only use short definitions in it (could this be made to work for data type
constructors/class members?).

another neat consequence not available with the other alternatives:
instances could be private (without having to be named), instead of 
flooding into importing modules. 

proper interfaces would still be nice (and useful!), but the general 
opinion seems to be that they're beyond Haskell' (what isn't, really?-).

about tools:
tools can relieve some of pressure on the language design (which is why
I'm more in the camp "a language definition should not ignore tools" now!-).

but the wrong language design can make the tools' job awkward, so it 
may be useful to look at what a tool can/cannot do:

1 ides may let you browse interfaces, but they don't give a standard form
    of printing those interfaces with the modules they belong to, nor even
    a standard form of those interfaces..

2 ides let you see different locations in your sources in a single window
    (I use this whenever I need to modify the imports while editing in the
    middle of my module; I sometimes use this to see the definition of the
    data types I'm working on). that means that the link between definitions
    and import lists can be implicit, and browsing may bypass import lists/
    export interfaces entirely. that holds for both browsing and navigation.

3 ides can add/remove items from the imports "remotely" (HaRe does 
    this). they can also generate explicit export/import lists (even my old 
    Hugs.vim supported that), and add types in comments, but if they do 
    so, it is not clear what to do with comments already present (update 
    any types in them? what if they were meant to document alternative/
    old/comming versions..; leave any unidentified comments alone? then 
    we'll duplicate type comments as soon as someone adds any text to
    the automatically generated non-interface..)

4 ides can use tooltips to tell you whether the stuff you're looking at
    is exported or not, but again, that won't usually make it into printouts.

look at the problem from this perspective, and you see that

- haskell98 fails 1/4, profits from (and really needs) 2, doesn't support 
    3 all that well
- public/private modifiers only help with 4, part of their job is covered 
    by 3 already
- public/private sections solve 1/4, may still use 2/3 

so, public/private sections seem to support all pragmatic issues, and
since they're still just haskell code, don't suffer from duplication/scoping/..
issues, either. in fact, we might end up simplifying the syntax be removing
export lists! but exposing only some data constructors of a data type 
would be awkward?

cheers,
claus