On Thu, Sep 15, 2011 at 18:58:00 +0100, Tim Streater wrote:
> On 15 Sep 2011 at 18:21, Jay A. Kreibich <j...@kreibi.ch> wrote:
> > Why? It is a function call. One would expect all the parameters to
> > be evaluated, and then the function called. In almost all languages,
> > short-circuit evaluation is reserved for operators, not function
> > parameters.
>
> Really? I'd like to think that if a parameter is not used due to the
> particular logic of the function, then it's not evaluated but I wouldn't go
> into court on that :-)
No. That only applies to non-strict (lazy) languages. Of which only Haskell
and possibly Miranda and Clean have any non-trivial user base outside
academia. Note, that all those languages are functional. Combining (implicit,
general) lazy evaluation with side effects would lead to unbelievable mess as
you would have hard time telling in which order the side-effect will happen.
Many languages do allow explicit lazy evaluation either by explicitly passing
functions or by having special kind of functions, macros, that take bits of
code instead of values and return bit of code to be evaluated (Lisp, Scheme,
Perl6, D).
That said, pure SQL does not allow side-effects and built-in functions may be
implemented specially just like operators can, so it's hard to tell whether
one should expect SQL to short-circuit in coalesce(). I would definitely
expect it to short-circuit in case/when/then/else/end, but I simply would not
know in function-like-looking coalesce().
--
Jan 'Bulb' Hudec <b...@ucw.cz>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
