Special symbols again (was Re: The problem with "as")

[Joe Mason]

In article <7n34609f4t6uueb79aia3km2pm68orh0u6 at 4ax.com>, David MacQuigg wrote:
>>I'm not clear on what you mean by "modified syntax".  If it's accepted
>>into the language, it's a standard syntax, so marking it with a symbol
>>makes no sense.  If you mean to mark things for preprocessors, sure, a
>>standard symbol would be a great idea, but we're not talking about
>>preprocessors here.
> 
> By "modified syntax" I mean an extension of the current standard
> syntax, e.g. the "decorators" we are now considering adding to the
> current standard function definition syntax, or the extra "arguments"
> we were discussing for the print statement.

Why is the current standard priveleged?  A few years down the road, half
of the basic functionality of the language will have special symbols in
front of it, just because it was proposed after an arbitrary date.  The
symbol wouldn't tell anything about the features it's attached to except
the relatively uninteresting fact of when they were added to the
language.

The only use I can see for such information is to mark features which
require a recent interpreter, and a single otherwise meaningless symbol
is a particulary ugly way to do it.

>>If you mean marking some bits of the language as being second-class,
>>absolutely not.
> 
> "Second class" has negative connotations.  A better description would

Yes, I used it deliberately.  Singling out syntax as non-basic makes it
second class.  What if you predict wrong?  What if it catches on like
wildfire and gets taught in Day 2 of every class?  Now your symbol has
no meaning at all, because it's part of what everybody considers basic.

> There is a similarity here in the use of comment characters to tell
> Python - "Ignore this.  It is for an external tool." - but the
> difference here is we are not talking not about external tools with
> their own command syntax.  In a sense, we are "adding tools" to the

If we're not, then I think it's an idea with almost no value at all.

> language by extending its syntax, so maybe the analogy to commented
> commands has some value.  Certainly, we wouldn't tolerate a variety of
> comment characters depending on which external tool the command was
> for.

No, but we might tolerate a comment character followed by a tag whose
first item was the tool identifier.  But like you said, different
debate.

> Consider the print statement, recently discussed in this forum (Paul
> Prescod 3/7/2004).  We can't say

Yep, I recall you bringing this up at the time and not convincing
anybody.

> The key design goal is to *mimimize* the number of syntactic
> variations we have to introduce as we extend the language.  The
> proposed @() syntax seems like it would work in *many* places, and it
> always has the same general meaning -- "This is a modification of the
> basic syntax you already understand."  To learn the details of a

That's a meaning that's too general to be of any use.  If the new syntax
is successful, it's no longer a modification, it's a basic syntax now,
so now @ means "this is either new, or not".

> particular variation, you read the manual on the particular statement
> where the variation occurs.  @(staticmethod) - read about it under
> "def".  print @(...) - read the manual on 'print'.

People will recognize things they don't understand without an @ sign, by
virtue of not knowing what they are.  @(staticmethod) won't tell me to
look under def any more than [staticmethod] will, and if I see something  
I don't recognize near a print statement, I'll already know to read the
manual on 'print'.

BTW, I favour making the decorators a single name, list or tuple, so you
can say any of the following:

    def foo() staticmethod:
        pass
    def foo() [staticmethod]:
        pass
    def foo() (staticmethod,):
        pass
    def foo() staticmethod,:
        pass

Feels cleaner in the sense that no new constructs are being added, you
can just put an existing one in a place it wasn't allowed before.
That's true even if the actual tuple, as an optimization, isn't created.
I dunno if this'd make it much harder to parse, though.  (I also like a
keyword, but I'm not hugely attached either way.)

Joe