Ops Review

[Bob Rogers]

   From: Andrew Whitworth <wknight8111 at gmail.com>
   Date: Mon, 19 Jan 2009 19:06:32 -0500

   On Mon, Jan 19, 2009 at 5:13 PM, Bob Rogers
   <rogers-perl6 at rgrjr.dyndns.org> wrote:
   > Do you think that would be fast enough?  The usual way for dynamic
   > languages to get fast compiled numeric code is to bind variables to
   > hardware types at compile time, and then inline numeric operations in
   > order to use that information.  That seems to require op_i_i_i and
   > op_n_n_n versions of these ops, which are not language-dependent.

   Consider also that these operations could be rolled into dynops or
   dynpmcs, if we want the speed of native compiled code, but don't want
   to clutter Parrot core with all sorts of numerical functions.

A Parrot-provided dynop library for math would be fine . . .

   We could always find one more mathematical function, or one more
   algorithm that somebody would like to have turned into an op.

Possibly true, but not wholly relevant; we were talking about what to
take out, not what to put in.

   We shouldn't feel the need to add them all (or keep them all) in
   Parrot core.

   --Andrew Whitworth

. . . but as those dynamic math ops would likely be needed for generic
Common Lisp math functions, Kea-CL would probably always want to load
them with its own language core.  I suspect that is true for most
languages.  If so, then that weakens the argument for keeping them out
of Parrot core.  (Though I admit that the added cost of including them
as dynops ought to be small.)

   It sounds like the design philosophy is shifting from "might as well
include the kitchen sink" to "small is beautiful" (or maybe "smaller is
less unsightly").  That could be a good thing, but it seems risky two
months before 1.0.

					-- Bob