On Sun, 16 Aug 2009, David Green wrote:

On 2009-Aug-15, at 9:22 am, Jon Lang wrote:
IOW, your "outside the file" stuff is whatever can be done without
having to open the file, and your "inside the file" is whatever only
makes sense once the file has been opened.  Correct?

        Pretty much, yes.

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.

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});


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).

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?

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).

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 :).

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).

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.

[Btw, I've snipped some stuff here that I disagree with, but have already stated my case above, I think].

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

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).

Having said that, though, I like some of the ideas in the section above.

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.

Though, to speak of file-types, this particular example would I think better be handled by:

  if $file.type ~~ MIME("text/plain") {...}

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 :).


| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayl...@wayland.id.au    | I am                           |

Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-

Reply via email to