coercion of symbols to strings

[Christopher Fry <cfry@OZ.AI.MIT.EDU>]

    To convert a symbol to a string one apparently must use the string function.
    That is, (coerce 'x 'string) is illegal.  But (string 'x) ==> "X" .
    Why not allow the former as a synonym for the latter?
Coersion is a powerful, easy to remember concept. 
I think it should be extended as much as possible.
The above is reasonable, as are:
(coerce #\a 'string) => "a"
(coerce 123 'string) => "123"
(coerce #\a 'integer) => (char-code #\a) ;this is mentioned as
  explicitly not provided CLtL p. 52. It appears that the only reason
  is that no one could decide on using char-code or char-int for the conversion
  so they chose not to do it at all. This reasoning is odd. Pick the most frequently
  used way, document it, and permit it.
  Same argument for coercion of numeric types.

Further out extensions might be:
(coerce #'foo 'compiled-function) => returns a compiled function object
     we can decide whether or not it should update foo's definition.
(coerce hash-table-1 'list) => makes an list of the values in the hash table.
You can find out their keys via sxhash.
We might also want to convert hash tables to simple-vectors, and visa-versa.
[key on printed representation ?]

(coerce pathname-1 'string)
(coerce string-1 'pathname)
(coerce bit-vector-1 'integer)  consider the bit vector to be a
    straight binary representation of a non-negative integer.
    This is like converting between #*101 and #b101  .
(coerce structure-instance-1 'list)

Coersion between streams and strings sounds useful.
This mechanism could be used to make a string from a file, for example,
or do the reverse.
Undoubtedly there are other coersions which would make sense.

Being implementors, we can think of hairy cases where semantics will
be ambiguous for most of the above suggestions. But typical cases
are, by definition, the cases usually used. The awkward cases can be
documented.
Users would save a lot of manual searching if coerce was extended.