Marc Nieper-Wißkirchen scripsit:

> However, we should not discourage implementations that implement SRFI
> 135 natively to implement it in a way such that each text can also
> regarded as a symbol and vice versa.

I entirely disagree with this.  At most I would support a one-way
relationship whereby symbols may be texts but not vice versa.  In any
implementation, symbols have an overhead because they are interned,
and that should not be imposed on text-handling programs that
deal with a large number of texts (which would inflate the symbol
table).  Maclisp used symbols as strings with similar costs;