Re: Kawa type-conversions

[Jamison Hope <jrh at theptrgroup dot com>]

On Mar 27, 2015, at 10:23 PM, Per Bothner <per@bothner.com> wrote:

> You discuss an extra search mechanism
> (convention) for explicit conversion, but I don't understand how
> that so much more convenient than just re-defining the ->TYPE function.

If all of the source is being compiled together, then perhaps it
isn't, except that it avoids having to explicitly group all of the
possible conversions together into a big case-lambda or whatever.
The search mechanism would make ->TYPE more akin to a CLOS generic
function, where the backing methods could be in separate modules.

Anyway, my thought was for separately-compiled libraries.  For example,
suppose I've got a textbook shape class library with a bunch of useful
functions to do things like calculate the minimum distances between pairs
of shapes (sphere/sphere, prism/cylinder, etc).  Everything is working
fine, and then the boss says that I need to support JBullet shape
primitives.  Knowing how these things go (next week it'll be ode4j or
some other package instead of JBullet), instead of making a bunch of
huge changes to the guts of my library, I change my top-level functions:


(define (calculate-distance s1::com.example.shape s2::com.example.shape)
  ::real
  ...)

becomes

(define (calculate-distance o1 o2) ::real
  (let ((s1 (->com.example.shape o1))
        (s2 (->com.example.shape o2)))
    ...))


I then compile that to a JAR and never touch it again.


To support JBullet, I then write a helper library which does the
conversion between JBullet shapes and com.example.shape, and then make
sure that JAR gets loaded any time I have to support JBullet shapes.
Likewise for ode4j and the next third-party library that comes along.


If I just redefine ->TYPE, then I end up needing 2^n different
re-definitions, for all of the possible combinations of "from" types.
In this example, I would need one that just handles JBullet shapes,
another which just handles ode4j shapes, a third which handles both,
etc.

(Again, the problem is the big generic procedure with everything all
in one place.  That means to compile/load that one function, I would
need to load the classes of all types mentioned by that function.)

Does all that make sense?

Maybe this isn't the job of ->TYPE, maybe it's some other COERCE-like
function which does runtime (not compile-time) lookup to enable the
kind of modularity I've described?

--
Jamison Hope
The PTR Group
www.theptrgroup.com