I can see rejecting .. to disallow access above the tree, but rejecting / doesn't make any sense to me. So we have to just plop everything down in one directory? If so, that's ridiculous. I think I need to be less critical of the forkers.
Hehehehe. It's not that we're deliberately forking off - it's more that:
1. pg has been talking about this language for years
2. he has built up a big fan club
3. he released arc in a "not-quite-done" state and unleashed a firestorm of third-party fixes
4. he hasn't updated arc again for more than a month or so.
So yes, although we're not deliberately forking off, I fear this is just what will happen unless pg updates us all again within the next few months, or puts major parts of Anarki in Arc3.
Within Anarki all the file serving was done out of the special docroot directory (at least it was a month ago). I'm not sure if disallowing "../" is what we want or if it what we really want is to ensure that all file serving comes from that dir.
Ok, I'll bite. Why do you want to opt out of the karma system? I can understand simply not caring about it, but I'm curious why you feel the need to "opt out" of it.
Continuing to create new ids seems like a pain and is confusing to other users. If someone were to want to find an old submission of yours, for example, they may have to search through 3 collections of submissions - one for each user.
When the karma "leaders" was introduced, I found myself paying too much attention to my standing and stressing about what I should be doing to get more karma points and "beat" the next person. I rapidly decided this was silly and counterproductive, especially for meaningless points. Since I lack the willpower to just stop looking (especially when the karma score is at the top of every page), I figured the next best thing was to blow my karma by starting a new account, which forces me to not care about my karma score. I don't mean to cause confusion, let alone start an internet meme :-)
See Tim Harford's "The Logic of Life" for more discussion of ways to force yourself to behave rationally. (This is also the motivation behind the startup stickk.com)
I'd suggest proposing a feature to pg to accomplish what you want without having to continually create new userids. Since he's provided an anti-procrastination feature, he may be open to the idea.
BTW I thought it was interesting that someone (not me) gave you a karma point on your post about not wanting karma points :)
This must already sort-of exist: check out pg himself (http://arclanguage.org/user?id=pg). He's got 1190 karma, whereas almkglor, the current leader, has "only" 660. So somehow, pg's opting out of the "leaderboard" system, at least. If that's the case, it should be in news.arc somewhere (I'll look if I get the chance); of course, there could be some other reason I'm missing.
The only time you need garbage collection is when you're allocating new memory. This is of course abstracted away into the 'cons procedure you end up calling at each (cons a d) - basically 'cons triggers gc if necessary. You may then very well just use the someone-Boehm garbage collector for C, which will (I think!) helpfully look at registers and stack for you.
The someone-Boehm GC (reportedly) works well with C - I'm reasonably sure that it will work well with assembly.
Anyway, maybe the right way to do so is by destructuring a Scheme implementation ? Starting from a given implementation, you write your compiler from scratch, but use the facilities of the chosen implementation for the reader and the GC. Then, once it's working, you gradually remove the scaffolding by implementing these things by hand...
Well, if you're going to end up implementing something like my unrolled-lists ideas, then everything can very well be a cons cell underneath. Including bignums and strings.
Let me preface my comments by saying that I mean them constructively, not negatively.
One big problem is this project has little relevance to the world outside arclanguage.org.
On the technical side, I'd suggest looking to see if anyone has made a Scheme to Common Lisp compiler, since that's an isomorphic problem. If one exists, that will give you a big start. If one doesn't exist, hmmm....
Offhand, I don't see how you're going to handle continuations or tail recursion. Note that many Scheme implementations punt on continuations (e.g. Kawa, Scheme 48, QScheme). Nil handling is also likely to be a pain.
If you're looking for a way to compile Arc, I think it would be much easier to use an existing Scheme compiler as the base, rather than using a Common Lisp compiler. Using a Common Lisp compiler seems to be just adding difficulty.
On the other hand, you have a lot of time budgeted to get the web server running. It seems to me that if you get Arc running, then srv.arc should just work and give you the web server for free.
I think interpreting Arc (as opposed to compiling) in Common Lisp using Peter Norvig's Scheme interpreter is doable, and I'm actually currently looking into that.
Thanks. I appreciate the constructive criticism :)
> This project has little relevance to the world outside arclanguage.org.
I don't see how much of anything I do here affects the outside world.
> I'd suggest looking to see if anyone has made a Scheme to Common Lisp compiler.
That seems like a rather roundabout method of compiling Arc to CL. Should we always use existing cross language compilers whenever we want to port Arc to a new language?
Say we have a language X, which only has a CL to X compiler. Compiling is then a conversion from Arc to Scheme, then to CL and finally to X. Is it really a good thing to have all the middlemen? And say we have a language Y which only has a X to Y compiler....
> I don't see how you're going to handle continuations or tail recursion.
Continuations are a difficulty, but I think one of CL's libraries may do the trick. They might not be truly first-class, but if they work I don't intend on worrying about it until I've got everything else working.
I don't see how tail recursion would be a problem. As far as I know most CL implementations provide tail recursion. (pg's ANSI Common Lisp talks a lot about using tail recursion in CL, which is one reason why I am not too worried about it.)
> It seems to me that if you get Arc running, then srv.arc should just work and give you the web server for free.
I hope it works out that way. (I will be more than happy to move on to other things if that step goes quickly.)
In my previous posting, I didn't mean to use the Scheme layer as a middleman; I meant to take an existing Scheme compiler and do s/lambda/fn/g on the code (as well as other necessary changes :-) to end up with an Arc compiler.
If you're implementing a Scheme-like system, I highly recommend Dybvig's "Three Implementation Models for Scheme" (http://www.cs.indiana.edu/~dyb/pubs/3imp.pdf). The three models are a heap model, a stack model, and implementation on a crazy string-based research processor; you'd probably want the stack model. Despite being a PhD thesis, it is very practical; it describes how the author implemented Chez Scheme and gives a pretty much full Scheme implementation running on a simple virtual machine. It handwaves about converting the virtual machine code to assembly, and gives some sample VAX code in an appendix.
I'll reiterate that you should look at how to make your project have a larger impact and relevance; what could you do (perhaps using your compiler as a base) that 1000 people would benefit from?
So basically you propose writing a meta-circular Arc compiler by porting a Scheme compiler to Arc, and modifying the compiler to compile Arc instead? That actually sounds like a really cool idea, if I understand you correctly. But what Scheme compiler would you use as a base?
I presume the paper you posted is meant for implementing Scheme from scratch? (So this would be an alternative to the previous option?) I'll look over it if I get the time.
Now perhaps I'll see if I can make a proposal out of this. (I might as well, assuming I have the time, since I am allowed more than one.) Although there is one issue: in order for such a proposal to get funded, I need someone from the Arc community to step up and mentor it.
I have a big Arc script that generates the documentation from template files. For instance, when I provide the examples, the script fills in the output. This helps ensure the examples actually work :-) The script also generates the HTML, the index, the previous and next links, etc. So most of the manual work is figuring out what everything does, figuring out the high-level organization, writing the description, and creating examples. Writing the script and templates in Arc is also an interesting way to get hands-on experience.
Documentation from the docstrings also has its place; I view my documentation as complementary. I'm hoping to end up with more high-level, conceptual documentation.
