There's no preplanned development schedule. When there's an essay I want to write, I write it; when I want to work on Arc, I work on it-- and when there's a significant amount of new stuff, I make a new release.
You don't have to work on it but we still would like some direction from you, like thoughts on anarki and the new editions that are added by the community.
The main thing I wish someone would write is a profiler that (a) had sufficiently low overhead that it could run in production code and (b) could be installed without huge changes to ac.scm and/or the underlying MzScheme.
Oof. Tough. I and raymyers did some work back on a profiler when we were optimizing treeparse, but it didn't quite work well in my use-case.
Certainly it seems to involve deeper hackery skills than I seem to have right now ^^.
As an aside, it might be slightly easier to actually insert profiling code in arc2c. Each function has its own ID number in arc2c and all we need is some sort of index from ID number to original function name (given that a function in arc2c may be split by CPS conversion, so a function with a name may end up being split into several functions),
> You don't have to work on it but we still would like some direction from you, like thoughts on anarki and the new editions that are added by the community.
That happened to me early on, because earlier versions of Arc were written in CL. Within a month or so I found some CL operators intolerably verbose. And yet I'd been using CL for 15 years and had never had a problem with them. That was an interesting data point about how much one gets used to the language one uses. So much so that external constraints (e.g. counting tokens) are needed to force one to come up with ideas for improvements.
One funny thing is that I was not even used to one thing: a let just to bind one local at the head of a function really bugged me, so I would use &aux to avoid it.
But yeah, just a few weeks of arccing and I realized I was hitting myself in the head with a hammer and decided to stop, or rather, how much surprisingly nicer it was to just superabbreviate and de-parens the obvious.
Of course I try not to use LET (I think there is a tax on it) but I was doing a DSL which was always starting by picking a random entity that then got re=used a few times, so I was in Letville unless I wanted to go nuts and code-walk in my DSL.
> a let just to bind one local at the head of a function really bugged me, so I would use &aux to avoid it.
> Of course I try not to use LET (I think there is a tax on it)
In Cadence Skill, the lisplike we use in the office, 'let does have a tax to it when using lexical bindings; environments were pretty hefty objects and using 'let in a loop would generate a lot of them as garbage (the language implementation doesn't even have tail call opts!). I ended up using @optional (approximately equal to &optional) for some variables in time-constrained code, which helped reduce environments.
Some of these operators will probably go away eventually. The reason there are many is that I'm experimenting to see which variants end up being used most.
The defopr redef problem is in fact a bug; will fix.
Exactly. Sorry, I never realized that adding news to the libs
would break the tutorial. In future, if anyone notices a bug this major, please email me about it or at least post something here.
I see that; it just seems like they don't have a huge amount of practical utility. I mean, they're nice to have, but when I was programming in CL, one rarely if ever saw them in production code.
But I think you're right -- they have that "feeling the bits between your toes" character.
They're not necessary in order to have a list abstraction, but they are the minimal thing you could build lists out of.
The whole point of the axiomatic approach is that you don't program in the axioms themselves. But you still do want to have the things you do program in built out of the smallest set of axioms.
Holy cow. Thanks for finding that. Originally that pos was a find. I think it got changed in a global replace, and since I normally used codetree I never noticed that the return values suddenly leaped.
