
Since no-one has yet mentioned it, and I think it might be relevant,
http://types.bu.edu/seminar-modularity/first-class-modules-for-haskell.pdf
I haven't read it with any degree of understanding, but I don't think it's
tractable to remove modules from haskell, nor desirable.
On Sat, May 28, 2011 at 6:17 AM, Brandon Allbery
On Sat, May 28, 2011 at 05:12, Alex Kropivny
wrote: Regardless of how crazy it sounds, an idea from Joe Armstrong is worth seriously thinking over.
Possibly, but this is just another manifestation of a general problem that nobody has yet managed to solve very nicely. Admittedly, the way Erlang handles its function namespace, it's both easier to consider this (due to the only metadata being function name and arity) and somewhat sensible to do so (because of the relative lack of organization methods, coupled to the lack of metadata). This won't work for any language which needs to use type information in its metadata; it's a bad idea for Haskell and an absolute terror to contemplate for C++.
This has bugged me before: think about how we design and write code as project size, or programmer skill grows. You start with composing statements inside a single function; later, you start to compose functions inside a single file; later you move on to composing modules; subsystems; systems... Different techniques, doing the same thing in different ways, depending on the level of complexity. Surely there's some unified approach that can replace them all?
I'd start poking from the direction of (a generalization of) ML modules, to be honest. Said generalization would be a hierarchical, parameterizeable namespace, which you could operate on with (possibly meta-versions of) the usual Haskell morphisms: map/fmap, folds, zippers, etc. Or arrows if you prefer that way.
Unfortunately, probably because I'm still pretty much a beginner at higher order thinking, when I try to make this notion concrete I end up with something rather Template Haskell-ish. This suggests that I should hand it off to someone named Oleg or Simon to chew on and see if it can be turned into something useful, usable, and practical....
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Alex R