Returning none

[Michael P. Reilly]

Aahz Maruch <aahz at netcom.com> wrote:
: In article <5ORz3.14$JG1.2704 at news.shore.net>,
: Michael P. Reilly <arcege at shore.net> wrote:
:>
:>One powerful, often used construct is treating callables as first
:>class: does the callable return a value? That doesn't matter, the
:>interface needs to be consistant to work properly, and currently it
:>does.  Do we now have new functions for apply, map, filter to handle
:>"procedures"?  (Are these now procedures?)  You then have to know ahead
:>of time if the callable is a function or a "procedure".  You can't mix
:>at a non-predetermined point, functions and "procedures".  This just
:>adds to the complexity of the language and implementations needlessly,
:>removing important functionality.

: One could just as easily make the same argument about using string
: functions on numbers -- you have to know in advance that something is a
: string.  Down this path lies the Perl approach....

I don't see how.. the interface between strings and numbers are similar
("+" and "*"; more similar than with Perl, where you have a very
isoteric autoincrement) this is the polymorphism that Python was going
for and that Perl doesn't; but strings are even more similar to lists
and tuples, and have the same interface as those.

Yes, you have to know it is a string and not a number.  But this one
proposal here is to have a callable that returns some new, special
value, not two different types of callables that you could run tests
on.

  -Arcege