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.

Am 04.07.2015 um 02:45 schrieb Allin Cottrell: > On Fri, 3 Jul 2015, Allin Cottrell wrote: > >> On Fri, 3 Jul 2015, Sven Schreiber wrote: >> >> 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. Well I stumbled over this in one of Jack's functions in SVAR...

> * The min and max fields in scalar parameter definitions are now > respected, which I'm afraid has not been the case to date. Meaning the bounds weren't checked?

> /* 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. I actually do think (without proof) that specifying a default is more common, such that the parameter also becomes optional.

Although of course it is also conceivable that somebody writing [0] intends to enforce a non-negative value, this would not actually have been possible with gretl's current behavior. So keeping the behavior and updating the documentation seems the best way to me.