On 1/7/08, Trey Harris wrote:
In a message dated Mon, 7 Jan 2008, Richard Hainsworth writes:
May I suggest the following extension to the 'use ' pragma, viz.
use <module name written in unicode and case sensitive> in
<filename as constrained by local system>
Oh please, no.
The entire point of the wording currently in the synopsis is so that
we can have platform-independent location of libraries. The "name
mangling capability" hypothesized lets the same C<use> get the
requested resource, regardless of the file (or database location!)
where the resource is actually located on the platform running Perl.
Yes, and having a proper library-manager to take care of all those
details will be a big improvement (e.g. Perl/Parrot can cache
pre-compiled versions because the library will know when things
change and need updating). But that comes at a cost: you can't
simply use some file you have lying about, you have to "load" it into
the library somehow first. So I'll run something like "plib load
--lang=perl some/file/path.pm", which takes care of specifying the
<filename as constrained by local system>. (Parrot will figure out
the module name by looking in the module itself.)
Still, we also want a way to use arbitrary files without the overhead
of going through the official library; something similar to the way
Perl 5 searches the current dir (if a requested module isn't in the
"library", which for P5 is just a list of dirs in @INC -- well, "."
is just the last element of @INC by default, so I guess it's part of
the "library" too). So we do need a way to say "look in the current
dir" or "look in this place" for bare files. And presumably you can
still say "use lib 'path'" in P6; but then we will need a way to
specify how to translate the module name into a filename.
That still doesn't mean that you need to be able to specify the
translation -- it could be predetermined, based on the OS/filesystem
you're using (e.g. if you're running Windows, the rule might be files
have to end in ".pm"; if you're using HFS+ on a Mac, it will look for
a case-insensitive filename; for ISO-9660, Unicode chars might have
to be %-encoded, etc.). (That assumes we can always tell what FS
we're using.)
However, that also means that the filename (however encoded) has to
match the module name. That's often fine, but sometimes
inconvenient. (E.g. the default translation policy might specify
that the local filepath would have to be 7 subdirs deep.) It'd be
much nicer to be able to say something like: use
Some::Fancy::Module::Name::Supercalifragilisticexpialidocious in
"./Supe.new".
I'm not worried about platform-independence because this is something
that typically applies when you're developing a module; once you're
ready to deploy or distribute it, you'd probably make a package that
officially "librarified" anything that needed to be. Portability,
independence, etc. are very important, but I don't think they should
be mandatory unless you can get them for free, and library-management
cannot be completely transparent, so there should be ways around it.
The .tar, etc., are typically named for transport, where you may
need to know the filetype without having the benefit of its contents
for examination. *.pdf and *.doc are filetypes that did not exist
until after Windows did, and so the required-extension behavior
ossified. The .* convention merely came about because it was a
convenient kludge put into ls for the purpose.
To be fair, they're all "convenient kludges" -- the problem isn't
Windows per se, the problem is filesystems that don't have a real
place for type metadata, which includes Unix as much as DOS, er,
Windows. Knowing the type of a file is valuable for lots of reasons;
it's just that in pre-GUI days, the primitive command-line interface
obscured some of the primitiveness of the FS.
So if I choose to call my perl6 scripts *.p6 it should not matter?
Other than for the sake of tradition or conformity with the tribe's
sense of propriety :)
Sure, knock yourself out. Call it ".perl6" if you like, or
".niftynewlanguagethatisn'tquitecompatiblewith.pl" (except those
violate eight.3 rules).
If one extension is bad, then surely a dozen are worse? So although
technically it's not necessary (personally, I hate filename
extensions), lots of people will be using them anyway -- we may as
well come up with a suggested community preference rather than
everyone coming up with something different.
And that configuration file would be a huge comb of $?OS and $?OSVER
switches in a typical platform-independent development. And even
so, the whole thing would be far more brittle than the
automatic-location system we have today, as problematic as it is
(not very, actually...).
Yup. Although I can't resist pointing out the that system we have
today uses extensions. Well, you could argue that the required ".pm"
is a "suffix" rather than an "extension" (in the Windows sense). I
think a primary raison d'etre is so you can have a module "Foo" which
is really Foo.pm and a directory "Foo" for sub-modules. But not
being allowed to have a file and a dir of the same name is itself
merely an unnecessary restriction that just happens to be implemented
by some currently-popular filesystems.
-David
