Ticket #449 (closed deprecation: done)

Opened 6 years ago

Last modified 4 years ago

[TODO] Migrate non-essential ops to dynops

Reported by: allison Owned by: plobsing
Priority: normal Milestone: 2.4
Component: core Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

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.

Change History

  Changed 5 years ago by 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.

  Changed 5 years ago by coke

  • owner set to coke

  Changed 5 years ago by coke

  • status changed from new to assigned

  Changed 5 years ago by jkeenan

  • component changed from none to core

  Changed 5 years ago by 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.

  Changed 5 years ago by 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.

  Changed 5 years ago by chromatic

  • milestone changed from 2.0 to 2.1

follow-up: ↓ 9   Changed 5 years ago by 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.

in reply to: ↑ 8   Changed 5 years ago by 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.

  Changed 5 years ago by 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.

  Changed 5 years ago by coke

  • type changed from todo to deprecated

  Changed 4 years ago by allison

  • milestone changed from 2.2 to 2.6

  Changed 4 years ago by allison

  • milestone changed from 2.6 to 2.3

  Changed 4 years ago by gerd

  • milestone changed from 2.3 to 2.4

  Changed 4 years ago by coke

  • owner coke deleted
  • status changed from assigned to new

follow-up: ↓ 17   Changed 4 years ago by plobsing

  • owner set to 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.

in reply to: ↑ 16   Changed 4 years ago by plobsing

  • status changed from new to closed
  • resolution set to done

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". ;-)

Note: See TracTickets for help on using tickets.