Allow anything in identifiers?

Sverker Nilsson sverker.is at home.se
Thu Mar 1 07:04:30 EST 2001


David Porter wrote:
> 
> * Sverker Nilsson <sverker.is at home.se>:
> > This would be a new kind of identifiers, I suppose one
> > can make them by writing for example id <string> like in:
> >
> > id 'a>b' = a > b
> > id 'x.b' = x.b
> > alu.id'+' = lambda x, y...
> >
> > I think it could make programs easier to read by allowing
> > more evident identifiers in many cases. The extended identifier
> > syntax should not break anything, and it seems it might be easy to
> > implement...
> 
> It would break any code using the name 'id', likely a lot of code.

How? Not id <string>, should likely be on the same line, may allow
space in between. That gives a syntax error currently, except when id
is some of a few special ones like r, u, etc. Adding id (or i?) to
that set of string prefixes shouldn't break anything, if I understand
it correctly and I'm pretty sure... to prove your statement you just
need to come up with an example that would be broken so I'll not try
to refute it (more) right now.

Well thanks for the comment and giving me the opportunity to come up
with some examples of where this could be useful:

* Equivalents to the operator module would need (less) new names
  invented.  eg. operator.id'+', operator.id'<' etc instead of
  operator.__add__, operator.__lt__ (though I am just guessing about
  the latter one and I  am sure it's wrong - that's a point of the
  argument :-)

* Same holds for the corresponding class methods __add__ etc.

* Command interpreters could dispatch to functions that had obvious
  names corresponding to the actual commands.

* Variables corresponding to files with fixed name, could have
  the obvious name.

* Temporary constants could be named after their initializing
   expression, i.e. if a variable is introduced to avoid
   recalculation of a[i] in an inner loop it could be clearer if
   it was called precisely that: id'a[i]'. (Note that the extended
   identifier shouldn't incur any extra overhead in the interpreter.)

* Variables could be named in any language, with national specific
  characters in Unicode for example.

One drawback I can think of myself right now is a kind of uglyness
by using quotes but at least they make the construct stand out so it
should not be so confusing to ordinary id's. I guess there are
alternative syntaxes but I couldn't think of any better myself yet.

Sverker



More information about the Python-list mailing list