I was just looking at some of the older posts here and came across the discussion of arc2js[0]. When that link didn't work I used Google and came across another post[1] where he mentioned an updated page and that one had a link that worked. I must have accidentally copied the broken link instead of the one to the actual page.
I just did it,though I am even not very familiar with arc and still under learning.
It seems that there are still some bugs. For example,when replying a comment it jumps to an unexpected page, which I don't know if it is a normal case.
So,the next step,what should I do to maintain such a site.
And what is the best way to backup the data, now I just backup the 'arc' folder everyday.
Say a 95% solution leaves 1 in 20 hackers dissatisfied, where an 80% solution leaves 1 in 5 hackers dissatisfied. The number of dissatisfied hackers goes down. But won't they still continue to react to their dissatisfaction by creating new libraries that don't build on prior attempts?
"At best the number of different, incompatible systems will be lower over time. But there's no reason to believe that dissatisfaction with prior solutions will be more likely to build on them."
Could you clarify this? I think there might be a typo in here, but I don't know where.
I think that's a very old version of Arc2js. There was at least one more version Pauan made after that, from scratch. Nowadays, Pauan's lisp-that-runs-on-JavaScript efforts seem to be focused on Nulan[1], which... seems to use the escodegen library[2] for JS generation.
And here I spent the weekend optimizing my own lisp-to-JS compiler, when I could've used escodegen. :-p Ah well, it'll probably be worth it because I'm very picky about stack overflows and such.
Well, that old version of Arc2js seems to be trapped in an orphaned set of commits that GitHub might garbage-collect at any time. I tried making a local mirror of the whole repo, but those commits don't come with it. Pauan probably wouldn't consider it to be code that's worth rescuing, but now's the time to figure out how to rescue it. :)
"I am not saying that these three designs of mine represent the last word on the issues -- "100%" is really a bit of a misnomer, since no design is ever truly 100%. I would prefer to think of them as sufficiently good that they at least present low-water marks -- future systems, I'd hope, can at least build upon these designs."
But it's not clear that an 85% solution or 95% solution helps to solve the problem he identified earlier in the post:
"[The 80%] socket interface isn't general. It just covers the bits this particular hacker needed for his applications. So the next guy that comes along and needs a socket interface can't use this one. Not only does it lack coverage, but the deep structure wasn't thought out well enough to allow for quality extension. So he does his own 80% implementation. Five hackers later, five different, incompatible, ungeneral implementations had been built. No one can use each others code."
At best the number of different, incompatible systems will be lower over time. But there's no reason to believe that dissatisfaction with prior solutions will be more likely to build on them.
I'm curious if Conrad Barski was aware of Olin Shivers's regular expression library when he built http://www.lisperati.com/arc/regex.html and if so, if he built on the design. That would be a strong counter-example to my hypothesis.
Equality is actually a rather complicated thing. The way I understand it 'is' is an object equality predicate, roughly equivalent to Scheme's 'eqv?' for most data types. The 'iso' function on the other hand sounds like it was intended to be a structural equivalence primitive (which is what isomorphism means in mathematics), which should roughly have the semantics of Scheme's 'equal?'. Arc 3.1 defined iso only for lists, but it seems that just about every other third-party implementation including my own Arcueid extended it to arbitrary other objects such as tables.
Oops, I assumed Github's search would show me every occurrence in every file, like a recursive grep. No such luck, I guess. :-p So you got me.
While that's a reasonably useful default behavior for 'iso on tagged types, I'm not particularly happy to see it.
Arc provides very few helper utilities for working with tagged types--basically just the axioms 'annotate, 'type, and 'rep, plus 'isa and 'coerce--and the documented purpose of tagged types is for user-defined types. I came to Arc from a more OO-like background and saw this as a good way to control access to the implementation details of my types. Unless you explicitly called 'rep, you didn't get more coupling than you bargained for. This gave 'rep almost an "unsafe" reputation for me.
If 'iso gets to access the rep at will, then I may have been programming in Arc less robustly than I expected: Either each of my types should have come with an 'iso extension to reinforce my encapsulation, or I should have considered 'iso "unsafe" and used it less often. Not that I could have known this at the time! :)
But it's not a big deal. I do deep comparison operations sparingly enough as it is, and I don't know if my soft encapsulation technique actually matters because I rarely saw anyone else following similar guidelines. (I've rarely seen anyone using 'annotate at all, actually, and I think it's been a common complaint that 'annotate is basically 'cons with fewer utilities built up around it. That's a plus for me, I guess, lol.)
A good example of me considering an operation "unsafe" is earlier in this thread, where I discouraged the use of compound values as table keys. It just so happens Arc's table key comparison breaks the encapsulation of tagged types as well. :)
"Once you or I have a self-hosted compiler, if it can compile to a platform, it can also run on that platform."
In theory yes, but it wouldn't be a good idea for jasper because it is a relatively thin layer on top of javaScript. So a backend for a different platform would have to emulate a lot of JS quirks, which would be complicated and produce slow code.
So if you want to make a cross platform language, it should be a thicker layer on the first platform from the beginning.
"Nevertheless, I think I'm still headed in that direction."
Always make backups of your compiler binaries or don't overwrite old compiler binaries so in case of a bug you don't end up with only one, broken, compiler binary.
(defextend iso (x y) (isa x 'table)
(and (isa x 'table)
(isa y 'table)
(is (len keys.x) (len keys.y))
(all
(fn ((k v))
(iso y.k v))
tablist.x)))
; default impl for tagged types
(defextend iso (a b) ($.vector? a)
(iso ($.vector->list a)
($.vector->list b)))
Does the 'default impl' trigger your gag reflex? :)
"A straight arc to javaScript compiler would have to be really smart to produce fast code, and interop wouldn't be seamless either. So I decided to try writing my own language."
"Current status: It is already sort of usable, but I wouldn't recommend anyone else to use it for anything beyond throw away tinkering, because I still might decide to make big changes to the semantics."
You could be telling the story of my recent language projects too. :-p
---
"Self hosted compilers are a pain in the behind, one has to mentally switch between the language version the compiler is written in and the language version the compiler is compiling and when you break you compiler you can't use it to compile the fixed version."
That's a really good warning to hear, because I was headed toward having a self-hosted compiler myself.
Nevertheless, I think I'm still headed in that direction. Once you or I have a self-hosted compiler, if it can compile to a platform, it can also run on that platform. That's a way to escape from the original platform you built it on: Write a compiler backend, and then just move to that platform for developing in the future. This could be a pretty nice superpower when we have the silos of C#-based Unity, Java-based Android, etc.
"Arc's attitude, championed by aw, is to avoid generalities and look for concrete code examples where an alternative makes for greater concision."
Yeah, this can be a pretty nice metric sometimes. :) This is probably one of the leading reasons to use weakly typed (or otherwise sloppy) versions of utilities.
No offense, but I'd like to give your comment an awful lot of errata:
Those objects you're creating will have the cons list (quote a) as a key. Non-atomic keys are full of gotchas because Arc's tables use use Racket's 'equal? for key comparison, rather than using 'is or 'iso. This means tables care whether a list ends in the symbol 'nil or the Racket empty list (), which is a detail that's otherwise invisible in Arc.
(If you want the symbol 'a as a key, the code is (obj a 'b).)
Arc's tagged types are not lists, and 'iso can support lists without supporting tagged types. (Personally, I wouldn't want 'iso to dig around in my tagged types anyway. I like pretending the data inside is encapsulated, except where my code absolutely needs to access it.)
Finally, does 'iso actually support tables in Anarki? I can't try it out right now, but I don't see any code for this when I search GitHub.
I actually worried that it wasn't painless enough, and that I should have waited for the web repl to be done before submitting.
These long strings contain the compiled macros. They are only there for debugging. They belong in comments instead of strings, but I didn't think of it at that time.
Thanks for the answer, especially the thoughts on self-hosted compilers. I'd always found myself vaguely unsatisfied with them as an outsider trying to understand them, so it's very useful to hear similar sentiments from someone who actually has experience building them.
BTW, I followed the instructions to run it and was pleasantly surprised by how painless it was.
Asking whether Arc is alive, or completed, tends to bring up arguments over definitions.
Perhaps if you talk about what you want to do with Arc, we can discuss whether it's a good fit or not. Why are you not satisfied with Clojure? What do you like about it that you want to keep?
Motivation:
I want to have a lisp which, runs in the browser, interops easily with existing javaScript libraries, and is reasonably fast. clojureScript sort of is this, but its macros are kind of a kludge (clojureScript macros are written in clojure and have to be in a seperate file from the rest of the code, also hygienic only), interop isn't seamless, and I don't want to start a jvm every time I want to compile some code. A straight arc to javaScript compiler would have to be really smart to produce fast code, and interop wouldn't be seamless either. So I decided to try writing my own language.
Implementation:
Since macros can call functions which were defined in the same file, the functions needed to be evaluated right after being compiled. So I couldn't just do a simple "jasper code in, javaScript code out" compiler in haskell. So there is a self hosted[1] compiler/repl.
Current status:
It is already sort of usable, but I wouldn't recommend anyone else to use it for anything beyond throw away tinkering, because I still might decide to make big changes to the semantics.
Not sure if that are the things you wanted explained.
[1] Self hosted compilers are a pain in the behind, one has to mentally switch between the language version the compiler is written in and the language version the compiler is compiling and when you break you compiler you can't use it to compile the fixed version.
1. Bounds checking errors are certainly in keeping with the spirit of scheme, no arguments there. If you care about distinguishing () from [], require if to have an 'else' branch, and consider it important to distinguish between #f and nil, then such substring behavior will fit right into that aesthetic milieu.
2. Incredibly, arc has never had a substring function, so I can't be sure what pg would do. My immediate reaction is that exceeding bounds would be permitted without error, but then sbcl seems to throw an error as well.
I looked at my toy language, which is more in the arc mould and more relaxed about the set of inputs acceptable to low-level primitives:
("abc" 0 10)
024string.cc:21 no such end-index in string: "abc" 10
=> nil
My unit tests show that I never considered out-of-bounds indices. Now that I consider them I'm tempted to permit them silently.
3. I am not persuaded by the reasons in the post. "Do one thing" is subjective about what "one thing" means. The unix creators have spoken out against all the flags that standard commands have creepingly added: http://harmful.cat-v.org/cat-v, recently https://twitter.com/rob_pike/status/410830396444532736. This disagreement with the community at large suggests that the rule of thumb leaves some room for interpretation, making it useless to resolve arguments. The phrase "referentially transparent" is grotesquely misused. The list of useful facts didn't feel compelling. The connection to recent security holes in other languages feels tenuous; you could make the same argument for not permitting lists to contain elements of multiple types if you were a java programmer, and comparing bounds checking to implicit type coercion is just a strawman. The two possible interfaces for substring are just different, there's no magic in either. I'm not convinced that the author made a good-faith attempt to build the "simple" version atop the more complex one.
There's clearly a difference of opinion here, but escalating a simple question to such diverse subjects is just an invitation for flames. Just pointing at the other ways that scheme has a similar policy toward strict and immediate errors suffices to keep aesthetics from devolving into religion.
4. The flame war itself feels, with hindsight and just from reading the archives, unnecessary and a poor advertisement for this community. Responses like http://lists.nongnu.org/archive/html/chicken-hackers/2013-02... and http://lists.nongnu.org/archive/html/chicken-hackers/2013-02... made me wince. Perhaps that's partly a culture gap; scanning the archives I found that the noob is still around, so perhaps no major offense was caused. Regardless, this wasn't a flame war so much as the insiders getting together to flame a noob. I looked around for possible reasons why it might have happened, but the mailing list seems to consistently stay around 25-50 participants per year, not high enough volume to justify such frustration. With such a small inflow every newcomer is precious, and every bad experience is hugely significant. The subject of substring doesn't seem to have come up before either, to make them so impatient.
Arc's attitude, championed by aw, is to avoid generalities and look for concrete code examples where an alternative makes for greater concision. That's our aesthetic and it has served well to avoid friction without avoiding debate altogether.
Are you reading the tutorial or anarki or something else? Arc started out defining iso just for lists, but the name ('isomorphic') was evocative enough that we ended up extending it to arbitrary aggregates, including tables.
arc> (iso (obj 'a 'b) (obj 'a 'b))
t ; nil in arc 3.1
Hopefully we're still following the original vision, and it was just an oversight that iso doesn't support tables in arc 3.1. The interpretation is that is is for primitives when you care about fast comparison, and iso is for aggregates and arbitrary user-defined types. Since arc's tagged types are just lists, supporting lists and tables ensures iso will continue to support any user-defined types.
Over time my personal opinion (and that of some others here, but I'll let them speak for themselves) has diverged from the tutorial. I think it's useful to have one strong default operator that usually "does what you want", which is to make equal-looking things equal. So I advocate using iso everywhere unless you explicitly want to compare pointers.
