cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@metalanguage.com>
Subject Re: "Continuations" vs. "Stateful Execuation" (was "Preserving Rhino State")
Date Sat, 09 Mar 2002 19:02:11 GMT
Judson,

Christopher started to add Scheme-like continuations to Rhino's
implementation of JavaScript. If continuations are in JavaScript, I
don't see why we cannot have two different back-end implementations to
choose from.

Ovidiu

On Thu, 7 Mar 2002 13:33:38 -0600, Judson Lester <judson@irev2.com> wrote:

> On Wednesday 06 March 2002 05:35 pm, Ovidiu Predescu wrote:
> > On Wed, 6 Mar 2002 18:05:42 -0500, Jason Foster <jafoster@uwaterloo.ca> 
> wrote:
> > > > I looked on the Rhino code, and also spoke with Christopher Oliver
> > > > (Rhino serialization) and Norris Boyd (Rhino main developer) about
> > > > continuations support in Rhino.
> > >
> > > You *have* been busy :)
> > >
> > > <snip content="full continuations are out"/>
> >
> > Yep ;-)
> >
> 
> Would this really be so bad?  Certainly the set of utility that continuations 
> supplies minus the set of utility from CPS is not null, (well...I'll concede 
> the point as OT) but isn't the set of utility we need for Cocoon from 
> continuations intersected with the set that CPS provides is identical to the 
> first set, no?  I mean, don't we get everything we want from CPS?
> 
> <snip>
> > > Near as I can tell, the really big thing, other than transparent states,
> > > will be the abilities to call a Cocoon pipeline for output and to
> > > construct pipelines on the fly.  <-- deliberate Functionality Syndrome
> > > provocation, but let's be honest... it *will* happen regardless of
> > > whether we use Rhino or FlowScript.
> >
> > As I said in an earlier message, we should not have a language
> > designed for the average programmer, but for the hackers we all
> > are. It would take a lot of words to explain why we should do this,
> > and other people have done much better explaining this. Therefore I
> > ask you to go read some interesting stuff:
> >
> 
> I think both your references could as easily be read for either side of this 
> argument.
> 
> >   http://www.dreamsongs.com/WorseIsBetter.html (long version, highly
> >   entertaining and funny)
> 
> In which it's argued that Lisp is a bad solution because its better.  Or 
> worse.  Or not.  He doesn't know.  In essence though, the Worse is Better 
> suggestion is that less structured systems are prefered...which tends to 
> attack the purity suggestion later.
> >
> > Five questions about language design:
> >   http://www.paulgraham.com/langdes.html
> 
> I thought the suggestion that CPS in servers would be great, real 
> continuations better "if it isn't too costly." 
> 
> > > I'm not trying to take anything away from continuation-style programming,
> > > Scheme, or any other language.  I'd actually like to learn about this
> > > stuff.  What I'm wondering is whether we are pursuing purity at the
> > > expense of maintainability and comprehension?
> >
> > Probably this is controversial, but maintainability and comprehension
> > usually come from purity. The whole apparent complexity that you see
> > in Lisp like languages is built on top of only 5 (five) operations:
> > quote, variable reference, lambda, if, set variable and procedure
> > call! Everything else is syntax only, which is translated to above 5
> > operations.
> 
> And to some extent, the obtuseness and confusion of Lisp results directly 
> from the concision of its basis.  Is there a real reason to pass up Rhino 
> just because it won't do real continuations?  Isn't CPS sufficient for our 
> purposes?
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message