> Please tell me there will be a way to work out if you're called as a
> subroutine or as a method.
Yes. Subroutines and methods will inhabit different namespaces
(modules and classes respectively):
module X;
sub s { print "I am the very model of a modern Perl 6 subroutine
> So a class method and a plain function call are still not the same
> thing?
Correct.
Damian
> Well, sure, but that's precisely what the C operator was intended
> to do in the first place. I don't know why Damian used a dot there.
> I'd also expect that construct to return the old value of irs. The
> dot snuck into the last draft of E3 and I didn't read it with enough of
John confessed:
> I unconsciously typed *both* //= and $( ... ) today :P ;)
We are Perl6. Resistance is futile. You *will* be assimilated.
;-)
Damian
PS: If you're keen on $(...) and @(...), grab the wonderful
Perl6::Interpolators module from the CPAN.
> But I assume that == means numerically equal (and here I could be
> wrong). If what I assume is true however, then anything which doesn't
> have any numerical meaning, numerically compared to anything (even to
> itself) should not return the misleading result that the two compared
> : @costs = (sort { $a.key <=> $b.key }
> : { amortize($^_) => $^_ }^.(@cost ^* $inflation)
> :)^.value;
>
> I wonder how the parser is going to tell that the start of the second
> line is supposed to be an anon sub, rather than an anon hash. It
> > Let me make it clear: AFAIK Perl NaN's will not be IEEE 754
> > compliant. That was certainly my intention in suggesting them to
> > Larry. I share the view of a number of other language designers that
> > the non-self-identity of IEEE NaN is (to slightly misquote Tim)
> > "ug
RaFaL asked:
> So OK, tell me if I get it right, and how (and why) it will look in Perl
> 6. From Exegesis I see that NaN==NaN, but that's not stated in
> Apocalypse (or I just missed it).
No, it's not stated there. But I hope that Perl 6 will follow the lead of
other high level langu
Tim wrote:
> > Err. Are you *sure*? That's an C, not a C, you realize?
>
> Yes. I had to use all my fingers and toes to keep everything straight,
> but I think I did. :-) In the semantics you show (different from IEEE
> semantics) "NaN==NaN" is true, so "NaN!=NaN" is false, whic
> His point was that the NaN IEEE came up with is defined to have NaN !=
> NaN, and that it might be confusing if Perl's behavior wasn't consistent
> with that. Not that I think NaN != NaN is a particularly good idea, but
> consistency with other languages may be. If NaN != NaN, th
> So, does that mean that, to keep C and
> Cnew($baz, $frob)> doing the same thing, the object will always
> come in before the colon?
Yes.
> Is unary . gonna refer to the "one and only"
> argument before the colon?
Yes.
> Cool.
Yes.
;-)
Damian
> Semantic confusion alert!
Aroogha! Aroogha! All crew to clarification stations!
> EX3 (great document!)
Thank-you.
> sez:
>
> > print "Inflation rate: " and $inflation = +<>
> > until $inflation != NaN;
>
> This requires that
> Are these the same thing?
>
> print _@{$data.{costs}};
> print _ $data{costs};
Larry has indicated that they almost certainly will be.
Arrays and array refs will be interchangeable in a scalar context
(such as the unary _ applies to its argument).
In fact, in Perl 6 you
> Well, it's pretty handy to be able to generalise what join() does
> for concat to any abitrary function. It's covered by:
> http://dev.perl.org/rfc/76.html which proposes a new reduce()
> builtin.
C is almost definitely in (in some form). That's why I used it
in E3.
> Edwin's
> Actually... Damian, does this, along with the new reference/context
> stuff, mean that HOFs could also have hash and array parameters? I
> guess there's no reason why not...
None at all. Though I haven't specifically discussed that with Larry,
I think it's very likely.
Damian
> $a == $b != NaN
>
> really means this:
>
> $a == $b && $b != NaN
>
> But "$a == $b != NaN" is supposed to "[solve] the problem of numerical
> comparisons between non-numeric strings." Well, what if:
>
> $a = 'hello';
> $b = 0;
>
> Do
Very nice. And yes, too many brackets of various kinds.
Also $this doesn't really describe what it stores.
Maybe $first would be better?
And we can also optimize the performance by making the lexicals
constant (so the optimizer can hard-wire the method names into the
closure). That gives us:
> Can I get a .car and a .cdr please? In my limited mind "key" and "value"
> are specific to hashes and their wimpy brother associative lists.
Sure. Roll-you-own with:
module PAIR;
method car { return .key }
method cdr { return .value }
or, if you're really
> Well, my head is definitely spinning. :) Thanks, Damian.
Just doing my job, Citizen.
;-)
> One oversight (on one of our parts - you either didn't put it in or I
> didn't see it. :)): it looks like the example uses the new ";" operator
> (between the mandatory and option argum
> When you say Unary here:
>
> Binary (low) | Binary (high) |Unary
>
> Don't you mean "bitwise"? If not then I'm confused :-)
Looks like *I'm* the one who was confused! ;-)
Yes, indeed, they should be:
s/Binary/Boolean/g
s/Unary/
> OK, I have a question.
>
> On page 3 you say:
>
> > Because the Perl 6 "diamond" operator can take an arbitrary expression
> > as its argument, it's possible to set a filehandle to read an entire
> > file and do the actual reading, all in a single statement:
> >
> >
> > my @images = qw( pic1 pic2 pic3) ^_ ('.jpg');
>
> Doesn't that clash with the default currying argument?
No. The DCA is: $^_
Damian
> Is the following correct for := :
>
> left side is like function in the respect that the right side is treated
> differently depending on the left-side-types i.e. left side is like
> prototype!! for the right side.
Yep.
> (@a ,@b) := (@b,@a)
> is the same as :
> (\
> Will Hyper operators work on strings as well ?
Yes. You can "hype" *any* operator (except ^)
Damian
Stéphane writes:
> Hyper operators with operands of different size are partly covered
> in A3:
>
> Hyper operators will also intuit where a dimension is missing from one
> of its arguments, and replicate a scalar value to a list value in that
> dimension. That means yo
> Or even
>
> for my $x (1..98) {
> for my $y (1..(99-$x)) {
> for my $z (1..(100-$x-$y)) {
> print "$x, $y, $z\n" if $x ** 2 = $y ** 2 + $z ** 2;
> }
> }
> }
Sure. Depending on whether you want combinations or permutations.
Damian
> >> Backtracking:
> >>
> >> Ok, I don't get it at all. Damian, clarification?
> >
> > Nothing to clarify. Larry punted (to a later Apocalypse).
> >
> > Okay. That's a cop-out. He's basically saying that you can write
> > C and C yourself as:
>
>
> At 02:18 PM 10/4/2001 +1000, Damian Conway wrote:
> >> ** Miscellaneous
> >>
> >> Why 'operator:+' instead of 'operator::+'? (Other than the
> >> potential verbosity required to declare operators with
> Hyperoperators:
>
> I sort of understand it, but don't really grok it. I can sort of
> thing of ways it might eliminate the need for a few maps and
> foreaches. Damian, might I request some clarification in Exogenesis?
Well, I'll probably clarify them in Exegesis instead.
"E
> Part of quitting smoking is that my hubris has gone back up.
> Here are critical first-impression notes on Apo3. Praise has
> been eliminated to save space.
A false economy. We should encourage Larry as often as we can.
After all, is it any wonder that it's so long between Apocalypse
> And package::subroutine should go the way of package`subroutine as
> package.subroutine will work and become the preferred method :), no?
Err...no. They're still not the same thing in Perl 6:
package::subroutine(@args) --> package::subroutine(@args)
package.subroutine
> So does that mean that the Perl5 meaning of
>
>@refs = \($a, $b, $c);
>
> will go away?
I doubt it.
> It seems like it should as it's a caretless hyper.
Not really. Or, at least, no more so than C or C or C is.
Hyperoperators apply to *arrays* not lists.
What w
Bryan asked:
> What about filetests that already return something meaningful? I'll
> assume that they still behave the same. (And thus, shouldn't be
> chained. Unless you're doing something weird.)
Yep.
> It's also mentioned that they don't short-circuit, so what do
> post-failu
> > And I didn't see anything about you being able to hyper =,
> > so ^= ought to be alright too.
>
> I would expect
>
>@a ^= 1; # sets default value for (all elems of) @a
>@a ^+= 1; # increments each element of @a
>
> etc.
Yep. AFAIK *every* operator (exce
> Set in stone, huh? Hmm. It may affect the parsing, but I'm not sure.
> Perhaps we can Arbitrarily Declare that an underscore isn't allowed as
> the last character of a symbol. That way, you can still do $foo_$bar
> without worrying about whitespace.
I doubt it. From E3:
> PS: I'm getting excited about the announcement of _sample_ code for a
> language _design_... That's kinda 'meta-vaporware' isn't it? Where did
> things go so wrong... ;-)
I've found it a real challenge to write that sort of code. It's an
constantly (and unsteadily) moving target, I
> # solitary underscore for that. So, instead of:
> # $a . $b . $c you'll say:
> # $a _ $b _ $c The only downside to that is the space between a
> # variable name and the
> # operator is required. This is to be construed as a feature.
>
> Ouch. Although I don't wish
> I haven't seen it mentioned here yet, so for those who haven't
> noticed A3 is now out:
> http://www.perl.com/pub/a/2001/10/02/apocalypse3.html
And Exegesis 3 will follow within 24 hours.
> But... earlier messages from
> Larry suggested that the hyper-operator symbol would actu
Bryan thought:
> > my $x = 1;
> > my $y = \$x;
> > my $z = 2;
> > %MY::{'$x'} = \$z;
> > $z = 3;
> > print "$x, $$y, $z\n"
>
> My $x container contains 1. ($x = 1)
> My $y container contains a ref to the $x container. ($x = 1, $y = \$x)
> My $z contai
Bryan asked:
> > That would be:
> >
> > given ( $a ) {
> > when /a/ : { foo($a); goto BAR }
> > when /b/ : { ... }
> > BAR: when /c/ : { ... }
> > ...
> > }
>
> If they were statements, wouldn't that be:
>
Dan concluded:
> Certainly doable. Just potentially slow, which is what I'm worried
> about. Making it not slow has both potential significant complexity
> and memory usage. If we have to, that's fine. Just want to make
> sure the cost is known before the decision's made. :)
I rather
Dan wept:
> I knew there was something bugging me about this.
>
> Allowing lexically scoped subs to spring into existence (and
> variables, for that matter) will probably slow down sub and
> variable access, since we can't safely resolve at compile time what
> variable or sub
Dan sighed:
> >I don't understand why you think that's particularly wormy?
>
> Ah, but what people will want is:
>
>my $x = "foo\n";
>{
> my $x = "bar\n";
> delete $MY::{'$x'};
> print $x;
>}
>
> to print foo. That's where things g
Bryan wrote:
> > > Er, scratch this. Blows up if the sub isn't prototyped. A much
> > > *better* way is to make the prototype of any sub a property
> > > (trait) of that sub. We can always query for a property.
> >
> > This is possible now:
> > $foo = sub ($) { print "hello wor
Dan wrote:
> At 12:50 PM 9/4/2001 -0500, Garrett Goebel wrote:
> >
> >So deleting it
> >would remove it from the scratchpad of &incr. But I would guess that
> >future calls to &incr would have to autovify $x in the scratchpad and
> >start incrementing it from 0. I.e., ignorin
Dave Mitchell asked:
> If there is to be a %MY, how does its semantics pan out?
That's %MY::. The colons are part of the name.
> for example, what (if anything) do the following do:
>
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
Bryan wrote:
> > C and C
>
> [ LABEL: ]
> try { block }
> [ [ catch [ ( expr ) ] { block } ] ... ]
the "expr" is more likely to be a "parameter_specification".
> >> Conditional Statement Modifiers
> >>
> >> 6. [ LABEL: ] expr if expr;
> >>
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
Dan revealed:
> > How am I expected to produce fresh wonders if you won't let me
> > warp the (new) laws of the Perl universe to my needs?
> That's easy--you slip the pumpking or internals designer a 10-spot.
> Amazing what it'll do... :)
And how do you think I got five of my module
> 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 allow every symbol table *ex
> > Are prototypes going to be checked at runtime now?
>
> For methods, at least. Dunno about subs, that's Larry's call. I
> could make a good language case for and against it. It adds
> overhead on sub calls, which is a bad thing generally.
I would strongly like to see a guarante
> But since the current prototyping system... has a highly positive
> pressure gradient compared to the surrounding air,
Well...I think it's more a problem of "I do no' thin' dat word means
wha' you thin' it means".
People want prototypes to be parameter type specifiers,
when they're actua
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
Some feedback.
> Syntax Overview
>
> Keywords
> continue, do, else, elsif, for, foreach, given, goto, grep, if, last,
> map, next, redo, sort, sub, unless, until, when, while
C and C
(C is not nearly so certain.)
> Conditional Statement Modifiers
>
> 6. [ L
Ken wrote:
> The way to approach this problem is to profile
> Class::MultiMethods and figure out (a) where the hot spots
> are and (b) what core support would help eliminate those
> hot spots.
But please don't do that until I release the next update of C::MM,
which will use a new dis
> Thinking about what Zhang was saying about multiple-dispatch not being
> inherently OO. I think he's sort of right. Multiple-dispatch need
> not be confined to method lookups.
True, but that doesn't make it non-OO ;-)
> foo();
> foo($bar);
> foo($baz);
>
> > It doesn't. The multimethod consists of those variants that are currently
> > loaded.
> >
> How do you define the currently loaded?
Accessible in the program's symbol table and registered with the multimethod
dispatcher.
> >> 2) If there is mismatch on more than one
Hong wrote:
> > Note that the handler that is selected depends on the *combination* of
> > the types of the two arguments. And that the dispatcher understands
> > the argument/parameter inheritance relationships and selects the most
> > specific handler for each combination. For examp
Dan observed:
> I hadn't considered having it as a global thing, just because I can see
> class Foo wanting multimethods, and class Bar being fine with 'normal'
> class hierarchy walking, and class Baz deciding it wants the automatic
> redispatch form of method calling.
>
> We
> 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
Schwern explained:
> # Following RFC 256
> sub name (Foo $self) : multi {
> return $self->{name};
> }
>
> sub name (Foo $self, STRING $name) : multi {
> $self->{name} = $name;
> return $self->{name};
> }
>
> which is q
> > I sure miss multi-dispatch.
http://dev.perl.org/rfc/256.html
Damian
Uri writes:
> DC> One might also envisage a C pragma to require
> DC> that all lexicals be typed.
>
> do you mean lexical params in a sub signature? or all lexicals in the
> current scope which contains the pragma?
any(@above).
Some people will want one; some, the other. We
John asked:
> Can properties be temp()orarily masked? For example:
>
> foreach my $array (@arrays)
> {
> temp $array.sep = ', '; # assuming this is a real property
> print "$array\n"; # prints "item1, item2, item3, ..."
> }
I would expect so,
Garrett asked:
> Any word from on high whether subroutine signatures will apply to
> methods in Perl6?
Well, I hardly qualify as "on high" ("on *a* high" perhaps?) but I can
definitely say this: They will and they won't. ;-)
At compile-time, signatures can only be honoured if the com
> When foo() is called as &foo with no parens and no arguments, it
> inherits @_ from it's caller.
> I can't think of any reason why this feature is useful anymore, and it
> can be a really confusing behavior, so what say we kill it in Perl 6?
It's alreday scheduled for termination.
> My personal preference would be for all such properties (traits?) to be
> reserved across all types - eg using 'prompt' on a hash gives a
> compile/run time error. This allows the compiler to catch certain types
> of typo and thinko, and also allows us to expand in future - eg when
Scott wrote:
> Hmm. C seems to be synonymous with C (almost)
>
>when ($foo) { ... } # Does this mean if ($_ eq $foo)?
> if ($foo) { ... }
A C is an whose "other half" is specified by a surrounding C.
> However ...
>
> > A C within a C's block causes
> # >my $foo is const = 0 is true;
> # >
> # > $foo has the property const, while the value 0 in $foo has
> # > the property true.
> #
> # So, if I do
> #
> # my $foo is constant = new Counter(0);
> # $foo->increment # OK
>
> I think so.
Yep. Except the prop
Dan suggested:
> The syntax for variable and value properties are going to be different, I
> think, I just can't remember what it's going to be. (I think the colon's
> involved, but isn't it always?)
I think you're now channelling my de specula, not Larry's de jure. :-)
In A2, Larry
> More questions regarding the new 'given when' construct.
More answers (modulo Larry :-)
> 1) Is a 'when' clause required? Is it:
>
> [ LABEL: ] given ( expr_1 ) {
>when expr_2 : block
>[ when expr_3 : block ...]
>expr_n [;]
>
> 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
>$"
> for arrays?)
It's not
> There are a number of properties "built into" Perl 6. Nearly all of these
> properties don't make sense across the board - eg, a scalar won't have a
> dimension, a hash won't prompt, etc.
>
> So given the two different sets that you must consider (variable versus
> value, and
> Two things i think is good to have it :
>
> 1. ALIAS keyword.
> - first reason is 'cause many people don't know that this is possible.. at
> least any newscommer and it will help not to forgot that it exist :").
> - Code become more readable.
> - can be Overloaded
>
Chris Hostetter asked:
> Quandary #1: How "deep" of type specifications should / will perl6 allow?
> For example, could something like this work?
> my ARRAY(int(0..9)) $ref # $ref can only store an array ref
> # ...and that array can only hold ints
> > 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 'persistent'.
The programmer has marked the
> Simplifying somewhat (ok, a heck of a lot), an rvalued:
>
> $foo is bar
>
> or
>
> $foo : bar
>
> is syntactic sugar for:
>
> bar($foo)
>
> with some extra magic for handling a properties hash
> associated with $foo's value, in particul
> > 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
> delegation stuff in perl5+i, but it didn't
> >What's wrong with multiple inheritance?
>
> Nothing, but he wants MI on a per-object basis, rather than a per-class
> basis, presumably to avoid having to create a zillion classes who's sole
> purpose in life is to have an @ISA array.
>
> Sounds sensible, and worth send
Graham wrote:
> Now I may be wrong here, but I thought I remembered something about
>
> .foo being the same as $_.foo
It's certainly a possibility.
> In which case you could do
>
>for (%database.$accountnumber) {
>
>.interestearned += $interestrat
> What I was asking, in a roundabout way, was if
> $foo.bar.baz
> makes sense; your answer suggests that it does. In which case, we can
> teach the parser that a property query is just like a method call is
> just like a hash or array element (with optional dereference if you're
Dave Whipp asks:
> Does it do short-circuit evaluation, too?
I would certainly expect it to, yes.
Damian
Graham asked:
> IIRC there was some suggestion of a class being able to declare
> elements to be accessable as methods in this was.
>
> So if $ref is of a known type and 'a' was declared in that way,
> the parser would take $ref.a and turn it into $ref.{a}
This is intended. I'm n
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
Larry and I recently discussed chaining inequality operators.
He's in favour of it, but not of complex semantics involving
properties and implicit state (as I originally proposed in the
RFC)
I think we will see n-ary comparisons allowed in Perl 6:
if ($x < $y <$z < $foo) {...
but as sp
> > $ref.{a}can be $ref{a}
>
> which can also be
>
> $ref.a
>
> can it not?
Err..no.
$ref.{a}/$ref{a} is an access on a hash element through the hashref in $ref.
$ref.a is a call to the method a() of the object referred to by
> > But it's not as *convenient* as "unadorned" interpolation.
>
> Sometimes convenient has to give way
Here we differ. I think the frequency of the
/$var.ident(whatever)/
pattern is likely to be low enough that method interpolation is a
better use for the syntax.
> > Exp
> But with the above you still have abiguity, for example what does this do
>
> $bar =~ /$foo.colour($xyz)/;
"Looks like a method call with parens, so *is* a method call with parens."
> I may be remembering about interpolation into strings as "$file.ext" is
> going t
> >> So, to match $foo's colour against $bar, I'd say
> >>
> >> $bar =~ /$foo.colour/;
> >
> > No, you need the sub call parens as well:
> >
> > $bar =~ /$foo.colour()/;
>
> Hm, I thought Larry said you would need to use $() to interpolate
> So, to match $foo's colour against $bar, I'd say
>
> $bar =~ /$foo.colour/;
No, you need the sub call parens as well:
$bar =~ /$foo.colour()/;
> Great, but how do I match $foo followed by any character followed by the
> literal "colour"?
$bar =~ /
> Should properties interpolate in regular expressions? (and/or strings)
Do you mean property look-ups via the pseudo-method syntax?
In that case, yes they should
> I don't suppose they should, because we don't expect subroutines to.
> (if $foo =~ /bar($baz,$quux)/;? Urgh, maybe we ne
> So, is it right to say that one can't use stricture to avoid
> use of mistyped user defined value attached properties?
> (Perhaps with the exception of references to a value
> property in the same lexical scope as assignments of
> that value?)
>
> And, if this is so, then i
> Consider the code:
>
> my $foo = 1 is Found;
> &bar($foo);
>
> sub bar { my $baz = shift; if ($baz.Found) { ...} }
>
> Does the value of $baz have the Found property?
Yes.
> If so, does the compiler know that?
No. Because it only has the property at
> Question 1:
>
> Afaict, even with use strict at its most strict, perl 6
> can't (in practice) complain, at compile time, if
>
> $foo.Foun
>
> refers to an undeclared Foun.
It could certainly warn you, but it can't object fatally since there's
always the p
David wrote:
>defined $thing and return $thing
Why not use the existing mechanism? Namely:
return $_ for grep{defined} $thing;
which also scales rather nicely:
return $_ for grep{defined} $thing, $otherthing, $somethingelse;
As for the original problem of:
1
MJD just pointed out a minor thinko in the explanatory Perl6 code I posted:
sub gorkulator {
...
return $result is true if defined $result;
return undef is Because($borked);
}
# and later...
if ($res = gorkulator) {
> > Err. There are only two things: compile-time variable properties and
> > run-time value properties. Attributes are a Perl 5 construct that we're
> > renaming because the name conflicts with the OO term for object data.
>
> So,
>
> $a is true
>
> and
>
> $
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
Dave Storrs wrote:
> Second: I'm afraid that even after all this discussion and puzzling over
> this table for a bit, I'm still a bit baffled by this stuff. Perhaps I'm
> just slow, but let's assume for the sake of argument that I'm not the only
> one still scratching his head. C
Scott Duff wrote:
> > $bar is Open;
> > $bar is Open("from 5pm");
> > $bar{soom} is Open("from 5pm");
> > "bar" is Open("from 5pm");
> > 1 is Open("from 5pm");
> >
> > Note that in the first three of the above cases, it's the I > vari
901 - 1000 of 1282 matches
Mail list logo
