This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
On Sun, 2010-03-07 at 00:45 -0500, R. Kent Dybvig wrote: > > But, not being able to name libraries with the same freedom as with all > > other symbols (and that freedom is a big thing I love about Scheme) ... > > Yes, but even though you can create a string containing any sequence of > characters, you don't necessarily have the freedom to use it as a > pathname. Should we modify open-file-input-port, etc., so that we do, > somehow? No, because file-name strings are inherently platform specific. Library names (for portable libraries) are supposed to be completely abstracted from any platform, and that's why I'm convinced allowing them to be determined by the flaws of platforms is unacceptable. > Scheme's freedom is curtailed once one interacts with things > outside of Scheme. That's life. (Not after Scheme takes over everything... :-) > Have you thought about what to do when a library name translates to a file > name or pathname longer than allowed by the underlying file system? I have known that issue exists. > 255 > seems to be a fairly common limit for a file name, and 1024 and 4096 seem > to be fairly common limits for paths on Unix systems. These are fairly > generous limits, but symbols don't have any such limits. (Plus, 255 gets > eaten up faster when a lot of long encodings are used.) If I have the > freedom to use arbitrary symbols as library name components, shouldn't > that freedom extend to size as well as contents? Yes, it should. That issue is virtually never going to be a problem, but the Windows-portability issue is going to be. If that issue was realistically going to determine library names, I'd have a problem with it too. Also, there's nothing SRFI 103 can do about that issue (I think), but it can do something about the Windows-portability issue. > Also, I'd like the freedom to use libraries stored in the user's home > directory, like (~ \x2e;myappinit) in ~/.myappinit.sls, assuming the > Scheme system interprets ~ the way a shell does, as some do. The encoding > of ~ prevents that. That's not portable and SRFI 103's purpose is supposed to be portability across prevalent OSs, so it's not supposed to be concerned with that. That can be portably accomplished with libraries named like (personal ---) and (for unixes) placing the "personal" directories in home directories and doing SCHEME_LIB_PATH=$HOME/wherever:$SCHEME_LIB_PATH. > Similarly, I would like the freedom to import from > absolute path names starting with /, e.g., so a set-uid script can > protect itself from exploits involving the setting of the library-path > environment variable. The encoding of / prevents that. Actually, the joining of relative library-file names with searched-directory names is what prevents that (assuming I'm understanding what you mean). Without the encoding, a library named (/ foo), with SCHEME_LIB_PATH=/exploit, will be found at /exploit///foo.ext. That's an OS-security design flaw, and OSs should have better security models. So, I don't think your arguments are convincing reasons for losing the portability-assisting special mapping rules. > One freedom leads > to the loss of others. In the sense we've been using "freedom", indeed. (In the libertarian semantics of "freedom", that's not possible, but I digress.) > I support the notion that we not encode any characters but instead leave > it to library authors to choose names that don't conflict with the systems > upon which they intend their libraries to be used. You have a lot of weight (metaphorically :-), so I'm leaning towards losing it, but only because I think Windows deserves that. > Programmers can police > the authors who don't initially comply. I'll be telling people: "Sorry you can't automatically use that library I made, it's Windows' fault." I'm okay with that, and I want to make sure everyone else is ready. > Sure, a library named > (srfi s2 and-let-star) might be uglier than (srfi :2 and-let*), For me, that's not an issue of ugliness, it's an issue of corresponding to the intended meaning of the library. A library named (acme thing?) is named that because it exports "thing?", not "thing" or "thing-predicate". > but it's > not clearly better to have a file named srfi/%3a%/and-let%2a%. The undesirability of the ugliness, annoying-to-type-ness, and small additional processing of the encoding should not outweigh keeping the primary abstraction of library names pure. I think it's clearly better to not restrict library names *and* to have portability with Windows (because I think it'll help Scheme adoption), via an encoding design which will die when Windows does and which won't be used much. I want to make sure other weighty people have a chance to comment. I'm going to wait until the end of the draft period (in 1 month) to make a decision. -- : Derick ----------------------------------------------------------------