Arc Forumnew | comments | leaders | submitlogin
Simpler definition of aand?
2 points by jeff303 6467 days ago | 5 comments
in arc.arc, aand is defined thusly:

(mac aand args (if (no args) 't (no (cdr args)) (car args) `(let it ,(car args) (and it (aand ,@(cdr args))))))

but isn't this definition a bit simpler?

(mac aand args (if (no args) 't `(and ,(car args) (aand ,@(cdr args)))))

Unless I'm missing something the behavior is equivalent. Gentle replies are appreciated.



3 points by absz 6467 days ago | link

Unfortunately, your definition is broken. You just defined and, not aand. What you miss in aand is that it is bound to the previously-evaluated clause, so we have

  arc> (aand 3 (prn it) 10 (prn it) t)
  3
  10
  t
Yours, on the other hand (band), results in

  arc> (band 3 (prn it) 10 (prn it) t)
  Error: "reference to undefined identifier: __it"
. However, and is defined as

  (mac and args
    " Evaluates arguments till false is found else returns the last one.
      See also [[or]] [[aand]] [[andf]] [[andmap]] "
    (if args
        (if (cdr args)
            `(if ,(car args) (and ,@(cdr args)))
            (car args))
        't))
, which is roughly equivalent to your aand.

Also, a formatting tip: surround code by two blank lines and indent it to get it to format properly.

-----

1 point by jeff303 6467 days ago | link

Ack, OK somehow I didn't even think to read the definition of and before. Now I can see how my definition is basically equivalent.

I noticed it being bound in aand before but wasn't sure why. Your example of applying prn seems useful but are there any other common similar idioms? Thanks for the reply.

-----

1 point by absz 6467 days ago | link

Well, you can write (aand (complex-expression 'that (might return) "nil") (frobnicate it)), but I can't think of any specific examples off the top of my head. There's also aif and awhen, which do similar things, and which are probably slightly more useful.

-----

1 point by jeff303 6467 days ago | link

Nevermind - I can see this proposed version builds more complex expressions at evaluation time (builds an "and" expr even if only one arg). I guess we would prefer shorter expanded forms to shorter macro definitions?

-----

2 points by eds 6467 days ago | link

You have to be careful there. The and expression of one arg you mentioned won't cost anything because (and expr) will evaluate to expr. So you need to be sure you are looking at the final expansion, which is not necessarily what macex gives you, because macex doesn't expand nested macros.

Also, the general idea "shorter is better" doesn't really apply to expanded code, since often more optimized code is longer than simpler code, and being expanded code, it doesn't usually need to be read by humans.

Now that said, your proposed aand still doesn't work, but this particular issue isn't your problem.

-----