develooper Front page | perl.perl6.language | Postings from December 2003

This week's summary

Thread Previous | Thread Next
From:
The Perl 6 Summarizer
Date:
December 16, 2003 02:55
Subject:
This week's summary
Message ID:
m2llpdghgi.fsf@obelisk.bofh.org.uk
The Perl 6 Summary for the week ending 20031214
    It looks like things are starting to slow down slightly as we run up to
    Christmas, but the quality of discussion remains high. We'll start with
    the usual trawl through perl6-internals.

  Testing for null
    Dan ruled on last week's discussion of testing for undef in Parrot.
    We're getting a new "isnull" branch op along with a new Undef PMC. Leo
    Tötsch implemented it with his usual alacrity.

    http://groups.google.com/groups?selm=a06010209bbfa414ccf86@[10.0.1.2]

  How many comparison ops do we need again?
    One of the annoyances of writing something that's really going to be
    used is that you can't get away with the equivalent of outlining your
    proof on the blackboard, waving your hands and saying "The details are
    left as an exercise for the interested reader". A case in point is
    Parrot's array of comparison branch operators. For a while now we've
    been getting by with a sparsely populated array of such beasties. This
    week saw people (well, okay then, Leo, but he has the productivity of
    people) doing the detail work to get the full range implemented.

    http://groups.google.com/groups?selm=a06010208bbfa40078332@[10.0.1.2]

  Incorrect scoping of constants in IMCC
    Dan wasn't happy with the scoping of the ".const" directive in IMCC
    (essentially constants are sub/block scoped, which makes them pretty
    much useless for the things constants are normally used for). Melvin
    Smith made the fix.

    http://groups.google.com/groups?selm=a06010227bbfbec732329@[10.0.1.2]

  Objects and Namespaces
    Dan had mandated that the Parrot internal equivalent of the Perlish
    "Package::Name" should be "Package\0Name". Nobody (Dan included) liked
    the embedded nulls mandated in Dan's original spec. After some
    discussion he posted a description of a new hierarchical namespace
    design.

    Dan pointed out that the use of hierarchical namespaces would probably
    mean that the semantics (and syntax) of "find_global" would need to be
    adjusted.

    http://groups.google.com/groups?selm=a06010229bbfc0dac4e0a@[10.0.1.2]

    http://groups.google.com/groups?selm=a0601020bbbfe5002d599@[10.0.1.2]
    -- The New Namespace

  Dan Sugalski, IMCC Bugfinder General
    Dan's been writing more PIR code by hand, and is discovering
    infelicities as he goes.

    http://groups.google.com/groups?selm=a06010207bbfd4f47dab9@[10.0.1.2]

    http://groups.google.com/groups?selm=a06010208bbfd52feb9be@[10.0.1.2]

  Macros, PIR and PASM
    Following his bout of IMCC bug spotting, Dan announced a decision about
    macros in PIR and PASM code. Essentially, Parrot's built in PIR and PASM
    parsers do not need to do macros as 'macro assemblers are for people,
    not compilers'. Because of this, Dan would like to see any macro
    processing moved out of the core binary and into an external tool.
    (Which can always be invoked via the hypothetical macro-parrot.pl).
    Melvin Smith suggested that it would probably be worth extracting the
    existing macro processor from imcc.l and moving it into a separate
    library.

    http://groups.google.com/groups?selm=Pine.LNX.4.58.0312121357440.2785@okcomputer.antiflux.org

Meanwhile, in perl6-language
    The language list continues to fascinate (and not in the 'car crash' way
    it has done on occasions in the past) with an ongoing conversation
    between Larry on the one hand (seemingly designing on the hoof and
    certainly doing a great deal of thinking aloud) and everyone else on the
    other hand getting clarification or extrapolating to the point where
    Larry has to step in and do a little bit more design.

    I'm finding it hard to do a proper summary of what's going on because so
    much is changing (and because so much of what seems to be set in quick
    drying concrete now is so novel.)

    Essentially the discussion revolves around Roles, which are sort of like
    Java interfaces, sort of like mixins and nothing like either. In his
    'Vocabulary' post, Luke Palmer describes a Role as 'A collection of
    methods [and/or attributes] to be incorporated into a class sans
    inheritance [...]. Used with "does"'. In this new world, a property
    ("$bar but Red" etc) is a kind of degenerate role.

    At the same time though, we're getting other gems. For instance, Perl 6
    is going to get something a little like "final", but instead of it being
    a declaration made in a type's implementation ("This is the one, the
    only Integer and you may not inherit from it or ever alter it!"), it
    will become a promise made by a type's user not to attempt to monkey
    with it come run time, which should set the code generator free to use
    optimizations that aren't safe when everything's dynamic.

    So, if you're interested in how Perl 6's OO system is going to work, now
    is the time to get involved in the language list. If there's something
    you've always wanted to do or something about Perl's current OO that you
    love and want to retain, it's time to speak up for it. The odds are good
    that you'll be able to do what you want using the mechanisms being
    designed, but you'll be kicking yourself later if it turns out you
    can't.

    If you do join in, you'll see references to the 'Traits Paper'. This is
    where the original idea for what Larry's calling 'Roles' came from. When
    you read it, bear in mind that the authors of the paper use the term
    'trait' for what we're calling a 'role' (We already have traits you
    see).

    http://www.cse.ogi.edu/~black/publications/TR_CSE_02-012.pdf -- Traits
    paper

  Iterating through two arrays at once
    Joe Gottman asked for some clarification about which was more
    right, Apocalypse 4 ("for @a ; @b -> $a ; $b {...}") or *Perl 6
    Essentials* ("for zip @a, @b -> $a, $b {...}") when talking about
    iterating through two (or more) arrays at once. The rule of thumb
    for this seems to be 'latest publication date wins' so *P6E* is
    the most correct. He went on to wonder what happens when one array
    is shorter than the other (an undefined value is passed into the
    loop when the array runs out of values until the last array is
    exhausted). He wondered what would happen if any of the arrays
    contained "undef"; how would the body of the loop be able to
    differentiate between a 'valid' undef and one created by the loop
    itself.

    Larry pointed out that, in Perl 6, undef isn't necessarily unique and
    may well contain an unthrown exception with extra information hidden in
    a property.

    http://groups.google.com/groups?selm=011701c3bfa1$6e97fc40$42404a18@carolina.rr.com

  Vocabulary
    If you're even vaguely interested in the workings of Perl 6's object
    system, you need to read the referenced post.

    Luke Palmer, worrying about people using Object related vocabulary in
    subtly inconsistent ways, posted a glossary explaining how OO
    terminology is used in a Perl 6 context. Casey West wrapped it up in a
    POD, which will, I hope, end up on dev.perl.org soon.

    Of course, there were a few corrections for subtleties, a few rethinks
    of the design so far, and general gratitude for at least having a
    baseline document that people could refer to.

    http://groups.google.com/groups?selm=20031211050216.GB5184@lighthouse.tamucc.edu

    http://groups.google.com/groups?selm=20031212175822.GA80586@geeknest.com -- Casey's POD

  Enums and bitenums
    Stéphane Payrard wondered if Perl 6 would have enums and bitenums
    directly supported in the language (he pointed out that it wouldn't be
    hard to implement them using macros of course). Larry speculated that
    enums might just end up being special cases of roles/subtypes.

    Further down the thread, Uri Guttman commented that Larry seemed to be
    working on a grand unification and wondered if string theory had any
    place in it. (Actually, it's been apparent for ages now that a great
    deal of the power that Larry's putting into Perl 6 arises from the
    unifications he's making, but that's an article for my weblog I think).

    http://groups.google.com/groups?selm=20031211134806.GA3771@stefp.dyndns.org

Acknowledgements, Apologies, Announcements
    For the duration of the panto season, Leon Brocard will be appearing in
    the role of Pumpking in a Perl 5 Porters summary near you.

    Still no link shortening. I appear to have managed to subtly screw my
    Perl installation and now I can't get the link shortening module
    installed. I shall try and make time to fix it this week.

    Unless someone beats me to it (please someone, beat me to it) I'm going
    to try and put together a 'state of play' post, summarizing the current
    state of the Perl 6 Object system with a little more background in it
    than Luke Palmer's excellent 'Vocabulary' post. All being well it'll be
    appearing in next week's summary.

    If you find these summaries useful or enjoyable, you might like to
    contribute to the Perl Foundation to help support the ongoing
    development of Perl. I also welcome feedback at p6summarizer@bofh.org.uk
    or at my website.

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

    http://www.bofh.org.uk:8080/ -- My website, Just a Summary


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About