This week on Perl 6, week ending 2003-03-30

Mar 30, 2003 by Piers Cawley

Welcome once again to the gallimaufry that is a Perl 6 summary. Unfettered this week by the presence of feline distraction we plunge straight into the crystal clear waters of perl6-internals.

Iterator proof of concept

People must really like Leo Tötsch’s Iterator proposal and patch. There was only one comment about it this week (from Leo, so I’m not sure if it counts) asking for thoughts about a possible Ref or Reference class. Anyone?

http://groups.google.com/groups

Bonsai

Zach Lipton announced that he has Bonsai up and running on the Parrot CVS repository. This gives us a shiny new way of looking at the history of the distribution. Thanks Zach.

http://tinderbox.perl.org/bonsai

BASIC, IMCC and Windows

Clinton A Pierce had problems trying to get IMCC building correctly under Win32 in order to generate a binary distribution for the win32 platform. He finally brought up a working IMCC on Friday and asked for comments about what a binary distribution should look like.

http://groups.google.com/groups

http://groups.google.com/groups

getopt.macro

Inspired by the argument processing in Leon Brocard’s uniq(1) implementation, Jonathan Scott Duff presented a getopt macro for Parrot programmers. Benjamin Goldberg had a few suggestions about how to make things a little more flexible.

http://groups.google.com/groups

Patch to examples/assembly/cat.pasm

Paul Duncan offered a patch to examples/assembly/cat.pasm which would cause it to terminate when it received a ctrl-D.

http://groups.google.com/groups

IMCC and scientific notation

Having got IMCC working in a win32 environment, Clinton A Pierce discovered that IMCC didn’t understand scientific notation, but the parrot assembler does. Leo Tötsch pointed out that it sort of does, but instead of 1e20 you have to write 1.e20. Joseph Ryan wondered if handling scientific notation wasn’t really a job for individual compilers, but Clint and Mark Biggar explained why this wasn’t a good idea. As Mark said, in a world with BigFloats you don’t want to have to expand 1e2048 into a 2049 character string if you can possibly help it.

http://groups.google.com/groups

RT spam

Someone claiming to be Marla Hurley crawled out from under a stone and took it upon themselves to offer credit to the perl6 RT installation. Thanks. We needed that.

Meanwhile, over in perl6-language

The language list was again busier than the internals list this week, but volume has fallen on both lists. (If you don’t count an off topic thread on the internals list, which I haven’t, there were only 22 messages there this week. And very few patches from Leopold Tötsch, I hope he’s all right.)

is static?

Discussion of static/state variables continued. Arcadi Shehter wondered if it made sense to attach but properties to closures. I confess I didn’t really understand what he was driving at. Austin Hastings and Larry saw something in it, and the question shifted to ways of doing state variable initialization, which in turn led to possible changes in the various control of flow keywords. As Larry pointed out, if you have a static variable:

   state $variable

Then, assuming that you need ‘undef’ to be a possible value for your variable, you need some way of doing once and only one initialization of that variable.

   state $variable;
   ONCE_AND_ONLY_ONCE { $variable = $initial_value };

The problem is that INIT and CHECK blocks happen too early; in the code above, $initial_value may well not be set, if your state variable is set up inside a closure this becomes even more likely. Larry reckons that the most useful initialization semantics appear to be ‘just in time’. In other words you want initialization to happen on the first actual call to a closure. But FIRST {...} is already taken, so Larry is considering renaming FIRST and LAST to ENTER and LEAVE, freeing up FIRST to mean “my very first time”. Freudian analysis was discouraged.

http://groups.google.com/groups

Argument initializations

Michael Lazzaro summarized the various different and proposed assignment operators available in Perl 6, including a proposed ::= for ‘only assign to uninitialized variables’. Michael wondered how these could be used in method signatures and proposed some changes to the signature system as set out in Apocalypse 6. People were dubious about this, with Damian saying “I don’t think that allowing 20 different types of assignment in the parameter list of a subroutine actually helps at all.” I’m not sure Michael is convinced yet.

http://groups.google.com/groups

P6ML?

Michael Lazzaro asked if anyone was actually working on P6ML (a project name that popped up last week in the ‘XML is too hard for Programmers’ thread) and if there was any idea of what such a project would entail. Robin Berjon was unsure of the wisdom of such a project, arguing that supporting a tool that wasn’t strict about the XML it parsed would be a retrograde step and giving reasons as to why. However, he did think that creating a toolset for ‘recuperating data from a quasi-XML [document] (aka tag soup)’ would be interesting and useful, and he proposed a couple of approaches.

It’s apparent, from reading this thread that people who don’t like the current generations of XML tools really don’t like them at all: adjectives such as ‘craptacular’ and phrases like ‘festering pile of steaming camel turds’ were bandied about. Then there’s the ‘Perl has lots of ways of doing XML, which is great because you can pick the one that suits you’ camp, and the ‘Perl has lots of ways of doing XML, which is terrible because you have to pick the one that suits you and that takes time’ camp.

Leon Brocard pointed out that, whilst Perl 6 might have nicer syntax and a faster parsing engine, there was nothing to stop people working out, and implementing, the required semantics in Perl 5 right now. There was a fair amount of muttering that, however desirable or otherwise P6ML may be, there wasn’t really much need to be discussing it on a language design list (as if that could stop anything).

Dan Sugalski caught everyone out by raving about the idea: “the thought of altering Perl 6’s grammar to make it a functional language is sheer genius […] I say we start right away!“. The only catch is that Dan was talking about ML, a programming language and he bent the needle on Austin Hasting’s Sarcasmeter. But he promised to fix any such devices at OSCON if their owners would bring them to him there. So that’s all right then.

http://groups.google.com/groups

Summary writer goes all red and glowy.

Matthijs van Duin pointed out that Piers had misspelled him as ‘Mattijs’ 4 times in last week’s summary.

I am really sorry and I shall endeavour never to do it again.

Support for attributed DAGs

In a thread deceptively named ‘Perl and *ML’, Dan opined that XML would be so much easier to support if Perl had good support for attributed DAGs (That’s Directed Acyclic Graphs, or ‘trees’), and noted that having such support would be good for things like Abstract Syntax Trees too. Robin Berjon wasn’t so sure, pointing out that, whilst fast and efficient graph support would be really useful, acyclic graphs weren’t that useful for XML as useful XML representations usually had back links to parent and sibling nodes (and that’s before you take linking into account). I have the feeling that further discussion of graph support probably belongs on the internals list for the time being, but I could well be wrong.

http://groups.google.com/groups

Acknowledgements, Announcements and Apologies

I’ve already apologized to Matthijs “Mattijs” van Duin for misspelling his name, but I’ll do it again. I’m really, really sorry.

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

This week’s summary was again sponsored by Darren Duncan. Thanks Darren. If you’d like to become a summary sponsor, drop me a line at p6summarizer@bofh.org.uk.

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