On Wed, 8 Apr 2020, Sven Schreiber wrote:
I'm wondering what the value added of 'inbundle' over
'exists' is. In
principle both check for the existence of an object and return a type
code if yes.
I know that currently where inbundle(b, "m") returns 0 because m isn't
there, exists(b.m) instead yields an error. But I guess that could be
changed if wanted.
And vice versa: inbundle(a, "x") yields an error if there is no bundle
a, whereas exists(a.x) just returns 0. But are those differences really
by design or just by historical coincidence?
Good points. There's some redundancy here (particularly if we throw
in typeof() as well). We probably don't want to remove any of these
functions but some tweaking is in order. On the inconsistencies you
mention:
* I think it's OK that inbundle(a, "x") fails when there's no bundle
a -- the way I see it you're kind of committing to the existence of
the bundle in question when calling this function.
* However, exists(b.m) should be non-committal, so should return 0
if either b doesn't exist or it doesn't have anything under the key
"m". That's now fixed in git.
As for exists() vs typeof() -- they're basically the same thing
under two names: the same back-end, and exists() returns the same
codes as typeof(), though the help text is a little coy about that!
Perhaps exists() should just be documented as an alias.
Now talking of typeof(): it returns numeric type codes, which
typestr() can "translate". Not all that convenient. We recently
introduced the symbolic constants TRUE and FALSE. Would it be
overkill to introduce a few more: NULL, SCALAR, SERIES, MATRIX,
STRING, BUNDLE, ARRAY? In that case you could do things like
if typeof(b.m) == MATRIX
...
endif
(Maybe we could get away with using the same lower-case forms that
appear in declarations, but only if we can rule out syntactic
ambiguity.)
Allin