Re: FRP (was: Designing Lisp from scratch)

> So what does FRP bring to the table that is new?

There are lots of differences in the intent, and therefore in the
language design, from the Lucid, Signal, etc. series of work.  These
are, as you yourself observe, trying to embed dataflow characteristics
into general-purpose languages with closures, streams, and dynamic
graph reconfiguration.  The specific contribution of the paper by
Cooper was to show a very light-weight embedding strategy to exploit
rather than reproduce the existing call-by-value evaluation strategy
to build the graph.  The paper by Ignatoff et al showed the principles
of connecting the resulting language to GUI toolkits.

If you've written this up any time before 2006, we'd be delighted to
be pointed to papers so we can be sure to cite them and give proper
credit the next time we write about our work.

> I thought FRP was only to work these out for a language like Haskell
> that already had problems in this area due to extreme laziness.

1. No, given that many of the Haskell FRP systems don't provide the
bounds you mention.

2. No, given that many of the Haskell FRP systems *exploit*, rather
than work around, the laziness of Haskell.

3. No, given that many of the Haskell FRP systems are still victim to
the "extreme laziness" of Haskell.

Shriram