>>>>> "DS" == Dave Storrs <[EMAIL PROTECTED]> writes:

  DS> 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.


  DS>   I feel very uncomfortable about speaking up in opposition to a
  DS> much more experienced person, but I'd like to register a vote
  DS> against this idea.  The whole reason that we're building Perl6 in
  DS> the first place is because there is a lot of nasty cruft in Perl5.
  DS> We are working towards creating something clean and elegant; let's
  DS> not start out by putting things in just because they are "trivial
  DS> to code" when we don't have a use for them.

this is not clutter. it is just another short entry in the op code table
and a short c sub to do the work. pretty much all the math op are just
wrappers or simple and common variants of the math funcs. since parrot
will be supporting multiple languages, the math lib can have all of
those ops already. then the lang to parrot code generator can be more
efficient and simpler. the need for the variant ops will happen even if
perl6 lang doesn't use them.

  DS>   In general, I would like to see the policy be "unless there is a
  DS> clear and demonstrated need, we don't do it."  Let's just make the
  DS> engine easy enough to change that, as we discover things we didn't
  DS> know we needed, we can go back and add them in later.

this is not the engine, but the math lib. it will just be a set of c
subs with autogenerated op code wrappers. there will be an op code table
as well. there will not be any (or much) real math work in this module
as it will all be done in the system c math library. we can easily add
in ops to the math lib later but there is no penalty (even cruft) to
support more wrapper variants now. these subs should absolutely never
change once (correctly) written as they are just wrappers.

uri

-- 
Uri Guttman  ---------  [EMAIL PROTECTED]  ----------  http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs  --------------------------  http://jobs.perl.org

Reply via email to