macrocreation wrote:
> Yariv,
>
> I suggest you have a look at seaside. Continuations not only make the
> code development easy, but you can suddenly start to develop "true"
> components and they are straightforwardly embeddable - the complexity
> of mixing and matching components becomes additive rather the
> geometric if that makes sense.
This is the argument I've heard in favor of it as well.
The bit that made the most sense to me why you'd want to do this is not
the reduction in code size (I don't think there is), but the ability to
think and code dirictly in a process flow manner instead of a finite
state machine's transitions. FSMs cause problems as they grow larger and
more complex as it gets harder to fit it all in one's head at the sametime.
Consider this bad ASCII art, adopted from "Inverting back the inversion
of control or, Continuations versus page-centric programming"
get post post
----->[get num1]----->[get num2]---->[display num1 + num2]
using the current erlyweb we'd have something like, ignoring error cases,
-module(traditional)
add(A) ->
case Method of
'GET' ->
generate_num1_form(A);
'POST' ->
F = get_fields_from_form(A),
%% uses client to store num1 as hidden field in 2nd form
case proplists:lookup(num1, F) of
none -> {ewr, traditional, add};
N1 -> case proplists:lookup(num2) of
none -> generate_num2_form(A, N1);
N2 -> generate_sum_page(A, N1, N2)
end
end
end.
What would this look like in an Erlang/Erlyweb with continuation? I'll
leave this for someone else as this what I'm trying to work out. In
psuedo code
add(A) ->
N1 = get_num1(A),
N2 = get_num2(A),
generate_sum_page(A, N1, N2).
get_num1(A) ->
generate_num1_form(A),
break/resume
F = get_fields_from_form(A),
proplists:lookup(num1, F).
get_num2(A) ->
generate_num2_form(A),
break/resume
F = get_fields_from_form(A),
proplists:lookup(num2, F).
which is really just the previous code turned inside out. The bit I'm
stumbling on at the moment is error control and branching of flow
(case/if) and how it fits into this.
Regardless, I can't understand why continuations would use so much
memory. The only things I can think of are
1) The estimate I heard was wrong.
2) The estimate I heard was for large applications
3) This is due to saving the full stack for each call (post/get) and
then keeping the old stacks around for a long time.
I keep seeing not stacks but changes in state forming a tree of changes.
ie, erlyweb taking snapshots of the values of functions at the
break/resume points but not the entire stack and these for the node of a
state tree in time.
Lasty, thanks to [EMAIL PROTECTED] for recommending a couple of papers
I'm only half through the first one as I'm not formilar with scheme. In
searching I also found this archived message which seems to indicate
some relevent papers,
http://www.cs.brown.edu/pipermail/plt-scheme/2007-April/017628.html
Jeff.
> I can't explain the gist of my argument - its one of those matrix
> things - when it sinks in you go "Wow!".
>
> Why am I still programming in erlang? I really like the scalability
> and a lot of my applications need lots of concurrent processes.
>
> I have been told any system that supports first class function objects
> with lexical closure is able to support continuation passing style - I
> think it would even be easier with erlang considering you don't have
> to worry about variable mutations and the like.
>
> hafeez
>
>
> On Feb 13, 8:32 pm, "Yariv Sadan" <[EMAIL PROTECTED]> wrote:
>> Dang, I actually realized I just overlooked something big: my examples
>> didn't use real closures -- just anonymous functions. With framework
>> support, those functions could be used as closures and their
>> environment data could be accessible in subsequent actions without the
>> controller's using the session store explicitly. I should have thought
>> a bit harder before voicing my skepticism :) (However, I believe some
>> of the disadvantages I listed still hold true.)
>>
>> Yariv
>>
>> On Feb 12, 2008 10:35 PM, Yariv Sadan <[EMAIL PROTECTED]> wrote:
>>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"erlyweb" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/erlyweb?hl=en
-~----------~----~----~----~------~----~------~--~---
