Re: pretty fonts in sources

[Juergen Christoffel <unido!gmdzi!LISPM-1!JC@seismo.css.gov>]

    Date: Thu, 4 Jun 87 23:12 EDT
    From: "Robert W. Kerns" <RWK%YUKON.SCRC.Symbolics.COM%unido@gmdzi>

    Who says these are bugs, and who said you can just put whatever source
    code you want into bold?

I called it bug, now after reading your explanations, I'd call it
misfeature. Before Release 7.x you just could 'put whatever source code
you want' into different fonts. And we used (and still do use) this to
make our code more readable; because we have a ZMACS extension to do it,
even Symbolics's source code get's more readable from this.

    I understand the surprising aspect of Juergen's examples.
    But if we made "1foo0" not be bold, consider the highly
    surprising (and inconvenient) result of

    (format t "This is 1bold0.")

    printing out This is bold. instead of This is 1bold0.

I wouldn't have been suprised by the first. I would have expected just
this. While it may be convenient (but error prone), I think one should
use some reader macro to clearly state wether or not a font switch *is*
desired when the code get's into the environment.

    It's a trade-off.  A fair bit of thought went into choosing the
    current behaviour, and it is 2not0 a bug.  You may argue it's
    a 2mistake0, of course, but I personally find being able to
    put boldface, etc, into strings to be far more useful than
    any problems it causes.

Not enough thought went into it, I suppose. Consider e.g.

(describe "1b0ar")
(describe 1#\a0)

While the string becomes a fat string, the character still will be a
ordinary one with style NIL.NIL.NIL. That kind of behaviour seems
a bit inconsistent...

And what would happen to #\1control2-space0? :-)

I think a proper solution would be to use reader macros for the intended
purpose, so anybody could clearly see, what is intended.

E.g. #(NIL.BOLD.NIL)\control-space and the #" syntax Peter Norvig
suggests.

	--JC