[erlang-questions] Service platform (longish rant)

[Roger Larsson]

On Monday 07 May 2007 22:32, Vlad Dumitrescu wrote:
> The example was
>
> with(Dict, Actions) ->
>     lists:foldl(fun(F,D) ->
>                         F(D)
>                 end, Dict, Actions).
>
>     Dict = with(Dict0,
>                 [fun(D) -> read_options_file(D) end,
>                  fun(D) -> store_options(Options, D) end,
>                  fun(D) -> post_process_options(D) end,
>                  fun(D) ->
>                          {Path, [App, Vsn]} = get_app(D),
>                          store_options([{app_name, list_to_atom(App)},
>                                         {app_vsn, Vsn}], D)
>                  end,
>     ...................
>
> I agree, not very friendly, but it works.

But it can be simplified to

Dict = with(Dict0,
	[fun read_options_file/1,
	fun(D) -> store_options(Options, D) end,
	fun post_process_options/1,
	fun(D) ->
		{Path, [App, Vsn]}=get_app(D),
		store_options(([{app_name, list_to_atom(App)},
			{app_vsn, Vsn}], D)
	end,
	...
	]).

An alternative definition of 'with' could be
  with(Dict, []) -> Dict;
  with(Dict, [A|LaterA]) when is_function(A,1) -> with(A(Dict), LaterA).

In both cases
  functions in current module with one argument can be listed like:
	fun name/1
  external functions with one argument can be listed like:
	fun module:name/1
    or even
	{module, name}

But I guess it all boils down to
	Dict1=read_options_file(Dict0),
	Dict2=store_options(Options, Dict1),
	Dict3=post_process_options(Dict2),
	{Path, [App, Vsn]}=get_app(Dict3),
	Dict4=store_options(
		[{app_name, list_to_atom(App)},
		 {app_vsn, Vsn}])
beeing kind of ugly and hard to update - add a line (Basic anyone)...
But on the other hand here you can notice some strange looking things
- is the store_options really expected to return a modified Dict
- if not why doesn't post_process_options get Dict1
- and if store_options does not return a Dict why is it feed to 
post_process_options
- ...

Note that all versions but your process based lacks one component from the 
Unix pipes - concurrency! The 'ls' is not required to finish before the 
final 'head', rather when head is finished the pipe is terminated.

> Grand finale
> -----------------
> I would like to suggest a syntax addition that would allow an even
> nicer looking source code (if I may say that myself :).
>
>     ls() => grep(_£_, "*.erl")   %% _£_ is a reserved variable,
>                                          %%     meaning "the current
> intermediate value"
>           => sort                     %% this is a process name, could be a
> pid => hd/1

But what is the output from ls()? Complete listing? One line? One char?
  ls() => sort => hd/1
Same issue for sort, and hd/1... (sort would not like one char at the time...)

>
> The operator would be semantically equivalent to
>
>     with(ls(),
>         [fun(X) -> grep(X, "*.erl") end,
>          sort,
>          fun hd/1])
>
> If intermediate values need to be saved, writing
>     Term => UnboundVariable => Next
> would bind UnboundVariable to the current result value and
> UnboundVariable will be accessible in the subsequent scope.

This would require the complete result to be passed in each step...

/RogerL