No, I have no plan to replace Ocaml yet :) Felix currently compiles using flx. In turn, flx invokes flxg (Ocaml) and flx_pkgconfig .. which is written in Felix. This creates a circularity.
This circularity is resolved as follow currently: flx_pkgconfig is built first, using hand crafted Python script to replace what flx would do. This script is split between a core part of fbuild (which supports Felix directly) and part of the Felix build system extension. The script emulates what flx_pkgconfig would do by doing nothing. Instead, we note that the one thing flx_pkgconfig does that is mandatory for C++ compilation is that it maps abstract resources to #include files. But, I know what those files are, so the repository directly includes the output that flx_pkgconfig would produce if it existed and was invoked when compiling itself. Now, I am thinking to write more tools in Felix that become part of the compilation and build process. Several of these already exist, but they're only required after they've been built by the normal build method: these include flx_cp, which is a sane variant of the unix cp command. flx_cp uses Perl regexps and replacement syntax to copy files (as well as guaranteeing no clobbering). However there is another tool, flx_tangle, which already exists, and is used to verify that the tutorials contain working code, by extracting that code, subsequently we run the code and check its output. Flx_tangle is a mini-literate programming too. It processes a document in fdoc format which can be displayed as "documented code" by the webserver, and, with flx_tangle, it can also be compiled. This works well now: the new tutorial text is checked this way automatically by "make gendoc". Now why am I telling you all this? Because I want to put the whole library into this format! At present some tools can document the library by extracting special //$ comments. This is fine for an index, especially as it hyperlinks to the actual code. But it is useless for *explaining* how the library module works. I do NOT want to explain every library module in a separate document: it is impossible to keep the documentation accurate. It requires repeating at least the types and signatures of the library in the docs. No way Jose! Not enough resources for that. Now I am not writing this to argue about literate programming (there are separate concerns here, worth discussing). The issue is: how do we extract the Felix source code from the Fdoc sources with flx_tangle to create the standard library, when we need the standard lbrary to compile flx_tangle in the first place? METHOD 1 The first method is simple and I am already using this method to support generated documentation such as the library index. With that method I run "make gendoc" and the web pages get generated from the library sources. The generated pages are tracked by git in the repository, so I just commit them. When a user gets Felix from git, there's no need to generate the docs, the job is already done. The big negative here is that these are dependent sources. They're NOT editable because any changes you make will be clobbered by the next gendoc. I wish there were a way to specify that in git. In the generated code we might add "warning, generated do not edit". This method will work for the library too. The main caveat is that with a mixture of wrapped and non-wrapped library code, any contributor will need to be careful to edit the original independent source. [That's a BIG negative of literate programming, because IDE's and editors are not good at handling the mixed format of LP sources] METHOD 2 This is an advanced version of method 1, in which we seek to extract the library code from the original source (LP code) without needing to commit the product files (actual Felix code) to the repository. We still have to cheat the repository by committing generated code, but we move one level up. What we do is we commit the C++ generated by Felix for the core tools: flx_tangle, flx, flx_pkgconfig, to the repository. We then use C++ to build these tools. If we want, we can use these bootstrapped tools to rebuild themselves from Felix sources (or, indeed, from LP wrapped versions of them). So, one aim for the build system in the near future is to ensure we can generated "packaged up" versions of tools as C++ source code that can easily be built. Possibly we just add a Makefile to the directory containing the generated sources. Doing this has another advantage. If you don't want your boss to know you're using Felix, just supply the C++. Well, that's a joke but the real use is to generate tools conforming to common package manager specifications. Then Felix can be used to create tools ready to package for ArchLinux, Debian, Ubuntu, Redhat, or whatever (in fact with a bit more work "flx" can be taught how to generate the package scripts). This is a major advantage of Felix over some other systems. Bootstrapping on a new platform should be a breeze, because in principle, you can just generate targeted C++ code, ship to the new platform, and compile. IMPORTANT USE There is a really important use of this: if the build system is rewritten in Felix, how do you build Felix without Felix?? And now we have an answer: all you need is C++ and an ordinary kind of bootstrap build tool (like make or even fbuild). So in the future, I may write some build tools and there will be a bit of duplication and confusion during the rephasing. -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
