On 05/11/2010, at 10:53 PM, Lenny222 wrote: > > I've heard about Felix for some years but have mistaken it for a C++ > library like FC++ or Boost Phoenix. > My second misconceptioon was that it's dead.
Well it was. I gave up on it for a few years while I worked on my yacht, because we couldn't generate enough interest. A language needs users and developers, plural. > I am looking for something more pragmatic and more performant than > Haskell. When it works, and given the restrictions compared to Haskell, it would normally be faster. It depends whether you want things like higher order polymorphism, for example. Felix doesn't really support that. There IS some support, but not to be completely trusted at this stage (for example we have a Monad typeclass). > I'd like to invest some time and learn what Felix is and how well it > fits into the real world. Cool! So, what it is: an ML family language with a bit of Haskell and C++ thrown in. The core system is based loosely on Ocaml. As to real world: it is very much better than Haskell or Ocaml or any other language could hope to be in terms of how it binds to real world resources such as C libraries. The only language that can do this better is C++. This is no accident, it is a fundamental design goal. You will of course understand this also creates plenty of problems! The big problem as far as "real world" goes is that we don't have very much in the way of libraries: although it is quite easy to create a binding to a C library, it is a lot of work if the library is big. I would like to create a complete Posix binding for example. But I do not have a file containing the signatures of all the functions. In text form I mean (I have it as PDF but that's useless, and so is the HTML). At one stage we had a program called "flxcc" which automatically generated Felix bindings from C header files. But keeping it working was a maintenance problem, and we've just been doing a Razor Gang on Felix: throwing out a lot of stuff to cut it down to a more managable size. Quite a lot of good stuff got thrown out, for example Felix had a built-in GLR parser and DFA based lexer, it also had some support for C++ style classes. All that got thrown out. The basic model was "bloat it with features, unify what you can, and chuck out the rest" :) flxcc got thrown out. > I am willing to write documentation along the way from the persepctive > of a beginner, but wonder what's the most efficient way. > Either i'd keep the documentation to myself, which would be a pitty, > or i could share it. > One option would be the GitHub wiki. >From my perspective, Wiki's suck. The problem is that if, say, some syntax changes and examples have to be edited, with a Wiki you have alot of manual labour to do this: not just making the changes but finding where to make them. And you have to be online to do this (I have expensive slow wireless internet). Documentation should go in the Felix Git repository. Best approach: ask Erick for write access. Don't be afraid to break things .. we both do that quite regularly :) you should note there IS a tutorial, look at lpsrc/flx_tutorial.pak lpsrc/flx_tut_bind.pak lpsrc/flx_tut_macro.pak lpsrc/flx_migrate.pak However it is encoded in interscript format. Interscript is included with Felix at the moment. It is a Python program. It is a literate programming tool. All of the "tut" regression tests are generated using it from the lpsrc files (lpsrc= literate programming source). However the documentation is not generated by the build system, that is, we tangle the tutorial to get the test cases out but we don't weave it to get the HTML docs out. I wrote interscript many years ago. It is a good tool, but Erick and I are on a program of getting rid of it completely because most people don't like LP and this stands in the way of attracting developers. All that is left now is some config stuff and the tutorial. I have to write some scripts (in Felix!) to convert the interscript format tutorial to the new *.fdoc format. however the problem is that I don't want to lose the "literate" advantage that the tutorial examples are sure to compile and work because we actually run all of them in the build process. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
