=head1 This week on Perl 6 (17-23 June 2002) by Piers Cawley, 020020624
=head2 Notes It's been a while since the last Perl 6 digest and summarizing everything that's happened since then would take, ooh, a while. So I've punted on that, and just pretended that the last one was published this time last week. (Well sort of, sometimes I'll refer back to earlier posts in threads that continued this week.) =head2 More 6PAN musings: local namespaces John Siracusa L<asked|http:[EMAIL PROTECTED]/msg10140.html> a bunch of questions about the naming of local modules in Perl6, pointing us at java's style of uk.org.bofh.html.template, which makes sure that one organizations templating system won't clash with that of another. Various schema were proposed, then Larry L<popped up|http:[EMAIL PROTECTED]/msg10162.html> and told us that there'd be more than one way to do it, along with a way of aliasing names to avoid RSI. Aaron Sherman warned us away from reinventing X.whatever it was addressing. After some discussion about the merits of long, guaranteed unique module names versus a standardized module naming schema, Webb Sprague L<suggested|http:[EMAIL PROTECTED]/msg10152.html> a CPAN "Curation Project" be formed. The idea being that there'd be the more or less unstructured seething mass of CPAN, and then there'd be a group of "highly managed, by real people" modules that were promoted from that pool to an "Extended Perl Library". Which led to a discussion about where you'd find the "real people" and a certain amount of silliness about acronyms. Favourite quote of the thread: L<The problem is that the directive to "be smart" quickly expands to "be omniscient."|http:[EMAIL PROTECTED]/msg10149.html> =head2 Regexes and untainting Miko L<proposed|http:[EMAIL PROTECTED]/msg10166.html> that, by default regexes shouldn't untaint, and proposed a 'safer' mechanism for managing taintedness. Jonathan Paton L<pointed out|http:[EMAIL PROTECTED]/msg10167.html> that some of this is already possible in Perl 5. He also came up with the idea of marking different rules as untaint safe or unsafe when they are defined. =head2 what's new In an effort to understand the state of Perl 6, raptor L<posted|http:[EMAIL PROTECTED]/msg10155.html> a really good summary of some of the changes from Perl 5 to Perl 6 asking if he'd got the right end of the stick. Damian L<clarified|http:[EMAIL PROTECTED]/msg10168.html> a few things and generally confirmed that the stick was correctly oriented. =head2 Meanwhile... over in perl6-internals =head2 latest Parrot Luke Palmer L<asked|http:[EMAIL PROTECTED]/msg10573.html> why the latest ChangeLog entry was from March 19, and was the Parrot he'd just got from CVS really the latest version. Dan explained that it was, but that the ChangeLog wasn't being kept up to date 'for some reason', which triggered a small amount of kvetching about CVS. Robert Spier (sensible chap) L<suggested|http:[EMAIL PROTECTED]/msg10577.html> that all non trivial patches should contain a 'human readable' changelog entry along with the patch and at least one test. Ask agreed. And so do I. =head2 Perl6 grammar Melvin Smith posted a L<suggested roadmap|http:[EMAIL PROTECTED]/msg10561.html> towards being able to parse Perl 6. Jerome Vuillon pointed us at the beginnings of a L<parser|http://www.pps.jussieu.fr/~vouillon/parrot/parser.y> that he was putting together using yacc, and Sean O'Rourke L<posted|http:[EMAIL PROTECTED]/msg10598.html> his Parse::RecDescent based grammar sketch. And there was much rejoicing. =head2 Irrational fear of macros Melvin Smith L<pointed out|http:[EMAIL PROTECTED]/msg10567.html> a joke in the perl 5 source about the sheer number of macros in the perl 5 source. Which provoked a variety of serious responses. Dave Goerhrig L<reckoned|http:[EMAIL PROTECTED]/msg10581.html> that macros weren't inherently bad, but having hordes of them wasn't necessarily good, and his sig quote: qw/ who is praying for parrot to support XS code, cause he doesn't want to rewrite SDL_perl's 11,000 lines /; provoked a L<serious response|http:[EMAIL PROTECTED]/msg10662.html> from Tim Bunce proposing a 'wrapper that manages a simple perl5-like run-time environment'. Tim's .sig (Tim [who doesn't want to rewrite the DBI's ~4000 lines or tell the many DBD authors that they have to rewrite their drivers].) gave us a clue as to his motivation in wanting this too... The 'Irrational fear of macros' thread proper was L<kicked off|http:[EMAIL PROTECTED]/msg10582.html> by that man Dave Goehrig as he launched a defence of macros, pointing out that "Perl 5's problem with macros ... is that too many of them remain largely undocumented, under-utilized, or over-exposed." He argued for "a dictionary, a work to explain the usage of each element of the API. Parrot needs a rosetta stone, through which future implementors will decipher and re-interpret the decisions made years in the past." Melvin L<disagreed|http:[EMAIL PROTECTED]/msg10584.html>, pointing out that macros don't play well with debuggers, and argued that it's far better to write code that is self explanatory than to write code that requires to to constantly refer back to a dictionary to understand it. Larry, as is his wont, cut through all this with yet another of his L<incisive posts|http:[EMAIL PROTECTED]/msg10585.html> explaining why perl 5's macro system looks like it does. "After all these years, I still know exactly what a dPOPTOPnnrl does, and it's not because I remember the name." Meanwhile, Mike Schwern L<showed off|http:[EMAIL PROTECTED]/msg10600.html> his splendidly cunning trick for defining something as both a subroutine I<and> a macro. Well, I was impressed anyway. =head2 Tasks for the interested Dan posted a L<handy list|http:[EMAIL PROTECTED]/msg10589.html> of other virtual machines, and asked interested people to try and make lists of the opcodes used by each of them, and what those opcodes do. And then to write opcode libraries for them. The usual suspects were all there (Perl5, Python, Ruby, JVM, .NET) along with the dark horse that is the Infocom Z-machine. Does Dan have a thing for classic text adventures? Rafael Garcia-Suarez suggested that if anyone managed to do the job for Perl 5, p5p would definitely be interested in seeing the results.) Simon Wistow L<proposed|http:[EMAIL PROTECTED]/msg10604.html> PHP/Zend as another candidate for this approach. Dan pointed out that, daft as it seemed, the z-machine would be a really good system to tackle since, as well as needing a custom opcode library, the z-machine would also need the ability to load packed files, and that making $ parrot -m:zmachine lurking_horror.dat do the right thing "involves most of the infrastructure we'd need to get working to get .NET and JVM code loaded in." It looks like Josh Wilmes has stepped up to this particular plate. On the Java front, Leon Brocard pointed out his <earlier post|http:[EMAIL PROTECTED]/msg09812.html> where he announced his proof of concept for loadable java bytecodes. Dan encouraged him to keep up the good work. =head2 matrix design Josef Höök posted a L<suggested matrix representation|http:[EMAIL PROTECTED]/msg10599.html> which opened something of a can of worms. People L<questioned the need|http:[EMAIL PROTECTED]/msg10606.html> for first class matrices (though Dan disagreed with them, pointing at the PDL project.) Josef's basic design also got a L<vote|http:[EMAIL PROTECTED]/msg10609.html> of "Yech! :)" from Dan, who reckoned that it was better to start with a simple data structure, get that working and then worry about making it sparse. For some reason this led off into a discussion of hyper operators. In a message that doesn't appear to have been archived, Paul Kienzle pointed us at L<BLAS|http://www.netlib.org/blas/faq.html> and reckoned that a compatible representation would win big because of tools like LAPACK "which provides fast stable implementations of a lot of very useful linear algebra." Ashley Winters L<suggested|http:[EMAIL PROTECTED]/msg10616.html> that we take advantage of the lazy evaluation we're expecting from Perl 6 and set things up to do deferred calculation. He also suggested that we don't "need to worry about optimizing complex operations too much, the PDL people have come up with miracles before... they just need the tools." Which sounds good to me... =head2 Stack and GC Melvin Smith L<asked|http:[EMAIL PROTECTED]/msg10623.html> a few questions and made a few proposals about the stack and garbage collection with particular reference to continuations, coroutines and other entertaining flow of control constructs. And then released a L<patch| http:[EMAIL PROTECTED]/msg10624.html> containing his first cut at continuations and exceptions. =head2 Vtables David Lloyd has updated the L<Vtable PDD|http://dev.perl.org/perl6/pdd/pdd02_vtables.html>. =head2 Glossary The parrot glossary is now available at L<http://dev.perl.org/perl6/pdd/pdd02_vtables.html> =head2 More tests Robert Spier L<pointed out|http:[EMAIL PROTECTED]/msg10633.html> that, according to L<http://www.hitchhiker.org/parrot_coverage/> the tests only cover 33% of the parrot codebase. We need more tests. =head2 INTVAL keys David Lloyd L<announced|http:[EMAIL PROTECTED]/msg10639.html> the arrival of a new C<_keyed_int> form for every C<_keyed> vtable method, and asked for contributions and tests that exercise them. =head2 New stack tests Simon Glover L<offered|http:[EMAIL PROTECTED]/msg10643.html> a torture test of the N stack. =head2 Another new language Jeff L<offers|http:[EMAIL PROTECTED]/msg10646.html> a (currently limited) implementation of FORTH. =head2 .include directive for new assembler Brian Wheeler has L<implemented|http:[EMAIL PROTECTED]/msg10647.html> a .include directive for the assembler which was generally liked, eventually getting committed. =head2 Steve Fink goes on hiatus Steve Fink announced that, for at least the next couple of months, he was going to be too busy to do any work on parrot, and that anyone ho wanted to was to feel free to do whatever they wanted with has.c and the regex compiler he'd been working on. Given the speed of Parrot development it'll be interesting to see his reaction when he comes back... -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
