Hi, John Leuner <[EMAIL PROTECTED]> writes:
> It still seems conflicting to me to mix a language like C with one like > Smalltalk/Slate. What kind of syntax will you use for dynamically > dispatched methods? Unlike Smalltalk/Slate (and C++, Objective-C, Java, C#, etc), Ocean lacks first class "objects". Instead, it uses the implementation technique of prototype multiple dispatch on the implicit "current lexical module" object plus any explicit arguments, for an effect that resembles Lispish generic functions. So, function calls look just like standard C function calls, with the difference that any function can be overloaded or replaced at runtime. > How will you pass arguments between functions and methods? I don't understand this question, since Ocean doesn't have explicit methods. Does the above answer it? > Compared to C, your language will use a lot more memory and incur many > runtime costs. Yes, that is true. You can think of the full Ocean ABI as turning on many, many debug assertions. I would expect performance similar to an equally dynamic language such as Slate. I am trying to cater to two different audiences (and I belong to both of them): * People who want to use C because they need minimal overhead for production software, but would like to develop in a safe environment that offers a REPL, memory leak detection, and other niceties. * People who like C syntax and want syntactically-conservative extensions for garbage collection, multimethods, concurrency, etc. > Traditionally this has been avoided in favour of complex compilers > and type-checking, it doesn't make sense to me to compete with > existing C compilers and safety tools like valgrind etc. I have a goal that is inspired by the STEPS project: to recreate a Unix-like environment with better features than it has now, at less complexity (by looking at the system as a whole and reducing it to core abstractions rather than trying to replace just one piece at a time). As far as a self-sustaining system is concerned, Ocean is intended to be mostly-compatible with C so that any C project can be gradually evolved to use it without having to reimplement vast tracts of legacy code or deal with FFIs. > It sounds like the programmer has too many "switches". ABI-mode, memory > safety, garbage collection, dynamic dispatch. Programs which can be > compiled with some combination of these switches will be incompatible > with another set of switches. In my experience the more features you add > to a language the harder it becomes to keep them all working together. 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. Cheers, -- Michael FIG <[EMAIL PROTECTED]> //\ http://michael.fig.org/ \// _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
