Larry Wall wrote:
> Jon Lang wrote:
> : And with package versioning, you may not need an "is instead"
> : equivalent: if you want to "redefine" a package, just create a newer
> : version of it in a tighter lexical scope than the original package was
> : in.
In reading over the Debugging draft (i.e., the future S20), I ran
across the concept of the infectious trait - that is, a trait that
doesn't just get applied to the thing to which it is explicitly
applied; rather, it tends to spread to whatever else that thing comes
in contact with. "Taint" is the
Darren Duncan wrote:
> There are ways to get what you want if you're willing to trade for more
> restrictiveness in the relevant contexts.
>
> If we have a way of marking types/values and routines somehow as being pure,
> in the types case marking it as consisting of just immutable values, and in
>
Martin D Kealey wrote:
> On Mon, 16 Feb 2009, Jon Lang wrote:
>> if there's any doubt about the matter (e.g., conclusively proving or
>> disproving purity would be NP-complete or a halting problem), then
>
> Deciding whether you have a halting problem IS a halting problem
Larry Wall wrote:
> So it might be better as a (very tight?) operator, regardless of
> the spelling:
>
> $x ~~ $y within $epsilon
I like this: it's readable and intuitive. As well, it leaves ±
available for use in its mathematical sense.
> For what it's worth, ± does happen to be in Latin-1,
Daniel Ruoso wrote:
> What about...
>
> if $x ~~ [..] $x ± $epsilon {...}
>
> That would mean that $x ± $epsilon in list context returned each value,
> where in scalar context returned a junction, so the reduction operator
> could do its job...
(I'm assuming that you meant something like "if $y ~
TSa wrote:
> Larry Wall wrote:
>> So it might be better as a (very tight?) operator, regardless of
>> the spelling:
>>
>> $x ~~ $y within $epsilon
>
> This is a pretty add-on to smartmatch but I still think
> we are wasting a valueable slot in the smartmatch table
> by making numeric $x ~~ $y s
On Tue, Feb 24, 2009 at 1:39 PM, Daniel Ruoso wrote:
> Em Ter, 2009-02-24 às 13:34 -0800, Jon Lang escreveu:
>> Daniel Ruoso wrote:
>> > if $y ~~ [..] $x ± $epsilon {...}
>> Junctions should not return individual values in list context,
>
> It is not the junction th
Doug McNutt wrote:
> Thinking about what I actually do. . .
>
> A near equal test of a float ought to be a fractional error based on the
> current value of the float.
>
> $x tested for between $a*(1.0 + $errorfraction) and $a*(1.0 -
> $errorfraction)
>
> If you're dealing with propagation of error
Someone should go through the Parametric Roles section and properly
indent the code blocks. They're not rendering properly at
http://perlcabal.org/syn/S14.html
--
Jonathan "Dataweaver" Lang
On Fri, Feb 13, 2009 at 11:49 AM, Larry Wall wrote:
> On Fri, Feb 13, 2009 at 10:24:14AM -0800, Jon Lang wrote:
> : Given that signatures have grown well beyond their origins as
> : subroutine parameter lists, and given that signatures have their own
> : syntax, perhaps they should
Mark J. Reed wrote:
> I do quite like the magical postfix %, but I wonder how far it should
> go beyond ±:
>
> $x += 5%; # becomes $x += ($x * .05)? Or maybe $x *= 1.05 ?
> $x * 5%; # becomes $x * .05 ?
If it works with ±, it ought to work with + and -. Rule of thumb: if
there's no easy way
TSa wrote:
> HaloO,
>
> Jon Lang wrote:
>>
>> �...@a[50%] # accesses the middle item in the list, since Whatever is
>> set to the length of the list.
>
> I don't understand what you mean with setting Whatever. Whatever is
> a type that mostly be
Daniel Ruoso wrote:
> Em Qui, 2009-02-26 às 17:01 +0100, TSa escreveu:
>> $y.error = 0.001;
>> $x ~~ $y;
>
> Looking at this I just started wondering... why wouldn't that be made
> with:
>
> my $y = 10 but Imprecise(5%);
> $x ~~ $y;
That's not bad; I like it.
--
Jonathan "Dataweaver"
Jon Lang wrote:
> TSa wrote:
>> Jon Lang wrote:
>>>
>>> �...@a[50%] # accesses the middle item in the list, since Whatever is
>>> set to the length of the list.
>>
>> I don't understand what you mean with setting Whatever. Whatever is
&
Martin D Kealey wrote:
> On Thu, 26 Feb 2009, Jon Lang wrote:
>> asin is not the inverse function of sin, although it's probably as close
>> as you can get. And even there, some sort of compiler optimization could
>> potentially be done, replacing the composition of asin
Darren Duncan wrote:
> I don't know if this was previously discussed and dismissed but ...
>
> Inspired by some recent discussion in the "comparing inexact values" thread
> plus some temporal discussion and some older thoughts ...
>
> I was thinking that Perl 6 ought to have a generic interval type
Let me see if I'm grasping the concept here: by default, all functions
are British in the sense that they always do things the British way no
matter where they are in the world:their behavior is determined by the
culture in which they were raised. In contrast, lifted code "goes
native" and does th
> +Note that in each piec of lifted code there are references to
Typo: s/piec/piece/
--
Jonathan "Dataweaver" Lang
--
Jonathan "Dataweaver" Lang
On Fri, Feb 27, 2009 at 1:19 AM, Darren Duncan wrote:
> Jon, I like all of your stated ideas in general. I also don't care about
> the postfix %; that was just a concept example pulled from the inexact
> comparison thread. The idea of using zero is also appropriate conceptually
> with shades of
Under the section about twigils in S02, "$=var" is described as a "pod
variable". I'm not finding any other references to pod variables;
what are tey, and how are they used? (In particular, I'm wondering if
they're a fossil; if they aren't, I'd expect further information about
them to be in S26.)
Darren Duncan wrote:
> In reply to Jon Lang,
>
> What I'm proposing here in the general case, is a generic collection type,
> "Interval" say, that can represent a discontinuous interval of an ordered
> type. A simple way of defining such a type is that it is a &qu
Thomas Sandlaß wrote:
> The benefit of a dedicated Interval type comes from supporting set
> operations (&), (|) etc. which are still unmentioned in S03.
Have set operations been implemented in either Rakudo or Pugs?
> BTW,
> what does (1..^5).max return? I think it should be 4 because this
> is
Daniel Ruoso wrote:
> Daniel Ruoso escreveu:
>> What really got me confused is that I don't see what problem this change
>> solves, since it doesn't seem that a signature that expects an invocant
>> (i.e.: cares about invocant) will accept a call without an invocant, so
>> "method foo($b,$c) is exp
Darren Duncan wrote:
> Here's a question:
>
> Say I had an N-adic routine where in OO terms the invocant is one of the N
> terms, and which of those is the invocant doesn't matter, and what we really
> want to have is the invocant automatically being a member of the input list.
How about allowing
OK; let me get a quick clarification here. How does:
say "Hello, World!";
differ from:
"Hello, World!".say;
or:
say $*OUT: "Hello, World!";
in terms of dispatching? And more generally, would there be a
reasonable way to write a single routine (i.e., implementation) that
could be
> +To declare an item that is parsed as a simple term, you must use the
> +form C<< term: >>, or some other form of constant declaration such
> +as an enum declaration. Such a term never looks for its arguments,
> +is never considered a list prefix operator, and may not work with
> +subsequent par
On Sat, Mar 14, 2009 at 7:29 AM, Larry Wall wrote:
> : So if I were to say:
> :
> : rand $n:
> :
> : is the compiler smart enough to notice that trailing colon and
> : recognize this as an indirect method call rather than two adjacent
> : terms?
>
> No, currently under STD you get:
>
> Obso
This isn't the first (or second, or third, or fourth...) time that
I've seen complications arise with regard to junctions. Every time,
the confusion arises when some variation of the question "is it a
junction?" is raised. Ultimately, this is because Perl is trying it's
darnedest to treat Junctio
Larry Wall wrote:
> Sigh. The current design of Junctions is quite extensible *because*
> it is based on a real type. You can easily write operators that
> work only on Junctions, just as you can easily write operators that
> are transparent to Junctions or autothread on Junctions by declaring
>
Ovid wrote:
> Requiring methods and requiring methods to be called are different things.
> It might be a nice feature to have roles which tie into "events". If a
> particular condition doesn't hold true by, say, INIT time, the role fails.
>
> How would I implement something like that in Perl 6?
OK: as I see it, this is how signatures work:
There are three broad use-cases for signatures: function parameters
(S06), role parameters (S14), and variable declarators (S03).
Question: Do binding operators (S03) count as a fourth use?
There are two broad styles of signatures: those that want an
Larry Wall wrote:
> This is basically a non-problem. Junctions have one public method,
> .eigenstates, which is vanishingly unlikely to be used by accident by
> any mere mortal any time in the next 100 years, give or take a year.
> If someone does happen to be programming quantum mechanics in Perl
Darren Duncan wrote:
> Jon Lang wrote:
>> Larry Wall wrote:
>>> This is basically a non-problem. Junctions have one public method,
>>> .eigenstates, which is vanishingly unlikely to be used by accident by
>>> any mere mortal any time in the next 100 years, give
Larry Wall wrote:
> I think I've mentioned before that .perl autothreads. It's the final
> (low-level) stringification of a junction that slaps the appropriate
> quantifier around that, I suspect.
Please bear with me; I'm starting to get a little lost: are you
telling me that $j.perl does what I'
Darren Duncan wrote:
>
> Jon Lang wrote:
>>
>> Darren Duncan wrote:
>>> I would assume that invoking .perl on a Junction would result in Perl
>>> code
>>> consisting of the appropriate any/all/etc expression. -- Darren Duncan
>>
>> Tough to
> + method !eigenstates (Junction $j: --> List)
Shouldn't that be lowercase-j junction?
--
Jonathan "Dataweaver" Lang
Darren Duncan wrote:
> Maybe the problem is a technicality with the parser because ...
>
> I'm guessing that the problem is that until you see the <-- then what you've
> read so far on its left is ambiguous as to whether it is a result type or a
> parameter. I can understand that but I don't know
Darren Duncan wrote:
> Jon Lang wrote:
>> Spitballing here: you drew an analogy to the feed operators. I wonder
>> if that analogy could be taken further: use --> and <-- outside of
>> signatures as feed operators - but instead of feeding arrays back and
>> fort
2009/3/24 Larry Wall :
> http://www.wall.org/~larry/camelia.pdf
Cute. I do like the hyper-operated smiley-face.
What I'd really like to see, though, is a logo that speaks to Perl's
linguistic roots. That, more than anything else I can think of, is
_the_ defining feature of Perl.
--
Jonathan "
In the case of strings and numbers, I'd recommend using leg instead of
cmp - that is, coerce both items to strings, then compare the strings.
But as far as cmp goes, "3 cmp '3'" should fail because a number
isn't a string.
--
Jonathan "Dataweaver" Lang
On Fri, Mar 27, 2009 at 10:39 AM, Dave Whipp wrote:
> Richard Hainsworth wrote:
>>
>> The following arose out of a discussion on #perl6. Junctions are new and
>> different from anything I have encountered, but I cant get rid of the
>> feeling that there needs to be some more flexibility in their u
Dave Whipp wrote:
> [I’d been planning to put this suggestion on hold until the spec is
> sufficiently complete for me to attempt to implement it as a module. But
> people are discussing this again, so maybe it's not just me. I apologize if
> I appear to be beating a dead horse
Damian Conway wrote:
> 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.
Daniel Ruoso wrote:
> But the semantics of sets are still somewhat blurry... there are some
> possibilities:
>
> 1) Sets are in the same level as junctions, but have no collapsing and
> allow you to get its values. The problem is if it autothreads on
> method calls or not... It also makes
On Sat, Mar 28, 2009 at 6:39 AM, Daniel Ruoso wrote:
> Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu:
>> Daniel Ruoso wrote:
>> > The thing is that junctions are so cool that people like to use it for
>> > more things than it's really usefull (overseeing that junctions are too
>>
Thomas Sandlaß wrote:
> Set operations are with parens.
Which Synopsis is this in?
--
Jonathan "Dataweaver" Lang
Henry Baragar wrote:
> The blackjack program is an excellent example for junctions (and not so good
> for sets, IMHO). The problem in the example above is that the calculation
> of the value of a hand was not completed. The complete calculation is as
> follows:
>
> my $pa = ([+] @a).eigenstates
On Sun, Mar 29, 2009 at 1:18 PM, John Macdonald wrote:
> On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote:
>> That happens because $pa and $pb are a singular value, and that's how
>> junctions work... The blackjack program is an example for sets, not
>> junctions.
>>
>> Now, what are j
Moritz Lenz wrote:
> Since afaict this is not specced, I'll hand that over to p6l.
>
> Eric Hodges (via RT) wrote:
>> use v6;
>>
>> rule test {test};
>>
>> "test" ~~ //;
>> say '$/.keys => ', $/.keys.perl;
>> say '%($/).keys => ', %($/).keys.perl;
>>
>> # outputs
>> # $/.keys => []
>> # %($/).keys
On Sun, Mar 29, 2009 at 10:57 PM, Mark Lentczner wrote:
> What I see here is that there is a tendency to want to think about, and
> operate on, the eigenstates as a Set, but this seems to destroy the "single
> value" impersonation of the Junction.
In my case, this tendency comes more from a desir
Here's another useful one:
any($x) eqv all($x) eqv one($x) eqv $x
but:
none($x) !eqv $x
That is, applying any, all, or one to a one-item list produces the
equivalent to a single item. For an empty list: any() eqv all() eqv
(). But what about one() and none()?
--
Jonathan "Dataweaver
In "Junction Algebra", Martin Kealey wrote:
> On Mon, 30 Mar 2009, Mark J. Reed wrote:
>> > ( $a <= any(-1,+1) <= $b ) == ( $a <= any(-1,+1) && any(-1,+1) <=
>> > $b )
>>
>> Clearly, the RHS is true for $a == $b == 0, but I'm not sure the LHS
>> shouldn't also be. Isn't it just syntactic s
I've been having some second thoughts concerning this. Here's where I
stand on it now:
In Perl 6, you have the following "decision points", where code may or
may not be executed depending on a condition:
if/unless/while/until/loop/when statements; if/unless/while/until
statement modifiers; short-
Yes, I know that there is no S08. I'm working on writing one, and I'd
like some feedback to help me do so.
My draft is going to be about Signatures and Captures. Thus, my questions:
Invocants:
* Is it illegal to specify an invocant in a sub, or is it merely
nonsensical? That is, should the co
Jonathan Worthington wrote:
> Jon Lang wrote:
>>
>> Invocants:
>>
>> * Does anyone object to roles having an invocant, and that invocant
>> referring to the class that is doing the role?
>>
>>
>
> Yes; on further reflection, the ability to typ
On Wed, Apr 1, 2009 at 12:58 AM, Richard Hainsworth
wrote:
> Thinking about Jon Lang's -1|+1 example in another way, I wondered about
> simultaneous conditions.
>
> Consider
>
> $x = any (1,2,5,6)
>
> How do we compose a conditional that asks if any of this set of eigenstates
> are simultaneously
On Wed, Apr 1, 2009 at 5:07 AM, Daniel Ruoso wrote:
> Em Ter, 2009-03-31 às 22:54 -0700, Jon Lang escreveu:
>> Yes, I know that there is no S08. I'm working on writing one, and I'd
>> like some feedback to help me do so.
>
> ++
>
>> My draft is going to
Martin Kealey wrote:
> On Tue, 31 Mar 2009, Jon Lang wrote:
>> Another issue: what happens if conditional code mutates a junction
>> that it filtered? For example:
>>
>> $x = any (-5 .. 5);
>> if $x > 0 { $x++ };
>>
>> At this point, which
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
> @@ -1836,6 +1836,12 @@
> prototype objects, in which case stringification is not likely to
> produce something of interest to non-gurus.)
>
> +The C<.^parents> method by default returns a flattened list of all
> +parents sorted in MRO (dispatch) order. Other options are:
> +
> + :local
On Thu, May 21, 2009 at 11:25 PM, John M. Dlugosz
<2nb81l...@sneakemail.com> wrote:
> Larry Wall larry-at-wall.org |Perl 6| wrote:
>>
>> And since the "when" modifier counts as a conditional, you can rewrite
>>
>> grep Dog, @mammals
>>
>> as
>>
>> $_ when Dog for @mammals;
>>
>> So perhaps wi
On Fri, May 22, 2009 at 5:34 AM, Timothy S. Nelson
wrote:
> On Fri, 22 May 2009, Jonathan Worthington wrote:
>
>> Daniel Ruoso wrote:
>>>
>>> Em Sex, 2009-05-22 às 01:25 -0500, John M. Dlugosz escreveu:
>>>
�...@primes = do $_ if prime($_) for 1..100;
becomes
�...@primes = $_ wh
On Mon, May 25, 2009 at 2:13 PM, Daniel Carrera
wrote:
> In this way, a relatively simple change makes Perl 6 Pod able to do literate
> programing for anyone who is interested.
>
> What do you think?
The main literate programming feature that's missing from POD is the
ability to scramble the orde
>From S09, under Junctions:
"The exact semantics of autothreading with respect to control
structures are subject to change over time; it is therefore erroneous
to pass junctions to any control construct that is not implemented via
as a normal single or multi dispatch. In particular, threading
junc
On Tue, May 26, 2009 at 8:05 PM, John M. Dlugosz
<2nb81l...@sneakemail.com> wrote:
> Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
>>
>> >From S09, under Junctions:
>>
>> "The exact semantics of autothreading with respect to control
>> structures a
Andrew Whitworth wrote:
> The issue mentioned in the Synopses is that junctions autothread, and
> autothreading in a conditional could potentially create multiple
> threads of execution, all of which are taking different execution
> paths. At some point, to bring it all back together again, the var
On Wed, May 27, 2009 at 7:05 AM, John Macdonald wrote:
> On Tue, May 26, 2009 at 04:38:21PM -0700, yary wrote:
>> perl4-perl5.8 or so had a variable that let you change the starting
>> index for arrays, so you could actually make the above work. But then
>> everyone who'd re-arranged their brains
Jonathan Scott Duff wrote:
> Or perhaps
>
> for 0...@foo.end -> $k { ... }
>
> @foo.keys may not be what the user wanted if @foo is a sparse array.
IIRC, you have to explicitly ask for the custom index in order to get
"sparse array" keys. By design, the normal index is never sparse;
only the c
On Thu, May 28, 2009 at 1:37 AM, Daniel Carrera
wrote:
> Hi Damian,
>
> This is a really good list. Mind if I copy it / modify it and post it
> somewhere like my blog? One question:
>
>> * Compactness of expression + semi-infinite data structures:
>>
>> �...@fib = 1,1...&[+] # The
On Fri, May 29, 2009 at 6:52 AM, John Macdonald wrote:
> Yep, I've done that.
>
> But comparing the difference in effort between:
>
> - press a key
> - Google for a web page that has the right character set, cut, refocus, paste
>
> means that I don't bother for the one or two "weird" characters
>
On Fri, May 29, 2009 at 6:53 PM, Darren Duncan wrote:
> I had some thoughts lately about the Perl 6 operators, and wanted to bounce
> some ideas.
>
>
>
> Firstly, regarding the string replication ops as documented in Synopsis 3,
> 'x' and 'xx', I'm wondering whether it might be better to
Darren Duncan wrote:
>> Side note: one thing that I recently learned concerning implication
>> operators is that the direction of the implication doesn't necessarily
>> follow the direction of the arrow. In particular, "A if B" is "A←B",
>> and "A only if B" is "A→B": in both of the original state
On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera
wrote:
> I think we might need to come up with some sort of standard naming
> convention to distinguish dependencies. Something that the *user* can
> recognize quickly when he browses CPAN.
Why do we need the dependencies to be part of the name? Per
On Thu, Jun 4, 2009 at 9:57 AM, TSa wrote:
> HaloO,
>
> Daniel Ruoso wrote:
>>
>> So the questions are:
>>
>> * Are there any imperative barriers in Perl 6?
>
> I would think that at least every method call is a barrier.
> An object's lifetime is a sequence of states and methods are either
> retu
2009/6/8 Ville Koskinen :
> Hello all,
>
> I was curious if this is possible in Perl 6:
>
> %hash{ 'foo' & 'bar' } = 'some value';
> # %hash{'foo'} eq 'some value' and %hash{'bar'} eq 'some value'
By autothreading, this would be equivalent to:
(%hash{'foo'} & %hash{'bar'}) = 'some value';
wh
On Fri, Jun 12, 2009 at 10:02 AM, yary wrote:
> I am tickled pink to see an Array "rotate" method in the settings spec
> S032, as I was thinking of writing up a little discussion on the very
> topic.
>
> Has there been discussion on using array rotate on multi-dimensional
> arrays? Being able to pa
On Fri, Jun 12, 2009 at 10:58 AM, yary wrote:
>> * you can rearrange the dimensions themselves (e.g., transpose).
>
> Reflecting on 2 or more axes creates a transposition.
No, it doesn't:
@a = (1, 2, 3; 4, 5, 6; 7, 8, 9);
Reflecting on two axes would result in:
@a = (9, 8, 7; 6, 5, 4; 3
On Fri, Jun 12, 2009 at 11:51 AM, Daniel Ruoso wrote:
> Ok, There's one thing that is not clear in the thread, which is when an
> array is multidimensional or not...
>
> For instance:
>
> �...@a = (1, 2, 3; 4, 5, 6; 7, 8, 9);
>
> Will produce a flatten array, because list assignment causes flatteni
On Fri, Jun 12, 2009 at 11:23 PM, Matthew
Walton wrote:
> Although some things may be able to be implemented far more
> efficiently if they know that they're being called with infix:<.=> and
> not with infix:<.>.
Last I checked, Perl 6 had some types that are mutating and others
that aren't (e.g.,
On Mon, Jun 22, 2009 at 4:12 PM, Minimiscience wrote:
> On Jun 22, 2009, at 5:51 PM, Damian Conway wrote:
>>
>> 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.
Take a look at the page to which Damian provided a link. You'll find
that XOR does indeed correspond to the definition being used by Perl
6, as well as the natural language meaning. What other languages call
XOR is actually an "odd parity check".
As I suggested above, I think that Perl 6 already
On Wed, Jun 24, 2009 at 10:35 AM, John Macdonald wrote:
> On Tue, Jun 23, 2009 at 07:51:45AM +1000, Damian Conway wrote:
>> 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"), [ ... ]
>
> That choice tends to mean "exa
On Thu, Jun 25, 2009 at 1:20 PM, Moritz Lenz wrote:
> Hi,
>
> I had the pleasure to implement the series operator (&infix:<...>) in
> Rakudo(*), and came across the difficulty to come up with a signature
> for it. These are the use cases I want to cover:
>
> 1, 2 ... { $^a + $^b }
> 1 ... { $_ + 1
On Tue, Jul 7, 2009 at 2:48 AM,
Ovid wrote:
>
> Giving a talk about roles at YAPC::EU in Lisbon and I'm a bit stuck on how to
> translate a Perl 5 example into Perl 6. Basically, Imagine a "PracticalJoke"
> class which has fuse() and explode methods(). It needs the timed fuse() from
> a Bomb r
Jonathan Worthington wrote:
> Ovid wrote:
>> Though I have issues with Jonathan's approach (I don't like classes
>> silently discarding role methods as this has caused us many bugs at the
>> BBC), it's much cleaner that what I see here.
>
> s/Jonathan's approach/Perl 6's approach/ # at least, so fa
Jonathan Worthington wrote in "YAPC::EU and Perl 6 Roles":
> More fitting to me would be an adverb to the does trait modifier...
>
> class C does R1 :without does R2 :without { ... }
>
> The thing is that in this case, does the class actually do R1 and R2? If you
> are going to derive an anonymous
The question is whether or not Rakudo is smart enough to realize that
R1::foo is the same as R2::foo, or if it complains that R1 and R2 are
both trying to supply implementations for foo. The former is the
desired behavior.
> I guess being able to create a role by dropping some bits from an existing
The question is whether or not Rakudo is smart enough to realize that
R1::foo is the same as R2::foo, or if it complains that R1 and R2 are
both trying to supply implementations for foo. The former is the
desired behavior.
> I guess being able to create a role by dropping some bits from an existing
Larry Wall wrote:
> Dave Whipp wrote:
>> Ovid wrote:
>>
>>> I'd like to see something like this (or whatever the equivalent Perl 6
>>> syntax would be):
>>>
>>> class PracticalJoke does Bomb does SomeThingElse {
>>> method fuse() but overrides { ... }
>>> }
>>>
>>> The "overrides" tells Pe
On Fri, Jul 10, 2009 at 2:22 PM, Austin
Hastings wrote:
> Mark J. Reed wrote:
>>
>> I'm all for not having any variety of log() in the default namespace.
>> Regardless, mathematical functions should follow mathematical norms.
>> Changing Perl tradition is one thing, but we have centuries, sometimes
Jon Lang wrote:
> "supersede" already has a meaning with respect to classes; and what
> I'm thinking of would apply to classes as well as roles; so I'm going
> to suggest another keyword.
>
> How about this: in role composition, "mandate" causes methods
Daniel Ruoso wrote:
> Jon Lang wrote:
>> The key to understanding roles is to note that roles don't implement
>> methods; classes implement methods.
>
> Er, while I see your point, Roles are not just interfaces... they are OO
> components that can be plugged into other
Raphael Descamps wrote:
> Am Freitag, den 10.07.2009, 17:06 -0700 schrieb Jon Lang:
>> How about this: in role composition, "mandate" causes methods to take
>> precedence over other methods with which they would normally conflict,
>> and to conflict with methods that
TSa wrote:
> HaloO,
>
> Jon Lang wrote:
>>
>> Well, yes and no. The class still has the final say on how a given
>> method is to be implemented; the only thing being debated here is
>> whether or not the class should have to explicitly pull rank to
>> red
On Mon, Jul 20, 2009 at 6:03 PM, wrote:
> Author: lwall
> Date: 2009-07-21 03:03:38 +0200 (Tue, 21 Jul 2009)
> New Revision: 27635
>
> Modified:
> docs/Perl6/Spec/S03-operators.pod
> Log:
> [S03] rename 'nonchaining infix' to 'structural infix'
>
>
> Modified: docs/Perl6/Spec/S03-operators.pod
>
On Mon, Jul 20, 2009 at 7:15 PM, Darren Duncan wrote:
> Jon Lang wrote:
>>
>> On Mon, Jul 20, 2009 at 6:03 PM, wrote:
>>>
>>> Modified: docs/Perl6/Spec/S03-operators.pod
>>> ===
>>>
Larry Wall wrote:
> Moritz Lenz wrote:
> : Either it's parsed as '@a[0] = (W, W)' (list assignment), then @a should
> : get both elements, and so should @z.
>
> Not according to S03, at least by one reading. �...@a[0] as a scalar
> container only wants one item, so it only takes the first item off
Damian Conway wrote:
> 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, dependin
On Mon, Aug 10, 2009 at 12:25 PM, Patrick R. Michaud wrote:
> I'd be fine with the ##(embedded comment solution) approach (doubling
> the #'s), but it's much less visually appealing to me. I think I'd
> prefer to see a doubling of the bracketing chars instead of doubling
> the #'s -- the # is visu
101 - 200 of 329 matches
Mail list logo
