This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Guile docstrings---should Guile code be ANSI C compatible?


"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) :)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]