#3 allowing procs to directly return values
This was mentioned in the mailing list at one point, so just making a
comment in the tracker so it can be tracked.
The idea is that currently the only way to directly get a value back from a
function, you have to use a fun. However, funs are not allowed to have
side effects. On the other hand, procs can have side effects, but cannot
return values. This of course can be worked around by passing in a
mutatable object into the function call.
One potential argument for allowing procedural return is that it makes
sense when wrapping external c libraries in felix. If someone sees a
function "fun foo: int -> int", they may expect that this function call has
no side effects. However, if foo is an external function, that function can
do arbitrary things behind the scenes. So it would make sense to have
that function call to be a proc.
I'm sure John has many other reasons for and against this, and can
comment on them if he feels it's important to :)
Logged In: YES
user_id=5394
At the moment the only workaround is:
proc fopen: lvalue[int] * int = "$1 = fopen($2);";
var x:int <- fopen(c"Filename.txt");
The <- notation is just syntactic sugar of course.
The fact the wrapper generator flxcc doesn't know the
semantics of the C function is not surprising.
The issues here are deep. Even a function with no
side-effects need not be pure:
var x = 1;
fun f()=>x;
print (f()); endl;
x = 2;
print (f()); endl; //oops ...
and this has serious consequences for the optimiser because
it is aggressive about inlining function calls.
BTW: this issue is assigned to everyone -- tracker has no
way to say that so leaving it open at the moment.