[Swift-devel] Call function.

[Yadu Nand]

> 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.

> 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.

> If you want to preserve type checking, then in your example in your message, you could use first order function references (eg: functions in Haskell, function pointers in C) which can carry their type with them.
>
> Your example might then look like:
>
> int assoc_array [ string ] [ int ];
> assoc_array[do_x][1] = 1000; assoc_array[do_x][2] = 1001;
> assoc_array[do_y][1] = 5000;assoc_array[do_y][2] = 5002;
> foreach i in assoc_array {
>     foreach vi  in assoc_array[ i ] {
>            call ( i , vi  );
> }}
>
> All I did there was remove the quotes, and make each function usable as a variable name (which happens in other languages too - both C and Haskell).
>
> The return type of call( f, ...) is then the return type of f, and the type of other parameters of the call are the type the other parameters of f.

I don't know enough to actually comment on that, I think.

> That's making the type system more fancy, though, in a way that might not actually make this more useful for users doing actual things. (but I don't know what your real application use case is).
> It also excludes the use case of the function names really being dynamic - for example, something like:
> s = read(file_containing_a_function_name);
> call(s,4);
> Is that a use case you expect?
I don't understand this example.

What I need is a way to pass functions to other functions.
In the map , reduce , fold style functions we need to pass
a function and the list of items to operate on. I'm trying to
make that possible here. The end result I'm looking for is
the map-reduce style.


-- 
Thanks and Regards,
Yadu Nand B