rator:
./unary public-method-call-on-invocant
.:unary private-method-call-on-invocant
So the rule is:
One-character operator --> call on $_
Two-character operator --> call on $?SELF"
Damian
a special case, and it's easy to explain that the magic of
the C is being applied before the magic of junctions.
Damian
s every time someone
who's defining an operator is too lazy to think about precedence or to type
two dozen extra characters.
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
example, we'd also need to decide what these evaluate to:
3 =:= 3.0 #
3 =:= '3' #
They're surely not identical, but you'd probably want C to think so.
Or maybe you just have to SWYM and write:
@uniq_nums = uniq [EMAIL PROTECTED];
or:
@uniq_strs = uniq [EMAIL PROTECTED];
if you have heterogeneous data.
Damian
)
No, the second is an error.
But these two are _not_:
foo($a : $b : $c)
foo($a : $b : $c : )
Well, they're both errors, so whether they're identical becomes a
philosophical problem. ;-)
Damian
n the call
syntax (apart from single-dispatch indirect object syntax, of course).
Damian
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
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
what the indefinite article means in English.
So presumably, one could also envisage:
$anon_scalar_ref = a Scalar;
Damian
method is called, regardless
of which 'new' method is called, correct?
Yes. It's invoked by bless().
Damian
macro time_to_ground ($height, $accel) {
...acceleration math...
}
my $time = time_to_ground( 500, $gravity );
Damian
ed, postpend them as a default:
$sum = ([+] @values err 0);
$prod = ([*] @values err 1);
$prob = ([*] @probs err 0);
Damian
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": w
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
tever () returns: an empty list in list context, undef in scalar
context.
I'd have assumed that "empty list in list context, undef in scalar
context" *is* what C returns when C isn't in effect.
Damian
7;c'
would equal '~a~b~c' instead of 'a~b~c'
Good point. Thanks. Make that:
sub join (Str $sep, [EMAIL PROTECTED]) {
reduce { $^a ~ $sep ~ $^b } @list || ""
}
Presuming (of course) that my earlier plea that || should preserve context
across both operands is granted. ;-)
Damian
$factorial = ([*] 1..$n err 1);
So what you want is not an identity value as default (which isn't even
possible for many operators, as Luke pointed out), but a predictable failure
value as default, so you can intercept that failure and choose your own
outcome in the edge case.
Damian
the same name.
... which seems to contradict.
Apologies. I hadn't noticed that you were intending to call it with a
positional argument. In which case, yes, you would indeed require the separate
constructor definition.
Damian
submethod.
Is that really off the wall?
Not at all. It's entirely reasonable. As I mentioned in my previous message, I
simply missed your original intent.
Damian
g it "initvalue", since people are apt to confuse it
with real initialization. I'd be inclined to call it "identityval" and simply
say that an undefined variable that is op-assigned defaults to the identity
value of the operator (if any).
Damian
signment operator depends on the return value of the operator and
the type of which the lhs is undef.
The MMD mechanism sorts out which op is required, either by looking at the
static type of the lhs variable, or by treating the undef as a coercion
(Manhattan distance = 1)
Damian
e the
predictability and maintainability of programs written in those languages,
neither of which is renowned for its accessibility to ordinary programmers. ;-)
Damian
pplied to any other iterator object, in which case it
calls that object's C<.next> method.
Damian
that subs and methods *should* complain about all unused
non-optional parameters *except* invocants.
Damian
someone provide a patch, if not, can someone confirm that the design
documents are correct? (I just happened to be looking at class methods
this past week, which is why I was a little surprised by Luke and
Damian's answers... :-)
Both documents are correct, but S12 is correcter (as you would expect).
Damian
etter to allow people to explicitly say what they
mean:
sub factorial (Int $n is topic) {
return 1 when 0;
return $n * factorial $n;
}
Damian
urrent topic.
Unary ./ calls a specified method on the current invocant.
The point being that methods no longer topicalize their invocant. So you need
to use ./ instead of . to call methods on an implicit invocant.
Damian
t invocant. I'm arguing that that one umambiguous way should be the
*only* way. Having an unambiguous way *and* an ambiguous way seems like poor
design.
Damian
e an old fuddy duddy... :)
That's fine, Gramps! ;-)
(also, at least it's not "/." ;)
Damian
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
name) if necessary...
&function := sub { try_some_stuff || old_behaviour([EMAIL PROTECTED]) };
No infinite loop involved.
Perl 6 even has specific syntactic sugar for this kind of thing:
&function.wrap( { try_some_stuff || call([EMAIL PROTECTED]) } );
See: http://dev.perl.org/perl6/doc/design/syn/S06.html#Wrapping
Damian
ules that create as many synonyms as you feel are
needed/necessary/required/essential/requisite/demanded/called for.
Indeed even in Perl 5 it would not be hard to write a module that let you:
use Keyword::Synonym 'are' => 'is', 'mv' => 'rename', 'become' => '=';
H. ;-)
Damian
set) property on the node reference would have returned C which
would undergo the usual boolean conversion in the C, and the usual
promotion to zero in the numerical context of the increment.
Anyway, a patch is winging it's way to Simon even as I type.
Thanks for pointing out the snafu, John.
Damian
n conversion in the
C, and the usual promotion to zero in the numerical context
of the increment.
The point is that (as in Perl 5) neither of these two cases of undef
promotion trigger a warning, so there was nothing to alert me to the
fact that the initialization of the value was redundant!
;-)
Damian
And if all of the above is true, what does this do to the size of
> the internal representation of a scalar?
In the worst case, it adds a single pointer to it. But it's entirely
possible that properties would be stored centrally, in which case
there's no impact at all.
Damian
I thought the "truth" property was attached to the value, not to the
> variable. So if you assign a new value to that variable, the truth
> property is overwritten, too.
Yep.
Damian
quot;;
>
> you get nada, right?
Right.
> So... why the *$#$ is it getting into the loop?
>
> There has to be a method to print out the *contents* of $fh, not
> just the values.
print $fh.true; # Just the truth
print %{(+$fh).prop}; # All the value's properties
Damian
false value to it, then yes, that does count as action-at-a-distance
> and is probably a Bad Thing.
Yes. perhaps even a Very Bad Thing. ;-)
> However, if assigning to $Foo clears the eariler assertion of truth,
> then there's no problem.
Yep.
Damian
<http://www.yetanother.org/damian/diary_latest.html> explains why.
Please accept my apologies.
As my final word on the subject (for the present at least ;-), and in the
interest of trying to resolve some of the issues raised, let me once
more attempt to clearly summarize the intent and usage of
not, as it's quite possible that the property hash will
only be built on-demand.
Damian
Can 'undef' valued thingys have functions?
That's why I said "no" to the second.
If the second question was actually:
Can functions have properties?
Then the answer is, of course, "yes".
Damian
ty.
Er...yes...that's rather the point of the exercise: to be able to
polymorphically override the behaviour of properties by defining
methods.
Should we deprecate inheritance because the functionality of a working
program can be completely changed/broken by defining a derived method
that conflicts with an inherited method?
Damian
6 made that possible.
>
I guess that would be:
$ref = sub{my%k;%k{+pop}=\(@_);splice@_,$_,!%k{$_}for @_..0:-1;@_}.(@A,\@I);
>
> Maybe it already does and I haven't grokked that from the exegeses yet.
>
I'm pretty sure Exegesis II doesn't mention *that* particular technique ;-)
Damian
ference to a slice in perl 5 yields the list of the references
> to the slice members. Is that the way it's going to be in perl 6?
I would suspect so, since a slice is a list, not an array.
But, of course, that wouldn't preclude a different syntax for generating
a cross-sectional view of an array.
Damian
p://search.cpan.org/doc/MARCEL/Attribute-TieClasses-0.01/TieClasses.pm
for even more ideas.
Damian
ip'.
Except that it would be the object reference in $spot that had the run-time
property.
> MVA$spot.bark (+$spot).bark
> 000Error Error
> 001yip yip
> 010arf Error
> 011arf yip
> 100woofwoof
> 101woofwoof
> 110woofwoof
> 111woofwoof
>
> yes?
Yes.
Damian
s wait and see what he makes of that proposal.
> (note that this does away with
> the (+spot).bark syntax that some people feel is ugly):
That's been addressed in my latest proposal too.
Damian
Scott wrote:
> Would you also advocate separate declarative syntax for variable
> properties and value properties? That's where I think much confusion
> will be.
That's covered in my new proposal too.
Damian
actually want the possibility of that kind of namespace collision:
for polymorphism.
Damian
) {
...
}
else {
die $res.Reason;
}
Should, of course be:
die $res.Because
Damian
of:
1 until defined(getvalue()); return it;
You can already write:
1 until defined($_=getvalue()); return $_;
which doesn't seem a huge extra burden.
Or, if you worry about $_ pollution, use this:
{return $_ for grep{defined or redo} getval()}
Damian
oClass $self) {
return $self{const} || $self.prop{const}
}
Damian
ecause it only has the property at run-time.
Damian
statically
analyzable in general. Though static determinacy is obviously a
desirable thing, there are plenty of other B&D languages that offer it
in abundance. And the dynamic power that Perl would have to lose would not
compensate for the static benefits gained.
Damian
PS: Of course, as always, Larry's MMV on that ;-)
subscript is optional,
There is no arrow. Only dot.
And yes, it's optional anywhere the dot acts like a /\b/ boundary:
$ref.[1]can be $ref[1]
$ref.{a} can be $ref{a}
$ref.(@args)can be $ref(@args)
$ref.meth() CAN'T be$refmeth()
Disclaimer: Rules #1 and #2 apply to all of the above.
Damian
^^
Sorry, in my haste I missed that twist. You are, of course, correct.
> >> Oh, hrm. Shouldn't it be $a{test2}?
> > Yes. Or $a.{test}
>
> So "." isn't necessarily the "property" operator, then? OK.
> Time to spend more quality time with YACC. :(
Now there's an oxymoron, if ever I heard one. ;-)
Damian
; Hm, I thought Larry said you would need to use $() to interpolate
> a method call. So this would be
>
> $bar =~ /$($foo.colour)/;
That was not my understanding. At least not for (pseudo-)method calls.
But many things are still in flux and I may well have missed a meeting. ;-)
Damian
ot;$file.ext" is
> going to be common. But I do think the $() approach is clean and
> unambiguous
I agree wholeheartedly.
But it's not as *convenient* as "unadorned" interpolation.
Expecially if we expect method calls to be frequently interpolated.
Damian
the $() is easier than the current perl5 way to do it.
There we definitely do agree :-)
Damian
f the object referred to by $ref.
Damian
) {...
but as special case syntactic sugar for the expANDed version:
if ($x < $y && $y < $z && $z < $foo) {...
Oh, and with only single evaluation of each operand.
Damian
Simon asked:
> Are properties subscriptable? (Can the value of a property be a
> reference that can be dereferenced?)
Property values can be any scalar value, including array, hash, and code refs.
> Can properties have properties?
No, but their scalar values can.
Damian
elf->{a} }
>
> (Did I get that syntax right ? probably not :)
Try this:
sub a(Foo $self) is rw { $self{a} } # or $self.{a}
Damian
Dave Whipp asks:
> Does it do short-circuit evaluation, too?
I would certainly expect it to, yes.
Damian
believe it's vitally important not to mix everything together syntactically
(or semantically!)
Damian
t;.interestearned += $interestrate * .balance
>
>}
Larry doesn't favour using C thus, beause it introduces a sly
list context. That argument convinced me.
But there might well be another keyword for the same idea and that might tie
into switch statements too.
Damian
> Sounds sensible, and worth sending past Damian.
It's certainly not unreasonable, though it doesn't mesh perfectly with
Perl's OO model. The easy solution (available in Perl 5 too) is to
autogenerate the interim MI-ing classes as needed:
my $next = "a";
> > The downside is of course that I need to make a small stub for every
> > single function I want to delegate.
>
> Well, that's relatively simple to automate...
>
> Wasn't Damian working on something like this? I looked at his
> deleg
ote aspect.)
No. There will, I hope, be a mechanism for pre- and postfixing
subroutines, but not properties I think.
> So, to recap:
>
> $foo : bar;
>
> means bar is posted to $foo. $foo's value may change
> or stay the same. The return value may be $foo's, either
> before or after posting, or some other value. $foo's value
> may now have an attached bar postit.
You lost me here. Your ideas for properties are different from mine
(which may well, in turn, be different from Larry's).
Damian
> > Me:
> [$foo is bar] can change the value of $foo.
>
> > Damian:
> Yes. For example:
> my $foo is persistent;
>
> Could you explain this further please?
The programmer has specified a property named 'per
e HASH reference as ARRAY!
> Quandary #3: Should / will perl6 support polymorphic typing?
Probably. But that may require a more sophisticated type system than
most people would like to see (or implement!) in Perl.
Damian
his I'm not totaly sure, but it comes to my mind many modules
> uses notation like this to pass params i.e.
>
> someFunc ( -param1 => 'blah', param2 => 'xxx' .)
>
> Why not have %_ in our case we have the following elements :
http://dev.perl.org/rfc/128.html#Named_arguments
Damian
onsider (variable versus
> value, and hash versus array versus scalar versus filehandle), are
> properties that are meaningless for some section usable by the user?
I would expect so, but Larry's MMV.
Damian
> Damian,
> You mentioned in E2 that the chomped property relies on the insep
> property of the filehandle (formerly $/). Can I extrapolate that
>$.
>$,
>$\
>$|
> will also be properties on filehandles? (How about
>
within expression n - the equivalent to 'default:'?
> given ( a() ) {
>print $^_; # No when clause? See #1
> }
$^_ isn't an alias for the C's expression.
It's a higher-order function placeholder
(see: http://www.yetanother.org/damian/Perl5+i/higheror
Larry, but I will now reproduce it here to
show my current thinking on the subject.
Damian
---cut---cut---cut---cut---cut--
It seems that my property concept is becoming a little chunky.
So let me try again...
Suppose variables and subroutines had
stant Counter" if $self.constant;
}
> # However, if I do
> #
> # %foo is constant = (a=>1, b=>$foo);
> #
> # are only the keys contant; or both the keys and values.
>
> Keys and values, I imagine.
Probably.
Damian
uot;Ungoverned 'when' statement (where's the 'given'???)"
I think C and C are no more synonymous than C and C
and I doubt people will have much difficulty keeping them straight.
Damian
imagine the same types of warnings on all-lowercase traits/properties
as on lowercase barewords. That is: let them be, by convention, reserved for
(future) built-ins.
> PS - I *really* like the traits proposal.
Me too :-)
Damian
reday scheduled for termination.
In Perl 6, the expression C<&foo> returns a reference to the C subroutine.
Damian
ver.bark_at($felix); # method sig checked at run-time
# (type of both not known till then)
One might also envisage a C pragma to require that
all lexicals be typed.
Damian
, item3, ..."
> }
I would expect so, though I'm not sure that would be the syntax.
> If it's not possible, I think it should be :)
I agree.
Damian
ariable used as a subroutine/method argument,
but it's a good idea.
Damian
> > I sure miss multi-dispatch.
http://dev.perl.org/rfc/256.html
Damian
er for each combination. For example, a MoveEvent sent to
a FixedWindow causes a beep, but a MoveEvent sent to any other type of
window is dispatched to the more-generic handle(Window $w, MoveEvent $e)
subroutine, which causes it to move.
Damian
> Even if the dispatcher is the heart of multimethods, perhaps it
> would be nice if it were convenient to replace the dispatcher
> in whole or part.
I'm sure if we asked Dan nicely, he'd consider hanging the dispatcher on
a lexically-scoped hook to make that possible ;-)
Damian
o proposing that the *default* dispatch mechanism be
user-selectable. Hence a global hook.
Damian
error-prone. :-(
Multimethods elegantly solve a very hard problem in OO design: controlling
the interactions of multiple objects from multiple class hierarchies.
They are not required often, but when they are needed (e.g. in the
Quantum::Superpositions module), they are a *vastly* superior solution.
Damian
e.
> We can not put every superior solution into one language.
But we *can* put multiple dispatch in, since it greatly extends an existing
superior solution (single dispatch).
Damian
side-effect of multiple dispatch
in dynamic languages.
For example, see:
http://dev.perl.org/rfc/256.html#Handling_built_in_types
But note that the *run-time* dispatch of these overloaded subroutines
is still critically important because of Perl's dynamic typing of values
within container data structures.
Damian
clared a multimethod in
the current scope (the first version doesn't).
Damian
file boundaries. Semantically, I
> will define a block only in terms of its affect on scoping.
"its effect on scoping"
(we probably don't care about its pyschological demeanor ;-)
Damian
iVAN wrote:
> As we read in Damian Conway- Perl6-notes, there will be
"...may be..."
(Remember, I'm only the shambling henchman ;-)
> a var-iterator that can be used to see how many times the cycle has
> been "traversed" i.e.
>
&g
e parameter type specifiers,
when they're actually argument context specifiers.
> hopefully we won't be saddled with it in Perl 6
Here. Here. I'm sure for Perl 6 we can do much worse^H^H^H^H^Hbetter.
;-)
Damian
st have
> their prototypes known before the BEGIN phase is done"... :)
Yeah. Right. That's gonna happen.
;-)
Damian
PS: can we please *not* refer to the Perl 6 parameter lists as "prototypes".
The use of that term causes enough problems in Perl 5.
See: http://dev.perl.org/rfc/128.html#Banishment_of_the_term_prototyp
> I haven't seen details in an Apocalypse, but Damian's
> Perl 6 overview has a bit about it. The Apocalypse
> specifically mentions *compile-time* scope management,
> but Damian is, uh, Damian. (DWIMery obviously. ;)
Hmm.
It would seem *very* odd to al
how do you think I got five of my modules into the 5.8 core???
;-)
Damian
Ken wrote:
> Damian Conway wrote:
> > It would seem *very* odd to allow every symbol table *except*
> > %MY:: to be accessed at run-time.
>
> Well, yeah, that's true. How about we make it really
> simple and don't allow any modifications at
601 - 700 of 1296 matches
Mail list logo
