Re: FRP (was: Designing Lisp from scratch)

On 3/20/07, Shriram Krishnamurthi <[email protected]> wrote:
> > 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.


A paper which appeared in the proceedings of the International
Computer Music Conference, Hong Kong, 1996 was just a one page blurb
due to page restrictions and not very informative.

A paper which explains using expressions to functionally create data
flow graphs is this one:
Rethinking the Computer Music Language: SuperCollider
James McCartney
Computer Music Journal
Winter 2002, Vol. 26, No. 4, Pages 61-68
http://www.mitpressjournals.org/doi/abs/10.1162/014892602320991383?journalCode=comj

If count the web as publication, the docs for the language were online in 2001.
http://web.archive.org/web/20010302140939/www.audiosynth.com/schtmldocs/index.html

.. though I'm sorry I'll need to look at your paper again to see
exactly what you mean by embedding, exploiting and reproducing. SC is
call by value. SC expressions involving data flow objects result in
graphs of data flow objects.

-- 
--- james mccartney