It seems, there is nothing special about strstr: if "abc" print "abc" endif if (1 == 1) && "abc" print "nothing" endif if (1 == 1) && strlen("abc") print "wow!" endif It looks like 'if' can evaluate non-empty string alone as 1 but can't evaluate logical expressions with string input if "a" print "a" endif if "b" print "b" endif if "a" || "b" print "a or b" endif if "a"~"b" print "a~b" endif Oleh 8 березня 2018, 10:29:01, від "Sven Schreiber" <svetosch(a)gmx.net&gt;:

I think the matter is even outside of if: compare: eval "a"||"b" eval "a"=="b" if can evaluate expressions that can be evaluated e.g. by eval 1==1&&"abc" can not be evaluated anywhere not only as input for if Oleh 8 березня 2018, 11:26:54, від "Sven Schreiber" <svetosch(a)gmx.net&gt;:

!!! -> -o 8 березня 2018, 11:41:40, від "Sven Schreiber" <svetosch(a)gmx.net&gt;: > Am 08.03.2018 um 10:34 schrieb > oleg_komashko(a)ukr.net: > > I think the matter is even outside of if: > > > 1==1&&"abc" can not be evaluated anywhere > > not only as input for if > > Yes, that's what I meant with "stuff like ...." > > _______________________________________________ > Gretl-devel mailing list > Gretl-devel@lists.wfu.eduhttp://lists.wfu.edu/mailman/listinfo/gretl-devel

On Thu, 8 Mar 2018, Sven Schreiber wrote: Yep, either we ensure that the result of "if s", for s a string (literal, variable or expression), is consistently equivalent to "if strlen(s) != 0", or else we ban this usage as too obscure. I think my preference would be for the latter, unless there's a significant compatibility issue. Allin

On Thu, 8 Mar 2018, Sven Schreiber wrote: Assume? No. Systematic search? Not easy. Since a release is imminent I think it's better to go with fixing up what we have, at least for now. So in git the following now all work as expected -- "as expected", that is, if you know that in a boolean context a string just counts as empty (false) or not (true). <hansl> if strstr("abc", "a") && strstr("abc", "b") print "true" else print "false" endif if strstr("abc", "a") && strstr("abc", "d") print "true" else print "false" endif if (1 == 1) && strstr("abc", "a") print "true" else print "false" endif # and for good measure... printf "%s\n", strstr("abc", "a") ? "true" : "false" </hansl> Actually I'm quite happy with the strstr() case, no doubt because of the analogy with the C idiom "if (strstr(s1, s2))" as equivalent to "if (strstr(s1, s2) != NULL)" -- though we don't have true NULL (pointer-zero) in hansl because it's too dangerous, just empty strings. It's the 'if "a"' case that makes me a bit uneasy, but maybe I should just get over it! Allin

On Thu, 8 Mar 2018, Sven Schreiber wrote: Thanks for retrieving the history! No, it seems to be in limbo. There are plenty of use cases for the return value from strstr (extracting relevant substrings, carving up a string into components). But I agree, quite often one simply wants to check if a given string contains something or other. And in that context, just using strstr as giving a boolean value, as in C, is a nice shortcut. Well, wait a minute. "TRUE" and "FALSE" are pure synactic sugar for non-zero and zero, at least in all the languages I have used to any extent. The fact that we don't offer that sugar is not all that relevant. True in the limit, I suppose. Though that wouldn't work at present and I wouldn't wish to make it work. Maybe. Personally, it just rankles a bit to define a new function that returns a "collapsed" variant of what an existing function already returns. But perhaps that's just me. Allin

On Fri, 9 Mar 2018, Sven Schreiber wrote: There's no "string" type in C as such; a string is implemented as an array of "char" terminated by a NUL byte (8-bits 0, which can be writted explicitly as '\0'). But in addition a (char *) pointer have have value NULL (pointer-zero, which would be 32 or 64 bits). So in C you have two distinct boolean tests for an object s of type pointer-to-char: if (s) [ OR explicitly, if (s != NULL) ] returns 1 if s is not a NULL pointer. There are no true NULLs in hansl. Then if (*s) [ OR if (s[0]) OR if (*s != '\0') ] returns 1 if the first element of s is not a NUL byte. (This second test will reliably crash your program if s is in fact a NULL pointer, in which case it doesn't have a "first element" at all.) So there isn't a strict analogy between what C does and what hansl (currently, and not fully consistently) does. I think I got a bit carried away with the semi-analogy: "if strstr(s, p)" is a very natural idiom in C but really a bit of a stretch in hansl. So I guess in the long run I'd be inclined to disallow using strings as booleans in hansl, in which case I'd also be open to your suggestion of instring() as an (up-front) boolean twist on strstr(). 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!). Allin

On Sat, 10 Mar 2018, Sven Schreiber wrote: Yes, I would hope so too. 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

On Sun, 11 Mar 2018, Sven Schreiber wrote: On checking the current code, I'm reminding myself that strlen() does in fact count UTF-8 code points, so "a" and "<a-umlaut>" will both give 1. If we enable nelem() for strings, it would add value if it counted bytes instead (internally, use the C library's strlen rather than g_utf8_strlen). One thing we do internally when trying to get certain strings to line up correctly under translation is compare strlen and g_utf8_strlen. It's conceivable that package writers (or at least addon writers) might also want to do this. Allin

On Sun, 11 Mar 2018, Sven Schreiber wrote: Count of bytes before the terminating NUL is the convention. Strings have to end with (at least one) NUL byte in all programming languages that I know of: it's how they tell that the end was reached. It's debatable, but it seemed to me that in case of non-ASCII text it would be more intuitive in the hansl context to return the number of "characters" (code points) rather than the number of bytes. (With ASCII text there's no difference.) That could be done. Allin

On Thu, 8 Mar 2018, Allin Cottrell wrote: I'm sorry I'm chiming in only at this stage, but I find the whole issue quite confusing. In my view, Hansl should not aim at being too clever with strings. There already are many tools that are much better at that than Hansl will ever be (Python of course springs to mind). Maybe I'm being a little too conservative here, but in my eyes a Boolean expression is something that should unambiguously map to 0 or non-zero. True, "if foo" (foo being a string) can be interpreted as shorthand for "if strlen(foo)", but then the problem arises on cases like if foo || bar if foo && bar if foo * bar if foo + bar if !foo ("bar" being some arbitrary variable, such as a string but also possibly a scalar, a matrix etc), etcetera, in which we would have first to guess whether the intended outcome is Boolean or not and then act accordingly. Too complicated IMO. If it weren't for backward compatibility, I'd ban "if <string>" altogether, but at this point I would guess we could allow "if foo" (where "foo" is a named string, but not something that evaluates to a string) for historical reasons, but no more than that. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------