Sign In/My Account | View Cart  
advertisement


Listen Print

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

Complex Parameter Types

Michael Lazzaro wanted to know more about 'complex' type declarations. He wanted to know how these interacted with signatures, could one use arbitrarily complex types in subroutine signatures? Could one do multidispatch on them? He also had a question about when/whether types got coerced (that wasn't actually his question, but it's what it boiled down to) when functions were called.

The answer to the first two questions was straightforward: Yes, you can use arbitrarily complex types in function and multimethod signatures.

The third one proved a little trickier. Damian said that values would not be coerced, but Larry wasn't so sure. He thought that coercion would be the right thing to do. Probably. Damian noted that the 'Right Thing' could well vary depending on whether the parameter in question was declared is constant/rw (in which case passing a parameter with the wrong type would be an error) or is copy (in which case coercion could be the thing to do). Austin Hastings wondered if this could be handled with a use strict 'params' type pragma, but Damian wasn't convinced, arguing that the use of typed params automatically implied type stricture.

This thread gets horribly hard to summarize so, for now, I'll just pick out some representative highlights.

Larry says that, in the absence of a pragma to the contrary type checking will be done at runtime if the type is unknown/unknowable at compile time, but he expects the B&D types to come up with a pragma that enforces compile time checking on pain of failed compilations.

Brent Dax came up with the concept of 'strict' and 'loose' argument typing. Strict arg typing doesn't coerce except that, say, a Child can satisfy a requirement for a Parent. Loose arg typing will coerce wherever possible. He argued that the mechanism for choosing between strict and loose arg typing should be under the control of the caller rather than the callee, as that seemed to fit best with The Perl Way. Larry agreed with him. He added that the real question is whether the default use strict should include strict arg typing and noted that he was inclining toward the strict side. This week.

A subthread sprang up dealing with Type inference. David Whipp noted that a smart compiler might well be able to infer the type of some variables at compile time. The theory being that in the presence of good type inference some variables wouldn't have to have a known type to avoid triggering compile time errors under strict arg typing. Angel Faus pointed out that using 'user visible' type inference wasn't too good an idea because (among other reasons) it might lead to cases where a program only works as written for more recent versions of the compiler (which doesn't mean that type inference is a bad idea; if the compiler knows the type of a variable it could potentially use that information to improve code performance).

My head started spinning when Larry seemed to imply that, not only is Int a Scalar, but a Scalar is also an Int. Or maybe it plays one on TV.

This thread is still very much underway as I write this summary, so attempting to summarize it is akin to summarizing a book when you're halfway through it; you're never quite sure what are the important bits. Hopefully things will be a little nearer resolution next week and you'll get a more coherent summary of the conclusions.

http://groups.google.com/groups

http://groups.google.com/groups -- the inference subthread

http://groups.google.com/groups -- My head hurts

Signatures zones and line noise

Brent Dax wasn't keen on the new syntax for declaring whether parameters were optional, positional, named or variadic (greedy) and wondered if we couldn't use something prettier (wordier) with named traits ($x is optional etc). Damian thought that would be 'uncomfortably prolix' with default values ending up a long way from their owners. Paul and Brent proposed allowing


    multi substr(Str $str, $from = $CALLER::_ is optional
                           $len  = Inf is optional,
                           $new is optional) {
        ...
    }

but Damian pointed out that this could lead to badness because, in a signature the is would bind to the variable, but in a normal variable declaration and assignment the is would bind to the value, which would be confusing. There was some discussion of appropriate names for the other 'linenoise' in signatures, specifically the choice of name for the * type. The three front runners appear to be 'variadic', 'greedy' and 'slurpy/slurpificatious'. I like 'greedy', but then I'm close to the person who proposed it.

http://groups.google.com/groups

In which Luke Palmer gets ignored

Luke Palmer had things to say about Appendix C of the apocalypse, specifically to do with temp/let and with caller and Continuations. Maybe what he said on these subjects was completely uncontroversial, but nobody has replied to either of them yet.

http://groups.google.com/groups -- temp/let

http://groups.google.com/groups -- Continuations

Multi promotion

Richard Proctor wondered what would happen if you declared a multimethod with the same name as a previously declared normal sub/method. Specifically he wanted to know if the new declaration would automagically turn the old one into a multimethod. Michael Lazzaro thought not. As did Damian and Larry. Damian provided a summary of the rules for subroutine/method dispatch, which look wonderfully subvertable. Piers Cawley wondered if it would be possible to get at a 'dispatcher' object and/or override it in a lexical scope, nothing that sometimes, he scares himself. Nicholas Clark seemed to think Piers wasn't completely insane before going on to talk about wrapping and unwrapping in the case when the wrapper has itself been wrapped. Larry seemed to think that unwrapping should still do the right thing even if the wrapper being removed is itself wrapped.

http://groups.google.com/groups

http://groups.google.com/groups -- Dispatch rules (OK?)

Wrappers vs. Efficiency

In the Apocalypse, Larry talked about the performance implications of generalized function wrappers and brought up the idea of subroutine traits which would mark a sub as unwrappable, giving is inline as an example. John Siracusa asked that whatever the 'specific definition for speed' is that forbids runtime wrapping, it shouldn't be spelled 'inline' (though inline may imply "don't wrap me please"). A few people agreed, but things mostly got left vague.

http://groups.google.com/groups

Macro invocants

Dave Whipp wondered about using macros to do things like:


    my Database $db = MySqlDatabase.connect(...);
    $db.select * FROM Foo WHERE Foo.bar LIKE a%b;

by implementing select as a macro. Larry thought so, but you would have to export the macro into the calling context. Larry added that you would probably implement that particular functionality by treating ".select" as an infix macro with a specially parsed argument on its right hand side (the SQL statement). David thought this was a little clunky and proposed macromethod as a way to avoid the export requirements. Luke Palmer was unconvinced and it went back and forth a few times.

Larry wasn't convinced by David's suggestion either, commenting that 'mixing such compile-time semantics with a notation that supposedly mandates run-time dispatch is a recipe for a certain amount of confusion no matter how well we do it.'

http://groups.google.com/groups

Overloading multis on constness of parameters

Joe Gottman wondered if it would be possible to overload multimethods based on the const-ness of a parameter is the same way C++ does. The answer appears to be 'yes'. Piers Cawley passed on a question from Greg MacCarroll about overloading on the value of a parameter. Damian thought probably not, but then showed a cunning trick involving overloading isa and a junction to allow something pretty similar. Luke Palmer was impressed.

I'm not entirely sure what it had to do with this particular thread, but Austin Hastings posted a chart of his understanding of the various dispatch rules. Worth reading.

http://groups.google.com/groups

http://groups.google.com/groups -- Austin's chart

Operators and context

Deborah Ariel Picket had some questions about Michael Lazzaro's complete list of known Perl 6 operators, and wondered if this list should be extended to take context into account. She also wondered what the complete list of possible contexts was now. Michael reckoned that the list she pointed to was still current, but he expected to add the new <== and ==> ops. He also agreed that adding information about contextual behaviour would be a good (if daunting) thing to do. He noted too that Apocalypse 6 seems to imply that there would be a context for every type. Nothing definitive from Larry (or even Damian) yet.

http://groups.google.com/groups

http://archive.develooper.com/perl6-language@perl.org/msg12130.html -- the current operators list

Assignment Overloading

Luke Palmer wondered if it would be possible to overload the assignment operator and wondered if the assignment operator was a value or a reference copy. Damian pointed out that *infix:= was really an operator on containers not values and you'd probably implement it by overloading STORE in the container's class. He also commented that STORE might end up being spelled &infix:=. Copying is a shallow value copy.

Larry popped up to discuss the .copy method on SCALAR but I wasn't entirely sure whether that gets called on the target container or the thing being copied. But that might just be me being confused.

http://groups.google.com/groups

P6FC

Aldo Calpini put up a tentative class hierarchy for Perl 6's standard classes (he called them the Perl 6 Foundation Classes, narrowly avoiding a knee jerk response from at least one summarizer of this parish) and asked for comments. Murat Ünalan suggested that Aldo was posting to the wrong audience before suggesting that we adopt the .Net/Java object hierarchy, which confused Aldo somewhat, so Murat clarified what he meant. Simon Cozens made a few suggestions to Aldo about naming and missing classes. Larry added some clarifications on his thinking about the difference between types and classes.

http://groups.google.com/groups

http://dada.perl.it/p6fc.html -- Aldo's class diagram

http://groups.google.com/groups -- Larry on types and classes

Thoughts about multiple properties

Chris Dutton wondered about using junctions for multiple properties so method bar is public is rw {...} could be written as method bar is public & rw {...} instead. Jonathan Scott Duff didn't think that made much sense, and pointed out that the is is optional after the first, so you could write method bar is public rw {...} if you wanted. Larry noted that 'that feature is still in Schrödinger's little box.'

This led Mark Biggar to suggest some syntax for neatly defining groups of traits and complex types without having to go to the length of defining a class. Michael Lazzaro thought that Perl 6 classes wouldn't be as heavyweight as they are in Perl 5 and did some WAGging (Wild Ass Guessing) about making subs that inherit from Sub which looked pretty good to me even if it did lead Austin Hastings to call Michael a 'bad, evil man'.

http://groups.google.com/groups

Named vs. Variadic Parameters

Michael Lazzaro pointed up some issues with subroutines that have both variadic arguments and named arguments. Luke Palmer thought that there were two, mutually exclusive, ways of dealing with this: Michael's proposed behaviour and the behaviour described in the Apocalypse. Luke was happy with the Apocalypse behaviour. Michael said that he hoped that whatever was decided, 'broken' function signatures would give rise to a compiler error.

http://groups.google.com/groups

is static?

Uri Guttman asked about static variables in Perl 6. In Perl 5 you can get a static variable by doing:


    {
        my $count = 0;

        sub sequence { return ++$count }
    }

Uri wanted to be able to do something like:


    sub sequence {
        my $count is static is default(0);
        return ++$count;
    }

Dave Whipp wondered if our did the job (it doesn't). Larry mentioned that he didn't particularly like 'static' as a name for this sort of variable and reckoned that, if there were an 'is static' declaration the compiler would probably translate:


    my $pi is static = 3;

to something like


    our $foo__Xdeadbeef will init {.set(3)}

Larry's preferred syntax would be our $foo is unique, but he noted that 'It's not like someone isn't going to implement "is static" the moment our back is turned anyway'.

http://groups.google.com/groups

No mandatory named arguments?

Nicholas Clark wondered if his reading of Apocalypse 6 was correct and that there is no way to specify mandatory named parameters. Larry agreed that this was so, but that one could finesse things at runtime with tricks like:


    sub foo(+$req = die 'You must supply a "req =>" argument') {...}

http://groups.google.com/groups

Acknowledgements, Announcements and Apologies

That about wraps it up for this week. Many thanks to Larry for giving us all something to talk about on perl6-language this week; I was starting to think about making the language list summary a fortnightly thing.

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.