[Gretl-devel] Default value specification for scalar and integer arguments

Allin Cottrell cottrell at wfu.edu
Fri Jul 3 20:45:21 EDT 2015

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 

* 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.


More information about the Gretl-devel mailing list