DFPQ factory

[phoe]

I need to work on a DFPQ factory that compiles different versions of DFPQ code with custom element types and such. It will be a mess, but it seems to be the only solution to the fact that I just got a request for float priorities rather than ub32 ones, and I don't want to copy all the files just to accomodate that.

[3b]

multiple priorities would also be nice (my current project wants to sort on 2 floats).

I have an ugly hack that lets me do something like

(damn-fast-generic-priority-queue:define-priority-queue-package
    damn-fast-f+f-priority-queue)

(in-package damn-fast-f+f-priority-queue)

(damn-fast-generic-priority-queue:define-priority-queue
    damn-fast-f+f-priority-queue
  single-float single-float)

;;; then in some package with q: as a local nickname for the above package

(q:enqueue queue foo y x)

but having M-. on everything just go to that macro is sort of annoying (and needing to do package stuff in 2 steps is a bit ugly as well).

Any thoughts on what a good solution would look like? Options i can think of aside from a macro like the above are:

• something to generate source files for a particular configuration

  pros: M-. works, easier to check the output.
  cons: M-. working encourages changing the generated code instead of porting fixes back to the generator, need to remember to regenerate all variants after doing so, and then pay attention for unexpected effects.

• something like specialization store or fast generic functions

  pros: more shared code, M-. probably works and goes somewhere editable?
  cons: need to figure out how they work, and figure out a good protocol to use them efficiently. Possibly doesn't work (or work as quickly) on all implementations?

• figuring out how to compile a single source file multiple times with varying contexts

  pros: M-. works
  cons: C-c C-c after M-. probably doesn't work, would probably take some effort to get ASDF set up for that (and deal with portability and conformance subtleties)

• actually generic code (normal GFs, or passing key/compare functions instead of inlining)

  pros: normal CL code
  cons: probably not damn-fast

[3b]

and orthogonal to how to implement it, listing some possibilities for features to expose to users:

• type of priority

  • Numerical types only?
  • any type?
  • some subset of numeric types likely to be storable "unboxed"?

• sort order

  • #'< only
  • limited to #'< or #'> choice?
  • completely arbitrary comparison operator

• multiple priorities (if first is =, check next, and so on)

  • same type for all?
  • same ordering for all?
  • is it worth any extra effort to let the user name the argument names for priorities in enqueue (so it shows up in minibuffer in slime or popup completion help or whatever)?

For my code I'd probably be OK with "unboxed" numerics, limited ordering, and multiple priorities with varying types. Possibly also have full generality available but slower for more complicated cases (not sure i'd expect a #'string-lessp queue to be that fast to start with).