Re: Questions about floating numbers, rethink and bug report

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:

    Dirk> On 16 Oct 2001, Neil Jerram wrote:
    >> >> - we already have a general virtualization mechanism --
    >> GOOPS >> -- and so should use that rather than inventing an
    >> additional >> mechanism.
    >> 
    Dirk> OK, then how would you replace SCM_VECTORP and friends?  How
    Dirk> does your virtual function lookup mechanism look when using
    Dirk> goops?  I'm curious, because I currently don't see how
    Dirk> low-level types can be virtualized using goops without a
    Dirk> noticeable performance drawback.  Could you give a code
    Dirk> example for how you would do it, please?
    >>  I'll have a go, and aim to let you know the results by end
    >> Friday.

    Dirk> Thanks.

    >> It may well be that you are right, and that it is impossible to
    >> use GOOPS without losing a lot of performance, but I'd like to
    >> be sure that we've checked the possibilities first.

    Dirk> Yes, in principle you are right.  And, if I understand
    Dirk> things right, GOOPS will once be capable of replacing smobs
    Dirk> and similar stuff, or at least put it under a common
    Dirk> mechanism.  But, for that to happen - at least that's my
    Dirk> understanding - some things still need to be added, among
    Dirk> them a clean API that allows for better interaction with C
    Dirk> datatypes and also will allow for fast classes with
    Dirk> performance similar to smobs.

Well, no code example I'm afraid, and sorry for being late with this
reply, but I have now had time to look at the existing code and think
more about this issue.

Overall, I have reached the same conclusions as you.  In theory we
should use GOOPS, but that presupposes a C API for doing that, which
doesn't exist yet.  In that API's absence, we gain clarity and lose
nothing by doing the work now to separate out the code for different
types of vector.

Regarding SCM_VECTORP, the long term answer is that there would be a
SCM_VECTOR_XXX_P for each individual vector type, which type-specific
code can use for assertions, and a scm_vector_p function which would
probably be implemented as (is-a? obj <vector-base>).  If you look at
the relatively few places that currently use SCM_VECTORP, either they
are part of the vector implementation itself, or they are in code like
sort.c which, in a GOOPS/generic function approach, it would also make
sense to genericize.  The upshot is that I don't think that C code
will ever need a super-efficient SCM_VECTORP, meaning _any_ kind of
vector, because the concept will rarely be required.

In other words, in a GOOPS approach, any function that accepts an
argument of multiple type, and which uses different code according
to that type, would be better off making itself generic.

    >> Had you already considered and rejected using GOOPS before I
    >> mentioned it?

    Dirk> Not really, because I have not used it for myself yet.  But,
    Dirk> I have taken a look into how GOOPS works and from that I
    Dirk> have the impression that it is not capable (yet) for
    Dirk> replacing smobs in an efficient way.

    Dirk> However, the main problem will be to select a good way to
    Dirk> virtualize the strings and vectors - using GOOPS or not.  If
    Dirk> that is done, it won't be a big deal to switch things later:
    Dirk> We will most probably stick to the current way of using
    Dirk> macros like SCM_VECTORP and such.  If SCM_VECTORP expands to
    Dirk> the GOOPS way of determining the type or if it does it as
    Dirk> currently, checking the bit pattern in the cell header, this
    Dirk> doesn't make a difference.

Agreed.  Good luck!

        Neil