Feel free to use user:pass as a login. I considered using cookies, but personal and global high scores are next the list and I was heavily referencing blog.arc, besides, you only have to login once.
I personally like the :o, maybe just because it reminds me of CL. Anyway, it shouldn't be too hard to add a special case for ': in ssyntax if it is the first character.
After all, wouldn't that be an error anyway? Therefore redefining it would not interfere with normal usage of ':. In fact, it makes sense to have different versions for each ssyntax if it is at the beginning, end or middle.
I've called length on a dotted list in ppr.arc, and to do that I needed to redefine 'len to support it. I can't really think of an application outside of messing with argument lists.
well, it is a complicated function. At the very least, it is better than the old version.
That bug must have creeped in because it calls ppr again on the body if it needs to wrap. I'm not 100% sure how to fix it though. Maybe print the first and then map ppr over the rest?
The question is, how to get br-fns to properly indent their bodies. Maybe ppr needs an option to avoid printing the parens.
I think that both CatDancer and rntz have good points, the problem is that they are working on different things and thus have different perspectives.
CatDancer is mostly working on libraries - independent pieces of code that, while they may redifine some things, or make minor changes to the base language, mostly leave it alone. These can be written easily in the "shortest distance from arc" method and still work well together because they don't actually change the base of arc. This also means that while VC is useful in development, it is hardly needed in publishing.
rntz has been working on porting changes from arc2 to arc3 and some other hacks, many of which require major changes to the arc code base itself such as his coerce hack. These need to be VC'd so that they can be understood by other users of Anarki, and so that they can work more easily with eachother. Since many of them create major changes to the codebase, it can sometimes be a challenge to get them to work together and as he says plain diffs would be a nightmare.
I may be summarizing a bit much, and I'm sure there are more subtleties to it than that, but it's how I understand the situation.
As far as I can tell, they can be handled separately. The publishing of libraries and miscellaneous code can be done without publicly visible version control, but the Anarki base should probably be versioned.
Git is still a good choice for what we're doing, as far as I can tell, because for one thing all it is is scripts built for managing it's base. That is the essence of the so-called porcelain. I'm sure it won't hurt anyone to add a little bit more in the way of domain-specific tools. They might be useful to others as well.
So it sounds like we have to things going on here:
1) We need a meta-data and library publishing system for people to share code that they've written to use with arc.
2) We need a slightly better method of handling changes to the arc base so that people can coordinate massive changes thereto. I think that individual commits works ok for minor changes, but it rapidly gets complicated to handle if they start stepping on eachother. That's when we should switch to "branches" which can be interpreted to mean alternate conceptions of arc. Case in point being the hygienic version of arc in the hygiene branch.
At some point we just admit that the lisp community is hopelessly built on making their own incompatible versions of lisp, and everyone makes their own fork of arc. Magic merges and rebasing can only handle so much incompatibility in the history of the system.
I wouldn't dismiss the possibility of using darcs for your project. git was designed to merge tens of thousands of lines of code in a fraction of a second; that doesn't mean it isn't useful for other tasks, but it also doesn't mean that darcs might not be better for the kinds of tasks that you find yourselves needing to do.
Git was also designed to have a fast, simple back end, with a script based front end. Each command that you're used to using with git is just a shell or perl script that calls a few basic git functions to mess with blobs. Therefore, it is easy to add new tools and scripts. A good example given the darcs context would be: http://raphael.slinckx.net/blog/2007-11-03/git-commit-darcs-...
My point is that the architecture of git allows us to write scripts that work at the same level as the other git scripts; we can keep or leave the others as desired.
If it's for debugging, wouldn't it be easier if you just left it going to standard out? That way you could run it on the repl and see the output, and still wrap it in 'tostring or w/outfile if you wanted it to go to a string or file instead.
Maybe the stream argument could be made optional, and default do stdout? The redundancy would still exist, but it would allow us to use it both ways.
What should I do in git if I have been developing a branch off of master, and I want to move it over to be based on arc3.master so that it will be more forwards compatible?
I haven't changed anything that existed in arc3.master, or master for that matter, just added some new things, and modified them a bit.
I thought I was supposed to use "git rebase arc3.master" while in the other branch, but it seems that didn't work, as it was complaining about merging changes in arc.arc, and I never touch that file in this branch.
Well, first of all, `git rebase --abort` if you haven't already to avoid fucking things up. The actual command you want is `git rebase --onto arc3.master master ${my-branch}`. Explanation follows.
`git-rebase $target $branch` takes the changes made by the commits in $branch relative to its nearest ancestor in $target and attempts to change them to be relative to $target - it "forward-ports" the changes you've made relative to an old version of $target. The problem in your case was that the common ancestor of arc3.master and master is plain old arc2. So what it did was attempt to take essentially the whole of anarki's changes to arc2 (plus whatever changes you were working on) and forward-port it to arc3.master. Something of this magnitude is not really amenable to handling by automatic merge. Conflicts are inevitable, and moreover, a semantic change (like the rename of 'set to 'assign and 'assert to 'set) won't be caught... there's a reason that the arc3 anarki is a fresh start instead of a straightforward port.
`git-rebase --onto $newbase $oldbase $branch`, however, takes the changes made by the commits in $branch relative to $oldbase and tries to forward-port them to $newbase, rather than just taking the nearest shared ancestor. `git-rebase --onto arc3.master master $branch`, therefore, says "take the changes between $branch and master and forward-port them to arc3.master", which is a much more feasible thing to do automatically if those changes haven't touched anything that differs significantly between master and arc3.master.
I already did the git rebase --abort as soon as it started complaining about something I new I didn't change.
What if master has changed since I started the branch? Should the command instead be 'git rebase --onto arc3.master mybranch~n mybranch'? Or does it not matter where the head of master is relative to the beginning of my branch? Should I rebase to the head of master first, and then move it over to arc3.master?
I guess the documentation on git rebase wasn't quite detailed enough for me ;)
I had thought of making programmable coercion before, but never realized the connection between functional position and coercing the object to a fn.
Great job. I think it should be added to the master version, since you still have defcall and in theory nothings "changed" except an increase in performance and conceptual simplicity.
I have actually merged both rntz.coerce.0 and rntz.defcall.0 into arc3.master; I forgot to mention that in my original post. Unless you were asking about merging this into the arc2-based master branch, which I haven't done - I didn't really think about it; I've switched over entirely to arc3 at this point.
