This week on Perl 6, week ending 2003-04-20
by Piers CawleyApril 20, 2003
You know how it is, you go away for a lovely weekend folk festival in Wales, you have a really good, relaxed time, singing yourself hoarse and generally forgetting all about technology before coming home to email from the perl.com editor asking if he could have the summary about half an hour ago, and then you skim through the lists and find nearly 300 messages unread? You do? I thought it was just me. So, having utterly failed (by virtue of being elsewhere) to get a summary written by Monday, I'm currently shooting for 'getting it written'. Welcome to this week's Perl 6 summary; all the fun of the Perl 6 lists with none of the tedious 'reading every message'.
Let's see if I can't ease myself back into the Perl 6 vibe by summarizing the still rather quiet perl6-internals list first...
Building Parrot on Win32
Steve Fink has been busy committing (in the CVS rather than the culpability sense) Mattia Barbon's patches to get Parrot building happily in a Win32 environment. If you have such an environment, now would probably be a good time to grab the latest Parrot from CVS and see if it builds for you. I'm sure the list would be grateful to hear of your experience, good or bad.
PMC documentation
After seemingly weeks in the wilderness with very little feedback, Alberto Simões finally got some comments on (and thanks for) his latest PMC doc patches from Steve Fink and Brent Dax. The docs haven't made it into the distribution yet though, but it can only be a matter of time.
http://groups.google.com/groups
Is PMC size fixed?
Mattia Barbon wanted to know if it would eventually become possible to create PMCs with additional data members. Dan says not; PMCs are allocated from arenas which apparently means they need to be the same size (variable sized PMCs would mean adding complexity to the garbage collector, which is already complicated enough thanks very much...)
http://groups.google.com/groups
Dan Does Design Decisions
Dan announced a few design decisions:
- It's time to start assigning permanent opcode numbers to some of the opcodes.
- There's some new stack ops,
halfpop[insp]. - We now have
cananddoesops. - Dan explained that
cananddoeswere there to support fast interface polymorphism.
http://groups.google.com/groups -- permanent opcode numbers
http://groups.google.com/groups -- halfpop
http://groups.google.com/groups -- can/does
http://groups.google.com/groups -- Interfaces/Classes
Short-lived memory allocation
Luke Palmer wondered what the Right Way was to allocate dynamic memory that wouldn't be needed beyond a function invocation. The answer, of course, was 'use Parrot memory management and let Garbage Collection work its shiny magic'. Toward the end of the thread Dan let on that Parrots Garbage Collector is 'always going to be walking the system stack' so there was no need to worry about anchoring the newly allocated buffer to the root set for the duration of the function invocation, which seems to be a new commitment. Both Dan and Steve Fink observed that the memory documentation could use updating to clarify best practice for everyone. Volunteers?
http://groups.google.com/groups
How deep is clone?
Alberto Simões asked how deeply the clone operator worked.
According to Leopold Tötsch it's a deep,
recursive clone,
which he noted makes for interesting times when dealing with self referencing structures (Dan reckoned that it shouldn't be too bad if you take advantage of the GC system's graph traversal smarts...).
Luke Palmer wondered why the default was a deep copy as,
he claimed,
deep copies were seldom needed.
He wondered how to make a shallow copy.
Leo suggested extending clone with an extra parameter to specify deep or shallow copying.
Dan said that it is the way it is because he said so,
and that one would make a shallow copy with assign.
http://groups.google.com/groups
Shared memory
David Robins wondered whether Parrot's memory allocation system would cope with sharing memory between processes and found some messages in the archive that seemed to imply that 'it will cope eventually'. He wondered how it would cope. Warnock's Dilemma applies...
http://groups.google.com/groups
A New GC approach?
Kurt Stephens announced that he had a partially written 'conservative, non-copying "treadmill"' GC system that could work in real time without stopping the world. He wondered if it could be useful for Parrot. No comments so far...
http://groups.google.com/groups
http://kurtstephens.com/research/index.html
IMC and variable number of arguments
K Stol wondered how to handle a variable number of function arguments in IMC code. Dan remarked that it was covered by the Parrot calling conventions (presumably IMC code doesn't do the dfull Parrot calling conventions though). Leo Tötsch suggested making sure that the last thing pushed onto the argument stack was the number of arguments, and Will Coleda suggested passing a single PMC like a PerlArray...
http://groups.google.com/groups
Meanwhile, over in perl6-language
If I were asked to summarize this week's traffic on perl6-language with one word, that word would be 'Types'. It turns out that thinking about types, and how they should behave in Perl 6, is hard. I don't envy Damian the writing of the next Exegesis, that's for sure.
Instead of presenting the threads in roughly chronological order this week I'm going to deal with the none type related threads first and then attempt to sketch the current issues with types without quite so much reference to individual threads. Cover me, I'm going in...
Currying questions
Last week,
Ralph Mellor had asked whether currying assumptions could be overridden when the curried function was called and Luke Palmer had said he didn't think so.
This week Damian answered with a rather more authoritative "No,
they can't be overridden,
just make a call to the original function.".
Ralph had also wondered if there would be a way to specify whether currying assumptions were made by binding or by copying a value (currently,
they get bound,
just like they do when you call a function normally (I wonder what happens when the function prototype specifies is copy)).
Damian said that,
if you wanted to make an assumption based on a copy then you needed to explicitly make that copy.
http://groups.google.com/groups -- Ralph's original questions
Are all list constructors iterators?
'Marek Ph.' admired the shiny goodness that is lazy evaluation and wondered if all list constructors were actually iterators. He wanted to know if that meant that
@a = 1 .. Inf;
splice @a, 5, 2;would yield
@a == (1 .. 4, 7 .. Inf)He also asked if the x operator would generate an iterator too.
Luke Palmer thought the answer to both questions was "Yes".
http://groups.google.com/groups
... but foo('bar')
Stéphane Payrard spotted a possible ambiguity in Perl 6's grammar. He wanted to know if
... but foo('bar')set the property 'foo' to the value 'bar',
or did it create a property with the name being the value returned by a function call of foo('bar').
He wondered what the syntax would be to get the 'other' meaning.
Luke Palmer thought the first part was that the property 'foo' would get set to 'bar' (so do I,
unless the thing implementing the property has some special semantics).
He suggested that to force the call to the function to get a property name one would do one of:
... but $(foo('bar'))or
... but &foo.('bar')I prefer the second of those two.
http://groups.google.com/groups
