The Perl 6 Summary for the 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).

    http://tinyurl.com/2mowl

  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

    http://tinyurl.com/34be5

  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://tinyurl.com/2gcbs

  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.

    http://tinyurl.com/2xsrc

  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.

    http://tinyurl.com/2ff8t

  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.

    http://tinyurl.com/3bl4u

  "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.

    http://tinyurl.com/37wqy

  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.

    http://tinyurl.com/24h68

  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'.

    http://tinyurl.com/3xn29

  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.

    http://tinyurl.com/2j3kp

  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 ".local"s 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.

    http://tinyurl.com/3f9gq

  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.

    http://tinyurl.com/ysd9z

  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.

    http://tinyurl.com/365k3

  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.

    http://tinyurl.com/22nxa

    http://tinyurl.com/3dfas

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.

    http://tinyurl.com/ywyle

  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.

    http://tinyurl.com/39qvw

  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.

    http://tinyurl.com/26bc6

  Hyper mutating methods
    Matthew Walton wondered if the new "@things».method()" hyperized method
    syntax also worked with mutating methods ("@things».=method()"). Answer:
    Yes.

    http://tinyurl.com/2kuqn

  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.

    http://tinyurl.com/yq424

  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.

    http://tinyurl.com/33tcm

  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.

    http://tinyurl.com/2xdpt

  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.

    http://tinyurl.com/2fx7d

  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.)

    http://tinyurl.com/3b63e

  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...

    http://tinyurl.com/ytpex

  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.

    http://tinyurl.com/2pvay

  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.

    http://tinyurl.com/2bbsh

  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.

    http://tinyurl.com/37hoz

  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.

    http://tinyurl.com/2424p

  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.

    http://tinyurl.com/3x8xq

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:[EMAIL PROTECTED]

    http://donate.perl-foundation.org/ -- The Perl Foundation

    http://dev.perl.org/perl6/ -- Perl 6 Development site

Reply via email to