curly-brace-aphobic?

[Quinn Dunkan]

On Mon, 29 Jan 2001 22:07:49 GMT, Rainer Deyke <root at rainerdeyke.com> wrote:
>"Quinn Dunkan" <quinn at bolivar.ugcs.caltech.edu> wrote in message
>> So even in a language where functions are the major important element,
>> efficiency dictates a data-oriented view.  And python is pretty
>data-oriented
>> anyway, so a functional representation would be out of character.  And
>> mutation is important in python, while a functional representation gives
>no
>> opportunity for that.
>
>None of these is really a compelling reason for using '[]' instead of '()'
>for access.  There is no efficiency difference in Python because both are
>implemented as (hidden) method calls, and languages like C++ allow 'f(5) =
>5;'.  Is there any good reason for function calls to use a different syntax
>than mapping/sequence element access?

Oh, so you mean "why not make the function-call *syntax* double for dictionary
access"?  Well, easy, because we have a dictionary access syntax already.

In python, as in just about all OO languages, [] just a method call, like '*',
'+', etc.  A function/method call is *not* a method call, because you'd never
get out of that little sinkhole.

If you're going to use function syntax, you should use function semantics, and
functions (AFAIK) are just about always immutable.  Otherwise you are writing
self-modifying code (and I'm sure in python it's possible to go mangle
func_code.co_code, but you're not supposed to do that in polite company).  I
don't know any languages where self-modifying code is the norm, so I'm used to
thinking of functions as things that you don't reach inside of and change at
runtime.

It's true, if you write a class that uses __call__, you can make it look like
a function call.  You can then mutate the class, and it looks like you're
mutating a function.  But you can make lots of weird looking syntax by abusing
__getattr__, __getitem__, __call__, and the like :)  I mean, I could
also understand a function that holds a static pointer (oops, slipped into
C-land) to some dict which is mutating, and thus gives you different values.
But then it's the dict, not the function, doing the mapping, so making it
*look* like the function is doing the mapping is a lie.

Also, if you think of a dict as a function mapping keys to vals, *all* you can
do is get a val from a key.  The only way to check for the existence of a key
is have the function return a tuple (error_flag, possible_val).  There's no
way to get all the keys, except remember them in another function (mapping
integers or some known sequence to keys).

If C++ allows 'f(x) = y;', then C++ is truly weird.  What is *that* supposed
to mean?  'f(x)' returns a value, and assigning to a value makes no sense.
You assign to variables, not values.  I could understand '*(f(x)) = y;', but
the only way I can see to get 'f(x) = y;' to do what you want is to have 'f'
return an lvalue.  Icon does stuff like that, but it has an excuse: it's icon.
Just out of curiosity, what is the type of the C++ 'f' function above (and
don't say "cpp macro" :) ?  It's likely C++'s idea of assignment is one I'm
not familiar with.

In any case, python has a SyntaxError for that:

SyntaxError: can't assign to function call

And it's the 'no traceback' flavor of SyntaxError, which means it's for real
:)