Re: Pass by Reference
- Posted by jimcbrown (admin) Jan 12, 2015
- 2308 views
Here's my logic: Euphoria still doesn't support functions passing back multiple values. A function can still only pass back a single value.
Agreed.
What's been added is a syntax that makes it much easier to unpack a sequence. And this is a good thing. 
Preaching to the choir.
If I write:
function foo(integer a, integer b, integer c) return 12 end function ? foo()
and try to run it, this is the result I get:
<0236>:: 'foo' needs 3 arguments ? foo()The compiler is able to clearly identify an mismatch between the two.
Though you could have optional parameters like so:
function foo(integer a = 1, integer b = 2, integer c = 3) return 12 end function ? foo()
and try to run it, this is the result you get:
0
Unlike the prior declaration of foo(), it's clear by looking at the function that the routine is intended to return multiple values, and not a single sequence. The hypothetical parser could return an error:
<xxxx>:: 'foo' returns 2 values this = foo(this, 11)
Actually, it'd be easy enough to require, and have the parser enforce, when desequencing is used with a function, that the return statement of the function be of the form "return {a, b, ...}" where the curly braces are not optional. (So you wouldn't be able to desequence a function that had "return repeat(0, 10)" for example.) Then on the other side, count out the number of values that are being desequenced in the LHS, and require any values that are being skipped to be explicitly represented with a question mark. So you'd have to have "{this, ?} = foo(this, 11)" or else it's an error. That takes care of the logic errors from "{this} = foo(this, 11)" ...
But what of "this = foo(this, 11)" ? This is how that logic error could be detected: if the function is ever used once by a desequencing operation, the parser keeps track of that and at the end goes back and spits outs an error on "this = foo(this, 11)" if it sees "{that, ?} = foo(that, 12)" somewhere else. Only if the function is never used by a desequencing call do we then allow "this = foo(this, 11)" to be valid.
That's why I keep hammering on the word intent. Otherwise, the functions aren't really returning multiple values. We've just provided a means for Euphoria to emulate the behavior. But emulation isn't the same as actually doing it, and the job of "making it work" falls on the developer.
By adding this syntax to Euphoria, you're no longer emulating the behavior, and you get the full benefit: the parser can catch logical errors because it sees what was written didn't follow the intent.
You're right - it is easier to just have the developer specify intent and let the parser enforce it. But I think we can still keep it within desequencing:
function foo(sequence this, integer update_value) integer prior_value = this[1] this[1] = update_value return using desequencing with size 2 values {this, prior_value} -- we can come up with a better syntax than this end function object spare sequence this = {50} this = foo(this, 11) -- parser blows up here since we aren't using desequencing, but we stated that we intended the caller of this function must use it. {this} = foo(this, 11) -- parser blows up here since it can tell that there's a size mismatch {this, ?} = foo(this, 11) -- parser allows this {this, spare} = foo(this, 11) -- parser allows this
It also (happily) happens to follow the syntax of other language (Lua, Python) which have functions that return multiple values.
That's a really good point. Maybe we can just make the changes to the parser to allow multiple return values - so it looks the same as the other languages and the parser can check intent - but have it implemented behind-the-scenes by replacing it with the appropriate sequence creation and desequencing calls (once the parser has validated everything of course)...
