This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
On Tue, Jan 24, 2006 at 11:51:34AM -0800, Per Bothner wrote: > What would using symbols and s-exp gain? What kind of > operations would it make easier? There are two different issues here: how should paths or URIs be represented at run-time, and what kind of notation should be used for giving literal values for them in code. As you are speaking about "operations", I assume you mean the former here. To me it is obvious: _all_ common operations on URIs are easier if you have a structured representation instead of a flat string. Maybe the most common operation is resolving a relative URI against a base URI. A purely string-based implementation is a huge mess that involves searching for slashes from right to left (but remembering that consequent slashes count as a single one), detecting ".." and "." -segments and whatnot... it's the sort of thing you expect to see only in C code. Any sane implementation will first parse the URI into its constituents and form a list of path segments, and then operate on that list. It would be just silly to constantly parse and unparse the URIs at every operation, so it's better to have a distinct internal representation for them. And indeed, this is why many languages do have special types or classes for representing URIs. But I wasn't talking about this, but about the syntax of the module language. And, indeed, you're right about this one: > Your argument is an aethetic one - which is certainly valid. Essentially, yes. I very much like the minimalism and cleanliness of Scheme's syntax: there's just names, spaces and parentheses, and no icky $-prefixes for identifiers, nor quotation marks anywhere except in plain text literals. I just find it distasteful if a _string_ is being used as an identifier. You are right that URIs are standard way of identifying resources, and as such they are a fine choice for a library path. However, to my mind a URI is is essentially an abstract object that has various attributes (scheme, username, hostname, port, path, query string) that may be present or not. The URIs have a standardized written representation that is intended to be useful in all kinds of contexts (e.g. an unescaped space is forbidden in URI syntax since URIs are often inserted into plain text as such). However, Scheme source code is a special context because in this context there is already a conventional way of representing all kinds structured data: s-expressions. Having structured data in some other format looks just plain weird. For an analogy, consider regular expressions: POSIX-style regexps are compact, but quite un-schemish to my mind. And to others' minds too. Hence we have SRE notation, which represents the structure of a regexp exactly the same way as all structures are represented in Scheme: with s-expressions. URIs should be no different. > What about "path names" (as used in file operations): Should they be > structured objects or strings? Definitely objects. Nowadays PLT Scheme has built-in support for path objects, but before that I used to use a simple library: ;; A path is (dir subdir subsubdir . file), or the file may be missing, ;; designating the actual directory. ;; If the path starts with /, it's absolute (define (reverse-path path) (if (pair? path) (cons '.. (reverse-path (cdr path))) '())) (define (relative-path from to) (or (and (pair? to) (let ((h (car to))) (or (and (pair? from) (eq? (car from) h) (relative-path (cdr from) (cdr to))) (and (eq? h '/) to)))) (append (reverse-path from) to))) Here relative-path calculates the relative path from "from" to "to". Would you like to do this kind of stuff using _strings_? I just find it sad that underneath all these high-level conveniences, the operating system still uses strings for paths in the system call interface. As a result, '/' is an utterly magical character that cannot appear in any file's name. > There are good reasons to prefer strings (standard, universal, and > familiar, as listed above). At least it makes sense to read and print > pathnames using URI syntax. Certainly it should be possible, but hardly the default. XML's surface syntax is also standard, universal and familiar. Would you suggest that XML data in Scheme code be therefore expressed with strings: "<foo>bar<baz/></foo>" instead of, say, Xexprs: (foo "bar" (baz))? Lauri