<div>Hi,</div><div><br></div>Just thinking aloud :<div><br></div><div>A way  to start is to define concrete workflows for concrete events. &quot;What It is necessary to do if&quot;. This may make things more explicit and to clarify the problems. .Later, .maybe. these concrete workflows can be abstracted away from procedural/imperative to declarative and from concrete events to categories of events and tasks.. <div>

<br></div><div>The declarative abstract description  then could create concrete workflows. The best way to express the abstract description, and the way to transform the description in a concrete set of instructions depend on what is needed  (The workflows produced can be just informative, in the form of a textual description of activities). <div>

<br></div><div>Thus, the power users should  handle the abstract descriptions, and the ordinary users could run the engine, perhaps they should answer some questions to obtain the concrete workflows for their intended tasks</div>

<div><br></div><div>Not very informative, but better than nothing ;)</div><div><br></div><div>Alberto<br><br><div class="gmail_quote">2012/3/13 C K Kashyap <span dir="ltr">&lt;<a href="mailto:ckkashyap@gmail.com">ckkashyap@gmail.com</a>&gt;</span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My dear Haskell folks,<br><br>I work in a software company where I develop components that go into a really complex system that&#39;s built of several components developed by different teams that are geographically distributed. The components themselves run in a distributed manner across client and several servers. All our design documents are in wiki&#39;s (fashionably so). As a result of the above situation and the fact that our code base is not in Haskell, we are almost always dealing with &quot;Oh I did not know this would effect that&quot; and &quot;Oh I have no clue what all this change will impact&quot;. <br>


<br>I&#39;ve been wondering if it would be a good idea to try and create a spec for the system in Haskell, such that would could get a better handle on the dependencies. Perhaps an EDSL, that would allow Product Managers to introduce new requirements - compilation failures would indicate the areas that would need to be touched. How is it different from having a spec in a diagram - well, in that case, we are requiring humans to look at the diagram to detect dependencies instead of the compiler telling me about the dependencies. I am about to start off with some implementation to capture my idea - I can articulate it better then. However, I just wanted to throw it out there to check if anyone&#39;s had some thought in this direction or if there is some prior art here.<br>


<br>Regards,<br>Kashyap<br><br>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div></div></div>