J.P. Morrison <[EMAIL PROTECTED]> writes on the dataflow list: > > I have been in the IT business for about 40 years, and have been > maintaining PL/I programs intensively for the last year or so. In 1994 > I wrote a book called "Flow Based Programming" which was quite well > received. It describes a technique for developing big applications as > networks of asynchronous processes communicating via streams of > formatted data chunks. In fact this technique has been in continuous > use for the last 30 years at various places I have worked (surprise!), > and I feel it has proven its usefulness. It also leads very naturally > to the concept of mini-languages, where a given process can be written > in a language appropriate to the application area. However, designing > such a language is non-obvious! As a result of my work, I feel pretty > sure that both variables and constants are undesirable - variables > because they are very sensitive to the timing of events, and constants > because they usually aren't! > > Now, even if we replace variables by entity attributes, in most > languages I am familiar with the coding schemes are usually mathematical > - i.e. most variables are either binary, packed decimal, BCD, etc. What > I am looking for is a language where most values have dimension, which > constrains the operations that can be performed on them. E.g. > > - currency can be added, but not multiplied > - currency can be multiplied or divided by non-dimensioned quantities, > but not added to them > - distances can be added; if multiplied, you get area; multiply again, > and you get volume! > - dates can be subtracted, but not added; number of days can be added or > substracted to/from a date > - etc. > > Further, dimensioned quantities are measured in units, so it would be > nice to be able to add miles to kilometers - I don't care what unit is > used for the result, so long as it is identified. Currency conversions > are more problematic, as a) the rate changes frequently, and b) there is > often a charge, so some amount of cash has to be sent somewhere else! > > If your answer is OOP, it must be symmetrical (the permitted operations > must depend on the types of all variables - in which case, how do you > manage all the combinations?) - the popular OOP languages are > asymmetrical, which is not acceptable. Multi-parameter type classes in Haskell. Haskell: http://www.haskell.org/ GHC User Manual --- Section about Multi-parameter type classes: http://www.haskell.org/ghc/docs/latest/users_guide/users_guide-5.html#ss5.5 Paper: http://www.dcs.gla.ac.uk/~simonpj/multi.ps.gz > Also, the language must be > natural to non-programmers - business types ought to be able to express > business rules without having to learn some abstruse notation... > Well, Haskell looks more like a kind of mathematical notation than the kind of programming language (C, COBOL, Java) most non-programmers are used to consider as non-natural, so it might fit your ideas ;-) More seriously: There has been quite some research about using Haskell as background for domain-specific languages, so the the approach to follow would require some real Haskell programming to set up the necessary classes and combinators, and then business-type sticking-together of these building blocks. See the home page of Paul Hudak for DSL work: http://www.cs.yale.edu/~hudak.html A recent thread on the Haskell mailing list discussed units: Search for ``Units'' in: http://www.dcs.gla.ac.uk/mail-www/haskell/ This message also goes to the Haskell list. Best regards, Wolfram
