This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/

The Perl 6 Summary for the week ending 2005-04-26

It's my turn again. What fun.

"What," I hear you all ask, "has been going on in the crazy mixed up world of Perl 6 design and development"? Read this summary and, beginning with perl6-compiler, I shall tell you.

This week in perl6-compiler

Refactoring Test.pm

Stevan Little had an idea while he was refactoring Test.pm. He wondered whether to get rid of the various todo_* functions in favour of just using a t/force_todo file. Which led him to wonder about doing away with t/force_todo in favour of a force_todo() function. He asked for opinions before he started making the change (which isn't exactly a refactoring).

General opinion seemed favourable, though I confess I am perturbed by the proposed release trick of proclaiming all failures, whether expected or not, to be TODOs. The current system generates an explicit list of tests that are failing on 'core' systems. The proposed solution would seem to make all failures equal, so even unexpected 'platform' failures wouldn't be caught.

groups.google.com

Weird thing with say ++$

What do you know, say $i++, ++$i behaves weirdly.

groups.google.com

Pugs 6.2.1 released

Autrijus announced the availability of Pugs 6.2.1 which comes complete with much shininess.

groups.google.com

This week in perl6-language

Parrot Common Lisp

Cory Spencer's port of Common Lisp to Parrot was much admired (it's got some way to go before it's really Common Lisp, but it's a cracking start). Uwe Volker suggested porting emacs to it and was promptly accused of being Erik Naggum by Lars Balker Rasmussen.

Cory acquired (or is acquiring) a committer bit.

groups.google.com

State of the Tcl

Will Coleda gave the list a heads up on the state of ParTCL, the Parrot TCL port. It's still failing some tests, apparently because of GC issues.

A few days later, these problems went away (we're not quite sure how though).

groups.google.com

groups.google.com

alarm() and later()

Leo stated that Parrot provides subsecond timer resolution as well as alarm callbacks and multiple timers. Hurrah!

groups.google.com

RFC assign Px, Py

Leo posted a discussion of the semantics of assign and set, with a proposed change to PIR syntax. Warnock applies.

groups.google.com

RFC unary operations

In another RFC, Leo discussed changes to Parrot's unary operators and proposed other changes.

groups.google.com

One more MMD -- assignment

Dan noted that he was writing a great deal of code in his set_pmc vtable methods that looked very MMD-like. He suggested that adding assignment to the list of MMD functions might be a good idea. Leo pointed him at his assignment RFC.

groups.google.com[172.24.18.155]

Fun with morph()

Nicholas Clark wondered about the responsibilities of the morph method with respect to handling PMC_struct_val. In the subsequent discussion it became apparent that morph can get complicated. Bob Rogers supplied a bunch of extra complications and wondered about the feasibility of making Parrot morph-free. Leo agreed that it seemed feasible and is probably a good idea. Another subthread made my head hurt -- I can understand this stuff much better when I'm sat 'round a table with people and we're kept supplied with drinks, notepaper and, in Leo's case, industrial quantities of tobacco. (Ah... YAPC::Paris!)

groups.google.com

Building an incomplete code generator into Parrot

rocko@adampreble.com (that's the only name I have) has started work on implementing a JIT backend for the AMD64 processor. He asked a few questions and Leo provided answers.

groups.google.com

Calling Convention Abstraction

This thread continues to rumble on. Leo said that what he wants is for the HLL folks to create a workable scheme for abstract and extendable calling conventions that could express all the various HLL specific semantics of function calling, pointing out that, unless we have this we can forget interoperability (or at least, easy interop).

groups.google.com

Alpha development Box

Bob Rogers 'has' an Alpha development box that can be used for open source projects. He wondered if the Parrot project could make use of it, and if so what was the best way of doing this. Some discussion occurred on the list, but I assume (hope) more happened offline.

groups.google.com

Meanwhile, in perl6-language

Calling junctions of closures

Brad Bowman wondered about calling junctions of closures. He guessed that the rule is "call 'em all and return a similarly structured junction." but wasn't sure. Thomas Sandla\xDF wasn't so sure.

My head hurts.

groups.google.com

{ => } autocomposition

Autrijus asked about the following fragment:

    %ret = map { $_ => uc $_ }, split '', $text;

which gives Pugs a massive headache.

>From the ensuing discussion, it appears to cause Larry and Autrijus headaches too. Also, it turns out that Larry's Perl 5 to Perl 5 translator has both madprops and madskills. Hurrah! Darren Duncan suggested that

    %ret = map:{ $_ => uc $_ }, split '', $text;

should serve to say that the block is to be treated as a block rather than a hash constructor. He thought that that came from one of the synopses, but couldn't remember which.

I wonder if

    %ret = map -> {$_ => uc $_}, split '', $text; 

wouldn't do the job. (Or did the syntax change on me when I wasn't looking?)

groups.google.com

Embedding languages in Perl 6

B\xC1RTH\xC1ZI Andr\xE1s had some questions about introducing different parsing rules in the middle of a Perl 6 program. Larry's answer was, essentially "All's fair if you predeclare", but with an interesting idea about using ` as a way of introducing a 'self-terminating construct', so one could do:

   use XML;

   $a = `<elems><elem>Content #1</elem><elem>Content #2</elem></elems>;

or

   use SQL;

   $a = `select * from table`;

Various possibilities were discussed, but nothing got set in stone.

groups.google.com

Closure/block/sub multiplier

Matt Creenan wondered about doing @names = &get_next(...) XX 5; (which, obviously, would call &get_next five times and shove the results into @names). Juerd pointed out some subtleties to do with functions that return closures. Later in the thread he decided that he controlled both the horizontal and the vertical, with particular reference to redefining true, false and undef.

groups.google.com

alarm() and later()

Remember the discussion of alarm and later in perl6-internals? It moved over to perl6-language. Larry agreed that Perl 6's time interfaces would favour floating point time values, but he wasn't quite sure if any of them would be called alarm. Discussion ensued, both on the topic and matters of naming style.

groups.google.com

$?OS globals, etc

Scott McWhirter proposed making the various $?OS etc variables into attributes of some GLOBAL class. Larry thought it was a good idea, but wasn't sure it was entirely right as proposed; this area is still being designed.

groups.google.com

Parens vs. subroutine parameter

Autrijus had a question about how function signatures and various forms of paren magic interacted. He, Juerd and Larry thrashed things out.

groups.google.com

-Xs auto-(un)quoting

Michele Dondi had some questions/suggestions about the various file test operators. Larry answered and the thread spun off into a discussion of all sorts of aspects of these handy operators. Well, that was before it turned into a discussion of the semantic of <.foo>, or was that ^foo, or maybe _foo, or possibly ....foo. At this point, things got a little heated. There's no decision as yet (personally I'm a fan of the scheme as originally proposed; .foo calls the method foo on the current topic, whatever that may be. If you need to hang onto old topics, give them a name. I appear to be in something of a minority).

groups.google.com

Unify cwd

It turns out that the 'current working directory' isn't as obvious as it sounds. It also turns out that Larry would like to be able to pretend that it is until it turns out not to be.

groups.google.com

Blocks, continuations and eval

When last we saw this thread, Larry had said that continuations would be available in Perl for people who ask specially, but wouldn't be left lying around in the open where 'some poor benighted pilgrim might trip over them unaware'. Wolverian asked what the interface would be. Larry thought it would probably start use Continuations;, or possibly use CONTINUATIONS;.

The thread prompted St\xE9phane Payrard to ask about the possibility of some of the more 'out there' functional programming tricks making it into Perl 6. Once again, all's fair if you predeclare, but it looks like Perl 6 already has core access to some pretty out there stuff.

groups.google.com

Accepted abbreviations

Juerd wondered if we could compile a list of standard abbreviations for various terms so that they can be consistently applied. He kicked off with a list of his own. There was some discussion but I somehow doubt his list will be used rigorously.

groups.google.com

Thunking semantics of :=

Once someone starts to implement a language, you get a wonderful driver for design decisions that need to be made and ambiguities to be ironed out. On this occasion, Autrijus needed some clarification of the semantics of the binding operator, :=. Ambiguities were ironed, and implementations were written (and yes, I do mean implementations).

groups.google.com

for all(@foo) {...}

Brad Bowman had questions about the workings of for all(@foo) {...} based on S03. It turns out that the synopsis is wrong. Larry explained how it's supposed to work (which is how it already works in Pugs).

groups.google.com

Lazy Lists + Mutable Arrays + Garbage Collection

Brad also had questions about the workings of lazy lists. In particular, he wondered about treating streams as mutable arrays. Warnock applies.

groups.google.com

map { $_ => uc $_ }, @foo again

Autrijus proposed a cunning plan to deal with the ambiguities inherent in:

    map { $_ => uc $_ }, @foo;

by suggesting that using a block without the comma should force said block to be interpreted as a block rather than a hash constructor. Larry wasn't sure, arguing that it were best to disambiguate with something just before, or just inside the block (in the same way that pattern modifiers now go before the pattern).

groups.google.com

Passing hash to a sub expecting named params

Carl Franks wondered if he could pass a splatted hash (*%hash) to a function that expects named arguments. Answer, yep.

groups.google.com

Turning off warnings for a function's params?

David Storrs wanted to be able to turn off selectively turn off some warnings when he's testing. He asked how to go about doing it. Luke and Juerd provided some answers.

groups.google.com

How do I... tie hashes/arrays

Discussion of how to tie hashes and arrays continued.

groups.google.com

Surprising consequences

Juerd worried that code like if($foo) { say 'foo'} would throw syntax errors. It turns out that one of his givens wasn't quite as given as he though. So it's not a syntax error.

groups.google.com

Calls and parens

Juerd posted a set of examples of the new rules for parsing parentheses in function calls and asked which of his assumptions were wrong. Luke Palmer reassured him.

groups.google.com

Context and index expressions

Autrijus posted a set of examples of array indexes and asked if he'd got all the contexts right. There was no answer at the time of writing.

groups.google.com

Hmm... still fun. I could get used to this.

If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl.

donate.perl-foundation.org -- The Perl Foundation

dev.perl.org -- Perl 6 Development site

Or, you can check out my website. Maybe now I'm back writing stuff I'll start updating it.

www.bofh.org.uk

Vaguely pretty photos by me can be found at:

www.flickr.com

See you all in a fortnight.