Hi,
Just thinking aloud :
A way to start is to define concrete workflows for concrete events. "What
It is necessary to do if". 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..
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).
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
Not very informative, but better than nothing ;)
Alberto
2012/3/13 C K Kashyap
My dear Haskell folks,
I work in a software company where I develop components that go into a really complex system that'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'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 "Oh I did not know this would effect that" and "Oh I have no clue what all this change will impact".
I'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's had some thought in this direction or if there is some prior art here.
Regards, Kashyap
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe