The only caveat I want to inject is to not blame Racket too strongly. Clamp showed me that I don't know enough CL to make a good Arc in it. By the same token, Pauan's https://github.com/arclanguage/arc-nu showed me how much better Arc-on-Racket can be. Racket is pretty mature, but the default Arc implementation hasn't moved much from the days of mzscheme.
Sure, obviously Racket is a great language, specially for teaching. Though, I don't find it is in the same greatness category as C and python (and some others like Ruby, Rust and Go). Those are the hacker languages. I would like to see a lisp actually in this category.
Just as a counter-point, I'm utterly unconcerned about fragmentation. This community is small, and the Arc codebase is small, in the grand scheme of things. It's tractable for one person to hold it in his/her head. We all have different strengths and weaknesses. If somebody finds it easier to work with C++ (that's me), go do it. If Common Lisp is your forte, and you find it easier to port Arc to it than to build threads into Racket-Arc, go for it. Regardless of where you are, it's tractable (though not trivial; write lots of tests!) to share code across projects.
One lament that often comes up with programmers is why software can't be as stable as a house or a bridge or whatever. Well, the reason is that our forebears tried lots of different houses and bridges before we settled on the ones we see today. That was only able to happen because of large amounts of fragmentation, only we don't call it fragmentation because atoms are harder to copy than bits, we just call it "trying again". Since bits are easy to copy, software culture has internalized some amount of "peer-pressure copying" under the banner of "avoiding fragmentation". I think it's silly. Particularly in the context of a small-scale project where there's never going to be much demand for deploying at scale, we'll never be a massive target for black-hat folks (so quickly transmitting security fixes isn't a priority), etc. Even for a large-scale project like Android, I think the problems people attribute to "fragmentation" are symptoms of deeper issues, and not fragmenting just keeps us from better understanding the issues.
That's fair. I definitely have a bias away from creating architecture, which probably explains more of my reactions than I'm comfortable with. I normally prefer to make things work within an existing system.
But yeah, I do see that it's worthwhile to try random things; it just doesn't feel true to me. For some reason, waterfall design is what makes me more comfortable.
Just made a quick test on my pet project using :clamp (not clamp experimental) and since most CL is exported, it's pretty compatible and works without much effort. So far so good. I'm gonna test the experimental part this week end.
I did find a better way to export everything. By using defpackage-plus, you can define a package definition clause that imports and exports every symbol that doesn't have a naming conflict with the current package. Exporting all of the symbols in :cl becomes just using this clause on :cl.
That's only ssyntax. a.b is rewritten as (get a b) where get is a generic function. You may be able to use set-funcallable-instance-function to get something closer to what arc supplies. Also there are a lot of edge cases with the ssyntax since you have to be within a w/ssyntax block. There is one included in def, so you can use ssyntax in function definitions, but you can't use it at the toplevel.
I wouldn't spend too much time on it. malisper truly has the right idiomatic approach with packages. I was mostly just flailing around with the little bit of Common Lisp I understand.
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.
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.
