skaller wrote:
> One thought is simply to allow procedures to return a value:
>
> proc f(x:int): int = {
> return x + x;
> }
>
> This is a function 'declared' to have side effects by naming
> it a proc .. it is implemented by
>
> proc f(x:int) (&px:int) {
> *px = x + x;
> }
>
> which has the same overload signature, however the return
> type is different. The compiler can reliably detect this
> and lift an application out, even if the closure is a variable.
> Its a bit hacky still, because if you wrote:
>
> proc f(x:int) (&px:int) {
> *px = x + x;
> }
>
> directly, you shouldn't be able to use it as a function
> in an expression because it isn't *declared* to return a value.
>
> The only proper solution here is to modify the type system :)
>
>
I really think that something like this would be the simplest solution.
And technically, wouldn't it decompose from this:
proc f(x:int): int {
return x + 1;
}
proc g(y:int): int {
return y + 2;
}
val z = f(g(2));
Into this:
proc f(x:int) (px:int) {
*px = x + 1;
}
proc g(y:int) (py:int) {
*py = y + 2;
}
ref tmp1 = 2;
f(2, tmp1);
// the optimizer may be able to detect that we could substitute tmp2 for
tmp1 here without breaking anything
ref tmp2;
g(tmp1, tmp2);
This pattern, as you probably know, is a common in mathematic
applications when you want to apply multiple matrix operations without
creating multiple temporaries. Supporting this pattern directly in the
syntax would be really quite useful, in my opinion :)
-e
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
