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 the
It occurs to me that ln() is even shorter than log(), leaving the
Huffmanization issue unresolved. :)
On Wed, May 6, 2009 at 3:42 PM, Leon Timmermans wrote:
> Most people seem to lean towards the pod comments, though I disagree
> with it on a simple ground: aesthetics. Python docstrings aren't just
> useful, they are reasonably pretty too, #={} isn't. In fact I'd say
> it's pretty fugly. I think t
2009/5/4 Jon Lang :
> With this in mind, I'd propose two forms of '#=', based on what comes
> after the '='. If it is followed by one or more '['s, you have
> bracketed POD which is terminated by an equal number of ']'s;
> otherwise, you have POD which is terminated at the end of the current
> lin
2009/5/4 Hinrik Örn Sigurðsson :
> Could Perl allow Pod blocks to be indented in #={ } comments? Maybe
> the "local" beginning-of-line in the comment could be considered to be
> at the position where the #={ appeared, or at the position of the
> first whitespace character af
I suppose that #={ } would work like a normal Pod block which does not
allow implicit code. That way you could keep it properly indented by
default:
class Foo;
method bar ($x, $y) {
#={Swaps $x and $y}
...
}
method baz ($a, @b) {
#={
Takes $a, applies it to the values in @b
Bl
The only reason that Pod directives have to be at the beginning of the
line is so that Pod parsers don't need to know Perl (or any other
language) in order to extract Pod from files, right? Allowing them to
be indented like I suggested would break that, but the tool would need
to parse Perl in orde
On Mon, May 4, 2009 at 12:30 PM, Charles Bailey
wrote:
> If the two can be made eqaully expressive (i.e. content is normal POD,
> and multiple lines merged logically), I think I favor the pod-comment
> form, since it allows one to place the doc close to the thing
> documented - in particular, to t
These two (generalized Pod comments and C are both better than
my suggestion. :) They require less typing, so documenting at a finer
granularity (e.g. object attributes) is easier. It would provide an
opportunity for very thorough auto-generated documentation as outlined
in Mark's 2007 post
In Per
I've been thinking lately about how Perl 6 might offer functionality
similar to Python's docstrings. That is, documentation which is tied
directly to a particular routine, class or module[1]. This is
something which would is very useful in a REPL, and for documentation
readers[2].
Taking one case,
Google has announced this year's Summer of Code[1]. The Perl
Foundation accepted one project (mentored by Moritz) related to Perl 6
last year[2]. I was wondering if there are any developers interested
in mentoring students on Perl 6-related projects this year. I for one
would like to apply (as a st
11 matches
Mail list logo