Re: SCM_LENGTH ???

[Bruce Korb <bkorb@veritas.com>]

On Monday 10 January 2005 09:26 am, Marius Vollmer wrote:

> The recommended way to check for deprecated features is to compile a
> version of Guile with --disable-deprecated and compile/link/test
> against that.

That's a cute idea.  I like it!  I confess, I don't remember it from the last
time I went through the Guile docs.  When was that?  '99 or '98?
Have the docs changed much since then?  ;-)

> > I cannot control my clients.  They will use whatever is installed.
> 
> Which is not always going to work, period.  Programs do have
> reqirements that must be honored by the clients of these programs.
> The less requirements there are, the better, but it is unrealistic to
> aim for zero requirements.  Requiring Guile 1.6 is very reasonable in
> my view, especially since it is still maintained.

Well, 1.4 is old enough that requiring something newer isn't a problem
for me.

> > They could (and do) still use 1.4.  Are these scm_c_*_length functions
> > available in 1.6 (let alone 1.4)?
> 
> No.

However, it is a bit premature to use scm_c_*_length functions since
1.7.x is a test release series and 1.8 is not available.  :)  Thank you
for restoring the compatibility stuff!

> >> This version is guaranteed to contain serious bugs, and the publically
> >> visible interfaces will almost certainly change before 1.8 is
> >> released.  The 1.7 releases might be termed "selected snapshots".
> >
> > A disappearing interface is certainly a bug.
> 
> No, if the interface itself is buggy, I'd say removing it is a
> feature. :-)

OK.  A feature then.  Whether a feature or a bug, it breaks my released
software.  :-(

> > It is not possible to migrate released software.
> 
> You are not supposed to.  Just use 1.6 for the old releases and
> require 1.8 for the new ones, if you see a benefit.

1.4 is adequate for my needs (though I agree it is old enough to
not worry about anymore).  So, I want to build to an interface that
works for either 1.6 *or* 1.8 and I would really hope for binary
compatibility between them as well.  Once 1.6.x has been dormant
for a couple of years, *then* one can stop fretting over clients
still using the thing.

> > Please ensure that *ALL* legacy interfaces are maintained.
> 
> Unfortunately, the legacy interfaces of Guile are problematic.
> Traditionally, Guile has exposed lots of its internal implementation
> details (such as the fact that strings, symbols, and vectors stored
> their length in the same way), and because of the lack of clean
> alternatives and also lack of proper documentation, people have made
> use of these internals in their programs.  We try to slowly fix this
> situation.

To me, this still feels like grubbing around in internals and I do wish
you all were willing to supply something that approximates it.
I loathe having this in my code:

SCM
ag_scm_c_eval_string_from_file_line(
   const char* pzExpr, const char* pzFile, int line )
{
    SCM port;

    {
        static const char zEx[] = "eval-string-from-file-line";
        SCM  expr  = scm_makfrom0str( pzExpr );
        port = scm_mkstrport( SCM_INUM0, expr, SCM_OPN | SCM_RDNG, zEx );
    }

    {
        SCM file = scm_makfrom0str( pzFile );
        scm_t_port* pt = SCM_PTAB_ENTRY(port);
        pt->line_number = line - 1;
        pt->file_name   = file;
    }

    {
        SCM ans = SCM_UNSPECIFIED;

        /* Read expressions from that port; ignore the values.  */
        for (;;) {
            SCM form = scm_read( port );
            if (SCM_EOF_OBJECT_P( form ))
                break;
            ans = scm_primitive_eval_x( form );
        }

        return ans;
    }
}

> So, SCM_LENGTH is definitely deprecated and you need to stop using it
> eventually.  The alternatives are hopefully much better and will stay
> around much longer.

Excellent.  Thank you.

Regards, Bruce


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