On Sun, 20 Mar 2016, Sven Schreiber wrote:
Am 20.03.2016 um 00:50 schrieb Allin Cottrell:
>
> OK, I take Sven to be saying (and also Artur) that if there's any chance
> that renaming a series within a loop could lead to mischief, the general
> ban on using the "rename" command within loops should be maintained
> until further notice.
>
It's not so much the renaming as such. So if the solution is to say "we'll
just allow it" I guess I wouldn't mind. But I thought you were saying that
some other checks have to be introduced in order to distinguish allowed from
forbidden uses. And my worry is about the side effects of those new checks or
extra treatments.
[Note: I've put the devel-list in cc, because I guess this discussion may
get quite technical, and that we may want to continue it there, so sorry
for the cross-posting.]
I've begun to think that we may wan to introduce an option to the loop
command to distinguish between a "safe" and a "hi-perf" mode.
Let me explain: initally, the loop .. endloop construct used to imply a
simple repetition of whatever was inside, with only a few specific caveats
and checks: eg, some commands were disallowed on the ground of common
sense (eg, nulldata), some others would partially change their meaning (eg
"print" in progressive mode) etc.
This has been silently changing for a while: as Hansl has grown in
ambitions, it's become evident that sometimes you must use loops for
specialised tasks which involve very few different instructions, but
should ideally run as fast as possible. Typically, those instructiona are
the various incarnations of "genr" and, possibly, basic estimation
commands such as ols or var. Think for example of implementing a bootstrap
procedure or MCMC; you'll never need the full array of Hansl syntax inside
those: genr and user-written functions are normally all you need, but
you'll want those instruction to run as fast as possible.
In the past year or so, Allin has been working on "compiling" loops, that
is, change the way hansl handles them going from mere repetition of their
contents to a more efficient treatment. This is very nice, but very
complex, since it's very hard to optimise a few things the hansl language
provides (eg string substitution) without risking complete breakage.
Therefore, I'm now thinking about the possibility of introducing something
like a --hi-perf option to "loop", which would disallow some instructions
but would make it possible to run the allowed ones at full speed without
having to bother with too many checks. What do you guys think?
-------------------------------------------------------
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
-------------------------------------------------------