[E-Lang] Operators #3: Function call
Mark S. Miller
markm@caplet.com
Fri, 06 Apr 2001 19:23:58 -0700
The next Python page,
http://www.python.org/doc/current/ref/attribute-access.html doesn't seem
relevant. If I'm missing something, lemme know.
The following one http://www.python.org/doc/current/ref/callable-types.html
would have us expand
func(args...)
to
func op__call(args...)
(instead of the current
func run(args...)
)
This is a bit of a naming conflict with the rest of E. Elsewhere in E,
"call" is used for an immediate call in which the message name is an
explicit argument, such as
E call(receiver, verb, args)
Better, from my view, would be any of op__invoke, op__execute, or op__apply
(some of which have been suggested before). However, in the interests of
sticking with a preexisting convention when it's not too painful, I'm going
to stick with op__call.
Of the core data types, the only one I think should respond to "op__call" is
Lists (and therefore Strings), in order to extract sublists (which I think
corresponds to Python's slices, but which have their own syntax in Python):
list(start, bound) -> sublist containing the elements from start
inclusive to bound exclusive
list(start) -> means the same as list(start, list size() -1)
Note that the second is not currently a part of E, but is the expected
generalization of Java's String.substring() and the existence in E of the
first case.
In E currently, regions also respond to one argument function calls by
acting as a predicate, by testing the argument for membership. I think this
is a mistake, and will be replaced with an explicit message name to be
determined.
Cheers,
--MarkM