Re: [Gretl-devel] slight inconsistency with strstr truth value
On Sat, 10 Mar 2018, Sven Schreiber wrote:
Am 09.03.2018 um 23:47 schrieb Allin Cottrell:
> So I guess in the long run I'd be inclined to disallow using
> strings as booleans in hansl,
Yeah, let's clean that up and make it easy to understand by having
clear rules. Given that it's undocumented and only has been
present for 1.5 years it shouldn't be too hard to make the
necessary changes to hansl code, such that it could be done by the
release of 2018b.
Yes, I would hope so too.
> One other perspective on this: at present we (sort of) treat
> strings as booleans on the strength of their emptiness or not.
> But this is inconsistent in a larger sense, since we don't treat
> (e.g.) bundles or arrays in that way (and I certainly would not
> want to!).
Yes, I've noticed that, too. (Again, opposed to Python, which
apparently always tries to interpret emptiness as falsehood if
needed.)
Of course, for bundles, arrays, and matrix we have nelem(). I was
also wondering why nelem() isn't working for strings. I'm aware of
strlen, and it's no big deal, but in principle in the hansl logic
I don't see why nelem("") couldn't give 0 and nelem("abc")
couldn't give 3, for example.
Alright, no reason why nelem() on strings shouldn't be (in effect)
an alias for strlen() -- unless, that is, nelem() were to count
UTF-8 code-points rather than bytes! (In UTF-8, non-ASCII characters
are coded in two or more bytes.)
Allin