public/private module sections (was: Haskell-prime Digest, Vol 2, Issue 58)

[Claus Reinke]

>I feel unkeen.

you will notice that I haven't actually proposed adopting this (yet:-);
neither did Simon M for his original version. so far, I had thought
Haskell's export/import language quite limited, but useable and simple.
so apart from fixing the asymmetries between export and import, and
adding a few missing features, I wasn't expecting much change.

So, I was surprised to see that following the route of sections and
dropping export lists altogether might actually simplify the language and
accomodate other proposed variations more easily than the current
system. it isn't often that we find such opportunities in language design.

yes, this would add one constraint on where to place definitions. but
grouping logically related definitions together is not quite what one 
might think anyway: aren't the definitions making up the interface
most strongly related, with the others just changeable auxiliaries?
and how do you flatten the graph of mutually related (according to
one of many possible criteria) definitions, without separating some
of them? even refactoring does not solve this - you can't rewrite
your code (even automatically) any time you want to take a different
view on your sources. 

in other words, you can only _partially_ support _one_ of many
relations by actual proximity. everything beyond falls firmly into
tool support for virtual proximity (creating useful views of your
sources on the fly, without changing the sources, as needed).

for instance, I really dislike the public/private modifier idea
because it splatters logically related items from the export interface
and the definition of said interface all over the source code, so I 
need a tool to gather the interface definition back together;-)

even with the current system, I constantly need tool support
to keep one auxiliary view on the module header while editing 
its body, and another auxiliary view on the definitions of any
imported items I might be using. and though I always start with 
related definitions close together, it usually doesn't take long 
before that fails for some reason or other (not to mention that 
my view of what should be related changes all the time 
depending on what I'm doing).

the other problem you mention is that either the export section
would contain code (rather than just names) or synonym definitions
(rather than just names). that is true, and I don't particularly like
this (especially the second bit), but I can't see yet to what extent 
that problem would bite in practice. code navigation should 
certainly not be an issue here (even the ageing vim supports tag
stacks, and ghc head has supported tag file generation for some
time now; hmm, that reminds me that we should have hugs-style
editor integration in ghci..).

as for Haddock, it seems to have won the fight for the documentation
niche, so it would be nice to have it available with every Haskell
installation. but generally, the availability of a specific tool is not a
prerequisite for aiming for a balance between language and tool
design. you just need committment to building/distributing and
maintaining some tool to cover the issue (e.g., both ghci and hugs
support the :browse <module> command, which is about the
easiest way to extract the interface; and that has been used in
at least one editor mode, without needing Haddock).

what is a prerequisite is that the language definition does not
ignore tools, and that -apart from balancing the responsibilities
of language and tools- the definition provides foundations on
which tool building would be supported more easily than today.

cheers,
claus