This paper:
http://siscweb.sourceforge.net/docs/queinnec-inverting.pdf
helped me have the "aha!" moment using continuations and the web. If
you're comfortable reading Scheme, siscweb has a decent implementation
of continuation-based web programming, too. It might be good source
for ideas.
--Kevin
On Feb 13, 2008, at 9:12 PM, jm wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
