The Perl 6 Summary for the week ending 20030330
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.
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://xrl.us/fao>
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://xrl.us/fap>
<http://xrl.us/faq>
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://xrl.us/far>
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://xrl.us/fas>
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://xrl.us/fat>
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://xrl.us/fau>
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://xrl.us/fav>
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://xrl.us/faw>
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://xrl.us/fax>
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:
*
Send money to the Perl Foundation at
<http://donate.perl-foundation.org/> and help support the ongoing
development of Perl.
* Get involved in the Perl 6 process. The mailing lists are open to
all. <http://dev.perl.org/perl6/> and <http://www.parrotcode.org/>
are good starting points with links to the appropriate mailing
lists.
* Send feedback, flames, money, photographic and writing commissions,
or an ArtixScan 2500f to [EMAIL PROTECTED]
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]
--
Piers
