[Swift-devel] Call function.

Ben Clifford benc at hawaga.org.uk
Fri Aug 12 07:46:43 CDT 2011


On Aug 12, 2011, at 2:25 PM, Yadu Nand wrote:

> Do all procedures have the same default namespace in swift ?
> (not considering imports) 

I don't really understand what you mean by that question.

There's only one function namespace at the moment.

VDS/VDL, the predecessor to swift, had more namespace structure, but nothing has really driven that to happen in swift. (something that might drive that, for example, could be people wanting to write libraries in swift (rather than libraries to use *with* swift, but written in a different language) - so maybe they'll appear in swift too, one day)

> Sure, we
> can probably do map by writing a separate procedure for applying a function
> over every item in a list, but I think map is easier (and cooler!)

You can do a map now using foreach, without writing a separate procedure. that was one of the original "interesting things" that swift did beyond VDL.

hategan posted recently about using foreach to iterate "sequentially" over data (meaning a value in the output array can depend on everything to the left of it) which looks like it could do a lot of fold-like stuff too. (in a thread about getting rid of iterate).

(That needed the ability to access "the previous" element - when you're numbering your output array with an integer, thats easy: here-1. But when you're using 'auto', then that doesn't work (and the meaning of "the predecessor" is not immediately apparent in the case of 'auto' - there are a few different things it could mean))

What you can't do at the moment is use some function identity (be it a string or be it some richer function reference) - and given that, I find your comment:

>  If that is the case, the reason for having
> functions passed to other functions almost goes away. I can't
> imagine any scenario in which we might need that.


a bit perplexing because I thought that throwing functions around as values was exactly what you wanted to do?

-- 




More information about the Swift-devel mailing list