Re: [Gretl-devel] Default value specification for scalar and integer arguments
On Fri, 3 Jul 2015, Allin Cottrell wrote:
On Fri, 3 Jul 2015, Sven Schreiber wrote:
> I want to ask whether the following (which is working!) is actually
> according to the hansl spec. Consider the session at the end of the
> message.
>
> Hansl allows to specify the default value [0] both for 'scalar' and
'int',
> without requiring minimum or maximum values. But the way I read the
> paragraph "Function parameters: optional refinements" in the user guide,
> this would seem to be actually a syntax error. Instead for non-bool types
> it should be [::0].
Yes, it seems to me that if you just specify "int foo[0]" this should mean
that foo has a minimum of 0 but no specified max or default value; and, as
you say, "int foo[::0]" should be required to set a default of 0 with no
specified min or max.
But in fact "int foo[0]" seems to be taken as specifying a default of 0.
Presumably this should be fixed; unless perhaps there are lots of scripts out
there that rely on the undocumented and formally wrong behaviour.
> Also (and I feel like having deja-vus again) notice that in the check2()
> function an integer parameter is specified, but if the caller passes 0.5,
> there is no type error, instead the argument is converted to its integer
> component. I do not think this is obvious, is this documented somewhere?
Well, some time ago we tightened the criterion for accepting an argument as
an "int", for built-in functions, but for user-defined functions we still
have the old behaviour of truncating to int regardless. I guess the tighter
criterion should be applied to user functions too.
I've now taken a proper looks at this and have done the following in
CVS:
* For "int" parameters to user-defined functions, only arguments
very close to integers are accepted (as with built-in functions).
* The min and max fields in scalar parameter definitions are now
respected, which I'm afraid has not been the case to date.
Beyond that, I see this comment in the C code pertaining to the
parsing of the "[...]" field of scalar parameters to user functions:
/* we take a single value with no colon as indicating a default */
This does seem to be implicitly at variance with the documentation.
We have to adjust either the parser or the documentation, but which
way should we jump?
Is it more common to want to specify a default value, regardless of
min and max, or to specify a minimum regardless of max and default?
I guess the former would have to be a lot more common than the
latter to justify our current practice.
Allin