[nem-en] Choosing implementation according to used results

[Kamil Skalski]

I had a nice conversation on #mono:

<wolfman8k> well, i think that calling f() function should require a special 
syntax, similar to having the programmer force to catch an exception
<wolfman8k> and then inside the "catch" block, there would be variables that 
are automatically defined, the results A and B
<wolfman8k> nazgul`: my idea is that f isn't really a function, in that it 
doesn't return a value. it instead returns 2 possible options, and the caller 
is responsible for supplying the 2 code paths to respond to each
<wolfman8k> then the compiler would check if the string "A" exists in the code 
block
<wolfman8k> if it doesn't exist then then it's sure that the caller does not 
use that result
<nazgul`> ah, now I get the idea :)
<nazgul`> and it seems possible to do
<nazgul`> we already have analisys of used / unused variables, so this macro 
could use it
<wolfman8k> nazgul`: i'm thinking something like this: 
f(3) :
succcess
{
    print(A);
    // print(B);
}failure
{
    print("failure");
}

<wolfman8k> nazgul`: if you uncomment the "B" line, then a completely 
different implementation is used for the function call
<nazgul`> I see
<nazgul`> first, current syntax extender requires unique keyword before this 
expression, second - using keywords for succes / failure don't fit into 
language desing, where we have option<'a> - but this used/unused stuff is 
quite intresting
<nazgul`> wolfman8k, of course everybody can write macro of his own - but this 
is good to see, what people would like to have - for example here compiler 
should expose API for checking for unused variables

<wolfman8k> maybe instead of directly having A and B there should be a keyword 
"result" or something, and then A and B would be elements of result
<wolfman8k> result.A, result.B
<nazgul`> ok, f should define resuts in its body...
<wolfman8k> just to avoid potential name clashing
<wolfman8k> another problem is nested calls to f
<nazgul`> you mean recursive?
<wolfman8k> no, i mean if f is called in the success block
<wolfman8k> then inside the nested f's success block, when you use A it won't 
be clear if you are using the outer or inner A
<-- arc has quit (Terminando cliente)
<wolfman8k> maybe instead of "success {}" it should be "success x {}" and then 
you use x.A and x.B
<nazgul`> I see, so A in body of nested call should not trigger anything in 
upper block
<wolfman8k> that way the inner one could do "success y {}"
<wolfman8k> yeah, since they are different A's
<nazgul`> but again, WHAT f is creating?
<nazgul`> maybe we should consider how these A and B are defined
<wolfman8k> well, i'm not sure exactly how it should work, but from the 
programmer's perspective the syntax should look something like that

def f (x)
{
    ....
 
    if(foo)
        failure;
    else
        success(A=foo, B=bar);
}

<wolfman8k> that doesn't show how to delegate to f1 f2 or f3 though based on 
which results are used
<wolfman8k> still need to think about how that should work
<wolfman8k> i think it would be useful to think that f is not a function, it's 
some other construct
<nazgul`> this is how partial evaluation... or rather partial cutting should 
work - eliminate all code which is not needed (not counting side effects) to 
evaluate foo
<wolfman8k> it needs a different signature from other functions
<nazgul`> it can be function with macro attribute [Decomposed]
<wolfman8k> but you can't say that it has a signature of int -> int or 
something
<nazgul`> Decomposed macro would create different implementation of f, witch 
different results being computed
<wolfman8k> it must have a more complex signature: "int -> [success(A,B)|
falure]"
<nazgul`> hmm, variants comes in mind again
<wolfman8k> yeah, pattern matching seems like it could make things a lot 
simpler
<nazgul`> variant result { | Success { a; b; } | Failure }
<wolfman8k> the problem with pattern matching is that it's not possible to 
check which results are being used
<-- prencher (~prencher at home.prencher.dk) has left #mono
<nazgul`> well, variants can be used here only for signature purposes and 
definition of variable names - for the rest we could use macro analysing 
variables usage


Not sure if anything of this is worth implementing, but ideas are nice. And we 
need more compiler APi exposed for sure - this is a proof.

-- 
Kamil Skalski
http://nemerle.org developer