[Swift-devel] Call function.

[Mihael Hategan]

On Thu, 2011-08-11 at 18:15 +0530, Yadu Nand wrote:
> > That's moving a big jump away from compile time type checking: you can't check the return types if you don't know anything about the function to call.
> > Does that matter for Swift? Its nice to find errors before you embark on a long run. But the strongly-typed-ness of swift doesn't otherwise seem too useful.
> Well, What I plan on doing is the first string passed to a "call" function
> will need to be a function identifier and as we translate to karajan lookup
> the type of the function and ensure that the return and input args match.
> I haven't gotten there yet, I'm still arm-twisting the parser to accept the
> new syntax.

Right. Well, Ben nails it here.

> 
> > Do you need general string based invocation? Where are you getting these strings from?
> Well, I don't understand if it makes a difference. Its easier with strings,
> because we then just need to pass them on to executeElement which
> now accepts the string identifier of a procedure.

A string is not a function. It's as simple as that. One important
quality of strong typing is that values of a type don't magically
transform into values of another type. So a string shouldn't mean a
bunch of characters in one context and a function in others.

So that means that we need function types. These will have to look like
signatures without actual bodies:

(file b) proc(file a) mycat;

That's somewhat clear. What is unclear is how (and what) we assign to
mycat.
Given a standard cat (matching the above signature), we could have:

mycat = cat;

But the issue there is that now variables and procedures appear to live
in the same namespace. So the semantics of the following code are
unclear:

int f = 2;
(int r) f(int i) {...};
x = f;

What is assigned to x?

There are three resolutions I can think of:
1. Keep them in the same namespace, treat all procs as if they were
equivalent to name = signature {body}. Disallow variables and procedures
with the same name.
2. Do not keep them in the same namespace and consider the namespace
implicit in the type. So if I assign to a non-procedure type then it's a
normal variable, and if I assign to (or use in the context of) a
procedure type, then it's a procedure. This could be confusing to a user
and it requires one to look at the context of an expression to determine
its type, which complicates the compiler code.
3. Have some special keyword that indicates the procedure namespace:
myfn= proc f (or myfn = proc(f) or myfn = proc:f).