"Chris Uppal" wrote:
> Petr Prikryl wrote:
>
> > for element in aCollection:
> > if element > 0:
> > return True
> > return False
>
> [I'm not sure whether this is supposed to be an example of some specific
> language (Python ?) or just a generic illustration. I'll take it as the
> latter, since it makes my point easier to express. I'll also exaggerate,
just
> a little...]
Sorry, I do not know Smalltalk, but this was meant as the transcription
of your...
| E.g. consider the Smalltalk code (assumed to be the body of a method):
|
| aCollection
| do: [:each |
| each > 0 ifTrue: [^ true]].
| ^ false.
into Python
> But now, in order to hack around the absence of a sensible and useful
> feature -- /only/ in order to do so -- you have added two horrible new
> complications to your language. You have introduced a special syntax to
> express conditionals, and (worse!) a special syntax to express looping.
Not
> only does that add a huge burden of complexity to the syntax, and
semantics, of
> the language (and, to a lesser extent, its implementation), but it also
throws
> out any semblance of uniformity.
I guess that it is not me who is confused here. The subject clearly
says that the thread is related to Python and to lambda supported
by Python. It was only crossposted to other groups and I did
not want to remove them -- other people may want to read
the thread in the other newsgroups.
So, I did not introduced any horible syntax, nor looping
construct that would look strange to people used to
classical procedural languages. The lambda syntax
in Python is the thing that could be viewed as a complication,
not the "for" loop or the "if" construction.
If you take any English speaking human (even the non-programmer),
I could bet that the Python transcription will be more understandable
than your Smalltalk example.
> E.g. in Java there's an unresolved, and irresolvable, tension between
whether a
> failing operation should return an error condition or throw an exception
[...].
It is more a design problem than the language problem. And it is also
the implementation problem (i.e. what is the price of exceptions
in comparison with the other code). In Python, the exceptions
are intesively used.
> E.g. can you add three-way comparisons (less-than, same-as, greater-than
to,
> say, Python with corresponding three-way conditional control structures to
> supplement "if" etc ? Are they on a semantic and syntactic par with the
> existing ones ? In Smalltalk that is trivial (too trivial to be
particularly
> interesting, even), and I presume the same must be true of Lisp (though I
> suspect you might be forced to use macros).
Such built-in function already is in Python. But you could add it
by hand if it were not:
def cmp(x, y):
if x < y:
return -1
if x == y:
return 0
return 1
and the "if" supplement (the "switch" or "case" command) could be
replaced easily in Python using the hash-table (dictionary) structure.
> I should say that if your example /is/ in fact Python, then I believe that
> language allows fairly deep hooks into the execution mechanism, so that at
> least the "for" bit can be mediated by the collection itself -- which is
better
> than nothing, but nowhere near what I would call "good".
It is a dual point of view. Should the collection be passive data, or not?
I believe that the "pure" object oriented view (there are no functions,
only the object methods) is not very practical and does not reflect
well the big part of the reality that is simulated by programs.
Python and C++, for example, allow mixing functions and objects.
You should try Python. The "for" construct iterates through
a sequence or through all values of the generator, thus making
the for loop much more generic than for example in C or other
languages.
Every language forms the way of thinking. Every language has its strong
and weak points. Every language has its followers and haters.
Not every language is practical enough to fly around the Earth
in the space ship.
pepr
(Sorry for my broken English.)
--
http://mail.python.org/mailman/listinfo/python-list
