implementation of file-related modules

[Isaac Jones]

Jan-Willem Maessen <jmaessen at MIT.EDU> writes:

> Alastair Reid <alastair at reid-consulting-uk.ltd.uk> writes:
>> Following Java's lead and using configuration files to localize a
>> system would potentially allow us to ship portable bytecode files
>> around from one platform to another.
>
> Actually, just delaying binding to System.Directory.Native would be
> enough (and I bet in such a system we'd want to delay binding to the
> prelude).

So how would this work?  Some #ifdef sections in the implementations
that bind System.Directory.Native, depending on which platform we're
on?  Would this be very hard?  Are there more complex issues that I'm
not seeing?

>> A general mechanism for accessing configuration strings would be useful.
>
> Anyone taking up this task would get to choose a format.  A chance to
> foist your aesthetics on the community!  Surely that's irresistable to
> *somebody*. 

I like the idea of type safety, but the configuration strings are
probably still useful for some things.  How might this look?

- A constant CONFDIR (#ifdef'd into the implementations) telling where
  to find configuration files (a kind of bootstrapping)

- A configuration file in CONFIGDIR with (var, val) tuples

- The runtime system reads this file at startup?

The virtue of this is that there is less work for the haskell
implementors if there's just one #ifdef and everything else comes in
as strings.

Reading the file at runtime, however, seems a little strange since
lots of the stuff we're talking about is actually known when you build
the compiler.

OTOH, maybe the work of having #ifdefs in the implementations isn't
that hard?  Obviously, there's platform-dependent configuration going
on, but is there any going on that is eventually made available as
constants or functions?  Is there an implementation-neutral way to
implement this?

peace,

isaac