At 09:51 PM 9/8/2001 -0700, Dave Storrs wrote:
>On Sat, 8 Sep 2001, Uri Guttman wrote:
>
> > >>>>> "BW" == Brian Wheeler <[EMAIL PROTECTED]> writes:
> > BW> =item eqv tx, ty, tz *
> >
> > BW> Bitwise Equivalence all bits in y with z and store the result in
> > BW> register x.
> >
> > that is just !(y xor z). we can provide the op but perl as we know it
> > has no operator that will map to it. maybe another front end would want
> > it so let's have it. it is trivial to code up and won't take any space.
>
>
> I feel very uncomfortable about speaking up in opposition to a
>much more experienced person, but I'd like to register a vote against this
>idea.
I'm glad you did. I really don't want people to stifle dissent just because
of an air of authority and/or experience that might be perceived around
someone.
>The whole reason that we're building Perl6 in the first place is
>because there is a lot of nasty cruft in Perl5.
True, but the cruft isn't actually in the list of opcodes itself in perl 5.
Rather it's inside the functions for those opcodes. (Amongst other places)
A large list of opcodes isn't itself a big problem if they're organized in
a way that makes them straightforward to deal with. (Having a couple dozen
fancy math opcodes isn't a problem here--they can be lumped together
conceptually as "That big lump of opcodes from 150-187" if you don't need
to deal with 'em)
>We are working towards
>creating something clean and elegant; let's not start out by putting
>things in just because they are "trivial to code" when we don't have a use
>for them.
Well, we do have a use for them. The math folks are one of our new target
audiences, and I'd really like to roll as much of what PDL does as feasable
into the core. Also there's the possibility (albeit remote) that perl will
at some point handle deferred evaluation of expressions, in which case
having these handy (more to the point making perl aware of them) will make
reducing the expressions correctly later easier.
FWIW, clean and elegant is somewhere under "fast" on the big list 'o goals.
This:
@foo = tan @bar;
should be faster than:
foreach (0..$#bar) {
push @foo, sin $bar[$_]/cos $bar[$_];
}
by rather a lot. (Unless tan's cos/sin, in which case it's both faster and
more correct... :)
> In general, I would like to see the policy be "unless there is a
>clear and demonstrated need, we don't do it." Let's just make the engine
>easy enough to change that, as we discover things we didn't know we
>needed, we can go back and add them in later.
That policy is in effect in general, just not necessarily in the areas you
might think.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
