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

["Greg J. Badros" <gjb at cs dot washington dot edu>]

mstachow@alum.mit.edu writes:

> "Greg J. Badros" wrote:
> > 
> > That's what reading diffs are for! :-). 
> 
> Having the code out there for a while is also pretty important.

Yes, for some things.  But there are some classes of changes that we'd
like to think we can reasonably make w/o fear of side-effects
(unfortunately, for portable C code, that set of things is pretty
small).  Your point is well taken though.

> > And maybe "right before release" is not the right way to put it.  Right
> > after finishing the massive docstring effort which hopefully won't be the
> > last thing that needs to get done before the next relesae.  Or we can do
> > the change once we have some reasonable X?Emacs tools to manage ANSI-C
> > literal strings split across lines.... whichever comes first.
> 
> Personally I think the docstrings shouldn't contain explicit linebreaks
> and should be formatted by whatever is generating the ready-to-display
> output. Then they could either be written as one long line, or using the
> autoconcatenation feature:

One long line would break the GNU coding standards, wouldn't it?
Besides, when we're talking about having markup in the docstrings, I
think it'd be really hard to format the markup source (i.e., the
docstring text) nicely w/o using line breaks.

> "This is a docstring that I wrote "
> "just for the sake of example." 

Don't legacy C compilers have problems with this (even more so than \n\
separators)?

> I don't think that's too much of a pain to deal with.

For humans it's still a pain, too, and probably no better than just
newline separators for portability.

> But if you think it is I'd be happy to wait until all the docstrings
> are there before reformatting.

That'd be great.  Hopefully that's not too far off.

Greg