[Swift-devel] Extending the set of builtin functions with external scripts?

[Michael Wilde]

was: Re: [Swift-devel] strange behavior evaluating function call as 
trace arg

On 2/5/09 2:40 AM, Ben Clifford wrote:
> On Wed, 4 Feb 2009, Mihael Hategan wrote:
> 
>> Yes, I am. I think it's reasonable to be able to use procedures with a 
>> return arity of one like that.
> 
> yes. I think beyond that it would be nice to lose the procedure/@function 
> distinction entirely.

Yes, I agree.

On a related topic: can we make it easier for users to define @-like 
functions externally, as scripts, so that we can readily grow the 
function library, and experiment with such functions? (much like the ext 
mapper).

Users can currently define such functions in pairs: an app, searched for 
in PATH, which takes typically simple type data and returns its value(s) 
in a file, which is then read in a (compound) wrapper function that uses 
readData() or readdata2(). This works well, except for a few issues:
- not so easy to do varying number of args (must use arrays)
- cant do varying types of args (eg, hard to do a sprintf)
- need to put each one in tc.data
- it could be more elegant (eg, the code for each function today touches 
4 places: app, wrapper, tc, and the actual external code). We could make 
it 2: an extern() func, syntactically almost identical to app(), and the 
external code (ie, it bypasses tc.data)

This relates to the procedure/@function difference in the following way:

If we extend the language slightly with an "any" type declaration for 
parameter types that accepts any value, and a form of var-args, for 
example permitting @arc, @arglist[], and possibly @argtypes[], to be 
placed on the app() command line, then external functions could reflect 
as needed on their args and do pretty much anything that an 
internally-implemented function could do.  In this way the library could 
grow more readily, with simple perl, python, shell, awk, etc. scripts to 
implement them, searched for in a path like SWIFTLIB which would include 
SWIFT_HOME/swiftlib as well as user directories.

(By the way, I played with cpp as a way to #include swift library code. 
It worked well for a simple test; needs much more experimentation and 
testing. That or a similar approach looks promising).

With such extensions, we could use the app() declaration for such 
externs, and they would work exactly like any other app(), but serve the 
same purpose as built-in functions.

The builtins are faster (which is seldom needed), unthrottled (which is 
sometimes needed) and more robust (ie dont depend on external 
interpreters) which is handy for the core of the language, I guess.

Thoughts? Any interest in such a direction?

A related issue is how we want to control and shape the growth of such a 
library so that it gains the necessary power without getting unruly.

- Mike


> They used to be very different but as time passes 
> they get closer and closer to the same thing, so that pretty much the only 
> distinction at the moment is how they return their return value(s) and 
> that @functions can only return one value.
> 
>> Right. I'm aware of the nasty issue with this, but I think it's doable.
> 
> yes.
> 
>> I've started looking into it. If I don't get something in the next 8 
>> hours of Swift work, I'll drop it. I want it there because not having it 
>> is a bit unintuitive.
> 
> ok. let me know if you abandon it and I'll put it on my todo.
>