Re: Premature pessimization
On Sun, 5 Dec 2004 11:46:24 -0700, Luke Palmer <[EMAIL PROTECTED]> wrote: > Leopold Toetsch writes: > > This term came up in a recent discussion[1]. But I'd like to give this > > term a second meaning. > > Except what you're talking about here is premature *optimzation*. > You're expecting certain forms of the opcodes to be slow (that's the > pessimization part), but then you're acutally using opcodes that you > think can be made faster. This is a classic Knuth example. So the sequence of using classoffset/getattribute is a _feature_ necessary for completeness, rather than a "pessimization" to compensate for the belief that not explicitly caching would be hopelessly slow? Ahh. I'm learning much. :) Ashley Winters
Re: RFC - Hashing PMC's
On Tuesday 23 July 2002 08:44 am, Alberto Manuel Brandão Simões wrote:
> On Tue, 2002-07-23 at 09:27, Ashley Winters wrote:
> > @foo = ();
> > %hash{@foo} = 10;
> > push @foo, 'This would change the hash key for @foo?';
> >
> > print "ok 1" if exists %hash{ [] };
> > print "ok 2" if exists %hash{ ['This would change the hash key for
> > @foo?'] }; print "ok 3" if exists %hash{@foo};
> >
> > What's going to get printed from that?
>
> IMHO, it should print 'ok 1'. The idea of the hash function is to use
> PMC's as hash keys. That means that different content PMC (as an array
> with different elements) must return different hash keys.
I can see the argument both ways, but I have a proposal.
@foo = (1 .. 100);
%hash{@foo} = "reference";
%hash{@foo.freeze} = "contents";
%hash{@foo} eq "reference";
%hash{[1..100].freeze} eq "contents";
I'm just using "freeze" as the serialization routine until a real name is
determined. If I need a "unique" key for hashing based on aggregate content,
can I ass_u_me the builtin Perl6/Python/etc serialization mechanism will
suffice?
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: RFC - Hashing PMC's
On Tuesday 23 July 2002 08:27 am, Ashley Winters wrote:
> push @foo, 'This would change the hash key for @foo?';
>
> print "ok 1" if exists %hash{ [] };
> print "ok 2" if exists %hash{ [10] };
Err, I meant:
print "ok 2" if exists %hash{ ['This would change the hash key for @foo?'] };
Also, the same question would apply if I simply changed the value of an
element in @foo instead of changing the number of elements.
Re: RFC - Hashing PMC's
On Tuesday 23 July 2002 07:47 am, Alberto Manuel Brandão Simões wrote:
> Now, I ask for PMC programmers to take care implementing this! Notice
> that, for example in arrays, arrays with the same length but different
> elements should return different hash codes (or try). But for the same
> elements MUST return the same hash code.
@foo = ();
%hash{@foo} = 10;
push @foo, 'This would change the hash key for @foo?';
print "ok 1" if exists %hash{ [] };
print "ok 2" if exists %hash{ [10] };
print "ok 3" if exists %hash{@foo};
What's going to get printed from that?
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: PARROT QUESTIONS: Keyed access
On Sunday 21 July 2002 06:46 pm, Scott Walters wrote: > 2. PMCs return iterators allocated on a stack that allow them to function > as KEY *s allocating a single fixed size peice of memory rather than all of > the parts of a linked list. In other words, factor out the part of PMCs > that index a given element. This would completely bypass the construction > of KEY* lists, and allow PMCs to function as keys. This case needs to be > optimised, as most keys will be scalars or a few scalars, and quickly > moving from a scalar to a key should be paramount. > 3. Let PMCs create KEY * lists. Whats more, rather than scraping KEY * >lists of an adequate size and replacing them every iteration in user > code loops, *update* the KEY* list from PMCs. Eg, if $x is the first item, > $y is the second, and $z is the third, update the values in the KEY* with > the new values from the scalars, then shuffle the same KEY * off again. Use > a load/store strategy! The complexity involved in exposing every single > method in a contained object damages cache use beyond *any* possible > benefit! See earlier post for details. Not to beat a dead horse, but I like the concept. However, rather than using the KEY* linked list, use a tuple. They would be constant size, so we could allocate them on the stack. They would iterate nicely without thrashing memory. No malloc(), so we could keep the main KEY* functionality without adding a special-purpose key pmc, and we'd get a *fast* generic Tuple PMC class out of it. Ashley (by committee) Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: PARROT QUESTIONS: Use the source, Luke
On Tuesday 16 July 2002 01:02 am, Melvin Smith wrote: > >It's also unnecessary. It isn't like there aren't perfectly good > >alternatives--what's wrong with "Parrot__"? > > Well, what's wrong with Parrot_ ? There's nothing wrong with Parrot_ -- as long as it isn't used *everywhere*. A good thing used in excess is bad, and all that mumbo jumbo. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
PARROT QUESTIONS: The PDDs
ry gets marked while I need it? Question: Is the GC really implemented in resources.c? It's a non-obvious name, and the top-of-file comment doesn't say so. Okay, that's all of the PDDs. I learned quite a bit from them, hopefully some of it was accurate & useful. :) Discuss. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: PARROT QUESTIONS: Use the source, Luke
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 Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: PARROT QUESTIONS: Use the source, Luke
Hrm, I had intended to put my questions at the end. I hit Send early. Questions: 1. Why is test_main.c not named 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. 3. What source files implement what docs? 4. Where can I find out what embed.c is doing? 5. Why is parrot.c empty? Ashley Winters
PARROT QUESTIONS: Use the source, Luke
I'm trying to pay attention to the difficulties I have understanding parrot so
I can give some decent n00b feedback before I know the code like the back of
my hand.
First, test_main.c is a totally non-obvious location for parrot.exe's main().
I dismissed it out of hand when I did grep ^main. I only believed it was real
when I looked at the linker arguments. Is there a reason for the test_
prefix? It's really misleading if you're actually using it.
I'm also a little disturbed by *everything* having Parrot_ in front of it.
Namespace friendliness is nice, but having the internal functions with the
same prefix as the embed.c functions is unkind. I'd like to see _Parrot_ or
Parrot__ for the internal functions (hell, just the opcodes) and Parrot_
reserved for the visible API. _Parrot_ would be better, since source grepping
for ^Parrot wouldn't list them. Grepping for ^Parrot_new (the first function
called in main(), and the first function anyone reading from the top would
search for) was painful.
There's no pointers between source and documentation. embed.c is a direct
implementation of embed.pod, but neither mentions the other. Any place
documentation and implementation exist, they should point to each other.
Until the documentation is good enough that you don't need to look at the
source to see how to use it, the documentation needs to give the location of
the source. :)
test_main.c and embed.c have no comments. They are the starting-point of the
parrot interpreter but there's no guidance as to where to go from there. In
the case of embed.c, I would definitely like to see each function specify
what files their implementation can be found. A gushing amount of inline
documentation would be good too, but even as little as this:
struct Parrot_Interp *
Parrot_new(void)
{
if (!world_inited) {
world_inited = 1;
init_world(); /* global_setup.c */
}
return make_interpreter(NO_FLAGS); /* interpreter.c */
}
I had to cut&paste&grep the source countless times to find anything.
A pointer from test_main.c to embed.c and embed.pod would've been helpful as
well.
What the heck is parrot.c doing empty? I expected it to have... something. I
don't know. Being empty is Wrong. I would've expected the functions which are
actually in embed.c to be in there ala. perl5's perl.c at least. If it's not
going to have source, it definitely needs a comment saying "this is not the
file you are looking for, see test_main.c and embed.c".
I think that's all for today,
Ashley Winters
--
When you do the community's rewrite, try to remember most of us are idiots.
Re: Parrot contribution
On Saturday 13 July 2002 07:39 am, Sean O'Rourke wrote: > To help even more, you could collect the answers to these questions when > you receive them, and make the resulting FAQ part of your contribution to > Parrot. Write the FAQ you wish had existed when you first came. I would find that handy. I'm sure the answers would be enlightening. How much "why?" can this list handle, anyways? If I subscribe to the CVS commit list and start asking you folks for explanations of the interesting, undocumented patches, would you answer my questions if I submitted doc patches with the answers? I haven't even compiled Parrot before, so you'd be getting genuine n00b questions. Be warned. Is there a complete description, or even listing, of command-line switches outside of parrot -h or whatever? running.pod doesn't quite do it for me. Ashley Winters -- When you do the community's rewrite, try to remember most of us are idiots.
Re: Mutable vs immutable strings
On Wednesday 10 July 2002 08:18 pm, Melvin Smith wrote:
> I was referring to the above situation where a lexical might be optimized
> away without being stored in a pad (for %MY).
I would *hope* %MY is only modified at compile-time. I wouldn'd be upset if
Perl ignored my attempts to access %MY at runtime.
As for eval, if I ever need a CS master's thesis subject, I could always try
this...
Whenever the compiler runs across an eval, take a continuation from within the
compiler. Make sure the compiler keeps enough state in lexicals to start
where it leaves off. At runtime when the eval is reached, save the current
continuation and hop over to the compile-time continuation and try compiling
it in-place as a sub. It would be necessary to treat any lexicals used inside
the eval"" as arguments to the sub -- otherwise usage of those lexicals
inside the sub might change the optimization of those scalars and you
wouldn't be able to call the continuation back to the runtime eval and have
it work. Then, fiddle with the newly compiled bytecode and find the address
of the eval continuation location we jumped from, and go back there.
for 1..1000 -> int $i { # $i is optimized away in a nice register
my $str = '$i + 1';# assume this isn't constant voodoo'd away
#eval $str;# at runtime, this could mean:
my $compiletime_cont;
my $runtime_cont;
BEGIN {
$compiletime_cont = take_continuation();
if caller(0).continued { # just guessing at a flag
# this block is actually called at _runtime_
# this should morph the else clause bytecode below
Perl6::compile_for_eval($str, $runtime_cont);
invoke($runtime_cont);
}
}
$runtime_cont = take_continuation();
unless caller(0).continued {
invoke($compiletime_cont);
} else {
# this code is modified/generated/whatever by compile_for_eval above
my sub &eval_expression = sub ($i) { $i + 1 }
eval_expression($i);
# I decided $(-> $i { $i + 1 }).($i) was too obfuscated. You're welcome
}
}
Wouldn't it be great to have something so incredibly slow? Code morphing is so
80's! Okay, I've had my headache-inducing thought for the evening.
Yes, my Scheme interpreter written in Perl6 is coming along nicely. Muahaha!
(kidding, obviously)
Ashley Winters
Re: Mutable vs immutable strings
On Wednesday 10 July 2002 02:39 pm, Melvin Smith wrote:
>
> Since Perl vars type-morph themselves, Perl will use PMC types everywhere
> that there is an exposed interface. Internally you could use an I/S/N
> register.
>
> I see no reason why
>
> foreach my $i (@nums) {
> ...
> }
>
> should not use an Ix reg for $i, but maybe $i isn't an int at all, or @nums
> is actually a mixed list.
I thought that was the whole point of typing in Perl 6.
my int @nums = (1, "2", 3.1); # (1,2,3) assuming C 'works'
for @nums -> $i {} # $i is a PMC, still
for @nums -> int $i {} # $i is in an Ix register now
for @nums {}# will $_ be smart enough to 'int' itself? I hope so
Yes, people will have to think about optimizing their code. It's not great,
but it's not that onerous. It might be nice if the current topic would type
itself based on its initializer, when obvious.
Ashley Winters
Re: Perl 6 grammar progress?
On Sunday 30 June 2002 09:09 pm, Sean O'Rourke wrote:
> On Sun, 30 Jun 2002, Ashley Winters wrote:
> > I don't know how the grammars are going, and I'm not fit to write one
> > myself,
>
> Hey, neither am I, but that hasn't stopped me from taking a stab or two,
> figuring that through pain comes fitness. The attempt has certainly given
> me a much better understanding of Perl (both 5 and 6) than I had before as
> a mere user. If there's anyone else out there with the time for and
> interest in working on a Parse::RecDescent grammar, feel free to speak up.
I don't want to do it in Parse::RecDescent, I want to do it in
Parse::FastDescent! Too bad it's not written yet... Damian?
>
> Neither am I, but we might as well throw in @{foo}, %{foo}, &{foo}, maybe
> even $*{foo} (global symbolic reference?).
$*{foo} was in there, at least. I'm still not quite diabolical to come up with
the really screw-your-parser-up kind of stuff. ${"}"} and such come to mind,
assuming that's legal.
Also, where does $() come in? Is statement scalarification ever useful outside
a string?
>
> > # Also, there are globals to consider
> > [...]
>
> And the wonderous *@$*foo (flattened dereferenced global $foo?).
I didn't do any sigil stacking at all in there, just context characters. I
don't think there will be much sigil stacking, if any, beyond just stacking
$'s to dereference scalar refs.
>
> > # off the subject, but lets make sure $foo.. is parsed correctly
> > $foo..1;
> >
> > $foo..[1];
> > $.foo..{1};
>
> Color me slow, but are these even legal? What does an anonymous list
> constructor do on the LHS of a range operator? I suppose it could just be
> one example of something that is always true, but could it possibly be
> useful other than by the perversity of overloading ".."? And would the
> second require whitespace before the '{' to be parsed as a closure/block?
Well, perhaps PDL will have a reason to overload .. that way. There's no
reason for the parser to choke on it by default - the compiler certainly
should, though.
As for .{}, that's an interesting thing to ponder. From the apocalypse, it
says a { found where an operator is expected without preceding whitespace
would be considered a subscript. Since '.' or '..' is the operator, the next
brace would *normally* start a hash constructor or sub. I would guess '.'
forces the next opening brace to start a subscript, but without the
whitespace rule.
$foo . { $x + 10 }# really means $foo{$x + 10};
Or maybe using binary . in this fashion is Bad?
> > @foo{1}; # I ass_u_me {} [] and () can be overloaded?
>
> Blech! Even if it's legal, this seems like it should be a mandatory smack
> upside the head. If we allow this, someone will overload {} to do hash
> slices on %foo, and we'll be right back to Perl 5 ;).
Well it's unambiguous, so I expect someone out there will try to be funky.
>
> > @foo(1);
> > @foo();
>
> Strange overloading again, or am I missing something? If we allow
> subscripting and calling to be overloaded on variables with any kind of
> sigil, what's the point of having sigils at all?
There isn't much of a 'point' anymore except overlapping variable names. I
would guess the p52p6 translator could do something silly like this:
#!/usr/bin/perl5
@x = (500..800);
$y = $x[rand($#x)];
#!/usr/bin/perl6
$x_array := @x_array;
@x_array = (500..800);
$y_scalar = $x_array[rand($x_array.length)];
The Highlander RFC (009) suggested making @x %x and &x all mean $x, and Larry
liked the idea in general, but he wanted to keep them separate because people
were used to it that way. Since $foo can be subscripted in all ways, I can
see how other people might want to subscript @% as well. If someone were
particularly perverted, they could make subscripts on &foo have reflective
consequences. *shrug*
> > foo{1}; # foo is unary here
>
> Is this a hash subscript on a no-argument function returning a hash, or a
> block passed to foo(&block), or a malformed hash constructor being passed
> to foo(%hash)? I vote for the first, because I thought blocks' and
> hashes' opening brackets always needed preceding whitespace (or at least
> /(? ${ foo() }{1}
foo.{1} => ${ foo() }{1}
foo {1} => foo(sub {1});
foo {a => 1} => foo(hash(a => 1));
> > foo.(); # Is this &{ foo() }() or foo()? I would vote former
>
> aka foo()()? Sick...
Hey, it has to mean something.
> > # As a final sanity check, lets chain these things
> >
> > @.proc[$*PID].ps.{RSS};
>
> == "@{.proc()[$*PID].ps().{RSS}}&qu
Re: Perl 6 grammar progress?
On Sunday 30 June 2002 12:46 pm, Dan Sugalski wrote:
> So, it's been a week or so and, while I'm mostly offline until
> wednesday, I'll ask the question...
>
> How's the work on the perl 6 grammar going? We any further along than
> we were before YAPC?
I don't know how the grammars are going, and I'm not fit to write one myself,
but I wrote a list of variables I'll try to parse using any grammars which go
by. Are all of these legal? I suppose that's more of a -language question.
Ashley Winters
# Variable access you will want to parse
# standard variables
$foo;
@foo;
%foo;
&foo;
# need more tests for ${}, I'm not evil enough for it
${foo};
# Apocalypse 3 specifies context characters
*@foo;
$@foo;
&@foo;
*%foo;
*@{foo};# sanity check
# Also, there are globals to consider
$*foo;
@*foo;
%*foo;
&*foo;
$*{foo};
*@*foo;
$@*foo;
&@*foo;
*%*foo;
# not to mention members
$.foo;
@.foo;
%.foo;
&.foo;
$.{foo};
*@.foo;
$@.foo;
&@.foo;
*%.foo;
# lets test packages at least once
$foo::bar;
@foo::bar::baz;
%foo::bar::baz::blurfl;
&foo::bar::baz::blurfl::aybabtu;
# Now, the hard part. Element access
$foo{1};
$foo[1];
$foo(1);
$foo();
$foo.{1};
$foo.[1];
$foo.(1);
$foo.();
# off the subject, but lets make sure $foo.. is parsed correctly
$foo..1;
$foo..[1];
$.foo..{1};
$foo..(1);
$foo..<$*STDIN>;# perfectly legal
$foo...bar; # $foo .. .bar, since there's no binary ...
@foo{1}; # I ass_u_me {} [] and () can be overloaded?
@foo[1];
@foo(1);
@foo();
@.foo{1};
@.foo[1];
@.foo(1);
@.foo();
@foo.{1};
@foo.[1];
@foo.(1);
@foo.();
@.foo.{1};
@.foo.[1];
@.foo.(1);
@.foo.();
# I will just assume if the parser made it this far, <[%$&]> also work
foo{1}; # foo is unary here
foo[1];
foo();
foo.{1};
foo.[1];
foo.(); # Is this &{ foo() }() or foo()? I would vote former
.foo{1};
.foo[1];
.foo();
.foo.{1};
.foo.[1];
.foo.();
# As a final sanity check, lets chain these things
@.proc[$*PID].ps.{RSS};
@proc.[$*PID].ps().{RSS};
# And, just to make sure your parser doesn't pass this suite...
$foo{"Do you want to try $interpolated{"string"}?"};
# Okay, I've had my fun
RE: parrot rx engine
--- Brent Dax <[EMAIL PROTECTED]> wrote: > Tim Bunce: > # On Thu, Jan 31, 2002 at 05:15:49PM +, Graham Barr wrote: > # > # Especially as the perl6 rx engine will have to be able to > # work directly on > # non-trivial things like streams and generators ans suchlike. > > I have a suggestion similar to the ops suggestion but more flexible: > Regex vtables. > > We'd probably need three: > > -normal text match > -case-folded text match > -generic sequence match (the stuff Larry's been talking about) Hmm... based on what I've read in Larry's message and the unicode spec, some of this could be spirited away into a customizable and/or chained unicode string iterator. For instance, it (the iterator) could return case-folded (or not) characters, it could convert "" pairs into Ps/Pe quote pairs (for code parsers) and remove comments (yay), and it could return locale-based graphemes (I'm scared). Since graphemes at least will be multi-character in some locales, I see how my objection to rx_literal was a Bad Thing. And I expect to be able to write a grapheme-sending unicode string iterator and plug it into a regex and have it DWIM in my Distant $future, right? Perhaps the backtracking mechanism should be *in* the iterator? Maybe the iterator will be the home of some locale evil? Could we make it handle locale character-ranges [a-o'] too? Okay, that last one's a bit much. Still, Larry did mention that business with generalized backtracking and bookkeeping... I can't wait for Apocalypse 5. Is there a custom iterator syntax/convention in parrot? I hope I don't give Larry any *new* scary ideas for the next apocalypse. This is just for entertainment purposes, after all . Ashley the Zealot __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
parrot rx engine
lse {
$r.popindex or last; # backtrack or start over
}
}
# /[cd]+/
loop {
NEXT { $r.next_code_point or last }
given $r.current_code_point {
when U+43, U+44, U+63, U+64 {}
# since a switch is actually executed in order, the
# optimizer can not only merge sequential codepoints,
# it can order the comparisons to make the most likely
# matches (ascii) be tested first, and for oddball
# "equivalent" character comparisons be done later.
#
# just showing what the optimizer might do with /[a-z]/i
#if U+41 <= $_ <= U+5A or U+61 <= $_ <= U+7A {}
default { last }
}
}
}
}
return false;
}
match("xxabbBBcdcdcdzz");
__END__
Am I fool, or an idiot? Discuss.
Mostly, I'd like to hear how either Unicode character-ranges aren't
deterministic at compile-time (I doubt that) or how crippling to
performance this would be (and by implication how slow parrot will be)
in either time or space.
Ashley Winters
__
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
