I like Stefan's idea. In fact, this is how I've already been using Julia, precisely for scalability. I think that not having an explicit return value in a long function is just unreadable, so for long-form functions I always add return statements at the bottom. At the same time, there's no reason for return statements in f(x,y)=2x*y. Enforcing this convention will likely have positive benefits for users in the future.
On Tuesday, May 24, 2016 at 9:16:07 PM UTC-7, David Parks wrote: > > I like Stefan's long-form / short-form solution myself. > The trivial issue at hand was whether adding a simple print statement at > the end of a long-form function was going to break one of the dozens of > uses of it. > That should be trivial, but it wasn't. > The bigger the project, the bigger this problem. It's an issue of > scalability to me. > > > > On Tuesday, May 24, 2016 at 10:28:33 AM UTC-7, Stefan Karpinski wrote: >> >> The modification I've occasionally considered would be: >> >> - short-form functions implicitly return their expression value; >> - long-form functions implicitly return `nothing` unless an explicit >> value is returned. >> >> This could be implemented by automatically inserting a `return nothing` >> at the end of every long-form function body. I agree that it doesn't help >> cases where an expression like `a[:] = 1` evaluates to something >> unexpected. What it does mitigate is accidentally returning some value that >> you didn't really mean to return. That's not a huge issue since people are >> free to call the function and ignore the return value, but there is a >> hazard of people relying on accidental return values which could then >> change in the future since they were unintentional in the first place. >> >> On Tue, May 24, 2016 at 1:19 PM, Jeff Bezanson <jeff.b...@gmail.com> >> wrote: >> >>> We did it this way because it's useful in general for the value of a >>> block to be the value of its last expression (as in lisp `progn` and >>> scheme `begin`). For example, a macro might want to return some >>> statements that need to execute before finally computing its value. >>> The "implicit return" behavior falls out of this. We could maybe add a >>> check that says "you must write an explicit return", but I find this >>> to be kind of an arbitrary restriction. It also doesn't fit so well >>> with other features of the syntax. For example is >>> >>> f(x) = 2 >>> >>> allowed, or do you have to write >>> >>> f(x) = return 2 >>> >>> ? >>> >>> True, some constructs have non-obvious return values. For example in >>> >>> function set1(a) >>> a[:] = 1 >>> end >>> >>> some might assume it returns `1`, and others might prefer it to return >>> `a`. If we gave a "must write a return" error, many would just >>> reflexively add >>> >>> function set1(a) >>> return a[:] = 1 >>> end >>> >>> which doesn't clarify anything. It seems like a documentation problem >>> to me. If the meaning of a function's return value isn't clear, >>> requiring people to add redundant keywords doesn't seem like a real >>> fix to me. >>> >>> >>> On Tue, May 24, 2016 at 12:48 PM, David Parks <davidp...@gmail.com> >>> wrote: >>> > The last line of a function is its implicit return value in Julia. >>> > >>> > Can someone tell me why this is a great idea? >>> > >>> > I'm realizing a serious downside to it in reading someone else's code. >>> It's >>> > not immediately clear to me if a use of a particular function is using >>> the >>> > last statement as a return value or not. >>> > >>> > The lack of an explicit return is making the code ambiguous to read, >>> and >>> > therefore I'm searching for uses of it to understand the original >>> intent. >>> > >>> > Even if the original coder is being perfectly hygienic in their style, >>> I >>> > can't make an assumption as such. I've always though explicit over >>> implicit >>> > reigned king in code maintainability. Can someone convince me >>> otherwise? >>> > >>> > >>> > >>> >> >>
