Re: require < 6.x
NeonEdge wrote on 2/21/01 4.07: ... >sense: could p6 allow (for the >first few versions anyway) a >"require <6;" directive? My ... This sounds to me like a good idea, especially if we implement some of the other radical changes, such as implicit 'use strict' or major changes to builtins. Personally I'd have it be 'use perl5' (it's the difference between making a new pragma and defining a third meaning for require [or redefining its current meaning]) but that's a minor detail. Unfortunately, it may be too late. Oh well... --Brent Dax Excuse typos, it's hahd to write on a Palm...
Re: Schwartzian Transform
John Porter declared:
Adam Turoff wrote:
> This message is not an RFC, nor is it an intent to add a feature to Perl
or specify a syntax for that feature[*].
Yay.
> We're all for making easy things easy, but the complexities of
> "map {} sort {} map {} @list" has always been befuddling to newbies,
especially when reading the code left-to-right.
So you think
@s =
map { $_->[0] }
sort { $a->[1] <=> $b->[1] }
map { [ $_, /num:(\d+)/ ] }
@t;
would be more clearly written as
@s = schwartzian(
{
second_map => sub { $_->[0] },
the_sort=> sub { $a->[1] <=> $b->[1] }, first_map => sub { [
$_, /num:(\d+)/ ] },
},
@t );
---
How about this?
@array=tsort
{ /num:(\d+)/ }
numerically #optional
@array;
is handled by something like
tsort(&;&@) {
my $t=shift;
my $s=shift || sub { $a cmp $b };
my @a=@_ || (something);
return
map { $_->[0] }
sort {
$a=$a->[1];
$b=$b->[1];
&$s;
}
map { [ $_ , $t ] }
@a;
}
It's totally untested, but you get the idea...
Or, a slightly different syntax from yours:
schwartzian {
first {...}
sort {...}
last {...}
} @ary;
--Brent Dax
Excuse typos, it's hahd to write on a Palm...
RE: Schwartzian Transform
>>>>>> "Brent" == Brent Dax <[EMAIL PROTECTED]> writes:
> Brent> @s = schwartzian(
> Please, if we're going to add an operator, let's not call it schwartzian!
> I have enough trouble already telling people how to spell my name. :)
Which is why my real suggestion was a 'tsort' ('tsort' eq 'transform and
sort') operator. Someone else showed a very ugly syntax with an anonymous
hash, and I was out to prove there was a prettier way to do it.
BTW, I don't think 'schwartz' as the function name would be a good idea
either. Then I'd have to write something silly like
schwartz {$a <=> $b} {s/foo/bar/} @ary; #I see your Schwartz is as big as
mine... --Dark Helmet
> Maybe I should have a kid named "Ian", so I can see on a roster some day:
>
> Schwartz,Ian
>
> :-)
:^)
--Brent Dax
[EMAIL PROTECTED]
This e-mail is a circumvention device as defined by the Digital Millennium
Copyright Act.
#qrpff
s''$/=\2048;while(<>){G=29;R=142;if((@a=unqT="C*",_)[20]&48){D=89;_=unqb24,q
T,@
b=map{ord
qB8,unqb8,qT,_^$a[--D]}@INC;s/...$/1$&/;Q=unqV,qb25,_;H=73;O=$b[4]<<9
|256|$b[3];Q=Q>>8^(P=(E=255)&(Q>>12^Q>>4^Q/8^Q))<<17,O=O>>8^(E&(F=(S=O>>14&7
^O)
^S*8^S<<6))<<9,_=(map{U=_%16orE^=R^=110&(S=(unqT,"\xb\ntd\xbz\x14d")[_/16%8]
);E
^=(72,@z=(64,72,G^=12*(U-2?0:S&17)),H^=_%64?12:0,@z)[_%8]}(16..271))[_]^((D>
>=8
)+=P+(~F&E))for@a[128..$#a]}print+qT,@a}';s/[D-HO-U_]/\$$&/g;s/q/pack+/g;eva
l
Re: Perl culture, perl readabillity
Otto Wyss wrote on 3/26/01 5.41: >A study in Science (291 >P.2165) found out that >english speaking children has >twice as much reading >problems as italian speaking >children of the same age. >And about similar difference >towards german and french. >This could come from the >fact that english has for 40 >phonetics over 1100 kinds of >writing while italian has for >25 phonetics only 33 kinds of >writing (sorry I hope I've >translated it into correct >terms). Also 9 years old >english children produce >more reading error than 7 >years old austrian children. The reward? English-speaking children learn what is arguably the most flexible and expressive spoken language in the world. >This is exactly like I feel >when I see a Perl script. Lots >and lots of special symbols, >special cases. And several >where it's not easy to >understand. This might come >from the fact Perl was/is >designed by english speaking >people. It seems that the >complexity of english writing >is directly integrated into >Perl. Yup. Remember, Larry Wall is a linguist by training--he learned in school about human languages. He applied this knowledge to Perl. While I agree that there /are/ a lot of special symbols and stuff, it ought to be fairly easy to write a script you can run on any Perl script that adds 'use English;' to the top of a script and translates all the special variables into their English.pm equivalents. They may not be French or Austrian variable names, but they'll be more readable. On another note, perhaps we should set up something where longer names for some special variables are built in. How's $}PERLVERSION sound? > On the contrast Pascal >was designed by german >speaking person (Wirth). I'm >not saying Perl should >become Pascal nor Pascal >like, I only want to show the >difference. While Pascal (at >least standard Pascal) was so >limited, it's still possible to >read >20 years old programs. Well >Larry once said "... lots of >languages that come out of >Europe have this thing of ..." >(http://archive.develooper.c >om/perl6-language%40perl. >org/msg05283.html). This >also might be related to the >language. Perl is hard to compare with any other languages except those it borrowed heavily from or those that borrowed heavily from it. I don't think Perl has borrowed much from Pascal (besides maybe the " : " syntax for attributes) so Perl and Pascal are hard to compare. >I have come to Perl6 just >about a month ago, so I can't >give much advice what >should be done. Also I'm not >too accustomed to Perl to >spot weaknesses. All I can do >is give some general advice. > >- Make readability your >main objective. Readability is >possibly the weakest part of >Perl. Of course. However, I found that the readability of Perl was greatly enhanced by the Llama. :^) Though many of the design decisions in Perl lend themselves to obfuscation, the final decision of readability lies with the guy writing Perl, not with the guy writing perl. We should, however, consider readability when we add New Magic to Perl. >- Keep your eyes on >modularity. Modularity is by >far the best concept where >complexity could be hidden. > >- Don't forget usability. This >is after all the point why >people use Perl in the first >place. Never. So the basic question is, readability or usability? I say usability. --Brent Dax Excuse typos, it's hahd to write on a Palm...
RE: Perl culture, perl readabillity
-Original Message- From: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 15.43 To: Brent Dax Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Perl culture, perl readabillity >> The reward? English-speaking children learn what is arguably the most >> flexible and expressive spoken language in the world. > > Sorry, my bigotry meter just went through the roof, adding this thread > to my kill list. Okay. If I offended anyone with that statement (as I appear to have done) I am sorry. I did _not_ mean to say other languages were bad. However, I believe that my statement that English may be the most flexible and expressive language stands--for the same reason that Perl is a flexible language, its redundancy. I never intended that to mean that there's something wrong with other languages, or even that English is 'better' in all ways. (Perl may be more flexible than C or other languages, but that doesn't make it 'better' than C--C is generally quicker to compile and execute.) However, I will not retract my statement, because I believe it and I believe that there are statistics to back it up. If you want to killfile me, fine, that's your choice. I just don't want you to do so because of a misunderstanding. --Brent Dax [EMAIL PROTECTED]
RE: Larry's Apocalypse 1
I think we were all just stunned by the sheer brilliance. :^) That package
thing is pretty damn clever...
--Brent Dax
[EMAIL PROTECTED]
This e-mail is a circumvention device as defined by the Digital Millennium
Copyright Act.
#qrpff
s''$/=\2048;while(<>){G=29;R=142;if((@a=unqT="C*",_)[20]&48){D=89;_=unqb24,q
T,@
b=map{ord
qB8,unqb8,qT,_^$a[--D]}@INC;s/...$/1$&/;Q=unqV,qb25,_;H=73;O=$b[4]<<9
|256|$b[3];Q=Q>>8^(P=(E=255)&(Q>>12^Q>>4^Q/8^Q))<<17,O=O>>8^(E&(F=(S=O>>14&7
^O)
^S*8^S<<6))<<9,_=(map{U=_%16orE^=R^=110&(S=(unqT,"\xb\ntd\xbz\x14d")[_/16%8]
);E
^=(72,@z=(64,72,G^=12*(U-2?0:S&17)),H^=_%64?12:0,@z)[_%8]}(16..271))[_]^((D>
>=8
)+=P+(~F&E))for@a[128..$#a]}print+qT,@a}';s/[D-HO-U_]/\$$&/g;s/q/pack+/g;eva
l
-Original Message-
From: Nathan Torkington [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 04, 2001 23.46
To: [EMAIL PROTECTED]
Subject: Larry's Apocalypse 1
Not a comment at all on it? Was I accidentally unsubscribed to
perl6-language?
*tap* *tap* is this thing on?
Nat
Re: Larry's Apocalypse 1
[EMAIL PROTECTED] wrote on 4/5/01 12.15: >2. package vs. module/class >Whoa. This is so simple yet so sublime. It solves so many issues in one swoop. Cool. >Assuming Perl6 will be parsing Perl5 code? Hmmm. That's interesting. Forget p52p6 and the whole 80/20 thing, we could potentially hit the 100% mark. I wonder, implementationally, if to keep Perl6 light Configure could ask "Path to Perl 5?" and then fork the Perl5 interpreter (instead of doing this natively). Maybe this is thinking too far ahead. I don't think so, because we want the symbols used in the p5 code accessible in p6. Maybe we can hack a special version of perl5 we can interfage with. Hell, we could even embed 5 into 6, if could contain the older symbols. Alternatively, since we're allowing for other parsers, maybe we could design a parser that handles Perl5.
Re: Perl_foo() vs foo() etc
Dan Sugalski wrote on 4/11/01 13.38: >At 03:09 PM 4/11/2001 >-0400, John Siracusa wrote: >>On 4/11/01 10:55 AM, Dan >Sugalski wrote: >> > It does fix the link issues, >though. perl6.so won't ever >have an >> > unqualified function in >it--they'll all have either a >Perl_ or _Perl_ >> > prefix on them, and all >global data will have a PL_ >prefix on it. >> >>Remind me again why it's >PL_ and not PERL_? > >Well, Perl_ and PERL_ won't >work, since that's relying on >case-sensitivity in the >various linkers, which is a Bad >Thing. Why don't we just say, "Variables and functions will NOT have the same post-prefix name"? Having Perl_foo and PL_foo is a bit confusing anyway. I like Perl_foo and PERL_foo--it makes it very clear what things are while making sure we keep our own little 'namespace'. --Brent Dax Excuse typos, it's hahd to write on a Palm...
RE: Re: Tying & Overloading
>I am not sure I do like the use of ~ here. It does not screan concatenate to me (but then again neither did . when I started perl) >I am thinking that maybe it should be a 2 character operator with at least one of then being + as + is common in many other languages for doing concatenation. How about $a cat $b? That keeps the theme of strings using words and numbers using symbols--like eq vs. ==. --Brent Dax
RE: Larry's Apocalypse 1 \}
> What I see as needed is a designated meta-token that will be reserved, in some form or another, as the switch-parser command. . . . > What about a hash-bang? Maybe putting a hash-bang in the middle of the text (outside of quoted literals, of course) could indicate that the referenced program is to take over the parsing duties. Or that we should dynaload (a la XS) a previously registered parser with that name. $foo=bar(); #!syntax VisualBasic baz=foo & frob() #!syntax Perl6 print $baz; That just feels right for some reason. Spooky... (cue X-Files theme) So, what else would we do with our new inline #! notation? Hmm... $foo=$bar; #!comment yadda yadda yadda blah blah blah foo bar baz #!endcomment $bar.=$baz; Maybe? Possibly? No? Darn... --Brent Dax [EMAIL PROTECTED]
Dot can DWIM without whitespace
IMHO, . can DWIM in most cases even if it's both object deref _and_ concat--without paying any attention to whitespace. Let's think about this for a minute. What are the common cases for use of concat? $a."b"; "a".$b; $a.$b; a.$b; $a.b; a.b; The first two are obviously concat, since that code makes absolutely no sense as an object deref. Unless we decide that objects can contain scalars and to access them you must prefix their name with $, the middle pair can't be object calls, so they're concat. The last two, however, are ambiguous. How can we figure out what they mean? Two possibilities: 1) we define a cc (or something like that--I prefer j, since it's shorter) operator that _always_ means concat, or 2) when you mean "call a function called b", you have to say &b; Alternately, we can overload . to do a deref on (blessed?) references, and concat otherwise. Does any of that make sense? Or should I be returned to my straightjacket? :^) --Brent Dax [EMAIL PROTECTED]
Re: Damian Conway's Exegesis 2
Damian Conway wrote: > > Simon observed: > >> On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote: >> > - A while ago, someone suggested that the word 'has' be an alias >> > for 'is', so that when you roll your own properties, you could write >> > more-grammatically-correct statements such as "my $var has >> > Colors(3)". Since 'are' is being considered as a synonym, is there a >> > possibility that 'has' will make it too? >> >> It would be disappointing if a substantial proportion of the built-in >> keywords were merely syntactic sugar for each other. is|are|has|: seem >> like far too many ways to express exactly the same concept. > > I agree. However, we envisage that the Perl 6 parser itself will be > highly mutable and comparatively painless to mutate, so it should be > easy to set up modules that create as many synonyms as you feel are > needed/necessary/required/essential/requisite/demanded/called for. Here's a thought: warn "half-(digested|baked) ideas ahead"; @a is constant; #sets @a to constant @a has constant;#same thing @a are constant;#sets *each element* of @a to constant @a have constant; #same thing See the distinction? This doesn't show well in the case of constant, but consider a property that says "remember my old value whenever I'm assigned to." We'll call this 'undoable'. In this case: @a is undoable; #@a=() is noticed, @a[0] isn't @a are undoable;#@a[0] is noticed, @a=() isn't (or maybe it is?) #i could have used has/have instead, but is/are makes more sense here --Brent Dax [EMAIL PROTECTED]
A couple of ideas about properties
Note the time I sent this out. My mind may not be thinking quite straight
at this point, so bear with me.
First of all, the dot dispute. If we want a way to absolutely make sure
we're checking a scalar's properties, why not reuse our keywords?
$foo is constant; #sets $foo's constant property to true
is $foo constant; #returns value of $foo's constant property
This avoids the possible ambiguity of C<$foo.constant> without adding any
new keywords or requiring the absence of a C<.prop> member. This also reads
like English:
Foo is constant.
Is foo constant?
Second, the values vs. variables problem. I'm sorry, but
C<(+$foo).whatever> is just way too ugly. Plus, it's really hacky and
inexpressive. Perl is supposed to be an expressive language, right?
This issue can be avoided altogether if we just say, "properties must
declare whether they attach to variables or values." This makes some
sense--what does C mean attached to a value? Is attaching C
to a variable a good idea?
This could also probably be done with minimal keyword impact. I'm not sure
if anyone has said how properties are implemented, but for the sake of
argument I'll assume they're somehow implemented as subs. If so, we could
just do:
sub foo is property(value) {#property that attaches to the value
...
}
sub bar is property(variable) { #property that attaches to the variable
...
}
Even if it was actually implemented some other way, all we'd need to do is
make sure that we can attach properties to it somehow. (The C
property would itself attach to a variable, not a value.)
--Brent Dax
[EMAIL PROTECTED]
RE: A couple of ideas about properties
Simon Cozens:
>On Sun, May 20, 2001 at 01:09:28AM -0700, Brent Dax wrote:
>> This also reads like English:
>> Is foo constant?
> Until you realise that in order to actually use it sensibly, you'll
have to say something like
> if (is $foo constant)
> instead of (as I would prefer)
> if ($foo is constant)
That depends on how you read an if statement. Personally, I read them
inside out, so I would read it as:
Is foo constant?
If so, do this.
Of course, most people do read them left to right, which does seem a lot
more like natural language. So maybe I'm just weird. (Inside out is more
useful for me in general when programming, so I just apply it everywhere.
Think about complicated subscripts or parenthesized expressions and you'll
see why.)
Having infix C be its value in Boolean context would probably not be a
good idea, so I won't suggest it.
An interesting thought just occured to me: are we going to implement tying
through properties?
my $foo is tied('Tie::SomethingOrOther', *@params);
This kinda fits in with the other properties we're using, where they
(conceptually) don't have any effects until later in the program. (Of
course, just as C<$fh is chomped> does actually do *something* at that
point, C<$foo is tied> would actually do something, but you don't think of
it as doing so.) Plus, you can access the underlying object through
$foo.tied (or whatever mechanism it may, but probably won't be, changed to).
Plus, that would mean that we'd freed up the C keyword.
This brings up another point: How do we un-property something? I know that
to undo $foo is true, you can just say $foo is false, but what if you now
want the variables trueness to be just like any other variable's trueness?
Perhaps we should add something to take away a property:
$foo is true; #$foo.prop{true}=(whatever)
.
.
.
$foo isnt true; #delete($foo.prop{true}), at least in Perl 5 terms
If we went with the C suggestion I made above, that means we've
just replaced a specific mechanism (untie()) with a more general mechanism
(isnt). In fact, if you muck with the meaning of not a bit, you could have
it be:
$foo is not true;
which avoids the adding of C, as well as the seemingly inevitable
problem of people putting the apostrophe in. I think the compiler would be
able to figure out what not means based on context. Of course, I could be
wrong. I've never written a real parser before, much less one as magical as
Perl's.
--Brent Dax
[EMAIL PROTECTED]
Fear the sys command on a windows boot disk. It can ruin your whole day.
Re: Coupla Questions
Graham Barr <[EMAIL PROTECTED]>:
>On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
>> [EMAIL PROTECTED] writes:
>> :> What should $foo = (1,2,3) do now? Should it be the same as what
>> :> $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC
does what
>> :> $foo = \@INC; does now.) Putting it another way: does a list in
scalar
>> :> context turn into a reference, or is it just arrays that do that?
>> :
>> : Just arrays, I believe.
>>
>> That hasn't actually been decided yet. There are good arguments on
>> both sides.
>
>Can someone post a few ? I am open to what are the pros/cons
>but right now my mind is thinking " Whats the benefit of making
>$a=(1,2,3); be the same as $a=[1,2,3]; when it could do something
>different, ie what it does in perl5"
I'm wondering if () should keep its functionality as a list composer at all.
Perhaps it should just be:
$foo=($a, $b); #$foo is equal to $b
$foo=[$a, $b]; #$foo is an array ref
$foo={$a, $b}; #$foo is a hash ref
@foo=($a, $b); #same as @foo=$b (what would that do?)
@foo=[$a, $b]; #@foo is an array containing $a and $b
@foo={$a, $b}; #@foo is an array containing $a, '', $b, '' (?)
%foo=($a, $b); #same as %foo=$b (what would that do?)
%foo=[$a, $b]; #%foo is a hash containing $a => $b (?)
%foo={$a, $b}; #%foo is a hash containg $a => '', $b => '' (?)
Thus,
($a, $b)=($c, $d); #$b=$d
[$a, $b]=[$c, $d]; #$a=$c; $b=$d; (except inline)
{$a, $b}={$c, $d}; # ???
This means that each of the wraparound things has exactly one meaning,
regardless of context. It also gives () back its C meaning, grouping stuff
together so it'll be evaluated first, instead of a meaning that can be
different in different contexts. (In general, I think that "syntactic
operators" like parenthesis and comma should behave the same regardless of
scalar/list context, while functions should behave differently. That's just
my bias, though. Feel free to laugh at me if I'm wrong here.)
--Brent Dax
[EMAIL PROTECTED]
RE: Multiple classifications of an object
I'd think that @ISA would be copied to .ISA on object instantiation, and after that the two wouldn't have anything to do with each other. We could set up one of those cool copy-on-write locks everyone's been talking about to save memory too. Or we could have it default to @ISA if .ISA doesn't exist, which is basically what Bart's saying, so I guess I agree with him, maybe. (Although I do think that when .ISA is created, it should get @ISA, whenever that happens to be.) -Original Message- From: Bart Lateur [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 28, 2001 17:59 To: [EMAIL PROTECTED] Subject: Re: Multiple classifications of an object On Wed, 27 Jun 2001 13:48:38 -0400, Dan Sugalski wrote: >And the current @ISA stuff is MI, >albeit on a per-class basis rather than on a per-object one. > >Anyway, as Damian mentioned, setting the .ISA property is a perfectly >reasonable sort of thing to do if the language supports this. Just one question. If an object would have both per-object inheritance (.ISA), and per class inheritance (@ISA), which one would have precedence? If there's a conflict, a method exists both for a superclass and for an object superclass (i.e. through .ISA), which list would be checked first? Which method would be picked, and executed? FWIW, I think I'd vote for .ISA, as it is more individually tied to this particular object. The other one is generic.
The function-interpolation syntax
I'm writing a little module that implements the $() and @() stuff we've been
talking about (using a source filter), and I just want to make sure I have
it right. This is the SYNOPSIS from my docs; let me know if the behavior
I'm describing is wrong.
sub Foo { '1' }
sub Bar { 1..5 }
sub Baz { @_ }
sub Context { wantarray ? 'list' : 'scalar' }
print "Foo: $(Foo)\n"; #prints Foo: 1
print "Bar: @(Bar)\n"; #prints Bar: 1 2 3 4 5
print "Baz: $(Baz('a', 'b'))"; #prints Baz: b
print "Baz: @(Baz('a', 'b'))"; #prints Baz: a b
print "$(Context)"; #prints scalar
print "@(Context)"; #prints list
Does that check out right?
Thanks,
--Brent Dax
[EMAIL PROTECTED]
How easy will it be to install new methods into builtins?
I was thinking about it today, and it occurred to me that we could make it very easy
to install new
methods into the builtin types (SCALAR, ARRAY, HASH, CODE). What if we simply had a
package for
each of these builtin types such that you could say something like:
sub ARRAY::merge(ARRAY $lhs, ARRAY $rhs) {
my @result;
my $ubound=($lhs.length < $rhs.length ? $rhs.length : $lhs.length) -
1; #here i'm calling
ARRAY::length, not SCALAR::length
for(0..$ubound) {
push @result, $lhs[$_ % $lhs.length];
push @result, $rhs[$_ % $rhs.length];
}
return @result;
}
and expect that to be callable like C<@a1.merge(@a2)>?
Here's another possibility along the same lines:
package SparseArray;#yes, I know package is going away...
@ISA=('ARRAY'); #without this, the stash assignment later would be
illegal
#do other stuff here...
and then later be able to say something like C<%main::{'@sparsearray'}=new
SparseArray> and expect
*that* to work right?
This could be a more general tying mechanism. It could also probably be integrated
into vtables,
although I don't really know enough about how they work to say that for sure.
(Obviously, this is
more of a Perl-level interface idea than an internals idea. I suppose that's why I'm
sending it
to -language. :^) )
BTW, one other random thought I came up with while I was writing this: Could
inheritance be a
property?
class My::Class is a('Other::Class'); #My::Class::ISA=('Other::Class')
--Brent Dax
[EMAIL PROTECTED]
FW: if then else otherwise ...
# This makes no sense. ?: tests a boolean value, which is either true or false.
# There is no ternary state for a boolean value. True/False, Yes/No, On/Off,
# 1/0. Are you suggesting Yes/No/Maybe? Or are you redefining True and False?
No. He's effectively saying this:
condition ? executed-if-positive : executed-if-zero : executed-if-negative
It doesn't quite fit into simple boolean logic. This has the potential to be useful
for sorters:
@indices=sort { $ary[$a] <=> $ary[$b] ? -1 : 0 : 1 } @indices; #sort by values of
another array in
reverse order
Yes, that last example can be done with a simple $ary[$b] <=> $ary[$a], but I'm trying
to show you
what this feature does and I just woke up so my brain isn't up and running yet. :^)
# Doesn't matter. What you're asking has no counterpart in boolean logic, and
# as such would make no sense in any computer language. You may have an idea,
# but you are saying it wrong if you do.
There are plenty of things that have no counterpart in boolean logic. Where are loops
defined in
Boolean logic?
--Brent Dax
[EMAIL PROTECTED]
Semi-OT: Good compiler book?
I'm going on vacation soon, and I'd like to get a good book on writing compilers--hopefully one that will help me when we actually start coding Perl 6. Any suggestions? I have no formal education on compilers, and I only know C, C++ and Perl (duh). (If this is too off-topic, let me know.) Thanks, --Brent Dax [EMAIL PROTECTED]
RE: Will subroutine signatures apply to methods in Perl6
# -Original Message-
# From: Uri Guttman [mailto:[EMAIL PROTECTED]]
# Sent: Friday, August 24, 2001 4:09 PM
# To: [EMAIL PROTECTED]
# Cc: [EMAIL PROTECTED]
# Subject: Re: Will subroutine signatures apply to methods in Perl6
#
#
# >>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
#
# DC> One might also envisage a C pragma
# to require
# DC> that all lexicals be typed.
#
# do you mean lexical params in a sub signature? or all lexicals in the
# current scope which contains the pragma?
#
# required typing for all lexicals feels too strong. many lexicals are
# just ordinary scalars and don't type well unless we require an
# int/string/float/ref type.
#
# what about making that mean that any scalar being assigned a
# method call
# (compile time checked only), must have a type? it would not
# be too broad
# and should be simple to check and it has useful behavior.
#
# use strict 'typing' ;
#
# my $foo = Dog.new() ;
#
# that fails at compile time.
#
# my Dog $spot = Dog.new() ;
#
# that is ok.
#
# my Canine $spot = Dog.new() ;
#
# that is ok if Dog ISA Canine. $spot could be assigned a Dog or a Cat
#
# my $foo = foo() ;
#
# is fine too, since no compile time detection of OO values is made.
Two other possibilities:
1. Typing is required on variables which method calls are invoked on:
use strict 'typing';#don't look at the keyboard! :^)
my Dog $spot=Dog.new; #ok
my Dog $fido=new Dog; #ok (indirect-object is staying, right?)
my $rex=Dog.new;#ok at this point...
$spot.bark(); #ok
$fido.bark(); #ok
$rex.bark();#ERROR: $rex isn't declared to hold an object
my $class="Dog";
my Dog $butch=$class.new; #lost in the shuffle
#of course, you could easily do this:
my Dog $sparky;
{
no strict 'typing';
$sparky=$class.new; #ok, since you switched off strict typing
}
2. A 'normal' type:
use strict 'typing';
my Dog $spot=Dog.new; #ok
my $foo="bar"; #bad--no type on $foo
my val $baz="quux"; #ok
I'm not necessarily suggesting 'val' as a type, however--that's just a
placeholder for whatever we would choose.
I don't see this as being one of the 'normal' strictures--this would be
in the @EXPORT_OK array, not @EXPORT (if strict used Exporter, that is).
You'd have to turn it on explicitly.
Could we use this so that we don't have to use 'ref' (or its moral
equivalent) in method lookups? In other words, if $spot is declared to
hold a Dog, can we assume that it does, thus skipping the check with
'ref' normally used for method dispatch? Would this even buy us
anything? Why am I asking myself these questions? Why are the
orderlies putting me in a white truck?
--Brent Dax
[EMAIL PROTECTED]
RE: Will subroutine signatures apply to methods in Perl6
# -Original Message- # From: Uri Guttman [mailto:[EMAIL PROTECTED]] # Sent: Friday, August 24, 2001 8:56 PM # To: [EMAIL PROTECTED] # Cc: [EMAIL PROTECTED] # Subject: Re: Will subroutine signatures apply to methods in Perl6 # # # >>>>> "BD" == Brent Dax <[EMAIL PROTECTED]> writes: ... # BD> Two other possibilities: # # BD> 1. Typing is required on variables which method calls # are invoked on: # # BD> use strict 'typing';#don't look at # the keyboard! :^) # BD> my Dog $spot=Dog.new; #ok # BD> my Dog $fido=new Dog; #ok # (indirect-object is staying, right?) # BD> my $rex=Dog.new;#ok at # this point... # # BD> $spot.bark(); #ok # BD> $fido.bark(); #ok # BD> $rex.bark();#ERROR: $rex # isn't declared to hold an object # # is that a compile time or runtime error? i don't think you can make it # compile time since $rex can be assigned a real object and # still call the # bark method. Compile-time error. $rex was assigned a real object with Dog.new; however, $rex wasn't _declared_ to be holding an object of any kind. Thus, we can say at compile time that $rex can't bark since $rex isn't supposed to have an object in it. # BD> 2. A 'normal' type: # # BD> use strict 'typing'; # BD> my Dog $spot=Dog.new; #ok # BD> my $foo="bar"; #bad--no type on $foo # BD> my val $baz="quux"; #ok # # BD> I'm not necessarily suggesting 'val' as a type, # however--that's just a # BD> placeholder for whatever we would choose. # # i don't like that. plain perl scalars should always be # allowed even when # while odd pragmata are in effect. OTOH, we did invoke strict 'typing' so we would need to give types. It kinda makes sense that you would need to specify a normal type, so you don't accidentally forget to put a type in when you meant to. # BD> I don't see this as being one of the 'normal' strictures--this # BD> would be in the @EXPORT_OK array, not @EXPORT (if strict used # BD> Exporter, that is). You'd have to turn it on explicitly. # # if it has the meaning i proposed, it could be under the default set in # use strict. but it deosn't have to be. I like the stuff currently in strict, but I'm not sure if I'd want strict 'typing' in most of the places I use strict. # BD> Could we use this so that we don't have to use 'ref' # (or its moral # BD> equivalent) in method lookups? In other words, if # $spot is declared to # BD> hold a Dog, can we assume that it does, thus skipping # the check with # BD> 'ref' normally used for method dispatch? Would this even buy us # BD> anything? Why am I asking myself these questions? Why are the # BD> orderlies putting me in a white truck? # # no, that won't work. you can always bypass that at runtime in too many # ways. as damian stated, runtime checks for objects are always in # effect. if a method isn't found or handled by AUTOLOAD or something it # is fatal (unless caught, of course). the method itself will # always need # to check its arguments if it cares about whether a class or object is # the invocant (i like that word. thanx, damian!). I'm not sure if you understood what I meant there. I meant that, if we know $spot is supposed to have a Dog in it, can we avoid checking if it really does (at least some of the time) and maybe shuck some overhead by doing so? Perhaps we only check after each assignment to $spot, and when we check we set a flag saying that it's already been typechecked so we don't have to do it again. Whatever, methinks I may optimizing too early. We all know what Knuth says about that. BTW, I like 'invocant' too. :^) --Brent Dax [EMAIL PROTECTED]
Changes in addressing of package variables?
I was thinking about Perl 6 today, and thought of something: if the sigil is now part of a variable's name, does that mean that $Foo::bar should actually be Foo::$bar in Perl 6? --Brent Dax [EMAIL PROTECTED]
RE: Something to hash out
# -Original Message- # From: Simon Cozens [mailto:[EMAIL PROTECTED]] # Sent: Saturday, August 25, 2001 10:59 AM # To: Dan Sugalski # Cc: [EMAIL PROTECTED] # Subject: Re: Something to hash out # # # On Sat, Aug 25, 2001 at 10:37:35AM -0400, Dan Sugalski wrote: # > I'm currently thinking of using .pasm as the extension for # parrot assembly # > code, and .pbc for precompiled bytecode. (Yes, the # interpreter loads and # > runs compiled bytecode from disk. Wheee!) Can anyone think # of anything # > better? They seem rather lame. (Bonus points for clever # acronyms gotten # > without strain, or puns in any human language) # # I was using .pas and .pac. Gotta think about 8.3ness, unfortunately. If you're worried about Win32, even Microsoft is breaking 8.3 in Visual Studio.NET. (The extension for VB project files is .vbproj, and VC++ is .vcproj. I'm trying to shuck Win32, but haven't been too successful so far--apparently Tux didn't like my old box.) Besides, both of those can be truncated without any problems. # On an unrelated note, and seeing Dan Bryan's experiments with # different # kinds of switch/dispatch, I think it makes sense to separate out ops # which correspond to PMC vtable functions (add, subtract, # etc.) and those # which don't. Those which do can be done with a switch to save # a function # call, and those which don't can use function pointers. This achieves # the same objective as auto-generating op wrappers around # vtable functions, # (saving one level of indirection) while leveraging the gain # from a split-level # op despatch loop. Not a bad idea. Allowing for optimizations later so they aren't premature is usually a good idea. :^) --Brent Dax [EMAIL PROTECTED]
RE: Expunge implicit @_ passing
# -Original Message- # From: Michael G Schwern [mailto:[EMAIL PROTECTED]] # Sent: Tuesday, August 28, 2001 4:35 PM # To: [EMAIL PROTECTED] # Subject: Re: Expunge implicit @_ passing # # # On Tue, Aug 28, 2001 at 10:47:35AM -0700, Damien Neil wrote: # > On Tue, Aug 28, 2001 at 09:13:25AM -0400, Michael G Schwern wrote: # > > As the pendulum swings in the other direction you get # mind-bogglingly # > > silly things like finalize which I just learned of today. # > # > What's so silly about finalize? # # Sorry, I ment "final". final classes and methods. The idea that you # can prevent someone from subclassing your class or overriding your # methods. I've seen things that hinder reuse, but this is the first # time I've seen one that violently blocks reuse! On the other hand, it could stop some of the really stupid uses for inheritance I've seen. The dumbest one was in high school Advanced Placement's C++ classes--the queue and stack classes inherited from the array class! (It was private inheritance, so you couldn't tell this from the outside.) This was one of the biggest kludges I've ever seen, and a good example of a bad use of is-a. It also meant that the class was nearly impossible to modify for different storage--it was far easier to just write a new class with the same interface. Stupid, stupid, stupid. --Brent Dax [EMAIL PROTECTED]
RE: Source/Program metadata from within a program
# -Original Message- # From: Michael G Schwern [mailto:[EMAIL PROTECTED]] # Sent: Thursday, August 30, 2001 10:13 PM # To: Bryan C. Warnock # Cc: [EMAIL PROTECTED] # Subject: Re: Source/Program metadata from within a program # # # On Fri, Aug 31, 2001 at 12:45:03AM -0400, Bryan C. Warnock wrote: # > Access to the source code. # # Already got that. # # use Fcntl qw(:seek); # seek DATA, 0, SEEK_SET; # @code = ; IMHO, that's too hackish--just reading that doesn't make what you're doing obvious. An explicit $*CODE filehandle would make more sense to the uninitiated. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Source/Program metadata from within a program
# -Original Message- # From: Dave Storrs [mailto:[EMAIL PROTECTED]] # Sent: Thursday, August 30, 2001 9:59 PM # To: The Perl6 Language List # Subject: Re: Source/Program metadata from within a program # # On Fri, 31 Aug 2001, Bryan C. Warnock wrote: # # > Access to the source code. # # Particularly comments and POD. Cool--I'd suggest a special $*CODE filehandle, to match $*DATA (that isn't going away, is it?). # I'd also like to be able to access information on the # particular perl that # is running this program...e.g., does it support 64-bit nums, # what is the # endianness of the native numbers, does it support threads and # (if so) what # threading model (though this is probably a moot point in P6, # perhaps it # is something that could be included into 5.8.x). Can't this sort of thing be in Config.pm (or its equivalent)? Since Parrot needs to know things like endian-ness and for reading precompiled bytecode anyway, we might as well make it convenient... --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Multiple-dispatch on functions
# -Original Message-
# From: Ken Fox [mailto:[EMAIL PROTECTED]]
# Sent: Saturday, September 01, 2001 9:44 AM
# To: Me
# Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michael G Schwern; Dan
# Sugalski
# Subject: Re: Multiple-dispatch on functions
...
# The one thing I'm curious about is whether different syntactic
# conventions affect the dispatcher or whether this is all just
# sugar for a single dispatch. Perl 5 uses several different
# sub call syntaxes:
#
# $obj->method(...)
# method $obj ...;
# function($x, ...);
#
# $obj->Scope::method(...)
# Scope::method $obj ...;
# Scope::function($x, ...);
#
# Does the C style dispatch differently from the C++ style?
#
# I'd expect indirect object syntax to dispatch like C++
# syntax since indirect object syntax is just sugar. But is
# it possible to tell the difference between C style and
# indirect object style for functions of arity 1?
#
# IMHO it would be very nice if everything was just sugar
# for "function($x, ...)". It would be harder to define
# the nearest multi-method, but at least we wouldn't
# have to worry about different dispatchers kicking in when
# we didn't expect them to.
I think what we have to do is separate dispatch into two steps. The
first should identify the name of the function being called and run
through all the packages it might be in, passing the name and the
parameters to the second step. The second step should see if a function
by that name exists in the package passed in. The logic goes something
like this for a simple function call:
sub first_step_normal {
my($function, @params)=@_;
my($package, $name)= $function =~ /^(.*)::(\w+)$/
$package ||= "main";
$name ||= $function;
if($address=second_step($package, $name, @params)) {
return &$address(@params);
} elsif($address=second_step($package, "AUTOLOAD", @params)) {
$AUTOLOAD=$name;
return &$address(@params);
}
else {
die "subroutine $name not found in package $package";
}
}
For a method call, it's more complicated:
sub first_step_method {
my($function, @params)=@_;
my($package, $name)=$function =~ /^(.*)::(\w+)$/;
$package ||= ref $params[0];
$name ||= $function;
@packages=($package, get_all_parents_in_traversal_order($package));
for(@packages) {
if($address=second_step($_, $name, @params)) {
return &$address(@params);
}
}
for(@packages) {
if($address=second_step($_, "AUTOLOAD", @params)) {
$AUTOLOAD=$name;
return &$address(@params);
}
}
die "method $name not found for object of type $package";
}
(Both of these examples leave out complications involving the package
$AUTOLOAD is in.)
The second step takes care of resolving the address of the function; it
handles picking which (if any) of the prototypes available for the
method is appropriate for those parameters. Its implementation is left
as an exercise to the reader. :^)
--Brent Dax (who finds it very amusing that the spell checker tried to
change Sugalski to Sealskin)
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
Should MY:: be a real symbol table?
Currently, in Perl 5, my() variables are stored in a totally separate way from normal our()/local() variables, in an array-of-arrays structure. This means that my() variables are second-class citizens. The opcodes to look up a my() variable are separate from the opcodes for an our()/local() variable. >From my point of view, this seems dumb. Is there any real reason my() variables are stored in a pad instead of a symbol table? It seems more natural that they would be stored in a symbol table, since symbol tables are designed to hold variables. It also seems like it would allow us to implement 'my sub'. Of course, this has long been in Perl 5; I don't think it could be changed at this point. However, we're now doing the same thing with Perl 6. As if it didn't seem stupid enough as is, we're supposed to simulate at least some of the functionality of a symbol table through the MY:: pseudo-package. Once again, why isn't MY:: stored in some sort of anonymous symbol table? This would allow us to do all the things we can normally do with a global, without the hassles of writing a magical pseudo-package. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Deoptimizations
# -Original Message-
# From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
# Sent: Saturday, September 01, 2001 12:29 PM
# To: [EMAIL PROTECTED]
# Subject: Deoptimizations
#
#
# Random musings from a discussion I had yesterday. (And check
# me on my
# assumptions, please.)
#
# One of the more common lamentations is that a dynamic
# language (like Perl)
# doesn't mix well with optimizations, because the majority of
# optimizations
# are done at compile time, and the state at compile time isn't
# always the
# state at runtime. A common declaration is, "We'd like to
# optimize that, but
# we can't, because foo may change at runtime."
#
# Perl 5 optimizations replace (or, more accurately, null out)
# a more complex
# opcode stream [1] with a simpler one. Constant folding is
# one such example.
#
# 5 -> add -> 10 -> add -> 15 -> store
#
# becomes
#
# 30 -> store
#
# plus a bunch of null ops. (The null ops are faster than
# attempting to
# splice the new opcode stream [1] in place of the old one, but
# I don't know
# by how much.)
#
# Consider the following:
#
# Create an optimization op, which is more a less a very fancy
# branch operator.
# Whenever you elect to do an aggressive optimization, place
# the opt op as a
# branch between the newly created... [1] and the old, full one.
#
# The op could decide ( From a switch or variable - turn on and off
# optimizations while running. Or from state introspection,
# perhaps, since you
# probably have a good idea of what changes would invalidate
# it. ) whether to
# exercise the optimized code, or revert to the original,
# unoptimized version.
# I supposed, if you were to implement an advanced JIT, you
# could replace an
# invalidated optimization with its newly optimized variant.
#
# That would also work with a couple of tie-ins with the
# language. First,
# of course, the ubiquitous pragma, which could affect which
# optimizations
# (assuming we categorized them) we should run, and which we
# shouldn't, based
# on the suggestions from the programmer. And perhaps some
# hook into the
# internals for the same reason.
#
# sub foo {
# no optimizations;
# ...
# }
#
# or
# {
# local $opt = (ref $obj eq "SomeNewObject");
# # If the $obj has changed, don't run any optimizations
# }
#
# Is this possible? Feasible? Way out there?
I think it's a good idea! ++[bwarnock]!
Of course, the hard part is detecting when the optimization is invalid.
While there are simple situations:
sub FOO {"foo"}
print FOO;
evaluating to:
/-no--"foo"-\
opt: FOO redefined? -< >---print
\-yes-call FOO--/
there could also be some more complicated situations, in which the
situations where the optimizations are invalid are harder to define.
I'd also suggest a different pragma:
use less 'optimization';
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: Deoptimizations
# -Original Message-
# From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
# Sent: Saturday, September 01, 2001 3:01 PM
# To: Brent Dax; [EMAIL PROTECTED]
# Subject: Re: Deoptimizations
#
#
# On Saturday 01 September 2001 05:07 pm, Brent Dax wrote:
# > Of course, the hard part is detecting when the optimization
# is invalid.
# > While there are simple situations:
# >
# > sub FOO {"foo"}
# >
# > print FOO;
# >
# > evaluating to:
# >
# > /-no--"foo"-\
# > opt: FOO redefined? -< >---print
# > \-yes-call FOO--/
# >
# > there could also be some more complicated situations, in which the
# > situations where the optimizations are invalid are harder to define.
#
# Granted, code can always be written more complexly than our
# ability to
# understand it, in which case we very well may throw out the
# warnings that
# Thou Shall Not (if thou wants consistant, accurate results).
#
# But for many optimizations, although perhaps more with peephole
# optimizations than with full code analysis type of
# optimizations, simply
# identifying a possible optimization usually identifies its
# potential undoing
# as well.
#
# After all, optimizations don't just happen. They are, more
# or less, a set
# of known patterns that you look for. For a dynamic language,
# part of the
# original identification of those patterns may very well be
# the additional
# identification of what pieces are critical to the optimization.
#
# Of course, with as *highly* a dynamic language as Perl, there
# may be several
# hundred things that could invalidate a given optimization -
# it would be less
# optimal to detect all those things that to simply run the
# unoptimized code!
#
# But in many cases, it may only be one or two.
You'd be surprised how quickly the possibilities pile up:
sub FOO {"FOO"}
sub BAR {"BAR"}
sub BAZ {"BAZ"}
sub QUUX ("QUUX")
print FOO.BAR.BAZ.QUUX;
When you try to do inlining and constant folding, you end up with
something like this:
OPT:
Redefined FOO or BAR or BAZ or QUUX?
/ \
no yes
/ \
/ \
/ \
/ \
"FOOBARBAZQUUX" OPT:
| Redefined FOO?
| /\
|yesno
|/\
|call FOO"FOO"
|\/
| \ /
| \/
| \ /
|\/
| OPT:
| Redefined BAR?
| /\
|yesno
|/\
|call BAR "BAR"
|\/
| \ /
| \/
| \ /
|\/
| Concatenate
|||
| OPT:
| Redefined BAZ?
| /\
|yesno
|/\
|call BAZ "BAZ"
|\/
| \ /
| \/
| \ /
|\/
| Concatenate
|||
| OPT:
| Redefined QUUX?
| /\
|yesno
|/\
| call QUUX"QUUX"
|\/
| \ /
| \/
| \ /
|\/
| Concatenate
\ /
\ /
\ /
\ /
\ /
RE: Should MY:: be a real symbol table?
# -Original Message- # From: Simon Cozens [mailto:[EMAIL PROTECTED]] # Sent: Sunday, September 02, 2001 4:34 AM # To: Brent Dax # Cc: [EMAIL PROTECTED] # Subject: Re: Should MY:: be a real symbol table? # # # On Sun, Sep 02, 2001 at 03:13:09AM -0700, Brent Dax wrote: # > Is there any real reason my() variables are stored in a pad # instead of a # > symbol table? # # Recursion. Perhaps I wasn't entirely clear. I'm suggesting array-of-symbol-tables instead of array-of-arrays. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message-
# From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
# Of Ken Fox
# Sent: Sunday, September 02, 2001 8:49 AM
# To: Brent Dax
# Cc: [EMAIL PROTECTED]
# Subject: Re: Should MY:: be a real symbol table?
#
# Brent Dax wrote:
# > Is there any real reason my() variables are stored in a pad instead
# > of a symbol table?
#
# Simon already told you why a pad is used.
#
# But I think you misunderstand what a symbol table is. Variables
# aren't *stored* in the symbol table. Only the definitions and storage
# locations of variables are stored there. During execution of a program
# symbol tables usually aren't needed -- the generated code embeds the
# necessary information from the symbol table. For example, if you have
#
# void f() { int x; x = 1; ... }
#
# then "x" in the symbol table may be defined as "4 byte
# integer at stack
# pointer - 4". The code for getting/setting "x" doesn't use the symbol
# table because it has instructions like "mov sp[-4], 1" or something.
That's certainly true for C. Actually, I'm not sure the symbol tables
still exist when you execute the program.
Perl, however, is such a dynamic language you can't do a lot of that
resolution at compile-time. What happens when I say:
C:\Documents and Settings\Administrator\Desktop>perl
$x="foo";
$::{"x"}=\"bar";
print $x;
^Z
bar
? If that had been resolved at compile-time, it would have printed
"foo"--but I replaced the SV with "foo" in it. (FWIW, though, I think
it resolves it down to the typeglob.)
However, there are other cases, such as stash manipulations and symbolic
references.
# > Once again, why isn't MY:: stored in some sort of anonymous symbol
# > table? This would allow us to do all the things we can normally do
# > with a global, without the hassles of writing a magical
# > pseudo-package.
#
# You can't store lexical variable definitions in a global symbol
# table. What happens when you try to access a local variable that
# doesn't exist because it isn't in scope? Also, many of the scopes
# that contain variables aren't named. How would you differentiate
# between the following two "$x" variables?
#
# sub f() { if (...) { my $x; ... } else { my $x; ... } }
That's not terribly hard--the two ${x}es are in unrelated scopes. The
more difficult case is:
sub f() { my($x); if(...) {my($x); ...} }
but in that case the inner my($x) could be translated to
temp($MY::x)--the behavior is basically the same. (Actually, if pads
are replaced with stashes, is there any situation where my($x) can't be
translated to temp($MY::x)? Hmmm...)
# If you want to grab a lexical, you *must* be in scope. If you're
# already in scope there's no reason for "MY::" -- just use the
# variable's real name.
But we've promised to support %MY::. I think we could avoid coding a
special case by using an array of symbol tables instead of an array of
arrays. Besides, who's to say we don't want 'use dominatrix;' to
require my() variables to be fully qualified? :^)
# It sounds like you just want a simple way of getting the variables
# in scope -- are you writing a debugger? I agree with you that it would
# be very nice to have a low-level debugging API that doesn't treat
# lexicals differently than globals.
No, but I'm planning to help write Perl 6, and I want to make things at
least a bit easier. :^)
Plus, it would help remove many inconsistencies in certain operations,
such as symbolic references:
C:\Documents and Settings\Administrator\Desktop>perl
our($x)="global";
{
my($x)="local";
print join ' ', $x, ${"x"};
}
^Z
local global
(I also seem to remember some weirdness similar to this with eval, but
couldn't reproduce it.)
While this is the documented behavior of Perl 5.6.1, I don't think it's
the right behavior--do you?
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message- # From: Sam Tregar [mailto:[EMAIL PROTECTED]] # Sent: Sunday, September 02, 2001 1:23 PM # To: Brent Dax # Cc: [EMAIL PROTECTED] # Subject: RE: Should MY:: be a real symbol table? # # On Sun, 2 Sep 2001, Brent Dax wrote: # # > but in that case the inner my($x) could be translated to # > temp($MY::x)--the behavior is basically the same. # (Actually, if pads # > are replaced with stashes, is there any situation where # my($x) can't be # > translated to temp($MY::x)? Hmmm...) # # Closures, for one. File-scoped lexicals for another. # Lexical variables # are very different beasts from package variables. They are # not compatible # in some significant ways. Okay, I forgot to account for the fact that we'd have to increment the refcount for every inner scope a my() variable is referred to in. That's not terribly hard, is it? File-scoped lexicals are basically the same thing--increment the refcount for every inner scope they're referred to in (unless they have some other special behavior I'm not aware of). # Now, that said, we'll need to do something better than pads to support # %MY. If that means full-blown symbol tables for every scope... Well, # I'd be surprised. There's a reason lexical variables are faster than # package variables and I imagine we'd like to keep it that way. I imagine they'd *still* be faster than package variables, if only because it would check for a my() variable by that name first. Since we don't have to deal with autovivifying my() variables, we can probably resolve many lookups at compile time at least to the correct stash entry, which will make tighter loops than a full lookup each time. (In other words, if we know all the my() variables available, we can do the lookup at compile time to get the address of an RV to the actual SV.) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message-
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Sunday, September 02, 2001 1:37 PM
# To: Brent Dax
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
#
# On Sun, 2 Sep 2001, Brent Dax wrote:
# >
# > Perhaps I wasn't entirely clear. I'm suggesting
# array-of-symbol-tables
# > instead of array-of-arrays.
#
# It is right now in perl 5, and that isn't changing. How do you think
# string eval finds lexicals in scope by name now? :)
"As mentioned briefly above, the xcv_padlist element holds a
pointer to an AV. This array, the padlist, contains the
names and values of lexicals in the current code
block...The first element of the padlist - called the
'padname' - is an array containing the names of the
variables, and the other elements are lists of the current
values of those variables. Why do we have several lists of
current values? Because a CV may be entered several
times - for instance, when a subroutine recurses."
--from Simon Cozens's tutorial on Perl 5 internals.
What I'm suggesting is that, instead of the padlist's AV containing
arrays, it should contain stashes, otherwise indistinguishable from the
ones used for global variables. This way we don't have to recode the
lookup or do incredibly fancy stuff to support %MY::. It may even speed
up eval STRING or other situations in which lookup is at runtime. And
we should be able to resolve at least to the HE level at compile-time,
if you're worried about it slowing down runtime.
However, we might even be able to do this without a padlist! How? By
using temp() on the MY:: stash. Observe:
sub factorial {
my($x)=@_;
if($x==1) {return 1}
else {return $x*factorial($x-1)}
}
This could be translated by the parser to something like this:
sub factorial {
temp($MY::x)=@_;
if($MY::x==1) {return 1}
else {return $MY::x*factorial($MY::x-1)}
}
Assuming that each subroutine is given one MY:: stash, what
functionality has been lost? $x gets a new SV for each call into
factorial() (via the call to temp()), and since each subroutine has its
own MY:: stash, any routines that might be called by factorial() won't
be able to see factorial()'s MY::. Finally, this opens up the
possibility of easily-implemented static my() variables--just eliminate
the call to temp().
The basic principle behind this is to ask one simple question: "how are
temp() variables different from my() variables?" Ignoring closures and
implementation details (like that my() variables are stored in a pad),
the only difference is that temp() variables stay visible outside the
subroutine they were temp()orized in, while my() variables don't. The
simple way to emulate this is to make sure that no subroutine can see
another's MY:: stash. Since any subroutine can have my() variables, we
simply have to make sure each sub's MY:: stash blocks out each other
sub's.
There is a possible caveat with inner blocks--how does an outer block
get, er, blocked from accessing an inner block's my() variables?
However, I think this isn't really that big a problem, and can easily be
solved with properties:
sub foo {
# $x not declared yet, so it's out of scope
if(@_) {
my($x);
# now $x is in scope
# when we re-enter foo(), $x is not in
# scope in there.
foo();
# but by the time we get back, $x is back
# in scope again.
}
# $x is out of scope again
}
becomes
sub foo {
temp($MY::x);
$MY::x is out_of_scope();
#since $MY::x is marked as out of scope,
#attempts to access it in this block are
#unsuccessful...
if(@_) {
temp($MY::x);
# but in here, it's temp()ed again
# and the out_of_scope property is
# not in effect.
# when we re-enter foo, $x will be
# temp()ed again and the new $x
# will be marked as out of scope...
foo();
# but by the time we get back, we've
# got our $x back and we can access
# it.
}
# the inner temp is out of effect, so once
# again $x is marked as out of scope.
}
I don't think the argument that my() variables should be
RE: An overview of the Parrot interpreter
Note: this is my understanding of the situation; I could be wrong.
Sam Tregar:
# On Sun, 2 Sep 2001, Simon Cozens wrote:
#
# > For instance, the Parrot VM will have a register
# architecture, rather
# > than a stack architecture.
#
# s/rather than/as well as/; # we've got a stack of register
# frames, right?
IIRC, that's mostly for when we run out of registers or we're changing
scopes or whatever. For the most part, it's a register architecture.
# > There will be global and private opcode tables; that is to
# say, an area
# > of the bytecode can define a set of custom operations that
# it will use.
# > These areas will roughly map to compilation units of the original
# > source; each precompiled module will have its own opcode table.
#
# Side note: this isn't making sense to me. I'm looking
# forward to further
# explanation!
In other words, when you have sub foo {} in your code, it will be
assigned an opcode number in the 'private' section. The global section
is for things that are built-in to Parrot, while the private section is
for stuff you write. (Right?)
# > If our PMC is a string and has a vtable which implements Perl-like
# > string operations, this will return the length of the
# string. If, on the
# > other hand, the PMC is an array, we might get back the number of
# > elements in the array. (If that's what we want it to do.)
#
# Ok, so one example of a PMC is a Perl string...
>From what I've seen, PMCs will represent SVs, AVs, and HVs at the opcode
level. (When you get down to C, it's really SVs and AVs and HVs, but in
bytecode it's all PMCs.)
# > Parrot provides a programmer-friendly view of strings. The
# Parrot string
# > handling subsection handles all the work of memory allocation,
# > expansion, and so on behind the scenes. It also deals with
# some of the
# > encoding headaches that can plague Unicode-aware languages.
#
# Or not! Are Perl strings PMCs or not? Why does Parrot want to handle
# Unicode? Shouldn't that go in a specific language's string
# PMC vtables?
Perl *scalars* are PMCs. Those PMCs may hold strings within them.
However, string manipulation is done in special string registers, which
are *not* PMCs.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: Should MY:: be a real symbol table?
Note: some parts of this may seem a bit like a flame. This is unintentional. Ken Fox: # Brent Dax wrote: # > What I'm suggesting is that, instead of the padlist's AV containing # > arrays, it should contain stashes, otherwise indistinguishable from # > the ones used for global variables. # # Lexicals are fundamentally different from Perl's package (dynamically # scoped) variables. Even if you could somehow hack package variables # to implement lexicals, it would waste space duplicating a symbol table # for each instance of a lexical scope. *How* are they "fundamentally different"? You keep saying this, but I don't see it. In *functionality* what is the "fundamental difference" between package and lexical variables? # > The simple way to emulate this is to make sure that no subroutine # > can see another's MY:: stash. # # Right. Sounds a lot like a pad to me -- each instance of a scope (sub) # gets its' own copy of the variables. (By instance I mean activation # record, not the symbol table definition.) But in this case the pad is actually a full symbol table. The concept is the same, the data structure is different. # > There is a possible caveat with inner blocks--how does an # outer block # > get, er, blocked from accessing an inner block's my() variables? # > However, I think this isn't really that big a problem, and # can easily be # > solved with properties: # # You don't understand lexically scoped variables. There isn't # any run-time name lookup on a variable -- the compiler resolves all # access to a specific memory location (or offset). All your fancy # symbol table flag twiddling is slow, unreliable and unnecessary. There *is* run-time lookup in some contexts, such as a string eval. (Currently symbolic references are not another case--symrefs only work with globals--but I think they should work with lexicals too.) In the end, all I'm doing is suggesting an alternate implementation which should reduce our workload and make many concepts which currently don't work with lexicals work correctly. If there are big, huge problems with the alternate implementation I'm proposing, please explain them to me. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message-
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Monday, September 03, 2001 4:31 PM
# To: Ken Fox; Brent Dax
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: Re: Should MY:: be a real symbol table?
#
# >Lexicals are fundamentally different from Perl's package
...
# No, actually, they're not.
#
# The big difference between lexical variables and package
# variables is that
# lexicals are looked up by stash offset and package variables
# are looked up
# by name. (Okay, there are a few minor details beyond that, but that's
# really the big one) There really isn't anything special about
# a stash. All
# it is is a hash perl thinks contains variable names. (And it has GVs
# instead of [SHA]Vs, but once again a trivial difference, and
# one going away
# for perl 6)
#
# The real question, as I see it, is "Should we look lexicals
# up by name?"
# And the answer is Yes. Larry's decreed it, and it makes sense. (I'm
# half-tempted to hack up something to let it be done in perl
# 5--wouldn't
# take much work)
#
# The less real question, "Should pads be hashes or arrays",
# can be answered
# by "whichever is ultimately cheaper". My bet is we'll
# probably keep the
# array structure with embedded names, and do a linear search
# for those rare
# times you're actually looking by name.
Yay, someone understood what I was saying! :^)
As far as expensiveness, I think this can be just as fast as our current
offset-into-the-pad method.
If we allocate the stash at compile time (so the HEs don't change), we
can resolve lexicals down to the HE. In essence, the HE would be
serving the job a GV does in Perl 5 for globals, or an offset does for
lexicals on array-of-array pads--indirection. (Obviously this would be
in the fixup section in pre-compiled code.)
For those who don't understand my ravings:
sub foo { my($bar, @baz); ... }
becomes:
CV {
refcount --> 1
opcodes ---> ...
padstash --+
...|
} |
|
STASH { <+
HE (Hash Entry) { (0x1)
key -> '$bar'
value ---> SV *
...
}
HE { (0x2)
key > '@baz'
value --> SV *
...
}
...
}
At compile-time, we can allocate and fill the stash. Then, _still in
compile time_, we determine which HE will contain the value. For
example, we know that the value slot of the hash entry at 0x1 will
contain the SV currently representing $bar.
Now, we can change the actual SV containing the current value of $bar at
will. As long as the HE doesn't change, we're safe.
Since we're now looking up our variable names in a hash instead of an
array (remember, Perl hashes are only about 15% slower than arrays),
when we do have to look up a lexical at runtime we avoid an expensive
linear search. (I don't know how the offsets are determined at
compile-time in Perl 5, but if they're also determined by a linear
search, we'll make compilation more efficient too.)
Obviously, the current array-of-array pads are more compact than a
stash; however, I doubt that will be a serious issue.
~~
As far as the temp() thing I mentioned earlier, compare these two pieces
of code:
sub factorial {
my($x)=shift;
return 1 if($x==1);
return $x * factorial($x-1);
}
sub factorial {
temp($x)=shift;
return 1 if($x==1);
return $x * factorial($x-1);
}
These subroutines recurse. However, neither sub gets confused and tries
to modify another stack frame's $x. In the second sub, *temp() is just
a mechanism to get a new $x*. That's what I was talking about--I was
trying to draw an analogy between existing functionality and my
proposal.
If this point is still confusing, contact me privately and I can explain
it in more detail; if I get a bunch of requests I'll post it to the
group.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: Should MY:: be a real symbol table?
# -Original Message- # From: Dan Sugalski [mailto:[EMAIL PROTECTED]] # Sent: Monday, September 03, 2001 5:50 PM # To: Brent Dax; Ken Fox # Cc: Simon Cozens; [EMAIL PROTECTED] # Subject: RE: Should MY:: be a real symbol table? # # # At 05:30 PM 9/3/2001 -0700, Brent Dax wrote: # >As far as expensiveness, I think this can be just as fast as # our current # >offset-into-the-pad method. # # I was speaking in both speed and memory use when I was talking about # expense. We'd need to maintain a hash structure for each pad, # plus we'd # need to either design the hash structure such that it didn't # need absolute # addresses (so we could build it at compile time, which could # be a long time # before runtime with a disk freeze or two and an FTP in the # interim), or # we'd need to patch the addresses up at runtime when we # allocated a new pad. I assume we're willing to have more fixup time for runtime performance, correct? Then consider this: array-of-array pad: curpad => a pointer to the current pad; same as in Perl 5 offs => an offset into the current pad, representing a variable Accessing the address of the variable: curpad[offs] stash pad: hvaddr => the address of an HE, representing a variable Accessing the address of the variable: hvaddr->value Is either of these likely to be faster than the other? (Although I'm not an assembler hacker, I can't see the first being faster than the second.) If so, does the possible speed benefit outweigh any increased startup overhead? # I'm not convinced the memory usage, and corresponding time to # clone and/or # set up the hash-based pad, is worth the relatively infrequent by-name # access to variables in the pad. I could be wrong, though. # We'll have to try # it and see. (Shouldn't affect the bytecode, however, so we can try # different methods and benchmark them as need be) By using something similar to temp() (where the SV* is temporarily replaced), cloning should only be necessary for situations in which two threads are running the same function at the same time. Similarly, setting up the hash shouldn't take any more abstract operations than setting up padlist[0]; the actual hash internals may take more time to do their job, however. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Should MY:: be a real symbol table?
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
# -Original Message-
# From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# Sent: Monday, September 03, 2001 7:25 PM
# To: Brent Dax; Ken Fox
# Cc: Simon Cozens; [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
#
# At 07:05 PM 9/3/2001 -0700, Brent Dax wrote:
# ># From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
# ># At 05:30 PM 9/3/2001 -0700, Brent Dax wrote:
# ># >As far as expensiveness, I think this can be just as fast as
# ># our current
# ># >offset-into-the-pad method.
# >#
# ># I was speaking in both speed and memory use when I was
# talking about
# ># expense. We'd need to maintain a hash structure for each pad,
# ># plus we'd
# ># need to either design the hash structure such that it didn't
# ># need absolute
# ># addresses (so we could build it at compile time, which could
# ># be a long time
# ># before runtime with a disk freeze or two and an FTP in the
# ># interim), or
# ># we'd need to patch the addresses up at runtime when we
# ># allocated a new pad.
# >
# >I assume we're willing to have more fixup time for runtime
# performance,
# >correct?
#
# Yes. But fixup is a runtime cost, so we need to weigh what
# the fixup costs
# versus the return we get from it.
But it's a one-time runtime cost, unlike, say, a string eval in a loop.
(sub-entry overhead complaints cut--they'll be addressed at the end of
the e-mail.)
# ># I'm not convinced the memory usage, and corresponding time to
# ># clone and/or
# ># set up the hash-based pad, is worth the relatively
# infrequent by-name
# ># access to variables in the pad. I could be wrong, though.
# ># We'll have to try
# ># it and see. (Shouldn't affect the bytecode, however, so we can try
# ># different methods and benchmark them as need be)
# >
# >By using something similar to temp() (where the SV* is temporarily
# >replaced), cloning should only be necessary for situations
# in which two
# >threads are running the same function at the same time.
#
# Nope, I'm talking about recursion. When you do:
#
#sub foo {
# foo();
#}
#
# we need to clone foo's pad from the template, because we need
# a new one.
# Otherwise that whole lexical variable/recursion thing doesn't
# work, which
# is A Bad Thing. :)
Now is where the temp() stuff I was talking about earlier comes in.
sub foo {
my($bar);
foo();
}
is basically equivalent to
sub foo {
temp($MY::bar);
foo();
}
(I mentioned to Ken Fox in private that this isn't too different than
temp()ing globals when each sub is in its own package.)
If we did this, I don't think the cost would be greater to recurse than
it would be for array-of-arrays. (Especially since we'd make sure to
optimize the hell out of temp.) This would also lead to less code to
write and a smaller binary. Plus a simple way to do static: don't
temp()orize the variable on entry.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: An overview of the Parrot interpreter
Simon Cozens:
# On Mon, Sep 03, 2001 at 04:05:26PM -0700, Brent Dax wrote:
# > In other words, when you have sub foo {} in your code, it will be
# > assigned an opcode number in the 'private' section. The
# global section
# > is for things that are built-in to Parrot, while the
# private section is
# > for stuff you write. (Right?)
#
# That's a better explanation than I managed, thanks.
#
# > Perl *scalars* are PMCs. Those PMCs may hold strings within them.
# > However, string manipulation is done in special string
# registers, which
# > are *not* PMCs.
#
# That's also a better explanation than I managed, thanks.
Hey, I'm a trained professional in Cozens-to-English, what do you
expect? :^)
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
RE: pads and lexicals
Dave Mitchell: # Simon Cozens <[EMAIL PROTECTED]> wrote: # > On Thu, Sep 06, 2001 at 02:54:29PM +0100, Dave Mitchell wrote: # > > So I guess I'm asking whether we're abandoning the Perl 5 concept # > > of a pad full of tmp targets, each hardcoded as the # target for individual # > > ops to store their tmp results in. # > # > Not entirely; the last thing we want to be doing is creating PMCs at # > runtime. # # Sorry, I thought you were suggesting that at compile time a # fixed number of # tmp PMCs would be created, and slots 1-N of the PMC registers # would be set # permanently to point to them. Which is why I was concerned about the # possibility of N+1 tmps being needed. # # > > If a certain number of PMC regs are 'hardcoded' with pointers to # > > PMC tmps, then we need to address register overflow, eg # an expression like # > > # > > foo($x+1, $x+2, , $x+65); # > # > That's slightly different, though, because that'll all be # passed in as # > a list. # # So how does that all work then? What does the parrot assembler for # # foo($x+1, $x+2, , $x+65) # # look like roughly - and where do the 65 tmp PMCs come from? # In Perl 5 they're # the 65 pad tmps associated with the add ops. If foo is an unprototyped function (and thus takes a list in P0) we can immediately push the values of those calculations on to the list, something like (in a lame pseudo-assembler that doesn't use the right names for instructions): load $x, I1 load 1, I2 add I1, I2, I3 push P0, I3 load 2, I2 add I1, I2, I3 push P0, I3 (lather, rinse, repeat) In the more general case, however (say, $x*1+$x*2+...$x*65) that's an interesting question. Could we just do some fun stuff with lists? What do real CPUs do? --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: pads and lexicals
Dan Sugalski: ... # new P0, list# New list in P0 # get_lex P1, $x # Find $x # get_type I0, P1 # Get $x's type # set_i I1, 1 # Set our loop var # $10: new P2, I0 # Get a temp of the same type as $x # add P2, P1, I1 # Add counter to $x, store # result in P2 # push P0, P2 # Push it into the list # eq I1, 65, $20, $10 # If loop counter's 65 goto # $20, else $10 # $20 call foo# Call the sub ... Are you expecting the optimizer to be *that* powerful? If so, I think I'll stay with the execution engine... :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: pads and lexicals
Dan Sugalski: # At 12:04 PM 9/6/2001 -0700, Brent Dax wrote: # >If foo is an unprototyped function (and thus takes a list in # P0) we can # >immediately push the values of those calculations on to the list, # >something like (in a lame pseudo-assembler that doesn't use the right # >names for instructions): # # FWIW, it's: # # op, dest, source, source, source Yeah, I was just being too lazy to go open the assembler PDD and look for the right instructions, so I missed the format too. :^) # >In the more general case, however (say, $x*1+$x*2+...$x*65) that's an # >interesting question. Could we just do some fun stuff with # lists? What # >do real CPUs do? # # Real CPUs don't do lists. It's just one big addressable byte array... Those were two separate questions. :^) First, I thought that we could generalize the P0 case to all similar cases. Then, I thought "Hey, this has to happen on real CPUs all the time. How do they handle it?" See? Two separate ideas. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
Defeating variable-width encodings
A thought I had: if variable-width encodings are so difficult because it's hard to index into them by character, why don't we break them up ourselves? +PV---+ +strchunk-+-+ +strchunk-+-+ |string |-->|the quick brown fox jumped ov|>+-->|er the lazy dog |/| |... | +-+-+ +-+-+ Now, if we want to substr($str, 40, 1), we can skip the first chunk. (32 was a number I picked out of the air; other numbers may be better.) This avoids the possible huge overheads of other linked-list approaches while also avoiding some of the linear scanning that would otherwise be required to index into the string. As far as things with lvalue substr()...we could fudge that number a bit and allow strchunks to be a little more or less than 32, as long as they know their size. Then, whey you scan, you just add up the number of characters in each chunk until you overshoot. That makes scanning a bit slower, but not much. (We'd probably also want the string to rebalance itself periodically, but that's a different story.) An alternate approach would be to remember how far into the string you have to index to get to certain points in the string. (For the purpose of this part of the document, a 'byte' is a codepoint and a 'character' is an abstract character.) For example: +PV---+ |string |-->"the quick brown fox jumped over the lazy dog" |length 44| |bytes 44| |half 22| |quar 11| |threeq 33| |... | Although in this example the string is normal ASCII, consider what we would have if we replaced the 'o' in 'brown' and the 'a' in 'lazy' with two-byte characters (represented by a doubled letter): +PV---+ |string |-->"the quick broown fox jumped over the laazy dog" |length 44| |bytes 46| |half 23| |quar 11| |threeq 34| |... | Now, on a call like substr($str, 36, 1) we can skip all the way to byte 34--which we know represents character number 33--and count from there. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Math functions? (Particularly transcendental ones)
Jeremy Howard: # Uri Guttman wrote: # > >>>>> "BS" == Benjamin Stuhl <[EMAIL PROTECTED]> writes: # > # > >> Can anyone think of things I've forgotten? It's been a # while since # > >> I've done numeric work. # > # > BS> ln, asinh, acosh, atanh2? # > # > dan mentioned log (base anything) but i don't recall ln. # and definitely # > the arc hyberbolics are in after i pointed them out. dunno # about atanh2. # > # We only really need ln(). Then [log(y) base x] is simply # [ln(y)/ln(x)]. # There's no need to have separate functions for different bases. "OISC: You've heard of RISC, Reduced Instruction Set Computers? Well, here is the concept taken to its logical extreme -- an emulator for a computer with just one (1) instruction (Subtract and Branch if Negative)! Sample programs in the OISC machine language are included. We now have available have a revised and expanded version of oisc called OIC. In the future, this may replace OISC." from http://www.tuxedo.org/~esr/retro/ :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Configure system
Simon Cozens:
# One of the items on the Parrot TODO is to build a Configure
# system. I don't want to spark up the old metaconfig-versus-autoconf
# debate again, so I'll clarify what I mean.
...
# You'll notice that the Parrot build process currently depends on the
# existence of Perl 5 to build certain header files and preprocess the
# opcode table. So if we know we've got Perl 5 hanging around, we know
# we've already got a config file which tells us things like how big IVs
# are, what header files we have around, and so on. Furthermore, we
# can write a Perl program which uses Config.pm to give us this
# information in a hash, and hence we can use that to produce a
# config.h
# specific to a given machine.
#
# So I'd like to see a patch which consists of a program to
# automatically generate Parrot's config.h from Perl's Config.pm. You
# could be really clever, and also have it conditionally include some
# of the header files mentioned in parrot.h depending on whether the
# i_... values in Config.pm say we have them. (You may need to move the
# "#include"s of the system header files from parrot.h to config.h)
# No prizes will be awarded for using Perl's config.h, or C preprocessor
# abuse. :)
I'm starting to do some hacking on this. (Hey, I can't sleep... :^) )
Since Perl 5 already has this stuff, it seems like it should be pretty
easy. (Famous last words?) The $64,000 question is, what do I have to
copy over? A simple "autogenerate what's already in Parrot's config.h"
is easy--I've already written a prototype (pasted after my sig)--but
seems like it's too easy considering what you're talking about. What
else does it need to do?
The prototype below properly defines IV and NV (most of the time) based
on Perl 5's IV and NV. It also sets up HAS_HEADER_FOO for each of the
i_ symbols in Config.pm. Let me know if I should change the symbol I
define. (If the comment line with my name in it seems improper, feel
free to remove it.)
I'm on Win32, so I don't have the tools to make a diff (I'm trying to
get PPT working) so you'll have to turn it into a patch yourself.
Sorry.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
~~~
#!/usr/bin/perl -w
#we want -w on
#Configure.pl, written by Brent Dax
use strict;
use Config;
print <<"END";
Parrot Configure
Copyright (C) 2001 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Rules are the same as Perl 5's Configure--defaults are in
square brackets, and you can hit enter to accept them.
END
#Some versions don't seem to have ivtype or nvtype--provide
#defaults for them.
#XXX Figure out better defaults
my($iv, $nv)=(($Config{ivtype}||'long'), ($Config{nvtype}||'long
double'));
my $input;
print "How big would you like integers to be? [$iv] ";
chomp($input=);
$iv=$input||$iv;
print "How about your floats? [$nv] ";
chomp($input=);
$nv=$input||$nv;
my($config_h)=<<"END_OF_CONFIG_H";
/* config.h
*
* Platform-specific config file
*
* DO NOT EDIT THIS FILE!
* This file was autogenerated by Configure.pl--please
* rerun that! Changes to this file may be lost!
*
*/
#if !defined(PARROT_CONFIG_H_GUARD)
#define PARROT_CONFIG_H_GUARD
typedef $iv IV
typedef $nv NV;
typedef struct _vtable VTABLE;
typedef void DPOINTER;
typedef void SYNC;
//typedef IV *(*opcode_funcs)(void *, void *) OPFUNC;
#define FRAMES_PER_CHUNK 16
#define FRAMES_PER_PMC_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_NUM_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_INT_REG_CHUNK FRAMES_PER_CHUNK
#define FRAMES_PER_STR_REG_CHUNK FRAMES_PER_CHUNK
#define MASK_CHUNK_LOW_BITS 0xf000
END_OF_CONFIG_H
print <<"END";
Okay. Now I'm gonna probe Perl 5's configuration to see
what headers you have around. This could take a bit on slow
machines...
END
#set up HAS_HEADER_
foreach(grep {/^i_/} keys %Config) {
$config_h.=defineifdef((/^i_(.*)$/));
}
$config_h.="\n#endif";
open(CONFIG_H, ">config.h");
print CONFIG_H $config_h;
print <<"END";
Okay, we're done!
You can now use `make test_prog' (or your platform's equivalent to
`make')
to build your Parrot. Happy Hacking,
The Parrot Team
END
sub defineifdef {
my $thing=shift;
if($Config{"i_$thing"}) {
return "#define HAS_HEADER_\U$thing\E\n";
}
else {
return "#undef HAS_HEADER_\U$thing\E\n"; #XXX do we want this?
}
}
RE: Configure system
Simon Cozens: # On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote: # > A simple "autogenerate what's already in Parrot's config.h" is easy # # This is a good start. # # > --I've already written a prototype (pasted after my sig)--but # > seems like it's too easy considering what you're talking # about. What # > else does it need to do? # # I'd rather it took a config.h.in or similar and slapped the IV/NV/etc. # typedefs in the middle. This means we can hack the template each time # we need it to change, instead of hacking the Perl script that # generates # config.h. Good idea. Why didn't I think of it? :^) # Thanks for working on this. No problem--I'm just helping the best way I can at this point. Attached are new Configure.pl and config.ht files. Feel free to rename config.ht if you want. (They may have Windows newlines, unless e-mail clients do some translating of those behind the scenes that I don't know about.) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet." Configure.pl config.ht
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote: # > At 03:52 PM 9/10/2001 -0700, Damien Neil wrote: # > >Parrot fails to work in very obscure ways on FreeBSD. After some # > >poking around, I tracked the problem to the "end" op--this appears # > >to conflict with something inside libc. Renaming the op fixes the # > >problem. # > # > Ah, that's what was killing the build on Nat's machine. # Patch, by chance? # # The following quick-and-dirty patch appears to work. This prefixes # all opcode functions with "Parrot_op_". I'd have made the prefix # configurable, but the opcode generation is spread across three # different files. # # (Aside: What's the best way to generate a useful patch with cvs? # The following comes from "cvs -q diff -u".) This patch seems to work on the FreeBSD box I have access to. Now to figure out what's causing all those 'use of uninitialized value at assembler.pl line 81' messages... --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote: # > The following quick-and-dirty patch appears to work. This prefixes # > all opcode functions with "Parrot_op_". I'd have made the prefix # > configurable, but the opcode generation is spread across three # > different files. # # Oops--that breaks the assembler. This patch fixes the assembler to # work with the prior patch. That explains it! :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Parrot 0.0.1 is released.
# -Original Message- # From: Jeffrey Coleman Carlyle [mailto:[EMAIL PROTECTED]] # Sent: Monday, September 10, 2001 5:04 PM # To: 'Simon Cozens' # Cc: [EMAIL PROTECTED] # Subject: RE: Parrot 0.0.1 is released. # # # Am I missing something (well, clearly I am), but are test.pasm and # test2.pasm missing from the CVS repository? Check the t/ directory. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Patch to assembler/disassembler + parrot asm
Dan Sugalski: ... # The jump ops will be easy to figure--either they'll take a # register, a # constant number, or a label. We don't allow labels that could # be confused # with registers. (No I0: anywhere...) Noo! How will I write really confusing JAPHs now? :^) --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
RE: Math functions? (Particularly transcendental ones)
Dan Sugalski: # At 10:08 AM 9/10/2001 -0700, Wizard wrote: # >Uri Guttman wrote: ... # Okay, I see what you're aiming at. I don't think we will, # mainly because # it's not going to do us a whole lot of good. Parrot's got # more registers # than any system on the planet that I know of, so the bit that handles # converting to native machine code will need to do some analysis and # register renaming anyway. It can handle putting things in the # right places. I seem to remember reading in an article somewhere that Itanium has 128 registers. --Brent Dax [EMAIL PROTECTED] "...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet."
Should try work on use?
In Configure.pl, one of the things I do is include Data::Dumper if it's
there, and skip the part that needs it otherwise. Unfortunately,
because of the compile-time nature of use, I can't do it. Thus, I have
to use the following hack:
my($DDOK)=eval {
require Data::Dumper;
import Data::Dumper;
1;
}
Ugly, no? What I propose to fix it is that, if I do something like
this:
$DDOK=1;
try {
use Data::Dumper;
}
catch {
$DDOK=0;
}
and Data::Dumper doesn't load, the use statement be transmogrified:
$DDOK=1;
try {
throw "Can't find Data/Dumper.pm in \@INC (\@INC contains: @INC)";
}
catch {
$DDOK=0;
}
However, the transmogrification only occurs if a use is in a try block;
otherwise we get the same die-at-compile-time behavior.
In other words, I want exceptions thrown at compile-time to be catchable
at run-time by surrounding try blocks. Are there any barriers to this
working? If so, what are they?
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
RE: parrot-nightly
I applied this fairly recently; it may be helpful for a parrot-nightly. C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>perl Configure.pl --help Configure.pl - Parrot Configure Options: --debugging Enable debugging --defaults Accept all default values --define name=value Defines value name as value --help This text --versionShow assembler version C:\Brent\Visual Studio Projects\Perl 6\parrot\parrot>perl Configure.pl --defaults Parrot Configure Copyright (C) 2001 Yet Another Society Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. First, I'm gonna check the manifest, to make sure you got a complete Parrot kit. Okay, we found everything. Next you'll need to answer a few questions about your system. Rules are the same as Perl 5's Configure--defaults are in square brackets, and you can hit enter to accept them. Okay. Now I'm gonna probe Perl 5's configuration to see what headers you have around. This could take a bit on slow machines... Okay, that's finished. I'm now going to write your very own Makefile, config.h, and Parrot::Config to disk. Okay, we're done! You can now use `make test_prog' (or your platform's equivalent to `make') to build your Parrot. Happy Hacking, The Parrot Team --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done. H.Merijn Brand: # I've waited till either Configure or make would do something # sensible, and I'm # also aware that parrot-nightly isn't stable. Does # perl6-internals value input # like this (on a regular basis) or not. # # Either way, is there a point in time that parrot is released # as pseodo-stable # snapshots like Jarkko does with perl5? # # l1:/pro/3gl/CPAN/parrot-nightly 106 > make # perl Configure.pl # Parrot Configure # Copyright (C) 2001 Yet Another Society # # Since you're running this script, you obviously have # Perl 5--I'll be pulling some defaults from its configuration. # # First, I'm gonna check the manifest, to make sure you got a # complete Parrot kit. # # Okay, we found everything. Next you'll need to answer # a few questions about your system. Rules are the same # as Perl 5's Configure--defaults are in square brackets, # and you can hit enter to accept them. # # What C compiler do you want to use? [cc] # How about your linker? [ld] # What flags would you like passed to your C compiler? [ # -DDEBUGGING -Ae -D_HPUX_S # OURCE -I/pro/local/include -D_LARGEFILE_SOURCE # -D_FILE_OFFSET_BITS=64 -I.. -I./ # include] # Which libraries would you like your C compiler to include? # [-lnsl -lnm -lndbm -l # gdbm -ldb -ldld -lm -lc -lndir -lcrypt -lsec] # How big would you like integers to be? [long] # And your floats? [double] # # Okay. Now I'm gonna probe Perl 5's configuration to see # what headers you have around. This could take a bit on slow # machines... # # Okay, that's finished. I'm now going to write your very # own Makefile, config.h, and Parrot::Config to disk. # # Okay, we're done! # You can now use `make test_prog' (or your platform's # equivalent to `make') # to build your Parrot. # # Happy Hacking, # The Parrot Team # perl make_op_header.pl opcode_table > op.h # Can't locate Parrot/Opcode.pm in @INC (@INC contains: # /pro/lib/perl5/5.6.1/PA-RI # SC2.0 /pro/lib/perl5/5.6.1 # /pro/lib/perl5/site_perl/5.6.1/PA-RISC2.0 /pro/lib/pe # rl5/site_perl/5.6.1 /pro/lib/perl5/site_perl .) at # make_op_header.pl line 6. # BEGIN failed--compilation aborted at make_op_header.pl line 6. # make: *** [op.h] Error 2 # l1:/pro/3gl/CPAN/parrot-nightly 107 > # # -- # H.Merijn BrandAmsterdam Perl Mongers # (http://www.amsterdam.pm.org/) # using perl-5.6.1, 5.7.1 & 629 on HP-UX 10.20 & 11.00, AIX # 4.2, AIX 4.3, # WinNT 4, Win2K pro & WinCE 2.11. Smoking perl CORE: # [EMAIL PROTECTED] # http:[EMAIL PROTECTED]/ # [EMAIL PROTECTED] # send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
RE: Difficulties
Damien Neil:
# On Sat, Sep 15, 2001 at 01:15:57AM -0700, Brent Dax wrote:
# > As for the 5.6 thing...I think we're supposed to support 5.005 and
# > above. Can you tell what Parrot::Opcode needs it for?
# (And if it's for
# > 'our', I'm going to punch someone... :^) )
#
# Er...I think it IS for our, actually. :> I'm so used to using it, I
# didn't realize I was introducing a 5.6ism. The silly thing is, I
# deliberately avoided using "open(my $fh, $file)" to keep from
# requiring
# 5.6...
*THWAP*
# I notice that someone did add a "use 5.6.0" to Parrot::Opcode--here's
# a patch which removes it, and the offending ours.
#
# Index: Parrot/Opcode.pm
# ===
# RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
# retrieving revision 1.3
# diff -u -r1.3 Opcode.pm
# --- Parrot/Opcode.pm 2001/09/15 00:57:42 1.3
# +++ Parrot/Opcode.pm 2001/09/15 08:33:48
# @@ -1,12 +1,11 @@
# package Parrot::Opcode;
#
# -use 5.6.0;
# use strict;
# use Symbol;
# use Digest::MD5 qw(&md5_hex);
use vars qw(%opcode $fingerprint); #or strict will throw a tantrum
#
# -our %opcode;
# -our $fingerprint;
# +my %opcode;
# +my $fingerprint;
#
# sub _load {
# my $file = @_ ? shift : "opcode_table";
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
Backslashes in $PConfig{perl}
Configuration VC7 Normal is BROKEN. Step: make test STDOUT output: C:\Perl\bin\perl.exe t/harness t/op/basic..dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/2 tests, 50.00% okay (-1 skipped test: 0 okay, 0.00%) t/op/integerdubious Test returned status 26 (wstat 6656, 0x1a00) DIED. FAILED tests 1-26 Failed 26/26 tests, 0.00% okay t/op/number.dubious Test returned status 21 (wstat 5376, 0x1500) DIED. FAILED tests 1-19, 21, 23 Failed 21/23 tests, 8.70% okay (-2 skipped tests: 0 okay, 0.00%) t/op/string.dubious Test returned status 4 (wstat 1024, 0x400) DIED. FAILED tests 1-3, 5 Failed 4/5 tests, 20.00% okay (-1 skipped test: 0 okay, 0.00%) t/op/trans..dubious Test returned status 18 (wstat 4608, 0x1200) DIED. FAILED tests 1-18 Failed 18/18 tests, 0.00% okay Failed TestStat Wstat Total Fail Failed List of Failed --- t/op/basic.t 1 256 21 50.00% 1 t/op/integer.t 26 665626 26 100.00% 1-26 t/op/number.t21 537623 21 91.30% 1-19 21 23 t/op/string.t 4 1024 54 80.00% 1-3 5 t/op/trans.t 18 460818 18 100.00% 1-18 4 subtests skipped. STDERR output: 'C:Perlinperl.exe' is not recognized as an internal or external command, operable program or batch file. # Failed test (Parrot/Test.pm at line 74) # got: 'can't stat t/op/basic1.pbc, code 2 ' # expected: '42' # Looks like you failed 1 tests of 2. ... It looks like the backslashes in the path are being interpreted incorrectly. I don't think the problem is in Configure; can somebody look at it? --Brent Dax [EMAIL PROTECTED] They *will* pay for what they've done.
RE: A big GC D'oh!
Dan Sugalski:
# On my part. Here's a way we can dodge the whole neonate, infant
# mortality nonsense.
#
# Instead of marking everything dead at the beginning of a DOD run,
# which'll get us the most aggressive cleanup, we mark things dead at
# the *end* of the run. Then we also allocate all our headers marked as
# live on allocation, and make sure there's some minimum number of free
# headers after the end of a DOD run to make sure we don't collect too
# soon.
#
# This'll mean we don't have a neonate problem, though we trade that
# off with having all headers live through at least one DOD sweep. We
# can, if we want, have a separate DOD routine that does the mark as
# dead first (and last) that the explicit DOD trigger op can use so we
# don't have to worry about things living longer than they should.
#
# We could call them conservative_DOD and aggressive_DOD or something
# along those lines, if we wanted.
I could imagine a few pathological cases that would invoke two DOD runs
before we get around to anchoring the original header to the root set.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: [netlabs #629] [PATCH] Memory manager/garbage collector -major revision
Jerome Vouillon:
# I propose the following alternate guidelines.
#
# First, the code would look something like this:
#
# STRING * concat (STRING* a, STRING* b, STRING* c) {
# PARROT_start();
# PARROT_str_params_3(a, b, c);
# PARROT_str_local_2(d, e);
#
# d = string_concat(a, b);
# e = string_concat(d, c);
#
# PARROT_return(e);
# }
#
# Then, the rules would be:
# (1) start your functions with PARROT_start
# (2) register all parameters of type STRING * with PARROT_str_params
# (2') register all parameters of type PMC * with PARROT_pmc_params
# (3) declare the local variables of type STRING * with
# PARROT_str_local
# (3') declare the local variables of type PMC * with PARROT_pmc_local
I assume the lack of mentions of Buffers are an oversight.
# (4) use PARROT_return to exit the function
# (5) do not nest function calls
#(for instance, "e = string_concat (string_concat(a, b), c);"
# would be forbidden)
I don't understand the reasoning behind (5). Would you care to
elaborate?
# The idea is to explicitly manage a stack of parrot objects,
# which can be traversed by the GC.
#
# This rules let a lot of freedom to the garbage collector:
# - it can garbage collect anything which is not rooted;
# - it can move objects (strings and PMCs) around;
# - objects do not need any additional field/flag;
# - exception can be implemented using longjmp; if an exception is
# raised, temporary allocated objects will be properly freed
# by the GC.
Anything that lets us use longjmp is fine by me. ;^)
# Do you think that these rules would be too error-prone, or
# too cumbersome?
May I suggest an alternate version?
STRING * concat (STRING* a, STRING* b, STRING* c) {
Enter_sub(); /* The macros don't really need a Parrot_ prefix, do
they? */
Str_params_3(a, b, c);
Decl_str(d); /* These aren't needed anymore, actually... */
Decl_str(e);
Return(
string_concat(
string_concat(a, b),
c
)
);
}
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: GC design
Sean O'Rourke:
# On Tue, 28 May 2002, Jerome Vouillon wrote:
# > That's an interesting point, actually. What is the right
# thing to do
# > when we run out of memory?
# > - Abort immediately.
# > This is not very user-friendly.
# > - Return a special value.
# > But then we need to check the return value of almost all functions
# > (including string_compare, for instance).
#
# I personally dislike this approach, as it requires a large
# amount of programming discipline from everyone who works on
# the project. The current code indicates that if we took this
# approach, we would spend quite a bit of time squashing bugs
# from not checking return values in wierd places. It probably
# also hurts common-case performance to litter your code with
# redundant null-checks as well, but I don't have any data.
#
# > - Instead of returning a special value, we can set a global variable
# > to signal the error.
# > Again, we need to check this variable everywhere.
#
# This by itself seems worse than the above, since it makes
# problems even easier to ignore.
OTOH, if all C functions start with a boilerplate like:
if(interpreter->flags & PARROT_exception_FLAG) {
return NULL;
}
then this allows us to easily do things like:
string_concat(interpreter, string_concat(interpreter, a, b), c);
as long as we check for the exception immediately after. In fact, that
even lets you delay checking for exceptions so you can centralize
things--see below.
# > Note that this is the solution adopted by Java.
#
# Last time I wrote in Java, errors were entirely
# exception-based. Have things changed because of the locking
# issues you mention below?
I assume he means within the JVM's internals.
# > - Raise an exception using longjmp.
# > But then, if we start using locks all over the place like in Java,
# > we are pretty sure to leave the program in an inconsistent state.
#
# We're currently lock-free, which makes this sound like a good option.
I think we just have to say "if you put a lock on something, make sure
to set up an exception handler to unlock it and then rethrow the
exception".
I also think that any way you do it we'll have to wrap it in macros--at
least for embedders and extenders. If I ever find a few months of pure
boredom, I'd like to try to reimplement Parrot in C++, just to see how
much easier it would make things like PMCs; if we have appropriately set
up macros, we can hide from the user the actual implementation of
exceptions:
#define PARROT_TRY /* nothing */
#define PARROT_CATCH if(interpreter->flags &
PARROT_exception_FLAG)
...
PARROT_TRY {
d=string_concat(interpreter,
string_concat(interpreter, a, b), c);
...
}
PARROT_CATCH {
(code)
}
Just change the macros to:
#define PARROT_TRY try
#define PARROT_CATCH catch(void* PARROT_CATCH_this_is_unused)
for C++, or:
#define PARROT_TRY if(!setjmp())
#define PARROT_CATCH else
for setjmp/longjmp. (Yes, I know that's not the way setjmp is really
used, but you get the idea.) For short stretches of code, I'd imagine
that
PARROT_TRY d=string_concat(interpreter,
string_concat(interpreter, a, b), c)
PARROT_CATCH Parrot_fputs(interpreter, Parrot_stderr, "We're
screwed!");
(assuming that C++'s try and catch can take statements instead of
blocks, anyway--although even if they don't, it's just four more
characters.)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: Perl6 currying
Luke Palmer:
# Wait, does this have any meaning?:
#
# my &half = \div(y => 2)
Call div() with the named parameter 'y' equal to 2, take a reference to
its return value, and store that in &half.
# Is backslash even a valid operator for reference anymore? If so, this
# makes sense to me.
I'm sure it's still there. Otherwise there's no way to take a reference
to a scalar.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: [COMMIT] Added preprocessor layer to newasm.
Jeff:
# I haven't been tracking assembly speed at all. Keep in mind
# that a perl assembler is only a temporary measure, and it'll
# be rewritten in C eventually. It's only written in Perl so
C or PASM (or Perl 6)? The latter might be better.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: inline functions (was Re: [netlabs #629] [PATCH] Memory manager/garbage collector -major revision)
Melvin Smith:
# The common way is to define our own INLINE definition and
# have Configure check for it, define it null if needed, and
# conditionally include it into a file as extern if so.
#
# Sounds like a job for. BrentDax++!
We already *have* an INLINE, and it's done with #ifdefs. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: [netlabs #649] [PATCH] Allow numerical constant keys
Simon Glover:
# The new assembler allows one to use string constants and
# string registers interchangably as keys, but doesn't let you
# do the same for INTs or FLOATs. Patch below fixes.
That was intentional. S registers used on keyed ops are supposed to
contain runtime-constructed KEY structures, not strings.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: Parrot_Interp -> Parrot_Interp_t
Melvin Smith:
# In order to make the extension library work with C++ I had
# to rename Parrot_Interp typedef to Parrot_Interp_t
#
# I know _t was a subject of discussion, but its a quick fix so
# I can move ahead. Its only really used from embed.h in
# test_main.c and the extension API layer.
#
# If there are no complaints I'm going to commit this when I
# commit the initial patch for extensions.
I think that's renaming it the wrong way. The struct should probably
become parrot_interp_t and the typedef Parrot_Interp. This is
consistent with other data structures in Parrot. Unfortunately, that
means grepping over the core to change it, but that'll have to happen
anyway.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: [COMMIT] PXS or something like that
Melvin Smith:
# Native Extensions for Parrot:
#
# Rather than talk about it at length and not get any code
# done, I decided, concerning the native extension interface,
# to just take a simple hello world approach with some outside library.
I would normally agree with this sentiment, except that XS is externally
visible. That means that it can only change very slowly, so it has to
be more or less right from the start.
Now for my criticisms:
-We don't use the stack that way. Arguments are supposed to come in
as an array PMC.
-Macros suck. :^)
-How are you going to load a .dll instead of a .so on Windows when the
..so is hardcoded in?
-callnative is the wrong way to do it. What we need is a subroutine
PMC and a call vtable method.
However, this isn't a bad start. Overall, Melvin++.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: [netlabs #653] PATCH: P14[I3] support
Leon Brocard:
# This little patchette lets the new shiny assembler cope with
# using an I register as a PMC key, eg "P14[I3]". Obviously
# brainf*ck needs to be in the testsuite ;-)
See my comment on a previous, similar patch by Simon Glover.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: Configure.pl 2.0. and win32
Nick Kostirya:
# Configure.pl 2.0 does not want run on Win32 (windows NT 4.0,
# AcrivStatPerl 5.6.1, VC 6). Prior version ask me: what linker
# I want use. This do not ask, and variable $ld is undefined
# (module parrot/lib/Parrot/Configure/Step.pm, sub cc_build).
Configure now doesn't ask questions by default. You can tell it to ask
questions by passing in the "--ask" switch on the command line. You can
also tell it the linker's name directly by passing in
"--ld=(linker-name)".
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: Perl 6 regex stuff
Dan Sugalski:
# I've checked a draft copy of Apocalypse 5 into the repository. It'll
# get yanked once the final is released (and I think we may start
# checking in the final apocalypses and exegeses, but that's for later)
# but it's there now.
#
# Please note: This is so we can start writing the regex parser. It is
# *not* for design discussion as such (I'm not the person to talk to
# about that), and it really isn't for discussion on perl6-language (or
# elsewhere) since it *is* a draft. Close to final, but draft
# nonetheless. So, discretion please.
In that case, I have a half-written, untested bison/flex parser
attached. Have the appropriate amount of fun.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
regex6.y
Description: Binary data
regex6.l
Description: Binary data
RE: Half measures all round
Simon Cozens:
# I'm becoming somewhat disillusioned with Perl 6 these days;
# sometimes because it's too radical, more often than not
# because it's not radical enough, and quite often because it's
# more than a year behind schedule and still slipping. But that
# last point is by the by; with three people now working
# full-time on it, I'm sure we can expect it any day now.
It's actually starting to get a bit scary... ;^)
# What's really actually letting me down with it is the
# half-measures we're applying. We seem to be trying to please
# everyone, and it's not going to work; indeed, it's going to
# end up presenting a burden to the implementors.
#
# Let's take an example. One of the major points of Perl 6, and
# one of its major attractions for me, was that we finally put
# the backwards compatibility ghost to rest. We can do brave,
# new, exciting things, without worrying about needing to
# maintain obscure pieces of functionality. Yey! Except that we
# can't do that any more; we've constrained ourselves to
# faithfully regressing to Perl 5 when we see a "package"
# declaration. Why? Because we're scared. "package parses Perl
# 5" is a sop to people who don't want to program in Perl 6,
# and we're worried about losing those people.
Who says it's a bad thing to be scared, or that our fear isn't
justified? Fear is a survival instinct, and a relatively good one.
In this case, I think what happened is closer to "we saw a hook to bring
in backwards compatibility and used it". Unless I'm mistaken, the new
C and C keywords will probably have slightly different
meanings, so C was insufficient anyway. So we said, "OK, we're
changing this, and if we see it the old way we switch to Perl 5". I
don't think anyone's decided exactly what that means yet--we may load a
different rule set, set up some sort of source filter, or just cop out
and invoke p52p6. In any case, I think of it more as a convenience than
a major feature, and I suspect most Perl 6 users will agree with that
assessment.
# Maybe we've realised that we are going too far, and the new
# stuff doesn't look all that much like Perl 5, but we're not
# sufficiently committed to what we have to cut the umbilical
# cord. Are we going to innovate and improve Perl, no matter
# what the cost, or is this just a marketing exercise to draw
# in new users without scaring away the old ones?
#
# We have a wonderful new pattern matching language, with some
# really innovative ideas. It too is burdened by the beast of
# backwards compatibility. We're too worried about scaring
# people with change, so we provide these half-measure
# concessions to keep them happy.
Can you specify how? It looks to me like it's changed fairly
dramatically, but is still similar enough to be easy to adjust to.
# I feel like we're carrying around old luggage full of old and
# dirty clothes, and even when we pick up new suitcases and new
# clothes, we refuse to put down the old ones because they've
# been a part of our lives for so long. And so the burden gets
# heavier. The implementors have a tough enough job to do,
# dealing with a language which ended up being more difficult
# to parse and compile than Perl 5, not easier, and I suspect
# won't enjoy the extra baggage that's being forced upon them.
#
# So that's my warning: decide how innovative we're going to
# be. If we're really going to drive Perl forwards, let's not
# keep turning backwards, lest we end up as pillars of salt. If
# we're just giving Perl a spring clean, then maybe we've
# already gone too far. But let's not get stuck in the middle,
# doling out half measures all round.
Just because we're trying to make radical changes doesn't mean we can't
make a small sacrifice to the backwards-compatibility gods. After all,
it would be kinda nice if there were users besides p6* list members, and
I doubt it'll work without at least the small sacrifice of imperfect
emulation. (And I don't believe we're promising perfect emulation,
either--just "we'll try our best".)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: Half measures all round
Damian Conway:
# Schwern wrote:
#
# > For what it's worth, I'm looking forward to porting my
# 50-odd modules
# > to Perl 6. In a lot of cases, I'll finally be able to remove some
# > awful hacks.
#
# And I'll be porting most of my 30 or so (not the Perl6::
# ones, obviously).
#
# There. Nearly 3% of the CPAN ported in two fell swoops! ;-)
Why bother? You've already put P::RD and T::B effectively in the core!
;^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
blink: Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification
RE: regex and xml/html/*ml
[EMAIL PROTECTED]:
# Just read (skimmed) apocalypse 5, had one concern - it looks
# like we are on a serious collision course with parsing the
# various *mls.
#
# before:
#
# m#..etc#
#
# after
#
# m#\\\#
That's intentional. What will that regex do with this?
That's interpreted the same way, but typed a bit differently. It won't
match your regex.
The moral of the story is that you should not try to parse the *MLs with
regexen--use modules instead.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
A5: Is this right?
#Preliminary Perl6::Regex
# This does not have any actions, but otherwise I think is correct.
# Let me know if it's right or not.
use 6;
grammar Perl6::Regex {
rule metachar { <[<{(\[\])}>:*+?\\|]>}
rule ws { [<[\h\v]>|\#\N*]*}
rule atom { ( | \\ . | ) }
rule modifier { (<[*+?]> \?? \:?) }
rule molecule {
(
| \:<1,4>
|\|
)
}
rule compound { [()]* }
rule group{
( \( \)
| \[ \]
| \{ \}
| \< !? [ \w+ | \d+ , \d+ ] \>
)
}
}
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: A5: Is this right?
Larry Wall:
# On Fri, 7 Jun 2002, Damian Conway wrote:
#
# > Brent Dax wrote:
# >
# > > grammar Perl6::Regex {
# > > rule metachar { <[<{(\[\])}>:*+?\\|]>}
# > >
# > > rule ws { [<[\h\v]>|\#\N*]*}
# >
# > Or just:
# >
# > rule ws { [\s|\#\N*]* }
#
# Just as a practical matter, given that you tend to have runs
# of whitespace,
#
# rule ws { [ \s+ | \#\N* ]* }
#
# will probably run faster. At least, that would certainly run
# faster with Perl 5's engine. Can't speak for Perl 6's, of course.
Unless it backtracks. It would probably be better to have
rule ws { [ \s+: | \# \N*: ]* }
Unless I've misunderstood the meaning of the trailing colon.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
[PATCH PDD 7] Update type-naming conventions
Subject says it all. Updates conventions to be consistent with much of
the core. Unfortunately, that doesn't include 'struct Parrot_Interp'.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
Index: docs/pdds/pdd07_codingstd.pod
===
RCS file: /cvs/public/parrot/docs/pdds/pdd07_codingstd.pod,v
retrieving revision 1.5
diff -u -r1.5 pdd07_codingstd.pod
--- docs/pdds/pdd07_codingstd.pod 2 Apr 2002 07:08:43 -
1.5
+++ docs/pdds/pdd07_codingstd.pod 8 Jun 2002 00:04:50 -
@@ -391,7 +391,50 @@
=item *
-Variables and structure names should be all lower-case, eg C.
+Variables should be all lower-case.
+
+=item *
+
+Structures should have the following:
+
+=over 4
+
+=item *
+
+A structure definition with a name such as C.
+
+=item *
+
+A typedef of the form C. This should I be typedefed to a
pointer.
+(Note that some parts of the core are still using typedefs of the form
C;
+we're currently working on changing that.)
+
+=item *
+
+If the typedef is to be externally visible, a second typedef of the
form
+C is also necessary. For virtually all structs, this
should be
+typedefed to a pointer to the struct. If the struct is to be
externally
+visible, this (and a forward declaration of the C form) should
be the o
nly
+externally visible parts.
+
+=back
+
+A typedef of a built-in C type (like C or C) should
have the
+following forms:
+
+=over 4
+
+=item *
+
+A typedef of the form C. (Note that some parts of the core are
still using
+typedefs of the form C; we're currently working on changing
that.)
+
+=item *
+
+If the type is to be externally visible, a second typedef of the form
C.
+Often, the C form is defined in terms of the C
form.
+
+=back
=item *
RE: [NON-PATCH-DO-NOT-APPLY] PMC Up-To-Spec diffs
David M. Lloyd:
# NOTE: DO NOT APPLY THIS PATCH TO PARROT unless you like the
# smell of platforms burning. :-)
Er, what patch?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: [NON-PATCH-DO-NOT-APPLY] PMC Up-To-Spec diffs
David M. Lloyd:
# On Fri, 7 Jun 2002, Brent Dax wrote:
#
# > Er, what patch?
#
# It was attached because it is 214K. I could resend with it
# inline if nobody minds the large message body.
I don't think anybody minds an attached patch, but I didn't get the
attachment.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: [NON-PATCH-DO-NOT-APPLY] PMC Up-To-Spec diffs
David M. Lloyd:
# On Fri, 7 Jun 2002, Brent Dax wrote:
#
# > David M. Lloyd:
# > # On Fri, 7 Jun 2002, Brent Dax wrote:
# > #
# > # > Er, what patch?
# > #
# > # It was attached because it is 214K. I could resend with
# it # inline
# > if nobody minds the large message body.
# >
# > I don't think anybody minds an attached patch, but I didn't get the
# > attachment.
#
# Outlook users beware: Attachments sent using Pine (my mailer)
# tend to be somewhat invisible to you. They don't appear in
# the message list but they're there. You have to open up the
# message and (I think) click on the paperclip icon to get at
# them. Or something like that.
Double-click on the message and go to File | Save Attachments. Anyway,
the only thing that looks suspect to me is the whole s/BOOLVAL/INTVAL/g
thing.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: several changes committed (IO, miniparrot)
Josh Wilmes:
# I've been working on the beginnings of a miniparrot
# (something that can be
# built anywhere without the Configure step). The first step
# was to get
# configure to generate appropriate configuration files for an
# ANSI-only
# environment.
Looks excellent.
# To do this, I've added a --miniparrot option to Configure.pl.
# When used,
# this option causes Configure to disable to use of any gcc
# features, and to
# only make available those header files which are guaranteed
# by ANSI C89.
# Of these, 2 are not defined by ANSI C89:
# read (in core_ops.o,core_ops_prederef.o)
# write (in core_ops.o,core_ops_prederef.o)
#
# Pretty good!
Indeed. Those should probably be surrounded with ifdefs--does Configure
generate a HAS_HEADER for these?.
The only thing that jumped out at me were the direct calls to fprintf
with warnings--perhaps you should use the standard warnings mechanism
instead.
I'd suggest that your next steps include modifying
config/gen/config_h.pl to output a has_header.h with only ANSI headers
enabled. (Make sure that Configure tests for them in the first place,
though!)
The other thing I'd suggest is that we wrap mmap and munmap in
something. I think Windows has similar functionality through a
different API, so Parrot_map and Parrot_unmap might be in order.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: several changes committed (IO, miniparrot)
[EMAIL PROTECTED]:
# At 21:51 on 06/07/2002 PDT, "Brent Dax" <[EMAIL PROTECTED]> wrote:
#
# > # Of these, 2 are not defined by ANSI C89:
# > # read (in core_ops.o,core_ops_prederef.o)
# > # write (in core_ops.o,core_ops_prederef.o)
# > #=20
# > # Pretty good!
# >
# > Indeed. Those should probably be surrounded with ifdefs--does
# > Configure generate a HAS_HEADER for these?.
#
# Not sure- haven't looked at them yet.
#
# > The only thing that jumped out at me were the direct calls
# to fprintf
# > with warnings--perhaps you should use the standard warnings
# mechanism
# > instead.
#
# You're right- I meant to go back and fix those and totally forgot.
#
# > I'd suggest that your next steps include modifying
# > config/gen/config_h.pl to output a has_header.h with only
# ANSI headers
# > enabled. (Make sure that Configure tests for them in the
# first place,
# > though!)
#
# It's actually doing that already (it's in config/auto/headers.pl)
So you did. I kinda skipped past that. *smacks his forehead*
# > The other thing I'd suggest is that we wrap mmap and munmap in
# > something. I think Windows has similar functionality through a
# > different API, so Parrot_map and Parrot_unmap might be in order.
#
# Agreed. I'll take a look at that as well.
If you do that, I'd further suggest that on ANSI's Parrot_map you just
malloc() the memory and slurp the file in, then free() it in
Parrot_unmap. That way we never have to check to see if mmap or an
equivalent is actually available.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: several changes committed (IO, miniparrot)
Nicholas Clark:
# On Sat, Jun 08, 2002 at 01:39:56PM -0400, Dan Sugalski wrote:
# > At 12:55 AM -0400 6/8/02, Josh Wilmes wrote:
# > >
# > >Although I should mention that it's not verifying the presence of
# > >these
# > >headers- it just assumes they are available. It does that
# because the
# > >intent is to use this has_header.h for miniparrot, where
# we won't be doing
# > >any probing. The assumption is that if C89 says it will
# be there, it will
# > >be there, darn it.
# >
# > This is perfectly fine. We're assuming a minimum C89 level of ANSI
# > compiler compliance.
#
# hosted, or freestanding?
Hosted. Freestanding isn't complete enough to do anything with--you
don't even have file I/O. Besides, you'll most likely be
cross-compiling for WinCE.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: Apoc 5 questions/comments
Damian Conway:
# Richard Nuttall wrote:
# >
# > > I have no doubt that, once Perl 6 is available, we'll see
# a rash of
# > > modules released in the Grammar:: namespace. Including
# > > Grammar::Romana, Grammar::Klingon, Grammar::Buffy,
# Grammer::Mispelt,
# > > and others... :-)
# >
# > Grammar::Python, Grammar::Ruby, Grammar::PHP ?
#
# I should imagine that the first two at least would be very
# likely, given that we wish both of those languages to run on
# top of Parrot.
I have to wonder how the Ruby and Python people will feel about
implementing their interpreters in Perl... ;^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: lex behavior
Damian Conway:
# > I'm still unclear as to how you implement lex-like longest
# token rule
# > with P6 regexes. If the | operator grabs the first one it matches,
# > how do I match "bacamus" out of this?:
# >
# > "bacamus" =~ / b.*a | b.*s /
#
# Borrow this trick from Parse::RecDescent:
#
# rule max (*@candidates) {{
# my $best;
# my $startpos = .pos;
# for @candidates -> $next {
# .pos = $startpos;
# $best = $0 if /<$next>/ && $best &&
# $0.length < $best.length {
# }
# fail unless $best;
# let $0 := $best;
# .pos = $best.pos;
# }}
#
# then:
#
# "bacamus" =~ / /;
Will that handle captures correctly? Maybe you should temporize $0...
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: foobar syntax
Luke Palmer:
# I came across this problem when writing the vim syntax file:
#
# How can we tell the difference between these?:
#
# m:option(pattern)
# m:option(argument)/pattern/
The difference is that the first is a syntax error. :^) I think it
says that '(' is no longer a valid delimiter, and if you want a balanced
one '[' is usually ideal.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: Implementing Perl 6 (was Re: Implementing Parse::RecDescent directives)
Dan Sugalski:
# At 2:00 PM -0500 6/15/02, Jonathan Scott Duff wrote:
# >With all this new syntax, I can't wait until there's a perl6
# I can try
# >it out against rather than just perl6-language.
#
# Well, then, time to pitch in! :)
#
# Seriously, Parrot's at a state where a not inconsiderable chunk of
# perl 6 (and perl 5) can be implemented. We have scalars, arrays,
# hashes, simple I/O, and global variables. While there's some stuff we
# don't have yet (namely the specialized regex code, stream filters,
# lexicals, objects, and subroutines) we have more than enough to do
# much of perl 6. (Even regexes, if you don't mind doing it the slower
# way to start)
#
# We're looking for folks to work on the first cut perl 6 parser over
# on perl6-internals. All you need is a good knowledge of perl 5 (which
# is our first cut implementation language) and a willingness to dig
# through the Apocalypses and Exegeses. (Well, that and not minding the
# first version likely getting tossed out when we do the final
# implementation... :)
If we can use a real parser (Parse::Yapp, Parse::RecDescent), I'd love
to help. If not...well...it'll be Just Too Hard. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: vtables and multimethod dispatch
Nicholas Clark:
# On Wed, Jul 10, 2002 at 10:17:47AM -0700, John Porter wrote:
# >
# > Dan Sugalski wrote:
#
# > > Heh. I never expected to have to dust off my trig skills when I
# > > started this. If I need to dig out the calculus books, I
# think I'll
# > > just go run screaming...
# >
# > Not to worry. There's no trig involved. Just the Pythagorean
# > theorem.
#
# Unless I'm being thick, x² < y² whenever x < y for positive x
# and y (ie you don't need to take the square root of the
# hypotenuse to work out which hypotenuse is shorter. And all
# we're actually interested in which one is shorter, aren't we?)
Assuming x and y are integers, yes. Which'll probably be all we ever
deal with, so for all intents and purposes you're correct.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
Ashley Winters:
# 1. Why is test_main.c not named main.c?
Because parrot.exe was originally named test_prog.exe, so at the time it
made sense for it to be called test_main.c.
# 2. What does having a Parrot_ prefix signify, considering
# both the opcodes and
# the embed api use it? It's hard to distinguish between them.
It signifies one of the following:
-This function is externally visible.
-This function belongs to Parrot at large, and not any particular
subsystem (e.g. Parrot_sprintf and friends).
-This function has an identical name to a C library function because it
emulates it for certain platforms (e.g. Parrot_dlopen (?)).
-This function is autogenerated, so we're going to be paranoid about
naming conflicts.
For functions in the last category, I'd suggest we use
subsystem-specific names, e.g. Op_ for the opcodes.
# 3. What source files implement what docs?
It's a mess.
# 4. Where can I find out what embed.c is doing?
Try looking in my brain. :^) I'll see what I can do about documenting
it more thoroughly.
# 5. Why is parrot.c empty?
It was originally supposed to serve the role of test_main.c, but that
didn't ever happen for some reason. Ask Simon if you really want to
know.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: [PATCH] rx.dev
Stephen Rawls:
# I've only been involved with parrot since last week,
# but I've been learning quickly from all the
# documentation. With the recent activity about lack of
# documentation, I thought I'd try to help out as best I could.
# I've attached a file for an rx.dev candidate.
# Some parts may be wrong, and at some points I even ask
# questions, but there isn't much to rx.[ch], so overall it
# should be a decent rough draft. Below are my questions,
# copied right out of the attached document:
#
# 1) The rx_is_number_character function breaks the
# abstraction and uses the following expression to test
# the argument:
# if (ch >= '0' && ch <= '9')
# It explains that it is "faster to do
# less-than/greater-than"
# My question is: Doesn't this restrict the ability for
# adding different character encodings and languge
# support? What about languages that don't use arabic
# numerals?
It's a speed hack. I'm well aware that it won't work on some languages,
but I figured we can always change it later.
# 2) In the rxinfo struct:
# opcode_t *substfunc;
#
# My first guess was that that is a pointer to the first
# opcode the regex uses, but then I got confused by the
# name 'substfunc.' So basically ... what is it used
# for?
It's unused; originally I was planning to have the regex engine handle
substitutions (and you would pass in a label to call to get the
replacement string), but I changed my mind. Apparently that never
disappeared.
Overall, well done on the file--I think you explained bitmaps better
than I could have. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
John Porter:
# Brent Dax wrote:
# > > 2. What does having a Parrot_ prefix signify, considering
# > > both the opcodes and the embed api use it?
# >
# > It signifies one of the following:
# > -This function is externally visible.
# > -This function belongs to Parrot at large, and not any particular
# > subsystem (e.g. Parrot_sprintf and friends). -This function has an
# > identical name to a C library function because it emulates it for
# > certain platforms (e.g. Parrot_dlopen (?)). -This function is
# > autogenerated, so we're going to be paranoid about naming
# conflicts.
#
# Maybe I'm just being naive... but it seems to me that if
# there are four different meanings, there should be four
# different actual prefixes.
Well, let's go over the justifications for the first three meanings
having Parrot_...
-External visibility: This is something we want to have unequivocally
identified with Parrot. Also, we don't want unnecessary stuff added on
(which is why we don't want Parrot_extern_ or something).
-General functions: This is something that doesn't belong to any
particular category, so we don't want to prefix it and artificially
categorize it.
-C library wrappers: This is Parrot's version of the function, so it
makes sense to prefix it with Parrot_.
The third category I can see having a prefix of plat_ (for platform) or
some such, and perhaps the second could have misc_, but I foresee that
becoming annoying. (Which seems better to you, Parrot_sprintf or
misc_sprintf?)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
[EMAIL PROTECTED]:
# Good stuff. Didn't you also send out a draft PDD about how
# types should
# be named and managed in parrot at one point? I, for one,
At one point I sent out a patch to PDD7 that handled type naming.
# would love to
# see a PDD that described C-level nanming and namespace
# management in general.
I'd be happy to draw up guidelines if someone can tell me what they
should cover (naming of functions and data structures--anything else?)
and if people will read and review when I've finished it.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
Ashley Winters:
# On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > -C library wrappers: This is Parrot's version of the
# function, so it
# > makes sense to prefix it with Parrot_.
# >
# > The third category I can see having a prefix of plat_ (for
# platform)
# > or some such, and perhaps the second could have misc_, but
# I foresee
# > that becoming annoying. (Which seems better to you,
# Parrot_sprintf or
# > misc_sprintf?)
#
# c. parrot_sprintf
Lowercase is always the hallmark of struct names, i.e. parrot_string_t.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: Perl6 grammar (take V)
Deborah Ariel Pickett:
# [no longer sent to perl6-internals because it's not relevant there]
#
# I see a problem . . whether the problem's with me or the
# grammar, that's for you people to decide.
#
# Do I read this part of the grammar correctly?
#
# > sv_literal: /(?:\d+(?:\.\d+)?|\.\d+)(?:[Ee]-?\d+)?/
# > | '{' hv_seq '}'<
# > | '[' av_seq(?) ']'
# > |
# >
# > hv_seq:/,?/
# >
# > term: '<' expr(?) '>'
# > | subscriptable subscript(s?)
# > | /$CONTEXT/o term
# > | sv_literal <
# > | class
# > | closure<
#
# A "term" can be either a scalar literal ("sv_literal") (which
# might be a hash reference literal), or a closure (which might
# be a block).
#
# Both of those could be written "{ stuff }", for various
# values of stuff, but it looks like the current disambiguation
# rule is "if it's nothing but a sequence of "pair"s, then it's
# a hash ref, otherwise it's a closure.
#
# My perl5 sensibilities tell me that that's likely to cause a
# problem when I want to do something like this:
#
# $hashref = { function_returning_hash() };
#
# because I won't get the function's return values put into a
# hash, because the stuff inside the { ... } isn't a list of
# pairs. Instead I'll get a (reference to) a closure, not at
# all the same thing.
#
# Of course, in perl5, the requirement that "sub" prefix any
# closure-as-a-term nicely disambiguates that, but I understand
# that this is being phased out for perl6 (the grammar backs that up).
#
# How does perl6 distinguish between:
# $hashref = { function_returning_hash() };# call sub,
# get hash ref
# and
# $subref = { function_returning_hash() }; # make
# closure, don't call sub yet
# ?
When Perl can't disambiguate, you have to do it instead:
$hashref = hash { function_returning_hash() };
$subref = sub { function_returning_hash() };
Of course, there may be other ways for Perl to disambiguate--this one
comes to mind:
my HASH $hashref;
my CODE $subref;
As for the above grammar, I suspect that the is misplaced. It
should probably be allowed to fall through to the closure.
(Alternatively, always parse it as a closure and afterwards run through
the parse tree, checking all the closures and converting those that only
contain pairs.)
# (I hope the answer isn't "white space" . . )
#
#
# [Hi, I'm new around here, so I'll give you the three-line
# introduction. I teach Perl at Monash Uni, my office is in the
# same corridor as Damian's, and I like cats, chocolate, and
# curry. (Not all at once.) ]
Well, any friend of Damian's... :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
John Porter:
# Brent Dax wrote:
# > Ashley Winters:
# > > c. parrot_sprintf
# >
# > Lowercase is always the hallmark of struct names, i.e.
# > parrot_string_t.
#
# Ehhh... you yourself said something about plat_ and misc_
# as (theoretical) alternatives.
#
# Anyway, it's a silly rule. Upper-case (and lower-case) are
# going to have to do multiple duty.
Here's the rules, roughly as they stand right now:
-Functions start with Parrot_[a-z] or just [a-z].
-Typedefed names start with Parrot_[A-Z] or just [A-Z].
-Macros and constants start with PARROT_[A-Z] or just [A-Z].
-Struct names are of the form parrot_[a-z_]+_t.
Perhaps we should change the rules to this:
-Public functions start with Parrot_[a-z].
-Typedefed names start with Parrot_[A-Z] or just [A-Z].
-Macros and constants start with PARROT_[A-Z] or just [A-Z].
-Struct names are of the form parrot_[a-z_]+_t.
-Private functions start with parrot_[a-z] or just [a-z].
If people want that scheme, speak now or forever hold your peace. :^)
# Here's four:
#
# Parrot
# parrot
# _Parrot
# _parrot
#
# Here's two more:
#
# __Parrot
# __parrot
The last four are reserved by various C and C++ standards.
# Public API clearly should be Parrot. Any decisions regarding
# the rest should be for the benefit and convenience of us the
# developers. Right? Why make things harder for ourselves?
That means deciding what's harder and what's easier. Personally, I find
Parrot_ easier than plat_ to remember.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: Perl6 grammar (take V)
Ashley Winters:
# > You've got a point. There's an easy way to say "I want a sub":
# >
# > my $sub = -> { ... }
# >
# > But I can't think of a similarly punctuation-intensive way
# to say "I
# > want a hash." (someone please step in and correct me).
#
# I nominate:
#
# $() == scalar()
# %() == hash()
# @() == array()
#
# For the above function:
#
# $hashref = %(function_returning_list_which_needs_to_be_hashified());
#
# That would make %() a hash constructor, just like {}.
IIRC, $() and @() are already being used to denote scalar and array
context. Of course, an array or hash in scalar context would probably
referencify.
I'd suggest that $(), @(), and %() all be syntactic sugar for a
context() keyword:
$(foo) = context SCALAR : foo();
@(foo) = context ARRAY : foo();
%(foo) = context HASH: foo();
foo(); = context VOID: foo();
\foo() = context REF : foo();
foo()[0..5] = context ARRAY, 6: foo();
my MyClass $x=foo() = my MyClass $x=context MyClass : foo();
This context() keyword would be like the opposite of want(). Of course,
something like:
context $x: foo();
Might not work.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: PARROT QUESTIONS: Use the source, Luke
Paul Kienzle:
# On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote:
# > On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > > -C library wrappers: This is Parrot's version of the
# function, so
# > > it makes sense to prefix it with Parrot_.
# > >
# > > The third category I can see having a prefix of plat_
# (for platform)
# > > or some such, and perhaps the second could have misc_,
# but I foresee
# > > that becoming annoying. (Which seems better to you,
# Parrot_sprintf
# > > or
# > > misc_sprintf?)
# >
# > c. parrot_sprintf
#
# Why does Parrot need C library wrappers? For portability?
# If so, then for portability external applications should also
# use the wrapped functions, which
# means they are part of the Parrot API and so they should be
# prefixed with Parrot_.
If at some point in the future, we no longer need Parrot_time, I don't
think we should have to leave it in for backwards compatibility with
embedders. Perhaps we should export it *if they ask for it somehow*,
but not by default, and not in a way that implies that it'll always be
there till the end of time.
BTW, Parrot_sprintf is a reimplementation with extra features, not a
compatibility wrapper.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: hyper operators - appalling proposal
afolding code ordinarly clutters the actual work. I like
# being able
# > to write
# >
# > @defaults ^//= 1;
# >
# > don't you?
# >
# > -Erik
#
# @defaults = 1
Somehow, that seems wrong to me...
# > On Monday, July 15, 2002, at 01:52 PM, Aaron Sherman wrote:
# > Sure, that's always an option. I think Perl has a lot going
# for it other
# > than the way vectorization happens, and with the ability to
# define your
# > own array behavior, you can pretty much do this however you
# want anyway.
#
# Yes but it would be nuts to have PDL arrays do things one way
# and inbuilt
# compact arrays do things another way.
No, it wouldn't. PDL is supposed to be like the venerable language
Math. Math treats numbers and more complex objects (like matrices)
exactly the same (operator-wise). Therefore, PDL should treat numbers
and more complex objects exactly the same (operator-wise).
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
Deborah Ariel Pickett:
# > > ..., and someone pointed out that it had a problem
# > > with code like "{ some_function_returning_a_hash()
# }". Should it give a
# > > closure? Or a hash ref? ...
# > Oh, well now that it's stated this way... (something went
# wrong in my
# > brain when I read the actual message) It returns a closure
# :(. A4 says
# > that as a term, { } define a closure, unless it contains a pair
# > constructor at the top level. But, thanks to Perl 6's
# smartness, that would
# > be excessive syntax anyway:
# > $hashref = some_function_returning_a_hash()
# > would do what you wanted.
#
# Would it always? What if I had two functions (or more), all returning
# part of the hash I want to package up? Can I do:
# $hashref = some_function_returning_a_hash(),
# some_other_function_returning_more_of_the_hash();
# and get the result of both functions into the anonymous hash?
Not directly--just use the hash {} constructor.
# Besides, does
# $hashref = some_function_returning_a_hash()
# make $hashref simply refer to the result of the function, or does it
# make $hashref refer to a hash containing a *copy* of the result of the
# function? If Perl6 is going to do fancy things with
# functions returning
# lvalues, which looks like the case, those two things aren't
# necessarily
# the same thing.
#
# Or, saying the same thing another way, does this:
# $href = %hash;
# which I presume will be legal Perl6, mean the same as this Perl5:
# $href = \%hash;#A
# or this Perl5:
# $href = { %hash }; #B
# and how would I say each of A and B in Perl6 unambiguously?
A. And unambiguously:
$href = \%hash; #A
$href = hash { %hash }; #B
# Automatic referencing and dereferencing is all well and good, and it
# appears that it's here to stay in Perl6 (it's been in most
# Apocalypses),
# but I don't think anyone's actually sat down yet to thrash out exactly
# under what circumstances it happens.
Autodereferencing happens whenever we have a scalar but we need an array
or hash; autoreferencing happens whenever we have an array or hash but
need a scalar (usually because of scalar assignment, but not
necessarily).
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: Grammar ambiguities again (was: Perl 6 Summary for week ending 20020714)
David Whipp:
# Brent Dax wrote:
# > $href = hash { %hash }; #B
#
# Why the curlies? if C is a function (ctor), then surely
# these should be parentheses. In this context, parentheses are
# optional, so this could be written
#
#$href = hash %hash;
C is not a function. It's a keyword, analogous to C.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
Quick Perl 6 regex question
I was reading through the Monastery, and I noticed a node (about the
line between what's considered Perl discussion and what's off-topic)
that had this regex in it:
m:iw/how [do[es]?|can] [I|one] @tasks in @non_perl_languages/
(Yes, people are already using Perl 6 regexes in text. :^) ) Reading
this, I noticed a potential problem in :w.
To put it simply, what do these expand to?
m:w/foo [~|bar]/
m:w/[~|bar] foo/
m:w/[~|bar] [^|baz]/
m:w/@foo @bar/
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
RE: [PATCH] MANIFEST update
There should be no Makefile.in's left in the source--they've been tossed
in favor of config/gen/makefiles.
Andy Dougherty:
# --- parrot-cvs/MANIFEST Sat Jul 13 13:04:15 2002
# +++ parrot-andy/MANIFEST Wed Jul 17 11:46:50 2002
# @@ -12,16 +12,15 @@
# VERSION
# assemble.pl
# byteorder.c
# +byteorder.dev
# chartype.c
# chartypes/unicode.c
# chartypes/usascii.c
# classes/array.pmc
# +classes/coroutine.pmc
# classes/default.pmc
# classes/genclass.pl
# classes/intqueue.pmc
# -classes/coroutine.pmc
# -classes/pointer.pmc
# -classes/sub.pmc
# classes/perlarray.pmc
# classes/perlhash.pmc
# classes/perlint.pmc
# @@ -29,6 +28,8 @@
# classes/perlstring.pmc
# classes/perlundef.pmc
# classes/pmc2c.pl
# +classes/pointer.pmc
# +classes/sub.pmc
# config/auto/byteorder.pl
# config/auto/byteorder/test_c.in
# config/auto/cgoto.pl
# @@ -85,6 +86,8 @@
# debug.ops
# disassemble.c
# disassemble.pl
# +docs/Makefile.in <-- should be gone
# +docs/a5_draft.html
# docs/embed.pod
# docs/faq.pod
# docs/glossary.pod
# @@ -232,6 +235,7 @@
# languages/BASIC/stackops.pasm
# languages/BASIC/tokenize.pasm
# languages/BASIC/wumpus.bas
# +languages/Makefile.in<-- should be gone
# languages/cola/MAINTAINER
# languages/cola/Makefile
# languages/cola/README
# @@ -271,6 +275,7 @@
# languages/imcc/symreg.c
# languages/imcc/symreg.h
# languages/jako/MAINTAINER
# +languages/jako/Makefile.in <-- should be gone
# languages/jako/bench.jako
# languages/jako/euclid.jako
# languages/jako/fact.jako
# @@ -284,6 +289,7 @@
# languages/jako/primes.jako
# languages/jako/queens.jako
# languages/jako/sub.jako
# +languages/miniperl/Makefile.in <-- should be gone
# languages/miniperl/Miniperl.pm
# languages/miniperl/Miniperl/Generator.pm
# languages/miniperl/Miniperl/Makefile.PL
# @@ -298,6 +304,30 @@
# languages/parrot_compiler/gentable.pl
# languages/parrot_compiler/parrot.pasm
# languages/parrot_compiler/sample.pasm
# +languages/perl6/MANIFEST
# +languages/perl6/P6C/Addcontext.pm
# +languages/perl6/P6C/Builtins.pm
# +languages/perl6/P6C/Context.pm
# +languages/perl6/P6C/IMCC.pm
# +languages/perl6/P6C/Nodes.pm
# +languages/perl6/P6C/Parser.pm
# languages/perl6/P6C/TestCompiler.pm
# +languages/perl6/P6C/Tree.pm
# +languages/perl6/P6C/Util.pm
# +languages/perl6/README
# +languages/perl6/mkdistro.sh
# +languages/perl6/prd-perl6.pl
# +languages/perl6/t/compiler/1.t
# +languages/perl6/t/compiler/2.t
# +languages/perl6/t/compiler/3.t
# +languages/perl6/t/compiler/4.t
# +languages/perl6/t/parser/P6CTest.pm
# +languages/perl6/t/parser/README
# +languages/perl6/t/parser/basic.t
# +languages/perl6/t/parser/exe2.t
# +languages/perl6/t/parser/exe3.t
# +languages/perl6/t/parser/exe4.t
# +languages/perl6/t/parser/similar.t
# languages/regex/MAINTAINER
# languages/regex/Makefile
# languages/regex/README
# @@ -331,6 +361,7 @@
# languages/regex/t/star.t
# languages/regex/t/staralt.t
# languages/regex/test.pl
# +languages/scheme/Makefile.in <-- should be gone
# languages/scheme/Scheme.pm
# languages/scheme/Scheme/Generator.pm
# languages/scheme/Scheme/Parser.pm
# @@ -393,6 +424,7 @@
# resources.c
# runops_cores.c
# rx.c
# +rx.dev
# rx.ops
# rxstacks.c
# stacks.c
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
