Re: Pass by Reference
- Posted by DerekParnell (admin) Jan 05, 2015
- 2653 views
The statement has value,
Of course, but only when seen in light of other things. It doesn't stand on its own; it has no intrinsic value. It needs supporting arguments.
but I usually start with the opposite question: why should I force other people to learn a new syntax?
So that every programming language is not the same. For instance, which syntax ought we base Euphoria on? There are lots of options - each with their own flavor of syntax.
It's not that should never happen, but all things being equal, there should be a good reason for doing so.
Yes! A good reason is why we should be doing anything. Both in following the syntax pattern of another language or when striking out in new ways.
I apologize for being "late to the party" on this, but consider the two options:
function foo() return 1, 2, 3, 4 end function a, b, c = foo()
vs.
function foo() return {1, 2, 3} end function {a, b, c, d} = foo()
Obviously, the first can be verified as incorrect by the parser.
The second can only be determined to be wrong at runtime, and will result in a crash.
Unlike indexes, there's no way to check for this error - you can't see how many values a function is returning. So the use of this syntax is intrinsically unsafe, and there's no way that I see to make it safe.
Am I missing something here?
Yes, you might be missing out on something here.
Firstly, it is not intrinsically (sorry - that word again) an error or mistake to ignore some returned function values. It is also not necessarily a mistake to present more variables for assignment than are needed. The parser cannot guess the intention of the code writer.
Euphoria's implementation does this ...
- When given more right-hand-side (RHS) values than there are LHS variables, the extra values are silently ignored.
- When given more LHS variables than there are RHS values, the extra variables are silently ignored.
- It allows omitted variables in the LHS set, which permits the coder to ignore selected returned values.
This implementation gives capabilities and responsibility to the coder. We are on our way to avoid treating coders as children, in need of protection from themselves.
And this brings us back to the original topic ... PBR, when used responsibly, is as safe as any other coding paradigm. So why not allow it in Euphoria?
On the plus side, PBR can make some coding simpler to write, and can improve the performance of some algorithms. It could also make the porting of code from other languages to Euphoria easier.
On the down side, PBR will make optimization harder to do and probably make some optimization choices impossible, thus as a side-effect, reducing the current performance of applications.
PBR is never necessary. The current pass-by-value can achieve the required results. Though sometimes this would require more code to be written and may also hamper performance of some things.
The most compelling reason to disallow it in Euphoria is it would transform the language into something that is no longer Euphoria. So that would be a judgment call - an matter of opinion.
Another point, is that the current implementation of Euphoria would have to have a massive and major rewrite due to all the pass-by-value assumptions built into the back-end and the generated IL code. So even if we agreed to allow PBR, it might be impractical to implement it now. Unless someone wants to start a new implementation from scratch.
