Hacker News Reader

Comment by georgewsinger | Hacker News Reader

What are the core features that differentiate Arc from other lisp dialects?

If you take a look at the code for HN written in Arc, you can compare it against other Lisp dialects. I point to this as it is possibly the most widely-used and familiar application to most here written in Arc.

https://github.com/wting/hackernews

This is a great place to start with understanding Arc, as the jump to Anarki (an Arc fork) will make more sense as it comes bundled with News - a Hacker News style app - which is fun to play with if you have experience with HN and want to try a variation of this site.

To me, one of the most fundamental features of Arc is taking the unification of code and data much further. I don't know of other Lisps that do this! K is another language that does.

  arc> (= l '(1 2 3))
  (1 2 3)
  arc> (= f [+ _ 1])
  #<fn: f>
  arc> (map l '(0 1 2))
  (1 2 3)
  arc> (map f '(0 1 2))
  (1 2 3)

Clojure’s maps, sets, and vectors are all functions.

First public release of Arc came not long after Clojure.

Clojure is definitely better thought out as a language, and while Arc has some interesting ideas around web development, it also doesn't have a module system, so everything is just loaded into the same global namespace, which is pretty insane.

Keep in mind that Arc is the start of something with long-term goals; further, it's part of a lifecycle that didn't necessarily start with Arc but with the first Lisp. PG points to an early essay titled "The Hundred-Year Language" [1] as an indicator of where Arc is intended to go and some future outlooks that might inspire more evolution.

I don't know that any programming language can be everything it needs to be from the outset, but it certainly needs inherent featured supporting longevity, a framework that supports change and evolution, while still having a pleasing and useful function that can be taken advantage of immediately.

[1] http://www.paulgraham.com/hundred.html

It would be more correct to say that they can be coerced to a function with a special purposes (e.g. using a set as a function is an alias for checking whether an item exists).

To say they are functions would be incorrect. By the same logic, a keyword is would be a function.

They're callable as functions, i.e. they implement clojure.lang.IFn. So unless you want to shave hairs on what it means to say they're not "functions", they _are_ functions. Sets, vecs, maps, keywords, and IIRC symbols are all IFn

Oh and (#{1 2} 3) is equivalent to (get #{1 2} 3) not (contains? #{1 2} 3)

I think that it depends upon what you interpret it when you say “it’s a function”; it’s data as well. Which, now that I reconsider it, was kind of the point that the parent was trying to make, that they’re also very much unified.

So point taken.

Ah, that makes sense. The next main difference in my mind is ergonomic, but relies on this regularity: functional syntax for composition, negation, quoted application. There are also other syntax additions and in my experience they're well-chosen and go a long way.

This was discussed a lot before (according to Queinnec book at least) but people were worried that too much overloading would yield confusing code and bugs.

I don't know Arc, so this confuses me:

  arc> (map l '(0 1 2))
  (1 2 3)

What is the logic here? Is l made into a function that holds state and returns each element in turn (like an iterator function)? Because I would've expected:

  arc> (map l '(0 1 2))
  ((1 2 3) (1 2 3) (1 2 3))

In what way is map being applied here?

After RTFM, I can answer my own question:

> In Arc, data structures can be used wherever functions are, and they behave as functions from indices to whatever's stored there.

(quoted from the Arc tutorial)

   arc> (l 0)
   1

and so on. So the GP makes sense.

that's confusing as hell. there's a reason this didn't take off (Besides the competition from clojure)

It's kinda cool to be able to write (myarray i).

I don't like the Arc language because it's dynamically typed and thus inherently unsafe (see other threads for this sort of discussion.)

But I like this particular feature. If you think about it, an array is a mathematical function, or map, from indices to values. So it makes sense to be able to apply it to indices to get the respective values.

In that sense, map just composes its two arguments.

That's cool! I'm a mathematician and so inclined to (over-)abstract programming, but it had never occurred to me to think of it that way.

Learn you a lisp for great justice

I think the list '(0 1 2) is behaving like the function — in CL syntax, sorry, I don't know Arc — (lambda (x) (elt '(0 1 2) x)). That is, the list is being treated as a sequence, which is a function from each index to the corresponding element.

Is PicoLisp the same?

No offense, but I found your example code really confusing.

For the benefit of people familiar with Common Lisp:

  * (= ...) is assignment, not equality testing
  * (map list index-list) is equivalent to (loop for index in index-list collecting (nth index list)), or in a more FP style (mapcar (rcurry #'nth list) index-list)
  * (map function list) is equivalent to (mapcar function list)

I think your example would have been less confusing if it used larger numbers to highlight where addition was happening and where indexing was happening:

  arc> (= l '(4 5 6))
  (4 5 6)
  arc> (= f [+ _ 10])
  #<fn: f>
  arc> (map l '(2 1 0 0))
  (6 5 4 4)
  arc> (map f '(0 1 2))
  (10 11 12)

Thank you the map <list> makes more sense now.

And looks like an easy trap for misreading code ...

Wow next time don't use

and

in the same code listing.

Kind of like pattern matching in Elixir?

It is more concise thanks to "sugar" in the language.

Reply on news.ycombinator.com