I share your guess that 'obj is a contraction of "object". I don't think it means exactly what your example suggests. Continuing your example, if you write
(= conanite vampire)
, the symbols 'vampire, 'conanite and 'Dracula all refer to the same object instance, so it's probably not what you want. In other words, you can turn conanite's hair blue like this:
(= Dracula!hair 'blue) ; *not tested*
I don't know if it's the glue, but I think 'deftem ("define template") and 'inst ("instantiate template") do what you describe here.
(deftem vampire name nil fangs 2 hair 'black requires 'blood) ; sorry, my vampire is defined a little differently
'deftem sorta kinda creates a "class" - but only with data slots, no behaviour.[1] Now, if you want to call up some vampires,
inst is pretty similar to obj, except internally it relies on a set of preconfigured "templates" which provide the set of keys (and their default values) for the thing you are going to build. It's used in blog.arc to define blog posts, as well as news.arc to define news items, and user accounts.
[1] at least, not by design, but there's nothing to stop you from assigning a function as the default value of any slot; except then it couldn't really be written to disk ...
There was a vanilla arc profiler pushed to anarki a while ago - see http://arclanguage.org/item?id=5318 ... it requires you to specify which functions to profile. Which could be more or less useful, depending on what you need.
I'd guess that any kind of decent profiler has to get in under the hood somehow - so to get something similar working for vanilla arc you'd need to go hacking ac.scm, probably somewhere inside
I believe the strange behavior palsecam discovered is actually correct.
I believe the behaviour isn't even strange. Inside your for loop, (thread ...) creates a closure which references i, and when the closure is invoked, it looks up the current value of i, which has in the meantime changed.
(def test-strange-behaviour ()
(let fns (accum x
(for i 0 10 (x (fn () (prn i)))))
(each f fns (f))))
(test-strange-behaviour) ; displays "11" 10 times
javascript has the same behaviour:
<script type="text/javascript">
var fns = [];
function strange() {
for (var i=0; i<3; i++) {
fns[i] = function () { alert(i); }
}
for (var j = 0; j < 3; j++) {
fns[j]();
}
}
strange(); // alerts "3" 3 times
</script>
The workaround is to outsource the closure-creation to another function:
(def loop-work (i)
(fn () (prn i)))
(def no-strange-behaviour ()
(let fns (accum x
(for i 0 10 (x (loop-work i))))
(each f fns (f))))
(no-strange-behaviour) ; displays 0 up to 10
This works because now the closure references the i that belongs to the invocation of loop-work that created the closure; nothing modifies that i. The strangeness has nothing to do with threads; it's only about closures.
This is an awesome reference, thanks. I'll be using a few of these. The pi calculation uncovered a rainbow weakness: rainbow relies on java "long" integers for 'int types; but these are 64-bit signed integers and the algorithm fails at the 5th digit. So I'll need to think of a way to incorporate arbitrary-precision maths before I can run this benchmark. One thing is certain: using java's BigXXX family of numeric types is going to hurt.
Another arc3 change you might consider adding is that "set" was renamed to "assign".
jarc's build.xml makes some assumptions about tomcat which I don't have installed; I changed build.xml to point to my copy of javax.servlet.jar in order to compile jarc. I think it's ok (license-wise) to package the servlet jarfile along with your project so people don't have to go hunting for it.
You mention on the sourceforge page "Therefore web apps with the Arc html.arc package won't work. " - arc's web server doesn't actually use continuations, it uses closures, so they probably should work on jarc.
The proper symbol to declare for atstrings is "atstrings"
(declare 'atstrings t)
(you have "atstring", I was about to complain that they didn't work :))
this is a disadvantageous side-effect of using "java -server" - startup time is significantly longer. And I need to not run tests automatically on startup, that delays the prompt, too.
This was more about the official Arc on MzScheme than Rainbow here. Rainbow is a special case.
> not run tests automatically on startup
Yes, I remember I disabled them when I was using Rainbow for the last time.
Oh, and just FTR, there were a failed test, which I think was about a little problem in internationalization handling. There was a message about a decimal number not being OK, because my locale is fr_FR and the correct decimal separator in France is "," and not ".".
(but this is really not a big deal. Plus, i18n is terribly complex to get right. Plus, most of us (people not having English as their mother tongue) are so used to get fucked we don't even bother with this kind of things anymore.)
> hey, I like my 'in :))
Hihi, I see you've submitted a new "correct" version on the concerned thread, this is really cool.
Anyway, don't take me too seriously. I just expose my views quickly & in a direct manner, and I don't think they're (at least always ;-D) correct. I'm glad you defend yours, and I respect you a lot for that. But sorry, the "useless" here, at least, was too much.
And on the end I suppose we think the same here: (performance) improvements are a good thing to do. I was actually glad to see the "A faster 'in" thread, I prefer that 100x than seeing a thread which would argue Arc is perfect in its current form and people are morons not to think so.
