[racket-dev] package name restrictions - why?
Hi all, Package names are restricted as follows, per the documentation: a package name — a string made of the characters a through z, A through Z, 0 through 9, _, and -. Why does this restriction exist? Programmers never see package names when using (require); Operators see package names only when they use raco pkg; otherwise they're just strings, surely? Cheers, Tony _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package name restrictions - why?
The restriction is primarily because they appear in URLs as single path segments. Jay On Wed, Jul 31, 2013 at 11:50 AM, Tony Garnock-Jones to...@ccs.neu.edu wrote: Hi all, Package names are restricted as follows, per the documentation: a package name — a string made of the characters a through z, A through Z, 0 through 9, _, and -. Why does this restriction exist? Programmers never see package names when using (require); Operators see package names only when they use raco pkg; otherwise they're just strings, surely? Cheers, Tony _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package name restrictions - why?
On 07/31/2013 02:11 PM, Jay McCarthy wrote: The restriction is primarily because they appear in URLs as single path segments. Could we then widen the restriction to be [-A-Za-z0-9._~!$'()*+,;=], following http://tools.ietf.org/html/rfc3986#section-3.3 (but disallowing percent-escaping)? I ask because I find the occasional package whose git repo is named foobar.rkt/, and it's inconvenient to have to (a) make up and (b) remember a package name different from foobar.rkt for that case. Tony _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package name restrictions - why?
At Wed, 31 Jul 2013 14:17:18 -0400, Tony Garnock-Jones wrote: On 07/31/2013 02:11 PM, Jay McCarthy wrote: The restriction is primarily because they appear in URLs as single path segments. Could we then widen the restriction to be [-A-Za-z0-9._~!$'()*+,;=], following http://tools.ietf.org/html/rfc3986#section-3.3 (but disallowing percent-escaping)? Package names show up in all sorts of other contexts, too, such as filesystem paths. In all cases, there is some encoding that would work, but it's a pain and a source of subtle bugs. 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'). 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. I ask because I find the occasional package whose git repo is named foobar.rkt/, and it's inconvenient to have to (a) make up and (b) remember a package name different from foobar.rkt for that case. 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). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package name restrictions - why?
At Wed, 31 Jul 2013 15:02:34 -0400, Tony Garnock-Jones wrote: 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. Now that I think about it, we do have the problem now with foobar.zip, which is inferred to be a file name (and I think we want to keep that). In other words, simply allowing . in a package name would already create some amount of inference trouble/complexity. I'm sympathetic to the idea of relaxing the syntax of package names, and I started in that direction a couple of times for different characters --- but I ran into trouble each time and backed off. _ Racket Developers list: http://lists.racket-lang.org/dev
