On Tue, 2007-02-27 at 13:05 -0800, Erick Tryzelaar wrote: > skaller wrote: > > This project is pending death. 7 years of my life > > is enough to waste. > > > > > > Don't say that yet. I should get a blog up and running this weekend.
There are just too many problems. For example virtual functions introduced a performance hit, I reduced the impact only to cause other problems. The level of complexity is too much for one person: I'm the only one that has committed in months. A small group of workers could probably fix some of the problems fairly easily, but in 6 years failing to attract even one more unit of regular input is just too much to bear. Another side to this is that the C++ community has been totally unresponsive, if not actively opposed (moderators actually blocked some of my news articles). Unfortunately, the C++ object model has some very serious weaknesses, and Felix compromises to work around them. Some aspects of the ISO C and C++ Standards prevent type aliasing .. which IMHO is a stupid attempt to make C more efficient, but which actually destroys its use as a portable assembler. In addition, C++ object model is incomplete: it supports initialisation, assignment, destruction, and copying, but it doesn't provide any way to move or re-address objects: essential for advanced garbage collectors etc, eg compaction. Furthermore, the stack seriously gets in the way of advanced programming techniques, and gcc at least seriously gets in the way of the workaround (one large function). Sigh. I find it frustrating. I have something like $300,000 coming I could invest in the project, but the condition for doing that was that there was a core of working volunteers. One might compare with Neko: Nicolas Cannasse is clearly a better programmer than me. He designed and built a translator and VM for the language in a few months. He wrote an ML translator in it, then wrote the Neko compiler in that so he could bootstrap away the Ocaml compiler. There are now around 20 people using it, but Nicolas probably doesn't care because he wrote it for his own company to use, and the extra users are just a bonus. Felix actually does quite a few things I always wanted to do in a programming language. It has fibres, async I/O, typeclasses with multiple type arguments, axioms, pattern calculus (in the type system anyhow), a rudimentary kinding system, and even provides the start of a hook into theorem provers. And it still manages to trash C utterly calculating Ackermann's function, which makes it the fastest programming language on the planet :) But to really make something of it, it needs to be like GHC or Ocaml: at least one paid researcher and developer, a band of volunteer developers, and several hundred dedicated users. "If only the compiler actually worked" Felix not only outperforms GHC, Ocaml and C .. it also has a comparable type system .. as well as being able to bind more or less seamlessly to C and C++. So there's great potential .. but there has to be a time to decide it will never be realised. Erick and RF put quite a lot of effort into this project as well as me. The build system more or less works. The supported core async I/O more or less works. But the Felix libraries are seriously deficient and don't properly support typeclasses, and the RTL is a bit clunky: the gc just isn't up to heavy functional programming. The compiler handles most of the basic code ok (barring some correctable bugs), but is GADT's are applying some strain to the type system, and typeclasses to the optimiser. At least part of the problem is that the compilation model 'recalculates' a lot of stuff with independent routines, to allow the code generator to emit code in a single pass. Unfortunately it's hard to establish the required invariants, not the least because there's no simple documented model: most of the calculus is in my head. So there's quite a lot of hacking about to optimise the code, dependent on invariants that I have to remember to establish. For example there are multiple function calling protocols: general closure application, heap call, stack call, C function call, and inline C fragment insertion, and an option to pass the thread frame or not. Heap calls require RTTI for the gc. Procedures always pass a single argument, but some functions can split them up. Parameters can be unused, or they can be a useless type (unit) which is sometimes elided. There are also optimised tail calls, tail-rec calls, and self-tail-rec calls (all of which are different). There's no work around for the complexity here: it is required to generate readable <g> efficient C code. I haven't even started work on half the optimisations I know about, including for example continuation passing for functions, or the nice trick which will speed Ackermann's up by another 25% that no one else seems to have thought of (but needs a register .. ) Now compare with Pepsi/Coke system .. a few whipped up thoughts, attracting people, yet it is light years behind Felix. Or look at Ruby, which should never have attracted ANY users since it was just a variant of Python with a 'pure OO' slogan (the fact Python isn't pure OO is one of its best features :) So right now, the only way I can cope with the compiler -- forget about documentation, libraries, advocacy, applications, tutorials, release management, packaging and other stuff -- is probably a rewrite which throws out or integrates some of the features -- classes in particular would probably either be thrown out, or replace both modules and typeclasses simultaneously, and, considering Felix functions are actually C++ classes .. probably functions too.. :) I doubt I can do this without both a serious theoretician providing the theory (by which I mean *specifications* :) and another compiler writer. For example the builtin lexer could be replaced by one that handles substitutions: the code to do this is actually in the repository already (stolen from Ocaml), but I don't understand it, and it needs to be rewritten for licencing reasons. Papers describe the algorithm for NFA but not DFA construction, but they're very hard to read because they user weird maths instead of programming terminology (mathematicians don't like mutable arrays .. so they're modelled with a HOF which makes the paper almost impossible to read). -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
