Re: Should @x be defined after only "my @x"? (RT #64968)
On Wed, Aug 12, 2009 at 04:25:49PM -0500, Kyle Hasselbacher wrote: > use v6; > > my $s; # ! $x.defined > my @a; # @a.defined > > That's the current Rakudo behavior. RT #64968 suggests that this is a > bug. In Perl 5, @a would not be defined until something was put into > it. Which should it be? I'd like to write a test for this. http://perldoc.perl.org/functions/defined.html Use of defined on aggregates (hashes and arrays) is deprecated. It used to report whether memory for that aggregate has ever been allocated. This behavior may disappear in future versions of Perl. You should instead use a simple test for size: I don't know whether the Perl 6 apocalypses explicitly specify behaviour for defined, or if they inherit this Perl 5 behaviour by default. Nicholas Clark
Re: Filename literals
Hinrik Örn Sigurðsson wrote: I was wondering if there had been any discussion about how to type file and directory names in Perl 6. I've read a couple of posts about file test operators, where some have suggested making filenames special, either as a subtype of Str or something else entirely. That way Str wouldn't have all these file test methods, which is good because not all strings are valid filenames. Considering that in the general case a file name can be any string at all, if it is going to have its own type at all, it should be disjoint from Str in the same manner that, say, Instant and Duration are disjoint from Num/Rat. When I say "disjoint", I mean conceptually that "FileName" say has an attribute of type Str rather than being defined as a subtype of Str. -- Darren Duncan
Filename literals
I was wondering if there had been any discussion about how to type
file and directory names in Perl 6. I've read a couple of posts about
file test operators, where some have suggested making filenames
special, either as a subtype of Str or something else entirely. That
way Str wouldn't have all these file test methods, which is good
because not all strings are valid filenames.
I know that there are a lot of uncertainties with regard to the file
system, e.g. that you can only truly know that you'll be able to write
to a file when you actually go ahead and try it, so keeping state
about such things is pointless. But having a type or role that
encapsulates the /name/ of a file or a directory might still be
useful. With Perl 5, if you want to do it right, you construct proper
filenames with catfile and catdir (from File::Spec), but it's still
just a string.
Imagine two roles, Filename and Dirname (or Path::File / Path::Dir). I
chose two instead of just one Path role because I think there might be
ambiguities somewhere (same reason File::Spec has both catdir and
catfile), but I might be wrong. Anyway, it would be neat if you could
quickly construct a Str that does one of those roles in the following
manner:
# bin/perl on Unix
my $rel = qf/usr bin perl/;
# /usr/bin/perl
my $abs = qf[/usr bin perl];
# My Dir With Spaces/subdir
my $rel_dir = qd/'My Dir With Spaces' subdir/;
(qf is already used to interpolate &function calls, but ignore that
for the moment). The idea here is to have spaces substituted for
whatever delimiter the underlying operating system uses, and it
respects quotes (like «» does) for when a path component has spaces.
Your everyday cross-platform file test would then look something like this:
unless qf/foo logfile.txt/.exists {
# complain
}
The roles might have an .open method which returns a filehandle, and
some other conveniences (e.g. a .splitpath method for files and
.splitdir for dirs).
r27978 - docs/Perl6/Spec/S32-setting-library
Author: jani Date: 2009-08-13 14:19:25 +0200 (Thu, 13 Aug 2009) New Revision: 27978 Modified: docs/Perl6/Spec/S32-setting-library/Containers.pod Log: S32/Containers iterator rephrase (similar to S09 hash keys spec) Modified: docs/Perl6/Spec/S32-setting-library/Containers.pod === --- docs/Perl6/Spec/S32-setting-library/Containers.pod 2009-08-13 11:45:42 UTC (rev 27977) +++ docs/Perl6/Spec/S32-setting-library/Containers.pod 2009-08-13 12:19:25 UTC (rev 27978) @@ -635,9 +635,9 @@ multi method pairs ( %hash: Matcher $keytest? ) is export multi method values ( %hash: Matcher $keytest? ) is export -Iterates the elements of C<%hash> in no apparent order, but the order -will be the same between successive calls to these functions, as long as -C<%hash> doesn't change. +Iterates the elements of C<%hash>. The order is implementation dependent +and arbitrary, but will be the same between successive calls to these +functions, as long as C<%hash> doesn't change. If C<$keytest> is provided, only elements whose keys evaluate C<$key ~~ $keytest> as true are iterated.
Re: comments as preserved meta-data (was Re: Embedded comments ...)
Raiph Mellor hyperpunned: > With this whiny man exchange ultimately having bourne supreme fruit, > the apocalypse watch for the post damian weekend begins... ARRRG! Damian ;-)
Re: comments as preserved meta-data (was Re: Embedded comments ...)
> Excellent idea. But may I suggest you perhaps might like to hold off > that discussion until next week? > > @Larry had some very fruitful discussions about the long-overdue Pod > spec during YAPC::EU last week and, as a result, I plan to (finally!!!) > release a new version of S26 this week-end. I very much hope that this > new revision will satisfy The Overmeer Desiderata [1] too. > > Damian > > > [1] Sounds like a Robert Ludlum novel, eh? With this whiny man exchange ultimately having bourne supreme fruit, the apocalypse watch for the post damian weekend begins... -- love, raiph
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
On 2009-Aug-11, at 1:38 pm, raiph mellor wrote: For a quick backgrounder, Larry had talked of reserving backtick for use as a user defined operator [1], Mark had suggested its use as a (tightly bound) comment [2], and James et al had suggested using it to declare units [3]. I'd like to see units, but as I've pondered it in the back of my mind, I've realised we don't need special symbols for them. A unit is just an object that has methods for converting to other units; sugar can be provided by postfix operators that cast their operand to the appropriate type: "42ft" calls "Unit::Length::Foot(42)". I've long been in Mark's camp about a lightweight and attractive docstring syntax being likely to be helpful for encouraging habits that would likely contribute to improved long term maintainability of code with comments, and was mulling that. Me too. It's not just making it easier to write documentation as you go -- and POD already makes it fairly easy -- but more than that, it's a matter of making it easier to *structure* that documentation. P6 is so powerful that equally powerful docs are going to be needed to take advantage of it. For example, there needs to be a way to pull out the docs for a specific function, or a specific parameter of a specific function: perldoc --module=Foo::Bar --method=baz --param=Title In P5, there's a sort of coincidental structure available, in that you can put a chunk of POD next the function it describes, but the relationship needs to be more formal if, say, your editor is to be able to pull out that information to display it when you click on a keyword, or to auto-complete argument names, etc. Happily, Damian posted a while back that he is working on a way to associate docs with code. The other problem related to that is the need for end-user documentation to have its own structure and order, which often will not be the same order supplied by the code. There needs to be a way to override and extend the structure, either by specifying a recipe for assembling the finished doc out of separate chunks of POD scattered about the code; or else by writing the docs in order and then link pieces the associated units of code. (Of course, we're also faced with a poverty of tools: there's no technical reason we couldn't view the same file in "code mode" and "doc mode"... but it's no fun writing features that people can't use. On the other hand, nobody writes tools for features that don't exist, so you have to start somewhere.) -David
Re: comments as preserved meta-data (was Re: Embedded comments ...)
Raiph Mellor wrote: > Anyhoo, I'd love to see a session of brainstorming, with nitty gritty > detail, about possible ways to get what you guys and Mark and I and > perhaps others think we would like to see in the way of super tightly > woven together comments and code, where said brainstorming initially > works within the creative constraint of leveraging the P6 spec as is, > plus reasonable extrapolation of unspecced bits. Think grammar > morphing, aspects of macros, the existing unfinished POD6 spec, and > any other relevant existing bits I'm forgetting. Excellent idea. But may I suggest you perhaps might like to hold off that discussion until next week? @Larry had some very fruitful discussions about the long-overdue Pod spec during YAPC::EU last week and, as a result, I plan to (finally!!!) release a new version of S26 this week-end. I very much hope that this new revision will satisfy The Overmeer Desiderata [1] too. Damian [1] Sounds like a Robert Ludlum novel, eh?
Re: comments as preserved meta-data (was Re: Embedded comments ...)
On Thu, Aug 13, 2009 at 1:00 AM, Darren Duncan wrote: > Timothy, you raise a good point... > [discussion] > I think this can be made to work without much fuss I'm curious about these sorts of conversations, and the way the community works in relation to them. I'm also curious about this specific conversation, and the ability (or otherwise) to get a facsimile of what we want by using existing P6 specc'd features, especially morphing the grammar, and macros. First, about this conversation and the way the community works... We just had a bunch of threads touching on this stuff. Larry++ then made a change to the spec. Notably, @/Larry didn't post within the discussions I read and made the spec change while discussions were still going strong, with ingenious, fresh, thinking. (That suggests to me that he/they were trying to shut down debate, presumably due to viewing it as bike shedding, at a time when such could be considered ever more dangerous, perception- and productivity- wise. Leadership in an anarchist context is a tough role!) Despite @/Larry's move, you have continued, and I appreciate that, and hope @Larry are still paying some attention. Second, I'm hoping that @Larry are confident we'll get more or less what we want in the end, due to POD power and/or grammar morphing and/or macros and/or some other features we haven't thought about. I'm hoping that, rather than that what's happening is that @Larry are running out of time and patience (although that would be quite understandable!). There have been many of these comments discussions over the years. In particular, a notable multi year long exchange, best represented by Mark Overmeer and Damian Conway, about how best to weave documentation and code. Indeed, this issue goes way back and way deep; I recall Ward Cunningham's promotion of 'literate programming' in the mid 90s, in which, iirc, he talked of Donald Knuth's promotion in the 70s of the idea of code and comments being woven extremely closely together such that neither is dominant, and one can actually turn things inside out and have code embedded in commentary rather than the other way around. A radical paradigm indeed! Anyhoo, I'd love to see a session of brainstorming, with nitty gritty detail, about possible ways to get what you guys and Mark and I and perhaps others think we would like to see in the way of super tightly woven together comments and code, where said brainstorming initially works within the creative constraint of leveraging the P6 spec as is, plus reasonable extrapolation of unspecced bits. Think grammar morphing, aspects of macros, the existing unfinished POD6 spec, and any other relevant existing bits I'm forgetting. Did that make sense? Anyone interested? ;) -- love, raiph
