Not quite. If I just put _call, Scheme will try to resolve the variable at compile-time. However, it hasn't been defined by then, so an error is thrown. In order to allow it to be defined in-Arc, I had to wrap it in a call to arc-eval.
I chose "call" because that's how "help" was named. The setters hash is just "setters," though, I believe. I dunno, if you come up with a better name, feel free to rename it.
I don't really care that much, (at least not enough to bother changing it), just thought we might want to follow pg's conventions (in so far as those conventions exist).
Think of it that the ideal Arc would be written entirely in Arc, except that some parts are written in Scheme for performance reasons or to allow something to actually run.
I've been thinking that the Scheme code (ac.scm) should be split in two parts: an "axiomatic" part that defines car, cdr, set, annotate, etc; and a "library" part. The "library" part would define OS stuff like current-gc-milliseconds, open-socket, probably atomic-invoke, etc. There would probably be a "math" library that defines exp, sqrt, and all the missing math functions.
This structure would make it clear what parts of the language are really axioms, and what parts are in Scheme for performance, convenience, or because they are OS things that require low-level hooks.
Here "scheme-fn" is a macro that returns an Arc function that calls the named Scheme function, but still expects to be passed Scheme values and returns a Scheme value. Then various functions such as "scheme-istrue" can be used to convert Arc values to Scheme values and back again.
This what is broken in Arc right now - essentially we can't fix anything of this scale (or arguably anything non-trivial). If we do there will be merge nightmares when PG releases the next official version (and every subsequent release). All we can do is mention problems on the forum and hope he notices and changes things in the next official release.
I believe this would be solved if we shared a repository system (git) with PG in which we could sumbit patches which he would hopefully approve and merge in. Or not approve. Or delegate the sifting out the good patches to someone who knows what they're doing / shares the proper vision of arc.
I don't think that would fix it, as PG would probably refuse most of the patches anyway. It's not like this forum has a lot of traffic. Patches are unlikely to get lost in the flood (12 articles in the last 24 hours, and PG last commented 18 hours ago).
The two ways to get changes into Arc, as far as I can see, are to find a bug or write some real-world code that proves your suggestion is a good one. With so little real-world code around, that means very few changes will make it.
On the other hand, the last release was all about merging News.YC so there's no surprise that it lacks new features. Who knows, perhaps the next one will incorporate half the stuff from Anarki? We have very few data points from which to draw a conclusion.
Don't be disheartened, brother. It seems to me Mr. Graham gave us all a first cut to get exactly this kind of feedback, but the core language isn't yet fully baked, and so we should acknowledge that we're at the very beginning of a long journey. I'd be surprised if Linus Torvalds was merging in kernel patches from anyone besides himself in 1992.
I'm bemused that calling a function fixes in which lexical environment the functions it calls come from. Probably not something I want to use for my (emergency-shutdown) function, hmm? Or do I ensure that the functions that emergency-shutdown calls are fixed to a particular lexicon by, er, writing some other functions that call them and then calling them? But then there's the (turn-power-off) function that (emergency-shutdown) calls...
I'm not sure I quite understand this, but let me see if I can help clear up the confusion anyway.
A function, as distinct from a macro, has the property that when you call it, it will work the same way every time, even if you have provided some crazy bindings that shadow the functions it calls. For instance,
The comment in ac.scm says "maybe it doesn't matter since the thread will die?", but the error can be caught (or ignored with errsafe), so this is a serious bug that will bite.
Several people have fixed date to work on more operating systems, I believe the simplest version I've seen is the one I wrote: http://arclanguage.org/item?id=2652
From some comments it sounds like some people thought I was saying that documentation is unimportant, or even that code shouldn't or doesn't need to be documented. So do let me clarify: I think documentation is wonderful. I am delighted and appreciative of documentation efforts, and I find the documentation that people provide of tremendous value to me.
I started out thinking I'd be using Perl (just because I program in Perl a lot), but then it didn't look like any of the Perl OpenID libraries supported OpenID version 2 yet...
How are you integrating with Perl, just out of curiousity?
Yup, that's essentially the same approach as I'm taking (at least in terms of connecting Arc to another language).
Well, if any of the code I'm writing turns out to be useful to you for your project, you're welcome to make use of it... it's all in the public domain anyway :)
