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

[David MacQuigg]

On Thu, 25 Mar 2004 00:24:34 GMT, Joe Mason <joe at notcharles.ca> wrote:

>In article <7n34609f4t6uueb79aia3km2pm68orh0u6 at 4ax.com>, David MacQuigg wrote:

>> 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 key distinction is "basic" syntax vs "extensions".  Every language
has to make tradeoffs - doing everything possible and satisfying every
special need vs. keeping things simple but more laborious for advanced
users.  Things generally start simple, then as experience accumulates,
more stuff gets added.  Thus the correlation with date you have
noticed.

My guess is that Python has maybe a dozen or so significant
"extensions" still to be added to the basic syntax.  Even if it is
"half the functionality" still to come, as you envision, it won't be
the basic half, which is already in place.

Interestingly, my argument for a consistent extension syntax is
*stronger* the more numerous we assume these extensions will be.
Imagine a hundred new extensions, with mystifying names like 'lambda',
or 'staticmethod', each with a different syntax, all woven into the
basic syntax of the language.  This would be a nightmare for new users
and those who can't spend a lot of time staying proficient.

Someone asked me in another discussion to name one feature that would
justify adding a symbol to the language.  My answer was - I can't
imagine any single new feature that would be worth the cost of adding
a symbol.  It only makes sense if the symbol is used in enough places
that it acquires a benefit for non-expert users - that benefit being a
clear signal that "This is an extension syntax.  You can probably
understand this statement by ingoring the extension.  You don't have
to learn it in your first use of the language."

With a good extension syntax, the tradeoffs will be easier.  We can
satisfy more advanced requests, while not burdening the basic user.


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

We have to assume that the developers, guided by our wonderful
discussions, will make the right choices as to what is basic and what
is not.  These decisions are made all the time in setting up defaults
for a module, chosing the most needed options in a print statement,
etc.

If it turns out that static methods become more popular than basic
methods, we have the same problem as chosing the wrong defaults in a
new module.  The fact that it *might* happen is not a good argument
that we shouldn't even *try* to make a sensible choice.  Presenting
all choices as being equal is *guaranteed* to be wrong.


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

I'm glad Python development is guided by reason, not popular vote.
And I do appreciate your willingness to engage in reasoned discussion.


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

It's not enough that the user recognize something he doesn't
understand and be able to find it in the docs.  The number of these
things can be overwhelming.  I remember the first time reading about
static methods, and not having enough time to really understand what
they were.  The time was wasted, and had I needed to work with any
code having static methods, I would have given up.

The problem is that new users need guidance as to where they should
focus their efforts in learning the language.  A properly-designed
nameless-function syntax would avoid the obfuscation of lambda
functions.  Any user who understands basic functions would have no
difficulty with such an extension.

-- Dave