On 11/01/2013, at 6:43 AM, srean wrote: > Perhaps you should bow to the masses and remove the "Scripting language" > moniker from Felix. It probably is doing more harm than good at this point.
The intent is that it be just as capable of ease of use as Python, Perl, Lua, or other such language. Write once run anywhere. And faster than C at the same time :) That's why the y-combinator point about "eval()" was useful to me because I'd never thought about that, rather I was thinking in terms of "not needing types everywhere" like in C, and "run your script directly without needing Autoconf/Makefile, linker switches...". The eval critierion is interesting because it's very specific not waffly like what I said above. However on further analysis, you have to recognise that whilst the eval() function is general, one still has to write code that has known types. You cannot eval a set of math functions and use them unless you already know what they do and what their types are. Scheme is a good example of a "better" eval, indeed the Felix compiler USES this. That's how the grammar is lifted into the library! Scheme is used to build the AST terms required by the compiler. Is Felix that dynamic? Nope, not yet. Is it intended to be? Nope .. a lot MORE dynamic. But at a higher level: the internet, the cloud, etc. Not a micro level like "float" vs "int". That should be static because it can be. Otherwise your system collapses in performance and ability to write correct programs. Python is a perfect example of this. The system collapses at a particular size. Approximately interscript, fbuild, etc. Some bigger systems: mailman, zope, etc exist but only through heroic effort. C++ for all its warts can handle systems an order of magnitude bigger than this. > Its memory model is still not clear to me yet, It's C++. So it uses the C++ memory model. There's a garbage collector: world stop (YUK) naive mark/sweep with precise heap traversal and conservative stack traversal. The control (execution) model extends C++ by adding fibres (coroutines). And it restricts C++ by removing strong support for exceptions and C++ style virtual dispatch. The latter is a bit unfortunate and not really intended. Felix isn't OO but there's no in-principle reason not to support C++ OO stuff as a useful minor technology; its just hard to find a simple implementation model without losing closures. All the "method like" features of Felix at the moment sacrifice vectored dispatch (i.e. C++ virtual functions) in favour of keeping closures. You can still do OO, the Java like Object system shows that. That's based on the same concept as how you do OO in C: by using a struct of function pointers. The main problem with this is that it is too dynamic. Its TOO flexible. However the Felix system uses the dynamic syntax feature to hide that power. I'm surprised it succeeds so well: I would never have used records of closures for plugins without the syntax support. -- 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
