Reasoning behind or vs orelse and and vs andalso?

[H Durer]

This was discussed today on the IRC channel, but it might be better to move this discussion to the mailing list:

From trying things out I gather that lfe has both "or" and "orelse" and similarly "and" and "andalso".

"or" and "and" are 2-arity functions, i.e. eagerly evaluate their arguments while "orelse" and "andalso" are macros which take any number of arguments and short-circuit the argument evaluation, i.e. they stop when the result is known.

Traditionally in Lisp, "or" and "and" were short-circuiting macros, indeed we couldn't come up with any language other than Erlang/lfe where these logic operators aren't short-circuiting.

Given that lfe is meant to be Lisp-flavoured, it feels surprising that it follows Erlang here.  I really don't see when the functional form is preferable over the macro (except of course when you need to pass a function).

Can anybody give a the reasoning behind choosing the current system?

Thanks,

  Holger

[Duncan McGreggor]

I don't have reasoning for you, since I didn't write it ... but I can share the general view of LFE development which could very well have informed the reasoning behind the current system.

LFE is definitely a Lisp, but it also definitely rests on the Erlang VM. Since the whole point of LFE was to make a Lisp that was 100% compatible with Core Erlang, many of Robert's design decisions have ensured that those coming from Erlang would have everything they had in the original dialect. I'm guessing this might explain the situation with these functions/macros in LFE.

d

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[Robert Virding]

My view on this that they are basically 2 different types of operations:

- and/or/xor are *boolean operations* which test the boolean values of *both* their arguments so it is logical to evaluate both arguments. They are also guaranteed to return boolean a value.

- andalso/orelse are *short-circuiting tests* which are generally used for control and you are not really that interested in the actual boolean value. This also reflected in that they will return the value of the last argument which need not be a boolean. So you can do `(andalso (is-foo x) (process x))` as an alternative to `(if (is-foo x) (process x))` which is more common in Erlang than in LFE.

So in this it is logical that they are different. This is also has this view (strangely enough :-)). Also another reason to use and/or for boolean operations is that they are better at catching errors. Which is always a good thing. Also you always *know* what has been evaluated, which is a good thing in a language which is controlling things and has side-effects.

So as you might understand I think the lisps have got it wrong here. Having both is better.

Of course there are other languages which have different operators: C and java have & and && and | and ||. Yes, one set is also used for bitwise operations but they are also logical operations.

The reason andalso and orelse can't be used as functions is that they are not implemented as functions. `(andalso (foo x) (bar y))` is literally expanded to:

    (case (foo x)
      ('true (bar y))
      ('false 'false))

by the compiler. So is there is no function andalso/2. Seeing Erlang and LFE functions are strict it would have to be a special form or a macro.

Robert