Re: Filename literals
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});
}
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).
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
roleIO::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 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 fil
Re: S26 - The Next Generation
Darren Duncan asked:
> But one thing I'm not sure whether or not it was addressed is regards to
> whether free-form documentation is still supported or can be effectively
> combined with embedding documentation into the places that it is
> documenting.
Yes and yes.
Normal Pod blocks weren't mentioned in the executive summary because
they haven't changed. Except that they got much better, because now you
can indent them to match the layout of the code they're interleaving.
Or, indeed, indent them simply to indicate the Pod's own lexical
structure.
The Necrotelecomnicon example was originally written like so
(before I removed the Pod blocks...to keep the example properly
focussed):
=head2 IPC magic
=para
The base class for doing deep and dangerous things with IPC
is
#= Base class for comms necromancy hierarchy
class Magic::Necrotelecomnicon {
has $.elemental; #= Source of all power
has $!true_name; # Source of all self-protection (not documented)
method cast(Spell $s)
#= Initiate a specified spell normally
{
do_raw_magic($s);
}
#= Initiate a specified spell abnormally
method kast(Spell $s) {
do_raw_magic($s, :alternative);
}
}
which, by default (and in the absence of any semi-literate or
OO-bsessive modules one might explicitly C),
will simply produce something like:
IPC Magic
The base class for doing deep and dangerous things with
IPC is
Name: Magic::Necrotelecomnicon:
Desc: Base class for comms necromancy hierarchy
Attrs:
.elemental : Source of all power
Methods:
.cast(Spell $s) : Initiate a specified spell normally
.kast(Spell $s) : Initiate a specified spell abnormally
Damian
Re: S26 - The Next Generation
Damian Conway wrote: It's Sunday evening and, as promised, here's the new draft of S26. That's great to see. And from the executive summary, it seems to include a lot of the features or behaviors I was suggesting in the "comments as preserved meta-data" thread. I will look at this new S26 more closely soon. But one thing I'm not sure whether or not it was addressed is regards to whether free-form documentation is still supported or can be effectively combined with embedding documentation into the places that it is documenting. -- Darren Duncan
Re: S26 - The Next Generation
On 2009-Aug-16, at 2:26 pm, Damian Conway wrote: It's Sunday evening and, as promised, here's the new draft of S26. Yay! (To the contents, that is, not to the posting of it. Well, to the posting too, since otherwise it would have been much harder to read.) Perl that accesses $=POD and/or the .WHY and .WHEREFORE methods My favourite part is that it's actually called "WHEREFORE". (Take that, all-other-programming-languages!) Hopefully this is something close to the final draft...and something that every stakeholder and faction in this long discussion can dislike equally. ;-) I like it very much. But don't worry, I'll think of something to quibble about! -David P.S. to format it using perldoc2xhtml, I had to change the "=begin item" at line 589 to "=for item".
r28005 - docs/Perl6/Spec
Author: benmorrow Date: 2009-08-16 21:16:39 +0200 (Sun, 16 Aug 2009) New Revision: 28005 Modified: docs/Perl6/Spec/S04-control.pod Log: [Spec] Clarify behaviour of closure traits when an exception is thrown. Modified: docs/Perl6/Spec/S04-control.pod === --- docs/Perl6/Spec/S04-control.pod 2009-08-16 04:04:31 UTC (rev 28004) +++ docs/Perl6/Spec/S04-control.pod 2009-08-16 19:16:39 UTC (rev 28005) @@ -1232,6 +1232,21 @@ before C, C, or C, since those are done at compile or process initialization time). +If an exception is thrown through a block without a C block, the +C, C and C blocks will be run at that point, with +C<$!> set to the in-flight exception. If there is no in-flight +exception when these blocks are run, C<$!> will be C. The last +exception caught in the outer block is available as C<< OUTER::<$!> >>, +as usual. + +An exception thrown from an C block will abort the C +queue, but one thrown from a C block will not. The exceptions +thrown by failing C and C blocks cannot be caught by a +C in the same block, which implies that C blocks are not +run if a C block fails. If a C fails while an exception is in +flight the C failure doesn't replace C<$!> but goes straight into +C<$!.pending>. + For blocks such as C and C that are run when exiting a scope normally, the return value (if any) from that scope is available as the current topic. (It is presented as a C object.)
Re: Filename literals
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? 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, 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).
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 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
adverb that defaults to :escape<\>? Then you could have
Q:scalar:escape("^")[C:\path\with\literal^$\$filename].
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.) Let's see, `exec command`
bugs me too -- it's quoting something and then doing something with
the quoted string. (It's not entirely unreasonable as a cryptic
shorthand in the shell, but I think P6 should have an actual command
for that (e.g. the proposed run-gather()).) Similarly, in this
example, we're quoting a pathname, and then creating an IO object from
it.
So I don't like the quoting-and-then-using, when done by the quotation
marks, although having a function (really, macro) that does its own
quoting seems fine: "io /some/autoquoted/filename". And /regex/
doesn't bother me either. Hm. Ah, but an instant regex isn't doing
anything besides creating an object -- it is comparable to q[foo]
creating a Str. So `exec me!` bothers me because it isn't just
returning some kind of "System::Command" object, it's more like
creating the object and then calling the .run() method on it too. /
pattern/ doesn't *do* anything with the regex.
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 being hidden inside quotation
marks, just as in the `exec` case.
Anyway, that's a subtle but important point, I think. Fortunately, in
the end it doesn't have to work out much differently: instead a "path"
quoter that does IO-stuff, have a "path" function (macro, whatever)
that does quoting stuff.
$file = new IO::File(FSNode => "/path/to/file");
$file = path "/path/to/file";
$file = io /path/to/file;
$file = file://localhost/path/to/file;
Incidentally, I do think it's worth having an actual File::Name type,
even though names are really just strings. For example, not all
strings are valid filenames if the FS doesn't handle Unicode.
However, Strings should get transparently cast to IO::Names wherever
possible, so the typical user would never have to notice the difference.
IO::Name objects also provide a way to concatenate items correctly, as
per Hinrik's original post regarding a be
