On 28/05/2011, at 3:37 PM, Brandon Allbery wrote:

On Fri, May 27, 2011 at 23:10, Tom Murphy wrote:

...

I sure love Hackage, but there's a very interesting discussion going on, on the Erlang mailing list, about completely restructuring the module-model.

Sounds like one of those ideas that looks really neat on paper but in the real world runs up against the fact that we're absolutely *abysmal* at managing that much metadata, and our programs to do so mostly reflect our inabilities.

It's fair to say that nobody on the Erlang mailing list was terribly keen on the idea. People have testing and documentation and deployment strategies based on modules that they'd rather not give up. It seems fairly clear that it's not something you can add incrementally to a language: you'd need a massive new 'ecosystem for code', and the difficulties people have expressed here with finding things in Hackage would be doubled and redoubled to say the least of it. On the other hand, modules as we now know them look like very small objects in the light of the giant systems they are part of. (I had to download a new copy of Eclipse today. Good grief; to think people used to whinge about the size of *emacs*!) So maybe it's less of a jump than people think.

Regardless of how crazy it sounds, an idea from Joe Armstrong is worth seriously thinking over. 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? Erlang has the advantage of functions being the basic, composeable building block. Packages and modules are merely means to organize them, and mediocre means at that, so a better system is definitely a possibility. Haskell has the complication of having type definitions in addition to functions. On Sat, May 28, 2011 at 1:09 AM, Dmitry Vyal wrote:

On 28.05.2011 07:10, Tom Murphy wrote:

...

Hi All, I sure love Hackage, but there's a very interesting discussion going on, on the Erlang mailing list, about completely restructuring the module-model. Before you dismiss it as crazy, know that the topic was brought up by Joe Armstrong, one of the creators of the language.

Here's the archive: http://erlang.org/pipermail/erlang-questions/2011-May/058769.html

Food for thought...

Tom

Hi Tom, sounds interesting! But seems to me this will raise current package dependencies problems on a new level. Now one sees modules and packages as some kind of aggregates, black boxes which supply useful functionality and hide non relevant complexity and tight dependencies.

Moving to functions all the way down looks to me like a lowering level of abstraction. The meta information about the overall program structure would inevitably be lost.

Dmitry

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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....

On 5/28/11 10:11 AM, Alex Rozenshteyn wrote:

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.

Aww... I read that paper and got really excited thinking, "Wow! I didn't realize that people were working on that; I wonder when I'll get to play with it!", and then I saw the paper was written for a seminar that took place in 2002, so I guess the idea just didn't pan out... Would anyone involved in the matter want be so kind as to fill me in on how that particular story ended (i.e., why everyone gave up it)? Thanks! Greg

On Sat, May 28, 2011 at 13:34, Ketil Malde wrote:

Tom Murphy writes:

...

     Before you dismiss it as crazy, know that the topic was brought up by Joe Armstrong

Being brilliant doesn't mean the absence of mental bad hair days, but merely that they happen more rarely than for the rest of us. :-)

I was kinda angling for "brilliant idea, unfortunately only usable by brilliant people". Most of us would be lost in such a system, and wait until you see what kind of namespace grows out of that setup's Hackage-equivalent because most programmers simply don't have the extremely high level of discipline and organization needed to make it work.