Hi Ian, I was wondering how much your current thoughts on FONC have evolved from the original COLA paper you wrote (pre-VPRI).
Could you detail what concepts are the same, and what has evolved? Has the concept of "the real thing" changed much from your original formulation? (e.g. is jolt just an intermediate step which will eventually be superceded?) Barry Silverman -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Piumarta Sent: Tuesday, November 27, 2007 6:11 PM To: VPRI Fonc Subject: Re: [fonc] goals On Nov 23, 2007, at 5:04 AM, Waldemar Kornewald wrote: > wait for Ian to make an official statement. Can I make an officious statement instead? ;) > What are the goals for the programming language you are creating? For the language: - minimum 'default' syntax[1] and semantics[1] to satisfy the following bullet points - malleable syntax, semantics and pragmatics (runtime support/ primitives) - completely self-describing (from machine insns to HLLs) and self- hosting - static and dynamic compilation and anything in between - support for static[1] and dynamic[2] typing and anything in between[3] - late-bound implementation that could replace itself completely at runtime[4] [1] minimum needed to (1) understand C header files and generate library glue and check API correctness and (2) for [3] below [2] including multiple dispatch, since the cost is more than amortised by simpler back-end and numeric code [3] e.g., static type annotations that mangle selectors to help create transparent 'dynamic cast' mechanisms between objects and primitive types [4] including function calling conventions, dynamic dispatch mechanisms, etc. For the system (as opposed to the language): > As far as I understand the goals for the language are: > * increased productivity (20K lines of code) > * more correct code (?by using better concepts and automatic > checking?) A goal is certainly to create an environment conducive to these. See my previous message about intent vs. optimisation. > * ?better performance than Smalltalk? It entirely depends on what you are trying to do. If you stay entirely within the functional part of the language and avoid closures you can expect performance as good as (or even better than) C. If you spend most of your time sending messages, count on them costing 150% to 250% of a static (C-like) function call for one dynamic (single) dispatch. If you build your own inference engine and feed it prolog, your might never even terminate. ;-) > What about goals that give this language an identity: > ? easy to learn No. Trivial to 'mutate' into a language that is easy to learn: YES! > ? minimalistic syntax Yes. > ? very readable code No. Conducive to creating languages that attempt to optimise readability: YES! > ? free of unnecessary complexity Yes. > ? easy and natural to think in No (except for a very particular kind of brain). Conducive to creating systems that are easy and natural: YES! > ? attract many mainstream programmers No. Conducive to creating systems/languages (standard or otherwise) that will attract the mainstream: YES! > If you say "yes" to most of them could you (and the other VPRI > members) please order them by priority? All of the above. The 2.5 'yes' responses should fall right out of the circular system described at the start of this message. Cheers, Ian PS: Seeing the next message in this thread, I agree with everything Yoshiki said. (He was being way too modest in the last line of his reply.) _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
