Hi all (is there anyone here? :)
Currently, I'm reworking the compiler to simplify some of the
processing, so I can more easily discover if the intended language
rules are actually the ones implemented.
One of the driving forces at the moment is the identity:
f a <--> a . f
i.e. operator dot always means exactly reverse application.
///////////
Some of the rules have changed. The idea that
a . j = b
actually means
(&a) . j <- b
doesn't fly with compact linear tuples or arrays. Even though the array is
addressable,
component j may not be. So unfortunately, assignment stays because
a . j = b
has to work even if a is compact linear. One consequence is the loss of
generality such that the methods "stl_begin" and "stl_end" will not
compile correctly for compact linear arrays, and consequently
array sort can't work (because it uses C++ sort which uses C++ iterators).
One approach to this problem is simply to ignore it. This sounds bad, but
actually
it is already the situation with any type class: code binds, but doesn't
instantiate
if you fail to provide a suitable instance. So polymorphic code which assumes
addressable arrays and tuples have addressable components will simply
fail "as if there is no instance for the pointer projection operator".
[The compiler error message may leave something to be desired though .. ]
Note that sort cannot be rescued: C++ will work fine with an array iterator
built
from a pointer to the start of the array plus an index, provided a suitable
dereference function can be provided, and its easy to provide one that
fetches a value, but C++ requires
*p = fred
work too, and there's no way to make that happen because the C++ type system is
brain dead and can't tell the difference between an lvalue deref and an rvalue
deref
(i.e. get and set methods).
//////////
One of the core aims here is to write some more exhaustive tests that validate
language rules. Documentation should state the rules and display the tests.
The reason for desiring that is to convince potential users Felix actually
works :)
/////////
The other thing worth doing is comprehensive performance testing.
It is easy to compare Felix with, say, naive C code and Ocaml.
We could also throw in Python although that's a lot harder because Python
is going to exceed reasonable time limits on some tests.
Again, the reason for desiring this is to convince potential users Felix
is actually fast.
///////
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
