mai99dgf at studserv.uni-leipzig.de
Tue Feb 21 12:04:45 EST 2006
On Tuesday 21 February 2006 16:50, Henrik Nilsson wrote:
> Hi all,
> Georg Martius wrote:
> > I have some proposals for changes of the hierarchical module system as
> > it is at the moment.
> > [...]
> > The hierarchical name can be derived from the place in the filesystem.
> This is not a comment about the above proposal in itself, which arguably
> has its merits, but rather a meta comment.
> I get very anxious whenever I see "the file system" being mentioned
> in the context of a *language* specification (as opposed to, say,
> a specification of standard language libraries for interfacing with
> file systems).
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. 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
2) All file systems I know provide hierarchical structures
3) All files in one place seems not to be a feasible solution for larger
project and reusability, I think.
> Some reasons:
> * File systems have all kinds of quirks one would rather not deal with
> in a language spec.
> * File systems can differ radically between different operating systems.
> In fact, even within an OS, as OS's these days tend to support many
> file systems simultaneously.
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
> * A valid module names in a language is not necessarily the same
> as a valid file name. (Yes, bijective mappings could be defined,
> but they would only be valid for a specific set of file systems.)
We don't need bijection, we only need Haskell->Filesystem, which in all means
should not be a problem.
> * Even if we assume that the notion of a hierachical module name space
> always can be mapped to a corresponding file hierarchy in a simple
> way, why should that assumption be made in a language specification?
> In my opinion it is the task of the programming environment to locate
> the source files and interfaces that make up a semantically meaningful
> unit, and that semantics should be completely independent of where
> the different pieces happen to be stored.
If you leave everything to the programming environment, it is very complicated
to organise a project for multiple environments/compilers.
> I'm already somewhat unhappy about the way most present Haskell tools
> map module names to path names (I'd generally prefer to have the
> possibility to flatten my file hierarchies by, say, using dots in
> my file names), but at least these assumptions are not in the Haskell
> 98 language definition.
> So, please, to the extent possible, let's keep the file system
> out of the Haskell' definition!
> All the best,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.haskell.org//pipermail/haskell-prime/attachments/20060221/191be7a8/attachment.bin
More information about the Haskell-prime