Proposal for adding symbols within Python

[Pierre Barbier de Reuille]

Mike Meyer a écrit :
> Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:
> 
>>Please, note that I am entirely open for every points on this proposal
>>(which I do not dare yet to call PEP).
>>
>>Abstract
>>========
>>
[...]
> 
> 
>>Symbols are objects whose representation within the code is more
>>important than their actual value. Two symbols needs only to be
>>equally-comparable. Also, symbols need to be hashable to use as keys of
>>dictionary (symbols are immutable objects).
> 
> 
> The values returned by object() meet this criteria. You could write
> LISPs gensym as:
> 
>       gensym = object
> 
> As you've indicated, there are a number of ways to get such
> objects. If all you want is symbols, all that really needs to happen
> is that one of those ways be blessed by including an implementation in
> the distribution.

Well, I may rewrite the proposal, but one good thing to have is the
hability to go from symbol to string and the opposite (as written below)
and that is not really allowed by this implementation of symbols.

> 
> 
>>In LISP : Symbols are introduced by "'". "'open" is a symbol.
> 
> 
> No, they're not. "'(a b c)" is *not* a symbol, it's a list. Symbols in
> LISP are just names. "open" is a symbol, but it's normally evaluated.
> The "'" is syntax that keeps the next expression from being evaluated,
> so that "'open" gets you the symbol rather than it's value. Since
> you're trying to introduce syntax, I think it's important to get
> existing practice in other languages right.

You're right ! I was a bit quick here ... "'" is a way to stop
evaluation and you may also write "(quote open)" for "'open".

> 
> 
>>Proposal
>>========
>>
>>First, I think it would be best to have a syntax to represent symbols.
> 
> 
> That's half the proposal.
> 
> 
>>Adding some special char before the name is probably a good way to
>>achieve that : $open, $close, ... are $ymbols.
> 
> 
> $ has bad associations for me - and for others that came from an
> earlier P-language. Also, I feel that using a magic character to
> introduce type information doesn't feel very Pythonic.
> 
> While you don't make it clear, it seems obvious that you intend that
> if $open occurs twice in the same scope, it should refer to the same
> symbol. So you're using the syntax for a dual purpose. $name checks to
> see if the symbol name exists, and references that if so. If not, it
> creates a new symbol and with that name. Having something that looks
> like a variables that instantiates upon reference instead of raising
> an exception seems like a bad idea.
> 

Well, that's why symbols are absolutely not variables. One good model
(IMO) is LISP symbols. Symbols are *values* and equality is not
depending on the way you obtained the symbol :

(eq (quote opened) 'opened)

> 
>>On the range of symbols, I think they should be local to name space
>>(this point should be discussed as I see advantages and drawbacks for
>>both local and global symbols).
> 
> 
> Agreed. Having one type that has different scoping rules than
> everything else is definitely a bad idea.
> 
> 
>>There should be a way to go from strings to symbols and the other way
>>around. For that purpose, I propose:
>>
>>
>>>>>assert symbol("opened") == $opened
>>>>>assert str($opened) == "opened"
> 
> 
> So the heart of your proposal seems to be twofold: The addition of
> "symbol" as a type, and the syntax that has the lookup/create behavior
> I described above.
> 

Indeed !

> 
>>Implementation
>>==============
>>
>>One possible way to implement symbols is simply with integers resolved
>>as much as possible at compile time.
> 
> 
> What exactly are you proposing be "resolved" at compile time? How is
> this better than using object, as illustratd above?
> 
> Suggested changes:
> 
> Provide a solid definition for the proposed builtin type "symbol".
> Something like:
> 
>           symbol objects support two operations: is and equality
>           comparison. Two symbol objects compare equal if and only if
>           they are the same object, and symbol objects never compare
>           equal to any other type of object. The result of other
>           operations on a symbol object is undefined, and should raise
>           a TypeError exception.
> 
>           symbol([value]) - creates a symbol object. Two distinct
>           calls to symbol will return two different symbol objects
>           unless the values passed to them as arguments are equal, in
>           which case they return the same symbol object. If symbol is
>           called without an argument, it returns a unique symbol.

Good definition to me !

> 
> I left the type of the value argument unspecified on purpose. Strings
> are the obvious type, but I think it should be as unrestricted as
> possible. The test on value is equality, not identity, because two
> strings can be equal without being the same string, and we want that
> case to give us the same symbol. I also added gensym-like behavior,
> because it seemed useful. You could do without equality comparison,
> but it seems like a nice thing to have.
> Now propose a new syntax that "means" symbol, ala {} "meaning" dict
> and [] "meaning" list. Don't use "$name" (& and ^ are also probably
> bad, but not as; pretty much everything else but ? is already in
> use). Python does seem to be moving away from this kind of thing,
> though.

Well, maybe we should find some other way to express symbols. The only
thing I wanted was a way easy to write, avoiding the need to declare
symbols, and allowing the specification of the scope of the symbol. My
prefered syntax would be something like :

'opened, `opened or `opened`

However, none are usable in current Python.

> 
> Personally, I think that the LISP quote mechanism would be a better
> addition as a new syntax, as it would handle needs that have caused a
> number of different proposals to be raised.  It would require that
> symbol know about the internals of the implementation so that ?name
> and symbol("name") return the same object, and possibly exposing said
> object to the programmer. And this is why the distinction about how
> LISP acts is important.
> 
>       <mike

Maybe, although I may say I cannot see clearly how LISP quote mechanism
translates into Python.