Am 22.04.2020 um 07:56 schrieb Artur Tarassow: > Hi all, > > I've detected a weird gretl behaviour when trying to apply the "foreach" > loop type over vector entries. Loop index "i" is printed very round but > the printf-command in the loop-block is only shown at the very last > iteration for the very first iteration. Actually I thought this use isn't supported.

To be a little clearer (perhaps), Artur's code

translates to the following: <hansl> matrix id = seq(1,3)' smpl full eval id smpl firm == 1 --restrict printf "\n%.0f -- %d\n", 1, min(firm) </hansl> and as such the output is correct.

Am 22.04.20 um 14:27 schrieb Allin Cottrell: > On Wed, 22 Apr 2020, Allin Cottrell wrote: > >> On Wed, 22 Apr 2020, Sven Schreiber wrote: >> >>> Am 22.04.2020 um 07:56 schrieb Artur Tarassow: >>>> Hi all, >>>> >>>> I've detected a weird gretl behaviour when trying to apply the >>>> "foreach" >>>> loop type over vector entries. Loop index "i" is printed very round >>>> but >>>> the printf-command in the loop-block is only shown at the very last >>>> iteration for the very first iteration. >>> >>> Actually I thought this use isn't supported. >> >> It's not supported. What Artur is seeing is the effect of gretl >> treating id as a string (matrices not being accepted). There's only >> one iteration because only one string: "eval $i" prints id (a column >> vector); the number i equals 1 on the single iteration. Thanks for the clarification, Allin. But then, should gretl not throw an error of the foreach-loop is feeded with a matrix which is not being accepted?

On Wed, 22 Apr 2020, Sven Schreiber wrote: > Am 22.04.2020 um 19:09 schrieb Artur Tarassow: >> Am 22.04.20 um 14:27 schrieb Allin Cottrell: >>> On Wed, 22 Apr 2020, Allin Cottrell wrote: >>> >>>> On Wed, 22 Apr 2020, Sven Schreiber wrote: >>>> >>>>> Am 22.04.2020 um 07:56 schrieb Artur Tarassow: >>>>>> Hi all, >>>>>> >>>>>> I've detected a weird gretl behaviour when trying to apply the >>>>>> "foreach" >>>>>> loop type over vector entries. Loop index "i" is printed very round >>>>>> but >>>>>> the printf-command in the loop-block is only shown at the very last >>>>>> iteration for the very first iteration. >>>>> >>>>> Actually I thought this use isn't supported. >>>> >>>> It's not supported. What Artur is seeing is the effect of gretl >>>> treating id as a string (matrices not being accepted). There's only >>>> one iteration because only one string: "eval $i" prints id (a column >>>> vector); the number i equals 1 on the single iteration. >> >> Thanks for the clarification, Allin. But then, should gretl not throw an >> error of the foreach-loop is feeded with a matrix which is not being >> accepted? > > 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.

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.