This week on Perl 6 (9/1 - 9/8, 2002)
by Piers Cawley
|
Pages: 1, 2, 3
Implementation of Lists for languages/scheme
Jügen Bömmels offered a patch implementing Scheme pairs, using simple Arrays. Dan was impressed, and wondered how far we were from 'real' scheme. Jürgen thinks we're quite some way away; we still need symbols, strings, lexicals, functions, macros, continuations... Piers Cawley outlined an OO way forward using (initially) hashes, and proposed a 'SchemeObject' PMC, which would hide a lot of the common structural code needed for dispatching methods implemented in any of C/Parrot/Scheme.
Teasing notes
Dan announced that he was about to go dark for a while as a deadline of his had just got a lot closer. However, he dropped a list of hints about what was forthcoming. Bryan asked for some clarification of a few hints (but they're hints, they're supposed to be a bit vague), and Dan went and spoiled the mystery by giving him some.
http://archive.develooper.com/perl6-internals@perl.org/msg12475.html
Tinderbox turning green
Andy Dougherty noted that the recent work on portability and general lint gathering meant that we were well on the way to a green tinderbox (ie: automated builds are mostly working, yay!). Dan thought that gave him an ideal opportunity to break things again by adding exceptions to the mix. Andy then went a bit red, for assorted and faintly embarrassing reasons: the patch that was meant to turn things green had been applied and then inadvertently backed out. There's a moral here somewhere.
Actually there was a spate of inadvertent unpatching last week. People are embarrassed and hopefully putting procedures in place to avoid another spate.
Perl 6 miscellany
Steve Fink offered a portmanteau patch for the Perl 6 compiler, including such delights as a '-e' flag to perl6 so the one line script folks could play. (First person to do the RSA one-liner in Perl 6 gets much kudos from me). Sean wondered about a few of the other fixes, and between them he and Steve found and squashed a bug with here docs, and discussed ways of getting working Perl 6 patterns up and running.
Meanwhile, in perl6-language
Garrett Goebel reopened the 'auto deserialization' thread from last
week (which ended up with the concept of my Date $date .=
new('June 25, 2002') as the Damian approved idea). Garrett's
confusion seemed to hang on whether my Date $date and my
Date $date = Date->new() were equivalent. If they were, then a
class which implemented its own operator:= method could arrange
things so that the originally proposed my Date $date = 'June 25,
2002' would work.
Miko O'Sullivan proposed that, in the absence of a method name, .=
should automagically call a new_from_[class of object being
passed], noting that golfers would love it. The consensus seems to be
against this particular bit of DWIMmery.
A subthread of this mammoth thread concerned multimethod dispatch. David Wheeler wanted to know what it was, so Dan explained, and Damian pointed at a Perl Journal article on the subject. This subthread ended up spawning its own thread, where Miko wondered if multi dispatch/overloading implied anything about runtime/compiletime. Dan thought not, and said it was dependent on the language.
Quote of the thread: "I can still remember the precise moment I first fell in love with polymorphism." -- Damian, in the TPJ article referred to.
http://makeashorterlink.com/ -- multimethods?
http://makeashorterlink.com/ -- TPJ article
Class aliasing
The 'auto deserialization' thread also spawned a discussion of Class aliasing, but declined to change its subject line, making the life of a summarizer so much easier...
Last week, Damian had proposed doing class Date is
Really::Long::Package::Name::Ugh, ie. subclassing the long name
into a handy short name. Everyone else seemed to think he was
proposing aliasing a class name (which Damian later denied).
Uri Guttman certainly thought that Damian was talking about lexical
aliasing of classes (my mailer picks his post as this week's base for
this particular subthread). Trey Harris thought that Damian was
talking about subclassing, and proposed my class Date is
Really::Long::Package::Name::Ugh, which introduces a lexically scoped
subclass. Nicholas Clark wondered if class Date :=
Really::Long::Package::Name::Ugh would express aliasing of
classes. Damian thought it probably would, but noted that Larry hasn't
said a definite 'yes' to class name aliasing.
Brent Dax wondered if classes weren't in danger of becoming the "new filehandles" -- relatively limited entities with no sigils that confuse the syntax horribly.' and pointed out an ambiguous case.
David Wheeler apologised to everyone for confusing inheritance and aliasing in the first place, and the thread wound down to a close.
@array = %hash
Another thread from last week that rumbled on into this one.
The discussion of when hashes could have pairs as keys wouldn't go
away. Damian says that the %hash = (...) case is syntactic
sugar and that having a pair in an even slot of such a list would
probably be an error. I assume that this also applies in the case of
%hash = @array.
In a subthread, Piers Cawley told David Whipp that he hadn't actually been joking when he proposed implementing the entire Smalltalk Collection hierarchy and making it available in core Perl 6. Luke Palmer liked the idea too. Dan saw no reason why such a thing should be impossible either...
Atomicness and \n
Last week Damian reminded us of $roundor7 =
rx/<<roundascii>+[17]>/, and Brent Dax wondered how one could be
sure that <roundascii> is a character class. Luke wondered if
it mattered. The thread eventually led Aaron Sherman to make a few
proposals about user defined character classes in regular
expressions. Deborah Ariel Pickett wondered why we still used ? for
non-greedy quantifiers, citing teachability reasons for why we
shouldn't.
Hypothetical variables and scope
Aaron Sherman announced that he was working on a library of rules and
subroutines for dealing with UNIX system files, mostly as mental
exercise to help with his understanding of Perl's new pattern
features. He wondered, in particular, about the scoping of
hypothetical variables in the presence of lexicals of the same
name. For some reason this turned into a minor argument about whether
my $x; / (\S*) { let $x = .pos } \s* foo /, from Apocalypse 5,
was a typo for my $x; / (\S*) { let $x := .pos } /. I'm not
going to try to summarize the argument.
Argument aliasing for subs
Pete Behroozi wondered about syntax for 'allowing subroutines to have
many different names for the same argument', citing CGI.pm as an
example of such code in Perl 6. Damian thought that if it were
allowed, it would be done with properties sub hidden (..., int
$force is aka($override) ) {...}, (well, he did after he realised
that his first post on this issue was the result of posting after
travelling 14,000 miles and giving 93 hours of talks in the space of
18 days, and was somewhat flawed).
All this cunning use of is led Erik Steven Harrison (who should fix
his mailer so it does References or In-Reply-To properly) to wonder if
properties weren't being a little overused, and wondered if the is/but
distinction was still around. Damian thought not, and reiterated the
difference between is and but, and when you would use each of
them. Erik also wondered what was wrong with sub hidden ( int
$force := $override ) {...}. Damian pointed out that it didn't play
well with the defaulting operator, //=, in parameter
declarations.
Peter Behroozi got confused about the difference between $foo is
named('baz') and $foo is aka($baz). (named changes the
externally visible name of a parameter, aka adds another external
name for the parameter).
The thread then morphed into a discussion of runtime and compiletime properties. If you've not seen such a discussion before, the whole thread is worth reading.
