Apocalypses and Exegesis...
Hi Apocalypses and Exegesis are not an 'official' specification for Perl6, I mean, they are subject to change. Is there any idea when will we have a freeze on the syntax and features for perl6? Thanks, Alberto
Re: Apocalypses and Exegesis...
The question is simple, and Dan can have the same problem (or him or Larry). I am thinking on a Perl 6 book in portuguese (maybe only a tutorial... but who knows). But that means I must write something which will work :-) Of course to write it will take many time, which can give Larry time to write at least one more Apocalypse :) Cheers, Alberto On Thu, 2003-08-14 at 13:52, Dan Sugalski wrote: On 14 Aug 2003, Alberto Manuel Brandão Simões wrote: Hi Apocalypses and Exegesis are not an 'official' specification for Perl6, I mean, they are subject to change. Is there any idea when will we have a freeze on the syntax and features for perl6? Sometime after perl 5's syntax and features freeze, I expect. When *that* happens is anyone's guess. :) More seriously, things will get less mutable as the implementation progresses, and I expect as we come up to a beta release things will be pretty stable, barring changes because things are unimplementable or problematic. That should happen over the next 6-12 months, time willing. Dan
Re: Apocalypses and Exegesis...
On 14 Aug 2003, Alberto Manuel Brandão Simões wrote: Hi Apocalypses and Exegesis are not an 'official' specification for Perl6, I mean, they are subject to change. Is there any idea when will we have a freeze on the syntax and features for perl6? Sometime after perl 5's syntax and features freeze, I expect. When *that* happens is anyone's guess. :) More seriously, things will get less mutable as the implementation progresses, and I expect as we come up to a beta release things will be pretty stable, barring changes because things are unimplementable or problematic. That should happen over the next 6-12 months, time willing. Dan
Re: Apocalypses and Exegesis...
On Thursday, August 14, 2003, at 07:00 AM, Alberto Manuel Brandão Simões wrote: On Thu, 2003-08-14 at 14:49, Simon Cozens wrote: Just a hint: don't try writing it and revising it as the language changes. I wrote a Perl 6 chapter for a book in December and it is now almost unusable due to the pace of change. Yes. That's why I'm asking :-) I can start looking to apocalypses and exegesis to have an idea of the structure and content, but not really write them. I would need a running prototype, too. And that's more difficult to find :) I add a hearty Amen to Simon's advice. In my own opinion -- which is worth approximately what you paid for it :-) -- things are probably pretty slushy until A12/E12 Objects comes out. AFAIK, that's due to be the next official A/E. I expect that _after_ that one, things will solidify rather rapidly; but be wary of doing too much before that, IMHO. The A12/E12 problem is that the core concepts and syntax related to objects and types have wide repercussions on the syntax of everything else -- control structures, subroutines, operators, etc. etc. etc. Since *everything* can be described as being an operation upon a set of objects/types (and, after all, even csubs/subs/ops are themselves objects, in the larger sense) until those object/type concepts are nailed down *quite* firmly, I would be a little wary of counting on the stability of anything else. We've seen several examples already of things changing -- for the better! -- long after the AEs for them have come out. I confidently prophesize at least one more big, scary round of that. My personal advice is to wait until E12 comes out and is polished, and then go whole-hog. I wouldn't expect any major changes to happen after that, because the rest of the AEs are less far-flung in scope. MikeL
Re: Apocalypses and Exegesis...
* Alberto Manuel Brandão Simões [15 Aug 2003 00:36]: On Thu, 2003-08-14 at 15:19, Iain Truskett wrote: [...] Much like Perl 6 Essentials then? I must say that its chapter 4 is the clearest look at the perl 6 syntax (as it was at the time of writing) that I've seen yet. Yeah. I would like to read it. But as I think syntax will change, I'm not thinking on buying it.. ;-/ Safari. http://safari.oreilly.com/0596004990 Of course, you need a Safari subscription, but they quite useful things. I imagine purchasing it physical copies would be more common on p6-internals as over half the book is Parrot and related goodness. cheers, -- Iain.
Re: Implicit parameter aliases
On 2003-08-05 at 16:10:46, Dan Sugalski wrote: At 1:02 PM -0700 8/5/03, Dave Whipp wrote: Can I discriminate on parameter names using multi subs? Nope. Named parameters don't participate in MMD. 1. I'm thinking MMD should be called something else when being applied to multisubs rather than multimethods . . . 2. If named parameters are not part of the subroutine's signature for selection purposes, that is perhaps an argument for not allowing them to be mandatory (which I asked about earlier). -Mark
Re: Apocalypses and Exegesis...
On Thu, Aug 14, 2003 at 03:00:54PM +0100, Alberto Manuel Brand?o Sim?es wrote: On Thu, 2003-08-14 at 14:49, Simon Cozens wrote: [EMAIL PROTECTED] (Alberto Manuel Brandão simões) writes: The question is simple, and Dan can have the same problem (or him or Larry). I am thinking on a Perl 6 book in portuguese (maybe only a tutorial... but who knows). But that means I must write something which will work :-) Just a hint: don't try writing it and revising it as the language changes. I wrote a Perl 6 chapter for a book in December and it is now almost unusable due to the pace of change. Yes. That's why I'm asking :-) I can start looking to apocalypses and exegesis to have an idea of the structure and content, but not really write them. I would need a running prototype, too. And that's more difficult to find :) Well, you can always find prototypical pieces in perl 5. For instance, Perl6::Classes, Perl6::Currying, Perl6::Rules, etc. (note, you may have to pull that last one out of Damian's head :-) But it looks to me like most of the major syntactic elements are fairly stable. So you should be able to pull stuff out of the Apocalypses and Exegeses and at least be within a few degrees of accuracy. Besides you could always provide online updates to your book as the language changes. The first (dead tree) edition would be the rough cut, and later editions would be closer to reality as the language stablizes. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl 6's for() signature
John Siracusa [EMAIL PROTECTED] writes:
Did this ever get resolved to anyone's satisfaction? While reading
EX6, I found myself wonder exactly what for() would look like in
Perl 6 code...
A for loop[1] is basically syntax sugar for a while loop. In general,
where foo, bar, baz, and quux are expressions, the following are equivalent:
for (foo; bar; baz) { quux }
foo; while (bar) { quux; baz }
If Perl6 has enough syntax-sugar ability to let you turn the former
into the latter, then you don't need to worry about for's signature.
[1] Of course I mean a C-style for loop.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Apocalypses and Exegesis...
On Thu, 2003-08-14 at 14:49, Simon Cozens wrote: [EMAIL PROTECTED] (Alberto Manuel Brandão simões) writes: The question is simple, and Dan can have the same problem (or him or Larry). I am thinking on a Perl 6 book in portuguese (maybe only a tutorial... but who knows). But that means I must write something which will work :-) Just a hint: don't try writing it and revising it as the language changes. I wrote a Perl 6 chapter for a book in December and it is now almost unusable due to the pace of change. Yes. That's why I'm asking :-) I can start looking to apocalypses and exegesis to have an idea of the structure and content, but not really write them. I would need a running prototype, too. And that's more difficult to find :)
Re: Apocalypses and Exegesis...
On Fri, Aug 15, 2003 at 12:19:28AM +1000, Iain Truskett wrote: * Jonathan Scott Duff ([EMAIL PROTECTED]) [15 Aug 2003 00:16]: [...] Besides you could always provide online updates to your book as the language changes. The first (dead tree) edition would be the rough cut, and later editions would be closer to reality as the language stablizes. Much like Perl 6 Essentials then? Well, yeah. But in portugese. Maybe he should just try to translate that book instead of writing his own. Or create a exegesis-style tutorial that somehow compliments P6E (having not read the book myself, I don't know if this would be appropriate/possible) I must say that its chapter 4 is the clearest look at the perl 6 syntax (as it was at the time of writing) that I've seen yet. /me makes *another* mental note to get the book. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Perl 6's for() signature
Jonadab The Unsightly One wrote:
John Siracusa [EMAIL PROTECTED] writes:
Did this ever get resolved to anyone's satisfaction? While reading
EX6, I found myself wonder exactly what for() would look like in
Perl 6 code...
A for loop[1] is basically syntax sugar for a while loop. In general,
where foo, bar, baz, and quux are expressions, the following are equivalent:
for (foo; bar; baz) { quux }
foo; while (bar) { quux; baz }
Well, except that in the second, any variables declared in foo will leak
into the scope after the end of the for loop.
Actually, in Perl 6, they'll do that anyway. Scope in loops is
strictly defined by the location of the braces WRT the location of
my. That is:
while (my $x = somefunc()) { ... }
# $x still in scope
And the same for all other loops. Cfor loops are an exception,
sortof, because they're really declaring a parameterized block instead
of a lexical variable.
Luke
Also, in the second, baz is inside the same scope as quux, whereas
in the normal C-style for loop, it's not.
Thus, for (foo; bar; baz) { quux } is really more like:
{
foo;
start_for_loop:
if( !bar ) { goto end_for_loop }
{ quux }
baz;
goto start_for_loop;
end_for_loop:
};
If Perl6 has enough syntax-sugar ability to let you turn the former
into the latter, then you don't need to worry about for's signature.
Well, yes. But the point of this discussion is, precisely what *kind*
of syntactic sugar will be used.
[1] Of course I mean a C-style for loop.
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Apocalypses and Exegesis...
Based on current experience, I'd say about three years after the start of development for perl7. =Austin --- Alberto Manuel Brandão_Simões [EMAIL PROTECTED] wrote: Hi Apocalypses and Exegesis are not an 'official' specification for Perl6, I mean, they are subject to change. Is there any idea when will we have a freeze on the syntax and features for perl6? Thanks, Alberto
Re: Apocalypses and Exegesis...
On Thu, 2003-08-14 at 15:19, Iain Truskett wrote: * Jonathan Scott Duff ([EMAIL PROTECTED]) [15 Aug 2003 00:16]: [...] Besides you could always provide online updates to your book as the language changes. The first (dead tree) edition would be the rough cut, and later editions would be closer to reality as the language stablizes. Much like Perl 6 Essentials then? I must say that its chapter 4 is the clearest look at the perl 6 syntax (as it was at the time of writing) that I've seen yet. Yeah. I would like to read it. But as I think syntax will change, I'm not thinking on buying it.. ;-/ cheers,
Re: Perl 6's for() signature
Jonadab The Unsightly One wrote:
John Siracusa [EMAIL PROTECTED] writes:
Did this ever get resolved to anyone's satisfaction? While reading
EX6, I found myself wonder exactly what for() would look like in
Perl 6 code...
A for loop[1] is basically syntax sugar for a while loop. In general,
where foo, bar, baz, and quux are expressions, the following are equivalent:
for (foo; bar; baz) { quux }
foo; while (bar) { quux; baz }
Well, except that in the second, any variables declared in foo will leak
into the scope after the end of the for loop. Also, in the second,
baz is inside the same scope as quux, whereas in the normal C-style
for loop, it's not.
Thus, for (foo; bar; baz) { quux } is really more like:
{
foo;
start_for_loop:
if( !bar ) { goto end_for_loop }
{ quux }
baz;
goto start_for_loop;
end_for_loop:
};
If Perl6 has enough syntax-sugar ability to let you turn the former
into the latter, then you don't need to worry about for's signature.
Well, yes. But the point of this discussion is, precisely what *kind*
of syntactic sugar will be used.
[1] Of course I mean a C-style for loop.
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Apocalypses and Exegesis...
* Jonathan Scott Duff ([EMAIL PROTECTED]) [15 Aug 2003 00:16]: [...] Besides you could always provide online updates to your book as the language changes. The first (dead tree) edition would be the rough cut, and later editions would be closer to reality as the language stablizes. Much like Perl 6 Essentials then? I must say that its chapter 4 is the clearest look at the perl 6 syntax (as it was at the time of writing) that I've seen yet. cheers, -- Iain.
Re: Apocalypses and Exegesis...
Apocalypses and Exegesis are not an 'official' specification for Perl6, I mean, they are subject to change. Is there any idea when will we have a freeze on the syntax and features for perl6? Since the A/E gig is where the design team is getting a handle on what it is they want to be doing and how (and then trying to explain it to the rest of us using small words :), I think they won't freeze anything until they're much further along on the series OTOH, I think they aren't planning to make sweeping changes to whats there already and most of it can be considered 'slushy', which may not be as good as frozen, but it's closer :o That's my take on it, of course; I could be entirely wrong, too --attriel
Re: printf-like formatting in interpolated strings
Sorry to drag out an old conversation, but I was indisposed at the
time, and only just got back to it.
On Mon, Jun 16, 2003 at 01:07:21PM +0200, Edwin Steiner wrote:
: Edwin Steiner [EMAIL PROTECTED] writes:
:
: Disallowing interpolated formats on \F has the additional advantage of
: making the {} unnecessary in the most common cases (also removing the
: 'force to string').
:
: As an afterthought: This suggests getting rid of the {} entirely.
:
: The rule could be like:
:
: \\F printf_format_without_percent funny_character_expression
:
: so
:
: The value in hex is \Fx$value.
: The value in hex is \Fx%lookup{$key}.
: The value in hex is \Fx$(calculate($x,5)).
:
: would both be ok. For more complex formatting you use Csprintf or
: Cbut formatted.
: I really like that. (It's perlish, too, don't you think?)
Apart with the leaning toothpick, there are several other problems
with the \F approach:
* It's hard to parse visually.
* It's not general enough.
* It doesn't put the important thing out front.
* It's inventing new syntax when we don't actually need it.
The thing everyone is missing here is that methods can now be
interpolated (and that everything in Perl 6 can be treated as an
object if you want it to be). Suppose we have a method .form that
can format any object. Without changing anything, we already have:
The value in hex is $value.form('x').
The value in hex is %lookup{$key}.form('x').
The value in hex is $(calculate($x,5).form('x')).
That doesn't invent new syntax, and it puts the variable out front
where it belongs. It's more general in that it works outside of
interpolations as well as inside. It's also easier to parse visually.
If that is not deemed easy enough to parse visually, then we can talk
about syntactic relief. If we wanted to stick with standard printf
formats, we could go with a pythonesque operator. We can even go
with % if we add dot to keep it unambiguous:
The value in hex is $value.%02x.
The value in oct is $value.%03o.
The value as string is $value.%-20.20s.
Those dots might look ambiguous there, but they're not, at least in
principle. It's basically using formats as a funny quoting construct
starting with .% and ending with a letter. Nevertheless, if it *looks*
ambiguous, that's also a problem.
On the other hand, if we went with a more rules-based formatting system,
this syntax suggests itself:
The value in hex is $value.02x.
The value in oct is $value.03o.
The value as string is $value.-20.20s.
The nice thing about this approach is that the format is visually
encapsulated inside angles, so it's easy to ignore when you want to,
and easy to find the other end of. It's also more amenable to
interpolation:
The value as string is $value.-$x.$y s.
This also gives us the more general
The value is $value.money.
which can presumably take arguments:
The value is $value.money(11, 2, comma = 1).
But then maybe you might as well write
The value is $value.as_money(11, 2, comma = 1).
or some such.
Still, one could consider inverting the standard formatting sequence
The value in hex is $value.x 02.
The value in oct is $value.o 03.
The value as string is $value.s -$x.$y.
where the defaults are just
The value in hex is $value.x.
The value in oct is $value.o.
The value as string is $value.s.
We could even go as far as to reserve single character rule names
for rules that can work both directions. (Not all can.) But that's
probably a bad idea. On the other hand, if there are predefined rules
like o, d, and x, they'd map naturally to people's formatting
skills.
On the gripping hand, I've always loathed scanf() and its ilk...
But none of that needs to be added for 6.0.0, since methods work
just fine. All we need to figure out for sure is the name of the
standard formatting method. (And its arguments...)
Larry
Re: Apocalypses and Exegesis...
[EMAIL PROTECTED] (Alberto Manuel Brandão simões) writes: The question is simple, and Dan can have the same problem (or him or Larry). I am thinking on a Perl 6 book in portuguese (maybe only a tutorial... but who knows). But that means I must write something which will work :-) Just a hint: don't try writing it and revising it as the language changes. I wrote a Perl 6 chapter for a book in December and it is now almost unusable due to the pace of change. -- Dames lie about anything - just for practice. -Raymond Chandler
Re: Perl 6's for() signature
Luke Palmer [EMAIL PROTECTED] writes:
Yes, it's possible to have two routines with the same name which
differ by signature... however, in Perl 6, Cfor has only one
signature, and it's the one above. The Cfor loop you are thinking
of is spelled Cloop,
Oh, yes, forgot about that.
To the contrary, Cwhile and Cif take only a single expression in
scalar context, whereas Cfor takes a list in flattening list
context.
*light dawns*
That's what I get for trying to start reading in the middle of a
thread, I guess.
Methinks that a signature should be able to call for a code block
in braces, and when it's called the signature after that code
block should be optional.
You mean s:2nd/signature/semicolon/ ?
Yes, that was a thinko. I thought I typed semicolon there.
This has already been discussed at length. The answer is um. :-)
I see.
So far documented, the semicolon is only optional when the closing
brace is the only thing on the line. Don't worry, Larry's got a
handle on this one, and I don't think it needs further discussion.
Cool.
Fooey, English is weird, let's stick with Perl.
Hmm, that last quote seems a little odd when placed next to your
signature... :-)
What, my little pathetic attempt at a JAPH? It's only even slightly
hard to follow if you don't understand closures. Nothing like some of
the clever monstrosities I've seen floating around on the net.
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b-()}}
split//,[EMAIL PROTECTED]/ --;$\=$ ;- ();print$/
Re: Apocalypses and Exegesis...
On Thu, Aug 14, 2003 at 12:52:42PM +0100, Alberto Manuel Brandão Simões wrote: Apocalypses and Exegesis are not an 'official' specification for Perl6, I mean, they are subject to change. Is there any idea when will we have a freeze on the syntax and features for perl6? Its scheduled to occur shortly following Hell. ;) -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ WOOHOO! I'm going to Disneyland! http://www.goats.com/archive/980805.html
Fwd: Re: Perl 6's for() signature
Fwd from Luke -- he's adopted a retarded MUA.
--- Luke Palmer [EMAIL PROTECTED] wrote:
Date: Mon, 11 Aug 2003 21:22:05 -0600
From: Luke Palmer [EMAIL PROTECTED]
Subject: Re: Perl 6's for() signature
Austin Hastings writes:
And you can't do that because the loop has no way of knowing that
your
lexicals are referring to block's parameters.
Which begs the question:
my blk = - $a, $b {...};
for (@list) blk;
What happens?
Exactly the same thing as:
for @list - $a, $b {...};
You get a yada-yada-yada exception :-P
Seriously, think of them like this:
my blk = sub ($a, $b) {...};
for @list, blk;
and
for @list, sub ($a, $b) {...};
(IOW, how do we map locals/parameters into block vars?)
That is, block vars Iare parameters.
Or, given
my blk = - $a {...};
loop (my ($x, $max) = (0, -1);
$x $num_elts;
$x++, $max = max($max, $x)),
blk;
What happens?
That's a different story. You get a not enough arguments to call
at runtime.
That's because Cloop doesn't map parameters; instead, it repeatedly
manipulates
lexicals. You'd have to write:
loop (...)
blk.assuming(a = $x);
Or as I said before,
loop (...) { blk($x) }
(IOW, in a target-rich environment, how do we know what to bind?)
Then again, Cfor
could be made to do that using named parameters, but I don't
think it
will (there are some nasty traps with variables in outer scopes).
It's
easy enough to say:
loop (my ($a, $b) = (0, 1); $a $b; ++$a) { block($a, $b) }
Or maybe we have to say
loop (...) - $a blk;
But that's nasty.
Yeah, don't think so. Plus, the block to Cloop can't take any
parameters,
because Cloop doesn't know what to give it.
In summary:
Cfor takes a list and a parameterized block blk, calling blk
repeatedly
with the elements of the list as arguments. Cloop (and Cwhile
and friends)
take a closure with no parameters, and mess with variables in such a
way
that they look like loop variables. They have no idea what to pass
the
block as parameters.
Hope this cleared some things up.
Luke
Now on to your argument :-)
We're really just pulling the block vars out so we can tweak
them.
Yeah, sortof.
...
It's a beginner trap, so Larry changed it to follow intuition.
It can
be useful in a couple places, and it never really gets in your
way. So,
poof, no more magic scopes.
Hooray for newbies. And that's a good point.
I'm still curious about the binding rules, though.
=Austin
This Week's Perl 6 Summary
Perl 6 Summary for the week ending 20030703 Ooh look, it's another Perl 6 summary. Doesn't that man ever take a holiday? I think he took one last month. Is it in Esperanto this week? I don't think so. Does Leon Brocard get a mention? It certainly looks that way. Does it start with the internals list again? I think it does, in fact, here it comes now. Approaching Python Discussions (and coding) of the Parrot implementation of Python continued this week. Michal Wallace is working on taking a preexisting (but incomplete, it's a proof of concept only) python parse tree - parrot code generator and rejigging it to generate code for IMCC. Assuming the initial rejig is doable, Michal surmises that getting a complete python compiler will be 'just' a matter of fleshing out the rest of the visitor methods, 'and then dealing with the C-stuff.' Actually, the main strand of this discussion dealt with ways of extending IMCC to help optimize the translation of stack based code to code that uses registers more efficiently (register unspilling as Benjamin Goldberg called it), which should help with any bytecode translator based efforts. http://xrl.us/crudf http://xrl.us/crukq Semantics of clone for PIO-objects Jürgen Bömmels' work on the Parrot IO system continues to find edge cases in Parrot's memory management subsystem. As initially written, a clone call adds a reference to a ParrotIO object, but that object is neither garbage collected nor refcounted, and it gets destroyed when its first reference is destroyed. The problem can be solved by allocating a new ParrotIO in the clone call, but Jürgen had some questions about how to handle various things like what to do with buffering or position pointers. Jos Visser offered a suggestion involving indirection and reference counting which met with (at least) Melvin Smith's approval. http://xrl.us/crusx Making 'make' less verbose Leo Tötsch checked in a patch to make make's output rather less verbose. After the patch, the make process only echos the name of the file being compiled, and doesn't spam your terminal with the entire compiler commandline (the compiler warnings do that). Some people liked this. Others didn't. http://xrl.us/cruz5 Don't trace system areas in sweep ops One of the things we discussed at the Parrot BOF was how to solve the 'bogus objects' problem when doing timely destruction sweeps (The 'bogus objects' problem is when the stack walk code detects chimerical objects through holes in the C stack (hmm... if anyone has a good drawing of this?)). After much discussion we came to the conclusion that the trick was to only walk the system stack during DOD (Dead Object Detection) runs that got triggered via resource starvation. This works because There is nothing unanchored and alive beyond the runloop's stack. Brent Dax was impressed, but then, he wasn't at the BOF so he doesn't know how long it took us to get to the answer. http://xrl.us/cru73 User defined events Klaas-Jan Stol wondered if there would be some way of generating and posting user defined events. Uri Guttman thought that there probably would be. http://xrl.us/crviz PHP/Parrot The language implementation insanity continues! Stephen Thorne announced that he's working on implementing a PHP parser and is seriously considering targetting Parrot. He asked for pointers to good docs on how to go about doing so. He worried a little about bootstrapping as well. Luke Palmer and Simon Glover were forthcoming with lots of useful answers and pointers. http://xrl.us/crvsa Why Parrot uses Continuation Passing Style In a delayed response to a question from Klaas-Jan Stol, Dan has posted a long message on the reasons for choosing Continuation Passing Style as Parrot's calling convention. It's definitely worth the read if you're at all interested in the reasoning behind Parrot (and the reason that my copy of *Perl 6 Essentials* has a signed correction from Dan). http://xrl.us/crv24 IMCC supports the Parrot Calling Conventions Leo announced that IMCC's brand of assembler, PIR (I can't remember what it stands for, Parrot Intermediate Representation perhaps). Of course, there are things it doesn't quite do yet (tail call detection, only preserving 'necessary' registers...) and it's somewhat lacking on the test front, but it's a start. Yay Leo! http://xrl.us/crv75 Another task for the interested: Coverage Dan threw out another 'task for the interested' this week. At present we don't have a complete set of coverage tests for the parrot opcodes, nor do we even know why opcodes do have coverage. Volunteers to fix this state of affairs (start with a coverage report
Re: This Week's Summary
- Original Message - From: Piers Cawley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, August 11, 2003 5:42 AM Subject: This Week's Summary Perl 6 Summary for the week ending 20030810 Another week, another summary. How predictable is that? (...) Generic code generator? Not content with his efforts in porting Python to Parrot, Michal Wallace floated the idea of a generic code generator for parrot that everyone could use. Stephen Thorne liked the concept, but worried that it wouldn't necessarily play well with languages that allowed eval $aString. He proposed that, whatever the code generator got written in should be a language that would be self-hosting. Joseph Ryan argued that, instead of coming up with a new meta-language for the GCG (Generic Code Generator), we should use something like XML or YAML as a way of dumping the AST (Abstract Syntax Tree) with standardized node names. Dan (who has a 'deep personal loathing for XML') was all for just building a standard datastructure and passing that into the code generator. (ASTnode.pmc anyone?). He also suggested that having some way of doing AST transforms would be handy, as many languages would want to get hold of the AST and munge it in some way before it went any further (Lisp macros are the canonical example of this sort of thing). Following the discussion, Michal and Klaas-Jan Stol apparently spiked out a prototype that used s-expressions. Your summarizer wonders if there's any overlap between this and treecc. Maybe I've just misunderstood what treecc was all about. Yeah, in some way you're right. TreeCC is a program for managing tree data structures. The user can write the specification for the nodes (their layout: what fields do they contain) and the operations (if any) should be written. The program is very handy in that it handles memory stuff (allocation, deallocation, node constructors) and it checks if a defined operation is implemented for all node types (if not, an error is emitted). (for example, a print_node operation should be implemented for each node type; nodes can extend another node for easy inheriting) It should be possible to use TreeCC for designing an standard AST that can then be created by any compiler targeting Parrot. When one has this AST, (with a generate_code operation) one could just call the generate_code operation, and the compiler writer doesn't have to write a single line of IMC. However, TreeCC is written in C, so that might be a problem, because C isn't hosted by Parrot (yet :)
This Week's Summary
Perl 6 Summary for the week ending 20030810 Another week, another summary. How predictable is that? In keeping with the predictability, we'll start with the internals list. Set vs. Assign T.O.G of Spookware has an issue with the way IMCC treats =; sometimes an = means set and sometimes it means assign, which TOGoS finds confusing. What he(?) finds even more confusing is that sometimes set has assign semantics. Dan agreed that this was somewhat confusing, and pointed out that there was a third possible semantic, clone. Luke Palmer agreed with TOGoS and suggested that it would be useful if the assign like behaviours of of set were moved over to becoming assign like behaviours of assign. Benjamin Goldberg wasn't even sure that set and assign were good names for those behaviours in the first place. He proposed three behaviour classes; mutate, alias and create. The general feeling seemed to be that Ben's approach was a good way forward, but I don't think anything has actually been implemented along these lines yet. http://xrl.us/oz5 Generic code generator? Not content with his efforts in porting Python to Parrot, Michal Wallace floated the idea of a generic code generator for parrot that everyone could use. Stephen Thorne liked the concept, but worried that it wouldn't necessarily play well with languages that allowed eval $aString. He proposed that, whatever the code generator got written in should be a language that would be self-hosting. Joseph Ryan argued that, instead of coming up with a new meta-language for the GCG (Generic Code Generator), we should use something like XML or YAML as a way of dumping the AST (Abstract Syntax Tree) with standardized node names. Dan (who has a 'deep personal loathing for XML') was all for just building a standard datastructure and passing that into the code generator. (ASTnode.pmc anyone?). He also suggested that having some way of doing AST transforms would be handy, as many languages would want to get hold of the AST and munge it in some way before it went any further (Lisp macros are the canonical example of this sort of thing). Following the discussion, Michal and Klaas-Jan Stol apparently spiked out a prototype that used s-expressions. Your summarizer wonders if there's any overlap between this and treecc. Maybe I've just misunderstood what treecc was all about. http://xrl.us/oz6 Calling convention questions Vladimir Lipskiy had a couple of questions about how the calling conventions worked. Dan and Leo supplied the answers, Vladimir pointed to the section of pdd03_calling_conventions.pod that had caused the confusion, and Dan went and fixed the docs. http://xrl.us/oz7 Infant Mortality Every so often, perl6-internals ends up talking about the Infant Mortality Problem -- the possibility of an object being marked as dead by the GC system before it's even been fully initialized. Benjamin Goldberg addressed himself to the problem this week by proposing a generational Garbage Collector. I'm not sure anyone was convinced that his proposed use of a generational collector to avoid having to walk the C stack was the Right Thing, but nor do I think anyone's averse to trying a generational collection scheme to see how performance stacks up. http://xrl.us/oz8 Packfile stuff Dan outlined some things we need to add to the packfile format and the sub header in order to get things ready for more language work. He, Leo and the usual suspects thrashed out the implications (assemble.pl and disassemble.pl will finally get removed from the distribution for example), but I don't think a final bytecode and sub header format have been decided upon yet. http://xrl.us/oz9 Parrot on Win32? Valery A.Khamenya wondered if there was any news on getting a ready to run win32 Parrot distribution. Jonathan Worthington has volunteered to start work on producing regular build snapshots. Yay Jonathan! http://xrl.us/o2a Bitwise string ops Leo Tötsch checked in the beginnings of bitwise operators for strings and dropped a huge hint that it'd be good if someone could finish things up. Vladimir Lipskiy took the hint, but felt a good deal of pain trying to produce appropriately formatted diffs until he worked out how to do the equivalent of cvs diff -c in WinCVS (hopefully the same trick can be used to do cvs diff -u, which is the preferred diff format of perl6-internals). http://xrl.us/o2b Dynamic PMC classes Discussion of the appropriate interfaces for the dynamic loading of PMCs continued apace. Leo committed his current implementation, stressing that it wasn't final, but it is at least something to work on. http://xrl.us/o2c extproc_parrot Sometimes I worry
Re: %_ - is it available for use?
david nicol wrote:
[EMAIL PROTECTED] perl -le '$_{a}=27; package notmain; print $_{a}'
27
Gosh!
Let's document it! Would it go in perlvar or perlsyn?
It's already documented, in perlvar/Technical Note on the Syntax of Variable Names
(at the end)
