Concurrency in Icon has been studied; Kelvin Nilsen's Ph.D. dissertation was on an experimental system (Conicon, concurrent Icon) which was never released.
Concurrency in Unicon as Michael proposes might be an excellent addition. Here are a few additional thoughts on his proposal. 1. making the VM and runtime system (including the garbage collector) thread-safe is a potentially Huge job. Clever techniques and compromises might enable one to avoid a massive rewrite. 2. co-expressions are indeed synchronous, co-operatively scheduled threads. One option for pseudo-concurrency would be to extend the existing co-expression mechanism to include a scheduler and preemptively switch threads every so often under explicit control of the VM. Problem #1 only comes up if you want true concurrency on a true multiprocessor, or are building atop the Posix (or some similar) threads package. 3. Since Java is thread-friendly, if you need true concurrency instead of pseudo-concurrency, it might be easier to modify Jcon to include a threads facility, and to modify the Unicon translator to work with jcont, than modify the Unicon VM. I am not pushing this, I just wanted to point it out. 4. Both the Unicon translator and underlying icont translator currently use YACC but not Lex; they have handwritten scanners. This does not contradict Michael's assertion that it would be fairly "easy" to extend the translators to include new syntax for threads. I think the big hard job would be #1 above. Cheers, Clint ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
