
Anarki – Community-managed fork of the Arc dialect of Lisp - christianbryant
https://github.com/arclanguage/anarki
======
georgewsinger
What are the core features that differentiate Arc from other lisp dialects?

~~~
sctb
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)

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

~~~
hjek
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.

~~~
christianbryant
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](http://www.paulgraham.com/hundred.html)

------
dreamcompiler
The curse of Common Lisp is that every good programmer who tries it wants to
improve it. Which always results in a weird product with less, rather than
more, appeal.

------
krapp
I'm not nearly versed enough in either lisps or Arc to comment on it as a
language, but as far as the architecture of the forum is concerned, what is
the rationale for functions that appear to just print CSS and javascript[0]?

Wouldn't it be better to separate CSS and JS into separate, static files and
only have the forum deal with, at best, IDs and classes in HTML?

I'm asking because I'm tempted to actually try to fork it and make a PR for it
but it seems like such a simple and obvious bit of housekeeping that I have to
assume there's a reason no one else has bothered yet.

[0][https://github.com/arclanguage/anarki/blob/master/lib/news.a...](https://github.com/arclanguage/anarki/blob/master/lib/news.arc#L482)

------
andreareina
> The intention is to be _extremely permissive_ in accepting patches.

Interesting to see what this will lead to.

------
gtdthrow
Am I understanding right that Arc is a Lisp-1, like Clojure?

~~~
sctb
Yes, or like Scheme.

~~~
gtdthrow
I don't really get why you'd ever want a Lisp-2. Is there an
argument/explanation somewhere that I could read up on?

(I've used Clojure and JS, which also seems like a "Lisp"-1 in that you can
just put fns into variables and call them like 1st class fns, I just don't get
why the distinction is in any way positive rather than confusing, and in
Lisp-2s you now need to dereference everything all the time, like in Ruby).

~~~
sctb
If I understand it correctly, Lisp-2 is a way (not the only way!) of
maintaining more intuitive semantics in the face of macros. If I write the
following:

    
    
      (your-macro
        (let ((x (foo y))
          (bar x))))
    

I probably don't want the meaning of FOO or BAR to be up for grabs based on
the expansion of YOUR-MACRO, and certainly not LET. Lisp-1s often have
hygienic macros to deal with this concern, but not always.

~~~
hollerith
Completing your thought (please let me know if I misunderstood you) Y _is_ up
for grabs because what you wrote might macroexpand to for example (let ((y 5))
(let ((x (foo y))) (bar x))).

Where your comments falls down is that all the Lisp-2s I know allow the
"function definition" of a symbol to be overriden in a similar way, e.g., in
Common Lisp the macro might expand to (flet ((bar (arg) (* 5 arg))) (let ((x
(foo y))) (bar x))) where FLET is a macro similar to LET but for function
definitions.

~~~
kazinator
Where your comment falls down is that in a Lisp-1, every _let_ is also a
_flet_.

Also, of course, you must use gensyms for any locally bound identifier,
whether it is a _let_ or _flet_. Nobody said that Lisp-2 allows for _labels_
and _flets_ without having to use gensyms; nobody in their right mind is going
to lexically bind identifiers in macro-generated code that don't use gensymed
names (other than in cases when there is no possible capture).

Lisp-2 addresses (in a good-enough-beats-perfect way) the following problem:
the programmer's code wrongly capturing references that the macro would like
to use.

The macro wants to generate some (foo ...) call to a function in the global
environment. But, oops, in a Lisp-1, a user's local _variable_ foo takes this.
In a Lisp-1, the user would have to have a local function by that name.

If global functions have reasonably descriptive names, and local functions are
used sparingly, the potential for a clash is low.

We can have a warning when a local function shadows a global one; it won't be
too much of a nuisance since global functiions tend to use descriptive names,
and local functions are relatively rare compared to local variables.

