Is it? In all the programming languages I use, the colon is followed by
the return type (which for iif is str).
my claim of mainstream-ness, was mainly meaning the ": in => out" order
(one example would be most ML languages, Typescript, Java...) as opposed
to ": out <= in" which I haven't seen being used so far
Of course the '=>' also implies
return type and now I'm seeing two return types there.
[...]
I think it's pretty clear if you look at the usage in a config. Example
from my production config:
ssl_fc,iif(https,http)
That works like the pipeline operator in shell or various programming
languages. Effectively the 'ssl_fc' result acts as the first parameter,
it's just written a little differently.
I think we're just seeing it in a different way
I see converters (and shell pipe operations for that matter) as
functions being chained, so their individual types must be those of a
function (ie: in => out) and cannot be "str", since that is the type of
a value
Running with this on the example of shell pipes, where the fact that
things usually also support these forms:
tool [...args] file
tool [...args] -
is interpretable as a convenience parenthesis-less form of:
(tool [...args)(file)
(tool [...args])(-)
And the left-side portion of the pipe (not sure if that has a precise
name?) is not an implicit first argument to the right side, but rather
the only argument of a nameless function defined on the right side
In that view then
> var x = iif("foo","bar")
here x is a a function, of type bool => str
> var y = x(true)
and y is the result of giving a bool to a bool => str, and thus an str
> ssl_fc,iif(https,http)
is then pretty much akin to iif(https,http)(ssl_fc)
and that is why iif(str,str) being "bool => str" seems sensible to me
Now one can be pedantic and then argue to write it like this:
iif: (str,str) => (bool => str)
which is what many ML languages go with, and has some elegance, but is
terrible for readability and that I wouldn't defend
iif(str,str): bool => str
hides the type of the "important" parameter in the middle (and has the
colon = return type problem).
That's a fair point admittedly; maybe I've just grown too used to that
downside
iif(str,str): str <= bool
at least has the parameter on an outer position, but the order is still
reversed from the config.
fwiw while I said it seems to be an unusual notation order, it does have
the benefit of being clear, indeed
iif(bool,str,str): str
is reasonably similar to the config, but not identical
The similarity is specifically what I dislike about it, as it does seem
a lot like this
http-request set-var(txn.proto) iif(ssl_fc,https,http)
should be a valid config line
or at least I think that wouldn't be entirely unreasonable to think that
at first glance
bool,iif(str,str): str
which I didn't mention before might possibly be the best choice?
I do quite like that
Best regards, and thanks for the bike-shedding exercise :D
Tristan
