This week on Perl 6, week ending 2003-04-20

Apr 20, 2003 by Piers Cawley

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 can and does ops.
  • Dan explained that can and does were 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

Perl 6 parser questions

Right at the end of last week, Austin Hastings asked a bunch of questions about the behaviour of the Perl 6 parser. He wondered, for instance, if, in the future, he’d be able to (usefully) say:

    #!/usr/bin/perl6.1
    use Perl6::Grammar v6.0.0.2;

Larry answered this question (“I don’t see why not”) and all of Austin’s other questions on this topic. Apparently the Perl 6 Parser will be documented ‘whenever Apocalypse 18 comes out’.

http://groups.google.com/groups

Initializations outside of control flow

Mark J. Reed asked about elegant ways of initializing shared variables. He wanted something a little neater than the blunderbuss of a BEGIN block. Larry obliged with one of his ‘thinking aloud’ posts which, while not giving us a final answer does give us a few signposts. It’s looking like we’ll have traits along the lines of:

    state $where is begin($value);
    state $where is check($value);
    state $where is  init($value);
    state $where is first($value);

Where the traits work analogously to BEGIN, CHECK, INIT and FIRST.

http://groups.google.com/groups

http://groups.google.com/groups

The new returns keyword

David Storrs was a little worried about the possible clash between the new returns keyword – introduced in Apocalypse 6 – and return. Michael Lazzaro pointed out that the ‘possible clash’ was almost certainly deliberate, after all:

    sub foo returns Bar {...}

reads rather well. David had used the example my $spot returns Dog, which does look rather ugly, but Michael pointed out, in the case of a variable declaration, it made more sense to use my $spot of Dog or even my Dog $spot. Michael commented that this choice of syntax meant the programmer was able to pick the most readable phrase for a given situation.

http://groups.google.com/groups

A17 early discussion: Perl 6 threading proposal

Austin Hastings posted what would once have been called an RFC about Perl 6’s threading model. No comments so far.

http://groups.google.com/groups

wrap from Synopsis 6

David Storrs wondered if the new .wrap method, which returns a unique id identifying the particular ‘wrapper’ could have an associated warning if the resulting id wasn’t stored somewhere. Adam D. Lopresto and Austin Hastings weren’t keen…

http://groups.google.com/groups

http://groups.google.com/groups

Compulsorily named parameters?

The debate over declaring non optional named parameters continued as Damian joining in. The current consensus appears to be that the various optional/named/slurpy shorthands introduced in Apocalypse 6 should stay pretty much as they are, but that it should be possible to declare more complex parameter requirements using sensibly named traits. John Siracusa still wants a more ‘powerful’ shorthand, but there doesn’t seem to be anyone taking his side on that.

http://groups.google.com/groups

Multimethod invocants

Multimethods still appear to be causing some confusion, mostly to do with how they are called and dispatched, and which method parameters participate in the dispatch. There’s a largish contingent (and I probably my count myself a member of that contingent, spot the bias) who would like to be able to write:

    multi infix:@ (Number $x, Number $y) { new Point: $x, $y }

    class point {
        ...
        multi make_rectangle ( Point $p ) {
            new Rectangle: $_, $p;
        }
        multi make_rectangle ( Number $x, Number $y ) {
            .make_rectangle( $x @ $y );
        }
    }

Which isn’t allowed. Instead you would have to write:

    multi make_rectangle ( Point $p, Point $q ) {
        new Rectangle: $p, $q;
    }

    multi make_rectangle ( Point $p, Number $x, Number $y ) {
        make_rectangle ($p, $x @ $y);
    }

And you also have to be wary of

    my Point $p;

    ...

    $p.make_rectangle($x @ $y);

which would first try to dispatch to Point’s make_rectangle ‘unimethod’, only attempting to dispatch via a multimethod if there is no such method. Personally, I think there’s room for a spoonful or two of syntactic sugar to allow for the ‘method variant’ style of declaration as well as the full on generic multimethod style (which would, of course, underpin the more restricted method variant style). However, if it doesn’t exist out of the box I expect someone (me?) will write a set of macros to make things work.

In the message referenced, Damian explains the current state of the multimethod art…

http://groups.google.com/groups

Types…

Well, that’s 100 or so messages accounted for. Which leaves another 173 messages remaining all of which concern types. The problem as I see it is that different people seem to understand different things from the word type, and there’s a lot of people talking at cross purposes as well as a fair amount of axe grinding going on.

Now, I could just punt and write something like “Everyone except Leon Brocard talked for ages about types. Here are the links to those threads” which would at least has the virtue of getting the god awful running joke out of the way, but that would smack of cheating. So, what I’m going to do is to only cheat slightly. At the bottom of this section you’ll find links to all the threads that discussed types this week. However, before that I’ll try give you a (biased) overview of the issues involved and the areas of confusion.

An illustrative quotation from Lewis Carroll

“The name of the song is called ‘Haddocks’ Eyes.‘” [said the White Knight.]

“Oh, that’s the name of the song, is it?” Alice said, trying to feel interested.

“No, you don’t understand,” the Knight said, looking a little vexed. “That’s what the name is called. The name really is ‘The Aged, Aged Man.’”

“Then I ought to have said ‘That’s what the song is called’?” Alice corrected herself.

“No you oughtn’t: that’s another thing. The song is called ‘Ways and Means’ but that’s only what it’s called, you know!”

“Well, what is the song then?” said Alice, who was by this time completely bewildered.

“I was coming to that,” the Knight said. “The song really is ‘A-sitting On a Gate’: and the tune’s my own invention.”

– From Alice Through The Looking Glass, by Lewis Carroll

Two types of type

Perl 6 draws an important distinction between ‘variable type’ and ‘value type’. A variable is a binding between a name and a container. The variable type is the type of the container associated with the variable’s name. A variable’s ‘value type’ is the expected type of the value stored in the variable’s container. As far as I can tell, Perl is weirder than the average programming language in this respect in that it allows the programmer to specify both sorts of type. In C for instance, a value doesn’t know its own type, it’s just an area of memory that is interpreted according to the type of the variable that it is accessed via (or according to the type it is cast into). Meanwhile, in lisp like languages, ‘variables’ are simply keys in a symbol table, and the values in that symbol table are untyped pointers to values which know their own type.

Perl 6’s symbol tables are rather more like Lisp symbol tables than C’s, with the added wrinkle that the symbol table values are rather more sophisticated containers than simple generic pointers. This complexity arises for a couple of reasons:

Tied variables.
Instead of storing a variable’s value in one of the core container types (Array, Hash, Scalar), it can be useful to use a custom container type to allow for ‘magical’ behaviour:

    my $FTSE is ShareIndex('FTSE');
    print "$FTSE";
    # FTSE 100 Index: 3916.70 (+27.50/+0.7%) at 2003042216:40

Context
Context is really important to Perl. If you look at an array variable in a numeric context, then you get the number of items in the array; in list context, a list of all the items in the array; in a scalar context, a pointer to the array. This context dependent behaviour is best handled by the container object, possibly with the assistance of the contained object, but not always.

Scalars turn out to be one of the more remarkable types of Perl containers. At their simplest they can be thought of as a container which can hold at most one ‘atomic’ thing. Perl 5 scalars have three(?) slots for Number, String and Reference values (On IRC, Dan tells me that Perl 6 scalars will probably have slots for String, Float, Integer, Boolean and Reference values). These different ‘scalar value types’ can, with certain restrictions be treated without regard to their ‘actual’ type: A Number in a string context will give a sensible string representation, a string in a number context will give an appropriate numeric value, but not every possible scalar value type can be sensibly viewed as any other type; if you try and use a number in a reference context, you’re going to get an error for instance. For added fun, it’s perfectly possible for a scalar variable to contain both a Number value and a String value (In Perl 5, Scalar::Util provides a nice interface to this preexisting capability. On IRC, Dan suggests that the Perl 6ish way of doing this will probably be my $i = 4 but "Bibble!";).

What are value type declarations for?

Some people see value type declarations as being important for programmer safety. They want to see a situation where:

    my Number $foo = some_function_returning_a_string();

or

    sub a_func (Number $param) { ... }

    a_func("A string");

will throw exceptions, preferably at compile time.

Others want to see those same code fragments coerce any values assigned to them into the appropriate types (possibly with a warning) and see value type declarations simply as a way of letting the compiler do automatic optimization of code (if you have declared that a given variable will only contain, say, a number, you can (at least) get rid of a layer of indirection in accessing that value).

Others don’t really care one way or the other about whether or not to coerce, they just want to use value types in setting up multimethods.

Still others don’t really like the idea of declaring types at all, but do see value in ML like type inference for programmer safety reasons…

Others want to let the programmer choose, and worry about how to implement something which will let that happen. I’m a ‘let the programmer choose, and the compiler optimize what it can’ kind of guy.

Are types the same as objects?

If types are the same as objects, do they all inherit from a common base class? If they do, what does the hierarchy look like? What about interfaces? Do they need to be explicitly declared or can they be inferred. If they can be inferred, what about the problem of:

    class Tree {
        method feed {...}
        method grow {...}
        method bark {...}
        ...
    }

    interface Canine {
        method feed {...}
        method grow {...}
        method bark {...}
    }

    class Borzoi {
        method feed {...}
        method grow {...}
        method bark {...}
    }

    ...

    multi treat($vet, Canine $critter ) {...}

    treat($some_vet, Tree.new); # Should this fail?

Arrghh!!! Make the hurting stop!

However, I don’t care what Dan says, I want every type to have an associated class, and I want them all to inherit from some sort of common base class (at least conceptually, and, if I’m prepared to take the performance hit and jump through the hoops, actually. Sometimes you need to override Scalar’s behaviour (or whatever)) but I don’t think the inheritance trees that have been bandied about so far even come close to expressing the semantics we need. Expect a longish post to Perl 6 language on this at some point. Probably with (more or less) pseudo code.

Another distinction to think about

OO theory talks about value objects and reference objects. (I’m using ‘object’ here to try and get come conceptual distance from ‘value type’). Here’s an abstract example of what I mean

    my $a = new ValueObject: value => 10;
    my $b = $a;

    $b.set_value(20);

    print "$a $b"; # 10 20

    my $c = new ReferenceObject: value => 10;
    my $d = $c;

    $c.set_value(20)

    print "$c $d"; # 20 20

Just when you thought you understood value types…

Along come compound value types to mess with your head. Assuming a strict interpretation of value type declarations (assigning the the ‘wrong’ type to a variable throws an error), consider the following:

    my @a of Int = (1, 2, 3);
    my @b = @a;
    my @c of Str;

What happens to each of the following? If it’s an error does it happen at runtime or compile time?

    @c = @a;
    @c = @b;

    push @a, "String";
    push @b, "String";

Are you sure about those? Now, what happens if you start with:

    my @a of Int = (1 .. Inf);
    my @b = @a;
    my @c of Str;

And there’s more thorny problems where they came from.

http://groups.google.com/groups – Types of literals

http://groups.google.com/groups – Do we really need the dual type system

http://groups.google.com/groups – User defined hierarchical types

http://groups.google.com/groups – Mind the difference between value types and reference types

http://groups.google.com/groups – Static typing with Interfaces

http://groups.google.com/groups – Michael Lazzaro’s superb summary of how containers and values interact. Not sure it’s the whole story though…

Acknowledgements, Announcements and Apologies

Sorry it’s late. I blame the perl6-language people. It has nothing whatsoever to do with weekend spent in Wales and a Bank Holiday Monday spent at an Easter egg hunt and barbecue at my aunt’s.

This has been one of the harder Perl 6 summaries to write, mostly because the language list has been dealing with a complicated subject and finding lots of interesting corners and ambiguities. Many thanks to Michael Lazzaro for his careful summation of his understanding of how things work which certainly clarified my thinking, to Stéphane Payrard for his sanity check of the types summary and to Dan Sugalski for a few answers on IRC about Scalar behaviour.

If you’ve appreciated this summary, please consider one or more of the following options:

Tags

perl-6
perl-6-internals-parrot

Feedback

Something wrong with this article? Help us out by opening an issue or pull request on GitHub