
On 17 September 2013 09:35, Evan Laforge
On Mon, Sep 16, 2013 at 4:09 PM, Wvv
wrote: I suggest to add instead of (or with) export section Pragma EXPORT:
I doubt this has much chance, since haskell already made its choice here a long time ago (and even if it were still up for discussion, PRAGMA isn't right for it), but this brings up a design question I've had.
I too prefer to declare visibility on the declaration rather than in a separate list. C doesn't really have a proper module system, but header files are effectively a separate module signature. C++ and Java and go preferred to mark visibility on the declaration. The ML family keeps visibility and declarations separate, which is where I assume haskell got it (that or maybe modula?). In the case of the MLs, though, it's a much more developed concept, since they have module signatures and functors and all that.
In light of haskell's very basic module system, is there any particular philosophical reason to prefer a separate export list? Or are those who prefer it for practical reasons? The only thing I can think of is that it provides a nice summary of the module, which haddock capitalizes on. But when I want a summary, I look at haddock, which would already be capable of hiding internal definitions. I have heard that haskell's module system was originally intended as a kind of simple-as-possible placeholder (like records... cough cough), maybe the designers though an ML-style module system might eventually materialize?
To me it's always been a hassle to have to jump to the top of the file and fiddle with the export list, so much so that I tend to leave it off until a module is pretty stabilized. It can also be confusing when the export list is in a different order from the declarations. Sometimes I want to explicitly mark something private, and simply "doesn't happen to be in the export list" is too implicit, so I wind up putting a _ on it.
None of this is a big deal, but I'm curious about other's opinions on it. Are there strengths to the separate export list that I'm missing?
I do like the actual "summary" aspect as you've noted, as I can at times be looking through the actual code rather than haddock documentation when exploring new code (or even trying to remember what I wrote in old code). It also makes actual definitions cleaner/shorter rather than cluttering them with extra annotations (either PRAGMAs or public/private markers), though this is not that big of a deal.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com