Larry wrote:
I would like to point out that for mere mortals, *any* MMD is already too
complex to be predictable.
This is the relevant observation here.
This particular mortal's experience is that more than four variants, involving
parameters from more than two hierarchies makes it nearly
Piers Cawley wrote:
Here's a rubyish idiom:
my old_behaviour := function;
function := sub { try_some_stuff || old_behaviour }
Except, with binding it doesn't work like that, you end up with an infinite
loop.
But this version *should* work correctly:
# Bind the name
chromatic wrote:
I find it ugly enough that I plan to name my invocants explicitly.
...which should be construed as a *feature* of the current syntax. ;-)
Damian
Larry wrote:
: Can I write that as:
:
: sub factorial (Int $n:) {
: return 1 when 0;
: return $n * factorial $n;
: }
As it stands right now, no. Ordinary subs do not allow invocants.
Arguably, it'd be more consistent if ordinary subs always topicalized
their first argument.
John Siracusa wrote:
(BTW, I'm not sure where those ./ thingies came from, but it's what GMail
showed in your message. I'm assuming it should just be .)
No. There's now also a unary ./ operator in Perl 6.
Unary . calls a specified method on the current topic.
Unary ./ calls a specified
Abhijit Mahabal asked:
Er, is it true that methods don't topicalize the invocant nowadays?
If it's not true, it darn well ought to be!
I had thought that they do and one needs the ./ to still talk about the
invocant if some inner loop stole the $_, and until such stealing occurs
.foo()
John Siracusa wrote:
Wow, that..er...how did I miss that? It looks a lot like running an
executable in the current dir instead of letting the shell search its path.
That's the mnemonic, yes. Call this functionality relative to the current
location (i.e. invocant).
Was this syntax
Gaal Yahas wrote:
On Thu, Jun 16, 2005 at 01:26:31PM -0600, Luke Palmer wrote:
Say I have a class method in FooClass, callable as FooClass.greet():
method greet(Class $class: ) {
say Hello, FooClass!;
}
Aside from the fact that I don't think this is the right way to
specify
Patrick wrote:
Somehow I read these as though the original poster was correct --
i.e., one creates a class method for FooClass as either
method greet(Class $class:) { say Hello!; }
Yes. That will work, but it's not the recommended solution.
or
method greet(FooClass $class:) { say
Autrijus asked:
On Wed, Jun 15, 2005 at 05:37:18PM -0500, Patrick R. Michaud wrote:
Based on an off-list discussion, it turns out that unary C=
is not slurpy as mentioned in S04. The following patch to S04
corrects this; I've already applied the patch but thought I'd
pass it by p6l for
TSa (Thomas Sandlaß) wrote:
Let's assume that op is overloaded for two completely unrelated types
A and B, which are both defining their respective identity elements
but !(A.identval =:= B.identval). How should the op multi method object
pick the correct one *without* looking at $value's type?
Edward Cherlin wrote:
You haven't convinced me, but rather than flog a dead horse,
I'll just suggest that we both reserve the right to say I
told you so when there are several years' worth of Perl 6
code out there, and we see how common our respective examples
are.
No need to wait. There is a
Larry wrote:
Okay, I've made up my mind. The err option is not tenable because
it can cloak real exceptions, and having multiple versions of reduce is
simply multiplying entities without adding much power. So let's allow
an optional identvalue trait on operators. If it's there, reduce
can
Deborah Pickett wrote:
You are going to see empty lists more often than you think in expressions like
$product = [*] @array;
and having to write that as
$product = [*] 1, @array;
just to protect against a common case doesn't exactly flaunt Perl's DWIMmery
to me. I *have* to write 1 there,
Carl Franks wrote:
The universal new() would handle the one-argument call exactly the
same as your overloaded new() does.
Is that correct? S12 says...
All classes inherit a default new constructor from Object.
It expects all arguments to be named parameters initializing
attributes of
Carl Franks wrote:
However, if I allowed the default 'new' to handle that case, then the
BUILD submethod has to be aware of that.
I thought it would be cleaner to 'document' the special case with a
seperate constructor, and also not require any special-case logic in the
BUILD submethod.
Is that
Carl Franks wrote:
I have a class that normally takes a list of named arguments.
I also want to be able to handle a single argument.
class Foo {
multi method new (Class $class: Str $date) {
return $class.bless(date = $date);
}
submethod BUILD ($.date, $.time, $.offset) {
#
Adam Kennedy wrote:
Forgive my ignorance here, but for all of these different ways of doing
constants, will they all optimize (including partial
evaluation/currying) at compile/build/init/run-time?
my $gravity is constant = 10; # One significant figure
sub time_to_ground ($height, $accel) {
All this discussion of identity defaults for reductions has been very
interesting and enlightening.
But it seems to me that the simplest correct behaviour for reductions is:
2+ args: interpolate specified operator
1 arg: return that arg
0 args: fail (i.e. thrown or unthrown
Dave Whipp wrote:
Damian Conway wrote:
0 args: fail (i.e. thrown or unthrown exception depending on use
fatal)
...
$sum = ([+] @values err 0);
$prod = ([*] @values err 1);
$prob = ([*] @probs err 0);
Just wanted to check, if I've said use fatal: will that err 0 DWIM
Dave Whipp wrote:
Damian Conway wrote:
And what you'd need to write would be:
$sum = (try{ [+] @values } err 0);
The err ... idiom seems too useful to have it break in this case.
Afterall, the purpose of err 0 is to tell the stupid computer that I
know what to do with the empty
Juerd asked:
2+ args: interpolate specified operator
1 arg: return that arg
0 args: fail (i.e. thrown or unthrown exception depending on use fatal)
Following this logic, does join( , @foo) with [EMAIL PROTECTED] being 0 fail too?
No. It returns empty string. You could think of
Joe Gottman pointed out:
No. It returns empty string. You could think of Cjoin as being
implemented:
sub join (Str $sep, [EMAIL PROTECTED]) { reduce { $^a ~ $sep ~ $^b } ,
@list }
If this were the case, then
join '~', 'a', 'b', 'c'
would equal '~a~b~c' instead of
Brent 'Dax' Royal-Gordon wrote:
Juerd [EMAIL PROTECTED] wrote:
There is no way to get an anonymous rw scalar, is there?
There's always the Perl 5 hack:
\do { my $x }
Although that's not truly anonymous, I suppose.
There's a less-well-known hack that *is* truly anonymous:
Jeff 'japhy' Pinyan wrote:
I'd like to know where EXACTLY whitespace is permitted in rules. Is it
legal to write
\c [CHARACTER NAME]
or must I write
\c[CHARACTER NAME]
The latter, I believe. It's a single token.
Damian
Autrijus Tang wrote:
Hmm, Warnocked? I'll assume this is sane, until told otherwise, then. :)
Darn. I was hoping that Larry would field this one. In his absence, I'll take
a swing at it. The usual all(any(@Larry), none($Larry)) caveats apply.
So I'm finally starting to implement
Luke wrote:
foo($a : $b : $c)
foo($a : $b : $c : )
Hmm, I'm doubting that reflecting how many invocants you have on the
caller side is a good idea. It seems awfully brittle in the face of
reimplementation.
Yep. And that's precisely why we previously ruled against colons in the call
Autrijus wrote:
Err, wait. From S06:
# Indirect multimethod call...
handle_event $w, $e: $m;
Is this single-dispatch?
No. I think it's vestigial (or ought to be). Luke's argument against colons in
multimethod calls is compelling from a maintainability point-of-view.
Damian
Autrijus Tang wrote:
In that case:
$w.handle_event($e: $m);
should be illegal as well, right?
Right.
That is, the App (functional application) form always zero or one
invocants, and it is illegal to specify more than one.
Right.
Damian
Ingo Blechschmidt wrote:
Is it intentional that there's no uniq in the current S29[1] draft?
See [2] for Damian saying that uniq is probably in.
It still probably is.
I wondered what uniq's default comparator should be, =:=?
infix:~~
Should it be possible to give an own comparator block, similar
Luke wrote:
I wondered what uniq's default comparator should be, =:=?
infix:~~
Woah there. ~~ is a good comparator and all, but it's not the right
one here. ~~ compares an object and a pattern to see if they match.
That makes it the right choice for when and grep. But we're trying to
remove
Luke Palmer wrote:
In the absence of a trait specifying otherwise, the precedence
defaults to the same as infix:+.
Heh. It'd be much safer to *require* a precedence specification on any new
operator. If they're changing the parser, they ought to have the decency to be
explicit about precisely
Larry Wall wrote:
On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: Does this mean private methods will be called like this?
:
: ./:method()
No, I think that's still just
.:method()
This missing design rationale here is that the colon acts as part of the unary
operator:
Luke wrote:
Hmm. I'll just [mention] that if != is implemented like this:
multi sub infix:!= (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
I'd be fine with the dwimmy version if that is the underlying rule, since then
the behaviour isn't a special case,
Luke wrote:
If the alternatives are:
* declare $self, use $self.method, and .method for calling on $_
* use .method, and use $_.method for calling on $_
I'd say the former has no case.
I, for one, am not nearly so certain of that.
Our original rationale for that choice was not
Adam Kennedy wrote:
And reduction? I write 25,000+ lines of
Perl a year, and if you are talking about something like
List::Util::reduce, I think I've used it maybe twice?
Which proves what? That you don't (yet) write the sort of code that benefits
from reductions? That you don't (yet) think in
Larry wrote:
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via not raising, or
we have to disallow negative comparisons on junctions entirely.
Opinions?
Making them DWIM here would be a mistake, since the dwimmery would disappear
Larry wrote:
Actually, I think Damian's original formulation is sufficiently clear.
aolMe too!/aol ;-)
I think that a standard [.infix markerpostfix marker] abbreviation for all
postcircumfix operators within [op] reductions would be a useful bit of dwimmery.
Damian
Larry wrote:
I'm still not sure I believe in booleans to that extent. I suppose
we could go as far as to make it :p(0 but true). Actually, it's more
like undef but true, if you want to be able to distinguish
sub foo (+$p = 0) { # no :p at all
say true if $p; # :p with no
Larry Wall wrote:
I think we already said something like that once some number of
months ago. +$1 simply has to be the numeric value of the match.
Agreed.
Anyway, while we could have
a method for the .matchcount, +$1[] should work fine too.
Yep.
Actually, it's not clear to me offhand why @1
Patrick surmised:
So I'm guessing that we're all in agreement that +$/, +$1, and
+$subrule all refer to the numeric value of the string matched,
as opposed to what's currently written about their values in the
draft...?
Yes. The semantics proposed in the draft have proved to be too orthogonal
Uri Guttman wrote:
DC Sure. Just as $42 is a shorthand for $/[42], so too $whatever is a
DC shorthand for $/whatever.
but then what about the different index bases for $42 and $/[42]? i
don't think that has been resolved (nor has mixing the $1.1 and $1[1]
syntaxes).
Bear in mind that that
Larry decreed:
Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
Huzzah!
Our old $0 (P5's $) could be $ instead, short for $MATCH or some
such.
According to the new capture semantics document posted earlier this week:
A successful match returns a CMatch object whose ...
Larry mused:
I'm wondering if it's just a cardinal/ordinal thing, and we can just
translate $7 to $7th. Then we don't have to guess where to insert
a .flat or :flat.
That's a very interesting generalization. There are plenty of *other* cases
where one wants an ordinal, or some other kind of $n-1
Larry Wall wrote:
On Mon, May 09, 2005 at 12:14:35PM -0700, Larry Wall wrote:
: On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote:
: : Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ?
:
: Ouch.
Maybe that's a good reason to switch from 1-based to 0-based
$digit
Patrick R. Michaud wrote:
On Mon, May 09, 2005 at 09:14:02AM -0700, Larry Wall wrote:
: m/ alt: tea (don't) (ray) (me) (for) (solar tea), (d'oh!)
: | alt: BEM (every) (green) (BEM) (devours) (faces)
: /;
This seems like a rather ugly syntax for what is essentially a label,
or a
DC rule mv { $lastcmd:=(mv) $files:=[ ident ]+
$dir:=ident }
DC rule cp { $lastcmd:=(cp) $files:=[ ident ]+
$dir:=ident }
DC sub lastcmd { return $lastcmd }
DC }
DC while shift ~~ m/Shell::Commands.cmd/ {
DC say From: @{$files};
DC
I will be releasing a full description of the new capturing semantics in the
next day or two. It will be appended to the appropriate Synopsis, but I'll
also post it here. It may be as soon as tomorrow, but I'm away teaching this
week, so my time is restricted.
Damian
Autrijus wrote:
/me eagerly awaits new revelation from Damian...
Be careful what you wish for. Here's draft zero. ;-)
Note that there may still be bugs in the examples, or even in the design.
@Larry has thrashed this through pretty carefully, and Patrick has implemented
it for PGE, but it's 10.30
Luke Palmer wrote:
On 5/4/05, Larry Wall [EMAIL PROTECTED] wrote:
[] could mean monotonically increasing.
Not unless we make boolean operators magic. There are arguments for
doing that, but I don't really want to think about how that would be
done at the moment. Reduce over a straight-up (or
[Not back, just sufficiently irritated...]
Luke Palmer wrote:
in my proposal, when you call a coroutine, it returns an iterator (and
doesn't call anything):
my $example = example();
=$example; # 1
=$example; # 2
The thing this buys over the traditional (which I refer to as the
John Macdonald wrote a lovely summary of coroutines [omitted]. Then added:
I'd use resume instead of coreturn
We've generally said we'd be using yield.
and the interface for resume would allow values to be sent
in as well as out.
Indeed. As John suggested, the yield keyword (or whatever we call
[No, I'm not back; I'm just passing by. But I feel that I need to comment on
this whole issue]
Even before Brian announced Kwid, I was privately suggesting to Larry that
Markdown (http://daringfireball.net/projects/markdown/) was an excellent
evolution of mark-up notations and might be well
Oh, and I forgot to mention:
In the contents of any block, any line with '=' in column zero and a
whitespace character in column 1, has those two characters removed when the
contents are extracted. So you can write:
=begin data POSSIBLE_POD_DIRECTIVES
=
= =doh -- Oh, dear! Oh frikking dear!
=
Rod Adams wrote:
The purpose of a junction is to allow for performing several tests at a
given time, with the testing code needing no knowledge of that junctions
are present. While a junction can represent several values at the same
time, such notions as hold and contain should be avoided, and
Juerd wrote:
Naievely, I'd expect
my @a = @b = 1..3;
»foo«(@a, @b)
to result in
foo(@a[0], @b[0]),
foo(@a[1], @b[1]),
foo(@a[2], @b[2]);
but
foo([EMAIL PROTECTED], [EMAIL PROTECTED])
with the same arrays in
foo(@a[0], @b[0]),
foo(@a[0], @b[1]),
foo(@a[0],
Autrijus wrote:
Personally, I think the only reasonable way of resolving this is to
assume (as in the last paragraph above) that function calls in these
kinds of indeterminate contexts are always in list context.
So, even if the clash is Num vs Str context, we still run it
under List context? Or
Aldo Calpini wrote:
Damian Conway wrote:
@s = 'item' _ [EMAIL PROTECTED];
That's:
@s = 'item »_« @x;
(just checking that my unerstanding is correct, don't want to be
nitpicking :-)
assuming that you meant to prepend the string item to each element of
@x, isn't that:
@s
Rod Adams wrote:
This is my major point of the post. In my opinion, your example of:
# Print a list of substrings...
my $substring = substr(junctions, any(1..3), any(3..6));
say $substring.values();
Is a perfect example of a place where saying:
# Print a list of substrings...
my
Steve Peters wrote:
While looking into Perl 6 and pugs, I noticed a problem with Pairs pretty
quickly. Although pairs look like a very useful data type, I could find
in the Perl 6 and Parrot Essentials or any Apocolypse or other document
on how to get the key or value from a pair. I was
Autrijus wrote:
A difficulty arises because the expressions used as arguments
is not evaluated when arityMatch is done, and for good reason --
they may do wildly different things depending on its context.
When Pugs was only implementing FP6, I could affort to force
evaluation for each
Rod Adams asked:
This sound reasonable enough?
Frankly, no. ;-)
Sorry, but your latest proposal sounds complex, multiply special-cased, and
way too much of an imposition on the programmer (which is specifically what
junctions are supposed to avoid).
I'm going to continue to strongly recommend
Nicholas Clark wrote:
On Sun, Feb 20, 2005 at 07:41:16PM +1100, Damian Conway wrote:
Given this:
my $x = set(1..3);
my $y = set(1,3,5,7,9);
my $n = 2;
$x | $y # set(1,2,3,5,7,9)
$x $y # set(1,3)
$x - $y # set(2)
!$x
Hmm. On rereading my last message, I feel that it comes across as angry,
and critical of this entire discussion or perhaps of particular participants.
That was certainly not my intent and I apologize if that's how it appeared. I
genuinely respect the contributions of every person on this
Rod Adams wrote:
I had not caught the difference between:
use junctions;
$x = 6|7|8;
if is_prime($x) {...}
and
if is_prime(6|7|8) {...}
There isn't one.
Is this new, or yet another important detail I missed along the way?
Or is this a side effect of not being able to store a Junction,
Rod Adams wrote:
Simply put,
I want my junctions.
Standard in Perl 6.
I want my hyper operator superstrength arrays.
Standard in Perl 6.
I want them both at the same time.
Standard in Perl 6.
I never want to see implicit threading. Ever.
If this is the only stumbling block, then it's easily
Juerd wrote:
According to S03, ~ is tighter than x, while in Perl 5, . was looser
than x.
No. According to S03, *unary* ~ is tighter than x. *Binary* ~ is looser:
symbolic unary ! + - ~ ? * ** +^ ~^ ?^ \
multiplicative * / % x xx + + + ~ ~ ~
additive+ - ~ +| +^ ~|
Brent 'Dax' Royal-Gordon wrote:
The naive meaning of all of these would be::
any(map { @x[$_] = 7 } 4,3)
all(map { @x[$_] = 7 } 4,3,2)
one(map { @x[$_] = 7 } 1,2)
none(map { @x[$_] = 7 } 1,2)
But I'm not sure the naive interpretation is correct.
A junction as an array index or hash
Thomas Sandlaß wrote:
class Source[Language ::To] is Str {
multi sub *coerce:as (Any $data, To ::Lang) {
return Lang.serialize($data)
}
}
What is the return type of *coerce:as?
Sorry, I was too lazy (well, I'd claim I was thinking at a much higher level,
but
Rod Adams wrote:
All I want now is for autothreading to be explicit.
It already *is*.
The only way that:
is_prime($x)
can ever autothread is if $x holds a junction. But that can now only happen if
there's an explicit Cuse junctions in scope where $x was assigned to (or the
explicit use
Larry wrote:
Actually, I'm thinking we should just go with a single method and
have it merely default to :langPerl. But .repr is rather ugly.
How 'bout .pretty instead? If we made the language the first optional
argument you could have $x.pretty('Lisp'), $x.pretty('C#'), etc.
Hm, maybe
It's been mentioned to me that some folks were surprised that the design team
hasn't been more effusive in it's support for the incredible job that Autrijus
is doing prototyping the Perl 6 interpreter over the top of Haskell.
We had thought that answering his questions about 1000 times faster
Rod Adams wrote:
Okay, so we've established that:
$x = any(3,4,5);
@l = $x.values.sort;
Leaves us with @l == (3,4,5), and that makes a fair amount of sense.
What do the following evaluate to:
@l1 = all(3,4,5).values.sort;
Same.
@l2 = one(3,4,5).values.sort;
Same.
@l3 = none(3,4,5).values.sort;
Larry wrote:
That's the basic problem with
0 $x 10
after all--the problem with rewriting that as
0 $x and $x 10
is that it should only work as long as the two values of $x remain
entangled so that the always refer to the same abstract value.
That's certainly true. But I think the real
Jonathan Scott Duff wrote:
none($a, $a) == undef
True.
Isn't this one false in the case when $a is undef?
Yes. Apologies for not being more precise.
Damian
Patrick R. Michaud wrote:
none(none($a,$b),none($c,$d)) == none($a,$b,$c,$d)
True.
H...
- none(none($a,$b) == none($a,$b,$c,$d),
none($c,$d) == none($a,$b,$c,$d))
RHS distributes first. So the expansion is this instead...
- none(none(none($a,$b),none($c,$d)) == $a,
Patrick R. Michaud wrote:
RHS distributes first. So the expansion is this instead...
Ummm, okay, but that's not what I interpreted from S09, where
it says that the left-most conjunction or injunction is
autothreaded first. In this I've also assumed that
$a == $b
is equivalent to
Jonathan Lang wrote:
Maybe set should be an operator akin to any, all, one, and none,
at least in terms of and |. That is, if junctions are special cases
of sets, why not allow for the creation of generic sets in much the same
way? Then you could have:
# $A and $B are sets,
union($A, $B)
Jonathan Scott Duff wrote:
Perhaps. I'm not so sure it's the rare case that programmers aren't
prepared to deal with implicit parallelization. :-)
Of course. But I'm saying it's a rare case where they've have to. Or, at
least, where it will bite them if they don't.
use warnings
Rod Adams wrote:
However, what if what you're calling a non-Perl Parrot based function?
Do we disable junctions from playing with non-PurePerl functions? Or do
we autothread over them? How do we tell if a non-Perl function outputs
to determine if we should be able to autothread into them or
Timothy S. Nelson wrote:
Sorry, I've just worked out that, while I'm not sure I understand your
comments on RFC 051 in A2, it looks like there'll be a function where I pass
it a filename and it returns the contents, and that's what I want; I presume
this closes it after.
Yes. The function is
David Storrs OOC'd:
OOC, will there be a way to control where Cpick gets its randomness
from? (e.g. perl's builtin PRNG, /dev/random, egd, etc)
Sure:
# Use RBR (Really Bad Randomness) algorithm...
temp *rand (Num ?$max = 1) {
return $max/2;
}
my $guess = @data.pick;
Damian
Rod Adams wrote:
I also find the following incredibly disturbing:
perl6 -e $x = 'cat'|'dog'; say $x;
dog
cat
That would be disturbing if that's what happened.
Csay @what is just a shorthand for Cprint @what, \n.
So saying a junction is the same as printing it, which is a run-time error.
Can a
Autrijus wrote:
FWIW, I also find it incredibly disturbing. Although I don't have
to deal with it yet in the side-effect-free FP6, I think one way
to solve this is for the say to return a junction of IO actions.
No. It just throws an exception:
Can't output a raw junction
(did you
Jonathan Scott Duff wrote:
Let's set aside for the moment the fact that slurpy arrays/hashes
aren't autothreaded and talk about a user-defined routine:
sub foo ($alpha) { ... }
It doesn't take much imagination to come up with a mechanism for Perl6
programmers to stop the autothreading:
Autrijus wrote:
Is there other built-in methods not found in perl5 that you are
aware of?
Yes.
I'd like to work out declarations and implementations
of them in one sweep, if possible. :-)
Hah! Dream on! I don't think we have a canonical list anywhere (except in
Larry's head). Some non-Perl-5
Patrick Michaud wrote:
On Thu, Feb 10, 2005 at 10:42:34AM +, Thomas Yandell wrote:
Is the following comment correct?
my $x = any(2,3,4,5) and any(4,5,6,7); # $x now contains any(4,5)
Short answer: I don't think so.
Long answer:
decloak
Patrick is right on the money here...as usual. (Don't
Rod Adams wrote:
The overall impression I'm getting here is that we need some syntax for
saying:
$x = any(1..1000) such_that is_prime($x);
In standard Perl 6 that'd be:
$x = any(grep {is_prime $^x} 1..1000);
or, if you prefer your constraints postfixed:
$x = any( (1..1000).grep({is_prime
Abhijit Mahabal wrote:
I am a little confused if the following is valid perl6:
our xsub = { $x };
No. Illegal attempt to assign to a reference. You want aliasing/binding
instead:
our xsub := { $x };
(I like to think of := as assignment to symbol table entry.)
If you wanted to get a function
Adam Kennedy wrote:
Frankly, as the only person who has managed to get together a guessing
lexer that is sufficiently accurate to be something other than useless,
Hm. I must confess that I don't consider Text::Balanced's
Cextract_codeblock subroutine to be entirely useless. And presumably
Adam Kennedy wrote:
What I'm after are 3 critical features.
1. You always get back out what you put in.
$source eq serialize(parse($source)).
As Larry pointed out, this will depend on how much metadata your parser
augments your parse-tree with. I think it will be doable (probably by
subclassing
Luke has answered this better than I would have. In particular, he wrote:
Perl's contextual sensitivity is part of the language. So the best you
can do is to track everything like you mentioned. It's going to be
impossible to parse Perl without having perl around to do it for you.
That first
John Siracusa wrote:
I don't see how we could prevent someone from clobbering the global
definitions of PRE and POST to be no-ops if they wanted to. Seems to
me that the whole point of putting the program in charge of its own
compilation is to let it be in charge of its own compilation, n'est pa?
Larry wrote:
You can also create your own anonymous class at run time that incorporates
both roles simultaneously and disambiguates them.
Or, presumably, you could use an anonymous role directly:
$driver does role {
does SanitationEngineer;
does RaceCarDriver;
method
Larry wrote:
Actually, I've been rethinking this whole mess since last week, and
am seriously considering cranking up the Ruby-o-meter here just a tad.
At the moment I'm inclined to say that the *only* interpolators in
double quotes are:
\n, \t etc.
$foo
@foo[$i]
%foo{$k}
Scott wrote:
I'm just waiting for Damian to speak up :-)
I'm not at all comfortable with the notion of junctions as lvalues.
I've *always* considered a junction to be a special kind of constant, just as
a number or a string or a reference is.
I have trouble with junctive lvalues because I think
Austin Hastings wrote:
Hmm. For junctions I was thinking:
++ all([EMAIL PROTECTED]);
Which is almost readable.
But unfortunately not correct. Junctions are value, not lvalues.
This situation is exactly what hyperoperators are for:
++ [EMAIL PROTECTED];
Damian
Luke asked:
Er, did the hyper operator's direction flip? I thought it was:
++ [EMAIL PROTECTED];
My bad. 'Tis indeed.
Damian
Austin Hastings asked:
Junctions are value, not lvalues.
Why not bundle lvalues together?
Because, although this would mean what it says:
all($x, $y, $z)++;
None of these would:
any($x, $y, $z)++;
one($x, $y, $z)++;
none($x, $y, $z)++;
We're trying to avoid
Aaron Sherman wrote:
At the end of A12, Exportation covered the idea that you will now say:
sub foo() is export {...}
Rather than the P5:
@EXPORT=qw(foo);
sub foo;
Which is fine, except that in P5 we could say:
use Foo qw(foo);
@EXPORT=qw(foo);
Now, I know
201 - 300 of 1091 matches
Mail list logo
