This week's summary
The Perl 6 summary for the week ending 20031207 Another week, another late summary. Luckily it's been a quiet week so I should get this written faster than usual. As is traditional, we start with perl6-internals Parrot build system tinkering Andy Dougherty and other discussed extending the Parrot build system to allow for building parrot itself outside the main source directory (useful when Parrot's mounted read only via NFS for example. It's not (quite) possible to do this just yet because of a couple of generated files in the IMCC tree. Leo suggested only generating those when "Configure.pl --maintainer" is run, on the grounds that a maintainer shouldn't be building from a read only source. Dan asked for a volunteer to fix things up. http://groups.google.com/[EMAIL PROTECTED] Object stuff I (and others I presume) got ready to do the "Happy! Happy! Joy! Joy!" dance of delight; this was the week that Parrot finally got objects. Or, as Dan described them, 'objects-ish'. Parrot now has single inheritance objects. They're not the final word on the matter, but it's definitely better than a poke in the eye with a sharp stick. Dan went on to discuss what needs to be done with them before we're ready for Parrot 0.1 (Objects are one of the criteria for making a point release). Dan then went rather quiet, apparently because he got mugged by flu, or something like it, and spent the rest of the week wishing he were dead. Meanwhile, Leo lived up to his Patchmonster nickname by checking in a bunch of object related stuff. http://groups.google.com/[EMAIL PROTECTED] -- Rumblings http://groups.google.com/[EMAIL PROTECTED] -- Announcement http://groups.google.com/[EMAIL PROTECTED] -- The way forward http://groups.google.com/[EMAIL PROTECTED] -- Dan gets mugged by flu http://groups.google.com/[EMAIL PROTECTED] -- Leo's patches Raising exceptions Cory Spencer wondered about 'proper exception raising' and wondered what the state of play was, and if there were any good examples. Leo Tötsch pointed him at t/pmc/exception.t http://groups.google.com/groups?selm=Pine.LNX.4.58.0312011749290.13872@ okcomputer.antiflux.org Compilation units and the boundaries of IMCC Pete Lomax had wondered about package/file local variables in IMCC. At the moment IMCC variables can't be file or package scoped, but Melvin Smith is working on it. As he said this, he asked for suggestions for other potential IMCC features. Cory Spencer wanted to be able to write if _some_test() goto LABEL but that was vetoed by Dan (and Melvin) as being rather too high level for an intermediate language that's meant to be a compiler target. http://groups.google.com/[EMAIL PROTECTED] String manipulation Melvin Smith put forward a convincing argument that IMCC shouldn't concern itself with doing string interpolation as the expected behaviour is too 'high level language' dependent, but that Parrot should have a "printf"/"sprintf" equivalent, implemented in C for speed. Dan seemed to agree and reckoned it should be addressed as soon as objects were out of the way. http://groups.google.com/[EMAIL PROTECTED] IMCC pending changes Melvin Smith posted a list of pending IMCC changes, most of which were concerned with tightening up IMCC behaviour (making it both stricter nd more forgiving...). Discussion ensued. A few days later, Melvin committed some of his changes. http://groups.google.com/[EMAIL PROTECTED] http://groups.google.com/[EMAIL PROTECTED] PMC Compiler 2nd edition Leo applied a 'really long pending patch' which should simplify upcoming vtable changes. Melvin wondered if the time had come to replace the existing ops2c and pmc2c with the newer versions. Leo thought that pmc2c2 was definitely stable enough, but wasn't too sure about ops2c2. Jonathan Worthington pointed out a Win32 bug that was quickly fixed. http://groups.google.com/[EMAIL PROTECTED] "get_pmc_keyed()" in PerlString Sterling Hughes noted that, in PHP it's valid to index a string as if it were an array. He wondered it would be possible to implement "get_pmc_keyed()" on the PerlString vtable to allow for similar tricks with the standard string PMC. I'm confused as to what the decision was. I think Leo agreed that it was a good idea, but that it should probably be implemented in a new PMC for the time being... http://groups.google.com/[EMAIL PROTECTED] Symbolic vs. Named variable register allocation Pete Lomax stumbled over a bug in IMCC's register allocation. Melvin thinks the problem is that much of IMCC's flow analysis code doesn't yet know about the Parrot Calling Conventions and went to have a look to see if there was a quick fix available. http://groups.google.com/[EMAIL PRO
Re: This week's summary
The Perl 6 Summarizer <[EMAIL PROTECTED]> wrote: > PMC Compiler 2nd edition > ... Melvin wondered if the time had come to replace the > existing ops2c and pmc2c with the newer versions. Leo thought that > pmc2c2 was definitely stable enough, but wasn't too sure about ops2c2. RGWF[1] I was and am sure that ops2c2.pl isn't a problem because it simply doesn't exist. pmc2c.pl will be removed before next release. Thanks again for your concise summaries, leo RGWF ... Running Gag of the Week Followp. That is: our dear summarizer hasn't to mention Leon Brocard any more :)
Re: This week's summary
On 2003-12-10 at 15:05:09, The Perl 6 Summarizer wrote: > Oh yes, if you've not been following, "^op" (ie, the vector operators) > has become " >>op<< " which is, if nothing else, a right swine to write > in a POD C<> escape. Eh, >>op<< is just a hack for people who can't type C<»op«>, like ANSI C trigraphs. :) > Nope, still no link shortening. Noticed. Why is that? -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Iterating through two arrays at once
In Perl 6, how will it be possible to iterate through two arrays at the
same time? According to Apocalypse 4, the syntax is
for @a; @b -> $a; $b {
According to the book "Perl 6 Essentials" the syntax is
for zip(@a, @b) -> $a, $b {
Which of these is right? (of course, this being Perl, both may be right).
Whichever of these syntaxes is right, what happens when @a and @b are of
different sizes? I can think of three possible behaviors, each with its
potential drawbacks:
1) The loop executes min(+ @a, + @b) times, then finishes successfully.
2) The loop executes min(+ @a, + @b) times, then throws an exception
because the arrays were not of the same size.
3) The loop executes max(+ @a, + @b) times. If @a has fewer elements
than @b, then after @a's elements are exhausted $a is set to undef, and
similarly if @b has fewer elements than @a.
In cases 1) and 2), the problem is how to get the elements of the larger
array that were never iterated over. Case 2) is probably better than case
1), because the exception that is thrown might contain information about
which array was larger and which elements of it have yet to be examined. In
case 3), the problem is differentiating between an undef returned because
the arrays were of different sizes, and an undef returned because one of the
arrays contained an undef.
Joe Gottman
Re: Iterating through two arrays at once
On Wed, Dec 10, 2003 at 11:44:15PM -0500, Joe Gottman wrote:
:In Perl 6, how will it be possible to iterate through two arrays at the
: same time? According to Apocalypse 4, the syntax is
: for @a; @b -> $a; $b {
:
: According to the book "Perl 6 Essentials" the syntax is
: for zip(@a, @b) -> $a, $b {
:
: Which of these is right? (of course, this being Perl, both may be right).
The latter is righter.
: Whichever of these syntaxes is right, what happens when @a and @b are of
: different sizes? I can think of three possible behaviors, each with its
: potential drawbacks:
:
: 1) The loop executes min(+ @a, + @b) times, then finishes successfully.
: 2) The loop executes min(+ @a, + @b) times, then throws an exception
: because the arrays were not of the same size.
: 3) The loop executes max(+ @a, + @b) times. If @a has fewer elements
: than @b, then after @a's elements are exhausted $a is set to undef, and
: similarly if @b has fewer elements than @a.
3 is what happens. That has not changed from the Apocalypse.
:In cases 1) and 2), the problem is how to get the elements of the larger
: array that were never iterated over. Case 2) is probably better than case
: 1), because the exception that is thrown might contain information about
: which array was larger and which elements of it have yet to be examined. In
: case 3), the problem is differentiating between an undef returned because
: the arrays were of different sizes, and an undef returned because one of the
: arrays contained an undef.
In Perl 6, undef is not necessarily a unique value. It might well contain an
unthrown exception with all the information you want hidden in a property.
That being said, it's generally erroneous to rely on any undefined value
regardless of its origin.
Larry
