Although it might be better to make a thread pool, where each Arc-side thread is a "task" (which will reschedule itself until it ends), much like how Erlang does it and how SNAP will eventually do it. This will allow you to easily launch and destroy thousands of Arc-side threads on a machine with far fewer cores.
Of course there's the minor problem of I/O then... you'll have to use nonblocking I/O in the VM and emulate blocking I/O on the Arc-side by setting up a poll for the Arc-side task.
I didn't have in mind assignment. I was thinking at functions such as append that desctructively use their arguments. In Scheme such a function is called "append!", in CL "nconc" but in Arc there is no standard naming.
The problem is that when using join with zap you need to cons a lot of memory, while a destructive join would not cons up memory, it would just traverse the list setting the right cdrs. Probably the expression "recycling operations" describes better what I wanted to say, because operations such as nconc reuse the memory of their arguments.
This would mean to have a huge hash table containing all destructive operations, and that a lookup in that table would be necessary just to call a function. A namespace system (such that of CL) would be the right thing, because names in such a system are resolved before runtime.
(d::join ...)
The character #\: has been already taken, though.
Maybe a good name would be (d/join ...). What do you think?
Depends. If we accept the modification in http://arclanguage.com/item?id=7451 , it would be possible to make modules into a macro, and D!join would be resolved during macro-expansion into a 'uniq that can be 'symeval -ed to the destructive join operation.
That's what I would have thought, but it appeared to work. Though it may only have worked because of your second observation. And given that, I will repeat my desire for the destructive! custom. I like it because it doesn't interfere with any name (e.g. how alist could be association list or the "is the object a list?" predicate [though that's a bad example, you get the idea]), it has seen use in multiple languages, and it pretty clearly says what it means (assuming you want to encourage functional programming, as I think we do).
I suggest running a poll on this - of course, pg probably won't care either way, but we can integrate his code into Anarki next time he bothers to release an update, ne?
I think this convention is good; I'm just somewhat concerned with the fact that foo!bar is plenty overloaded.
edit: IIRC this has been suggested a few times before already, so I think there'll be good support for this - but it means we will then have to formally standardize the ssyntaxes too.
True. What about ehird's variation (from the same thread)? It's a little more complex but should accomplish what you're looking for, since all the work is done at read time.
Didn't try it tho, so give it a spin and let us know ^_^
Well, pretty much any solution involving a macro isn't going to do what I want. By necessity, calling a macro requires parentheses and a token. My solution just changes two parentheses to curly braces and requires no extra tokens. It will always be more lightweight than any macro solution. That's the main goal of my feature.
Ah, so it's a change in ac.scm ? Hmm. Just out of curiousity, do you think you could do this just in the 'do macro? Although you do lose the ability to do that in the function body. Hmm.
Also, since this feature hijacks some valuable characters, it would need to be applicable for far more situations than just 'do, or it would be a waste. I believe it fulfills this requirement.
It's an interesting idea, but unfortunately I can't really say that I'm feeling it (now mind you, I've made plenty of suggestions on this forum for ideas that were far worse than this one :-)
Here's the main issues I have with it:
1. Breaks the symmetry of declaration vs. use of parameters- If you're using a variable you should see it declared somewhere. It is true that anaphoric macros like 'aif break this rule, but the payoff with these macros is really high because they allow you avoid an entire 'let form. This makes them worth having, anyway.
2. The token count in the body of the macro doesn't change appreciably- Yes, you do have one less 'unquote-splice reference, but that is a pretty small gain.
3. The rule for macros used to be "if you see a comma, data is being spliced in". The comma used to divide the syntactic from the metasyntactic content- This now breaks that rule.
4. The Ampersand is a potentially extremely valuable symbol character that could now no longer be used for other purposes as the language evolves.
5. In a way, the body parameter is still there, it is just hidden inside of the word 'bod. If the 'bod macro offered some deeper insight into macro creation this wouldn't be the case- However, since there's a one-to-one correspondence between the 'bod macro and the 'body parameter, this macro is really just a way to move the 'body parameter definition to a different place in the function syntax. (That's why, for instance, I like the fact that arc doens't bother with a '1+ function)
The original pg article referenced was about having local variables without a let. This article, as a whole, is a bit confused, so it's hard to know what he's trying to say. Bottom line, I don't think he got the gist of the pg essay he references...