Sign In/My Account | View Cart  
advertisement


Listen Print

This week on Perl 6, week ending 2003-03-23
by Piers Cawley | Pages: 1, 2

Meanwhile, over in perl6-language

perl6-language was again the busier list this week. The fallout from Apocalypse 6 continues both with clarifications of what was in that document and some suggestions inspired by it.

is static?

Towards the end of last week, Uri Guttman had asked about a possible 'is static' variable trait, and the discussion carried on into the this week. Arcadi Shehter suggested using has to introduce a static variable:

    sub foo () {
        has $s //= 0;
        $s ++;
    }

Larry described this as a very interesting idea, but was concerned that this might be akin to overloading the meaning of has in the same way that C overloaded the meaning of static. Damian also worried that using 'has' in this way would mean stretching 'the concept of objects a little too far'. He also thought that using //= to initialize such a variable felt wrong, and that maybe we needed a third assignment operator to go with 'assign unless true (||=)' and 'assign unless defined (//=)', which could be thought of as 'assign unless exists' and suggested ??= as a possible (though he didn't profess to actually like it). Damian also thought that such functionality should really be introduced with a trait and suggested a list of possible trait names. Uri was unconvinced by any of Damian's alternatives and proposed deciding the name with a duel on the beach at Boca Raton.

Larry decided that using a trait to denote a 'static' variable would be the wrong way to go because such a variable has a different kind of scope from a my variable and described the whatever declaration was eventually settled on as introducing a lexically scoped alias to a property of the current block. Larry later suggested state $s = 0 because 'a static var makes a subroutine stateful'. Uri wasn't sure, but Damian liked it.

Arcadi Shehter wondered about scoping of lexically scoped subs and if they could really be thought of as lexically scoped at all, whereupon he and Matthijs van Duin got a bit tangled up with the various kinds of scoping available, but there's been no definitive comment from Damian or Larry about the correct behaviour.

http://groups.google.com/groups

On the place of Scalar in any class hierarchy

During the discussion last week about strictness and type coercion on function calls, some confusion arose about whether Int isa Scalar, or Scalar isa Int|String|Float|.... David Whipp proved himself a hero by posting on this subject, pointing out that Scalar is the type of the variable, not of the value (I'd probably replace variable with 'container', but I'm picky like that) and explained how this solved some of the problems people had been having. There was no comment from Larry or Damian about this post, but I thought it was wonderful.

http://groups.google.com/groups

A6 questions

Dave Storrs posted a grab bag of questions about Apocalypse 6 and got a grab bag of answers.

http://groups.google.com/groups

Apoc 5 - some issues

Matthijs van Duin had a pile of questions and issues with Apocalypse 5. Some of the questions were Hard. Only Luke Palmer dared answer them. He and Matthijs batted things back and forth a few times, but it looks like Matthijs still had some issues with backtracking into and over closures.

http://groups.google.com/groups

``XML is Too Hard for Programmers''

Rich Morin pointed everyone at Tim Bray's article about XML being hard to deal with in most programming languages. Robin Berjon chipped in with a pointer to an xml-dev thread on the same subject. There was a certain amount of muttering about companies that use formats that seem to walk like XML but fail to quack like XML (the initials M & S were used, and I don't think they were referring to Marks and Spencer). Michael Lazzaro made an impassioned plea for insuring that Perl 6 allows easy, fast parsing of XML-like things out of the box. Austin Hastings suggested that Michael should take command of P6ML. Dan pointed to a basic Parrot XML parser in the Parrot examples directory that was at least four times faster than the equivalent Perl 5 code that it's a line for line translation of, and noted that the performance numbers were old.

http://groups.google.com/groups

http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog -- Tim Bray's article

http://lists.xml.org/archives/xml-dev/200303/msg00536.html -- xml-dev thread

Rules and hypotheticals: continuations versus callbacks

Remember what I said about Matthijs van Duin still having some issues with backtracking? Well, he kicked off a whole new thread just to discuss it and two possible methods for implementing the grammar system (labelled the 'backtracking continuation' and 'callback' methods). Matthijs would like to see the backtracking continuation method blessed as the right way. (He discusses all this here because the choice of implementation could well have language level implications). Luke Palmer was concerned that both of Matthijs's proposed implementations would be very slow and had a couple of other possible implementation approaches (the 'success continuation' and 'backtrack exception' methods). Matthijs reckoned that the success continuation approach was pretty much the same as his 'callback' method, and that the 'backtrack exception' method seemed to have problems with rules like <foo> <bar>. And then it all got very complicated as Dan and Matthijs went back and forth at the issue with occasional interjections from others where appropriate. Then someone mentioned threads...

Dan and Matthijs seem to have very different sets of assumptions which leads one to suspect that they're arguing past each other on occasion. I certainly found myself wishing there was somewhere convenient with an ample supply of chalkboards, chalk, index cards and Sharpies and other high bandwidth communication aids where they could go and come to some kind of understanding.

At one point Austin Hastings observed that 'when anyone says ``I don't see why anyone would ...'', Damian immediately posts an example of why. Unless it's Damian, in which case Simon, Larry, or Dan usually counterpost.' Hey, it made me smile.

I think Larry's only contribution to this thread bears repeating in its entirety:

I would like to express my sincere gratitude to all of you for working through these issues. I bent my brain on the Perl 5 regex engine, and that was just a ``simple'' recurse-on-success engine--and I'm not the only person it drove mad. I deeply appreciate that Perl 6's regex engine may drive you even madder. But such sacrifices are at the heart of why people love Perl. Thanks!

http://groups.google.com/groups

Questions to Help Program Perl6::Parameters

Brent Dax is working on a Perl6::Parameters source filter for Perl 5, a task he describes as 'damn hard'. He had a couple of questions about argument behaviour. Damian had the answers, and made noises about his forthcoming module, Perl6::Rules. Simon muttered something about Parse::FastDescent (but everyone passed over that) and pointed out Matthijs van Duin's work in progress.

Larry thanked Brent for taking on the task and 'suffering vicarious pain for the user' and mentioned that he was interested in feedback on spots where the design impacts performance unduly. Larry went on to discuss possible changes to the scoping of $_ to help with with the transition from Perl 5 to Perl 6. He and Damian proceeded to discuss other entertaining syntax possibilities to do with want, where and when. Nobody has yet proposed meaningful semantics for what, who and why, but I'm sure somebody will get 'round to it.

http://groups.google.com/groups

http://www.liacs.nl/~mavduin/P6P5_0.00_01.tar.gz -- Matthijs' work in progress

.req or .arity?

Austin Hastings asked that Routine's .req method be renamed .arity. Damian rather liked the idea. Larry wasn't so sure because .arity is somewhat opaque to non-mathematicians, but he accepted that one could argue that anyone who doesn't know what arity means shouldn't be writing code that depends on it. Steffen Müller thought that either .req or .reqargs would be a better name for the method.

For those who don't know, 'arity' is the number of arguments a function or operator takes.

http://groups.google.com/groups

Acknowledgements, Announcements and Apologies

And another summary rolls towards its close. I'd like to echo Larry's thanks to everyone who's working on scary magic like the Perl 6 rules engine and Perl6::Prototypes. The way people like Brent, Matthijs, Leo and Luke have stepped up to the plate for this undeniably Hard Stuff is, frankly, inspirational. It's people like you who keeps me bullish about Perl 6.

Thanks too to everyone else involved in either list; Michael Lazzaro made the point that often the most productive way for perl6-language to proceed is for an initial suggestion to be thrown out onto the list, then everyone has a good long wibble about it going off in about 3000 different directions at once before someone (usually one of Damian, Larry or Allison but not necessarily) pulls it all together into something that makes sense and we move on to the next item. My gut tells me that without all the wibbling the end result wouldn't be quite so satisfying.

For instance, much as I hated trying to summarize the everlasting pipeline thread, the end results of that discussion are the rather lovely ==> and <== operators that appeared in the latest Apocalypse. (Of course, Larry or Damian will probably respond to this summary by telling me that actually, they'd been planning something like that all along. I just won't necessarily believe them)

If you 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.