| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
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 perk6-internals.
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?
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.
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.
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.
Paul Duncan offered a patch to examples/assembly/cat.pasm which would cause it to terminate when it received a ctrl-D.
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.
=head 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.
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.)
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.
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.
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.
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.
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.
groups.google.com[63.120.19.221]
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 [email protected]'>p[email protected].