jwb@cive.ri.cmu.edu (John Baugh) (12/14/88)
Do dataflow (and/or functional) languages provide exception handling mechanisms, or is this considered a no-no? The software engineering people advocate their use, but I haven't seen this kind of support in dataflow languages. Are their conceptual problems with doing this? Couldn't they be implemented using merge/switch nodes in a dynamic dataflow graph? John Baugh Carnegie Mellon University
cme@seismo.css.gov (Carl Ellison) (12/19/88)
In article <3883@hubcap.UUCP>, jwb@cive.ri.cmu.edu (John Baugh) writes: > Do dataflow (and/or functional) languages provide exception > handling mechanisms, or is this considered a no-no? The > software engineering people advocate their use, but I haven't > seen this kind of support in dataflow languages. The only problem with this idea is that the word "exception" isn't defined. That's a concept invented by programmers of von Neumann machines to talk about things which happened asynchronously (therefore not in the flow of a single- thread program). In other words, an "exception" is the arrival of a dataflow datum at a von Neumann processor. When that datum arrives at a dataflow processor, it rates no special label. --Carl Ellison ...!harvard!anvil!es!cme (normal mail address) ...!ulowell!cloud9!cme (usenet news reading) (standard disclaimer)
kh@uunet.UU.NET (Kevin Hammond CMP) (12/19/88)
There's a paper in TOPLAS describing the exception-handling mechanism in VAL. SISAL seems to have a similar mechanism, but these seem rather ad-hoc. HOPE+ and PSML (my dialect of Standard ML) both have exception-handling mechanisms based on error values. I have a paper which I can distribute (or you can get it from UEA) which describes various exception-handling techniques (dataflow, functional, term rewriting), and introduces a deterministic parallel approach based on error values. You have to be careful to define exactly what you mean by exception handling, though, event handling is not the same as error handling. There's a lot of confusion between these which leads to complex and over-general mechanisms, someone (A. Black) even argues that you should exclude exception handling from languages entirely just because the mechanisms can be misapplied! A few basic references (I have more if anyone's interested): Wetherell, C.S., "Error Data Values in the dataflow language VAL", ACM TOPLAS, Vol. 4, No. 2, pp. 226-238, 1982. Hammond, K., "Error Handling in the Parallel Implementation of a Lazy Functional Language", UEA Internal Report, School of Information Systems, University of East Anglia, Norwich, UK, 1988. Submitted to International Journal of Parallel Processing. Black, A., "Exception Handling: the Case Against", D.Phil thesis, Oxford University, 1980. Bretz, M, and Ebert, J., "An Exception-Handling Construct for Functional Languages", in Proc. ESOP 88, Nancy, France, L.N.C.S. 300, Springer-Verlag, 1988. Hope this helps, Kevin. -- Wot? No Signature? UUCP: ...!mcvax!ukc!uea-sys!kh JANET: kh@sys.uea.ac.uk
pardo@june.cs.washington.edu (David Keppel) (12/20/88)
>In article <3883@hubcap.UUCP>, jwb@cive.ri.cmu.edu (John Baugh) writes: >> Do dataflow (and/or functional) languages provide exception >> handling mechanisms, or is this considered a no-no? encore!cloud9!cme@seismo.css.gov (Carl Ellison) writes: >[``Exception'' exists to talk about things that happen async.] >[therefore not in normal flow of single-thread program.] >[``exception'' is the arrival of dataflow datum at a VNeumann proc.] I've been taught a different usage of ``exception''. An exception is an unusual event. Often times exceptions are synchronous and they need not involve the hardware in any particular way. Consider adding two non-negative numbers: c := a + b; if c < 0 then (* overflow *) return (OVERFLOW); endif; d := sin (theta); if d = NaN then (* overflow *) return (OVERFOW); endif; : : Doing this all the time as inline code is (a) bothersome and (b) tiresome and thus (c) error prone. It *may* also be less efficient. (It may be possible to build an exception mechanism that is expensive only when it is used, and does not, in fact, require inlining all the explicit tests). The language supports two return mechanism -- normal and exception. The interface to a routine includes the arguments, the return values, and the first-level exceptions: function sin (double angle) returns double except OVERFLOW; And you code without all the explicit error checks. c := a + b; d := sin (theta); : : return (result); except: OVERFLOW: raise (OVERFLOW); In this case, I think that ``exception'' is perfectly well-defined for dataflow languages. ;-D on ( Just noise on the sine wave of life ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo