One possibility for further control of Felix entities would be a model spec:
fun f() { .. } model "C++HeapFunctor", "Felix-C-Function";
The model clause lets you specify the allowed set of models.
The default is "any of them".
If you say "C++HeapFunctor" then you always get a C++ class object
on the heap.
If you say Felix-C-Function, you get exactly a C function which also
accepts the thread_frame as the first parameter.
If the compiler gets a context that requires some models it finds
the intersection of the workable models with the specified ones
and fails if a suitable model doesn't exist.
For example, C functions can be passed as arguments, but
not where a Felix closure is required.
The idea is you get fine control of the semantics or a compiler error.
An more real example:
fun f: int -> int = "$1" model "C++HeapFunctor";
If you say that the normal "macro" behaviour will be suppressed:
no lazy evaluation. Instead a closure wrapper will be generated
and used.
Felix already has some modelling control:
fun vs cfun
proc vs cproc
and export also forces a C API. Now, normally the end user wouldn't
want to see this. However we can make a simpler interface
with the user defined grammar stuff.
--
john skaller
[email protected]
http://felix-lang.org
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language
