On Tue, Mar 21, 2023 at 1:53 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
looking at some new hansl code I'm reminded again that we have a fundamental problem
for (mildly) advanced programming, I'm afraid. An example is probably the best way to
show what I mean:
<hansl>
function void level2 (string s2)
eval exists(s) ? s : "nothing"
end function
function void level1 (string s1[null])
if !exists(s1)
string s1 = null # this second null-setting is necessary
endif
level2(s1)
end function
level1()
</hansl>
What's the problem here: In the level1 function the arg s1 gets a default
'null' value, but this kind of null value cannot be passed on to another function.
(Gretl complains if you comment out the if-block.) Note that this is true even though the
level2 function properly handles the possibility that its arg s2 might be 'null'
(== might not exist) !
If level2() wants to permit skipping the s2 argument it must declare a
null default for that parameter; it's not correct as written. If its
signature were
function void level2 (string s2[null])
then level1 would not have to concoct an empty string to pass in; a
call as level2() would be OK.
Wouldn't it be possible that for every function argument --I
know, except for the list type with its special role-- that has a null value from the
outer scope, this null value is automatically "copied" to the function's
inner scope?
In a function call, a "null" argument means a non-existent one.
There's nothing there to copy. It would be possible to change the
semantics such that if no argument is supplied gretl automatically
creates an empty object of the right sort under the name of the
parameter, but that would be radically backward-incompatible. An
alternative that might be more palatable would be to add something
like that facility with new syntax. So, for example, you might say
function void foo (string s[""])
or
function void bar (matrix m[{}])
to allow non-null but empty string or matrix arguments.
Allin