The = macro looks into a database of settable functions and there is no way to update the database at array creation. In order to use = I must either change let, with, and withs, or, introduce settable accessors, such as aref, but as I said, accesssors are not nice (I use arrays a lot in common lisp, and the accessors are driving me mad). The <- is actually a lot more general than =; it can set anything that returns its own setter, not just arrays. It is not suited for hash-tables, though, since they are likely to contain the key Xsetter.
Actually, with only a tiny modification of the core code and using tagging as a typing mechanism, you can set this sort of array in more or less the same way you set hashes:
; Added as line 454 of ac.scm:
((ar-tagged? fn) (ar-apply (ar-rep fn) args))
; Added to arc.arc
(let old sref
(def sref (com val ind)
(if (no (isa com 'array)) (old com val ind)
((com 'setter) val ind))))
; Added at the end of your array code (or directly to make-array-wrapper)
(let old make-array-wrapper
(def make-array-wrapper (dim store)
(annotate 'array (old dim store))))
If you don't want to patch that manually, I've added your array lib and my patches to the Anarkies.
Patches are not a good thing since they breake the fundamental idea of arc: a language implmented in itself. Also you will soon run into trouble when introducing other array types, such are diagonal, bi-diagonal, tri-diagonal, upper-triangular, etc, and not to talk of foreign arrays, all requiring a new patch. (I can think 100 different array types, it should not require 100 patches.) However, it might be that a solution is to improve the arc type system itself, which seems over-simplified.
I disagree. If by "patch" you mean modifying the behavior of sref via Arc code, I think that's very much in tune with the fundamental principles of arc. I also think that working from basic principles - type, rep, and annotate (nee tag) - is a much more Arc-ish way to make a type system than having something deep and complex built in.
As for defining new accessors for every new type, it would be easy to modify sref to do a table like = does, and make defining accessors as easy as defset is now.
I think we need to do both, both spawn functionality based on types, but also build more complex constructs at the the top of the simpler.
The = and the <- do different things, the = depends on type, <- is a lot more general and depends on what the object itself returns. Arrays are higher order objects, and they depend on element-type, indexing, and, the physical store (currently only hash tables, but it should be raw memory segments for fast arrays) . So the true "type" of the array is a tuple of three (when i said 100 types I though about all the combinations. In reality there are infinitely many, but most them are not needed). In reality what I do in the library is to make a lexical type, that is created with the object, and is thrown away when its not needed anymore. However, a third possibility, is to make something like a template system. This is not easily done in CL, but should be possible in arc due to first class macros. How to actually do this, I do not know.
Very cool idea, dmdavis. Would you be willing to integrate this with the docstring support in the Anarkies? It would suck to have documentation in one place but not the other...
I changed my script that grabs the functions so that it will work with docstrings, but I thought it made more sense to be documenting the main branch rather than the git repo. What do you think?
The Git repo is pretty much a superset of arc0, except for a few bugfixes here and there. Plus if we're going to actually add docstrings to the code, the only way to do that would be to commit them to the repo.
I think it would make the most sense to just document the Git repo and make a note in the documentation that it's not identical to arc0.
I don't like the idea of binding in the order they're used - it seems like it would make a lot of uses impossible (at least without making it more verbose than a fn would have been).
It seems better and more concise to somehow specify the variables with numbers, presumably with some sort of prefix:
I thought about using numbers like that too, but when I posted this I was too tired to remember why that might be a better idea. You're right - it would make more sense to use numbers, and if you're writing a function that's long enough that numbers would make it hard to read, use fn. Zero-indexed numbers with sigils to designate the place in the arg list are better.
([- $1 $2 $0] 1 3 2])
translates to
((fn ($0 $1 $2)
(- $1 $2 $0)) 1 3 2))
I don't like binding the sigil by itself to the second arg - it's starting to look like Perl. I'd even be in favor of eliminating the underscore and only using the sigil-number notation, with the special case that the sigil by itself is arg 0.
(By the way, mathematica is all s-expressions (or rather, equivalently, McCarthy's m-expressions) underneath. You can call FullForm on any expression to strip away the syntactic sugar, eg, FullForm[a+b] => Plus[a,b]. Note the f[a,b] instead of (f a b). A nice thing about the commas is that you can throw in infix wherever it's convenient, like If[x>2+2, B, b] instead of If[Greater[x,Plus[2,2]], B, b]. The best lisp solution I've seen for that is curly sweet-expressions:
http://www.dwheeler.com/readable/
)
Adding parens to make it more "lispy"? I don't see the point, really. Also, why are you passing it a quoted list instead of the actual values you want?
Because this actually works in the current version of Arc. Maybe not quite as concise as the proposed syntax, but probably as close as you can get without adding syntax (at least that I can think of).
So you need to weigh the cost of adding more syntax to the language for the savings of "$1" vs. "(_ 1)".
Note that the latter is more than twice the size of the former, and that you'd also need to put the arguments to [] into a list prior to passing them into the fn. I'd say $1 is a pretty big win in terms of conciseness.
Makes sense. Obviously this is better for something being released to the public but during testing I didn't know if (even inefficiently) asv could be used as a one stop shop (a la webrick).
That shouldn't be too hard to hack in, I think... just find some way to capture all /images/* URLs or something and open up a file and send the contents. You might have to be a little careful with MIME types and so forth, but it seems pretty straightforward.
Just take any URL that is not defop'ed to mean a file name.
Currently, if no op is defined, the server responds with "Unknown operator.". Replace that with the code for opening a file, and if this fails, respond with a proper 404 Not Found message.
However, Subversion has the distinct benefit of practically everyone already having it installed. I think the current system works quite well: there are both Git and Subversion Anarkies, and they're kept as similar as possible.
I'm not sure this is necessary, at least yet. People seem to be quite well-behaved so far - the only breakage is accidental (and that's mostly me anyway :-/).
