octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Matlab-style empty output/input arguments support


From: Jaroslav Hajek
Subject: Re: Matlab-style empty output/input arguments support
Date: Fri, 29 Jan 2010 09:59:33 +0100

On Fri, Jan 29, 2010 at 2:57 AM, Judd Storrs <address@hidden> wrote:
> On Thu, Jan 28, 2010 at 4:14 AM, Olaf Till <address@hidden> wrote:
>> This looks very nice to me. Just my 2 cents from the users point of
>> view:
>>
>>> Should
>>> [c,d] = [a,~] = myfun (...)
>>> simply raise an error?
>>
>> An error (element number 2 undefined in return list) would seem
>> logical to me. But I think one should be able to do something like
>>
>> [d, ~, f] = [a, ~, c] = myfun (...)
>
> Some additional ideas:
>
>
> 1) ~ vanishes whenever it appears on the rhs of an expression (I think
> this is what octave calls a cs-list?). Then
>
> [c,d] = [a,~] = myfun (...)
>
> would raise an error because it would be evaluated as
>
> [a,~] = myfun (...)
> [c,d] = deal(a)   <<< ERROR
>
> but this
>
> [d, f] = [a, ~, c] = myfun (...)
>
> would succeed because it is equivalent to
>
> [a, ~, c] = myfun(...)
> [d, f] = deal(a,c)
>
> I don't know if deal shares code with assignment; but, maybe all that
> needs to happen is that deal() learns to skip over ~ ?
>
>
> 2) Another option could be that ~ evaluates to an empty matrix in an
> expression. The downside is that
>
> [c,d] = [a,~] = myfun (...)
>
> would be legal and equivalent to
>
> [a,~] = myfun(...)
> c = a
> d = []
>
> and
>
> [d, ~, f] = [a, ~, c] = myfun (...)
>
> is evaluated as
>
> [a, ~, c] = myfun(...)
> d = a
> f = c
>
> Option 2 seems more disruptive, because previously a solo ~ on the
> right hand side would have been a parse error i.e. typo.
>
> I think I prefer option 1.
>

The problem with option 1 (shrinking the list) is that you wouldn't be
able to do things like
[d, ~, f] = [a, ~, c] = myfun (...)
with the obvious meaning (f would be undefined here).

I like option 2 in the sense that ~ produces [] in this context.
There's no need to allow ~ anywhere.

thanks for the suggestion. I'll wait for more opinions and unless
someone disagrees I'll probably go for this option.

regards

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]