Arc Forumnew | comments | leaders | submit | silence's commentslogin
4 points by silence 5870 days ago | link | parent | on: Where are we going?

Thanks for all your hard work almkglor. I have learned a lot.

-----

3 points by silence 5944 days ago | link | parent | on: Consistency of check

Thanks for that reference.

Check is currently defined like this:

  (mac check (x test (o alt))
    (w/uniq gx
      `(let ,gx ,x
         (if (,test ,gx) ,gx ,alt))))
Can the order of evaluation problem be corrected by changing the check macro to the following?

  (mac check (test x (o alt))
    (w/uniq gx
      `(let ,gx nil
          (if (,test (= ,gx ,x)) ,gx ,alt))))

-----

3 points by skenney26 5944 days ago | link

Interesting twist. I don't immediately see any issues with doing it that way (other than making the definition slightly longer).

-----

2 points by silence 5945 days ago | link | parent | on: Sounds like pg is still working on Arc

I agree. Better to make some forward progress and then merge when the next arcN comes out.

-----

1 point by silence 5945 days ago | link | parent | on: Improve this function?

I am learning arc too and came up with this:

  (def foo (l)
     (avg:map [if (isa _ 'int) _ (foo _)] l))
drcode's version is even better. I didn't know about errsafe either. Out of curiouslity, is there a performance impact to using errsafe in this way since there will be an error for each integer in the list?

-----

2 points by drcode 5945 days ago | link

I don't know if I'd actually write something like that in a real program... not because of performance (which isn't good, but merely by a constant factor, so it's not an issue IMHO) but because the errsafe could hide other errors...

that said, the performance, in theory, might actually be better in some cases: lists (but not atoms) will be processed with one less condition.

-----