modifying within a perl5 block

[Richard Hainsworth]

Dear Audrey,

Consider:
my $x = 'test';
 {
 use v5;
 $x .= 'ing';
  };
say $x;

pugs yields 'test'
and not 'testing' - as expected.

Moreover, the following hangs pugs:

my $x = 'test';
my $y = 'case';
 {
 use v5;
 $x .= 'ing';
  {
 use v6-alpha;
 $y ~= 'book';
  };
  };
say $x;
say $y;

I have committed a test to t/perl5, viz., modify_inside_p5.t (which runs 
but fails)

and I attach another. viz., modify_inside_p5_p6.t , which hangs pugs.

Regards,
Richard
use v6-alpha;
use Test;
plan(2);

my $x = 'test';
my $y = 'case';
{
  use v5;
  $x .= 'ing';

  #the following code crashes pugs.
 {
use v6;
$y ~= 'book';
  };
};

is $x, 'testing', scalar modified inside perl5 block;
is $y, 'casebook', scalar modified inside perl6 block inside perl5 block;

Re: set_pmc_keyed_int delegates to set_pmc_keyed...?

[Patrick R. Michaud]

On Sat, Nov 04, 2006 at 05:18:22PM +0100, Leopold Toetsch wrote:
 Am Samstag, 4. November 2006 16:17 schrieb Patrick R. Michaud:
  Because 'Match' doesn't define its own set_integer_keyed_int
  vtable entry, it ought to be inheriting the one from Capture.
  But unfortunately, the default.pmc function above gets in the
  way, and redispatches the keyed_int call as a keyed call,
 
 Class inheritance from PMCs is very static still (like PMC-only cases). I 
 hope 
 that the :vtable patches will provide the base for a better solution. For 
 now, you can only implement the mssing _integer_keyed cases in Match so that 
 default isn't triggered. 

I don't think that's possible, is it?  Match is implemented as a
subclass of Capture, as in:

$P0 = subclass 'Capture', 'Match'

So, I can create the missing cases, but what do I put for the body
of the method to get to the corresponding method of Capture?

.namespace [ 'Match' ]
.sub set_integer_keyed_int :vtable
.param int key
.param int value

# ... how to do set_integer_keyed_int method of Capture?

.end


 We could of course remove the defaults too, but that 
 would need a very complete set of these keyed vtables on all PMCs.

How many of these would there be?  Doesn't this affect only those
classes that are built using ParrotObject ?

Pm

Re: set_pmc_keyed_int delegates to set_pmc_keyed...?

[Leopold Toetsch]

Am Samstag, 4. November 2006 16:17 schrieb Patrick R. Michaud:
 Any thoughts about how we should resolve this?

This is fixed now with r15111.

 Pm

leo

Re: set_pmc_keyed_int delegates to set_pmc_keyed...?

[Leopold Toetsch]

Am Sonntag, 5. November 2006 15:22 schrieb Patrick R. Michaud:
 I don't think that's possible, is it?  Match is implemented as a
 subclass of Capture, as in:

     $P0 = subclass 'Capture', 'Match'

 So, I can create the missing cases, but what do I put for the body
 of the method to get to the corresponding method of Capture?

     .namespace [ 'Match' ]
     .sub set_integer_keyed_int :vtable
         .param int key
         .param int value

         # ... how to do set_integer_keyed_int method of Capture?

     .end

A subclass of a PMC delegates to that PMC (via deleg_pmc.pmc). The PMC is the 
first attribute of that class named '__value'. Your code would look like:

  .local pmc capt
  capt = getattribute SELF, '__value'
  capt[key] = value

But this is all clumsy, and might/should change.

Therefore I've ci'ed in r15111 another workaround in parrotobject.pmc, which 
checks, if the parent isa PMC and in that case calls the deleg_pmc method 
instead of the default.

leo

Weekly Perl 6 mailing list summary for 29 October - 4 November, 2006

[Ann Barcomb]

 This week on the Perl 6 mailing lists

That fuzziness is classic $Larry. Some of the rest of @Larry can be
more *mumble*matic.

-- chromatic in 'where constraints as roles http://xrl.us/susf'


 Language

  where constraints as roles http://xrl.us/susf

A few clarifications were added to the original thread 'how typish are
roles'.

In the subthread 'where constraints as roles', started by Trey Harris,
the discussion from the previous week continued.

Last week, Trey asked if a `where` clause or junctive type defines an
anonymous role, while a type parameter defines a lexical role, and
suggested adding this information to S12. Larry Wall replied, saying
that a `where` clause is there for pattern matching...but went on to
note other possibilities. Jonathan Lang felt that S02 gave some
indication of what Trey suggested, and that `where` clauses and
junctive types should not be turned in to roles: roles and junctive
types should be turned in to `where` constraints.

  [svn:perl6-synopsis] r13350 - doc/trunk/design/syn http://xrl.us/szne

Larry Wall committed a patch on applying dwimmy hypers to hashes, then
disagreed with himself...maybe. He sees two ways of looking at it, and
finds merit in both.

  mmd-draft.txt http://xrl.us/susg

Earlier, TSa noted that multi-method dispatch is not yet in S06 and
asked if someone could explain the voting mechanism used to select the
dispatch target.

This week, Audrey Tang replied that the plan had been for Larry Wall
to review it in Brazil, but that it may now have to wait a while as
Larry cannot make it to Brazil. She tried to answer the question on
voting, and elaborated further on #perl6. TSa summarized her
explanation.

 Parrot Porters

  [perl #40443] Separate vtable functions from methods (using :vtable)
  http://xrl.us/r5xe

Earlier, in ticket [perl #40443] http://xrl.us/r5xf, Matt Diephouse
noted that it was decided at OSCON 2006 that vtables and methods
should be separated.

Jonathan wondered if this should be postponed until the object and
namespace issues have been dealt with. Allison Randal summarized the
results of her last conversation with Chip Salzenberg on the topic.
Jonathan thanked her for the specifications and said he would work on
an implementation.

This week, Jonathan reported the implementation in r15039. Allison
suggested a two release cycle for deprecating the old syntax. A bug
she reported with Punie was addressed in r15048, but some tests
continued to fail (the bug was covered in '[perl #40626] [BUG] :vtable
fails for subclasses of core classes http://xrl.us/szn7'). There was
further discussion about optimization, with it being agreed that first
the functionality would be added, and later the code could be
improved.

  Anyone relying on objects stringifying to class names?
  http://xrl.us/sznk

Jonathan Worthington noted that if you have a ParrotObject instance
and write `$S0 = foo`, $S0 will contain the name of the class. He
finds this problematic because you cannot overload what class it
stringifies to. He would like to get rid of this but asked if anyone
was relying on the current behavior. He wants to get rid of it in a
week.

Patrick R. Michaud joked that he thought a week was too long to wait
for its removal. He had no objections so long as tests still pass.
Allison Randal agreed with a week, provided tests pass.

Later, Jonathan wrote that he had been confused when he wrote the
post; the code is being used in PGE, for instance.

  [perl #40608] key_append segfault http://xrl.us/sznm

In ticket [perl #40608] http://xrl.us/sznn, Jonathan Worthington
showed a program which segfaults in Parrot on Windows. This issue was
resolved in r15043.

  RFC: Actions without barriers http://xrl.us/szno

Bob Rogers considered different approaches to eliminating the
continuation barrier from action invocation and wondered if his latest
idea was worth pursuing. Allison Randal replied that she saw the
temptation in the solution, but was glad Bob had paused to ask because
it would ultimately lead in the wrong direction. They discussed the
matter further.

  :init Where should we put the flag? http://xrl.us/sznp

Kevin Tew implemented `:init` some time ago but cannot check it in
because it requires a flag. Currently he is using
`PObj_private7_FLAG`; Leopold Toetsch suggested `PObj_private2_FLAG`
but that broke tests. He would like to know what flag he should use.

Jonathan Worthington asked if `PObj_private3_FLAG` could be used, as
it is labeled as unused.

Leopold Toetsch suggested 2 or 0. Kevin included his failing test
results with these flags.

  [perl #40616] [PATCH] Helping splint check further through the parrot
  source http://xrl.us/sznq

This week, Paul Cochrane