Please consider finite state machines, in erlang due to TCO it's easy to
implement:
%%%% get_content_service.erl
%% Implementing next state machine:
%%
%% From (A) to (B) when "begin_tag"
%% From (B) to (B) when "content"
%% From (B) to (A) when "end_tag"
%% From (A) to end when "end_document"
%%
%% end
%% ^ ___ content
%% end_document | / \
%% | begin_tag | /
%% -> (A) ---------------------------------> (B) <-
%% | |
%% \ ________________________________________/
%% end_tag
%%
%%
*-module*(get_content_service).
*-export*([start/0]).
*-export*([loop/1]).
*start(*) ->
register(get_content_service, spawn(get_content_service, loop, [[]])),
run_test(),
ok.
*loop(State)* ->
receive
{begin_tag} -> begin_content(State);
{end_document, From} -> From ! {result, State}
end.
*begin_content(State)* ->
receive
{end_tag} -> loop(State);
{content, Data} ->
NewState = lists:append(State, [Data]),
begin_content(NewState)
end.
*run_test()* ->
get_content_service ! {begin_tag},
get_content_service ! {content, 1},
get_content_service ! {content, 2},
get_content_service ! {end_tag},
get_content_service ! {begin_tag},
get_content_service ! {content, 99},
get_content_service ! {end_tag},
get_content_service ! {end_document, self()},
receive
{result, State} -> io:format("~w~n", [State])
end.
On Sunday, November 24, 2013 at 4:33:14 PM UTC-6, Stefan Karpinski wrote:
>
> That makes sense and I would say that you can certainly use recursion just
> fine in Julia. I wouldn't worry about TCO so much until you have an actual
> problem where it's an issue.
>
>
> On Sun, Nov 24, 2013 at 5:05 PM, Piotr X <[email protected]
> <javascript:>> wrote:
>
>> Hi,
>>>
>>> Not really. As Viral said, Julia's parser happens to be implemented in
>>> scheme and we use FemtoLisp as our Scheme implementation. There is no
>>> integration in any other sense.
>>>
>>>
>> [...]
>>
>> Thanks for clearing all these questions up!
>>
>>
>>
>>
>> 2) I found a Julia-Dev thread on TCO. Is there any news on that?
>>>
>>
>> "No. TCO is not really a priority."
>>
>> I understand that very well. I guess there are many more features that
>> are much more important than TCO e.g. proper debugging / a helpful error
>> traceback, etc.
>>
>>
>> "Since Julia provides iteration as a core part of the language, TCO is
>> not especially important. I'm not entirely sure why people are so fixated
>> on TCO – perhaps you can provide some insight – why are you interested in
>> tail-call optimizations in Julia?"
>>
>> I can not speak for the others, but here is why I want it:
>>
>> I learned programming line by line with python, starting out with
>> imperative spaghetti code, and got better with time. After some problems
>> with deployment on different platforms due to the nature of some python
>> libraries I decided to have a look at some other languages, most notably
>> scheme. It was the latter that brought me to SICP - a fantastic learning
>> experience.
>>
>> My reasons are not tied to a specific project, but I hope they are
>> worthwhile enough. They are primarly pedagogic - as the state of
>> metaprogramming in Julia seems to be en par to that of Scheme, it would be
>> great to have recursive, functional programming as an option for
>> algorithms.
>>
>> And there is the integration / ecosystem aspect:
>>
>> There are a lot options in Lispland to choose from, but none of those are
>> "perfect" for me.
>>
>> -- Chicken Scheme is great. However, the only gripe I have is that it
>> does only offer green threads. Also, there is little interface with other
>> languages except C.
>>
>> -- Clojure is superb with the LightTable IDE. The lack of a proper TCO is
>> - I said it before - not show stopper. Unfortunatly, I could not get warm
>> with it's JVM/JDK enviroment. The compile times, and the startup time of
>> the JVM is a bit annoying. The real trouble is that in order to really
>> benefit from Clojure and use it as a wrapper for stable Java libraries I
>> would need to get some knowledge in Java. I would like to stay away from
>> that path.
>>
>> I hoped that Julia could offer me most Scheme characteristics and be a
>> well suited integration platform for other languages such as Python or C.
>>
>> Hope that helps.
>>
>> Cheers,
>>
>> Piotr
>>
>>
>>
>>
>
