guile 1.4->1.6 migration hints, questions

[Steve Tell]

Way, way, back in late 2001 this list had a thread on collecting hints for
application-writers that want to either move their applications from guile
1.4 to guile 1.6, or to add guile-1.6 compatibility to an application that
still has to build and run with 1.4.

I don't suppose any repository of hints and recipies ever came of that
discussion?  
The NEWS file in a guile-1.6 release helps, but isn't always quite enough.

Here are a couple of issues I ran into while doing a minimal upgrade of
gschem (http://geda.seul.org/tools/gschem/) to let it build with guile 1.6.3.
Maybe this will help someone doing a similar upgrade.  
Comments on the appropriateness and guile-correctness of the fixes would
be appreciated.  Remember that the goal is minimal changes to allow
compiling/running both with 1.4 and 1.6.

1. one-argument (eval e) vs. R5RS (eval exp env).  
I found that either (eval e (current-module)) or
(primitive-eval e) would work for this app.  Gschem is utterly and
completely ignorant of guile's module system, so which replacement is
preferred in this case?   

Guessing, I settled on (eval e (current-module)), implemented for
compatibility like this (replacing subsequent uses of eval-cm with eval.

(if (false-if-exception (eval 'display (current-module)))
    (define (eval-cm exp) (eval exp (current-module)))
    (define eval-cm eval))

The C version of the compatibility fix I did with configure, as:
#ifdef HAVE_SCM_EVAL_X_MODULE
      scm_eval_x(form, scm_current_module());
#else
      scm_eval_x(form);
#endif


2. It seems like guile 1.4 would let sloppy users get away with mixing
symbols and strings in ways that guile 1.6 will not.  Pass a symbol from
scheme to C and then hand it to gh_scm2newstr() - in 1.4 it works, in 1.6
it thows an error.  This isn't explicitly mentioned in the NEWS file.
While careful expert guilers probably wouldn't do this, the
guile documentation of a few years back probably led others in addition to 
me to adopt a hack-till-it-works-then-ship-it approach.

The fix here was obvious: insert symbol->string calls where needed,
and add any SCM_ASSERT(SCM_STRINGP(s), s, ...) calls that were missing.


An aside: the deprecated-function warning is annoying, given that most or
all of the warnings are about functions that can't be replaced with their
newer counterparts until guile-1.4 compatibility is dropped by this
particular program. (Or a whole slew of ifdeffs are deemed better).
Many users of the program (unfortunately) don't care that guile's under
the hood nor care about the upgrade/deprecation schedule.
So in this case I'll probably suggest just doing a
 if(getenv(GUILE_WARN_DEPRECATED)==NULL) putenv("GUILE_WARN_DEPRECATED=no")
in the C code before initializing guile.
I'd prefer it if there was a programmatic way to do this that didn't muck
up the environment of any subprocesses.


Steve

















--
Steve Tell  address@hidden