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
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
