Dear all,
isnull Returns 0 if name is the identifier for a currently defined object # from function
reference
? string nstr = null Generated string nstr ? eval isnull(nstr) 0
I think the name of the function is confusing since it may make one think it tests whether
object=null There's actually not computing problems, only potentially misguiding name
Now I think, the simplest way to proceed is enlarge help text for this function
Oleh
27 жовтня 2015, 11:21:31, від "Sven Schreiber" < svetosch(a)gmx.net >:
[I've also read your other message from yesterday.]
Am 26.10.2015 um 22:13 schrieb Allin Cottrell:
On Mon, 26 Oct 2015, Sven Schreiber wrote:
> Am 26.10.2015 um 19:38 schrieb Allin Cottrell:
>> On Mon, 26 Oct 2015, Sven Schreiber wrote:
>
>> The above looks funny, I agree. However, it clearly
corresponds to the
>> documentation of isnull():
>>
>> "Returns 0 if name is the identifier for a currently defined object, be
>> it a scalar, a series, a matrix, list, string or bundle; otherwise
>> returns 1."
Given the backwards-compatibility issues especially with 'null' as an
established initializer for lists (less so for bundles), maybe the best
solution is to rename isnull(), for example to isobj() -- or to be
precise, 'isnull(X)' would be equivalent to '!isobj(X)'.
The alias isnull() could be deprecated eventually.
(And BTW/OT: perhaps 'isobj(b.X)' could also be an alias for
'inbundle(b, "X")'.)
>>
>> Is your suggestion that one should be able to say
>>
>> list lh = empty # instead of "= null"
>>
>> ?
>
> Perhaps this might be a solution, yes; see also below.
Again, I don't think it would be wise to replace the 'null' keyword
here. But maybe 'empty' could be allowed as an alias in this context
(for lists and bundles).
(Another BTW/OT: This might also work for arrays. Saying 'matrices ms =
array(4)' is redundant in a sense because 'matrices' already means that
it's an array. This could be 'matrices ms = empty(4)' instead.)
...
> So yes, one solution could be:
> - If an optional list argument is not provided in a function call,
> make isnull(X) true there. Perhaps even raise an error on attempting
> nelem() there.
The error on using nelem() would be logically required.
Logically, yes. But I suspect it would imply a pretty hefty
compatibility-breaking problem for existing real-world functions.
(Perhaps it could be used somehow that optional list arguments are an
exception already, they have their own paragraph in the guide and they
don't have to / cannot be passed in pointer form. Maybe introduce the
'empty' keyword there as well, with 'null' as an alias for
compatibility?)
...
> bundle b2 = null
> if isnull(b2) # false like with list type
> print "b2 no" # not printed!
> endif
> </hansl>
Again, that's precisely what the doc says: "isnull()" means
non-existent. But then, either "null" should not be offered as an
initializer or isnull(), as a test for non-existence, should be renamed.
Yes, then the example would go like this:
<hansl>
bundle b2 = null # or = empty in the future perhaps
if !isobj(b2) # would be false, because b2 exists
print "b2 no" # would not be printed
endif
</hansl>
...and this would feel natural and not confusing.
thanks,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel