Timothy S. Nelson wrote: > David Green wrote: >> Jon Lang wrote: >>> If so, could you give some examples of how such a distinction could be >>> beneficial, or of how the lack of such a distinction is problematic? > > Well, my main thought in this context is that the stuff that can be > done to the inside of a file can also be done to other streams -- TCP > sockets for example (I know, there are differences, but the two are a lot > the same), whereas metadata makes less sense in the context of TCP sockets; > I guess this was one of the thoughts that led me to want separate things > here.
Ah. I can see that. >> Well, I definitely think there needs to be a class that combines the >> inside and the outside, or the data and the metadata. Certainly the >> separate parts will exist separately for purposes of implementation, but >> there needs to be a user-friendlier view wrapped around that. Or maybe >> there are (sort of) three levels, low, medium, and high; that is, the basic >> implementation level (=P6 direct access to OS- and FS- system calls); the >> combined level, where an IO or "File" object encompasses IO::FSnode and >> IO::FSdata, etc.; and a gloss-over-the-details level with lots of sugar on >> top (at the expense of losing control over some details). > > Hmm. With the quoting idea, I don't see the need for a "both" type > of object. I mean, I'd see the code happening something like this: > > if (path{/path/to/file}.e) { > �...@lines = slurp(path{/path/to/file}); > } > > Or... > > if (path{/path/to/file}.e) { > $handle = open(path{/path/to/file}); > } > > > > (I'm using one of David's suggested syntaxes above, but I'm not > closely attached to it). For the record, the above syntax was my suggestion. > I guess what I'm saying here is that I think we can do the things > without people having to worry about the objects being separate unless they > care. So, separate objects, but hide it as much as possible. Is that > something you're fine with? It looks good to me. >>> In fact, having q, Q, or qq involved at all strikes me as wrong, >>> since those three are specifically for generating strings. >> >> Pathnames still are strings, so that's fine. In fact, there are different > > Hmm. I'm not so sure; maybe I'm just being picky, but I want to > clarify things in case it's important (in other words, I'm thinking out loud > here to see if it helps). > > First, Q and friends don't generate strings, they generate > string-like objects, which could be Str, or Match, or whatever. Think of > quoting constructs as a way of temporarily switching to a different > sublanguage (cf. regex), and you'll have the idea that I have in mind. > > As for pathnames being strings, you may be right FSVO string. But > I'd say that, while they may be strings, they're not Str, but they do Str, > as in > > role IO::FSNode does Str {...} > > (FSNode may not be the right name here, but is used for illustrative > purposes). I'd go one step further. Consider the Windows path 'C:\Program Files\'. Is the string what's really important, or is it the directory to which the string refers? I ask because, for legacy reasons, the following points to the same directory: 'C:\PROGRA~1\'. Then there's the matter of absolute and relative paths: if the current working directory is 'C:\Program Files\', then the path 'thisfile' actually refers to 'C:\Program Files\thisfile'. And because of parent directory and self-reference links, things like '/bin/../etc/.' is just an overcomplicated way of pointing to '/etc'. I'd like Perl 6's treatment of filenames to be smart enough that smart-matching any of these pairs of "alternative spellings" would result in a successful match. So while I'll agree that filenames are string-like, I really don't want them to _be_ strings. >> things going on here; one is to have a way of conveniently quoting strings >> that contain a lot of backslashes. Just as Perl lets you pick different >> quotation marks, to make it easier to quote strings that have a lot of " or >> ' characters, so it should have a way to make it easy to quote strings with >> a lot of backslashes. (The most obvious example being Windows paths; but >> there are other possibilities, such as needing to eval some code that >> already has a lot of backslashes in it.) >> >> Now, you can already turn backwhacking on or off via Q's :backslash >> adverb; Q:qq includes :b (and Q:q recognises a few limited escape sequences >> like \\). So you could say Q[C:\some\path], and you could add scalar >> interpolation to say Q:s[C:\some\path\$filename]. But there's no way to >> have all of: literal backslashes + interpolation + escaped sigils. >> >> Perhaps instead of a simple :b toggle, we could have an :escape<Str> >> adverb that defaults to :escape<\>? Then you could have >> Q:scalar:escape("^")[C:\path\with\literal^$\$filename]. > > Maybe a global variable? It's an interesting idea, and I'll see how > others feel :). I'm leery of global variables, per se; but I _do_ like the idea of lexically-scoped options that let you customize the filename syntax. Changing the default delimiter would be the most common example of this. >>> The ultimate in "path literals" would be to establish a similar >>> "default delimiter". [...] >>> `path`.size # how big is the file? Returns number. >> >> There's something that slightly jars me here... I don't like the quotation >> returning an IO object. (I like the conciseness, but there's something a >> bit off conceptually.) > > Hmm. But doesn't normal quoting return a Str object? And regex > quoting return an object (Regex? Match? Something, anyway). Exactly. >> Now, isn't Q:path[/some/file] just creating an IO object? Unlike /foo/, >> where "foo" just IS the pattern, "/some/file" is *not* an IO object, it's >> just a filename. So if the special path-quoting returned an IO::File::Name >> object, I would be perfectly happy. But you can't have $filename.size -- a >> fileNAME doesn't have a size, the file itself does. To get from the >> filename to the file, you need another step, and it's that extra step I >> don't like > > We seem to agree that we're talking about at least three things here > (however much some of them are disguised). > - Paths (ie. file names, URLs, whatever) > - File metadata (IO::FSNode, etc) > - File data (what S32/IO calls IO::File -- the stuff inside the file) > > The difference in our approaches is that you seem keen to integrate > closely the data and the metadata, whereas I'm trying to integrate the paths > and the metadata. Right. My own sense is that it's better to integrate the paths and the metadata. I rather miss the relatively straightforward way that Perl 5 let you say things like '-e "filename"'; and while I understand the argument against attaching file testers directly to strings, I would still like to be able to do something approximating that. Right now, smart-matching against a Pair is the officially endorsed approach for handling this sort of thing; but to me, that also feels like a kludge. Letting you access metadata by means of methods called on a path could come close to the original file tests in terms of utility, without requiring the kludginess of Pair matching or Str methods. >> IO objects always to parse a literal string the right way. (I.e. "/" is >> made to represent the official cross-platform path separator. Unless you >> parse some literal text with Q:ntfs, which parses a literal "\" as "/"?? Or >> say "use path-separator '\';" or something!) > > Another problem, just to make things exciting: > > $ echo $PATH > /home/wayland/local/bin:/usr/global/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/usr/local/sbin:/sbin > > Now, which of these is the path? The whole thing, or the individual > directory paths? And what's the path separator? Slash (/) or colon (:)? > So I think we need to distinguish between a search path, and a > file/directory path. So we'd be doing "use fs-path-separator Q '\';" (note > the Q -- your example would, I think, have needed a \\ in it). IMHO, the Perl equivalent of your 'echo $PATH' example ought to return a list of '/'-delimited paths - that is, what you're referring to as a search path would merely be a list of file/directory paths. >>> In fact, path literals may be more pattern-like than string-like, when >>> and if you start taking wildcard characters into account: >>> >>> if $file ~~ path[./*.txt] { >>> say "$file is a text file in the current working directory." >>> } >> >> Is that just a regex, in fact? > > No, we're talking about a globbing sublanguage (see the glob() > function). In p5, this could be done with the <> quotes, but S02 says that > in P6, that you need to use the "glob" function if you want this kind of > functionality. The "glob" language is different than regex. I was wanting > to replace the "glob" language with something more like XPath, but that idea > was vetoed by people who didn't want Tree-related objects to be part of the > core, so I'm doing that as a library. Right. And if globbing is built into path literals, then a path literal doesn't represent a filename, per se; it represents a filename pattern which might match 0, 1, or multiple filenames. That said, the globbing sublanguage is such that if you _don't_ use wildcard characters, you'll match one file at best. _This_ might be a reason to go with three separate things: path, metadata, and data. Data would refer to a file's contents, and would be represented by a stream to which you can gain access by opening the file; metadata would represent the file itself and information that you can glean without opening the file - essentially, p5's fstat. Path would be a filesystem pattern, used to test a particular file (as identified by its metadata) for location. >> Though, to speak of file-types, this particular example would I think >> better be handled by: >> >> if $file.type ~~ MIME("text/plain") {...} This doesn't include the other condition for which I was testing: namely, that $file can be found in the current working directory. > Cool idea. How would the type be determined? Are you thinking of > the algorithms in the unix "file" utility? Please tell me you're not > planning to use filename extentions -- that's bad :). Wouldn't $file.type be metadata? -- Jonathan "Dataweaver" Lang