> To be specific, here are the three switches that affect the ABI: > > * per-object metadata (enables GC, introspection, safety, etc.) > * multimethods (requires metadata) > * concurrency (requires metadata; enables async messaging, STM) > > I view these features as rather fundamental and easy to coordinate. I > intend to implement metadata and multimethods in a thread-safe manner, > so that there will be no difference in their implementation when > concurrency is toggled (or, say, pthreads is used directly by the > application). > > Thanks for making the effort to reply. I value your opinion and > analysis because it helps me clarify exactly what I'm trying to > accomplish.
I'm curious to see what your prototypes of Ocean will look like. In my Church/State implementation I have implemented a low-level (C like) language and a seperate high-level language (in COLA style). Other systems like this that I am aware of usually use a "pidgin" language with a slightly different syntax and semantics to be able to compile to C or an executable (RPython, prescheme, slang). I'm interested to see if you can achieve the mixture of dynamism and C compatibilty within the same source language. What language will you write your compiler in? Will you use C for the runtime? On another note, have you been following Ian's work on jolt3? Do you have any updates or insights to add to your earlier summary? John _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
