While "text = symbol" as proposed by Marc Feeley appeals to one of the basic principles of the Scheme programming language (I am, of course, referring to the famous first paragraph in the introduction of the latest report), the intended implementability of this SRFI in a portable way forbids to force "text = symbol".
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.
Thus I would love to see the following two things added to SRFI 135:
* The remark that: It is not specified whether texts (that are values for which text? evaluates to #t) and symbols are disjoint sets or whether (eq? (string->text (symbol->string <symbol>)) <symbol>) and (eq? (string->symbol (textual->string <text>)) <text>) evaluate to #t.
* The obvious two procedures symbol->text and text(ual)->symbol.
--
Marc