[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SCM_LENGTH ???
From: |
Bruce Korb |
Subject: |
Re: SCM_LENGTH ??? |
Date: |
Mon, 10 Jan 2005 10:03:10 -0800 |
User-agent: |
KMail/1.6.2 |
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
- Re: SCM_LENGTH ???, Bruce Korb, 2005/01/07
- Re: SCM_LENGTH ???, Marius Vollmer, 2005/01/07
- Re: SCM_LENGTH ???, Bruce Korb, 2005/01/07
- Re: SCM_LENGTH ???, Marius Vollmer, 2005/01/10
- Re: SCM_LENGTH ???,
Bruce Korb <=
- Re: SCM_LENGTH ???, Greg Troxel, 2005/01/10
- Re: SCM_LENGTH ???, Marius Vollmer, 2005/01/11
- Re: SCM_LENGTH ???, Kevin Ryde, 2005/01/11
- Re: SCM_LENGTH ???, Marius Vollmer, 2005/01/12
- Re: SCM_LENGTH ???, Ken Raeburn, 2005/01/10
- Re: SCM_LENGTH ???, Bruce Korb, 2005/01/11
- Re: SCM_LENGTH ???, Marius Vollmer, 2005/01/11