The Perl 6 Summary for the fortnight ending 20040621
Good evening. You find me typing away in a motel room on the edge of the
Lake District on the shortest night of the year. I suppose, by rites, I
should be spending the night by some stone circle drinking, dancing and
generally making merry, but as I'm a teetotal, unfit, atheistical nerd
with a mission to summarize I'll skip that and plough straight into the
activities of another arcane sect. Yes, it's perl6-internals again...
Towards an accurate README
Andy Dougherty sent in a patch adjusting the Parrot README so that it
accurately reflected the toolset needed to build parrot. For some
reason, as well as the requirement for a C++ compiler if you want to
build the ICU library, we've moved to needing Perl 5.6.0 rather than
5.005. Nicholas Clark suggested that, rather than bumping the Perl
version requirement, we bundle appropriate versions of modules Parrot
required, but chromatic thought it better to check the for the correct
versions of said modules at Configure time and bail out if they weren't
there.
There was further discussion about whether going to Perl 5.6.0 as a
requirement was the right thing to do -- the issue is that some OSes
(FreeBSD and Solaris 8 were cited) still only ship with 5.005 family
Perls. My feeling (which I didn't mention in the thread, more fool me)
is that, as eventually the goal is to eliminate the need for Perl at all
in the build process, then require 5.6.0 rather than 5.005 isn't exactly
the end of the world.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
OS X Builds again
Someone finally summoned up the tuits to fix the OS X build. Step
forward Nicholas Clark and accept your plaudits.
http://groups.google.com/[EMAIL PROTECTED]
Basics of the PMC class set
Dan announced that he was about to make some changes to the repository,
including establishing a basic set of PMC classes. Matt Fowles wondered
about Array PMCs, which seemed to be missing from Dan's list. Dan agreed
that they should be rationalized as well.
Bernhard Schmalhofer suggested adding a complex number class to Dan's
basic menagerie, but Dan was unconvinced.
http://groups.google.com/[EMAIL PROTECTED]
Correct use of #define
Nicholas Clark was moved to growl by a section of
include/parrot/string.h that used a #define to define a type. Actually,
he was moved to 'swearing and cursing and time wasted grepping to find
out what a STRING is'. Dan agreed that this was bad and decreed:
'Typedefs for types, #defines for constants and bizarre (*temporary!*)
debugging things.'
http://groups.google.com/[EMAIL PROTECTED]
The next release
During a lull while Leo TÃtsch was away at a conference, Dan mused on
the next release of parrot. His goal for that is a rejig of classes/,
aiming to make sure that all the PMCs we want are in and working, and
that the ones we don't care about are neatly deprecated.
Warnock applies.
http://groups.google.com/[EMAIL PROTECTED]
A small task for the interested
Stretching the definition of 'small' somewhat, Dan asked for volunteers
to implement the missing PMCs detailed in PDD 17. He reckoned it should
be 'fairly straightforward'. A new entrant in these summaries, Ion
Alexandru Morega took a crack at the String PMC and posted a patch to
the list which was promptly ignored. Which seems a little unfair really.
http://groups.google.com/[EMAIL PROTECTED]
Bignums!
Dan asked for a volunteer to get Bignums working. Alin Iacob stepped up
to the plate. Leo suggested that, rather than starting from
types/bignum.c, it might be better to use an existing, maintained, maths
(Look, I'll spell 'summarise' with a 'z' -- the OED does -- but it will
be a cold, cold day in hell when I start abbreviating 'mathematics' as
'math'. Ahem.) package. Dan worried about license compatibility; the
proposed GMP package is licensed under the LGPL which may (or may not)
be compatible with Parrots Artistic/GPL dual licence. After a closer
reading he reckoned that GMP's license is definitely incompatible with
Parrot.
http://groups.google.com/[EMAIL PROTECTED]
Adding Fixed*Array classes
Matt Fowles posted a patch implementing Fixed Array classes. Dan applied
it. Leo wondered about the patch's use of malloc(3) instead of Parrot's
memory management. Dan wasn't worried in the case of fixed size arrays.
http://groups.google.com/[EMAIL PROTECTED]
Resizeable*Array classes
Fresh from his Fixed Array triumph, Matt Fowles posted a patch
implementing naÃve Resizeable Arrays. Leo thought it a little too naÃve,
and worried about duplication of existing functionality. Dan wasn't
worried about the naÃvetÃ, or the duplication of functionality. He
pointed out that it was more important to get *something* which could be
improved and that the duplication was okay given that the idea was to
get a standard framework in place and then eliminate the duplication. (I
admit that I'm a little surprised to hear Dan, who's normally a strong
advocate of up front design, preaching the refactorers creed...)
http://groups.google.com/[EMAIL PROTECTED]
Making PMCs
Nicholas Clark wondered how to go about making a PMC, pointing out that
the documentation is rather sparse. He had a bunch of questions for the
Men Who Know. Matt Fowles and Dan Sugalski came up with answers. Leo
wrote a document and checked it in as docs/pmc.pod. If you're interested
in implementing a PMC, you'd do well to read it.
http://groups.google.com/[EMAIL PROTECTED]
Slices and iterators
Continuing his campaign to spec out more and more of Parrot, Dan set to
work on defining and documenting Parrot's handling of slices and
iterators. It appears that array slicing syntax is one of those topics
where you can't please everyone; Dan's post generated a good deal of
discussion.
Dan added more in a later post and, in later post still, threw up his
hands and asked for a volunteer to define the iterator protocol.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
Iterator semantics
Having a syntax is all very well, but you need to define what it *means*
too. So Dan did.
http://groups.google.com/[EMAIL PROTECTED]
Some rationale for Parrot's mixed encoding scheme
Argh! Unicode! Run away!
Dan posted the rationale for his design for Parrot's strings, in
particular the decision to defer conversion of strings to Unicode.
Amazingly, there was no argument.
http://groups.google.com/[EMAIL PROTECTED]
Strings. Finally.
Dan posted "the official, 1.0, final version" of the Parrot Strings
document. Modulo a caveat about the use of 'grapheme' it looks like this
one might stick.
http://groups.google.com/[EMAIL PROTECTED]
Strings internals
Having got a Strings spec that people seemed to agree on, Dan went on to
discuss how parrot's strings should work internally. He and Mark A
Biggar ironed out a few wrinkles.
http://groups.google.com/[EMAIL PROTECTED]
Fixing pbc2c.pl
Dan asked for volunteers to get build_tools/pbc2c.pl working and/or
write a test suite for it.
http://groups.google.com/[EMAIL PROTECTED]
PIO_unix_pipe
Leo's extended Parrot's "open" opcode to allow for opening a unix pipe
rather than simply a file. There were issues with passing arguments to
the the program being piped to/from, but Dan came up with a suggested
"backtick" opcode whose semantics were liked, but whose necessity and
name were called into question. Leo pointed out that the major credit
for the functionality belongs to Melvin Smith; Leo merely implemented a
means to get at the functionality from parrot code.
http://groups.google.com/[EMAIL PROTECTED]
Teapots!
Nick Glencross wants us all to look at his shiny SDL teapots; the poor
man's wife is apparently underwhelmed, so let's all make with the "Wooo!
Well done that man!".
Simple trinary ops
Dan toyed with adding a couple of non-flowcontrol min/max ops along the
lines of
min $P1, $P2, $P2 # Sets $P1 to the lesser of $P2 and $P3
he noted that such ops would make some of the code he was generating
much simpler, but wasn't sure if that particular itch needed to be
scratched with a new op. He was rapidly convinced that it wasn't a good
idea (I wouldn't be surprised to discover that he was convinced of this
about 10 seconds after he hit the 'send' button for the thread's root
message).
Steve Fink attempted to resurrect the idea by proposing a single
"choose" operator, which looks rather neat, but is probably still
unnecessary.
http://groups.google.com/[EMAIL PROTECTED]
Meanwhile, in perl6-language
Cawley's Corollary to Godwin's Law
Given enough time, any thread on perl6-language will end up arguing the
toss about Unicode operators.
Perl 6 will have Unicode operators. It will also have ASCII equivalents.
You're highly unlikely to convince Larry to change his mind on this.
IDs of subroutine wrappers should be objects
Ingo Blechschmidt made a convincing argument for making the subroutine
wrappers discussed in Apocalypse 6 into first class objects. (Well, I
was convinced.)
Later in the thread, Dan invoked "our Quantum Ninjas".
http://groups.google.com/[EMAIL PROTECTED]
Simple grammar example
Aldo Calpini asked for assistance in coming up with a simple, yet
impressive, example of Perl 6 grammars. I'm not sure anyone's come up
with a suitably satisfactory example yet, but Garrett Goebel pointed out
that Damian has released Perl6::Rules. And there was much rejoicing
(well, in this summarizer's head there was).
http://groups.google.com/[EMAIL PROTECTED]
http://search.cpan.org/~dconway/Perl6-Rules-0.03/Rules.pm
Messages are not guaranteed to arrive in the order sent
In a message dated 28th of January 2004, Damian Conway addressed the
issue of junctive lvalues.
http://groups.google.com/[EMAIL PROTECTED]
Apologies, Acknowledgements, Announcements
This summary would have been a great deal trickier to write it if
weren't for the efforts of Jeffrey Dik, Sebastian Riedel, Brent
Royal-Gorden and Robert Spier, all of whom helped me fill in my message
archive while my main server is away being fettled.
Apologies for the long URLs to those of you reading this in email; my
link shortening script is on the hard disk that's at the menders...
Computer menders and British Telecom willing, next week's summary will
actually happen. If it doesn't, I'll be along in a fortnight.
If you find these summaries useful or enjoyable, you can show your
appreciation by contributing to the Perl Foundataion to help support the
ongoing development of Perl. Money and time are both appreciated. Or you
could drop me a line at mailto:[EMAIL PROTECTED]; I'm always
happy to get feedback.
http://donate.perlfoundation.org/ -- The Perl Foundation
