I've not dive into it but I actually like a lot the idea of Arc being implemented as macros into CL. Ill take some time to review this implementation I think (at least for myself :P).
I recommend the community to audit this implementation and to switch to it as a primary impl if it's any decent. Every link should be redirected to it. I can say quite confidently that CL is the best lisp out there today and the way to go forward as the other lisp dialects both sux and are stucked (even clojure; I've made a 5K+ LOC program with clojure and got tons of technical problems as the codebase got bigger).
It's not about popularity. It's about that I, as a good programmer, doesnt use Arc because it sux for a couple of reasons, which defeat the purpose of the language. In my opinion, switching to CL would fix those issues and open up a bright future.
I implemented most of Arc in Common Lisp[0]. It supports destructuring in def/mac, ssyntax through symbol-macrolet/macrolet[1], and the bracket lambda syntax through reader macros. IIRC the only real Arc feature it doesn't have is ccc (call-with-current-continuation) which is kind of supplied through the cl-cont library.
More Arc implementations would be cool, but I don't know if that's the thing preventing Arc from gaining popularity.
Of course, in that sentence I assume "gaining popularity" is the goal. I do think it's a very worthwhile goal, but it might not be yours. And that's fine.
Virtual hosts are a task for a proxy server like apache or nginx. I would start up multiple arc servers on different ports and wire them up to different VirtualHost blocks in the apache config.
That's really cool! I'm a fan of all three of those things (Clojure syntax, ML types, and Rust memory management).
Although it's intended to be low level, one concern I have is that it's missing some kind of extension system (such as typeclasses, first class ML modules, Rust traits, etc.)
Even static function overloading (like in C++) could work.
That sounds super strange. From what I understand, Racket automatically caches modules, so they are only loaded once.
But then again, Racket does have multiple phases, so it's possible that it's loading the "compiler" file in two different phases, causing duplicate variable definitions.
In addition, Racket doesn't allow for mutually recursive modules, but Arc/Nu is using "namespace-require", which apparently bypasses that restriction. It's possible that there is a race condition that is causing the "arc/3.1/main" file to be loaded before the "compiler" file is finished loading, which then triggers a second load of the "compiler" file.
Just to clarify: have you tried inserting a "displayln" in the "compiler" file to verify that it is being loaded twice?
In my opinion, returning t/nil makes more sense than returning the file path, but Arc/Nu is supposed to be backwards compatible with Arc 3.1, so I fixed this. I also fixed "dir-exists", which has the same issue.
I just pushed out the fix to the Arc/Nu GitHub repository, please try it out and let me know if it solves the problem for you.
Actually I was wrong in saying that in the installation folder it worked. In the installation folder it succeeded in loading the "news.arc" file, and failed at runtime. While in the other folder that failed, because in that folder I already tried with anarki and created some news/bans and this is why it failed to load: the diskvar didn't work. However the problem wasn't in diskvar: it was in "file-exists" which should return the name of the file in case of true: because of this when I just modified "diskvar" it still gave me the contract violation error, I think because the arc code relies on the fact that file-exists returns true. I changed in "lang/arc/3.1/main" the line "(def file-exists (x) (tnil (file-exists? x)))" in "(def file-exists (x) (if (file-exists? x) x nil))". Now I successfully run the news!
You're right. It looks like file-exists has changed its behavior in Arc-Nu to return a boolean even though its being loaded from lang/arc/3.1/main, which might lead one to think it's trying to be compatible with Arc 3.1 [1]. Let me try to reach out to the original author.
[1] Arc has always returned the name on success, as far back as the Arc 0 release.
Notice the "(iflet ,gf (file-exists ,file)". It expexts file-exists to return the name of the file if it exists. file-exists doesn't, it returns t if files exists, so here is the cause of "error: open-input-file: contract violation expected: path-string? given: 't ".
Hmm... It looks like it's my turn to have trouble! What version of Racket are you using? I might need to revert to that version to get Arc/Nu working on my system. XD
---
"Then I decided to try to run the news from a directory(not the installation one). So i put all the library files in that directory [...]"
Now that I've read this again, that sounds like something that would break the libraries in some way. The files of Arc/Nu contain relative paths to each other. If you move some files, you might need to edit the paths that occur in the other files. Which files were you trying to move where?
---
For anyone here who can help, here's the problem I'm encountering.
When I try to start Arc/Nu on Windows 10 with Racket 6.4 or 6.5 installed, I get this error:
I've tracked it down to a specific place: The execution of the Racket code (mac % args (% args)) in lang/arc/3.1/main.
That line is trying to set a hash table entry in Arc/Nu's (globals) table. In the file "compiler", when (namespace-require path) is called to load lang/arc/3.1/main dynamically, the (globals) parameter has been parameterized to contain an appropriate table to store that definition.
However, when lang/arc/3.1/main requires the "compiler" module, it loads a second instance of the module. So when it tries to access (globals), it gets the original value: (define globals (make-parameter #f)). Since #f isn't a hash table, hash-ref raises an exception.
Does anyone know if there's a way to make lang/arc/3.1/main reuse the same "compiler" module instance that's already been loaded?
"I tried from the installation folder, and it works. The error appears only when I try to call it from a different folder."
That's good to hear. Thanks for sharing your process.
It would be useful to find out what's causing that error in particular, so I'll check on that in a moment.
(This is something that the official releases of Arc were pretty picky about; the language would load paths relative to the current directory, so you pretty much had to start Arc from the same directory as strings.arc, etc. I think Anarki has occasionally made changes to this behavior, but maybe Arc/Nu is still picky.)
