Re: This week's summary
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: Parrot Calling Convention Confusion ... -- I thought they were exactly the same as an unprototyped call, but you invoke the return continuation (P1) instead of P0, the other registers are set up exactly as if you were making an unprototyped function call. Unfortunately the call and return conventions are *not* symmetric - yet. S. Fdocs/ppds/pdd03_calling_conventions.pod. Well, yeah, but Dan's said they will be. [ Gives Dan a Paddingtonesque Hard Stare ]
This week's summary
The Perl 6 Summary of the week ending 20031102 It's Monday morning, the croissants have been baked, the focaccia is glistening with all the extra virgin olive oil I poured on it as it left the oven and, in the airing cupboard, a raisin borodinsky slouches towards full proof (thought at the rate it's currently rising it'll probably be Tuesday before I can bake it off), what better time could there be to pause and write a summary? So, I'll kick off with perl6-internals because, well, it's on the summary checklist (which goes something like: 1. Wibble about the weather or something before; 2. Start with perl6-internals; 3. Continue with perl6-language if it saw any traffic; 4. Make announcements, suggest people give money to the Perl Foundation; 5. Make sure Leon Brocard gets a mention; 6. Aspell; 7. Mail PODs to http://perl.com and a text version to perl6-announce; 8. Profit!) NULL Px Proposal Right at the end of the previous week, Melvin Smith suggested having the initial 'empty' PMC registers all point at a global PMCNull which would throw an exception if you tried to invoke any of its methods. Which sounds weird, but it does mean that you get a real exception instead of a segfault, and exceptions are so much more trappable. Dan liked the idea. Melvin later posted a patch implementing the idea, which Leo Ttsch fixed up slightly an applied. http://xrl.us/2w8 http://xrl.us/2w9 Parrot Calling Convention Confusion Steve Fink is having problems using an unprototyped call to a prototyped function, which he thinks is a reasonable thing to do (and I think I agree with him; I can imagine cases where you have a function pointer or something where you don't know its exact prototype, but you do want to make a call to it so you'd be forced to make an unprototyped call.). Melvin Smith disagrees with him. Steve then went on to point out that he's still getting failures when the function is both declared and called in an unprototyped fashion. According to Leo, this is because unprototyped returns are neither defined nor implemented. Which is odd really -- I thought they were exactly the same as an unprototyped call, but you invoke the return continuation (P1) instead of P0, the other registers are set up exactly as if you were making an unprototyped function call. http://xrl.us/2xa A clash of symbols Arthur Bergman, Ponie stablemaster, popped up to point out that definitions like #define version obj.version (found in include/parrot/pobj.h if you're interested) did some scary things to Perl_utilize in the Perl 5 core. Steve Fink stuck his hand up to being the person who added the version field (which is apparently rather handy if you're debugging the Garbage Collection (GC) system. Leo fixed things by applying a s/version/pobj_version/g patch. http://xrl.us/2xb Storing external data in PMCs Arthur popped up again asking for help with implementing a Perl5LVALUE PMC. It turns out that the API doesn't quite support what he needs. After a certain amount of discussion of various options Arthur proposed a Parrot_PMC_attach_data(Parrot, PMC, *void) extension to the API. He didn't *quite* get what he wanted, but he got something very like it later in the week. I did like Arthur's reasons for starting the serious Ponie effort by working on Perl5LVALUEs though: [because] it is so obscure that it's hardly used anywhere and is limited to a few small areas in the core. http://xrl.us/2xc Screaming Pumpkins Ahoy! On Monday, Leo declared that yes, Melvin Smith's proposed Halloween 'Screaming Pumpkin' Parrot release would be happening. Various people promised extra goodies, and a few problems were sorted out with some platforms. Features were frozen on Wednesday and Parrot 0.0.13 Screaming Pumpkin was released upon a cowering world at 2003103114:11:46 precisely. For all the astonishing speed of the release cycle, there's a lot of good stuff to be had in the screaming pumpkin, check out Leo's announcement for details. http://xrl.us/2xd http://xrl.us/2xe -- Leo's announcement Header Dependencies Jrgen Bmmels wasn't entirely happy with the way Parrot's headers are set up. Apparently there are some nasty dependency (and crypto dependency) issues. He proposed fixing up the headers as much as possible to eliminate these issues. Dan and Leo thought it would be nice, but Dan thought there wouldn't be that much point in doing it as things would probably decay, and pretty much everything internal should just be using parrot.h, and everything external should be using extend.h or embed.h. http://xrl.us/2xf Tinderboxen Jrgen Bmmels triggered a quick bout of tinderbox fixing, as various different hardware
This week's Summary
The Perl 6 Summary of the week ending 20031026 Where does the time go? It seems like only yesterday that I was sat hiding Leon Brocard in the first letters of the first 11 body paragraphs of the last summary. Now, here I am, on the train, typing away in a desperate attempt to get this mailed out before Wednesday. Let's start with perl6-internals again. Object Freezing Whoever would have thought that freezing objects would be so controversial? Object freezing is when you take an object and generate a 'frozen' representation of it that can be used to make a copy of the original object. It's what Storable, Data::Dumper and YAML (to name three Perl 5 modules) all do more or less successfully. (Most of the time there's no problem, the tricky case is a composite object which involves a circular data structure. Consider this: Ring - A - B - C - D ^ | `--' (It's not *quite* a purely academic example, I can point to at least one text editor that uses a similar data structure). When you come to freeze your ring, you need some way of detecting the cycle and generating a finite representation that works. This isn't the only problem; thread safety is hard, for instance.) Dan's set some fairly stringent requirements on whatever mechanism is used for freezing. The most important/stringent is the requirement that (because freezing during object destruction will be a possibility) object traversal is not allowed to use additional memory for that traversal. Dan is convinced that we can do this using the Garbage Collector's object traversal system. Leo Ttsch is equally convinced that we can't. The resulting thread is rather meaty and hard to summarize without massive amounts of cut and paste so I'll just point you at the root message. The upshot is that we're doing it Dan's way; Glorious Leader continues to trump Pumpking Patchmonster. In another subthread there was a good deal of misunderstanding about XML declarations and parsing, which got cleared up surprisingly quickly. http://xrl.us/y99 Object Instantiation Dan had a moment of clarity and declared that the Parrot Way to instantiate an object in class Foo will be: new P5, .Foo All we need now is a working implementation. And, apparently, knowing what class a class is a member of might be handy, but Dan's punting on (ignoring the heck out of) that one. http://xrl.us/zaa A less controversial API addition In the middle of the discussion about object freezing, Dan popped up another thread to discuss how to invoke Sub/Method PMCs from C code. So Leo implemented Parrot_runops_fromc_args(), but he's not exactly happy about the name. Regardless of the name, having this implemented is rather spiffy. http://xrl.us/zab Old Big Problems before New Big Problems Melvin Smith popped up with a rant about the Parrot development effort's tendency to rush off to implement new stuff before making double sure about the 'old' stuff is actually complete and robust. To which I can only say Hear! Hear! Dan agreed, and threatened to give Melvin the pumpkin after Leo had finished with it. http://xrl.us/zac Class metadata for PIR/assembly files Donning his designer's cap again, Dan posted a rough spec for class metadata declarations in PIR and pasm files. It looks pretty decent to me. Melvin Smith made a few telling comments though, so it looks like Dan's post isn't quite the final word on the matter. http://xrl.us/zad Class creation in bytecode Mere moments after the metadata post, Dan went on to spec out the assembly language needed to support it. http://xrl.us/zae Open Patches Leo pointed everyone at http://xrl.us/zaf, the list of open Parrot patches and asked for a volunteer to go through and make sure that the list is in agreement with reality. http://xrl.us/zag Leo's notes on objects and classes Leo posted a list of thoughts about how classes and objects will work in Parrot and offered a suggestion about using OrderedHashes to handle things. http://xrl.us/zah Unifying vtables and method invocations Leo wondered if we should arrange things so that PMC vtables could be invoked in the same way as in methods on Parrot level objects are invoked. Dan answered that it won't be quite like that, but it will be close. (Yay! A reflective programmer writes). http://xrl.us/zai More fixed number assignments So, it turns out that adding PMC classes to the core breaks binary compatibility. Which needs fixing. Dan asked for volunteers. I'm afraid I don't know what fixing it would entail. http://xrl.us/zaj Plotz! Plotz (the Pol(l)y-Lingual Opcode Translation for the Z-machine) is Amir
This week's summary
The Perl 6 Summary of the week ending 20031019 Lumme! Another week, another summary. Every week (almost) we start with the perl6-internals list, so here goes. An Evil task for the interested Our Glorious Leader, Dan Sugalski, last week asked for volunteers to work on making ordered destruction work. (Ordered destruction is where the system tries to ensure that 'parent' objects get destroyed before any of their children). Jeff Clites announced that he'd got a partial implementation working. Neither Leo Ttsch nor Jrgen Bmmels were sure that the approach Jeff was taking would be the Right Thing in the long run, proposing instead a more general iterator mechanism. http://xrl.us/x8k Perl 6 Sub calling Bringing the perl6 compiler (in languages/ back to live, Steve Fink has committed a 'rather large' patch which implements a subset of the Apocalypse 6 subroutine signature rules. The implementation is apparently very ad hoc and shouldn't be regarded as the final word. But it looks like a very good start to me. http://xrl.us/x8l Website timeliness Responding to Matt Fowles' observation that the parrot website is rather behind the times, Robert Spier let slip that there would soon be a revised website that will be easy for everyone to send patches to, and which would be much easier to have multiple maintainers of different areas of the site. Of course, there are still a few 'technical chunks' that need to get finished before it's ready to unveil, but it's good to know that work continues in this area. Thanks Robert. http://xrl.us/x8m http://xrl.us/x8n -- Mike Scott's Parrot Wiki Dynamic oplibs Chances are, you've never really needed a fortytwo operator, or even a what_do_you_get_if_you_multiply_six_by_nine operator, and you certainly don't need them cluttering up the parrot core. Which is why Leo Ttsch has implemented those ops as a dynamically loadable ops library. Admittedly, you're highly unlikely to load this particular ops library, but the underpinning tools for dynamic loading of ops libraries are new and potentially very useful. Rather later in the week, once he'd got dynamic loading of ops working in all the runtime cores, Leo posted an 'intermediate summary' which explains how things work. http://xrl.us/x8o http://xrl.us/x8p Oplips, pmclibs, function libs Dan has been thinking about the problems that can arise with dynamic loading. One issue is that, if you have separate files for each PMC class, opcode library and parrot function library, things get unwieldy very quickly, and if you're not careful you'll exhaust the OS file descriptor pool. Which would be bad. So, he asked for a sanity check before going on to work out a scheme for bundling libraries into larger files. Leo agreed that Dan was talking sense, so I expect we'll be seeing some design in this area soon. http://xrl.us/x8q Instantiating objects It's been a busy week on the parrot front for Dan. On Wednesday he outlined his thinking on instantiating objects, with the aim of getting single inheritance objects up and running. This sparked a good deal of discussion, but nothing was actually agreed. http://xrl.us/x8r Redoing IMCC macros Surprisingly, Jrgen Bmmels opened up a can of worms when he redid IMCC's macro support to use a hash lookup instead of a linear search through an array. This sparked a good deal of discussion about the right scoping, which hash implementation to use, and whether IMCC should be closely entwined with the interpreter. http://xrl.us/x8s Fixed opcode numbering infrastructure Dan checked in a patch to fix opcode numbers for the core ops, deliberately breaking the JIT in the process. Leo wasn't happy. After a bit of back and forth, we now have fixed opcodes, but the implementation isn't quite what Dan originally did. There was also some discussion of how many opcodes really needed to be fixed; after all, in the presence of dynamically loaded oplibs, you can't nail every opcode down. Leo worried that dynamically loaded oplibs don't play well with JIT, and making it work would probably need a total rewrite of the JIT core, but Jrgen didn't think it was all that bad. http://xrl.us/x8t Applying the Pumpking Patch $ patch RESPONSIBLE_PARTIES 6c6 Release pumpking Steve Fink --- Release pumpking Leopold Toetsch In other words, Steve Fink has stepped down from the rle of Parrot Pumpking and handed the his mantle on to Leo Pumpking Patchmonster Ttsch. I'm sure I'm not alone in wishing to thank Steve for his sterling work as our release manager. Nor, I'm sure, am I alone in wondering where Leo finds the time.
This Week's Summary
The Perl 6 Summary of the week ending 20031012 Good afternoon readers. You find me sitting comfortably and tired after a vaguely frantic week involving large amounts of new (and huge) equipment, the delivery of a new Mini Cooper, and four days offline at a large format photography workshop (photos will be going online soonish, if you're interested). All of which hopefully goes some way to explaining the fact that I've only just started writing the summary at ten to four on Tuesday. We start (and finish) with the internals list. New PMC compiler Leo Ttsch isn't exactly happy with the current classes/pmc2c.pl PMC compiler. He outlined the drawbacks as he sees them, proposed a scheme for reimplementing it, and asked for comments. Dan said that so long as the resulting code is clearer than the current PMC compiler, Leo should go for it. So he did. http://xrl.us/w5m The Status of Language, Credit Where It's Due Melvin Smith has added a LANGUAGES.STATUS file in the languages/ subdirectory and asked for language authors to add summaries of the various language subdirectories to the file. Fresh from this success he added a CREDITS file for giving credit where it's due. Rumours of an entry reading N: Leon Brocard D: Running Joke are (currently) false. Later in the week, LANGUAGES.STATUS was extended to cover both the languages found in languages/ but any other languages that people were working on and making available outside the Parrot distribution for whatever reason. http://xrl.us/w5n http://xrl.us/w5o Binary MMD vtable functions are go Dan's solved an off by one error with multimethod dispatch and checked everything in, so now Parrot has working two argument multimethod dispatch. Hurrah! There's still lots it doesn't do mind, but getting started is always good. http://xrl.us/w5p Attacking the Unicode Monster Dan's searching for a Unicode Monster Wrangler. ICU is now building on enough platforms that the time has come to build an encoding and chartype library for it. Volunteers gratefully received. Jeff Clites and Michael Scott have both been poking at it a bit; hopefully they'll be able to put their heads together and emerge with something wonderful. http://xrl.us/w5q More NCI stuff Dan's been a busy boy this week. Parrot now comes with library/postgres.pasm, an interface to libpq (the C library that talks to Postgres). These NCI interface files are currently built by hand. Tim Bunce wondered if it might be possible to ExtUtils::XSBuilder to generate PASM from C header files instead of XS code. It was generally agreed that this would be a cool thing, but it's not been done yet. http://xrl.us/w5r http://www.postgresql.org/ The Parrot Stack and Z-Machine Amir Karger is working on getting his head 'round the Z-Machine (The virtual machine that runs Zork and the other Infocom games, amongst others) by writing code to translate Z-code into a Perl executable. He came up with a problem with saving and restoring the stack in order to save the game state. http://xrl.us/w5s References Leo's been giving the Reference PMC a hard look and, as a result, suggests adding a couple of handy ops, deref and ref (which finds the type of the thing the reference refers to) to use with them. Melvin Smith pointed out that, actually we only needed one of Leo's proposed ops. On the other hand, as Nicholas Clark pointed out, ref avoids the need to grab another PMC register, which may cause a register spill. On the gripping hand, Melvin argued that spillage is pretty rare with the number of registers Parrot has. http://xrl.us/w5t The program's ending! DESTROY everything! Jrgen Bmmels found a subtle bug where objects that had active destruction weren't having their destroy functions called correctly (at all) when parrot terminated. After a couple of goes round the 'this would be so much easier if we were all in the same room misunderstanding' loop, the Right Thing was settled upon and implemented. http://xrl.us/w5u An interesting task for the evil One of the things that Dan would really like to be able to promise with Parrot's GC is ordered destruction. Taking a leaf out of my lightning talk on complexity management, he noted that we just need to order the PMCs before destroying them, to make sure we don't call the destructor for a PMC before we destroy the things that depend on it and asked for volunteers to implement it. Dave Mitchell spoilt the understatement party by pointing out that, in the presence of circular dependencies things got a little more complicated (but not that much more complicated, Dan claims). Nobody's actually volunteered yet. http://xrl.us/w5v
This week's summary
The Perl 6 Summary of the week ending 20031005 Hello, good evening, and welcome from the teeming metropolis that is Newcastle/Gateshead, home of The Angel of the North, the Winky Eye Bridge, the ham and pease pudding stotty and freezing your extremities off on a Saturday night down the Bigg Market. This isn't (yet) a permanent move, but I'm here, my laptop is here, and there's a summary to write so let's get on with it shall we? As per always, we'll start with the internals list. Disassembler issues Marcus Thiesen had some problems getting the disassembler working (it was throwing segfaults, never a popular behaviour). Leo Ttsch (who else?) fixed it. http://xrl.us/v4g Pondering proper parameter passing The argument passing discussion continued. Leo suggested some changes to PDD03 for Dan to bear in mind when he rewrote it. (Something that was only going to take a few hours last week. Dan? I don't wish to nag you understand.) http://xrl.us/v4h Multimethod dispatch function installation issues Dan's in the process of writing the the Multi Method Dispatch (MMD) subsystem (at least the parts needed for operator overloading) and is scratching his head over what to do when a Multimethod is defined that references some other class that hasn't yet been loaded. He asked for the list's assistance in choosing one of two alternative approaches. The list refused to choose (no surprise there), and suggested a third option. http://xrl.us/v4i Library Loading an initialization sequence Dan is also working on what happens when PMCs are loaded -- how they are initialized etc -- so he posted a long message documenting his current thinking in this area. http://xrl.us/v4j MANIFEST failings, and how to overcome them There's been a few language checkins recently that have broken the MANIFEST, Robert Spier asked for a little help writing a MANIFEST checker which could be used as part of the CVS checkin which would make CVS refused to check anything in unless the MANIFEST was also up to date. Garrett Goebel came up with the goods and now, anyone attempting to check something in that invalidates the MANIFEST will be made to fix it before proceeding. Which is nice. http://xrl.us/v4k Testing Parrot IO (PIO) Last week, Michael Scott submitted a bunch of tests for the Parrot IO subsystem. This week, Jrgen Bmmels responded and he and Michael thrashed out some of the issues arising. http://xrl.us/v4l Waiting for the great renaming Leo Ttsch and others are working on getting things ready for when everything gets moved around and IMCC starts getting built as the one true parrot. http://xrl.us/v4m LVALUE casts considered scary Andy Dougherty found a problem building Parrot with Sun's Workshop compiler, which doesn't like having casts as lvalues. Leo proposed a (mistyped fix) and then ended up implementing a macro, LVALUE_CAST(type, value) to do the job reliably. So, if you find yourself wanting to use a cast as an lvalue when working on Parrot, use LVALUE_CAST instead. http://xrl.us/v4n Parrot on AIX Adam Thomason has taken on the task of getting Parrot to build on an IBM RS/6000 running AIX 4.3 with VisualAge C 6. He submitted a patch which fixes most things, but there's still one failing test (something to do with negative zero). His big patch was applied, and there's now a little debate about whether -0 should be a valid value. Later in the week, Adam tracked down what was causing the -0s. http://xrl.us/v4o Parrot gets Perl regular expressions Actually, Parrot gets pcre.imc: Leo Ttsch has wrapped libpcre, the Perl Compatible Regular Expression library that almost every language out there (except Perl of course) uses for its regexes. Leo thinks it might be useful for bootstrapping Perl6 rules. Dan doesn't want to have PCRE in core, or for it to be required for any part of building parrot, so the wrapper will be available in our current 'catch all' directory for such things, runtime/. http://xrl.us/v4p Parrot on Itanium Aldo Calpini is busy bringing parrot up on an Itanium box. It's not quite there yet, but it's getting there. Thanks Aldo. http://xrl.us/v4q The beginnings of an extension mechanism Dan's checked in the first part of the extension code for parrot, which lives in extend.c and which will be documented in docs/extend.pod. For now, Dan's post is the only extant documentation. http://xrl.us/v4r Safe mode for Parrot -- Call For Volunteers Dan reckons it's time to start on getting a safe mode for Parrot, which will (eventually) need a lot doing. However, the initial bit is thought to be relatively simple. Dan asked for a a volunteer with enough appropriately shaped tuits to
Re: The Block Returns
Dan Sugalski [EMAIL PROTECTED] writes: On Thu, 2 Oct 2003, Mark A. Biggar wrote: Austin Hastings wrote: But that imposes Ceval()/C pretty frequently. Better to provide some lower-level hackish way to agglutinate Blocks. Isn't this one of the prime examples of why CPS is being use, it allows for Tail Recursion Optimization. With TRO all your worries about overhead do to the wrap go away. This isn't why CPS is being used under the hood. (Nothing in perl 6 propmted CPS) I wouldn't necessarily count on being able to do tail calls here either, as they potentially alter the semantics, or at least the introspectable environment, of the program as they make frames go away. I'm vaguely hoping that modules will be able to declare that they don't need to access a 'strict' caller and that they'll be happy with a return from caller that skips any tail calls. Then, if the Perl 6 compiler sees that all modules in play have declared themselves in this fashion it'll use optimized tail calls. However, thinking about that I'm not entirely sure how it could be done with a single pass compiler.
Re: The Block Returns
Dan Sugalski [EMAIL PROTECTED] writes: At 11:55 PM +0100 10/3/03, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: On Thu, 2 Oct 2003, Mark A. Biggar wrote: Austin Hastings wrote: But that imposes Ceval()/C pretty frequently. Better to provide some lower-level hackish way to agglutinate Blocks. Isn't this one of the prime examples of why CPS is being use, it allows for Tail Recursion Optimization. With TRO all your worries about overhead do to the wrap go away. This isn't why CPS is being used under the hood. (Nothing in perl 6 propmted CPS) I wouldn't necessarily count on being able to do tail calls here either, as they potentially alter the semantics, or at least the introspectable environment, of the program as they make frames go away. I'm vaguely hoping that modules will be able to declare that they don't need to access a 'strict' caller and that they'll be happy with a return from caller that skips any tail calls. Then, if the Perl 6 compiler sees that all modules in play have declared themselves in this fashion it'll use optimized tail calls. However, thinking about that I'm not entirely sure how it could be done with a single pass compiler. I think it's reasonable to allow you to mark your subs as being able to be tail-called out of. Subs with no lexical variables should be safe to call out of as well, though that's a bit dodgier. OTOH, it's not like too many folks walk up their call chain. Actually, that makes a good deal more sense than my suggestion. As for hook functions, they probably want to hide themselves from Ccaller anyway, or hooking a single function in a call chain could cause introspective programs to fall over.
This week's summary
The Perl 6 Summary of the week ending 20030928
This week, on perl6-internals, stuff was said, code was written, Leo
Tötsch was the patchmonster, life got some colour, Amir Karger needs to
work harder if he wants to be mentioned in the summary again, Dan
Sugalski was our glorious leader.
Meanwhile, on perl6-language, Larry's back (yay!), Austin Hastings'
front.
If you've enjoyed this summary please send lawyers, guns and money to...
Ah heck! Try as I might, I can't get away with that can I? Here's the
real thing, starting with perl6-internals
parrot -t gets fixed
Will Coleda had some problems that parrot -t didn't seem to solve.
This prompted Leo to take a look at the -t behaviour, which, whilst
not actually *leaking* memory, nevertheless used an awful lot of it. So
Leo fixed things up and posted an explanation of what got fixed. It
looks to me as if said explanation might come in handy for anyone
wanting to know how to play nice with the garbage collector. (The
essential rule seems to be Whatever you do, don't turn off garbage
collection, you might have to jump through a few extra hoops when it's
on, but trust us, it's worth it.)
http://xrl.us/uxk
Pondering argument passing
The prototyped and unprototyped parameter passing powwow perpetuated
itself this week. It was decided/reiterated that all flattening happens
in the caller and all binding happens in the callee. Steve Fink and Leo
finally managed to get onto the same wavelength. Dan emphasised that
passing everything in a PerlArray is the Wrong Thing. Parrot acquired a
setp Ix, Py op, which does indirect register addressing.
Scary thought of the week: mutable default values.
http://xrl.us/uxl
Trig functions for vtables
Dan started collecting a list of trig functions to hang off PMCs. After
an initial bit of quibbling about whether trig functions were really
necessary, Leo Tötsch pointed out that they would be reached via a
secondary vtable, akin to doing $obj-{vtable}{trig_funcs}{sin} (but
not implemented in Perl.)
http://xrl.us/uxm
All hands to the pumps!
Leo Tötsch has been running the parrot test suite and looking for memory
leaks. Things are not looking good. It looks like we'll be seeing a
bunch of patches to patch the leaks soon. At least, I hope will will.
http://xrl.us/uxn
Notes from the Captain
Dan has been thinking hard about stuff. In particular, he's been
thinking about namespaces and calling/return conventions. He's still
undecided about how we're going to handle namespaces. The Calling/return
conventions however have been settled (but not written up formally yet).
Essentially, calling a subroutine and invoking a return continuation are
pretty much indistinguishable, so returning a bunch of values will use
the same mechanism as passing in a bunch of parameters.
http://xrl.us/uxo
http://xrl.us/uxp
Parrot::DWIM
Leo Tötsch is a scary man. 'Inspired' by Damian Conway's Acme::DWIM
module, he's perpetrated Parrot::DWIM. You're better off not knowing.
Honest.
http://xrl.us/uxq
Loading up bytecode segments
Now that we have dynamically loaded bytecode segments, Dan specified how
they should be auto execed on loading (for running set up code etc). Leo
and Dan had a short discussion about whether Dan's spec was the Right
Spec, the two proposals were deemed equivalent, so Dan's spec was the
one that gets implemented.
http://xrl.us/uxr
Another trivial language
Marcus Thiesen announced that he had ported another language to Parrot:
URM -- 'Universal Register Machine' which is a teaching language used in
German universities.
http://xrl.us/uxs
Curses!
Dan's wrapped ncurses in parrot using NCI and used that to redo
examples/assembly/life.pasm (which was originally written by Dan, but is
often misattributed to Leon Brocard) as
examples/assembly/ncurses_life.pasm, adding colorized goodness.
http://xrl.us/uxt
Lightweight Languages 2003 CFP
The Lightweight Languages conference LL3 has a Call For Papers out now.
Dan posted it to the list.
http://xrl.us/uxu
Meanwhile, in perl6-language
Larry Wall is in the house
Larry popped up on the list for the first time in ages, answering
questions about macro arguments and autovivification.
http://xrl.us/uxv
http://xrl.us/uxv
Pondering parametrized operators
Austin Hastings wondered about making parametrized operators. The
example he gave was an infix version of strncmp. I can't see what's
wrong with doing strncmp $this, $that, cmplen = 4, but Austin
proposes a scheme where one could write Dough eqn(4) Douglas and
have it return true. Various other possibilities were discussed.
http://xrl.us/uxw
Acknowledgements, Announcements, Apologies
Sorry it's late.
This week's summary
The Perl 6 Summary of the week ending 20030921
Deadlines, I love the sound they make as they fly past.
Those of you who receive this summary via mail may have noticed that
this summary is a little late, with any luck it will make up for its
tardiness by being inaccurate and badly written as well.
I'm going to reinstitute the tradition of starting with the internals
list this week, so without further ado:
Pondering argument passing
Steve Fink pondered passing parameters properly, with a prototyped Perl
6 example. Perl 5 certainly, and Perl 6 possibly, allow you to ignore
any function prototype by calling the function like f(1,2). Steve had
concerns about what to do in the presence of 'splatted' argument lists.
(Consider
sub foo(@a, $b) {...}
@generated_arglist = ([1,2,3], 2);
Calling foo(@generated_arglist) will throw an error, because the
function is expecting an array followed by a scalar. However, you can
get around that by using the * (splat) operator, which tells Perl to
wait until runtime and then treat @generated_arglist as if it were a
list of arguments to the function, and check its contents against foo's
parameter list. In Perl 5, if you had a prototyped function sub foo(@$)
{...} you would work around the problem by calling it as
foo(@generated_arglist), but I have digressed a long way already.)
I'm not entirely sure I got what this thread was about. I've just had a
chat with Dan about it on IRC, and I think I'm a little wiser, but the
thread that arose from Steve's post gave me the impression of people
talking past each other a little.
http://xrl.us/t4x
Feature Freeze for 0.0.11
Steve Fink announced that Parrot was feature frozen in the wee small
hours of Monday morning (at least it was Monday morning if you live in
GMT; it was still Sunday if you're in Steve's timezone). Everyone set
about tidying things up, nailing bugs and generally getting Parrot's
house in order for a public release.
http://xrl.us/t4y
Some Parrot people are disgustingly young
In a move calculated to annoy your summarizer, Dan Sugalski pointed out
that Piers is now twice the age of Brent Dax. I thought it was bad
enough back when I was working with Leon Brocard, who is also
disgustingly young, but at least he was old enough to drink beer and
vote. (It's very important that you do the former before the latter
apparently).
Parrot musical chairs
Some time after the next Parrot release everything's going to get moved
around in the parrot directory tree so things make a little more sense.
Dan laid out his vision. Leo liked it. Looks like it'll be happening.
http://xrl.us/t4z
Sorting out dependencies
Andy Dougherty has been shaking the parrot tree with different versions
of Perl and found some incompatibilities between the jako and perl6
languages and Perl 5.005. A few patches and skipped tests solved that.
http://xrl.us/t42
Attaching Debuggers
Nicholas Clark passed on the concerns of a nameless interlocutor who had
expressed a desire for a Perl debugger which could attach itself to a
troubled running process. This is, after all, something that gdb can
already do for C programs. Dan punted on details, but thinks it should
be possible to implement. It's definitely post 0.0.11 though. Michal
Wallace pointed out that Python is very 'hooky' and supports this.
http://xrl.us/t43
Various fixes
Because most of the week was spent under a feature freeze, the vast
majority of this week's threads have been the kind of short lived
Patch! Applied! bugfix threads. Suffice to say, lots of bugs and
niggles got stamped on by the usual heroes plus a few more heroes for
good measure.
Parrot 0.0.11 Doubloon Released
Parrot 0.0.11 got released on Saturday, narrowly missing International
Talk Like a Pirate Day. It was almost immediately superceded by version
0.0.11.1 which fixed a slight oversight and introduced a new bug.
Breaking my 'midnight GMT cutoff' rule, the latest version, released is
actually 0.0.11.2, which deals with the fact that Parrot isn't set up to
handle 4 part version numbers.
http://xrl.us/t44
http://xrl.us/t45 -- The We really can't handle these version
numbers release
Meanwhile, in perl6-language
Disposable optimization
The increasingly poorly named Next Apocalypse thread went off into
discussing the possibilities of disposable optimizations that could get
thrown out when invariants that they depend on no longer hold. This
rapidly developed into serious blue sky stuff that I can't help but
think is a little premature. Fascinating certainly, but I would like a
working language before we got off making it do all sorts of clever
optimization stuff.
http://xrl.us/t46
Re: This week's summary
Leopold Toetsch [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] wrote: ... spending the morning of your 36th birthday Happy birthday to you and us. Thanks.
Re: Next Apocalypse
Luke Palmer [EMAIL PROTECTED] writes:
Also, the standard library, however large or small that will be, will
definitely be mutable at runtime. There'll be none of that Java you
can't subclass String, because we think you shouldn't crap.
Great. But will it also be possible to add methods (or modify them)
to an existing class at runtime? You only have to look at a Smalltalk
image to see packages adding helper methods to Object and the like
(better to add a do nothing method to Object that find yourself doing
C$thing.do_that if $thing.can('do_that') all the time...)
Re: Macro arguments themselves
Luke Palmer [EMAIL PROTECTED] writes: Alex Burr writes: In theory you could write one as a perl6 macro, although it would be more convenient if there was someway of obtaining the syntax tree of a previously defined function other than quoting it (unless I've missed that?). There is a large class of cool optimizations possible when you combine notifications with storing the syntax tree at runtime, so I think it will be possible to get the syntax tree of a previously defined function. Probably just a method on Code objects. I'll be very disappointed if you can't get the syntax tree at runtime, though I have the feeling that it might require a compilation switch of some sort.
Re: Macro arguments themselves
Austin Hastings [EMAIL PROTECTED] writes: --- Luke Palmer [EMAIL PROTECTED] wrote: Alex Burr writes: But I confidently predict that no-one with write a useful partial evaluator for perl6. The language is simply too big. Then again, there are some very talented people with a lot of free time in the Perl community; I wouldn't count it out. That looked to me like a Damian troll, hoping that DC would pop up and say, Oh, no. It can be done in six lines of P6. See: ... No fair trolling someone when he's on holiday.
Re: Next Apocalypse
Luke Palmer [EMAIL PROTECTED] writes:
Piers Cawley writes:
Luke Palmer [EMAIL PROTECTED] writes:
Also, the standard library, however large or small that will be, will
definitely be mutable at runtime. There'll be none of that Java you
can't subclass String, because we think you shouldn't crap.
Great. But will it also be possible to add methods (or modify them)
to an existing class at runtime?
Parrot supports it, so I don't see why Perl wouldn't.
You only have to look at a Smalltalk image to see packages adding
helper methods to Object and the like (better to add a do nothing
method to Object that find yourself doing C$thing.do_that if
$thing.can('do_that') all the time...)
Agreed completely. Plus, there are some cool things you can do by
mutating methods of Object, like implementing auto-rollback variables.
(A6 Clet foo() behavior).
Shhh!
Re: Next Apocalypse
Simon Cozens [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Piers Cawley) writes: Great. But will it also be possible to add methods (or modify them) to an existing class at runtime? You only have to look at a Smalltalk image to see packages adding helper methods to Object and the like People get upset when CPAN authors add stuff to UNIVERSAL:: :) More fool people.
Re: Next Apocalypse
Austin Hastings [EMAIL PROTECTED] writes: There's a growing body of interesting work on what's essentially disposable or partially-useful optimizations. Given the dynamic nature of most of the languages we care about for parrot, throwaway optimizations make a lot of sense--we can build optimized versions of functions for the current structure, and redo them if the structure changes. This isn't entirely an easy task, however, since you can't throw away or redo a function/method/sub/whatever that you're already in somewhere in the call-chain, which means any optimizations will have to be either checked at runtime or undoable when code is in the middle of them. Why is this? Given that threads are present, and given the continuation based nature of the interpreter, I assume that code blocks can be closured. So why not allocate JITed methods on the heap and manage them as first class closures, so that the stackref will hold them until the stack exits? Ooh, cunning.
This week's summary
The Perl 6 Summary for the week ending 20030914 Welcome to this week's Perl 6 Summary. And what better way could there be of spending the morning of your 36th birthday than by reading through a bunch of old messages in a couple of mailing lists and boiling them down into a summary? Hmm... you have a point. Still, I'd just spend the day feeling slightly guilty if I did that. And I'd spend more than just the day feeling guilty if I did that, but thanks for the offer. Ahem. Continuing the thread of So little was said we might as well get it over with and move onto the meat of the week, we'll start this week with the language list. Dispatch on context Piers Cawley wondered about doing multiple dispatch based on context and came up with a scheme which involved wrapping multimethods in a simple method that would 'reify' context so that it could be used as a multimethod argument. Luke Palmer came up with a better notation for handling class arguments to multimethods than Piers's suggestion... http://xrl.us/tgd Next Apocalypse In a transparent (and successful) attempt to generate some traffic on the language list, Jonathan Scott Duff wondered when the next Apocalypse was due. (If anyone's reading this who isn't up to speed on the Perl 6 design process, Apocalypses are Larry's design documents which describe the syntax and semantics of Perl 6. In theory they reflect the structure of *Programming Perl*, but the order may vary slightly). Dan Sugalski popped up with an answer Not for a while. The thing is, the next Apocalypse is objects, and judging by the amount of time it took Dan to get object internals finalized (hah!) over on perl6-internals, getting objects right in Perl 6 is going to take a time. Dan thought that Damian may well get Exegesis 7, formats, out sooner. (Apocalypse 7 boiled down to the following: See Damian). However, Damian is currently on holiday for the first time in too long, Dan hoped (and I agree) that Damian wouldn't answer for a few weeks. There was general agreement that getting objects right deserved as much time as it needed. Luke Palmer dropped a few hints though (and made your summarizer happy by noting that 'the standard library will definitely be mutable at runtime'. http://xrl.us/tge Macro arguments themselves Alex Burr responded to a question about Macro arguments that Luke Palmer posed on the second of August (you have to love the dizzying pace of life on perl6-language). Alex suggested the partial evaluation might be handy but predicted that nobody will write a useful partial evaluator for Perl 6 as the language is 'simply too big'. The thread went on to discuss ways of getting at syntax trees from precompiled code and whether or not Alex had been serious in his prediction. http://xrl.us/tgf Meanwhile, in perl6-internals Of AST And YAL At the back end of last week, Leo Tötsch announced that he was looking into the AST (Abstract Syntax Tree) interface to Parrot by implementing parts of Yet Another Language (YAL). What's been done so far looks remarkably impressive, and Leo wondered whether to commit the changes. He noted that the work was currently totally standalone and could be distributed as a tar file instead. Michal Wallace liked it, noting that he'd like to merge in all the pirate code generation stuff. James Michal DuPont suggested using the redland RDF API, and representing the syntax trees with RDF. Not being a fan of XML (Who is?) Leo was unconvinced, worrying that he wasn't keen on having an external library in such a central place in Parrot. James pointed out that RDF isn't necessarily XML, and that the redland API wasn't quite the same as the redland library. Meanwhile, Leo put a YAL distribution up on his web page. http://xrl.us/tgg http://toetsch.at/yal/ vtable-dump The How to do serialization right thread rumbled on. Threads continue to make things hard. http://xrl.us/tgh Parrot Z-Machine Amir Karger continued his investigation of what would be needed to get Parrot emulating the Z-machine. Later in the week he announced that he was about to start coding. Go Amir! http://xrl.us/tgi Moving IMCC Everyone admits that languages/imcc is the wrong place for something as central to Parrot as IMCC. Leo wants to make a top-level imcc directory. Dan wants to move the current top-level C code to a core directory and move the IMCC stuff into that directory as well (without an imcc subdirectory). Quite what the Right Thing is hasn't yet been decided so IMCC remains in the wrong place. Robert Spier thought that we should wait 'til after the next Parrot release anyway. http://xrl.us/tgj Leon Brocard Speaks! Leo Tötsch noted
Dispatch on context
So, I was wondering about how to do multidispatch based on the
context in which something is called, which leads me to wonder if
there's going to be a way of reifying calling context so I could
write:
method whatever($arg1, $arg2)
{ my multi whatever ($self, Scalar $context:
$arg1, $arg2) { ... }
my multi whatever ($self, Array $context:
$arg1, $arg2) { ... }
whatever($_, want(), $arg1, $arg2) }
Just wondering.
This week's summary
The Perl 6 Summary for the week ending 20030907 Welcome to the last Perl 6 summary of my 35th year. Next week's summary will (in theory) be written on my 36th birthday (a year of being square, so no change there then). I'll give you fair warning that it might be late, though it probably won't. Newcastle University has, in its infinite wisdom decided to have its students enrolling on that day so Gill will be off up to Newcastle to register leaving me at home with nothing to do but keep the house tidy in case a buyer wants to come and look at it, so sitting in one place with a laptop writing a summary seems like a good strategy. As last week's 'world turned upside down' approach of starting with perl6-language was such a success we'll do the same again this week. The language list gets some traffic shock! Jonadab the Unsightly One replied to Abhijit A. Mahabal's message from the first of August concerning junctions and set theory. http://xrl.us/sm6 Meanwhile, on perl6-internals Serialization is Hard! Last week's discussion of serialization sparked off by Leopold Tötsch's suggestion of a vtable-dump mode *really* got into its stride this week. It turns out that getting this right is a Hard Problem in the presence of threads. Dan's plan for serialization involves using the GC's object graph walker to work out what to serialize when you tell Parrot to dump a PMC. Leo worried that this would essentially stop the garbage collector running during serialization which could be tricky if the serialization process tried to allocate any memory. Dan and Leo ended up in a protracted, but polite, argument about details. At about 45 entries into the thread, Leo produced a summary of the various options and issues associated with them. http://xrl.us/sm7 http://xrl.us/sm8 -- Leo's summary File Spec Leo Tötsch commented on Vladimir Lipskiy's implementation of a File::Spec like tool for Parrot. (File::Spec is Perl's tool for dealing with filenames and paths in a platform independent fashion). Michael Schwern pointed at Ken Williams' excellent Path::Class module which gives you actual file and directory objects which he reckons has a much better interface than File::Spec. http://xrl.us/sm9 Notifications Gordon Henriksen posted a great discussion of using notifications to implement weakrefs. Rather wonderfully he used the notification system itself as a good example of why dying object notifications were a good idea. http://xrl.us/sna Parrot 100% GNU .NET Danger. Here be Licensing Issues. I don't do Licensing issues. The main thrust of the discussion was what kind of library would ship with Parrot. Dan's answer is worth reading, if only for the That's a swamp I don't have enough castles for line. http://xrl.us/snb http://xrl.us/snc -- Dan's take on the library You are in a maze of keyed variants, all similar This seems to have been a week in which Dan and Leo spent a good deal of their time politely disagreeing with each other. This time they were disagreeing about the need for all the keyed variants of Parrot's opcodes. Dan outlined the reasoning behind demanding keyed variants of every operation in a PMC's vtable (Executive summary: A combination of speed and space reasons). Leo still doesn't seem convinced but, for now, Pumpking trumps Patch monster. http://xrl.us/snd Parrot Z-machine Amir Karger's post from last week about implementing the Z-machine (the VM that runs Infocom and other text adventures) got de-Warnocked this week. Nicholas Clark explained that doing the Z-machine 'properly' would require some bits of Parrot that weren't actually there yet, specifically dynamic opcode loading and dynamic bytecode conversion. This led to a discussion of how to get those things implemented. http://xrl.us/rtr PIO Questions Benjamin Goldberg posted a long list of issues and suggestions about handling character type and encoding on Parrot IO objects. Jürgen Bömels said that there were indeed issues, that he'd be dealing with them as tuits allowed and that patches are welcome. http://xrl.us/sne How to dynamically add a method to a class Joseph Ryan had asked how to add a method to a class at runtime. Dan explained what was supposed to happen (each class has a 'backing namespace' associated with it which contained all the class's methods). Leo asked for a few details about how that would look in Parrot assembly. A little later, Joseph reported what appeared to be a bug in the way IMCC handles .namespace. It appears that IMCC is working as designed, the question is whether the design is doing the Right Thing. http://xrl.us/snf http://xrl.us/sng Proposed amendment to chartype
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030831 Welcome to this week's Perl 6 summary. This week, for one week only I'm going to break with a long established summary tradition. No, that doesn't mean I won't be mentioning Leon Brocard this week. Nope, this week we're going to start by discussing what's been said on the perl6-language list this week. Now that's out of the way, we'll continue with a summary of the internals list. Continuation Passing is becoming the One True Calling Style Jos Visser had some code that broke in an interesting fashion when find_lex through an exception, so he asked the list about it. Leo Tötsch explained that exceptions and old style subs don't play at all well together. It seems to me that the total and utter deprecation of subs using the old style calling conventions is not far distant. http://xrl.us/rtk Embedding Parrot in Perl Luke Palmer has started to learn XS in the service of his project to embed Parrot in Perl. Unsurprisingly, he had a few questions. He got a few answers. http://xrl.us/rtl Implementing ISA Leo Tötsch has implemented isa. The unfashionably lowercased chromatic argued that what Leo had implemented should actually be called does. Chris Dutton thought does should be an alias for has. Piers Cawley thinks he might be missing something. http://xrl.us/rtm More on constant PMCs and classes Leo Tötsch's RFC on constant PMCs and classes from last week continued to attract comments about possible interfaces and implementations. http://xrl.us/qxk A miscellany of newbie questions James Michael DuPont a bunch of questions and suggestions about bytecode emission, the JIT and about possibly extracting the Parrot object system into a separate library. Leo supplied answers. http://xrl.us/rtn What the heck is active data? Dan clarified what he'd meant when he talked about Active Data. His one sentence definition being 'Active Data is data that takes some active role in its use -- reading, writing, modifying, deleting or using in some activity'. The consequences of such data are far reaching; even if your code has no active data in it, Dan points out that you still have to take the possibility into account, or solve the halting problem. Benjamin Goldberg seemed to think that you didn't need to solve the halting problem, you could just add scads of metadata to everything and do dataflow analysis at compile time. I look forward with interest to his implementation. Matt Fowles wondered why active data necessitated keyed variants of all the ops, asking instead why we couldn't have a prepkeyed op to return an appropriate specialized PMC to use in the next op. Dan agreed that such an approach was possible, but not necessarily very efficient. Leo Tötsch disagreed with him though. TOGoS wondered if this meant that we wouldn't know whether set Px, Py did binding or morphing until runtime. (It doesn't. set always simply copies a pointer). In an IRC conversation with Dan we realised that some of this confusion arises from the fact that set_string and friends behave as if they were called assign_string; to get the expected set_string semantics you'd have to do: new Px, .PerlUndef set_string Px, some string Hopefully this is going to get fixed. http://xrl.us/rto Mission haiku Nicholas Clark To make some kind of mark Committed haiku. Don't you. Yes, I know that's not a haiku. It's a Clerihew. I suggest that anyone else who feels tempted to perpetrate verse on list restrict themselves to a sestina or a villanelle, or maybe a sonnet. I also note that POD is a lousy format for setting poetry in. http://xrl.us/rtp Jürgen gets De-Warnocked Jürgen Bömmels had been caught on the horns of Warnock's Dilemma over a patch he submitted a while back. It turns out that he'd been Warnocked in part because both Leo and Dan thought he already had commit rights. So that got fixed. Welcome to the ranks of Parrot committers Jürgen, you've deserved it for a while. http://xrl.us/rtq Parrot Z-machine New face Amir Karger wants to write the Parrot Z-machine implementation and had a few questions about stuff. So far he's been Warnocked. http://xrl.us/rtr Notifications Dan described how Parrot's notification system would work, and what that means for weak references. Michael Schwern thought the outlined notification system would also be awfully useful for debugger watch expressions. Tim Bunce worried about some edge cases. http://xrl.us/rts MSVC++ complaints Vladimir Lipskiy (who's been doing some stellar work recently on various build issues amongst other things) found some problems trying to build Parrot with MSVC
The Perl 6 Summary
The Perl 6 Summary for the week ending 20030824 Another week, another Perl 6 summary. I'm running late writing this and I don't care because I spent the bank holiday weekend at a folk festival and didn't get back 'til Monday evening. Predictably enough, we'll start with the shenanigans in perl6-internals. Timely Destruction: Luke Palmer's Scheme The timely destruction meme just won't go away. This week Luke Palmer suggested a possible improvement to Parrot's current scheme (Parrot keeps a counter of 'eager' objects needing timely destruction, and a language's compiler emits conditional sweep opcodes at appropriate points. In Perl's case, for instance, the conditional sweeps would be triggered on scope exit, other languages may have different requirements). Luke's scheme involves terminating the DOD (Dead Object Detection) run if every outstanding eager object is found alive at any point in the run. For added performance, there would also be a 'high priority' flag on all objects. The idea is that the high priority flag could be used to ensure that, during a sweep, the paths through the object group that are likely to lead to an eager object get checked first, hopefully ensuring that the sweep gets terminated as quickly as possible in the case where no eager objects need to be finalized. The proposal was discussed, but I don't think anyone has gone so far as to implement anything based on the scheme. This discussion led Klaas-Jan Stol to ask what the heck timely destruction was, anyway. This sparked a longish discussion, covering what timely destruction is all about, why you'd want it, and why having it could be problematic. http://xrl.us/pu7 http://xrl.us/qxf The String API Benjamin Goldberg is concerned with 'a number of shortcomings in the [string] API' and outlined the problems he sees, along with some proposed improvements. Luke Palmer generally liked the ideas, but Leo Tötsch had concerns about some of Benjamin's proposals. The discussion that ensued got fairly technical. (One of these days I'm actually going to go and get my head properly around the details of the various encodings and charactersets. And then I'll probably go insane.) Dan also thought that Benjamin was confusing language level strings with low-level strings, and that this was a Bad Thing. He outlined the difference between language level (PMC) and low-level (Parrot S register) strings, and explained what each was appropriate for. http://xrl.us/qxg Making the Perl 6 Compiler use Continuation Passing Style Allison Randal sent in a patch to switch languages/perl6 -- Parrot's (incomplete) Perl 6 Compiler -- over to using Continuation Passing Style, which is a useful step in the right direction. Leo applied it. http://xrl.us/qxh Fun with search_lex Jos Visser (who in an earlier post confided that he's working on writing a parrot compiler back end for his personal 'computer language personality disorder: Comal', and that he does this for 'therapeutical value') wants to generate some parrot code that is capable of searching the lexical pads for the existence of a lexical. His current code tries to look up a lexical and catches the exception when the lexical doesn't exist, but this is apparently very slow. So, he proposes an op, search_lex which, instead of throwing an exception, returns a null PMC if the lexical is not found. Leo Tötsch wasn't convinced by the need for the op, but he is looking into why the exception handling route is so slow (indeed, he seems to have found the reason, now he's trying to fix it). http://xrl.us/qxi Syntax Highlighting Inspired by Luke Palmer's cunning, core.ops parsing vim syntax highlighter, Andy Bussey wrote something similar for the KDE Kate editor. Now, if someone could modify pasm.el, the Emacs highlighting mode to use the autogeneration trick too... http://xrl.us/qxj RFC: Constant PMCs and Classes Leo Tötsch kicked off a discussion of the handling of constants within Parrot and proposed adding a bunch of functions for creating constant strings (symbols?) within the core. He also proposed a system for creating constant classes. In the ensuing discussion I think the proposals for strings were pretty much accepted, but it's not yet known if the proposal for constant classes is quite the Right Thing. http://xrl.us/qxk Should Tom Locke target parrot? Tom Locke is about to start on a project to create a new language and wondered if Parrot might be a good target VM for him. In short, we think so. But we would, wouldn't we? http://xrl.us/qxl More fun with set/assign The semantics of set in Parrot are, somewhat complex. Leo Tötsch showed a fragment of code which got a value from out
The Perl 6 Summary
Perl 6 Summary for the week ending 20030817 Picture, if you will, a sunny garden unaffected by power cuts, floods, plagues of frog or any of the other troubles that assail us in this modern world. Picture, if you will, your summarizer sat in this garden with a laptop on his knee, cursing the inability of LCD display manufacturers to make displays that are legible in sunlight. Picture your summarizer returning to the comfortable chair in the shade of his book room casting around for a witty and original way to open another Perl 6 summary. Picture him giving up and starting to type. Here's what he writes: We start, as usual, with the the internals list. Tail call optimization Leo Tötsch has started to work on getting IMCC to detect tail calls and optimize them to either a simple jump or an invoke. If you're not sure what tail call optimization is I can recommend Dan's What the heck is a tail call? article on the subject. http://xrl.us/pun http://xrl.us/puo -- What the heck? Leo's QUERIES from last week Last week, Leo bundled up a bunch of outstanding questions for Dan, and Dan answered them. Benjamin Goldberg queried Dan's answer about find_method, which, if I'm reading things correctly is currently implemented in the interpreter. Benjamin argued (convincingly I thought) that, although the method hashes needed to be stored in the interpreter structure, find_method should be implemented on default.pmc, allowing for different classes/languages to override its behaviour. http://xrl.us/pup Why ~ for xor? Michal Wallace wanted to know why ~ maps to both unary bitwise-not and binary bitwise-xor in IMCC; he expected xor to be ^ and ^^. Leo explained that it was, at one point at least, the way Perl 6 did it but that he'd stopped keeping up with the developments in perl6-language. He noted that, if the Perl 6 operator had been settled, then IMCC should use that. A quick skim of my copy of *Perl 6 Essentials* tells me that Perl 6 now uses +, +| and +^ for bitwise and/or/xor, with ~, ~|, ~^ for stringwise and/or/xor. http://xrl.us/puq http://xrl.us/pur -- My review of *Perl 6 Essentials* Raising Hell Michal Wallace's Py-Pirate project continues to exercise the edges of Parrot as he implements more and more of Python's semantics. This time he needed to know about raising (and catching) exceptions. In particular he wanted to be able to catch an exception when find_lex failed to find an appropriately named variable. (Currently, a find_lex failure doesn't raise an exception, it just kills Parrot). Jos Visser told him that there were plans to have find_lex throw a real, catchable exception, or maybe just return undef. See last week's summary for a pointer to that discussion. http://xrl.us/pus Pirate status and help with instances Michal Wallace announced that he had just finished an all night coding spree and that Py-pirate could now handle: * functions (closures, recursion, etc) * Global variables * tuples (but they turn into lists) * dictionaries (create, setitem, getitem, print) * list comprehensions * raise (strings only) * try...except (partial) * try...finally * assert (At this point, I think we should all pause for moment of wild applause). However, he was having a few problems with instantiating objects of a class. (For those who don't know, Python instances are created by calling the Class as if it were a function). Leo Tötsch noted that almost nothing would work, since Parrot's classes and objects weren't actually finished yet. He agreed with others in the thread who reckoned that Python classes could be made to work by subclassing the standard class.pmc to allow it to respond to an invoke by by creating a new instance. Easy! Michal muttered something about faking classes with closures but I don't think he went through with it. http://xrl.us/put Packfile fun So long assemble.pl, it's been good to know you. http://xrl.us/puu Approaching m4 Leon Brocard, Sean O'Rourke and James Michael DuPont looked on in awe as Bernhard Schmalhofer announced that he'd been working on implementing m4 in Parrot. According to Sean, the implications are staggering... Sure, plenty of compilers can bootstrap themselves, but how many can generate their own configure scripts via autoconf? With p4rrot, we may live to see this dream. One does worry about Sean's dream life. http://xrl.us/puv Call and return conventions TOGoS has been thinking about the workings of the Parrot calling conventions. He wondered if there was a case for making calling and returning look exactly the same, allowing for cunning stunts with fake continuations in P1. Luke Palmer really
Re: The Perl 6 Summary
Robin Berjon [EMAIL PROTECTED] writes: Uri Guttman wrote: MS == Melvin Smith [EMAIL PROTECTED] writes: MS This has been a major stumbling block for me in getting back the MS motivation to help with Parrot again. so if that helps salve your wound, i am sure you contributions (past and future) to parrot are welcomed and appreciated by the parrot community (pretty much those on these lists) I second that. The imperatives of book production are mercantile, and have nothing to do with one's excellent participation in an Open Source effort, irrespective of the quality that a given editor may normally have. I'm certain that when a more definitive book is started, there will be much more time to ask all the interesting people for input. Please don't lose your motivation :) Speaking of books. I keep mulling over the idea of attempting to write a 'Soul of a New Machine' type book for Parrot and Perl 6...
Re: Apocalypses and Exegesis...
Iain Truskett [EMAIL PROTECTED] writes: * Alberto Manuel Brandão Simões [15 Aug 2003 00:36]: On Thu, 2003-08-14 at 15:19, Iain Truskett wrote: [...] Much like Perl 6 Essentials then? I must say that its chapter 4 is the clearest look at the perl 6 syntax (as it was at the time of writing) that I've seen yet. Yeah. I would like to read it. But as I think syntax will change, I'm not thinking on buying it.. ;-/ Safari. http://safari.oreilly.com/0596004990 Of course, you need a Safari subscription, but they quite useful things. I imagine purchasing it physical copies would be more common on p6-internals as over half the book is Parrot and related goodness. I think the chapter on the Perl design philosophy is definitely worth the reading of. I just wish the book had wider margins so I can make notes as things change. (Dan's already made, and signed a correction on page 93 for me :)
This Week's Perl 6 Summary
Perl 6 Summary for the week ending 20030703 Ooh look, it's another Perl 6 summary. Doesn't that man ever take a holiday? I think he took one last month. Is it in Esperanto this week? I don't think so. Does Leon Brocard get a mention? It certainly looks that way. Does it start with the internals list again? I think it does, in fact, here it comes now. Approaching Python Discussions (and coding) of the Parrot implementation of Python continued this week. Michal Wallace is working on taking a preexisting (but incomplete, it's a proof of concept only) python parse tree - parrot code generator and rejigging it to generate code for IMCC. Assuming the initial rejig is doable, Michal surmises that getting a complete python compiler will be 'just' a matter of fleshing out the rest of the visitor methods, 'and then dealing with the C-stuff.' Actually, the main strand of this discussion dealt with ways of extending IMCC to help optimize the translation of stack based code to code that uses registers more efficiently (register unspilling as Benjamin Goldberg called it), which should help with any bytecode translator based efforts. http://xrl.us/crudf http://xrl.us/crukq Semantics of clone for PIO-objects Jürgen Bömmels' work on the Parrot IO system continues to find edge cases in Parrot's memory management subsystem. As initially written, a clone call adds a reference to a ParrotIO object, but that object is neither garbage collected nor refcounted, and it gets destroyed when its first reference is destroyed. The problem can be solved by allocating a new ParrotIO in the clone call, but Jürgen had some questions about how to handle various things like what to do with buffering or position pointers. Jos Visser offered a suggestion involving indirection and reference counting which met with (at least) Melvin Smith's approval. http://xrl.us/crusx Making 'make' less verbose Leo Tötsch checked in a patch to make make's output rather less verbose. After the patch, the make process only echos the name of the file being compiled, and doesn't spam your terminal with the entire compiler commandline (the compiler warnings do that). Some people liked this. Others didn't. http://xrl.us/cruz5 Don't trace system areas in sweep ops One of the things we discussed at the Parrot BOF was how to solve the 'bogus objects' problem when doing timely destruction sweeps (The 'bogus objects' problem is when the stack walk code detects chimerical objects through holes in the C stack (hmm... if anyone has a good drawing of this?)). After much discussion we came to the conclusion that the trick was to only walk the system stack during DOD (Dead Object Detection) runs that got triggered via resource starvation. This works because There is nothing unanchored and alive beyond the runloop's stack. Brent Dax was impressed, but then, he wasn't at the BOF so he doesn't know how long it took us to get to the answer. http://xrl.us/cru73 User defined events Klaas-Jan Stol wondered if there would be some way of generating and posting user defined events. Uri Guttman thought that there probably would be. http://xrl.us/crviz PHP/Parrot The language implementation insanity continues! Stephen Thorne announced that he's working on implementing a PHP parser and is seriously considering targetting Parrot. He asked for pointers to good docs on how to go about doing so. He worried a little about bootstrapping as well. Luke Palmer and Simon Glover were forthcoming with lots of useful answers and pointers. http://xrl.us/crvsa Why Parrot uses Continuation Passing Style In a delayed response to a question from Klaas-Jan Stol, Dan has posted a long message on the reasons for choosing Continuation Passing Style as Parrot's calling convention. It's definitely worth the read if you're at all interested in the reasoning behind Parrot (and the reason that my copy of *Perl 6 Essentials* has a signed correction from Dan). http://xrl.us/crv24 IMCC supports the Parrot Calling Conventions Leo announced that IMCC's brand of assembler, PIR (I can't remember what it stands for, Parrot Intermediate Representation perhaps). Of course, there are things it doesn't quite do yet (tail call detection, only preserving 'necessary' registers...) and it's somewhat lacking on the test front, but it's a start. Yay Leo! http://xrl.us/crv75 Another task for the interested: Coverage Dan threw out another 'task for the interested' this week. At present we don't have a complete set of coverage tests for the parrot opcodes, nor do we even know why opcodes do have coverage. Volunteers to fix this state of affairs (start with a coverage report
This Week's Summary
Perl 6 Summary for the week ending 20030810 Another week, another summary. How predictable is that? In keeping with the predictability, we'll start with the internals list. Set vs. Assign T.O.G of Spookware has an issue with the way IMCC treats =; sometimes an = means set and sometimes it means assign, which TOGoS finds confusing. What he(?) finds even more confusing is that sometimes set has assign semantics. Dan agreed that this was somewhat confusing, and pointed out that there was a third possible semantic, clone. Luke Palmer agreed with TOGoS and suggested that it would be useful if the assign like behaviours of of set were moved over to becoming assign like behaviours of assign. Benjamin Goldberg wasn't even sure that set and assign were good names for those behaviours in the first place. He proposed three behaviour classes; mutate, alias and create. The general feeling seemed to be that Ben's approach was a good way forward, but I don't think anything has actually been implemented along these lines yet. http://xrl.us/oz5 Generic code generator? Not content with his efforts in porting Python to Parrot, Michal Wallace floated the idea of a generic code generator for parrot that everyone could use. Stephen Thorne liked the concept, but worried that it wouldn't necessarily play well with languages that allowed eval $aString. He proposed that, whatever the code generator got written in should be a language that would be self-hosting. Joseph Ryan argued that, instead of coming up with a new meta-language for the GCG (Generic Code Generator), we should use something like XML or YAML as a way of dumping the AST (Abstract Syntax Tree) with standardized node names. Dan (who has a 'deep personal loathing for XML') was all for just building a standard datastructure and passing that into the code generator. (ASTnode.pmc anyone?). He also suggested that having some way of doing AST transforms would be handy, as many languages would want to get hold of the AST and munge it in some way before it went any further (Lisp macros are the canonical example of this sort of thing). Following the discussion, Michal and Klaas-Jan Stol apparently spiked out a prototype that used s-expressions. Your summarizer wonders if there's any overlap between this and treecc. Maybe I've just misunderstood what treecc was all about. http://xrl.us/oz6 Calling convention questions Vladimir Lipskiy had a couple of questions about how the calling conventions worked. Dan and Leo supplied the answers, Vladimir pointed to the section of pdd03_calling_conventions.pod that had caused the confusion, and Dan went and fixed the docs. http://xrl.us/oz7 Infant Mortality Every so often, perl6-internals ends up talking about the Infant Mortality Problem -- the possibility of an object being marked as dead by the GC system before it's even been fully initialized. Benjamin Goldberg addressed himself to the problem this week by proposing a generational Garbage Collector. I'm not sure anyone was convinced that his proposed use of a generational collector to avoid having to walk the C stack was the Right Thing, but nor do I think anyone's averse to trying a generational collection scheme to see how performance stacks up. http://xrl.us/oz8 Packfile stuff Dan outlined some things we need to add to the packfile format and the sub header in order to get things ready for more language work. He, Leo and the usual suspects thrashed out the implications (assemble.pl and disassemble.pl will finally get removed from the distribution for example), but I don't think a final bytecode and sub header format have been decided upon yet. http://xrl.us/oz9 Parrot on Win32? Valery A.Khamenya wondered if there was any news on getting a ready to run win32 Parrot distribution. Jonathan Worthington has volunteered to start work on producing regular build snapshots. Yay Jonathan! http://xrl.us/o2a Bitwise string ops Leo Tötsch checked in the beginnings of bitwise operators for strings and dropped a huge hint that it'd be good if someone could finish things up. Vladimir Lipskiy took the hint, but felt a good deal of pain trying to produce appropriately formatted diffs until he worked out how to do the equivalent of cvs diff -c in WinCVS (hopefully the same trick can be used to do cvs diff -u, which is the preferred diff format of perl6-internals). http://xrl.us/o2b Dynamic PMC classes Discussion of the appropriate interfaces for the dynamic loading of PMCs continued apace. Leo committed his current implementation, stressing that it wasn't final, but it is at least something to work on. http://xrl.us/o2c extproc_parrot Sometimes I worry
This week's Perl 6 Summary
Perl 6 Summary for the week ending 20030727 Welcome to another in the ongoing series of Perl 6 summaries in which your faintly frazzled summarizer attempts to find a native speaker of Esperanto to translate this opening paragraph in honour of the huge amount of money (1371 Euros) raised for TPF during the YAPC::Europe auction, when the official language of both London.pm and Paris.pm's websites were auctioned off as one lot. Somewhat to the surprise of everyone, the winning bid was for Esperanto. As Jouke Visser just commented on IRC, the price was well worth paying just to see the looks of panic on the faces of Mark Fowler, Leon Brocard and other London.pm worthies as the price of keeping the website English (and changing Paris.pm's website to English in the process) shot up beyond the reach of their collective pocket. Meanwhile, we'll return to English and start with the internals list as usual. Events Junior reporter: Mr Macmillan, what caused your greatest difficulties in your time as UK Prime Minister? Macmillan: Events dear boy, events. Whilst I'm not sure Dan would fully agree with Macmillan, there was a certain amount of concern about Events (well, event handling). Damien Neil is still convinced that asynchronous IO is the Wrong Thing, but he hasn't convinced Dan, and (in this at least) it's Dan's opinion that counts. http://xrl.us/nj3 http://xrl.us/nj4 -- Dan ditches the cranky reply Memory system issues Jürgen Bömmels' work on the aforementioned Asynchronous IO system means that he's been getting rather more involved with the internals of Parrot's memory allocation and Garbage Collection system than he intended. He had a few questions, which Dan answered. http://xrl.us/nj5 Splitting core.ops Brent Dax announced that the patch splitting core.ops into a slightly more logical set of smaller files has been committed. This occasioned a small flurry of discussion and a smaller flurry of patches to ensure that all the new .ops files had their associated documentation files built. http://xrl.us/nj6 Parrot docs translated to Japanese Koichi Sasada, a Japanese university student has translated the Parrot Primer into Japanese and put it on his website. He wanted to know if he could publicise the translation. This summary is (at least in part) his answer. http://xrl.us/nj7 http://xrl.us/nj8 -- In English http://xrl.us/nj9 -- In Japanese PMC methods Luke Palmer can't stop thinking of other ideas as he works on implementing lazy PMCs. His latest idea relates to accessing methods on PMCs without having to generate scads of new opcodes (Personally, I don't see what's wrong with using the object stuff for getting both PMC vtable (C) methods and methods that are implemented in Parrot itself.) Luke proposed a few ops which he reckons will solve the problem. http://xrl.us/nka objects.t Failures Simon Glover tracked down a problem with the objects.t test file that had been failing on some, but not all platforms. It turns out that the class_hash wasn't included as part of the root set, which meant that the garbage collector could try to reclaim it before it got used. Which is bad. He supplied a two line patch to fix the problem. Which is good. Dan made with the D'oh!, commenting that he'd known he'd forgotten something. http://xrl.us/nkb RFC: Cleaning up the ParrotIOLayer API Jürgen Böemmels has reached a point in his redoing of the Parrot IO subsystem that he wanted to remove and/or rename several of the old methods so he posted an RFC explaining what he intended to do and asked for comments. Gregor N. Purdy had some comments, mostly to do with the data structures involved (with particular reference to strings) but other than that there has been no further comment. http://xrl.us/nkc Parrot Emits an Executable Daniel Grunblatt checked in a patch to make parrot generate native executables. There are caveats about what must be done in order to get a working executable and the original patch needed to have a few wrinkles ironed out, but this looks like a fantastic start to me. http://xrl.us/nkd Approaching Python Michael Wallace wondered about the issue of compiling python to parrot. He wondered if it would be possible to make use of the existing Python compiler module which generates python bytecode from a parse tree. He wondered if it'd be worthwhile modifying it to generate parrot bytecode. The discussion which followed covered various options for handling Python code, ranging from bytecode transformation to translating the source code into Perl 6 (which is probably the least likely to save Dan from pie). I'm not sure if a particular approach was chosen, but Michael
The Perl 6 Summary
Perl 6 Summary for the week ending 20030720 Welcome back to an interim Perl 6 Summary, falling as it does between two conference weeks; OSCON and YAPC::Europe. For reasons involving insanity, a EuroStar ticket going begging, and undeserved generosity I shall be bringing my conference haul up to 3 for the year. Yay me! Now if I can just finagle a talk into the schedule I will have spoken at all three too. I'll certainly have heckled at all three... The State of the Onion Tim Howell wondered if Larry's State of the Onion address to OSCON would be available anywhere. Robert White Camel Spier didn't rest on his laurels, but posted a link to Larry's slides and transcript. Chromatic popped up with a different link, which neatly combines slides and transcript. However, they both lack the funny balloon pony which I gave Larry just before the talk. Maybe there will be video later. http://xrl.us/mtl http://xrl.us/mtm A Small Perl Task for the Interested A few weeks back, Dan asked for volunteers to improve Parrot's build system. Lars Balker Rasmussen stepped up to the plate and offered a simple wrapper. Josh Wilmes seems to be somewhat sceptical about the whole endeavour, pointing at libtool as an illustration of the size of the problem. http://xrl.us/mtn env.pmc Parrot is in the process of getting an env PMC, for accessing environment variables. Dan and Leo's discussion of the patch took in iterators and the wisdom of caching values. In the end, Dan prevailed and the environment PMC doesn't cache values. http://xrl.us/mto Dan on threading Yes, [there is some plan of how threading will work in Parrot]. (Though there's some disagreement [as] to the solidity and sanity of the plan) Dan went on to outline the plan. http://xrl.us/mtp Event handling Event handling appears to be the topic of the week. The consensus seems to be that getting it right is hard. Lots of people offered constructive suggestions and/or problem cases. I sat on the sidelines and trusted them to get it Right (a strategy which seems to pay off remarkably often, thankfully). Damien Neil was rather less sure of the wisdom of Parrot's events and asynchronous IO model, arguing for a system based on threading. Dan was unconvinced. I don't think Damien was convinced either. http://xrl.us/mtq http://xrl.us/mtr http://xrl.us/mts IMCC sub names are not labels Luke Palmer had some problems with using continuation passing style subroutines in IMCC. Leo initially pointed out that IMCC didn't support CPS, then he fixed it so that it did (sort of, the user still has to do a chunk of the work, but sometimes that's a good thing). In an example of synchronicity, Will Coleda had a similar problem. Leo's fix helped him too, and he went off to continue hacking on TCL. (It helps me too, I have this cunning plot you see...) http://xrl.us/mtt More on targeting GCC In last week's summary I wondered what Tupshin Harper was talking about when he suggested emulating a 'more traditional, stack-oriented processor'. This week, Tupshin wished that 'people had the decency to tell me how insane [the idea] is'. Dan obliged, telling Tupshin that he was insane (but he did it with a smile). The problem boils down to GCC's assumptions about the 'shape' of the stack. GCC assumes a conventional, contiguous area of stack memory filled with stack frames. Parrot assumes a garbage collected chain of continuations, which is about as far as you can get from GCC's beliefs. http://xrl.us/mtu Parrot_sprintf not recognizing 7 in precision mrnobo1024 posted a patch to fix a minor niggle with Parrot_sprintf. Leon Brocard applied it. http://xrl.us/mtv Problems with new object ops Dan has started adding real classes and objects to Parrot. (Yay!) Simon Glover found some bugs. (Not entirely unexpected) Simon also sent in a patch fixing the bugs. (Yay! Yay! and thrice Yay!) http://xrl.us/mtw The big core.ops split Brent Dax has started work on splitting core.ops up from being the second largest file in the Parrot distribution (108k) into a total of 10, rather more narrowly defined .ops files. Benjamin Goldberg wondered if this would be a good time for tidying up the parrot directory structure (at the very least, he called for moving the source files into a src subdirectory). Dan asked for a volunteer to rough out a move plan coving which files move where and what the new directory structure would look like, which would allow the CPAN jockeys to rearrange things in such a way that the various files remember their histories. http://xrl.us/mtx Copyrights Josh Wilmes posted a monster patch to unify the various copyright notices attached to the files
This week's summary
Perl 6 Summary for the week ending 20030713 Welcome once again to the Perl 6 Summary, in a week of major developments and tantalizing hints. Starting, as usual, with what's happening in perl6-internals Targeting Parrot from GCC Discussion in the thread entitled 'WxWindows Support / Interfacing Libraries' centred on writing a Parrot backend to GCC. (No, I have no idea what that has to do with the thread subject.) Tupshin Harper, Leo Tötsch and Benjamin Goldberg discussed possibilities and potential pit/pratfalls. At one point, Tupshin suggested emulating a 'more traditional stack-oriented processor' and I don't think he was joking... http://xrl.us/l6b Timely destruction and TRACE_SYSTEM_AREAS Jürgen Bömmels' rewrite of Parrot IO is causing some problems with the garbage collection (IO handles are the canonical examples of resources that need timely destruction). Leo tracked down the source of resource leak to a problem with handles being found on the C stack. Jürgen wasn't happy about this (he's not keen on the stack walking approach to garbage collection). He proposed that we get rid of the stack walk in favour of some other solution to the infant mortality problem and offered a few candidates. Leo said that he didn't like walking the C stack, going so far as to state that Timely destruction and solving infant mortality don't play together or are mutually exclusive - in the current approach. Dan hasn't commented on this yet. http://xrl.us/l6c Parrot is not feature frozen There was a certain amount of confusion as some old email with the subject 'Parrot is feature-frozen until Wednesday' made its way into a small number of inboxes sowing confusion as it went. Suffice to say, Parrot is not currently feature frozen, though Steve Fink did say that he was considering a point release once the imcc/parrot integration was complete. If Dan gets objects and exceptions finished, then it might even warrant a 0.1.0 version number rather than 0.0.11 http://xrl.us/l6d Perl* Abstraction Luke Palmer has finally started to implement his Infinity PMC and has noticed a lot of redundant code in the Perl* classes. He also noticed that Parrot doesn't seem to have the distinction between container and value that has been confusing people on the language list. http://xrl.us/l6e Fun with ParrotIO First, Jürgen Bömmels sent in a patch to excise integer file descriptors from Parrot except when they are managed via ParrotIO PMCs. Leo applied this. Clinton Pierce thought that this patch meant that a Win32 bug could be closed in the Parrot bug database. This sparked a discussion with Leo, and Jürgen, but I'm not entirely sure of the status of the bug... http://xrl.us/l6f http://xrl.us/l6g Jako groks basic PMCs Gregor N Purdy seems to have started working on Jako again, and checked in some changes allowing Jako to manipulate PMCs. People agreed that this was cool. http://xrl.us/l6h I want a Ponie! The [EMAIL PROTECTED] mailing list was announced and I'll be summarizing it as of next week when I've joined, caught up, and generally recovered from America. What's Ponie? Ponie is 'Perl On New Internal Architecture' or, as Thomas Klausner put it, A version of Perl 5 that will run on Parrot, which was announced by Larry at his OSCON 'State of the Onion' address. Discussion of Ponie on the perl6-internals list centred on the What is ponie? question, with a certain amount of Why ponie-dev, not perl6-ponie? thrown in for good measure. Brian Ingerson announced that he'd set up a Ponie Wiki, Leon Brocard pointed at the use.perl story announcing Ponie, and your summarizer punted on writing a description of the project himself. http://xrl.us/l6i http://www.poniecode.org/ -- More on Ponie http://ponie.kwiki.org/ -- Ingy's Ponie Wiki http://xrl.us/lib -- use.perl announcement Exceptions! Leo Tötsch checked in the beginnings of an exceptions system. Then he checked in the beginnings of an events system. http://xrl.us/l6j http://xrl.us/l6k Meanwhile, in perl6-language There were all of 6 messages, all of them discussing the effects of aliasing an array slice. http://xrl.us/l6l Perl 6 Rules at OSCON No, wait, that should be Perl6::Rules. For his last talk at OSCON, Damian spoke about Perl6::Rules, his implementation of Perl 6's rules system in pure Perl 5. And oh boy was it tantalizing. He showed us something actually running a large chunk of Perl 6 matching semantics, complete with handy debugging information, diagnostic dumping and all the other useful stuff. When we were all gagging for him to release it to CPAN immediately, he told us that it wasn't finished yet; that he'd implemented it all
This Week's Summary
Perl 6 Summary for the week ending 20030706 Welcome to this week's Perl 6 Summary, coming to you live from a gatecrashed Speakers' lounge at OSCON/TPC, surrounded by all the cool people like Dan Sugalski, Lisa Wolfisch, Graham Barr and Geoff Young, who aren't distracting me from writing this summary at all. 10 minutes later, after the arrival of James Duncan and Adam Turoff, I'm still not being distracted. Oh no... Leon Brocard's just arrived, which helps with the running joke, but not with the 'getting the summary written'. So, we'll start as usual with the goings on in perl6-internals. More on Parrot's multiple stack implementations Dan pointed out that, although Control, User and Pads share the same stack engine, Pads should be implemented using a simple linked list. He also confessed that all the register backing stacks should share an implementation, but that he'd been too lazy to macro things up properly. http://xrl.us/ldt Building IMCC as parrot Leo Tötsch posted an initial patch to make IMCC build as the parrot executable. And there was much Makefile debugging. http://xrl.us/ldu Parrot IO work Work on Parrot's IO system was ongoing this week. http://xrl.us/ldv Parrot Exceptions Discussion of possibly resumable exceptions continued, and morphed into a discussion of the workings of warnings when Benjamin Goldberg wondered if warnings were being implemented as exceptions. The aren't. I think Benjamin was being confused by Perl 6's fail function which can either issue a warning and return undef to its caller's caller, or throw an exception, depending on a pragma whose name I can't for the life of me remember. http://xrl.us/ldw Parrot's build system. Last week Dan asked for help writing a configuration and build system that would allow per-C-file compiler flag overrides and various other complexities. This week Alan Burlison worried that this approach looked '*very* suspect'. This sparked a discussion of the proper way to do interrupt safe queueing, reentrant code and other scary things. I may be misreading what's being said in the thread, but it seems that the scariest thing about the whole issue is that there's no portable way of doing the Right Thing, which leads to all sorts of painful platform dependencies and hoopage (From 'to jump through hoops', anything which requires you to jump through a lot of hoops has a high degree of hoopage. For the life of me I can't remember if it was me or Leon Brocard who coined the term). Swamps were mentioned. Monty Python skits were quoted. Uri Guttman was overtaken by (MUAHAHAHAHAHA!) megalomania. http://xrl.us/ldx Klaas-Jan Stol Explains Everything (part 1) Last week I mentioned that I didn't know what Klaas-Jan Stol was driving at when he proposed a general, language-independent argument PMC class and hoped that he would provide an explanation, with code fragments. This week, Klaas-Jan came through, and I think I understand what he wants. Go read his explanation and see if you understand it too. It's to do with when a parameter should be passed by reference or by value. Parrot currently assumes that Strings and PMCs are passed by reference, and that integers and floats are passed by value. There was some discussion of whether support for optionally passing PMCs by value should be added at the parrot level or whether individual language compilers should be responsible for calling the appropriate PMC methods. http://xrl.us/ldy Moving ParrotIO to PMCs Jürgen Bömmels is working hard on moving Parrot's IO-system to a fully garbage collected PMC based system. He posted an initial patch transforming ParrotIO structures into PMCs using a simple wrapping approach. The patch had problems because the new ParrotIO PMCs were marked as needing active destruction, which could lead to problems with files being closed twice and memory structures getting cleaned up twice. Which is tends to make memory leak detecting tools a little unhappy. This bug proved to be easy to fix. But then another one reared it's head and has so far proved rather harder to fix. http://xrl.us/ldz Jako gets modules (sort of) Gregor N Purdy announced that he's added rudimentary module support to his Jako little(?) language. A little late he announced that he'd added rather less rudimentary module support. http://xrl.us/ld2 Stupid Parrot Tricks Clinton Pierce, shooting for his 'mad genius' badge announced that he'd implemented a simple CGI script in Parrot BASIC. Everyone gasped. Robert Spier decided that the time may have come to start playing with mod_parrot (embedding Parrot in Apache) again. http://xrl.us/ld3 http://xrl.us/ld4 -- that BASIC CGI URL Lazy
This week's summary
The Perl 6 Summary for the week ending 20030629 Welcome to the third of my US tour Perl 6 summaries. Once again I'm pleased to report that the denizens of the Perl 6 mailing lists continue to make the life of a touring summarizer an easy one by not posting all that much to the lists. So, I can sit here in my room at the Shaker Inn in Enfield and marvel at the traffic noise outside, wonder about the car next door with the New Hampshire plates reading PERLFAN, and just generally appreciate the loveliness of the room. But, while I'm doing that, I should start with perl6-internals Exceptions At the end of last week, Dan outlined his thoughts on how exception handling will work in Parrot. This week, people talked about it. Discussion revolved around how much information should be attached to an exception and how/whether we should support resumable exceptions. http://xrl.us/j73 More on Continuation Passing Last week I said that I get the strong feeling that Leo Tötsch isn't entirely happy with the new Continuation Passing Style. This week Leo corrected me; I hadn't noticed that the speed issues had been addressed by the latest changes to parrot (in fact the current CPS implementation is faster than the old invoke/ret scheme. Sean O'Rourke addressed Leo's problem with the Perl 6 Compiler tests failing by saying that the compiler should really be ported to use CPS rather than implementing a new variant of the Sub PMC that uses the old scheme. Leo reckoned that such a port wasn't currently doable because IMCC needed to be modified to use the CPS scheme, which would also involve reworking the register allocator. Given Leo's prodigious rate of implementation, this may have already happened. http://xrl.us/ktb IMCC/Parrot leak Clinton A. Pierce had reported a memory leak in Parrot, but tracked it down to a situation where he was doing: .arg 0 call _foo And forgetting to take the 0 off the stack. However, even after he'd fixed that, he had segfault issues, and posted a (largish) code fragment that tweaked the bug. It appears that Parrot wasn't throwing warnings when stacks get to big, just failing silently. Leo added a check for too deeply nested stacks, which at least avoids segfaulting on logic bugs. Leo and Dan discussed other places where such limit checking should be put in place. Dan also muttered something about turning stack chunks into PMCs, allowing for the garbage collection of stack frames. Leo also muttered about the proliferation of stack implementations in Parrot (there are five) and thinks it should be possible to have one general stack engine. http://xrl.us/ktc Making + a unary operator Bernhard Schmalhofer found a problem with the Perl 6 implementation. print +42, \n; printed '42', but omitted the carriage return. He fixed this by making + into a unary operator as well as a binary operator and sent the patch to the list, where it was applied. Good catch Bernhard. http://xrl.us/ktd ParrotIO File-Descriptors Jürgen Bömmels is in the process of porting the IO subsystem from its current mem_sys_alloc/free based implementation to the sunny, garbage collected, uplands of a PMC based implementation. However, he's run into a problem; some of the operations in op.ops use integer File Descriptors, grabbing information from a table in the interpreter structure. This gets in the way of garbage collection, since any integer could be a file descriptor. Jürgen proposed removing the integer file descriptors and mandating that ParrotIO PMCs be the only way to access IO (including the standard STDIN, STDOUT and STDERR). He proposed adding get_std[in|out|err] ops to get at the standard streams. Dan suggested that Jürgen Just Do It; the current IO system being more than slightly hackish, it was essentially put in place until something better came along. http://xrl.us/kte Small Perl task for the interested Want to get involved in the Parrot development process? Don't know much about Virtual Machine design and implementation? Do know Perl? Dan has a small but interesting task for you. At present, Parrot gets built without any compiler level optimizations turned on because files like tsq.c can't have any optimizations turned on (tsq.c is the thread safe queue module, which is annoyingly execution-order-dependent because it has to operate safely as interrupt code potentially interrupting itself). Dan would like a version of Configure.pl which can build a makefile (or whatever build tool we end up using) with per-C-file compiler flags, and it needs to be possible to override those flags, per file, by the platform configuration module. Interested? David Robins seems to be, and
Re: Perl6 Daydreams (on topic but frivolous)
Rafael Garcia-Suarez [EMAIL PROTECTED] writes: Jonathan Scott Duff wrote in perl.perl6.language : My only dream is that by this time next year we have a fully- functional-people-can-use-it-in-production Perl6. It doesn't even have to be 100% complete; I think just 85% would be enough if it were the right 85%. 20% would be enough if it's what it takes to get 80% of the job done ;-) Eggzackerly. I'm looking forward to getting the rules/grammar engine up and running in Parrot. (Hell, getting a rules/grammer engine up and running in pure perl5 would be a good start) -- Piers
Re: Exceptions
Luke Palmer [EMAIL PROTECTED] writes: This is more of a language thang, so I've redirected your message there [here]. The most fundamental feature throwing an exception is that it transfers program execution from the call site. Allowing the caller to resume execution at that site is a very dangerous form of action at a distance. According to you. :-) I think you'd be better off a giving the caller an explicit way to inhibit throwing an exception. That is, use program design rather than language features to provide this functionality. e.g., a delegate: $ex = new My::Exception: ...; die $ex unless .delegate .delegate.should_ignore_ex($_, $ex)); Not only is the above pattern clearer to read and less afflicted by action at a distance, but it provides a wider bidirectional interface. It also has high inertia and is pretty verbose for error reporting. The thing about reporting errors is that it needs to be short, easy to type, easy to think about, or else people won't do it. Everyone did error checking in Perl 5 because it was a simple little Cor die. But I think you've got one thing right: giving the exception thrower control. The thing about Cdie is that it denotes a fatal error -- saying Cdie in a function is basically saying I can't continue after this... so you Iprobably shouldn't be allowed to continue it. If an error isn't fatal, you're supposed to use Cwarn. What's being said is I can't continue after this with the data and code as they are. I can envisage Perl code running in a Smalltalk like environment where catching such an exception would throw up a debugger allowing the programmer to alter either a variable, the exceptional code, or just faking a return value and either retrying or continuing. This kind of approach makes for a remarkably powerful way of doing, say, test first programming. You just write your test and start the test suite running, when this throws an 'unknown method exception' or whatever, you use the debugger to implement/stub out the method in question, retry, and repeat until the test stops throwing exceptions. So, maybe what's needed is a Cwarn catcher (CWARNCATCH... eew), where Cwarn would throw an exception object with an attached continuation. And of course, if a warning reached the top of the stack without being caught, it would print itself and invoke its continuation. In theory a thrown exception can include everything that's known about the runstate of your program at the time the exception was thrown. And it can't know how that information may be used by some handler up the chain. This implies to me that the correct behaviour when throwing a generic exception is to bundle up all the information available and leave it up to the catcher to decide what to do with it. Yes, this does mean that the catcher might be able to do some Really Stupid things, but if you don't open the door to Mr Stupid you are in danger of slamming it in the face of Mr Powerful. It seems to me that Perl's usual approach in such situations has been to leave the door unlocked... -- Piers
Re: Lightweight Object Existance Proxies
Further to the lightweight proxy thing, one of the things that proves
to be something of a pain in Pixie is writing 'self replacing'
proxies, where, once something is actually fetched from the database,
the proxy should go away. You can't simply assign to $_[0] (at least
in Perl 5) because that doesn't change every container that contains a
reference to the proxy. Right now, we do it with evilness like
%{$self} = %{$the_real_object}
which, whilst it fixes the Doesn't change everywhere issue, can
cause problems when classes track their instances.
So, the question is, if I do:
class Proxy {
...
method AUTOLOAD($methodspec) {
$_ := .get_the_real_thing;
.DISPATCH($methodspec); # Or whatever restarts the dispatch sequence
}
(Where C$methodspec is a handwavy object that encapsulates all the
information that Perl collects for dispatch purposes, hopefully
including at least context, methodname and parameters).
Will the proxy replace itself everywhere at a stroke, or will it do
the replacements piecemeal, replacing each reference to the proxy as
it tries to invoke a method on it?
--
Piers
This week's summary
The Perl 6 Summary for the week ending 20030622 Welcome to my first anniversary issue of the Perl 6 Summary. Hopefully there won't too many more anniversaries to celebrate before we have a real, running Perl 6, but there's bound to be ongoing development after that. My job is secure! Because I can't think of anything better to do, I'll start with the action on the perl6-internals list Converting parrot to continuation passing style The ongoing effort to convert Parrot to use/support continuation passing style (CPS) at the assembler level continues. Jonathan Sillito offered another patch implementing the require support, which Dan liked and applied. Klaas-Jan Stol wondered what he'd missed; last time he looked Parrot wasn't doing continuation passing. He asked why Dan had chosen to go down that route. Dan answered that he had realized that we had to save off so much state that we essentially had a continuation anyway. Explicitly going with continuation passing just made things more formal, and wrapped up all the context saving behind a straightforward interface. He promised a more detailed explanation later. http://xrl.us/j7x Portable way of finding libc, unbuffered reads Clinton Pierce noted that the following code: loadlib P1, /lib/libc.so.6 dlfunc P0, P1, system, it set I0, 1 set S5, ls invoke end just works, which simultaneously pleases and scares him silly. He wondered if there was a good way of finding the standard C library on a Unix system without scary hardwiring as in the fragment above. He also wondered if there was an 'official' way of getting an unbuffered read via parrot. Jens Rieks came up with a gloriously evil way of finding libc. The theory goes that Parrot is linked against libc, so you just have to dlopen the running image and you can call libc functions to your heart's content. To dlopen the running image you need to pass a NULL pointer to the underlying loadlib so he offered a patch to core.ops which interpreted an empty string as a pointer to NULL. Leo and Dan were impressed and the patch (or something similar) was applied. I get the feeling that Dan wants to do something a little less hacky to access the current executable though... Clint noted that the dlopen the running image by passing a null pointer trick doesn't work with Windows, but outlined a workaround for that too. Jen Rieks suggested a better Windows workaround. Nobody came up with an approved way of doing getc, but once you have libc loaded you can just use its getc. http://xrl.us/j7y OO, Objects If you look in a fresh from CVS parrot directory you'll now find object.ops, which will be the cause of much rejoicing in many places. Dan's nailed the object spec down enough that he's started implementing a few of the required ops. As he points out, what we have is hardly sufficient, but everyone's got to start somewhere, the journey of a thousand miles begins with but a single step, etc. Judging by the number of comments (none), everyone was stunned into silence. http://xrl.us/j7z More CPS shenanigans I get the strong feeling that Leo Tötsch isn't entirely happy with the new Continuation Passing Style regime. He's worried that the P6C tests break, and that CPS subs are some 3 times slower for calling the sub. This led into a discussion of what context really must go into a continuation, whether we can get away with different classes of continuation (hold more or less contextual information) and other ways of possibly speeding things up. I'm not sure Leo has been entirely convinced, but I'm confident that Dan's not going to change his mind about this. Leo later submitted a large patch which unifies the various subroutine related PMCs to take into account CPS. http://xrl.us/j72 Exceptions Now that the rules for subs/methods etc are settling down, Dan outlined his thoughts on exception handlers. If I'm understanding him correctly, an exception handler is just a continuation that you invoke with the exception as its only argument. There were no comments by the end of the week. http://xrl.us/j73 Meanwhile in perl6-language The language list was quiet again. Maybe everyone was doing face to face things at YAPC. Or on holiday. Or something. printf like formatting in interpolated strings Remember last week I mentioned that Luke Palmer had made a cool suggestion about printf like formatting in string interpolation? (He suggested a syntax like rx/expression but formatted(formatspec)/, which I for one quite liked). Edwin Steiner wasn't so keen, noting that Luke's suggestion was actually more verbose than rx/sprintf formatspec, expression/. He wasn't entirely
Re: Dispatching, Multimethods and the like
Adam Turoff [EMAIL PROTECTED] writes:
Damian just got finished his YAPC opening talk, and managed to allude
to dispatching and autoloading.
As it *appears* today, regular dispatching and multimethod dispatching
are going to be wired into the langauge (as appropriate). Runtime
dispatch behavior will continue to be supported, including things like
AUTOLOADER and the like.
Whoah! The wired in dispatch rules are going to be runtime dispatch
rules, but with potential compile time short circuiting where the
compiler knows enough stuff (frankly, I'm not sure I'd expect to see
compile time short circuiting in perl 6.0, maybe in 6.001 or whatever)
As of January, the thinking is sub DISPATCH {} will handle runtime
dispatching behaviors, including autoloading, but easily accomodating
value-based dispatching, AOP style pre/post methods, and whatnot.
Unfortunately, Damian said that the design team isn't saying much about
this, because the semantics aren't quite worked out yet, especially with
the interaction between autoloading and other dynamic dispatching
behaviors.
Yes, this is a *big* issue.
Yeah, but it's a late binding one.
--
Piers
Re: an idle question: returning from a nested call
David Storrs [EMAIL PROTECTED] writes:
So, as I sweat here in the salt mines of C++, longing for the
cleansing joy that Perl(5 or 6, I'd even take 4) is, I find myself
with the following problem:
Frequently, I find myself writing stuff like this:
void Ficp400::SaveRow(long p_row)
{
// if p_row is marked as deleted, return
if (GetStatus(row) FLX_ROW_DELETE) { return; }
...
}
As a general rule, I don't like comments. When I see a comment, I
want to turn it into a function name. So, I keep wanting to be able
to write the above code like so:
void Ficp400::SaveRow(long p_row)
{
Return_If_Is_Deleted(p_row);
...
}
Now, in C++ (or P6, FTM), I could make this work via a macro, but
that's ugly. In P6, I could make it work by passing the current
continuation down to Return_If_Is_Deleted and call the continuation if
the row is in fact deleted, but that will require an extra param. Is
there a way to make it work as written? I'm thinking maybe the
Ccaller object would have something that would allow me to jump to
the right point (i.e., caller[2]).
Something in Damian's talk this morning reminded me that:
void Ficp400::SaveRow(long p_row) {
when row_is_deleted { }
...
}
Will do a magic return. I do wonder if it'll simply return from
SaveRow, or from the innermost enclosing Cgiven
--
Piers
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030615 Welcome to the last Perl 6 Summary of my first year of summarizing. If I were a better writer (or if I weren't listening with half an ear to Damian telling YAPC about Perl 6 in case anything's changed) then this summary might well be a summary of the last year in Perl 6. But I'm not, so it won't. Instead, I'm going to try and keep it short (summaries generally take me about 8 hours on an average day, and I really don't want to lose 8 hours of YAPC thank you very much). It's getting predictable I know, but we'll start with the internals list again... Class instantiation and creation Dan continued slouching towards full OO and outlined the issues involved with setting up classes and asked for people's opinions. People offered them. http://xrl.us/jou Writing Language Debuggers Clinton Pierce wanted to know how to go about writing language level debuggers in Parrot. (This man is unstoppable I tell you.) He offered some example code to show what he was trying to do. Benjamin Goldberg had a style suggestion for the code, but nobody had much to say about Clint's particular issue. http://xrl.us/jov Converting Parrot to continuation passing style A lot of this week's effort was involved in getting support for the Continuation passing style function calling into Parrot. Jonathan Sillito posted a patch. This lead to a certain amount of confusion about what needs to be stashed in the continuation and a certain amount of bemusement about the implications of caller saves rather than callee saves (in a nutshell, a calling context only has to save those registers that *it* cares about; it doesn't have to worry about saving any other registers, because its callers will already have saved them if they cared.) Dan ended up rewriting the calling conventions PDD to take into account some of the confusion revealed. I think the upshot of this is that the Parrot core now has everything we need to support the documented continuation passing calling conventions. But I could be wrong. http://xrl.us/jow http://xrl.us/jox Segfaulting IMCC for fun and profit Clint Pierce's BASIC implementation efforts continue to be one of the most effective bug hunting (in code and/or docs) efforts the Parrot team has. This time, Clint managed to segfault IMCC by trying to declare nested .subs using the wrong sorts of names. Leo Tötsch explained how to fix the problem. It seems that fixing IMCC to stop it segfaulting on this issue is hard, since the segfault happens at runtime. http://xrl.us/joy Passing the time Clint's BASIC can now place chess! Not very well, but we're in 'dogs dancing' territory here. Bravo Clint! There was applause. http://xrl.us/joz Meanwhile in Damian's YAPC address... New DISPATCH method Last week Ziggy worried about multimethod dispatch not being good enough. This week at YAPC, Damian announced DISPATCH, a scary magic subroutine which allows you to define your own dispatch rules. Essentially it gets called before the built in dispatch rules, beyond that, I know nothing. Sorry, no link for this. Meanwhile in perl6-language Ziggy's obsoleted thread Last week I mentioned that Adam Turoff had worried a little about multimethod dispatch, and wanted to know if it would be possible to override the dispatch system in an easy way. This week, he outlines the sorts of things he might want to do. See above for the resolution. Details don't exist just yet, but we'll get there. http://xrl.us/jo2 Type Conversion Matrix, Pragmas (Take 4) Michael Lazzaro posted the latest version of his Type Conversion Matrix and asked for comments and hopefully definitive answers. There was a small about of discussion... http://xrl.us/jo3 Returning from a nested call Whilst idly 'longing for the cleansing joy [of] Perl', Dave Storrs wondered how/whether he could write a method that would return from its caller. Answer: Yes, use leave. http://xrl.us/jo4 printf like formatting in interpolated strings Edward Steiner wondered about having some way to to printf like formatting of numbers in interpolated strings. Luke Palmer (who just told me he's embarrassed about something I wrote about something he said last week, but I'd forgotten it) came up with a cool looking suggestion in response. http://xrl.us/jo5 Acknowledgements, Announcements and Apologies Well, that wraps up my first year of summary writing. Thanks to everyone for reading, it's been fun. I have one announcement to make: As of next week, there will be no obligatory reference to Leon Brocard -- I'm getting bored of it, you all must have been bored with it for months... If you've appreciated this
Re: *Tap Tap*
Nicholas Clark [EMAIL PROTECTED] writes: On Mon, Jun 09, 2003 at 09:56:06AM +0100, Piers Cawley wrote: Is this thing on? No messages since last Wednesday. Which admittedly makes a summarizer's life a good deal easier... It looks like it is. However, your life may be easier this week only, given that many armed and dangerous minds have been meeting up on the perl whirl, and may be about to unleash fearsome new concepts to the world. So it may only be the calm before the storm. Or I may be wrong. Ah well, I'll be in Florida for the next one, hopefully I'll be able ask some of said dangerous minds what on earth they're talking about. Anyhoo, time to get this week's summary mailed out. -- Piers
This week's summary
The Perl 6 Summary for the week ending 20030608 It's another Monday, it's another summary and I need to get this finished so I can starting getting the house in order before we head off to Boca Raton and points north and west on the long road to Portland, Oregon. Via Vermont. (I'm English and as the poem comments, the rolling English road is A rare road, a rocky road and one that we did tread // The day we went to Birmingham by way of Beachy Head. Just because I'm in America doesn't mean I can't take an English route to OSCON) We'll start with the internals list this week (and, given that there are only 18 or so messages in my perl6-language inbox, we may well stop there). Building IMCC as parrot It's been pretty much decided that IMCC will soon become 'the' parrot executable. Josh Wilmes, Robert Spier and Leo Perl Foundation grant recipient Tötsch are looking into what needs to be done to make this so. It's looking like the build system may well see some vigorous cleanup action in this process. http://xrl.us/jax The Horror! The Horror! Clint Pierce continued to expand on the internals of this Basic implementation. The more I see of his pathological examples, the gladder I am that I escaped BASIC as quickly as possible. Still, kudos to Clint once more for the effort, even if it is a tad embarrassing that the most advanced language hosted on Parrot is BASIC. (On IRC Leon Brocard and others have been heard to remark that they're? unlikely to go all out at a real language until Parrot has objects. Dan?) http://xrl.us/jay The Horror! The Horror! Part II The timely destruction thread still doesn't want to go away. Dan has been heard muttering about this on IRC. Eventually, he did more than mutter on IRC -- he stated clearly on list that 'We aren't doing reference counting' and that as far as he is concerned the matter is closed. Dan's blog also has another of his excellent What The Heck Is posts, this time about Garbage Collection. http://xrl.us/jaz http://xrl.us/ja2 http://xrl.us/ja3 - What the Heck is: Garbage Collection The Continu(ation)ing Saga Jonathan Sillito posted a longish meditation on Parrot's new continuation passing calling conventions. He wondered if, now we have continuation passing, we really needed the various register stacks that were used in the old stack based calling conventions. Warnock's Dilemma currently applies. http://xrl.us/ja4 Clint Pierce, IMCC tester extraordinaire Over the past couple of week's Clint Pierce has been porting his BASIC implementation over to run on IMCC. In the process of doing so he's been finding and reporting all sorts of IMCC bugs and/or misunderstandings and Leo Tötsch (usually) has either been correcting Clint's assumptions or fixing the bugs he's found. I've mentioned a few of these exchanges that generated longish threads in the past, but that hasn't covered everything that's been found, discussed and fixed. It's been great to see this sort of dialogue driving the design and implementation forward based on the needs of a real program. The thread I've linked to below is another exchange in this ongoing dialogue. Clint found a way of reliably segfaulting IMCC. Leo fixed it. And on to the next. http://xrl.us/ja5 And, on the subject of list stalwarts... Jürgen Bömmels is still working away at the Parrot IO (PIO) subsystem. In this particular patch, he's gone through the Parrot source replacing occurrences PIO_fprintf(interpreter, PIO_STDERR(interpreter, ...) with the better factored PIO_eprintf(interpreter, ...), which as well as eliminating repetition, helps to keep the IO code slightly easier to maintain. Leo applied the patch. (Although it's not mentioned explicitly elsewhere, Leo continues to keep up his astonishing productivity with various other patches to Parrot) http://xrl.us/ja6 Make mine SuperSized Bryan C. Warnock continued to discuss issues of the size of Parrot's various types, particularly the integer types that get used within a running Parrot. Bryan argues that these should ideally use a given platform's native types, worrying about guaranteed sizes only at the bytecode loading/saving stage. Dan and others commented on this (Dan essentially said that he understood what Bryan was driving at but wasn't quite sure of the way forward, and outlined his options). Discussion continues. http://xrl.us/ja7 Call invoke call? Jonathan Sillito submitted a patch which changes invoke to call, adds some PMC access macros and updates the tests. He and Leo Tötsch discussed things for a while and I think the patch is in the process of being rewritten as result of that discussion. http://xrl.us/ja8 Constant
Re: Cothreads
Michael Lazzaro [EMAIL PROTECTED] writes: On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote: So, in summary, its good to have a clean abstraction for all the HCCCT things. But I think it is a mistake to push them too close. Each of the HCCCT things might be implemented as facades over the underlying othogonal concepts of data management and execution management (hmm, we mustn't forget IO and other resource managers). Yeah, that. What I STRONGLY SUGGEST WE AVOID is a situation where _some_ of those interfaces are object-based, using new Thread: or similar, and others of those are trait or keyword based, such as coro foo or sub foo is coroutine, and others are implicit and invisible (closures).[*] I would be very, very surprised to see a situation where you don't have an object interface to the various things which are more usually made with the various bits of syntactic sugar. A nice, consistent OO API for these things will make the life of macro/refactoring brower/SmalltalkLikeIDE/whatever author so much easier. -- Piers
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030601 Another Monday, another Perl 6 Summary. Does this man never take a holiday? (Yes, but only to go to Perl conferences this year, how did that happen?) We start with the internals list as usual. More on timely destruction The discussion of how to get timely destruction with Parrot's Garbage Collection system continued. Last week Dan announced that, for languages that make commitments to call destructors as soon as a thing goes out of scope, there would be a set of helpful ops to allow languages to trigger conditional DOD (Dead Object Detection) runs at appropriate times. People weren't desperately keen on the performance hit that this entails (though the performance hit involved with reference counting is pretty substantial...) but we didn't manage to come up with a better solution to the issue. http://xrl.us/iu5 Bryan C. Warnock, patchmonster of the week Bryan C. Warnock seems to be attempting to outdo Leo Tötsch in the patchmonster stakes this week. He put in a miscellany of patches dealing with the Perl based assembler, opcode sizes, debugging flags and probably others. Most of them were applied with alacrity. The Perl 6 Essentials book Dan Sugalski gave a rundown of how the Perl 6 Essentials book came about, what's in it and all that jazz. He started by apologizing for not mentioning it before, but he thought he had. This led Clint Pierce to wonder if there was something up with Dan's Garbage Collection system. The existence of the book probably goes some way to explaining Leo Tötsch's relative silence over the last few weeks. Nicholas Clark wondered if it explains why Parrot doesn't have objects yet. Brent Dax wondered when it would be available (by OSCON this year apparently). http://xrl.us/iu6 IMCC, PASM and constants/macros Clint Pierce had some big headaches with moving his BASIC interpreter over to IMCC owing to problems with .constant which is legal for the assembler, but not for IMCC. Leo Tötsch pointed Clint at IMCC's .const operator. Bryan Warnock wondered if IMCC and the assembler's syntax couldn't be unified. Leo noted that it wasn't quite that straightforward because .constant declares an untyped constant, but .const requires a type as well. It turns out that .const wasn't quite what Clint needed, so Leo pointed him at .sym and .local which do seem to do what he needs. http://xrl.us/iu7 3-arg opens Bryan Warnock wondered if open I3, temp.file, r was valid code. Answer, no, the right way to do it is the Perlish open I3, temp.file, . Jürgen Bömmels promised more and better documentation for the Parrot IO system. Eventually. http://xrl.us/iu8 Smaller PMCs Leo Tötsch's work on the new PMC layout continues apace. I'm afraid I don't quite understand what's going on in this area, which does make it rather tricky to summarize things. It seems to have a good deal to do with memory allocation and garbage collection... Leo thinks that it's the right thing, but there seem to be issues involved with good ways of allocating zeroed memory. http://xrl.us/ijt An experimental Wiki for parrot development Mitchell N Charity has put up an experimental Wiki for Parrot and primed it with a few things. Stéphane Payrard pointed out that it's rather hard to make a WikiWord from, for example, PMC. (10 points to the first person to email [EMAIL PROTECTED] with the expansion of PMC). http://xrl.us/iu9 IMCC packfile bug While toying with pbc2c.pl, Luke Palmer discovered that it doesn't want to play with IMCC generated .pbc files. Apparently this is because we currently have two bytecode file formats. Leo Tötsch thought the problem lay with assemble.pl which is old and slow and doesn't produce 'proper' parrot bytecode. Leo also thought that the way pbc2c.pl worked wasn't actually any use. Dan reckoned the time had come to ditch assemble.pl too, and reckoned there was a case for renaming IMCC as parrot since it can run either .pbc or assembly files. Leo liked the idea, but is concerned about the state of the Tinderbox. http://xrl.us/iva Method Calling Dan tantalized all those waiting eagerly for objects in Parrot by discussing how to make method calls. This, of course, means a few new ops, called findmeth, callmeth and callccmeth for the time being. Jonathan Sillito had a few naming consistency issues with the ops. Dan agreed there were issues and asked for suggestions for an opcode naming convention. http://xrl.us/ivb Simple Constant Propagation in IMCC Matt Fowles posted a patch to add simple constant propagation to IMCC. Essentially this means that, say set I0, 5 set I1, 2 set I2, I1 add I2, I0 would
Re: Ruminating RFC 93- alphabet-blind pattern matching
Luke Palmer [EMAIL PROTECTED] writes:
On Thu, Apr 03, 2003 at 07:29:37AM -0800, Austin Hastings wrote:
This has been alluded to before.
What would /A*B*/ produce?
Because if you were just processing the rex, I think you'd have to
finish generating all possibilities of A* before you began iterating
over B*...
The proper way would be to first produce all possibilities of length n
before giving any possibility of length n+1.
''
'A'
'B'
'AA'
'AB'
'BB'
'AAA'
'AAB'
...
I haven't spent a milisecond of working out whether that's feasible to
implement, but from a theoretical POV it seems like the solution.
Well, I'm not certain there is really a proper way. But sure, your
way is doable.
use Permutations permutations compositions;
# Generate all strings of length $n
method Rule::Group::generate(Int $n) { # Type sprinkles :)
compositions($n, [EMAIL PROTECTED]) == map {
my @rets = map {
$^atom.generate($^n)
} zip(@.atoms, $_);
*permutations([EMAIL PROTECTED])
}
}
How's that for A4 and A6 in a nutshell, implementing an A5 conept? :)
I hope I got it right
For bonus points:
method Rule::Group::generate_all($self:) {
for 1 .. Inf - $i {
yield $_ for $self.generate($i);
}
}
Hmm... I wonder if there's a way of making the basic 'generate' method
lazy too.
--
Piers
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030330
Welcome once again to the gallimaufry that is a Perl 6 summary.
Unfettered this week by the presence of feline distraction we plunge
straight into the crystal clear waters of perk6-internals.
Iterator proof of concept
People must really like Leo Tötsch's Iterator proposal and patch. There
was only one comment about it this week (from Leo, so I'm not sure if it
counts) asking for thoughts about a possible Ref or Reference class.
Anyone?
http://xrl.us/fao
Bonsai
Zach Lipton announced that he has Bonsai up and running on the Parrot
CVS repository. This gives us a shiny new way of looking at the history
of the distribution. Thanks Zach.
http://tinderbox.perl.org/bonsai
BASIC, IMCC and Windows
Clinton A Pierce had problems trying to get IMCC building correctly
under Win32 in order to generate a binary distribution for the win32
platform. He finally brought up a working IMCC on Friday and asked for
comments about what a binary distribution should look like.
http://xrl.us/fap
http://xrl.us/faq
getopt.macro
Inspired by the argument processing in Leon Brocard's uniq(1)
implementation, Jonathan Scott Duff presented a getopt macro for Parrot
programmers. Benjamin Goldberg had a few suggestions about how to make
things a little more flexible.
http://xrl.us/far
Patch to examples/assembly/cat.pasm
Paul Duncan offered a patch to examples/assembly/cat.pasm which would
cause it to terminate when it received a ctrl-D.
http://xrl.us/fas
IMCC and scientific notation
Having got IMCC working in a win32 environment, Clinton A Pierce
discovered that IMCC didn't understand scientific notation, but the
parrot assembler does. Leo Tötsch pointed out that it sort of does, but
instead of 1e20 you have to write 1.e20. Joseph Ryan wondered if
handling scientific notation wasn't really a job for individual
compilers, but Clint and Mark Biggar explained why this wasn't a good
idea. As Mark said, in a world with BigFloats you don't want to have to
expand 1e2048 into a 2049 character string if you can possibly help it.
http://xrl.us/fat
RT spam
Someone claiming to be Marla Hurley crawled out from under a stone and
took it upon themselves to offer credit to the perl6 RT installation.
Thanks. We needed that.
Meanwhile, over in perl6-language
The language list was again busier than the internals list this week,
but volume has fallen on both lists. (If you don't count an off topic
thread on the internals list, which I haven't, there were only 22
messages there this week. And very few patches from Leopold Tötsch, I
hope he's all right.)
is static?
Discussion of static/state variables continued. Arcadi Shehter wondered
if it made sense to attach but properties to closures. I confess I
didn't really understand what he was driving at. Austin Hastings and
Larry saw something in it, and the question shifted to ways of doing
state variable initialization, which in turn led to possible changes in
the various control of flow keywords. As Larry pointed out, if you have
a static variable:
state $variable
Then, assuming that you need 'undef' to be a possible value for your
variable, you need some way of doing once and only one initialization of
that variable.
state $variable;
ONCE_AND_ONLY_ONCE { $variable = $initial_value };
The problem is that INIT and CHECK blocks happen too early; in the code
above, $initial_value may well not be set, if your state variable is set
up inside a closure this becomes even more likely. Larry reckons that
the most useful initialization semantics appear to be 'just in time'. In
other words you want initialization to happen on the first actual call
to a closure. But FIRST {...} is already taken, so Larry is
considering renaming FIRST and LAST to ENTER and LEAVE, freeing up FIRST
to mean my very first time. Freudian analysis was discouraged.
http://xrl.us/fau
Argument initializations
Michael Lazzaro summarized the various different and proposed assignment
operators available in Perl 6, including a proposed ::= for 'only
assign to uninitialized variables'. Michael wondered how these could be
used in method signatures and proposed some changes to the signature
system as set out in Apocalypse 6. People were dubious about this, with
Damian saying I don't think that allowing 20 different types of
assignment in the parameter list of a subroutine actually helps at all.
I'm not sure Michael is convinced yet.
http://xrl.us/fav
P6ML?
Michael Lazzaro asked if anyone was actually working on P6ML (a project
name that popped up last week in the 'XML is too hard for Programmers'
thread) and if there was any idea of what such a project would
Re: This week's Summary
Matthijs van Duin [EMAIL PROTECTED] writes: Apologies for nitpicking, but you misspelled my name as Mattijs 4 times in the summary. The right spelling is Matthijs :-) Argh! Kill me now. Please. Damn, damn and double damn. I say, Simon old chap, you couldn't fix that on the perl.com site could you? Expect an apology in the next summary to go with this one. I'm very, very sorry. -- Piers
Re: list manners question
Paul [EMAIL PROTECTED] writes: Hi all. I note that quite often I find myself wanting to express agreement or disagreement with some point made on the list, but without anything of value to add other than a vote on the matter. When this happens I usually ~try~ to bite my metaphorical tongue and just file the information away while deleting the message, at least until I can contribute meaningfully. I think it's worth saying 'me too' to something if it's sat there with no responses for a couple of days. If only to help the poster (and summarizer, he said selfishly) of the horns of Warnock's Dilemma. If there's ongoing debate then it's unnecessary. -- Piers
This week's Summary
The Perl 6 Summary for the week ending 20030323 Assuming I can tear myself away from stroking the cat who has just magically appeared on my chest and is even now trying to wipe his dags on my nose, welcome one and all to another Perl 6 summary, which should go a lot quicker now that Sully has moved off and let me see the screen. He'll be back though. But before that happens we'll start with perl6-internals. Speed question: save/restore vs push/pop Benjamin Goldberg wondered about how many saves it takes to be slower than one pushx. Steve Fink pointed out that save and pushx are not interchangeable as they push things onto totally different stacks (save pushes onto the generic user stack, pushx push onto type specific register frame stacks). Leo Tötsch ignored this difference (which Ben was apparently aware of) and did some tests which showed that, on his local architecture and core, 2 saves were slower than one push. On Dan's machine, it took 3 saves to be slower than one push. Dan also pointed out that, on some architectures, there's a subtle win with saves because a push would dirty the L1 and L2 caches while the save wouldn't. (On SPARC at least, apparently). http://xrl.us/eth Baby Steps in porting IO to the PIO architecture Last week, Leon Brocard posted his implementation of the uniq(1) Unix utility to PASM. This week, Jürgen Bömmels' ongoing project of moving Parrot's IO operators from the STDIO library to Parrot's own PIO library (which is asynchronous and a combination of lovely and scary by all reports.) broke this because PIO didn't have any read buffering capabilities, which means that the readline op didn't work. On Monday, Jürgen had write buffering working, which Dan applied with alacrity while making noises about needing to finish up the documentation for Parrot's asynchronous IO system. There was some debate on whether a PIO flush should force a write to the disk, or simply ensure that all the buffers were flushed to the OS. Nicholas Clark discussed some issues he'd had with Perl 5.8's PerlIO system, and the need for two different kinds of flush, or more succinctly, the need to distinguish 'flush' from 'sync'. Dan was convinced by this argument and Steve Fink seconded the decision. Then, on Sunday, Jürgen released a patch which got read buffering working. Dan had a few problems with it and the patch hadn't been applied by the end of the week. I'm sure it'll go in like a greased weasel once that's been fixed though. http://xrl.us/eti -- Jürgen adds write buffering http://xrl.us/etj -- Nicholas discusses different types of flush http://xrl.us/etk -- Jürgen adds read buffering PBC Object Files Michael Collins wondered if it might be a good idea to come up with a parrot 'object file' specification. I liked Michael's description of an object file as 'a file that contains compiled instructions plus a section with a table that maps subroutine/constant labels to their corresponding byte offsets within the file.' Leo Tötsch's answer was 'not yet'. Apparently the basic functionality is there but there are some cleanups and a couple of opcodes needed. http://xrl.us/etl Parrot binaries Ask Bjørn Hansen posted to say that he'd been trying to make an RPM .spec file for parrot and had noted the lack of a make install target. He also wondered about the permissions of various files in the distribution, which seem somewhat cockeyed. Steve Fink posted a patch which covered some of this (or at least the make install and RPM issues) with tools which would generate RPMs and asked for comments on his work. Leo Tötsch liked it and offered a couple of suggestions http://xrl.us/etm http://xrl.us/etn -- Steve's working patch Some comments on PDD 14 Big Numbers Mark Biggar, who implemented the original Big* packages for Perl had some suggestions about Parrot's big number handling based on PDD 14. Benjamin Goldberg wondered if it would be a good idea to design our BigInt type so that we could replace the maths engine with a different engine so that users could pick which ever engine they prefer as configuration option, and so that new maths engines could be added without having to make wholesale changes. http://xrl.us/eto 99 bottles of beer on the wall Douglas Hunter appears to have noticed that, up until now, Parrot had lacked a vital program -- one which would output the lyrics to that well known song, *99 Bottles of Beer on the Wall*. So, being a community spirited kind of chap, he implemented just that and posted it to the list. A few people quibbled about his style (unnecessary labels, that sort of thing). Leo Tötsch pointed out, with the aid of some IMCC output that the optimizer caught those issues
Re: is static? -- Question
Matthijs van Duin [EMAIL PROTECTED] writes:
On Sat, Mar 22, 2003 at 10:24:09PM +0200, arcadi shehter wrote:
sub a {
state $x;
my $y;
my sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
will all b refer to the same $z ?
yes, they will
Are you sure about that. If state is declaring a lexically scoped
alias to a property of the block/sub, then each invocation of a will
generate a different block/sub b, which implies that the various b
instances won't share the same $z property.
does it mean that this is legitimate sub a {
state $x;
my $y;
state sub b { state $z ; return $x++ + $y++ + $z++ ; }
return b; # is a \ before b needed?
}
No, since you can't refer to $y in that sub (perl 5 actually allows
you to do that but gives a warning 'Variable %s will not stay
shared' - but I hope perl 6 will simply give a compile-time error)
Personally I would hope that it would correctly close over
$y. Especially if, as you claim, $z would be shared by all values of
b. Otherwise there's no way to get that particular behaviour.
--
Piers
Re: grab-bag questions
David Storrs [EMAIL PROTECTED] writes: Piers, Apologies...I actually put them into one mail deliberately, because I didn't want to burn more mindspace than necessary...people could skim all my questions at once, answer those they were interested in, and be done. I didn't think about how this would impact the summaries. I confess I've been bitten by the 'grab bag' thing before and didn't sit back and notice that, whenever there was such a post, the summary dealing with it got muddy. Your list of questions was the first time I've actually thought about why that was. -- Piers
Re: survey page? [OT, was Re: is static?]
Michael Lazzaro [EMAIL PROTECTED] writes: As much as people hated it, I think the P6 Operators thread was *quite* beneficial. It lead to the saving of ^ xor, and the hyper syntax, and quite a few other improvements, and got things pinned down squarely. I wouldn't mind seeing more of that level of disciplined debate, but it's difficult to pull off. What I hated about the P6 Operators thread was the repetitiveness. And having to summarize it. That was definitely painful. -- Piers
This week's Perl 6 Summary
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://makeashorterlink.com/?O374159D3
http://makeashorterlink.com/?O284219D3 -- the inference subthread
http://makeashorterlink.com/?L294639D3 -- 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://makeashorterlink.com/?Y5A4129D3
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://makeashorterlink.com/?Y1B4229D3 -- temp/let
http://makeashorterlink.com/?H2C4139D3 -- 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://makeashorterlink.com/?U5D4239D3
http://makeashorterlink.com/?Q1E4259D3 -- 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://makeashorterlink.com/?U2F4159D3
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://makeashorterlink.com/?R205539D3
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
Re: A6: Signature zones and such
Brad Hughes [EMAIL PROTECTED] writes: Piers Cawley wrote: [...] Nope, send it to TPF as discussed. It's what I've said in all the summaries after all. I just hope that a chunk of it ends up in Larry's pocket. Does anyone know if TPF is set up to allow earmarked contributions? Dunno. But I'm merely expressing a preference. TPF can do with it what they will. -- Piers
Re: A6: Strict signature checking - was: Complex Parameter Types
Damian Conway [EMAIL PROTECTED] writes:
Austin Hastings wrote:
But what's the vision for p6? My expectation is that the
type-checking stuff will be heavily used
for:
1- Large scale projects.
2- CPAN modules.
I expect that the folks who want to do one-liners will still want to
be
able to say Cperl6 -MCPAN whatever
So the strict bits have to be forgiving of the non-strict
callers.
To me that's a contradiction in terms. Strictness can't be forgiving.
At the risk of stating the obvious, that's the whole point of strictness:
to be strict.
What we're suggesting is that if you want to be non-strict, don't use types.
After all, they're optional.
But, (I hear you say), I may not have a choice! If the Cruel Module
Author chose to use types, then I'm forced to do so too. That's not
Lazy.
And you're right. The module author gets to determine the interface of
their module. And if they determine that that interface will provide
type-safety, then you have to respect that. Just as if they decided
that it would have an OO interface, or would set PRE and POST
conditions on calls, or would only take named arguments.
Because the author of the module is *relying* on that interface to
ensure the correctness of their code; to prevent inappropriate data
being passed to their subroutines. Typing is yet another way in which
they can relax, knowing that the wrong type of data will be headed off
at the (compiler) pass.
To me, the way around this is NOT to force interface contracts down to
some lowest common denominator, but rather to document what is
expected, and then allow the developer to accept responsibility for
stepping on his crank.
Yep. And the way for the client of some module to accept that
responsibility is to put in an explicit conversion.
Of course, a module author could always layer on a 'non strict'
version of the interface that did the type conversions itself before
passing them into the more stringent internals.
But at the bottom, the C++ problem is a problem of its own making --
people want coercion. Just like me. I want coercion. I want the ability
to take advantage of the really nifty, carefully written code available
from dedicated, rigorous hackers like this Conway fellow. But I want to
do it as a slap-dash hack with no thought given to type stuff. How?
By distinguishing a parameter that *requires* a particular type, from
a parameter that *ensures* a particular type (by coercion if
necessary). I've suggested that using Cis copy semantics should
indicate make whatever I'm actually given into one of these, if you
can, whereas reference semantics say this must already be one of
these (by their very nature, since an aliased parameter *is* the
argument).
Alternatively, one might imagine a separate and explicit trait that
specifies that a parameter is allowed to coerce its corresponding
argument to it's own type.
But this would be better. And implementable relatively easily as a
macro if it weren't availabe in the core I would have
thought. Hm... it might be interesting/useful to implement a set of
macros to allow developers to define and export their own traits:
trait foo (...) is ParameterTrait {
COMPILATION_CHECK {...}
RUNTIME_CHECK {...}
}
(There's almost certainly a better syntax available mind).
--
Piers
Re: A6: Signature zones and such
Damian Conway [EMAIL PROTECTED] writes: And don't write off the Perl Foundation yet. TPF is just about to do a survey of what people think they (TPF) should be funding. If you believe Larry and/or myself and/or other members of the design or implementation teams are worth sponsoring, I'd certainly urge you to respond to that survey when it's announced (and, yes, I'll inform the mailing list when that happens). Well... I've finally got my act together and invoice ORA for the summary money that's destined for TPF and I would dearly love to see all of that lump of cash go to Larry. I'd certainly like them to continue to fund the development of Perl 6 if only because I wouldn't have to change that stanza of the summary. -- Piers
Re: A6: Signature zones and such
Simon Cozens [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Piers Cawley) writes: Well... I've finally got my act together and invoice ORA for the summary money that's destined for TPF and I would dearly love to see all of that lump of cash go to Larry. Yay, another attempt to confuse me and ORA's payments division. ;) I'll see what can be done. Nope, send it to TPF as discussed. It's what I've said in all the summaries after all. I just hope that a chunk of it ends up in Larry's pocket. -- Piers
Re: A6: overloading multis on constness of parameters
Joe Gottman [EMAIL PROTECTED] writes:
Will it be possible in perl6 to overload multis on the const-ness of a
parameter, like C++ does? For instance,
multi getX(Foo $self:) returns Int {...} #const version
multi getX(Foo $self: is rw) returns Int is rw {...} #non-const version
If getX were called on a const Foo object then the first getX would be
called, and if it were called on a non-const Foo object the second one would
be.
Speaking of multis and constants, Greg McCarroll wondered on IRC if
this would work:
multi factorial (Int 0) { 1 }
multi factorial (Int $n) { $n * factorial($n-1) }
Disregarding the fact that you should really write that as:
sub factorial (Int $n) {
my multi tail_fac ($result, 0) { $result }
my multi tail_fac ($result, $n) { tail_fac( $result * $n, $n - 1 ) }
tail_fac(1, $n);
}
(Assuming you want to do it recursively that is...)
--
Piers
Re: A6: Signature zones and such
Michael Lazzaro [EMAIL PROTECTED] writes: On Wednesday, March 12, 2003, at 11:14 AM, Damian Conway wrote: Larry wrote: : I agree. As long as it's not Cis slurpy! Of course not. We're trying to encourage the use of line noise, and discourage the use of the long variants, so the long one would have to be Cis slurpificatious. Riiight! Thank-you, General Haig. Of course, Cis variadic (my own preference for the name of this trait) would probably have much the same effect. ;-) Can we get a final answer, for the (documented) record? @list is variadic @list is slurpy @list is greedy @list is slurpificatious @list is slurptacular @list is bloated @list is greedy Anyone? -- Piers
This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030309 Ooh look, it's another of those Perl 6 Summaries where Piers tries to work a gratuitous reference to Leon Brocard into a summary of what's been happening to the Perl 6 development process this week. As tradition dictates, we'll start with all the action from perl6-internals. Object Specs With his great good taste and impeccable timing, Dan Sugalski managed to release his second draft of an Object spec at 22.27 GMT on Sunday March the second. Which meant that, strictly, the root message of this thread doesn't belong in this summary. To which I say 'Tosh!' Brent Dax wondered how this spec coped with classless OO languages like JavaScript and whether such languages would have to fake things with anonymous classes. It seems that faking it is going to the 'right' way. Erik Bagfors asked for a clear example of the difference between attributes and properties, and between class and object variables. Dan didn't actually offer an example, but explained that properties are 'runtime assigned name values pairs that are stuck on a variable', while attributes 'correspond to instance variables or slots in other object systems'. Dave Whipp wondered about the semantics of creation and destruction of objects with a long list of questions. Dan replied that there was a 'Class Spec' forthcoming at some point too. The Object spec concerns itself with 'just the behaviour of objects that already exist'. Some further discussion of this happened in perl6-language, but Dan dragged it back into perl6-internals. I shall follow his example by summarizing those subthreads here, whilst muttering rude words under my breath about people make a poor summarizer's life so hard. Garrett Goebel (not Göbel, as I mistakenly spelt it last week) wondered about serialization and persistence and wondered whether a 'pure Parrot' serialization scheme would be possible, allowing one to serialize Perl, Python, Ruby etc objects at the Parrot level. Dan pointed out that there were freeze and thaw vtable entries for PMCs, and said that he had some 'sketches of necessary core functionality to make it feasible'. It looks like simple 'data objects' will be simple to serialize at the parrot level. Sam Vilain suggested a whole bunch of extra things to be associated with Objects. Dan noted that all of Sam's suggestions were actually things that belonged with Classes rather than objects, with the exception of what Sam referred to as 'associations'. Garret asked for some clarification of what Sam was talking about, tying it to something Sam had said in perl6-language about 'exporting object relationships in a sensible and consistent manner', so Sam did a brain dump which outlined a scheme for persisting almost anything in a language neutral manner (requiring more or less complicity on the part of some languages) with loads of neat ideas in it. Dan liked the ideas, but isn't going to go the whole way (probably). Dan also implied that Parrot's serialize/deserialize methods would make use of the GC system to make sure that everything gets dumped properly, once and only once, solving the problem of cyclic references (YAY! An OO Persistence tool writer writes). Dan released the next iteration of his tentative object spec on Sunday (but a little earlier this time). He and Uri Guttman spent the rest of the day thrashing out some issues and clarifying some terminology. Dan is threatening a glossary with the next try at an object spec. (Dan just suggested on IRC that I summarize these threads as 'Dan muttered incoherently about objects again. Folks generally humored him.' Which I would never do of course; I'm English and I know how to spell 'humour'.) http://makeashorterlink.com/?L22455AA3 -- Object spec (try 2) http://makeashorterlink.com/?M2A2623C3 -- Garrett's first question http://makeashorterlink.com/?M2B2323C3 -- Sam Vilain's suggestions http://makeashorterlink.com/?P2C2323C3 -- Garrett asks for clarity http://makeashorterlink.com/?W2D2523C3 -- Sam's brain dump. http://makeashorterlink.com/?S1E2213C3 -- Object Spec (try 3) IMCC and multiple source files K Stol wondered whether it was possible to write multi-file IMCC programs. Leopold Tötsch answered that, whilst there's no Parrot linker as yet, but by the time we read his post we could use the .include macro to glue source files together. http://makeashorterlink.com/?A5F2213C3 Patch Roundup Jason Gloudon added some more ops to the sun4 JIT core. His patch was applied, along with most of Steve Peters' patches from last week. Jürgen Bömmels patched the print ops to use pure PIO (Parrot IO) rather than a scary stdio/PIO hybrid. Dan applied this one with alacrity (I
Apo 6: Typo in grammar
Larry says that
sub foo { ... }
is equivalent to
sub foo will do {...}
But then goes on to give the grammar for subroutine definitions as:
rule lexicalsub :w {
lexscope type?
subintro subname psignature?
trait*
block
}
rule packagesub :w {
subintro subname psignature?
trait*
block
}
rule anonsub :w {
subintro psignature?
trait*
block
}
which won't match C sub foo will do { ... } . I presume this is
another of those cases where the rules should be:
rule lexicalsub :w {
lexscope type?
subintro subname psignature?
trait*
block?
}
rule packagesub :w {
subintro subname psignature?
trait*
block?
}
rule anonsub :w {
subintro psignature?
trait*
block?
}
and rely on semantic analysis to catch the error and throw a sensible
exception?
--
Piers
Re: Object spec
Garrett Goebel [EMAIL PROTECTED] writes: Several people have mentioned a desire to see Perl6 and Parrot facilitate object persistence. Should such issues be tackled in Parrot? Will there ever be a Parrot Object Database that we can serialize our Perl, Python and Ruby objects into, to be used at some later date in code written in Jako? If an appropriate parrot topic, I'd be especially interested to hear the thoughts of people like Sam Vilain, Dave Rolsky, Piers Cawley, and others who've already spent a great deal of tuits tackling these issues. All I want is good object serialization. So I can say to an object 'write yourself to this stream' and have that do the right thing (ie, all the objects that are reachable from an object are serialized before that object, with any cycles broken. It's not much. The trick is defining the protocol of our stream classes so that we capture enough information. For bonus points it would be nice to be able to serialize a class so that one could send an object of an arbitrary class down a stream and know that, even if the object is later deserialized in a system which doesn't have the appropriate modules the object can still work. But that's probably something you'd do in a stream filter. Oh yeah, and 'Object' should have an Cinstantiate_from($stream) method, or what would be the point? Once I have a simple, stream based serialize/deserialize mechanism it's relatively easy to add pretty much any datastore management mechanism I want on top of it. Oh yeah, for extra bonus points, I'd like to be able to override the way Perl manipulates instance variables so I can track whether an object is modified during its 'in memory' time, that way I can write a storage system that's efficient about which objects it writes back to the database on a commit. (I can work scary mojo with having every object carry 'round a flattened copy of its old self, but that's rather expensive...) Note that I only need to do this when a database manager is in place, and I only need the override on unmodified, managed objects. Most of this stuff is available, at a cost (to both speed and programmer sanity) in Perl right now, but I really, really want nice interfaces. -- Piers
This week's summary
The Perl 6 Summary for the week ending 20030302
Welcome back to another episode in the ongoing saga that is the Perl 6
development process (or at least my attempt to describe it).
We kick off with perl6-internals.
IMCC calling conventions
Piers Cawley attempted to describe tail call optimizations, why they
were a good thing and why a caller saves calling convention made such
optimizations easier (possible?). He wondered if he hadn't just
succeeded in muddying the waters still further. Jerome Vouillon appeared
to understand what Piers was going on about and pointed out that a
caller saves scheme also helps with exception handling. Benjamin
Goldberg wondered about Perl 5's goto func semantics which can be
looked at as a 'sort of' tail call (except you don't actually get much
of an optimization with Perl 5 as it stands) and proposed a callee saves
scheme for doing tail call optimization which didn't optimize away an
unnecessary pair of save/restores. Dan pointed out that, while goto
func (which is sort of like tail call optimization in Perl 5) would
have to be supported, tail call optimization made more sense if you
didn't have to use any special syntax to make use of it.
http://makeashorterlink.com/?J18326AA3
A couple of easy questions...
David (Cuny?) wondered how he could determine the data type of an
arbitrary PMC and whether there were any pre-built Windows binaries of
Parrot available. Leon Brocard pointed him at the typeof operator in
answer to the first question but punted on the second. Leo Tötsch also
pointed at typeof. David noted that it didn't seem to be available in
his 0.0.9 installation and was recommended to use the CVS version, and
discussion drifted toward wondering when Parrot 0.1.0 would see the
light of day. (Not before at least one of either objects or exceptions
is implemented apparently).
Nobody answered the 'pre built Windows binary' part of David's question.
http://makeashorterlink.com/?I59315AA3
More on optimizing the JIT with IMCC
In last week's summary I mentioned that Sean O'Rourke had suggested
getting IMCC to store a control flow graph in bytecode, which the JIT
could use to optimize things more effectively. Sean read this and
pointed out that it wasn't his idea but was actually an area of active
research and gave a pointer to some information. He also pointed to a
USENIX paper which discussed adding a full data-flow compiler into a JVM
which could then generate code that ran faster than a lightweight JIT,
especially for long-running programs. Sean's original link was to a
subscription only site but Jason 'Research wants to be free' Gloudon
found a public version of the paper. Dan was fascinated, but was worried
about availability of engineering time, not wishing to presume on Leo,
Daniel and everyone who's done JIT work.
Dan said that he'd 'rather have a lower-overhead JIT with a win for
shorter programs than a high-overhead one with a win for long-running
programs'. Leo pointed out that, at the moment we already have a high
overhead JIT with most of the cost paid at load time and showed some of
these costs. Dan and Leo then discussed what kind of metadata would be
needed from IMCC (or some external tool) in order to improve matters.
Meanwhile, the original 'Using IMCC as JIT optimizer' thread continued
as Leo committed some more changes both to code and to the documentation
in jit.pod. The new version of the JIT optimizing IMCC should be
platform independent and apparently runs 95% of Parrot's tests on an
i386.
Phil Hassey wondered why we even had a set number of registers in the
JVM in the first place. He wondered if it would be possible to have each
block of code declare 'I need 12 registers for this bloc' and let the
JIT system do the appropriate register spilling magic with the system
registers. Leo said that this is approximately what the JIT optimizer
does at the moment and outlined some of the problems associated with it.
Angel Faus had some questions and suggestions about the optimization
approach that Leo was taking, with particular reference to the amount of
copies to and from memory and proposed an efficient way forward.
Nicholas Clark wondered if some of Angel's suggestions mean that imc
(IMCC source code) had now usurped the role of parrot bytecode and
muttered something about premature optimization and the lack of objects,
exceptions, IO or a Z-code interpreter. Leo bridled slightly at
'premature optimization' and wondered what was important about a Z-code
interpreter ('Z-code interpreter' is, according to Nicholas, 'obfuscated
shorthand for dynamic opcode libraries and reading foreign
bytecode.')
Toward the end of the week, Leo checked in a final patch related
This week's summary
The Perl 6 summary for the week ending 20030223 Another week, another Perl 6 Summary, in which you'll find gratuitous mentions of Leon Brocard, awed descriptions of what Leopold Tötsch got up to and maybe even a summary of what's been happening in Perl 6 design and development. Kicking off with perl6-internals as usual. Strings and header reuse Dan responded to prompting from Leo Tötsch about the use and reuse of string headers. The problem is that most of the string functions that produce modified strings do it in new string headers; there's no way of reusing existing string headers. This can end up generating loads of garbage. Dan's going through the various string handling ops and PMC interfaces working out what needs to do what, and documenting them, as well as adding in versions of the ops that take their destination string headers as an argument. Dan hopes that 'we can make the changes quickly and get this out of the way once and for all', leading Robert Spier to mutter something about 'famous last words'. http://makeashorterlink.com/?Z13621793 PXS help Tupshin Harper has been trying to use an XML parser from within Parrot and started off by looking at the PXS example (in examples/pxs) but had problems following the instructions given there as his compiler spat out errors by the bucket load. Leo Tötsch thought that PXS was probably deprecated and the native call interface (NCI) was the thing to use. Being Leo, he provided a port of the PXS Qt example to NCI. Although PXS appears to be out of sync with the parrot core, nobody was entirely sure whether it should be removed. http://makeashorterlink.com/?V14632793 Bit rot in parrot/language/* Tupshin Harper had some problems with some of the language examples not working well with the most recent versions of Parrot. Leo Tötsch addressed most of the issues he raised, but there are definitely issues with the interpreter and the languages getting out of sync. http://makeashorterlink.com/?O55624793 http://makeashorterlink.com/?S26652793 Macros in IMCC (part 2) Jürgen Bömmels extended the macro support in IMCC, implementing .constant and adding some docs. The patch was promptly applied. http://makeashorterlink.com/?G17656793 [RFD] IMCC calling conventions Leo Tötsch posted an RFD covering his understanding of the various calling conventions that IMCC would have to deal with which sparked some discussion. I'm now confused as to whether function calls in Parrot will be caller saves, callee saves, or some unholy mixture of the two. http://makeashorterlink.com/?F68641793 Parrot performance vs the good, the bad and the ugly Tupshin Harper decided to port primes.pasm to C and Perl 5 to compare results. Parrot came out very quick indeed. (Close to C). For bonus points he then took a python primes algorithm that had been ported to C and ported that to Parrot as well. In full on, all stops pulled out, knobs turned to 11 mode, Parrot came in at about 50% slower than C and around 14 times faster than Python. There was some muttering about the demo being rigged. However, Jim Meyer redid the Perl and Python implementations to use a loop that duplicated the algorithm used in primes.pasm and, whilst it improved their performance somewhat, Parrot was still substantially faster. This probably won't be the test that's run when Dan and Guido face the possibility of custard pies at 10 paces or whatever the performance challenge stake stands at now. http://makeashorterlink.com/?I29621793 Mmm... spaceships... Leon Brocard patched examples/assembly/life.pasm to use a small spaceship as its starting pattern. Apparently because it 'can provide hours of enjoyment at conferences if projected onto a big screen while answering parrot questions.' Nobody thought to ask him how a spaceship was going to answer Parrot questions, but Leo Tötsch applied the patch. http://makeashorterlink.com/?X2A613793 Using IMCC as JIT optimizer Apparently, Leo Tötsch finds it unbearable that 'optimized compiled C is still faster than parrot -j' so he's been experimenting with adding smarts to IMCC, making it add hardware register allocation hints to its emitted bytecode. Sean O'Rourke liked the basic idea, but reckoned that the information generated by IMCC should really be platform-independent, suggesting that it'd be okay to pass a control flow graph to the JIT, but that hardware register allocation for a specific number of registers would iffy. He suggested that another option would be for IMCC to 'just rank the Parrot registers in order of decreasing spill cost', then the JIT could just move the most important parrot registers into architectural registers. Dan thought the idea was
This week's Perl 6 Summary
The Perl 6 summary for the week ending 20030216
Welcome to the all new, entirely unaltered, all singing, all dancing
Perl 6 summary. Your beacon of reliability in the crazy world that is
Perl 6 design and development.
Another quiet week. Even quieter than last week in fact, unless my mail
spent some of the time up the spout, but I don't think so.
So, as is traditional, we kick off with perl6-internals
CGP - The Computed Goto Prederefed Runloop
Last week I mentioned that nobody seemed to have commented on Dan's bet
with Guido van Rossum that Parrot would outperform Python by OSCON 2004.
(I also missed the fact that the penalty for losing the bet now involves
cream pies as well as $10 and a round of drinks...). After I posted the
summary to the mailing lists, Leopold Tötsch informed me that he had
commented indirectly by announcing his new, improved, ludicrously quick
runloop that combines computed GOTOs and predereferencing. Whatever that
means.
This week, Leo and Nicholas Clark worked out how to combine the
blistering pace of the JIT core (for operations that had been translated
into hand hacked machine code) with the blistering pace of the CGP
runloop (for the other ops). As far as I can tell, this involved turning
the idea 'inside out', the VM actually starts up running JIT compiled
code and calls out to the CGP core to execute non-JITable sequences of
ops. The numbers for this approach look fantastic (quite stunningly
quick...) So Leo checked it in.
http://makeashorterlink.com/?Y27C12083
http://makeashorterlink.com/?Q48C22083 -- Some numbers
http://makeashorterlink.com/?G19C21083 -- Check in notice
Optimized runloops and threading issues
Last week we were reminded that JIT and predereferenced runloops don't
work in a threaded environment. This week Jerome Vouillon pointed out an
approach that looks like it could fix that (it seemed to convince Leo).
Dan (possibly playing mail catchup) said he was okay with having to fall
back to the old fast core (as opposed to the current, stupidly fast
core) in the presence of threads, but Leo seem to think that, using
Jerome's scheme we'll be able to have our cake, eat it and still throw
the cream pie at the Python team. Huzzah!
http://makeashorterlink.com/?P2AC23083
keyed_int issues
Leo Tötsch had wondered about why {get,set}_type_keyed_int vtable
methods needed to take an INTVAL* value instead of a plain INTVAL as
it introduced some possibly unneeded conditional code, a stack variable
for the key and made life hard for JIT code. It looks like the pointer
is a holdover from an early approach to doing multidimensional keyed
structures.
http://makeashorterlink.com/?W2BC32083
Changes to the calling convention and other fallout
Dan returned from the Sebastapol Perl 6 meeting with a few announcements
and one change in the parrot calling convention (how many calling
conventions have we had now?).
http://makeashorterlink.com/?N2CC62083
Macro support in IMCC
Jürgen Bömmels announced that he'd implemented macro expansion in IMCC
(Yay Jürgen!). Leo liked it, but requested a few changes before he'd
check it in, so hopefully, some time soon the mainline IMCC will have
macros, which is very nice.
http://makeashorterlink.com/?A2DC15083
Meanwhile, in perl6-language
Almost all the discussion was about the difference between arrays and
lists. Deborah Ariel Pickett came up with a good list of questions about
arrays and array references in scalar and list contexts, which Michael
Lazzaro answered (very neatly I thought) with a list of their different
contextual behaviours. Deborah extended Michael's list to hashes and
hashrefs in a reasonably obvious way. Smylers came up with a possible
new sigquote (after paraphrasing): We should limit new features to
those that arise from a desire for the functionality rather than a
desire to use up 'spare' syntax. (Okay, it's not exactly *snappy*, but
I think it's important).
http://makeashorterlink.com/?H1EC23083 -- Deborah's questions
http://makeashorterlink.com/?C1FC42083 -- Michael's answers
And that wraps it up for the language list. I'm sure it'll pick up again
soon though. There are rumours of a draft apocalypse in the next couple
of weeks, and presumably that implies a real apocalypse soon after.
Assuming we haven't had another kind of Apocalypse in the mean time.
Announcements, Acknowledgements and AnotherWordBeginningWithA
This week's summary was again prepared in the comfy chair with
surprisingly few distractions apart from the late arrival of mail from
Leon Brocard announcing that he'd implemented a brainf*ck compiler in
brainf*ck, but that didn't really happen this week so I've got no excuse
for mentioning Leon's name in this
Re: Language Discussion Summaries
Smylers [EMAIL PROTECTED] writes: Miko O'Sullivan wrote: The idea of discussion summaries has been well received, ... I read this thread over the past couple of days. It's only today that, having thought about it, an objection occurred to me. I've no problem with people summarizing threads, but with this bit: The summaries will be located at http://www.idocs.com/perl6/ Why? I read the Perl 6 language list with a news-reader, which conveniently shows new articles when it's run. People subscribed to read this by e-mail get similar service. I don't want to have to remember to check a webpage on a regular basis just to see if anything new has cropped up there. Couldn't thread summaries just be sent to this list? Piers would almost certainly link to them in his weekly summaries -- he has done previously when people, most notably MikeL, have posted ad hoc summaries of particular topics. That's definitely a good idea. With the added advantage that, if a reader wants, the whole thread is immediately accessible for further investigation. -- Piers
Re: Arrays: Default Values
Rick Delaney [EMAIL PROTECTED] writes: I'd also like to point out that ruby has defaults for hashes but assigning nil (the equivalent of undef) does not set the default; delete does. Yeah, but Hashes aren't Arrays. And vice versa. -- Piers
Re: Arrays: Default Values
Aaron Sherman [EMAIL PROTECTED] writes:
On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
Can someone give me a realish world example of when you would want an
array that can store both undefined values and default values and those
values are different?
my @send_partner_email is default(1);
while $websignups.getline {
($id) = /UserID: (\d+)/;
if /Source: External DB With No Privacy Policy/ {
@send_partner_email[$id] = undef; # No answer given
} elsif /Spam Me: Yes/ {
@send_partner_email[$id] = 1;
} else {
@send_partner_email[$id] = 0;
}
}
# If you were not in the websignups list, you signed up before privacy
# policy, so we spam you (default=1)
In this case, there's a true shrug answer, which is hard to deal with.
We need to do something later on with the undefined case (no answer was
given, and no spam warning issued). This sort of logic deferral is
common to many uses of undefined values (or NULL) in databases, even
when columns have defaults that are non-null.
In this case surely you're better off doing this with a state object.
class UnspecifiedState {
method maybe_send_mail($user) { go_get_more_info }
}
class SendMailState {
method maybe_send_mail($user) { generate_and_send_mail_to($user) }
}
class NoSendMailState {
method maybe_send_mail($user) { }
}
my @send_partner_email is default(SendMailState.new);
while $websignups.getline {
($id) = /UserId: (\d+)/;
when /Source: External DB With No Privacy Policy/ {
@send_partner_email[$id] = UnspecifiedState.new;
}
when /Spam Me: Yes/ {
@send_partner_email[$id] = SendMailState.new;
}
otherwise {
@send_partner_email[$id] = NoSendMailState.new;
}
}
in other words, when you have to deal with tristate logic, make it
explicit tri state logic.
--
Piers
Re: Language Discussion Summaries
Allison Randal [EMAIL PROTECTED] writes: Miko O'Sullivan wrote: Therefore, I propose that members of the language list provide summaries of the discussions in the group. Each summary describes a proposed idea feature of the language, then summarizes the list's feelings on the idea. Different opinions will be presented. The summaries will also attempt to provide a feeling for the weight of opinion, e.g., most people felt this way, some people felt differently, etc. The summaries will also link to the original threads so that readers can peruse the raw data. Go for it. It might not catch on, but it's worth a try. Keep in mind that Piers' summaries already cover a good part of this, but if you do it right you might make his job easier. :) Hell yes. Actually my summaries run on a different 'clock' to thread summaries; I'd expect thread summaries to get written after a given thread has pretty much died down (or at least started repeating itself too often) whereas my summaries get produced to a weekly timetable, which isn't necessarily the same as the threads (see the last few summaries where the same thread has appeared repeatedly) -- Piers
Re: arrays, hashes unified indexing syntax impact on futurevariat ion s on other collection types [x-bayes]
Garrett Goebel [EMAIL PROTECTED] writes:
From: Piers Cawley [mailto:[EMAIL PROTECTED]]
Garrett Goebel [EMAIL PROTECTED] writes:
And what's to prevent that collection object from handling:
my $queue = SomeQueue.new;
$queue.push('foo');
$queue.push('bar');
$queue.push('baz');
my $index_of_foo = $queue['foo']; # undef if no foo in queue.
Because I also want to be able to access
$nth_foo = $queue[$n]
Which I thought was so blindingly obvious as not to need stating.
Never underestimate blindingly obvious when I'm involved ;)
$idx_of_foo = $queue['foo']; # named lookup
$nth_foo= $queue[600]; # ordered lookup
One is SvPOK the other SvIOK...
Can't we handle both and still have the ordered lookup be fast?
No. Because in general we don't know what's in the brackets until
runtime. And then we don't know in what context to evaluate what's in
the brackets. Because, in Perl unlike in many other OO languages that
don't have a syntactic distinction between array and hash lookup, a
value can happily have both a numeric *and* a non-numeric value. Which
means that YOU CAN'T USE THE TYPE OF THE 'INDEX' OBJECT TO DETERMINE
WHETHER YOU'RE DOING A HASHLIKE OR AN ARRAYLIKE LOOKUP. As Dan pointed
out ages ago. The only reason I suggested that it didn't matter was
because I'd forgotten about the cases where having both arraylike and
hashlike behaviour was useful.
--
Piers
Re: More Array Behaviors
Damian Conway [EMAIL PROTECTED] writes: Dave Whipp wrote: OK, I've assimilated all that (though it still feels wrong). I think you are saying that of the following, the 4th is an error. my @d = @x but Foo; # error: no values involved in this assignment Correct. Although presumably this: my @d = @x »but« Foo; is okay. I think that the thing that confused is that Cis Vs Cbut distinction was introduced as compile-time vs run-time. It seems that this distinction is not relevant. Let's say it's an approximation to the true. Lets see if I apply this to objects. Objects are variables Yes. (they contain attributes). Yes. All access to objects is via (scalar) references: Yes. these references, being values, can have Cbut properties. Yes. When a method is invoked on an object, that method has an invocant, which enables the method to see the Cbut properties on that reference. Yes. If an object wants to have properties that apply to all references (to a given instance), then that property must be defined as an attribute of the object. Yes. At least, for the new opaque objects. Because there's no way to ascribe the necessary Cis property to them. Bugger. I was hoping that Perl 6 was going to make a Pixie like Object database easier to write; looks like I'm wrong. One of the things Pixie does is to attach its control data by magic to the object itself (rather than any particular variable pointing to it). This lets us do all sorts of useful stuff without invading the object since we know that it will carry our metadata around it. Please, consider making but properties attach to the target of a pointer rather than to the pointer itself. And if you don't want to do that, I'd say that there is a need to be able to specify some new kind of property that does attach to the target. -- Piers
Re: Spare brackets :-)
Damian Conway [EMAIL PROTECTED] writes:
This may sound like a silly idea
It's been suggested previously.
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?
Yes. We rejected the idea.
In particular, it would seem that
%foo[$key]
would be just as easy for the compiler to grok as
%foo{$key}
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Decided at runtime?
--
Piers
Re: More Array Behaviors
Dan Sugalski [EMAIL PROTECTED] writes: At 8:46 AM + 1/28/03, Piers Cawley wrote: Bugger. I was hoping that Perl 6 was going to make a Pixie like Object database easier to write; looks like I'm wrong. One of the things Pixie does is to attach its control data by magic to the object itself (rather than any particular variable pointing to it). This lets us do all sorts of useful stuff without invading the object since we know that it will carry our metadata around it. Please, consider making but properties attach to the target of a pointer rather than to the pointer itself. And if you don't want to do that, I'd say that there is a need to be able to specify some new kind of property that does attach to the target. Given the current implementation (And I hear rumors that you lurk on the internals list, Piers... :) Nah, that's someone else with the same name and writing style. I think we can manage something like this. Might require a drop to assembly somewhere, perhaps hidden behind a function rather than with syntax, but it should be doable... Breaths sigh of relief -- Piers
Re: Spare brackets :-)
Dan Sugalski [EMAIL PROTECTED] writes: At 8:47 AM + 1/28/03, Piers Cawley wrote: Damian Conway [EMAIL PROTECTED] writes: Sure. But then is this: $ref[$key] an array or hash look-up??? Decided at runtime? How? People use strings as array indices and ints/floats as hash indices, and count on autoconversion to Make It Work. Nope. The count on the fact that, at runtime you'll know whether $ref is a hash or an array. But I'm not actually arguing for this, just pointing out that it's not necessarily impossible (just way harder to optimize). -- Piers
Re: More Array Behaviors
Damian Conway [EMAIL PROTECTED] writes:
Piers Cawley wrote:
Bugger. I was hoping that Perl 6 was going to make a Pixie like Object
database easier to write; looks like I'm wrong. One of the things
Pixie does is to attach its control data by magic to the object itself
(rather than any particular variable pointing to it). This lets us do
all sorts of useful stuff without invading the object since we know
that it will carry our metadata around it. Please, consider making
but properties attach to the target of a pointer rather than to the
pointer itself.
Errno. That's rather the whole point of Cbut properties [*].
However, if your class returns a reference to an object and that reference
has the appropriate value properties ascribed to it (i.e. stuck on the
*reference*), then any access through that reference (or through any
subsequent copy of it) will see those properties.
So your magic Pixie would look something like
class Pixie {
method new($class: %args) {
return $class.SUPER::new(%args)
but Magic('whatever');
}
# etc.
}
[*] People, we just *have* to find better names for these things!
I'd suggest we henceforth call them value properties (for Cbut)
and referent properties (for Cis).
Hmm... Here's Pixie's interface:
my $pixie = Pixie.new.connect('dbi:foo:bar', $user, $pass);
...
my $cookie = $pixie.insert($some_arbitrary_object);
# Time passes, we forget everything but the value of $cookie
my $pixie = Pixie.new.connect('dbi:foo:bar', $user, $pass);
my $locked_object =
$pixie.get_with_locking_strategy( $cookie,
Strategy::ExclusiveLock.new );
When $locked_object is collected, Pixie unlocks it in the
database. If, while $locked_object is in scope something else tries to
fetch an object with the same cookie (from within the same thread)
then Pixie hands 'em a reference to the same object. Right now Pixie
keeps a handle on everything by attaching 'ObjectInfo' objects to
every object that comes under its control so it can keep track of
what's going on (it's a two way link, the object has a normal ref
(via magic) to the objectinfo, which has a weakref back to the object
itself, so when the object goes out of scope, the objectinfo goes out
of scope too, triggering unlocking and other such stuff).
So, if Pixie::get_with_locking_strategy looks something like:
method get_with_locking_strategy( $self: $oid,
Strategy $lock_strategy ) {
return $self.cache_get($oid);
CATCH Exception::NotInCache {
my $flattened_object =
$self.store.get_with_locking_strategy($oid, $lock_strategy);
my $obj_info = ObjectInfo.new.set_pixie($self)
.set_oid($oid)
.set_lock_strategy($lock_strategy);
my $real_obj =
Storable::retrieve($flattened_object) but PixieInfo($obj_info);
$obj_info.set_real_object($real_obj);
$self.cache_insert($obj_info);
return $real_obj;
}
}
method cache_get( $oid ) {
my $info = %.cache{$oid} // die Exception::NotInCache.new;
return $info.real_object;
}
Will every copy of the value of $real_obj have the PixieInfo property?
Am I going mad, or is order really that important? My initial idea was
to do the Cset_real_object and Ccache_insert and then just do
Creturn $real_obj but PixieInfo($obj_info), but then, if I
understand you correctly, the Info object's back reference to the real
object wouldn't have a PixieInfo property, which would in turn mean
that cache_get's return value wouldn't have the property and Bad
Things would happen. It seems counterintuitive that the order of
operations in this case should be so important.
Or am I missing something?
--
Piers
Re: A proposal for separable verbs.
Austin Hastings [EMAIL PROTECTED] writes:
--- Joseph F. Ryan [EMAIL PROTECTED] wrote:
If the final design stays the way it is now, there really won't be
a lexer. Instead, a perl6 grammar parses the data, and builds up
a huge match-object as it, well, matches. This match object is then
munged into the optree.
With this in mind, I'll say it again:
Let's support separable verbs.
Here's how:
# Note my arbitrary selection of _ as separation indicator. Feel free
to replace this with something more appropriate:
sub if($test, block)
_ elsif ($test, block) is optional is floating is multi
_ elsunless ($test, block) is optional is floating is multi
_ else (block) is optional is fixed
{
while (!$args[0].test) shift;
args[0].block();
}
Mmm... Smalltalk style message specifiers here we come...
method Bool::ifTrue (trueBlock) _ ifFalse (falseBlock);
($a == $b).ifTrue { do_this() }
ifFalse { do_that() }
I really like this idea or something like it.
--
Piers
This week's Perl 6 Summary
that Graham had some interesting things to say about language design. The discussion that followed was mostly off topic (in the sense that they weren't talking at all about Perl 6). Graham's paper is interesting though. http://makeashorterlink.com/?L2C516D33 http://paulgraham.com/arcll1.html Array/Colon question Michael Lazzaro wondered about the seemingly different meanings of colon in: print $FH : $a;# $FH is an indirect object @a = 0 .. 10 : 2; # @a is (0,2,4,6,8,10) and wanted to know when : meant 'step' and when it designated an indirect object. Brent Dax helped clear things up. Essentially : is a 'supercomma' and different operators and functions interpret what comes after the supercomma in different ways. .. treats it as specifying a step. http://makeashorterlink.com/?Q1D521D33 Multiple Dispatch by Context? Piers Cawley wondered if it would be possible to specify a multimethod by context as well as by parameter types. Dan Sugalski managed to hole the proposal below the waterline with a neat set of multidispatch declarations that led to a horrible ambiguity. Thomas A Boyer pointed out that Ada can handle such ambiguities but that it was a complete pain to implement and voted against using return type for multiple dispatch. http://makeashorterlink.com/?B5E525D33 Who's Who in Perl 6 Ah... um... I appear to be lacking an answer set this week. Announcements, Acknowledgements and Apologies I'm afraid to have to announce that, as of this week I can no longer donate the fee for these summaries to the Perl Foundation it's currently my only source of income. On the positive side, now that I don't have to spend 8 hours a day working for someone else I should be able to get the Summary mailed out to the Perl 6 lists on a Monday from now on. Thanks to everyone who sent me mail about my redundancy. No matter how good it feels not to have to get up at 5.50 every morning with the prospect of not getting home again 'til at least 18.40 it's still a terrible shock to lose your job. Thankfully we look to be in a much better position this year than we were last time I was out of work; I'm hoping that, if I can get a few more freelance writing gigs and maybe a little consultancy I'm not going to have to go back to the 4 hour commutes for the foreseeable future. Thanks too to everyone who's given me answers for the Who's Who section since this summary started. I'm sorry to be retiring it for now, but as new blood filters into the Perl 6 community I hope I'll be able to restart it some time further down the road. If you appreciated this summary, please consider one or more of the following options: * Send money to the Perl Foundation at http://donate.perl-foundation.org/ and help support the ongoing development of Perl * Get involved in the Perl 6 process. The mailing lists are open to all. http://dev.perl.org/perl6/ and http://www.parrotcode.org/ are good starting points with links to the appropriate mailing lists. * Send feedback, flames, money, job offers or concrete proof either way about Iraq's weaponry to [EMAIL PROTECTED] -- Piers
Re: Arc: An Unfinished Dialect of Lisp
Adam Turoff [EMAIL PROTECTED] writes: On Wed, Jan 22, 2003 at 10:16:50AM +, Andy Wardley wrote: On Tue, Jan 21, 2003 at 12:55:56PM -0800, Rich Morin wrote: I'm not a Lisp enthusiast, by and large, but I think he makes some interesting observations on language design. Take a look if you're feeling adventurous... I can't help feeling slightly deflated. Given the chance to re-design Lisp from scratch, the tasks on the top of my TODO list to address would be: * getting rid of some/all those damn parenthesis * renaming cons/car/cdr to something meaningful Alas, these are about the only parts he's not changing. He promises that Arc will have a syntax one day, but there isn't one yet. These slides are over a year old. There hasn't been much of Arc since Paul Graham's early musings on it. But one of the things he did do was rename lambda to fn. This is proof that the holy grails can be tossed out of the window. The problem with cons/car/cdr is that they're fundemental operations. Graham *has* learned from perl, and is receptive to the idea that fundemental operators should be huffman encoded (lambda - fn). It would be easy to simply rename car/cdr to first/rest, but that loses the huffman nature of car/cdr. ISTR that he was also a fan on the 'composibility' of car and cdr, giving operators like (caar list), which means (car (car list)). I can see where he's coming from, but I can also see that those tricks could also be dismissed as clever dickery.
Multimethod/multisub thought...
In my quest to eliminate as many explicit conditionals from my code as
possible, I found myself wondering if Perl 6's multidispatch mechanism
would allow one to write:
sub gmttime ( $time = time() ) is in_scalar_context {
strftime( $perls_default_time_format, $time );
}
sub gmttime ( $time = time() ) is in_list_context {
...
}
where 'in_scalar_context' and 'in_list_context' are place holders for
better syntax.
Thoughts?
Re: Why Cmap needs work
David Storrs [EMAIL PROTECTED] writes:
On Tue, Jan 21, 2003 at 03:52:30PM -0800, Dave Whipp wrote:
$a = sub ($a, $b) { ... }
$x = - ($y, $z) { ... }
The pointy-arrow doesn't buy anything here.
IMHO, it's actually a loss. I have yet to come up with any mnemonic
for pointy arrow means sub that will actually stick in my brain.
Every time I see this construct, I have to stop in my tracks and
mentally flip through the reference manual.
Personally, I think it looks a bit like a lambda on its side (and if
we're going to have unicode operators then I'd not be unhappy to see
'real lambda' being an equivalent to '-'.
--
Piers
Re: L2R/R2L syntax
Graham Barr [EMAIL PROTECTED] writes:
On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
What benefit does C ~ bring to the language?
Again, it provides not just a null operator between to calls, but
rather a rewrite of method call syntax. So:
map {...} ~ grep {...} ~ @boing;
is not:
map {...} grep {...} @boing;
But rather:
@boing.map({...}).grep({...});
This is not a for or against, but there is something that has been
bugging me about this.
Currently in Perl5 it is possible to create a sub that has map/grep-like
syntax, take a look at List::Util
If the function form of map/grep were to be removed, which has been
suggested, and the ~ form maps to methods. How would you go about
defining a utility module similar to List::Util that uses the same
syntax as map/grep but without making the subs methods on the global
ARRAY package ?
Well, I very much hope that the function form won't be going away;
functional style is bloody useful dammit and I don't want to be forced
to add line noise just to make those who have a woody for
orthogonality happy. Anyhoo, if it *does* go away, then it should be
possible to set up an appropriate set of multiply dispatched generic
functions.
sub reduce ( block, $init, *@array ) is multi {
@array.reduce(block, $init);
}
sub reduce ( block, $init, Collection $collection ) is multi {
$collection.reduce(block, $init);
}
sub reduce ( $expr is qr/Perl::term/,
$init, *@array ) is immediate, is multi {
@array.reduce( $expr, $init);
}
sub reduce ( $expr is qr/Perl::term/,
$init, Collection $collection ) is immediate, is multi
{
$collection.reduce($expr, $init);
}
Though I'm sure Damian will be long eventually to correct my
syntax. I'm getting this weird feeling of deja vu though...
--
Piers
Re: TPF donations
David Storrs [EMAIL PROTECTED] writes: On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote: Paul Johnson wrote: Well, I'll be pretty interested to discover what cause is deemed more deserving than Larry, Perl 6 or Parrot. The P still stands for Perl, right? True. But I suspect that TPF's position is that, to many people, Perl 6 is far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL, or Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or any of a hundred other projects on which their job depends on a daily basis. Supporting those efforts is important too, and TPF has only limited resources. Correct me if I'm wrong, but isn't the one thing that all those projects have in common...well...Perl? And isn't Larry the guy to whom we owe the existence of Perl? I'm not fortunate enough to be using Perl in my job, but I'm still more than happy to pony up for a donation, purely from gratitude. This is something along the lines of the applied research vs basic research question. What Larry is doing pretty much amounts to basic research that will help all of these other projects in the long run. I shall certainly be thinking long and hard about passing the perl.com payments to TPF if Larry's not being funded this year (if I should become a member of the copious free time club there'll be no thought necessary I'm afraid, income is income). Which reminds me, I need to check (as I have naively assumed) that the money is automagically being paid to TPF without my having to muck about with invoices and the like. Hmm... Seriously, I think that not putting some funding Larry's way is a big mistake. I'm not saying he should be the only recipient of funds, but he *is* a special case.
Re: L2R/R2L syntax
Michael Lazzaro [EMAIL PROTECTED] writes: On Tuesday, January 21, 2003, at 12:26 PM, Piers Cawley wrote: Though I'm sure Damian will be long eventually to correct my syntax. I'm getting this weird feeling of deja vu though... When I come home from work each day, I can see my dog eagerly waiting at the window, just black snout and frenetically wagging tail visible over the sill. I often think Larry and Damian must feel that way about this group. Poor, comical beasts, but so eager and well-meaning. We greet them so enthusiastically when they've arrived, it's hard for them to get too mad at us. Even when they discover we've peed on the carpet while they've been gone, and they have an awful mess to clean up. Heh. I wouldn't mind, but I'm getting the very strong feeling that this is about the third time we've returned to this particular pile of vomit and spread it around differently. Everyone, please don't take that perjoratively, I just saw the opportunity to extend Mike's metaphor further than it should be expected to go, and I took it. Right, back to the summary. -- Piers
Re: L2R/R2L syntax
Brent Dax [EMAIL PROTECTED] writes:
Mr. Nobody:
# I have to wonder how many people actually like this syntax,
# and how many only say they do because it's Damian Conway who
# proposed it. And map/grep aren't specialized syntax, you
IIRC Damian also supports Unicode operators (and may have originated the
idea), and obviously many people don't like them.
# could do the same thing with a sub with a prototype of
# (block, *@list).
Great. That could mean it won't work right for
MyCustomArrayLikeThing.
Actually, it will, as I have discussed the LAST TIME this bloody
subject came up. Multiple dispatch is your friend.
map (block, *@list) { @list.map(block) }
map (block, @array) { @array.map( block ) }
etc. Remember most of this will be set up by default anyway, when you
come to implement MyCustomArrayLikeThing you *may* have to add a few
function definitions, or the fact that MyCustomArrayLikeThing inherits
form Array may just fix it for you anyway.
Re: L2R/R2L syntax
Damian Conway [EMAIL PROTECTED] writes:
Brent Dax asked:
So
@a ~ grep { ... } ~ @b
Is the same as
@b = grep { ... } @a
Yes.
As in...
class Array {
...
method grep (Array $ary: Code $code) returns Array {
...
}
method grep (Code $code: Array $ary) returns Array {
...
}
}
No. As in:
sub grep (Code|Hash $selector, *@candidates) is multi {...}
class Array {
...
method grep(Array $self: *@candidates) {...}
}
Multimethods don't belong to classes; they mediate interactions
*between* classes.
Will the 'is multi' actually be necessary? Just curious.
Re: L2R/R2L syntax
Mr. Nobody [EMAIL PROTECTED] writes:
--- Michael Lazzaro [EMAIL PROTECTED] wrote:
On Friday, January 17, 2003, at 11:00 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Michael Lazzaro) writes:
...the absence of the commas is what's special. If they were normal
functions/subroutines/methods/whatever, you would need a comma after
the first argument
This is plainly untrue. See the perlsub documentation, which talks
about
creating your own syntax with the prototype. You can do all this in
Perl 5, and it saddens me that some of the people redesigning Perl
don't
know what Perl can do.
No. I said it was _special_, not _impossible_. You're creating your
own syntax -- that's exactly my point. Cmap, etc. are using an
invocation syntax _slightly_ different from the vast majority of other
cases -- one that skips a comma. Yes, it's a special case that exists
because of the prototype and the special case caused by '', which is a
special case precisely so that there can be *any* way to emulate the
special case Cmap syntax. But whether we like the perl5 Cmap
syntax or not, we should at least recognize that it's not regular.
The syntax is going to be special no matter what. It has the power to turn
a bare block into a subref:
sub foo ($x) { }
sub bar (x) { }
foo { }; # hash
bar { }; # sub
Have you been reading the Apocalypses? Both of those are blocks, as
discussed in (I think) Apocalypse 2.
Re: L2R/R2L syntax
Damian Conway [EMAIL PROTECTED] writes:
Piers Cawley wrote:
Multimethods don't belong to classes; they mediate interactions
*between* classes.
Will the 'is multi' actually be necessary? Just curious.
That's still being discussed. *Something* is necessary. But it may
be that, instead of:
sub handle (Window $w, Event $e, Mode $m) is multi {...}
one will write:
sub handle (Window $w: Event $e: Mode $m:) {...}
That is, if it's a Csub (or a method, for that matter) and
you specify that it has multiple invocants, then it's a multimethod.
The advantage, of course, is that this potential syntax confers much
finer control over which parameters participate in the multiple
dispatch. For example, if that had been:
sub handle (Window $w: Event $e, Mode $m:) {...}
then the dispatch would only be polymorphic with respect to
$w and $m.
The *disadvantage* of this syntax is that it confers much finer
control over which parameters participate in the multiple dispatch --
which may make it harder to achieve predictable dispatch behaviours
for specific multimethods.
Another disadvantage is that it's easier to miss those trailing colons
(or confuse them with semicolons), whereas an explicit Cis multi is a
much clearer signal of intent.
I really don't like that fine grained syntax I'm afraid. And I'm not
entirely sure you actually gain anything from it do you?
Another option,
sub handle (Window $w, Event $e, Mode $m) is dispatched($w, $m) {...}
is explicit, but disgusting.
I also find myself wondering if functions called with:
$foo.bar($baz)
should be *required* to be singly dispatched on $foo and saying that
mulitply dispatched functions/generics/whatever should look like
normal function calls:
bar($foo, $baz); # May be multiply dispatched
But I can't begin to offer reasons for this beyond a vague gut
feeling.
Re: Array Questions
Michael Lazzaro [EMAIL PROTECTED] writes:
On Thursday, January 9, 2003, at 03:24 AM, Damian Conway wrote:
Michael Lazzaro asked:
class FileBasedHash is Hash { ...stuff... };
my %data is FileBasedHash('/tmp/foo.txt');
Yes.
my $path = '/tmp/foo.txt';
my %data is FileBasedHash($path);
Indeed
Great -- then I have only one more question, I think. In the words of
a certain cartoon character, what's *this* button do?
my $b is $a;
Compile time error. 'is' is a compile time property, scalar values
aren't.
Re: Array Questions
Damian Conway [EMAIL PROTECTED] writes: Michael Lazzaro wrote: Which, in turn, implies that the lines: my Foo $a; # (1) my $a is Foo; # (2) my Foo $a is Foo; # (3) are all subtly different. (2) and (3) (auto)instantiate a Foo, but (1) does not. Correct. Though the instantiated Foo is the implementation object and not directly accessible (just as the implementation object in a Perl 5 tie isn't). BTW, Cmy Foo $a is Foo is just sick! (i.e. I'll *definitely* be using it ;-) Surely anyone who does C my Array @foo , or C my Scalar $foo will be using it, albeit indirectly.
Re: Disappearing code
Damian Conway [EMAIL PROTECTED] writes:
John Siracusa asked:
Has there been any discussion of how to create code in Perl 6 that's there
under some conditions, but not there under others? I'm thinking of the
spiritual equivalent of #ifdef, only Perlish.
In Perl 5, there were many attempts to use such a feature for
debugging and
assertions. What everyone wanted to do was write code like this:
debug(Doing foo with $bar and $baz);
foo($bar, $baz);
And then have the entire call to debug() just plain disappear when
the
program was run with a certain flag, or when a particular constant was set,
or whatever. The closest we got in Perl 5, AFAIK, was stuff this:
use constant DEBUG = 0;
...
debug(Doing foo with $bar and $baz) if DEBUG;
foo($bar, $baz);
But all those if DEBUGs or DEBUG s were a pain. So I'm
wondering what
the solution will be in Perl 6.
Something like this:
module Debug;
my $debugging = 1;
method import ($debug) { $debguuging = $debug }
sub debug is immediate is exported (@message) {
return $debugging ?? { print $*STDERR: @message; } :: {;}
}
then:
use Debug;
debug(Doing foo with $bar and $baz);
and to deactivate the debug statements:
use Debug 0;
debug(Doing foo with $bar and $baz);
Immediate subroutines are executed as soon as they are parsed (i.e. they're
like named BEGIN blocks).
Returning a closure/block from an immediate sub called in a void context
(as Cdebug is in the example above) causes the immediate sub call to be
replaced -- during compilation! -- by the returned closure/block.
So, one could implement 'assert' in the same package with something
like:
sub assert is immediate is exported
( rx/expr/ expr ; $message = Assertion failed )
{
return $debugging ?? { expr() || die $message } :: { ; }
}
For bonus points one could have the assertion die if it's called in a
non void context, but I'll leave that as an exercise for the
interested reader.
Re: This week's Perl Summary
Buddha Buck [EMAIL PROTECTED] writes: Mr. Nobody wrote: If you and Damian think you'll get me to leave p6l this easily, forget it. I've seen far worse flames than that. While you were the person that Damian lost his sense of humor at, Piers didn't identify you in this part of the summary. So I don't think Piers was trying to get you to leave. Exactly. -- Piers
Re: Variable Types Vs Value Types
Dan Sugalski [EMAIL PROTECTED] writes: At 1:10 PM + 1/6/03, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: An object is a data type, as much as an array or hash is a data type, but that doesn't make an array an object. [insert obligatory all men are Socratese quote here) I really hope you're wrong here Dan. At least in that particular case. Being able to inherit from Array or Hash or whatever as a neater way of implementing, say, Tie semantics would be remarkably useful... Well, you'll certainly be able to use delegation to get in the way if nothing else. Go on, how would delegation help in the case where you want to be subclass Array so as to be able to do: my TiedArraySubclass @foo;
Re: Variable Types Vs Value Types
Damian Conway [EMAIL PROTECTED] writes: attriel wrote: AssignmentOK?Because... ======== my Basket $c = $a no $c's type: Basket (of Object) X ^ | | $a's type: Set of Apple my Basket of Apple $c = $aok $c's type: Basket of Apple ^ ^ | | $a's type: Basket of Apple Now, just to be sure I didn't miss a step: That second entry is wrong, sin't it? it should be OK? no b/c: C's Type : Basket of Apple X^ || A's Type : Set of Apple yes? Quite correct. I messed up A's type. :-( Could the Secret Maintainers of Perl 6 Truth please update that for the records. If you want me to doctor the summary you're going to have to do better than a simple 'please' mate. I want personal tuition on making presentation software actually *enhance* the presentation...
Re: This week's Perl Summary
Steve Fink [EMAIL PROTECTED] writes: On Jan-04, Leopold Toetsch wrote: Damian Conway wrote: Piers Cawley wrote: Acknowledgements But, of course, modesty forebade him from thanking the tireless Perl 6 summarizer himself, for his sterling efforts wading through the morasses that are P6-language and P6-internals Remembering e.g. perl6 operator threads, brrr, I just can say ... Thank-you, Piers! me2 Me3. But watch out -- you are single-handedly responsibility for the sanity of hundreds of us, and are therefore responsible for anything we might do in this unnatural state. I accept no responsibility for any such actions, and reserve the right to cease producing summaries at any time (but not in the foreseeable future). Now, I've got the perl6-internals section of the christmas/new year summary written, hopefully I'll have the perl6-language and other bits written and mailed out later today. Hang in there people. -- Piers
Re: Array Questions
Mark J. Reed [EMAIL PROTECTED] writes:
On 2003-01-07 at 11:31:13, Mr. Nobody wrote:
.length is unneeded, since an array gives its length in numeric context, so
you can just say +@a.
Unneeded, but harmless.
grep shouldn't be an array method either, it should be
like the perl5 grep, as it is often used on lists, grep /foo/, keys %h is
far more readable than @{[keys %h]}.grep(/foo/).
Didn't we already have the left-to-right vs. right-to-left discussion?
Regardless of how grep works when it's not invoked as a method, it
most definitely should be invokable as one on arrays. It would probably
be defined in a superclass rather than in Array itself, assuming Array
is a specific subclass of a more general collection class
(be it List or Collection or whatever), but that doesn't matter as long
as you can call it on an array.
Also, some of the line noise in your unreadable example comes from your
mixing method syntax with other syntax. No need to do all that @{[keys %h]}
stuff - it would just be %h.keys.grep(/foo/), which looks pretty darn readable
to me.
Or, even
%h.grep(- $pair {.key =~ /foo/})
depending on what you actually want (assuming that grep treats %h as a
list of pairs...)
Re: Variable Types Vs Value Types
Dan Sugalski [EMAIL PROTECTED] writes: An object is a data type, as much as an array or hash is a data type, but that doesn't make an array an object. [insert obligatory all men are Socratese quote here) I really hope you're wrong here Dan. At least in that particular case. Being able to inherit from Array or Hash or whatever as a neater way of implementing, say, Tie semantics would be remarkably useful...
Re: This week's Perl Summary
Paul Kienzle [EMAIL PROTECTED] writes: Piers Cawley wrote: * Thanks to everyone who has given me feedback as a result of these summaries. It's really good to know that people finding these things useful. Me too. I find I no longer read the list because I can pick up the few relevant bits from the summary and follow them up in makeshortlink. Can I just get your summary and drop the rest of the subscription? Just subscribe to [EMAIL PROTECTED] -- Piers
This week's Perl 6 summary
The Perl Summary for the week ending 20021222 Hello, good morning and welcome to the Christmas edition of the Perl 6 summary. For some reason I have convinced myself to sit here on Christmas Eve writing a summary for all you crazy kids out there who hang on my every word. Plus, it beats wrapping all the presents and last minute panic shopping. So, let's get perl6-internals out of the way first. The Road to 0.0.9 The first half of the week saw a feature freeze in the run up to the release of Parrot 0.0.9, so people spent their time trying to track down and fix various tinderbox issues and other bugs. Steve Fink worked on trying to get the NCI (Native Call Interface) tests to work properly. Simon Glover and Leo Tötsch worked on tracking down a GC bug that was causing problems for the scratchpad tests. Andy Dougherty is having problems getting languages/perl6 to pass its tests. Apparently part of the problem is that the undef function isn't fully defined. Andy also found problems with sprintf and 64 bit INTVALs (fixed by Brent Dax), PMCs and 64 bit INTVALs (fixed by Leo Tötsch), PerlHashes and gcc-2.95.3 and 2.8.1 on Solaris (confirmed as a problem with other versions of gcc on Solaris by Joshua Hoblitt), dependency issues between Jako and IMCC from a clean directory and problems with the Jako life implementation. Bruce Gray sent a pile of fixes for Win32 systems, covering GC and build problems. Compiling to ParrotVM Klaas-Jan Stol is thinking of writing a compiler that targets Parrot for his Bachelor's in Computer Science, probably a TCL compiler, and he asked for suggestions and tips. David Robins made a few suggestions and pointed out that parrot is a moving target. Dan protested that it wasn't moving that much (If I 'adn't nailed it to the perch, it'd've muscled up to them bars and... VOOM!) and said that he thought a TCL to Parrot compiler would be great. Will Coleda put up a URL for his first pass at such a beast and asked that we be gentle with him (he put up a URL for his second pass later, which is the link below). Gopal V pointed out that IMCC may be a better target than Parrot assembly as that took care of register allocation and generally helped programmers retain their hair and also suggested that, if the compiler was written in C then DotGNU's TreeCC would be worth looking at. Tanton Gibbs, who is working on a C++ compiler agreed that TreeCC is 'an extremely nice system' that he recommended highly. http://makeashorterlink.com/?T27042FD2 http://www.coleda.com/users/coke/parrot/ http://makeashorterlink.com/?H2CF62ED2 Register scanning Apologizing for reopening the register scanning can of worms, Steve Fink wondered about the requirement that all Parrot GC implementations scan all hardware registers for live pointers. Apparently this is a real problem with, for example, the IA64 architecture. He proposed that configure probe for systems that would support register scanning GC, but that the default implementation should use a 'registration' system. He followed this up with a 'naive' implementation of such a system. Jason Gloudon suggested another scheme that I'm afraid I didn't understand to implement 'accurate' GC. http://makeashorterlink.com/?L2DF41ED2 http://makeashorterlink.com/?T1EF22ED2 Returning a new PMC from ops David Robins wondered about the cleanest way to return a new PMC from an op. He and Leo Tötsch thrashed it out. http://makeashorterlink.com/?K1FF62ED2 Parrot v0.0.9 Nazgul released Steve Fink announced the release of Parrot version 0.0.9, aka Nazgul complete with a long list of new features, and the usual call for further assistance. Well done everyone. As Steve says, Parrot is getting dangerously close to being really usable... http://makeashorterlink.com/?X10022FD2 http://makeashorterlink.com/?C51024FD2 Meanwhile, in perl6-language It was quiet... too quiet. Only 48 messages in perl6-language, maybe we're all keeping quiet so as not to distract Larry from writing the next Apocalypse. Comparing Object Identity This thread (along with every other thread in the language list this week) continued from last week. Dan pointed out that using long lived object IDs (ie. unique for all time) would be expensive, and reckoned that the basic approach should be fast and good enough for the common case. Piers Cawley wondered if doing object 'identity' comparison with a method (eg: $obj.is($other_obj);) wasn't actually the best way forward. (Piers had been applying his OO rule of thumb -- if you're not sure of how to do something, take a look at a Smalltalk image). Dave Whipp proposed an adverb syntax ($a eq : ID $b) which would be generalizable: $a eq:i
Re: is it required to use type declarations?
Dave Storrs [EMAIL PROTECTED] writes:
On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote:
From: Dave Storrs [EMAIL PROTECTED]
My understanding was that in Perl6, you could use pretty much anything
for a hashkey--string, number, object, whatever, and that it did not
get mashed down into a string. Did I have this wrong?
By default they're keyed by strings. You can smack a property on them
to key them by something else, though:
my %sparse is keyed(Int);
my %anything is keyed(Object); # or UNIVERSAL
Hmmm...maybe this is a good time to bring up something that's been
bothering me for a while.
It seems like Perl6 is moving farther and farther away from Perl5's
(almost) typelessness.
It depends what you mean by typed. Perl has always had strongly typed
*values* (which strike me as being a damn sight more useful than
typed variables). In a language with typed values, being able to
declare a typed variable is useful for a few reasons:
* After watching things in a profiler, you sacrifice programmer
flexibility by typing a couple of variables as a way of giving the
Optimizer something to get its teeth into (if you have a typed
variable then you can limit the amount of runtime checking you have
to do in favour of compile time checks)
* For setting up multiply dispatched methods and functions. Consider
the example below (which I know I've used before).
sub grep ( (Rule | Block) $selector, @*args ) { @args.grep($selector) }
sub grep ( (Rule | Block ) $selector, Collection $collection ) {
$collection.grep($selector)
}
sub grep ( WeirdSelector $selector, @*args ) {
grep $selector.as_block, *@args;
}
Because we can declare the types of the function parameters we can
let the language sort out the dispatch for us. Without typed
parameters and multi dispatch those three function definitions
become:
sub grep ( $selector, $first, @*args ) {
if @args.length {
return [ $first, @args ].grep($selector);
}
else {
$first.grep($selector);
}
}
method Object::grep ($self: $selector {
[ $self ].grep($selector);
}
Which, to my way of looking at things is deeply ugly.
* And last and least, for 'strictness'. Personally I think this is
the least useful choice; the programmer sacrifices flexibility for
having the compiler catch errors that would be more usefully caught
in a test suite. And to make matters worse, if you want the
compiler to catch the errors you have to make *everything*
explicitly typed, and and life's too short for buggering about like
that thank you very much.
--
Piers
Re: Comparing Object Identity
Dave Storrs [EMAIL PROTECTED] writes: On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote: $obj.ID; $obj.IDENTITY; FWIW, I favor the latter. I found myself mulling over: $obj.is($other_obj); Which seems to work reasonably well, and I'd be rather surprised if it clashed with anything with different semantics...
Re: Comparing Object Identity
Aaron Crane [EMAIL PROTECTED] writes:
Piers Cawley writes:
I found myself mulling over:
$obj.is($other_obj);
Which seems to work reasonably well, and I'd be rather surprised if it
clashed with anything with different semantics...
I quite like it. It also has the advantage of disallowing the equivalent
of:
my $stored_identity = $obj.id;
# Time passes...
if ($other_obj.id == $stored_identity) {
# Massive breakage ahoy
}
Ah, sorry, I thought that went without saying. So I didn't say
it. That's actually the problem that led me to come up with .is in
the first place.
There just isn't any way you can get .is() to compare identities at
different times.
Indeed. I'm definitely liking it the more I think about it. Someone
will be along to say 'but I use Cis in *all* my classes!' soon,
mark my words.
