string->symbol, symbol->string

[Jonathan A Rees <JAR @ MIT-MC>]

    Date: Sun, 3 Feb 85 12:00:27 est
    From: Kent Dybvig <dyb%unc.csnet at csnet-relay.arpa>

    "symbol->string" and "string->symbol functions are not analogous to
    "list->string" or "string->list".

    "list->string" converts the same data from one representation into
    another, with no loss of information.  The same is true for "string->list",
    "list->vector", "vector->list" and "character->integer".  

There definitely is loss of information in list->vector and friends; you
lose eq-ness and location identity.  (vector->list (list->vector l))
gives a copy of the list, so rplacas and rplacds will affect different
cells.

    A symbol is more than just an alternate representation for a string.
    It can be an identifier or keyword.  Some implementations allow symbols
    to have property lists.  All of this information is lost in the conversion
    from symbol to string, some is regained in the opposite conversion.
    I tend to think of the name of a symbol as an attribute of that symbol.
    "symbol->string" is more correctly called "symbol-name".

How do symbols differ from numbers, which can also be identifiers or
"keywords," in this regard?  The way I look at things, all associations
of information with symbols are through tables not intimately tied to
the symbol itself.  To say that symbols "have" values is like saying
that integers "have" values - getting a value out of an environment,
given a symbol, is completely analogous to getting a value out of a
vector, given an integer.  "Essential scheme" intentionally doesn't have
property lists.  Symbol eq-ness is global, so property lists would
violate the desire (based on modularity considerations) to avoid global
state; and given reasonable association tables, they are unnecessary.

    Furthermore, whereas one can expect "string->list" to return a new list
    made up of unique cons-cells, "string->symbol" may return an existing
    symbol.  The name "intern" is more appropriate for this functionality.
    (Perhaps "hash-make-symbol" would be a better name.)

But character->integer (or char->ascii or whatever you want to call it)
may return an existing integer.  What is the difference?  Since symbols
are immutable objects, like numbers, it's okay that an existing one is
returned.

Reference to hashing doesn't seem very abstract to me...

    If making a unique, uninterned symbol is supported, the name "make-symbol"
    is appropriate.  

I personally don't believe in uninterned symbols (yet?), but if they
existed then make-symbol would be an okay name, maybe better than
string->uninterned-symbol, but I don't much care.

I think that the "->" convention shouldn't have such a terribly strict
meaning.  I guess it's my feeling that string->symbol and symbol->string
are acceptable even if they aren't strictly analogous to list->vector
and vector->list.

Jonathan Rees (JAR@MC)