[Haskell-cafe] An idea to document inter department dependencies in Haskell

[C K Kashyap]

Thanks a lot Alberto,

Actual code generation is not really my immediate goal ... What my
immediate requirement is to validate the consistency of design changes. So
essentially, this EDSL would not generate any target code - it's successful
compilation would be the desired result and perhaps "more friendly"
compilation error messages that can guide the non Haskell user to make
corrections.

Regards,
Kashyap


On Wed, Mar 14, 2012 at 5:31 AM, Alberto G. Corona <agocorona at gmail.com>wrote:

> 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 <ckkashyap at gmail.com>
>
>> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20120314/d08c7c93/attachment.htm>