|
A Fexl program may therefore be resolved inside an arbitrary context, giving whatever meanings you like to all its open symbols. This makes it easy to wrap a Fexl program in an enhanced or restricted context. For example, in a web context you probably don't want "delete_file" to be defined at all, at least not in its normal sense. So you would resolve the program in a highly restricted context which only provides a handful of safe functions, omitting all the dangerous ones.
Ultimately the core functions of Fexl are written in the [[C]] programming language. To write a new core function named "X" within Fexl, you simply create an appropriate C routine named "fexl_X". It automatically becomes available as a built-in Fexl function.
For example, here is the C routine which implements the classic '''S''' combinator (fusion), where (S x y z) = (x z) (y z):
<lang C>value fexl_S(value f)
{
if (!f->L || !f->L->L || !f->L->L->L) return f;
return A( A(f->L->L->R, f->R), A(f->L->R, f->R) );
}</lang>
Fexl functions may have side effects -- after all, they've gotta happen '''somewhere'''. For example here's the implementation of the char_put function, called as (char_put ch next), which prints the single character ch to stdout and then continues with next:
<lang C>value fexl_char_put(value f)
{
if (!f->L || !f->L->L) return f;
value x = f->L->R;
if (!arg(type_long,x)) return f;
putchar(get_long(x));
return f->R;
}</lang>
Fexl is very free-wheeling about side effects, because of course they must happen '''somewhere'''. But you the Fexl programmer can easily isolate and confine side effects as diligently as you like, factoring them out systematically, applying monadic techniques, or whatever.
Fexl has no built-in type inference system. You can check types at run-time however you like. Fexl also has reflective features which allow you to examine types and the internal data structures at run-time, for example if you want to print a value for testing or debugging purposes.
|