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.

Your proposal would force us to have platform-dependent locations, and hence platform-dependent programs. Do you really want to see dozens of switches like

  given $?OS {
     when m:i:/win/ { use Foo in }
     when m:i:/nix/ { use Foo in }

at the top of programs?

The broken operating system, or rather family of systems (and I converted away from them about three years ago), still is used by 90% of users. In practice, it does matter what happens in that environment.

Yes--but better for implementators to make that decision than for each and every Perl programmer (most of whom will have no experience with most OS's Perl runs on, so will be making such decisions blind!) to make them separately (and differently).

But also consider, whatever operating system is in use, it has to know how by default to handle a file - interpret it as a script, run it as a native executable, pipe it to an editor or renderer etc. That information has to be associated with the file in some way. One operating system uses name extensions, another looks at the first line for a #! etc.

Personally, I find it useful to have a visible clue in the name (via an extension) as to the content of the file. This seems to me more widespread than just an OS requirement, as otherwise why have *.tar *.tar.gz *.pdf *.doc *.png etc or even .* for hidden files in unix?

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.

By way of illustration,
   % mv foo.png foo.jpg
does not convert the file's image type. If it did (or if it refused to do the move) you'd have an argument there.

If it doesnt matter - as far as perl6 is concerned - how the module is named (see Larry Wall's response regarding unicode and case-sensitivity), then the extensions too are irrelevant, no? 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'" (except those violate eight.3 rules).

And that brings me to another question. Should it matter what the name of the file is? For modules in perl5 as far as I can discern, the name of the module in the file name has to conform with the package name inside the script. I have found this default behaviour annoying at times.

To do otherwise is to again require platform-dependence. If you truly want to force it, load the code manually with C<require> in a C<BEGIN> block.

By extending the 'use' pragma to include information about which container it can be found in, filenames become truly irrelevant.

Quite to the contrary--they become much more relevant.

Moreover, the initiation file for a large project might just be a configuration file containing all the module names, together with "use Main <main> in ProjectDebugStage.v03"

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...).


Reply via email to