Sign In/My Account | View Cart  
advertisement


Listen Print

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

Meanwhile, over in perl6-language

The Type discussions continued. (Though I note, with some satisfaction that most of the discussions died down after I posted the summary. Maybe I got it right. Or not.)

Types

Michael Lazzaro's excellent summary of what we knew about Types served as the seed for this particular discussion, which was essentially a continuation by other title of the thread that started last week. Discussion centred on ways of specifying what sorts of type coercions should be automatic and which disallowed. Paul Hodges suggested use strict allow => { Int => Str, Foo => Bar } as a possibility, which doesn't quite work where you want to allow a type to convert to more than one possible target type, but it does look like a reasonable start.

There was also discussion of autocoercion to different types via a 'path' of coercions which looks to like it has enormous potential for complexity based nuisance. Michael Lazzaro reckoned that a lot of the chaining problems would go away if you drew a distinction between a 'lossless' coercion to a string and a serialization of something to a string for the purposes of debugging or whatever. (Coercing *from* a string to almost any other type but a numeric one seems to be the hard problem...)

Damian offered some thoughts about user defined coercions when he pointed out that a coercion is really an interaction between two classes and should therefore be implemented using a multimethod. He argued that things like Coercions were a strong argument for allowing return type to be incorporated into the multidispatch resolution mechanism. Others agreed that this would be a good thing, and we await a decision from Larry.

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

http://groups.google.com/groups -- This week's 'root'

http://groups.google.com/groups

Change in 'if' syntax

The Subject of the thread still thinks the discussion is about a change in the syntax of if, but it's actually about a change in how a block is recognized, which has knock on effects on on the syntax of various control structures, of which if is just one example. Various people balked (again) at the fact that the new rules for detecting a block mean that code like %foo {bar} no longer means ``find the value associated with 'bar' in the hash %foo'' but instead evaluates to a hash variable followed by a block, and probably a syntax error soon afterwards. Michael Lazzaro and Damian showed workarounds for this (%foo .{bar} and %foo{ bar} respectively) and Arcadi Shehter reminded everyone of the space eating _ that seems to have been completely forgotten since the last time this issue arose.

http://groups.google.com/groups

anon-sub()'s execute in a for??

Paul Hodges took a crack at implementing for as a subroutine and came up with something that didn't look too insane. Luke Palmer added a refinement allowing for n at a time looping. However, for reasons that I can't quite put my finger on, I'm not quite sure that either method has got the sub signature quite right, and I'm not entirely sure how you would express for's signature as a Perl 6 signature anyway. Answers on a mailing list please.

http://groups.google.com/groups

* vs **

Paul Hodges wondered about the * and ** flattening operators. He wondered if they were actually distinct operators or if the double variant was simply the result of applying * to the results of *@whatever. According to Larry, the two are distinct, the only difference between them is one of timing. I'm not sure I understood the distinction to be honest and I don't think I'm alone in this. Austin Hastings asked for an illustrative example, but we didn't see any before the end of the week.

http://groups.google.com/groups

P6Objects: Hint's allegations and things unsaid

Austin Hastings' response to last week's mammoth Types discussion was a mammoth document of his own on what is currently known about Perl 6's Object Orientation features which was the result of trawling back through about two years of perl6-language postings. And jolly good it is too. It triggered a modest amount of discussion, but my theory is that everyone was too impressed to say much. I know I was.

http://groups.google.com/groups

Storing program state for restarting

Ed Peschko wondered if it would be possible to serialize the state of a running program so that it could pick up where it left off after it died at the point of expiry. Dave Storrs suggested that, if one could just serialize the current continuation, the problem would become trivial (I'm not entirely sure he's right about that though; the current continuation seems to me to be in slightly the wrong place) and asked how one could do such a thing. The answer appears to be 'to the best of current research's knowledge, you can't generally do that, but we're working on it...'.

http://groups.google.com/groups

C-struct style data reads

Paul Hodges doesn't like pack. What he wants to be able to do is something akin to C's:

    struct {
        int   someInt;
        float someFloat;
        char  strData[42];
        float otherFloat;
        char  moreStr[123]
    } buf;
    fread(buf, sizeof buf, 1, fp);
    printf("%.0f %s", buf.someFloat, buf.moreStr);

instead of unpacking a string with unpack "ifa43fa123" <$file> or whatever. This led to some discussion of appropriate syntax and the like, but it was generally felt that, even if something like this wasn't in the core, it wouldn't be too hard to implement it.

http://groups.google.com/groups

Return types vs. Generic Programming

Michael Lazzaro wants the moon on a stick. In particular he wants to be able to declare:

   class Object { method CLONE returns MAGIC_TYPE {...} }

where MAGIC_TYPE is some magical token that means not having to declare

   class Whatever { method CLONE returns Whatever { .NEXT::CLONE } }
   class Whoever  { method CLONE returns Whoever  { .NEXT::CLONE } }

Quite what's wrong with

   class Object { method CLONE returns Object {...} }

is a mystery to me. Luke Palmer wants more than that. The insanity continued for several messages.

Do you get the feeling that I'm not a fan of this particular proposal? I confess I'm finding it very hard to summarize it any more than the above without exclamations of shock and dismay. So I'll stop now. Read the thread if you're interested.

http://groups.google.com/groups

Type Conversion Matrix

Michael Lazzaro posted a matrix of some of the known built in types and of the possibilities of conversion between them, noting that what was shown were the conversions that it was possible to make automatic, not necessarily those which should be automatic. For some reason this led to a discussion of boolean types. Nope, I don't know why either.

Another subthread discussed which conversions were lossy and whether or not to make them automatic in the case of going from, say 'Int' to 'int'. (Int being a Perl Integer which could be undef and have properties and traits, and 'int' being, essentially, at least 32 bits of signed integer).

Michael posted a second take on the matrix with more information and with an additional 'Scalar' type added to it.

http://groups.google.com/groups

http://groups.google.com/groups

Fun with Junctions

Austin Hastings got faintly confused by the difference between 'all' and 'any' junctions. The rule of thumb appears to be 'if you want to use a junction to represent a set, use an ``any'' junction.'

http://groups.google.com/groups

Fun with multi-dimensional arrays

Dave Whipp pointed everyone at a discussion of Perl 6 on Perlmonks, where people were implementing J H Conway's Game of Life in Perl. Dave had a some questions about tools for iterating over multidimensional arrays, suggesting some syntax as he went, then pulling it all together in a rather neat recalculation engine for the game of life.

Things got scary pretty quickly after that; at one point Dave even did a local redefinition of infix:= which certainly had me worried. Some clever stuff going on there and no mistake.

http://groups.google.com/groups

http://www.perlmonks.org/index.pl?node_id=253366

Acknowledgements, Announcements and Apologies

That about wraps it up for this week.

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