Arc Forumnew | comments | leaders | submit | rkts's commentslogin
4 points by rkts 6454 days ago | link | parent | on: Updated range with step

It seems wrong to allow a negative step if the direction is inferred. How about this:

  (def unfold (f init)
    (aif (f init)
      (cons (car it) (unfold f (cdr it)))
      nil))

  (def range-up (start end (o step 1))
    (unfold [if (<= _ end) (cons _ (+ _ step))] start))

  (def range-down (start end (o step 1))
    (unfold [if (>= _ end) (cons _ (- _ step))] start))

  (def range (start end (o step 1))
    ((if (< start end) range-up range-down) start end step))
Example:

  arc> (range 1 100 10)
  (1 11 21 31 41 51 61 71 81 91)

  arc> (range 1 -100 10)
  (1 -9 -19 -29 -39 -49 -59 -69 -79 -89 -99)

-----

2 points by rkts 6455 days ago | link | parent | on: Unquoting

The unquote character (,) is definitely ugly. I'd suggest using ~ instead, as Clojure does. Of course that means dropping the current meaning of ~, which strikes me as redundant anyway given the composition operator (i.e. ~foo is the same as no:foo).

-----

1 point by ehird 6455 days ago | link

blaise did this too

-----


And hard to understand.

-----

1 point by etfb 6457 days ago | link

The fundamental philosophy of Arc is that "hard to understand" is not an issue. It's a language for programmers who aren't afraid of learning hard things, and rarely have any trouble doing so. It's the anti-Java, if you like. So that's not really a good reason to discard the OP's idea.

-----

3 points by rkts 6457 days ago | link

I mean that it makes code hard to understand, not the language itself.

-----

2 points by rkts 6457 days ago | link | parent | on: Suggestion: partial application by default

  (mac par (f . args1)
    (w/uniq (gf gargs1 gargs2)
      `(with (,gf ,f ,gargs1 (list ,@args1))
         (fn ,gargs2 (apply ,gf (join ,gargs1 ,gargs2))))))
Partial application probably isn't as useful in Arc as it is in Haskell since many functions take an arbitrary number of arguments. E.g. you couldn't do (map (+ 10) xs) because (+ 10) just evaluates to 10.

Edit: why is there a gap at the top of my comment?

-----

1 point by Zak 6457 days ago | link

Probably not, but it's still useful as a generic way to write generator functions. Your par macro isn't working as expected for me. Is this a bug, or am I using it wrong?

  (def accgen (n) (par ++ n))
  #<procedure: accgen>
  arc> (= foo (accgen 5))
  #<procedure>
  arc> (foo 8)
  Error: "Function call on inappropriate object #3(tagged mac #<procedure>) (5 8)"

-----

1 point by rkts 6457 days ago | link

Well, I was thinking par would be call-by-value. So your accumulator would have to be something like

  (def ref (x) (obj contents x))

  (def ++ref (x (o by 1)) (++ (x 'contents) by))

  (def accgen (n) (par ++ref (ref n)))
I don't know if a call-by-reference par could be implemented using macros. I also don't know that that's a good idea, since it could lead to bugs when mutation is involved.

  (= fns nil)

  (= x 1)
  (push (par + x) fns)

  (= x 2)
  (push (par + x) fns)

  (= x 3)
  (push (par + x) fns)

  (map [_ 1] fns) => (4 4 4)  ; probably not what you want
Edit: I think the issue is that we have slightly different definitions of partial application. You are thinking of it as a sort of syntactic sugar on top of closures, whereas I (being primarily an ML programmer) am used to thinking of partial application as a function call. So that's why we have different intuitions about how it should work.

-----

1 point by rkts 6457 days ago | link

By the way, why are you bothering with generators? Arc being an exploratory language, the idea seems to be to use lists for everything, at least at first. Iterators/generators are often a premature optimization.

-----

1 point by sjs 6457 days ago | link

Did you mean to write (def accgen (n) (par + n))?

-----

3 points by Zak 6456 days ago | link

I did not: an accumulator increments. See http://paulgraham.com/accgen.html

-----

1 point by greatness 6453 days ago | link

I was thinking more like this:

  (def curry (f . args)
    (fn args2 (apply f (join args args2))))
which is pretty much the same thing except without it being a macro. I've found that with the [] syntax, currying doesn't really improve code brevity.

-----

2 points by rkts 6458 days ago | link | parent | on: The proposed : syntax

It seems more natural to me if you reverse the meanings of . and !. I wouldn't expect x.y to mean that y is evaluated.

-----

4 points by rkts 6458 days ago | link | parent | on: Show us your Arc code

I translated into Arc a little program I wrote a few months ago to compare the distribution of characters in Qwerty vs. Dvorak by hands, fingers, etc. It currently outputs text; the next step of course is to output HTML.

http://benstoker.com/code/lytcmp.arc

http://benstoker.com/code/lcex.txt

Getting the program to work was a bitch as there doesn't seem to be any debugging support at all. Nevertheless, I'm extremely pleased with the language itself.

The utility at the beginning reflects the only serious issue I ran into: objs don't seem to be able refer to themselves. I had to write a new obj macro that binds the current object to 'this'.

Also, although it's not a serious problem, I'd love to be able to refer to obj fields with a simpler syntax, e.g. x.foo instead of (x 'foo). In particular, that quote before the field name is kind of a wart.

-----