:) It's a function expression language, meaning a language for expressing pure functions of an arbitrary nature. It's really just a variant of the lambda calculus, and I compile those expressions into combinators to eliminate all variables.
For example, the "flip" function for swapping the order of two functions is this:
\flip = (\x\y y x)
But Fexl converts that into pure combinators like so:
\flip = (S (C (S I)) C)
Actually it uses the higher level combinators L, R, I, etc. so that flip is defined as:
\flip = (L I)
But the higher-level are shorthand for forms that use S and C only.
I hear ya. I consider Fexl to be at the extreme end of computational abstraction. The kind of things you reference are convenient tools for making certain lower-level things accessible from a high level sort of script.
I've used that approach in my work for many years with great success. I use ultra-simple domain-specific languages consisting of this syntax:
token token token token ...
:) Seriously though. It's amazing what you can do in a script consists of nothing but tokens or "words", e.g.
do_this 4 5
do_that x "Hello there."
Where all filler such as #-comments and white space, even line breaks, are completely insignificant. I've made a lot of hay out of languages like that.
I even have a Turing-complete language in that form, and I can define "verbs" which access any sorts of machine functions I care to provide. It ends up looking a bit like Forth but I think more clear (coming from a biased judge of course). I'm actually tending to favor that token-based Turing-complete language over Fexl for doing real work. I'm not devoted to the idea of functional programming, I'm devoted to simple, powerful, flexible, and secure programming.
Strangely, the token-based languages make my application code more "language independent" -- meaning that I can write the interpreter in any language I want (C, Perl, etc.) and it really does not matter at all. I like to keep pushing as much application logic into the scripting language as possible. With the Turing-complete language it might even be feasible to do all of my application logic in it, leaving me with only a small residual interpreter written in C. But it remains to be seen if my Turing-complete token language can really scale well to that large body of application logic.
Comments
:) It's a function expression language, meaning a language for expressing pure functions of an arbitrary nature. It's really just a variant of the lambda calculus, and I compile those expressions into combinators to eliminate all variables.
For example, the "flip" function for swapping the order of two functions is this:
But Fexl converts that into pure combinators like so: Actually it uses the higher level combinators L, R, I, etc. so that flip is defined as: But the higher-level are shorthand for forms that use S and C only.Well, these things exist in the wild, and they're not as fun & cute as yours:
http://en.wikipedia.org/wiki/Expression_Language
http://docs.jboss.org/seam/latest/reference/en-US/html/elenh...
http://java.sun.com/products/jsp/reference/techart/unifiedEL...
I hear ya. I consider Fexl to be at the extreme end of computational abstraction. The kind of things you reference are convenient tools for making certain lower-level things accessible from a high level sort of script.
I've used that approach in my work for many years with great success. I use ultra-simple domain-specific languages consisting of this syntax:
:) Seriously though. It's amazing what you can do in a script consists of nothing but tokens or "words", e.g. Where all filler such as #-comments and white space, even line breaks, are completely insignificant. I've made a lot of hay out of languages like that.I even have a Turing-complete language in that form, and I can define "verbs" which access any sorts of machine functions I care to provide. It ends up looking a bit like Forth but I think more clear (coming from a biased judge of course). I'm actually tending to favor that token-based Turing-complete language over Fexl for doing real work. I'm not devoted to the idea of functional programming, I'm devoted to simple, powerful, flexible, and secure programming.
Strangely, the token-based languages make my application code more "language independent" -- meaning that I can write the interpreter in any language I want (C, Perl, etc.) and it really does not matter at all. I like to keep pushing as much application logic into the scripting language as possible. With the Turing-complete language it might even be feasible to do all of my application logic in it, leaving me with only a small residual interpreter written in C. But it remains to be seen if my Turing-complete token language can really scale well to that large body of application logic.