Naming conventions of conversion routines

Naming conventions of conversion routines

[Daschbach, John L]

I have been working to upgrade my guile C code to the new "scm_*" routines from the "gh_*" routines.  The new naming convention is more confusing than the gh convention.   Does anyone else find this so, and should it be changed?

For instance:

`gh_long2scm'\r     Use `scm_long2num' instead.\r\r`gh_double2scm'\r     Use `scm_make_real' instead.

`gh_scm2long'\r     Replace `gh_scm2long (OBJ)' by\r          scm_num2long (OBJ, SCM_ARG1, STR)\r     where STR is a C string that describes the context of the call.\r\r`gh_scm2double'\r     Replace `gh_scm2double (OBJ)' by\r          scm_num2dbl (OBJ, STR)\r     where STR is a C string that describes the context of the call.
With the gh convention it is clear that the return value is an SCM object, and without thinking one can write the conversion to and from C.  With the new convention we have

scm_make_real(NUMBER) <=> scm_num2dbl(OBJ,STR)

and

scm_long2num(NUMBER) <=> scm_num2long (OBJ, SCM_ARG1, STR)

When reading code it seems to me  more transparent to have "2scm" rather than "2num" and "make_real".  
The symetric naming of the gh system is more logical.  Why do we now have "scm_make_real" instead of "scm_double2num"?  Why does scm_num2long have three arguments with SCM_ARG1 and scm_num2dbl have two arguments?
Why is the new system inconsistent when the old one was not?  

The reason I started using guile some time back was to have a way to script mixed C and Fortran codes.  I found it easy to wrap these codes with guile and get values into and out of the C code from guile.  Mostly this used the gh_ interface.  Now gh_ is being depreceated, but the conversion routines between C and guile are not complete.  e.g.

`gh_scm2newstr'\r     No direct scm equivalent.  [FIXME]\r\r`gh_get_substr'\r     No direct scm equivalent.  [FIXME]\r\r`gh_symbol2newstr'\r     No direct scm equivalent.  [FIXME]\r\r`gh_scm2chars'\r     No direct scm equivalent.  [FIXME]\r\r`gh_scm2shorts' and `gh_scm2longs'\r     No direct scm equivalent.  [FIXME]\r\r`gh_scm2floats' and `gh_scm2doubles'\r     No direct scm equivalent.  [FIXME]

This is causing me to think that the use of guile as a wrapper for C code is not important to the developers and there is a risk that this will not work in the future.  Is the use of guile as a wrapper for C code being depreceated?

-John



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Naming conventions of conversion routines

[Marius Vollmer]

"Daschbach, John L" <John.Daschbach@pnl.gov> writes:

> I have been working to upgrade my guile C code to the new "scm_*"
> routines from the "gh_*" routines.  The new naming convention is
> more confusing than the gh convention.  Does anyone else find this
> so, and should it be changed?

Yes, yes.  We are not yet ready to replace the gh_ API with an equally
elegant scm_* API.

I agree that the conversion routines between C types and Scheme types
are a very important part of Guile.  They should be complete,
consistent, easy to use correctly, beautiful on the eyes, etc.

> Why is the new system inconsistent when the old one was not?  

Because, in reality, what you think of as the new system, is actually
the very old one, the one that the gh_* API improved upon.  You are
right that gh_ is better in places than the scm_ functions, but since
you can't get far without scm_ functions anyway, we thought it would
be confusing to have two API and decided to remove the gh_ interface
eventually.  But as you say, it still shines brighter than the scm_
API, in places.

> Is the use of guile as a wrapper for C code being depreceated?

No, no.  Things are just moving much slower than one might like...

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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

RE: Naming conventions of conversion routines

[Daschbach, John L]

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_*.  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.  

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?

-John

> ----------
> From: 	Marius Vollmer
> 
> 
> "Daschbach, John L" <John.Daschbach@pnl.gov> writes:
> 
> > I have been working to upgrade my guile C code to the new "scm_*"
> > routines from the "gh_*" routines.  The new naming convention is
> > more confusing than the gh convention.  Does anyone else find this
> > so, and should it be changed?
> 
> Yes, yes.  We are not yet ready to replace the gh_ API with an equally
> elegant scm_* API.
> 
> I agree that the conversion routines between C types and Scheme types
> are a very important part of Guile.  They should be complete,
> consistent, easy to use correctly, beautiful on the eyes, etc.
> 
> 
> -- 
> GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405
> 
> 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Naming conventions of conversion routines

[Marius Vollmer]

"Daschbach, John L" <John.Daschbach@pnl.gov> 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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user