11:01 a.m.
Hi,
OK here's something a little embarassing, because there's a stupid
syntax mistake on my part. However, it's interesting that gretl didn't
complain about the syntax error, only afterwards:
<hansl-wrong>
loop i = 1 to 5 # of course wrong syntax, instead of 1..5
print i # complaint happens here
endloop
</hansl-wrong>
I wonder how gretl interpreted that "1 to 5" part...
thanks,
sven
1:12 p.m.
On Mon, 24 Sep 2018, Sven Schreiber wrote:
OK here's something a little embarassing, because there's a
stupid
syntax mistake on my part. However, it's interesting that gretl didn't
complain about the syntax error, only afterwards:
<hansl-wrong>
loop i = 1 to 5 # of course wrong syntax, instead of 1..5
print i # complaint happens here
endloop
</hansl-wrong>
I wonder how gretl interpreted that "1 to 5" part...
Hmm, gretl is trying to treat this as a "count" loop, with the string
"i = 1 to 5" as a candidate expression for producing the number of
iterations on evaluation. This is, I notice, an undocumented extension
of the count loop syntax (the doc says the number of iters should be a
numeric constant or the name of a scalar variable).
Anyway, evaluation of "i = 1 to 5" then fails since (first error) "i"
is undefined -- and that's actually the source of the error message,
not the attempt to print i.
What should we do? It would be easy to enforce the documented count
loop syntax -- and therefore flag a syntax error up-front in this
case. But I wonder if there's any usage of the extended count-loop
syntax out there among extant hansl scripts. The sort of thing one
might reasonably expect to work (even though it's contrary to doc)
would be, "loop K/2", "loop N-M" and such.
Allin
2:02 p.m.
Am 24.09.2018 um 15:12 schrieb Allin Cottrell:
On Mon, 24 Sep 2018, Sven Schreiber wrote:
>
>
> I wonder how gretl interpreted that "1 to 5" part...
Hmm, gretl is trying to treat this as a "count" loop, with the string
"i = 1 to 5" as a candidate expression for producing the number of
iterations on evaluation. This is, I notice, an undocumented extension
of the count loop syntax (the doc says the number of iters should be a
numeric constant or the name of a scalar variable).
Ah, I see.
What should we do? It would be easy to enforce the documented count
loop syntax -- and therefore flag a syntax error up-front in this
case. But I wonder if there's any usage of the extended count-loop
syntax out there among extant hansl scripts. The sort of thing one
might reasonably expect to work (even though it's contrary to doc)
would be, "loop K/2", "loop N-M" and such.
In principle using an expression there could indeed be useful. What
would already be helpful is gretl saying something like "failed to
evaluate loop count expression, object i is undefined", or similar.
thanks,
sven
2:18 p.m.
On Mon, 24 Sep 2018, Sven Schreiber wrote:
> What should we do? It would be easy to enforce the documented
count loop
> syntax -- and therefore flag a syntax error up-front in this case. But I
> wonder if there's any usage of the extended count-loop syntax out there
> among extant hansl scripts. The sort of thing one might reasonably expect
> to work (even though it's contrary to doc) would be, "loop K/2",
"loop N-M"
> and such.
In principle using an expression there could indeed be useful. What would
already be helpful is gretl saying something like "failed to evaluate loop
count expression, object i is undefined", or similar.
It could be _marginally_ useful; the only case when I use count loops is
when I have to time things so some repetition is needed. Otherwise,
looping without being able to access the index is pretty useless to me.
If we want to allow
loop A/B
in place of
scalar C = A/B
loop C
I'd be fine with this, provided it's not too much work for the tokenizer.
-------------------------------------------------------
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
-------------------------------------------------------
2:54 p.m.
Am 24.09.2018 um 16:18 schrieb Riccardo (Jack) Lucchetti:
On Mon, 24 Sep 2018, Sven Schreiber wrote:
It could be _marginally_ useful; the only case when I use count loops
is when I have to time things so some repetition is needed. Otherwise,
looping without being able to access the index is pretty useless to me.
If we want to allow
loop A/B
in place of
scalar C = A/B
loop C
I'd be fine with this, provided it's not too much work for the tokenizer.
If I understand correctly it's already allowed (but not documented). The
thing is that a syntax error can then lead the parser to think it's
intended as a count loop when it was a different kind of loop.
-s
9:28 p.m.
On Mon, 24 Sep 2018, Sven Schreiber wrote:
Am 24.09.2018 um 16:18 schrieb Riccardo (Jack) Lucchetti:
> On Mon, 24 Sep 2018, Sven Schreiber wrote:
>
> It could be _marginally_ useful; the only case when I use count loops is
> when I have to time things so some repetition is needed. Otherwise, looping
> without being able to access the index is pretty useless to me.
>
> If we want to allow
>
> loop A/B
>
> in place of
>
> scalar C = A/B
> loop C
>
> I'd be fine with this, provided it's not too much work for the tokenizer.
If I understand correctly it's already allowed (but not
documented). The thing is that a syntax error can then lead the
parser to think it's intended as a count loop when it was a
different kind of loop.
OK, I've found a way to present a better error message in a case of
this kind, so I guess we may as well keep the facility to accept an
expression that yields a scalar for the repetitions of a "count"
loop. (Although I agree with Jack that this is probably only
marginally useful.) In which case I suppose it should also be
documented.
Allin
2262
days inactive
2262
days old
5 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber