On Mar 29, 2009, at 11:09 PM, john skaller wrote: > > 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?
That's awesome, I was wondering what you were doing on that boat. I do believe I had the right time, though I'd recommend you confirm it. Is there a better time for you? I picked that because I knew you and RF should be awake then, but I'm completely flexible. It'd be silly to hold a meeting about the future of felix without you there :) >> 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. True. The only real benefit for llvm is that I believe it'd be a lot easier for people to help out with, especially since it seems like everyone's writing an llvm backend these days. The typing stuff may be a little too daunting for the average joes like me. >> 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). Thats along the lines I was thinking of. We're just not orthogonal. I love the experimentation, but I'm sure it keeps a lot of people away because it's not a stable language. I think if we were able to slim down some, maybe build ourselves more around the idea of fthreads, we'd be a little more appealing. I'm also not sure how important the c/c++ interface is these days. So many more people are experimenting with alternative languages that we don't need the c-isms to get mindshare. To be honest, I keep expecting felix to work like python, and it's frustrating when I have to go through the c libraries to get file io to work :) > 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. Are you talking about the faio stuff? It may have some bugs, but I actually see it as one of the unique features for felix. All the other aio libraries I've seen require a hell of code to work, and faio and fthreads could be a really elegant solution. > >> 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.. Yeah, felix is pretty speedy, but when you include the c++ compiler, the speeds go down a fair amount. I'm not sure if it would be that reasonable to work on a codebase the size of the felix compiler. Ocaml's probably one of the fastest compilers I've seen, but it still takes a couple minutes to compile felix for me. I can't imagine that felix+g++ could be orders of magnitude faster than ocaml. So, it'd be pretty painful if you were just tweaking a small section and you had to wait a minute for everything to recompile. I think it could help out with the end user experience. I also believe that llvm could help out with this as well, since they already support working with multiple object files natively. It'd require even deeper changes to the compiler though. ------------------------------------------------------------------------------ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
