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;
adopting true strings was one of the first improvements added to it
by Zetalisp, one of the ancestors of Common Lisp.

I would be happy with encouraging programs to treat symbols as textuals,
however.  That's what Common Lisp does: some of its string functions
accept symbols (possibly for backward compatibility with converted Maclisp
code), and the cost of 3-morphism isn't much higher than 2-morphism,
though monomorphism is cheapest.

> * The obvious two procedures symbol->text and text(ual)->symbol.

Those make sense to me.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Even the best of friends cannot attend each others' funeral.
        --Kehlog Albran, The Profit