Re: [Scheme-reports] Ballot item #113 "directory contents"

[Alaric Snell-Pym <alaric@x>]

On 01/12/11 15:58, Thomas Bushnell, BSG wrote:
> On Tue, Jan 11, 2011 at 6:53 AM, Alaric Snell-Pym
> <alaric@x>wrote:
>
>> Aye; my preference, rather than encouraging too much string arithmetic,
>> is to provide functions to convert lists of strings to and from paths in
>> the local convention (including mapping special relative-path
>> conventions like ".", "..", and a leading "/" as appropriate). But let
>> WG2 ponder on that. I'll be sure to follow their deliberations and bend
>> John's ear with my opinions in due course, should I see them straying
>> from the path of sanity ;-)

> What about systems which don't have files, or don't have hierarchical paths?

That's fine; they can either lack the filesystem interface altogether,
or stub it out with a static single directory containing "device
special" files for available serial ports or whatnot. Non-hierarchial
systems can just have a root directory, and attempting to create
subdirectories fails (maybe there'll even be a cond-expandable feature
list to see how sophisticated the filesystem is).

As for more general filesystem organisations than hierarchies - right
now, most of the implementations of those I've seen proposed map into a
hierarchy anyway (even if it's one with lots of aliasing), as that's
baked hard into POSIX and other filesystem interfaces. If not, they tend
to have their own entirely separate interface, as there's not much by
way of portable ways to integrate them. Systems like Mac OS have an
underlying hierarchy of "actual names", and then a searchable
metadata-index that can be consulted to obtain pathnames given
non-hierarchical specifications... so fit a non-hierarchical system
alongside a hierarchy.

> Is it really the job of the language to specify the topology of the
> filesystem?

No, but it's the job of a standard to specify how to talk to the common
case of a vaguely POSIXy filesystem (whether that standard is part of
the language or something like an SRFI is a matter of definitions, as
long as Scheme apps that want to interact with the filesystem can do so
portably, where such a filesystem exists)

>
> Thomas
>

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports