prints 0, 1, 12, 25, 102, 205, 822, 1645, which much larger than the expected 1, 2, 3, 4, 5, 6, 7, 8 because all the threads update the same global variable
Thanks for the information on continuations and threads. Your suggestion worked perfectly for me.
And if you have to know, I am trying to port a program entered in the 5th annual Obfuscated Perl Contest (http://perl.plover.com/obfuscated/). It was originally implemented using fork(), but I was experimenting with using continuations and threads just to see if it would work.
I took a look at the Perl program. Just a warning: Arc doesn't have real pipes, so if you try to synchronize on pipes like the Arc program, you're in for trouble. Also, if you implement real forks and fork 32 mzscheme interpreters in parallel, you better have a bigger computer than mine :-)
Also, I think I need to use wait() to wait for a child process to terminate, but I am somewhat at a loss as to how to accomplish this, since the manual says it takes an int pointer... Again, any help would be appreciate.
Also, in your malloc() example, don't you have to explicitly free the memory afterwards? MzScheme's GC doesn't deal with memory explicitly allocated from C, does it? (I know the example itself uses only a tiny amount of memory, but still...)
Yes and no. I think mzscheme's GC can handle it without explicitly calling free at the right time, but you have to register a "finalizer" function to do so. That function will be called when the GC collects the object.
It does not know the size of malloced objects however, so be careful (no pb there, but if you allocate something very big, mzscheme will only see a new reference and will not necessarily call GC when you will actually lack memory).
I do have one question about loading libc. Since the system doesn't automatically find libc.so for you, you need to name the path explicitly. What worked for me was
The underlying foreign implementation is looking for the
library. The problem is that /usr/lib/libc.so is not the
library and dlopen() does not know how to handle this.
A better alternative with mzscheme's foreign interface is
to use `#f' for the library -- that treats the mzscheme
binary as the library to open (which includes the usual
libc stuff.)
I believe that Arc intends to provide features sometimes considered to be OO, but not packaged in a single monolithic system like most OO langauges. So while you should (at least theoretically) be able to accomplish anything in Arc you could do in an OO language, don't expect it to conform to your concept of OO.
Exactly what do mean? Macros seem to work in functional position at least.
arc> (and:or nil t)
t
> But really, what improvement in readability do you get with the 'block style?
I agree with you on this. 'block doesn't really remove parens, it just moves them around and removes the nested structure. According to pg's Ansi Common Lisp, "Lisp programmers read and write code by indentation, not by parentheses." I find nested code to be more readable than flat code for exactly that reason, even if the parens stack up at the end of the block.
Which is exactly what I meant by "macros seem to work in functional position." But amkglor's original statement "compose does not work with macros" does not take into account the special treatment of 'compose in functional position, which is why I was confused.
And if I am not mistaken, first class macros, once implemented, could be used in other situations like your example above.
Looking at alkmglor's comment, it appears to indicate that a literalcompose doesn't work; when it's optimized out, it works fine. In other words, everyone is vehemently agreeing with each other ;)
And of course, first class macros could do this. But we don't have those yet…