Re: Idea: Extension of function / return syntax.

[Daniel Carrera]

On 7 January 2013 15:47, Michael D. Godfrey <address@hidden> wrote:
> About return values from functions: One way to
> think about it might be to use ans.  Currently, the
> value of ans is local to the function, so
>
> function f(x,y)
> x+y
> end
> produces :
> f(1,2)
> ans
> (void)
>
> If ans were not local, the specific behavior asked for
> would (nearly) happen.

Interesting idea. With that change, one could write something like:

function foobar(a,b,c)

    if a > b
        foo(a,b)
        return
    end
    bar(b,c)

end

I would prefer to be able to write "return foo(a,b)", but this is fine too.


> By the way, Julia proudly says that you can define functions at the
> command line unlike Matlab.  They do not mention that this is just
> like Octave...

Incidentally, Matlab's inability to define functions on the command
line is one of the things I find insufferable about Matlab. For a long
time I didn't know that Octave had this ability, so I used to switch
between Octave and Python a lot. I'd use Octave as a calculator,
avoiding Python's insufferable division operator. But when I needed a
function on the command line I switched to Python because dealing with
division in Python was worth the price of having functions on the
command line.

Since then I've learned that Octave can do functions on the command
line and I've learned that you can fix Python's division with "from
future import division". So I feel much less desire to switch between
one and the other. I am still bothered by Octave's function syntax,
but I am still bothered by NumPy's array syntax.

So that is where I am today personally. This is what was on my mind
when I wrote my initial proposal. I was thinking that if Octave had a
more familiar function syntax, I would be much happier with it and
stop using Python and NumPy.

Cheers,
Daniel.
--
Lord of the rings calendar in your Linux/Unix/Mac terminal: cat
/usr/share/calendar/calendar.lotr