Hi Richard,
Not a complete answer to your question;
just an observation about your grammar:
> rule TOP{ ^ + $ };
>
> rule statement { '='
> | { { self.panic($/, "Declaration syntax incorrect") } }
> };
>
> rule endvalue { '(' ~ ')'
>
Dear fellow revellers in the dawning Golden Age of Perl 6,
I just had a colleague contact me, to express their surprise that Perl 6
does not rate a mention in:
https://en.wikipedia.org/wiki/Functional_programming.
The Perl 6 community (and Larry in particular) has already done an
incredible
> It's an awesome language, which is exactly the problem. "Inspiring
> awe" is not far from inducing panic and terror, especially in people
> who aren't feeling too confident in the first place. We want to be
> accessible to the people who start looking nervous when the modulus
> operator is added
Raiph Mellor wrote:
> The .kxxv method name is a placeholder.
Phew! Thanks for taking the time to respond and
explain, Raiph.
> The brief discussion that motivated introducing it is at:
> http://irclog.perlgeek.de/perl6/2014-04-13#i_8582049
>
> Larry has chimed in at:
> http://irclog.perlgeek.d
> Spec Bag.kxxv
It's a clever name...but maybe too clever?
I find it unfortunate that a method that only returns keys has a 'v'
in its name.
Up to now, we've had a more predictable pattern to naming these accessors.
How about one of:
.weighted-keys
.distribution
instead???
And wha
Moritz wrote:
> To spin the tale further, we need to think about what happens if
> somebody writes
>
> multi foo(1|2e0) { ... }
>
> so now we have Int|Num. We could explore the most-derived common
> ancestor (Cool), or look into role space (Real, Numeric come to mind),
> or simply error out.
Or m
> But by using the term ‘variable’, which is ambiguous, you are not
> answering my question! :-)
Sorry. I tend to think of *every* variable name as merely being
an alias for some underlying storage mechanism. ;-)
> Does
>
> my $x;
> for 1..10 -> $x {}
>
> cause the existing name $x to ref
Father Chrysostomos pointed out:
> I said when, not whether. :-)
Isn't that just typical of me: confusing ontology with chronology. ;-)
I'm afraid don't know the implementation details for Rakudo. It may be
bound as the surrounding block is entered, or perhaps just-in-time when
the Code object i
Father Chrysostomos asked:
> What I am really trying to find out is when the subroutine is actually
> cloned,
Yes. It is supposed to be (or at least must *appear* to be),
and currently is (or appears to be) in Rakudo.
> and whether there can be multiple clones within a single call of
> the encl
> Thank you damian, i will apply that patch,
Much appreciated, Herbert!
Damian
Herbert Breunung asked:
> what was you rational behind this decision.
> I like it visually but my brain refuses to find any logic why only there
> special vars should be different.
This change stems from another change that we made after discussions at
YAPC Riga last year. That change was to conv
yary suggested:
> In a situation like this, I reach for a thesaurus
The standout from that list for me is: 'consonance'.
Second favorite is: 'gibe' or 'jibe'.
But the underlying operation is .ACCEPTS(),
so perhaps the operation should be referred to
as "acceptance" or "acceptibility".
Damian
> At least in #perl6 I've never seen anybody try to write an auto-deduced
> sequence, and fail because of floating-point errors.
Except for Martin's 1, sqrt(2), 2...8
But, yes, the widespread use of Rats rather than Nums
means only the edgiest of edge-cases fails. And as you get
an explicit Failu
> Actually, that one works fine in both niecza and rakudo, since those are Rats.
Oh, that's good to hear.
It doesn't change my underlying argument however. Any operations
performed on genuine floats are going to lose precision, and if we're
using such operations to infer relationships (such as eq
> But unless we twist smartmatching semantics for that purpose,
No!
Please, no.
;-)
> it means we cannot do the same fuzziness for the endpoint,
Except that we will be encouraging people to use: * >= $END
as their standard endpoint pattern, which will provide
most of the necessary fuzz.
> S
Patrick correctly observed:
> On Rakudo on my system, sqrt(2) indeed produces a Num,
> but since floating point arithmetic doesn't result in
> sqrt(2) / 1 == 2 / sqrt(2), no geometric sequence is deduced
> and the sequence fails with "unable to deduce sequence".
Although, arguably, that might be
> Ok, so infix:<...> isn't what I wish for either... Can you help me
> understand Damian's example?
Breaking down that example:
$a, # Start at $a
*+$c # Generate next number via: sub($prev_num} { $prev_num + $c }
... # Repeat until...
* >=$b # ...this sub matches:
> Interesting... but it doesn't seem to work in Rakudo Star (2012.02):
>
>> @(2,5..10)
You need three dots, not two.
Damian
> Is it possible to create a new range operator ':' such that:
Do you need to?
> a:b:c is a range from 'a' to 'b' by steps of 'c'.
Perl 6 already has: $a,*+$c...* >=$b
E.g. 2, 5 ...^ *>=15 > 2,5,8,11,14
> :b is the same as 0..b
Perl 6 already has ^$b
e,g, ^100 > 0..99
> a: is th
Moritz observed:
> And here the problem already starts. Signatures with where-blocks can't
> by compared by a Turing machine. At least we know which signatures we
> can compare and which we can't. So we need to think about that case too.
Indeed. Although it's not as bad as it might be. A where-bl
Carl asked:
>class A {
>method foo($x) {
>PRE { $x < 10 }
># ...
>}
>}
>
>class B is A {
>method foo($a, $b, $c) {
>PRE { [>] $a, $b, $c }
># ...
>}
>}
>
> When C is called, are both C blocks meant to b
yary wrote:
>>The current approach is violating the DRY principle. When you write a
>>.new method that wants to initialize private attributes, you have to
>>repeat all their names again in the signature of your BUILD submethod:
The other way of looking at this is that redefining the new() is abou
My thanks to Kris and Moritz for reassuring me that
the Perl 6 initialization semantics remain sane. :-)
In response to yary's original observations, the extra work required to
achieve non-standard semantics doesn't seem unreasonable to me.
Especially as, should one need to do it regularly, one co
Moritz clarified:
> In BUILD, the object isn't yet fully constructed, and thus using $.attr
> (which is really a virtual method call in disguise) is wrong. STD and
> niecza already catch that at compile time, and I'm currently trying to
> make rakudo catch it too (branch 'has-self' on github).
Ag
Yary wrote:
> If one wants to use any argument in the constructor other than a
> public attribute (positional OR named other than an attribute name),
> one must define a "method new( ... )".
Huh? I know I've been out of the loop lately, but this seems fundamentally
wrong.
Constructor args certai
> The current stance seems to be that low-level things are spelled with
> underscores, while we reserve the minus character for user-space code. Try
> grepping the specs for identifiers of built-ins that have a minus in it -- I
> didn't find any in a quick search.
I had a little more time to look
It's a trivial point, but why hidden_from_backtrace instead of
hidden-from-backtrace? Especially given that the associated
method is is-hidden, not is_hidden?
Are we consistently using underscores for multi_word traits
and hyphens for multi-word methods? Wouldn't it be nice to
have a consistent an
Carl asked:
> * What do we mean when we say 'has @.a is readonly'?
> What do we want it to mean?
Not sure about "we", but I want that to mean that nothing outside the
class can alter any component of @.a, no matter how deeply nested that
component may be.
> * Are we fine with references from re
Moritz wrote:
>> $value !~~ Junction && $value ~~ $junction
>
> In general this definition makes it impossible to return a list of
> eigenstates from the junction. Just think of junctions containing Code
> objects.
Well, that's a deficiency in smartmatching: that Callable ~~ Code doesn't
ch
Martin D Kealey suggested:
> Well, I think returning or throwing an "Unordered" exception would be
> the appropriate way to handle those, both for complex numbers and for
> junctions.
For complex numbers that might be true, because the order relationship
between two complex numbers isn't expressi
Martin D Kealey asked:
> Or do we not invert junctions, and run the risk of unexpected
> action-at-a-distance instead?
I think our current approach is correct. That is: we "invert"
junctions on operators that are themselves intrinsically inverted
(such as !=, !~~, !<), but do not invert on those
Jon Lang wrote:
> Personally, I don't think that it should be a public method: one thing
> about junctions is that you can use them interchangeably with ordinary
> scalars; giving them a public method breaks that. In particular, code
> that makes use of a Junction public method would break if you
Dave Whipp noted:
> I think that the two proposals are equivalent, in the sense that either can
> be trivially implemented using the other.
Agreed.
> However, I am a little concerned that the transjunction "magically" changes
> an operator that returns a Boolean value into one that returns a li
Ben Goldberg asked:
> I'm probably missing something, but wouldn't it have been easier to
> write that module by using eval STRING to create all of those infix
> operators?
Sure. But the module is already slow to start up. I was concerned
that it would get even slower with an embedded eval. But,
> In general I like where this is going but need a little hand holding
> here- I'm not an expert on junctions or anything perl6-
>
>> So I'm going to go on to propose that we create a fifth class of
>> Junction: the "transjunction", with corresponding keyword C.
>
> It seems that by these definitio
Brandon mused:
> It occurs to me: If their purpose is that narrow, why are they wasting
> conceptual space in the core language?
Well, mainly because their purpose isn't narrow at all: it's parallelized data
comparisons (all(@values) < $threshold), and multiway comparisons
(all(@values) ~~ any(@
Dave Whipp wrote:
> When this issue has been raised in the past, the response has been that
> junctions are not really intended to be useful outside of the narrow purpose
> for which they were introduced.
Hmm. There are intentions, and then there are intentions. I know
what I intended when I
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
Specificially, in S32-setting-library_Containers.pod, we currently have:
=item !eigenstates
method !eigenstates (Junction $j: --> Parcel)
Return
Leon Timmermans wrote:
> For the love of $DEITY, let's please not repeat ithreads!
$AMEN!
Backwards compatibility is not the major design criterion for Perl 6,
so there's no need to recapitulate our own phylogeny here.
The problem is: while most people can agree on what have proved to be
unsati
Jonathan wrote:
> Sounds like the encapsulation breaking thingy probably wants to be looking
> for some pragma to have been used in the lexical scope of the caller, maybe.
> I'd rather that we called it something other than MONKEY_TYPING though.
> Different evil, different pragma. :-)
As long as
Moritz writes:
>> Objects that you can't do that with don't make sense to be serialized and so
>> .perl can reasonably refuse to work on them.
>
> method perl {
>die "Can't serialize objects of type $?CLASS, because ...";
> }
Sure. But now the cautious programmer has to add that to *every* cl
Moritz wrote:
> To re-iterate, Perl 6 has no "real" privacy by default -- both the
> default .new and .perl methods give you access to private attributes,
> unless you explicitly override them.
At least you *can* explicitly override them (and perhaps factor that out
into a role that you could alw
Carl wrote:
> For what it's worth, we had exactly this discussion a couple of days
> ago on IRC. I represented your views above, Damian.
Thank-you for that.
> As long as C<.perl> works the way it does, there can be no real
> privacy.
Sigh. That is indeed badly broken. Surely it ought to defaul
On 30 September 2010 06:09, Moritz wrote:
> After lengthy IRC discussion, we concluded that it's a good idea to provide
> some form of introspection that doesn't bother about perceived privacy
> borders, provided that the implementation makes it feasible.
Wow, that's the first time I've ever bee
Darren suggested:
> Use namespaces.
The upper/lower/mixed approach *is* a
namespace approach.
> Explicit versioning is your friend.
>
> Can I get some support for this?
Not from me. ;-)
I think it's a dreadful prospect to allow people to
write documentation that they will have to rewrite whe
Aaron wrote:
> I dislike "reserved" in this context, but understand why the namespace has
> to be shared. For config options, I'd say anything should go, but people
> inventing their own config options should be aware that across N release
> cycles, new options may be introduced.
...which means t
Carl proposed:
> The other path that seems reasonable to me would be to use the same
> naming scheme as for the block types, i.e. reserve all-upper and
> all-lower forms (and die if an unrecognized one of this form is
> encountered), and let the custom ones live in the namespace of
> mixed-case id
On 23 July 2010 01:41, Moritz Lenz wrote:
> Use the right tool for the right job:
>
>> square numbers: 0, 1, 4, 9, 16, 25, 36, etc.
>
> (1..10).map(* ** 2)
Or even just:
(1..10) »**» 2
Note that you can also get most of the effects you want by using
@_ in the series' generator block.
Well, if we're not going to try to implement linguistically based
hyphenation/underscoriation rules (and I'd still argue that hyphenating
adjectives to nouns and underscoring everything else isn't exactly
rocket science), then I'd suggest we reconsider a radically different
proposal that was made o
John Siracusa commented:
> That's certainly an example of how hyphens might gain meaning in Perl
> 6 names, but I don't think I can endorse it as a convention. People
> can't even use hyphens correctly in written English. I have very
> little faith that programmers will do any better in code
Bu
Personally, I'd prefer to see the English conventions carried over to
the use of general use of hyphen and underscore in identifiers in
the core (and everywhere else).
By that, I mean that, in English, the hyphen is notionally a
"higher precedence" word-separator than the space
(or than its intra-
> We could make enum declarators even more like constant declarators
> by using a pseudo assignment. Then we could use = instead of parens:
>
> enum Perms = Z=> 1,2,4...*;
Hmm. That doesn't seem very like constant declarators. In a
constant declarator,
the constant appears on the lhs and
Jonathan Lang wrote:
> Wouldn't that be C< = 0...* >?
Indeed. Thanks for the correction.
> That said, don't we already have a means of assigning specific values
> to individual members of an enum? I forget the exact syntax,
The exact syntax is:
enum Perms [Read => 1, Write => 2, Exec =>
Daniel Ruoso pointed out:
> Using bitsets in Perl 6 is just as easy as using in Perl 5 -- which
> happens to be the same as using in C, but it's not C...
>
> constant PERM_WRITE = 0b0001;
> constant PERM_READ = 0b0010;
> constant PERM_EXEC = 0b0100;
> constant PERM_NAMES = { PERM_WRITE => 'Write
Larry mused:
> Alternatively, maybe there should be some way to express infinite sets.
> Not sure I like the idea of an infinite junction, but something resembling:
>
> subset PowersOf2 of Int where any(1,2,4...*)
> enum Perms of PowersOf2 ;
> say Exec; # 4
>
> Presumably the series in t
Larry concluded:
> I do freely admit that most Perlfolk are not used to thinking of
> permissions in terms of set theory. But as I said, we're looking at
> kind of a strange use case here, and perhaps not typical of the kinds
> of sets of small numbers that people will be using in the future.
Th
An issue came up in a class I was teaching today...
There doesn't seem to be an easy way to create a type that allows a set
of enumerated bit-flags *and* all the combinations of those flags...and
nothing else.
For example:
enum Permissions ( Read => 0b0001, Write => 0b0010, Exec => 0b0100 )
Surely this is not a common-enough requirement to warrant a special
syntax.
At 80-columns, you can represent integers up to ninety-nine
quinvigintillion, nine hundred ninety-nine quattuorvigintillion, nine
hundred ninety-nine trevigintillion, nine hundred ninety-nine
duovigintillion, nine hundred
>>> + rhyme((1,2),3,:mice) # rhyme has 2 arguments
>>
>> Should that say 3 arguments?
I believe so.
>> (If not, please can somebody clarify what
>> the 2 arguments are.)
>
> (1,2) and 3. Named arguments ("mice" in this case) are handled separately.
That interpretation is not consistent wi
Carl observed:
> Partly that is because documentation isn't at the forefront of things
> that need to be implemented for Perl 6 to be useful, so it's kind of
> lagging behind the rest.
>
> Partly it's because Damian is the "owner" of that synopsis, and he
> practices a kind of "drive-by-updating"
Jon Lang asked:
> Not actually S26; but closely related: should $=POD and .WHY be
> read-only?
I had assumed so.
> Also, should there be other Pod variables besides $=POD?
> If so, which ones?
The original idea was that every Pod block with any kind of TYPENAME
would be available as $=TYPENAME
yary asked:
> Can some concept/implementation of $=POD lazyness only incur the
> memory and performance hit on access?
IANAImplementor, but I suspect that virtually all of the performance hit
could be incurred at run-time, if it happened to be implemented that
way. The memory hit too, if necessar
Aaron Sherman asked:
> Should there be an explicit way to step this down to just parsing the bits
> that are called out as pod?
The original conception allowed for Pod to be independent of the
interleaved language. That has now been supplanted by a model that views
Pod as an integral part of Perl
Darren Duncan wrote:
> So another proposal I have is to add to the slideshow mentions of the
> Enlightened and Modern Perl movements and where one can go to read more,
> this being supplemental to PBP.
With that suggestion I'd whole-heartedly concur.
> My own opinion is that the modern best way
Darren Duncan wrote:
> pg 36 - About the "Perl Best Practices" book, you should be clear to
> mention that what is considered best practices has evolved significantly
> since that book came out, so teams can't simply agree on "We'll just follow
> PBP guidelines" and call it a day, but should stud
Jon Lang elaborated:
> I don't think that there will be a problem. First, #=> is easy enough
> to distinguish from #=; I don't foresee any confusion.
I'm not so sure. #=> is a lot more like #= that =alias is. And the one
character of difference is on the non-significant (right-hand) side.
Need t
Jon Lang huh'd:
> Huh. Would you be able to do something like:
>
> =begin pod
> Welcome to $?FILE.
>
> ...and have it interpolate the file's name? Or would you need some
> special markup for this, such as:
>
> =begin pod
> Welcome to A<$?FILE>.
The latter. Variables are just too com
Jon Lang kept his promise:
> I promised some further thoughts; here they are:
Much appreciated.
> As written, declarator aliasing attaches the alias to a piece of code,
> and draws both the name and the alias from that. What about using a
> special case of the declarator block for this? That
Raiph elucidated:
> Hmm. I was thinking Pod would be parsed by a P6/PGE grammar, one that
> could be relatively easily edited/extended to suit another context, because,
> I thought, it could then be made available as a stock --doc subsystem that
> all PCT based languages get more or less for free.
Smylers pointed out:
>> * Hence it must always parsed using full Perl 6 grammar: perl6 -doc
>
> Having a multi-character option preceded by a single hyphen doesn't play
> well with bundling of single-character options...
You make many good points. Changed to: perl --doc
Thanks,
Damian
Jonathan "Dataweaver" Lang proposed:
> OK. Let me propose an alternative (which I expect will be immediately
> shot down):
BANG!
;-)
> Allow '=begin alias', '=end alias', and '=for alias' as special cases:
> the Perl parser makes an exception for them and doesn't treat them as
> the start or
Kyle suggested:
> Pod itself is a DSL.
Sure. But to allow arbitrary processing and rendering of Pod, a DSL
isn't enough.
> If we're committed to giving guns to books, can we default to having
> the safety on? Can it be so that 'perl6doc foo.pl' does not execute
> any code without an option to al
> Could we also get "=numbered" and "=term" directives that are
> equivalent to "=item :numbered" and "=item :term", respectively, for
> use with abbreviated blocks? E.g.:
>
> =numbered First Item
> =numbered Second Item
> =numbered Third Item
That's just:
=item # First Item
=i
Jonathan "Dataweaver" Lang enquired:
> Will ther be any ambiguity between Pod and wraparound operators that
> begin with =?
No. Lines that start with an '=' that is *immediately* followed by an
identifier are always Pod. If there's a space after the '=' it's always
an assignment. You could *creat
Raiph commented:
> Couldn't the pod processing be encapsulated, perhaps in PGE/NQP, so
> that it could be reused in a different Parrot language, provided that
> said language supports declarators and comments, or even just comments
> (if one downgrades the impact of encountering an "attached" comm
Moritz wrote:
> However it seems we have to pay a price: each act of rendering a Pod
> file actually means executing the program that's being documented (at
> least the BEGIN blocks and other stuff that happens at compile time),
> with all the security risks implied. So we'll need a *very* good
>
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 ment
Raiph Mellor hyperpunned:
> With this whiny man exchange ultimately having bourne supreme fruit,
> the apocalypse watch for the post damian weekend begins...
ARRRG!
Damian ;-)
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 in
Mark J. Reed wrote:
> My understanding is that the P6 way to do that is to return a Capture
> containing the desired return values (which can lazily do things only
> when accessed) in the appropriate slots.
Return a Capture or a more heavily overloaded object, depending on how
fine a degree of co
Perl 6's approach to xor is consistent with the linguistic sense of
'xor' ("You may have a soup (x)or a salad (x)or a cocktail"), and also
with the IEEE 91 standard for logic gates. See:
http://ozark.hendrix.edu/~burch/logisim/docs/2.1.0/libs/gates/xor.html
for a concise explanation of both t
Larry mused:
> �...@a.mung
>
> the .mung could return
>
> A) a modified @a (treat @a as mutable)
> B) a new array (treat @a as immutable)
> C) a remapped array whose elements refer back to @a's elements
>
> Currently .rotate is defined as A, but I could easily switch it to B,
I, for on
Daniel Ruoso asked:
>> &prefix:<[+]>
>
> Is that really? I mean... [ ] is a meta-operator,
Sure. But once you "[]-meta" an infix operator, you get a prefix operator.
See http://perlcabal.org/syn/S03.html#Reduction_operators, which states:
"Any infix operator (except for non-associating opera
Mark J. Reed asked:
> So how is this:
>
>> Any infix operator (except for non-associating operators) can be surrounded
>> by square brackets in term position to create a list operator
>> that reduces using that operation:
>
> reconciled with this:
>
>> Any ordinary infix operator may be enclosed
Jon Lang suggested:
> Start with the addition operator, '1 + 1'. Apply the reducing
> metaoperator to it so that it works syntactically like a function:
> '[+] 1, 1'. Instead of calling it, pass a code reference to it:
> '&[+]'.
No. &[+] isn't the Code object for [+]; it's the Code object for &
Daniel Carrera wrote:
> This is a really good list. Mind if I copy it / modify it and post it
> somewhere like my blog?
That's fine.
> One question:
>
>> * Compactness of expression + semi-infinite data structures:
>>
>> �...@fib = 1,1...&[+] # The entire Fibonacci sequence
>
>
Here are a few of my favourite Perl 6 selling points:
* Compactness of expression:
say 'Hello, World!';
* Compactness of expression + semi-infinite data structures:
@fib = 1,1...&[+]# The entire Fibonacci sequence
* Junctions make comparisons much more natur
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
> something which would is very useful in a REPL, and for docum
Moritz Lenz wrote:
> Instead we should provide a very DWIMmy way to (lazily) create objects
> that behave differently in different contexts.
That's precisely what the Contextual::Return module does for Perl 5.
It's less than perfect in Perl 5, because it has to be implemented via
runtime tricker
Richard Hainsworth conjectured:
> 1) Is the following true for an any junction?
> any( ... , any('foo','bar')) === any(...,'foo','bar')
>
> If yes, then
> if an 'any' junction is contained in an outer 'any', the inner 'any' can be
> factored out?
Yes. More precisely, an 'any' that is directly nes
> I stand corrected. That said: with the eigenstates method now private,
> it is now quite difficult to get a list of the eigenstates of the
> above expression.
Yes, that's a concern. Most of the interesting junction-based algorithms
I've developed in the past rely on two facilities: the ability t
Jon Lang wrote:
> For that matter, I'm not seeing a difference between:
>
>any( 1&2 ) # any of all of (1, 2)
>
> ...and:
>
>any( 1, 2 ) # any of (1, 2)
Those two are very different.
any(1,2) == 2 is true
any(1&2) == 2 is false
Nested heterogeneous junctions are extremely u
Earlier I wrote:
> Maybe just something like one of the attached graphics
> (only redone by someone with actual graphical design skills ;-)?
It occurs to me that this comment might be misread as an implied
criticism of Conrad's original artwork as well. Just wanted to make it
very clear that was
Larry observed:
> My feeling on this is that the compiler should simply hardwire this
> particular adverb so that all the tests can be autogenerated, and the
> multi system never needs to see those versions.
I strongly agree.
> We are merely hijacking the adverb syntax so that is clear which
>
Larry wrote:
You have to have a way of talking about your own attributes *as if*
they were not your own attributes, and $.foo is that way.
When thinking about this, it's also important to remember that, in Perl 6, not
everything with a sigil is automatically writeable. For example:
On Sat, Sep 06, 2008 at 07:06:30PM +1100, Илья wrote:
: Hello there,
: what :foo<> should exactly produce?
: At first I was expecting:
: foo => ""
: but in Rakudo:
: foo => []
: and it looks like the right thing on the other hand.
At YAPC::EU I pointed out to Larry that we have an adverbial form
Moritz Lenz wrote:
There are some tests for List.uniq in the test suite, and pugs
implements it, but it's not in S29.
Damian seems to have though we should have it.
So should we have it?
I still think we should. If only because I've seen it re-(mis)-implemented so
many times.
I'd also sugg
Richard Hainsworth wrote:
Consider the position you put me, or another sponsor, in.
I want to endorse everything Richard then went on to say.
I have already contacted Uri and expressed my dismay at his entirely
inappropriate interjection of an advertisement for our Perl College event into
t
Just a brief note to reassure Mark--and everyone else who's interested--
that I'm not ignoring his post...I'm just fully occupied at the moment
with other (paying) work. In the meantime I'm thinking very carefully
about what Mark suggested. I'll reply properly as soon as I am able.
Damian
Mark Overmeer wrote:
>> Would the following syntax suffice?
>>
>>method isValidPostalCode(str $postalcode) returns bool {...}
>>=PURPOSE Check weather the postal code confirms to the standards
>>=ARG $postalcode
>>a string with blanks trimmed.
>>=RETURN
>>the stri
1 - 100 of 1282 matches
Mail list logo
