> The intention is to be extremely permissive in accepting patches.
Interesting to see what this will lead to.
Anarki – Community-managed fork of the Arc dialect of Lisp
41–45 of 45 posts
Re: Anarki – Community-managed fork of the Arc dialect of Lisp
#42Re: Anarki – Community-managed fork of the Arc dialect of Lisp
#43Earlier quoted context omitted.
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.
Re: Anarki – Community-managed fork of the Arc dialect of Lisp
#44I'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...
Re: Anarki – Community-managed fork of the Arc dialect of Lisp
#45Earlier quoted context omitted.
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).
A lot of the comments mention reasons. In my experience, once you get used to a lisp-2 programming in a lisp-1 feels limiting: you can’t just write (def str “foo”) In Clojure, because you’ll shadow the builtin definition of str (which leads to really weird bugs). But, this means that there’s one more thing to think about when naming your variables. Additionally, I think we’re pretty used to “separate namespaces” for…
Lisp-1 fails to prevent the situation that the left position of a form is treated specially, both syntactically and semantically. Yet, the evaluation-strategy is sold that way to programmers: "look, symbols all positions of a compound form are treated uniformly".
It is not true syntactically, because special operators are recognized only in the leftmost position, as are function-style macros.
But it is not even true when all symbols in the form are variable bindings. Because at some point, the function is called, and that is not uniform. The leftmost thing is treated as a function being invoked, and the others as arguments being passed. These are different categories. We take the leftmost object and activate its ability to behave as a process; and we don't do that for the other objects. That's effectively a different semantic space.
Objects potentially have two "semantic bindings": a binding to the ability to behave as a function (denoting a process which takes arguments and produces values, and possibly side effects) and the trivial binding to the value that they denote; e.g. the integer object 3 to the abstract integer three. These bindings are two spaces, effectively. Therefore, Lisp-1 doesn't get away from two spaces. It resolves the leftmost object of a call form in the "function behavior space" and the remaining objects in the "value denotational space", in order to bring about a function call.
Lisp-2 has a cleaner story/explanation of operators. It simply embraces the idea that the left position and argument positions are different, through the entire evaluation stack, rather than trying to pretend they are the same.
In a Lisp-2, you cannot write an expression which refers to an operator as if it were a variable. Whereas in Lisp-1, meaningless nonsense like (progn progn) is possible, in a Lisp-2 this can exist with a meaning. The potential that we can give any form meaning is a core theme in Lisp. The fact that we can bind a progn variable so that (progn progn) works is more "Lispy" than having to give up and conclude that it's an absurdity.