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
[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@lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel