On Tue, 13 Nov 2012, 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.) >

> 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'd keep the new version of inbundle() and typestr(). At that point, we may scrap isscalar(), which was never "officially" supported anyway.

Ok so isscalar() was broken, ismatrix() didn't exist -- what the hell has existed and worked in that area :-)

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?

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.

On 11/14/2012 10:11 AM, Ignacio Diaz-Emparanza wrote: > >> 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 agree with deleting the issscalar() function, and I think > the argument above is an important point in favor of accepting the > modified version of inbundle() and the new typestr() function. Ok ok, I rest my case, and indeed the boolean test is a good point. Given the previous discussion, this would also imply to deprecate the other is*() functions, no?