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