| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Another week, another Perl 6 summary. I'm running late writing this and I don't care because I spent the bank holiday weekend at a folk festival and didn't get back 'til Monday evening.
Predictably enough, we'll start with the shenanigans in perl6-internals.
The timely destruction meme just won't go away. This week Luke Palmer
suggested a possible improvement to Parrot's current scheme (Parrot
keeps a counter of 'eager' objects needing timely destruction, and
a language's compiler emits conditional sweep opcodes at
appropriate points. In Perl's case, for instance, the conditional
sweeps would be triggered on scope exit, other languages may have
different requirements).
Luke's scheme involves terminating the DOD (Dead Object Detection)
run if every outstanding eager object is found alive at any point in
the run. For added performance, there would also be a 'high priority'
flag on all objects. The idea is that the high priority flag could be
used to ensure that, during a sweep, the paths through the object
group that are likely to lead to an eager object get checked first,
hopefully ensuring that the sweep gets terminated as quickly as
possible in the case where no eager objects need to be finalized.
The proposal was discussed, but I don't think anyone has gone so far as to implement anything based on the scheme.
This discussion led Klaas-Jan Stol to ask what the heck timely destruction was, anyway. This sparked a longish discussion, covering what timely destruction is all about, why you'd want it, and why having it could be problematic.
Benjamin Goldberg is concerned with 'a number of shortcomings in the [string] API' and outlined the problems he sees, along with some proposed improvements. Luke Palmer generally liked the ideas, but Leo Tötsch had concerns about some of Benjamin's proposals. The discussion that ensued got fairly technical. (One of these days I'm actually going to go and get my head properly around the details of the various encodings and charactersets. And then I'll probably go insane.)
Dan also thought that Benjamin was confusing language level strings with low-level strings, and that this was a Bad Thing. He outlined the difference between language level (PMC) and low-level (Parrot S register) strings, and explained what each was appropriate for.
Allison Randal sent in a patch to switch languages/perl6 -- Parrot's (incomplete) Perl 6 Compiler -- over to using Continuation Passing Style, which is a useful step in the right direction. Leo applied it.
search_lexJos Visser (who in an earlier post confided that he's working on
writing a parrot compiler back end for his personal 'computer
language personality disorder: Comal', and that he does this for
'therapeutical value') wants to generate some parrot code that is
capable of searching the lexical pads for the existence of a
lexical. His current code tries to look up a lexical and catches the
exception when the lexical doesn't exist, but this is apparently very
slow. So, he proposes an op, search_lex which, instead of throwing
an exception, returns a null PMC if the lexical is not found.
Leo Tötsch wasn't convinced by the need for the op, but he is looking into why the exception handling route is so slow (indeed, he seems to have found the reason, now he's trying to fix it).
Inspired by Luke Palmer's cunning, core.ops parsing vim syntax highlighter, Andy Bussey wrote something similar for the KDE Kate editor. Now, if someone could modify pasm.el, the Emacs highlighting mode to use the autogeneration trick too...
Leo Tötsch kicked off a discussion of the handling of constants within Parrot and proposed adding a bunch of functions for creating constant strings (symbols?) within the core. He also proposed a system for creating constant classes. In the ensuing discussion I think the proposals for strings were pretty much accepted, but it's not yet known if the proposal for constant classes is quite the Right Thing.
Tom Locke is about to start on a project to create a new language and wondered if Parrot might be a good target VM for him. In short, we think so. But we would, wouldn't we?
The semantics of set in Parrot are, somewhat complex. Leo
Tötsch showed a fragment of code which got a value from out of
a hash, set the fetched value to a new value and then printed out the
value from the hash. Depending on whether the original hash entry
existed or not, the fragment of code printed different things. He
wondered if things shouldn't be fixed to make it print the same thing
each time. Consensus has not yet been reached.
Tom Locke reopened the register or stack machine can of worms. He even offered to recan them afterwards (by writing up the discussion for adding to the FAQ). In particular, he wanted to know what we thought Miguel de Icaza meant when he claimed that Parrot was "based on religion". Klaas-Jan Stol pointed us at Dan's blog where he'd addressed this issue some time ago.
Benjamin Goldberg hoped that Parrot would have some way of creating Weak References, as he felt that they were probably a vital feature. He outlined a scheme for implementing them. Various people disagreed about their level of vitality.
Dan pointed out that weak refs could be implemented with no special core support beyond a general notification mechanism (which we're getting anyway) and a weak reference PMC. Dan seemed to think that this had already been discussed, but I confess that I can't remember the discussion and, as Benjamin pointed out, it looks like Google can't remember it either.
Leo kicked off a discussion of embedding debugging information (line
numbers, both for parrot code and the original high level code) in
parrot bytecode. Right now, only the slow core tracks lines within
the pasm file, and he wondered if using the -w switch should
automatically force using the slow core.
Nobody actually answered that question, choosing to discuss the various means of storing meta data about line numbers and the like in the bytecode file. Consensus hasn't been attained yet, but I think we're getting there.
As he warned some time ago, Leo has finally removed the 'feature'
whereby IMCC would parse code it found outside of subs. All IMCC code
must now be contained in .sub/.pcc_sub/.emit blocks. If
you're writing code that doesn't behave properly, please fix it.
Leo noted that Parrot programs get commandline info passed in in P0, but there is currently no way for a parrot program to communicate an exit status to the shell. Leo offered up 3 different possibilities for fixing this and asked for comments. Dan came up with a 4th option involving a status PMC. Discussion is ongoing.
There were all of 6 messages. Gordon Henriksen moved the set/assign discussion over from perl6-internals, asking for clarification of what various bits of Perl 6 should do. Essentially it boils down to 'when should Perl 6 autovivify?'. The discussion is ongoing.
my Dog $spotDoes anyone want to buy a four bedroomed house in Newark upon Trent, dating back to the late 16th century? The house is on the market, Gill's term starts on September 15th and so far the Estate Agents haven't sent any prospective buyers. Well, at least it gives me time to write the summary.
Check out www.bofh.org.uk for more of my writing (and thanks to those who have already popped by).
As ever, if you've appreciated this summary, please consider one or more of the following options: