I thought I'd rant on a bit of a roadmap.
Scripting language?
================
In principle, Felix works "like Python". Python is a compiler just like
C. Sure, it compiles to platform independent bytecode which runs
in a VM but that's no different in principle to compiling to a program
that uses the "VM" commonly known as the C/Posix library, which
is what Felix uses underneath. Neither is an interpreter, there aren't
many of those left (bash is an interpreter).
For me one of the key things that distinguish a scripting language
from a compiled language is the tooling: with a scripting language
you can just run the text file. As of a few commits back .. C++ is now
officially (TM) a scripting language because "flx" can auto-run pure C++.
Mike Maul wrote:
"Use case of scripting languages is fast iterations
of edit, run, tweak, run and toss"
which would, in practice, eliminate Python and Ruby.
Felix can be used the same as Python and Ruby, and the
run time for scripts, including compilation, is faster in all cases
but one: the first time. Felix, like Python, auto-compiles and won't
compile text files that are already compiled.
So if you allow that the "toss" case works, albeit slowly,
there's a tradeoff different to Python, but surely not enough
of a difference to eliminate Felix as a scripting language.
I will come back to this a bit later, but for now note that the
compilation speed of flxg can be improved out of sight,
and the C++ compilation speed can probably be improved
a lot too. One reason I'm working on separate compilation.
gcc runs much faster with -O0 optimisation (and the result
would still probably outperform Python :)
Dynamics
========
I think Srean is a bit offended when I say Felix was always intended to be
dynamic. But I want to do an analogy first.
We start with a whole program analyser. But then we move to separate
compilation. Why? Because that's the RIGHT WAY (TM) to do it.
If you want separate compilation, you do whole program analysis first.
Then the bits "inside" the translation units will be fast, modulo the
chosen boundaries of those units. In particular, it's nice to be
able to "include" all the code for slow compile times and performance,
and also use separate compilation for faster development times.
The roadmap for dynamics is similar. To make a really cool dynamic language
you first have to start with strong static typing. After all you want a robust
high
performance "virtual machine" to run in and you should implement that in your
language itself, not another language. Otherwise you will get ugly and difficult
boundaries.
Felix already has some dynamics. The GC is obvious. Then there's serialisation.
Apart from "minilanguages" like Regexps.
Now if you look at the implementation of Python you see a RIGID definition
of what a type is. There's a C data structure with a fixed set of slots allowing
you to define addition, or iteration. The set is big enough to do lots of
interesting things, but when it fails you have to move to classes and
user defined protocols, which cannot be supported syntactically
(even using "hooks"). Ultimately in Python all classes are the same type
and for additional functionality you have to use arbitrary named methods.
But in Felix, this isn't the case. You can *implement* any dynamic typing
mechanism you want, and then use it -- all in the same language.
You don't need "meta-typing" API to try to work around the limitations
of the typing API.
For example... want Javascript? Forget V8. A Felix implementation
could probably be done in a few pages of code. Note I am NOT
talking about an interpreter here! I'm talking about *compiling*
code:
union JS =
| Number of double
| String of string
| ....
fun add (x:JS, y:JS) => match x,y with
| Number ?a, Number ?b => Number (a+b)
| ...
You see you can make *Felix* expressions evaluate like Javascript.
and if you don't like the syntax you can invent your own. I have done this
for regdefs .. its in the library:
regdef ident = letter ( letter | digit)*;
Clearly the RHS is not your standard Felix expression.
Dynamic Metatyping
================
For Felix, however my roadmap isn't to go directly to dynamic typing. By
analogy to
the kind of processes above, we move like this:
Whole program compiler
Serialisation and GC
Plugins, libraries, separate compilation
WOOPS! How do you make serialisation work with separate compilation?
Clearly you need a run time representation to manage it, the current
implementation is restricted but it uses the same RTTI tables
the GC uses with some additions.
But wait! Those tables are generated by the compiler. But they're
just structs in memory with a particular layout. Cannot we generate
these tables *dynamically* at run time?
What if a Felix program was loading data according to an XML Schema?
If you want a binary version of that, you need to make the RTTI tables
for it.
And while we're at it, why not "do a Python" and provide some "fixed methods"
other than "report pointer locations" (which the GC and serialisation need).
Wait, but we have another one: a finaliser, usually a C++ destructor.
So why not copy, move, default initialise, and assign too?
And why not "aggregate" meaning "make a struct at run time
as a sequence of components"?
This isn't dynamic typing (we can already emulate the crap done by Java
and Python using unions), it's dynamic meta-typing. We're constructing
types at run time, not trying to discover the type of some some object
dynamically. Our objects are still just as "static" as before in the
sense we're using binary data.
Roadmap
========
So roughly the roadmap is to get more dynamic, but to use
a solid statically typed compiled system underneath to avoid
the usual split between "Python" and "CPython extensions".
An example of this I'm working on actively at the moment
is of course the build system for Felix which itself is used
BY Felix in the "flx" tool.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
