[TODO] Migrate non-essential ops to dynops

[allison]

Several ops that are currently compiled as core could (and likely should) be dynamic ops instead. Candidates include (in part or in whole): bit.ops, debug.ops, io.ops, math.ops, obscure.ops, set.ops (the obscure and rarely used parts), sys.ops.

[coke]

obscure.ops was moved yesterday; Planning to move:

• bit.ops (all)
• debug.ops (all)
• set.ops
  • exchange
  • set?_ind
  • clear?
• math.ops
  • gcd
  • lcd
  • transcendentals
  • fact

Anyone have an opinion on sys.ops? io.ops? If we move io.ops, we should keep the basic print/say variants at a minimum.

[allison]

Those look good, on io.ops and sys.ops, I'd say:

• io.ops
  • printerr
  • seek
  • peek
  • tell
  • open (method is primary way of doing this)
  • fdopen (ditto)
  • close (ditto)
  • read (ditto)
  • readline (ditto)
  • getstd* and setstd* (method on interpreter is primary way of doing this, TT #264)
  • say (we don't really need a whole set of opcodes that just add a newline, it's op-bloat)

So, just keep print in core ops.

• sys.ops
  • time and sleep should be core, everything else can be a dynop.

[coke]

Based on discussion in #parrotsketch on jan 5, 2010, 'say' should stay a regular op for now. (If it gets migrated to a dynop, we'll open another ticket later.)

Nothing else on the list in comment:5 raised any red flags.

[whiteknight]

I've been digging though the mathematics ops specifically and I have a few qualms about our current implementation:

• We don't really have a complete set of certain types of ops. Trigonometric ops for instance are missing csc and cot. For hyperbolics we're likewise missing csch and coth. We're missing tons of the inverse functions too.
• We have a few other random, rarely-used functions like gcd, lcm, and fact. These operations will be used uncommonly and don't even represent a complete set of useful arithmetic shortcuts that people would want.

Instead of making these mathematical functions a dynop in the repo, I suggest we cut them out of Parrot entirely and instead create a new child project with these kinds of utilities for the people who are actually interested in them. A separate project would allow these libraries to get the focus and attention that they need to become comprehensive, useful resources.

I recommend that we change the deprecation notice to indicate these ops are going to be removed completely from the repository, and after the 2.3 release we move them to a new home.

[doughera]

Replying to whiteknight:

- We don't really have a complete set of certain types of ops. Trigonometric ops for instance are missing csc and cot. For hyperbolics we're likewise missing csch and coth. We're missing tons of the inverse functions too.

I'm not sure it's fair to categorize those all as "missing". For example, since csc, cot, csch, and coth are not part of the standard C math library, I wouldn't necessarily expect them to be available in a basic parrot math library.

I could reasonably see two levels of useful bundling of trigonometric ops. (Analagous reasoning could be applied to other groups of ops as well.)

1. Thin wrappers around the standard C math library functions (similar to what perl5's POSIX module does). I'd expect a standard parrot install to provide such basic library functions.

2. A more "complete" set of trigonometric functions, similar to perl5's Math::Trig module. I could reasonably see such functions as not being part of a base installation.

[whiteknight]

Nowhere do we say that Parrot's ops need to be little more than a thin wrapper over libc. Regardless of what libc offers (We don't make design decisions about that), TI think that Parrot should either provide a complete library of trigonometric functions by default or it should delegate that responsibility to a library. If we half-ass it, we lose the ability to do it correctly: I'm not going to put together a mathematics library that offers only a handful of things that Parrot doesn't have. A library that offers csc and cot only is pretty worthless, and anybody who needs those functions is just going to implement them again and again.

What we have now is a thin wrapper around part of libc that provides only some of the trigonometric functions. I think this is a bad approach. We're not providing either a complete libc wrapper for people who might prefer that, and we're not providing a complete set of mathematical utilities for people who need those. I suggest both of these things would be better suited as separate projects.

[plobsing]

I'll take a crack at this one.

So far I've moved: math.ops => obscure.ops:

• gcd
• lcm
• fact

set.ops => deprecated.ops:

• clear[insp]
• set[insp]_ind
• exchange

I'll be slowly moving more over the next few days/weeks.

[plobsing]

Replying to plobsing:

I'll take a crack at this one.

I've moved all ops mentioned in this ticket. Given the pain this has already caused, I'm not inclined to push the envelope here (even though there are probably some remaining ops that aren't strictly essential). If more ops are deemed non-essential, open up a new ticket to move them.

I'll be slowly moving more over the next few days/weeks.

In hindsight, maybe I should have said "swiftly and abruptly". ;-)