[racket-dev] package name restrictions - why?

On 07/31/2013 02:42 PM, Matthew Flatt wrote:
> Package names show up in all sorts of other contexts, too, such as
> filesystem paths.

Sure, but if there's something that won't work as a filesystem path, the 
developer finds that out awfully quickly.

> Note that the programming language in which we'd have to deal with
> encoding is sometimes not nearly as nice as Racket. For example,
> including a package with "$" in its name as part of a `PKGS=...'
> argument to `make' is going to fail in lots of ways (since the `PKGS'
> value flows back and worth between `make' and `sh' or `cmd.exe').

Yes. (Does this say something about the PKGS= argument to make?)

I don't care about "$" so much, but I do care about ".". If there are 
good reasons for a particular restriction, so be it, but the current 
restriction feels unnecessarily tight.

> Finally, there's the question of inference that `raco pkg install' and
> other tools perform on a string that represents a package source.
> Keeping the package-name grammar simple makes that inference more
> predictable.

Do you have an example in mind? I can imagine permitting ":" in package 
names would make this difficult, but other than that, my imagination is 
failing me in coming up with something that'd make inference trickier.

> I see what you mean, and yet "foobar.rkt" seems like a strange name for
> a Racket package. In particular, I'd expect it to be inferred as a
> filename source, instead of a package-name source, if we ever manage to
> make individual files act as packages (as some have suggested).

That's a problem we don't have right now. But I do have the problem of a 
git repo named "something.rkt" which I'd like to straightforwardly use 
as a package.

Cheers,
   Tony