Excellent, could we get some sort of separate forum to talk about this project though to discuss bugs, recent patches, etc.. I noticed you have a module system up now, but I can't get it to work:
arc> (impas blah spec)
#3(tagged mac #<procedure>)
arc> (blah:do2 nil nil nil)
Error: "reference to undefined identifier: _blah"
And I'm not sure why it doesn't work, but I also have an Idea for a more general impas function:
The import.arc stuff is a sketch. One of it's many shortcomings is that if you define a function blah and then use it from inside the same module/file, it won't be able to find blah, because it's been silently renamed |modulename blah| .
The problem you're having seems to be different, though.
After looking, I realize that my testing process was masking a bug where I didn't change some symbol dereference. It's fixed now on my machine, but I'm new to git, and not sure what I need to do to make it show up in the repository. I did git push, but that doesn't seem to have made it appear in the commit list.
EDIT: okay, nex3 helpfully explained things to me, so this fix is in the arc-wiki repo now. It still doesn't change use points, though, as mentioned above.
Replying to myself because it seems as good a place as any...
We could walk the tree of a module and patch up any symbols we find that were referenced in a def or mac, but that's not a clean solution, since it can't find all actual calls (something could be building up names, for example, which we'd never find by walking the tree).
What this means is that any module system built right now, as far as I can tell, will have to require support from those writing the modules, but since renaming modules is implicit in how import.arc works at the moment, there's no way to know what the call should look like, for the module programmer. I can't see any way around this except to change Arc itself to make function and macro definitions respect lexical boundaries, rather than all being bound at the top level. Until that change is made, all we can do is fake a module system.
"... The idea isn't to have a single standard repository, of course. It's to take advantage of the purpose of distributed revision-control systems - to provide a standard way of publishing and exchanging patches. ..."
Hey nex3 that is such a neat solution, using git is smart.
They are separate repos, but I have a git-svn mirror on my local machine from which I've been periodically pulling in any changes to the Subversion wiki and push them to the git wiki. Anyone else is, of course, welcome to do the same.
Cool, so patches flow one way and could in principle flow both ways.
Hold on though, will this scale, or will the cost of merging patches from svn become prohibitive? People would in principle be pushing on both the git and svn sides.
Patches are currently flowing both ways as people commit to both repositories.
Git has excellent merging tools, including a way to step through the history of both the Subversion and Git sides, applying patches automatically when possible and asking the user for manual assistance when there's an ambiguity. Even if the repositories get horribly out-of-sync, which I'll try to make sure they won't, it'll only take a moderate amount of effort to get them back to a stable state.
I put a note in the subversion repository to this effect --- unless there are any complaints, I'm going to take the code out of the SVN repository and leave only a note. There's no point in spending any time merging back and forth.
For now, anyone who is interested in Arc is smart enough to figure out git.
I like the idea of using a distributed revision-control system more than a client-server one like Subversion, so people can make their own personal commits and push around patches to each other at will. I think to some extent it mitigates the need to give everyone commit rights since everyone's on an equal footing.
That said, I think it's still a cool experiment. I'd just like to see the repository in a format that can get patches from the git network (that is, granted, only composed of me at the moment).
I like git. I thought doing exactly what you did. I went with subversion because it was simpler (I know svn better than I know git) and because it makes the Wikipedia analogy work.
Okay, sounds good. I'll set up a wiki branch of my git repo mirroring it.
I was going to ask you to reorganize the directories so that they'd work better for mirroring, but then I realized it was a wiki, and did it myself. I hope you don't mind.
Update: There now exists git://nex-3.com/arc-wiki.git, with anonymous push access.
You don't even need a fake username-password :). It has all the patches in the Subversion wiki as of this writing, and it's based on my existing git repo, so patches can easily be sent back and forth.
Sounds good to me. But we'd have to keep a complete list of which characters can be used that way, or else the parser wouldn't know where to slice the tokens, right? Or can you think of a general way to do it?
This topic really makes me wish I knew a function-level programming language like K. It's all about composing a certain set of basic functions, and it's amazingly concise, so I feel like someone with that background would be able to suggest a Right Way of handling functions at this level.
