This Week on Perl 6, Week Ending 2004-04-25
And we’re back on a weekly schedule again (unless the Mayday bank holiday knocks me for six next week). As I expected, the Apocalypse has brought out a rash of prophets and prognosticators in perl6-language, but perl6-internals is still ahead on number of messages per week.
Constant Strings
I confess I’m not sure I quite understand the constant strings patches that Leo Tötsch and Jeff Clites were discussing. I understand the bottom line though – they make parrot a lot quicker when comparing constant strings. Huzzah!
Then it turned into a discussion of Unicode (or at least, Parrot string handling which is almost, but not quite, the same thing).
Parrot m4 0.0.4
Bernhard Schmalhofer posted a patch to bring his parrot implementation of m4 up to what he’s calling version 0.0.4
SDL Parrot status
Portland Parrot stalwart, chromatic, posted a link to a SDL Parrot site he’s set up with current status, downloadable snapshots and other good SDL Parrot related things.
http://wgz.org/chromatic/parrot/sdl/
Passing arrays of structs to NCI subs
That man chromatic again, this time he asked if there was a secret syntax for passing and retrieving arrays of things to and from NCI. Leo noted that, according to the docs, there is no secret syntax, it’s all documented but unimplemented.
PMC Constants
Last week, Leo asked for comments on his proposal for PMC constants. This week, Dan replied. Essentially he’s all for the idea, but wasn’t sure which implementation strategy was the best choice.
Assign and set
Leo announced some changes he’d made to the behaviour of the set and assign opcodes. Jens Rieks pointed out a case that he’d missed.
hyper op - proof of concept
Leo also implemented what he described as a rather hackish and incomplete new opcode called hyper. Dan liked it enough to suggest that we should go the whole hog and add a hyper vtable to PMCs, with hyper versions of all the standard vtable entries. He and Dan had a long discussion of this, with contributions from various luminaries including Larry. There was some debate as to whether we really needed overridable hyper ops, but Dan’s adamant that whatever happens they’ll be implemented in a vtable to allow for potential optimizations in some cases.
Separating allocation and initialization of objects
Last week, Leo posted the latest object benchmarks, and things were fast. But there was one test where Python was faster. Analysis of the results and the code seemed to point the finger at Parrot’s combined allocation and initialization. This week Dan confessed that he was leaning towards separating the two because that would allow for a standard PCC call into the initialization code. He pointed out that there were still a few issues, but that appears to be the way he’s thinking.
Another config task
Dan pointed out that the current config scheme relies rather heavily on flags set in the current perl install, which isn’t ideal. He suggested that people might like to look into making Parrot’s config step rather less Perl dependent and pointed at things like ‘metaconfig’.
Problems with the Perl 6 Compiler
Allison Randal noted that languages/perl6/ was failing all its tests. The issue arose because the Perl 6 test module inherits from Parrot::Test, and Parrot::Test’s behaviour got changed recently. She wondered why the changes had been made. After some discussion, Allison provided a patch to make things work with the new Test module.
IMCC temp optimizations…
Dan is possibly the only person using Parrot in a commercial (mission critical?) environment, using a compiler from a legacy language to Parrot. He’s currently experiencing problems with IMCC taking a long time to compile the PIR generated by his compiler. Apparently it’s because he’s using a lot of .locals and temps. He and Leo discussed it back and forth to try and find optimizations (both of IMCC and of Dan’s compiler) for the issue. (Dramatic) progress was made.
Korean character set information
Last week, Dan had wished he had access to anyone who knew anything about Korean. This week kj provided some information. The ensuing discussion of Unicode (again, maybe I’m going to have to extend my “I don’t cover the Unicode arguments” policy from perl6-language to the internals list too) led Jarkko Hietaniemi to propose that Parrot’s standard character set be cuneiform, with Phaistos disc symbols for variable names.
I think he was joking.
Containers and Values
The difference between containers and values cropped up again (for the first time in a while actually). It got kicked off by a discussion of what
my Joe $foo;
$foo = 12;
meant. It turns out that the my Joe $foo; part sets up a lexical variable (called $foo), which points to a container (in this case a Perl Scalar), which is constrained to contain either undef or a Joe objects. I believe it’s somewhat open as to whether $foo = 12 is legal and, if it isn’t, when the decision about the legality of the assignment would be made. Simon Cozens asked if the type declaration information went with the variable or the value and the answer was ‘neither’, it goes with the container that the variable points to. (Actually, that’s not quite true, variables also know what type the containers they point to should be constrained to holding, otherwise
my Dog $spot;
my $feline = RSPCA.get_stray(Cat);
$spot := $feline
wouldn’t throw an exception.) Dan noted that, right now, there is a ‘muddled split’ between values and containers in Parrot, which may well come back to bite us in the future.
Dan Does Unicode
After struggling manfully against the slings and arrows of outrageous text representations, Dan finally choked down the Unicode bolus and declared Unicode the “One True Character String Encoding Set Stuff Thingie”. Not long after this he posted the shiny new, all Unicode, all the time (ahem) strings design document.
Meanwhile, in perl6-language
Backticks
Last week’s thread rumbled on. Larry eventually made a ruling in favour of not using ` as an operator. He mentioned that the current backticks behaviour ‘probably needs to be completely rethought anyway’, and promised to cover it in a future Apocalypse. This didn’t stop Austin Hastings speculating, but a p6l without Austin speculating wouldn’t be the p6l we all know and love.
Spaces in method calls
Late last week, Abhijit A Mahabal had wondered about one of the examples of using method calls without brackets given in Apocalypse 12. In particular, he wondered why
$obj.method ($x + $y) + $z
was equivalent to
$obj.method(($x + $y) + $z)
rather than
$obj.method($x + $y) + $z
Larry was forthcoming with an explanation. He hoped it would be possible to unambiguously define what is ambiguous.
Returning from Rules
Luke Palmer noticed a common pattern in his grammar writing, where he did a great deal of assigning a value to $0. He proposed that <{ some_thing() }> be redefined to assign the result from the block to $0. Warnock applies.
Hyper mutating methods
Matthew Walton wondered if the new @things».method() hyperized method syntax also worked with mutating methods (@things».=method()). Answer: Yes.
Placeholder attachment
Trey Harris asked for an explanation of placeholder attachment. Being the gentleman he so obviously is, he even came up with a few thorny examples. Larry answered that the rule of placeholders is simple: Placeholders bind to the most closely surrounding closure. That is all. If you want anything more complicated then arrow blocks (-> $a, $b, $c { ... }) are what you should be using.
Lvalue methods
John Siracusa is after a neat way of overriding the assignment side of an is rw attribute. Various proposals were batted about, including using a different metaclass. Larry insisted that the $obj.foo($value) was the wrong way of doing what $obj.foo = $value does in A12 and repeated his reasoning for this. It looks like John was reasonably happy with the ‘different metaclass’ approach though.
Required Named Parameters Strike Back
Way back in the mists of time, John Siracusa had argued forcefully for required named parameters; required arguments to a function (or method) that must be supplied as pairs rather than positionally. Apocalypse 12 gave him some grist for this particular mill and he reopened the discussion with a long recap and extension of his argument.
Larry’s response is a masterpiece of conciseness:
Well, actually, we saved you last summer when we decided to make +
mean that the parameter must be named.
Discussion continued after this of course, but it was mostly concerned with making sure things worked as expected.
Conflicting Attributes in Roles
Jonathan Lang appeared to be shooting for the most cryptic question of the week award when he simply posted a chunk of code. Austin thought he understood it and essayed an answer. The resulting thread generated all sorts of interesting stuff. Which is odd, because on rereading Jonathan’s original post, I don’t think the code he wrote does what he thinks it does.
Syntax to call attributes.
Jonathan Lang also wondered what the syntax was for accessing a list attribute from a scalar object. Answer: The same was as you would access any other attribute of that object; by calling a sigil free method. (Which seems to imply that you either can’t have all of $.foo, @.foo and %.foo as attributes in the same class. Which in turn looks like plain common sense to me.)
Lower case magic methods?
Aldo Calpini worried that ‘implicit’ methods like meta, dispatch, etc seem to break the rule that implicit things get UPPER CASE (and some of the implicit methods have names that a programmer might want for something else – especially dispatch). Larry confessed that the names were chosen for the very strong reason that he “hadn’t thought about the issue yet”. He went on to discuss things that go into the Apocalypses as ‘placeholders’ – he knows that more design is needed, and there wants to be something there, but he hasn’t necessarily got the name right yet. He went on to make like a disabled octopus, offering six hands worth of reasons for choosing different rules for naming the various structural methods. No decision yet, but now we know that Larry’s thinking about it…
Subtypes that lack methods or roles
Jonathan Lang wanted to know how to declare a “subtype of a class which messes with the dispatching mechanism to exclude certain methods and/or roles from it”. I want to know whether the class he’s subtyping is the one that messes with the dispatching, of if the new class is the one that does the messing. I appear not to have been the only one confused by the question: Larry asked Jonathan for some sample code, which he did. Only to have the underlying design criticised by Dov Wasserman and chromatic, who argued that what Jonathan was asking how to do was exactly the thing that Roles were designed to avoid in the first place by pulling orthogonal behaviour out into roles and then composing them in classes.
Delegation using arrays
Austin Hastings voiced his misgivings about the A12 magic for delegating to an array attribute. After a short discussion with Larry, a light went on over Austin’s head.
Typed undef
Austin Hastings had a few things to say about typed undefs (the things that get made when you do my Dog $spot), he liked the idea of being able to call class methods on a typed undef for instance. The thread went on to discuss other tricks with flavoured undefs, like undefs that contain unthrown exceptions so that, when someone finally checks their return value, they can examine the exception to find out what it was that failed in the first place.
Universal Exports
Aaron Sherman had questions about the new export syntax discussed at the end of A12. In particular, he wondered how he’d go about reexporting a symbol that a module imports from somewhere else. Discussion and sketchy design occurred in the ensuing thread.
MethodMaker techniques in Perl 6
John Siracusa wondered how he’d go about writing a Class::MethodMaker equivalent in Perl6. (Personally, I’d roll my own subclass of Class and MetaClass). Discussion followed, but I don’t think they came up with any implementation techniques yet.
Announcements, Acknowledgements, Apologies
I’m sorry, but there’s no announcements this week.
If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. You might also like to send me feedback at mailto:pdcawley@bofh.org.uk
http://donate.perl-foundation.org/ – The Perl Foundation
http://dev.perl.org/perl6/ – Perl 6 Development site
Tags
Feedback
Something wrong with this article? Help us out by opening an issue or pull request on GitHub
