5:53 p.m.
Hi,
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) !
Instead a hansl programmer is forced to check for the null value of s1,
and then --a little absurdly-- the programmer must set it to 'null' yet
again. This feels quite stupid, to be honest. (No offense intended, of
course!) And it also wastes lines of code, making everything harder to read.
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? Basically that gretl automatically executes the
equivalent of the if-block above? I think this would make it much easier
/ more elegant to write real-world hansl code with nested function calls.
thanks
sven
6:41 p.m.
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
6:51 p.m.
One more go on this...
On Tue, Mar 21, 2023 at 1:53 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
<hansl>
function void level2 (string s2)
eval exists(s) ? s : "nothing"
end function
[ BTW note confusion between s2 and s here ]
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>
The second null-setting is never necessary. Revised version:
<hansl>
function void level2 (string s2[null])
eval exists(s2) ? s2 : "nothing"
end function
function void level1 (string s1[null])
level2(exists(s1) ? s1 : null)
end function
level1()
</hansl>
Allin
10:43 p.m.
Am 21.03.2023 um 19:51 schrieb Cottrell, Allin:
One more go on this...
On Tue, Mar 21, 2023 at 1:53 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
> <hansl>
> function void level2 (string s2)
> eval exists(s) ? s : "nothing"
> end function
[ BTW note confusion between s2 and s here ]
Yes, that was a typo, sorry. In this
example it is inconsequential,
however, because the point is what happens when "null" is passed in.
The second null-setting is never necessary. Revised version:
...
function void level1 (string s1[null])
level2(exists(s1) ? s1 : null)
end function
This was in fact also my first version of the example, but then I
decided to make it visually more explicit. I mean what you do there in
the ternary statement is also a second and explicit null-setting, that's
why you have to write the keyword "null" again. So I don't think this
serves as a valid counter-example. Or am I missing your point?
Let me get back to your answer in the first reply message: "If level2()
wants to permit skipping the s2 argument..." -- No, that's not really
the aim. The real-world problem is that sometimes a top-level function
gets some kind of input which _might_ be null, and it wants to pass on
that input to a nested-level function. This kind of "pass-through"
operation is currently not possible with some overhead checking (and/or
explicitly null-setting) code like the stuff above.
To put it differently, we don't want to skip s1 in the call to level2,
because we don't know in general what its value is going to be at runtime.
Let me give you another example which might be more realistic and thus
perhaps more useful; it's based on an options bundle that may or may not
be provided by the caller:
<hansl>
function void level1 (bundle opts[null])
bundle defaults = _(x=5)
bcheck(&defaults, opts) # causes an error in this example
end function
level1()
</hansl>
Again, to overcome this problem we could add the explicit null-setting,
as in these lines:
bundle b = null
bcheck( &defaults, exists(opts) ? opts : b )
Another way would be:
bcheck( &defaults, exists(opts) ? opts : defbundle() )
But --BTW-- what does _not_ work here for me in this bundle case are
these variants (on snapshot March 6th):
1) bcheck( &defaults, exists(opts) ? opts : null )
2) bcheck( &defaults, exists(opts) ? opts : _() )
thanks!
sven
1:49 a.m.
On Tue, Mar 21, 2023 at 6:43 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
Am 21.03.2023 um 19:51 schrieb Cottrell, Allin:
One more go on this...
On Tue, Mar 21, 2023 at 1:53 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
<hansl>
function void level2 (string s2)
eval exists(s) ? s : "nothing"
end function
[ BTW note confusion between s2 and s here ]
Yes, that was a typo, sorry. In this example it is inconsequential, however, because the
point is what happens when "null" is passed in.
Not totally inconsequential, in that passing "null" as an argument
keyword would automatically fail for level2() as written, since a
missing argument is not permitted by the function's signature.
The second null-setting is never necessary. Revised version:
...
function void level1 (string s1[null])
level2(exists(s1) ? s1 : null)
end function
This was in fact also my first version of the example, but then I decided to make it
visually more explicit. I mean what you do there in the ternary statement is also a second
and explicit null-setting, that's why you have to write the keyword "null"
again. So I don't think this serves as a valid counter-example. Or am I missing your
point?
Well, I didn't take my example as a case of "null-setting" (as in with
your string, where you created a named, empty string variable). My
case just uses "null" as a keyword, meaning "don't pass any argument
corresponding to this parameter". If one wanted something less terse
than the ternary expression, the equivalent would be
if exists(s1)
level2(s1)
else
level2()
endif
Let me give you another example which might be more realistic and
thus perhaps more useful; it's based on an options bundle that may or may not be
provided by the caller:
<hansl>
function void level1 (bundle opts[null])
bundle defaults = _(x=5)
bcheck(&defaults, opts) # causes an error in this example
end function
level1()
</hansl>
Sorry, I don't really understand this example. If opts is not supplied
there's nothing to be checked, so one should simply do
if exists(opts)
bcheck(&defaults, opts)
endif
Moreover, the second argument to bcheck() is not optional, so passing
null as a substitute is not going to work. If in context the opts
bundle is supposed to contain at least one required key + setting,
then the function whose role is to pass opts to bcheck() should not
permit null in place of opts.
However, thinking about the 3-argument usage of bcheck(), perhaps I'm
beginning to see what you mean. I need to think about it some more.
Allin
9:19 a.m.
Am 22.03.2023 um 02:49 schrieb Cottrell, Allin:
On Tue, Mar 21, 2023 at 6:43 PM Sven Schreiber
<sven.schreiber(a)fu-berlin.de> wrote:
> Yes, that was a typo, sorry. In this example it is inconsequential, however, because
the point is what happens when "null" is passed in.
Not totally inconsequential, in that passing "null" as an argument
keyword would automatically fail for level2() as written, since a
missing argument is not permitted by the function's signature.
I think we have been (just for a second) talking past each other,
because of the double meaning or usage of "null": When I said "pass
'null' in", I meant to create a string and initialize it to null (string
s1 = null), and then pass s1 to the function. That works. What you mean
is to directly write "null" in the function call. This indeed fails when
that arg does not have the '[null]' postfix.
It seems to me that this is a good example of why the double meaning of
"null" is problematic. Maybe you're right and using "null" for
initializing a new/empty string should be deprecated, instead using
s1="". And the arg postfix for strings might then become
'[""]'. (In the
function call the keyword 'null' might still be used to indicate a
missing argument.)
Well, I didn't take my example as a case of
"null-setting" (as in with
your string, where you created a named, empty string variable). My
case just uses "null" as a keyword, meaning "don't pass any argument
corresponding to this parameter". If one wanted something less terse
than the ternary expression, the equivalent would be
if exists(s1)
level2(s1)
else
level2()
endif
Right - the whole point of this thread (apart from the double-meaning
issue above) is that it feels clunky in hansl to need extra checking
code involving exists() when all we want to do is to pass through the
input. Whatever precise form this checking code takes.
Sorry, I don't really understand this example. If opts is not supplied
there's nothing to be checked, so one should simply do
if exists(opts)
bcheck(&defaults, opts)
endif
Yes, again the point is: why do we need this if block with the exists()
check in the first place when all we want to do is to channel opts to
bcheck?
Moreover, the second argument to bcheck() is not optional, so
passing
null as a substitute is not going to work.
Again yes, but: As I showed in my post, we can do b=null and then pass b
in. For you at the internal (C) level it makes a big difference whether
nothing is passed in or whether it's an empty bundle. And I clearly
understand the technical reason, given the status quo.
However, for a hansl programmer this looks slightly schizophrenic: in
verbal pseudo-code the check reads "let's see if my input argument opts
is 'null' / Oh, it is, so I need to to set it to 'null' before passing
it on!". If that sounds absurd to you, then perhaps I'm getting my point
across.
About the use of 'null' for initializing a bundle, perhaps in analogy to
your suggestion for strings, perhaps a solution would be to deprecate
the syntax "b=null" as well, and the recommended thing would be
"b=_()"
(and "b=defbundle()", of course).
(And if so, then later one would probably have to talk about
initializing other types such as arrays, too.)
However, thinking about the 3-argument usage of bcheck(), perhaps
I'm
beginning to see what you mean. I need to think about it some more.
Yes, in that case the check at the hansl level would be even more
involved, I guess.
thanks for sticking with me
Sven
9:40 a.m.
Am 22.03.2023 um 10:19 schrieb Sven Schreiber:
Am 22.03.2023 um 02:49 schrieb Cottrell, Allin:
> Sorry, I don't really understand this example. If opts is not supplied
> there's nothing to be checked, so one should simply do
>
> if exists(opts)
> bcheck(&defaults, opts)
> endif
Yes, again the point is: why do we need this if block with the
exists() check in the first place when all we want to do is to channel
opts to bcheck?
One addendum to this problem, based on real-world code: It is not
unusual that there is a middle function layer before the bcheck()
function comes into play. In a stripped-down pseudo example:
<hansl>
function void toplevel (matrix myinput, bundle options[null])
matrix someneededstuff = middlelayer(options) # fails when options
is absent
# then continue to act on myinput and someneededstuff
end function
#
function matrix middlelayer (bundle options[null])
bundle defaults = _(x = 1)
if exists(options)
bcheck(&defaults, options)
endif
# here one would do some useful stuff
return mshape(defaults.x, 2,2) # just a placeholder
end function
#
toplevel(I(2))
</hansl>
This example will currently fail at the first line inside toplevel(),
even though the bundle arg is marked as optional at all function levels!
Sure, one can insert more checking code with exists(), and that is
currently the workaround. But does it have to be that way forever?
thanks
sven
399
days inactive
401
days old
6 comments
2 participants
participants (2)
-
Cottrell, Allin -
Sven Schreiber