This Week's Summary

[Piers Cawley]

Perl 6 Summary for the week ending 20030706
Welcome to this week's Perl 6 Summary, coming to you live from a
gatecrashed Speakers' lounge at OSCON/TPC, surrounded by all the cool
people like Dan Sugalski, Lisa Wolfisch, Graham Barr and Geoff Young,
who aren't distracting me from writing this summary at all.

10 minutes later, after the arrival of James Duncan and Adam Turoff, I'm
still not being distracted. Oh no... Leon Brocard's just arrived, which
helps with the running joke, but not with the 'getting the summary
written'.

So, we'll start as usual with the goings on in perl6-internals.

  More on Parrot's multiple stack implementations
Dan pointed out that, although Control, User and Pads share the same
stack engine, Pads should be implemented using a simple linked list. He
also confessed that all the register backing stacks should share an
implementation, but that he'd been too lazy to macro things up properly.

http://xrl.us/ldt

  Building IMCC as parrot
Leo Tötsch posted an initial patch to make IMCC build as the parrot
executable. And there was much Makefile debugging.

http://xrl.us/ldu

  Parrot IO work
Work on Parrot's IO system was ongoing this week.

http://xrl.us/ldv

  Parrot Exceptions
Discussion of possibly resumable exceptions continued, and morphed into
a discussion of the workings of warnings when Benjamin Goldberg wondered
if warnings were being implemented as exceptions.

The aren't. I think Benjamin was being confused by Perl 6's "fail"
function which can either issue a warning and return undef to its
caller's caller, or throw an exception, depending on a pragma whose name
I can't for the life of me remember.

http://xrl.us/ldw

  Parrot's build system.
Last week Dan asked for help writing a configuration and build system
that would allow per-C-file compiler flag overrides and various other
complexities. This week Alan Burlison worried that this approach looked
'*very* suspect'. This sparked a discussion of the proper way to do
interrupt safe queueing, reentrant code and other scary things.

I may be misreading what's being said in the thread, but it seems that
the scariest thing about the whole issue is that there's no portable way
of doing the Right Thing, which leads to all sorts of painful platform
dependencies and hoopage (From 'to jump through hoops', anything which
requires you to jump through a lot of hoops has a high degree of
hoopage. For the life of me I can't remember if it was me or Leon
Brocard who coined the term).

Swamps were mentioned. Monty Python skits were quoted. Uri Guttman was
overtaken by (MUAHAHAHAHAHA!) megalomania.

http://xrl.us/ldx

  Klaas-Jan Stol Explains Everything (part 1)
Last week I mentioned that I didn't know what Klaas-Jan Stol was driving
at when he proposed a general, language-independent "argument" PMC class
and hoped that he would provide an explanation, with code fragments.

This week, Klaas-Jan came through, and I think I understand what he
wants. Go read his explanation and see if you understand it too. It's to
do with when a parameter should be passed by reference or by value.
Parrot currently assumes that Strings and PMCs are passed by reference,
and that integers and floats are passed by value.

There was some discussion of whether support for optionally passing PMCs
by value should be added at the parrot level or whether individual
language compilers should be responsible for calling the appropriate PMC
methods.

http://xrl.us/ldy

  Moving ParrotIO to PMCs
Jürgen Bömmels is working hard on moving Parrot's IO-system to a fully
garbage collected PMC based system. He posted an initial patch
transforming ParrotIO structures into PMCs using a simple wrapping
approach.

The patch had problems because the new ParrotIO PMCs were marked as
needing active destruction, which could lead to problems with files
being closed twice and memory structures getting cleaned up twice. Which
is tends to make memory leak detecting tools a little unhappy. This bug
proved to be easy to fix. But then another one reared it's head and has
so far proved rather harder to fix.

http://xrl.us/ldz

  Jako gets modules (sort of)
Gregor N Purdy announced that he's added rudimentary module support to
his Jako little(?) language. A little late he announced that he'd added
rather less rudimentary module support.

http://xrl.us/ld2

  Stupid Parrot Tricks
Clinton Pierce, shooting for his 'mad genius' badge announced that he'd
implemented a simple CGI script in Parrot BASIC. Everyone gasped. Robert
Spier decided that the time may have come to start playing with
"mod_parrot" (embedding Parrot in Apache) again.

http://xrl.us/ld3

http://xrl.us/ld4 -- that BASIC CGI URL

  La

Re: Aliasing an array slice

[Jonadab the Unsightly One]

David Storrs <[EMAIL PROTECTED]> writes:

>  my $r_slice = [EMAIL PROTECTED];
>  @$r_slice = qw/ a b c d e /;
>  print @a;   #  0 a b c d e 4 5  

This seems right to me.  It would take approximately no time to get
used to this semantic, IMO.

>  #  Note that it does NOT modify in rvalue context

[/me recoils at the very idea]

>  @a = @start;
>  $r_slice = [EMAIL PROTECTED];
>  print @a;  # 0 1 2 3 4 5
>  print @$r_slice;   # 0 1 2 3 
>  shift @a;  #  (*)
>  print @a;  # 1 2 3 4 5
>  print @$r_slice;   # 1 2 3 

Just to clarify:  @$r_slice would point to specific elements of @a,
_not_ the the xth through the yth element, is that what you're saying
above?  That is, although in the example above it initially pointed to
the first four elements, it after the pop points to the first three,
because one of the four is no longer in the array; it does _not_ now
point to the now-current first four elements.

Does this imply, though, that it's pointing to specific elements, and
if so doesn't that imply that elements can be inserted into the
original array in-between them...

  print @a;# 0 1 2 3 4 5
  print @$r_slice; # 0 1 2 3 
  splice @a, 2, 0, 6;  # 0 1 6 2 3 4 5
  
After that, does @$r_slice contain (0,1,2,3) (the same elements of @a
as before), or does it contain (0,1,6,2,3) (the elements from the
first one it contained before to the last one it contained before)?

I can reason either way, but it needs to be nailed down, and there
might be good reasons (which I'm not thinking of just now) to do it
one way or the other.

> (*) There should probably be a suppressable warning emitted here,

I can go along with that.

Re: Aliasing an array slice

[Jonadab the Unsightly One]

"Jonadab the Unsightly One" <[EMAIL PROTECTED]> writes:

> Does this imply, though, that it's pointing to specific elements, 

Wow, I wasn't paying attention to what I was thinking there.
Obviously it points to specific elements, because the subscripts used
to create a slice don't have to be sequential or even in order.  I
(theoretically) knew that...

>   print @a;# 0 1 2 3 4 5
>   print @$r_slice; # 0 1 2 3 
>   splice @a, 2, 0, 6;  # 0 1 6 2 3 4 5
print @$r_slice; # 0 1 2 3
splice @a, 1, 1, 7;  # 0 7 6 2 3 4 5
print @$r_slice; # 0 7 2 3

Am I now thinking clearly?

Re: Aliasing an array slice

[Austin Hastings]

--- Jonadab the Unsightly One <[EMAIL PROTECTED]> wrote:
> "Jonadab the Unsightly One" <[EMAIL PROTECTED]> writes:
> 
> > Does this imply, though, that it's pointing to specific elements, 
> 
> Wow, I wasn't paying attention to what I was thinking there.
> Obviously it points to specific elements, because the subscripts used
> to create a slice don't have to be sequential or even in order.  I
> (theoretically) knew that...
> 
> >   print @a;# 0 1 2 3 4 5
> >   print @$r_slice; # 0 1 2 3 
> >   splice @a, 2, 0, 6;  # 0 1 6 2 3 4 5
> print @$r_slice; # 0 1 2 3
> splice @a, 1, 1, 7;  # 0 7 6 2 3 4 5
> print @$r_slice; # 0 7 2 3
> 
> Am I now thinking clearly?
> 
I don't think so.

If you've created two separate arrays that happen to start with related
values, then the changes to the first won't affect the second.

If splice overwrites the values instead of dropping and then replacing
them, it's going to produce some strange behavior.

I think that for example:

my @a is Array of int;
my $r_slice is Array of int;

# ... as before ...

should behave as expected, and "expected" in this case means
copy-on-assign. OTOH, if you said C<$r_slice := @a ...> then you'd be
binding, not copying, and the one-change-affects-both behavior is in
effect.

=Austin