Dear Sven, isnull Output: integer  Argument: name  ( string ) I have tried this nulldata 1 list nlist = null z = isnull(varname(nlist)) z series v1 = 1 list vlist = v1 eval vlist[1] z2 = isnull(varname(vlist)) z2 I agree with you in that isnull() should output error with a list argument, or correct 0/1 and not 0 as it does Oleh 26 жовтня 2015, 18:16:57, від "Sven Schreiber" < svetosch(a)gmx.net >: Hi, a null list somehow isn't a null object to gretl: <hansl> open denmark # dummy dataset list lh = null if isnull(lh) print "yep" # doesn't get printed endif </hansl> I actually can understand conceptually that the list 'lh' is "empty" rather than non-existing, but then I think either there should be this (new) keyword 'empty' for lists, or isnull(lh) should return True/1 in this case. I also know (and used the fact) that we have 'nelem(lh) == 0' to achieve the check I want to have, but still. thanks, sven _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Am 26.10.2015 um 19:38 schrieb Allin Cottrell: Perhaps this might be a solution, yes; see also below. I stumbled over this in real life in the context of optional function arguments, cf. the paragraph from the user guide: " Optional list arguments If a list argument to a function is optional, this should be indicated by appending a default value of null, as in function scalar myfunc (scalar y, list X[null]) In that case, if the caller gives null as the list argument (or simply omits the last argument) the named list X inside the function will be empty. This possibility can be detected using the nelem() function, which returns 0 for an empty list. " So the doc is absolutely correct and even consistent. However, the syntax itself is confusing IMO. When you call this example function myfunc() from the guide and omit the optional list argument, there is no list X. But still isnull(X) will return 0. This is in contrast to other optional argument types (as also correctly explained in the doc), and this difference is probably the most important issue here. Example: <hansl> function void noi(matrix *in[null]) if isnull(in) print "yep" # get's printed! endif end function noi() </hansl> The problem seems to be a semantic inconsistency between the "empty" concept and the 'null' property in hansl across variable types. If you mark a list argument as optional with [null], then nelem(X) == 0. But try to compute nelem(in) in my example with the matrix, then gretl spits out an error "undefined symbol 'in'"! 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. - For an empty list in general, change the corresponding keyword from "null" to "empty"; and an empty list would not be null, but of course nelem(X) == 0. - (How to deal with backwards compatibility, I don't know right now.) And BTW, I just checked the situation with bundles, which is also awkward and might need to distinguish between empty and null, too. See this example to finish off an already long message: <hansl> function void nob(bundle *in[null]) if isnull(in) # true like with matrix type print "yep" # get's printed! endif end function nob() bundle b2 = null if isnull(b2) # false like with list type print "b2 no" # not printed! endif </hansl> thanks, sven

[I've also read your other message from yesterday.] Am 26.10.2015 um 22:13 schrieb Allin Cottrell: 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")'.) 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.) ... 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?) ... 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

On Tue, 27 Oct 2015, Sven Schreiber wrote: If we ever decide to do this, I'd rather have exists() than isobj() (more intuitive name IMHO). ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

Am 27.10.2015 um 21:26 schrieb Allin Cottrell: No problem with exists() here. Given that 'null' now will get a clearly defined meaning of "empty", and it applies already to list, bundle, string, and apparently also various arrays, why not go all the way and apply it to matrix, too? Such that 'matrix m = null' would be equivalent to 'matrix m = {}'. (Currently it produces an error.) Perhaps even with series. 'series s = null' for example could mean that _all_ of its values would be re-set to NA, which would be different from 'series s = NA', which AFAIK only applies to the active sample. In this way 'series s = null' would be equivalent to: delete s series s # or series s = NA ? thanks, sven

On Mon, 26 Oct 2015, Sven Schreiber wrote: At this point I'm inclined to think that (besides any other issues), offering "null" as an initializer for lists and bundles was not a great idea. It was tempting for C coders, since NULL is a standard initializer for pointer-y objects in C. But the analogy is not very good: unlike a hansl object set to "null", a C null-pointer is not an "empty object" (e.g. a list or string in good standing but of length zero), it's a pointer to nowhere, and with a few exceptions it's not a valid function argument (many C library functions will crash if you pass a NULL pointer as an argument). So "empty" might have been a better word to choose for the hansl initializer. Whether it would be a good idea to make a change now is another question. Allin