The problem with "as" [was "Re: PEP 318"]

[David MacQuigg]

On Wed, 24 Mar 2004 13:15:53 GMT, Joe Mason <joe at notcharles.ca> wrote:

>In article <m8o160tec35glo6ruqhkd3tk15tk75una3 at 4ax.com>, David MacQuigg wrote:
[snip]
>> Re-use of the same symbol to mean "modified syntax" in any context,
>> will avoid the Perl problem (too many symbols with idiosyncratic
>> meanings).  Beginners will learn very quickly that the special symbol
>> means "similar to the standard syntax, but RTFM if you don't yet know
>> this variation".  Locating the right documentation will be easy,
>> because it will always be at the end of the discussion on the normal
>> form of the statement.
>
>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.

[snip]
>> Does it make sense to have a general symbol for modifications of the
>> simple standard syntax?
>
>If you mean marking some bits of the language as being second-class,
>absolutely not.

"Second class" has negative connotations.  A better description would
be a "modification" or "extension" of the basic syntax, "secondary"
perhaps in the order in which beginners would learn the language, or
in the frequency with which the new syntax is used in comparison to
the basic syntax.

>It may make sense to have comment character meaning "ignore the
>keyword after this - it's for an external, mechanical tool".  Doxygen
>and others already have conventions for this (not to mention the #!
>syntax), but it would be helpful to have a common agreed-on format.  I
>think that would arise better as something the various tool vendors
>evolve among themselves, though.

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
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.

I guess its time for some concrete examples.  For the function
decorator syntax, I would use

    def func(arg1, arg2, ...) @(dec1, dec2, ...):

This is very similar to the syntax proposed in PEP 318, the
differences being the use of a special symbol, and () instead of [].
This satisfies all of the design goals in PEP 318 (which are a very
good statement of some general design goals for any extension syntax).

The advantage over what is proposed in PEP 318 is that this syntax is
more universally applicable to other statements we may want to extend.
The [] alone are good for just this one statement, so we will have to
learn a different syntax every time we want to add something new to an
existing statement.

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

print [separator = ' ', terminator = '\n'] x, y, z

because that looks like we are trying to print a list.  A special
symbol will make it clear -- this is a modification of the normal
print statement, not just another item to be printed.

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
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'.

Here is another example. Now that we have function decorators, a very
sensible thing to do is to use a "generator" decorator to make a
function into a generator.  We should then deprecate the 'yield'
keyword as it is no longer necessary, and may actually cause problems
when you change a function into a generator, but forget to change
'return' to 'yield'.

That leaves one little problem.  What do we do for the unusual case
where you want both a "generator return" and a return that terminates
the function, just as if it were not a generator.  This problem can be
solved almost without any documentation once our "modified syntax" is
well understood.  '@return' means 'this is a different kind of return'
-- in the case of generators, a return that terminates the generator.

There are lots of examples like this, but I don't want to get into a
long discussion on the merits of each example.  We have to assume that
changes and extensions will come.  I would like to discuss the idea of
using a common syntax for all these extensions.  I would also like to
avoid a debate about the @ sign ( I haven't been burned by Perl. :>)
We can choose another symbol.  The requirements are no conflict with
existing syntax, and neutral meaning.

The proposed syntax for PEP 318 is good, and I am glad it is turning
away from special words.  The proposed syntax satisfies the design
goals for extending the syntax of one statement.  I would just like to
have something more general that works for other statements as well.

-- Dave