The Perl 6 Summary for the week ending 20021103
    Welcome to the latest of the ongoing series of Perl 6 summaries, in
    which your arrogant moderator does battle with the forces of prolixity
    in a Brobdingnagian attempt to tame the tortuously tangled threads of
    Perl 6's design and development mailing lists. And if I keep up the
    purple prose at that rate it'll *still* be clearer than the tangle that
    is this week's perl6-language discussion.

    However, because it's customary, and because the language list scares
    me, we'll start with the comparatively tame perl6-internals.

  Fun with file formats
    Toward the end of last week, Rhys Weatherley had asked about being able
    to insert arbitrary chunks of metadata into parrot bytecode files. Dan
    ended up producing a `draft sketch' of the bytecode generation
    facilities and the ability to add arbitrary chunks of metadata was
    conspicuous by its absence. People didn't seem to be happy about this,
    lamenting a lack of flexibility, both in the overall file structure and
    in what one could stick into the bytecode. Dan mounted a sturdy defence,
    pointing out that we want `a file format that does what we need it
    to--present executable bytecode data to the interpreter--as fast as
    possible. Everything else is secondary to that.'

    Kv Org wondered if it would be a good idea to worry about sandbox issues
    in the bytecode format, but nothing came of that question. Well, not
    this week anyway.

    http://makeashorterlink.com/?S1F442C52

    http://makeashorterlink.com/?V20551C52

    http://makeashorterlink.com/?H21513C52

    http://makeashorterlink.com/?H22541C52

  Portable linking issues

    Andy Dougherty is having portability problems. He wants to portably
    compile and link 3 files and he wondered what was the best to get an
    early test compiled properly on all platforms. Help was supplied, the
    build was fixed, and the world remained safe for democracy. (Modulo a
    few local difficulties.)

    http://makeashorterlink.com/?Q23532C52

  Implicit stack direction probe
    Meanwhile, Jason Gloudon's patch to move the stack direction probe back
    to initialization time rather that compile time was offered. I'm
    assuming that Nicholas Clark's suggested speedup trick from last week
    was implemented as part of it, but I'm no great understander of C.

    http://makeashorterlink.com/?R54532C52

  Of MOPS and Microops
    There's been some discussion of granting a small number of Parrot
    registered 'most favoured' status. The idea being that a small number of
    registers would actually be held in global (possibly real register)
    variables, with the rest being accessed through via indirection through
    the interpreter. Apparently the JIT core already does some optimization
    along these lines, and Dan doesn't seem to be sure that doing it for the
    main interpreter would actually be much of win. Discussion continues.

    http://makeashorterlink.com/?L55521C52

  Very complete lexical scopes
    Jonathan Sillito has submitted a patch which `implements a very complete
    set of lexical scope semantics'. It looks pretty cool to my untutored
    eye. General response was positive, though Jürgen Bömmels did have a
    query about how to create a new scope.

    http://makeashorterlink.com/?W26514C52

  miniparrot, a first attempt
    If you've been paying attention to the Parrot build process, you'll be
    aware that it was always a goal to use a cut down variant of parrot
    itself to run the configuration tests. The plan is that this miniparrot
    should be buildable with nothing more than an ANSI compliant C compiler.
    Josh Wilmes thinks we're about ready to start building said miniparrot,
    and offered his first cut to the list. Response was positive, with
    quibbles, which is about what one would expect.

    http://makeashorterlink.com/?W37512C52

Meanwhile, over in perl6-language (or "The Horror! The Horror!")
    The dreaded `Operator Reshuffle' thread continues apace -- of the 450
    posts last week I'd say about 400 of 'em were discussing various aspects
    of this. Bear in mind too that the path of discussion could be described
    as helical (sort of like circular, but getting more and more wound up
    with each go 'round). There are at least two factions involved, roughly
    caricatured as `Simon Cozens vs. The Rest of the World'. Simon can be
    thought of as the voice of conservatism (or Reason, depending on whether
    you agree with him or not), generally arguing against stuff he considers
    massively ugly or confusing. Simon's allies vary depending on which
    issue he's discussing and his worries include:

    *   Perl 6 is going to be even harder to parse than Perl 5

    *   Unicode operators in the core language are Just Wrong. Lots of
        people agree with him on this.

    *   Superpositional operators will be too rare to justify giving them
        precious one character operators.

    This is, of course, a gross simplification of what's going on in the
    various operator threads, but it does cover a fair number of the issues
    that are arising in the attempt to get "^" back as exclusive or (which
    then frees "~" up to become string concatenate, which... ah, go read
    last week's summary, I already did this...)

    BTW, `Vectorizing' is the new `Hyperizing' (or did I do that last week?)

    Here's the various threads involved in the kerfuffle, along with Michael
    Lazzaro's utterly wonderful summaries of the current core operator list
    as he sees it.

    http://makeashorterlink.com/?R26F21E42 -- Op list, Take 3.

    http://makeashorterlink.com/?L28532C52 -- Take 4

    http://makeashorterlink.com/?B69511C52 -- Take 5

    http://makeashorterlink.com/?U1A561C52 -- Take 5a

    http://makeashorterlink.com/?U2B553C52 -- Take 5b

    http://makeashorterlink.com/?S5C542C52 -- Take 6

    http://makeashorterlink.com/?O2D522C52 -- Pointers to Unicode stuff

    http://makeashorterlink.com/?C5E522C52 -- Someone coming in late

    http://makeashorterlink.com/?L2F542C52 -- Questioning the value of
    infix superpositions

  Smalltalk type collection classes?
    One of the subthreads of the mammoth operator thread covered whether it
    might be a good idea to include a set of Collection classes in the style
    of the Smalltalk Collection hierarchy to the Perl 6 core dist.

    http://makeashorterlink.com/?H40652C52

  Persistence of superpositions
    Buddha Buck wondered how pervasive superpositions were, and for how long
    they would remain entangled. Damian thinks they should be all pervading
    and fully propagating. This thread didn't really stay very on topic...

    http://makeashorterlink.com/?K61613C52

  Proposal: Vector operators for Hashes
    Arcadi made some proposals about how to extend the concept of vector
    operators to Hashes as well as lists and arrays. Discussion ensued.
    People seem to like the idea of extending vector ops to cover hashes,
    but weren't necessarily sure that Arcadi's approach was the right one.
    'Adverbial' control of how the vector ops work was also discussed,
    though Larry gave the impression that he thought this might be a
    generalization too far...

    http://makeashorterlink.com/?K12623C52

  Plaintive whine about "for" syntax
    Dave Storrs really doesn't like the syntax of the `parallel streams'
    variant of "for":

        # This iterates over @a and @b in parallel

        for @a; @b -> $x is rw; $y { $x = $y[5] } 

    and he offered a list of suggestions, though I think more people
    disliked his alternatives (even among those who didn't like the current
    syntax) than liked 'em. Damian pointed out that a little finesse with
    the editor could be of some assistance:

        for @a      ; @b       
         -> $x is rw; $y { ... }

    Ed Peshko wondered what happened when you had a lot of parallel streams,
    and Damian obliged with:

        for  @a;  @b;  @c;  @d;  @e
         ->  $a_var1 is rw, $a_var2 is rw;
                  $b_var is rw;
                       $c_var is rw;
                            $d_var is rw;
                                 $e_var1 is rw, $e_var2 is rw 
        {
            ...
        }

    But this is a somewhat pathological case. Damian also mentioned that he
    and Larry had thought long and hard about whether or not to interleave
    sources and iterators before deciding on the current syntax.

    http://makeashorterlink.com/?W23612C52

    http://makeashorterlink.com/?Y54632C52

  Nondeterministic algorithms, flexops, and stuff
    Piers Cawley made heads hurt (his included) when he posted a question
    about using superpositions (aka flexops) to implement non deterministic
    algorithms. The particular example given was an algorithm to find a path
    between two nodes of an acyclic directed graph (lifted from a text on
    lisp). Jonathan Scott Duff thought the idea was 'neat'. For an encore,
    Piers redid the function without flexops, using a continuation based
    implementation of "choose" and "fail" (which hurts my head more than the
    superposition based version, frankly).

    http://makeashorterlink.com/?E55625C52

  Primitive Boolean type?
    Michael Lazzaro asked a tricky question, can a "bit" be undefined? If
    so, then it leads to the somewhat counterintuitive assumption that one
    would need two bits to store a single `bit'. Which is certainly odd.
    However, it turns out that native types like "bit", "int", etc cannot be
    undefined, so that's all right. This then branched off into a discussion
    of whether Perl 6 would have an explicit Boolean type. It won't. Unless
    Larry changes his mind.

    http://makeashorterlink.com/?J66625C52

  Labelled if blocks
    Last week, Steve Canfield wondered if Perl 6 would have labelled if
    blocks, which would allow one to jump out of arbitrary levels of nested
    ifs. It seems the answer is `no', but this led to a discussion of
    possible control statements which affect the flow of control in
    different sorts of blocks (subs, conditionals, loops, etc.). It's
    looking like we may end up with a "leave" statement. The other
    possibility would be to make return a method, allowing one to do:

        Loop.return($x)

    or whatever.

    http://makeashorterlink.com/?I17625C52

    http://makeashorterlink.com/?J28614C52

In Brief
    There was some discussion on the internals list about what functions
    need to have an interpreter argument. The basic rule appears to be `if
    it's going to allocate memory, it needs an interpreter'.

    Leopold Toetsch has rejigged the startup procedure so that we will
    always have a valid interpreter, making patches like the one that
    allowed for a NULL interpreter in "sprintf" unnecessary.

    Discussion of the Parrot Copyright/License changes was subdued,
    bordering on the nonexistent. Lets hope it stays as smooth.

    Leo Toetsch has been doing various refactorings of Parrot ops.

    There was discussion about how to generate the MD5 hashes for parrot
    bytecode `fingerprints'. The catch is that the Perl module Digest::MD5
    isn't guaranteed to be available on all Perl installations...

    Josh Wilmes did a massive 'indentation clean up' patch (2000+ line
    patch).

    Allison Randal has a fascinating article all about Perl 6 topics and
    topicalizers at http://makeashorterlink.com/?W59612C52, which is well
    worth the read.

    Paul Johnson had some thoughts about using properties on statements and
    the like as a way of providing metadata to things like code coverage
    tools.

    Leon Brocard is on Holiday.

Who's Who in Perl 6?
    Who are you?
        Mike Lazzaro. My wife and I own a company called Cognitivity
        (http://www.cognitivity.com/) in Burbank, California -- we met at
        Caltech, in Pasadena. We use Perl5 for our commercial e-learning
        software (online, customizable corporate training software). This is
        the first company we actually own, after working as
        consultants/contractors/employees for years at other places. It's
        great.

    What do you do for/with Perl 6?
        Originally, I just wanted to document Perl6's OO behaviours, but I
        soon found that to be impossible without documenting everything else
        first, so that's what I'm doing. I'm going piece-by-piece through
        all the early Apocalypses, attempting to fill in all the details and
        implications, which I am writing up in book-like form. As I get them
        done, I'll post them for review and feedback -- but before that,
        I'll have a lot of little questions and inconsistencies that I need
        to pin down.

        My feeling is, because I'm *not* on the design team, and I *don't*
        know all the thinking on how and why things are decided, I'm a good
        test person to write newbie-level documentation. If you can explain
        it to me, that's a pretty good indication that you and I can explain
        it to someone else. I think the disconnection between designer and
        documenter will be important, in this case, because we want Perl6 to
        be heavily adopted by mere mortals, not just experts.

    Where are you coming from?
        I've been using Perl since the 4 to 5 migration. Before that, I was
        mainly a C/C++ person. Before that, assembler. Perl5 is the best
        language I've ever used, but lately it's had some enterprise-level
        scalability problems that I need to solve, if I'm going to keep
        using it. Hence, I'm helping with Perl6.

    When do you think Perl 6 will be released?
        Sooner than people think... maybe a robust alpha within six months,
        I bet. People are worried about the length of time it's taking to
        get through the initial decisions, but most of the hard ones have
        already been done. It's going to pick up dramatically after the next
        two or three Apocalypses.

    Why are you doing this?
        Because I've had to work in five different languages over the past
        few years, and they all suck, each in their own special way.
        Horribly. If I'm going to continue programming as a career, I want
        to work in a language that, as much as possible, takes the grunt
        work out. I don't like re-solving the same design patterns umpteen
        times. That's something a computer should do for me.

        Why am I volunteering for documentation? Dunno, seemed like that
        effort was falling behind, since everyone keeps asking the same
        questions, over and over (like me, for example). And I can type
        fast. And I've got lots of experience at herding cats, which can't
        hurt...

    You have 5 words. Describe yourself.
        Programmer, Manager, Writer, Optimist, Cynic.

    Do you have anything to declare?
        I've grown to hate most technical terms, because nobody uses them to
        mean the same way. So I have an allergic reaction to descriptions
        that use a lot of big words to explain something that should be Much
        More Obvious. You'll find I post a lot of "please clarify" messages,
        to try to beat that out of people. :-) It doesn't *always* mean I'm
        dense, though sometimes it does. Sometimes it means "No -- really.
        Is that your final answer?"

Acknowledgements, requests and the third thing.
    This summary was once again brought to you from the comfort and security
    of a GNER Express train running between Newark and London, and from the
    greater comfort and security of my armchair at home. Production was
    abetted by industrial quantities of site tea (in the case of GNER) and
    Earl Grey China Moon tea (in the armchair).

    Proofreading was mostly done by Piers Cawley, so you can blame him if
    there are any outrageous typos.

    And, as the postamble usually goes, if you didn't like this summary,
    what are you doing still reading it? If you did like it, please consider
    one or both of the following options:

    * Send money to the Perl Foundation at
      http://donate.perl-foundation.org/ and help support the ongoing
      development of Perl 6.

    * Send feedback, flames, money and/or a tenchi-masa goban with a set of
      thickish yuki grade shell and slate stones in mulberry bowls to
      <mailto:pdcawley@;bofh.org.uk>.

    The fee paid for publication of these summaries on perl.com is paid
    directly to the Perl Foundation.



-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Reply via email to