home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / gofer230.zip / Progs / Gofer / Docs / release.230 < prev   
Text File  |  1994-06-23  |  25KB  |  727 lines
  1.  
  2.  
  3.                                                                       
  4.  
  5.  
  6. -----------------------------------------------------------------------
  7.        __________   __________   __________   __________   ________
  8.       /  _______/  /  ____   /  /  _______/  /  _______/  /  ____  \
  9.      /  / _____   /  /   /  /  /  /______   /  /______   /  /___/  /
  10.     /  / /_   /  /  /   /  /  /  _______/  /  _______/  /  __   __/
  11.    /  /___/  /  /  /___/  /  /  /         /  /______   /  /  \  \ 
  12.   /_________/  /_________/  /__/         /_________/  /__/    \__\
  13.  
  14.   Functional programming environment, Version 2.30a
  15.  
  16.   Copyright Mark P Jones 1994.  This release is subject to the same
  17.   conditions of use and distribution as previous versions, documented
  18.   in src/goferite.h and in the main user manual.
  19.  
  20.   Release notes
  21. -----------------------------------------------------------------------
  22.  
  23. This document is intended to be used as a supplement to the original
  24. user manual ``An introduction to Gofer version 2.20'' and release
  25. notes for Gofer 2.21 and Gofer 2.28.  These notes replace the
  26. preliminary version distributed with Gofer 2.30.
  27.  
  28. ACKNOWLEDGMENTS:
  29. A lot of people have contributed to the development of Gofer 2.30a
  30. with their support, encouragement, suggestions, comments and bug
  31. reports.  There are a lot of people to thank:
  32.  
  33.        Jim Blandy        Jonathan Bowen           Rodney Brown
  34.       Nick Chapman          Derek Charleston      Stuart Clayman
  35.      Terry Dineen             Luc Duponcheel        Dirk Dussart
  36.  Sebastian Egner          Stephen Eldridge        Jeroen Fokker
  37.       Jeff Fried             Andy Gill           Michial Gunter
  38.      Kevin Hammond         Daniel Harris          Barney Hilken
  39.      Steve Hill               Ian Holyer         Richard Jones
  40.    Fumiaki Kamiya             Eak Khoon         Hiroyuki Matsuda
  41.       Sava Mintchev        Torben Mogensen          Dirk Nehring
  42.       Chin Wei Ngan          Kurt Olender          Palle Nielsen
  43.        Ian Poole          Bambang Prastowo          Jaan Priisalu
  44.   Giuliano Procida          Jerry Prothero       Laurenz Pruessner
  45.     Niklas R\"ojemo    Kristoffer Rose          Bernhard Rumpe
  46.      David Rushall        Carsten Schultz          Viren Shah
  47.       Dave Sherratt           Guy Steele Jr.      Donald Smith
  48.    Matthew Smith          Michael Stout          Bernard Sufrin
  49.      Peter Thiemann       Stephen Thomas            Bert Thompson
  50.    Ignacio Trejos-Zelaya   Goeran Uddeborg         Robin Watts
  51.      Gavin Wraith           David Wright            Isii Yuuitirou
  52.  
  53. This also includes the names of people who sent comments and bug
  54. reports after the release of version 2.28 and who may not have been
  55. credited in previous release notes.  The list probably isn't complete,
  56. and I apologize if I have inadvertently left your name out.
  57.  
  58. Enjoy!            jones-mark@cs.yale.edu   (Until mid-July 1994)
  59. Mark              mpj@cs.nott.ac.uk        (From  Sept/Oct 1994)
  60.  
  61.  
  62.  
  63.  
  64.                                       1
  65.  
  66.  
  67.  
  68.  
  69. Release Notes v2.30                 1. MINOR ENHANCEMENTS AND BUGFIXES
  70.  
  71.  
  72. 1. MINOR ENHANCEMENTS AND BUGFIXES
  73.  
  74. The following sections list the minor enhancements and bugfixes that
  75. have been made to Gofer since the release of version 2.28.  More
  76. significant changes are described in Section 2.
  77.  
  78.  
  79. 1.1  Enhancements
  80. -----------------
  81.   o  A new command, :gc, has been added, making it possible to force the
  82.      interpreter to carry out a garbage collection.
  83.  
  84.   o  The infamous `too many variables in type checker' message that has
  85.      caused problems with some programs, particularly machine generated
  86.      Gofer scripts like the parsers produced by Ratatosk, should now be
  87.      a thing of the past.  The message may still appear when running
  88.      such programs on smaller machines where the amount of free memory
  89.      available for such things is very limited.
  90.  
  91.   o  It is now possible to compile Gofer without support for old style
  92.      Dialogue based I/O and, independently, without support for (n+k)
  93.      and (c*n) patterns.  You may take this as a hint that these
  94.      features may not be supported in future versions, although no firm
  95.      decisions have been made just yet.
  96.  
  97.   o  As a convenience, the parser allows constructor expressions of
  98.      the form (t ->) as an abbreviation for ((->) t).
  99.  
  100.   o  Tuple patterns (with irrefutable components) are now treated as
  101.      irrefutable patterns, but without changing the previous lifted
  102.      semantics.  This is marginallly more efficient.  It also means
  103.      that it is no longer necessary to use ~ for generators of the form
  104.      (x,y) <- expr in monad comprehensions, too avoid restricting the
  105.      enclosing comprehension to monads with a zero.
  106.  
  107.   o  Type expressions appearing in primitive declarations may now
  108.      include synonyms, classes etc. defined in the same script.
  109.  
  110.   o  Other minor tweaks and improvements.
  111.  
  112.  
  113. 1.2  Bug fixes
  114. --------------
  115. Nobody really likes to dwell on bugs, especially when they have been
  116. eliminated.  But for those of you who want to know, here is a summary of
  117. the bugs discovered and fixed in Gofer 2.30:
  118.  
  119.   o  Test programs apr*.gs that were included in previous distributions
  120.      are no longer included in the src directory.  These programs were
  121.      intended only for quick tests, not for public distribution.  The
  122.      fact that some of the test programs (intentionally) caused errors,
  123.      was a source of unnecessary concern for some since the expected
  124.      behaviour was not documented.
  125.  
  126.   o  Some minor fixes to the parser/grammar to give better error
  127.      messages.
  128.  
  129.  
  130.                                       2
  131.  
  132.  
  133.  
  134.  
  135. Release Notes v2.30                                     1.2  Bug fixes
  136.  
  137.  
  138.   o  Fixed problems with the :edit command on some machines,
  139.      particularly noticable on the RISCOS version.
  140.  
  141.   o  Large integer constants that are outside the range for Int
  142.      values are no longer implicitly coerced to type Float.
  143.  
  144.   o  The implementations of assignment in the LAMBDAVAR and LAMBDANU
  145.      extensions, and the implementation of the system primitive for
  146.      LAMBDANU contained subtle bugs that have now been fixed.  Note
  147.      however that these extensions are now regarded as obsolete, and
  148.      will probably not be supported in future versions.  (LAMBDAVAR and
  149.      LAMBDANU where never formally included as an official feature of
  150.      Gofer anyway.)
  151.  
  152.   o  Infix data constructors can now be used in a datatype definition
  153.      such as:
  154.  
  155.          data  Tree a  =   Empty  |  Tree a `Fork` Tree a
  156.  
  157.   o  A very subtle bug in the unification algorithm has been fixed.
  158.  
  159.   o  Some bugs in mildly complicated examples involving pattern
  160.      matching of integer constants and singleton lists have been
  161.      fixed.
  162.  
  163.   o  Fixed some small problems with a couple of the demonstration
  164.      programs.
  165.  
  166.   o  Modified prelude definitions of the index function (in class Ix)
  167.      to include a bounds check.
  168.  
  169.   o  Other minor bug fixes and tweaks.
  170.  
  171. Someone is bound to find a new one within hours of the release of 2.30,
  172. if past experience is anything to go by.  If that someone is you,
  173. please let me know!
  174.  
  175.  
  176. 2. LANGUAGE DIFFERENCES
  177.  
  178. This section outlines a number of more substantial extensions that are
  179. supported in Gofer 2.30.  One of the most important motivations for
  180. some of these extensions, and part of an ongoing process, is to provide
  181. greater compatibility with standard Haskell.
  182.  
  183.  
  184. 2.1  Contexts in datatype definitions
  185. -------------------------------------
  186. For greater compatibility with Haskell, it is now possible to include
  187. contexts in datatype definitions.  These are treated in exactly the
  188. same way as in Haskell.  For example, the only effect of using a
  189. context in the datatype definition:
  190.  
  191.     data Eq a => Set a = NilSet | ConsSet a (Set a)
  192.  
  193.  is to treat the ConsSet constructor function as having type:
  194.  
  195.  
  196.                                       3
  197.  
  198.  
  199.  
  200.  
  201. Release Notes v2.30              2.1  Contexts in datatype definitions
  202.  
  203.  
  204.     ConsSet :: Eq a => a -> Set a -> Set a
  205.  
  206.  See Section 4.2.1 of the Haskell report, version 1.2, for further
  207.  details.
  208.  
  209.  
  210. 2.2  Contexts in member function types
  211. --------------------------------------
  212. For greater compatibility with Haskell, it is now possible to include
  213. contexts in the type of member function definitions in a class
  214. specification.  For example, you can now try out the class definition
  215. for pseudo monads given in the Yale Research Report YALEU/DCS/RR-1004
  216. entitled `Composing Monads' by myself and Luc Duponcheel:
  217.  
  218.     class Premonad m => Pseudomonad m where
  219.       pbind :: Monad m => p a -> (a -> m (p b)) -> m (p b)
  220.  
  221. Unlike Haskell, Gofer does not make the restriction that the additional
  222. constraints on the types of the member functions should not mention any
  223. of the types in the first line of the class declaration.  This appears
  224. to have been a consequence of the formal system underlying the original
  225. theoretical work on type classes by Blott.  For the qualified type
  226. system that is used as a basis for Gofer, such restrictions are
  227. unnecessary, although one might argue that they should be retained on
  228. stylistic grounds ...
  229.  
  230. See Section 4.3.1 of the Haskell report, version 1.2, for further
  231. details.
  232.  
  233.  
  234. 2.3  Haskell arrays
  235. -------------------
  236. For closer compatibility with Haskell, Gofer now supports a built-in
  237. implementation of Haskell style arrays.  To include support for these
  238. arrays, Gofer must be compiled with the HASKELL_ARRAYS flag set to 1.
  239. This is the default for all but the very smallest PC version of Gofer.
  240.  
  241. The implementation includes is based on new primitive datatype:
  242.  
  243.     data Array a b
  244.  
  245. The array primitives are not currently incorporated into any of the
  246. preludes supplied with Gofer.  However a separate script file,
  247. array.gs, is included in the same directory with the following
  248. interface:
  249.  
  250.     data Assoc a b =  a := b  deriving (Eq, Ord, Text)
  251.  
  252.     array      :: Ix a => (a,a) -> [Assoc a b] -> Array a b
  253.     listArray  :: Ix a => (a,a) -> [b] -> Array a b
  254.     (!)        :: Ix a => Array a b -> a -> b
  255.     bounds     :: Ix a => Array a b -> (a,a)
  256.     indices    :: Ix a => Array a b -> [a]
  257.     elems      :: Ix a => Array a b -> [b]
  258.     assocs     :: Ix a => Array a b -> [Assoc a b]
  259.     accumArray :: Ix a => (b -> c -> b) -> b -> (a,a)
  260.  
  261.  
  262.                                       4
  263.  
  264.  
  265.  
  266.  
  267. Release Notes v2.30                                2.3  Haskell arrays
  268.  
  269.  
  270.                             -> [Assoc a c] -> Array a b
  271.     (//)       :: Ix a => Array a b -> [Assoc a b] -> Array a b
  272.     accum      :: Ix a => (b -> c -> b) -> Array a b
  273.                             -> [Assoc a c] -> Array a b
  274.     amap       :: Ix a => (b -> c) -> Array a b -> Array a c
  275.     ixmap      :: (Ix a, Ix b) => (a,a) -> (a -> b)
  276.                                     -> Array b c -> Array a c
  277.  
  278.     instance (Ix a, Eq [Assoc a b]) => Eq (Array a b)
  279.     instance (Ix a, Ord [Assoc a b]) => Ord (Array a b)
  280.     instance (Ix a, Text (a,a), Text [Assoc a b])
  281.                => Text (Array a b)
  282.  
  283.     instance (Ix a, Ix b) => Ix (a,b)
  284.     rangeSize :: (Ix a) => (a,a) -> Int
  285.  
  286. For example, to use these primitives in a Gofer session, just include
  287. array.gs as the first file that you load, or as the one of the first
  288. file names in a project file.
  289.  
  290. Arrays, and the primitives above are supported in both the interpreter
  291. and the compiler.  Because of restrictions in memory management, the
  292. current implementation does not provide true O(1) lookup/indexing in
  293. the interpreter or the compiler using the markscan garbage collector.
  294. True O(1) access is supported when the twospace collector is used for
  295. compiled programs.
  296.  
  297. See Section 6.9 of the Haskell report, version 1.2, for further details
  298. about the use of arrays and the primitives described above.  Please
  299. bear in mind that the current implementation is still preliminary, and
  300. may contain bugs.  Please let me know if you encounter any problems
  301. with it!  A few short demo programs are included in demos/arrayEx.gs.
  302.  
  303.  
  304. 2.4  Monadic I/O
  305. ----------------
  306. A preliminary implementation of the monadic I/O is supported, built on
  307. top of the framework for lazy functional state threads that has been
  308. proposed by John Launchbury and Simon Peyton Jones (PLDI '94).  The
  309. details of monadic I/O can be expected to change in future releases as
  310. a new standard for monadic I/O is established.  For the time being, the
  311. primitives described here will be of most interest to those looking to
  312. experiment with simple monadic I/O and the Launchbury/Peyton Jones
  313. system.  To include support for monadic I/O, Gofer must be compiled
  314. with the IO_MONAD flag set to 1.  This is the default for all but the
  315. very smallest PC version of Gofer.
  316.  
  317. The current implementation provides several new primitive types:
  318.  
  319.     data ST s a        -- lazy state threads monad
  320.     data World         -- representation of `the world'
  321.     type IO = ST World -- the I/O monad proper
  322.     data MutVar s a    -- a mutable variable
  323.  
  324. An interface to monadic I/O can be obtained by loading the file
  325. iomonad.gs which may be found in the same directory as the prelude
  326.  
  327.  
  328.                                       5
  329.  
  330.  
  331.  
  332.  
  333. Release Notes v2.30                                   2.4  Monadic I/O
  334.  
  335.  
  336. files.  This provides the following operations:
  337.  
  338.     returnST     :: a -> ST s a
  339.     thenST       :: ST s a -> (a -> ST s b) -> ST s b
  340.     thenST_      :: ST s () -> ST s b -> ST s b
  341.     seqST        :: [ST s ()] -> ST s ()
  342.  
  343.     newVar       :: a -> ST s (MutVar s a)
  344.     readVar      :: MutVar s a -> ST s a
  345.     writeVar     :: MutVar s a -> a -> ST s ()
  346.     mutvarEq     :: MutVar s a -> MutVar s a -> Bool
  347.  
  348.     instance Eq (MutVar s a)
  349.  
  350.     getch        :: IO Char
  351.     getchar      :: IO Char
  352.     putchar      :: Char -> IO ()
  353.     putString    :: String -> IO ()
  354.     thenIO       :: ST s a -> (a -> ST s b) -> ST s b
  355.     interleaveST :: ST s a -> ST s a
  356.  
  357. The thenIO function is a stricter version of thenST that is suitable
  358. only for computations in the IO monad.  See the Launchbury and
  359. Peyton Jones paper referenced below for further details.
  360.  
  361. There is also a built-in special form, runST expr, which is typed
  362. using the rule:
  363.  
  364.     expr :: forall s. ST s a        (s not appearing in a)
  365.     ------------------------
  366.        runST expr :: a
  367.  
  368. This special form is used for encapsulating state based computations
  369. within a purely functional program.  See references below for more
  370. details.
  371.  
  372. If the version of Gofer being used also includes support for arrays, as
  373. described above, you can also use the definitions in ioarray.gs to
  374. support monadic array operations:
  375.  
  376.     newArr    :: Ix a => (a,a) -> b -> ST s (MutArr s a b)
  377.     readArr   :: Ix a => MutArr s a b -> a -> ST s b
  378.     writeArr  :: Ix a => MutArr s a b -> a -> b -> ST s ()
  379.     freezeArr :: Ix a => MutArr s a b -> ST s (Array a b)
  380.  
  381. Some sample programs using the functions described here may be found in
  382. the demos/IO directory.  For further details about monadic I/O, please
  383. consult the papers:
  384.  
  385.     Imperative Functional Programming, S.L. Peyton Jones and
  386.     P. Wadler, POPL '93.
  387.  
  388.      Lazy Functional State Threads, J. Launchbury and S.L. Peyton
  389.     Jones, PLDI '94.
  390.  
  391.  
  392.  
  393.  
  394.                                       6
  395.  
  396.  
  397.  
  398.  
  399. Release Notes v2.30                                   2.4  Monadic I/O
  400.  
  401.  
  402. See also:
  403.  
  404.     Lazy depth-first search and linear graph algorithms in
  405.     Haskell, D. King and J. Launchbury, 1993.
  406.  
  407. For some very nice applications of lazy functional state threads.
  408. All of these papers are currently available by anonymous ftp from
  409. the University of Glasgow, ftp.dcs.glasgow.ac.uk.
  410.  
  411. Monadic I/O as described above is supported in both the Gofer
  412. interpreter and compiler.  No special optimizations are used in
  413. the current implementation which should still be treated as
  414. preliminary, and may contain bugs.  Please let me know if you
  415. encounter any problems with it!
  416.  
  417.  
  418. 2.5  Trace primitive
  419. --------------------
  420. A simple trace function, inspired by the original implementation in
  421. LML, can now be accessed by including the primitive definition:
  422.  
  423.     primitive trace "primTrace" :: String -> a -> a
  424.  
  425. in a Gofer script.  When called, trace prints the string in its first
  426. argument, then returns the second argument as its result.  The trace
  427. function is not referentially transparent, and should only be used for
  428. debugging, or monitoring execution.  That is why it is not included in
  429. any of the preludes.  Be warned also that, unless you understand
  430. something about the way that Gofer programs are actually executed,
  431. results obtained using trace may be rather confusing.
  432.  
  433. Because of it's intended use, the trace primitive is not supported
  434. by the Gofer compiler, gofc.  It is however possible to `hack' in
  435. a version of trace for gofc using the external function call
  436. mechanism described below with the following C program:
  437.  
  438.     #include <stdio.h>
  439.     #include "/usr/local/lib/Gofer/gofc.h"
  440.    
  441.     #define emptyList mkCfun(0)
  442.    
  443.     extern Cell primTrace(str,val)
  444.     Cell str, val; {
  445.         eval(str);
  446.         while (whnf!=emptyList) {
  447.             eval(pop());
  448.             putchar(charOf(whnf));
  449.             eval(pop());
  450.         }
  451.         fflush(stdout);
  452.         return val;
  453.     }
  454.  
  455. See Section 2.7 below for further details.
  456.  
  457.  
  458.  
  459.  
  460.                                       7
  461.  
  462.  
  463.  
  464.  
  465. Release Notes v2.30                          2.6  Constructor synonyms
  466.  
  467.  
  468. 2.6  Constructor synonyms
  469. -------------------------
  470. Type synonym definitions have been generalized to allow arbitrary
  471. constructor synonyms such as:
  472.  
  473.     type List     = []
  474.     type Function = (->)
  475.     type Infer    = StateM Int Error
  476.  
  477. Previously, it was assumed that both the constructors on the left and
  478. right hand sides were types, i.e. constructors of kind *.  This
  479. restriction has now been lifted, although both sides are still required
  480. to have the same kind.  However, the restriction that all arguments to
  481. a synonym must be given is still imposed.
  482.  
  483.  
  484. 2.7  External function calls
  485. ----------------------------
  486. The Gofc compiler, translating Gofer programs to C provides a simple
  487. external function calling mechanism.
  488.  
  489. External functions are specified using a primitive declaration of the
  490. form:
  491.  
  492.     primitive foo "bar" :: a1 -> a2 -> a3 -> ... -> an -> r
  493.  
  494. where foo is the Gofer name for the function, bar is the name of the
  495. corresponding C function (which must not be a string referring to one
  496. of the built in primitives ... if you avoid the `prim' prefix, this
  497. should not be a problem), the ai are the argument types, and r is the
  498. result type.  Arguments of type Int, Bool, Char and Float are evaluated
  499. before the bar function is invoked, and their results passed to bar in
  500. parameters of suitable types.  All other values are passed as
  501. unevaluated Cell values.  (Special treatment is also provided for
  502. arrays, mutable variables, and mutable arrays for versions of Gofer
  503. that support these facilities.)
  504.  
  505. Results of type Int, Bool, Char and Float returned from an external
  506. function are automatically converted to suitable representations for
  507. Gofer.  Values of any other type should be passed back as Cell values
  508. by the C code for the external function.
  509.  
  510. A result type of the form IO r should be used for external functions
  511. that may have some side effects.  A result type of the form IO () can
  512. be used to call a function that does not return any useful value and is
  513. executed only for its effect.
  514.  
  515. Here is a simple example using the external function mechanism.  It
  516. involves the following short Gofer and C programs:
  517.  
  518. (gix1.gs):    primitive howdy "sayHello" :: Int -> IO ()
  519.  
  520.               main = howdy (length (filter even [1..5]))
  521.  
  522.  
  523.  
  524.  
  525.  
  526.                                       8
  527.  
  528.  
  529.  
  530.  
  531. Release Notes v2.30                       2.7  External function calls
  532.  
  533.  
  534. (cix1.c):     #include <stdio.h>
  535.               #include "gofc.h"
  536.  
  537.               Void sayHello(i)
  538.               Int i; {
  539.                   while (i-- > 0)
  540.                       printf("hello, world\n");
  541.               }
  542.  
  543. First, we compile gix1.gs to get a C program gix1.c:
  544.  
  545.     machine% gofc gix1.gs
  546.     Gofer->C Version 1.02 (2.30) ...
  547.  
  548.     Reading script file "/usr/local/lib/Gofer/standard.prelude":
  549.     Reading script file "gix1.gs":
  550.                    
  551.     Writing C output file "gix1.c":
  552.     [Leaving Gofer->C]
  553.  
  554. Now we compile the C programs, and link them into a single executable
  555. file, ix1:
  556.  
  557.     machine% cc -O -o ix1 gix1.c cix1.c runtime.o
  558.  
  559. Finally, we get to run the program:
  560.  
  561.     machine% ix1
  562.     hello, world
  563.     hello, world
  564.  
  565. See Section 2.5 above for another example using the external function
  566. mechanism, and also illustrating how values of type String can be
  567. evaluated and used in a C function.  You will probably need to refer
  568. to the report described in Section 3 below if you plan to do anything
  569. very ambitious with external function calls.
  570.  
  571. Note that the external function call mechanism described here cannot be
  572. used in the Gofer interpreter.  The external function call mechanism is
  573. a prototype only.  It should also be emphasized that we do not, in
  574. general, regard the Gofc compiler as suitable for serious applications
  575. development.  If you want to do something along those lines, try one of
  576. the full Haskell systems available (e.g. the Lisp or C interfaces for
  577. Yale Haskell, or the C interface for Glasgow Haskell).
  578.  
  579.  
  580. 2.8  The do notation
  581. --------------------
  582. Gofer 2.30 supports a new, experimental syntax for monad comprehensions
  583. which we will refer to as `do {...} notation'.  To maintain
  584. compatibility with previous releases of Gofer, the do notation is
  585. only supported if the system is compiled with the DO_COMPS flag in
  586. prelude.h set to to 1, and the DO_COMPS section of parser.y included.
  587. See the comments in these files and in src/Readme for further
  588. details.
  589.  
  590.  
  591.  
  592.                                       9
  593.  
  594.  
  595.  
  596.  
  597. Release Notes v2.30                               2.8  The do notation
  598.  
  599.  
  600. The do notation is useful for monadic programming.  It requires the
  601. cc.prelude, and provides the following syntax:
  602.  
  603.     <expr>   ::=  do "{" <dquals> <expr> "}"  -- uses layout rule
  604.  
  605.     <dquals> ::=  {<dqual> ;}
  606.  
  607.     <dqual>  ::=  <expr> <- <pat>             -- generator
  608.               |   <expr>                      -- command
  609.               |   let "{" decls "}"           -- local definitions
  610.               |   if <expr>                   -- guard
  611.  
  612. With this notation, a guard is written as if <expr>, while a single
  613. expression of the form <expr> is treated as a command, i.e. a generator
  614. of the form _ <- <expr>.  For example, a general version of the filter
  615. function can be defined as:
  616.  
  617.     myFilter     :: Monad0 m => (a -> Bool) -> m a -> m a
  618.     myFilter p xs = do x <- xs
  619.                        if p x
  620.                        result x
  621.  
  622. If you prefer, this can be written as follows, using explicit layout:
  623.  
  624.     myFilter p xs = do { x <- xs;
  625.                          if p x;
  626.                          result x
  627.                        }
  628.  
  629. In standard comprehension notation, this would be written:
  630.  
  631.     myFilter p xs = [ x | x <- xs, p x ]
  632.  
  633. Perhaps the most significant difference between these two examples is
  634. the fact that the call to result must be written explicitly in the
  635. first case.  In fact, if the comprehension is interpreted in a monad,
  636. m, then any expression of type (m a) can be used as the final
  637. expression in a do comprehension.  This is useful for describing `tail
  638. recursive' procedures.  For example, compare:
  639.  
  640.     echo' = do c <- getchar
  641.                if c==EOF
  642.                  then result ()
  643.                  else do putchar c
  644.                          echo'
  645.  
  646. with:
  647.  
  648.     echo' = [ () | c  <- getchar,
  649.                    () <- if c==EOF then result ()
  650.                                    else [ () | _ <- putchar c,
  651.                                                () <- echo' ] ]
  652.  
  653. It is, of course, a matter of personal opinion which of these you
  654. prefer.  The intention of do notation is to provide a more attractive
  655. syntax for monadic programming, to be compared with programs using
  656.  
  657.  
  658.                                       10
  659.  
  660.  
  661.  
  662.  
  663. Release Notes v2.30                               2.8  The do notation
  664.  
  665.  
  666. `bind` in which the example above would be written:
  667.  
  668.     echo' = getchar `bind` \c ->
  669.             if c==EOF then result ()
  670.                       else putchar c  `bind` \_ ->
  671.                            echo'
  672.  
  673. See which notation you prefer for practical programming, and let me
  674. know!
  675.  
  676. 3. THE IMPLEMENTATION OF GOFER
  677.  
  678. For those interested in the actual implementation of Gofer, there is
  679. a (relatively new) technical report available that describes the
  680. implementation of Gofer 2.30:
  681.  
  682.     The implementation of the Gofer functional programming system
  683.     Mark P. Jones
  684.     Research Report YALEU/DCS/RR-1030
  685.     Yale University, Department of Computer Science,
  686.     May 1994.
  687.  
  688. Copies of this report are currently available by anonymous ftp from
  689. nebula.cs.yale.edu in the directory pub/yale-fp/reports, together
  690. with a number of other recent reports by members of the Yale Haskell
  691. project.
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.                                       11
  725.  
  726.  
  727.