luqui's Journal http://use.perl.org/~luqui/journal/ luqui's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:12:48+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 luqui's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~luqui/journal/ I hate boilerplate http://use.perl.org/~luqui/journal/33762?from=rss <a href="http://luqui.org/blog/archives/2007/07/09/rehashing-the-boilerplate/">Rehasing the Boilerplate</a> luqui 2007-07-09T23:19:19+00:00 journal Dwimmery sanity http://use.perl.org/~luqui/journal/32489?from=rss <a href="http://luqui.org/blog/archives/2007/02/23/why-designing-a-language-and-designing-a-command-line-are-differen/">Why designing a language and designing a command line are different</a> luqui 2007-02-24T04:37:18+00:00 journal Perl 6 Rules: Elementary Compositionality + More Vocabulary http://use.perl.org/~luqui/journal/32200?from=rss <p>Sorry for the bare link: I thought it would be best if I put all my writing in my one blog (which is easily backupable) than scattered around in several.</p><p> <a href="http://luqui.org/blog/archives/2007/01/19/perl-6-rules-elementary-compositionality-and-more-contrived-vocabulary/">Perl 6 Rules: Elementary Compositionality and More Contrived Vocabulary</a> </p> luqui 2007-01-19T10:46:29+00:00 journal The reason I left Perl 6 http://use.perl.org/~luqui/journal/29679?from=rss <p>Sometime around January or February, I suddenly disappeared from the Perl 6 scene. Before then, I was actively discussing, proposing, hacking on pugs, and everything. In an instant, it all stopped. I've had some time to reflect on that, so I'll write it down because it is presently keeping me from sleeping.</p><p>I'll first say that it wasn't out of disgust for the language or its process. I like Perl, and I like the direction Perl 6 is going for the most part. The forces at work were much more subtle than that.</p><p>Before I begin, I'd like to say that I'm writing this from memory, not checking my records. The dates may be inaccurate, and my comments, particularly those about Damian, are probably emotionally biased in some respect. If I went back and looked at the details, the result would probably be even more mild than I describe here, but the "feel" of the situation is really what is important to this article, so that's how I'm going to keep it.</p><p>Designing Perl has interested me for so long because it has satisfied two fundamental desires I have had. First, I could exercise my mathematical creativity (something that is very difficult to do in a math program where you are working with traditional math which has been very well explored). Second, I have discovered that the last few years of my life have been about social artistry. I tried to start the Miki (music wiki) project and I love game design for this reason. The design of Perl, though I did not realize it at the time, is social artistry.</p><p>Gradually a tension in the design team arose between me and Damian. I usually credit Damian as the one who taught me to argue, because if my arguments were not rock solid, he would poke holes in them until they were nothing. This was wonderful for certain debates, but it soon became a problem. He and I probably have some different principles of language design, but I was never able to identify where we fundamentally differed. In any case, it came to a point where he would respond in opposition to almost every proposal I had. This isn't an attack on himhe definitely had good reasonsbut it had an effect on me.</p><p>I can demonstrate most clearly with the Junctions debate (this was the most accented, but the same thing happened subtly a couple more times). Perl was a work of art to me, and I saw the semantics of Junctions as a big ugly spot. I would propose a solution and be opposed (because the solution had some semantic holes; we don't want to take away functionality). So I would get out my paper and my whiteboard, working on a solution, mulling, exploring, for several weeks both actively and passively until I came up with what I considered more beautiful but still accomplishing the same semantic ideas, in some cases with a little more work (allow an asymptotic constant; they were in the same order of expressibility). Damian would find a yet smaller hole, we'd argue for a bit, then I would go back to the drawing board and start the process over again. When I was not opposed entirely, Larry would usually pick the bits of my proposal that enabled some feature and give a variant of my syntax to it. This didn't satisfy me at all, because my proposals were not about adding a particular feature to Perl 6, but about the beauty of the interplay of some features that previously seemed unrelated.</p><p>In the end, I did some of my best work during these minidebates. I had reached my limit on several proposals in November or December, and the holes that were found (not always, but usually, by Damian) seemed small, obscure, and without support (as if the word "useful" were a universally understood and accepted metric not needing support). I respect Perl for not ignoring programming's linguistic heritage, but the virtue of mathematical creativity was extinguished when most of the design team substituted that for attention to programming's mathematical heritage, which also must not be ignored! The virtue of social art was extinguished when the solutions that I had worked for weeks on and I considered truly beautiful lost to syntax bloat and "DWIM tables". It bascially came down to the rest of the team considering Perl much more pragmatically than I did, which may end up better for the end result anywayit is hard to tell.</p><p>Yet I persevered until school interfered. In January, I was taken by surprise when two of the three "easy math classes" I took turned out to be very challenging. In particular, the homework for my Set Theory class was usually about four proofs. These proofs were not simple; they required insight, understanding, and ingenuity. Each one usually took an hour or more and ended up being only three or four lines long. This exhausted my brain, but also fulfilled my desire for mathematical creativity. Now I have a masters thesis in the area to work on.</p><p>In the middle of February, I started a fortnightly musical jam night with a few of my friends. This group of inexperienced musicians made some vaguely tolerable music sometimes, nothing I would ever pay money for. Yet it became the most exhilarating, most enjoyable thing I had ever done. Very gradually we improved, recruited guest musicians every once in a while, and the more fun it became. Now that school is out again, in addition to these (which are now weekly) I have joined a band of quite competent musicians and am touring around some other jam groups having fun with them. I found fulfillment for my desire of social artistry, and it was musicin particular, improvisation.</p><p>Working on Perl 6 was wonderful; I may never again have the pleasure of working with so many polite, diplomatic, intelligent people on one project. Even the conditions that caused me to inadvertently leave were very mild. But it's not too likely that I'll be coming back as a language designer, simply because I've found other avenues for these desires to travel. I'm not the kind of person to multitask in my interests.</p> luqui 2006-05-23T13:07:33+00:00 journal Yesterday's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/28471?from=rss <p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - customer project deadlines keep jumping and scopes keep creeping<br> &nbsp; &nbsp; &nbsp; &nbsp; - the deadline is next Wednesday<br> &nbsp; &nbsp; &nbsp; &nbsp; - I should be done then<br> &nbsp; &nbsp; &nbsp; &nbsp; - did send Allison an e-mail about the operator precedence parser</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you'll go into the Perl 6 parser then?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - yes<br> &nbsp; &nbsp; &nbsp; &nbsp; - maybe adding some features to PGE driven by parser demands</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - also have a work deadline<br> &nbsp; &nbsp; &nbsp; &nbsp; - but sneaked in a synopsis change from "till" to "ff"<br> &nbsp; &nbsp; &nbsp; &nbsp; - threw some conjectural stuff in S12 to bless ^ as a shorthand for<nobr> <wbr></nobr>.meta</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I think it's important to keep the difference between a type and a<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; package concrete<br> &nbsp; &nbsp; &nbsp; &nbsp; - I thought ^ was for types<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll see what I make of your changes and *then* whine</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - P5 to P5 is still about 95%?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't done anything on that in the last week</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - enjoying my processor arch class<br> &nbsp; &nbsp; &nbsp; &nbsp; - might dive into Parrot to apply some of my knowledge in a while<br> &nbsp; &nbsp; &nbsp; &nbsp; - otherwise working on an algorithm and paper to dispatch pure<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; multimethods as fast as possible<br> &nbsp; &nbsp; &nbsp; &nbsp; - can also incorporate compile-time information if it's available<br> &nbsp; &nbsp; &nbsp; &nbsp; - getting those two things at once is pretty hard<br> &nbsp; &nbsp; &nbsp; &nbsp; - the algorithm is still in progress<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can build a decision tree that dispatches to the right multi-method<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; provably with as few checks as possible<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can rule out some candidates based on compile-time information<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can use a bit of the theory that falls out of that to do type<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; inference<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's probably a couple of weeks away<br> &nbsp; &nbsp; &nbsp; &nbsp; - it might be worth a senior thesis</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Punie almost does simple if statements<br> &nbsp; &nbsp; &nbsp; &nbsp; - meeting with Chip in a bit<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll work on operators next<br> &nbsp; &nbsp; &nbsp; &nbsp; - it looks like Patrick's solution might fix my problem<br> &nbsp; &nbsp; &nbsp; &nbsp; - have about five or six people reviewing AL 2.0<br> &nbsp; &nbsp; &nbsp; &nbsp; - don't know if I'll get any comments<br> &nbsp; &nbsp; &nbsp; &nbsp; - have one more week on it</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I asked to have that list created<br> &nbsp; &nbsp; &nbsp; &nbsp; - I haven't seen anything yet<br> &nbsp; &nbsp; &nbsp; &nbsp; - Chip answered some of Leo's questions on Monday</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - thinking about overriding stuff in classes<br> &nbsp; &nbsp; &nbsp; &nbsp; - attributes that have a constant value through the lifetime of an object<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; are different beasts from attributes that can change<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm searching for a way to make that distinction without imposing<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; horrible cognitive or finger blocks on people</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - like our readonly versus contant distinction?<br> &nbsp; &nbsp; &nbsp; &nbsp; - on ordinary variables<br> &nbsp; &nbsp; &nbsp; &nbsp; - bound in a constant way<br> &nbsp; &nbsp; &nbsp; &nbsp; - but not a constant<br> &nbsp; &nbsp; &nbsp; &nbsp; - different iterations of this function may have a different value<br> &nbsp; &nbsp; &nbsp; &nbsp; - can't optimize it away in that sense</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - the fact that attributes aren't read-only inside of an object causes<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; problems with inheritance<br> &nbsp; &nbsp; &nbsp; &nbsp; - that distinction may be nice to have if it works cognitively</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is that an implementation detail not exposable?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - more about the intent of its use rather than its actual use</p> luqui 2006-01-26T09:28:10+00:00 perl6 Yesterday's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/28406?from=rss <p> Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I started school today<br> &nbsp; &nbsp; &nbsp; &nbsp; - I have five hours in a row of classes<br> &nbsp; &nbsp; &nbsp; &nbsp; - started to learn Scala outright, as if I were to program in it<br> &nbsp; &nbsp; &nbsp; &nbsp; - I read three papers about its cool object model<br> &nbsp; &nbsp; &nbsp; &nbsp; - it seems that it has every cool idea I've already thought of<br> &nbsp; &nbsp; &nbsp; &nbsp; - the idea that a role isn't just an object really seems like a good idea<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; to me<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're not just for composing into classes<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're for composing into anything<br> &nbsp; &nbsp; &nbsp; &nbsp; - a collection of stuff<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't see any downsides except for the lack of strict subtyping<br> &nbsp; &nbsp; &nbsp; &nbsp; - but there's a neat result: parameterized classes<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're the same as virtual classes<br> &nbsp; &nbsp; &nbsp; &nbsp; - just make roles purely compositional<br> &nbsp; &nbsp; &nbsp; &nbsp; - not subtyping things<br> &nbsp; &nbsp; &nbsp; &nbsp; - eventually I'll write a document on my thoughts</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - why do you lose subtyping?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - if you can compose anything, you can compose class names<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can compose those, you lose subtyping based on how that class is<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; used in the rest of that role<br> &nbsp; &nbsp; &nbsp; &nbsp; - if you use the virtual class for argument types, you have to have a<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; contravariant relation</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - busy with my day job<br> &nbsp; &nbsp; &nbsp; &nbsp; - just keeping up with the mailing lists<br> &nbsp; &nbsp; &nbsp; &nbsp; - I have another week or two of heavy duty work<br> &nbsp; &nbsp; &nbsp; &nbsp; - eventually I'll get back to the translator<br> &nbsp; &nbsp; &nbsp; &nbsp; - I have to prepare a talk for it for OSDC Israel<br> &nbsp; &nbsp; &nbsp; &nbsp; - also thinking through how to make a lower impedence mismatch connection<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; between my AST and some of the Pugs projects</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is it worth throwing random ASTs at them?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - not yet</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - did they convince you to visit Japan?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - didn't take much convincing</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't touched Punie in about three days<br> &nbsp; &nbsp; &nbsp; &nbsp; - I finished off comma lists since last week<br> &nbsp; &nbsp; &nbsp; &nbsp; - still haven't heard from Patrick<br> &nbsp; &nbsp; &nbsp; &nbsp; - have other things I need to fix too<br> &nbsp; &nbsp; &nbsp; &nbsp; - I might start on functions before operators<br> &nbsp; &nbsp; &nbsp; &nbsp; - besides control structures, that's about it</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - don't forget regexes<br> &nbsp; &nbsp; &nbsp; &nbsp; - they gave me trouble</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I might just implement a compatibility layer</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - how's the licensing going?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll release something within two weeks, even if I don't have comments<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; from everyone I asked to comment</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - sounds good</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - working frantically to write a keynote for next week<br> &nbsp; &nbsp; &nbsp; &nbsp; - involved a lot of photoshopping Peter Jackson<br> &nbsp; &nbsp; &nbsp; &nbsp; - also negotiating with Japanese folks for the YAPC there<br> &nbsp; &nbsp; &nbsp; &nbsp; - preparing for the talk has thrown up a lot of questions for the mailing<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; list<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm still curious about a special way to declare class methods<br> &nbsp; &nbsp; &nbsp; &nbsp; - Larry seems to be keen not to tie them down<br> &nbsp; &nbsp; &nbsp; &nbsp; - there are a lot of people who'd like the option</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it can always be the option</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm trying to show syntax, though<br> &nbsp; &nbsp; &nbsp; &nbsp; - I could just have a blurry screen<br> &nbsp; &nbsp; &nbsp; &nbsp; - maybe I'll just show it with some fake syntax</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I couldn't come up with a good single word for that<br> &nbsp; &nbsp; &nbsp; &nbsp; - Rob Kinyon kind of has a point with the polymorphism there</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - more of a cultural one, as far as I see it</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - no doubt about that<br> &nbsp; &nbsp; &nbsp; &nbsp; - there are plenty of people who want to leave Java without leaving the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Java mindset</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it'd be interesting to see how much information the type inferencer<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; gives us for free</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it would be wise not to rely on it<br> &nbsp; &nbsp; &nbsp; &nbsp; - there hasn't been much research into inferencing these type models</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - even inferrence doesn't mark them physically in the syntax<br> &nbsp; &nbsp; &nbsp; &nbsp; - people like that</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's like Haskell<br> &nbsp; &nbsp; &nbsp; &nbsp; - you don't have to put explicit types on your functions<br> &nbsp; &nbsp; &nbsp; &nbsp; - but people do -- for documentation and future-proofness</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - and checking your logic of the system<br> &nbsp; &nbsp; &nbsp; &nbsp; - you're showing what you believe about a system</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Haskell will catch you eventually<br> &nbsp; &nbsp; &nbsp; &nbsp; - but it won't point you to the right place without prototypes</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I almost had a bad moment and suggested "state"</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't understand how partially undefinedness supports prototype-based<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; OO<br> &nbsp; &nbsp; &nbsp; &nbsp; - replying to Rob's thread might answer that</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll think about that</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - fighting with customers mostly this past week<br> &nbsp; &nbsp; &nbsp; &nbsp; - went to the GPL v3 thing Monday and Tuesday<br> &nbsp; &nbsp; &nbsp; &nbsp; - talking to potential Ponie contributors, but one fell through<br> &nbsp; &nbsp; &nbsp; &nbsp; - two people are interested in hacking<br> &nbsp; &nbsp; &nbsp; &nbsp; - they asked what there is to do<br> &nbsp; &nbsp; &nbsp; &nbsp; - Jerry Gay is poking at getting a Windows box for regular Parrot builds</p> luqui 2006-01-20T02:13:41+00:00 journal Overrrrrriding http://use.perl.org/~luqui/journal/28335?from=rss <p>I'm toying with the idea of "composable modules" for Perl 6. It all started with the combinator library for Parse::Rule in the pugs distribution. I wanted to keep a uniform interface for combinators, but keep the options for a choice of evaluation strategy (CPS, Parrot JIT compiled, etc.) and choice of medium (utf8 string, array of objects, etc.).</p><p>The way I ended up doing it was to use stateless objects as modules. That is, to create combinators for a text medium with a CPS strategy, you would do:</p><blockquote><div><p> <tt>class TextCPS {<br>&nbsp; &nbsp; does Strategy::CPS;<br>&nbsp; &nbsp; does Medium::Text;<br>&nbsp; &nbsp; # implement one or two required combinators<br>}<br>my $c = TextCPS.new;<br>$c.quantify($c.any_char,<nobr> <wbr></nobr>:min(4));&nbsp; # /<nobr> <wbr></nobr>.**{4...}<nobr> <wbr></nobr>/</tt></p></div> </blockquote><p>These roles used virtual classes all over the place. For example, the Medium role, which holds medium-specific combinators, has to refer to a Pos class, which reperesents a medium-specific position in a stream. However, that Pos will change based on what specific medium implementation is in use, so the Pos class is virtual.</p><p>But since the combinator objects don't have any state, they're really more like modules: collections of functions. But we still want composable behavior.</p><p>But the thing that's been on my mind recently is the overriding problem. What are you, and what are you not, allowed to override? You can clearly override functions, as long as the new function's type is a subtype of the old function's type. That's what OOers have been doing for ages. It also makes sense to override constants, since they're just functions that take no arguments, as long as the subtyping relationship holds.</p><p>But what about variables? For variables that can be assigned to and read from, the type must be exactly the same, or more generally, <i>isomorphic</i> (A and B are isomorphic if A &lt;: B and B &lt;: A). Type isomorphisms are something that I've wanted in Perl for a while, but never really figured out how they would work.</p><p>There's a pattern here: if you read from it, new &lt;: old; if you write to it, old &lt;: new. But what about classes? A class is just a kind of constants. By the pattern, the overriding class must be a subclass of the overridden class. But I don't think that's quite accurate. For starters, it's wrong, because:</p><blockquote><div><p> <tt>role Foo {<br>&nbsp; &nbsp; class Bar {...}<br>&nbsp; &nbsp; method foo(Bar --&gt; Int) {...}<br>&nbsp; &nbsp; method bar(Int --&gt; Bar) {...}<br>}</tt></p></div> </blockquote><p>Here, you can't override Bar with a subclass of itself, because then you lose Liskov substitutability on foo(). You can't override Bar with a superclass of itself, because then you lose Liskov substitutability on bar(). So if you do override Bar, it has to be an isomorphic class.</p><p>That's because when you override a constant, you require not that the new constant is &lt;: to the old one, but the new constant's <i>type</i> is &lt;: to the old one. So really we have to require that the overriding class's type is a subtype of the overridden class's type. As far as I recall, types of types are kinds, and all non-parameteric classes would all have the same kind, so that trivially holds. But clearly that's not the only constrant that is on these special constants.</p><p>The constraints come from the usage of the class within a scope, which is a little bit scary (mandatory inference kinds of things). We could be like Scala and allow you to specify the relationship that must hold, but that's requiring that the user know a little too much about type theory. The constraint might just be that the class doesn't cause any other subtype constraints to be violated in overriding. That is:</p><blockquote><div><p> <tt>role Foo {<br>&nbsp; &nbsp; class Bar {...}<br>&nbsp; &nbsp; method foo(--&gt; Bar) {...}<br>}</tt></p></div> </blockquote><p>Our constraint is that for any subclass X of Foo, typeof(X::foo) &lt;: typeof(Foo::foo). So if you override Bar with a supertype of Bar, then you break the constraint, so that isn't allowed.</p><p>Stepping back to the original question: what is a module? I'd say a module is a collection of virtual things that refer to each other. It is closed, so you can't add to the collection; you can only derive new collections based on it. The constraints are exactly Liskov substitutability constraints.</p><p>Actually, the constraints might be more liberal than Liskov. It might just be that a derived module still has to be well-typed. That is a characteristic of a code-reuse construct rather than a typing construct. That characteristic might be something to think about with roles, too.</p> luqui 2006-01-13T00:43:35+00:00 journal Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/28319?from=rss <p> Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - things are looking up<br> &nbsp; &nbsp; &nbsp; &nbsp; - I took a break, which helps<br> &nbsp; &nbsp; &nbsp; &nbsp; - first week back at work from the near year<br> &nbsp; &nbsp; &nbsp; &nbsp; - lots of mail<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll be in Asia and Tokyo in March<br> &nbsp; &nbsp; &nbsp; &nbsp; - otherwise enjoying the holidays<br> &nbsp; &nbsp; &nbsp; &nbsp; - I've been tracking Larry's updates<br> &nbsp; &nbsp; &nbsp; &nbsp; - intend to send more feedback soon<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll be at a Linux conference in New Zealand the week after next<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll have time then</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - lots of non-Perl busy-ness here<br> &nbsp; &nbsp; &nbsp; &nbsp; - will pick up on PGE again tomorrow<br> &nbsp; &nbsp; &nbsp; &nbsp; - another project moved up a deadline, so that was busy<br> &nbsp; &nbsp; &nbsp; &nbsp; - should free up some time tonight</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - what's the next checkpoint there?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - actually writing a parser for Perl 6 code<br> &nbsp; &nbsp; &nbsp; &nbsp; - I have the various pieces in the constellation to bring them together<br> &nbsp; &nbsp; &nbsp; &nbsp; - figuring out what to do with the parse trees comes after that<br> &nbsp; &nbsp; &nbsp; &nbsp; - but we can generate parse trees<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll also be on #parrot again</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - working on extending Punie still<br> &nbsp; &nbsp; &nbsp; &nbsp; - Patrick, I mailed a question about the operator precedence parser<br> &nbsp; &nbsp; &nbsp; &nbsp; - working on comma-separated expressions<br> &nbsp; &nbsp; &nbsp; &nbsp; - discovered an interesting thing<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can set up a PGE grammar to make it easier or harder to write tree<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; transformations<br> &nbsp; &nbsp; &nbsp; &nbsp; - the Perl 1 style of recursive rules makes trees harder<br> &nbsp; &nbsp; &nbsp; &nbsp; - at least, harder than repetition within the rule</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - what are you turning things into?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - some things need flat lists<br> &nbsp; &nbsp; &nbsp; &nbsp; - some things don't, but flat lists are easier to iterate over</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it can make a huge difference<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's nice to have both options with a nice syntax<br> &nbsp; &nbsp; &nbsp; &nbsp; - is there a reason not to treat comma as an operator?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - not sure<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll decide which way works best later<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I suspect repetition may be simpler</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - my plans for operator precedence allow list-associativity<br> &nbsp; &nbsp; &nbsp; &nbsp; - so it may work easier</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Perl 1 had a lot of hard-wired things in its grammar<br> &nbsp; &nbsp; &nbsp; &nbsp; - Perl 5 was more flexible</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - definitely interesting and informative</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - various bad luck<br> &nbsp; &nbsp; &nbsp; &nbsp; - desperately trying to follow along on everything at once<br> &nbsp; &nbsp; &nbsp; &nbsp; - not really responding<br> &nbsp; &nbsp; &nbsp; &nbsp; - my day job is really busy for the next couple of weeks<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't done anything on the translator<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm letting that gurgle in the background</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - what's your goal for the translator?<br> &nbsp; &nbsp; &nbsp; &nbsp; - 100% test suite?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't know that it can ever get entirely there<br> &nbsp; &nbsp; &nbsp; &nbsp; - but it's effectively there already<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't know how much I'll have to warp it<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm pretty confident I'm getting all of the information out<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't know if I'm getting it all out in the most convenient form for<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the translator<br> &nbsp; &nbsp; &nbsp; &nbsp; - it'd be good if someone could merge it back in to the Perl 5 mainline<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; at some point<br> &nbsp; &nbsp; &nbsp; &nbsp; - my impression is that Perl 5 is not mutating rapidly at this point<br> &nbsp; &nbsp; &nbsp; &nbsp; - not a big rush</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - what are its effects on parsing speeds?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - very little<br> &nbsp; &nbsp; &nbsp; &nbsp; - only a few conditional tests if you don't want the extra information<br> &nbsp; &nbsp; &nbsp; &nbsp; - a separate grammar file with extra goodies<br> &nbsp; &nbsp; &nbsp; &nbsp; - just a wrapper around yyparse mostly<br> &nbsp; &nbsp; &nbsp; &nbsp; - that was part of my original spec<br> &nbsp; &nbsp; &nbsp; &nbsp; - do need some stuff in the tokenizer, but they're guarded by conditionals</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - not much this week<br> &nbsp; &nbsp; &nbsp; &nbsp; - thinking about generalizing the design of Parse::Rule into useful<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; language constructs<br> &nbsp; &nbsp; &nbsp; &nbsp; - I had to pull some dirty design tricks<br> &nbsp; &nbsp; &nbsp; &nbsp; - talked a bit on p6l about composable modules<br> &nbsp; &nbsp; &nbsp; &nbsp; - now thinking about building an object and type system out of them<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't had much time to work on it<br> &nbsp; &nbsp; &nbsp; &nbsp; - but it looks promising<br> &nbsp; &nbsp; &nbsp; &nbsp; - my final project for cognitive science was on tree adjoining grammars<br> &nbsp; &nbsp; &nbsp; &nbsp; - they seem appropriate for our metaoperators<br> &nbsp; &nbsp; &nbsp; &nbsp; - instead of building a separate operator for each metaoperator-operator combination, you<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; could set that up as an auxiliary tree in that theory<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can parse them top-down<br> &nbsp; &nbsp; &nbsp; &nbsp; - as long as you have parameterized rules<br> &nbsp; &nbsp; &nbsp; &nbsp; - I wonder if I can massage that into a grammar that actually works<br> &nbsp; &nbsp; &nbsp; &nbsp; - does PGE do parameterized rules?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it only understands strings so far<br> &nbsp; &nbsp; &nbsp; &nbsp; - subrule name, colon, space -- everything else is an argument<br> &nbsp; &nbsp; &nbsp; &nbsp; - from Apocalypse 5<br> &nbsp; &nbsp; &nbsp; &nbsp; - maybe never blessed into a Synopsis<br> &nbsp; &nbsp; &nbsp; &nbsp; - official syntax is subrule( list )<br> &nbsp; &nbsp; &nbsp; &nbsp; - PGE doesn't understand that yet</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - spent two weeks mostly not working<br> &nbsp; &nbsp; &nbsp; &nbsp; - ended up writing some code, which was weird<br> &nbsp; &nbsp; &nbsp; &nbsp; - heard from Chip on Monday; he's back now<br> &nbsp; &nbsp; &nbsp; &nbsp; - have had some interest in Ponie pumpkining<br> &nbsp; &nbsp; &nbsp; &nbsp; - is anyone blocking on anything external?</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - what's the legal documents status?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's probably time for the public review</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Audrey is prodding us to come up with tagged unions<br> &nbsp; &nbsp; &nbsp; &nbsp; - the theory.pod syntax isn't very nice<br> &nbsp; &nbsp; &nbsp; &nbsp; - can't put my finger on why<br> &nbsp; &nbsp; &nbsp; &nbsp; - I looked at OCaml's tag types<br> &nbsp; &nbsp; &nbsp; &nbsp; - put a tag on a type and get a new type<br> &nbsp; &nbsp; &nbsp; &nbsp; - then create unions of types and get a tagged union<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I've never seen them used in practice<br> &nbsp; &nbsp; &nbsp; &nbsp; - I wonder how well they fit common uses</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - the type becomes a value bit of the new tag<br> &nbsp; &nbsp; &nbsp; &nbsp; - used as a discriminant at runtime, if not earlier?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I think so<br> &nbsp; &nbsp; &nbsp; &nbsp; - Perl has scalars where they are kind of deranged tagged unions with more<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; than one tag at once<br> &nbsp; &nbsp; &nbsp; &nbsp; - but ignoring that...</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm agreeable to the idea that unions should be discriminated<br> &nbsp; &nbsp; &nbsp; &nbsp; - the C idea of unions is a complete botch<br> &nbsp; &nbsp; &nbsp; &nbsp; - there has to be some way of telling them apart<br> &nbsp; &nbsp; &nbsp; &nbsp; - if they're objects, they have their own built-in identity<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I'm not a great type theoretician</p> luqui 2006-01-12T01:40:45+00:00 perl6 Last Week's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/28318?from=rss <p>(Sorry, forgot to post these last week)</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - until last Wednesday, I worked on PGE in Perl 6<br> &nbsp; &nbsp; &nbsp; &nbsp; - then I worked on something completely unrelated<br> &nbsp; &nbsp; &nbsp; &nbsp; - PGE in Perl 6 now, barring the operator precedence parser, does<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; everything that the Parrot one does<br> &nbsp; &nbsp; &nbsp; &nbsp; - except for parsing rules<br> &nbsp; &nbsp; &nbsp; &nbsp; - but Audrey is doing that</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - does it produce match objects like PGE does?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - yes<br> &nbsp; &nbsp; &nbsp; &nbsp; - last week I thought about things<br> &nbsp; &nbsp; &nbsp; &nbsp; - XQuery, tree matching<br> &nbsp; &nbsp; &nbsp; &nbsp; - pondering a data comprehension module for Perl 5<br> &nbsp; &nbsp; &nbsp; &nbsp; - whatever can make processing big, complex data structures quick and easy<br> &nbsp; &nbsp; &nbsp; &nbsp; - working with Audrey on context and coercion<br> &nbsp; &nbsp; &nbsp; &nbsp; - we have some disagreements about how that works<br> &nbsp; &nbsp; &nbsp; &nbsp; - mostly we're on the same page<br> &nbsp; &nbsp; &nbsp; &nbsp; - wrote a document describing pure MMD scheme<br> &nbsp; &nbsp; &nbsp; &nbsp; - including return type dispatch<br> &nbsp; &nbsp; &nbsp; &nbsp; - related to context<br> &nbsp; &nbsp; &nbsp; &nbsp; - those are in the Pugs repository<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll hack on them and then pass them along</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - did about 18 refactorings of the Perl 5 to Perl 5 translator<br> &nbsp; &nbsp; &nbsp; &nbsp; - ends up with a more adequately typed AST</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - typed how?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm not quite sure what I mean either<br> &nbsp; &nbsp; &nbsp; &nbsp; - a lot of the stuff internally to Perl is implicit<br> &nbsp; &nbsp; &nbsp; &nbsp; - there's no name for a particular node in the tree<br> &nbsp; &nbsp; &nbsp; &nbsp; - they happen accidentally<br> &nbsp; &nbsp; &nbsp; &nbsp; - we rearrange kids somehow and change a few flags and it applies<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; differently<br> &nbsp; &nbsp; &nbsp; &nbsp; - trying to name everything, or at least get close<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're types in that sense<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's not yet well-typed in the sense that I've looked at those names<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; and tried to figure out what's common between them<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's nothing like PIL<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's just trying to give a name to everything so we can have a hope at<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; translating at some point<br> &nbsp; &nbsp; &nbsp; &nbsp; - basically there are more node types currently than there are operator<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ppcodes in Perl 5<br> &nbsp; &nbsp; &nbsp; &nbsp; - there's now a Statement, which doesn't really exist<br> &nbsp; &nbsp; &nbsp; &nbsp; - there's an opcode for transitioning into a statement in Perl 5<br> &nbsp; &nbsp; &nbsp; &nbsp; - but nothing really contains a statement<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's a lot of the refactoring work<br> &nbsp; &nbsp; &nbsp; &nbsp; - make a more ordered tree<br> &nbsp; &nbsp; &nbsp; &nbsp; - now, of all the tests in the core modules, it translates more than 99.5%<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; correctly<br> &nbsp; &nbsp; &nbsp; &nbsp; - I haven't tried CPAN; I'd have to download it<br> &nbsp; &nbsp; &nbsp; &nbsp; - I also haven't bothered to try to hook this up to bleadperl<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can probably delegate that eventually<br> &nbsp; &nbsp; &nbsp; &nbsp; - most of these refactorings come about due to thinking about what I need<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; to translate to Perl 6<br> &nbsp; &nbsp; &nbsp; &nbsp; - making sure that the information is there<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't actually tried to translate anything yet<br> &nbsp; &nbsp; &nbsp; &nbsp; - eventually I'll get up the courage to translate $foo[] to @foo[] and go<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; from there<br> &nbsp; &nbsp; &nbsp; &nbsp; - otherwise, thinking about what people say on the mailing lists<br> &nbsp; &nbsp; &nbsp; &nbsp; - admittedly not being very responsive to that</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - planning to take time off around Christmas to do development<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I had my wisdom teeth out<br> &nbsp; &nbsp; &nbsp; &nbsp; - started working on expanding the Punie grammar again<br> &nbsp; &nbsp; &nbsp; &nbsp; - made it into sexpr part of the original perly.y<br> &nbsp; &nbsp; &nbsp; &nbsp; - ran into the traditional left recursion problem<br> &nbsp; &nbsp; &nbsp; &nbsp; - decided to use PGE's operator precedence parser instead</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - with regard to left recursion, there's a simple transform you can do<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; with closures to turn right-recursion data structures into ones that<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; look like left recursion</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - rather than doing left recursion, I flipped around<br> &nbsp; &nbsp; &nbsp; &nbsp; - broke it into two pieces<br> &nbsp; &nbsp; &nbsp; &nbsp; - the first element, and the rest of the expression</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - x [\+ x]* ?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - expression matches<br> &nbsp; &nbsp; &nbsp; &nbsp; - expression = expression<br> &nbsp; &nbsp; &nbsp; &nbsp; - expression = expression + expression<br> &nbsp; &nbsp; &nbsp; &nbsp; - instead, say expression = term + rexpression</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's my biggest complaint about Parse::RecDescent<br> &nbsp; &nbsp; &nbsp; &nbsp; - it has a nice leftop which does that<br> &nbsp; &nbsp; &nbsp; &nbsp; - but then you get back a flat structure of all the matches you want<br> &nbsp; &nbsp; &nbsp; &nbsp; - I want a left recursive structure<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's easier to parse things that look left-recursive<br> &nbsp; &nbsp; &nbsp; &nbsp; - you only have to handle two arguments, not N<br> &nbsp; &nbsp; &nbsp; &nbsp; - left-recursion transform might be nice in grammars, if it's generic...</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - for now, all I need in Perl 1 is operator precedence<br> &nbsp; &nbsp; &nbsp; &nbsp; - looks pretty cool so far<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll try to finish it off by the end of the day<br> &nbsp; &nbsp; &nbsp; &nbsp; - it'd be nice to have comments in the syntax of the independent grammar,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; but...</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - my friend the crazy C++ programmer is trying to learn a new language<br> &nbsp; &nbsp; &nbsp; &nbsp; - I invited him to learn Perl 6<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm going to try to teach him Perl 6 without any past knowledge of<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; dynamic languages</p> luqui 2006-01-12T01:35:04+00:00 perl6 Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/28089?from=rss <p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Stevan and Audrey are working on PIL2 minilanguage<br> &nbsp; &nbsp; &nbsp; &nbsp; - they want to talk about how to optimize it<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll corner Allison and have her show me how to hook it up to TGE</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - probably won't have my Parrot day until Friday<br> &nbsp; &nbsp; &nbsp; &nbsp; - I still plan on working next on supporting more operations in Punie<br> &nbsp; &nbsp; &nbsp; &nbsp; - probably will do a whole pile at once<br> &nbsp; &nbsp; &nbsp; &nbsp; - I need to genericize it not to parse on the name of the operation<br> &nbsp; &nbsp; &nbsp; &nbsp; - "there's an identifier here"<br> &nbsp; &nbsp; &nbsp; &nbsp; - then add a step to do semantic checking<br> &nbsp; &nbsp; &nbsp; &nbsp; - check for only valid operations</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - sounds like what PIL2 needs</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - very co-useful</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is Roberta back in town?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we're supposed to talk to a Perl-friendly company soon<br> &nbsp; &nbsp; &nbsp; &nbsp; - not sure if it'll work during the holidays<br> &nbsp; &nbsp; &nbsp; &nbsp; - will send out a few more review copies</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm porting PGE to Perl 6<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's really fast<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can do the fundamental operations in an hour<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't found the easiest way<br> &nbsp; &nbsp; &nbsp; &nbsp; - will probably look at how PGE does it<br> &nbsp; &nbsp; &nbsp; &nbsp; - using CPS, as it's easy for the easy stuff<br> &nbsp; &nbsp; &nbsp; &nbsp; - the general quantified style isn't as easy that way<br> &nbsp; &nbsp; &nbsp; &nbsp; - coming along a really well<br> &nbsp; &nbsp; &nbsp; &nbsp; - Perl 6 is a nice language to write in, compared to PIR</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is this as an exercise for fun?<br> &nbsp; &nbsp; &nbsp; &nbsp; - is it for a chunk of Pugs?<br> &nbsp; &nbsp; &nbsp; &nbsp; - does it eventually need to happen?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - all three<br> &nbsp; &nbsp; &nbsp; &nbsp; - our best backend, which is JavaScript right now, doesn't even have rules<br> &nbsp; &nbsp; &nbsp; &nbsp; - that needs to happen to get stuff out fast</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - if the lowest level you guarantee to support is the HLL, you have to<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; implement a lot of stuff in the HLL to support it everywhere</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - what's your status of outstanding design decisions?<br> &nbsp; &nbsp; &nbsp; &nbsp; - it'd be nice to get a concrete list of missing design<br> &nbsp; &nbsp; &nbsp; &nbsp; - what we need for 6.0<br> &nbsp; &nbsp; &nbsp; &nbsp; - it seems like that'll become a list of blockers soon<br> &nbsp; &nbsp; &nbsp; &nbsp; - we're getting runnable implementations that run</p> luqui 2005-12-21T23:49:43+00:00 perl6 Core rule calculus http://use.perl.org/~luqui/journal/28064?from=rss <p><a href="http://en.wikipedia.org/wiki/Lambda_calculus">Lambda calculus</a> is a beautiful compiler backend. When I wrote my <a href="http://svn.luqui.org/svn/misc/luke/work/code/haskell/typist">Toy language</a> a month or so ago, I used this core data structure:</p><blockquote><div><p> <tt>data AST<br>&nbsp; &nbsp; = Lambda&nbsp; VarName AST<br>&nbsp; &nbsp; | Apply&nbsp; &nbsp;AST AST<br>&nbsp; &nbsp; | Var&nbsp; &nbsp; &nbsp;VarName<br>&nbsp; &nbsp; | Literal Value</tt></p></div> </blockquote><p>That's it. Those four nodes and I could do anything. I wrote an interpreter for this language in half an hour. I wrote a type inferencer in an hour, scrapped it, and took another hour to write another type inferencer. That's the beauty of a small core calculus. The optimial calculus is hard to come up with, but once you have it, <i>everything</i> else is cake. That's why PIL is so important.</p><p>Recently I've been porting PGE to Perl 6, so we can have rules in the Javascript and Perl 5 backends. Perl 6 rules are another fairly simple language. However, Patrick Michaud's calculus has 15 nodes. That's huge! I mean, it's not huge if you're taking the approach of executing the parse tree, as is done by Perl 5, P6C (the initial take of Perl 6 written in Perl 5 for Parrot), and Pugs's first runtime. But my toy language was a powerful experience for me, so I'd like to come up with a simple calculus for rules.</p><p>The following three nodes get you to <a href="http://en.wikipedia.org/wiki/Context-free_grammar">context-free </a> (displayed in Haskell for its consice description of data structures, even though I'm actually writing it in Perl 6):</p><blockquote><div><p> <tt>data Rule<br>&nbsp; &nbsp; = Literal String<br>&nbsp; &nbsp; | Union&nbsp; &nbsp;Rule Rule<br>&nbsp; &nbsp; | Concat&nbsp; Rule Rule</tt></p></div> </blockquote><p>Anyone with experience in formal languages will say "That's not context-free! That's not even <a href="http://en.wikipedia.org/wiki/Regular_language">regular</a>!" Oh, but I neglected to mention: I allow infinite, recursive structures. It's easy to see how to build an inifite structure for the <a href="http://en.wikipedia.org/wiki/Kleene_star">Kleene star</a>. A similar technique will allow you to model every context-free language.</p><p>After playing with this structure a little bit, I have concluded that allowing infinite structures is a bad idea. It means that in order to do any processing that isn't straight-up execution, you have to use the graph variants of whatever tree algorithms you were going to use. Those can get complicated, and some algorithms even become impossible. It's like the waterbed theory: I'm pushing <i>too much</i> complexity out of the core calculus.</p><p>If we disallow recursive structures, then we need to add Kleene star to get back to regular. To get to context free from here, we basically need symbolic reference. But I'm not going to do that. I have an objection to symbolic reference, and that is that you have to add all sorts of machinery to get it to work in a powerful way: Lexical pads, full qualification, etc. What I'm looking for is a lambda-calculusesque <a href="http://en.wikipedia.org/wiki/Fixed_point_combinator">fix</a>, which allows you to build recursion without symbolic lookup or infinite structures.</p><p>Maybe that means that I just mimic the lambda calculus and do pretty much what <a href="http://www.cs.uu.nl/~daan/parsec.html">Parsec</a> does: build a <i>value</i> out of functions that can be used to match strings. That gives you the full power of the lambda calculus, and all the research that has been done on it, to match strings. And Parsec can do predictive parsing, which is something I've wanted. The only thing it can't do is bottom-up parsing, which is also something I've wanted. But bottom-up parsing is more restricted than Perl 6 rules, so maybe that belongs at a earlier stage in processing.</p> luqui 2005-12-20T04:26:22+00:00 journal Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27992?from=rss <p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - worked on Pod::Simple<br> &nbsp; &nbsp; &nbsp; &nbsp; - almost have Parrot recompiled<br> &nbsp; &nbsp; &nbsp; &nbsp; - network trouble here, making it hard to get the code<br> &nbsp; &nbsp; &nbsp; &nbsp; - almost have the change to use precompiled PGE grammars working<br> &nbsp; &nbsp; &nbsp; &nbsp; - the next goal in Punie is to start parsing and compiling other<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; operations besides print</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - fetch, store, and rewind tape, right?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - what's the next most important thing after print?</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - a conditional<br> &nbsp; &nbsp; &nbsp; &nbsp; - print "ok 1" if 1</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that might be more advanced than just adding an operation</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - increment, then decrement<br> &nbsp; &nbsp; &nbsp; &nbsp; - Audrey is in the process of retooling Ingy's Perl6::Bible into p6doc<br> &nbsp; &nbsp; &nbsp; &nbsp; - synthesizing from the canonical spec<br> &nbsp; &nbsp; &nbsp; &nbsp; - trying to make them more accessible<br> &nbsp; &nbsp; &nbsp; &nbsp; - they roped in Skud<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're trying to make it a better starting point<br> &nbsp; &nbsp; &nbsp; &nbsp; - trying to extract useful information from the Synopses<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're a bit sad that Perl 6 Essentials is not open</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - so am I</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it sounds like Larry is making insane progress<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's a wonder having something else to work on</p> luqui 2005-12-15T00:10:13+00:00 perl6 Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27892?from=rss <p> Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Punie now compiles and executes statements<br> &nbsp; &nbsp; &nbsp; &nbsp; - print a single digit, multiple digits, or a string with word characters<br> &nbsp; &nbsp; &nbsp; &nbsp; - no space characters</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's certainly a start</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I want to use Patrick's Text::Balanced hack<br> &nbsp; &nbsp; &nbsp; &nbsp; - oh, it also parses multiple statements</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's a good way of keeping your code concise<br> &nbsp; &nbsp; &nbsp; &nbsp; - is Roberta still gone?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - she'll be back December 14th</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm doing finals<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're final projects<br> &nbsp; &nbsp; &nbsp; &nbsp; - thinking about the type system stuff in my free time<br> &nbsp; &nbsp; &nbsp; &nbsp; - also talked to Autrijus about it<br> &nbsp; &nbsp; &nbsp; &nbsp; - he convinced me that leaving out a type system is a bad idea for<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; interoperability<br> &nbsp; &nbsp; &nbsp; &nbsp; - he said some extremely large undecidable calculus<br> &nbsp; &nbsp; &nbsp; &nbsp; - trying to come up with a good type system as dynamic at Perl 5's at<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; runtime, but at compile time</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - doesn't sound like much</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - fairly well-researched except not at all</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - only worth two or three PhDs</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - when do you start to free up again?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - my last final is on Monday<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll probably start madly hacking, as long as I have something to<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; procrastinate</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - merrily hacking away on the Perl 5 to Perl 5 translator<br> &nbsp; &nbsp; &nbsp; &nbsp; - translates 73% of the test suite successfully<br> &nbsp; &nbsp; &nbsp; &nbsp; - successfully collecting all the type information that the compiler loses<br> &nbsp; &nbsp; &nbsp; &nbsp; - starting to think about how I'll use that information<br> &nbsp; &nbsp; &nbsp; &nbsp; - also for translating to Perl 6<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's still in thought status<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm past the hump on the thing<br> &nbsp; &nbsp; &nbsp; &nbsp; - I guess there are two though<br> &nbsp; &nbsp; &nbsp; &nbsp; - getting the first 5% of the tests to pass was really hard<br> &nbsp; &nbsp; &nbsp; &nbsp; - probably the last 5% will be really hard too<br> &nbsp; &nbsp; &nbsp; &nbsp; - then I can think about downloading and translating all of CPAN back to<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; itself<br> &nbsp; &nbsp; &nbsp; &nbsp; - the tricky thing is I'm not sure what to do about BEGIN blocks that<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; skip tests<br> &nbsp; &nbsp; &nbsp; &nbsp; - don't bother compiling the rest<br> &nbsp; &nbsp; &nbsp; &nbsp; - maybe I need a shim that says "this BEGIN block said to exit, but don't"<br> &nbsp; &nbsp; &nbsp; &nbsp; - usually a runtime reason, not a compile-time reason<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm only interested to running until CHECK time basically<br> &nbsp; &nbsp; &nbsp; &nbsp; - also worth two or three PhDs</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - then do you plan to spit out an arbitrary AST or go straight to Perl 6?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I want to be able to spit out the AST, just for Perl 5<br> &nbsp; &nbsp; &nbsp; &nbsp; - somewhere in there<br> &nbsp; &nbsp; &nbsp; &nbsp; - when I have that done<br> &nbsp; &nbsp; &nbsp; &nbsp; - we can open it up<br> &nbsp; &nbsp; &nbsp; &nbsp; - pulling the information out of Perl 5 is the insane part of it<br> &nbsp; &nbsp; &nbsp; &nbsp; - having the AST out in some form cleanly is a point at which we can open<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; up the project to multiple contributors</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can see some of the crazy Pugs kids compiling straight to JavaScript</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - to PIL first<br> &nbsp; &nbsp; &nbsp; &nbsp; - then we get JavaScript automatically!</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - also Perl 5! yay!</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - when did you pull from blead?<br> &nbsp; &nbsp; &nbsp; &nbsp; - not sure how painful the merge back will be</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm at 5.9.2 at the moment<br> &nbsp; &nbsp; &nbsp; &nbsp; - it ought to be mergeable<br> &nbsp; &nbsp; &nbsp; &nbsp; - this hairy dance back and forth between the program which does the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; final translation and the internal code which spits out the initial XML<br> &nbsp; &nbsp; &nbsp; &nbsp; - my basic philosophy is to make minimal changes to the Perl core<br> &nbsp; &nbsp; &nbsp; &nbsp; - to what extent you just mark up the things as they're going out and<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; messing up the tree versus intuiting what should have been there...<br> &nbsp; &nbsp; &nbsp; &nbsp; - only time will tell whether I made the right decisions<br> &nbsp; &nbsp; &nbsp; &nbsp; - I figured that you can drive it one way or another<br> &nbsp; &nbsp; &nbsp; &nbsp; - one way and you break the semantics of existing code too much<br> &nbsp; &nbsp; &nbsp; &nbsp; - "Just don't do constant folding" breaks plenty of things, such as<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; interpolated constant subroutines<br> &nbsp; &nbsp; &nbsp; &nbsp; - too much guessing after the fact means I may not have guessed correctly<br> &nbsp; &nbsp; &nbsp; &nbsp; - there are intermediate forms in there too<br> &nbsp; &nbsp; &nbsp; &nbsp; - go ahead and keep the same structure<br> &nbsp; &nbsp; &nbsp; &nbsp; - then annotate it with just a little extra type information for the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; backend<br> &nbsp; &nbsp; &nbsp; &nbsp; - I've been doing that compromise more and more<br> &nbsp; &nbsp; &nbsp; &nbsp; - seems to work out pretty well<br> &nbsp; &nbsp; &nbsp; &nbsp; - the ordinary regression tests have two or three failures that need<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; fixing before the merge<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't test that part of it as often as I test the translator</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I bet we can find some help to deal with that</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - checked in Test::More in PIR<br> &nbsp; &nbsp; &nbsp; &nbsp; - talked to Jerry Gay and it looks like we have an easy way to add PIR<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tests to the Perl testing harness<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll check in some of my library tests and see how that works<br> &nbsp; &nbsp; &nbsp; &nbsp; - should let us rely on those a little bit more</p> luqui 2005-12-08T07:50:53+00:00 perl6 Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27720?from=rss <p> Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - continuing to work on Punie using TGE<br> &nbsp; &nbsp; &nbsp; &nbsp; - working on a grammar to convert Punie match results to PAST nodes<br> &nbsp; &nbsp; &nbsp; &nbsp; - think I have a complete set of PAST nodes<br> &nbsp; &nbsp; &nbsp; &nbsp; - simple core class and subclasses<br> &nbsp; &nbsp; &nbsp; &nbsp; - mostly based on Pugs's PIL<br> &nbsp; &nbsp; &nbsp; &nbsp; - didn't bother with Haskell-specific nodes</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - PIL 1 or PIL 2?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - looked at both<br> &nbsp; &nbsp; &nbsp; &nbsp; - closer to PIL 2<br> &nbsp; &nbsp; &nbsp; &nbsp; - not exactly either one</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can't figure out where PIL 2 encodes its structure<br> &nbsp; &nbsp; &nbsp; &nbsp; - it works? That's cool<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't know how</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm not familiar enough with Haskell to mimic the implementation<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I don't need to mimic the implementation<br> &nbsp; &nbsp; &nbsp; &nbsp; - seemed like a nice set of abstract nodes to start<br> &nbsp; &nbsp; &nbsp; &nbsp; - hope to finish that Punie match trees -&gt; PAST grammar and nodes and<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tests today<br> &nbsp; &nbsp; &nbsp; &nbsp; - might play with opcode syntax tree<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's going pretty fast so far<br> &nbsp; &nbsp; &nbsp; &nbsp; - Roberta is on vacation for the next three weeks<br> &nbsp; &nbsp; &nbsp; &nbsp; - we're still passing around license and contributor agreements for review<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; now<br> &nbsp; &nbsp; &nbsp; &nbsp; - if you have suggestions for people to review it, please let me know</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - a few minor updates to S5<br> &nbsp; &nbsp; &nbsp; &nbsp; - answering questions about that<br> &nbsp; &nbsp; &nbsp; &nbsp; - minor changes there<br> &nbsp; &nbsp; &nbsp; &nbsp; - added a Perl 5 pattern parser for PGE on Thursday<br> &nbsp; &nbsp; &nbsp; &nbsp; - it understands rudimentary and basic Perl 5 patterns<br> &nbsp; &nbsp; &nbsp; &nbsp; - Jerry Gay is porting over Perl 5 regex test suite<br> &nbsp; &nbsp; &nbsp; &nbsp; - we can test PGE against them<br> &nbsp; &nbsp; &nbsp; &nbsp; - there are 800 tests, he has to skip 290, and 155 are failing<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll add a few things to handle those as time permits<br> &nbsp; &nbsp; &nbsp; &nbsp; - not a high priority</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's a fairly late milestone</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll work on it when I feel like getting a few quick tests out of the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; way<br> &nbsp; &nbsp; &nbsp; &nbsp; - ought to be handoffable to someone who expresses interest<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll post a message about that<br> &nbsp; &nbsp; &nbsp; &nbsp; - there's already a test suite<br> &nbsp; &nbsp; &nbsp; &nbsp; - they get a lot of quick wins<br> &nbsp; &nbsp; &nbsp; &nbsp; - otherwise, I'm trying to catch up with Larry's changes<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm just going to have to reread the Synopses again</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you were originally planning to work from a snapshot of the Synopses<br> &nbsp; &nbsp; &nbsp; &nbsp; - did that work out?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we'd have to take another one to do that now</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - are you spending enough time churning that it's worthwhile<br> &nbsp; &nbsp; &nbsp; &nbsp; - or are the changes useful enough to track?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're useful</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - hope to make more progress on Parrot Test::More this weekend</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - scrapped theory.pod v1, working on v2<br> &nbsp; &nbsp; &nbsp; &nbsp; - it has nothing to do with theories anymore<br> &nbsp; &nbsp; &nbsp; &nbsp; - reading TaPL<br> &nbsp; &nbsp; &nbsp; &nbsp; - coming up with a core calculus for types<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's the the same calculus as for execution<br> &nbsp; &nbsp; &nbsp; &nbsp; - embracing executing code at compile-time<br> &nbsp; &nbsp; &nbsp; &nbsp; - leveraging that into the type system<br> &nbsp; &nbsp; &nbsp; &nbsp; - hope to start with something simple<br> &nbsp; &nbsp; &nbsp; &nbsp; - writing a toy language right now<br> &nbsp; &nbsp; &nbsp; &nbsp; - hope to implement union types and subtyping within the toy language<br> &nbsp; &nbsp; &nbsp; &nbsp; - wondering how I can do inference in that<br> &nbsp; &nbsp; &nbsp; &nbsp; - but it looks like I can build just about everything we need<br> &nbsp; &nbsp; &nbsp; &nbsp; - way cool<br> &nbsp; &nbsp; &nbsp; &nbsp; - surprised me<br> &nbsp; &nbsp; &nbsp; &nbsp; - being thoroughly impressed with Haskell<br> &nbsp; &nbsp; &nbsp; &nbsp; - it was up and running in 200 lines of code<br> &nbsp; &nbsp; &nbsp; &nbsp; - becoming more of a convert every day</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Patrick<br> &nbsp; &nbsp; &nbsp; &nbsp; - meta-information from match nodes<br> &nbsp; &nbsp; &nbsp; &nbsp; - you're printing line number and source string in the dump?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - PGE's built-in dump?<br> &nbsp; &nbsp; &nbsp; &nbsp; - not using Data::Dumper?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm using Data::Dumper<br> &nbsp; &nbsp; &nbsp; &nbsp; - name of the rule, source string, character number on the line?<br> &nbsp; &nbsp; &nbsp; &nbsp; - is there a way to get the line number of the source code for the match?<br> &nbsp; &nbsp; &nbsp; &nbsp; - how can I get that string you're printing in the dump?<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's the raw source that this particular rule matched</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - for every match object, there are from() and to() method<br> &nbsp; &nbsp; &nbsp; &nbsp; - offsets to the beginning and the end of the match<br> &nbsp; &nbsp; &nbsp; &nbsp; - the match object contains a reference to the entire string it's matching<br> &nbsp; &nbsp; &nbsp; &nbsp; - also then has the offsets for the portion that it matched<br> &nbsp; &nbsp; &nbsp; &nbsp; - when you ask a match object for its string value, it gives you that<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; substring<br> &nbsp; &nbsp; &nbsp; &nbsp; - in Parrot, if you assign it to a string register, it stringifies<br> &nbsp; &nbsp; &nbsp; &nbsp; - you get the substring that it matches<br> &nbsp; &nbsp; &nbsp; &nbsp; - match objects duplicate the semantics of S5<br> &nbsp; &nbsp; &nbsp; &nbsp; - if you ask a match object for an integer, it gives you the integer<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; conversion of the string<br> &nbsp; &nbsp; &nbsp; &nbsp; - boolean, did it match?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - lines are harder</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - because you have the from position, you can use it against the original<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; string and find out how many newlines occurred before it</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - ugh</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it'd be nice to report what line of the source file had an error as I<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; write compilers</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - who cares about cost when you report an error?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's better than incurring the cost of counting newlines as you go<br> &nbsp; &nbsp; &nbsp; &nbsp; - just count them in the string<br> &nbsp; &nbsp; &nbsp; &nbsp; - I could write a method for it in the match object<br> &nbsp; &nbsp; &nbsp; &nbsp; - but that's all it would do</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - people will want to annotate the parse tree node with the line number<br> &nbsp; &nbsp; &nbsp; &nbsp; - if it has a run-time error, it can report the line number</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's pretty easy to do<br> &nbsp; &nbsp; &nbsp; &nbsp; - no problem<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm not certain how to fit that in<br> &nbsp; &nbsp; &nbsp; &nbsp; - whenever we're matching, we have to figure out where to do that</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - need some rule with a closure that annotates the tree at newline points</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - but you have to count every newline, even if it's in an embedded string<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; or heredoc</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you don't need to annotate every node<br> &nbsp; &nbsp; &nbsp; &nbsp; - just the interesting things<br> &nbsp; &nbsp; &nbsp; &nbsp; - match objects tend to know a little bit about their context<br> &nbsp; &nbsp; &nbsp; &nbsp; - each could easily report how many newlines were prior to it<br> &nbsp; &nbsp; &nbsp; &nbsp; - and how many newlines it contains</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is this the wrong solution?<br> &nbsp; &nbsp; &nbsp; &nbsp; - is it more at the level of where we read the file?<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I just read up to the maximum buffer size</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - me too<br> &nbsp; &nbsp; &nbsp; &nbsp; - but this'll change in the future anyway<br> &nbsp; &nbsp; &nbsp; &nbsp; - as long as the match objects contain the offset... provided you have the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; source lying around somewhere</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I think you're right to delay expensive operations<br> &nbsp; &nbsp; &nbsp; &nbsp; - if I store the offset<br> &nbsp; &nbsp; &nbsp; &nbsp; - figure out some way to make the original source string available to the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; error reporting routine...</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I've come up with enough cases where it seems useful to have a target()<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; method on match objects<br> &nbsp; &nbsp; &nbsp; &nbsp; - return the whole string they're matching against</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we want to support streams too</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's not a permanent idea for the design<br> &nbsp; &nbsp; &nbsp; &nbsp; - we could throw it in right now</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's just a question of where to put the error reporting</p> luqui 2005-11-24T07:11:03+00:00 perl6 New theories http://use.perl.org/~luqui/journal/27688?from=rss <p>Okay, here's an update on my current thinking for theory.pod version 2. For those of you who read, understood, and were comfortable with theory.pod version 1, prepare to be surprised. I'm completely turning it on its ear. However, I think there won't be a big acceptance issue, since nobody (including me) understood and was comfortable with version 1.</p><p>Version 1 gave Perl a (broken) type system with tagged union types and type classes. The system, had it not been broken, would have been turing-complete, and thus you could do all the fancy stuff you wanted, but you'd have to encode it in the language of the type system. For instance, if you wanted to make a vector class that would only allow you to add vectors of the same length, you could do that, but it would be a major pain to implement Peano naturals to encode numbers in the type system.</p><p>But that's so stupid. We have a great language, Perl 6, which knows all about numbers (among other things<nobr> <wbr></nobr>;-), and we're forced to recreate them for the type system. The number one goal of version 2 is to get rid of this stupidity, and let you talk about the types of your Perl program in Perl. Here are the features I'm trying to support (in rough order of importance; i.e. rough order of required elegance):</p><p> &nbsp; &nbsp; &nbsp; &nbsp; * Type metaprogramming; i.e. talk about types in Perl, not some weird type language<br> &nbsp; &nbsp; &nbsp; &nbsp; * Roles and Classes with mandatory allomorphism (a property of version 1: types are only interfaces)<br> &nbsp; &nbsp; &nbsp; &nbsp; * Type classes and parametric polymorphism<br> &nbsp; &nbsp; &nbsp; &nbsp; * Inferrable<br> &nbsp; &nbsp; &nbsp; &nbsp; * Tagged unions with allomorphism<br> &nbsp; &nbsp; &nbsp; &nbsp; * Union types [1]</p><p>At the moment, I'm doing a lot of research out of TaPL and ATTaPL. It's hard to get a concrete grasp on what those books are saying sometimes, so I'm going to implement a little syntaxless language (not unlike Blondie) with the hard parts of the above points: in particular, an inferrable, metaprogrammable type system.</p><p>Incidentally, I think that an inferrable metaprogrammable system needs a logic engine. Cool. I also think that embedding a logic engine in Perl 6 can be done in a unintrusive and easy-to-implement way, providing (and this is the hard part, but it is already specced) support for hypotheticals.</p><p>[1] Which happen to screw over inference algorithms. That's why it's way at the bottom of the list. If it doesn't fit, I'll even consider trying to argue us out of supporting them.</p> luqui 2005-11-21T23:57:45+00:00 journal The fourth paradigm is... http://use.perl.org/~luqui/journal/27652?from=rss <p>Okay, I thought about this some. I walked around the house, talked to myself, played with some fresh fruit (moving them here and there, describing their properties), and I think I've come up with a very vague idea of this fourth control paradigm.</p><p>First, here's how I started. I figured, I'm trying to classify the three existing control paradigms (imperative, functional, logical) into two orthogonal properties. Well, it has to be one of these:</p><blockquote><div><p> <tt>&nbsp; &nbsp; &nbsp; A&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; B<br>X | Imperative | Functional |<br>Y | Logical&nbsp; &nbsp; | ???&nbsp; &nbsp; &nbsp; &nbsp; |<br> &nbsp; <br>&nbsp; &nbsp; &nbsp; A&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; B<br>X | Functional | Imperative |<br>Y | Logical&nbsp; &nbsp; | ???&nbsp; &nbsp; &nbsp; &nbsp; |<br> &nbsp; <br>&nbsp; &nbsp; &nbsp; A&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; B<br>X | Logical&nbsp; &nbsp; | Functional |<br>Y | Imperative | ???&nbsp; &nbsp; &nbsp; &nbsp; |</tt></p></div> </blockquote><p>That covers all the possible cases. I then did a little scanning back and forth, and settled on the second diagram, where A ~~ "doesn't change anything" and B ~~ "does change something". Then I did some brainstorming to figure out what X and Y were based on that.</p><p>And I think this is it: You give a functional program an object, and it tells you some property of the object (these can be very complex objects and properties, but it ultimately reduces to that). You give a logical program a property, and it gives you an object that satisfies that.</p><p>Then, the imperative parallel is: You give an imperative program an *action* and it tells you the result. So, the fourth paradigm is the converse of this; a generalized inverse kinematics engine: you give it a result, and it tells you the action.</p><p>A prime example of this kind of paradigm is the UNIX <tt>diff</tt> program. You give it a file, and the result of some action on that file, and it tells you how to modify the original to get the result. Also, in gaming, pathfinding and inverse kinematics (the process of finding how to move, say, a human body from one position to another in a physically sound way) are both examples of this paradigm.</p><p>So what does a language that enables this paradigm look like? And what would you name it?</p> luqui 2005-11-19T09:26:48+00:00 journal What is the fourth paradigm? http://use.perl.org/~luqui/journal/27651?from=rss <p>At OSCON, Ovid cited the four paradigms like this:</p><p> &nbsp; &nbsp; &nbsp; &nbsp; * Procedural<br> &nbsp; &nbsp; &nbsp; &nbsp; * Object-oriented<br> &nbsp; &nbsp; &nbsp; &nbsp; * Functional<br> &nbsp; &nbsp; &nbsp; &nbsp; * Logical</p><p>I've also seen this list in several other places. However, I think this mixes up its concepts a bit. There are really two orthogonal properties acting here: the <i>abstraction style</i> and the <i>control style</i>.</p><p>The abstraction style refers to how you break up the logic of your program. It falls into two categories:</p><p> &nbsp; &nbsp; &nbsp; &nbsp; * Procedural<br> &nbsp; &nbsp; &nbsp; &nbsp; * Object-oriented</p><p>The difference is what you put in name. In the procedural style, you put mappings (functions) or actions (procedures) into names. In the object-oriented style, you put things (objects) and messages (methods) into names.</p><p>The control style describes how the control flows through the program. It falls into three categories:</p><p> &nbsp; &nbsp; &nbsp; &nbsp; * Imperative<br> &nbsp; &nbsp; &nbsp; &nbsp; * Functional<br> &nbsp; &nbsp; &nbsp; &nbsp; * Logical</p><p>In the imperative style, you are instructing the program to do things, to manipulate the state of the world. In the functional style, you are instructing the program to compute things, to evaluate a very complicated mathematical function. In the logical style, you are instructing the program to find objects that satisfy a complex condition.</p><p>Here's a table of common languages:</p><blockquote><div><p> <tt>Abstraction | Procedural&nbsp; &nbsp; | OO<br>Control&nbsp; &nbsp; &nbsp;+---------------+------------<br>Imperative&nbsp; | C&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;| C++, Java<br>Functional&nbsp; | Scheme, ML&nbsp; &nbsp; | OCaml, Haskell, Lisp (under CLOS)<br>Logical&nbsp; &nbsp; &nbsp;| Prolog&nbsp; &nbsp; &nbsp; &nbsp; | Curry</tt></p></div> </blockquote><p>A lot of these languages actually cut across the table in various ways. If a language is capable of OO, I've put it in the OO section, even if it has procedural capabilities as well. In fact, all of these languages have procedural capabilities except Java (which still does, but tries to deny it).</p><p>Anyway, what I'm wondering has to do with the control style. Three is a strange number for a classification. Usually classifications are powers of two: combinations of orthogonal binary capabilities. What are the orthogonal capabilities in the control style? What's the combination of those that has gone unnoticed?</p> luqui 2005-11-19T08:48:57+00:00 journal theory.pod sucks http://use.perl.org/~luqui/journal/27646?from=rss <p>In trying to prove some interesting properties about theories relating to multimethods, I stumbled upon this fact that completely invalidates them. I'm embarassed to post it here, since it is so simple and obvious that I should have seen it sooner. But, alas, I was cursed by my hubris, not verifying that the most essential properties held, and just assuming that they did. This is why mathematicians insist on being rigorous!</p><p>So, let's illustrate by example. Let's say we have a theory Ring{^T} that requires that ^T have a ring structure. We have a role Int for integers, and a role Nat for naturals. Let's also call the set of integers Z and the set of naturals N. Clearly N is a subset of Z.</p><blockquote><div><p> <tt>Given Ring{Int} (the integers form a ring),<br>&nbsp; &nbsp; &nbsp; Int{Z} and Nat{N} by definition<br>Ring{^T} &lt;= Int{^T}&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # expand model definition<br>N subset Z implies Int{N}, so Int{N} # role relation<br>Ring{N} since Int{N}.</tt></p></div> </blockquote><p>But the naturals do not form a ring (under integer operations), though I seemed to have proven that they do. The error came in when I "expanded the model definition" from <tt>Ring{Int}</tt> to <tt>Ring{^T} &lt;= Int{^T}</tt>.</p><p>This can be fixed. The changes necessary to fix this are very minor from the point of view of the theory user, but very major from the point of view of the theorist. In particular, they imply that theory expressions can no longer be reduced to first-order constraints on unnamed types. Instead, the system becomes unbounded-order, which is a bummer for the implementor.</p><p>However, I have that unbounded-order system almost entirely formulated in my mind. I'm pretty sure I can keep the benefits of theories while maintaining the solvability of an <i>explicitly annotated</i> system (we know that completely inferring a system this complex is equivalent to the halting problem and thus undecidable). I hope that it is also inferrable "most of the time". Updates soon.</p> luqui 2005-11-18T22:55:10+00:00 journal Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27605?from=rss <p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - hacking on Pugs a lot<br> &nbsp; &nbsp; &nbsp; &nbsp; - getting more comfortable with its internals<br> &nbsp; &nbsp; &nbsp; &nbsp; - now Haskell itself isn't an issue<br> &nbsp; &nbsp; &nbsp; &nbsp; - I just have to get my brain around Autrijus's brain, which is difficult<br> &nbsp; &nbsp; &nbsp; &nbsp; - but it's coming along<br> &nbsp; &nbsp; &nbsp; &nbsp; - thought also about the laws of Perl 6 builtins a little bit<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can't come up with anything</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's like trying to think up the laws of English</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - reading "Types and Programming Languages"<br> &nbsp; &nbsp; &nbsp; &nbsp; - how would you implement an inferencer for a purely predicative system<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; like Theory?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - checked in TGE last week<br> &nbsp; &nbsp; &nbsp; &nbsp; - that and refactoring and documentation took up my type last week<br> &nbsp; &nbsp; &nbsp; &nbsp; - I missed the implementors meeting because I forgot about it<br> &nbsp; &nbsp; &nbsp; &nbsp; - currently working on the AST in the Punie repository<br> &nbsp; &nbsp; &nbsp; &nbsp; - using the tree grammar stuff there<br> &nbsp; &nbsp; &nbsp; &nbsp; - I've just built up some node objects<br> &nbsp; &nbsp; &nbsp; &nbsp; - building up a tree grammar to go from Punie PGE output to AST<br> &nbsp; &nbsp; &nbsp; &nbsp; - the next step is nodes for the opcode syntax tree<br> &nbsp; &nbsp; &nbsp; &nbsp; - another grammar to go from the AST to the OST<br> &nbsp; &nbsp; &nbsp; &nbsp; - the last step is the little bit to compile the OST into Parrot<br> &nbsp; &nbsp; &nbsp; &nbsp; - will probably do something similar to Leo's PAST prototype<br> &nbsp; &nbsp; &nbsp; &nbsp; - it has the hooks for telling IMCC how to compile down a data structure</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I have a commit bit!<br> &nbsp; &nbsp; &nbsp; &nbsp; - bright and shiny<br> &nbsp; &nbsp; &nbsp; &nbsp; - I shall have to use it shortly<br> &nbsp; &nbsp; &nbsp; &nbsp; - working on wreaking havoc on the Synopses this past week<br> &nbsp; &nbsp; &nbsp; &nbsp; - Luke has been very helpful in getting me to clarify my thinking in<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; places where it's too muddy<br> &nbsp; &nbsp; &nbsp; &nbsp; - other than that, just a lot of infrastructural things<br> &nbsp; &nbsp; &nbsp; &nbsp; - getting the latest Parrot things<br> &nbsp; &nbsp; &nbsp; &nbsp; - now I have bleadparrot and bleadpugs and everything<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can actually contribute on that level<br> &nbsp; &nbsp; &nbsp; &nbsp; - mostly I think I'll just be looking at tests and things<br> &nbsp; &nbsp; &nbsp; &nbsp; - checking validity<br> &nbsp; &nbsp; &nbsp; &nbsp; - also learning XSLT<br> &nbsp; &nbsp; &nbsp; &nbsp; - mostly because I don't think a language that that's ugly should be<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; able to do things that Perl can't<br> &nbsp; &nbsp; &nbsp; &nbsp; - this fits into the tree transformation stuff<br> &nbsp; &nbsp; &nbsp; &nbsp; - there are things it does better than attribute grammars<br> &nbsp; &nbsp; &nbsp; &nbsp; - they seem not to handle lists of children well</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - more toward named nodes</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's something we have to fix<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's something XSLT does better</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - attribute grammars aren't that good at looking around</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're very constrained as to how you look around<br> &nbsp; &nbsp; &nbsp; &nbsp; - there's some power in that</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - have you seen CDuce?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I haven't looked at it</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it has an interesting signature syntax</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - now wait, I did look at it</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - your list of predicate type signatures thing is reminiscent</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that was some of the grist<br> &nbsp; &nbsp; &nbsp; &nbsp; - you're explicit about AND and OR in CDuce<br> &nbsp; &nbsp; &nbsp; &nbsp; - I did look at that</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - does XPath add better selectors to XSLT<br> &nbsp; &nbsp; &nbsp; &nbsp; - or does it have better node selectors on its own?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's procedural, but more top-down</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - sort of like a regular expression?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - yeah<br> &nbsp; &nbsp; &nbsp; &nbsp; - sort of like a hierarchical SQL statement<br> &nbsp; &nbsp; &nbsp; &nbsp; - we do need a better syntax than XML though<br> &nbsp; &nbsp; &nbsp; &nbsp; - may take another whack at my Perl 5 -&gt; Perl 5 thing<br> &nbsp; &nbsp; &nbsp; &nbsp; - try to do that with XSLT instead of Perl</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's what I tried to do a few years back<br> &nbsp; &nbsp; &nbsp; &nbsp; - I learned that you can be right and still fail with bad code</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - primarily worked on S5<br> &nbsp; &nbsp; &nbsp; &nbsp; - checked in the latest draft I sent out<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's not on the website yet</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I believe Robert has a daily cron update</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm happy to make corrections if anyone has comments</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you could make yourself the maintainer too</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm planning to send you some minor feedback</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I also tried to reduce some redundancies<br> &nbsp; &nbsp; &nbsp; &nbsp; - if I omitted anything, let me know<br> &nbsp; &nbsp; &nbsp; &nbsp; - more updates to the grammar engine<br> &nbsp; &nbsp; &nbsp; &nbsp; - now does lookbehinds, though it cheats for now<br> &nbsp; &nbsp; &nbsp; &nbsp; - a variety of other small rules<br> &nbsp; &nbsp; &nbsp; &nbsp; - mostly doing some internal Parrot things<br> &nbsp; &nbsp; &nbsp; &nbsp; - driven by the desire to have Unicode work<br> &nbsp; &nbsp; &nbsp; &nbsp; - better string escaping</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - very good job on S5 too, by the way</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - convenient, that he's the one implementing it</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's much easier to cut than it is to create</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - for you, maybe<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm too sentimental</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - give me a knife<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm ruthless when it comes to prose</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - speculating is too much fun</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - just catching up with other updates<br> &nbsp; &nbsp; &nbsp; &nbsp; - continuing on with this path<br> &nbsp; &nbsp; &nbsp; &nbsp; - one nice thing from the past week is the lexical stuff implementation<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's a big plus<br> &nbsp; &nbsp; &nbsp; &nbsp; - it opens another door for me to continue pushing forward</p><p>Damian:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I've been busy<br> &nbsp; &nbsp; &nbsp; &nbsp; - had the most appalling jetlag after I returned to Australia<br> &nbsp; &nbsp; &nbsp; &nbsp; - this week I'm away teaching in Melbourne<br> &nbsp; &nbsp; &nbsp; &nbsp; - next week too<br> &nbsp; &nbsp; &nbsp; &nbsp; - earning a living gets in the way of *everything*<br> &nbsp; &nbsp; &nbsp; &nbsp; - I have a whole backlog of postings to read and think about<br> &nbsp; &nbsp; &nbsp; &nbsp; - especially from Larry<br> &nbsp; &nbsp; &nbsp; &nbsp; - life stacks up while I'm traveling</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I poked at Parrot::Test a little bit<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm stuck thinking about how to change STDOUT/STDERR</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - someone sent mail to TPF<br> &nbsp; &nbsp; &nbsp; &nbsp; - an editor of the "For Dummies" books wants a date on Perl 6<br> &nbsp; &nbsp; &nbsp; &nbsp; - Andy Lester asked me for completion or milestone dates<br> &nbsp; &nbsp; &nbsp; &nbsp; - I've tended to stonewall on this<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're getting it cheap<br> &nbsp; &nbsp; &nbsp; &nbsp; - we want it good<br> &nbsp; &nbsp; &nbsp; &nbsp; - sticking dates on things won't do anyone any good<br> &nbsp; &nbsp; &nbsp; &nbsp; - what do you think?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's what I've always said<br> &nbsp; &nbsp; &nbsp; &nbsp; - we explicitly do not have scheduled dates<br> &nbsp; &nbsp; &nbsp; &nbsp; - the editor in this case wanted to know if there'd be a release this year<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; or next</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's sort of a "maybe"</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - not *this* year</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I told her there may be a beta at the end of next year<br> &nbsp; &nbsp; &nbsp; &nbsp; - she wanted to know if she should publish a book on it now<br> &nbsp; &nbsp; &nbsp; &nbsp; - my answer is no</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is there any way that fixing dates to anything might help you all out?</p><p>*not really*</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I work on the internal date of "as soon as possible"</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it seems that putting pressure on people in OSS projects tends to make<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; them lose interest</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I agree, but there are a few notable exceptions</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - actually, when I have due dates for school, I work on Pugs!</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - shave a yak, write Perl 6</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is anyone blocking?<br> &nbsp; &nbsp; &nbsp; &nbsp; - no answer makes my life better<br> &nbsp; &nbsp; &nbsp; &nbsp; - okay, questions</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Patrick, Autrijus and I were talking about porting PGE to Perl 6<br> &nbsp; &nbsp; &nbsp; &nbsp; - not for the fast side, but for the working side<br> &nbsp; &nbsp; &nbsp; &nbsp; - supporting you get PGE stable, would you be interested in helping?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - sure<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's stable now</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I thought so</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you want a Perl 6 implementation?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - alternate runcores could use it then<br> &nbsp; &nbsp; &nbsp; &nbsp; - even though it'd be slow</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - the biggest issue is being able to parse expressions into a match tree<br> &nbsp; &nbsp; &nbsp; &nbsp; - I did the first version with a rec-descent parser<br> &nbsp; &nbsp; &nbsp; &nbsp; - now it uses the precedence table which is much nicer<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'd have to look and see what it would take<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't want to get sidetracked<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I can certainly help if you have questions</p> luqui 2005-11-16T23:41:06+00:00 perl6 Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27534?from=rss <p> Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - lots more stuff with PGE<br> &nbsp; &nbsp; &nbsp; &nbsp; - sent out a message on Friday<br> &nbsp; &nbsp; &nbsp; &nbsp; - now support for commit operator, Unicode characters (as far as Parrot<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; can), hex, octal, newline, conjunctions, subrules with arguments,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; documented public interface<br> &nbsp; &nbsp; &nbsp; &nbsp; - it helps that particle has created so many tests<br> &nbsp; &nbsp; &nbsp; &nbsp; - so have the Tcl guys<br> &nbsp; &nbsp; &nbsp; &nbsp; - beyond that, just catching up with Chip's draft design documents<br> &nbsp; &nbsp; &nbsp; &nbsp; - going to do parser things next</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - working on the tree grammar stuff<br> &nbsp; &nbsp; &nbsp; &nbsp; - have it checked into my local mirror<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't merged it back into mainline yet<br> &nbsp; &nbsp; &nbsp; &nbsp; - Parrot has some extraneous requirements on new files<br> &nbsp; &nbsp; &nbsp; &nbsp; - converting some of my little test scripts to test files<br> &nbsp; &nbsp; &nbsp; &nbsp; - I couldn't run tests until I added libraries into Parrot repository<br> &nbsp; &nbsp; &nbsp; &nbsp; - Patrick, what's your advice on where to put the test files?<br> &nbsp; &nbsp; &nbsp; &nbsp; - PGE keeps the test files in the Parrot hierarchy<br> &nbsp; &nbsp; &nbsp; &nbsp; - for the language, I want the tests in the languages/ directory</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - PGE's tests went in the Parrot thing because of Dan's advice<br> &nbsp; &nbsp; &nbsp; &nbsp; - PGE is a part of Parrot<br> &nbsp; &nbsp; &nbsp; &nbsp; - I separated them out as p6rules tests<br> &nbsp; &nbsp; &nbsp; &nbsp; - there are several different syntaxes to do pattern matching<br> &nbsp; &nbsp; &nbsp; &nbsp; - Perl 5 rules, for example<br> &nbsp; &nbsp; &nbsp; &nbsp; - in this case, if we consider TGE as a part of Parrot, then it goes in<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the Parrot repository<br> &nbsp; &nbsp; &nbsp; &nbsp; - or sensibly a subdirectory in compilers/ subdirectory</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll do that for now<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's not a big deal to move them later</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - some overhead with work and family<br> &nbsp; &nbsp; &nbsp; &nbsp; - otherwise hanging out on p6l and p6c<br> &nbsp; &nbsp; &nbsp; &nbsp; - thinking about design issues for roles and things<br> &nbsp; &nbsp; &nbsp; &nbsp; - thinking about some of Patrick's regexp issues too<br> &nbsp; &nbsp; &nbsp; &nbsp; - actually writing a few Perl 6 programs to see if it feels right<br> &nbsp; &nbsp; &nbsp; &nbsp; - running into interesting Pugs bugs there<br> &nbsp; &nbsp; &nbsp; &nbsp; - also playing with attribute grammar stuff and thinking about tree<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; transformation syntax</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - did Autrijus send out the doc that he and Liz have started to put<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; together about concurrency?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I didn't see it</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I encouraged them to show it to people who've done stuff in Perl 5<br> &nbsp; &nbsp; &nbsp; &nbsp; - then make it public<br> &nbsp; &nbsp; &nbsp; &nbsp; - how's the response to licensing stuff been, Allison?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - just a handful of responses<br> &nbsp; &nbsp; &nbsp; &nbsp; - most questions were from the Perl 5 cabal about the amount of time<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; required to turn in their agreements<br> &nbsp; &nbsp; &nbsp; &nbsp; - they wanted more than a week<br> &nbsp; &nbsp; &nbsp; &nbsp; - it'll be more like six months</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it should last through at least a conference season for in person<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; haranguing</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I thought it looked clear and well-defined<br> &nbsp; &nbsp; &nbsp; &nbsp; - I wish other open source licenses were as clear as this one</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - the only one that blew me away was Microsoft's clear and simple group of<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; licenses</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I've been trying to recompile Pugs<br> &nbsp; &nbsp; &nbsp; &nbsp; - I get a weird message from GHC about unrecognized "-i" flags<br> &nbsp; &nbsp; &nbsp; &nbsp; - GHC 6.4.1<br> &nbsp; &nbsp; &nbsp; &nbsp; - one of these years I'll have to start submitting some tests myself</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - have you been submitting bug reports?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I mentioned one on the list<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't know what my commit procedure would be<br> &nbsp; &nbsp; &nbsp; &nbsp; - I haven't taken anyone up on a commit bit</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can make sure that you get relevant documentation<br> &nbsp; &nbsp; &nbsp; &nbsp; - that'll make the Pugs crowd very happy</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm still eager for S05 to show up</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Damian had taken that for comments?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; - yes<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm getting enough questions from people that it'd be nice to have a<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; document point to</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is there any reason not to put a big warning on top of the last draft<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; and check it in?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I have no problem with that<br> &nbsp; &nbsp; &nbsp; &nbsp; - the only thing that may change is the whitespace flags<br> &nbsp; &nbsp; &nbsp; &nbsp; - we can put a notice around that<br> &nbsp; &nbsp; &nbsp; &nbsp; - other than that, it looked good</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - anything new is good</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Damian has the latest draft</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - what's the status of the S29 draft?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - there's one in the Pugs repository<br> &nbsp; &nbsp; &nbsp; &nbsp; - I could review it and pass it around</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - at some point we should do it</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll ask the Pugs folks about it<br> &nbsp; &nbsp; &nbsp; &nbsp; - we can look at it</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - they have a couple of Synopses there waiting for approval<br> &nbsp; &nbsp; &nbsp; &nbsp; - Autrijus, Jarkko, and Jos have started an updated CPAN synopsis</p> luqui 2005-11-10T20:21:19+00:00 perl6 Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27425?from=rss <p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - almost finished with the tree transformation thing that takes a grammar<br> &nbsp; &nbsp; &nbsp; &nbsp; - last remaining piece is tricky<br> &nbsp; &nbsp; &nbsp; &nbsp; - if you use compreg and compile a subroutine on the fly from a string of<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; PIR text, can you have parameters in that?<br> &nbsp; &nbsp; &nbsp; &nbsp; - can you accept subroutine parameters?<br> &nbsp; &nbsp; &nbsp; &nbsp; - do you have to declare it as a named subroutine?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you have to compile it as a named subroutine<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can make it anonymous<br> &nbsp; &nbsp; &nbsp; &nbsp; - give it a name, but put<nobr> <wbr></nobr>:anon pragma after it</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's exactly what I need</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you get back a PMC that you can call like any other subroutine in a PMC</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll have a version of the engine that uses grammars by the end of this<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; call<br> &nbsp; &nbsp; &nbsp; &nbsp; - parses the tree grammar file using PGE<br> &nbsp; &nbsp; &nbsp; &nbsp; - does a tree transformation on the match result<br> &nbsp; &nbsp; &nbsp; &nbsp; - then loops through the tree (an array of rules, where each rule is a<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; hash)<br> &nbsp; &nbsp; &nbsp; &nbsp; - compiles rules for an attribute grammar from that result<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can compile from a tree grammar file to a working tree grammar<br> &nbsp; &nbsp; &nbsp; &nbsp; - you use a tree grammar to use this</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - an abstract syntax?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - your attribute grammar<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can create that from a syntax file<br> &nbsp; &nbsp; &nbsp; &nbsp; - I do that using attribute grammars</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - for me, it ended up being less readable than doing it by hand<br> &nbsp; &nbsp; &nbsp; &nbsp; - but it's fun to bootstrap</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it was my way of testing if I can use an attribute grammar<br> &nbsp; &nbsp; &nbsp; &nbsp; - before I put it into the repository, I want to make sure that I can<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; parse the output from a PGE match and transform it<br> &nbsp; &nbsp; &nbsp; &nbsp; - this proves that that is possible<br> &nbsp; &nbsp; &nbsp; &nbsp; - also Roberta and I finished our final draft of the Artistic Licence 2.0<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; and the contributor agreement<br> &nbsp; &nbsp; &nbsp; &nbsp; - the next step is to solicit reviews from a few interested parties,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; including the patent lawyer<br> &nbsp; &nbsp; &nbsp; &nbsp; - then we'll do a general public review</p><p>Nick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - will Perl 5 come under this agreement as well?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we took that into account for the contributor agreement</p><p>Nick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - can you have the Perl 5 cabal review it too?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - PGE has grown by leaps and bounds<br> &nbsp; &nbsp; &nbsp; &nbsp; - converted it to use a shift-reduce parser internally<br> &nbsp; &nbsp; &nbsp; &nbsp; - everyone else can use that parser<br> &nbsp; &nbsp; &nbsp; &nbsp; - probably 25% shorter in parsing code, much faster<br> &nbsp; &nbsp; &nbsp; &nbsp; - also added support for custom whitespace rules<br> &nbsp; &nbsp; &nbsp; &nbsp; - create a grammar with its own rule<br> &nbsp; &nbsp; &nbsp; &nbsp; - now does closures; can embed them in a rule<br> &nbsp; &nbsp; &nbsp; &nbsp; - can specify what language it'll send to which Parrot compiler</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - can you give it a lexical pad to start with?<br> &nbsp; &nbsp; &nbsp; &nbsp; - does Parrot already do that?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't done anything with that yet<br> &nbsp; &nbsp; &nbsp; &nbsp; - shouldn't be hard<br> &nbsp; &nbsp; &nbsp; &nbsp; - we can do whatever we want<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm still waiting for the dust to settle on the design</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - suppose I wrote a lexer for a LALR(1) grammar?<br> &nbsp; &nbsp; &nbsp; &nbsp; - can I have PGE understand that?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - as long as it understands match objects<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can control how it handles tokens<br> &nbsp; &nbsp; &nbsp; &nbsp; - "give me a match object"<br> &nbsp; &nbsp; &nbsp; &nbsp; - "call this subroutine which tells me how much to consume"<br> &nbsp; &nbsp; &nbsp; &nbsp; - the subroutine can be a rule<br> &nbsp; &nbsp; &nbsp; &nbsp; - go from recursive-descent to shift-reduce or vice versa at any point<br> &nbsp; &nbsp; &nbsp; &nbsp; - we don't have to worry about backtracking over Perl comments, for<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; example<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're atomic<br> &nbsp; &nbsp; &nbsp; &nbsp; - pretty straightforward</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - can you commit yet?<br> &nbsp; &nbsp; &nbsp; &nbsp; - will that allow us to clean up memory that we don't need?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - not yet<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I know how to do it<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can take any match object and call the same rule<br> &nbsp; &nbsp; &nbsp; &nbsp; - it gives you a match object that starts there<br> &nbsp; &nbsp; &nbsp; &nbsp; - drop the old object and the GC will clean it up<br> &nbsp; &nbsp; &nbsp; &nbsp; - continue from where that match started<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can build that trivially in about 15 minutes now<br> &nbsp; &nbsp; &nbsp; &nbsp; - I did lookaheads<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll do lookbehinds in the near future, with a naive implementation<br> &nbsp; &nbsp; &nbsp; &nbsp; - particle on IRC has committed around 200 tests for PGE<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll clear off a lot of the TODOs there to reward him for his work there<br> &nbsp; &nbsp; &nbsp; &nbsp; - my next plan is to start parsing Perl 6 expressions<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll go as far as possible<br> &nbsp; &nbsp; &nbsp; &nbsp; - should be able to go quite a ways<br> &nbsp; &nbsp; &nbsp; &nbsp; - already an expressions parser in the examples directory<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can get back a parse tree with precedence taken into account<br> &nbsp; &nbsp; &nbsp; &nbsp; - now that that's a rule, I'll start working on statements<br> &nbsp; &nbsp; &nbsp; &nbsp; - we'll see where it goes from there<br> &nbsp; &nbsp; &nbsp; &nbsp; - probably can produce fairly complete parse trees for Perl 6 programs in<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; two weeks<br> &nbsp; &nbsp; &nbsp; &nbsp; - may not have all of the esoterics in there, but most will be available<br> &nbsp; &nbsp; &nbsp; &nbsp; - one question<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can fairly rapidly build an interpreter based on the match tree<br> &nbsp; &nbsp; &nbsp; &nbsp; - is that a direction to bother going down?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it would be useful just in a sense of having bits and pieces being<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; usable right away</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's the way I want to go<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll start building an interpreter<br> &nbsp; &nbsp; &nbsp; &nbsp; - it may be slow<br> &nbsp; &nbsp; &nbsp; &nbsp; - my intermediate goal is to get the language interpreter far enough along<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; that it can run the Pugs test harness</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's what Pugs did for a while<br> &nbsp; &nbsp; &nbsp; &nbsp; - that sucks<br> &nbsp; &nbsp; &nbsp; &nbsp; - all of your special cases get into the big, bloated runtime</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we're working on the syntax tree at the same time<br> &nbsp; &nbsp; &nbsp; &nbsp; - we will do that<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's just nice to have something running</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I think Luke means "don't go too far with it"</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you don't want to go too far in that direction<br> &nbsp; &nbsp; &nbsp; &nbsp; - people could spend their time adding features to a bloated interpreter<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; rather than building a small, scalable one<br> &nbsp; &nbsp; &nbsp; &nbsp; - where do you stop?<br> &nbsp; &nbsp; &nbsp; &nbsp; - where do you throw it out and start with PIL?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - when I push the tree transformations two steps further and Patrick can<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; use that instead of the interpreter</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - PIL and the interpreter aren't entirely in conflict<br> &nbsp; &nbsp; &nbsp; &nbsp; - my goal is the compiler<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't want to target PIL directly<br> &nbsp; &nbsp; &nbsp; &nbsp; - I need something to evaluate my syntax trees relatively interesting</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you don't want to go too far, like Pugs in throwing so much away</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - the best way to check the grammar and PGE is to have something that<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; actually works while he's at it</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can help out, Luke<br> &nbsp; &nbsp; &nbsp; &nbsp; - when you think it's going too far, say so</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it goes too far with other contributors, not you</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we don't really have other contributors now</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we could get some very quickly</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - "thanks for your help, but we're throwing it away now"</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we'll just tell them up front<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll create a new languages/ directory so it's clear it's not the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; official Perl 6 system<br> &nbsp; &nbsp; &nbsp; &nbsp; - we will watch for that very carefully<br> &nbsp; &nbsp; &nbsp; &nbsp; - if this system doesn't have a release schedule but the Perl 6 compiler<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; does, it'll be clearer about our priorities</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - okay<br> &nbsp; &nbsp; &nbsp; &nbsp; - one more thing though<br> &nbsp; &nbsp; &nbsp; &nbsp; - Perl 6 is a complex language<br> &nbsp; &nbsp; &nbsp; &nbsp; - I think that interpreter will be bigger than you expect it to be</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't expect to write a complete interpreter<br> &nbsp; &nbsp; &nbsp; &nbsp; - I expect to write enough to get me to a compiler in a comfortable<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; environment<br> &nbsp; &nbsp; &nbsp; &nbsp; - after writing PGE as a compiler, I know that's how I want to go</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - describing it as a development aid and experiment might help</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm planning to send out an e-mail later tonight if I can stop coding<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; long enough to document things</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm happy that everyone else is making good progress<br> &nbsp; &nbsp; &nbsp; &nbsp; - I didn't this week mostly because of school<br> &nbsp; &nbsp; &nbsp; &nbsp; - I was going to write a couple of things, but they're still on my queue<br> &nbsp; &nbsp; &nbsp; &nbsp; - also going to port Language::AttributeGrammar to Perl 6</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - are you blocking on anything else?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - only learning my way around the new Parrot</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - working on the book<br> &nbsp; &nbsp; &nbsp; &nbsp; - writing a proof of concept in Perl 5 that I can port to PIR pretty<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; easily<br> &nbsp; &nbsp; &nbsp; &nbsp; - requires the OpenGL bindings</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - are those maintained?</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I have a proof of concept on my hard drive<br> &nbsp; &nbsp; &nbsp; &nbsp; - I think it'll be pretty easy<br> &nbsp; &nbsp; &nbsp; &nbsp; - don't need to wrap them in a nice interface as I did SDL<br> &nbsp; &nbsp; &nbsp; &nbsp; - should be a quick port</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Autrijus and Liz have been enumerating their desires for S17 and<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; concurrency in Perl 6<br> &nbsp; &nbsp; &nbsp; &nbsp; - once they feel like they have a draft they like, should they send it to<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the cabal and ask where to go from there?<br> &nbsp; &nbsp; &nbsp; &nbsp; - maybe the answer will be "no, this isn't what we want!"</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - yes, that is the right way to go</p><p>Nick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I remember discussions from Perl 5 several years ago<br> &nbsp; &nbsp; &nbsp; &nbsp; - someone needs to go over the proposal and see if there are portability<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; problems and guarantees<br> &nbsp; &nbsp; &nbsp; &nbsp; - they're talking about STM for this<br> &nbsp; &nbsp; &nbsp; &nbsp; - seems like a disconnect between what Ponie wants<br> &nbsp; &nbsp; &nbsp; &nbsp; - the fact that everything in Ponie goes through a vtable means that<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; there's no speed hit for going through non-shared code<br> &nbsp; &nbsp; &nbsp; &nbsp; - there'll probably need to be the concept of closing in Parrot<br> &nbsp; &nbsp; &nbsp; &nbsp; - as soon as you start a thread, you'll have to replace the parent vtables<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; with shared ones<br> &nbsp; &nbsp; &nbsp; &nbsp; - this probably needs Chip<br> &nbsp; &nbsp; &nbsp; &nbsp; - don't know how much Chip has thought about it yet</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it sounds like the right thing to do is to pass the draft around to<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; everyone who's thought about threading in Perl 5</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - next week, the call will be at the DST time<br> &nbsp; &nbsp; &nbsp; &nbsp; - 10 pm UK<br> &nbsp; &nbsp; &nbsp; &nbsp; - GMT now</p> luqui 2005-11-03T01:40:02+00:00 perl6 Principles of Perl 6 http://use.perl.org/~luqui/journal/27362?from=rss <p>Ever since the <a href="http://groups.google.com/group/perl.perl6.language/tree/browse_frm/thread/c189bc6a1ff45b63/7cf995869ba97985?rnum=21&amp;q=MML+Dispatch&amp;_done=%2Fgroup%2Fperl.perl6.language%2Fbrowse_frm%2Fthread%2Fc189bc6a1ff45b63%2F0b0c38d6bb2a7db9%3Ftvc%3D1%26q%3DMML+Dispatch%26#doc_115e6ad8a95aa3df">Great Multimethod Debate</a>, I've been introducing various principles into my arguments. These are my "axioms of semantics", and my hope is to take the hard questions and answer them purely in terms of reasoning from these basic principles. This is the kind of reasoning that makes me love mathematics: to reduce all hard decisions into obvious truths by using proper definitions of terms.</p><p>So, anyway, here's the list I have so far. (The other well-known Perl principles like Least Surprise, Waterbed, and Endweight are omitted. Maybe I'll do a writeup about those soon.)</p><ul> <li><b>The principle of free derivation (or composition):</b> If you derive a class B from a class A, and B has an empty body (defines nothing new), then objects of class B should behave exactly like objects of class A[1]. Likewise for roles. This was the first principle I ever introduced, and I used it to argue against manhattan distance dispatch.</li><li> <b>The principle of partial definition:</b> Defining a new type or instance can only break a previously well-typed program by making it ambiguous. Another way of saying that is: there may be types and instances already hidden in the algebra of your program, and making those instances explicit should not break anything.</li><li> <b>The principle of type:set isomorphism:</b> There exists a type that describes every possible set of objects in your program, even if it not named, or even possible to name.</li></ul><p>The motivations for the three were: manhattan MMD, the junctive one() type, and manhattan MMD again, respectively. Also note that the first principle precludes the existence of submethods. Now it's clear why I keep asking why we need submethods. It's not entirely clear why I continue not to get any answers[2].</p><p>[1] Up to metainformation, such as asking which class the object is in, of course.</p><p>[2] To be fair, Damian responded to my query, but he didn't answer my question. He gave more an example of how submethods are used, rather than why they are used.</p> luqui 2005-10-29T02:36:59+00:00 journal Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27323?from=rss <p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - trying to figure out types<br> &nbsp; &nbsp; &nbsp; &nbsp; - and everything else<br> &nbsp; &nbsp; &nbsp; &nbsp; - rewriting the world<br> &nbsp; &nbsp; &nbsp; &nbsp; - put out new versions of S02 and S06<br> &nbsp; &nbsp; &nbsp; &nbsp; - already have things I want to change</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - good thing committing only takes a couple of seconds</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - also I was in Hungary<br> &nbsp; &nbsp; &nbsp; &nbsp; - it was thirsty<br> &nbsp; &nbsp; &nbsp; &nbsp; - they apparently don't believe in caffeine there<br> &nbsp; &nbsp; &nbsp; &nbsp; - I spent a goodly part of that with a headache<br> &nbsp; &nbsp; &nbsp; &nbsp; - the conference was pretty okay<br> &nbsp; &nbsp; &nbsp; &nbsp; - getting ready to give a talk to HP on Thursday</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Perl 6-ish?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - variant of my 9.3 State of the Onion talk that I gave at EuroOSCON<br> &nbsp; &nbsp; &nbsp; &nbsp; - it'll be by teleconference<br> &nbsp; &nbsp; &nbsp; &nbsp; - my slides will be a Java app running in everyone's browser<br> &nbsp; &nbsp; &nbsp; &nbsp; - part of the reason I did EuroOSCON with just words is that I wanted it<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; to still work in case everything blew up</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm pleased using the Takahashi method Autrijus found<br> &nbsp; &nbsp; &nbsp; &nbsp; - it just works<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can edit them in a text editor</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - the named arguments are now marked with colon instead of plus</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - makes many people happy</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - probably the type sigil is up arrow, rather than a cent sign<br> &nbsp; &nbsp; &nbsp; &nbsp; - as in caret<br> &nbsp; &nbsp; &nbsp; &nbsp; - we're trying to iron out all of our terminology for what's a class and<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; what's an abstract class that isn't really a class<br> &nbsp; &nbsp; &nbsp; &nbsp; - probably relates to Luke's "a class is not anything"<br> &nbsp; &nbsp; &nbsp; &nbsp; - think we're making good progress on that<br> &nbsp; &nbsp; &nbsp; &nbsp; - looks like I'll be home for the next couple of months<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll probably accept a position at the place where I'm currently<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; consulting<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll still be spending the majority of my time on Perl 6</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - checked in my shift/reduce parser last night<br> &nbsp; &nbsp; &nbsp; &nbsp; - busy cleaning it up<br> &nbsp; &nbsp; &nbsp; &nbsp; - it works pretty nicely<br> &nbsp; &nbsp; &nbsp; &nbsp; - getting ready to parse all sorts of Perl 6 expressions<br> &nbsp; &nbsp; &nbsp; &nbsp; - then I found a segfault (which I reported earlier)<br> &nbsp; &nbsp; &nbsp; &nbsp; - I think I'll be able to parse out most Perl 6 expressions now<br> &nbsp; &nbsp; &nbsp; &nbsp; - including all of the weird whitespace things</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - can that all be in one spot, like we talked about?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - yes<br> &nbsp; &nbsp; &nbsp; &nbsp; - register a token and specify if it's whitespace okay or not<br> &nbsp; &nbsp; &nbsp; &nbsp; - if you need to do fancy things from the bottom-up parser, you can<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; always call a rule<br> &nbsp; &nbsp; &nbsp; &nbsp; - it tells the shift/reduce parser "this is what I have, now continue on"</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - okay<br> &nbsp; &nbsp; &nbsp; &nbsp; - does the rule vs. token distinction we discussed make sense in this<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; context?</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - for general in Perl 6 rules?<br> &nbsp; &nbsp; &nbsp; &nbsp; - not at the moment<br> &nbsp; &nbsp; &nbsp; &nbsp; - I like the way<nobr> <wbr></nobr>:w works in general<br> &nbsp; &nbsp; &nbsp; &nbsp; - pretty nice way of doing it<br> &nbsp; &nbsp; &nbsp; &nbsp; -<nobr> <wbr></nobr>:r<nobr> <wbr></nobr>:t that Damian proposed didn't do anything for me for these things<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; that I needed to parse</p><p>(On the cabal list we have been discussing separating the concepts of rule and token for whitespace dwimmery purposes. -L)</p><p> &nbsp; &nbsp; &nbsp; &nbsp; - now I'm working on parsing out the ternary operator<br> &nbsp; &nbsp; &nbsp; &nbsp; - think I have that working in the past five minutes<br> &nbsp; &nbsp; &nbsp; &nbsp; - next steps are to test and check in some examples<br> &nbsp; &nbsp; &nbsp; &nbsp; - Perl 6 expressions, Perl 6 rules, general expressions<br> &nbsp; &nbsp; &nbsp; &nbsp; - parsing gives you a nice match tree with the nodes in the right place<br> &nbsp; &nbsp; &nbsp; &nbsp; - useful starting place for figuring out the tree transformations we need<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; to do<br> &nbsp; &nbsp; &nbsp; &nbsp; - especially true for the grammar engine itself<br> &nbsp; &nbsp; &nbsp; &nbsp; - once I parse it out to the tree, we want a bunch of transformations and<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; optimizations<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll write PIR code that does that for now<br> &nbsp; &nbsp; &nbsp; &nbsp; - we can catalog those we need and how we might want our TTL to look</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - and not box ourselves in so we can't use "use" statements</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - also promised to update the milestones document for PGE today or tonight<br> &nbsp; &nbsp; &nbsp; &nbsp; - just haven't done it yet by being too busy writing code</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - sent a patch to p6i to update the opcode mismatch error message</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - not sure that's the right approach<br> &nbsp; &nbsp; &nbsp; &nbsp; - I like your second suggestion better<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can look at it if you like</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's why I sent in the patch, not checking it in directly<br> &nbsp; &nbsp; &nbsp; &nbsp; - this made my life easier though</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - are these capturable by something running atop Parrot?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's an interpreter exception<br> &nbsp; &nbsp; &nbsp; &nbsp; - working today on finishing the PIR attribute grammar implementation<br> &nbsp; &nbsp; &nbsp; &nbsp; - coming along nicely<br> &nbsp; &nbsp; &nbsp; &nbsp; - because of the closures issue, I've made it much more heavily OO<br> &nbsp; &nbsp; &nbsp; &nbsp; - instead of relying on closures to capture a certain value, I'm passing<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; around relevant objects<br> &nbsp; &nbsp; &nbsp; &nbsp; - AttributeGrammar::Rule object, for example<br> &nbsp; &nbsp; &nbsp; &nbsp; - pass that down to where it needs the information</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - might be a better approach, given Parrot's architecture</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - seems to be working better in PIR</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - which version are you interpreting?<br> &nbsp; &nbsp; &nbsp; &nbsp; - I released a new one this week</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - started with the old one<br> &nbsp; &nbsp; &nbsp; &nbsp; - figure I'll update it later<br> &nbsp; &nbsp; &nbsp; &nbsp; - the old one was simpler in the model<br> &nbsp; &nbsp; &nbsp; &nbsp; - which parts did you change?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - completely rewrote it<br> &nbsp; &nbsp; &nbsp; &nbsp; - most of the algorithm's semantics rely on the simple semantics of the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; thunk<br> &nbsp; &nbsp; &nbsp; &nbsp; - used to traverse the tree, find out the attributes, made thunks if I<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; need them<br> &nbsp; &nbsp; &nbsp; &nbsp; - new version makes thunks for all the attributes it may need eventually,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; starts with the first one, then goes on</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - was this to help memory usage?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - yes<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's hard to tell when Perl cleans up memory<br> &nbsp; &nbsp; &nbsp; &nbsp; - you can't use this technique verbatim in Parrot because of the<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; difference in how they handle pads<br> &nbsp; &nbsp; &nbsp; &nbsp; - write destructor code that tells you when things are cleaned up</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it would be nice if destructors worked<br> &nbsp; &nbsp; &nbsp; &nbsp; - last time I tried, they didn't<br> &nbsp; &nbsp; &nbsp; &nbsp; - we need some sort of finalization and destruction<br> &nbsp; &nbsp; &nbsp; &nbsp; - I want to release non-memory resources at a reliable, known point<br> &nbsp; &nbsp; &nbsp; &nbsp; - I don't really care when Parrot GCs the dead object</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - block exit, right?</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's fine with me</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - you want to know that you have reliable finalization at some point, not<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; necessarily at the same time as destruction<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll check this into my personal repository tonight</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll try to come up with an idea for a more public repository for this<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sort of thing</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - mostly school<br> &nbsp; &nbsp; &nbsp; &nbsp; - lots of tests recently<br> &nbsp; &nbsp; &nbsp; &nbsp; - rewrote the attribute grammar module<br> &nbsp; &nbsp; &nbsp; &nbsp; - nice and memory-efficient, at least I think<br> &nbsp; &nbsp; &nbsp; &nbsp; - algorithmically it has a better bound<br> &nbsp; &nbsp; &nbsp; &nbsp; - also started the Perl 6 port of Language::AttributeGrammar<br> &nbsp; &nbsp; &nbsp; &nbsp; - still thinking about how to do that given Perl 6's handling of pads<br> &nbsp; &nbsp; &nbsp; &nbsp; - much different from Perl 5<br> &nbsp; &nbsp; &nbsp; &nbsp; - think that's about it<br> &nbsp; &nbsp; &nbsp; &nbsp; - attribute grammarsr are a great base for the tree transformation<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; language we're thinking about</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I was in Stockholm for the Nordic Perl Workshop<br> &nbsp; &nbsp; &nbsp; &nbsp; - presented 205 slides in 23 minutes<br> &nbsp; &nbsp; &nbsp; &nbsp; - missed the implementation meeting, but it happened<br> &nbsp; &nbsp; &nbsp; &nbsp; - need to send out mail about the upcoming time change<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's it from my side</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Allison, are you waiting on anything from PGE on what you're doing?</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm doing the part that doesn't depend on PGE right now<br> &nbsp; &nbsp; &nbsp; &nbsp; - after I finish the port, then I'll start trying out transforming PGE<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; trees</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll send you some PGE trees then</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I heard that Larry and Autrijus did some work on tuples<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'd like to see a summary of that</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - read S02 and S06<br> &nbsp; &nbsp; &nbsp; &nbsp; - basically the tuple constructor we stole with \()<br> &nbsp; &nbsp; &nbsp; &nbsp; - we didn't think that we should throw regular parens at that<br> &nbsp; &nbsp; &nbsp; &nbsp; - the signature constructor is different from that<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's still<nobr> <wbr></nobr>:()<br> &nbsp; &nbsp; &nbsp; &nbsp; - a tuple is parsed rvalues<br> &nbsp; &nbsp; &nbsp; &nbsp; - a signature parses differently<br> &nbsp; &nbsp; &nbsp; &nbsp; - that's how it currently sits<br> &nbsp; &nbsp; &nbsp; &nbsp; - also there's no special casing about having a comma on the end<br> &nbsp; &nbsp; &nbsp; &nbsp; - the fact that you are passing it to a function makes it a tuple<br> &nbsp; &nbsp; &nbsp; &nbsp; - the recognizer for a tuple in a signature is also a backwhacked variable<br> &nbsp; &nbsp; &nbsp; &nbsp; - Autrijus talked about that part of it<br> &nbsp; &nbsp; &nbsp; &nbsp; - the slurpy scalar will just slurp one argument at the top level<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'm sure you'll find other stuff out there, some of which is probably<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bogus</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - not much conferency coming up</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - MIT's Little Languages workshop may be the first week of December<br> &nbsp; &nbsp; &nbsp; &nbsp; - at least, I hope it is</p> luqui 2005-10-26T22:41:11+00:00 perl6 Yesterday's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27260?from=rss <p>Oh yeah, there was no meeting yesterday because of Euro-OSCON. See you next week.</p> luqui 2005-10-20T22:26:38+00:00 perl6 Today's Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27139?from=rss <p> Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - made it back safely from the cruise<br> &nbsp; &nbsp; &nbsp; &nbsp; - madly working<br> &nbsp; &nbsp; &nbsp; &nbsp; - hanging out on the lists a little bit<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't had enough time to think through the things I want to think<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; through</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - started the rewrite of attribute grammars module<br> &nbsp; &nbsp; &nbsp; &nbsp; - won't eat up memory as much<br> &nbsp; &nbsp; &nbsp; &nbsp; - spent hours trying to debug a nasty bug</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - a Perl 5 bug?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - no, in my code somewhere<br> &nbsp; &nbsp; &nbsp; &nbsp; - also talking with Stevan about the metamodel<br> &nbsp; &nbsp; &nbsp; &nbsp; - trying to unify that in my head with theories<br> &nbsp; &nbsp; &nbsp; &nbsp; - not working very well<br> &nbsp; &nbsp; &nbsp; &nbsp; - but I realize that the theory proposes a type system<br> &nbsp; &nbsp; &nbsp; &nbsp; - the metamodel proposes an object system</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - and a reflection system</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Autrijus says he'll talk to Larry in person at EuroOSCON<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll follow along on IRC to catch type annotation stuff</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - working on PGE some more<br> &nbsp; &nbsp; &nbsp; &nbsp; - tracked down and fixed a problem with Parrot's coroutine handling<br> &nbsp; &nbsp; &nbsp; &nbsp; - rewriting PGE captures code so that match objects are true to what they<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ought to be<br> &nbsp; &nbsp; &nbsp; &nbsp; - clean it up, make it faster, make it more accurate<br> &nbsp; &nbsp; &nbsp; &nbsp; - working on shift/reduce parser component<br> &nbsp; &nbsp; &nbsp; &nbsp; - this first ought to produce Perl 6 rules<br> &nbsp; &nbsp; &nbsp; &nbsp; - the recursive descent part is actually the slowest part of the current<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; process</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - surprise, surprise</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - in the process, I find that match trees look like something I need to do<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tree transforms on<br> &nbsp; &nbsp; &nbsp; &nbsp; - expect to have a real-world example in the next week or so<br> &nbsp; &nbsp; &nbsp; &nbsp; - we could look at using attribute grammars on it soon<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll be publishing the start and the end and the necessary<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; transformations<br> &nbsp; &nbsp; &nbsp; &nbsp; - then we can look at them<br> &nbsp; &nbsp; &nbsp; &nbsp; - looking at a port of Text::Balanced<br> &nbsp; &nbsp; &nbsp; &nbsp; - turned out to be fairly easy to do in Parrot now<br> &nbsp; &nbsp; &nbsp; &nbsp; - also posted several questions on the list</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - haven't had time to go through the whole document yet</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - do the docs need updating to reflect that?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - undoubtedly</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - Damian has drafts of those<br> &nbsp; &nbsp; &nbsp; &nbsp; - I went through them in some detail<br> &nbsp; &nbsp; &nbsp; &nbsp; - his latest drafts looked pretty complete to me<br> &nbsp; &nbsp; &nbsp; &nbsp; - just looking for confirmation on various things<br> &nbsp; &nbsp; &nbsp; &nbsp; - I can pull out the outstanding issues if you need them<br> &nbsp; &nbsp; &nbsp; &nbsp; - Damian has another draft I think<br> &nbsp; &nbsp; &nbsp; &nbsp; - could use an opinion on letting whitespace before a quantifier imply a<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; rule</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - in the absence of a better idea, run with it</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - if we put a quantifier on a subrule<br> &nbsp; &nbsp; &nbsp; &nbsp; - the quantifier doesn't include any whitespace between them<br> &nbsp; &nbsp; &nbsp; &nbsp; - if you put space between the subrule and the quantifier<br> &nbsp; &nbsp; &nbsp; &nbsp; - currently it's meaningless<br> &nbsp; &nbsp; &nbsp; &nbsp; - what if it put a whitespace rule between each instance?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - maybe a good temporary idea<br> &nbsp; &nbsp; &nbsp; &nbsp; - maybe we're approaching the<nobr> <wbr></nobr>:w thing from the wrong direction<br> &nbsp; &nbsp; &nbsp; &nbsp; - all other context-free approaches try it upside-down from us<br> &nbsp; &nbsp; &nbsp; &nbsp; - for quick regexes without many calls to subrules, we're good<br> &nbsp; &nbsp; &nbsp; &nbsp; - for context-free things, a completely different semantic may be much<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; handier</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - we may need both</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - had a question for Patrick about my PIR code<br> &nbsp; &nbsp; &nbsp; &nbsp; - will e-mail him when I remember</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - more chatter in the implementation meeting<br> &nbsp; &nbsp; &nbsp; &nbsp; - Chip's working on the PDDs<br> &nbsp; &nbsp; &nbsp; &nbsp; - Leo and Nick both seem to be waiting on bits of design<br> &nbsp; &nbsp; &nbsp; &nbsp; - maybe need someone to put together questions which various design docs<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; need to say<br> &nbsp; &nbsp; &nbsp; &nbsp; - Chip would find it easier to write them by answering questions rather<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; than working in a vacuum<br> &nbsp; &nbsp; &nbsp; &nbsp; - might need to find some volunteers for them<br> &nbsp; &nbsp; &nbsp; &nbsp; - been posting transcripts and links to the implementation notes on<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; use.perl.org</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - posted a request for comments on annotations to p6l<br> &nbsp; &nbsp; &nbsp; &nbsp; - the people on the "programming left" responded<br> &nbsp; &nbsp; &nbsp; &nbsp; - "I don't want any type errors anywhere"<br> &nbsp; &nbsp; &nbsp; &nbsp; - didn't really generate any interesting thoughts<br> &nbsp; &nbsp; &nbsp; &nbsp; - mostly a mood-generating thought<br> &nbsp; &nbsp; &nbsp; &nbsp; - are there any ideas about the integration between annotated and<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; unannotated code?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - seems like one of those things the user deserves to give a knob<br> &nbsp; &nbsp; &nbsp; &nbsp; - what the default setting is</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - it's not a trivial knob<br> &nbsp; &nbsp; &nbsp; &nbsp; - you're working with a complex system<br> &nbsp; &nbsp; &nbsp; &nbsp; - Autrijus and I talked about this some on IRC<br> &nbsp; &nbsp; &nbsp; &nbsp; - before we figure out the big issues, we have to figure out the little<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; issues</p><p>c:<br> &nbsp; &nbsp; &nbsp; &nbsp; - would it be helpful to come up with examples where the syntax,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; semantics, and behavior might be a problem?</p><p>Luke:<br> &nbsp; &nbsp; &nbsp; &nbsp; - that was what my thread tried to do, but it didn't go there</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - everything gets more complex in the middle ground<br> &nbsp; &nbsp; &nbsp; &nbsp; - we're not going all type-checked<br> &nbsp; &nbsp; &nbsp; &nbsp; - some people never want type checking<br> &nbsp; &nbsp; &nbsp; &nbsp; - most people are probably in the middle<br> &nbsp; &nbsp; &nbsp; &nbsp; - people need more time to think about that</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - is there anything besides free time that are blocking you?</p><p>Larry:<br> &nbsp; &nbsp; &nbsp; &nbsp; - brain cells</p><p>Patrick:<br> &nbsp; &nbsp; &nbsp; &nbsp; - daylight savings time changes are coming<br> &nbsp; &nbsp; &nbsp; &nbsp; - we should figure out the implication<br> &nbsp; &nbsp; &nbsp; &nbsp; - the calls will be earlier</p><p>Allison:<br> &nbsp; &nbsp; &nbsp; &nbsp; - last year we postponed the change until December</p><p>Jesse:<br> &nbsp; &nbsp; &nbsp; &nbsp; - I'll send mail about the time change<br> &nbsp; &nbsp; &nbsp; &nbsp; - we'll figure out something that works</p> luqui 2005-10-13T00:03:43+00:00 perl6 Conflicted http://use.perl.org/~luqui/journal/27116?from=rss <p>I'm feeling conflicted about theory.pod. While I'm very proud of it for being a great object model and giving precise semantics to things we've been handwaving over for ages, it just isn't Perl. It's too formal and static for Perl; you can't talk it into checking something a different way.</p><p>However, it is not possible to add a pure hook system that's reasonable for the everyday user to use. Type inference can't deal with arbitrary code, because it needs to go forwards and backwards and sideways through the annotations to figure things out, whereas arbitrary code can only go forwards. If we had a logic subsystem, we could give them arbitrary code (within that subsystem) because logic programming has the nice property that you can execute a function backwards:</p><blockquote><div><p> <tt>&nbsp; &nbsp;<nobr> <wbr></nobr>:- append(X, Y, [1,2,3,4,5]).</tt></p></div> </blockquote><p>But maybe instead I need a coproposal, one that really gets down and dirty with Perl 6's internals, for the hook system on top of which theory.pod can be built as a module. If that exists (assuming it is even possible), then I wouldn't feel so uneasy about theories not being arbitrarily flexible.</p> luqui 2005-10-11T17:05:48+00:00 journal Perhaps a bit of management insight http://use.perl.org/~luqui/journal/27054?from=rss <p>Now, I've only been a project manager once, so I definitely have no idea what I'm talking about. But two principles occurred to me while I was procrastinating a paper I had to write. They are quite along the same lines as -Ofun, but a little bit more specific:</p><p> &nbsp; &nbsp; &nbsp; &nbsp; * Always make people feel like they're making a difference.<br> &nbsp; &nbsp; &nbsp; &nbsp; * Never make people feel like they're making "the final product".</p><p>And the reasoning is: #1 makes them start, #2 makes them finish. Nobody ever finishes "the final product", because it's never quite designed well enough, or quite as flexible, or quite as orthogonal, etc. as they'd like it to be. And of course, before you start writing "the final product", you have to have it all worked out in your head. These emotional responses are extremely counter-XP, and never end up working, of course. So #2 is basically there to shatter those false emotions and get people into XP mode without overengineering.</p><p>I'd be interested in hearing from some people with management experience on these thoughts.</p> luqui 2005-10-07T07:50:09+00:00 journal Today's Lack of Perl 6 Meeting Notes http://use.perl.org/~luqui/journal/27038?from=rss <p>There was no Perl 6 meeting today, because of the Perl Whirl. See you next week.</p> luqui 2005-10-06T00:53:56+00:00 perl6 Memory-saving lazy attribute grammars http://use.perl.org/~luqui/journal/26991?from=rss <p>Okay, well, my lazy implementation in Language::AttributeGrammar is really memory hungry. Not only is there the O(mn) overhead usually present in lazy implementations, <i>all data is kept around until the end of the computation</i>. This is silly (but it is still a trade-off).</p><p>I have two options for making a reasonable implementation.</p><p>1) Use a proper lazy approach that knows how to clean up after itself.<br>2) Compile the grammar using Kastens's algorithm.</p><p>I'll demonstrate option 1 by showing the Branch visitor in the repmin problem:</p><blockquote><div><p> <tt>sub Branch::visit {<br>&nbsp; &nbsp; my ($self, $globalmin) = @_;<br>&nbsp; &nbsp; my ($left_min, $left_result)&nbsp; &nbsp;=&nbsp; $self-&gt;{left}-&gt;visit(thunk { $globalmin-&gt;call });<br>&nbsp; &nbsp; my ($right_min, $right_result) = $self-&gt;{right}-&gt;visit(thunk { $globalmin-&gt;call });<br>&nbsp; &nbsp; return (thunk { min($left_min-&gt;call, $right_min-&gt;call) },&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# min<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; thunk { Branch-&gt;new($left_result-&gt;call, $right_result-&gt;call) });&nbsp; # result<br>}</tt></p></div> </blockquote><p>Each of the $left_min etc. are thunks. When you -&gt;call a thunk, it runs the closure associated with it and then overwrites the closure with the value that the closure returned. It's the standard lazy evaluation technique.</p><p>Now you say, "$left_min? Why not $left-&gt;{min}? The code would be clearer." (Also importantly -- and this is the trade-off -- you wouldn't have to know the types of the child nodes). Well, it's about memory. If I put all the thunks in a hash, then the values they return will be cleaned up after I run all the thunks (exhausting the pointers to the lexical pad). However, if I put them in lexicals, then the values will be cleaned up incrementally, as soon as the computation doesn't need them anymore.</p><p>For instance, you don't need the local minimum to build the result, so as soon as the local minimum of this branch is returned, there are no more references to $left_min and $right_min and they can be cleaned up. This is more important when you're passing around large data structures, which attribute grammars often do.</p><p>The cool thing about this new lazy formulation (which isn't new at all, UUAG does it), is that it's time <i>and</i> memory complexity is exactly the same as Kastens's algorithm. There is linear overhead in the number of nodes, but that has the same complexity as the attribute values themselves. You just allocate them a little earlier. So all that's left are the details.</p><p>And that brings me to option 2. The details could be important. Kastens's algorithm is less flexible than the lazy algorithm above because it needs to know more about the input. Kastens's algorithm, though, can compile to an abstractionless representation, where pretty much the only operations are "bsr" and "execute attribute body". In Perl, this will make a little difference, but not one noticable (I may benchmark to back up/invalidate this claim). However, if you are compiling to C or a JIT, this could make a really really huge difference. If Perl 6 gets attribute grammar support (s/If/When/, just a question of whether it's shipped or module), then it's probably a good idea to use Kastens's algorithm, because we can then compile to JITted parrot (or even C).</p><p>However, all the lifetime analysis, visitation dependencies, and hard-to-compute bullshit like that in Kastens's algorithm are automatically handled using thunks and garbage collection. That means that a lazy approach is <i>significantly</i> easier to implement. Also, the lazy approach can accept more grammars; that is, grammars that are not "ordered attribute grammars" as in Kastens's paper. But the class of ordered attribute grammars is already quite large, so that's probably not an issue.</p><p>I think I'll go with option 1, mainly because it's easier to implement. Funny how big a factor that can be, and how little people understand how big a factor that is.</p> luqui 2005-10-03T16:32:39+00:00 journal Silly Academia http://use.perl.org/~luqui/journal/26943?from=rss <p>While reading "Ordered Attribute Grammars, Uwe Kastens, 1980", I came across this description of one of the functions he was using in his example:</p><p>include(a,d): "a" is a set of descriptions, "d" is a description; the result is "a U {d}" if a does not contain a description "d'" for the same identifier described by "d", "{a\{d'}} U {d}" otherwise.</p><p>(I used U for union and \ for difference)</p><p>Stare at that for a little while. You can probably figure out what it's saying within a few minutes. But how about:</p><p>include(set,desc): "set" is a set of descriptions, "desc" is a description; if "set" already contains a description with "desc"'s identifier, it returns "set" with that description replaced by "desc". Otherwise it returns "set" with "desc" added.</p><p>If the author weren't so attached to keeping everything set-theoretic, you could say that a is a dictionary from names to descriptions, and make it even easier to read.</p><p>More recent papers have the same kind of purely mathematical language, formulating everything in terms of sets, using single uppercase letters for set names and single lowercase letters for variables. Anybody who programs that way is scolded by the community for producing unreadable and unmaintainable code. Yet academic papers, which have much more respect than programmers, continue to use this cryptic notation. These papers don't deserve respect.</p><p>It's because of this mathematical-notative culture that Haskell uses all the cutting-edge research and the dynamic languages are stuck re-inventing Smalltalk. It's not that the new research is so hard to implement, it's that it's documented incomprehensibly. PhDs in Haskell read papers and write the algorithms they describe just like everybody else, but they're trained in reading this dense academic language.</p><p>And of course, when I eventually do my dissertation, if I don't write this way my dissertation will be rejected and I won't get my degree. I won't think of the problem I solve purely in terms of sets and single-letter variables, I'll think of it in terms of computer science concepts, which have English names. I'll have to convolve my ideas into mathematical academic language, only to have other academics untangle them back into everyday computer science concepts as they read.</p><p>Computer science academics need to retake Freshman writing.</p> luqui 2005-09-30T01:53:31+00:00 journal