Re: Some Things I'd Like To Do With Pod

2007-06-24 Thread Piers Cawley

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

2006-02-18 Thread Piers Cawley
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

2006-01-23 Thread Piers Cawley
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?

2005-12-30 Thread Piers Cawley
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

2005-12-18 Thread Piers Cawley
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()

2005-11-30 Thread Piers Cawley
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

2005-11-15 Thread Piers Cawley
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

2005-11-04 Thread Piers Cawley
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

2005-11-04 Thread Piers Cawley
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

2005-10-14 Thread Piers Cawley
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

2005-10-13 Thread Piers Cawley
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

2005-10-12 Thread Piers Cawley
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

2005-10-10 Thread Piers Cawley
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

2005-10-06 Thread Piers Cawley
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

2005-09-30 Thread Piers Cawley
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

2005-09-27 Thread Piers Cawley
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...

2005-09-26 Thread Piers Cawley
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

2005-09-26 Thread Piers Cawley
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

2005-09-26 Thread Piers Cawley
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?

2005-08-03 Thread Piers Cawley
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)

2005-08-03 Thread Piers Cawley
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

2005-08-03 Thread Piers Cawley
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

2005-07-26 Thread Piers Cawley
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

2005-07-23 Thread Piers Cawley
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?

2005-07-20 Thread Piers Cawley
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?

2005-07-14 Thread Piers Cawley
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

2005-07-08 Thread Piers Cawley
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

2005-07-06 Thread Piers Cawley
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

2005-07-06 Thread Piers Cawley
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)

2005-06-26 Thread Piers Cawley
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

2005-06-23 Thread Piers Cawley
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 $_

2005-06-23 Thread Piers Cawley
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?

2005-06-21 Thread Piers Cawley
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

2005-06-16 Thread Piers Cawley
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

2005-06-16 Thread Piers Cawley
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?

2005-06-16 Thread Piers Cawley
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

2005-06-14 Thread Piers Cawley
Following a conversation with Chip on IRC, is this

my @y := @foo[0..][1];

legal?



Re: Binding slices

2005-06-14 Thread Piers Cawley
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?

2005-06-13 Thread Piers Cawley
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?

2005-06-13 Thread Piers Cawley
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?

2005-06-12 Thread Piers Cawley
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

2005-06-09 Thread Piers Cawley
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

2005-06-09 Thread Piers Cawley
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

2005-06-09 Thread Piers Cawley
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

2005-06-08 Thread Piers Cawley
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

2005-06-08 Thread Piers Cawley
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

2005-06-08 Thread Piers Cawley
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

2005-06-08 Thread Piers Cawley
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

2005-06-07 Thread Piers Cawley
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

2005-05-26 Thread Piers Cawley
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

2005-05-25 Thread Piers Cawley
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

2005-05-25 Thread Piers Cawley
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?

2005-04-27 Thread Piers Cawley
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()

2005-04-12 Thread Piers Cawley
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

2005-03-29 Thread Piers Cawley
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?

2005-03-28 Thread Piers Cawley
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

2005-03-28 Thread Piers Cawley
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

2004-10-26 Thread Piers Cawley
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

2004-09-09 Thread Piers Cawley
Aaron Sherman [EMAIL PROTECTED] writes:

 On Thu, 2004-09-09 at 13:14, Larry Wall wrote:

 So whereas Ruby's syntax actually tends to push you toward .each
 iterators, Perl 6's syntax will be fairly neutral on the subject,
 or maybe biased every so slightly away from method iteration by the
 width of about one character:
 
 for @foo { ... }
 @foo.each:{ ... }
 
 But then, a good Ruby programmer would have put a space where there's
 a colon anyway, so maybe it's a wash.  If I wanted to make it even
 I'd pick something shorter than each, I suppose.  Except all is
 already taken.  I suppose there's something to be said for:
 
 @foo.for:{ ... }

 act any are ask cog cue did ere for get got has hop jet job kin
 let map mix net now one ore per pro put run set tag

 I won't describe why I think each one would be appropriate, since if
 it's not obvious, it's a bad choice ;-)

I find myself wondering if this is going to allow people to write
smalltalk style method selectors...

   @foo.inject:0 into: - $accum, $each { $accum + $each }



Re: Reverse .. operator

2004-09-06 Thread Piers Cawley
Joe Gottman [EMAIL PROTECTED] writes:

 In perl 6, the statement  

 @foo = (1.. 5) ;

 is equivalent to

 @foo = (1, 2, 3, 4, 5); 

  

 Is there similar shorthand to set @foo = (5, 3, 3, 2, 1) ?  I know you can
 go

 @foo = reverse (1 ..5);

 but this has the major disadvantage that it cannot be evaluated lazily;
 reverse has to see the entire list before it can emit the first element of
 the reversed list.  Would

 @foo = (5 .. 1 :by(-1));

 do the trick?  If so, would the same trick work for

 @bar = ('e' .. 'a' :by(-1)); ?

   @foo = 5.down_to(1)

Where down_to is 

method Number::down_to ($self : Number $target) {
return if $self  $target;
return $self, ($self - 1).down_to($target);
}

You might have to do some monkeying around with a range object or
something to make it appropriately lazy, but that's a mere detail. Or
you could implement it as an operator. Or...


Re: S4: Can PRE and POST be removed from program flow?

2004-09-04 Thread Piers Cawley
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

2004-07-29 Thread Piers Cawley
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

2004-07-28 Thread Piers Cawley
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

2004-07-26 Thread Piers Cawley
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

2004-07-26 Thread Piers Cawley
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

2004-07-21 Thread Piers Cawley
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

2004-07-08 Thread Piers Cawley
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

2004-06-20 Thread Piers Cawley
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

2004-06-20 Thread Piers Cawley
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

2004-04-17 Thread Piers Cawley
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

2004-03-29 Thread Piers Cawley
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

2004-03-22 Thread Piers Cawley
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

2004-03-22 Thread Piers Cawley
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

2004-03-02 Thread Piers Cawley
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

2004-01-21 Thread Piers Cawley
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?

2004-01-09 Thread Piers Cawley
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

2004-01-07 Thread Piers Cawley
[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?

2004-01-07 Thread Piers Cawley
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?

2004-01-07 Thread Piers Cawley
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

2004-01-07 Thread Piers Cawley
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

2004-01-05 Thread Piers Cawley
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

2004-01-05 Thread Piers Cawley
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*

2004-01-01 Thread Piers Cawley
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

2003-12-25 Thread Piers Cawley
Michael Joyce [EMAIL PROTECTED] writes:

 Thank you for a lovely Christmas Present.

Any time.


Re: but true

2003-12-23 Thread Piers Cawley
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

2003-12-21 Thread Piers Cawley
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

2003-12-17 Thread Piers Cawley
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

2003-12-16 Thread Piers Cawley
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

2003-12-16 Thread Piers Cawley
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

2003-12-16 Thread Piers Cawley
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

2003-12-16 Thread Piers Cawley
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

2003-12-14 Thread Piers Cawley
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

2003-12-02 Thread Piers Cawley
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

2003-11-25 Thread Piers Cawley
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

2003-11-25 Thread Piers Cawley
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

2003-11-25 Thread Piers Cawley
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

2003-11-20 Thread Piers Cawley
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: Control flow variables

2003-11-19 Thread Piers Cawley
Damian Conway [EMAIL PROTECTED] writes:

 David Wheeler wrote:

 Isn't that just:
 for @array_of_random_values_and_types, 'ok' - $t {
 when 'ok' { yada(); last }
 last unless some_sort_of_test($t);
 }
 IOW, the topic is only 'ok' when all of the items in the array have
 been processed

 Unless, of course, the string 'ok' is also one of the random_values_and_types.
 Hence my alternative solution.

Or:

   my $guard = Object.new;
   for @array_of_random_values_and_types, $guard 
 - { when $guard { yada(); last }
  last unless some_sort_of_test($_) }

If there's some danger of some weird equality thing somehow causing a
problem there, you might need to make a Guard class with a very strict
'=~' implementation, but otherwise I can't see any problem.

Of course, that's better if some_sort_of_test is actually a method,
because then it becomes:

   my $guard = class { method some_sort_of_test { yada() }}.new;

   for [EMAIL PROTECTED], $guard 
 - { last unless .some_sort_of_test }

All of which means you can wrap it up in a macro and prove Simon's
point about what's syntax and what's CP6AN:

   macro unless_all( Block test is parsed /perl.expression/,
 Block consequence, [EMAIL PROTECTED] ) 
 { my $guard = Object.new;
   for [EMAIL PROTECTED], $guard 
 - { when $guard { consequence() ; last }
  when test { last } } }

But I've probably got the signature slightly wrong. 

Higher Order Functions/Methods/Macros are great aren't they? 








Re: s/// in string context should return the string

2003-11-19 Thread Piers Cawley
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

2003-11-19 Thread Piers Cawley
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.



  1   2   3   4   5   >