Re: Y Store /Closures

[Sundar Narasimhan <address@hidden>]

   Sundar Narasimhan writes:
   >
   > Personally speaking I feel that flows are very poorly characterized
   > by textual programs (regardless of the language they are in) that
   > can often represent only ONE serial course of action (it shows you
   > how dominant the single program-counter paradigm is :). struts 2-d
   > designers are a bit better in visualization of web app flows (I
   > wonder if "covigo" is still around -- you may want to look them up
   > too), but in any complex app, the flow diagrams tend to get fairly
   > complex and hard to manipulate. I take it you haven't used such
   > tools.

   Flow diagrams don't modularize very well -- I think flowcharts were
   abandoned for good reasons. 

Agreed -- which is why I think the covigo designer went over well with
me. It was gratifying to see people rethinking some of these age-old
problems -- and let me tell you that having a set of charts/flows
(even in 2d, even in multiple tabs..) *is* a great way of
communicating with one's clients who are not programmers -- while
we're talking about code construction and code maintenance
phases/time/costs often in this list -- let us not forget the other
phases in the normal life-cycle of a software/web application. Such
tools help in that they catch business related flow errors or plain
useability errors right in the first meeting (but hey, if people are
hacking these adjuncts in Visio, I don't want to dissuade them, after
all we need to keep some things secret :)

(For those that haven't seen such tools flow designers are really just
flow charts with a packaging/module concept throw in w/ some
click/drag tools to make modularity boundaries easy to see. They are
quite common in voxml and wireless app development -- covigo is just
an example.)

Thanks for the pointers below. I actually don't like constraint based
approaches for this particular set of problems (perhaps I don't see
how such approaches apply exactly -- because in Web applications, you
often do want to specify a->b->c->d etc., and not have that emerge as
the result of some constraint evaluation), but I haven't seen the
Laszlo talk you refer to below.. so will look that up.

   I think that the future really lies in
   constraint-based approaches, like the Laszlo LZX language that was
   demoed at LL2. I thought that was one of the most impressive talks at
   the whole workshop.

   I could point out that continuations make implementing backtracking
   engines for constraint solvers much easier, except that I won't. While
   naive engines are easy to write, putting in heavy optimizations is a
   lot harder. As a result, I am not sure that even continuations are a
   powerful enough abstraction for managing control flow.

   Recently I read Hughes' paper _Generalizing Monads to Arrows_, and
   have been thinking that it potentially offers a very disciplined
   methodology for adding stack inspection primitives to a
   language. There are a lot of neat uses for this -- optimizing
   backtracking engines, generating genuinely context-sensitive help
   messages, better logging, and debugging, to name just a few. This list
   looks a lot like the selling points of aspect-oriented programming,
   which isn't surprising because AOP has rich stack-inspection
   primitives. But this way could potentially let users define AOP advice
   in terms of actual object values rather than regexps on method names,
   which seems a lot cleaner. Stack inspection, of course, is another way
   of saying "reflection on continuations".

   -- 
   Neel Krishnaswami
   neelk@alum.mit.edu