Pensieri di un lunatico minore

14 November 2005 Lisp, Python, Ruby, Smalltalk

Linguistic symbols

There is an odd and disquiting conversation going on on comp.lang.python about adding symbols to Python. Every other language I use regularly (Smalltalk, Ruby and Lisp) has the concept of a symbol in the language. The Wikipedia contains the following definition for a symbol:

A symbol, in its basic sense, is a conventional representation of a concept or quantity; i.e., an idea, object, concept, quality, etc. In more psychological and philosophical terms, all concepts are symbolic in nature, and representations for these concepts are simply token artifacts that are allegorical to (but do not directly codify) a symbolic meaning.

In Lisp, symbols are actually objects in the system, and to quote the hyperspec:

Symbols are used for their object identity to name various entities in Common Lisp, including (but not limited to) linguistic entities such as variables and functions.

In fact, because of the structure of macros in the Lisp world, you actually have ways to generate symbols that are held as placeholders for other symbols, in the form of GENSYM. For Smalltalk, the definition is a little different, but also it is a specific type of object (from Squeak):

Symbol is a subclass of String, and understands, in large part, the same messages. The primary difference between a symbol and a string is that all symbols comprising the same sequence of characters are the same instance. Two different string instances can both have the characters ‘test one two three’, but every symbol having the characters #’test one two three’ is the same instance. This “unique instance” property means that Symbols can be efficiently compared, because equality (=) is the same as identity (==).

And in Ruby:

Simply, a symbol is something that you use to represent names and strings. What this boils down to is a way to efficiently have descriptive names while saving the space one would use to generate a string for each naming instance.

The common theme that runs through all of these implementations is that symbols are really just placeholders. We don’t particularly care what they are placeholders for, only that we can make comparison decisions based on them, and the only comparison that matters is equality. No other manipulation really matters. (This is not totally true in Lisp, but without macros, the rest vaporizes).

In the Python world, a symbol is a name for something. For example, when you define a function:

def myFunction(x, y, z):
    pass

The name of the function, myFunction is a symbol, as are the variables x, y and z. The idea exists, however because it’s never been formalized in the same way they have in other languages. Python even has a symbol module, but it’s really not the same thing.

Symbols can be thought of as a parallel namespace (or in the case of some languages, multiple name spaces, each attached to a package) with a whole set of strings in them which will always be the same. A veritable garden of global names. For example:

x = 'string'
x = :string

are two seemingly similar things in Ruby, but the second reffers to a symbol that will always be the same. The reality is that the Python world has been using strings as symbols for a very long time, but without a lot of the advantages in implementation that the exposure of real symbols can bring (lots of reduced evaluation context costs).

This entry was posted at 12:01 pm on 14 November 2005 and is filed under Lisp, Python, Ruby, Smalltalk. You can follow any responses to this entry through the post-specific RSS 2.0 feed.

The way rubyists think about symbols:

” Symbols aren’t Strings” ... “Strings are about a sequence of characters. Symbols are about naming and identifying things.”
from {|One, Step, Back|}

Go and read the whole thing very well written:
http://onestepback.org/index.cgi/Tech/Ruby/SymbolsAreNotImmutableStrings.red

Both comments and pings are currently closed.