Re: reduce via ^
Damian Conway <[EMAIL PROTECTED]> writes: > Colin exemplifies: > >> $a = 1; >> @a = (1); >> @b = (1, 2, 3); >> @c = (4, 5, 6); >> >> $a = $a ^+ @b; >> @a = @a ^+ @b; >> >> print $a; # 7 > > No. It will (probably) print: 4. Because: > > $a = $a ^+ @b; > > becomes: > > $a = ($a,$a,$a) ^+ @b; > > which is: > > $a = (1,1,1) ^+ (1,2,3); > > becomes: > > $a = (2,3,4); > > which is: > > $a = 4; Hmm... I thought that $a = $a ^+ @b becomes: $a = [$a, $a, $a] ^+ [1, 2, 3] $a = [1, 1, 1] ^+ [1, 2, 3] $a = [2, 3, 4] Or am I mistaken about the new perl6 syntax for $a = @b; Or does the hyper operator 'listify' the stuff it's working on? -- Piers
Operator function names
Okay, I think I understand how we're going to be mapping from an operator to a function name in most cases. But what about the ternary operator? operator:??:: Or something else. I'm assuming something else, because there may be cases in which we want to define our own ternary operators. (Weird cases perhaps, but cases nevertheless... operator:??($)::($) perhaps? An enquiring mind wants to know. -- Piers
Apropos of nothing...
In the following code fragment, what context is foo() in? @ary[0] = foo() the following code @ary= foo() obviously evaluates @foo in a list context, but in the first I'm no longer sure. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Apropos of nothing...
"Brent Dax" <[EMAIL PROTECTED]> writes:
> Piers Cawley:
> # In the following code fragment, what context is foo() in?
> #
> # @ary[0] = foo()
>
> The short answer is scalar context. The long answer is below. Note
> that the long answer is only the way I think of it. You may think
> differently.
>
> I like to think of it as 'one context'. 'Scalar' and 'list' no longer
> describe the whole situation. The way I see it, there are three types
> of context:
> -void context (which could just be 0 context)
> -N context
> -infinite context (which could just be Inf context)
>
> Ihe meaning of each of those should be obvious. In that case, 'scalar'
> context is really 'one' context. However, we can still call it scalar
> context if it makes you feel better. :^) (Yes, those are just my
> opinions. They do not necessarily reflect Larry's, Damian's or the guy
> in the padded cell next to mine's.)
Okay. Here's the examples I threw at Dan.
@ary[0] = foo() # scalar
@ary[1,2] = foo() # list context
@bar = 1;
@ary[@bar] = foo() # ? probably list or maybe scalar...
@bar = (1,2);
@ary[@bar] = foo() # list?
@bar is constant = 1;
@ary[@bar] = foo() # We know at compile time there's only one thing in
# @bar. Does that mean foo() is in a scalar context
# now?
sub a_scalar { 1 };
sub an_array { my @a = (1,2) }
sub context { wantarray ? (1,2) : 1 }
@ary[a_scalar()] = foo() # ???
@ary[an_array()] = foo() # ???
At around this point, Dan was heard to say 'Mommy, make the bad man go
away!'
@ary[context()] = foo() # ???
Oh yes, and what context is &context called in?
And, just for laughs:
$ref = [1,2];
@ary[$ref] = foo(); # probably a syntax error
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Apropos of nothing...
Aaron Sherman <[EMAIL PROTECTED]> writes: > On Sun, Dec 16, 2001 at 03:55:10PM +1100, Damian Conway wrote: > > [...] > >>> And, just for laughs: >>> >>> $ref = [1,2]; >>> @ary[$ref] = foo(); # probably a syntax error > > Ok, as far as I can recall, Larry hinted that arrays and references to > arrays would be interchangable in many contexts in P6. In this case, I > can't see any reason that subscripting would *want* to do a SvIV on > a known reference, so I would expect it to obey that logic and treat > the reference as an array. Thus, I expect this to be list context for > the exact same reason that: > > @bar = (1,2); > @ary[@bar] = foo(); > > would be. > > Next question, though: > > $val = (foo())[0]; > > List? Scalar, obviously. With a possible runtime error if foo doesn't return an arrayref. And that should probably written as: $val = foo().[0] -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Apropos of nothing...
Damian Conway <[EMAIL PROTECTED]> writes: >> >$val = (foo())[0]; >> > >> > List? >> >> Scalar, obviously. > > How do you figure that? (Not a criticism: I'd really like to understand your > thought process here so I can assess the relative DWIMity of the two > alternatives). I figure I'm going mad actually. Misread the initial post. (foo())[0] is distinct from (foo()).[0], or foo[0] or all the other options. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Apropos of nothing...
Resending due to BT doing bad things to good nameservers. Damian Conway <[EMAIL PROTECTED]> writes: >> >$val = (foo())[0]; >> > >> > List? >> >> Scalar, obviously. > > How do you figure that? (Not a criticism: I'd really like to understand your > thought process here so I can assess the relative DWIMity of the two > alternatives). I figure I'm going mad actually. Misread the initial post. I'm now thinking that (foo())[0] is distinct from (foo()).[0], or foo[0] or all the other options. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Does this mean we get Ruby/CLU-style iterators?
Michael G Schwern <[EMAIL PROTECTED]> writes:
> Reading this in Apoc 4
>
> sub mywhile ($keyword, &condition, &block) {
> my $l = $keyword.label;
> while (&condition()) {
> &block();
> CATCH {
> my $t = $!.tag;
> when X::Control::next { die if $t && $t ne $l); next }
> when X::Control::last { die if $t && $t ne $l); last }
> when X::Control::redo { die if $t && $t ne $l); redo }
> }
> }
> }
>
> Implies to me:
>
> A &foo prototype means you can have a bare block anywhere in the
> arg list (unlike the perl5 syntax).
>
> Calling &foo() does *not* effect the callstack, otherwise the
> above would not properly emulate a while loop.
>
> If that's true, can pull off my custom iterators?
> http:[EMAIL PROTECTED]/msg08343.html
>
> Will this:
>
> class File;
> sub foreach ($file, &block) {
> # yeah, I know. The RFC was all about exceptions and I'm
> # not using them in this example.
> open(FILE, $file) || die $!;
>
> while() {
> &block();
> }
>
> close FILE;
> }
Hmm... making up some syntax on the fly. I sort of like the idea of
being able to do
class File;
sub foreach ($file, &block) is Control {
# 'is Control' declares this as a control sub, which, amongst
# other things 'hides' itself from caller. (We can currently
# do something like this already using Hooks::LexWrap type
# tricks.
open my $fh, $file or die $!; POST { close $fh }
while () {
my @ret = wantarray ?? list &block() :: (scalar &block());
given $! {
when c::RETURN { return wantarray ?? @ret :: @ret[0] }
}
}
}
This is, of course, dependent on $! not being set to a RETURN control
'exception' in the case where we just fall off the end of the block.
It's also dependent on being able to get continuations from caller
(which would be *so* cool
> allow this:
>
> File.foreach('/usr/dict/words') { print }
Sounds plausible to me.
> or would the prototype be (&file, &block)?
I prefer the ($file, &block) prototype.
> And would this:
>
> my $caller = caller;
> File.foreach('/usr/dict/words') {
> print $caller eq caller ? "ok" : "not ok"
> }
>
> be ok or not ok? It has to be ok if mywhile is going to emulate a
> while loop.
In theory there's nothing to stop you writing it so that that is the
case. I'd like it to be as simple as adding an attribute to the
function declaration (and if it isn't that simple out of the box, it
will almost certainly be, if not trivial, at least possible to write
something to *make* it that simple...)
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Does this mean we get Ruby/CLU-style iterators?
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 3:37 PM + 1/18/02, Piers Cawley wrote:
>>Michael G Schwern <[EMAIL PROTECTED]> writes:
>>
>>Hmm... making up some syntax on the fly. I sort of like the idea of
>>being able to do
>>
>> class File;
>> sub foreach ($file, &block) is Control {
>> # 'is Control' declares this as a control sub, which, amongst
>> # other things 'hides' itself from caller. (We can currently
>> # do something like this already using Hooks::LexWrap type
>> # tricks.
>>
>> open my $fh, $file or die $!; POST { close $fh }
>>while () {
>> my @ret = wantarray ?? list &block() :: (scalar &block());
>> given $! {
>> when c::RETURN { return wantarray ?? @ret :: @ret[0] }
>> }
>> }
>> }
>>
>>This is, of course, dependent on $! not being set to a RETURN control
>>'exception' in the case where we just fall off the end of the block.
>
> I don't think you'll see $! being set to anything other than real
> errors. Larry may change that, but I'd doubt it. It's more a global
> status than anything else. Exceptions would go elsewhere, I'd hope.
Um... I'm not sure that's how I read the Apocalypse. And if it doesn't
get set how on earth are we going to be able to tell how a block
exited in the case of home rolled looping/iterating constructs where
we're going to want to write:
sub foo {
...
File.foreach($file_path) {
...
return ($someval) if /some_pattern/;
...
}
}
and have foo return.
Maybe we'll have to have something like:
while () {
try {
temp c::RETURN is Error;
temp c::NEXT is Error;
temp c::REDO is Error;
temp c::LAST is Error;
wantarray ?? list &block() :: (scalar &block());
DEFAULT { throw };
}
}
Then, because the control structures are temporarily Errors within the
scope of the try block they get thrown up to the first thing that can
handle them. In the case of NEXT/REDO/LAST, that's the while loop, and
in the case of the RETURN, that's the enclosing subroutine. But it
seems kludgy as hell.
> I personally would like to see subs be taggable as transparent to
> yielding, so if you call a sub, and it calls a sub, that inner sub
> could yied out of the caller if the caller was transparent. Not, mind,
> that the scheme doesn't have issues, but...
>[...]
>>It's also dependent on being able to get continuations from caller
>>(which would be *so* cool)
>
> For some brainwarping version of cool. :)
Hmm... the example I wrote which might possibly have used
continuations got wiped 'cos I realised I wasn't exactly clear on how
they were going to work. But I still think being able to grab a
continuation from up the stack somewhere could be handy, allowing
syntax like:
&block.call_from($continuation);
Which is sort of nice, and sort of really, really evil. The thing is,
given continuations and $continuation.want (so I can work out what
context the continuation called in...) I can see how to implement it:
class BLOCK;
sub call_from ($continuation) {
given $continuation.want {
when LIST { $continuation.return(list .yield) }
default { $continuation.return(scalar .yield) }
}
}
Of course, I could have got *completely* the wrong end of the stick
about continuations. And this example doesn't do the 'right thing' for
caller, but hey, it's a start.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Apo4: PRE, POST
"Me" <[EMAIL PROTECTED]> writes: >> [concerns over conflation of post-processing and post-assertions] > > Having read A4 thoroughly, twice, this was my only real concern > (which contrasted with an overall sense of "wow, this is so cool"). I think that people have sort of got used to the fact that Perl 6 is not going to look quite as much like perl5 as they thought it was going to. Either that or they've all buggered off... Personally I'm loving it. The small changes in the syntax are all coming together to give us something that's going to be far easier to parse (and therefore far easier to mess with syntacticly, which is what excites me; I've long had the mathematician's view that stuff becomes so much easier when you have the right notation. A more mutable perl means that I build myself the right notation and then solve the problem -- I want to invent my own syntactic sugar if that makes sense...) -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
A question
Okay boys and girls, what does this print:
my @aaa = qw/1 2 3/;
my @bbb = @aaa;
try {
print "$_\n";
}
for @aaa; @bbb -> my $a; my $b {
print "$a:$b";
}
I'm guessing one of:
1:1
2:2
3:3
or a syntax error, complaining about something near
C<@bbb -> my $a ; my $b {>
In other words, how does the parser distinguish between postfix for
followed by a semicolon, and the new semicolon enhanced 'normal' for?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Does this mean we get Ruby/CLU-style iterators?
Larry Wall <[EMAIL PROTECTED]> writes:
> Michael G Schwern writes:
> : Reading this in Apoc 4
> :
> : sub mywhile ($keyword, &condition, &block) {
> : my $l = $keyword.label;
> : while (&condition()) {
> : &block();
> : CATCH {
> : my $t = $!.tag;
> : when X::Control::next { die if $t && $t ne $l); next }
> : when X::Control::last { die if $t && $t ne $l); last }
> : when X::Control::redo { die if $t && $t ne $l); redo }
> : }
> : }
> : }
> :
> : Implies to me:
> :
> : A &foo prototype means you can have a bare block anywhere in the
> : arg list (unlike the perl5 syntax).
>
> That is correct.
>
> : Calling &foo() does *not* effect the callstack, otherwise the
> : above would not properly emulate a while loop.
>
> Maybe it's transparent to caller but not to caller($n). I'm not sure how
> much of a problem this will be. Inside &block it's a closure, which
> carries a lot of the context you need already. Continuations may be
> overkill.
I think having the caller($n) stack work so that control structures
are transparent no matter where they came from is really, really
important. But we can do that right now by pulling Hooks::LexWrap type
tricks:
temp &CORE::GLOBAL::caller = { ... };
Problem solved. I'd just hoped it was something we'd not have to do
ourselves in the general case.
> : If that's true, can pull off my custom iterators?
> : http:[EMAIL PROTECTED]/msg08343.html
> :
> : Will this:
> :
> : class File;
> : sub foreach ($file, &block) {
> : # yeah, I know. The RFC was all about exceptions and I'm
> : # not using them in this example.
> : open(FILE, $file) || die $!;
>
> That's
>
> my $FILE = open $file || die;
>
> and so on.
>
> : while() {
> : &block();
> : }
> :
> : close FILE;
> : }
> :
> : allow this:
> :
> : File.foreach('/usr/dict/words') { print }
>
> File.foreach('/usr/dict/words', { print })
>
> or even (presuming the prototype is available for parsing):
>
> File.foreach '/usr/dict/words' { print }
Hmm... does this mean that control structures are just going to be
normal expression (a la Ruby)? Or are if/for/loop etc going to be
special cases? I really like them not being special cases, but I can
also see that having:
foreach foreach @a { ... } { ... }
be legal syntax would be very weird indeed. Hmm... going the whole
ruby hog would mean that:
{ ... }.foreach @ary;
would be valid. Hmm...
> : or would the prototype be (&file, &block)?
> :
> : And would this:
> :
> : my $caller = caller;
> : File.foreach('/usr/dict/words') {
> : print $caller eq caller ? "ok" : "not ok"
> : }
> :
> : be ok or not ok? It has to be ok if mywhile is going to emulate a
> : while loop.
>
> I don't see why the default caller has to be caller(1). In any event,
> user-define control code will need to be able to get out of the way
> of the programmer's expectations. A return certainly needs to return
> from the surrounding lexical sub block, not from a mere bare block.
And caller has to 'lie' about its stack, because otherwise methods
that get called from within the loop that do caller($n) will get
confused.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: A question
[reformatting response for readability and giving Glenn a stiff talking
to]
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>> Okay boys and girls, what does this print:
>>
>> my @aaa = qw/1 2 3/;
>> my @bbb = @aaa;
>>
>> try {
>> print "$_\n";
>> }
>>
>> for @aaa; @bbb -> my $a; my $b {
>> print "$a:$b";
>> }
>>
>> I'm guessing one of:
>> 1:1
>> 2:2
>> 3:3
>>
>> or a syntax error, complaining about something near
>> C<@bbb -> my $a ; my $b {>
>>
>> In other words, how does the parser distinguish between postfix for
>> followed by a semicolon, and the new semicolon enhanced 'normal' for?
>
> That particular example is flawed, because the try expression is turned
> into a try statement because the } stands alone on its line.
>
> But if you eliminate a couple newlines between } and for, then your
> question makes sense (but the code is not well structured, but hey, maybe
> you take out all the newlines for a one-liner...).
>
> The answer in that case is probably a syntax error, and to avoid it, you
> put a ; between the } and the for.
Yeah, that's sort of where I got to as well. But I just wanted to make
sure. I confess I'm somewhat wary of the ';' operator, especially
where it's 'unguarded' by brackets, and once I start programming in
Perl 6 then
for (@aaa ; @bbb -> $a; $b) { ... }
will be one of my personal style guidelines.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Apoc4: "When do I put a semicolon after a curly?"
You're treating do, if, foreach as if they were keywords. I'm not entirely sure that that's still the case. And you're also forgetting the possibility of user implemented control type operators/methods. Unless I'm very much mistaken you're suggesting that we special case the parser for 'do' and any user defined functions that take a block can go hang. Which I'm really not keen on. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: A question
Larry Wall <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
> : Yeah, that's sort of where I got to as well. But I just wanted to make
> : sure. I confess I'm somewhat wary of the ';' operator, especially
> : where it's 'unguarded' by brackets, and once I start programming in
> : Perl 6 then
> :
> : for (@aaa ; @bbb -> $a; $b) { ... }
> :
> : will be one of my personal style guidelines.
>
> That is likely a syntax error, because the -> is not an operator, but a
> kind of unary keyword like "sub", and it binds the righthand arguments
> to the following block. You'd have to say:
>
> for (@aaa; @bbb) -> ($a; $b) { ... }
So long as there's *some* way of 'protecting' the ; operator the
details of the syntax are almost irrelevant. And that does make a good
deal more sense.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: A question
Piers Cawley <[EMAIL PROTECTED]> writes:
> Larry Wall <[EMAIL PROTECTED]> writes:
>
>> Piers Cawley writes:
>> : Yeah, that's sort of where I got to as well. But I just wanted to make
>> : sure. I confess I'm somewhat wary of the ';' operator, especially
>> : where it's 'unguarded' by brackets, and once I start programming in
>> : Perl 6 then
>> :
>> : for (@aaa ; @bbb -> $a; $b) { ... }
>> :
>> : will be one of my personal style guidelines.
>>
>> That is likely a syntax error, because the -> is not an operator, but a
>> kind of unary keyword like "sub", and it binds the righthand arguments
>> to the following block. You'd have to say:
>>
>> for (@aaa; @bbb) -> ($a; $b) { ... }
>
> So long as there's *some* way of 'protecting' the ; operator the
> details of the syntax are almost irrelevant. And that does make a good
> deal more sense.
than my original suggestion.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Apoc4: The loop keyword
Michael G Schwern <[EMAIL PROTECTED]> writes: > On Mon, Jan 21, 2002 at 03:27:29PM -0500, Casey West wrote: >> So you're suggesting that we fake lexical scoping? That sounds more >> icky than sticking to true lexical scoping. A block dictates scope, >> not before and not after. I don't see ickyness about making that >> so. > > Perl5 already fakes lexical scoping all over the place. A lot of that > fakery can be removed from the language, yes, but in the case of block > conditions it seems that DWIMery should win over orthoginality. But that kind of DWIMery makes it really hard to extend perl's syntax in any meaningful ways. You end up having to write your own parser virtually, and parsers are really hard to write because there's so many exceptions to rules. If we have a more orthogonal language to begin with it's going to be far easier to extend it in whatever direction we need for a particular problem space. And once you have something whose syntax is easy to extend, you can always introduce your own non-orthogonality and DWIMery, but this time you can make it do what you really mean. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: [dha@panix.com: Re: ^=~]
Damian Conway <[EMAIL PROTECTED]> writes:
> I suppose this discussion also raises the vexed question whether ??::
> can also be put out to pasture in favour of:
>
> $val = if $x { 1 } else { 2 }
Only if you can also do:
if $x { $x } else { $y } = 'foo';
But that looks really scary.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Night of the Living Lexical (sequel to Apoc4: The loop keyword)
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Mon, Jan 21, 2002 at 03:02:06PM -0500, Tzadik Vanderhoof wrote:
>> Why all the fuss? Often, you would *want* to access that lexical after the
>> loop terminates, for instance to check how it terminated.
>
> In most cases you don't want that to happen, usually the life of the
> lexical is only the block. If you do want it to live on you can
> simply predeclare it.
>
> my $foo;
> if $foo = bar {
> ...
> }
>
> which is much simpler than the current setup, where you'll often have
> to do this to keep $foo in its proper place.
>
> do {
> if my $foo = bar {
> ...
> }
> }
If, by the time Larry has finished with the apocalypse process you
don't have enough tools to write yourself a 'lexif' that does exactly
that (and which you can actually define to be 'if' for the remainder
of the package file) I will be more than a little surprised.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: PMCs, setting, and suchlike things [forward from p6-internals]
"Wizard" <[EMAIL PROTECTED]> writes:
> This came up on perl6-internals, and Dan liked the "try" suggestion and
> suggested That I post it here for comments. I'm not subscribed to
> p6-language, so you'll need to include me in any replies where you want a
> response from me.
> =
> Dave Mitchell <[EMAIL PROTECTED]> wrote:
>> my Complex $c = 3+4i;
>> my $plain = 1.1;
>> $plain = $c;
>
> This might be even more "Complex" than that - what if Complex can be
> reduced? Should it? for instance:
>
> my Complex $c = 3+4i;
> my Complex $d = 4i;
> my $plain = $c / $d;
>
> Does $plain (which is actually '3' after reducing) get promoted to Complex,
> or does the result from the division get demoted?
In general I'd say that $plain shouldn't change class (I'm not sure
it's being demoted; after all, a real number has more constraints on
it than a complex number), for the same reason that
Rectangle.new(sides => [1, 1]).isa('Square');
should return false.
>
> Perhaps there could be a sort of 'try' for conversion that returns the best
> possible result? for instance:
>
> my Complex $c = 3+4i;
> my Complex $d = ;
> my $plain = try_demote( $c / $d );
>
> $plain now ISA Complex if it couldn't demote the result of the math, or it
> ISA scalar (int or float) if it could. Now if you need to know, then just
> check:
>
> $plain = try_demote( $c / $d );
> # the '(or)'s here are alternate forms, not comparison
> if( $plain.type == "Complex" (or) $plain.Complex ){
>print "It promoted!\n";
> }
> elsif( $plain.type == "Scalar" (or) $plain.Scalar ) {
>print "Result was reduced!\n";
> }
Demote is a really bad name I think.
$plain = most_appropriate_type($c / $d);
might be better, but it's still ugly.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Metadata
Larry Wall <[EMAIL PROTECTED]> writes: > Charles Bunders writes: > : I came across Simon Cozens email > : (http:[EMAIL PROTECTED]/msg08641.html) again > : tonight and it got me thinking... > : > : In Perl 6 are modules compiled down to pbc (Perl byte code) going to also > : create metadata similar to what .NET has describing methods, use, etc. > > We have to do that if we want to run well on top of .NET. > > : I don't think it would be that dificult to do and you could do some interesting > : things with the development environments on the various platforms with it as > : well. > : > : Just curious if you plan on keeping with the POD documentation in the source or > : had some magic mojo you would be throwing in either with the pbc or files that > : go with it? > > Hasn't been designed yet. POD streams will certainly have to be > accessible, but so will various kinds of metadata derived from Perl > declarations. So it's unlikely to be an either/or thing. Those of us attempting to write refactoring tools would *really* appreciate being able to trace an opcode back to the actual source that generated it. An optree that held onto comments in no op type nodes would be quite handy too. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
A thought occured to me...
Wouldn't it be nice if you could do:
class Foo {
...
&{intern('{}')} := method ($self: $key) is lvalue {
...
}
}
So, later, you could do:
$obj = Foo.new;
$obj{something} = $something_else;
ie, overriding hash lookups, array lookups, whatever. (I'm using a
Lispish 'intern' here to return a symbol from a string by the way, I
doubt it's a good 'real' syntax, but I'm not at all keen on C
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: A thought occured to me...
Simon Cozens <[EMAIL PROTECTED]> writes:
> Piers Cawley:
>> ie, overriding hash lookups, array lookups, whatever.
>
> Ah, you want C#/Python indexers, you do. So do I.
Um... is that what you call 'em. Actually, you can already do
'use overload q|%{}|', to sort of do this...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Exegesis 4
Over on use.perl, someone spotted what looks like a bug in the example
program which (if it *is* a bug) is fixed by using unary '*', but
that's not what I'm writing about here.
In the discussion of the yadda yadda yadda operator, Damian says that
... in this example, Err::BadData is *never* completely defined. So
we'd get a fatal compile-time error ...
Surely it would be better to make it a 'CHECK' time error (or whatever
CHECK's equivalent will be in perl 6. ie, it happens after compilation
has finished, but before runtime starts. That way, the likes of
B::Deparse can still do useful work.
Also, some sort of pragmatic control would be nice, say
use incomplete;
would allow incomplete definitions to compile successfully, only
throwing errors if they are encountered at execution time. That way
one could write.
CATCH {
when TricksyException {
...
}
when IgnoreableException {
redo; # Hmm... how do I say 'redo the block containing the
# block containing the block containing the redo'?
# Labels are one way I guess, but how about 'redo 2'
# meaning 'go up two blocks from here'
}
}
And in the presence of 'use incomplete' the running code would run
happily until it encountered an undefined section of, when it would
throw an 'IncompleteDefinitionException' or whatever.
Then one could also use
method abstract_method {...}
in abstract, or semi abstract class definitions, then again
method abstract_method is abstract;
might well be a better bet, but that depends on whether a method
definition without a block is going to be legal syntax in perl 6 (and
reading between the lines of E4, I don't think it will be).
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Exegesis 4
Damian Conway <[EMAIL PROTECTED]> writes:
> Piers wrote:
>
>> Over on use.perl, someone spotted what looks like a bug in the example
>> program which (if it *is* a bug) is fixed by using unary '*', but
>> that's not what I'm writing about here.
>
> I'll admit I'm not sure whether it is a bug or not. I've asked Larry for
> clarification and will post an update as soon as he responds.
Good oh. BTW, (and apologies for repeating the question I asked
elsewhere) are we going to see an updated Apocalypse 4 incorporating
all the changes made to get E4 to work?
>> In the discussion of the yadda yadda yadda operator, Damian says that
>>
>>... in this example, Err::BadData is *never* completely defined. So
>>we'd get a fatal compile-time error ...
>>
>> Surely it would be better to make it a 'CHECK' time error (or whatever
>> CHECK's equivalent will be in perl 6. ie, it happens after compilation
>> has finished, but before runtime starts. That way, the likes of
>> B::Deparse can still do useful work.
>
> Well, I consider C to be part of of compile-time,
> so I don't think we're disagreeing. :-)
Heh. Okay.
>> Also, some sort of pragmatic control would be nice, say
>>
>>use incomplete;
>
> or perhaps:
>
> no strict 'definitions'.
Ah, now that's better.
>>when IgnoreableException {
>>redo; # Hmm... how do I say 'redo the block containing the
>> # block containing the block containing the redo'?
>> # Labels are one way I guess, but how about 'redo 2'
>> # meaning 'go up two blocks from here'
>>}
>>}
>
> As described in E4, you make the block containing the block
> containing the block containing the C a C block (or a
> labelled block).
Dang, being able to redo arbitrary blocks would be really neat. Though
possibly scary to implement...
>> Then one could also use
>>
>> method abstract_method {...}
>>
>> in abstract, or semi abstract class definitions, then again
>>
>> method abstract_method is abstract;
>>
>> might well be a better bet, but that depends on whether a method
>> definition without a block is going to be legal syntax in perl 6 (and
>> reading between the lines of E4, I don't think it will be).
>
> Larry indicated to me that blockless declarations of methods and subs
> would be illegal. So you'd probably have to write:
>
> method abstract_method is abstract {...}
>
> And the C would absolve your method from the
> compile-time "method 'abstract_method' was never defined" error.
That makes sense. Solves the 'intention revealing code' problem quite
neatly too; you don't have to worry about whether a particular
C was left unfinished by the coder or whether it's
*deliberately* unfinished and is actually an abstract method. (Yeah, I
know you can use a comment, but I prefer executable comments like C, which can survive perl -MO=Deparse)
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Apocrypha
So, I've been looking at the stuff in the Apocalypses and Exegeses so far and I think I've reached the point where I can have a crack at using perl 6 to implement another programming language. Coming (possibly) to a mailing list near you, Perl6::Scheme... -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Exegesis 4
Damian Conway <[EMAIL PROTECTED]> writes: >> Good oh. BTW, (and apologies for repeating the question I asked >> elsewhere) are we going to see an updated Apocalypse 4 incorporating >> all the changes made to get E4 to work? > > Probably not any time soon. Previous Apocalypses haven't been > updated when changes were made. > > Eventually, of course, we'll have to go back and make eveything > copacetic, but at the moment I think most folks would rather have us > working on writing unwritten A's and E's, rather than rewriting > written ones. ;-) Point. Maybe someone will step up to plate and do Perl 6 so far in a nutshell; and will keep it up to date. Maybe that someone will be me, but if anyone else would like to volunteer... -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Nested whens?
Just a thought, I assume that something like the following will be legal:
given $msg {
when Message::ACK {
$msg_store.fetch( $msg.acknowledged_msg ).set_state($msg);
}
when Message::SMS {
when .is_incoming { ... }
when .is_outgoing { ... }
default { die "$msg is neither coming nor going" }
}
}
Yeah, it's not good style; I should really be doing
$msg.dispatch_to($self)
or some such trick and letting polymorphism be my aid and comforter,
but it's illustrative.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Exegesis 4
Damian Conway <[EMAIL PROTECTED]> writes: >> > Eventually, of course, we'll have to go back and make eveything >> > copacetic, but at the moment I think most folks would rather have us >> > working on writing unwritten A's and E's, rather than rewriting >> > written ones. ;-) >> >> Point. Maybe someone will step up to plate and do Perl 6 so far in a >> nutshell; and will keep it up to date. Maybe that someone will be me, >> but if anyone else would like to volunteer... > > Eventually Larry and/or I will have to go back and work the whole thing > through. I've already had thoughts on "Perl 6 in a Nutshell", and I'm > sure Larry will want to do "Programming Perl 6". > > The problems with having someone update the previous documents are: I wasn't really suggesting updating the previous documents. I was thinking more of keeping a single document that tracks the current, published state of perl 6. I think I might have a crack at it myself, see if I can come up with anything useful. (Show, don't tell...) > > a) We lose the historical development, > > b) It's a constantly moving target (go back and read the > early A's and E's and see just how much has changed every > single time we released another A or E), > > c) Larry would still have to executive edit the changes, and > that would take far too much of his time (just dealing with > the Exegeses takes far too much of his time). Hmm... that's the showstopper isn't it? -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: $^a, $^b, and friends
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Wed, Apr 03, 2002 at 11:27:10AM -0800, Larry Wall wrote:
>> They are assumed to be declared in alphabetical order. Whoa! you say,
>> that could get confusing. It surely can. But if you're doing
>> something complicated enough that alphabetical order would be
>> confusing, don't use this shorthand.
>
> Alphabetically or asciibetically? I mean, are these functionally
> equivalent?
>
> { $^a - $^A }
> { $^b - $^a }
I'm assuming it can't be strictly asciibetical, given that $^2 sorts
before $^10.
What's happened with C<{ $^_ - $^_ }>? Are those two the same
parameter now? Or two different 'anonymous' parameters?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Exegesis 4
Damian Conway <[EMAIL PROTECTED]> writes:
> Larry explained:
>
>> : Umm. didn't you say bare blocks were going away?
>>
>> Rule #2 was invoked.
>>
>> The current thinking is that any bare block will never be interpreted
>> as returning a closure. You have to use explicit C or C
>> to return a closure.
>
> Or the equivalent of a C, namely:
>
> $closure = -> {...};
>
> or:
>
> $closure = { $^has_a_placeholder_variable };
>
>
> Or an explicit closure context:
>
> sub foo(&closure) {...};
>
> foo { this_block_is_a_closure() };
The closure is going to close over all the variables currently in
scope isn't it? Not just the immediately containing scope.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: $^a, $^b, and friends
Larry Wall <[EMAIL PROTECTED]> writes: > Dan Sugalski writes: > : >Strict, but doesn't really matter. Nobody sane will use anything other > : >than $^a and $^b. > : > : Well Are we allowing non-latin characters in identifiers? There > : may be potential interesting ramifications with those. Kanji > : specifically, though I don't have details for them yet. > > Yes, you can use anything with the letter or number property in > identifiers, plus you can use ideographs. As it happens, the Kanji > for "one" and "two" come in the right order, but don't try to extend > that to "three". Aw... so no C then? I've kind of got used to that while I've been playing with scheme and smalltalk. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: $^a, $^b, and friends
Larry Wall <[EMAIL PROTECTED]> writes: > Piers Cawley writes: > : Larry Wall <[EMAIL PROTECTED]> writes: > : > : > Dan Sugalski writes: > : > : >Strict, but doesn't really matter. Nobody sane will use anything other > : > : >than $^a and $^b. > : > : > : > : Well Are we allowing non-latin characters in identifiers? There > : > : may be potential interesting ramifications with those. Kanji > : > : specifically, though I don't have details for them yet. > : > > : > Yes, you can use anything with the letter or number property in > : > identifiers, plus you can use ideographs. As it happens, the Kanji > : > for "one" and "two" come in the right order, but don't try to extend > : > that to "three". > : > : Aw... so no C then? I've kind of got used to that > : while I've been playing with scheme and smalltalk. > > You can do anything you like if you mess with the parser. Changing > the rules for recognizing an identifier would be trivial. Duh! Of course. What was I thinking? -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Tail Recursion optimization
So, here I am working on a Scheme interpreter in Perl 6, and I'm trying to write it in a (for want of a better description) 'Scheme-like' fashion with lots of recursion. The trouble is, unless Perl6 is going to be guaranteed to do optimization of tail calls, this is going to lead to horribly slow code. So, do I bite the bullet and recast some of the functions in an iterative vein, or do I trust that Perl6 will do tail call optimization? Larry? -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Questions about private variables
Damian Conway <[EMAIL PROTECTED]> writes:
> Joe Gottman wrote:
>> For instance, what would happen in the
>> following code?
>>
>> sub func1() {
>> our $varname is private \\= 1;
>> return $varname;
>> }
>>
>> sub func2() {
>> our $varname is private \\= 2;
>
> Fatal error: "Private variable $varname declared in two distinct scopes".
Um... there'd be a syntax error before that. "\\=" should be "//=" surely?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Tail Recursion optimization
"Jonathan E. Paton" <[EMAIL PROTECTED]> writes:
>> : Piers Cawley writes:
>> :
>> : So, here I am working on a Scheme interpreter in Perl 6, and I'm
>> : trying to write it in a (for want of a better description)
>> : 'Scheme-like' fashion with lots of recursion.
>> :
>> : The trouble is, unless Perl6 is going to be guaranteed to do
>> : optimization of tail calls, this is going to lead to horribly slow
>> : code. So, do I bite the bullet and recast some of the functions in an
>> : iterative vein, or do I trust that Perl6 will do tail call optimization?
>> :
>> : Larry?
>>
>> Larry Wall responds:
>>
>> Why not? The only casualty is caller()'s semantics, and I think we
>> can live with that, or disable the optimization on routines that use
>> caller().
>
> Carp.pm is implemented with caller(), does that mean:
>
> sub forever {
> my $depth = shift;
>
> croak "I got bored"
> if $depth == 1000;
>
> forever($depth + 1);
> }
>
> will have its optimizations disabled? Or is that fair game;
> considering you have to play a little more intimately with Carp to
> croak from the right place?
Hmm... I'd hope croak would do the right thing without having to break
the tail call optimization. Personally, I think the best bet is to
alter caller's semantics slightly (in fact I think that the
optimization will make it more likely that caller(1) will return the
right thing.)
> Mental note:
>
> 1. Don't use recursion in Perl, it'll be much slower than an
>iterative approach
> 2. If in doubt, refer to note 1.
Certainly will be slower in Perl 5. Hopefully what won't be the case
in Perl 6 (having had to recast code from tail recursive form
explicitly iterative form, I'd really rather not have to do that in
the general case.)
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Tail Recursion optimization
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 11:45 PM +0100 4/5/02, Piers Cawley wrote: >>So, here I am working on a Scheme interpreter in Perl 6, and I'm >>trying to write it in a (for want of a better description) >>'Scheme-like' fashion with lots of recursion. >> >>The trouble is, unless Perl6 is going to be guaranteed to do >>optimization of tail calls, this is going to lead to horribly slow >>code. So, do I bite the bullet and recast some of the functions in an >>iterative vein, or do I trust that Perl6 will do tail call optimization? > > If you don't mind emitting bytecode directly, Parrot's calling > conventions are such that tail calls and tail recursion works OK. I know. When I do the parrot version of this I'm going to be taking every advantage of it. (Once I've worked out how to detect that I'm about to make a tail call). -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: $^a, $^b, and friends
Larry Wall <[EMAIL PROTECTED]> writes:
> Rafael Garcia-Suarez writes:
> : Larry Wall wrote in perl.perl6.language :
> : >
> : > Such a grammar switching routine could operate either over a lexical
> : > scope or over the rest of the file. The only restriction is that
> : > one module not clobber the grammar of a different module.
> : >
> : > Basically, we're trying to make the opposite mistake of the one
> : > we made with source filters. :-)
> :
> : I see that. But should it be possible to import grammar rules,
> : to allow :
> :
> : use Some::Module::That::Modifies::A::Grammar::Rule;
> : # continue to parse the perl program with the modified grammar
> :
> : or even :
> : {
> : use Some::Module::That::Modifies::A::Grammar::Rule;
> : # continue to parse the block with the modified grammar
> : }
>
> Well, it's kind of klunky to do an import every time. More likely
> you'd import a special subroutine once that you can use like this:
>
> Java {
> whatsit.blorf.unnecessary.bletch.extra.something.whatever(1);
> }
>
> Perl 5 is restricted to doing compile-time actions using BEGIN or
> use. In Perl 6 there will be some way of marking a normal
> subroutine as as grammatically active, so that it's called
> immediately, even before its arguments are parsed. Our hypothetical
> Java subroutine above could switch to a Java grammar, parse its
> block, and then restore the Perl grammar at the end.
In a use.perl post not far away I sketched out something like the following:
module foo is Mixin {
sub category($category, &block) {
&block.abstract_syntax_tree.walk_with -> $node {
when AST::Method {
.attrib(category => $category) if .parent =~ █
}
}
}
Actually, my naming choices were rather worse, I originally suggested
'optree', but the optree is really too low level for a lot of things.
# Which leads to thoughts of:
macro Java(&block is rw) {
&block = &block.source.parse_with( Parser::Java )
}
}
(The idea here is that 'macro' would get the block 'earlier' while the
raw source is still lying around, and before perl has started to throw
syntax errors.)
> : And what about switching to a different or modified tokenizer ?
>
> It's not clear that the lexer is a separate entity any more. Lexers
> were originally invented as a way of abstracting out part of the
> grammar so that it could be done in a separate pass, and to simplify
> the grammar for the poor overworked parser. But you can write a
> grammar for an identifier just about as easily as for an if-then-else.
> More easily, if we're basing it on regexes. If we're viewing all
> grammar through the lens of regexes, we're really starting out closer
> to Lexerland anyway, and generalizing toward parsing, a traditionally
> weaker area for Perl. And that's an odd weakness for a text
> processing language.
I am *so* looking forward to Apocalypse 5...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: $^a, $^b, and friends
Larry Wall <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
> : In a use.perl post not far away I sketched out something like the following:
> :
> : module foo is Mixin {
> :
> : sub category($category, &block) {
> : &block.abstract_syntax_tree.walk_with -> $node {
> : when AST::Method {
> : .attrib(category => $category) if .parent =~ █
> : }
> : }
> : }
>
> I don't entirely understand what you're trying to do. Pretty code,
> though. :-)
Heh. I didn't think it was that tricky.
..abstract_syntax_tree gets the blocks Syntax Tree.
..walk_with iterates over the tree passing each node into the block it
gets called with.
-> $node {
when AST::Method { ... }
}
a single argument callback function. Yeah, I could have used
{
given $^node {
when AST::Method {...}
}
}
But I liked the C<-> $node {...}> notation better in this case. And
then the callback decorates every method defined at the top level of
the block with a category attribute. So, I know I'm stretching on the
AST thing, but we're not far off being able to do this sort of thing
right now with B::Optimize and B::Utils.
> : Actually, my naming choices were rather worse, I originally suggested
> : 'optree', but the optree is really too low level for a lot of things.
> :
> : # Which leads to thoughts of:
> : macro Java(&block is rw) {
> : &block = &block.source.parse_with( Parser::Java )
> : }
> : }
> :
> : (The idea here is that 'macro' would get the block 'earlier' while the
> : raw source is still lying around, and before perl has started to throw
> : syntax errors.)
>
> Hmm, I think most macros with arguments would want to assume the
> arguments to be Perl code, and not delay parsing till the macro
> call. The abstraction of having an argument to the macro that's not
> really there when you call it seems a bit odd. Why return a value
> through the argument? I'd rather look at it as an argumentless
> macro that just happens to harvest additional text from the input
> stream. Then return the block as part of what the macro ordinarily
> returns. Seems cleaner to me.
Good point. However, I'd like to see a mechanism that allows one to
use an entirely different parser a la Inline.
macro Java is raw { ... } # Gets untokenized, unparsed source
macro PerlDialect { ... } # Gets some sort of syntax tree?
> : I am *so* looking forward to Apocalypse 5...
>
> Mmm. You wanna write it for me? :-)
Hell no. I'd volunteer to do tech review, but I'm sure that with
Damian, Dan, Hugo, Jon, Gnat and Co. on your case already you don't
really need another pair of eyes; I'd just slow you down.
> 'Course, all the hard bits will likely be deferred to Apocalypse 18
> or so...
By which time it'll all seem obvious and/or inevitable. One hopes.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Unary dot
Whilst I've been hacking the perl 6 scheme interpreter I've found
myself using code like the following
method get_token( $self: ) {
given $self.get_char {
when !defined { fail IOException: msg=> "EOF" }
when /\s/ { $self.get_token }
when '(' { $the_left_paren }
when ')' { $the_right_paren }
when '"' { $self.read_string }
when /\d/ { $self.read_number($_) }
default { $self.read_identifier($_) }
}
}
Initially, that got written as:
method get_token {
given .get_char {
...
default { # Hang on, how do I call a method on myself now?
}
}
}
The issue here is that, if you ever want to use a topicalizer inside a
method definition, and you're going to want to call a method on
yourself from inside the scope of that topicalizer then you can't
really make use of implicit self references.
And because topicalizers are such a powerful tool (believe me; I don't
think I've written a single 'if' statement anywhere in the scheme
interpreter, it's starting to feel clumsy), you're going to end up
with almost all your method declarations looking like:
method foo($self: ... ) {...}
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
(I'm sure we'll be able to write 'object_name', I'm just hoping that
it'll come as part of the core distribution)
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Bracekets
"Jonathan E. Paton" <[EMAIL PROTECTED]> writes: > but wait, there's more... what does: > > @multi_dim[$a][$b][$c] > > give? Who cares? So long as the intermediate results in @multi_dim.[$a].[$b].[$c] respond to []. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Unary dot
Damian Conway <[EMAIL PROTECTED]> writes:
> Piers asked:
>
>> So, is there any chance that we'll be able to do:
>>
>> class ical {
>> use object_name '$self';
>>
>> method ical {
>> given $self.ology {
>> ... { $self.ish }
>> }
>> }
>> }
>
> Of course, if you're not using explicit parameters, you can always write:
>
> method ical {
> given @_[0].ology {
> ... { @_[0].ish }
> }
> }
>
>
> It would be nice to have a cleaner way to do that, though.
> So I'd like to see something like your pragma. However, I'd
> probably make it more like:
>
> use invocant 'self';
*Much* better name. You see, that's why you're the mad genius and I'm
just the lowly lab assistant. Marthter.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Ex4 smart match question
Damian Conway <[EMAIL PROTECTED]> writes:
> Incidentally, the table of C<=~> comparisons (Table 1) at:
>
> http://dev.perl.org/perl6/apocalypse/4
>
> suggests that hash/hash matching is equivalent to:
>
> match if grep exists $a{$_}, $b.keys
>
> I hope to convince Larry that it would be better if it were equivalent to:
>
> match if any($a.keys) =~ any($b.keys)
That certainly seems more 'smart matchy' (does that make sense?)
> so that each key is recursively C<=~>-matched against each key.
>
> I'd prefer that because if I hope to convince Larry to allow hash
> keys to be any scalar value (not just strings). That way the "keys
> as a set" idiom might actually be usable.
I thought he was already convinced of that one. And even if he's not,
setting up the smart match in the second form means less work when
someone does:
# Like a hash, but with arbitrary keys.
class Dictionary is HASH { ... }
Not that changing =~ would be that much work anyway...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Bracekets
Dan Sugalski <[EMAIL PROTECTED]> writes: > At 2:33 PM +0100 4/7/02, Piers Cawley wrote: >>"Jonathan E. Paton" <[EMAIL PROTECTED]> writes: >>> but wait, there's more... what does: >>> >>> @multi_dim[$a][$b][$c] >>> >>> give? >> >>Who cares? So long as the intermediate results in >>@multi_dim.[$a].[$b].[$c] respond to []. > > Hrm. Will they need to? That could arguably pass a three element key > ($a,$b,$c) to @multi_dim which, conveniently being a three-dimensional > array, returns a value itself. Oh ghod. I'm getting confused now. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Bracekets
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Mon, 2002-04-08 at 13:01, Jonathan E. Paton wrote:
>
>> I'm I beating this point to death, or do I have to write
>> the RPC:
>>
>> "Keep the {} and [] notation for hashes and arrays"
>>
>> or
>>
>> "Save our array!"
>
> Let's boil this RFC down to one short phrase:
>
> If {} goes away in Perl6, then everything you've heard about Perl6 being
> "not really all that different from Perl5" is either a lie or a damned
> lie. People keep saying "it's just Perl5, but instead of syntax X, you
> now use syntax Y". Well, as both X and Y lists grow longer
>
> I know this is harsh, but really folks, you're pulling Perl apart
> looking at a half-dozen good features and building a new language around
> them. I don't fault you for this (it's a great way to come up with a new
> language), but I'm beginning to get the feeling that going from Perl5 to
> Perl6 is going to be almost the same level of effort as going from
> Pascal to ANSI C!
>
> Also, just wondering:
>
> $_[_][EMAIL PROTECTED] _=_0_-_
>
> does that work the way I expect it to?
Dunno, what do you expect it to do?. To my way of thinking there's
going to be a syntax error at the third '_'. But I'm not entirely
certain of that.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Bracekets
"Mark J. Reed" <[EMAIL PROTECTED]> writes: > On Mon, Apr 08, 2002 at 07:56:11PM +0100, Piers Cawley wrote: >> > Also, just wondering: >> > >> >$_[_][EMAIL PROTECTED] _=_0_-_ >> > >> > does that work the way I expect it to? >> >> Dunno, what do you expect it to do?. To my way of thinking there's >> going to be a syntax error at the third '_'. But I'm not entirely >> certain of that. > To me, the third '_' seems like it'd be an unambiguous case of the concatenation > operator. I still can't parse it, however; it looks like an attempt to > modify a non-lvalue: > > $_.[_()] _ @_._() _= _0_() - _() > > That is: > 1. Invoke the subroutine _ (name resolved in current scope) > 2. Dereference the variable $_, yielding an array reference. > 3. Retrieve the element of the referenced array whose index is >the result of step 1. > 4. Invoke the method _ on the array @_. > 5. Concatenate the results of steps 3 and 4 > 6. Invoke the subroutine _0_ > 7. Invoke the _ again (or retrieve the cached result from step 1) > 8. Subtract #7 from #6 > 9. Append the result of step 8 to contents of the lvalue >which is the result of step 5. > > This is where my interpretation fails because the result of step 5 > is not an lvalue. How do you know that? '_' could be a method on its LHS that returns and object that responds to _=. But generally, I think it's weird. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Unary dot
Me <[EMAIL PROTECTED]> writes:
>> But suppose you want all .foo to refer to self and not
>> to the current topic.
>
> What about
>
> given (self) { }
>
> Also, what about
>
> use invocant;
>
> resulting in all method bodies in scope getting an implied
> surrounding given (self) { }.
>
> And what about 'me' or 'i' instead of 'self'?
Keep up at the back.
use invocant 'me';
> PS. Please don't flame me, my assistant wrote this.
Whereth hith lithp?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Bracekets
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> On Tue, Apr 09, 2002 at 04:17:38PM +0100, Simon Cozens wrote:
>> Aaron Sherman:
>> >nice du -a | sort -n | tail -300 | tac | perl -nle '
>> >die "Require non-zero disk size!\n" unless $ENV{DF};
>> >if ($. == 1) {
>> >$total = $_ + 0;
>> >next;
>> >}
>> >($size,$rest) = split /\s+/, $_, 2;
>> >if ($rest =~ /^\.\/([\w.\-]+)\//) {
>> >next if $count{$1}++ >= 3;
>> >}
>> >printf "%5.1f%% %5.1f%% %11s %s\n", $size/$ENV{DF}*100,
>> >$size/$total*100, $size, $rest;' |\
>> >head -100
>>
>> This doesn't change at all.
>
> Well, it does but only slightly. $ENV{DF} becomes %ENV{DF} and
> $count{$1} becomes %count{$1} and I'm not sure, but I think that $. is
> changing it's name to something else. Everything else looks like it
> stays the same though.
I think $count{$1} will still work. $count will just be autovivified
as a hashref.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Bracekets
Simon Cozens <[EMAIL PROTECTED]> writes:
> Piers Cawley:
>> Well, no. Because Perl 6 is specified as behaving like perl 5 until
>> told different. Which means that the first translation you give would
>> be a syntax error.
>
> Ouch. Guess I need to go reread A1. Anyway, that makes it easier -
> then there needs to be no translation.
>
> Eh, doesn't that mean Damian's TPJ article is misleading?
Well, there's still going to be a desire to 'upgrade' to perl6
capabilities for scripts that need to be maintained. You do that by
sticking a C at the top and by fixing the syntax
errors. Which should be easy.
Then you get to refactor to more Perl6ish idioms if you want to.
>> If the second one were to become perl6ish, then you'd have to replace
>> $ENV{...} with %ENV{...} and $. might become $*STDIN.recordnum or
>> something.
>
> Oops.
Ah well. All the sorts of things that a convertor will likely be able
to catch.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Unary dot
Larry Wall <[EMAIL PROTECTED]> writes:
> Me writes:
> : > But suppose you want all .foo to refer to self and not
> : > to the current topic.
> :
> : What about
> :
> : given (self) { }
>
> That wouldn't have the same effect as what we're talking about--it'd be
> overruled by any C within. We're talking about how to make .foo
> mean self.foo regardless of the current topic.
Are we? I was looking for a way to unambgiously access the current
object in such a way that topicalizers would still work, eg:
use invocant 'it';
method foo($bar) {
given .wibble($bar) {
when .method { it.do_it(.attrib) }
}
}
(I'm assuming here that, in a method, $bar is *not* the same as @_[0],
which one would declare using C). In the
above chunk of code it'd be really nice if .method and .attrib were
called on the results of .wibble($bar) (which was called on the
current object), whilst 'it' unambiguously refers to the current
object.
The C syntax is just a suggestion (and a way of
dodging arguments about whether to call the object
self/this/that/it/whatever because the programmer can cleave to his
own taste.
> : And "use me;" instead of "use invocant;"?
>
> And here "me" is referring to something that doesn't even necessarily
> exist at the time of the declaration. Who is "me" at this point?
Can I propose an 'abuse' builtin? Then one could say: C, which has to be good for poetry if nothing else.
> In any event, I'm inclined to think that this whole "selfish" notion
> of the object is a bit of a misnomer. We are a programmer. We are
> not an object. We use "my" on lexical declarations because it's my
> piece of code. Some of that code just happens to deal with objects,
> but objects are "them" more than they're "us". C++ probably has the
> more accurate idea here with "this", but maybe we've finally found a
> good place for the occasionally proposed "it":
>
> it.foo(1);
>
> or even better:
>
> close it;
>
> On the other hand, "it" doesn't interpolate too well. And $_ is
> still pronounced "it"...
Personally, I like the 'self' notation; it encourages the programmer
to think the 'right way around'. 'it' encourages one to think of
objects doing things to objects, 'self' encourages to think of objects
taking responsibility for their own data and asking other objects to
do things for it. Hrm... I think I might need to think about that some
more.
>
> But think of the commercial possibilities if your program starts out:
>
> just use it;
>
> Though I do wonder what
>
> use it or lose it;
>
> would mean...
You are a *bad* man Mister Wall.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
I'll show you mine...
Okay, this is the beginnings of Scheme in Perl6. I'm sure there's
stuff I'm getting wrong. I've not written the parser yet for instance
and I'm toying with waiting for A5 before I do. Also, I've not yet
implemented such important stuff as proper closures/lambda or the
environment chain, but the underpinning structure is there.
I'm also deeply uncertain about the workings of overloading and of
operator declaration so those bits are probably wrong.
---SNIP---
module SchemeInterpreter;
class SchemeExpr {
use overload
'""' => 'raw_string',
'0+' => 'to_number',
fallback => 1
;
my SchemeExpr $.value;
method new($proto: $val) {
my $s = $proto.SUPER::new but true;
$s.set_value( $val );
$s;
}
method value { $.value }
method set_value($s: SchemeExpr $val) { $.value = $val; $s }
method raw_string { "$.value" }
method display_string { .raw_string }
method evaluate($s: $context) { $s }
method AUTOLOAD {
my($method) = ($AUTOLOAD =~ m/.*::(.*)/);
my $self = shift;
$self."NEXT::$method"(*@_) unless $method =~ /^is_/;
return;
}
}
class SchemeBoolean is SchemeExpr {
my($t, $f);
method new($proto: $val) {
given $val {
when '#t' { $t //= $proto.SUPER::new($val) }
when '#f' { $f //= $proto.SUPER::new($val) but false }
default { $proto.new( $val ?? '#t' :: '#f' ) }
}
}
method is_boolean { 1 }
}
class SchemeNumber is SchemeExpr {
my sub apply($self: $target, $rhs, &block) {
if $is_rhs { $self.new(+ &block( $target, $self.value )) }
else { $self.new(+ &block( $self.value, $target )) }
}
method operator:+ { apply(*@_, {$^a + $^b}) }
method operator:* { apply(*@_, {$^a * $^b}) }
method operator:- { apply(*@_, {$^a * $^b}) }
method operator:/ { apply(*@_, {$^a * $^b}) }
method is_number { 1 }
}
class SchemePair is SchemeExpr {
my $nil //= class is SchemeExpr {
method is_nil {1}
method car { fail Exception:
msg => "car: expects argument of type , given ()" }
method cdr { fail Exception:
msg => "cdr: expects argument of type , given ()" }
}.new('()');
method new($proto: PAIR $val) { $proto.SUPER::new($val) }
method cons($proto: SchemeExpr $car, SchemeExpr $cdr) {
$proto.new( $car => $cdr )
}
method car { .value.key }
method cdr { .value.value }
method is_pair { 1 }
method as_array($s:) {
my @ary;
my $l = .cons($nil, $s);
while ($.is_pair) {
push @ary, $l.car;
$l = $l.cdr;
}
push @ary, $l;
return @ary;
}
method raw_string {
my @ary = .as_array;
if @ary[-1].is_nil { @ary.pop; "(@ary)" }
else { my $last = @ary.pop; "(@ary . $last)" }
}
method evaluate($self: $context) {
$context.eval_list($self)
}
method length($self:) {
my @ary = $self.as_array;
unless @ary[-1].is_nil {
fail Exception:
msg => "length: expects argument of type ; given $self";
@ary.length - 1;
}
method AUTOLOAD {
.NEXT::AUTOLOAD unless $AUTOLOAD =~ /:?c([ad]+)r$/;
my @ops = reverse split '', $1;
my $val = $_[0];
for @ops -> $type {
$val = $val."c${type}r";
}
return $val;
}
}
class SchemeSymbol is SchemeExpr {
my %symcache;
method new($name) {
%symcache{"$name"} //= .SUPER::new("$name");
}
method is_symbol { 1 };
method evaluate($self: $context) {
$context.eval_symbol($self);
}
}
class SchemePrimitive is SchemeExpr {
method new($proto: PAIR $val) {
$proto.SUPER::new($val)
}
method is_primitive { 1 };
method raw_string { "#" }
method apply($self: SchemeExpr $expr, $context) {
$self.value.value($expr, $context)
}
}
class SchemeEnvironment is HASH {
my $the_null_envt = class {
method exists { }
method bind { fail "You can't bind anything in the null environment" }
method set { fail "You can't set anything in the null environment" }
method get($symbol) { fail "reference to undefined identifier: $symbol" }
}.new;
method init {
.{__parent__} //= $the_null_envt;
method new_scope($self:) { ref($self).new(__parent__ => $self) }
method bind_primitive($name, &func) {
.bind(SchemeSymbol.new($name),
SchemePrimitive.new( $name => &func ));
}
my method parent { .{__parent__} }
method set($self: SchemeSymbol $key, SchemeExpr $value) {
given .exists($key) {
when defined { .value($value) }
default { fail "cannot set undefined identifier: $key" }
}
return $self;
}
method bind($self: SchemeSymbol $key, SchemeExpr $val) {
.{$key} = $value;
return $self;
}
}
class MathEvaluator {
method evaluate($self: SchemeExpr $expr) {
$expr.evaluate($self);
}
method eval_list($self: SchemePair $list) {
my($op, $a, $b, @rem) = $list.as_array;
fail Exception:
msg => "Malformed expression $list. Expect ( )"
if @rem.length;
$a.evaluate($self); $b.evaluate($self);
giv
Re: I'll show you mine...
In message <[EMAIL PROTECTED]>, I wrote: > [ A huge wodge of possible perl 6 code ] I'm getting that Warnock's Dilemma feeling here... Did I stun you all into silence? -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: I'll show you mine...
Aaron Sherman <[EMAIL PROTECTED]> writes: > On Wed, 2002-04-10 at 10:03, Piers Cawley wrote: >> In message <[EMAIL PROTECTED]>, I wrote: >> > [ A huge wodge of possible perl 6 code ] >> >> I'm getting that Warnock's Dilemma feeling here... Did I stun you >> all into silence? > > On my clock, your original message arrived at 04:23, and your > followup at 10:03. On the west coast of the US, that would be 01:23 > to 07:03. That's probably the time you're least likely to get > responses. Ah yes. Timezones. But I confess I was hoping for a reaction from any European contingent. > Personally, I'm a little stunned. I wish I could load it into a > debuggger ;-) Me too. I'm *sure* it's full of mistakes 'cos wetware sucks for this sort of thing. But it was fun to write. > Your idea at the end of regugitating the code back out as Parrot or Perl > is just slightly stunning on its own. I thought that was the easy bit. The compiler just (for appropriate values of 'just' of course) walks the syntax tree and uses an appropriate code generator to output appropriate source, which is what compilers have been doing since the year dot surely. > Still digesting Patches welcome. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: I'll show you mine...
Melvin Smith <[EMAIL PROTECTED]> writes:
> At 09:23 AM 4/10/2002 +0100, Piers Cawley wrote:
>>Okay, this is the beginnings of Scheme in Perl6. I'm sure there's
>>stuff I'm getting wrong. I've not written the parser yet for instance
>
> Very nice! Quite a sample, maybe Larry/Damian can use this
> in one of the next $(A,E)'s
>
>
>> my SchemeExpr $.value;
>
> I haven't been keeping up in the back, I've a wedding bearing down on me.
>
> What is the significance of the . in the declaration?
class Class {
my $class_variable;
my $.instance_variable;
...
}
Easy eh?
> I think I paid attention enough to know a little about the unary dot
> but I'm still confused. We are able to use .foo to mean self.foo,
> but I would assume foo would be declared with my Foo $foo, not my
> Foo $.foo ?
>
>> method car { .value.key }
>> method cdr { .value.value }
>
> Maybe its the C++ in me but why the use of the unary . inside methods
> of the current class who's scope includes C already?
Consider
class SpecializedPair is SchemePair {
method value {...}
}
If you've written 'cdr' without the unary . it will attempt to
dispatch to a *subroutine* in the same context, ie
SchemePair::value. Even assuming that we play nice and allow confusion
between methods and subroutines (which I'm personally not keen on),
it's still apparent that, in the case of a SpecializedPair, car and
cdr would use the wrong &value.
> Isn't this like using C in C++ from inside a non-static method?
Don't ask me. I know nothing about C++ -- Objective C (Looong ago),
Perl 5, Smalltalk and Ruby for me.
> I'll await your ruler on my knuckles, but overall; very impressed
> here.
Thanks. Wait for the next version though, I'm busy implementing
lexical scopes at the moment.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Unary dot
Melvin Smith <[EMAIL PROTECTED]> writes:
> At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
>>"Mark J. Reed" wrote:
>> >
>> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
>> > > method m1
>> > > {
>> > >m2; # calls method m2 in the same class
>> > Yes, but does it call it as an instance method on the current invocant
>> > or as a class method with no invocant? If the former, how would you
>> > do the latter?
>>
>>Should both be allowed to exist? Do both exist? Why do both exist?
>>(with the same name). If only one exists, then that would be the one
>>that gets called.
>
> I'd hope it would assume "instance" method until told otherwise,
> since static methods (class methods) are seldom used in OOP.
Um... don't you use factory methods? I know I do.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Unary dot
Graham Barr <[EMAIL PROTECTED]> writes:
> On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
>> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
>> > method m1
>> > {
>> >m2; # calls method m2 in the same class
>> Yes, but does it call it as an instance method on the current invocant
>> or as a class method with no invocant? If the former, how would you
>> do the latter?
>
> This may be a case of keep up at the back, but if that is a method call,
> how do I call a subroutine from within a method ?
And anyone who says "You don't" will receive a good hard talking to
from me. Being able to declare private subroutines within classes is
really useful, witness:
class SchemeNumber is SchemeExpr {
my sub apply($self: $target, $rhs, &block) {
if $is_rhs { $self.new(+ &block( $target, $self.value )) }
else { $self.new(+ &block( $self.value, $target )) }
}
method operator:+ { apply(*@_, {$^a + $^b}) }
method operator:* { apply(*@_, {$^a * $^b}) }
method operator:- { apply(*@_, {$^a * $^b}) }
method operator:/ { apply(*@_, {$^a * $^b}) }
method is_number { 1 }
}
Yes, I know there's several different ways I could do it, but this
approach feels right.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Unary dot
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Graham Barr wrote:
>>
>> On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
>> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
>> > > method m1
>> > > {
>> > >m2; # calls method m2 in the same class
>> > Yes, but does it call it as an instance method on the current invocant
>> > or as a class method with no invocant? If the former, how would you
>> > do the latter?
>>
>> This may be a case of keep up at the back, but if that is a method call,
>> how do I call a subroutine from within a method ?
>
> The same way. If there is a name conflict between subroutine and
> methods, then you qualify the subroutine name...
>
> ::m2; # calls global subroutine main::m2
> main::m2; # calls global subroutine main::m2
This is looking more and more horrible Glenn.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: none
Ashley Winters <[EMAIL PROTECTED]> writes:
>> Patches welcome.
>
> Excellent...
>
> Forgive any formatting errors, I have mail issues.
Thanks, applying. With a few caveats.
> @@ -62,6 +62,7 @@
> class SchemePair is SchemeExpr {
>my $nil //= class is SchemeExpr {
> method is_nil {1}
> +method is_pair {0}
> method car { fail Exception:
> msg => "car: expects argument of type , given
> ()" }
> method cdr { fail Exception:
That change isn't necessary. If you look you'll see that the anonymous
class of which $nil is the only instance is a subclass of SchemeExpr,
not SchemePair.
> @@ -77,12 +78,13 @@
>method car { .value.key }
>method cdr { .value.value }
>method is_pair { 1 }
> + method is_nil { 0 }
SchemeExpr's AUTOLOAD handles that automagically.
>method AUTOLOAD {
> .NEXT::AUTOLOAD unless $AUTOLOAD =~ /:?c([ad]+)r$/;
> -my @ops = reverse split '', $1;
> -my $val = $_[0];
> +my @ops = reverse split '', $1; # $1? Apocalypse 5...
> +my $val = @_[0];
YARGH! I thought I'd got rid of all those 5isms.
>
>method new_scope($self:) { ref($self).new(__parent__ => $self) }
>
> - method bind_primitive($name, &func) {
> -.bind(SchemeSymbol.new($name),
> - SchemePrimitive.new( $name => &func ));
> + method bind_primitive(PAIR @primitives) {
> +for @primitives -> $primitive {
> + .bind(SchemeSymbol.new($primitive.key),
> +SchemePrimitive.new( $primitive ));
Hmm... does that declaration syntax work? I really hope so 'cos it's
lovely.
>}
>
>my method parent { .{__parent__} }
>
>method set($self: SchemeSymbol $key, SchemeExpr $value) {
> given .exists($key) {
> - when defined { .value($value) }
> + when defined { .{key} = $value }
D'oh. Should be C<.{$key}> thought.
> - '+' => $expr, $context -> {
> + '+' => -> $expr, $context {
Oops. C *@_ }> anyone?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Unary dot
"Mark J. Reed" <[EMAIL PROTECTED]> writes: > On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: >> > ::m2; # calls global subroutine main::m2 >> > main::m2; # calls global subroutine main::m2 >> >> This is looking more and more horrible Glenn. > I think we need to back off of unmarked subroutines becoming a method > call. That one extra '.' in front isn't too much, is it? > > I like the following, assumed to be within method m1: > > ..m2(); # call m2 the same way m1 was called, instance or class Can't say I'm keen on that at all. We already have a '..' operator (admittedly it's binary), and this new, unary .. doesn't really do anything remotely similar (cf unary dot, unary _ and unary +, which have behaviours which are obviously related to the binary forms.). And haven't we done this discussion already? -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Unary dot
"David Whipp" <[EMAIL PROTECTED]> writes: > Piers Cawley >> > This may be a case of keep up at the back, but if that is a >> method call, >> > how do I call a subroutine from within a method ? >> >> [...] >> >> Yes, I know there's several different ways I could do it, but this >> approach feels right. > > I think this comes does to huffmann encoding: which things are > common, and which are less common. This probably depends on > what you are doing (what paradigm you are following), so its > really a question about the nature of perl. > > The things I've heard people wanting to do are: > > call method on current topic > call method on current invocant > call class method on invocant's class > call private subroutine defined in current class > call global subroutine > > The following syntaxes have been seen: > > foo() > .foo() > ..foo() ## rejected because ".." is different binary op > class.foo() > FooClass.foo() > ::foo() > Package::foo() > $foo() > $_.foo() > > I see 2 partionings: > > * by scope: topic, self, named package, global > * by invocant: instance, class, none > > My suggested resolutions: > > By Scope: global/ named package use the existing > Foo::bar syntax; Topic uses unary . syntax; self > uses nothing > > By invocant: infer from current invocant/topic; use > &foo() for no invocant > > Thus, the perl5 transalations would be: > > foo() => $self->foo() > .foo() => $_->foo() > &foo() => foo() > ::foo() => ::foo() > Bar::bar() => Bar::bar() > > class.foo() => ref($self)->foo() > .class.foo() => ref($_)->foo() > > &foo(self) => foo($self->self) > => $self->self->foo() > > This assumes that C and C are defined in > UNIVERSAL For reasons that I can't quite put my finger on at the moment, I really, really don't like that approach. One of the really nice things about perl 4 was that we didn't have to use & any more. Making it essential seems like a horribly retrograde step. I suppose you could require the & only when calling subroutines from within a method/class definitions, but I still don't like it. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Unary dot
Damian Conway <[EMAIL PROTECTED]> writes: [...] > Reflecting on this, it seems that it would be useful if methods > implicitly did their default topicalization-of-invocant like so: > > -> $self > > rather than just: > > -> $_ > > That is, that as well as aliasing the invocant to $_, they also alias it > to some standard variable name. > > Then one would be guaranteed an invariant name (across all OO Perl!) > for the invocant, even under internal topicalizations. > > Of course, the problem is then: what should the name of this topicalizer > variable be? The main options are: > > $self > $me > $I > $this > $invocant > $object > $obj > > And frankly, that's a very minor issue. Someone (i.e. Larry) should just > pick one and then we can all move on. Nailing my colours to the mast here, I choose '$self'. I will confess to suggesting the C syntax not because I thought it was a desperately good idea, but because I didn't want to get into arguing about what colour to paint the bikeshed before we'd actually decided whether or not to build the bikeshed in the first place. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Unary dot
Luke Palmer <[EMAIL PROTECTED]> writes: >> > $.foo >> >> It's already defined as an instance variable. > > I don't think I like that. Instance variables are far more common that > class variables, so why not just $foo, and you could use a compile-time > property for class variables. Like C as discussed. That or > C. I think the latter makes more sense. Ah, but I think the mnemonic value of the '.' more than earns its keep here. C is doing a slightly different job anyway. And instance variables are *not* the same as 'normal' variables, they hang off a different symbol table (or syte, to use Damian's oh so clever term from Perl 5+i) and I'm all for things that are different *looking* different. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Defaulting params
"Miko O'Sullivan" <[EMAIL PROTECTED]> writes:
> The current plans indicate that a subroutine's params should be defaulted
> like this:
>
>sub load_data ($filename ; $version / /= 1) {...}
>
> (The space between / and / is on purpose, my emailer has problems if
> they are together.) If that's the technique, how does the caller
> indicate that the second param is *supposed* to be undef? If I were
> to call a sub like this:
>
> load_data ($filename, undef);
>
> then I would expect that means that I am explicitly saying the
> second argument is supposed to be undef. However, if I call it like
> this:
>
> load_data ($filename);
>
> then I'm not sending the second param and it can be whatever the
> default is. Ergo, I propose that / /= and simply = are both allowed
> and mean slightly different things:
>
># $version is 1 if the second param isn't sent at all
>sub load_data ($filename ; $version = 1) {...}
>
># $version is 1 if the second param is undef
>sub load_data ($filename ; $version / /= 1) {...}
>
> (Yes, this is a repeat of an earlier suggestion. It was suggested I might
> repost reworded.)
I think you're right that this is a valid distinction, I'm just not
sure if it's not a little too subtle and that the two different
notations won't cause confusion. I *think* that the //= case is going
to be the more common one, and one could always handle the first case
more explicitly by doing:
sub load_data ($filename; $version) {
$version = 1 if @_.length < 2;
...
}
Yes, it is undoubtedly uglier, but I don't think it's a common enough
case that that worries me.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Defaulting params
Damian Conway <[EMAIL PROTECTED]> writes:
> Piers wrote:
>
>> one could always handle the first case
>> more explicitly by doing:
>>
>>sub load_data ($filename; $version) {
>> $version = 1 if @_.length < 2;
>> ...
>>}
>
> Err...no. If you specify named parameters, you don't get @_.
>
> It could be handled by overloading though:
>
> sub load_data ($filename) { load_data($filename, 1) }
>
> sub load_data ($filename, $version) {...}
Ooh. Multiple dispatch is definitely in then? Did I miss something?
But *great*.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Defaulting params
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Thu, 2002-04-11 at 00:47, Damian Conway wrote:
>
>> sub load_data ($filename) { load_data($filename, 1) }
>>
>> sub load_data ($filename, $version) {...}
>
> Interesting. This brings goto to mind. Above, I could just assume
> that inlining will happen, but what about goto? Obviously:
>
> sub load_data($filename) { goto &load_data }
>
> would be ambiguous, and would throw away the (now lexical)
> $filename.
>
> I can't see any way to usefully preserve the old new meaning of
> goto. Is this a good thing?
If we're getting continuations then, where we're going we won't need
goto.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: How to default? (was Unary dot)
Trey Harris <[EMAIL PROTECTED]> writes:
> I think I've missed something, even after poring over the archives for
> some hours looking for the answer. How does one write defaulting
> subroutines a la builtins like print() and chomp()? Assume the code:
>
> for <> {
> printRec;
> }
> printRec "Done!";
>
> sub printRec {
> chomp;
> print ":$_:\n";
> }
You could take advantage of subroutine signatures and multi-dispatch
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print ":$rec:\n" } # 1 arg
Assuming we *get* multidispatch that is. It would be nice to hope that
the compiler could optimize that...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Fisher-Yates shuffle
[EMAIL PROTECTED] writes:
> As for "cleanness", this is my interpretation of how perl6 is going
> to work:
>
> %foo = ();
> if %foo {"key"} {print "Hello 1"}
>
> %foo = ();
> if %foo{"key"} {print "Hello 2"}
>
> %foo = ();
> if %foo{"key"}{print "Hello 3"}
>
> Case 1 will print "Hello 1"; this is a block after the if statement.
No, it will be a syntax error. The first closing brace does not end
the statement, probably something like "Block seen when keyword
expected".
> Case 2 will not print anything. The print is in the 'then' part
>of the if.
Correct.
> Case 3 will be a syntax error - an if statement with a condition,
>but not block.
It won't be a syntax error *yet*. If there's a block immediately
following then that will be treated as the 'then' block. If it's the
end of file, or a nonblock, then it'll be a syntax error.
> You call this **CLEAN**? Not even in Python can a space influence
> control flow that significantly. (In fact, in Python, Java, C, Pascal,
> awk, and perl5, whitespace between an aggregates names and its index is
> optional. Not mandatory, not forbidden, no, optional).
I confess that it's not my favourite feature. But I wouldn't go so far
as to say it wasn't clean. 'Different', certainly.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Fisher-Yates shuffle
[EMAIL PROTECTED] writes:
> On Fri, Apr 12, 2002 at 04:00:37PM +0100, Piers Cawley wrote:
>>
>> [EMAIL PROTECTED] writes:
>> > As for "cleanness", this is my interpretation of how perl6 is going
>> > to work:
>> >
>> > %foo = ();
>> > if %foo {"key"} {print "Hello 1"}
>> >
>> > %foo = ();
>> > if %foo{"key"} {print "Hello 2"}
>> >
>> > %foo = ();
>> > if %foo{"key"}{print "Hello 3"}
>> >
>> > Case 1 will print "Hello 1"; this is a block after the if statement.
>>
>> No, it will be a syntax error. The first closing brace does not end
>> the statement, probably something like "Block seen when keyword
>> expected".
>
> Now I am confused. In perl6, we can leave off the the parenthesis
> around a condition, and I hope that it isn't required to have
> an 'elsif' or 'else' block.
>
> Why isn't
>
> if %foo {"key"} {print "Hello 1"}
>
> equivalent with the perl5 syntax:
>
> if (%foo) {"key"} {print "Hello 1"}
>
> Which keyword is it expecting?
Keyword /els(e|if)/, or end of line, or semicolon. Sorry badly phrased
on my part. The closing brace of {"key"} only ends the statement if it
is followed by /\s*$/, or a semicolon.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Fisher-Yates shuffle
[EMAIL PROTECTED] writes:
> On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
>> [EMAIL PROTECTED] writes:
>> >
>> > Why isn't
>> >
>> > if %foo {"key"} {print "Hello 1"}
>> >
>> > equivalent with the perl5 syntax:
>> >
>> > if (%foo) {"key"} {print "Hello 1"}
>> >
>> > Which keyword is it expecting?
>>
>> Keyword /els(e|if)/, or end of line, or semicolon. Sorry badly phrased
>> on my part. The closing brace of {"key"} only ends the statement if it
>> is followed by /\s*$/, or a semicolon.
>
>
> You've got to be kidding. That makes the whitespace rules even more
> insane; your program can behave quite differently wether there's a
> space, a newline, or nothing between two tokens. Wonderful! People
> who tend to use -e all the time (like me) will love it. (Not!)
> Pasting code into IRC will be so much more fun.
So use a semicolon. Or disambiguate with parentheses. Or try and
convince Larry that he's wrong about this. Or use the perl5 syntax
rules that will be understood by default.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Subroutine variables are like underwear
Damian Conway <[EMAIL PROTECTED]> writes:
> Yes, subroutine variables *are* like underwear.
> But parameter names *aren't* like underwear.
> Because they're not (primarily) subroutine variables.
>
> So they're like the labels on the knobs, dials, and buttons of your
> favourite elctronic device. They're part of the *interface*, not
> (primarily) part of the implementation. They should be chosen with
> care, and not changed on a whim.
There's always the Smalltalk approach:
Dictionary extends Collection
at: key put: anObject
Good Smalltalk style uses the variable names to suggest the variable
type and the 'selector' names to say that they're used for.
In Perl6, it seems that this would be sort of 'turned inside out',
variable names would suggest roles while compiler hints would suggest
(enforce) types.
class Dictionary is Collection {
method insert_at( Object $key, Object $value ) {...}
}
> I do, however, understand the desire to allow them to change, or to
> be somewhat "fuzzy" (i.e. "filename" vs "file_name" vs "file"). And
> I agree that it could be a very useful facility.
>
> But your proposed syntax is...err...less than ideal.
>
> If we were to have this, I'd far rather we use the existing
> mechanism for annotating variables. Namely: properties.
>
> For example:
>
> sub load_data ($filename_tainted is named('filename'),
> $version_input is named('version','ver') //= 1)
>{...}
But down that road lies the likes of Symbol::Parameter::Approx. Which
may, or may not, be a bad thing.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Unary dot
Andy Wardley <[EMAIL PROTECTED]> writes:
> On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
>> So the main reason that objects can function as hashes is so that the
>> user can poke an object into an interface expecting a hash and have it
>> "make sense", to the extent that the object is willing to be viewed like
>> that.
>
> AKA the uniform access principle.
>
> This was something that I was very keen to exploit in the Template Toolkit
> where foo.bar is interpreted as "Do(t) The Right Thing" to access the
> 'bar' part of 'foo', be it the 'bar' key in the 'foo' hash or the 'bar'
> method of the 'foo' object. The result is, of course, that you can use
> a hash of static data one day (great for mocking up web pages for example)
> and later upgrade it to an object which fetches/generates data on demand
> (e.g. from a database) when you put your pages into production.
>
> Alas, I also designed a flaw into the system by introducing "virtual
> methods" that TT automatically applies onto various data types, equivalent
> to various Perl functions, e.g. somehash.keys or somelist.size. As
> convenient as this is, the problem lies in the fact that you can't
> differentiate somehash.keys between the Perl equivalents of C
> or C<$hash->{keys}>.
>
> So my thought for version 3 of TT is to introduce somehash.{keys} as
> a syntax to mean "only the 'keys' key/method of the 'foo' hash/object
> but *NOT* the 'keys' virtual method" and to leave somehash.keys resolving
> to the virtual method as it currently does.
>
> Am I right in thinking that this would then be (roughly) consistent with
> the Perl 6 syntax?
>
> e.g.
>
> TT3 Perl 6 Perl 5 (hash) Perl 5 (obj)
>
> foo.keys $foo.keys keys %$foo $foo->keys()
> foo.{keys} $foo.{keys} $foo->{keys} $foo->keys()
>
> Hang on, now I'm a little confused - I thought that hashes were supposed
> to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
> But then that would then violate the uniform access principle because
> hash/key access has a different syntax from object/method?
$foo = %hash; # Take a reference to %hash;
$foo.{keys} # get the value keyed by 'keys' in the hash refered
# to by $foo.
$bar = Object.new # Make an object
$bar.{keys} # Get the value of $bar's '$.keys' instance
# variable.
I think that the '.' is optional in this case too...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Scary things
Also known as constructs you wish you hadn't discovered.
So, I'm reading through Finkel and I came across the following, which
computes the greatest common divisor of a and b (recast into perl6ish
syntax)
while {
when $a < $b { $b -= $a }
when $b < $a { $a -= $b }
}
The idea is that the loop keeps on looping until none of the guard
conditions match. This can be redone in 'real' Perl 6 as
while 1 {
given 1 {
when $a < $b { $b -= $a }
when $b < $a { $a -= $b }
else { last }
}
}
I'm not sure about the 'break'ing behaviour of a C that isn't in
a C block so I've introduced a 'dummy' one here. Maybe Larry
can clarify.
So, do we want this monstrosity? I confess that I did find myself
using something like it occasionally when I was working on the scheme
evaluator, but it looks very weird indeed.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Hashes, Stringification, Hashing and Strings
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Tue, 2002-04-16 at 14:00, Mike Lambert wrote:
>> Speaking of which, how do we ensure the immutability of keys being put
>> into the hash? I think Perl copied the string, so that:
>>
>> $b = "aa";
>> $a{$b} = 1;
>> chop $b;
>> print $a{"aa"};
>>
>> still works.
>>
>> If we start storing full thingies into the keys of a hash, we either need
>> to make deep copies of these, or copy enough to ensure the hashing
>> function has all that it needs.
>
>
> I thought about this myself, and I don't think Perl would do it that
> way. Please, Larry, et al. correct me if I'm wrong.
>
> I suspect it would involve:
>
> 1. Copying the key (which might be a reference) on insertion.
> 2. Hashing once, and caching the hash.
>
> This means a minimum of overhead, so it's a good thing. It also means
> that the structure of your hash would never need to re-compute if the
> hash of a particular object changes (which I would imagine it could
> easily do in any number of cases).
So you'd have:
%hash{$some_obj} = $aValue;
$some_obj.mutator;
exists %hash{$some_obj} # returns undef.
Somehow I *really* don't think that's going to fly.
Personally I'd like the default hash to return some immutable, unique
and probably opaque object id (something the like
'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but
probably not identical). This isn't going to change as an object's
contents change.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Hashes, Stringification, Hashing and Strings
David Wheeler <[EMAIL PROTECTED]> writes: > On 4/16/02 11:57 AM, "Piers Cawley" <[EMAIL PROTECTED]> claimed: > >> Personally I'd like the default hash to return some immutable, unique >> and probably opaque object id (something the like >> 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but >> probably not identical). This isn't going to change as an object's >> contents change. > > I would agree that such a default would be preferable, as long as I could > overload it with my own idea of what the hash key should be. This will be > useful for database applications, where I could have two separate objects > that loaded the same data from the database, and are therefore "the same > object," even though they wouldn't have the same OID. So I'd want to be able > to say, for hash keys, use a key I define (probably including a primary key > ID from the database). Ah yes. I'm currently doing something like that trick with a home rolled object store. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Regex and Matched Delimiters
Larry Wall <[EMAIL PROTECTED]> writes:
> /^pat$/m /^^pat$$/
$$ is no longer the current PID? Or will we have to call that '${$}'
in a regex?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Regex and Matched Delimiters
"Brent Dax" <[EMAIL PROTECTED]> writes: > Larry Wall: > That's...odd. Is $$ (the variable) going away? > > # /./s// or /<.>/ ??? > > I think that . is too common a metacharacter to be relegated to > this. I think you failed to notice that '/s' on the regex. In general . will still mean . but if you want it to match *anything* including a new line, you have to call it <.>. Personally, I don't have a problem with that. > # space(or \h for "horizontal"?) > > Same thinking as '.'. The golfers aren't going to like it for sure. But most of the time when I'm doing production code I have /x turned on anyway, and in that context, if I want to match a space and only a space, I have to do [ ] anyway. It might be nice if we could have m:X// mean 'space and hash match themselves'. > # \t also > # \n also or (latter matching > logical newline) > # \r also > # \f also > # \a also > # \e also > > I can tell you right now that these are going to screw people up. > They'll try to use these in normal strings and be confused when it > doesn't work. And you probably won't be able to emit a warning, > considering how much CGI Perl munches. But assigning meaning to < and > is going to do that anyway. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Loop controls
Luke Palmer <[EMAIL PROTECTED]> writes:
> On Tue, 30 Apr 2002, Miko O'Sullivan wrote:
>
>> > Damian, now having terrible visions of someone suggesting C ;-)
>>
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
>
> Ooh! Why don't we have a dont command! With several variants:
> dont FILE
> dont BLOCK
>
> dont { print "Boo" }
Hmm... what sort of semantics do you suggest? Just noop the following
block?
sub don't (&) { return }
I really should get 'round to releasing the semi mythical
Acme's::Abbreviations module. Here's a taster. I really hope that it
won't be possible to perpetrate this sort of thing in Perl 6:
package Acme's::Abbreviations;
@ISA = 'Bloody Silly Thing To Do';
our $VERSION = '0.01';
sub can't {
my $target = shift;
if (UNIVERSAL::isa($target, 'UNIVERSAL')) {
return ! $target->can(@_);
} else {
return ! UNIVERSAL::can($target, @_);
}
}
*doesn't = \&can't;
sub isn't {
my $target = shift;
if (UNIVERSAL::isa($target, 'UNIVERSAL')) {
return ! $target->isa(@_);
} else {
return ! UNIVERSAL::isa($target, @_);
}
}
sub won't {
my $target = shift;
my $method = shift;
eval { $target->can't($method) &&
$target->can't('AUTOLOAD') };
}
sub mightn't {
my $target = shift;
my $method = shift;
eval { $target->can't($method) &&
$target->can('AUTOLOAD') };
}
sub mustn't {
my $target = shift;
my $method = shift;
no strict 'refs';
my $old_glob = \ $ {"${target}::"}{$method};
delete $ {"${target}::"}{$method};
*{"$target\::$method"} = *{$old_glob}{$_} for (qw/ SCALAR HASH ARRAY IO /);
1;
}
# Preloaded methods go here.
1;
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
What does this do?
Consider the following.
sub foo {...}
foo *@ary;
foo * @ary;
Is this another place where whitespace will have meaning? Or should I
add parentheses to disambiguate? Enquiring minds want to know.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: What does this do?
Larry Wall <[EMAIL PROTECTED]> writes:
> Piers Cawley writes:
> : Consider the following.
> :
> :sub foo {...}
> :
> :foo *@ary;
> :foo * @ary;
> :
> : Is this another place where whitespace will have meaning? Or should I
> : add parentheses to disambiguate? Enquiring minds want to know.
>
> I see no ambiguity. It's a unary * in either case. You'd have to
> declare it
>
> sub foo () {...}
>
> to get a multiply out of it.
Good oh.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Accessor methods ?
Damian Conway <[EMAIL PROTECTED]> writes:
> Aaron Sherman wrote:
>
>> > What if I want my methods to be called C<.get_bar()> and C<.set_bar()>,
>> > since a certain Perl OO specialist suggests this approach is best for
>> > avoiding ambiguity in one's API?
>>
>> Then you can declare them as such:
>>
>> sub get_bar() { .bar }
>> sub get_baz() { .baz }
>> sub set_baz($newbaz) { .baz = $newbaz }
>
>
> Close. They'd probably be implemented like this:
>
> method get_bar() { $.bar }
> method get_baz() { $.baz }
> method set_baz($newbaz) { $.baz = $newbaz }
>
> Of course, there would need to be some way of simultaneously preventing the
> automagic creation of accessors. That might be manual:
>
> class Foo {
> my $.bar;
> my $.baz;
>
> method bar is private {}
> method baz is private {}
> ...
> }
>
> or per-attribute:
>
> class Foo {
> my $.bar is accessorless;
> my $.baz is accessorless;
> ...
> }
>
> or (my favorite) global:
>
> class Foo {
> no accessors;
>
> my $.bar;
> my $.baz;
> ...
> }
I've recently come to the conclusion that I like my get/set methods to
look like:
method foo() { $.foo }
method set_foo($self: $new_foo) { $.foo = $new_foo; $self }
(Perl6 syntax obviously). I hope it's going to be possible to set that
up automagically... (Yeah, I know, if/when Perl 6 gets macros...)
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Loop controls
"Miko O'Sullivan" <[EMAIL PROTECTED]> writes:
> From: "Damian Conway" <[EMAIL PROTECTED]>
>> while (my $res = $search->getnext) { ...}
>>
>> has a valid meaning in Perl 6. In fact, it's meaning in Perl 6 is far more
>> reasonable than in Perl 5.
>
> I don't think the new meaning makes sense at all. Essentially it's saying
> "the statement gets run many times but the variable only gets declared
> once". It makes sense to declare a variable many times when it gets a
> fresh, new block for each declaration, like when it's inside a loop, but to
> use it in a statement that is run many times but declares the var only once
> seems like it ought to throw a warning about declaring the same variable in
> the same scope multiple times.
Yeah, but declaration happens at compile time, not runtime so there's
no problem.
Minor syntax quibble, it should in fact be:
while (my $res = $search.getnext) { ... }
Or, for shiny collection modification fun:
while (my $res := $search.getnext) { ... }
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Idea
Luke Palmer <[EMAIL PROTECTED]> writes: >> >The rest of this message assumes that the answer to A is "run time error". >> >> I'm not sure that's correct. Might just be a runtime warning, > > I would assume not. How can we optimize if we just make it a > warning? By only optimizing in the presence of C perhaps? -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: A5: a few simple questions
Allison Randal <[EMAIL PROTECTED]> writes:
> On Thu, Jun 06, 2002 at 10:38:39AM -0400, John Siracusa wrote:
>> On 6/6/02 2:43 AM, Damian Conway wrote:
>> > rule wordlist { (\w+) [ , (\w+) ]* }
>>
>> No semicolon at the end of that line? I've already forgotten the "new
>> rules" for that type of thing... :)
>
> No, because rules are basically methods, just like grammars are
> basically classes. You would only need a semi-colon if you were defining
> an anonymous C (similar to an anonymous C):
>
> my $wordlist = rule { (\w+) [ , (\w+) ]* };
You wouldn't even need it then. Assuming you're following the closing
brace with nothing but white space and a newline.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Apoc 5 questions/comments
Andy Wardley <[EMAIL PROTECTED]> writes: > On Sat, Jun 08, 2002 at 06:51:19AM +1000, Damian Conway wrote: >> I have no doubt that, once Perl 6 is available, we'll see a rash of >> modules released in the Grammar:: namespace. Including >> Grammar::HTML and Grammar::XML. > > I have no doubt that, once Perl 6 is available, we'll see a rash of > modules released in the Grammar:: namespace. Including > Grammar::Romana, Grammar::Klingon, Grammar::Buffy, Grammer::Mispelt, > and others... :-) I'm sure Mister Cross is already planning Grammar::Approx to go with the rest... -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Perl 6 summary for the week ending 23rd June 2002
=head1 This week on Perl 6 (17-23 June 2002) by Piers Cawley, 020020624 =head2 Notes It's been a while since the last Perl 6 digest and summarizing everything that's happened since then would take, ooh, a while. So I've punted on that, and just pretended that the last one was published this time last week. (Well sort of, sometimes I'll refer back to earlier posts in threads that continued this week.) =head2 More 6PAN musings: local namespaces John Siracusa Lhttp:[EMAIL PROTECTED]/msg10140.html> a bunch of questions about the naming of local modules in Perl6, pointing us at java's style of uk.org.bofh.html.template, which makes sure that one organizations templating system won't clash with that of another. Various schema were proposed, then Larry Lhttp:[EMAIL PROTECTED]/msg10162.html> and told us that there'd be more than one way to do it, along with a way of aliasing names to avoid RSI. Aaron Sherman warned us away from reinventing X.whatever it was addressing. After some discussion about the merits of long, guaranteed unique module names versus a standardized module naming schema, Webb Sprague Lhttp:[EMAIL PROTECTED]/msg10152.html> a CPAN "Curation Project" be formed. The idea being that there'd be the more or less unstructured seething mass of CPAN, and then there'd be a group of "highly managed, by real people" modules that were promoted from that pool to an "Extended Perl Library". Which led to a discussion about where you'd find the "real people" and a certain amount of silliness about acronyms. Favourite quote of the thread: Lhttp:[EMAIL PROTECTED]/msg10149.html> =head2 Regexes and untainting Miko Lhttp:[EMAIL PROTECTED]/msg10166.html> that, by default regexes shouldn't untaint, and proposed a 'safer' mechanism for managing taintedness. Jonathan Paton Lhttp:[EMAIL PROTECTED]/msg10167.html> that some of this is already possible in Perl 5. He also came up with the idea of marking different rules as untaint safe or unsafe when they are defined. =head2 what's new In an effort to understand the state of Perl 6, raptor Lhttp:[EMAIL PROTECTED]/msg10155.html> a really good summary of some of the changes from Perl 5 to Perl 6 asking if he'd got the right end of the stick. Damian Lhttp:[EMAIL PROTECTED]/msg10168.html> a few things and generally confirmed that the stick was correctly oriented. =head2 Meanwhile... over in perl6-internals =head2 latest Parrot Luke Palmer Lhttp:[EMAIL PROTECTED]/msg10573.html> why the latest ChangeLog entry was from March 19, and was the Parrot he'd just got from CVS really the latest version. Dan explained that it was, but that the ChangeLog wasn't being kept up to date 'for some reason', which triggered a small amount of kvetching about CVS. Robert Spier (sensible chap) Lhttp:[EMAIL PROTECTED]/msg10577.html> that all non trivial patches should contain a 'human readable' changelog entry along with the patch and at least one test. Ask agreed. And so do I. =head2 Perl6 grammar Melvin Smith posted a Lhttp:[EMAIL PROTECTED]/msg10561.html> towards being able to parse Perl 6. Jerome Vuillon pointed us at the beginnings of a Lhttp://www.pps.jussieu.fr/~vouillon/parrot/parser.y> that he was putting together using yacc, and Sean O'Rourke Lhttp:[EMAIL PROTECTED]/msg10598.html> his Parse::RecDescent based grammar sketch. And there was much rejoicing. =head2 Irrational fear of macros Melvin Smith Lhttp:[EMAIL PROTECTED]/msg10567.html> a joke in the perl 5 source about the sheer number of macros in the perl 5 source. Which provoked a variety of serious responses. Dave Goerhrig Lhttp:[EMAIL PROTECTED]/msg10581.html> that macros weren't inherently bad, but having hordes of them wasn't necessarily good, and his sig quote: qw/ who is praying for parrot to support XS code, cause he doesn't want to rewrite SDL_perl's 11,000 lines /; provoked a Lhttp:[EMAIL PROTECTED]/msg10662.html> from Tim Bunce proposing a 'wrapper that manages a simple perl5-like run-time environment'. Tim's .sig (Tim [who doesn't want to rewrite the DBI's ~4000 lines or tell the many DBD authors that they have to rewrite their drivers].) gave us a clue as to his motivation in wanting this too... The 'Irrational fear of macros' thread proper was Lhttp:[EMAIL PROTECTED]/msg10582.html> by that man Dave Goehrig as he launched a defence of macros, pointing out that "Perl 5's problem with macros ... is that too many of them remain largely undocumented, under-utilized, or over-exposed." He argued for "a dictionary, a work to explain the usage of each element of the API. Parrot needs a rosetta stone, through which future implementors will decipher and re-interpret the decisions made years in the past." Melvin Lhtt
Re: @array = %hash
Uri Guttman <[EMAIL PROTECTED]> writes:
>> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
>
> SC> [EMAIL PROTECTED] (Damian Conway) writes:
> >> > hashes can now take objects as keys and won't just stringify them.
> >>
> >> Correct. But I believe that's only if the hash has a property that marks
> >> its keys as being objects, not strings:
> >>
> >> my %hash is keyed(REF);
> >>
> >> And, even if that's the default, it still oughtn't apply to PAIRs.
>
> SC> So, uhm, what *does* happen if I do
>
> SC> $hash{$pair} = "foo";
>
> SC> Runtime error? And what if I do this:
>
> SC>my %hash is keyed(REF);
> SC>$hash{bless $pair, "NotAPairReally"} = "foo";
> SC>...
> SC>for %hash.kv -> ($k, $v) {
> SC>bless $k, "PAIR";
> SC>}
>
> SC> Storing pairs as hash keys could lead to interestingly funky data
> SC> structures. I'm sad that this is being ruled out.
>
>
> i don't think he said that is ruled out. it is not the default
> behavior. i think if you declared it as keyed(PAIR) it would do what you
> want.
But that implies that *all* the keys will be pairs. Which is
(emphatically) not necessarily the case.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: @array = %hash
David Whipp <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Maybe we should just say 'sod it' and implement the entire Smalltalk
>> Collection hierarchy and have done with it? Sets, bags, hashes
>> (dictionaries for the Smalltalker), whatever, all have their uses...
>
> I'm not sure if you were being facetious,
I wasn't. I'd love to see something akin to the full Smalltalk
collection hierarchy available with Perl. And I'd love to see them
'blessed' into core Perl so people would *use* them. But I'm not sure
it'll actually happen.
> but I do think all the functionality of these should exist: how many
> times do we have to explain, to newbies, the perl idioms for using
> hashes as sets? Collections boil down to two basic properties:
> ordered/unordered and duplicates/unique. We only have c<%> and c<@>
> available for 4 combinations; and perl uses these to indicate the
> underlying implementation (sans ties), and the type of key. Seems to
> me that we will either end up using c<$> (objects) for most
> collections; or we'll be creative in our use of properties for @ and
> %.
%foo is Ordered
@bar is Set
Hmm... I think I'd rather see
my $foo is Bag = @array.as('Bag');
The idea being that one could treat hashes and arrays as syntactic
vitamins meaning 'Dictionary' (to use the Smalltalk term) and
'OrderedCollection', but all Collections would implement an C
method allowing conversion between the different classes.
Hmm... you know, the more I think about that idea, the more I like
it...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Implementing new control structures
This came up in a discussion on London.pm about Damian's Perl 6 talk,
which led us to wonder about control exceptions and how they're
handled. At the moment, control exceptions fall into the 'vaguely
handwavy' category, and what follows is my attempt to work out how I
think they should behave...
Damian Conway <[EMAIL PROTECTED]> writes:
> Lusercop wrote:
>
> > It has to be said that watching someone talk about this is rather easier
> > than trying to follow the exegeses and apocalypses (IMO). Certainly, in
> > the absence of a real, live Perl6 interpreter this is the case.
>
> H. Maybe that makes *me* the real, live Perl 6 interpreter at the moment. ;-)
>
>
> > One thing I am slightly confused about, though, is that if {} now delimits
> > a subroutine, what happens to this bit of code:
>
> The implicit question seemed to be if raw blocks and C blocks
> and C blocks and C blocks, etc. are all really
> closures/subroutines, what happens if they have a C in them?
>
> The answer is that C throws a "control exception". The named control
> structures catch and re-propagate this to the surrounding subroutine. Raw
> blocks do the same thing. So the effect is exactly as in Perl 5: a C
> in a controlled or raw block causes the surrounding subroutine to
> return.
So, when you're writing a looping construct for a class that will be
used like:
method lazy_search ($a_collection, $a_target) {
...
$a_collection.do -> $each {
$each =~ $a_target and return $each;
}
return;
}
ie, where a 'return' inside the arg block should return to the calling
scope, but where a normal 'fell off the end of the block' should just
continue 'round the block. How do we do that? Will there be some
cunning calling convention which will allow us to interrogate the
return value of a try to find out how it was arrived at?
method do ($self : &block) {
for $self.members █
CATCH Control::return { throw }
}
Hang on, that should just work shouldn't it? Just take advantage of
the fact that the current C already has those semantics and it
seems I'll need to think a good deal harder to come up with something
concrete that'd require knowledge of how something got returned.
Thinking about this, I suppose that one could arrange it so that a
C *always* sets $!, either to some error type exception that was
thrown, or to the control exception that escaped the block. If one
then overloaded C<< operator:? >> for control exceptions so that they
were false in a boolean context one could continue to write code like:
try █
if ($!) {...}
and have it work as expected, but still be able to get at the control
exceptions in the (rarer) occasions they were needed.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: @array = %hash
Damian Conway <[EMAIL PROTECTED]> writes:
> Uri Guttman wrote:
>
>> but what simon was saying (and i agree) is the the pair IS a single
>> item. it becomes the key and its value is 'scalars'.
>
> No. If it's a PAIR, then its key is the key and its value is the value.
>
>
>> hashes can now take objects as keys and won't just stringify them.
>
> Correct. But I believe that's only if the hash has a property that marks
> its keys as being objects, not strings:
>
> my %hash is keyed(REF);
>
> And, even if that's the default, it still oughtn't apply to PAIRs.
> To get keys that are PAIRs, you should have to say:
>
> my %hash is keyed(PAIR);
I really hope you're wrong about that last one. Or are you really
proposing that, given C, one can't do
C<%hash{$arbitrary_object} = $value> and get back the 'real'
C<$arbitrary_object> from C<%hash.values>, that seems to run counter
to what's been said about perl6 hashes. Requiring C
seems kludgy, but 'is keyed(PAIR)' for anything but optimization or
'contract' stuff seems Bad And Wrong.
>> @array = ( key => 1, key2 => 3, 4, 5 ) ;
>> %hash = @array ;
>> what does that do? 3 pairs in the hash or 2 (the first pair is the
>> key
>> for the second pair)?
>
> Three. As above. You'd get:
>
> %hash{'key'} = 1;
> %hash{'key2'} = 2;
> %hash{'4'}= 5;
I'm not sure I agree. If you're going to make it behave like that
then at least allow us to do something like
%hash = @array but no_special_pairs;
(Not sure that's a good property name, but it's the best I could come
up with at the moment.)
> > there needs to be some semantic way to select the hash assignment style
>
> C
No; that puts the property in the wrong place.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Perl 6 Summary for week ending 2002-09-01
were as portable as possible. Mike Lambert pointed out that it may make sense to have the files generated by bison/flex checked directly into the repository, since then those tools wouldn't be needed except by people who go messing with the grammar. http://makeashorterlink.com/?F28652DA1 Concatenation failing Leon Brocard (phew, I was worried I was going to have to run his questionnaire this week) found a bug where concatenation fails occasionally leaving no clues as to why. He attached some sample code which illustrates the problem. Peter Sinnott noted that Parrot seems to be getting confused about the length of the strings involved. Peter Gibbs meanwhile offered a patch and Mike Lambert reckoned it fixed a bug in his code, but couldn't for the life of him work out why. Peter reckons it has to do with "unmake_COW" resizing the allocation and causing confusion elsewhere. I get the feeling that what we have now is a `symptomatic' fix in search of a fix for an underlying issue. But I'm just a summarizer. Markus Laire found what he thinks might be another bug, but I've no idea if it's fixed by Peter Gibbs' patch. http://makeashorterlink.com/?N69623DA1 http://makeashorterlink.com/?V3A623DA1 IRIX64 alignment problem Steven McDougall chased down a bug causing t/pmc/perlhash.t to throw a bus error, but wasn't at all sure how to go about fixing it, and asked for advice. Bryan C. Warnock offered a few pointers, as did Peter Gibbs, but we don't have a fix yet. http://makeashorterlink.com/?M3B615DA1 Meanwhile, in perl6-language Prototypes, grammars and subs, oh my! Thom Boyer wondered what "while"'s signature would be. He'd considered "sub while (bool $test, &body);" and "sub (&test, &body);" but neither really fit. Larry agreed and offered sub while (&test is expr, &body); and then, reaching deeper into his bag of tricks, he pulled out the wonderful/scary sub while (&test is rx//, &body); (Think about that for a moment. What is proposed that you'll be able to specify a grammar for your functions argument list, which is definitely something that made *me* sit up and take notice.) Damian sat up and took notice too, offering some refinements and did some thinking aloud. Damian suggested that maybe the prototype should look like "sub while ( &test is specified(//), &body);". Damian also suggested blurring the line still further between statements and expressions by having the likes of "for" return a value, and had some thoughts on multimethods. Trey Harris also offered some more comments on multimethods. All of which leaves me looking forward with bated breath for Apocalypse 6. Quote of the thread: "The whole point of making Perl 6 parse itself with regexes is to make this sort of stuff easy." -- Larry http://makeashorterlink.com/?H1C632DA1 http://makeashorterlink.com/?E1D623DA1 Rule, rx and sub Deborah Ariel Pickett summarized the state of her understanding of the difference between "rule" and "rx" and wondered if there was any case where ... rule ... and ... rx ... (given the same "..."s in both cases), lead to valid, but different semantics. Uri Guttman thinks not. Damian thinks so, and provided an example. (It was joked, on the London.pm mailing list (by Damian himself) that Damian is currently our only real, live Perl6 interpreter.). Luke Palmer raised a red flag about Damian's example; Damian thinks it wasn't a red flag, but left it to Larry to adjudicate. This also provoke a certain amount of discussion about the philosophy behind some of the design decisions so far. Glenn Linderman wondered if "rx" shouldn't be respelled, as the term `regex' is being deprecated. Damian suggested that "rx" actually stood for `Rule eXpedient', but I'm not sure he convinced anyone (himself included). Ever the linguist, Larry observed that `we can tweak what people mean by "regular expression", but there's no way on earth we can stop them from using the term.' and that, no matter how many editions it goes through, Friedl's book is always going to be called *Mastering Regular Expressions*. So, Larry is `encouraging use of the technical term "regex" as a way to not precisely mean "regular expression".' Piers Cawley raised a question about when "}" terminates a statement and got it wrong. This subthread led to a short discussion on good Perl 6 style. Damian told us that `Any subroutine/function
Re: regex args and interpolation
Nicholas Clark <[EMAIL PROTECTED]> writes:
> On Wed, Sep 04, 2002 at 10:46:24PM -0400, Ken Fox wrote:
>> What is really needed is something that converts the date syntax
>> to normal Perl code:
>>
>>rule iso_date { () -
>>() -
>>()
>>{ use grammar Perl::AbstractSyntax;
>> $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }
>
> I'm confused. Why has that last line got a lisp expression for the spliced
> in code?
'cos S expressions are a relatively simple way of writing a syntax tree?
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: regex args and interpolation
Nicholas Clark <[EMAIL PROTECTED]> writes:
> On Fri, Sep 06, 2002 at 02:20:10PM +0100, Piers Cawley wrote:
>> Nicholas Clark <[EMAIL PROTECTED]> writes:
>>
>> > On Wed, Sep 04, 2002 at 10:46:24PM -0400, Ken Fox wrote:
>> >> What is really needed is something that converts the date syntax
>> >> to normal Perl code:
>> >>
>> >>rule iso_date { () -
>> >>() -
>> >>()
>> >>{ use grammar Perl::AbstractSyntax;
>> >> $0 := (expr (invoke 'new (class 'Date) $1 $2 $3))) }
>> >
>> > I'm confused. Why has that last line got a lisp expression for the spliced
>> > in code?
>>
>> 'cos S expressions are a relatively simple way of writing a syntax tree?
>
> But it's in the middle of stream of perl.
>
> Except, if I understand things correctly, the way the perl parsing rules
> work, it would be quite legal for any perl grammar to say that the next
> argument is to be written as an S expression *directly and raw in the source
> code*, and the parser will happily then read one S expression to its
> terminator, before continuing in perl (well, more conventional perl) syntax.
>
> ie Ken's code, above, could well be completely legal perl6 code.
>
> This idea of just switching language syntax in a context-sensitive way is
> trying to make my head explode.
But you mean that in a good way right? Anyway, he did introduce the
'use grammar Perl::AbstractSyntax;' in the lexical scope, so obviously
there's *something* afoot...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Perl 6 summary for week ending 2002-09-08
rke wondered what effect this would have, apart from breaking his procmail setup. Dan thinks we'll probably shift to a more neutral list name eventually. John Porter claimed that `some folks seem to think that sufficient reason [to change] exists now.', and Dan pointed out that John didn't have to convince `some folks', he had to convince Dan. John then attempted to invoke Larry. John Porter reckoned that changing the list name would have "a huge psychological effect, at least outside our tight little club. But if that's only as far as you can see...". Dan responded with admirable restraint. Steve Fink is surprised at how little Parrot is tied to Perl 6, and noted that Perl 6 `mostly provides evidence that this isn't just an exercise in intellectual masturbation', and came down in favour of renaming the mailing list. Ask Bjoern Hansen popped his head up to say that it would soon be relatively easy to change the list name to, say, '[EMAIL PROTECTED]'. Andrew Kuchling -- one of the python-dev crew popped to talk about parrot-gen.py and why it's not being heavily developed. (From his point of view, the mailing list name is an irrelevancy BTW). Andrew made some good points about the fun and benefits of Parrot from the point of view of a Pythoneer (It isn't much fun, mostly because of culture shock and there don't appear to be any real benefits apart from the possibly chimerical cross-language stuff), and worried about the amount of optimization that was going on before we'd got any real languages implemented. Andrew also suggested making Scheme one of the driving languages for Parrot, based on its simple syntax and fully specced semantics. As a result of all this, Dan posted his list of `Parrot long-term goals/prospects'; a 9 point list, with footnotes about where he sees things going. I'm not going to summarize it because it's already its own summary. Read it. There was some discussion about what the eventual `pure parrot' build environment will look like, including some optimistic copyright lines... http://makeashorterlink.com/?G48625EB1 http://makeashorterlink.com/?E59651EB1 http://makeashorterlink.com/?J2A632EB1 -- A Pythoneer speaks http://makeashorterlink.com/?B2B631EB1 -- Dan's list Implementation of Lists for languages/scheme Jügen Bömmels offered a patch implementing Scheme pairs, using simple Arrays. Dan was impressed, and wondered how far we were from 'real' scheme. Jürgen thinks we're quite some way away; we still need symbols, strings, lexicals, functions, macros, continuations... Piers Cawley outlined an OO way forward using (initially) hashes, and proposed a 'SchemeObject' PMC, which would hide a lot of the common structural code needed for dispatching methods implemented in any of C/Parrot/Scheme. John Porter, at his patronizing best pointed out that the hash bashed approach seemed to be reinventing the wheel. http://makeashorterlink.com/?O2C651EB1 Teasing notes Dan announced that he was about to go dark for a while as a deadline of his had just got a lot closer. However, he dropped a list of hints about what was forthcoming. Bryan asked for some clarification of a few hints (but they're *hints*, they're supposed to be a bit vague), and Dan went and spoiled the mystery by giving him some. http://makeashorterlink.com/?Q4D625EB1 Tinderbox turning green Andy Dougherty noted that the recent work on portability and general lint gathering meant that we were well on the way to a green tinderbox (ie: automated builds are mostly working, yay!). Dan thought that gave him an ideal opportunity to break things again by adding exceptions to the mix. *Andy* then went a bit red, for assorted, faintly embarrassing reasons, the patch that was meant to turn things green had been applied and then inadvertently backed out. There's a moral here somewhere. Actually there was a spate of inadvertent unpatching last week. People are embarrassed and hopefully putting procedures in place to avoid another spate. http://makeashorterlink.com/?E6E631EB1 Perl 6 miscellany Steve Fink offered a portmanteau patch for the Perl 6 compiler, including such delights as a '-e' flag to perl6 so the one line script folks could play. (First person to do the RSA one-liner in Perl 6 gets *much* kudos from me). Sean wondered about a few of the other fixes, and between them he and Steve found and squashed a bug with here docs, and discussed ways of getting working Perl 6 patterns up and running. http://makeashorterlink.com/?Z6F654EB1 Meanwhile, in perl6-language Garrett Goebel reopened the `a
Blocks and semicolons
So, the new rule for blocks and when the need semicolons seems to be
"You don't need a semicolon if the block is the last argument of a
subroutine which expects a block as its last argument", which is all
very well and all, but where does that leave:
sub foo ( &block ) {...}
...
$wibble = foo { ... } + 10;
The problem here is that this change makes the meaning of every brace
dependent on everything that's gone before and we're back with a
language that's at least as hard as Perl 5 was to parse.
Now, my understanding was that the rule for 'statement terminating
braces' was
1. brace matches rx/^^ \s* \} \s* $$/
Or, less strictly:
2. brace matches rx/ } \s* $$/
Which I could have *sworn* was something Damian had told me was the
right thing, but I've mislaid the original mail. The idea behind this
approach, judging by the Apocalypse, is that it means that instead of
blocks needing or not needing a semicolon based on special cases, all
blocks have a simple rule.
Here's what Apocalypse 4 says on the subject:
If there is any space before the curly, we force it to start a
term, not an operator, which means that the curlies in question
must delimit either a hash composer or a block. And it's a hash
composer only if it contains a => pair constructor at the top level
(or an explicit hash keyword on the front.) Therefore it's possible
to unambiguously terminate an expression by following it with a
block
Which seems to imply that:
$wibble = foo {...} + 10;
would actually be parsed as:
$wibble = foo {...}; +10;
Ah... hang on, that's *expression* not statement, so that should parse
as C<< $wibble = foo( sub {...}) + 10; >> which is fine.
The rules for what the parser infers (semicolon, comma, nothing) after
a block are somewhat undefined though. How would
func $foo {...}
func $bar {...}
func $baz {...}
deparse? C<< func $foo {...}; func $bar {...}; func $baz {...}; >>?
C<< func $foo {...}, func $bar {...}, func $baz {...} >>?
Am I worrying unduly about nothing?
What was my question? Argh! I'm more confused now then when I started
this message...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Blocks and semicolons
Luke Palmer <[EMAIL PROTECTED]> writes:
> This is for everyone: <
>In Perl, this problem comes up most often when people say "Why do I
>have to put a semicolon after do {} or eval {} when it looks like a
>complete statement?"
>
>Well, in Perl 6, you don't, if the final curly is on a line by itself.
>That is, if you use an expression block as if it were a statement
>block, it behaves as one. The win is that these rules are consistent
>across all expression blocks, whether user-defined or built-in. Any
>expression block construct can be treated as either a statement or a
>component of an expression. Here's a block that is being treated as a
>term in an expression:
> $x = do {
> ...
> } + 1;
>
>However, if you write
> $x = do {
> ...
> }
> + 1;
>then the + will be taken erroneously as the start of a new statement.
>(So don't do that.)
>
>Note that this special rule only applies to constructs that take a
>block (that is, a closure) as their last (or only) argument. Operators
>like sort and map are unaffected. However, certain constructs that
>used to be in the statement class may become expression constructs in
>Perl 6. For instance, if we change BEGIN to an expression construct we
>can now use a BEGIN block inside an expression to force compile-time
>evaluation of a non-static expression:
> $value = BEGIN { call_me_once() } + call_me_again();
>
>On the other hand, a one-line BEGIN would then have to have a
>semicolon.
>
> EOA4
>
> To me, this looks like it has answers to all these questions.
Up to a point. Look at the discussion of given/when in the same
Apocalypse. Here's some example code from A4:
given $! {
when Error::Overflow { ... }
when Error::Type { ... }
when Error::ENOTTY { ... }
when /divide by 0/ { ... }
...
}
Look, closing braces, ending statements, not on a line by
themselves. There's code like this all through the apocalypse and its
associated Exegesis, so it looks to me like C<< rx/\} \s* \n/ >> is
the regex for 'end of statement'. Either that or we're back with a
pile of special cases, which I thought the Apocalypse was supposed to
be eliminating.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Perl 6 Summary for week ending 2002-09-15
The Perl 6 Summary for the Week Ending 20020915 Happy birthday to me! Happy birthday to me! Happy birthday dear me! Happy birthday to me! And, with a single breech of copyright, Piers was free. The production of this summary was delayed by my turning 35 on the 15th and then spending the Monday train journey reading one of my birthday presents (*Dead Air* by Iain Banks, it's jolly good) instead of writing a summary. So this morning I left the book at home. So, what's been going on with Perl 6. We'll start, as usual with perl6-internals. Goal call for 0.0.9 The week before, Dan had asked for some suggestions as to what should be the priorities for the 0.0.9 release of Parrot. One of Nicholas Clark's goals from last week was the `Careful elimination of all compiler warnings, particularly on non x86 platforms, and for builds with non-default INTVAL size', and discussions of how to go about doing this (and indeed some doing) carried on into this week. There was also some discussion about whether IMCC and the Perl 6 compiler should be built by default. On the one hand, it would mean that the tinderboxes were testing those important subsystems, on the other hand, it was thought that there were some people who wouldn't be interested in testing those things. Consensus seemed to be that we should just build and test them anyway. http://makeashorterlink.com/?M2E0225D1 Scheme Implementation Details Jürgen Bömmels and Piers Cawley continued their discussion of how to go about implementing a scheme interpreter, and "lambda" in particular. Piers made noises about a proof of concept implementation of Scheme that he'd made using Perl objects, but didn't show code. (And, I can exclusively reveal, will not be showing (the original) code owing to badness with backups and lackadaisical use of CVS). Jürgen, who had actually made the effort of writing some code, listened politely and agreed that Piers' suggestions looked like they might be a way forward. Jürgen went away and implemented a first cut at "quote", "define" and "set!". http://makeashorterlink.com/?O2F0325D1 http://makeashorterlink.com/?K101255D1 "chr", "ord" etc. Clinton A Pierce restarted this thread and discussed what he'd like to see (apart from a pony) from Parrot's equivalent of Perl 5's "pack". Clint wondered whether Parrot "pack" should use a template, or if it should be implemented as a horde of smaller ops, each handling a different conversion, so that a single, Perl level call to pack would become lots of op calls at the parrot level. Clint also drools at the thought of doing "sprintf" at the parrot level. Aaron Sherman agreed with most (all?) of Clint's proposals, and also wants a pony. (Who doesn't?). Peter Gibbs went so far as to offer a patch which implemented a subset of pack functionality, and was applauded. Graham Barr wondered if pack should also allow for packing to 'native' types, which wouldn't have to worry about endian issues. Peter thought that would be a good idea. Nicholas Clark pointed out that extending the code to cope with unsigned integers would be a good idea too. http://makeashorterlink.com/?A311215D1 Lexicals Jürgen Bömmels asked a pile of questions about the implementation of lexical variables and how one could use them to make a closure. Jonathan Sillito provided a mixture of answers and guesses. It seems that we're waiting on Dan to firm some things up about lexicals. http://makeashorterlink.com/?E221215D1 IMCC 0.0.9 Runs 100% Perl 6 Tests + Various Results Leopold Toetsch has been working on getting IMCC to generate parrot bytecode directly rather than going through a stage of generating an intermediate ".pasm" file, and had been having some problems with `writing out the .pbc, especially Const_Table, type PFC_KEY / PARROT_ARG_SC'. Two hours later he announced that he had all the perl6 tests running successfully within IMCC, but only if GC was turned off (there are problems with the longer running tests when GC is turned on). Things get progressively worse as first JIT, and then Predereferencing are turned on. Dan wondered what the GC bug could be. Leo wasn't sure but posted some possible pointers. Peter Gibbs thought that at least one of the bugs was in continuation.pmc and posted a patch which fixed one of the problems when running under parrot. Meanwhile Leo tracked down the bug to a bit of code that he'd appropriated from debug.c, so he fixed his IMCC and sent in a patch to fix debug.c as well. Applying both patche
Re: Perl 6 Summary for week ending 2002-09-15
Aaron Sherman <[EMAIL PROTECTED]> writes: > On Wed, 2002-09-18 at 11:42, Piers Cawley wrote: >> The Perl 6 Summary for the Week Ending 20020915 >> Happy birthday to me! > > Indeed! > > And thank you so much for this. You have a way of taking a tangled mess > of discussion that's even confusing the participants and making it easy > to digest (no pun intended). I even come out of it with a smile at the > end. Someone just pointed out that I called Tim Bunce "Tim Bunch" in the summary. I really should resist the temptation to post it before at least one extra pair of eyes has looked over it, but I was running my deadline pretty close. The typo makes me, at least, smile, but in a rueful kind of way. > Thanks again! No problem. It's fun, in a weird kind of way. And it definitely keeps me abreast of what's going on. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Re: Perl 6 Summary for week ending 2002-09-15
Leopold Toetsch <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: > >> Happy birthday to me! > > > Congratulations. > >> ... by my turning 35 on the 15th > > > 44 on 16th - yes Sept. Congrats to you too. So, should I start maintaining a birthday database for the summaries? Probably not. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
Perl 6 Summary for week ending 2002-09-22
The Perl 6 Summary for the Week Ending 20020822
So, another week, another Perl 6 summary. Let's see if I can get through
this one without calling Tim Bunce 'Tim Bunch' shall we? Or maybe I
should leave a couple of deliberate errors in as a less than cunning
ploy to get more feedback. Hmmm.
So, kicking off with the internals list as always:
The Compound Key discussions continue
Dan Sugalski, Graham Barr and Leopold Toetsch (who, incidentally, turned
44 on the 16th, so not only does he contribute really useful code, he
makes Dan and I feel younger. Can this man do no wrong?) all thought
hard about Ken Fox's Hard Question from last week. The Hard Question
was: `If "%h{"a"}[0][1]" is a PASM "P2["a";0;1]", then what is
"%h{"a"}{0}[1]"?'. Leo thought that things would work because an integer
isn't a valid key type for a hash, so the second case would throw a `Not
a string' error. Dan thought that this might not be enough, so we
probably need an extra flag to designate whether a key element should be
taken as an array or hash lookup. Graham Barr agreed, citing the `hash
with objects as keys' example that seems to crop up everywhere, and
suggesting the rather lovely looking "my @array is indexed('a'..'b');"
as another possibility. Graham also wondered how the flag should be
used, suggesting that it should get passed into a vtable's lookup
method, thus allowing the writing of PMCs that don't care how they're
looked up, or other PMCs that did cunning things depending on how they
were accessed. Dan agreed.
http://makeashorterlink.com/?P66B337E1
Return undef for negative indices
Sean O'Rourke supplied a patch that arranged for @ary[-1000], say, to
give "undef" when @ary has fewer than 1000 elements. Also included was a
patch which changed array's "get_string()" method to return the array's
"get_integer()" value converted to a string. Leo Toetsch wasn't keen on
this idea, wondering if it shouldn't return something like
"PerlArray(0xaddr)" by analogy with the behaviour of PerlHash PMCs. Sean
disagreed, pointing out that in Perl5 one could say "print "You scored
$score out of" . @questions . "questions."", and the array would
stringify to the number of elements it contained. Brent Dax pointed out
that in Perl 6 one would have to write "print '\@foo has ' _ +@foo _ '
elements';" because Perl 6 arrays stringify to their elements, separated
by ".prop{sep} //= ' '". Sean didn't like this, but appeared to take the
point. Uri Guttman quibbled about style, and proposed "print "\@foo has
$(@foo.length) elements";", which certainly does a good job of making
its intention explicit.
http://makeashorterlink.com/?M17B627E1
A Lexicals pre-patch
Sean O'Rourke was unhappy with the current lexical implementation, as it
doesn't seem to support different levels of static nesting. Apparently
this makes nested scopes hard to implement, especially in the presence
of Perl 6's %MY magic. So he sent a patch for people to play with.
Jonathan Sillito liked the patch, and pointed to a different approach
that would make taking closures easier, but which would possibly make
lookup slightly less efficient. Sean wondered how Jon's scheme would
handle recursion. Jon thought about that, and answered by outlining how
you would implement closures using Sean's scheme, and proposing that
Sean make a 'real' patch.
Jürgen oumlmmels had a pile of questions too, related to using Sean's
patch to implement proper Scheme functions, and he proposed a set of ops
for manipulating pads. Sean agreed that this looked useful.
http://makeashorterlink.com/?U48B217E1
http://makeashorterlink.com/?K19B257E1
http://makeashorterlink.com/?K19B257E1
default.pmc patches
Leopold Toetsch patched default.pmc to make almost all methods throw
meaningful exceptions. Sean O'Rourke reckoned that the patch went a bit
far, proposing a few places where having a slightly richer default
behaviour would be the Right Thing to do, and some others where doing
nothing was the right default behaviour -- the example given was "init".
Leo countered that one should really have a default_scalar.pmc for the
first types, and that, for the second type, the PMC should have an
explicitly empty method. The thread resembled the Monty Python Argument
skit for a few messages (`Look, this isn't a proper argument!', `Yes it
is!', `No it isn't it's just contradiction!'). After a couple of rounds
of this, Sean showed his (substantial) list of default behaviours that
he thinks should be in default.pmc, and Leo showed us his planned PMC
hierarchy.
Dan came down on Leo's side.
http://makeashorterlink.com/?C1AB227E1
http://makeashorterlink.com/?K1BB157E1 -- Sean's list
http://makeashorterlink.com/?L2CB537E1 -- Leo
Perl 6 summary for week ending 2002-09-29
ve Fink voted that Leo should be given commit access to CVS and Leo was grateful for the vote of confidence. Leo later sent in yet another patch for intlist, which after a short quibble from Tom Hughes, and a correction from Leo, was applied. http://makeashorterlink.com/?G4AD236F1 http://makeashorterlink.com/?M2BD326F1 Of PMCs Buffers and memory management Worker of the week, Leo Toetsch posted a bunch of questions about PMCs, Buffers and their associated memory management. Firstly, he wondered why there was a separation between the two. He commented that `If PMCs and Buffers are unified, it should be possible to mark [during a GC run] in one recursive process'. And there's the rub; we don't like recursion. PMCs are structured in such a way that a PMC tree can be walked in iterative fashion, which means that GC can be done in pretty much constant memory. Leo had a bunch of other questions, that were mostly answered by Mike Lambert, which drew supplementary questions from Leo. Both Mike and Leo agreed that the changes needed to Parrot for unification would lead to massive patches; but that's not a reason for *not* doing the work. http://makeashorterlink.com/?W2CD626F1 http://makeashorterlink.com/?U5DD126F1 Add Stone Age Exception Handling This should possibly really go in the 'In Brief' section because there was only one post in the `thread'. But it looks like an important post. Brent Dax sent in a patch which `adds a very, very rudimentary form of C-level exception handling' to parrot. Brent Reckons that brings parrot up to slightly better than `homo erectus' quality exception handling. http://makeashorterlink.com/?T5ED546F1 Meanwhile, in Perl 6 I can't remember who it was christened this week's monster thread `Paren Madness', but they weren't wrong. The `Here, we can build a list like this...' thread continued on its merry way. I'm afraid I pretty much stopped reading once it became apparent that the only thing that was going to stop the madness was Larry making a pronouncement. Eventually Dan stepped up and asked if someone could summarize the discussion, maybe with a few possible conclusions, and then leave it for a while 'til Larry got back. Luke Palmer wrote it up and offered a suggestion which looks at first glance to be sane, and which seemed to be well liked. http://makeashorterlink.com/?D1FD256F1 http://makeashorterlink.com/?Y50E416F1 For loop and streams In pretty much the only other substantial thread of the week, `[EMAIL PROTECTED]' had some problems with the new "for" loop using multiple counters, and wondered if this was because of problems with the current Perl6 implementation, or because of problems with his understanding. It turned out that it was a problem with Sean O'Rourke's understanding when he implemented the Perl 6 grammar; he'd missed something in the appropriate Apocalypse. There also seems to be a problem in that the current behaviour is mostly defined with hand waves, which is great when you're doing the broad brush design, but less great when you're trying to implement the language. http://makeashorterlink.com/?V21E116F1 In Brief Leopold Toetsch patched packfile.c to stop monkeying with the internals of key structures. Parrot T Shirts, based on Andy Wardley's parrot logo design, are now available from Cafe Press at http://makeashorterlink.com/?F22E226F1, any proceeds go to YAS/TPF. Simon Cozens found, and patched a problem with IMCC's `ostat' structure, which clashed with a structure in Darwin's stat.h. Leopold Toetsch has been playing with using Doug Lea's memory allocator (see http://makeashorterlink.com/?D23E216F1) in Parrot. Apparently it makes `life' run faster, but appears to double the memory footprint. Steve Fink sent in some patches for IMCC, Leopold Toetsch did some cherry picking and released an integrated patch. Erik Lechak wondered if there was a getting started guide to parrot, and if there wasn't, how should he go about writing one? My tip: Do it, use the tools you prefer to make the kind of guide you would have welcomed finding when you first came to parrot. Just don't use proprietary formats. Heck, it's how I started writing these summaries. Who's Who in Perl 6 Who are you? Piers Cawley What do you do for/with Perl 6? I write the summaries every week, and try and contribute to perl6-language and perl6-internals when they're discussing things I know about. Where are you coming from? I've been a happy Perl user for since around 4.036, initially using
