Return values considered harmful
One of the first really controversial realizations I had was that return values are bad. Don’t get me wrong, I utilize them hugely because current language's syntax gives a tremendous flexibility with the return value. However as other people besides me have noticed is that there is some problems when it comes to multiple return values. In order to do that you have to return struct’s and suddenly the syntactical elegance starts to vanish. Syntax sugar may mend this, but to me it does not solve the core of the problem.
My take? Return values are bad, because they reduce reusability. Well a rephrase or precision may be in place - functions are bad. A procedure can easily return a value trough a reference and this is the core of the argument: Designers choose to return values in many different ways - so users of API's (well - me) get annoyed about jumping through (different) hoops to use them.
Solution: abolish return values i.e. functions. Then add syntax sugar to re-introduce them.
This is another way of describing data flow programming. Alas usually dataflow programming takes elaborate graphical user interfaces. Dawn will try to allow dataflow programming to be specified in a somewhat understandable syntax, provide syntax sugar so programming can look like it does today, while still allowing for some graphical user interface to be built on top of the syntax.
My take? Return values are bad, because they reduce reusability. Well a rephrase or precision may be in place - functions are bad. A procedure can easily return a value trough a reference and this is the core of the argument: Designers choose to return values in many different ways - so users of API's (well - me) get annoyed about jumping through (different) hoops to use them.
Solution: abolish return values i.e. functions. Then add syntax sugar to re-introduce them.
This is another way of describing data flow programming. Alas usually dataflow programming takes elaborate graphical user interfaces. Dawn will try to allow dataflow programming to be specified in a somewhat understandable syntax, provide syntax sugar so programming can look like it does today, while still allowing for some graphical user interface to be built on top of the syntax.
Labels: dawn, programming
posted by phook at
12:31 AM
6 Comments:
You know, I actually used to agree but for a completely unrelated reason: namely, that meaningful return values (other than error codes) would encourage sloppy code (i.e. using function return values directly inside expressions without checking).
Of course, now we have exception handling so the above doesn't really apply that much any more.
Cheers,
Antonello (yes, your old colleague :-)
Well, Antonello - there will be another rant against exceptions later ;-)
boost::tuple<string, int> my_function(int r);
or haskell,
my_function :: int -> (string, int)
that's what I think about multiple return values!
The problem with multiple return values is that some of them are optional. And directing the output (return) with the program flow allows for runtime optimization by the not returned optionals handling code is not executed.
Variable return types sounds like what you dont like. I think return values should be the only way to get computation out of a piece of code.
A function should have a single emitted type. That means no nulls, ever.
I don't know what it is but there should be something between a NULL/None/Nil and an exception. Exceptions themselves are multivalued and I think this is a problem. They basically fall into two categories fatal and retryable. The retryable ones forming a sort of back tracking mechanism. With the backtrack being an exceptional IF.
try:
code
except:
exceptional code
vs.
EIF:
code
DOTHIS_AND_RE_ENTER:
new state entry
this isn't flushed out ...
My rant against return values are a little theoretical since it is based on the paradigm "push result to stack, return". I want the values to travel through a call/cc an no other way. Since you can "return" values to a earlier scope, the result can be return as before, but the difference is that it does not have to return it to the caller but can send it to someplace else.
Your comment about exceptions are something like I address in later posts. The only general error handling mechanism I've found is timeout. So a timeout "exception" will default to being handles as a retry. Not flushed out either :-)...
Post a Comment
<< Home