Difference between revisions of "Lucid"

From HaskellWiki
Jump to navigation Jump to search
(A table explaining the concept of ``running average'' by an example)
m (Reverted edits by LJost (Talk); changed back to last version by Crazy fizruk)
 
(13 intermediate revisions by 4 users not shown)
Line 5: Line 5:
 
Weblogs Forum: [http://www.artima.com/forums/flat.jsp?forum=106&thread=102839 Fluid Programming in Lucid] -- good examples, and very good links.
 
Weblogs Forum: [http://www.artima.com/forums/flat.jsp?forum=106&thread=102839 Fluid Programming in Lucid] -- good examples, and very good links.
   
[http://i.csc.uvic.ca/home/hei/hei.ise%3Ctop:lucid%3E Lucid page] written by [http://i.csc.uvic.ca/home/hei/hei.ise%3C%3E Bill Wadge], including an [http://i.csc.uvic.ca/home/LucidPrimer/LPS.ise excerpt from Lucid Primer book].
+
[http://i.csc.uvic.ca/home/hei/ihei.cgi?context=%3Ctop:%3C%22lucid%22%3E%3E Lucid page] written by [http://i.csc.uvic.ca/home/hei/ihei.cgi?context=%3C%3E Bill Wadge], including an [http://i.csc.uvic.ca/home/LucidPrimer/LPS.ise excerpt from the book "Lucid, the Dataflow Programming Language"].
   
 
[http://en.wikipedia.org/wiki/Lucid Wikipedia article] (yet a stub, but useful links).
 
[http://en.wikipedia.org/wiki/Lucid Wikipedia article] (yet a stub, but useful links).
Line 20: Line 20:
 
* [[Media:Lucid.lhs|Lucid.lhs]]
 
* [[Media:Lucid.lhs|Lucid.lhs]]
 
* [[Media:Test.lhs|Test.lhs]]
 
* [[Media:Test.lhs|Test.lhs]]
written to mimick and test the following Lucid example (I have made it a little Haskell-like):
+
written to mimick and test the following Lucid example (I have made it a little Haskell-like -- it is not original Lucid syntax, but it is not an embedding into Haskell language, either -- in fact, it is a didactic intermediate syntax):
 
<code>
 
<code>
 
average n = sum n / card
 
average n = sum n / card
Line 26: Line 26:
 
card = 1 '''`fby`''' succ card
 
card = 1 '''`fby`''' succ card
 
</code>
 
</code>
This program counts the ''moving average'' of the input stream:
+
This program computes the ''moving average'' of the input stream:
 
<center>
 
<center>
 
{| border=1 cellspacing=0 cellpadding=5
 
{| border=1 cellspacing=0 cellpadding=5
| '''Snapshot'''
+
| style="background:#efefef;" | '''Snapshot'''
| '''Input'''
+
| style="background:#efefef;" | '''Input'''
  +
| style="background:#efefef;" | '''Output'''
| '''Ouput'''
 
 
|-
 
|-
 
| 0
 
| 0
Line 38: Line 38:
 
|-
 
|-
 
| 1
 
| 1
| <code>1.0</code>
+
| <code>10</code>
| <code>1.0</code>
+
| <code>10</code>
 
|-
 
|-
 
| 2
 
| 2
| <code>1.0</code>, <code>2.0</code>
+
| <code>10</code>, <code>20</code>
| <code>1.0</code>, <code>1.5</code>
+
| <code>10</code>, <code>15</code>
 
|-
 
|-
 
| 3
 
| 3
| <code>1.0</code>, <code>2.0</code>, <code>3.0</code>, <code>4.0</code>
+
| <code>10</code>, <code>20</code>, <code>30</code>
| <code>1.0</code>, <code>1.5</code>, <code>2.0</code>, <code>2.5</code>
+
| <code>10</code>, <code>15</code>, <code>20</code>
 
|-
 
|-
 
| 4
 
| 4
| <code>1.0</code>, <code>2.0</code>, <code>3.0</code>, <code>4.0</code>, <code>5.0</code>
+
| <code>10</code>, <code>20</code>, <code>30</code>, <code>40</code>
| <code>1.0</code>, <code>1.5</code>, <code>2.0</code>, <code>2.5</code>, <code>5.0</code>
+
| <code>10</code>, <code>15</code>, <code>20</code>, <code>25</code>
  +
|-
  +
| 5
  +
| <code>10</code>, <code>20</code>, <code>30</code>, <code>40</code>, <code>50</code>
  +
| <code>10</code>, <code>15</code>, <code>20</code>, <code>25</code>, <code>30</code>
 
|}
 
|}
 
</center>
 
</center>
 
In fact, <code>first</code>, <code>next</code>, <code>fby</code> are not necessarily primitives in Lucid, but this fast-food implementation treats them as primitives.
 
In fact, <code>first</code>, <code>next</code>, <code>fby</code> are not necessarily primitives in Lucid, but this fast-food implementation treats them as primitives.
  +
  +
The above example may suggest that Lucid be necessarily synchronous -- it reacts on inputs in a one-output-for-each-input way. This is not the case: Lucid has general, unrestricted stream processing abilities (thus able to implement also asynchronous processes).
   
 
=== Arrow ===
 
=== Arrow ===
Line 64: Line 70:
 
=== Comonad ===
 
=== Comonad ===
   
A professional approach based on comonads:
+
A professional approach based on [[comonad]]s:
 
see [http://www.cs.ioc.ee/~tarmo/papers/aplas05.pdf The Essence of Dataflow Programming] paper written by [http://www.cs.ioc.ee/~tarmo/ Tarmo Uustalu].
 
see [http://www.cs.ioc.ee/~tarmo/papers/aplas05.pdf The Essence of Dataflow Programming] paper written by [http://www.cs.ioc.ee/~tarmo/ Tarmo Uustalu].
 
Comments on this paper can be found on [http://lambda-the-ultimate.org/node/988 Lambda the Ultimate] (but the link to the mentioned given there seems to be broken, I have given an updated one here). The links to pages introducing the concept of comonad are [http://www.cs.helsinki.fi/u/ekarttun/comonad/ Comonads and Haskell] written by [http://www.haskell.org/tmrwiki/EinarKarttunen Einar Karttunen].
 
Comments on this paper can be found on [http://lambda-the-ultimate.org/node/988 Lambda the Ultimate] (but the link to the mentioned given there seems to be broken, I have given an updated one here). The links to pages introducing the concept of comonad are [http://www.cs.helsinki.fi/u/ekarttun/comonad/ Comonads and Haskell] written by [http://www.haskell.org/tmrwiki/EinarKarttunen Einar Karttunen].

Latest revision as of 15:07, 5 November 2011

Introduction

Weblogs Forum: Fluid Programming in Lucid -- good examples, and very good links.

Lucid page written by Bill Wadge, including an excerpt from the book "Lucid, the Dataflow Programming Language".

Wikipedia article (yet a stub, but useful links).

Details

The most detailed online material on the details of this language I could find: Raganswamy Jagannathan, Chris Dodd. GLU programmer's guide (downloadable as the 4th paper of GIPSY Publications). The first pages seem to discuss other problems, but it is worth of reading further, because a detailed description of Lucid's syntax and semantics is hiding inside this paper (section 3.1.2 on pages 22--38). This paper is part of the Gipsy Project Home Page (GIPSY: A General Intensional Programming System).

Implementation

Fast-food

A fast-food implementation:

written to mimick and test the following Lucid example (I have made it a little Haskell-like -- it is not original Lucid syntax, but it is not an embedding into Haskell language, either -- in fact, it is a didactic intermediate syntax):

average n = sum n / card
sum n = first n `fby` (sum n + next n)
card = 1 `fby` succ card

This program computes the moving average of the input stream:

Snapshot Input Output
0  
1 10 10
2 10, 20 10, 15
3 10, 20, 30 10, 15, 20
4 10, 20, 30, 40 10, 15, 20, 25
5 10, 20, 30, 40, 50 10, 15, 20, 25, 30

In fact, first, next, fby are not necessarily primitives in Lucid, but this fast-food implementation treats them as primitives.

The above example may suggest that Lucid be necessarily synchronous -- it reacts on inputs in a one-output-for-each-input way. This is not the case: Lucid has general, unrestricted stream processing abilities (thus able to implement also asynchronous processes).

Arrow

A better implementation could be written using the arrow library available at the Downloads page of Arrows: A General Interface to Computation written by Antony Courtney, Henrik Nilsson and Ross Paterson.

Comonad

A professional approach based on comonads: see The Essence of Dataflow Programming paper written by Tarmo Uustalu. Comments on this paper can be found on Lambda the Ultimate (but the link to the mentioned given there seems to be broken, I have given an updated one here). The links to pages introducing the concept of comonad are Comonads and Haskell written by Einar Karttunen.