On 30/03/2009, at 12:38 PM, Erick Tryzelaar wrote: > Anyone out there interested in having a meeting on the future of > felix? I'm tentatively thinking Wednesday at 7pm PST (I believe 1pm- > ish on Thursday for the Australians)
I'm a volunteer skipper for Sailability, which puts disabled/ disadvantaged people into sailing boats. Weather permitting I'd probably still be out on the water 1PM Thursday Australian Eastern Standard time (AEST). But don't forget the International Date Line .. is Thursday Thursday? > on [#felix](irc://irc.freenode.net/#felix). We've stagnated a bit > but I don't feel that felix is dead. I think some folks are just > unmotivated. Indeed. After 10 years development, the fastest compiler on Earth has no users and little interest. I had the funds for commercial development and no interest in proceeding. Unless (a) there are several more workers OR (b) someone offers to pay me I don't see the point to further development. The existing system is "proof of principle" for several major features like advanced build system, dynamic loading grammar, functional code generating C++ but as easy to use as a scripting language, high performance, interface to theorem proving systems, cooperative threading ... long list, sure there's more. > I've got some ideas on some major projects that could be fun, like > fully supporting the iphone, writing a [llvm](http://llvm.org) > backend, Felix doesn't really need even more half-finished experimental adventures, though it is of course fun to play with them. > and rewriting the standard library to take more of an advantage of > felix's capabilities. To make it more consistent would help.. > I'd also like to explore dropping features from felix that are > redundant and confusing. So would I .. like the need to interface to C/C++. How about getting rid of class, cclass, obj, cstruct the Felix parser and lexer, namespaces (keep modules of course). Also we might junk TCP/IP interface because it doesn't work reliably, STL interface, and most of the library exotica like SDL, GMP, etc. These can't be maintained by the current small number of people. > Finally, I'd also like to explore the implementation of felix, and > how it could be changed. For instance, supporting partial compilation, There's probably no need for that.. I've looked into saving symbol tables instead of parse trees, this makes more sense because it saves a LOT more compilation time. In theory it isn't so hard, but there's an awful lot of editing to make it work (to make relocatable symbols requires either renumbering things, or using identifiers consisting of TWO integers and translating the first one) However, Felix is already reasonably fast so it isn't clear why to bother with compiler performance instead of working on semantics and libraries.. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
