Re: Some Things I'd Like To Do With Pod
On 22/06/07, brian d foy <[EMAIL PROTECTED]> wrote: ===Per class documentation, not per file documentation Related to the one above, I'd like to have NAME, SYNOPSIS, etc. for each class, not just per file. Well, what I really want is the Smalltalk class and method browsers, but I know I'm not going to get those. I'm sure it's going to be great deal easier to implement such a tool in Perl 6 than it is in Perl 5 though. It's just not going to be in the core. And even if it's not going to be easy, I can think of at least one person who is going to have a bloody good go at implementing it. With apologies if I'm teaching my grandma to suck eggs here.
Re: Selective String Interpolation
Damian Conway <[EMAIL PROTECTED]> writes:
> Brad Bowman asked:
>
>> When building code strings in Perl 5 I usually write the code,
>> then wrap it in double quotes, then "\" escape everything light blue
>> under syntax highlighting. I was wondering if there'll a better
>> way in Perl 6. I thought it would be nice to define the variables
>> you wish to
>> interpolate individually, perhaps as extensions to the :s, :a,
>> etc quote adverbs, perhaps using a signature object.
>
> There is already a mechanism for this. You simply turn off all
> variable interpolation, and interpolate any the variables you wish to
> interpolate via block interpolations. Or, more simply, only turn on
> block interpolation in a non-interpolating string:
>
> my $code = q:c{
> package {$package_name};
>
> sub {$sub_name} \{
> return {$return_val}
> \}
> };
The problem here is that sometimes (especially in code generation) you
don't really want to interpolate the stringification of a value, you
just want the value itself. I've been struggling with this slightly
when I've been writing code generation methods in Ruby. Where, in
Scheme or lisp you'd simply use some combination of C<`>, C<,> and
C<,@>, in Ruby you end up having to store values somewhere in the
binding that will be accessed by your compiled code; which would be
fine if (again, as with Lisp macros) you could generate what I tend to
think of as an anonymous symbol to bind the value to:
my $anon_symbol = gensym
my ${$anon_symbol} = $the_complex_value_we_want_to_use_in_generated_code
my $code = q:c{
package {$package_name};
sub {$sub_name} \{
return ${$anon_symbol}
\}
};
And backwhacking braces in generated code is *not* a pretty solution
to my eyes. I'd *like* to be able to have a quasiquoting environment
along the lines of lisp's backquote (though I'm not sure about the
unquoting syntax):
my $code = q:`{
package ,$package_name;
sub ,$sub_name {
,$the_complex_value_we_want_to_use_in_generated_code
}
sub ,$another_sub_name {
,[EMAIL PROTECTED](';')}
}
};
Whatever we go with, we need a quoting mechanism that returns a parse
tree rather than a simple string if we want to deal with interpolating
complex values (especially if we don't want to have to worry about
what, if any, quotes are needed round some of our interpolated values.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
perl6-language@perl.org
John Siracusa <[EMAIL PROTECTED]> writes:
> On 1/18/06 11:06 PM, Rob Kinyon wrote:
>> Not to mention that 90% of the hacking done in Class:: and Object:: will
>> handled by the fact that Perl6 has actual OO syntax. ("Look Ma, no hands!")
>> You won't need Class::MakeMethods because Perl6 will make your accessors for
>> you.
>
> There's more to life than simple get/set accessors. Method-makers will have
> and a long and glorious life in Perl 6, I assure you :)
I refer the interested reader to all the handy dandy method makers
(and other tricksy class methods) to be found in the Ruby on Rails
framework...
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: relationship between slurpy parameters and named args?
Stuart Cook <[EMAIL PROTECTED]> writes: > On 29/12/05, Austin Frank <[EMAIL PROTECTED]> wrote: >> So, is there a conceptual connection between imposing named argument >> interpretation on pairs in an arg list and slurping up the end of a >> parameter list? Are there other meanings of prefix:<*> that relate to >> one or the other of these two meanings? > > The missing link is that prefix:<*> in an argument list also causes > things like arrays to be treated as a sequence of separate parameters, > rather than as a single array parameter. See "Flattening argument > lists" in S06. > > (This was the original meaning of prefix:<*> in arglists; the > named-pair behaviour was added later, when pair values ceased to have > named behaviour automatically.) Personally, I think that prefix * in an arglist should only flatten array arguments if there is only one array. And if it doesn't, how do I declare parameter that is 'a slurpy list of arrays' or 'the rest of the arguments, without flattening'. If I *really* want aggressive flattening then I can call, say, @slurpy_param.flatten -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/
Re: relational data models and Perl 6
Rob Kinyon <[EMAIL PROTECTED]> writes: > On 12/16/05, Ovid <[EMAIL PROTECTED]> wrote: >> Minor nit: we're discussing to the relational algebra and not the >> relational Calculus (unless the topic changed and I wasn't paying >> attention. I wouldn't be surprised :) > > Algebra, in general, is a specific form of calculus. So, we're > speaking of the same thing, just in different terms. Umm... I think you have that relationship the wrong way around. -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/
Re: statement_control()
Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Nov 22, 2005 at 10:12:00AM +0100, Michele Dondi wrote: > : Oh, I'm not the person you were responding to, and probably the less > : entitled one to speak in the name of everyone else here, but I feel like > : doing so to say that in all earnestness I'm quite sure no one took any > : offense out of your words. Despite the slight harshness, they're above all > : witty. Just as usual: and that's the style we all like! > $fh = open '>>', 'quotefile' or fail; $fh.print <<'EOQ' I like witty sayings as much as the next guy, but wit can hurt when misdirected. If people want me to be machine for cranking out quote file fodder, I'll do my best. But I also care about my friends. Larry EOQ -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/
Re: Perl6 perlplexities
Rob Kinyon <[EMAIL PROTECTED]> writes: > First-class blocks make continuations and coros almost neglible to > implement from an API perspective. Almost makes me wonder how much > trouble it would be to implement this in P5 ... Um... tosh. Seriously. Full continuations need some fairly serious retooling of the call stack if they are to work properly. And one shot continuations are the next best thing to useless. -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/
Re: Perl6 perlplexities
Rob Kinyon <[EMAIL PROTECTED]> writes:
> On 11/4/05, Michele Dondi <[EMAIL PROTECTED]> wrote:
>> I'm still convinced my remark _partly_ applies in the sense that the
>> overall impression is that a vast majority of most common needs is
>> addressed by a *subset* of the current features and trying to stuff all
>> them in has brought in quite a lot of discussions of which I'm not even
>> sure if they've all settled down.
>
> I think a good comparison can be made to Ruby. For work, I've been
> learning Ruby this past week (we're going to try out Rails to see if
> we like it). As my colleague put it, Ruby has all the P6 features we
> want and it's usable now.
>
> Ruby's OO system is 1000% more complex that Perl5's. Yet, it's still a
> net win. For one thing, I don't have to write the following anymore
> (lifted from a CPAN module I am working on):
The thing about Ruby (and Perl 6's) OO system is that the complexity is in the
right place -- tucked away where most people don't have to worry about it until
they want to do something complex.
> sub children {
> my $self = shift;
> if ( caller->isa( __PACKAGE__ ) || $self->isa( scalar(caller) ) ) {
> return wantarray ? @{$self->{_children}} : $self->{_children};
> }
> else {
> return @{$self->{_children}};
> }
> }
>
> This is in a vain attempt to implement a protected subroutine. In
> fact, I really want a private writing accessor with a public reading
> accessor, but have absolutely no way to implement that.
>
> Why do I want such a beast? Because I want to GUARANTEE in an absolute
> kind of way that, unless my user truly intended to do so, he's not
> going to be able to accidentally screw up my internal state.
And when your user does want to, essentially say "Nah, you screwed up designing
that object protocol, children shouldn't've been protected." it's the work of a
moment to write:
thing.send(:children, *args)
> (Oh, and Ruby has first-class block. W00T!)
And continuations. But continuations are scary. Good scary, but still scary.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Perl6 perlplexities
Juerd <[EMAIL PROTECTED]> writes:
> Michele Dondi skribis 2005-11-04 14:58 (+0100):
>> Let me explain: we all know that Perl5 has a very simple parameter
>> passing mechanism for subs and an even more rudimentary
>> {prototyping,signature} mechanism that one actually seldom uses.
>
> It is unused because it sucks.
>
>> With this simple mechanism one can implement or fake quite a lot of
>> parameter passing paradigms.
>
> And it is a lot of work to do so.
>
>> for simple subs in Perl6 I will probably still use @_
>
> You'd be a fool to do so, with the sole exception of list manipulation,
> which at least in my codebase isn't used quite that much, and almost
> never listens to the qualification "simple sub".
>
> Compare:
>
> sub dosomething { @_[0] blah @_[1] }
>
> sub dosomething ($a, $b) { $a blah $b }
>
> sub dosomething { $^a blah $^b }
>
> The @_ solution is really the most ugly and hard to type of the three
> possibilities.
>
>> err... that or the new pointy subs which are indeed so cool!
>
> Cool, but probably not a good idea for named subs, if only for style.
>
> our &dosomething ::= -> $a, $b { $a blah $b }
>
> Not really a winner in any perspective.
And the return semantics of pointy blocks are different, you have to be careful
about doing an explicit return in them because that returns to the caller of
the lexical scope in which they were defined (otherwise for ... -> ... {...}
wouldn't work)
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Proposal to make class method non-inheritable
Stevan Little <[EMAIL PROTECTED]> writes: > Piers, > > On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote: >> We definitely have two instances of A since, B.isa(::A). We also have >> a fragile implementation of count. > > :) > > Sorry, I purposefully made it a kludge as that is usually the way the example > is shown in most tutorials about class methods. So, let me see if I have this straight here. You're arguing that, because people are often foolish, we should make it harder to be clever? And you're using a deliberately broken example as grist to your mill? Doesn't sound all that Perlish to me. -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/
Re: Roles and Trust
Ovid <[EMAIL PROTECTED]> writes:
> --- Piers Cawley <[EMAIL PROTECTED]> wrote:
>>
>> How about:
>>
>> my method SCALAR::attributes($self:) { $$self }
>> my method HASH::attributes(%self:) { %self.kv }
>> my method ARRAY::attributes(@self:) { [EMAIL PROTECTED] }
>>
>> method _attributes($attrs) {
>> my @attributes = $attrs.attributes
>> return @attributes[0] if @attributes == 1;
>> ...
>> }
>>
>> Assuming it's legal.
>
> Just saw this. Sorry for the late reply.
>
> At first that gave me the willies, then I noticed the "my" on the
> front. I assume because of the "my" on there that this would affect
> those data types only locally? That seems like it would be a nice
> compromise.
>
> Is this legal syntax?
After some discussion on #perl6, we thought probably not (unless
@Larry rules otherwise). However,
my multi attributes( Scalar $scalar: ) { $$scalar }
my multi attributes( Hash %hash: ) { %hash.kv }
my multi attributes( Array @array: ) { [EMAIL PROTECTED] }
definitely is legal (though it does rather suffer from the end-weight
problem to my way of thinking).
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Proposal to make class method non-inheritable
Stevan Little <[EMAIL PROTECTED]> writes:
> Hello all.
>
> I would like to propose that class methods do not get inherited along
> normal class lines.
>
> I think that inheriting class methods will, in many cases, not DWIM.
> This is largely because your are inheriting behavior, and not state
> (since class attributes are not inheritable). Let me explain in more
> detail.
>
> Let's start by making a very basic definition of an *object*,
> ignoring any implementation details or specifics.
>
>object == state + behavior
>
> This statement assumes that *objects* at their core are a unique
> state coupled with a collection of behaviors to act upon that
> particular state. Of course we are ignoring all the other class/meta/
> inheritence junk for now.
>
> To take away the behavior, and only be left with state would degrade
> our object to the level of C struct or Pascal-style record-type. To
> take away the state, and only be left with behavior, would basically
> leave a module/package or some pseudo-random collection of functions.
>
> So at this point, I think it is safe to say that an *object* should
> have both state and behavior.
>
> Now, back down from the theoretical cloud to reality. I would like to
> show some canonical class-method examples (and in some cases, show
> how they are broken), then show how they might be better accomplished
> in Perl 6 without the need for class methods to be inherited.
>
> == Instance Counting Class
>
> The most common example given for class methods is an "instance
> counter". Here is how one might (naively) look in Perl 6:
>
> class A {
> our $.count;
> method count (Class $c:) { $.count; }
> submethod BUILD {
> $.count++;
> }
> }
>
> Each time an instance of A is created the counter is incremented. So
> that ...
>
> A.count; # 0
> A.new;
> A.count; # 1
>
> Now this makes sense, until we subclass A.
>
> class B is A {}
>
> A.count; # still 1
> B.new; # calls A::BUILD
>
> A.count; # 2
> B.count; # 2
>
> Clearly, we only have one instance of A, and one instance of B, so
> those numbers are wrong. It could be argued that since B is a subtype
> of A, we do have two A's, but the argument does not work in reverse.
> But either way, I would argue that the results shown above are
> misleading, and probably not what the programmer intended.
We definitely have two instances of A since, B.isa(::A). We also have
a fragile implementation of count.
class A {
our %.count_of
method count (Class $c:) { %.count_of{$c} }
method BUILD {
$class = ($?SELF.class)
@countable_ancestors = $class.ancestors.uniq.grep :{.isa(::A)}
for $class, [EMAIL PROTECTED] -> $c { %.count_of{$c}++ }
}
Where we're assuming I've got the syntax of 'for' right, and that
'ancestors' is a class method that returns all of a class's
ancestors. This might not work too well in the face of a dynamic
inheritance tree, but it should be possible to work around. Something
like this might work:
Class A {
our %.instance_count_of
method count (Class $c: ?$with_descendents = undef) {
my @interesting_classes = $c;
if $with_descendents {
push @interesting_classes, *($c.all_subclasses);
}
[+] %.instance_count_of(@interesting_classes)
}
method BUILD {
%.instance_count_of($?SELF.class)
}
}
Where we're assuming that a class can find all its subclasses
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Roles and Trust
Ovid <[EMAIL PROTECTED]> writes:
> Apocalypse 12 has the following to say about roles and trust
> (http://www.perl.com/pub/a/2004/04/16/a12.html?page=10)
>
> It's not clear whether roles should be allowed to grant
> trust. In the absence of evidence to the contrary, I'm
> inclined to say not.
>
> In Perl 5, I recently found myself in the annoying position of having a
> method which could accept scalar, array, or hash references. My
> primary code looked similar to this (simplified for clarity):
>
> sub _attributes {
> my ($self, $attrs) = @_;
> return $$attrs if UNIVERSAL::isa( $attrs, 'SCALAR' );
>
> my @attributes = UNIVERSAL::isa( $attrs, 'HASH' )
> ? %$attrs : @$attrs;
> return unless @attributes;
> # more code here
> }
>
> This was a private method, but $attrs is an argument that is passed in
> by the person using my class. It would be nice if I could just assign
> an "attributes" role to the SCALAR, ARRAY, and HASH classes and say
> that only my class could see the method(s) it provides. Thus, my
> caller would be blissfully unaware that I am doing this:
>
> $attrs->attributes; # even if it's an array reference
How about:
my method SCALAR::attributes($self:) { $$self }
my method HASH::attributes(%self:) { %self.kv }
my method ARRAY::attributes(@self:) { [EMAIL PROTECTED] }
method _attributes($attrs) {
my @attributes = $attrs.attributes
return @attributes[0] if @attributes == 1;
...
}
Assuming it's legal.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Exceptuations
"Peter Haworth" <[EMAIL PROTECTED]> writes:
> On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
>> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
>> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
>> > > Piers Cawley wrote:
>> > > >>Exactly which exception is continued?
>> > > > The bottommost one. If you want to return to somewhere up its call
>> > > > chain, do:
>> > > >
>> > > > $!.caller(n).continue(42)
>> > >
>> > > Whow, how does a higher level exception catcher *in general* know
>> > > what type it should return and how to construct it? The innocent
>> > > foo() caller shouldn't bother about a quux() somewhere down the line
>> > > of command. Much less of its innards.
>> >
>> > Well said.
>>
>> No! Not well said at all!
>
> Sorry, I misread that. I thought I was agreeng with "how does a higher
> level exception catcher know what to change in order to make resuming the
> continuation useful?", especially in the light of Piers saying that the
> bottom-most exception should be the one resumed.
I'm sorry, we appear to have lost some kind of context, the original example
given only had one exception thrown, but it got propagated up through a long
call chain. At no point did anything catch the original exception and
rethrow. If they had, you're absolutely correct in asserting that by default
things should resume from the point of the outermost rethrow. A brave exception
catcher (or more likely programmer with a debugger) might want to crack that
exception open and examine its inner exceptions, but in general that's not
going to be safe.
The scary syntax proposed above is, again, the sort of thing that might be
useful in a debugger "I don't really care about the inner workings of these
helper functions, I just want 'open' to return this mocked handle." (actually
in that case, being able to do $!.caller(&open).continue(MockIO.new), where
'caller &open' looks up the call chain for the lowest call to open and returns
that continuation would be rather neat)
> The highest level exception is the only one a caller has any right to deal
> with, but even then it doesn't really know what will happen if it resumes
> some random continuation attached to the exception.
Oh stop with the 'rights'. And it's not dealing with a 'random' continuation,
if it's going to resume it should be damned careful about which exceptions it
resumes from; you don't just go around doing CATCH {...; $!.continue(...)}, you
do CATCH SomeSpecificKindOfResumableException { ...; $!.continue(...)}. And, in
general, you don't do that either, because in the average program you catch the
exception at a point where you can simply return a sensible default to your
caller. Resumable exceptions come into their own, however, when you're
debugging. I can envisage doing:
perl6 -debug::on::error some_script
And have it run along happily until an exception gets propagated up to the top
level, at which point the debugger swings into action and uses the continuation
to tunnel back to the point at which the exception was thrown so the programmer
can inspect the program state, possibly fix things up, return something
sensible and carry on.
>> CATCH {
>> when some_kind_of_error {
>> $!.continue($appropriate_value_for_some_kind_of_error)
>> }
>> }
>
> That just gives me the willies, I'm afraid.
It doesn't amuse me that much, unless whatever generates
$appropriate_value_for_some_kind_of_error is very, very smart indeed. But, as
I've said above, that's not really where resumable exceptions shine.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Exceptuations
TSa <[EMAIL PROTECTED]> writes:
> BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
CATCH Exception { say "Why do you hate freedom?" }
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: This week's summary
TSa <[EMAIL PROTECTED]> writes:
> HaloO,
>
> The Perl 6 Summarizer wrote:
>> Meanwhile, in perl6-language
>> "\(...)"
>> Oh look, a thread in p6l that's still going more than a fortnight later.
>> How unusual.
>
> Is a long running thread considered a bad thing on this list?
Nah, it's just hard to summarise.
> I have grasped so far, that spawning a new thread after
> some divergence from the original topic is considered nice.
Definitely.
>> This particular instance of the form is nominally about the
>> behaviour of "\($a, $b)" but various subthreads have drifted onto
>> discussions of context in general and meaningful whitespace. So far
>> there has been no discussion of the return value of
>> "Pin.head.contents.grep -> Angel $a {$a.is_dancing}" but I'm sure it's
>> only a matter of time.
>
> Please tell me if the particular pinhead is me. I'm actually about to reply
> to Juerds question about my ranting about code backing the interpolation
> of data into strings. Or is that considered counter productive
> hairsplitting?
Just a reference to the old philosophical question of how many angels can dance
on the head of a pin. That and the fact that I occasionally get curmudgeonly
and hit the send button before I have second thoughts.
The weird thing is that the syntax I rolled there is soon to be the topic of an
original thread, once I've got the thing written up a little more.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Exceptuations
TSa <[EMAIL PROTECTED]> writes:
> HaloO,
>
> Piers Cawley wrote:
>>>Exactly which exception is continued?
>> The bottommost one. If you want to return to somewhere up its call chain, do:
>> $!.caller(n).continue(42)
>
> Whow, how does a higher level exception catcher *in general* know
> what type it should return and how to construct it.
It asks the continuation? The information should be there. Consider a function
definition:
sub whatever(...) returns List {
throw ResumableException;
}
Then, assuming that caller returns continuation -- which is a pretty big
assumption, but which would be really cool -- $!.caller(1) would be a
continuation with an signature of (List $not_a_real_name). If the function can
return several types dependent on context, then the continuation's signature
would be the appropriate one for the context in which the function was
called. Monkeying with this kind of thing in code isn't necessarily a good
idea, but it's great for, for instance, having a top level exception catcher
that could (potentially) bring up an interactive shell with limited debugging
features which would allow you to inspect the running program and work out what
went wrong. Ruby on Rails already does something like this, with the added
wrinkle that, if it hits a breakpoint when running in the server it hands off
the interactive session to a console process rather than having you monkey with
it within your browser. A very neat trick and a remarkably powerful debugging
technique.
> The inocent foo() caller shouldn't bother about a quux() somewhere down the
> line of command. Much less of it innards.
>
> Think of receiving a 'shelf picker died of lung cancer' exception when you
> just ordered a book from your favorite book dealer. Irrespective of the
> seriousness to the shelf picker, but how would you expect a customer to
> handle such an exception?
I wouldn't, but I would expect that a programmer would find such an exception
very useful indeed.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Exceptuations
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>> I propose a new model - each exception has a continuation that
>> allows it to be unfatalized.
>
> I think we've already talked about something like this. But in the
> presence of "use fatal", it makes a lot more sense.
>
> Something comes to mind:
>
> use fatal;
> sub foo() { bar() }
> sub bar() { baz() }
> sub baz() { quux() }
> sub quux() { fail }
> {
> say foo();
> CATCH { $!.continue(42) }
> }
>
> Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call chain, do:
$!.caller(n).continue(42)
Assuming caller returns a continuation (which I still fondly hope it will). I'm
assuming you're examples aren't necessarily tail calls of course.
> Where do we cut off the call chain and replace our own value? This comes up
> again with open(). Let's say open is implemented with a series of five
> nested calls, the innermost which knows how to fail and propagate outwards.
> However, the programmer using open() has no idea of its internals, so it
> ought to override the return value of open() itself, rather than its utility
> functions. However, we can't go with outermost, because then you'd only be
> "fixing" the lexical call ("say foo()" above). So it's somewhere in between.
> Where?
Obviously the topmost function should do:
sub open(...) {
...
CATCH { $!.rethrow }
}
This assumes that 'rethrow' throws a new exception that delegates to the
original exception for lots of its behaviour. If, later, you want to explicitly
get at the exception thrown by the helper function, you could do something
like:
$!.inner
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Sort of "do it once" feature request...
Michele Dondi <[EMAIL PROTECTED]> writes:
> Every time I've desired a feature for Perl6 it has turned out that either it
> was already planned to be there or I have been given good resons why it would
> have been better not be there.
And you've done it again. What you ask for is already there. See below.
>
> Now in Perl(5) {forum,newsgroup}s you can often see people doing stuff like
>
>my @files=grep !/^\.{1,2}/, readdir $dir;
>
> Letting aside the fact that in the 99% of times they're plainly reinventing
> the
> wheel of glob() a.k.a. File::Glob, there are indeed situations in which one
> may
> have stuff like
>
> for (@foo) {
>next if $_ eq 'boo';
># do something useful here
> }
for @foo {
next if (($_ ne 'boo')..undef)
# do something useful
}
> whereas they know in advance that C can succeed at most once (e.g. foo
> could really be C).
>
> Or another case is this:
>
> while (<>) {
> if (@buffer < MAX) {
> push @buffer, $_;
> next;
> }
> # ...
> shift @buffer;
> push @buffer, $_;
> }
while <> {
if 0..MAX { push @buffer, $_; next }
end
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
Re: Do slurpy parameters auto-flatten arrays?
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 8/3/05, Aankhen <[EMAIL PROTECTED]> wrote:
>> On 8/3/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
>> > So how *do* I pass an unflattened array to a function with a slurpy
>> > parameter?
>>
>> Good question. I would have thought that one of the major gains from
>> turning arrays and hashes into references in scalar context is the
>> ability to specify an unflattened array or a hash in a sub call
>> without any special syntax...
>
> Well, you can, usually. This is particularly in the flattening
> context. In most cases, for instance:
>
> sub foo ($a, $b) { say $a }
> my @a = (1,2,3);
> foo(@a, "3");
>
> Passes the array into $a. If nothing flattened by default, then you'd
> have to say, for example:
>
> map {...} [EMAIL PROTECTED];
>
I would assume that the way to implement map is:
multi sub map(&block, @array) { map &block, [EMAIL PROTECTED] }
multi sub map(&block, [EMAIL PROTECTED]) { ... }
If I call map like:
map {...} @a, @b, @c;
then I would expect the block to be called three times with @a, @b and @c as
the respective arguments.
I think the problem I have with this is that unless I missed something, the
default prototype for a block is [EMAIL PROTECTED] If slurpiness works as
described, then
$func = { [EMAIL PROTECTED] }
$func.(@array)
doesn't return the length of the array, but the numification of its first
element.
It seems to me that a slurpy parameter spec should simply say "Grab the
rest of the arguments and stick 'em in this array/hash", a function's caller
should control the flattening of a particular array argument, not the thing it
calls.
One of us has obviously misread the appropriate Apocalypse/Synopsis/Exegesis. I
have the horrible feeling that it's probably me, but I do think that the
interpretation I propose is the least surprising and most useful.
By the way, if flattening that way, what's the prototype for zip? We can after
all do:
zip @ary1, @ary2, @ary3, ... @aryn
Re: Elimination of Item|Pair and Any|Junction
Autrijus Tang <[EMAIL PROTECTED]> writes:
> On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
>> I dunno. I'm inclined to say that it should default to Item|Pair, and
>> let people say Any explicitly if they really want to suppress autothreading.
>> Otherwise conditionals and switches are going to behave oddly in the
>> presence of "accidental" junctions.
>
> Okay. However, in that view, I suspect many builtins will be defined on
> Item|Pair, for example &perl, &clone, &id, as well as various coercion
> builtins. Considering that builtins are Code objects but not Routines,
> maybe they, too, should default to Item|Pair -- except the ones that
> operates on junctions, of course.
>
> This leads me to think that maybe users don't really need to write down
> the two junctive types, under the hierarchy below:
>
> - Object
> - Any
> - Item
> - ...pretty much everything
> - Pair
> - Junction
> - num, int, str...
>
> Since junctions are still boxed objects, having the Object type to
> effectively mean Any|Junction seems natural ("everything is an object").
>
> Also, since Any unifies Item and Pair, the rule for implicit types of
> argument becomes:
>
> sub ($x) { }# Item $x
> -> $x { } # Any $x- i.e. Item|Pair but not Junction
> { $^x } # Any $x- i.e. Item|Pair but not Junction
Maybe there's a case for introducing Bundle types, akin to CPAN bundles. These
would be types only in the very losest sense, that could be used in function
prototypes to stand for particular bundles of types. So instead of Any being in
the class hierarchy where you propose it'd be a bundle that expanded to the
equivalent of doing:
any(Object.all_subclasses.grep -> $class { !$class.does(Junction) })
That way we get to arrange the class hierarchy in the way that makes the most
sense conceptually, but slice still slice it appropriately for Type
specifiers.
Just a thought.
Re: Exposing the Garbage Collector (Iterating the live set)
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 7/26/05, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> wrote:
>> Piers Cawley wrote:
>> > I would like to be able to iterate over all the
>> > objects in the live set.
>>
>> My Idea actually is to embedd that into the namespace syntax.
>> The idea is that of looking up non-negativ integer literals
>> with 0 beeing the namespace owner.
>>
>>for ::Namespace -> $instance
>>{
>> if +$instance != 0 { reconfigure $instance }
>>}
>
> Oh, so a namespace can behave as an array then. Well, to avoid
> auto-flattening problems in other, more common places, we ought to
> make that:
>
> for *::Namespace -> $instance {...}
>
> However, this is very huffmanly incorrect. First of all, what you're
> doing may take a quarter of a second or more for a large program
> (which isn't a short amount of time by any means). Second, the fact
> that you're using it means you're doing something evil. Third, only a
> fraction of 1/omega perl programmers will be using this feature.
> Therefore, it should probably look like:
>
> use introspection;
> for introspection::ALL_INSTANCES(::Namespace) -> $instance {...}
And if my proposal or something like it were accepted, the implementation could
simply look like:
module introspection {
class Class is extended {
method all_instances($class:) {
fail unless $*PLATFORM.GC.can_iterate_over_liveset;
$*PLATFORM.GC.grep -> $instance { $instance.isa($class) }
}
}
sub ALL_INSTANCES($class) {
$class.all_instances
}
}
The point about my proposal to have the garbage collector or something like it
expose methods to iterate over the live set isn't that it's syntactically
gorgeous, but that it's a useful minimal behaviour that can be used to
implement nicer syntaxes which can be loaded as required. If we're going to
allow such reflective stuff (on platforms that can do it) then there needs to
be some minimal core functionality that other modules can use. The point about
iterating over the live set is that it's essentially free until you use it; the
garbage collector must *already* hold onto the information needed to do the
iteration.
Re: Do slurpy parameters auto-flatten arrays?
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 7/26/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> are the following assumptions correct?
>>
>> sub foo ([EMAIL PROTECTED]) { @args[0] }
>>
>> say ~foo("a", "b", "c"); # "a"
>
> Yep.
>
>> my @array = ;
>> say ~foo(@array);# "a b c d" (or "a"?)
>> say ~foo(@array, "z"); # "a b c d" (or "a"?)
>
> "a" for both of these. The *@ area behaves just like Perl 5's calling
> conventions. I could argue for never auto flattening arrays, but then
> there'd really be no difference between @ and $.
>
>> say ~foo([EMAIL PROTECTED]); # "a"
>> say ~foo(*(@array, "z"));# "a"
>
> Hmm, *(@array, "z")... what does that mean? Whatever it means, you're
> correct in both of these. In the latter, the @array is in a
> flattening context, so it gets, well, flattened.
>
>> sub bar ([EMAIL PROTECTED]) { [EMAIL PROTECTED] }
>>
>> say bar(1,2,3); # 3
>> say bar(@array); # 1 (or 4?)
>
> 4
Wha? And I mean that sincerely. That's cockeyed. Surely a [EMAIL PROTECTED] in
the
signature simply says 'gather up the rest of the args and stick 'em in this
list'. In this case @array is a single argument, so @args should be equal to
[EMAIL PROTECTED] If I'm calling the function and I want @array to be treated as
anything but a single argument I use [EMAIL PROTECTED]
>> say bar(@array, "z");# 2 (or 5?)
>
> 5
Double wha? That's even worse.
Do you claim that
say bar('z', @array)
also emits 5? Ick.
>> say bar([EMAIL PROTECTED]);# 4
>
> Yep.
So how *do* I pass an unflattened array to a function with a slurpy parameter?
Re: Exposing the Garbage Collector
"TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> Let's say I have a class, call it Foo which has a bunch of attributes, and
>> I've
>> created a few of them. Then, at runtime I do:
>>eval 'class Foo { has $.a_new_attribute is :default<10> }';
>> Assuming I've got the syntax right for defaulting an attribute,
>
> I think you need a 'class Foo is extended' to re-open the class.
> Otherwise you produce a redefinition error if the scope you call
> eval in already contains---or is that extains because of the name
> search beeing *outwards*---one you start from scratch.
Oh for heaven's sake! That's the last time I go trying to come up with concrete
examples for this sort of thing. Of course, you're right, I should have said
'is extended', but if I were doing it for real, the eval would fail and I'd
have a meaningful error message.
[ An explanation of why this particular case doesn't require iterating over the
live set ]
I really shouldn't go picking concrete examples that can be worked around
should I? Suffice to say that sometimes (say for debugging purposes, or program
analysis -- Smalltalk can do some cunning typer inferencing tricks by examining
the live set for instance) I would like to be able to iterate over all the
objects in the live set. ISTM that exposing the Garbage Collector at the
Language level is the neatest way of doing this (or coming up with something
like Ruby's ObjectSpace, but conceptually I reckon the GC is the right place to
hang it).
Exposing the Garbage Collector
Let's say I have a class, call it Foo which has a bunch of attributes, and I've
created a few of them. Then, at runtime I do:
eval 'class Foo { has $.a_new_attribute is :default<10> }';
Assuming I've got the syntax right for defaulting an attribute, and lets assume
I have, the Perl runtime needs to chase down every instance of Foo or its
subclasses and add an attribute slot (adding a method to a class is nowhere
near as interesting, because every instance of the class shares a single class
object).
One way to do this is for a class to keep track of all its instances, which is
all very well until you start subclassing because subclasses have to both keep
track of their instances and inform their superclasses about any new instances,
which seems an awfully heavyweight thing to have to do just to be ready for the
occasional programmer like me who wants to develop classes in an image based
IDE or someone else who wants to add a role to a class at runtime or
whatever. Also, the class's links to its instances needs to be week, otherwise
you end up with instances that never get collected, which isn't good.
It seems to me, that the way to get at all the instances of a class is to ask
the Garbage Collector to do the heavy lifting for us, and ideally I'd like to
see this exposed at the Perl level. It doesn't really have to expose that many
methods of course -- a simple map/grep would do nicely, then it'd be possible
to write, say:
class Class {
method all_instances ($class:) {
$*GC.grep {$^obj.isa($class)}
}
}
Note that, *of course* this is slow, but I suggest that this sort of thing
should be slow (or, at the very least, you shouldn't require everything else to
pay a runtime cost just to allow people to use reflective tools like this).
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Sam Vilain <[EMAIL PROTECTED]> writes: > Larry Wall wrote: > > > Users of the class includes people subclassing the class, so to them > > > they need to be able to use $.month_0 and $.month, even though there > > > is no "has $.month_0" declared in the Class implementation, only > > > "has $.month". >> We thought about defining the attribute variables that way, >> but decided that it would be clearer if they only ever refer to >> real attributes declared in the current class. > > Clearer in what way? > > This implies that you cannot; > >- refactor classes into class heirarchies without performing > code review of all methods in the class and included roles. That's why it's generally a bad idea to use the C<$.whatever> forms outside your basic accessor methods. >- "wrap" internal attribute access of a superclass in a subclass Which is why it's generally a bad idea to use the C<$.whatever> forms outside your basic accessor methods. > This in turn implies that the $.foo syntax is, in general, bad > practice! Yup.
Re: What do use and require evaluate to?
Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Jul 12, 2005 at 08:48:41PM +0300, Gaal Yahas wrote: > : I propose to throw away the filesystem coupling, and map from a more > : general name of the bit of code we are requiring to a more general > : description of which instance of it we actually got. Once modules return > : interesting values, it might be useful to keep a copy of that value > : somewhere on the value side of %*INC: or else turn it inside out and > : stipulate that a standard field in the Module object is where you got > : this particular module. > > Yes, that's basically what I was mumbling about in my response. Now just > make sure %*INC is lexically scoped. > > : Probably, %*INC values should be weak references. > > Why should they be weak references? If %*INC is lexically scoped > then its entries represent this lexical scope's *real* references to > modules, and there's no need to weaken them, since it's not functioning > as some kind of cache. As long as this lexical scope sticks around, it > needs the modules it points to. As soon as the lexical scope is destroyed, > it doesn't need them any more. (Counting all closures over this lexical > scope as preserving its needfulness, until all such closures are dead > objects.) > > It's my conjecture that any explicit need for weak references probably > indicates a design failure somewhere. Something like the mis-scoping > of a reference variable, or maybe only something niggly like the > absence of a feature like "is cached" to encapsulate weak semantics. > Or maybe something as major as the lack of robust GC, in the case of > Perl 5... So long as there's some way of asking the garbage collector for everything in the live set so you can grep through them I'm sure you're right. Because almost everything is extensible at runtime a class is going to need some way of finding all its (and its subclasses) instances so it can update 'em when/if it's definition changes. I'm also trying to think how an object/database mapper could be made to work effectively without being able to keep track of all its managed objects, or would that just be handled through the use of 'is cached'?
Re: Dependency Injection
Larry Wall <[EMAIL PROTECTED]> writes: > On Wed, Jul 06, 2005 at 11:47:47PM +0100, Piers Cawley wrote: > : Or you could use a global, but globals are bad... > > Globals are bad only if you use them to hold non-global values. > In this case it seems as though you're just going through contortions > to hide the fact that you're trying to do something naturally > global. You might argue that a singleton object lets you hide the > implementation of the delegation from the world, but there's really not > much to implement if you just want to tell the world that whenever the > world says "LOGGER" the world is really delegating to "LOGGER::DBI". > Plus if you really need to reimplement you just vector the world > through "LOGGER::SELECTOR" or some such. The thing about the version where the language handles the vectoring through Logger, or whatever, is that you can retrofit such indirection without having to make sure all your code uses the global. For instance, in the Test::* world, there's a huge number of test modules that all play nicely because they work with Test::Harness, and that's fine until you reach the point where you want to specialize Test::Harness itself (say you want to write a graphical test runner). With the global variable approach, you have to alter everything that uses Test::Harness, with an injection approach, you only have to make changes to Test::Harness itself. Hmm... thinking about this a little further, the interface I proposed can't be as automagical as simply loading a class that injects into your injectable class because said class could well inherit from another injecting class. You would have to make it a two step process like: use InjectableClass; use InjectingClass; InjectableClass.inject_with(InjectingClass); What I'm after is another way to hide implementation details from client classes and allow programmers to write natural code. > One nice thing about a variable is that you're guaranteed to > be able to temporize it: > > temp $*LOGGER = pick_a_logger(); I'm not sure that, in the particular case, that's all that useful. It'd be cool if, say in a debugging situation, I could say that, from now on, all messages to Logger from class Foo are actually dispatched to InstrumentedLogger, and then to turn it off again, but I'm not sure how I'd do that with a global. $Package::Name::OUR::*LOGGER = ::InstrumentedLogger perhaps?
Dependency Injection
So, I got to thinking about stuff. One of the more annoying things about
writing nicely decoupled objects and applications are those occasions where you
want an object to be able to create objects in another class. Say you've
provided a singleton interface to your logging system. The naive implementation
goes something like:
require Logger;
has $.logger;
method logger { $.logger //= Logger.new }
method whatever {
./logger.debug("About to do stuff");
.do_some_stuff;
./logger.debug("Did stuff");
...
}
But that's problematic because we've backed knowledge of the particular class
that handles logging into our class. The bad solution to this is to subclass
our class if we want a different Logger class (that conforms to the same
interface). A slightly better solution is to parametrize the logger class
name, probably with a class variable -- but doing that means you have to
remember to set the variable for every class you use. Or you could use a
global, but globals are bad...
It'd be really cool if you could essentially write the naive implementation
above and have your application/test/webserver harness decide which particular
class will be taken to be the concrete implementation. Something like this:
role Logger is Injected {
method debug {...}
method info {...}
...
}
Logger::DBI does Logger { ... }
Logger::Debugger does Logger { ... }
Then the harness that actually sets up the application would simply do
use Logger::DBI :dsn<...>, :user<...>, :password<>
and Logger::DBI would install itself as the default Logger class.
The question is, how does one write Injected to make this work? Or what
features do we need to be able to write Injected? Thinking about this, it
shouldn't be too hard to implement 'Injected' in Perl 5:
sub Injected::AUTOLOAD {
no strict 'refs';
die "If something's already been instantiated you're screwed"
if ref($_[0]) or $Injected::injecting;
local $Injected::injecting = 1;
my $target_role = $_[0]
my @possibles = grep {/(.*)::$/ && $1->isa($target_role)} keys %::;
die "Too many possibles" if @possibles > 1;
if (@possibles) {
*{"$target_role\::} = *{$possibles[0]};
}
else {
my $default_package = $target_role->default_class;
eval "require $default_package" or die "Can't find a default package";
*{"$target_role\::"} = *{"$default_package\::"};
}
&{$target_role->can($AUTOLOAD)}(@_);
}
NB, that's completely untested code, but it, or something like it, should work.
Re: SMD is for weenies
Yuval Kogman <[EMAIL PROTECTED]> writes:
> On Fri, Jul 01, 2005 at 13:42:34 +1200, Sam Vilain wrote:
>> Yuval Kogman wrote:
>> >As I understand it SMD is now not much more than a mechanism to
>> >place a constraint on the MMD, saying that there can only be one
>> >method or subroutine with the same short name.
>> >Why is this the default?
>>
>> Otherwise you lose this quite useful warning if the signatures didn't
>> match;
>>
>> method foo redefined at ...
>
> That's a good point...
>
> I'm guessing that the default warnings should have a warning for MMD
> methods which append to a short name without appearing immediately
> after each other in the same file.
>
>> I agree with you MMD is very cool, and I use it a lot. But I don't
>> mind clarifying the intent with "multi"; this "overloading" is
>> considered by some to be surprising to new programmers.
>
> Prepending 'mutli' is not a problem when I have to type it. It's a
> problem when others won't type it. When 90% of the module code I'll
> be using is not MMD compatible, because MMD is not the default, I
> can't specialize other people's code without editing it (at runtime
> or at the source level).
>
> Overloading won't happen unless people overloading semantics are
> introduced, and that's exactly what I'd like to do to other people's
> code occasionally.
Then write yourself a module, call it 'multiplicity' say, which would allow you
to say
use multiplicity;
sub foo (...) {...} # foo is a multimethod, even if there's already a 'SMD'
# foo in existence.
It shouldn't even be that hard, just macroize sub/method/whatever to become
multis that first check if there's already a singly dispatched sub with the
same name and promoting to multi status if possible.
Of course, if you use something like that, you're taking the risks on your own
head, but you knew that as soon as you typed 'use multiplicity'.
The important thing is that the dispatch and reflection system should be
flexible enough to allow you to write something like this.
Re: OO magic (at least for me)
BÁRTHÁZI András <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm wondering, if it's possible with Perl 6 or not?
>
> class MyClass {
>
> method mymethod($par) {
> say "mymethod called!";
> }
>
> }
>
> class ExClass is MyClass {
>
> mymethod(12);
>
> }
>
> #> pugs myprog
> mymethod called!
>
> I would like to use mymethod to add ExClass some methods, etc.
>
> ///
>
> Just another problem, related to the above:
>
> class MyClass {
>
> method whenmother() {
> say "MyClass is parent now!!!";
> say "Her child name is: " ~ ;
> }
>
> }
>
> class Child is MyClass {
> }
>
> #> pugs myprog
> MyClass is parent now!!!
> Her child name is: Child
I'd like to hope so. Actually, I don't think that this *specific* functionality
should be in the core, but the ability to implement it (just needs a unified
notifcation scheme that gets tickled when new classes, methods, subs, packages,
etc, get added to the image -- more detailed behaviour is a SMOP).
Re: AUTLOAD and $_
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 6/20/05, chromatic <[EMAIL PROTECTED]> wrote:
>> On Mon, 2005-06-20 at 12:11 +0200, Juerd wrote:
>>
>> > I think there exists an even simpler way to avoid any mess involved.
>> > Instead of letting AUTOLOAD receive and pass on arguments, and instead
>> > of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its
>> > thing, and then have *perl* call the sub?
>>
>> Who says AUTOLOAD will always either call a loaded sub or fail?
>
> Uh, what else can it do? It doesn't have to load a sub to return a
> code reference.
For myself, I'd like to see AUTOLOAD with a signature along the lines of:
sub AUTOLOAD (Symbol $sym, ArgumentCollection $args, Continuation $cc)
returns (Code | Pair)
{
...
}
This presupposes a deal of support infrastructure, but also provides
flexibility. For the 'NullObject' case, you'd simply do C<$cc()> to return
directly to the caller, skipping over whatever Perl is up to.
'ArgumentCollection'? Well, that's the activation record and I'd like to see it
allowing methods like:
my ($foo, $bar, $baz) =
$args.parse_signature('Int $foo, String $bar, Code $baz')
That way code could probe the argument structure in order to do its own
dispatch.
As for returning a coderef or a pair. If you return a coderef, Perl simply
calls it and throws it away. Returning a pair, with a name (long or short) as
the key and the code as the value would make perl bind the code to the given
name (which should be compatible with the name passed in in the first place).
Details left as an exercise for the interested reader.
Re: proposal: binding with a function
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes:
> As I've said before, Perl supports `alias`--it's just spelled `:=`.
Here's a rubyish idiom:
my &old_behaviour := &function;
&function := sub { try_some_stuff || &old_behaviour }
Except, with binding it doesn't work like that, you end up with an infinite
loop.
Re: When can I take given as read?
Carl Franks <[EMAIL PROTECTED]> writes:
>> sub factorial (Int $n is topic) {
>> return 1 when 0;
>> return $n * factorial $n;
>> }
>
> hmm, could we write...
>
> sub foo (Class $self is topic: +$foo, +$bar) {
> .method;
> }
>
> to avoid having to use ./
> ?
Yay!
When can I take given as read?
Suppose I have a simple, single argument recursive function:
sub factorial (Int $n) {
return 1 if $n == 0;
return $n * factorial $n;
}
Can I write that as:
sub factorial (Int $n:) {
return 1 when 0;
return $n * factorial $n;
}
NB. Yes, I know it's a pathological example.
Re: nested subs
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 6/16/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
>> So, I was about to write the following test for Pugs:
>>
>> sub factorial (Int $n) {
>> my sub factn (Int $acc, $i) {
>> return $acc if $i > $n;
>> factn( $acc * $i, $i+1);
>> }
>> factn(1, 1);
>> }
>>
>> When I thought to check the apocalypses and exegeses and, what do you know, I
>> couldn't find any evidence that nested named functions like this were legal.
>>
>> So, are they legal?
>
> Yep. And they work just as if you had used an anonymous sub there--it
> closes over lexicals and everything.
I should bloody well hope so too.
nested subs
So, I was about to write the following test for Pugs:
sub factorial (Int $n) {
my sub factn (Int $acc, $i) {
return $acc if $i > $n;
factn( $acc * $i, $i+1);
}
factn(1, 1);
}
When I thought to check the apocalypses and exegeses and, what do you know, I
couldn't find any evidence that nested named functions like this were legal.
So, are they legal?
And yes, I know there are other ways of doing this, but I like the lack of
sigils on the function when you do it this way.
Re: Binding slices
Luke Palmer <[EMAIL PROTECTED]> writes: > On 6/14/05, Piers Cawley <[EMAIL PROTECTED]> wrote: >> Following a conversation with Chip on IRC, is this >> >> my @y := @foo[0..][1]; >> >> legal? > > Definitely not. But it sure would be nice if this: > > my @y := @foo[0...][1]; > > were. I think that's what I meant to write :)
Binding slices
Following a conversation with Chip on IRC, is this my @y := @foo[0..][1]; legal?
Re: How much do we close over?
Rod Adams <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>
>>Chip and I have been having a discussion. I want to write:
>>
>>sub foo { my $x = 1; return sub { eval $^codestring } }
>>say foo()("$x");
>>
>>I claim that that should print 1. Chip claims it should throw a warning about
>>because of timely destruction. My claim is that a closure should close over
>>the
>>entire lexical stack, and not simply those things it uses statically. Chip
>>claims the opposite, arguing that timely destruction implies that this is
>>absolutely the right thing to do. It's also quicker.
>>
>>
> I'm going to have to side with Piers on this one. My feeling is that having a
> reference to a closure accessible in memory should keep all the possible
> lexicals it can access in memory as well. That said, I can the compiler
> optimizing memory consumption by destroying all the outer lexicals that it can
> prove will never be used by the inner closure. However, the presence of an
> eval' in the closure makes such a proof tenuous at best.
>
> On the other hand, one could easily view the eval as constructing yet another
> closure, and it's unclear if we wish for that closure to be able to "skip" the
> first level outer closure to directly access the 2nd level outer lexicals. In
> that respect, I could see things Chip's way.
>
> As for the warning, it should only be a warning if strictures are on, for
> using
> the now undeclared '$x' inside the eval.
>
>>But dammit, I'm doing runtime evaluation of code strings, I don't care about
>>quicker.
>>
>>If it's not the default can it please be mandated that there be some way of
>>doing:
>>
>>sub foo { my $x = 1; return sub is lexically_greedy {eval $^codestring} }
>>
>>in other words, some way of declaring that a subroutine wants to hang onto
>>every lexical it can see in its lexical stack, not matter what static analysis
>>may say.
>>
>>
>>
> Well, you could always do something like:
>
> sub foo { my $x = 1; return sub {my $x := $OUTER::x; eval $^codestring} }
>
> But I'm spending too much time in other languages lately to remember exactly
> how "$OUTER::x" is spelled for certain. One could probably even write a macro
> that auto-binds all the lexicals in the outer scope to the current scope.
Only if I actually know what variables which were within scope when that inner
sub was compiled are going to be used by my passed in code string. I really
don't want to have to write a macro to walk the OUTER:: chain in order to build
a something like:
sub { my $foo = $OUTER::foo;
my $bar = $OUTER::OUTER::bar;
...;
eval $^codestring }
Just to pull everything into scope.
And even if I could do that, what I actually want to be able to do is something
like this:
$continuation.bindings.eval_in_this_scope($^codestring);
Which can be done today in Ruby and which is one of the enabling technologies
for tools like Rails.
Re: How much do we close over?
Rob Kinyon <[EMAIL PROTECTED]> writes:
>> Piers Cawley said:
>> in other words, some way of declaring that a subroutine wants to hang onto
>> every lexical it can see in its lexical stack, not matter what static
>> analysis
>> may say.
>
> I'm not arguing with the idea, in general. I just want to point out
> that this implies that you're going to hold onto every single
> file-scoped lexical, leading to quite a bit of action-at-a-distance.
Well, duh. If eval string isn't a hearty pointer to the "This subroutine
deliberately takes advantage of action at a distance" then I don't know what
is.
> Maybe, instead, you should say "sub is lexical_stack(N)" where N is
> the number of scoping levels it will hold onto in addition to any
> lexical it actually refers to. I would have 0 be the innermost scope,
> 1 be the enclosing scope, etc.
Which is all very well, but you don't necessarily know how deep in the stack
you are. I want to be able to write something in such a way that evalling the
string works in exactly the same way as it would if I had just written a do
block in the first place.
sub foo { my $x; ...; return sub { do {...} } }
It's an introspection thing. Most of the time you don't want it, but sometimes
you do and we really shouldn't be making that impossible.
How much do we close over?
Chip and I have been having a discussion. I want to write:
sub foo { my $x = 1; return sub { eval $^codestring } }
say foo()("$x");
I claim that that should print 1. Chip claims it should throw a warning about
because of timely destruction. My claim is that a closure should close over the
entire lexical stack, and not simply those things it uses statically. Chip
claims the opposite, arguing that timely destruction implies that this is
absolutely the right thing to do. It's also quicker.
But dammit, I'm doing runtime evaluation of code strings, I don't care about
quicker.
If it's not the default can it please be mandated that there be some way of
doing:
sub foo { my $x = 1; return sub is lexically_greedy {eval $^codestring} }
in other words, some way of declaring that a subroutine wants to hang onto
every lexical it can see in its lexical stack, not matter what static analysis
may say.
Non-deterministic programming in Perl 6
So, the return in pointy sub thread got me thinking about useful uses of return
in pointy subs that involve being able to return multiple times. And this is
what I came up with, it's an implementation of 'choose':
my &give_up = sub { fail "Ran out of choices" }
sub choose ([EMAIL PROTECTED]) {
my &old_give_up = &give_up;
my $try = -> @choices {
if [EMAIL PROTECTED] { &give_up = &old_give_up; give_up }
else {
my ($choice, @newchoices) = *choices;
&give_up = -> { return $try(@newchoices) }
$choice;
}
}
$try(@all_choices);
}
How do you use that I hear you ask:
my $x = choose(1,3,5);
my $y = choose(1,5,9);
# say "Trying $x * $y"; # Uncomment for an insight into how this works.
give_up unless $x * $y == 15;
say "Found $x * $y = 15";
Yes, that is an artificial example.
If you can't use a returning pointy block more than once, then this becomes:
sub callcc (Code &block) { &block(&?CALLER_CONTINUATION) }
my &give_up = sub { fail "Ran out of choices" }
sub choose ([EMAIL PROTECTED]) {
callcc -> &cnt {
my $try = -> @choices {
if [EMAIL PROTECTED] { &give_up = &old_give_up; give_up }
else {
my ($choice, @newchoices) = *choices;
&give_up = sub { cnt($try(@newchoices)) };
$choice;
}
}
$try(@all_choices);
}
}
Tracing the flow of control in both these examples is left as an exercise for
the interested reader.
The only catch is, neither of them works in Pugs. Yet.
Re: return() in pointy blocks
Larry Wall <[EMAIL PROTECTED]> writes: > On Wed, Jun 08, 2005 at 10:51:34PM +, Luke Palmer wrote: > : Yeah, that's pretty. But that will bite people who don't understand > : continuations; it will bite people who don't understand "return"; it > : will even bite people who understand continuations, because they can > : be made in such an awkward form so easily. > > Right--we don't want mere mortals to be able to get at continuations > quite that easily, whether they think they want them or not. Shame. If you go monkeying with continuations without knowing what they do, then of course you deserve everything you have coming to you, but is that really any reason for making them hard to get at when you *do* need them? I'm not denying that they should be hard to get accidentally, but it would be good to know how to get them deliberately.
Re: return() in pointy blocks
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 6/8/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
>> > In other words, it outputs:
>> >
>> >Foo
>> >Foo
>> ># dies
>
> Yep. My mistake.
>
>> If that works, then I think it means we can write:
>>
>> sub call-with-current-continuation(Code $code) {
>> my $cc = -> $retval { return $retval }
>> $code($cc);
>> }
>>
>> Which I personally think is rather cute. Even if I can't quite bring myself
>> to
>> believe it's that simple...
>
> Yeah, that's pretty. But that will bite people who don't understand
> continuations; it will bite people who don't understand "return"; it
> will even bite people who understand continuations, because they can
> be made in such an awkward form so easily.
Having worked through the little and seasoned Schemers, I'm actually at the
point where I can happily think that 'return' is deep scary magic. What I
*want* is a 'proper' continuation, but this would have been close enough for
government work until the real ones came along.
> Currently call/cc is done like this:
>
> sub call_with_current_continuation(&code) {
> &code(&?CALLER_CONTINUATION);
> }
>
> But that might be broken in pugs at the moment.
Doesn't that call code with the continuation of the caller of
call_with_current_continuation, when it *should* call &code with the
continuation of call_with_current_continuation?
Re: return() in pointy blocks
"TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> [..] then I think it means we can write:
>> sub call-with-current-continuation(Code $code) {
>> my $cc = -> $retval { return $retval }
>
> For the records: the return here is the essential ingredient, right?
> Without it the block would be evaluated or optimized away to an undef
> or some such.
Yes. Without the return you just get block that returns the value its last
expresion to the place from which it (the pointy sub) was called, rather than
to the place that the subroutine that created it was called from.
>
>> $code($cc);
>> }
>> Which I personally think is rather cute.
>
> Me too!
>
>
>> Even if I can't quite bring myself to
>> believe it's that simple...
>
> I have convinced myself.
> How can I be of assistance on your side?
How's your Haskell?
Re: return() in pointy blocks
Piers Cawley <[EMAIL PROTECTED]> writes:
> "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> writes:
>
>> Piers Cawley wrote:
>>> My preference is for:
>>> Boo
>>> Boo
>>> Can't dereferene literal numeric literal 42 as a coderef.
>>
>> How do you reach the second 'Boo'? Iff -> does not create a Sub
>> but a Block instance then Luke's code can be interpreted as a
>> much smarter version of
>
> I really wish you'd quote in more detail, it makes it a real PITA to go back
> and find the explanatory code.
>
> sub foo () {
> return -> { return 42 }
> }
>
> my $code = foo();
> # ^--- continuations points to the RHS of the assignment
> say "Boo!";
> $code();
>
> So, this is what happens.
>
> 1. foo() returns a coderef to the RHS of the assignment.
> 2. The coderef gets assigned to $code.
> 3. say "Boo!"
> 4. We invoke the coderef, which returns 14 to continuation which was current
>when it was created.
> 5. That means 42 gets returned to the RHS of the assignment
> 6. say "Boo!"
> 7. Try to invoke the literal 42.
> 8. Die.
>
> In other words, it outputs:
>
>Foo
>Foo
># dies
If that works, then I think it means we can write:
sub call-with-current-continuation(Code $code) {
my $cc = -> $retval { return $retval }
$code($cc);
}
Which I personally think is rather cute. Even if I can't quite bring myself to
believe it's that simple...
Re: return() in pointy blocks
"TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
>> My preference is for:
>> Boo
>> Boo
>> Can't dereferene literal numeric literal 42 as a coderef.
>
> How do you reach the second 'Boo'? Iff -> does not create a Sub
> but a Block instance then Luke's code can be interpreted as a
> much smarter version of
I really wish you'd quote in more detail, it makes it a real PITA to go back
and find the explanatory code.
sub foo () {
return -> { return 42 }
}
my $code = foo();
# ^--- continuations points to the RHS of the assignment
say "Boo!";
$code();
So, this is what happens.
1. foo() returns a coderef to the RHS of the assignment.
2. The coderef gets assigned to $code.
3. say "Boo!"
4. We invoke the coderef, which returns 14 to continuation which was current
when it was created.
5. That means 42 gets returned to the RHS of the assignment
6. say "Boo!"
7. Try to invoke the literal 42.
8. Die.
In other words, it outputs:
Foo
Foo
# dies
>
> sub foo()
> {
> enter: 42;
> if $?RETURN_LABEL { goto $?RETURN_LABEL }
> return;
> }
>
> say "Boo!";
> say goto foo::enter; # goto sets up $?RETURN_LABEL
> say "after goto";
>
> which of course prints
>
> Boo
> 42
> after goto
>
> The smartness is in the value that &prefix:{'->'} returns
> while in the snippet above it is explicitly coded.
>
> Or do I completely misunderstand the distinction between
> blocks and closures?
It seems so.
Re: return() in pointy blocks
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 6/7/05, Matt Fowles <[EMAIL PROTECTED]> wrote:
>> On 6/7/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> > sub foo (Code $code) {
>> > my $return_to_caller = -> $ret { return $ret };
>> >
>> > $code($return_to_caller);
>> > return 23;
>> > }
>> >
>> > sub bar (Code $return) { $return(42) }
>> >
>> > say foo &bar; # 42 or 23?
>> >
>> > I think it should output 42, as the return() in the pointy
>> > block $return_to_caller affects &foo, not the pointy block.
>> > To leave a pointy block, one would have to use leave(), right?
>>
>> I don't like this because the function bar is getting oddly
>> prematurely halted.
>
> Then let's put it this way:
>
>sub foo () {
>for 0..10 {
>when 6 { return 42 }
>}
>return 26;
>}
>
> And if that didn't do it, then let's write it equivalently as:
>
>sub foo () {
>&map(-> $_ { return 42 }, 0..10);
>return 26;
>}
>
> Do you see why the return binds to the sub rather than the pointy now?
>
> Also, we're going to be avoiding the return continuation problem with:
>
>sub foo() {
>return -> { return 42 };
>}
>
>my $code = foo();
>say "Boo!";
>$code();
>
> Says not:
>
>Boo
>Boo
>Boo
>...
>
> But:
>
>Boo
>Can't return from subroutine that already returned at line 2.
My preference is for:
Boo
Boo
Can't dereferene literal numeric literal 42 as a coderef.
Actually, my preference is for not writing such silly code in the first place,
but there you go.
Re: return() in pointy blocks
Ingo Blechschmidt <[EMAIL PROTECTED]> writes:
> Hi,
>
> sub foo (Code $code) {
> my $return_to_caller = -> $ret { return $ret };
>
> $code($return_to_caller);
> return 23;
> }
>
> sub bar (Code $return) { $return(42) }
>
> say foo &bar; # 42 or 23?
>
> I think it should output 42, as the return() in the pointy
> block $return_to_caller affects &foo, not the pointy block.
> To leave a pointy block, one would have to use leave(), right?
That's how it's defined in the relevant Apocalypse. And that's how I hope it'll
stay.
Re: Perl6 and support for Refactoring IDE's
Stevan Little <[EMAIL PROTECTED]> writes:
> On May 25, 2005, at 5:39 AM, Piers Cawley wrote:
>> One of the 'mental apps' that's been pushing some of the things I've been
>> asking for in Perl 6's introspection system is a combined
>> refactoring/debugging/editing environment for the language.
>
> Maybe I have been reading too much about Smalltalk meta-classes lately, but in
> doing some draft ideas of the Perl6 meta-model for Pugs, I realized that given
> a really solid class/metaclass introspection system and access to the
> interpreter level meta-meta-classes, it would be possible to easily write a
> class browser much like Smalltalk.
Yes. The application in my head looks very a Smalltalk environment. The way I
see it working is that the language itself has a bunch of minimal hooks that
get triggered by various phases of compilation etc. Your editor then becomes
something that instruments the compiler in such a way that loading a file for
editing compiles it, but the compilation process hangs populates the data
structures you need for editing. So, when you go to edit, say:
class Collection {
method inject_into ($self: $initial_value is copy, *&block) {
$self.each
:{ $initial_value = &block($initial_value, $_) }
return $initial_value;
}
}
You'd end up with a Class object which would have all sorts of interesting
things added to it, including collections of instance variables, class
variables, methods etc. Methods would have metadata about the environment in
which they were evaluated (so when you edit a method you could recompile it in
the correct environment), the file they're found in, their source code
(possibly attributed to allow for syntax highlighting), the resulting AST,
etc. Once you have such a rich set of metadata to hand, it becomes a simple
matter of programming to add all sorts of handy features, refactorings,
breakpoints, whatever...
The point being that you don't really need a massive amount of support from the
core language to do all this. At a pinch you can take advantage of the fact
that the grammar is replaceable and core classes are extensible (and if they're
not, you just stick them in boxes for the editor's purposes).
> And to extend that to also be a refactoring browser would require the
> meta-meta-class system to be able to generate and emit code, which, if we
> properly model the meta-meta-classes should also be fairly simple as well.
We've got eval for that. Assuming you can do eval with arbitrary bindings (and
if necessary you can drill down to parrot for it) you just do something like:
Class.can('fred').environment.eval($freds_new_sourcecode)
Of course, if you alter a macro you're going to have to reevaluate pretty much
all the source code, but so what?
> And of course all this is even simpler if the interpreter is written in Perl6
> (although the cyclical nature of that can be dizzying at times).
It really doesn't have to be. It'd be nice, but not necessary. You just have to
make sure you can extend the runtime using perl. And macros already do that.
> However adding debugging support to this is another matter all together, and
> it
> is only partially useful to the non-OO programmer.
Not that hard to be honest. The same instrumented interpreter techniques can be
used to write the debugger.
Re: Virtual methods
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Wed, 2005-05-18 at 10:51, Luke Palmer wrote:
>
>> Except that mixins like this always treat things as "virtual".
>> Whenever you mixin a role at runtime, Perl creates an empty, anonymous
>> subclass of the current class and mixes the role in that class. Since
>> roles beat superclasses, you'll always override your own methods.
>
> Ok, good point (I've even pointed that out to others before, and I
> missed it)...
>
> I know that's the way it works, but now it's really bothering me.
>
> There are many gotchas that fall out of that. For example, you might
> have a special role that overrides .print to handle structured data, so
> your code says:
>
> my Foo $obj;
> given $obj {
> when StructuredPrintRole {
> # Someone's already taken care of it, possibly
> # adding a more specialized role, so leave it
> # alone.
> }
> default {
> # Add in a boring default handler
> $obj does StructuredPrintRole
> }
> }
> $obj.print($structured_data);
>
> Woefully, you lose is Foo happens to be DECLARED with
> StructuredPrintRole, and it overrode print. But, if it just inherited a
> print(), then it works. In other words, this code will mysteriously fail
> the second someone innocently adds a print method to Foo!
>
> Action at a distance... my head hurts.
Aaron, you do realise that that's quite obscene code don't you? I mean, you're
doing a case statement based on the type of its topic, and to compound the
evils, you're changing how your topic's print method works *everywhere* simply
to get your 'special' print behaviour. If you must do something like this (and
call it print), then write it as a multimethod or something.
Re: Perl6 and support for Refactoring IDE's
Luke Palmer <[EMAIL PROTECTED]> writes: > On 5/6/05, J Matisse Enzer <[EMAIL PROTECTED]> wrote: >> I've become scared that if Perl is to continue to be viable for large, >> complex, multi-developer projects that the tools need to serious >> catch-up with what is available for Java, for example. Things like: >> >>- Refactoring Support (see http://www.refactoring.com/) >>- CVS and/or Subversion integration >>- Support for integrating regression tests and auto-building >>- Automated syntax and dependency checking >> >> I've been using Eclipse, with the EPIC plugin >> (http://e-p-i-c.sourceforge.net/) and so far I like it. It uses >> Devel::Refactor to support "extract subroutine", but a lot more is >> needed to match what you can do with Java these days. >> >> What are others' thoughts on this? > > I think you're absolutely right. Perl should have an IDE with > Eclipse-like context-sensitivity and refactoring support. However, > it's hardly in Perl's philosophy or interest to bless one. > > One thing is for sure. Perl 6 is providing enough introspection and > parsing capabilities to make it possible to write a context-sensitive > IDE, unlike Perl 5 (well, Perl 5 made it *possible*, I suppose, but > Perl 6 will make it obvious). Perl 6 is exposing its whole grammar at > the language level, so you can say "give me a syntax tree for this > chunk of code" and it will. Even if there are modules that change the > syntax with macros (though your editor might have trouble > understanding what the macros mean). One of the 'mental apps' that's been pushing some of the things I've been asking for in Perl 6's introspection system is a combined refactoring/debugging/editing environment for the language. One of the annoyances of the 'only perl can parse Perl' thing is not so much the truth of the statement, but that perl 5 doesn't allow you to ask about the parsed code in ways that would be useful for an IDE. Perl 6 promises to change that -- it should be possible to either write a fantastic Perl 6 IDE in perl itself, or to write a codegrokker object that can be used by some pre existing IDE. > In other words, Perl 6 is open to the possibility of such an IDE, and > is going to provide the machinery necessary to build a really good > one, but I doubt it will become a development milestone. What about the debugger?
Re: turning off warnings for a function's params?
David Storrs <[EMAIL PROTECTED]> writes:
> I image we've all written logging code that looks something like this
> (Perl5 syntax):
>
> sub foo {
> my ($x,$y) = @_;
> note("Entering frobnitz(). params: '$x', '$y'");
> ...
> }
>
> This, of course, throws an 'uninitialized value in concatenation or
> string' warning when your test suite does this:
>
> is( foo(undef, undef), undef, "foo(undef, undef) gives undef" );
>
> In a testing environment, I don't want to see this warning.
>
> In a
> production environment, I do. Furthermore, when I want it gone, I
> want it gone from every instance of C, without having to change
> something in every location. I suppose I could change all my logging
> calls to look like this:
>
> {
> if ( $DEBUG ) { no warnings 'uninitialized'; note(""); }
> else { note(""); }
> }
>
> But that's really ugly, takes up a lot of space, is confusing, and is
> redundant.
>
> How would I best solve this problem in Perl6?
Write an appropriate macro:
warns(is( foo(undef, undef), undef, "foo(undef, undef) gives undef"),
"uninitialized value in concatenation or string");
That way you get to ensure that the warning gets thrown correctly if undef is
passed, but you don't get the warning mucking up your test output.
Re: Blocks, continuations and eval()
Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Apr 12, 2005 at 11:36:02AM +0100, Piers Cawley wrote: > : wolverian <[EMAIL PROTECTED]> writes: > : > : > On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote: > : >> I cannot say how much Perl6 will expose to the high level language. > : > > : > That is what I'm wondering about. I'm sorry I was so unclear. > : > > : >> Can you tell me what your idea of a "scope" is? I'm thinking a > : >> continuation, and if that is what you are thinking, I'm thinking the > : >> answer to your question is yes. > : > > : > Yes. I want to know how Perl 6 exposes continuations, and how to get one > : > for, say, the current lexical scope, and if it has a method on it that > : > lets me evaluate code in that context (or some other way to do that). > : > : As I understand what Larry's said before. Out of the box, it > : doesn't. Apparently we're going to have to descend to Parrot to write > : evalcc/letcc/your-preferred-continuation-idiom equivalent. > > We'll make continuations available in Perl for people who ask for > them specially, but we're not going to leave them sitting out in the > open where some poor benighted pilgrim might trip over them unawares. Oh goody! Presumably we're initially talking of a simple 'call_with_current_continuation'?
Re: Blocks, continuations and eval()
wolverian <[EMAIL PROTECTED]> writes: > On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote: >> I cannot say how much Perl6 will expose to the high level language. > > That is what I'm wondering about. I'm sorry I was so unclear. > >> Can you tell me what your idea of a "scope" is? I'm thinking a >> continuation, and if that is what you are thinking, I'm thinking the >> answer to your question is yes. > > Yes. I want to know how Perl 6 exposes continuations, and how to get one > for, say, the current lexical scope, and if it has a method on it that > lets me evaluate code in that context (or some other way to do that). As I understand what Larry's said before. Out of the box, it doesn't. Apparently we're going to have to descend to Parrot to write evalcc/letcc/your-preferred-continuation-idiom equivalent.
Re: return of copies vs references
Darren Duncan <[EMAIL PROTECTED]> writes: > At 7:10 AM +0100 3/29/05, Piers Cawley wrote: >>Doesn't that rather depend on the type of the attribute? Personally, if I get >>an object back from accessor method then I expect that any modifications of >>that object's state will be seen the next time I look at the results of that >>accessor method. This is a direct result of the way reference types work, and >>the world is a better place because of it. If you want a (deep) copy of the >>returned object you should say so: >>my $res = $object.attribute.clone; > > I recanted what you're replying to last week. Essentially, I agree with you > that references of non-scalar values should be returned by default, and that > the method must do an explicit copy if that's what they want returned. Things > are much simpler that way, and its how Perl 5 worked. -- Darren Duncan Bah! Must start keeping up to date with the list again.
Re: return of copies vs references
Darren Duncan <[EMAIL PROTECTED]> writes: > At 11:26 PM -0700 3/16/05, Luke Palmer wrote: >> > For each of the above cases, is a copy of or a reference to the >>> attribute returned? For each, will the calling code be able to >>> modify $obj's attributes by modifying the return values, or not? >> >>Well if you're making accessors, why the heck are you making them >>private? But I can't really answer your question, because it depends on >>how you write the accessors. > > I am writing accessors to mediate with the attributes, which are all private, > and whose implementation may change over time. What I want, in the normal > case, is that calling code which invokes my methods will get a copy of > attributes which it can modify, that won't affect the original attribute > values. > > When I last asked a related question here, I was told that simply returning > an attribute will allow the caller to modify the original attribute by > default. I wanted to make sure this didn't happen. It is possible that > there was a misunderstanding regarding the previous question, and the default > action is in fact a copy. Doesn't that rather depend on the type of the attribute? Personally, if I get an object back from accessor method then I expect that any modifications of that object's state will be seen the next time I look at the results of that accessor method. This is a direct result of the way reference types work, and the world is a better place because of it. If you want a (deep) copy of the returned object you should say so: my $res = $object.attribute.clone;
Re: .method == $self.method or $_.method?
Larry Wall <[EMAIL PROTECTED]> writes:
> I've been thinking about this in my sleep, and at the moment I think
> I'd rather keep .foo meaning $_.foo, but break the automatic binding
> of the invocant to $_. Instead of that, I'd like to see a really,
> really short alias for $self. Suppose we pick "o" for that, short
> for "object". Then we get self calls of the form:
>
> o.frobme(...)
I really, really don't want to see .foo meaning anything but $_.foo, so how
about arranging things so that the invocant becomes $_ iff you don't give it a
name. So:
method whatever {
# $_ is whatever's invocant
}
method whosit ($self:) {
# $_ is unbound, so:
.this # fails
...
}
Note that this would also work for mappy things with pointy subs used to name
arguments.
method whatever {
map { .this } .list_of_contents; # Works, but is weird...
map -> $x { .do_something_with($x.result) } # .do_something uses the
# method's invocant.
}
Same applies to given:
method foo {
given .parent -> $p {
... # $_ is foo's invocant
}
given .parent {
... # $_ is the result of calling .parent
}
}
Re: [OT] Perl 6 Summary for 2004-10-01 through 2004-10-17
Aldo Calpini <[EMAIL PROTECTED]> writes: > Larry Wall wrote: >> I suppose if I were Archimedes I'd have climbed >> back out and shouted "Eureka", but as far as I know Archimedes never >> made it to Italy, so it didn't occur to me... > > well, Archimedes *was* italian. for some meaning of italian, at least. > he was born in Syracuse (the one in Sicily, not the one in the state of > NY obviously :-). he lived and studied in Egypt, but most of his life > was spent in Syracuse. granted, Sicily at that time was more a Greek > region than an Italian one as it is today, but well, geographically > speaking, it is in Italy. > > and of course, Venice was founded ~700 years after Archimedes death, so > he really had no chance of falling into your same canal. But the odds are good that at least one of the water molecules in said canal passed some of its time in Archimedes body (or one of its constituent atoms did).
Re: Iterators and C
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Thu, 2004-09-09 at 13:14, Larry Wall wrote:
>
>> So whereas Ruby's syntax actually tends to push you toward .each
>> iterators, Perl 6's syntax will be fairly neutral on the subject,
>> or maybe biased every so slightly away from method iteration by the
>> width of about one character:
>>
>> for @foo { ... }
>> @foo.each:{ ... }
>>
>> But then, a good Ruby programmer would have put a space where there's
>> a colon anyway, so maybe it's a wash. If I wanted to make it even
>> I'd pick something shorter than "each", I suppose. Except "all" is
>> already taken. I suppose there's something to be said for:
>>
>> @foo.for:{ ... }
>
> act any are ask cog cue did ere for get got has hop jet job kin
> let map mix net now one ore per pro put run set tag
>
> I won't describe why I think each one would be appropriate, since if
> it's not obvious, it's a bad choice ;-)
I find myself wondering if this is going to allow people to write
smalltalk style method selectors...
@foo.inject:0 into: -> $accum, $each { $accum + $each }
Re: Reverse .. operator
"Joe Gottman" <[EMAIL PROTECTED]> writes:
> In perl 6, the statement
>
> @foo = (1.. 5) ;
>
> is equivalent to
>
> @foo = (1, 2, 3, 4, 5);
>
>
>
> Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ? I know you can
> go
>
> @foo = reverse (1 ..5);
>
> but this has the major disadvantage that it cannot be evaluated lazily;
> reverse has to see the entire list before it can emit the first element of
> the reversed list. Would
>
> @foo = (5 .. 1 :by(-1));
>
> do the trick? If so, would the same trick work for
>
> @bar = ('e' .. 'a' :by(-1)); ?
@foo = 5.down_to(1)
Where down_to is
method Number::down_to ($self : Number $target) {
return if $self < $target;
return $self, ($self - 1).down_to($target);
}
You might have to do some monkeying around with a range object or
something to make it appropriately lazy, but that's a mere detail. Or
you could implement it as an operator. Or...
Re: S4: Can PRE and POST be removed from program flow?
John Siracusa <[EMAIL PROTECTED]> writes:
> On 9/3/04 6:45 PM, Damian Conway wrote:
>> John Siracusa wrote:
I don't see how we could prevent someone from clobbering the global
definitions of PRE and POST to be no-ops if they wanted to. Seems to
me that the whole point of putting the program in charge of its own
compilation is to let it be in charge of its own compilation, n'est pa?
>>>
>>>
>>> Hm, okay, but there'd still be the "call" (or whatever) to the overridden
>>> versions. I guess that is "no-op"ing them, but they're still technically in
>>> the program flow, unlike "disappearing macros" or #defines in C or whatever.
>>> Any facility for totally nuking them?
>>
>> macro PRE (&block) {""}
>> macro POST(&block) {""}
>
> Ah ha, I didn't realize macros could override/replace existing control
> structures. Okay, ship it! :)
They'd be no fun if they couldn't.
Re: This week's summary
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes: > Piers Cawley wrote: >> Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes: >>>Care to explain what those are, O great math teacher? >> What's a math teacher? > > It's the right^H^H^H^H^HAmerican way to say "maths teacher". You mean American and 'right' are not equivalent? Wow.
Re: This week's summary
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> writes: > The Perl 6 Summarizer wrote: >> The infinite thread >> Pushing onto lazy lists continued to exercise the p6l crowd (or at >> least, a subset of it). Larry said that if someone wanted to hack >> surreal numbers into Perl 6.1 then that would be cool. > > Care to explain what those are, O great math teacher? What's a math teacher?
Re: String interpolation
Damian Conway <[EMAIL PROTECTED]> writes:
> I can't say I'm keen on making {...} special in strings. I felt that the
> $(...) and @(...) were a much cleaner and more general solution. The
> prospect of backslashing every opening brace in every interpolated
> string is not one I relish.
Maybe we could write macros to provide a Lispish 'metaquoted'
environment for when one is writing template code which wouldn't
interpolate *anything* unless it was in C<$(...)> or C<@(...)>.
Re: String interpolation
Larry Wall <[EMAIL PROTECTED]> writes:
> On Tue, Jul 20, 2004 at 11:00:39PM -0700, chromatic wrote:
> : On Tue, 2004-07-20 at 19:35, Luke Palmer wrote:
> :
> : > The New Way (tm) to do that would probably be sticking a role onto the
> : > array object with which you're dealing:
> : >
> : > my @foo does separator('//') = (1,2,3,4,5);
> : > say "[EMAIL PROTECTED]"; # 1//2//3//4//5
> :
> : Shh, no one's let slip the idea of curried roles yet! I'm not even
> : certain A12 mentioned parametric roles, let alone first-class roles.
>
> Well, A12 did talk about parametric roles, but I glossed over the
> first-class roles a bit. I didn't want to scare people with
>
> $foo does $bar
>
> though, of course, there's no reason in principle you shouldn't be able
> to do that as a run-time operation. You just can't instantiate a role
> object. The murky area in the middle is, of course, how you specify
> an initial value aimed at the attributes of a particular role without
> creating a "real" object containing just those values. Passing around
> lists of pairs is probably good enough for that, as long as you can
> keep straight which list of pairs is intended to initialize which
> roles.
I really hope you change your mind about this; the sooner I can get
that wild and crazy list of pairs nicely stashed in their appropriate
role objects, the happier I'll be about the resilience of my code.
Re: This week's summary
Austin Hastings <[EMAIL PROTECTED]> writes: > --- The Perl 6 Summarizer <[EMAIL PROTECTED]> wrote: >> Okay, so the interview was on Tuesday 13th of July. >> It went well; I'm going to be a maths teacher. [...] > As we all know, time flies like an arrow, but fruit flies like a > banana. If you found this mathematical summary helpful, please consider > paying your tuition you ungrateful little bastards." ** Gurfle **
Re: scalar subscripting
Luke Palmer <[EMAIL PROTECTED]> writes:
> Gautam Gopalakrishnan writes:
>> Hello,
>>
>> I've tried the archives and the 'Perl 6 essentials' book and I can't
>> find anything
>> about string subscripting. Since $a[0] cannot be mistaken for array subscripting
>> anymore, could this now be used to peep into scalars? Looks easier than using
>> substr or unpack. Hope I've not missed anything obvious.
>
> Well, no, it can't really. $a[0] now means what Perl 5 called $a->[0]
> (or @$a[0]). So it's still an array subscript, it's just subscripting
> $a, not @a.
So, it should be possible to define
method postcircumfix:[] is rw { ... }
in the String class to do the right thing? Or even to define it in some
Sequence trait that both arrays and strings share? Of course, the
putative method would have to take into account the calling context's
Unicode behaviour, but I can't see why it shouldn't be possible.
Re: This week's summary
"Jonadab the Unsightly One" <[EMAIL PROTECTED]> writes: > The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: > >> Different OO models >> Jonadab the Unsightly One had wondered about having objects >> inheriting behaviour from objects rather than classes in Perl 6. > > Urgle. I've completely failed to explain myself so as to be > understood. That wasn't at *all* what I had in mind. It could well be that I didn't read things carefully enough.
Re: [Summary] Help
Piers Cawley <[EMAIL PROTECTED]> writes: [...] > Thanks in advance. And thanks to Sebastian Riedel, Brent Royal-Gordon, Robert Spier and the aforementioned Jeffrey Dik I have filled in my lacunae and I'm ready to get my summary on when Monday rolls around.
Re: [Summary] Help
Piers Cawley <[EMAIL PROTECTED]> writes: > For various annoying reasons involving a pernickety external drive and > a service centre that, after more than a week *still* hasn't taken a > look at my main machine, I find myself missing a tranche of messages to > perl6-internals and perl6-language. If some kind soul were to send me > mbox files containing messages in the period from, say, the first of > June through to the 17th, then they would have earned my undying > gratitude. > > Thanks in advance. Thanks to Jeffrey Dik's extreme promptness, I now have an archive for perl6-internals and I'm just looking for perl6-language.
[Summary] Help
For various annoying reasons involving a pernickety external drive and a service centre that, after more than a week *still* hasn't taken a look at my main machine, I find myself missing a tranche of messages to perl6-internals and perl6-language. If some kind soul were to send me mbox files containing messages in the period from, say, the first of June through to the 17th, then they would have earned my undying gratitude. Thanks in advance. -- Piers
Re: Apocalypse 12
chromatic <[EMAIL PROTECTED]> writes: > Perl.com has just made A12 available: > > http://www.perl.com/pub/a/2004/04/16/a12.html > > Warning -- 20 pages, the first of which is a table of contents. But it's all excellent good stuff. Well done Larry and Co. Now, if you could all just hold off with the questions 'til Monday you'll make a summary writer's life a good deal easier. -- Biologist: What's worse than being chased by a Velociraptor? Physicist: Being chased by an Acceloraptor -- Larry Wall in A12
Re: Compatibility with perl 5
Luke Palmer <[EMAIL PROTECTED]> writes: > David Cantrell writes: >> A few days ago I briefly discussed with Nicholas Clark (current perl 5.8 >> pumpking) about making perl5 code forward-compatible with perl6. A >> quick look through the mailing list archives didn't turn up anything >> obvious, and I don't recall any mechanism being presented in any of the >> Apocalypses, so ... > > Well, there is one, as far as I understand it. Your "use perl5;" is > spelled "package". That is, perl will assume Perl 6 unless it sees > "package SomethingOrOther;" (since Perl 6 calls them "module"s). So, to > force Perl 5 interpretation, use: I thought that the rule was .pm files were deemed to be Perl 6 unless they began with 'package', but that anything else was deemed to be Perl 5 unless it began with 'module main'. That way legacy scripts will run happily and perl 6 scripts can either use a perl6 shebang or start with 'module main'. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: z ip
"Mark J. Reed" <[EMAIL PROTECTED]> writes: >> I think the ¥(yen) suggestion is great, especially since it does indeed >> look like a zipper. Still, I would very much like an ASCII infix >> alternative for zip(). > >> I propose z as the ASCII alternative for the infix zip operator (either >> broken bar or yen). With some imagination, it is a good candidate for >> representing interleaving. Besides that, zip() starts with a z so it is >> easy to remember even if you don't think it looks like something that >> zips. > > I think if we go with ¥ for the Unicode operator, the logical choice > for an ASCII equivalent would be Y. You could read it as Spanish "and", > if you like. :) You'll really confuse the deep functional programmers if you do that, for whom the term 'Y operator' means something very different -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Funky «vector» operator
David Wheeler <[EMAIL PROTECTED]> writes: > On Mar 22, 2004, at 5:02 PM, Piers Cawley wrote: > >> Try this: >> >> (cond >> ((eq window-system 'mac) >> (when (string= default-directory "/") >> (setq default-directory "~/")) >> (setq mac-command-key-is-meta t >> mac-reverse-ctrl-meta nil >> process-connection-type nil >> mac-keyboard-text-encoding kTextEncodingISOLatin1) >> (create-fontset-from-fontset-spec >>"-apple-courier-medium-r-normal--14-*-*-*-*-*-fontset-courier14, >> ascii:-apple-courier-medium-r-normal--14-*-75-75-m-*-mac-roman, >> latin-iso8859-1:-apple-courier-medium-r-normal--14-*-75-75-m-*-mac- >> roman") >> (modify-frame-parameters (selected-frame) >> '((font . "fontset-courier14") >> >> (pushnew (lambda (frame) >> (modify-frame-parameters frame >> '((font . "fontset-courier14" >> after-make-frame-functions) > > No joy: > > An error has occurred while loading `/Users/david/.emacs': > > Symbol's function definition is void: pushnew (require 'cl) somewhere before that code chunk. I thought everyone already did that. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Funky «vector» operator
David Wheeler <[EMAIL PROTECTED]> writes: > On Mar 20, 2004, at 1:32 PM, Calle Dybedahl wrote: > >> You don't need Unicode display « and », just plain old ISO 8859-1. > > True, but I'd like to get Unicode working for other projects, as well. > >> They're characters number 171 and 187 there. And AFAIK every Emacs >> version released in the past ten years handles ISO-8859-1 out of the >> box. It's more likely that you're using a font that doesn't have the >> characters. > > No, the font works perfectly in TextEdit. There's some configuration > change I need to make to Emacs to get it to work. Try this: (cond ((eq window-system 'mac) (when (string= default-directory "/") (setq default-directory "~/")) (setq mac-command-key-is-meta t mac-reverse-ctrl-meta nil process-connection-type nil mac-keyboard-text-encoding kTextEncodingISOLatin1) (create-fontset-from-fontset-spec "-apple-courier-medium-r-normal--14-*-*-*-*-*-fontset-courier14, ascii:-apple-courier-medium-r-normal--14-*-75-75-m-*-mac-roman, latin-iso8859-1:-apple-courier-medium-r-normal--14-*-75-75-m-*-mac-roman") (modify-frame-parameters (selected-frame) '((font . "fontset-courier14") (pushnew (lambda (frame) (modify-frame-parameters frame '((font . "fontset-courier14" after-make-frame-functions) Fontsets are weird. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Exegesis 7: Fill Justification
Tom Christiansen <[EMAIL PROTECTED]> writes: >>On Tue, Mar 02, 2004 at 10:01:11AM +1100, Damian Conway wrote: >>: That's a *very* interesting idea. What do people think? > >>I think anyone who does full justification without proportional >>spacing and hyphenation is severely lacking in empathy for the reader. >>Ragged right is much easier on the eyes--speaking as someone who had >>their seventh eye operation today. > > At least aesthetically, yes, it sure does look better ragged. I do > wonder why that is, though. Could it be that the unevenness of the > inserted fixed-width spacing looks rough? Or is maybe because with > long lines, one's eye might get lost, being slower to tell one line > from the next? That's certainly a reason for have shorter columns. > > In a message of mine to p5p of 4-Nov-2003 <[EMAIL PROTECTED]>, > I showed (but did not mention) how this sort of can be done without > inserting any spurious spaces whatsoever, even in a long paragraph: > >> Well, no. Mark answered so quickly after I did, and covered so much of it >> so succinctly, that I backed off again. It seems to me that he and I have >> both for a long time yearned for a perliotut; I don't believe either of us >> has ever fleshed out more than an outline, though. IO is a subject that's >> not always easy to figure out how to get the best handle on (ENOPUN). For >> one thing, it's steeped in Unix lore and tradition, and it requires either >> knowing or else teaching quite a bit of C programming that would otherwise >> be completely irrelevant to Perl. For example, when you see someone lseek >> zero bytes from the current position in Perl, you know they're remembering >> the ANSI C requirement of a seek falling between switching from reading to >> writing or vice versa. As always, you're subject to all the silly bugs in >> your libc runtime system and in your kernel; for example, we tried to have >> all buffers flushed before a fork() to avoid duplicate output in the child >> by calling fflush(0) from C, the intent being to flush data still there in >> stdio buffers. Unfortunately, on some platforms, you'll accidentally toss >> not just pending output, but also pending input. Thus the case where read >> on STDIN was called with 2 against "asdf\n", you'd still have the df\n yet >> to read get completely trounced. This is incorrect behaviour, at least as >> far as the goal of flushing pending output buffers before forking. Sadly, >> there really are a zillion little things like this, and these are just the >> exceptions, not the core functionality that you'd like to teach people for >> learning IO. Blocking and buffering are tricky; did you remember that the >> output commands can also block? Think about sending something down a pipe >> where the reader on the other end is slow or busy. That's why with select >> you also have a slot for output handles you want to know whether are ready >> for IO. It just goes on and on. It would be easier to hand out copies of >> Stevens than to write perliotut, but that's too embarrassing and annoying. > However, I fear this isn't really readily automated; sorry to interrupt. :-) It's more fun if you do an acrostic on the left hand column. And rather harder if you perpetrate a simultaneous acrostic on the right. But I've given up on such pursuits. Not that I ever managed an ambidexterous one myself anyway. For particular values of fun, of course. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Semantics of vector operations
Uri Guttman <[EMAIL PROTECTED]> writes: >> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: > > LW> This would be relatively straightforward for syntax highlighters, > LW> I think. But Perl 6 will throw other curves at highlighters that > LW> will be much more difficult to solve, such as the fact that any > LW> C potentially changes the subsequent syntax. Even an operator > LW> declaration changes the subsequent syntax. Making things easy for > LW> syntax highlighters is not a primary design goal for Perl 6--in this > LW> Perl will remain the AntiLisp. > > and don't forget that since p6 will use the grammar to parse > perl, that will be available to syntax highlighters. no more wacko > heuristics and broken colors (i don't use them anyway. i can parse code > just fine with b&w :) depending on what the grammar produces > there might be some extra processing needed. I think you're only going to get truly accurate syntax highlighting for all Perl in an image based IDE implemented in Perl since such an editor will always know what grammar rules are in scope for a given chunk of code. And once you go to an image based IDE and have access to the bytecode of the code you're writing there's all *sorts* of interesting things you can do. And that's before one starts to imagine attaching the IDE/debugger to a running process... -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Archive tarball?
Luke Palmer <[EMAIL PROTECTED]> writes: > michael.firestone writes: >> Is there somewhere I can get the entire perl6-language archive in a >> tarball? > > I personally don't know, but there could be somewhere. > >> I am trying to work on turning the Apocalypses into story cards at >> http://p6stories.kwiki.org. It would be helpful to me if I could search >> the mailing list archives to make sure I incorporate any decisions made >> after each Apocalypse was written. As there is no search engine at this >> moment ( that is not a whine or a complaint, merely a statement ), the next >> best thing for me would be a tarball I could grep. > > Well, most of the decisions you'll find in the "official" documents: the > apocalypses, exegeses, and synopses. perl6-language has a lot of > brainstorming, and a lot of Larry saying something interesting in the > form of "maybe ...", but those could hardly be considered decisions. > > If worse comes to worst, you can always ask me. I manage to keep the > largest amount of the language in my head with the most time available > to answer questions :-) > > Oh, and thanks for the p6stories work. Of course the beauty of a Wiki is that you can just watch the RecentChanges page, proof read the new stories for up to date syntax and correct 'em as necessary. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: A modest question
chromatic <[EMAIL PROTECTED]> writes:
> On Tue, 2004-01-06 at 22:26, Austin Hastings wrote:
>
>> So on the grand balance of utility, what are the metrics that traits are
>> supposed to help improve?
>
> Two big ones:
>
> - naming collections of behavior that are too fine-grained to fit into
> classes cleanly
> - enabling finer-grained code reuse
>
> Consider a method that needs to print an object. You might require a
> String:
>
> sub print_it ( String $thingie )
> {
> print $thingie;
> }
>
> Why does it have to be a String, though? What prevents it from working
> with anything that can stringify, besides the overly restrictive
> signature? What if you could say (the Perl 6 equivalent of):
>
> sub print_it ( does Stringify $thingie )
> {
> print $thingie.stringify();
> }
>
> That's both more general and something more specific. By asking for
> what you really want, you're not coding everyone else into a corner.
In this particular case I prefer the Smalltalk thing of requiring all
objects to have a C method and not even requiring
that C<$aStream> satisfy the Stream role. But that's probably a matter
of taste.
--
Beware the Perl 6 early morning joggers -- Allison Randal
Re: Roles and Mix-ins?
"Joe Gottman" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Luke Palmer" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, January 06, 2004 4:51 AM
> Subject: [perl] Re: Roles and Mix-ins?
>
>
>> David Storrs writes:
>> >
>> > On Sat, Dec 13, 2003 at 11:12:31AM -0800, Larry Wall wrote:
>> > > On Sat, Dec 13, 2003 at 04:57:17AM -0700, Luke Palmer wrote:
>> >
>> > > : For one, one role's methods don't silently override another's.
> Instead,
>> > > : you get, er, role conflict and you have to disambiguate yourself.
>> >
>> > How do you disambiguate?
>>
>> Let's see...
>>
>> role Dog {
>> method bark() { print "Ruff!" }
>> }
>> role Tree {
>> method bark() { print "Rough!" }
>> }
>> class Trog
>> does Dog does Tree {
>> method bark() { .Dog::bark() }
>> }
>> }
>>
>> Perhaps something like that. In any case, you do it by putting the
>> offending method directly in the aggregating class.
>>
>
>How about something like
> class Trog
>does Dog {bark=>dogBark} does Tree {bark=>treeBark}
>{...}
>
> Then we could have code like
> my Trog $foo = Trog.new();
> my Dog $spot := $foo;
> my Tree $willow := $foo;
> $spot.bark(); # calls dogBark()
> $willow.bark(); #calls treeBark()
>
>This works better when Dog::bark and Tree::bark are both needed but they
> do different things.
I'm really not happy with the idea that simply using a typed variable
should change the way a method call on that variable is
dispatched. You seem to be saying that
class Parent { override { "Parent" }}
class Child is Parent { override { "Child" }}
my $kid = Child.new;
my Parent $dad := $kid;
print $kid.override; # "Child"
print $dad.override; # "Parent"
And down that road lies C++ and other insanity.
--
Beware the Perl 6 early morning joggers -- Allison Randal
Re: Roles and Mix-ins?
Jonathan Lang <[EMAIL PROTECTED]> writes: > Luke Palmer wrote: >> Renaming methods defeats the purpose of roles. Roles are like >> interfaces inside-out. They guarantee a set of methods -- an interface >> -- except they provide the implementation to (in terms of other, >> required methods). Renaming the method destroys the interface >> compatibility. > > Not so. A role is more than an inside-out interface; it guarantees a set > of methods either by calling it an error to not define a given method in a > class that C the role or by defining the method itself. In the > latter case, renaming the method can be quite useful; even in the former > case, renaming or excluding methods from a role is useful if you want an > interface which is almost, but not quite, like the one that the role > provides. And examples of doing all of that are given in the original Traits paper (and, for that matter, in the summary of Traits/Roles that I wrote up for the summary.) -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
[EMAIL PROTECTED] (Peter Scott) writes: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Austin Hastings) writes: > >>PS: While I'm somewhat sympathetic to the fact that eu guys are trying to >>spin up 200 years worth of amendments and supreme court decisions at the >>same time, it's still a ratf*ck. Eu need to get eurselves a Larry. > > Just put Damian on it, and there'll be a Lingua::EU::ConstitutionGenerator > by Christmas. Probably with a back door making him king with droit du > seigneur option in perpetuity. Has everyone *quite* finished? -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Melvin Smith <[EMAIL PROTECTED]> writes: > At 09:30 PM 1/5/2004 +0000, Piers Cawley wrote: >>Melvin Smith <[EMAIL PROTECTED]> writes: >> >> > At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: >> >>The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: >> >> > people's salaries will depend on Parrot. I confess I >> >> > wouldn't be surprised if, by the end of the year, we >> >> > haven't seen the full implementation of at least one of >> >> > the big non-Perl scripting languages on top of Parrot. >> >> >> >>I'm confused, are you optimistic or pessimistic in that last >> >>sentence? >> > >> > Knowing Piers, I would guess: optimistic. :) >> >>Have we met? You're right though. > > Unless you count our chats on IRC, no. > > I can deduce that much from IRC and summaries. We do read them, you > know. :) Thank heavens for that. I thought people printed them out and used them to roll cigarettes with. -- Piers
Re: This week's summary
chromatic <[EMAIL PROTECTED]> writes: > On Mon, 2004-01-05 at 10:55, Lars Balker Rasmussen wrote: > >> The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: > >> > I confess I wouldn't be >> > surprised if, by the end of the year, we haven't seen the full >> > implementation of at least one of the big non-Perl scripting languages >> > on top of Parrot. > >> I'm confused, are you optimistic or pessimistic in that last sentence? > > Mostly just British. There's no 'just' about it. Bloody colonials. That sentence did rather get away from me didn't it? s/wouldn't/would/ for the right sense.
Re: This week's summary
Melvin Smith <[EMAIL PROTECTED]> writes: > At 07:55 PM 1/5/2004 +0100, Lars Balker Rasmussen wrote: >>The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: >> > people's salaries will depend on Parrot. I confess I wouldn't be >> > surprised if, by the end of the year, we haven't seen the full >> > implementation of at least one of the big non-Perl scripting languages >> > on top of Parrot. >> >>I'm confused, are you optimistic or pessimistic in that last sentence? > > Knowing Piers, I would guess: optimistic. :) Have we met? You're right though. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Lars Balker Rasmussen <[EMAIL PROTECTED]> writes: > The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: >> Me? I think Perl 6's design 'in the large' will be pretty much >> done once Apocalypse 12 and its corresponding Exegesis are >> finished. Of course, the devil is in the details, but I don't >> doubt that the hoped for existence of a working Perl6::Rules by >> the end of April is going to provide us with a great deal of >> the leverage we need to get a working Perl 6 alpha ready for >> OSCON with something rather more solid ready by the end of the >> year. Parrot continues to amaze and delight with its progress; >> Dan tells me that he's about ready to roll out a large parrot >> based application for his employers, so it's approaching the >> point where people's salaries will depend on Parrot. I confess >> I wouldn't be surprised if, by the end of the year, we haven't >> seen the full implementation of at least one of the big >> non-Perl scripting languages on top of Parrot. > > I'm confused, are you optimistic or pessimistic in that last sentence? Optimistic. Parrot being used for other languages too is a good thing. We're not going to see a full Perl 6 inside a year 'cos the design won't be finished (well, not at the detailed level it needs to be for a full implementation) and Ponie probably won't be finished because of the complexities of getting the backwards compatilibility with XS that's Ponie's raison d'etre. But there are other languages out there that don't have such stringent requirements. -- Beware the Perl 6 early morning joggers -- Allison Randal
*tinkle*
Coo... you really can hear a pin drop in here. Anyway, happy new year everyone. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Michael Joyce <[EMAIL PROTECTED]> writes: > Thank you for a lovely Christmas Present. Any time.
Re: but true
Larry Wall <[EMAIL PROTECTED]> writes:
> On Fri, Dec 19, 2003 at 10:36:01AM -0600, Adam D. Lopresto wrote:
> : I've been trying to follow the recent discussion on roles and
> : properties and traits and such, but there's something that bugs
> : me. If I understand correctly, adding a role at runtime using but
> : won't override any methods defined by the class itself (but it
> : will override inherited methods). But then if I create a class
> : that has its own method of saying whether it's true or not, does
> : that mean that "but true" and "but false" won't do anything to it?
> :
> : class Complex {
> : has $.real;
> : has $.imag;
> :
[...]
> : Since Complex already has an implementation of whatever method decides whether
> : it's true or not, wouldn't just applying a property be insufficient to override
> : that?
>
> That is a problem, and you'll notice I haven't answered Jonathan
> Lang yet. That's because I've been thinking about this issue all
> week, and I haven't thought of a way around the problem. Which
> probably means that C really does imply the derivation of a new
> class somehow. Which in turn implies that C is probably not
> powerful enough yet, because it might not only bind roles, but also
> new class methods to control those roles. Maybe
[...]
> However we write it, this derivation does do something more like a
> "slatheron" with respect to the original class. However, a single
> such "slather" can apply multiple roles as well as new class methods.
> So all the compositional power of roles is still there within that
> new class. I guess the real power of roles comes from their parallel
> composition into a class, not from being able to apply them one by
> one at run time. So what we need to do is make C apply a new
> class containing some number of collected and rationalized roles
> (usually one). Call it controlled slathering...it lets you use
> inheritance for slathering as it should be, while not forcing you
> to use extra levels of inheritance to mix in multiple roles when
> you should instead be using a composition.
Will this approach allow for the removal of a property? (I'm currently
stuck for a suggested syntax...)
--
Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
"A. Pagaltzis" <[EMAIL PROTECTED]> writes: > * The Perl 6 Summarizer <[EMAIL PROTECTED]> [2003-12-16 11:57]: >> bear in mind that the authors of the paper use the term >> 'trait' for what we're calling a 'role' (We already have >> traits you see). >> >> http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf >> -- Traits paper > > I think it deserved mention that at least Larry has taken to > capitalizing "Trait" when referring to the paper's idea of Traits > that we call roles, and leaving "trait" lowercased when referring > to traits of the Perl 6 fashion. I'm reasonably sure that Larry hadn't actually mentioned this at the point when I wrote the summary. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Vocabulary
Larry Wall <[EMAIL PROTECTED]> writes: > On Wed, Dec 17, 2003 at 12:11:59AM +0000, Piers Cawley wrote: > : When you say CHECK time, do you mean there'll be a CHECK phase for > : code that gets required at run time? > > Dunno about that. When I say CHECK time I'm primarily referring > to the end of the main compilation. Perl 5 appears to ignore CHECK > blocks declared at run time, so in the absence of other considerations > I suspect Perl 6 might do the same. I feared that might be the case. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Vocabulary
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote: >> finally by default? None for me; thanks, though. > > I don't think so; we're just talking about whether you can extend a > class at _runtime_, not _compiletime_. Whether or not Perl can have > some degree of confidence that, once a program is compiled, it won't > have to assume the worst-case possibility of runtime alteration of > every class, upon every single method call, just in case you've > screwed with something. There's still a hell of a lot of stuff you can do with 'cached' optimization that can be thrown away if anything changes. What the 'final' type declarations would do is allow the compiler to throw away the unoptimized paths and the checks for dynamic changes that mean the optimization has to be thrown out and started again. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Vocabulary
Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote: > : Michael Lazzaro writes: > : > > : > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: > : > >But the agreement could be implied by silence. If, by the time the > : > >entire program is parsed, nobody has said they want to extend an > : > >interface, then the interface can be considered closed. In other > : > >words, if you think you *might* want to extend an interface at run > : > >time, you'd better say so at compile time somehow. I think that's > : > >about as far as we can push it in the "final" direction. > : > > : > That seems a very fair rule, especially if it adds a smidge more speed. > : > Runtime extension will likely be very unusual > : > : Unless you're me. Or Damian. Or a fair number of other programmers who > : like to dive into the Perl Dark Side on a regular basis. > : > : > -- requiring it to be explicit seems reasonable. > : > : It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I > : definitely want to be able to declare in a module "I'm going to be > : screwing with stuff; keep out of my way," so that I don't impose any > : awkward declarations on my module users. If that request can be made > : more explicit in the cases where that's possible, great, but the general > : declaration should be available. > > Okay, we'll call the general declaration: > > use $& > > or some such. :-) > > Seriously, I hope we can provide a framework in which you can screw > around to your heart's content while modules are being compiled, > and to a lesser extent after compilation. But we'll never get to a > programming-in-the-large model if we can't limit most of the screwing > around to the lexical scope currently being compiled, or at least > to a known subset of the code. Modules that turn off optimization > for all other modules are going to be about as popular as $&. Or the debugger. Or a refactoring tool. Or a Class browser... > So the general declaration should probably be something easy to see > like: > > use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN; No question about that. > That will encourage people to be more specific about what they want > to pessimize. Certainly, your fancy module should be encouraged > to declare these things on behalf of its users if it can. I'm not > suggesting that Lukian or Damianly modules force such declarations onto > the users unless it's impossible for the module to know. And it seems > to me that with sufficient control over the user's grammar, you can > often get that information into your own fancy module somehow. > Might take a few macros though, or analysis of the user's code at > CHECK time (or maybe just before). When you say CHECK time, do you mean there'll be a CHECK phase for code that gets required at run time? -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Luke Palmer <[EMAIL PROTECTED]> writes: > Piers Cawley writes: >> The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: >> > >> > http://groups.google.com/[EMAIL PROTECTED] >> >> This should, of course, read: >> >> http://groups.google.com/[EMAIL PROTECTED] > > Or even: > > http://groups.google.com/[EMAIL PROTECTED] We have a winner!
Re: This week's summary
The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: > Vocabulary > If you're even vaguely interested in the workings of Perl 6's object > system, you need to read the referenced post. > > Luke Palmer, worrying about people using Object related vocabulary in > subtly inconsistent ways, posted a glossary explaining how OO > terminology is used in a Perl 6 context. Casey West wrapped it up in a > POD, which will, I hope, end up on dev.perl.org soon. > > Of course, there were a few corrections for subtleties, a few rethinks > of the design so far, and general gratitude for at least having a > baseline document that people could refer to. > > http://groups.google.com/[EMAIL PROTECTED] This should, of course, read: http://groups.google.com/[EMAIL PROTECTED] Apologies for the confusion. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Vocabulary
Jonathan Scott Duff <[EMAIL PROTECTED]> writes: > On Sat, Dec 13, 2003 at 01:44:34PM -0800, Larry Wall wrote: >> On Sat, Dec 13, 2003 at 12:50:50PM -0500, Austin Hastings wrote: >> : It seems to me there's an argument both ways -- >> : >> : 1. Code written in the absence of a role won't anticipate the role and >> : therefore won't take (unknowable) steps to disambiguate method calls. Ergo >> : method overloads are bad. >> : >> : 2. Roles may be written to deliberately supercede the methods of their >> : victims. Method overloads are vital. >> >> I think the default has to be 1, with an explicit way to get 2, preferably >> with the agreement of the class in question, though that's not absolutely >> necessary if you believe in AOP. > > So, if we follow the rules in the Traits paper, a role may have no > semantic effect if the object's class already provides the necessary > methods. To *guarantee* that a role will modify an object's behavior, > we need some sytactic clue. Perhaps "shall"? > > my Person $pete shall Work; But presumably my Person $self will Work; Using a pair of words that change their meaning depending on the subject of the verb seems to be a courageous choice of language and rather too contextual even for Perl. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: 'Core' Language Philosophy
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Wednesday, November 26, 2003, at 12:29 PM, Larry Wall wrote: >> If you contrast it with an explicit try block, sure, it looks >> better. But >> that's not what I compare it with. I compare it with Perl 5's: >> >> $opus.write_to_file($file) or die "Couldn't write to $file: $!"; >> >> That has some known problems with false positives, er, negatives, >> which Perl 6 addresses with things like: >> >> $opus.write_to_file($file) err fail "Couldn't write to $file: $!"; >> >> But if we're going to talk about philosophy, we should talk about >> Perl's notion of not forcing people to escalate all the way to >> exceptions when a lesser form of undefinedness or falseness will do. >> Perl 6 doesn't back off from this. In fact, it takes it further >> by allowing you to return unthrown exceptions as "undef". And by >> providing a "fail" that either returns or throws the exception >> depending on the preferences of the caller. > > Well, yes, hmm, har, but... > > Speaking only for myself, my own (database-heavy) code already makes > pretty extensive use of the differences between "false", > "unknown/undefined/NULL", and "worthy of exception" -- all three of > those conditions may exist at various times, and no two of them can > reasonably be lumped together as being logically identical. So implement a *real* NULL instead of trying to force 'undef' somewhere it doesn't want to go.
