- Haskell - Haskell.org

existential type synonyms
by John Meacham 13 Dec '05

13 Dec '05

I was wondering if this would make sense allow extensential type synonyms, so if you had something like the following, > data Type a = .... you could declare a synonym such as > type AnyType = exists a . Type a so you can create functions such as > areSame :: AnyType -> AnyType -> Bool which would expand to > areSame :: forall a b . Type a -> Type b -> Bool this is opposed to the currently allowed in ghc > type AllTypes = forall a . Type a > oddFunc :: AllTypes -> AllTypes -> Bool which expands to the rank 2 type > oddFunc :: (forall a . Type a) -> (forall b . Type b) -> Bool which means something quite different. if we use 'exists' for existential types, this might be another useful use of said name. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

Re: ECT and SearchPath
by Sven Moritz Hallberg 12 Dec '05

12 Dec '05

[cc'ing to the Haskell mailing list] S. Alexander Jacobson schrieb: > A while back, I had been arguing on the Haskell mailing list that module > meanings were not and should not be qualified by package names. It cannot be argued that introducing a package system does nothing in terms of disambiguating modules except adding a new top level to the existing hierarchy. Then it must be argued whether this is a good idea or not. My current standpoint is that packages make sense as distributional units (at least in some cases - haven't thought this through), but give no real solution to the problem of managing the module namespace. In the latter respect, I think the only solution is to explicitly partition the namespace by author or organization - the same effect as the Java style of embedding DNS domain names in the module namespace. I find the Java way very ugly, though. But as you surely know, current Haskell practice already is to place a module into the hierarchy in some seemingly appropriate place and suffix it with, say, the author's name or some other characteristic identifier to avoid clashes. I tend to think this is a good scheme. For it to _really_ work, however, we should form a registry of "officially assigned" module names (i.e. ones without a disambiguation suffix) and also one for the author and/or organization names to be used as suffixes. I for example am known by the nickname Pesco, or (more recently) by the mnemonic SM at domain KHJK.ORG. So I could register - Pesco as a (personal) disambiguation suffix or - KHJK as an (organizational) suffix. The latter case would put the management of the KHJK subnamespace under organizational control and I could, in this example, use KHJK.SM for my personal use, or just KHJK (if the organization agrees). > I just > read your ECT article which seems to start with the same assumption and > takes the theory to its logical conclusion. I take that as a compliment. ;) Thank you. > On my end, I decided to implement a tool that shows why packages are not > a good model for versioning and implemented SearchPath > (http://searchpath.org) SearchPath takes a map of module locations on > the Internet and does automatic import chasing for your particular > application. Cool, nice work! I've actually thought about building a system just like this. > In your ECT article you say: > > In the long run, I envision a world where I can stumble across some > module on the Net, immediately import it in my code, and, on the > stroke of a single command, have my system locate, fetch, compile, and > install that module, dropping me at an interactive prompt with the new > import available! All of the above without having to worry about > whether or how to bundle that module with my code, prompted by > questions of its availability and compatibility on my users' hosts. > > I think SearchPath helps get us there. I am soliciting any thoughts you > may have to improve SearchPath and better integrate it with people > implementing ECT in their modules. The main issue that springs to my mind is authenticity control. How do I know the module I'm downloading is the one I want? Note that this question is always there, even in the local case, but it is usually not seen as a problem until module sources are distributed over the Net. The issue of course boils down to establishing trust. Oh, I just remember Raph Levien of advogato.org complaining about his trust metrics not being used! Maybe that would be an idea... - Module authors PGP-sign their code. No problem. - Module importers check their imports for trusted signatures. Hm. - To trust a signature means to a) trust that it belongs to the author it claims to belong to, b) trust that author to produce "friendly" code. Here's where trust metrics could be employed. The PGP web of trust already does it for (a) and (b) would be to do by us. Does the following make sense? Or is there an elegant way to make this not rely on the central registry for authority? - Module importers also check their imports against the registry. - The registry records for each "block" of the module namespace, the author/organization - identified by key - responsible for that block. I don't have time just now to think through these things. But many thanks for your mail, and keep going. I'm sure we can devise some brilliant way to solve all these problems -- in theory ;) . Regards, Sven Moritz

1 0

RE: [Haskell] Re: comment vs varsym
by Simon Marlow 12 Dec '05

12 Dec '05

On 09 December 2005 05:47, Taral wrote: > On 12/8/05, Taral <taralx(a)gmail.com> wrote: >> or b) comment, because the maximal munch rule says so (it matches >> the newline): >> >> comment -> dashes [any<symbol> {any}] newline >> varsym -> (symbol {symbol | :})<reservedop | dashes> > > Aha. Maximal munch only applies to non-whitespace, so Hugs is right. > Yay. This looks like a mistake in the syntax. I think GHC is following the letter of the spec, but I also think that the intended behaviour was to admit --: as a varsym, i.e. Hugs' behaviour. The syntax allows --: to be a comment, because the class of characters "symbol" does not include :. In contrast, the syntax does *not* admit varsyms beginning with '--' as comments. I'm not aware of maximal munch being applied only to non-whitespace; does it say so anywhere in the report? Cheers, Simon

2 1

comment vs varsym
by Taral 10 Dec '05

10 Dec '05

The first token in "--:\n" is... a) varsym, because varsym always wins according to section 2.3: An ordinary comment begins with a sequence of two or more consecutive dashes (e.g. --) and extends to the following newline. The sequence of dashes must not form part of a legal lexeme. For example, "-->" or "|--" do not begin a comment, because both of these are legal lexemes; however "--foo" does start a comment. or b) comment, because the maximal munch rule says so (it matches the newline): comment -> dashes [any<symbol> {any}] newline varsym -> (symbol {symbol | :})<reservedop | dashes> GHC says comment. Hugs says varsym. What's the answer? -- Taral <taralx(a)gmail.com> "Computer science is no more about computers than astronomy is about telescopes." -- Edsger Dijkstra

2 2

Simple and Easy Persistence
by Matthew M. Munz 09 Dec '05

09 Dec '05

Hi all, I have some program data that I'd like to persist. I could just use read and show and file I/O to store arrays as files. [1] This works and it is easy and simple (which I like) but it is also inefficient and a little cumbersome. I imagine that this is a very common task, and I know of utilities in other environments like object databases, embedded databases, XML persistence, etc. that can make this kind of persistence simple *and* relatively efficient and reliable. E.g.) I have found the HSQLDB embedded database [2] to be useful when writing Java applications. What do you do for quick and easy persistence in Haskell? Are there any libraries or techniques that are especially useful for this? [1] > type SimpleRecord = (Integer, Integer, Integer) > type SimpleIndex = Integer > type SimpleDB = (Array SimpleIndex SimpleRecord, FilePath) > loadDB :: FilePath -> IO SimpleDB > loadDB f = do h <- openFile f ReadMode > s <- hGetContents h > hClose h > return $ r s > where r :: String -> SimpleDB > r = read > getRecord :: SimpleDB -> SimpleIndex -> SimpleRecord > getRecord (a, _) = (a !) > updateRecord :: SimpleDB -> SimpleIndex -> SimpleRecord -> SimpleDB > updateRecord (a, f) i r = (a//[(i,r)],f) > storeDB :: SimpleDB -> IO () > storeDB sdb@(a,f) = do h <- openFile f WriteMode > hPutStr h (show sdb) > hClose h > sampleDB = (array (0,10) [(x,(x+1,x*2,42)) | x <- [0..10]],"output/ 1.db.txt") [2] http://hsqldb.org/ - Matt Munz mmm92(a)pantheon.yale.edu

6 8

Call for papers -- FOAL 2006: Foundations of Aspect-Oriented Languages
by Ralf Lammel 09 Dec '05

09 Dec '05

FOAL: Foundations of Aspect-Oriented Languages --- CALL FOR PAPERS --- Submission deadline: 25 January 2006 A one day workshop affiliated with AOSD 2006 in Bonn, Germany, on March 21, 2006. Themes and Goals FOAL is a forum for research in foundations of aspect-oriented programming languages. Areas of interest include but are not limited to: - Semantics of aspect-oriented languages - Specification and verification for such languages - Type systems - Static analysis - Theory of testing - Theory of aspect composition - Theory of aspect translation (compilation) and rewriting The workshop aims to foster work in foundations, including formal studies, promote the exchange of ideas, and encourage workers in the semantics and formal methods communities to do research in the area of aspect-oriented programming languages. All theoretical and foundational studies of this topic are welcome. The goals of FOAL are to: - Make progress on the foundations of aspect-oriented programming languages. - Exchange ideas about semantics and formal methods for aspect-oriented programming languages. - Foster interest within the programming language theory and types communities in aspect-oriented programming languages. - Foster interest within the formal methods community in aspect-oriented programming and the problems of reasoning about aspect-oriented programs. Workshop Format The planned workshop format is primarily presentation of papers and group discussion. Talks will come in three categories: long (30 minutes plus 15 minutes of discussion), short (20 minutes plus 5 minutes of discussion) and very short (7 minutes plus 3 minutes of discussion). The very short talks will allow for short presentations of topics for which results are not yet available, perhaps for researchers who are seeking feedback on ideas or seek collaborations. We also plan to ensure sufficient time for discussion of each presentation by limiting the number of long talks and having only a few short talks. Submissions Invitation to the workshop will be based on papers selected by the program committee; those wishing to attend but not having a paper to submit should contact the organizers directly to see if there is sufficient space in the workshop. FOAL solicits full-length, short, and very short papers on all areas of formal foundations of AOP languages. Submissions will be read by the program committee and designated reviewers. Papers will be selected for long, short, and very short presentation at the workshop based on their length, scientific merit, innovation, readability, and relevance. Papers previously published or already being reviewed by another conference are not eligible. Some papers may not be selected for presentation, and some may be selected for presentation in shorter talks than their paper length would otherwise command. We will limit the length of paper presentations and the number of papers presented to make sure that there is enough time for discussion. Papers presented at the workshop will be included in a technical report (from Iowa State University). Authors will retain their own copyright to the papers. Publication of papers at other venues will thus remain possible. We will also investigate having a special issue of a journal for revisions of selected papers after the workshop. Authors should note the following details: - Submissions are due no later than 23:00 GMT, Friday, 25 January, 2006. This is a firm deadline. - Authors must indicate whether they wish to be considered for a long, short, or very short presentation. - Papers for long presentations must not exceed 10 pages in length; those for short presentations must not exceed 5 pages in length, and those for very short presentations must not exceed 3 pages in length. - Some papers may not be selected for presentation, and some may be selected for presentation in shorter talks than requested. - We encourage use of the ACM Conference format for submissions, as this will be required for accepted papers. You must add page numbers (which are not part of the standard format) to your submissions, to make adding comments easier. - Submissions are to be sent as PDF (preferred) or postscript attachments in an email to Curtis Clifton, clifton -at- rose-hulman -dot- edu. We will notify the corresponding author of papers that are selected for presentation at the workshop by 10 February 2006. The early registration deadline for AOSD will be 17 February 2006. FOAL attendees must be registered for AOSD. Final versions of papers for the proceedings will be due on 7 March 2006. Important Dates * Submission Deadline 23:00 GMT, 25 January 2006 * Notification of Acceptance 10 February 2006 * AOSD Early Registration Deadline 17 February 2006 * Final Versions of Papers due 7 March 2006 * Workshop 21 March 2006 Program Committee * Mira Mezini (PC Chair) - Darmstadt University of Technology * Jonathan Aldrich - Carnegie Mellon University * Don Batory - University of Texas, Austin * Paulo Borba - Universidade Federal de Pernambuco * Curtis Clifton - Rose-Hulman Institute of Technology * Marc Eaddy - Columbia University * Robby Findler - University of Chicago * Matthew Flatt - University of Utah * Pascal Fradet - INRIA * Alan Jeffrey - Bell Labs * Shmuel Katz - Technion-Israel Institute of Technology * John Lefor - Microsoft Research * Karl Lieberherr - Northeastern University * Todd Millstein - University of California, Los Angeles * Oege de Moor - Oxford University * Hridesh Rajan - Iowa State University * David Walker - Princeton University * Mitchell Wand - Northeastern University Organizers * Gary T. Leavens - Iowa State University * Ralf Lämmel - Microsoft * Curtis Clifton - Rose-Hulman Institute of Technology For more information, visit the FOAL Workshop home page at http://www.cs.iastate.edu/FOAL.

1 0

fptools mirror in darcs ready for testing
by John Goerzen 08 Dec '05

08 Dec '05

Hello everyone, Finally! Simon Marlow's plan[1] for moving from CVS to darcs for fptools, GHC, etc. is happening. Thanks to some feedback from him and the author of Tailor, as well as some free time finally, I've been able to convert things from CVS to darcs according to the plan. So, the first phase is to have live, updated darcs mirrors of CVS repos as appropriate. We now have that. Please feel free to darcs get --partial any of these. (Trust me, you *REALLY* want to use --partial. You'd be downloading over 13,000 patches otherwise on some of these.) http://cvs.haskell.org/darcs/ghc GHC HEAD http://cvs.haskell.org/darcs/ghc.ghc-6.4 GHC ghc-6-4-branch http://cvs.haskell.org/darcs/libraries libraries dir from fptools, HEAD http://cvs.haskell.org/darcs/libraries.ghc-6.4 libraries dir from fptools, ghc-6-4-branch http://cvs.haskell.org/darcs/nofib nofib dir from fptools, HEAD (there were no commits on ghc-6-4-branch for nofib) http://cvs.haskell.org/darcs/testsuite testsuite dir from fptools, HEAD http://cvs.haskell.org/darcs/testsuite.ghc-6.4 testsuite dir from fptools, ghc-6-4-branch Please note that you cannot pull patches between branches. This is because it is not really possible to have an automated CVS to darcs conversion that preserves enough information to do so. However, once the 6.4 branches go away, this will become nicely possible with future branches. Also please note that these repos are READ ONLY for now. Nobody will be accepting darcs patches until Simon (or someone) gives the word. These will all be updating daily as soon as I get around to writing a cron job. [1] http://www.haskell.org//pipermail/cvs-ghc/2005-November/027174.html

4 5

Libraries mailing list
by Krasimir Angelov 08 Dec '05

08 Dec '05

Hi Guys, Yesterday I sent a message to libraries(a)haskell.com mailing list but it seems like the message isn't dispatched yet. Is there any problem with the list or I have to send the message again? Cheers, Krasimir

3 3

Re: [Haskell] cabal and ghcconfigure.h
by Robert 07 Dec '05

07 Dec '05

On Dec 1, 2005, at 10:18 AM, Duncan Coutts wrote: > On Wed, 2005-11-30 at 22:48 -0500, Robert Dockins wrote: >> I've just run across a problem with my cabal build system -- I'm not yet sure >> if this is a cabal problem or a system configuration problem. >> I've been developing a package on OSX using the ghc 6.4.1 and cabal from >> darwinports. All is fine and dandy. However, today I've sucked my darcs >> repo down to my machine at home (running Gentoo linux) and now my package >> won't build. (this time with GHC 6.4.1 from portage and cabal 1.1.3) >> It halts while apparently running an Alex generated lexer through CPP, with >> the error: >> ghcconfig.h: No such file or directory >> My GHC install has this file at /usr/lib/ghc-6.4.1/include, but it clearly >> isn't in the include path that cabal is using. >> So the question is -- is this a cabal bug of some kind, or is the gentoo setup >> messed up some how? How should I proceed? > Are you using cpphs? No, both environments do not have cpphs installed. > When you use ghc to do the 'cpp'ing it adds -I/usr/lib/ghc-6.4.1/include > but if Cabal is using cpphs then I suspect that it will not. > You can pass -v to Cabal to get it to show you exactly what it is > invoking: > runhaskell Setup.lhs build -v > Alternatively you can specify the /usr/lib/ghc-6.4.1/include directory > in the "include-dirs" field in the .cabal file, however this is not > ideal of course since that path will vary between systems and ghc > versions. Yes, but this seems like exactily the kind of thing we'd like to avoid. The major difference between the two machines seems to be the version of cabal. On my mac (where compilation works), cabal version 1.0 is installed, whereas on my gentoo machine cabal 1.1.3 is installed (both with GHC 6.4.1). Neither command line has a '-I' option. Any ideas? The following output was generated on the OSX machine: --------------------------------------------------------------------------------------------- $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 $ ghc-pkg -list /opt/local/lib/ghc-6.4.1/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0, Cabal-1.0, parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0, HUnit-1.1, mtl-1.0, fgl-5.2, X11-1.1, HGL-3.1, OpenGL-2.0, GLUT-2.0, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) $ runhaskell Setup.hs configure -v Warning: No license-file field. Configuring Cmm-0.1... configure: searching for ghc in path. configure: found ghc at /opt/local/bin/ghc /opt/local/bin/ghc --version >tmp19500 configure: looking for package tool: ghc-pkg near compiler in /opt/local/bin/ghc configure: found package tool in /opt/local/bin/ghc-pkg configure: Using install prefix: /usr/local configure: Using compiler: /opt/local/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1 configure: Using package tool: /opt/local/bin/ghc-pkg configure: Using haddock: /opt/local/bin/haddock configure: Using happy: /opt/local/bin/happy configure: Using alex: /opt/local/bin/alex configure: Using hsc2hs: /opt/local/bin/hsc2hs configure: No cpphs found configure: Reading installed packages... /opt/local/bin/ghc-pkg --global list >tmp19500 $ runhaskell Setup.hs build -v Reading parameters from /Users/rdocki01/code/cmm/Cmm.buildinfo Preprocessing library Cmm-0.1... /opt/local/bin/alex -g -osrc/Language/Cmm/Parser/CmmLex.hs src/Language/Cmm/Parser/CmmLex.x /opt/local/bin/happy -agc -osrc/Language/Cmm/Parser/CmmParser.hs src/Language/Cmm/Parser/CmmParser.y Preprocessing executables for Cmm-0.1... Building Cmm-0.1... /opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes Language.Cmm.Parser Language.Cmm.Lint Language.Cmm.Messages Language.Cmm.Messages.EN Language.Cmm.Parser.CmmLex Language.Cmm.Parser.CmmParser Language.Cmm.Parser.PPrSyntax Language.Cmm.Parser.Syntax Language.Cmm.Parser.Tokens Language.Cmm.Parser.ParseMonad Language.Cmm.Parser.ParserUtils Language.Cmm.Parser.LexUtils Language.Cmm.Lint.SymbolTable Language.Cmm.Lint.BuildTables Language.Cmm.Lint.LintMonad Language.Cmm.Lint.Typecheck Language.Cmm.Lint.LintProc Language.Cmm.Lint.LintConstants Language.Cmm.Lint.LintTop Chasing modules from: Language.Cmm.Frontend,Language.Cmm.Datatypes,Language.Cmm.Parser,Language.Cmm.Lint,Language.Cmm.Messages,Language.Cmm.Messages.EN,Language.Cmm.Parser.CmmLex,Language.Cmm.Parser.CmmParser,Language.Cmm.Parser.PPrSyntax,Language.Cmm.Parser.Syntax,Language.Cmm.Parser.Tokens,Language.Cmm.Parser.ParseMonad,Language.Cmm.Parser.ParserUtils,Language.Cmm.Parser.LexUtils,Language.Cmm.Lint.SymbolTable,Language.Cmm.Lint.BuildTables,Language.Cmm.Lint.LintMonad,Language.Cmm.Lint.Typecheck,Language.Cmm.Lint.LintProc,Language.Cmm.Lint.LintConstants,Language.Cmm.Lint.LintTop Compiling Language.Cmm.Lint.SymbolTable ( src/Language/Cmm/Lint/SymbolTable.hs, dist/build/src/Language/Cmm/Lint/SymbolTable.o ) Compiling Language.Cmm.Datatypes ( src/Language/Cmm/Datatypes.hs, dist/build/src/Language/Cmm/Datatypes.o ) [ snip a bunch of successful compile messages ] This output was generated on the gentoo machine where compilation fails: --------------------------------------------------------------------------------------------------------------- $ ghc-pkg -list /usr/lib/ghc-6.4.1/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0, parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0, HUnit-1.1, mtl-1.0, fgl-5.2, X11-1.1, HGL-3.1, OpenGL-2.0, GLUT-2.0, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0), Cabal-1.1.3 $ runhaskell Setup.hs configure -v Setup.hs: Warning: No license-file field. Configuring Cmm-0.1... configure: searching for ghc in path. configure: found ghc at /usr/bin/ghc "/usr/bin/ghc" --version >tmp8374 configure: looking for package tool: ghc-pkg near compiler in /usr/bin/ghc configure: found package tool in /usr/bin/ghc-pkg configure: Using install prefix: /usr/local configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1 configure: Using package tool: /usr/bin/ghc-pkg configure: No haddock found configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found configure: Reading installed packages... "/usr/bin/ghc-pkg" --global list >tmp8374 $ runhaskell Setup.hs build -v Preprocessing library Cmm-0.1... /usr/bin/alex -g -o src/Language/Cmm/Parser/CmmLex.hs src/Language/Cmm/Parser/CmmLex.x /usr/bin/happy -agc -o src/Language/Cmm/Parser/CmmParser.hs src/Language/Cmm/Parser/CmmParser.y Preprocessing executables for Cmm-0.1... Building Cmm-0.1... /usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend Language.Cmm.Datatypes Language.Cmm.Parser Language.Cmm.Lint Language.Cmm.Messages Language.Cmm.Messages.EN Language.Cmm.Parser.CmmLex Language.Cmm.Parser.CmmParser Language.Cmm.Parser.PPrSyntax Language.Cmm.Parser.Syntax Language.Cmm.Parser.Tokens Language.Cmm.Parser.ParseMonad Language.Cmm.Parser.ParserUtils Language.Cmm.Parser.LexUtils Language.Cmm.Lint.SymbolTable Language.Cmm.Lint.BuildTables Language.Cmm.Lint.LintMonad Language.Cmm.Lint.Typecheck Language.Cmm.Lint.LintProc Language.Cmm.Lint.LintConstants Language.Cmm.Lint.LintTop Chasing modules from: Language.Cmm.Frontend,Language.Cmm.Datatypes,Language.Cmm.Parser,Language.Cmm.Lint,Language.Cmm.Messages,Language.Cmm.Messages.EN,Language.Cmm.Parser.CmmLex,Language.Cmm.Parser.CmmParser,Language.Cmm.Parser.PPrSyntax,Language.Cmm.Parser.Syntax,Language.Cmm.Parser.Tokens,Language.Cmm.Parser.ParseMonad,Language.Cmm.Parser.ParserUtils,Language.Cmm.Parser.LexUtils,Language.Cmm.Lint.SymbolTable,Language.Cmm.Lint.BuildTables,Language.Cmm.Lint.LintMonad,Language.Cmm.Lint.Typecheck,Language.Cmm.Lint.LintProc,Language.Cmm.Lint.LintConstants,Language.Cmm.Lint.LintTop src/Language/Cmm/Parser/CmmLex.hs:19: ghcconfig.h: No such file or directory The offending file has the same opening, which looks like: ------------------------------------------------------------------------------------- {-# OPTIONS -fglasgow-exts -cpp #-} {-# LINE 1 "src/Language/Cmm/Parser/CmmLex.x" #-} module Language.Cmm.Parser.CmmLex ( lexer , lexAll , lexTokens ) where import Numeric import Data.Char import Language.Cmm.Messages import Language.Cmm.Datatypes( Name(..), PrimOp(..) ) import Language.Cmm.Parser.Tokens import Language.Cmm.Parser.LexUtils import Language.Cmm.Parser.ParseMonad #if __GLASGOW_HASKELL__ >= 603 #include "ghcconfig.h" #else #include "config.h" #endif #if __GLASGOW_HASKELL__ >= 503 import Data.Array import Data.Char (ord) import Data.Array.Base (unsafeAt) -- Robert robdockins(a)fastmail.fm -- http://www.fastmail.fm - The professional email service

4 6

ANNOUNCE: Process library (for dataflow-oriented programming?)
by Bulat Ziganshin 07 Dec '05

07 Dec '05

Hello haskell, Joel's program (discussed in cafe), which now uses MVars instead of Channels to send data between threads, may be a good example of dataflow-driven program: it consists of many hundreds of threads and when one thread sends data to another through MVar, this thread in most cases goes to sleep until receiving thread will process previous value of this MVar. so, threads are waked up and asleep according to passing values between them, and the whole program executes in order defined by these data dependencies, as opposite to the order of program statements one year ago i developed small library, which can be helpful if you want to use such style of programming. its ideas are modelled after Unix pipes, which are widely used to assemble complex data processing "engines" from simple "details". really this library is very thin layer over direct using of forkOS, channels and MVars; nevertheless, is is very convenient and beatiful you can download library as http://freearc.narod.ru/Process.tar.gz this page also contains sources of my program where you can find examples of using library in real toy :) below is a guide to library usage to create pipe, which contains 3 processes - "producer", "transformer" and "consumer": runP ( producer |> transformer |> consumer ) each process in pipe runned in separate Haskell thread. process is represented by ordinary Haskell function which gets an additional parameter - handle, which can be used to receive data from previous process in pipe (using receiveP) and send data to the next process (using sendP). for example, abovementioned processes can be implemented as: producer handle = mapM_ (sendP handle) [1..10] transformer handle = replicateM_ 10 $ do x <- receiveP handle sendP handle (x*2) consumer handle = replicateM_ 10 $ do x <- receiveP handle print x if first process in pipe tries to use receiveP or last process in pipe tries to use sendP, then run-time exception is generated. number of processes in pipe can be arbitrary. because each process is just ordinary Haskell function, you can add additional parameters to processes when constructing pipes: runP ( producer |> multiple 2 |> multiple 3 |> consumer ) multiple n handle = replicateM_ 10 $ do x <- receiveP handle sendP handle (x*n) moreover, you can construct pipe or part of it as ordinary data value, which then can be runned by runP: let pipe = case multipliers of [x] -> multiple x [x,y] -> multiple x |> multiple y [x,y,z] -> multiple x |> multiple y |> multiple z _ -> \handle -> fail "Zero or too much multipliers" runP ( producer |> pipe |> consumer ) there is also "back channel", which can be used to "return" data to previous process in the pipe, its operations is send_backP and receive_backP. it can be used to return acknowledgments, synchronize processes or to return resources back. brief example of its usage: producer: sendP pipe (buf,len) consumer: ; ; (buf,len) <- receiveP pipe ; hPutBuf file buf len ; send_backP pipe () receive_backP pipe ; --now we know that buf is free ; (i organized lines to show execution order) if processes joined in pipe with "|>" then channel between them uses MVar, so at any moment it may contain no more than 1 element. if channel between two processes is created with "|>>>" then Chan is used, which can contain arbitrary number of data items. be careful with such channels, because they can grow to unlimited size. "|>" and "|>>>" can be arbitrarily combined in one pipe: runP ( producer |>>> multiple 2 |> multiple 3 |>>> consumer ) back channel (used by send_backP and receive_backP) are always multi-element (uses Chan) runP returns when all processes in pipe are finished. if any process in pipe generates uncaught exception, then all processes in pipe are killed and this exception is re-raised in thread called runP pipe or single process can also be runned in background using runAsyncP: handle <- runAsyncP (multiple 2) handle returned here can be used to interact with first and last processes in pipe, in contrast to runP: handle <- runAsyncP (multiple 2) sendP handle 1 res <- receiveP handle of course, pipe runned asynchronously is not required to perform input, output, or both: handle <- runAsyncP ( producer |> transformer ) handle <- runAsyncP ( transformer |> consumer ) handle <- runAsyncP ( producer |> transformer |> consumer ) currently channels to "open ends" of background pipe are always one-element (uses MVars). types of channels inside pipe are determined, as usual, by using the "|>" or "|>>>" operator you can wait for finishing of asynchronous pipe with "joinP handle" you can "replace" process, which is runned in pipe, with another process or pipe by using runFuncP: transformer handle = runFuncP ( multiple 2 |> multiple 3 ) (receiveP handle) (send_backP handle) (sendP handle) (receive_backP handle) actually, runFuncP just executes its pipe using 4 supported functions for interaction with first and last pipe processes. to make this obvious i will say how runP can be implemented in terms of runFuncP: runP p = runFuncP p (error "First process in runP tried to receive") (error "First process in runP tried to send_back") (error "Last process in runP tried to send") (error "Last process in runP tried to receive_back") runFuncP returns when all processes in its pipe are finished. using it, you can create unlimited number of scenarios: running several runFuncP sequentially to deal with different parts of your data, process part of data itself and part with runFuncP, "redirect" your input to process runned by runFuncP but consume output from runFuncP in other way: consumer handle = runFuncP ( multiple 4 ) (receiveP handle) undefined print -- output action undefined runFuncP can also be used in other cases when we need to run single process or whole pipe "imitating" its interaction with "external world" by some functions: runFuncP transformer readLn -- input action undefined print -- output action undefined it will also be interesting to have some functions which can just insert "filtering" process or pipe on input or output side of current process: transformer channel = do channel <- insertInputFilterP (multiple 2) channel channel <- insertOutputFilterP (multiple 4) channel x <- receiveP channel sendP channel (x+1) ... but i don't need it and therefore this currently is not implemented the library also don't contains routines to check that input is ready or output can be done (because i don't need it and it is a bad programming style), nor routines to check for EOF (i prefer to encode this explicitly in structure of data sent across channels; you also can wrap your data in Maybe type and use Nothing to encode EOF) -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0