Typically in Erlang you write ..
(fun(X) -> X * 2 end)(6)
to get 12 as the result. With string lambda, you write ..
(utils:lambda("X * 2"))(6)
to get the same result. Ok, counting the characters of the module and the function, you grin at the fact that it is really more verbose than the original one. But we have less boilerplates, with the explicit function declaration being engineered within the lambda.
A couple of more examples of using the string lambda :
(utils:lambda("X+2*Y+5*X"))(2,5) => 22
(utils:lambda("Y+2*X+5*Y"))(5,2) => 34
Less noisy ? Let's proceed ..
You can have higher order functions using the string lambdas, and with lesser noise .. The following are based on original Javascript examples in Oliver Steele's page ..
lists:map(fun(X) -> X * X end, [1,2,3]).
-> [1,4,9]
lists:filter(fun(X) -> X > 2 end, [1,2,3,4]).
-> [3,4]
lists:any(fun(X) -> length(X) < 3 end, string:tokens("are there any short words?", " ")).
-> false
and with string lambdas, you have the same result with ..
utils:map("X*X", [1,2,3]).
utils:filter("X>2", [1,2,3,4]).
utils:any("length(_) < 3", string:tokens("are there any short words?", " ")).
In the last example,
_
is the parameter to a unary function and provides a very handy notation in the lambda. Here are some more examples with unary parameter ..%% multiply by 5
(utils:lambda("_*5"))(8).
-> 40
%% length of the input list > 2 and every element of the list > 3
(utils:all_and(["length(_) > 2", "utils:all(\">3\", _)"]))([1,2,3,4]).
-> false
Explicit Parameters
As per original convention,
->
separates the body of the lambda from the parameters, when stated explicitly and the parameters are matched based on their first occurence in the string lambda ..(utils:lambda("X Y->X+2*Y"))(1,4).
-> 9
(utils:lambda("Y X->X+2*Y"))(1,4).
-> 6
Implicit Parameters
If not specified explicitly, parameters can be implicit and can be effectively deduced ..
%% left section implicit match
(utils:lambda("/2"))(6)
-> 3
%% right section implicit match
(utils:lambda("10/"))(2)
-> 5
%% both sections implicit match
(utils:lambda("/"))(12,6)
-> 2
Chaining for Curry
The operator
->
can be chained to implement curried functions.((utils:lambda("X->Y->X+2*Y"))(1))(4).
-> 9
or deferred invocation ..
Fun=(utils:lambda("X->Y->X+2*Y"))(1).
-> #Fun<erl_eval.6.72228031>
Fun(4).
-> 9
Higher Order Functions
String lambdas allow creating higher order functions with much less noise and much more impact than native boilerplates in the language.
%% compose allows composition of sequences of functions backwards
(utils:compose("+1", "*2"))(1).
-> 3
%% higher order functions
utils:map("+1", utils:map("*2", [1,2,3])).
-> [3,5,7]
lists:map(utils:compose(["+1", "*2"]), [1,2,3]).
-> [3,5,7]
And here are some catamorphisms ..
lists:reverse()
is typically defined by Erlang in the usual recursive style :reverse([] = L) ->
L;
reverse([_] = L) ->
L;
reverse([A, B]) ->
[B, A];
reverse([A, B | L]) ->
lists:reverse(L, [B, A]).
Here is
reverse()
using catamorphism and delayed invocation through string lambdas ..Reverse = utils:lambda("utils:foldl(\"[E] ++ S\", [], _)").
-> #Fun<erl_eval.6.72228031>
and later ..
Reverse([1,2,3,4]).
-> [4,3,2,1]
Or the classic factorial ..
Factorial = utils:lambda("utils:foldr(\"E*S\", 1, lists:seq(1,_))").
-> #Fun<erl_eval.6.72228031>
and later ..
Factorial(5).
-> 120
Motivation to learn another programming language
I am no expert in functional programming. I do not use functional programming in my day job. But that is why I am trying to learn functional programming. Also it is not that I will be using functional programming to write production code in the near future. We all know how the enterprise machinery works and how a typical application developer has to struggle through the drudgery of boilerplates in his bread-earner job. Learning newer paradigms of programming will teach me how to think differently and how to move gradually towards writing side-effect free programs. The principal take-away from such learning is to be able to write a piece of code that encapsulates my intention completely within the specific block, without having to look around for those unintentional impacts in other areas of the codebase.
I am a newbie in Erlang and the attempt to port string lambdas to Erlang is entirely driven by my desire to learn the programming language. The source code is still a bit rusty, may not use many of the idioms and best practices of the language, and may not cover some of the corner cases. Go ahead, download the source code, and do whatever you feel like. But drop in a few comments in case you have any suggestions for improvement.
- lib_lambda.erl (the string lambda implementation)
- lib_misc.erl (miscellaneous utilities)
- lib_lambda_utilities.erl (utility wrappers)
10 comments:
Nice, congratulations!
I can't seem to open the attached files. Can you host them elsewhere?
It would be really neat to use Erlang parse substitutions to do this. You'd eliminate the run-time overhead of performing the string hackery and function instantiation.
@Anonymous:
I do not have any alternative site for hosting. If u send me your email address, I can mail the code to you. My email address is [dghosh at acm dot org].
@mike:
As I mentioned, I have only started learning Erlang. Will u please pass on a few pointers on parse transformation in Erlang ?
Amazing!
You could host it on google code :)
Here is a google code URI :
http://code.google.com/p/erl-string-lambda/
Parse transformations are (very roughly) something like Erlang's version of Lisp macros. It would allow, for example, the Erlang code F = lambda('+1') to be translated at compile time into the corresponding "fun" definition. I too am a novice at Erlang, but from what I've seen on a few blogs (Planet Erlang, Yariv's Blog, etc) it doesn't seem very hard at all.
what a truly horrible idea. this reminds me of the bad old days when people did things in C like:
#define EVER ;;
for( EVER )
do_something();
erlang has a perfectly fine mechanism for creating anonymous functions. why kludge it up with string hacks?
Pithy and illuminating, thanks ^_^
Post a Comment