(Tue 2011-07-05) Here's a note on some interesting naysaying I'm seeing out there. Someone said that all I did was invent a syntax for writing lambda terms. Well no. In addition to doing that, I also wrote some code to run those lambda terms on a machine.
Another said all I did was take lambda calculus and add nothing to it other than a thin syntax layer. Why yes, that sounds about right! The purpose of Fexl is to be a thin layer of functional programming which serves as a general-purpose sequencer for some primitive routines written in ANSI-C.
Here's the thing. I like writing code in ANSI-C, but I don't want to write whole applications in it. Moreover, I need dynamic scripting capability, including iron-clad secure ("sandboxed") embedded scripting. Now you might suggest some scripting languages and environments that are good for that, but I want something very lightweight and written in ANSI-C code that I understand and control, with fully reflective capability. If I have a system written in Fexl, that system depends on nothing but a standard C compiler, and it doesn't require me to write everything in the scripting-language-du-jour with a big fat footprint. Don't get me wrong: I make my living with scripting languages, but I'm attempting to break the dependency on any one of them.
Also someone suggested that a Fexl programmer would have to encode numbers using Church encoding. No you don't -- just use numbers implemented at the machine level. But if you really want to encode numbers as pure functions, you can certainly do so, and it's surprisingly fast. But I recommend using a binary notation instead of unary.
Then he went on about the impossibility of representing concepts in the real world as lambda expressions. But that's silly. Of course you can, and I know because I've done it. You can also represent concepts as C structs, or as machine word layouts in assembly language. I can't imagine why he makes such a severe and arbitrary distinction.
