Re: Naming conventions of conversion routines

[Marius Vollmer]

"Daschbach, John L" <address@hidden> writes:

> In the face of a changing interface between C and guile it seems
> that the best solution is to write my own conversion API for the
> routines I need and then migrate this to scm* from gh_*.

Hmm, I think it is safe to wait with this until we actually start
making the gh_ API obsolete so that you know what kind of conversion
you have to do.  Also, we will keep the gh_ API for a long time so you
don't need to hurry.

> This however represents another layer which in many cases basically
> copies the gh_* routines.  For example the gh_num2doubles() routine,
> which I use often, wraps calls to scm_* in a loop.  I suppose then
> that if a scm_num2doubles() appears the my_num2doubles() routine
> could be made a macro.

Yes, ideally, the switch from gh_ to scm_ would just be s/gh_/scm_/g.
Realistically, there will probably things that don't go that smoothly
but hopefully for a good reason.

> Because I'm used to it I like the scm2double <=> double2scm naming
> convention.  I always know that scm is the scheme object.  The
> current scm_* convention does not follow this, using num for an scm
> number.

> It is always clear that scm is the scheme side, but looking at code
> years from now it would not be as obvious that num is the scheme
> object.  Would it be possible to revisit the new naming convention?

Yes, definitely.  I think it would be good to have a very consistent
and simple set of functions like

    scm_to_string, scm_to_int, scm_to_doubles, etc.

in addition to the ones we already have.  The ones we have allow you
to specify what kind of error should be reported, which makes them
harder to use.

A concrete plan needs yet to be formulated.  Would you like to help?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405