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