- Haskell - Haskell.org

mfix as an effect
by oleg＠pobox.com 12 Jan '04

12 Jan '04

Can mfix be considered as "just a fix point combinator", without any trace of effect? The recent discussion about continuations and implementations of Scheme in Haskell highlighted that question. The point of the discussion is the difference between letrec implemented using the fixpoint combinator, and a letrec implemented via an updateable cell (as in Scheme, according to R5RS). Ashley Yakeley wrote: > > The difference between the Y and set! approaches to letrec *is* > > observable. > I don't believe you. My implementation uses Haskell's "mfix", which > looks like a Y to me. I certainly don't use anything like "set!". That is, Ashley Yakeley claimed that his Haskell implementation of Scheme implements letrec via Y -- and yet his implementation is consistent with the R5RS semantics, which mandates the updateable-cell letrec. Indeed, his implementation passes the tests designed to discern the way letrec is implemented. There seems to be a contradiction in the above statements. The contradiction is resolved by noting that "mfix", although may look like "Y", is fundamentally different. There is a latent "set!" in mfix, which can be pried open with call/cc. There is an effect in mfix. The following is a simple test that shows it. Let us consider the following test (Scheme code first, Haskell code follows). (letrec ((fact (cons #f (lambda (n) (set-car! fact #t) (if (zero? n) 1 (* n ((cdr fact) (- n 1)))))))) (let* ((before (car fact)) (res ((cdr fact) 5))) (list before res (car fact)))) The test has been introduced and discussed in http://google.com/groups?selm=200102240312.TAA11588%40adric.cs.nps.navy.mil If letrec is implemented via updates, the test returns (#f 120 #t) If letrec is implemented via Y, the test should return (#f 120 #f). It is easy to see that if we use Y defined by (Y f) = f (Y f), the result indeed must be (#f 120 #f). Now, let us implement letrec in Haskell via fix and mfix, and compare the results. First, the implementation of the test via fix > import Data.IORef > import System.IO.Unsafe > import Control.Monad.Fix (mfix) > fix f = f g where g = f g > g = \f -> newIORef > (False, \n -> do > (flag,body) <- readIORef f > writeIORef f (True,body) > res <- if n ==0 then return 1 else > body (n-1) >>= return . (* n) > return res) > > g1 = \f -> unsafePerformIO (g f) > > test = let fact = fix g1 in do > (flag,body) <- readIORef fact > res <- (body 5) > (flag',_) <- readIORef fact > return (flag, res,flag') The code matches the Scheme code in every detail. If we try > *Main> test >>= putStrLn . show > (False,120,False) we obtain the expected result. Now, we bring in mfix: > test2 = do > fact <- mfix g > (flag,body) <- readIORef fact > res <- (body 5) > (flag',_) <- readIORef fact > return (flag, res,flag') And, quite predictably, > *Main> test2 >>= putStrLn . show > (False,120,True)

2 1

Type classes confusion
by andrew cooke 10 Jan '04

10 Jan '04

Hi, I'm trying to use type classes and suspect I've got confused somewhere down the line, because I've got to an error message that I don't understand and can't remove. I have a class that works like a hash table, mapping from String to some type. I have two instances, one that is case insensitive for keys. I want to hide these instances from the rest of the code, which should only use the class. This class is called Dictionary. In addition, for Dictionaries that map Strings to Strings, I have some functions which do substitutions on Strings using their own contents. Possibly the first source of problems is that I can't find a way to express these two classes together without multiple parameter type classes (one parameter for the case/no case and one for the type returned): class Dictionary d a where add' :: d a -> (String, a) -> d a ... instance Dictionary DictNoCase a where add' d (k, v) = ... -- Dict is the underlying tree implementation and Maybe stores the -- value for the null (empty string) key. data DictNoCase a = DictNoCase (Dict a) (Maybe a) class (Dictionary d String) => SubDictionary d where substitute :: d String -> String -> String ... instance SubDictionary DictNoCase where substitute d s = ... All the above compiles and seems correct (is it?). I also provide an empty instance of the two instance types. For DictNoCase, this is empty = DictCase Empty Nothing where Empty is the empty type constructor for Dict Now (almost there) elsewhere I want to define a data type that contains two of these Dictionaries. One stores String values. The other stores functions that take this same type and return a result and a copy of the type: data Context s f = (Dictionary s String, Dictionary f (CustomFn s f)) => Ctx {state :: s String, funcs :: f (CustomFn s f)} type CustomFn s f = Context s f -> Arg -> IO (Context s f, Result s f) data Result s f = Attr Name String | Repeat (CustomFn s f) ... newContext = Ctx empty emptyNC (where empty is the case-sensitive empty dictionary) Now THAT doesn't compile: Template.lhs:60: All of the type variables in the constraint `Dictionary s String' are already in scope (at least one must be universally quantified here) When checking the existential context of constructor `Ctx' In the data type declaration for `Context' Template.lhs:60: All of the type variables in the constraint `Dictionary f (CustomFn s f)' are already in scope (at least one must be universally quantified here) When checking the existential context of constructor `Ctx' In the data type declaration for `Context' where line 60 is "data Context...." And I can't see what I've done wrong. Any help gratefully received. Cheers, Andrew -- personal web site: http://www.acooke.org/andrew personal mail list: http://www.acooke.org/andrew/compute.html

1 1

Re: getting the path to the executing program
by oleg＠pobox.com 10 Jan '04

10 Jan '04

Hal Daume wrote: > is there a function, related to getProgName, which returns the (absolute) > path to the current program? > basically, i want to be able to read a file which i know will be in the > same directory as the current program, but not necessarily in the same > directory that we're running it from. Actually, if you want to read a file located in the same directory as the executable itself, you don't need the absolute path of the executable. You merely need any path to the executable that is valid with respect to the working directory at the start-up time. Some four years ago I wrote a similar code that seems to work reliably across HP/UX, Solaris, Linux, FreeBSD and various versions of Winxx (from Windows98 onwards). The application has been deployed in more than thousand copies and nobody has complained regarding the path. The application reliably finds the name of a file from the application's own directory no matter how the application was invoked: from its own directory by name, from its own directory as "./appname", from its own directory by the absolute or relative (../dir/appname) name, or from some other directory by the absolute or relative name, or by a symbolic link. The only assumption is that neither forward nor backward slash can appear in a file path. The latter assumption seems to always hold on Winxx, which takes the forward slash as a path delimiter too. On Unixen, the backward slash in file names seems to appear only on hacked systems. So, the failure of the approach in that case should be considered a feature. The algorithm is simple: remove the last path-component from argv[0] and append the local file name to the result (which may be an empty string). A path component is a sequence of characters that does not contain a path delimiter. Note that argv[0] may not end in a path delimiter. The algorithm requires argv[0] as it is given by the OS. Alas, neither GHC nor Hugs seem to give us that. Therefore, I'm inclosing the Scheme code that implements the algorithm. I do not have the guts to post the original code (which was in Perl). If I may suggest, a Haskell implementation may want to give a programmer a way to obtain the unmangled argv0. ; last-delimiter STR -> POS ; where POS is the location of the last path-delimiter in STR ; or #f (define delimiters '(#\\ #\/)) (define (last-delimiter str) (let loop ((i (- (string-length str) 1))) (cond ((negative? i) #f) ((memv (string-ref str i) delimiters) i) (else (loop (- i 1)))))) (define local-file-name "that-is-it") ; Like with-input-from file, but the file ; is assumed to be in the same directory as the executable ; itself (define (with-input-from-local-file local-file-name thunk) (let* ((argv0 (car (command-line))) (last-delim (last-delimiter argv0))) (with-input-from-file (if last-delim (if (< (+ 1 last-delim) (string-length argv0)) (string-append (substring argv0 0 (+ 1 last-delim)) local-file-name) (error 'with-input-from-local-file "path-delim at the end of argv0: " argv0)) local-file-name) thunk))) (display (with-input-from-local-file local-file-name read)) (newline)

4 3

ANNOUNCE: Cryptographic Library for Haskell
by Dominic Steinitz 10 Jan '04

10 Jan '04

I would like to annouce a new release of the Haskell Cryptographic Library (1.0.1). See http://www.haskell.org/crypto/ReadMe.html for more details. This library collects together existing Haskell cryptographic functions and augments them so that they: · Have common type signatures. · Can be used with the standard mode and padding algorithms (in the case of block mode ciphers). This release includes much improved support for public / private key pairs and contains: · DES · Blowfish · Cipher Block Chaining (CBC) mode · PKCS5 and nulls padding · SHA-1 · RSA · OAEP · ASN.1 · PKCS#8 Dominic Steinitz

1 0

from array update algorithm to nice Haskell code
by Wolfgang Jeltsch 10 Jan '04

10 Jan '04

Hello, I have an algorithm which updates one or more arrays in a loop. The update operations depend on the (old) contents of the arrays, so I cannot use accumArray. I want to implement this algorithm without mutable arrays in Haskell. Are there any possibilities to do so efficiently? Are there some hints about how to do this? Wolfgang

3 8

Problems building experimental Unicode version of Hugs on Windows
by Graham Klyne 09 Jan '04

09 Jan '04

This message notes some edits I'm making to try and build the Dec2003 Hugs source kit with Unicode under MS-Windows (because I want to try and use HXML toolbox under Hugs). It also describes a problem I'm having with the experimental Unicode support under Windows. (I'm also thinking these notes might be helpful to anyone else who wants to build Hugs on Windows without using the Unix tools environment.) Using Microsoft Visual Studio, version 6, and supplied project files: (1) edit src/msc/options.h to include #define UNICODE_CHARS_1 (2) Change #if STDCALL_SUPPORTED to #ifdef STDCALL_SUPPORTED in: connect.h input.c static.c (3) Add the following files to the Visual Studio project: char.c edit.c errors.c evaluator.c goal.c machdep.c module.c observe.c opts.c script.c strutil.c (4) In version.c, changed the definition of VERSION_STRING to "Hugs-Unicode-20031206, so that this instantiation of Hugs will use a different registry key from the standard version for saving its options. Copied the resulting executable into the Hugs installation directory as hugs-unicode-20031206.exe (this being the date string in the source kit I was using, obtained from): http://www.golubovsky.org/software/hugs-patch/test-hugs98-Dec2003.tar.gz per: http://haskell.org/pipermail/hugs-users/2003-December/000508.html http://www.golubovsky.org/software/hugs-patch/hugs_unicode_test.html ... At this point, I run into a problem that appears to be (obscurely) related to the source changes that relate to Unicode support... If I start the modified program in the normal way, it appears to start OK. But if I change *any* option (e.g. :set -q), then stop and restart the program, I get: ERROR, a closing quote, '"', was expected FATAL ERROR, Unable to load Prelude and then the program crashes with an access violation, in module char.c, function freeConsCharTable, line 539: [[ static void local freeConsCharTable() { int i, j; for (j=1; j<NUM_LEVEL2; j++) >>> this line: >>> if (consCharTable[0][j]!=NULL) free(consCharTable[0][j]); for (i=1; i<NUM_LEVEL1; i++) if (consCharTable[i]!=NULL) { for (j=0; j<NUM_LEVEL2; j++) if (consCharTable[i][j]!=NULL) free(consCharTable[i][j]); free(consCharTable[i]); } ]] The debugger shows that "consCharTable[0]" is null (0). I note that this is new code which is part of the experimental Unicode support. If I delete the registry key created for the saved parameters, and restart Hugs, basic expressions seem to work fine. (e.g. simple string operations like concatenation were performed OK). ... The build procedure I've outlined above is essentially the same as one I used to create a version of Hugs with enlarged code storage space, which has been working fine for me. I'll leave it there, for now. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

COORDINATION2004: First Call for Participation
by Emilio Tuosto 09 Jan '04

09 Jan '04

[[ -- Apologies for multiple copies of this message -- ]] COORDINATION 2004 Call for Participation Sixth International Conference on Coordination Models and Languages 24-27 February 2004 Pisa, Italy http://www.di.unipi.it/Coordination2004 =============================================================================== Scope of the Conference The need for increasing programming productivity and rapid development of complex systems provides the pragmatic motivation for the development of coordination/orchestration languages and models. The intellectual excitement associated with such endeavours is rooted in the decades-old desire to leverage off increasingly higher levels of abstractions. Coordination-based methods provide a clean separation between individual software components and their interactions within their overall software organisation. Coordination is relevant in design, development, debugging, maintenance, and reuse of all complex concurrent and distributed systems. Specifically, coordination becomes paramount in the context of open systems, systems with mobile entities, and dynamically re-configurable evolving systems. Moreover, coordination models and languages focus on such key issues in Component Based Software Engineering as specification, interaction, and dynamic compositions. More recently, market trends brought on by the commercialisation of the World Wide Web, have fuelled a new level of interest in coordination-based approaches in industry. Applications like BizTalk, standards like the web services' WS-* family, and contending coordination standards like BEPL4WS and WSCI, are all examples of this phenomenon. This interest is opening up new opportunities both to apply coordination-based techniques to a broad class of applications as well as to grapple with potentially new kinds of requirements coming from internet-scale scenarios. The conference provides a forum for the discussion of fundamental principles and important innovations in the definition of coordination models and languages. The preliminary program of the conference can be found at http://www.di.unipi.it/Coordination2004/program.html Conference Location The Sixth International Conference on Coordination Models and Languages will be held in Pisa, Italy, at Dipartimento di Informatica, Via F. Buonarroti 2 (sala Gerace). Further information about the conference location may be found at the URL: http://www.di.unipi.it/Coordination2004/location.html Conference Accommodation and Registration Information about accommodation (reserving rooms in hotels specially booked for COORDINATION 2004 attendees) and registration for COORDINATION 2004 and the affiliated workshop (WS-FM 2004) is available at http://www.di.unipi.it/Coordination2004/inforeg.html Program co-chairs Rocco De Nicola (Univ. Firenze) Greg Meredith (Microsoft) Organising Chair Gianluigi Ferrari (Univ. Pisa) Program Committee: Roberto Amadio, Univ. Marseilles - France Farhad Arbab, CWI - The Netherlands Marcelo Bonsangue, Leiden University - The Netherlands Paolo Ciancarini, Univ. Bologna - Italy Gianluigi Ferrari, Univ. Pisa - Italy José Fiadeiro, Univ. Leicester - United Kingdom Chris Hankin, Imperial College - United Kingdom Jean-Marie Jacquet, Univ. Namur - Belgium Antonia Lopes, Univ. of Lisbon - Portugual Jeff Magee, Imperial College - United Kingdom George Papadopoulos, Univ. Cyprus - Cyprus Gian Pietro Picco, Politecnico di Milano - Italy Rosario Pugliese, Univ. Firenze - Italy Gruia-Catalin Roman, Washington University, St. Louis - USA Ant Rowstrom, Microsoft Cambridge - United Kingdom Vijay Saraswat, IBM Research - USA Carolin Talcott, SRI - USA Robert Tolksdorf, Free University of Berlin - Germany Herbert Wiklicky, Imperial College - United Kingdom Alan Wood, Univ. York - United Kingdom Franco Zambonelli, Univ. Modena - Italy Organising Committee Andrea Bracciali, Univ. Pisa - Italy Roberto Bruni, Univ. Pisa - Italy Antonio Cisternino, Univ. Pisa - Italy Dan Hirsch, Univ. Pisa - Italy Laura Semini, Univ. Pisa - Italy Emilio Tuosto, Univ. Pisa - Italy Further Information - COORDINATION2004 Web site: http://www.di.unipi.it/Coordination2004 - For questions: coordination2004(a)di.unipi.it

1 0

getting the path to the executing program
by Hal Daume III 08 Jan '04

08 Jan '04

is there a function, related to getProgName, which returns the (absolute) path to the current program? basically, i want to be able to read a file which i know will be in the same directory as the current program, but not necessarily in the same directory that we're running it from. -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

5 6

Re: getting the path to the executing program
by Hal Daume III 08 Jan '04

08 Jan '04

Sadly, this doesn't seem to work: 9:26am albini:SVMseq/ cat Foo.hs module Main where import System.Environment main = getEnv "_" >>= putStrLn 9:27am albini:SVMseq/ ghc Foo.hs -o foo 9:27am albini:SVMseq/ ./foo Fail: does not exist Action: getEnv Reason: no environment variable File: _ On Thu, 8 Jan 2004, Christopher Milton wrote: > The environmental var "_" in $ENV{"_"} (pardon my Perlish) holds > the full path name of the command currently executing (itself), at > least on RedHat Linux and HP-UX, so you should be able to use > getEnv... I think... > > --- Hal Daume III <hdaume(a)ISI.EDU> wrote: > > is there a function, related to getProgName, which returns the (absolute) > > path to the current program? > > > > basically, i want to be able to read a file which i know will be in the > > same directory as the current program, but not necessarily in the same > > directory that we're running it from. > > > ===== > Christopher Milton > cmiltonperl(a)yahoo.com > -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

1 0

RE: class ??? with Haddock
by Simon Marlow 08 Jan '04

08 Jan '04

> > Am Donnerstag, 8. Januar 2004 11:02 schrieben Sie: > > > [...] > > > > > Anyway, you can use GHC to preprocess your source files > > before feeding > > > them to Haddock: > > > > > > $ ghc -E -cpp -D__HADDOCK__ Foo.hs -o Foo.raw-hs > > > > This only replaces all __HADDOCK__ occurences with 1 but > > doesn't process #ifdefs. > > Are you sure? It works for me, and it's what we use in GHC's > libraries. One thing I forgot to mention is that you also need to remove the pesky lines beginning with '#' that the C preprocessor leaves behind. Here's what we do in GHC: $ ghc -D__HADDOCK__ -E -cpp Foo.hs -o Foo.tmp $ sed -e 's/^#.*//' <Foo.tmp >Foo.raw-hs Cheers, Simon

2 1