Extending Python Syntax with @

"David MacQuigg" <dmq at gain.com> wrote in message
news:s2vu409dio5vc9ndl81dcinteagrkpntf5 at 4ax.com...
> Seems like we need a simple way to extend Python syntax that doesn't> break existing syntax or clash with any other syntax in Python, is> easy to type, easy to read, and is clearly distinct from the "base"> syntax.  Seems like we could put the @ symbol to good use in these> situations.  Examples:

There is indeed a cost to adding new keywords and operators;
it's possible that existing programs will break. It's quite possible
to design a language where this wouldn't happen, but Python is
not that language.

As it turns out, there is one very simple key to a language
with keywords where adding new ones won't break existing
programs: put them in a lexically distinguishable namespace.
It happens that solution is quite unpleasant to work with -
unless it's supported by a syntax aware editor/IDE. Someday
people will get over their attachment with being able to write
programs with any old text editor that happens to be lying
around, and being able to print their programs without
needing a special formatting program, but that day isn't today,
and I doubt if it's tomorrow.

The problem with adding new operators is a quite different
issue. It arises from the language designer trying to be too
nice to the developers. If the lexer simply collected the longest
possible string of special characters *before* checking if that
collection of special characters made a valid token, and declared
a syntax error if it didn't, then there would be no difficulty with
adding new operators.

That solution is also fairly unpleasant: we're a bit too used to
being able to string special character operators together without
separating them with white space. Again, an intelligent editor/IDE
would help here, too.

An intelligent editor/IDE would also make it possible to add
any of the numerous mathematical symbols from the Unicode
set easily: it could adjust for the developer's preferences in
entering them, and would, of course, display them properly.

I am, I suppose, getting old and cynical enough to have quit
expecting anything quite so radical as a language that actually
expectes the editor/IDE to pull its share of the work.

John Roth