5:16 p.m.
Sorry for cross-posting, but this is very very important.
In the past few weeks, we have been working on a substantial rewrite of
the hansl interface to state space models.
The underlying computational engine is pretty much the same as before, but
the way a user can access it via hansl scripting has been completely
redesigned. The work isn't finished yet, but we're quite near completion
and we'll publish soon a document explaining the revised interface.
In fact, we're quite impatient to make the change for two reasons: (a) the
new style is WAY better than the old one under all respects: efficiency,
maintainability, generality, intuitiveness, you name it. (b) keeping both
approaches functioning at once is possible (in the git/snapshot version
you get just that, in fact), but very costly. Therefore, we'd like to drop
the old syntax as soon as possible.
Of course I hear you, Sven. This would be a MASSIVE backward-incompatible
change, much bigger than any we had in the whole history of the project.
For this reason, we'd like to have an idea of how many people out there
are using the "kalman" command in a "production" environment; that is,
hansl scripts that HAVE TO WORK. If it's just a few, we can arrange a
somewhat "ad personam" migration strategy. If there are hundreds of such
cases (but I doubt it), we'll have to find another solution.
So please speak up! The sooner the better.
-------------------------------------------------------
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
-------------------------------------------------------
11:25 a.m.
Am 01.06.2016 um 19:16 schrieb Riccardo (Jack) Lucchetti:
I'm not sure what to think of this. From what I understand, the new
approach makes use of bundles and is therefore much cleaner and more
intuitive. That's of course very good.
OTOH, I can easily think of further goodies that gretl might get in the
future and which would make a different interface/approach even more
convenient. (To be concrete, having named function arguments as opposed
to only positional arguments would sure inspire changes for many
packages.) Do we want to change the Kalman interface (or other stuff)
again once that gets added to gretl?
As I said, I'm not sure what the decision should be in this case. But
I'd say that gretl/hansl is old enough by now to make some fundamental
design decisions now and then stick to them. Right now I only have that
example with named arguments again, but I think it's a good example: Do
we ever want them, then why not now? (I'm talking about making the
decision, I know that the implementation takes time and work and cannot
happen now now now.) I can also live with the decision that it's not
worth the effort, but then I wouldn't want to see them next year and
somebody saying we have to change the Kalman interface again because of
that.
cheers,
sven
In fact, we're quite impatient to make the change for two
reasons: (a)
the new style is WAY better than the old one under all respects:
efficiency, maintainability, generality, intuitiveness, you name it.
> Of course I hear you, Sven. This would be a MASSIVE
> backward-incompatible change, much bigger than any we had in the whole
> history of the project.
4:06 p.m.
On Thu, 2 Jun 2016, Sven Schreiber wrote:
Am 01.06.2016 um 19:16 schrieb Riccardo (Jack) Lucchetti:
>
> In fact, we're quite impatient to make the change for two reasons: (a)
> the new style is WAY better than the old one under all respects:
> efficiency, maintainability, generality, intuitiveness, you name it.
> Of course I hear you, Sven. This would be a MASSIVE
> backward-incompatible change, much bigger than any we had in the whole
> history of the project.
I'm not sure what to think of this. From what I understand, the new
approach makes use of bundles and is therefore much cleaner and more
intuitive. That's of course very good.
OTOH, I can easily think of further goodies that gretl might get in
the future and which would make a different interface/approach even
more convenient. (To be concrete, having named function arguments as
opposed to only positional arguments would sure inspire changes for
many packages.) Do we want to change the Kalman interface (or other
stuff) again once that gets added to gretl?
There are no plans at present to introduce named function arguments.
Obviously I can't rule that out as a possible future development, but
I don't think it would be disruptive of interface design at the hansl
level: I assume that if we were to do that, we'd implement it as an
"invisible" layer that simply rearranges function arguments into the
correct order, inserting "nulls" or other default values for empty
slots. I think that only the user-documentation would need to be
updated, and non-explicitly named arguments would continue to work
according to the current rules.
As I said, I'm not sure what the decision should be in this case.
But I'd say that gretl/hansl is old enough by now to make some
fundamental design decisions now and then stick to them. Right now I
only have that example with named arguments again, but I think it's
a good example: Do we ever want them, then why not now? (I'm talking
about making the decision, I know that the implementation takes time
and work and cannot happen now now now.) I can also live with the
decision that it's not worth the effort, but then I wouldn't want to
see them next year and somebody saying we have to change the Kalman
interface again because of that.
Here's the sort of issue we're running into now. Jack has just spotted
a nice simplification of the Kalman interface (beyond what we've
already done to date) that is enabled by the new bundle approach.
Seems to me it's well worth pursuing, but implementing it while
maintaining the old interface will mean duplicating and
differentiating several existing internal functions, making the source
code messy and hard to maintain. This is not a very common situation,
but we've hit it here.
Allin
12:19 p.m.
On Thu, 2 Jun 2016, Allin Cottrell wrote:
> OTOH, I can easily think of further goodies that gretl might get
in the
> future and which would make a different interface/approach even more
> convenient. (To be concrete, having named function arguments as opposed to
> only positional arguments would sure inspire changes for many packages.) Do
> we want to change the Kalman interface (or other stuff) again once that
> gets added to gretl?
There are no plans at present to introduce named function arguments.
Obviously I can't rule that out as a possible future development, but I don't
think it would be disruptive of interface design at the hansl level: I assume
that if we were to do that, we'd implement it as an "invisible" layer that
simply rearranges function arguments into the correct order, inserting
"nulls" or other default values for empty slots. I think that only the
user-documentation would need to be updated, and non-explicitly named
arguments would continue to work according to the current rules.
Besides, the systematic use of bundles makes the case for named arguments
much less compelling than it would have been otherwise. Define your
function with a bundle as argument and you're done. The difference with
named arguments becomes largely aesthetic.
-------------------------------------------------------
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
-------------------------------------------------------
12:36 p.m.
Am 03.06.2016 um 14:19 schrieb Riccardo (Jack) Lucchetti:
On Thu, 2 Jun 2016, Allin Cottrell wrote:
>> (To be concrete, having named function arguments as
>> opposed to only positional arguments would sure inspire changes for
>> many packages.)
> There are no plans at present to introduce named function
arguments.
Besides, the systematic use of bundles makes the case for named
arguments much less compelling than it would have been otherwise. Define
your function with a bundle as argument and you're done. The difference
with named arguments becomes largely aesthetic.
At least it takes more LOC currently to populate the bundle with the
needed members than to pass the needed arguments.
But that's not the point here, it's not a feature request or a
discussion about it, it's about the new possibilities that such a future
change would imply, and that that might trigger another incompatible
rewrite of packages and add-ons.
-sven
3132
days inactive
3134
days old
4 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber