Re: [Gretl-devel] gretl 1.9.11: once more on isscalar etc.
On Tue, 13 Nov 2012, Sven Schreiber wrote:
On 11/13/2012 06:33 PM, Allin Cottrell wrote:
> For now, let me just take this to the practicalities of the
> next release. If you have any interest in this, please give
> me your views on these two points:
>
> 1) The isscalar() function. This was introduced about 4 years
> ago but never documented. It has been broken (I think) for the
> past 3 years or so, until I fixed it a few days back. Should
> we drop this function? Keep it and document it? Or leave it in
> undocumented limbo? (I don't like the last option myself.)
Ok so isscalar() was broken, ismatrix() didn't exist -- what the hell
has existed and worked in that area :-)
Precisely the is* functions that are documented: islist,
isnull, isseries, isstring. People aren't too shy about
requesting features and in the 4 or 5 years since the is*
functions appeared nobody has requested any more of them,
IIRC.
> 2) My recent modification to the inbundle() function, which
> now returns an integer code for the type of the bundled data.
> Keep this modification and document it? Or revert it? If we
> keep it, I'm assuming we'd also want to keep and document the
> new typestr() function, which turns the return code from
> inbundle() into a comprehensible string such as "scalar".
I will say one last time that I don't find the need to avoid strings for
performance reasons convincing -- I mean this function would not be used
in a loop with thousands of repititions, right? And with strings the
code would be much more intuitive.
I hear you, but you can get the strings if you want them. Its
a fairly common trope in library code (OK, not equivalent to a
scripting language, but anyway) to have functions that return
a numerical code, accompanied by another function to convert
the code to a string if wanted. Also, with inbundle as it is
now, you can do a straight boolean test if you want, which you
could not do if it returned a string.
I also liked Allin's alternative suggestion to define
aliases for numerical constants like SCALARTYPE, and I
personally wouldn't consider these new reserved words as
restricting me much. (Especially now that long identifiers
can be used....)
I was just sort of floating that idea; I probably shouldn't
have mentioned it. It would be nasty to implement.
Allin