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/
Re: Perl 6 OO and bless
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_controlfoo()
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
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. /blunt
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: 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: 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: 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 Cif can succeed at most once (e.g. foo
could really be Ckeys %hash).
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: 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: 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: 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 = a b c d;
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 (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: 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
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 :default10 }';
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 :default10 }';
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?
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.
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: 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: 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: 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: 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!
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: 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.
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.
Binding slices
Following a conversation with Chip on IRC, is this my @y := @foo[0..][1]; legal?
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 :)
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.
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.
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.
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
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.
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
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 eval 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
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
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:
[..] 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
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: 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: 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: 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 Cnote, 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: 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: .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: 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: [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 Cfor
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: 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-oping 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
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: 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: 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: 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.
[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: [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.
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: 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 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: 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: 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 Cuse 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 perl 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 bw :) depending on what the perl 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: 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: 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 Cdoes 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: 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: 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 Cprint_on($aStream) 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: 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
Re: This week's summary
Melvin Smith [EMAIL PROTECTED] writes: At 09:30 PM 1/5/2004 +, 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
*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 Cbut really does imply the derivation of a new
class somehow. Which in turn implies that Cbut 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 Cbut 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 +, 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: 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
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: 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: 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: 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.
Re: Control flow variables
Simon Cozens [EMAIL PROTECTED] writes: Luke Palmer: So modules that introduce new concepts into the language can add new syntax for them without working with (ugh) a source filter. And some of these new syntaxes in the core language will actually be in standard modules, if they're not commonly used. Just like traits. This is good. This is what I like to hear. This is why the answer to all these stupid syntax questions should be Look, if you need it, just put it in a module when we're done. But can we please get on with getting Perl 6 designed and out the door, now? But it isn't, and I don't know why it isn't, and so we end up spending loads of time discussing things that can be punted out to modules. Designing Perl 6 is hard enough; let's not try to fill CP6AN at the same time. But the vast majority of us *aren't* designing Perl 6, that's Larry and his team's job. We're in the position of taking the work that's been done on the language so far and working out how we'd use it (and yes, we're in the business of thinking about the sort of thing that will go in CP6AN). Considered in that light, Luke's question is a really good one, it points up an ugly idiom and considers how one would generate a better idiom in Perl 6. Where he falls down is in proposing new syntax to solve the problem rather than in proposing the new syntax and then offering a sketch of its implementation as a macro in Perl 6. After all, problems with 'implemented' solutions are simply demonstrations that the design is sound, and that's good feedback to Larry and his team. These things only become real design issues if there appears to be no good way to solve such problems.
Re: s/// in string context should return the string
Jonathan Scott Duff [EMAIL PROTECTED] writes:
On Wed, Nov 19, 2003 at 08:23:30PM +, Smylers wrote:
This, however, is irritating:
my @new = map { s:e/$pattern/$replacement/; $_ } @old;
I forget the C; $_ far more often than I like to admit and end up with
an array of integers instead of modified strings.
That one gets me every now and then too.
So I'd like a more elegant way of writing that -- but I don't think
making the return value of Cs/// more complicated (and duplicating
data in the process) would be a nett gain.
What if the method form of s/// didn't mutate the string, but returned
the mutated result? Then, you'd just need to do something like:
my @new = map { $_.s:e/$pat/$rep/ } @old
Except I don't know how the method form of s/// would be spelt.
$string.s:e/$pat/$rep/; # . and ~~ are almost the same?
$string.sub($pat,$rep,each); # ick.
$string.sub:e($pat,$rep); # hmm.
aString replace: aPattern with: aString.
aString replaceAll: aPattern with: aString.
Except... the second argument isn't strictly a string because it's
evaluated in the match context. Assuming we get a pure functional form
of the substitution operator, then scoping's going to be fun. If you
want a simple form with the signature:
method String::sub( Rule $pattern, String $replacement )
you're almost certainly going to have to implement that as a macro so
you can get at the string before it's interpolated.
Re: s/// in string context should return the string
Mark J. Reed [EMAIL PROTECTED] writes:
On 2003-11-25 at 18:17:04, Piers Cawley wrote:
aString replace: aPattern with: aString.
aString replaceAll: aPattern with: aString.
Stop! Stop that at once! No small talk; we're here for
serious discussions!
:)
Except... the second argument isn't strictly a string because it's
evaluated in the match context. Assuming we get a pure functional form
of the substitution operator, then scoping's going to be fun. If you
want a simple form with the signature:
method String::sub( Rule $pattern, String $replacement )
you're almost certainly going to have to implement that as a macro so
you can get at the string before it's interpolated.
Or you could have the method version take a closure/proc
object/block/whatever, which gets run each time to generate the
replacement. Quoting is then not an issue.
Well, yes, sorry, thought that was implicit. The macro form would
simply replace itself with an appropriate call to the
method String::sub(Rule $pattern, Block replace_block) {...}
form. This is perl after all, no harm sprinkling a little syntactic
sugar. Catch is, the macro form can't really (safely) look like a
method call because at macro expansion time we don't know the
invocant's type (or even if it is an object).
Hm. What was that about the Rubyometer? :)
Is that how Ruby does it then?
Re: Control flow variables
Smylers [EMAIL PROTECTED] writes: Larry Wall writes: And nested modifiers are still quite illegal in Standard Perl 6. Right. Anybody else get the feeling we should write that down somewhere, so we don't have to have this conversation again in a few months? It'll be in the summary.
Re: s/// in string context should return the string
Stéphane Payrard [EMAIL PROTECTED] writes: s/// in string context should return the string after substituion. It seems obvious to me but I mention it because I can't find it in the apocalypses. Surely it should return the string after substitution, but with an appropriate 'but true' or 'but false' property depending on whether anything was substituted. Though that could have its own problems too.
Re: [perl] RE: s/// in string context should return the string
Joe Gottman [EMAIL PROTECTED] writes: - Original Message - From: Austin Hastings [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 3:04 PM Subject: [perl] RE: s/// in string context should return the string As a Bvalue where possible, so they can cascade and nest. Excuse me. I know enough C++ to know the difference between an lvalue and an rvalue, but what the heck is a BValue? A mystery to me.
Re: This week's summary
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley wrote: newsub and implicit registers [...] ops [...] that IMCC needed to track. Leo has a patch in his tree that deals with the issue. Sorry, my posting seems to have been misleading. The register tracking code is in the CVS tree. I seem to be doing rather well at misrepresenting you in the summaries recently. Maybe we should make that the new running joke.
This week's summary
The Perl 6 Summary of the week ending 20031109 Traditionally this paragraph concerns itself with a few words on what I've been up to before finally settling down to get the summary written. But despite the fact that it's nearly four o'clock, it's been one of those days where I seem to have done almost as much as Leon Brocard generally does to warrant a mention each week. So, here's what's been happening in perl6-internals to make up for the lack of guff about breadmaking or whatever. (If you're interested, the raisin borodinsky I mentioned last week was an unmitigated disaster. The focaccia was fabulous though). New glossary entries Gregor N. Purdy has added a few entries to the Parrot glossary, so if you've been bursting to know what PIR, IMCC and other Parrot specific clusters of capitals stand for, check out docs/glossary.pod in the parrot distribution. http://xrl.us/3pv String Encodings hurt my head! Peter Gibbs is attempting to implement the DBCS encoding (whatever that is) and has discovered that he can't implement skip_backward for it because of the mixture of 1-byte and 2-byte characters. He offered seven suggestions for the right thing to do at this impasse. Michael Scott didn't have any suggestions about the Right Thing, but he did point to a page on his very lovely Parrot Wiki which discussed most things Unicode for parrot, and made a plea for Dan (or whoever) to produce a Strings PDD. http://xrl.us/3pw http://xrl.us/3px - Michael's WikiWord Perl 6 patches Allison Randal posted a couple of patches to the current (very) mini Perl 6 that comes with Parrot (in languages/perl6. A little later in the week, Joseph F. Ryan contributed a Perl 6 patch. It's good to see this receiving attention again. http://xrl.us/3py Documentation Nick Kostirya wondered why docs/parrot_assembly.pod appeared to be simply an old version of docs/pdds/pdd06_pasm.pod. He also worried that docs/ops/ appeared to be empty in the 0.0.13 release of Parrot. Dan noted that both of the parrot assembly docs were wrong, and that what would probably happen would be that the PDD would be updated and docs/parrot_assembly.pod would be retired. Jürgen Bömmels said that the empty docs/ops was because during the Great Move, the Makefile that generated those POD files didn't get updated to cope with the new location of the .ops files. Nick wondered which other POD files might be going away so he'd not have to go through the process of translating obsolete docs into Russian. http://xrl.us/3pz http://www.parrotcode.ks.ua/docs -- Why can't I type in Cyrillic? From the Interesting, but is it useful? department Melvin Smith has been playing with an uncommitted version of invoke which allows you to invoke a function by name not address. He outlined the ideas behind it (and the workaround to make it play nice with the GC system), but wondered if it was actually of any use. Dan and Leo both agreed that it wasn't because of issues with threading and the JIT. http://xrl.us/3p2 Freeze/thaw data format and PBC Leo Tötsch is working on the data serialization/deserialization (aka Freeze/Thaw) system discussed over the last few weeks. He wondered if there were any plans for the frozen image data format. Leo's plan is to use PBC constant format (with possible extensions) so things integrate neatly into bytecode. Dan had a bunch of comments, but the PBC based format idea seemed to be well received, with the caveat that it should be a 'dense' format. http://xrl.us/3p3 Opening files on other layers Jürgen Bömmels asked for comments on a patch for opening files on different layers which had a few issues that he felt needed clarifying. He and Melvin Smith spent some time discussing things. Apologies for not doing a better job in summarizing this thread, but I'm hamstrung by not quite knowing what 'layer' means in this context. http://xrl.us/3p4 Parrot Has PHP Okay, so the subject line's not quite true (yet), but who could resist the recursive acronyminess of it? Anyhow: Thies C. Arntzen and Sterling Hughes, core PHP hackers, popped up to discuss the work they're doing on porting PHP to Parrot. Specifically, they've hit a performance snag where PHP's typeless nature meant using a PMC where they would rather be using a native type for speed. Thies proposed a new datatype to get 'round the issue. The general response was Hey! Fabulous! Someone's making a serious effort to port a real language to Parrot! But that new type suggestion is just reinventing the PMC. Oh, and if you could change your generated code slightly you'd get much faster execution. It's definitely fabulous though. http://xrl.us/3p5
