Am 30.10.2015 um 16:40 schrieb Allin Cottrell:
On Fri, 30 Oct 2015, Sven Schreiber wrote:
> Hm, I'm not sure that's the best course of action. We had
the issue
> before that "you pay a price for the simplicity of commands". For
> example,
> var b.lagorder series1 series2
> isn't possible, either.
>
> IMHO either bundle elements (of the right type, of course) should be
> possible everywhere, or they should be banned everywhere.
I take your point; maybe we should back off on this until we've
considered it more carefully. Let me comment on this a but more generally.
...
One question is how far we want to go in this direction. It turns
out
that it's quite easy to make that extension for option-flag arguments
(or at least seems easy, there may be cases where this causes problems).
As regards bundle-members, I don't think it's going to be worth treating
them as a special case: they require an evaluation process
...
But we have a parser to handle all
those cases, so I think we should either use it or not, rather than
trying special means to detect stuff inside bundles.
Ok, so this now sounds a bit like "the mighty parser will come to the
rescue", so let's take the var-example a bit further:
<hansl-future>
bundle b
p = 3
list l = ser1 ser2
b.l = l
b.p = p
var b.p b.l
</hansl-future>
Is this possible to achieve without "dangerous" modifications to gretl
that in turn are likely to lead to subtle bugs in the future?
If not, then my opinion is to have the documented rule that bundle
members cannot be used as regular variable names in commands. (If there
are cases where it still works, well good luck with that, but it's not
part of the spec then.)
Given that the use of bundles is to move them around between functions,
a substitute feature might be a command to "unpack" all the bundle
members in one go into the function's namespace to avoid multiple lines
of trivial copying (like "p = b.p"). However, the problem here would be
possible name clashes with other function-scope variables. Perhaps the
bundle name could be used as a prefix to minimize this problem, "bin_p"
instead of "p" or something like that. But I guess this kind of
operation is tricky especially if the bundle is passed in pointerized form.
Anyway, coming back to the var-example above, if it is possible without
expecting other disruptions, then why not allow it.
thanks,
sven