Am 27.04.2020 um 07:40 schrieb Artur Tarassow:
Am 22.04.20 um 22:11 schrieb Allin Cottrell:
> On Wed, 22 Apr 2020, Sven Schreiber wrote:
>> The two characters "id" are treated themselves as a
string, because only
>> (a) lists, (b) string arrays, or (c) strings are expected in this
>> context. No check is ever done whether "id" is an identifier for
>> something else.
>> This has to do with the somtimes ambiguous representation of a string in
>> gretl/hansl (double quotes or not). I was struggling with this some
>> years ago. I like the clarity about string literals in Python (for
>> example) better, but it has to be acknowledged that other languages like
>> bash or whatever have similar behavior.
>
> Agreed, the legacy usage of "foreach" (in fact the ur-usage),
> involving space-separated unquoted strings, seems to stand in the way
> of flagging an error in the case Artur gave.
Thanks for your clarification, Sven.
> However, we could maybe surmise that if only one such "string" is
> given the user intended it as the name of a suitable object, and flag
> an error if it's the name of an unsuitable object.
Sounds reasonable to me.
I agree - however, perhaps it should be noted that this is only OK
because strings arrays are now also accepted in foreach. Because
otherwise someboday may have created a space-separated string like
string s = "this is my string"
and the do something like:
loop foreach @s
...
When doing this programmatically it could happen that s only contains a
single substring (s == "my"), and this would have worked so far, but
wouldn't anymore in the future.
So we are effectively telling people to instead do this:
strings ss = strsplit(s)
loop foreach ss
...
(Or would 'loop foreach strplit(s)' work directly?)
Which is fine, I justed wanted to be explicit about it.
cheers
sven