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

Jan 12, 2003 by Piers Cawley

… And we’re back. Yup, it’s summary time again. We’ll dive straight in with perl6-internals (as if you expected anything else).

More Thoughts on DOD

Leopold Tötsch posted a test program showing the effects of PMC size and timing of garbage collection and allocation and suggested ways of improving the GC system based on the conclusions he drew from its results. Leo, Dan and Mitchell N Charity discussed this further and tried a few different approaches to try and improve performance (though Mitchell did worry about premature optimization). Work in this area is ongoing.

http://groups.google.com/groups

The Perl 6 Parser

Dan asked about the current state of the Perl 6 parser, wanting to know what was and wasn’t implemented, and wondered about adding the Perl 6 tests into the standard Parrot test suite. Sean O’Rourke and Joseph F. Ryan both gave a summaries of where things stood. Joseph also suggested a few refactorings of the parser to deal with the fluidity of the current spec (almost all the operators have changed symbols since the parser was first written for instance).

http://groups.google.com/groups

LXR - Source code indexing

Last week, I said that Robert Spier had ‘started work on getting a browseable, cross-referenced version of the Parrot source up on perl.org.’ What actually happened was that Robert asked Zach Lipton to do the work. This week, Zach delivered the goods, which, I must say, look fabulous.

I’m sure that if someone were to extend LXR so it had a better understanding of .pasm, .pmc, .ops and other special Parrot source types, then the community would be very grateful indeed. I know I would.

http://groups.google.com/groups – Announcement

http://tinderbox.perl.org/lxr/parrot/source

Thoughts on Infant Mortality

Piers Cawley offered what he thought might be a new approach to dealing with the infant mortality problem that got efficiently shot down by Leo Tötsch. This led to further discussion of possible answers, and it looks like Leo’s proposed solution involving a small amount of code reordering and early anchoring will be the one that’s tried next. All being well, it won’t require walking the C stack and hardware register set, which can only be a good thing.

Later, Leo asked whether it’d be OK to check in his work so far on redoing the GC because he was up to 15 affected files and was starting to worry about integration hell. Steve Fink wasn’t sure about one of his changes, so Leo checked in everything else.

http://groups.google.com/groups

http://groups.google.com/groups

Objects, Finally (try 1)

Last week, I mentioned that Leon Brocard’s wish list for the next Parrot iteration included Objects. This week, Dan posted his first draft of what Parrot Objects would and wouldn’t be able to do. The 11th entry on Dan’s list (Objects are all orange) seemed to be custom-made to please Leon. There was a fair amount of discussion (of course), but the consensus was positive.

http://groups.google.com/groups

The Benchmarking Problem

Nicholas Clark crossposted to p5p and perl6-internals to discuss the problems of benchmarking Parrot against Perl 5. One of parrot’s aims is, of course, to go faster than Perl 5. The problem is, how do you measure ‘faster’? Nicholas has been working on making Perl 5 go faster and was distressed to find out that using ‘perlbench,’ a patch of his went 5 percent faster, 1 percent slower, zero and 1 percent faster, depending on what machine/compiler combination he ran the benchmark on. Leo Tötsch commented that he’d found performance varying by more than 50 percent in a JIT test, depending on the position of a loop in memory. Andreas Koenig commented that he’d come to the conclusion that bugs in glibc meant that there was little point in benchmarking Perl at all if it was built with a glibc older than version 2.3 (apparently malloc/free proved to be gloriously erratic…) I’m afraid not much was actually resolved though.

http://groups.google.com/groups

Meanwhile, in perl6-language

The discussion of Variable types versus Value types continued from the previous week. Dan opined that Arrays weren’t necessarily objects, which brought forth squawks from Piers Cawley who pointed out that being able to do:

   class PersistentList is Array { 
       method FETCH ($index) { 
           ...
       }
       ...
   }

would be much nicer than tying a value in the Perl 5ish fashion. Dan reckoned that delegation would probably be enough which, IMHO, seemed to miss the point. Various other people chimed in to, essentially, tell Dan that he was wrong, but I’m not sure Dan agreed with them.

Meanwhile, in a subthread sprouting lower on the thread tree, Damian pointed out that there were two types associated with any Perl variable – the ‘storage type’ and the ‘implementation type.’ (See his post for details) Essentially the storage type is the type associated with the contents of a variable and the implementation type is the type of the ‘thing’ that does the storing – usually one of SCALAR, HASH or ARRAY – i.e., related to the variable’s sigil. Specifying a different implementation type will probably be how Perl 6 does tying.)

http://groups.google.com/groups

http://groups.google.com/groups

Array Questions

In a thread that spilt over from the previous discussion about whether arrays were objects, Michael Lazzaro put up a list of examples that seem to imply rather strongly that arrays are either objects or indistinguishable from them, and there was general muttering that being able to overload tied Perl containers in this way was a neat way of implementing tie semantics. Mr Nobody attempted to restart the left-to-right versus right-to-left argument. There was also some discussion of the sickness of my Foo @foo is Foo (which, in Perl 5ish parlance creates a tied array – using Foo as the tying class – which can only contain objects in class Foo.) Damian agreed that this was definitely sick, and that he for one would be making use of it.

http://groups.google.com/groups

L2R/R2L Syntax

Argh! No! It’s back and this time it means business. The dreaded left->right versus right->left thing came back, and this time it was Damian applying the electrodes to the corpse. Of course, it being Damian, he was instantly forgiven as he came up with the very cool, very low precedence ~> and <~ operators, allowing you to write

   @out = @a ~> grep {...} ~> map {...} ~> sort;

Which is, to these eyes at least, lovely. See Damian’s post for the full details. The general response to this was definitely on the ‘lovely’ side of the balance, though one detractor did induce a sense of humor failure on Damian’s part. There was also a certain amount of discussion about whether this was exactly the right syntax to go with the semantics, but where would perl6-language be without a great deal of syntactic quibbling? (A good deal easier to summarize). The most popular alternatives were |> and <|. There was also a certain amount of discussion of what I can only describe as ‘evil’ uses of the syntax, involving arrows going in different directions in one statement. Rafael Garcia-Suarez earned at least one giggle when he suggested that we just needed v~ ^~ and we had our own flavour of Befunge.

There was a fair amount more discussion, mostly thrashing out details and edge cases.

http://groups.google.com/groups

“Disappearing” code

John Siracusa wondered whether there would be a perl6ish way of creating code that was ‘the spiritual equivalent of #ifdef, only Perlish.’ To which the answer is, of course, ‘yes.’ Damian showed off a neat trick (modulo a couple of pretty typos) with an immediate function that demonstrated using Perl 6 as its own macro language.

http://groups.google.com/groups

http://groups.google.com/groups – Damian’s neat trick

In Brief

Jim Radford fixed some typos in the rx.ops documentation.

Who’s Who in Perl 6

Who are you?

Steve Fink. Some guy who writes code.

What do you do for/with Perl 6?

The only thing I set out to do was implement a regular expression compiler. Along the way, I seem to have implemented hashtables, patched the configuration system, messed with memory management, implemented some stuff for IMCC, beefed up the PMC file parser, fixed some problems with the JIT, and a few other things. Then I got a job and ran out of time to work on Parrot, so they made me pumpking. And I still haven’t made it that far with the regex compiler.

Where are you coming from?

Computer games, originally. First language, BASIC; second language, 6502 assembly. Then a failed attempt at C, then more successful encounters with Pascal and 68000 assembly, and then C++. Next, a few more assembly languages together with SML, NESL, Lisp, Scheme, COBOL, Tcl, Prolog, and a few others. And, at last, Perl4 and then Perl5. Oh, and Java, fairly recently. My day job is now in a combination of Perl5 and C++, as well as C when nobody’s looking.

When do you think Perl 6 will be released?

Probably smoothing the path for other developers and keeping them motivated. My highest priority is applying (and testing) other people’s patches, since the mostly likely reason for someone to lose interest is to not have their hard work make it into the distribution. I would also like to somehow make people’s contributions more visible – anyone who has contributed anything significant should at least be able to point to something and say “Look! I did that! See my name?!”

I said, when do you think Perl 6 will be released?

Obviously, Leopold Tötsch. Anyone paying an iota of attention would know that. Particularly someone who’s been writing the summaries, unless you’re stupid or something. Leo’s amazing; I don’t know how he finds the time. To accomplish that much, I’d need to be working full-time about 26 hours a day.

No, really. When do you think Perl 6 will be released?

No, not really. I was originally thinking of Perl6 when I got involved, but since then the Parrot VM itself has become more interesting to me. Although I still wish Perl6 development would pick up – there’s a lot that can be done even with the limited amount of the language that’s been defined. Sean O’Rourke did an excellent job in a short amount of time, but it looks like real life has drawn him back into its fold, and nobody seems to have picked up the slack.

Why are you doing this?

Heh. That is the question, isn’t it? Making a release is probably the most concrete measure of how I’m doing as a pumpking, and by that standard I’m a dismal failure. As soon as we reclaim the tinderbox (and without dropping any machines off it in order to do so!) Everything else I wanted to get in is already there.

You have five words. Describe yourself.

No, I don’t think so. Maybe I’m wrong, but I know that I personally had to put aside a lot of the actual coding I was working on in order to concentrate on making sure everyone else’s changes were being given proper consideration. I’d much rather relieve him of that burden, and let him continue to exercise his demonstrated talent at churning out quality code.

Do you have anything to declare?

No. It kind of makes sense, but I remember how I first started by rewriting a bunch of Dan Sugalski’s code, and then seeing most of my code get rewritten. I used to be disturbed by that, but now I think of it more as a badge of honor – it proves that what I wrote was worth rewriting. Much more so in Dan’s case, I suppose, since he stated up-front that he was merely doing a reference implementation of a design. Dan’s done an amazing job of laying out a design that hasn’t needed to change at its core, and so has been a very dependable guide to the implementation of the backbone. But even in my case, I can see a number of ideas that were carried through in the reimplementation, even if no actual code survived. (Interestingly, my tests did. Which kind of makes sense if you think about it.)

Are you finished yet?

Why yes, thank you.

Ahem. Thanks Steve. Really.

Acknowledgements

Another Monday evening, another summary running over into Tuesday morning. Ah well. Distractions were provided by the usual suspects (Mike and Sully, our ginger kittens), supplemented this week by a horrible cold (the compulsion to find a tissue does tend to derail the train of thought).

Proofreading was once more handled by Aspell and me. This week, we even made sure that the Who’s Who section contains the name of the person answering the questions rather than making you wait ‘til the acknowledgements section.

Speaking of which, many thanks to Steve Fink for his answers to the questionnaire (well, to the questions he wanted to answer anyway). The questionnaire queue is now quite empty so, unless a few more folks in the Perl 6 community send me some answers soon then the Who’s Who section may be going on hiatus. Send your answers (or request the ‘correct’ question list from) 5Ws@bofh.org.uk.

If you didn’t like this summary, then how did you get this far? If you did like it, then please consider one or more of the following options:

The fee paid for the publication of these summarize on perl.com is paid directly to the Perl Foundation.

The Perl 6 Summarizer disclaims any and all responsibility for the sanity of his readers; he’s having enough trouble hanging onto his own.

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