On 02/07/2013, at 5:04 AM, srean wrote:
> Felix doesn't use linear scoping. It uses setwise scoping. Everything in a
> "scope"
> can access everything else, the order is irrelevant.
>
> Yeah I know about this and I had often wondered why. How hard are fwd
> declarations.
They'r'e a nightmare.
Interface specs are required for plugins. It's a pain.
With Felix, you just write your functions, mutual recursion
can happen without forward decls.
However the BIG problem isn't functions, its recursive types.
If you want to understand just how major the problem is look at the
Felix library sources. There are classes for directories, file status,
date and time, processes, etc. Common unix like thingos (that
also work in Windows).
If you think about it, these things are all interdependent.
If you're forced to make your modules (files) in a strict hierarchy that
can be topologically sorted (like Ocaml) it is a major constraint on
freely factoring your code into logical units. C does not have this
problem with functions: compile in any order, declare anything
in any order (as long as your incomplete types are used via pointers).
C++ cannot do this with templates. Still. Grrr.
Ocaml .. well its a nightmare, as I said.
In Felix it's a breeze. No ordering constraints. Define stuff anywhere.
And yes .. it took over two years to get the lookup code in the compiler to
work :)
Just to give you an idea you can do this:
typedef config_type = typeof (#Config::config);
// #f means the same as f()
The type here is a record, i.e. an unnamed struct type so it doesn't
have a name, like a tuple type. If I want to pass it to a function the function
has to know the type.
> I am sure it affects compile speed as well, are set-wise scopes worth the
> trouble ?
>
> But even if you could stop this, you end up with Ocaml:
>
> To me Felix is a more pragmatic and speedy Ocaml :)
The compiler isn't .. the compilation process is at least 10x slower than
Ocaml, maybe more. For compile speed Ocaml rocks.
Felix is plagued by the speed not only of flxg compiler but also
the underlying C++ compiler. C++ compilers are typically
EXTREMELY slow especially in optimising modes and are
incapable of handling big functions .. recall Felix inlines
everything so it tends to produce big functions :)
The bootstrap builder takes several HOURS on my Macbook Pro.
And on my small Rackspace slice. I'm debugging it at the moment
and I'm into day 3 chasing down a simple linker library ordering
bug. I actually know what the problem is, but it doesn't manifest
on OSX, only on Linux. Command line editing on a server in Dallas
with a 20 second delay between TCP packets on my flaky internet connection
adds to fits of loud swearing.
> Regarding an ATS backend, I would think it would be wise to keep the C++ one
> around.
ATS generates C. So the idea is to do both. Felix could bind to ATS just as it
binds
to C and C++. The we could have libraries written in ATS, since they're just
compiled down to C its just another step.
Actually I'm considering how to do a Javascript back end. The idea here is not
to generate all Javascript, but to build an online app consisting of C++
webserver
plugins and Javascript browser client code.
For client server applications nothing beats http(s) these days. HTML5 and
Javascript are the go. Whether I like it or not :)
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
