#3 allowing procs to directly return values

open
nobody
5
2006-03-11
2006-03-11
Erick Tryzelaar
No

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 :)

Discussion

  • John Skaller
    John Skaller
    2006-03-11

    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.