[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