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 :-)
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 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....)
thanks,
sven