This week on Perl 6, week ending 2003-01-26

Jan 26, 2003 by Piers Cawley

Welcome to the first Perl 6 summary of the new ‘Copious Free Time enabled’ era, which should mean that these summaries will get mailed out on Monday evening from now on.

We start, as usual, with perl6-internals

The eval patch

Leopold Tötsch continued to work on making eval and its associated operators work and asked for some opinions about a problem he was having with jumps between code segments. Jason Gloudon played sounding board and the two of them found a way forward.

http://groups.google.com/groups

The Parrot crashes

Dan announced that Parrot was crashing big time under (at least) OS X, throwing segfaults in the NCI mark routine. Other people contributed reports of what was happening on their platform and Leo Tötsch tried to track down the error, working on the assumption that it was something to do with his eval patch as that was the last patch that had gone in.

Later in the week Dan realised that part of the problem with OS X was a problem with imclexer.c, an autogenerated file being generated with bad code. Leo reckoned it was a problem with something having been multiply defined, which had since been fixed.

Still later in the week, Steve Fink offered some analysis on the NCI mark routine and a patch which attempted to fix the problems he saw with it. Leo reckoned that the patch wasn’t quite right, but the analysis was good and used that to fix the problem and discovered in the process that the parrot build process’s dependency analysis wasn’t quite up to the mark. (I don’t think there’s a fix for that yet, but at least we know the problem exists…)

http://groups.google.com/groups

http://groups.google.com/groups

http://groups.google.com/groups

Compiling to Parrot

K Stol is looking for a final project for his Bachelor’s degree and would like to implement some language targeting Parrot and asked for suggestions. Simon Wistow suggested PHP or Lua, Leon Brocard suggested Java (though Gopal V wasn’t sure that was such a good idea just yet). Dan suggested that, just because someone else was already working on a TCL compiler it didn’t mean it wasn’t worth trying anyway, but apparently it would have been unlikely to get approval as a Bachelor’s project. There was some further discussion of Lua and whether there would be any real point in implementing it and the thread died down before Mr Stol told anyone what he’d decided to do, which was rather a shame I thought.

http://groups.google.com/groups

Extending the packfile format

Some months ago, Jürgen Bömmels offered a patch to extend the Parrot packfile format whilst retaining backward compatibility. This week, after a little modification, Leo Tötsch applied it. James Mastros wondered if it didn’t make sense (at least before parrot 1.0) to ignore backward compatibility issues and just make it right. Leo and Dan agreed, but Leo pointed out that, at least until the switch from assemble.pl to IMCC was complete, maintaining backward compatibility was the right thing. (So, if you’re currently using assemble.pl to assemble your language, consider moving it to IMCC sooner rather than later).

http://rt.perl.org/rt2/Ticket/Display.html

The long running Objects thread

Discussions continued. A good deal of time this week was spent discussing the overrideablility (there’s got to be better word than that…) of OO method dispatch for different languages (and at a language level too I hope – I like flexibility). Python for instance seems to require that every step in the process be subject to override. Dan pointed out that dispatch would end up being implemented as vtable methods on per language Object PMCs so that messages from one language’s objects to another’s would use the target language’s dispatch rules. Which seems rather cute (in a good way).

http://groups.google.com/groups – Christopher Armstrong talks about Python

http://groups.google.com/groups – Dan on how it works.

Intersegment branching

Leo Tötsch added a new opcode for intersegment branches, called branch_cs which was his implementation of the fix that he and Jason Gloudon had discussed while talking about problems with eval. Dan didn’t think Parrot needed this and that we could just use a plain jump. Leo pointed out that there were several places where this didn’t quite work, especially in the presence of JIT optimization. Dan didn’t think that didn’t mean it wouldn’t work, but reckoned that the cases Leo pointed out were reasons he wanted to see intersegment jumps mediated by subroutine calls. Leo followed up to this with an example. I can’t for the life of me tell if this was a counter example, a suggestion or what though.

This reemerged as a new thread with the subject ‘Transferring control between code segments’. Dan opened the thread by discussing the design perspective and laying down a few edicts. He went on to discuss the issues that Leo’s ‘phenomenally cool’ compile opcode has exposed in his earlier handwaving and replaced the handwaves with more detail.

People were generally happy to see this, but there were a few small issues with it which weren’t explicitly resolved this week.

http://groups.google.com/groups

http://groups.google.com/groups – Design issues

Bytecode Metadata

Dan responded to the earlier discussion of extending the packfile format by opening a discussion of the type of metadata that might be useful to have in either the on disk packfile or in memory bytecode. He reminded everyone that parrot may have to ignore (or at least mistrust) the metadata and opened the floor suggestions.

James Michael DuPont came up with a proposal involving RDF which Dan thought might well be overkill (albeit interesting overkill) since he had been thinking more about metadata that would be used by the engine itself or provided to programs running on it.

Various other suggestions were made, and it’s apparent that one immutable design guideline is that any bytecode format for Parrot must allow for executable code to be mmapped in.

Leo Tötsch has a patch implementing a simplified API for generating packfiles and wondered if he should check it in.

http://groups.google.com/groups – Opening remarks

http://groups.google.com/groups – The RDF bazooka

Odd JIT timings

Dan reported that examples/assembly/mops_p.pasm was running slower with JIT optimization than without under OSX, which doesn’t seem right. Daniel Grunblatt pointed out that JIT cores that don’t optimize many opcodes will always be slower than a Computed Goto (CG) core and there aren’t many optimized opcodes for the PPC architecture. Bruce Gray pointed Dan at an introduction to PPC assembler in case Dan wanted to add to the score of optimizations. Anyone else is interested could take a look too, kudos awaits the heroic implementer.

http://groups.google.com/groups

http://www-106.ibm.com/developerworks/linux/library/l-ppc/

Meanwhile, in perl6-language

There was a little more diversity of discussion this instead of concentration on a single massive thread, though that thread did, of course, continue on its path.

L2R/R2L syntax

There was some discussion of implementing conditionals (if, else etc) as functions rather than special keywords. Personally I’m not sure that anything that monkeys with Perl’s normal order of evaluation can strictly be called a function, but what the hey.

Buddha Buck showed off a rather neat implementation of if, then and else which borrowed some of its implementation from a Smalltalk like ‘Bool’ class with isTrue and isFalse methods and then used multiple dispatch to get the rest.

In another subthread, Michael Lazzaro explained why he still wanted Right to Left pipelining, even though he was much more at ease with Perl 6’s rules for when you needed a comma in an argument list. It appears to be mostly about teachability.

Damian popped up to make (at least) Graham Barr and me happy when he said that he didn’t think the Perl 5ish functional forms of map and grep etc would be going away. Huzzah!

http://groups.google.com/groups – Buddha’s Smalltalk port of conditionals

http://groups.google.com/groups – Michael Lazzaro on grep, map and explicit pipelines

http://groups.google.com/groups – map/grep/etc still functions

A proposal on if and else

Brent Dax proposed a solution to the problem of implementing if and else as functions (the problem being that, unless you cuddle all your elses, perl will intuit a semicolon at the end of if’s block and things will get confused) by proposing that all code blocks take an optional ‘else’, accessed by the $code.else attribute, one of the side effects of which would be that elsif would become else if.

Austin Hastings wondered if supporting ‘separable verbs’ might be a better way forward. The idea certainly looks interesting, the best summary of the idea I can give you is to point you at Austin’s original message though.

http://groups.google.com/groups – All blocks are elseable

http://groups.google.com/groups – Separable verbs

Arc: An Unfinished Dialect of Lisp

Rich Morin pointed everyone at Paul Graham’s presentation at the first Little Languages conference about Arc, pointing out that Graham had some interesting things to say about language design. The discussion that followed was mostly off topic (in the sense that they weren’t talking at all about Perl 6). Graham’s paper is interesting though.

http://groups.google.com/groups

http://paulgraham.com/arcll1.html

Array/Colon question

Michael Lazzaro wondered about the seemingly different meanings of colon in:

    print $FH : $a;    # $FH is an indirect object
    @a = 0 .. 10 : 2;  # @a is (0,2,4,6,8,10)

and wanted to know when : meant ‘step’ and when it designated an indirect object. Brent Dax helped clear things up. Essentially : is a ‘supercomma’ and different operators and functions interpret what comes after the supercomma in different ways. .. treats it as specifying a step.

http://groups.google.com/groups

Multiple Dispatch by Context?

Piers Cawley wondered if it would be possible to specify a multimethod by context as well as by parameter types. Dan Sugalski managed to hole the proposal below the waterline with a neat set of multidispatch declarations that led to a horrible ambiguity. Thomas A Boyer pointed out that Ada can handle such ambiguities but that it was a complete pain to implement and voted against using return type for multiple dispatch.

http://groups.google.com/groups

Who’s Who in Perl 6

Ah… um… I appear to be lacking an answer set this week.

Announcements, Acknowledgements and Apologies

I’m afraid to have to announce that, as of this week I can no longer donate the fee for these summaries to the Perl Foundation it’s currently my only source of income. On the positive side, now that I don’t have to spend 8 hours a day working for someone else I should be able to get the Summary mailed out to the Perl 6 lists on a Monday from now on.

Thanks to everyone who sent me mail about my redundancy. No matter how good it feels not to have to get up at 5.50 every morning with the prospect of not getting home again ‘til at least 18.40 it’s still a terrible shock to lose your job. Thankfully we look to be in a much better position this year than we were last time I was out of work; I’m hoping that, if I can get a few more freelance writing gigs and maybe a little consultancy I’m not going to have to go back to the 4 hour commutes for the foreseeable future.

Thanks too to everyone who’s given me answers for the Who’s Who section since this summary started. I’m sorry to be retiring it for now, but as new blood filters into the Perl 6 community I hope I’ll be able to restart it some time further down the road.

If you appreciated this summary, please consider one or more of the following options:

Tags

perl-6
perl-6-internals-parrot

Feedback

Something wrong with this article? Help us out by opening an issue or pull request on GitHub