This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Guile docstrings---should Guile code be ANSI C compatible?
- To: "Greg J. Badros" <gjb at cs dot washington dot edu>
- Subject: Re: Guile docstrings---should Guile code be ANSI C compatible?
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 15 Jan 2000 03:02:02 +0100
- Cc: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>, Maciej Stachowiak <mstachow at alum dot mit dot edu>, guile at sourceware dot cygnus dot com
- Cc: djurfeldt at nada dot kth dot se
- References: <E129GC4-0004oo-00@mdj.nada.kth.se> <qrriu0wxj92.fsf@clavicle.cs.washington.edu>
"Greg J. Badros" <gjb@cs.washington.edu> writes:
> But it's got other constructs like "long long" that are not ANSI C (turn
> on -pedantic to find them).
But in configure.in, I've written:
AC_CACHE_CHECK([for long longs], scm_cv_long_longs,
AC_TRY_COMPILE(,
[long long a],
scm_cv_long_longs=yes,
scm_cv_long_longs=no))
if test "$scm_cv_long_longs" = yes; then
AC_DEFINE(HAVE_LONG_LONGS)
fi
I hope I'm strictly using it only if HAVE_LONG_LONGS is defined.
> > We now have two alternatives:
> >
> > 1. (Greg's suggestion) Making an exception to the rule about ANSI C
> > compliance and using a script which transforms the code in the
> > .x-files into ANSI compilant source using a script:
>
> Let me stress that this suggestion is for the short term-- I don't think
> we should *release* guile-1.3.6 w/ this script, but only that while the
> docstrings are in a state of flux, it might be prudent to ask those
> using stricter ANSI compilers to use the script and keep the code in the
> repo non-strict until the docstrings stabilize.
>
> Alternatively, some good Emacs tools for managing the docstrings \n\
> terminators (e.g., reformatting a docstring, adding the \n\ lines, etc.)
> might be really useful.
I'm used to using the bleading edge of Guile development. Until now
that hasn't actually been any big problem. I think it is a good
principle to try to let the repository always represent as close as
possible what is finally going to go out in the release---that way we
get a lot of valuable testing and early bug fixing done.
I can volunteer to make Emacs tools for removing/adding the \n\.
> > Maciej, could you please make a decision which route we should take.
>
> Again, I think it'd be insane to not have the docstrings properly
> terminated by release time, but my script shows that we can get there
> pretty easily whenever we want to, and I think it wiser to fall on the
> side of convenience to developers in the short term. Anyone using guile
> from CVS better be competent enough to apply the script to make a more
> ANSI-like version to compile on a stricter compiler.
I fully understand that it creates a lot of unnecessary work to edit
the strings by hand with the \n\ in the code.
I prefer the Emacs solution before the script solution, though,
because of the above reason and because it is conceptually simpler.
> I'd feel a little differently if there are lots of folks contributing
> who do their main dev work on systems w/ the stricter rules (since
> committing for them will be annoying; maybe then we'd need a script to
> undo the \n\ terminators, too), but I don't have any evidence to believe
> that that's the case.
I'm trying to report it (it once worked) to our supercomputer right
now...
/mdj
P.S. It's great, Greg, it's great! (it truly is) :)