This week on Perl 6 (10/20-27, 2002)

Nov 4, 2002 by Piers Cawley

You may have noticed that this summary is late. Um … [looks sheepish, shuffles feet], the dog ate my homework. I did a tiny bit of procrastination at the beginning of the week and then got totally overtaken by events involving failed AC adaptors and general confusion. Sorry folks, it will probably happen again, but hopefully not in the near future.

So, kicking off, as is customary, with perl6-internals before getting down to attempting to summarize the monster that was perl6-language:

C# and Parrot

The dialogue with Rhys Weatherley and Gopal V from the DotGNU project continues apace, mostly to do with clarifying what C# needs in the way of datatypes and the like. It appears that Leon Brocard is the go to guy if you need to know the exact details of almost anything in a language spec. Maybe he’s just really good with Google.

Gopal V wondered whether there was someone involved in p5i who would mind acting as a liaison with the DotGNU people and who could give them a heads up when, for example, the packfile format changed. Leopold Toetsch wondered what type of changes were potential C# breakers, as there were probably things that we thought of as `internal’ that the C# team could be depending on. Leo also thought that the liaison person should probably be Dan.

http://groups.google.com/groups

Scratchpad Confusion

At the end of last week, Allen Short pointed out some discrepancies between the implementation of scratchpads and the description of them in PDD6. John Sillito reckoned that PDD6 was waiting on a rewrite from Dan, especially where Scratchpad PMCs were concerned as there were a couple of different patches waiting on Dan’s say so. Dan also offered some clarification, but hasn’t ruled on the Scratchpad PMCs yet.

http://groups.google.com/groups

Help! Bugs! Crawling All Over Me! OR the Road to 0.0.9

Steve Fink wants the GC bugs ironed out before he goes adding much in the way of new features, and he wants to start putting together a 0.0.9 with working GC, too. To that end, he deliberately broke all the tests by turning GC_DEBUG on for tests. There’s a certain amount of cleverness involved in how he did this; read his post if you’re interested. Peter Gibbs found what he thought was a fix for a couple of the failures and pointed to the possibility of a fundamental problem in MultiArray as the culprit for the remaining failure. Steve applied this patch with much rejoicing, and then came up with a trial patch that seemed to fix the multiarray-triggered failure. This patch had not been finalized by the end of the week.

Steve also kicked off discussion of the forthcoming 0.0.9 release, when he posted his list of prerequisites and sparked off a decent amount of discussion of various points. Steve’s overarching goal for this release appears to be ‘bug reduction and general consolidation.’

http://groups.google.com/groups

http://groups.google.com/groups

Keyed ops, the Return.

I think it’s safe to say that some people aren’t entirely happy with keyed ops as they stand now in Parrot. The week before, Leopold Toetsch had written a proposal for keyed ops. This week, he supplied a proof of concept patch. Jürgen Bömmels liked it but Dan took a little more convincing. I’m not sure he is entirely convinced yet, but he’s willing to live with it.

http://groups.google.com/groups

64-bit ints and Noncapable Hardware

Dan announced that he was about to bite the bullet and declare that INTVALS have to be 64-bit integers and wanted to know of any (plausible) platforms that have neither native nor emulated 64-bit integers. Martin D Kealey pointed at what sounds like a scary proposal from C99 involving declarations and clever compilers and wondered whether it might be a way forward for Parrot. Rhys wondered how well the idea would play with something as dynamic as Parrot and the languages expected to run on it, but Martin didn’t seem to think it would be much of a problem.

http://groups.google.com/groups

http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/

Configuring and DOD

Erik Lechak couldn’t get the latest parrot to build on WinXP. Josh Wilmes diagnosed a problem with the way the configuration tools probed for stack direction, and patched things so that stack direction detection was done at runtime once more. Jason Gloudon, who had moved the detection phase out into configuration time wasn’t sure that this was a good idea ‘cos it would lead to a performance hit in the stack walking code. Nicholas Clark, with his clever head on, came up with three different ways of doing things at runtime without a performance hit, and Dan blessed the third choice.

http://groups.google.com/groups

Execute in place?

Rhys Weatherley has been taking a look at our packfile format code, and thinks it could be improved by designing the format in such a way that it can be mmapped into a block of memory and executed immediately, as opposed to the way parrot currently does it, which involves moving stuff around in memory before starting execution. Dan said that that’s how things were originally done, and if it wasn’t still possible, then that was a bug.

http://groups.google.com/groups

Toward the end of the week, Dan announced that he was about to straighten out the copyright and licensing situation. As a first step, he would be marking everything in the core as Copyright YAS. It looks like Parrot itself will be moving to an MIT-style license `Over no objections whatsoever from the FSF.’

If you’ve made any contributions to Parrot’s code base, then you’ve probably already been contacted, but if you haven’t and have an objection, then you should contact Dan.

Most of the discussion of this happened during the next week, and I’ll return to it in my next summary, but response was generally favorable after some clarifications from Dan.

http://groups.google.com/groups

Allow a NULL Interpreter in sprintf Like Functions

Jürgen Bömmels sent in a patch that allowed the use of a NULL interpreter in sprintf like functions. Leo Toetsch applied it, but wondered whether it was actually the right thing. Dan seemed to think that, in the long run, it probably wasn’t and that, if something went horribly wrong before an interpreter got properly set up, then it was probably best to use the standard library functions.

http://groups.google.com/groups

http://groups.google.com/groups

Draft Sketch of Bytecode Generation

Dan offered a `very sketchy’ draft of his thoughts on what we need from our bytecode generation system. Initial reaction seemed positive.

http://groups.google.com/groups

Meanwhile, in perl6-language

Won’t someone please think of the summarizer?

There were about 150 messages in perl6-language this week. The *vast* majority of them discussing the Perl 6 built in operator list. It all started weeks ago, when Damian wanted |, & and the_as_yet_unnamed_xor_operator as superposition generating operators. But that meant we’d need somewhere else to put the bitwise operators. And people like ^ as xor, but that’s not likely because of hyper ops. And nobody likes _ as a concatenation operator. It’s all become very complicated.

However, in answer to a summarizer’s prayer, Michael Lazzaro has taken to posting a scorecard of his understanding of what the current list of built in ops is. (A list of diffs between these would be interesting to see…). Things that appear to be set in stone:

  • ~ is the new _, which was the new . and which nobody liked.
  • ~~ is the new =~. (Otherwise =~ -> match, and ~= -> string append could get somewhat confused…) !~ stays the same.
  • | and & make any and all type superpositions, respectively. Damian has an article on why superpositions are such a good idea forthcoming for perl.com. The phrase `in constant time’ will probably not be used.
  • Nobody has any idea what xor will end up as.
  • Some people are worried that changing things too radically from old Perl/Algol type syntax will make for a harder learning curve. Other people tend to think that not many programmers use bitwise ops in Perl at the moment, so the change shouldn’t matter too much.
  • It’s a real shame that so many Unicode characters are so hard to type.

Here’s a list of Michael’s various opcode lists. They’re usually good entry points to the discussion. (Which is kind of fascinating…)

http://groups.google.com/groups

http://groups.google.com/groups

http://groups.google.com/groups

Character Properties

Luke Palmer wondered whether we were planning on having properties on individual characters on a string; something he felt was an essential feature. There was a certain amount of debate about the use of the word `essential’ in this context, leading Luke to give some more information about what he was driving at before he was eventually convinced that what he wanted was an ideal candidate for a module.

http://groups.google.com/groups

http://groups.google.com/groups

Perl6 Built-in Types

Michael Lazzaro asked for a list of Perl6 built-in types and offered his own first cut at such a list. Larry offered some corrections, but reckoned that the list Michael had just posted was the nearest thing we had to a definitive list.

http://groups.google.com/groups

Power of Lisp Macros

Adriano Nagelschmidt has been reading Paul Graham’s articles about Lisp and its advantages, especially the macro system, and wanted to know whether the macros were really as useful as Mr. Graham claimed, and whether it was worth adding something like them to Perl. General consensus appears to be ``Yes, they’re really good, and yes, Perl 6 will probably have something similar.” Larry had an interesting post on the subject (no surprise there then…)

http://groups.google.com/groups

http://www.paulgraham.com

http://groups.google.com/groups

In Brief

There was a minor kerfuffle early in the week when the Parrot CVS repository ended up with the wrong permissions. Oops.

Leopold Toetsch has implemented the splice vtable method based on the semantics in PDD2. This sparked a short discussion about copying vs. cloning.

It looks like native types are going to get type numbers just like PMCs, but native types will be negative.

Rhys Weatherley added a bunch of infix operators to IMCC’s syntax.

Jürgen Bömmels added `fingerprinting’ to .PBC files. The idea being that Parrot can fail at load time if it tries to load a .PBC file that was generated with a different version of core.ops. The previous behavior involved weird, hard-to-track-down runtime errors.

Some spam got past the perl6-internals filters. We were shocked.

Michael Lazzaro announced an updated Perl6 OO Cookbook at http://cog.cognitivity.com/perl6/.

Who’s Who in Perl 6?

Apparently, nobody is this week. I appear to have run out of answer sets for the questionnaire. If you’ve been mentioned in this, or any previous summary and you’ve not already answered, then please drop me a line and I’ll send you the questions.

Acknowledgement, Apologies and All That Good Stuff

This summary was once again brought to you from my office on board the 0625 from Newark to London and from my comfy chair at home. Distractions were provided by Xmame, Perls of the North, broken AC Adaptors and my own natural `Procrastinate now!’ instincts.

Proofreading services were provided by me. Having left it as late as I did, I just want to get this summary out of the door before next week’s is due. So any speeling mistooks are orl myne.

And, the old refrain: If you enjoyed this summary, then please consider one or both of the following options:

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

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