Re: Re-addition of deprecated stuff to 1.7.

[Bruce Korb]

Marius Vollmer wrote:

> > #define _GUILE_SOURCE 1.6
> > #include <libguile.h>
> >
> > And a 1.7.x/1.8.x libguile.h would have something at the end like
> >
> > #if _GUILE_SOURCE = 1.6
> > #include <guile/compat-1.6.h>
> > #endif

>    /* new code, using three-arg eval */
> 
>    #define GUILE_ENABLE_THREE_ARG_EVAL
>    #include <libguile.h>
> 
> Later, we can deprecate the 'enable' variant and prefer a 'disable'
> one:
> 
>    /* old code, using two-arg eval */
>    #define GUILE_DISABLE_THREE_ARG_EVAL
>    #include <libguile.h>
> 
>    -------------------
>    /* new code, using three-arg eval */
> 
>    #include <libguile.h>
> 
> And still later, we can just remove GUILE_DISABLE_THREE_ARG_EVAL and
> let the old code fail.

I'm going to guess here, so please correct me if I am wrong.
I think the client model you are operating with is that someone
develops some code and gets it running on their local system and
then they are happy campers.  That is not what I am doing.  I
am distributing my stuff to whomever and they will use whatever
Guile happens to be installed on their systems.  Some of them are
using libguiles that are quite a few years old.  May I please
encourage you to supply configury stuff that is capable of
adapting current interfaces to old Guiles?  For example, it would
be _really_nice_ if it were to define a scm2newstr_size_t.  That
way I would not be completely unbuildable on I32LP64 platforms
that still use "int" for the size argument.  Stuff like that would
be Really Nice.

You also need to consider what happens when someone tries to build
an old variation of my code with an as-yet-unreleased Guile.  It
is not a bad idea at all for me to define:

   #define _GUILE_SOURCE 1.6

as a way of saying, "When this program was distributed, it was
cognizant of the interface through to 1.6."  'course, in my case
it may actually be 1.4 because I don't have the time to track
changes. :)  My desire is to use a small stable subset that
won't vary very much.  Which is also why I selected the advertized-
as-stable gh interface for as much as possible.  *sigh*.

P.S. If _anyone_ can show me how to set the string port file
name and line number, I *sure* would be a happy camper.
I've tried all the variations of all the suggestions and have
still failed to get it working, though at least I'm now printing
the line and column numbers within each string fragment.
I'll even write it up or, better, I think, is to provide a:

   <<whateverprefixyouwant>>_eval_str_with_file_and_line

function.  That would sure make life easier for the next one along.

Cheers, Bruce

Bruce Korb <first initial + last name at gnu dot org>
AG URL: http://autogen.sourceforge.net