Module System

[Henrik Nilsson]

Hi Georg,

Georg wrote:

 > Well, the hierarchical module system as it is implemented today and
 > how it is proposed for being included into Haskell' uses the file
 > system to locate modules.

Yes, tools need to, somehow, locate modules.

Yes, for portability reasons, it is convenient if tools support common
conventions.

But that does not mean that the *language standard* should nail down
these details.

 > It could of course be a mapping like I think John Meacham proposed
 > with dots or whatever you like, but the point is that:
 > 1) You need some (preferable hierarchical) storage to reflect the
 > structure of  your modules

No, you don't. What is, in principle, wrong with a Haskell
implementation that scans whatever files it is given as input,
determines the modules in them, and compile those? That would even allow
multiple modules in one file, and possibly facilitate compilation of
mutually recursive modules.

I wrote such a compiler once.
One can argue about wheteher that's a good approach or not,
but why shouldn't that be an acceptable implementation?

When it comes to precompiled library hierarchies, they are specific
to particular compilers. Why should the language standard say anything
about how that compiler should organize its libraries? Leave that
decision to the implementors.

 > 2) All file systems I know provide hierarchical structures

Yes. But future file systems may go beyond that, towards a more
database-like organization, say. While I don't seriously
suggest that would imply that there wouldn't be support for
hierarchical names as well, why should tools not be able to
exploit such new facilities?

 > 3) All files in one place seems not to be a feasible solution for
 > larger project and reusability, I think.

No, that wasn't what said.
I simply said that whoever is in charge of a project, is the one
pest placed to decide how the source files should be organized.

And if they happen to want to put the files into a database,
and have some Haskell implementation that supports that, then all
the power to them.

 > True, but do these differences matter to us? Sorry for my naivety, but
 > I can't see that much problems, expect very old 8.3 restrictions, but
 > they are history now!

For all conceivable systems one possibly might want to run a
Haskell system on?

E.g. Hugs has a very small foot-print and could be made to run,
say, in a pretty-small embedded system on top of how-knows what
kind of arcane real-time OS?

And what other restrictions on lengths etc. are there out there?

Anyway that is beside the point. The point is that to have a
solid language definition, one would have to decide on a
specific set of file systems to support, or at least
nail down a minimal set of features that a file system must have,
thus potentially ruling out certain present or future file systems
and/or operating environments.

 > If you leave everything to the programming environment, it is very
 > complicated  to organise a project for multiple
 > environments/compilers.

I think e.g. Cabal and related efforts are a testimonial to the
opposite.

All the best,

/Henrik

-- 
Henrik Nilsson
School of Computer Science and Information Technology
The University of Nottingham
nhn at cs.nott.ac.uk

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.