Author: lwall
Date: 2009-05-04 23:23:49 +0200 (Mon, 04 May 2009)
New Revision: 26674
Modified:
docs/Perl6/Spec/S05-regex.pod
docs/Perl6/Spec/S12-objects.pod
Log:
[S12] clarify has = semantics
Modified: docs/Perl6/Spec/S05-regex.pod
==
21:00 pmichaud: note that for the self ticket, the phrase in
question is a has initializer, which runs in BUILD context, and hence
does have an obvious instance self, so this isn't really about binding
self to the class
21:04 TimToady: okay, thanks.
21:04 So we definitely can't leave self as bei
On Sun May 03 13:51:11 2009, s1n wrote:
> I ran into a bug where I couldn't refer to 'self' when it logically made
> sense I could:
>
> (15:33:15) s1n: rakudo: class A { has %.H = (a => -> $x { self.c($x) });
I don't see anything in the spec that indicates that the body of the
class declaration h
On Sun May 03 13:24:39 2009, masak wrote:
> rakudo: say (hash(a => '3' )).perl
> rakudo cddb16: OUTPUT«{}»
> wait a sec
> let me look up the semantics of hash() first
> sure.
> If you wish to be less ambiguous, the C list operator
> will
> explicitly evaluate a list and compose a hash of th
AFAIR in two Specs 'CharLingua' appears as - maybe - a leftover from the
history of Perl 6.
Whatever the idea of 'CharLingua' was, something nice-to-have would be
support of locale-dependent processing in the sense of Unicode
http://cldr.unicode.org/
Helmut Wollmersdorfer
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
http://perlcabal.org/syn/S02.html
quote-
Names
[...]
* An identifier is composed of an alphabetic character followed by
any sequence of alphanumeric characters. The definitions of alphabetic
and numeric include appropriate Unicode characters. Underscore is always
considered alphab
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #65344]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=65344 >
rakudo: say (hash(a => '3' )).perl
rakudo cddb16: OUTPUT«{}»
wait a sec
let me look
This message deals strictly with the syntax of '#='-based POD; the
semantics is a separate issue.
--
I'd like '#=' to follow similar rules to what '#' follows, with the
caveat that a line beginning with '#' counts as a single-line comment
no matter what the second character is. Specifically, hav
Author: hinrik
Date: 2009-05-04 18:34:57 +0200 (Mon, 04 May 2009)
New Revision: 26668
Modified:
docs/Perl6/Spec/S07-iterators.pod
Log:
[S07] fix the year in Last Modified date
Modified: docs/Perl6/Spec/S07-iterators.pod
===
--- do
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 after it.
I meant write /
# New Ticket Created by "jason switzer"
# Please include the string: [perl #65346]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=65346 >
I ran into a bug where I couldn't refer to 'self' when it logically made
sense I coul
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
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #65348]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=65348 >
Currently IO.get still does the old magic that prefix:<=> needed, which
means that it ret
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
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #65364]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=65364 >
rakudo: class A {}; class B hides A {}
rakudo 0588e8: OUTPUT«Unable to parse class def
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #65358]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=65358 >
As the commit mail below shows the parsing of statement controls like
'try' changed. Prev
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
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon May 4 12:52:05 2009 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with mo
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 the head of the function definition.
That's a convenience for the
* Hinrik ??rn Sigur??sson (hinrik@gmail.com) [090504 10:45]:
> In Perl 5 I hate having Pod interleaved with code, since it is usually
> mostly /user/ documentation and so just gets in the way. Having normal
> Pod elsewhere (at end-of-file or in a different file) and keeping API
> Pod docs inlin
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
* Damian Conway (dam...@conway.org) [090504 00:03]:
> Hinrik ?rn Sigur?sson wrote:
> > 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
> >
23 matches
Mail list logo
