Timothy, thanks for your feedback.
My proposal was never about the syntax, which I stated at the end, but rather my
syntax was just illustrative. I actually meant for p{} or whatever syntax to be
used, but I didn't recall those details and was keeping it simple. And the use
of a %DOI hash was just illustrative, meant to evoke how you set signal handlers
in Perl 5, and in no way does that syntax need to be used.
The idea of starting all paths with "<doi>/" rather than "/" was to first imply
that there was no single root, and also for consistency in that the one
representing "/" has the *same* syntax as all the others.
I wasn't actually proposing using "fsroot", etc as the names; those were just
examples, and in fact my proposal was about users picking what names they want,
so my list of 6 examples, such as "docs", was meant to represent something users
might pick and name for their own circumstances, not that these are built-ins.
Come to think of it, if a "<doi>" is allowed to be any string at all, like a
hash key can, then the system-defined one representing the real filesystem root,
"/", could just be the empty string, which means that you end up using the exact
same "/" syntax as you're already used to, and it means the same thing. So then
under my proposal, its more that the syntax for relative urls like "foo/bar" has
had its meaning changed so "foo" is a doi rather than a subdir of the single CWD.
While I didn't explicitly state it, the roots that came system-defined could
conceivably also be altered by the user, eg they could redefine
whatever-"fsroot"-is-called, which incidentally would result in them chroot-ing
themselves. This also means that part of what I had in mind is that you can't
use a relative url to go to some parent/sibling of a "doi" by way of that "doi",
meaning all urls visually are absolute. This might mean that the name
"bookmark" isn't as appropriate if it implies you can go to a parent of the
"doi" by way of it, but this is a minor quibble and if the feature is called
"bookmark" I won't really object.
-- Darren Duncan
Timothy S. Nelson wrote:
On Wed, 19 Aug 2009, Darren Duncan wrote:
My proposal is to have all filesystem paths as seen within Perl being
relative paths, and that there are multiple filesystem roots which can
be referred to by name and each relative path is explicitly relative
to a named root; each of these named roots is called a "directory of
interest" or "doi".
I briefly mentioned a similar idea, but with no theoretical
background :). I would've called them "bookmarks" instead of "doi",
though.
For those who shied away from Darren's large theoretical background,
fearing that it would lead to "pie-in-the-sky" or something, the simple
version of his proposal was to have a magic global hash, and have it
work like:
%*DOI<home> = "/home/foo";
$path = p{home/Music}; # $path points at /home/foo/Music
I disagree with the syntax, but the idea has merit.
Your idea for making everything a relative path isn't one that
appeal to me. But having a predefined set of bookmarks that could be
used is certainly an interesting idea.
I don't like your syntax, though :). But see below.
fsroot - the root of the real file system, analogous to "/"
I think we should stick with / as it's well-understood. Unless the
Windows users among us see some advantage to fsroot -- I'd be happy to
discuss it with them.
fscwd - the dir that was the fs CWD when Perl started up
Stick with $*CWD for this, I reckon, and have it implicit in all
paths that don't start with an absolute path. But all the other
variables below should be absolute paths.
docs - the dir that contains the usual files we want to work with
temp - the dir where we can put temporary files
home - the current user's home dir
mycwd - some other cwd-dir, which is virtual-changeable in Perl
Vote yes to temp and home. Don't understand what you mean by "docs".
So to refer to common things on a Unix system like the fully-qualified
ways, you can write paths like:
fsroot/home/me/myfile
fsroot/usr/bin/perl
fsroot
This is a great example of why fsroot is a bad idea.
For something analogous to traditional CWD sans modifications:
fscwd/mynewfile.txt
fscwd/lib/doit.pl
...and a great example of why fscwd is a bad idea.
To define a new doi at runtime, something like:
%DOI{'mycwd'} = %DOI{'fscwd'};
%DOI{'mycwd'} ~= 'subdir';
# later
my $fh = IO.open( 'mycwd/myfile.txt' );
If I were doing it, I'd make it look like this:
%bookmark<mycwd> = $*CWD;
%bookmark<mycwd>.push('subdir');
# later
my $fh = IO.open( p{#mycwd#/myfile.txt} );
The only part I don't like is marking the "mycwd" with the hashes.
I think we can't do without markers altogether because it would
absolutely confuse everyone :). Putting a hash before and after is also
a bad idea because it's like nothing else in Perl.
The only other idea I can think of is to come up with another quote
adverb/pragma pair. Something like:
use hashinterpolate %*bookmark;
...and have the :hi (short for :hashinterpolate) quote modifier make
$mycwd refer to %*bookmark<mycwd>, and then have :path automatically do
:hi as well, unless :qq is used, or something.
Anyway, I home someone who knows more about Perl interpolation than
me has an idea here.
Anyway, I like my terminology better, because it's less scary, and
I've shaved off some of the scariest bits of syntax from your proposal,
but there is still some work to be done on it here.
HTH,
