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 <allber...@gmail.com>wrote: > On Sat, May 28, 2011 at 05:12, Alex Kropivny <alex.kropi...@gmail.com> > 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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
