March 2002 - Haskell - Haskell.org

Re: Z_n in Haskell
by oleg＠pobox.com 29 Mar '02

29 Mar '02

The Z_n problem doesn't seem to be different from the problem of arrays or bitvectors of a statically-checkable size. If you prefer a decimal specification of the modulus, you may find the following articles relevant. Implementation of fixed-precision decimal types: Main> BV D1 0 Bitvector of width 1 and value 0 Main> BV (D1,D2) 123 Bitvector of width 12 and value 123 Main> BV (D5,D7,D9) 31415 Bitvector of width 579 and value 31415 It appears that modulus in the Z_n problem plays the same role as the bitvector width in the bitvector problem. An attempt to perform an operation on bitvectors of different sizes results in a compiler error: Main> (BV (D1,D0) 10) `b_and` (BV (D1,D1) 7) ERROR - Type error in application *** Expression : b_and (BV (D1,D0) 10) (BV (D1,D1) 7) *** Term : BV (D1,D0) 10 *** Type : BitVector (D1,D0) *** Does not match : BitVector (D1,D1) http://groups.google.com/groups?selm=7eb8ac3e.0202201753.473a5cb2%40posting… Arbitrary precision decimal types, e.g.: Main> BV (D1 $ D2 $ D3 $ D4 $ D5 $ D6 $ D7 $ D8 $ D9 $ D0 $ D9 $ D8 $ D7 $ D6 $ D5 $ D4 $ D3 $ D2 $ D1 $ Dim) 1234567879 Bitvector of width 1234567890987654321 and value 1234567879 which are slightly more general and less convenient, are described in: http://groups.google.com/groups?selm=7eb8ac3e.0202230221.62d98db8%40posting… Both implementations work in any Haskell-98 system. Multi-parameter classes, existential types or other extensions are not needed.

1 0

Z_n in Haskell
by Hal Daume III 28 Mar '02

28 Mar '02

Suppose I want to define integers modulo n, I could do this something like: data Zn = Zn Integer Integer -- modulus, number instance Num Zn where (Zn m1 n1) + (Zn m2 n2) | m1 == m2 = Zn m1 (n1 + n2 `mod` m1) | otherwise= error "differing moduli" ...etc... However, I'd really like it if, say, addition on Zn-s of different "n" values were caught by the typechecker and disallowed. One solution to this problem would be to do something like: class Modulus m where modulus :: T m -> Integer data Zn m = Zn (T m) Integer instance Modulus m => Num (Zn m) where (Zn m1 n1) + (Zn m2 n2) = (Zn m1 ((n1 + n2) `mod` (modulus m1))) data T a = T data Mod5 data Mod7 instance Modulus (Mod5) where modulus _ = 5 instance Modulus (Mod7) where modulus _ = 7 then we get: Modulus> (Zn (T :: T Mod5) 3) + (Zn (T :: T Mod5) 4) 2 but it fails when the moduli are different: Modulus> (Zn (T :: T Mod5) 3) + (Zn (T :: T Mod7) 4) Ambiguous type variable(s) `a' in the constraint `Show a' arising from use of `print' at <No locn> In a 'do' expression pattern binding: print it <interactive>:1: Couldn't match `Mod7' against `Mod5' Expected type: T Mod7 Inferred type: T Mod5 In an expression with a type signature: T :: T Mod7 In the first argument of `Zn', namely `(T :: T Mod7)' Unfortunately, this solution isn't very pretty. We have to define a new datatype for each modulus and make it an instance of Modulus. Is there a better way to do this? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

Do-notation
by Simon Peyton-Jones 28 Mar '02

28 Mar '02

James White has noticed that the draft Haskell 98 report gives the following translation for do-notation: do {e} = e do {e;stmts} = e >> do {stmts} do {p <- e; stmts} = let ok p = do {stmts} ok _ = fail "..." in e >>= ok On the face of it, that makes do-notation depend on the definitions of both (>>) and (>>=) in the monad. This makes a difference if someone defines an instance of the Monad class in which (>>) is not defined to be (\x y -> x >>= \_ -> y). I am certain that was not the intention of the authors. So one possibility is to change the second line to read do {e;stmts} = e >>= (\ _ -> do {stmts}) and that is what I *propose* to do. However, James implies that in his monad (>>) has a different meaning than its usual one, and Haskell 98 allows that because (>>) is one of the class operations (not a good design choice I think). I'm quite reluctant to make the meaning of do-notation dependent on such differences. James, can you convince us that doing so would be a good idea? Simon

5 6

Re: catch (fail "...")
by Sigbjorn Finne 28 Mar '02

28 Mar '02

Simon Peyton-Jones simonpj(a)microsoft.com writes: > > This is an inconsistency that was fixed in the revised Haskell98=20 > report (Apr 2001). See > http://research.microsoft.com/~simonpj/haskell98-revised > > In the bug list look for Page 90. > > It looks as though Hugs hasn't quite caught up with this change. Yes, the Feb 2001 release (which Brian was/is using) unfortunately didn't foresee the future change to the Report :-) The current release, Dec 2001, does the prescribed thing. --sigbjorn

1 0

">>" and "do" notation
by James B. White III (Trey) 28 Mar '02

28 Mar '02

I recently discovered that Hugs converts "do" notation as follows. do {e;stmts} = e >>= \_ -> do {stmts} To me, this is inconsistent with the definition given in the Haskell 98 Report. do {e;stmts} = e >> do {stmts} It "hard wires" the default definition of ">>" into "do" notation. If you provide your own definition of ">>", which is completely legal in Haskell, the "do" translation in Hugs disagrees with the definition in the Report. In other words, the following two statements produce different results. do {e;stmts} = e >>= \_ -> do {stmts} do {e;stmts} = e >> do {stmts} When I reported this as a bug, I got responses stating that the definition of "do {e;stmts}" in the Report is merely a suggestion, and that the default definition of ">>" in the "Monad" class is a law of Monads and should not be redefined in instances. I strongly disagree with these responses. I think the default definition of ">>" is just that, a default, and not a law. This view is consistent with every other default definition in a class; it is there for convenience but may be redefined. If it is a law, why are users given the power to change it! Also, I think that the Report *specifies* the translation of "do" to ">>", not merely suggests it. This is the only interpretation that makes sense to me. The above claims---that the contents of the Report are mere suggestions and that default definitions are laws---baffle me. I beg the community to reassure me or enlighten me. If my thoughts are wrong, then I assert that the Report needs revision. ">>" should no longer be a class function with a default value that can be changed; it should be syntactic sugar built into Haskell, like "do" notation. Let me just restate my argument for emphasis: a Monad instance should be able to define its own ">>" operator, and "do" notation should honor this redefinition! -- James B. White III (Trey) Center for Computational Sciences Oak Ridge National Laboratory whitejbiii(a)ornl.gov

1 0

2002 Static Analysis Symposium (SAS'02) Call for Papers
by sas02＠clip.dia.fi.upm.es 28 Mar '02

28 Mar '02

(Apologies for multiple postings) ---------------------------------------------------------------------- CALL FOR PAPERS (SAS'02) The 9th International Static Analysis Symposium September 17 - 20 2002, Madrid, Spain http://clip.dia.fi.upm.es/SAS02 Submission deadline: May 5, 2002 ---------------------------------------------------------------------- Static Analysis is increasingly recognized as a fundamental tool for high performance implementations and verification systems of high-level programming languages. The series of Static Analysis Symposia has served as the primary venue for presentation of theoretical, practical, and application advances in the area. The Ninth International Static Analysis Symposium (SAS'02) will be held at the Technical University of Madrid, do-located with Logic-based Program Development and Transformation (LOPSTR'02) and the APPIA-GULP-PRODE Joint Conference on Declarative Programming (AGP'02). Previous symposia were held in Paris, Santa Barbara, Venice, Pisa, Paris, Aachen, Glasgow and Namur. The technical program for SAS'02 will consist of invited lectures, tutorials, panels, presentations of refereed papers, and software demonstrations. Contributions are welcome on all aspects of Static Analysis, including, but not limited to: * abstract interpretation, * data flow analysis, * verification systems, * program specialization, * abstract domains, * optimizing compilers, * theoretical frameworks, * type inference, * abstract model checking, * complexity analysis, * abstract testing, * security analysis. Submissions can address any programming paradigm, including concurrent, constraint, functional, imperative, logic and object-oriented programming. Survey papers that present some aspect of the above topics with a new coherence are also welcome. Papers must describe original work, be written and presented in English, and must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal or a conference with refereed proceedings. Submission Instructions ----------------------- All submissions must be performed electronically at http://clip.dia.fi.upm.es/SAS02/submission.html. Submitted papers should be at most 15 pages excluding bibliography and well-marked appendices. Program committee members are not required to read the appendices, and thus papers should be intelligible without them. The proceedings will be published by Springer-Verlag in the Lecture Notes in Computer Science series (see http://www.springer.de/comp/lncs/authors.html for the LNCS author instructions). Thus, adhering to that style already in the submission is strongly encouraged. Papers should be submitted either in PostScript or PDF format and they should be interpretable by Ghostscript or Acrobat Reader. Papers must be printable on either A4 paper or US letter, and preferably on both. Important Dates --------------- May 5, 2002 Submission deadline June 10, 2002 Notification June 30, 2002 Final version Sept 17-20, 2002 SAS'02 Program Committee ----------------- Manuel Hermenegildo (Chair) Technical University of Madrid, Spain German Puebla (Co-chair) Technical University of Madrid, Spain Radhia Cousot Ecole Polytechnique, France Saumya Debray The University of Arizona, USA Manuel Fahndrich Microsoft Research, USA Roberto Giacobazzi Univerity of Verona, Italy Chris Hankin Imperial College, UK Giorgio Levi Univerity of Pisa, Italy Kim Marriott Monash University, Australia Alan Mycroft Cambridge University, United Kingdom Ganesan Ramalingam IBM T.J. Watson Research Center, USA Martin Rinard Massachusetts Institute of Technology, USA Shmuel Sagiv Tel-Aviv Univerisity, Israel Reinhard Wilhelm Universitat des Saarlandes, Germany Contact Info ------------ Email: sas02(a)clip.dia.fi.upm.es Fax: + 34 91 352 4819 Phone: + 34 91 336 7448 Post: Manuel Hermenegildo (Ref.: SAS'02) Facultad de Informatica Universidad Politecnica de Madrid 28660 Boadilla del Monte Madrid, Spain ---------------------------------------------------------------------- --

1 0

Mutable arrays in Haskell 98
by José Romildo Malaquias 27 Mar '02

27 Mar '02

Hello. I would like to use muttable arrays in Haskell 98, with the GHC _and_ NHC98 compilers. By muttable arrays I mean arrays with in-place updates, as with the MArray arrays (which are not Haskell 98 conformant) found in GHC. Is such array implmentation available? Regards. Romildo -- Prof. José Romildo Malaquias Departamento de Computação http://iceb.ufop.br/~romildo Universidade Federal de Ouro Preto romildo(a)iceb.ufop.br Brasil romildo(a)uber.com.br

3 3

Little problem
by Bahadır SEVİNÇ 27 Mar '02

27 Mar '02

Hello I have little problem. I want to solve this equation f(n-1) = f(n)+n f(6)=6 => f(2)=? Can anybody help me please ? Best regards.. Bahadır SEVİNÇ

2 1

MPOOL 2002 - FINAL CALL FOR PAPERS
by MPOOL 2002 27 Mar '02

27 Mar '02

We apologize if you have received this CfP multiple times. -------------------------------------------------------------------- CALL FOR PARTICIPATION Workshop on MULTIPARADIGM PROGRAMMING WITH OO LANGUAGES (MPOOL 2002, June 11) at the EUROPEAN CONFERENCE ON OBJECT-ORIENTED PROGRAMMING (ECOOP 2002, Malaga, Spain, June 10-14) While OO has become ubiquitously employed for design, implementation, and even conceptualization, many practitioners recognize the concomitant need for other programming paradigms according to problem domain. We seek answers to the question of how to address the need for other programming paradigms in the general context of OO languages. Specific areas of interest include, but are not limited to: * non-OO programming with OO languages; * merging functional/logic/OO/other programs (language crossbinding); * non-OO programming at the meta level (e.g. template metaprogramming) * module systems vs. object systems * OO design patterns and their relation to functional patterns * type system relationships across languages * theoretical foundations of multiparadigm programming with OO languages The deadline for the submission of a 5+ pages abstract is 8 April 2002 Prospective authors are invited to submit abstracts in PDF or postscript. Any common encoding (MIME or uuencode) or compression (zip, gzip) is acceptable. Authors of accepted papers are responsible for submitting the final version using the Springer LNCS LaTeX template (http://www.springer.de/comp/lncs/authors.html) by May 2, to ensure prompt printing of the proceedings. Submission and email correspondence to mpool02(a)multiparadigm.org. ORGANIZATION This workshop is a joint organization by the John von Neumann Institute for Computing (NIC) at Research Centre Juelich, Los Alamos National Laboratory, and the Georgia Institute of Technology. PROGRAM COMMITTEE Gerald Baumgartner (Ohio State University, Ohio, USA) Kei Davis (Los Alamos National Laboratory, New Mexico, USA) Jaakko Jaervi (Indiana University, Indiana, USA) Peter Van Roy (Universite catholique de Louvain, Belgium) Yannis Smaragdakis (Georgia Institute of Technology, Georgia, USA) Joerg Striegnitz (John von Neumann Institute for Computing, Germany) FURTHER INFORMATION MPOOL'2002: http://www.multiparadigm.org/mpool2002 ECOOP'2002: http://ecoop2002.lcc.uma.es

1 0

first-class modules
by Feuer 26 Mar '02

26 Mar '02

A number of people have discussed the use of implicit parameters to mimic global variables in Haskell. I am wondering if any have done the same for a first-class module system such as that proposed by Shields and Jones. It seems to make a tremendous amount of sense to do it that way: 1. semi-constant values: Things that are calculated or input at the beginning of the program could be handled by Main.main, which would pass the results to the Second module, whose main function it could then call. This seems much more natural than the implicit parameter approach for this purpose. 2. others: whenever a group of functions are likely to share a particular argument, they can be grouped in a module for greater convenience. For example, a library of mathematical functions that should all share a certain precision indicator could be grouped in a module: the user of the module could instantiate it once with the right precision and then use all the functions at that precision. David Feuer (please reply to dfeuer(a)cs.brown.edu)

3 2