September 2001 - Haskell

tuple component functions
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

S.D.Mechveliani writes: > As Haskell has the standard functions fst, snd to decompose (a,b), > maybe, it worths to provide also > tuple31, tuple31, tuple31, > ... > tuple51, tuple52, tuple53, tuple54, tuple55 > > for the tuples of n = 3,4,5 ? I've found some of these useful, except I named them differently: > fst3 :: (a,b,c) -> a > fst3 (x,_,_) = x > snd3 :: (a,b,c) -> b > snd3 (_,x,_) = x > thd3 :: (a,b,c) -> c > thd3 (_,_,x) = x .... never got around to quadruples etc. I also defined (some of these may be untested): > tripl :: a -> (a,a,a) > tripl x = (x,x,x) > curry3 :: ((a, b, c) -> d) -> a -> b -> c -> d > curry3 f x y z = f (x, y, z) > uncurry3 :: (a -> b -> c -> d) -> ((a, b, c) -> d) > uncurry3 f t = f (fst3 t) (snd3 t) (thd3 t) > applyTriple :: (a -> b, a -> c, a -> d) -> a -> (b,c,d) > applyTriple (f,g,h) x = (f x, g x, h x) > cross3 :: (a -> b, c -> d, e -> f) -> (a,c,e) -> (b,d,f) > cross3 (f,g,h) (x,y,z) = (f x, g y, h z) > mapTriple :: (a -> b) -> (a, a, a) -> (b, b, b) > mapTriple = cross3 . tripl > applyFst3 :: (a -> b) -> (a, c, d) -> (b, c, d) > applyFst3 f = applyTriple (f . fst3, snd3, thd3) > applySnd3 :: (a -> b) -> (c, a, d) -> (c, b, d) > applySnd3 f = applyTriple (fst3, f . snd3, thd3) > applyThd3 :: (a -> b) -> (c, d, a) -> (c, d, b) > applyThd3 f = applyTriple (fst3, snd3, f . thd3) > applyArgs3 :: (a -> b) -> (c -> d) -> (e -> f) -> (b -> d -> f -> g) -> (a -> c -> e -> g) > applyArgs3 af1 af2 af3 f = \x y z -> f (af1 x) (af2 y) (af3 z) > rotl :: (a -> b -> c -> d) -> (b -> c -> a -> d) > rotl f y z x = f x y z > rotr :: (a -> b -> c -> d) -> (c -> a -> b -> d) > rotr f z x y = f x y z > rotl4 :: (a -> b -> c -> d -> e) -> (b -> c -> d -> a -> e) > rotl4 f y z t x = f x y z t > rotr4 :: (a -> b -> c -> d -> e) -> (d -> a -> b -> c -> e) > rotr4 f t x y z = f x y z t Some more combinators (only for pairs so far): > twin :: a -> (a,a) > twin x = (x,x) > swap :: (a,b) -> (b,a) > swap (x,y) = (y,x) -- apply a pair of functions to one argument > applyPair :: (a -> b, a -> c) -> a -> (b, c) > applyPair (f, g) x = (f x, g x) -- apply a pair of functions to a pair > cross :: (a -> b, c -> d) -> (a, c) -> (b, d) > cross (f, g) = applyPair (f . fst, g . snd) -- compose a pair of functions onto one function > dotPair :: (a -> b, a -> c) -> (d -> a) -> (d -> b, d -> c) > dotPair (f, g) h = (f . h, g . h) -- compose a pair of functions onto a pair of functions > dotCross :: (a -> b, c -> d) -> (e -> a, f -> c) -> (e -> b, f -> d) > dotCross (f, g) (h, i) = (f . h, g . i) > mapPair :: (a -> b) -> (a, a) -> (b, b) > mapPair = cross . twin > applyFst :: (a -> b) -> (a, c) -> (b, c) > applyFst f = applyPair (f . fst, snd) > applySnd :: (a -> b) -> (c, a) -> (c, b) > applySnd f = applyPair (fst, f . snd) > applyArgs :: (a -> b) -> (c -> d) -> (b -> d -> e) -> (a -> c -> e) > applyArgs af1 af2 f = \x y -> f (af1 x) (af2 y) > betweenFst :: (a -> b -> c) -> (a, d) -> (b, e) -> c > betweenFst = applyArgs fst fst > betweenSnd :: (a -> b -> c) -> (d, a) -> (e, b) -> c > betweenSnd = applyArgs snd snd I find these combinators useful, and probably other people have their own versions - it would be nice to get them standardised, so we all speak the same language. By standardised, I mean a prominent version that will be adopted by users, not necessarily a committee process. Tim

3 2

ICFP programming contest
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

Michael Hobbs writes: > Just took a look at the results for the ICFP contest. Am I correct in > assuming that "LA" stands for Lennart Augustsson and that "Si^3" stands > for Simon Marlow, Simon Peyton-Jones, Sigbjorn Finne? Is there a URL for the results ? Tim

2 1

Re: Student Programming Projects
by Yoann Padioleau 16 Nov '01

16 Nov '01

Johannes Waldmann <joe(a)isun.informatik.uni-leipzig.de> writes: > > Next Semester, I am supposed to teach a short course in Haskell. > > Can anyone recommend interesting programming projects which can > > be completed in about a month? Thank you very much. > > apart from "pure" programming exercise > (see Haskell textbooks http://haskell.org/bookshelf/) > here are a few suggestions in the area of experimental mathematics. > also, check with your introductory discrete mathematics course (or equivalent). > a lot of combinatorial problems on finite structures > can be illustrated by finding (counter-)examples by computer. > > > say Ramsey colorings, Monochromatic arithmetic subsequences > (van der Waerden's theorem), words avoiding patterns, and so on. > http://www-igm.univ-mlv.fr/~berstel/Lothaire/ChapitresACW/C3.ps > > next, perhaps some game theory? > nim (and variants), other take-and-break games (octal games). > you can safely ignore all of the Sprague-Grundy theory, > and just define the game, and ask for some method > to determine quickly who wins. > > or graph theory: finding hamiltonian paths > (knights tours on a x b chessboards, for instance) > > if the students alreay took some computability theory, > then a nice topic is Posts Correspondence Problem, see > http://www.cs.ualberta.ca/~zhao/PCP/intro.htm > http://www.informatik.uni-leipzig.de/~pcp/pcpcontest_en.html > > also string rewriting: finding/avoiding loops. > this (open!) problem is easily stated: http://www.lri.fr/~rtaloop/95.html Wow, what some nice exercise, are you really serious ? do you think computer science student enjoy that kind of programs (except for the AI-related stuff)? why not make them programming something they would like to use !! why not a tetris/pong/reversi/any_video_game, see for example the book from Paul hudak (multimedia ... in haskell). this man understand what makes student happy : graphism,video games,compiler,operating systems, AI games and not this shit of mathematics/computer science theorist problem. This is the kind of things that make student think that functionnal programming is for doing useless things, and that C is cool cos you can do graphism, program your own operating systems, ... ICFP 2000 ask for an interesting problem: a raytracer, a thing that many student like cos you can then play with it and describe your own scene, and that contest show that ocaml/haskell were really cool for doing graphism-related work. > > > hope this helps. I'm happy to provide more detail. -- Yoann Padioleau, INSA de Rennes, France, http://www.irisa.fr/prive/padiolea Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____**

2 1

Re: Unicode support
by Marcin 'Qrczak' Kowalczyk 24 Oct '01

24 Oct '01

30 Sep 2001 22:28:52 +0900, Jens Petersen <petersen(a)redhat.com> pisze: > 16 bits is enough to describe the Basic Multilingual Plane > and I think 24 bits all the currently defined extended > planes. So I guess the report just refers to the BMP. In early days the Unicode Consortium was doing everything to confuse peoble about whether Unicode fits into 16 bits. It used to push the view that it's based on 16-bit units, and that pairs of units from the range U+D800..DFFF (called surrogates) can encode a million of extra characters (none of which had a more specific meaning defined at that time). I was told on the Unicode list that it was done because for some people it would be hard to accept an encoding which requires *more* than twice as much storage as 8-bit charsets. 16 bits is "only" twice as much. Unfortunately some companies, like Microsoft and Oracle, believed the "lie of Unicode marketing" and adopted the 16-bit view as the basic internal and external format, ignoring the issue of surrogates. Some time ago the Unicode Consortium slowly began switching to the point of view that abstract characters are denoted by numbers in the range U+0000..10FFFF. Storing them in 16-bit units by expressing characters below U+FFFF directly and representing others as pairs of surrogates is just a way to serialize Unicode to streams of bytes (or 16-bit words), called UTF-16. AFAIK UTF-8 was first present in ISO-10646-1. The ISO standard, although sharing actual assignments of characters to numbers with Unicode, from the beginning viewed character codes as 31-bit numbers, which can be serialized for transmission using for example UTF-8 or UTF-16. Unicode adopted UTF-8 by cutting it at the point of U+10FFFF. It also invented UTF-32 which means to just store characters in 32-bit words (endianness issues are analogous to UTF-16), but is explicitly restricted to characters below U+10FFFF, to avoid confusion with unrestricted 31-bit codes of ISO-10646-1. So now UTF-8, UTF-16 and UTF-32 are treated in parallel by Unicode. The ISO standard is going to match this and limit itself to U+10FFFF too, which in theory should end the problem about the number of characters in these standards. Unicode had to do something with this because it finally began adding characters above U+FFFF, and it would really make no sense to treat UTF-16 as the fundamental view, saying that some codes really don't represent characters but must be used in pairs, since character properties are defined in terms of real characters, not components of surrogate pairs individually. Surrogates are just a hole in the middle of the first 64k of characters, because UTF-16 can't encode them insolated. Unfortunately the 16-bit view is still widespread and there is much confusion. Companies invested money in the 16-bit Unicode and they can't simply replace it with something entirely different, so they actually begin implementing UTF-16. In practice support for surrogates could be almost non-existant in the past, but now there are actual characters allocated there, so it must be done, despite the pain of using a variable-length encoding. There are cases like Oracle which ignored surrogates and misimplemented UTF-8 by treating surrogates like other characters below U+FFFF, yet calling it UTF-8. Now instead of fixing their mistake they added the real UTF-8 under a strange name AL24UTFFSS (I'm not sure if they finally fixed the names) and are trying to push their old version as an official alternative to UTF-8. There is a very strong opposition, but they are still trying. IMHO it would have been better to not invent UTF-16 at all and use UTF-8 in parallel with UTF-32. But Unicode used to promote UTF-16 as the real Unicode, and now it causes so many threads on Unicode list to clear the confusion about the nature of characters above U+FFFF. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

6 6

RE: GUI Library Task Force
by Simon Peyton-Jones 12 Oct '01

12 Oct '01

| *** The GUI Library Task Force Strategy Proposal *** Great! | * Start from the API of GTK+ as a base line: That's fine by me. But can I suggest that the task force be sure to read the details of the Clean GUI library design. Peter Aachten (while visiting Cambridge) rendered a good chunk of it into Haskell, using MVars exactly as you describe. (The type structure became a good deal simpler than the Clean library when using MVars instead of state-passing.) The reason I think its worth a careful look is that the Clean folk have developed their library interface over a long period, and have a lot of experience in its use. It is not specific to any one platform or toolkit, nor does it attempt to implement everything, so its general goals fit with the ones you describe. I wondered whether its design would not "fit" Haskell because of the different approaches to I/O, but that turned out not to be an issue. There's a paper that introduces the Haskell rendering of the Clean library at http://research.microsoft.com/~simonpj/papers/haskellobjectio.htm Simon

16 23

RFC: GUI Library Task Force
by Manuel M. T. Chakravarty 10 Oct '01

10 Oct '01

The following is a summary of a discussion about a strategy to develop a standard GUI library for Haskell. The discussion was initiated by Simon Peyton Jones and involved Koen Claessen, George Russell, and me. The next step in our plan is the creation of a public mailing list (we propose, "gui(a)haskell.org") that can be used to develop an API definition according to the outlined strategy. Anybody who is interested in participating in this discussion is very welcome to join this mailing list, once it is set up. I expect that there will be feedback here on the main list to the appended proposal. As soon as this becomes technical, I propose to take it off the main list to the new GUI mailing list. Cheers, Manuel -=- *** The GUI Library Task Force Strategy Proposal *** Goals ~~~~~ * Development of a GUI library API for Haskell that is portable across Haskell systems and operating/windowing systems * The library focuses on graphical *user interfaces* (ie, buttons, menus, scrollbars, selection lists, etc) as opposed to drawing and animation routines. * Verification of the design by at least one implementation of a library that exports the GUI API * Minimal use of features that are not included in Haskell 98 (in fact, we currently believe that we can keep the API completely free of any non-H98 features; however, application programs that use the API will need some non-H98 functionality) * While we do not require support of concurrency by Haskell systems implementing the API, the use and behaviour of the API must be well-defined on systems that do support concurrency * Core library: - Due to the complexity of modern GUIs, we cannot hope to cover a fully-fledged GUI library in reasonable time and with reasonably effort; thus, we concentrate on a core library (what exactly constitutes the core remains to be defined) - The core library needs to provide a migration path to at least one fully-fledged GUI library * Openness for tools support; for example, it should be possible to support graphical interface builders (such tools are not part of the API, but we need to ensure that we do not seriously complicate the construction of such tools) Non-goals ~~~~~~~~~ * We will not design a fully-fledged GUI library from scratch: Just as a reference point, GTK+ has 93 different widgets (and that's just the base set) and probably over 1000 functions. Moreover, there are surely 100-200 different types of callbacks. I am pretty sure that Qt, the Win32 GUI API, and the MacOS are of similar size. This is well beyond the scope of what we can achieve with our resources. * We will not design a "purely functional GUI": - The pragmatic reason: H98 textual I/O works via the IO monad; so what's the problem with having graphical I/O in the IO monad? - The state-of-the-art reason: There doesn't seem to be a clear favourite in the proposals for purely functional GUIs. Moreover, it has yet to be shown that any of the proposals scales to real-life GUI applications. We do not intend to solve sophisticated research problems here. We want to get a workable solution quickly. Always remember: Worse is Better <http://www.jwz.org/doc/worse-is-better.html>. The Plan ~~~~~~~~ * Handling of state altered by both the application and by GUI widgets: - The GUI API will be kept free of any commitment as to which mechanism to use here. - The simplest solution, for a single-threaded application, is to use `IORef's and, for a multi-threaded application, is to use `MVar's (or primitives that are defined in terms of these). - Advantages of this design: + Doesn't require Haskell systems that want to provide the GUI library to also support concurrency + Doesn't preclude the use concurrency (where it is available) + `IORef's are very easy to implement if any system doesn't have them yet + More sophisticated approaches (that often require language extensions or are still experimental) can be implemented on top of this basic API - eg, FranTk, Yahu, Fruit, iHaskell, etc. - It is possible to write reasonably nice Haskell programs in this approach; for an example, see http://www.cse.unsw.edu.au/~chak/haskell/gtk/BoolEd.html (Note how many of the functions need to be in the IO monad anyway, because they need to perform file I/O.) * Start from the API of GTK+ as a base line: - This is an API that has a proven track record of being suitable for small, medium, and large-scale applications - The API does not overly rely on object-oriented language features - A large body of free documentation exists for the API, which can be adapted to our purpose - A working Haskell binding exists that can be extended to provide a first implementation of the Haskell GUI API - A clear migration path exists for applications that need more sophisticated features than the core API provided by the Haskell GUI - GTK+ itself is already reasonably platform independent * Ensure platform independence: - The Haskell GUI will be restricted to GTK+ features that can be implemented on other major platforms with reasonable effort * Haskell-ise the API: - C-ish functionality will be cut out - Full use will be made of Haskell's type system and, in particular, type classes * Convenience libraries - The API will include a set of convenience libraries on top of the basic API (eg, by providing layout combinators)

5 6

Re: Unicode support
by Ashley Yakeley 09 Oct '01

09 Oct '01

At 2001-09-30 07:29, Marcin 'Qrczak' Kowalczyk wrote: >Some time ago the Unicode Consortium slowly began switching to the >point of view that abstract characters are denoted by numbers in the >range U+0000..10FFFF. It's worth mentioning that these are 'codepoints', not 'characters'. Sometimes a character will be made up of two codepoints, for instance an 'a' with a dot above is a single character that can be made from the codepoints LATIN SMALL LETTER A and COMBINING DOT ABOVE. Perhaps this makes the UTF-16 'surrogate' problem a bit less serious, since there never was a one-to-one correspondence between any kind of n-bit unit and displayed characters. -- Ashley Yakeley, Seattle WA

2 1

Unicode support
by Colin Paul Adams 01 Oct '01

01 Oct '01

I have just been reading through the Haskell report to refresh my memory of the language. I was surprised to see this: The character type Char is an enumeration and consists of 16 bit values, conforming to the Unicode standard [10]. Unicode uses 24-bit values to identify characters. -- Colin Paul Adams Preston Lancashire

3 4

Re: Haskell <-> Java and floats
by Ashley Yakeley 30 Sep '01

30 Sep '01

At 2001-09-30 00:37, pachinko(a)magicaldesk.com wrote: >Has anyone ever tried to pass/receive a float to/from a Java app? If so, >how did you manage it? Using JNI through Haskell's FFI. Both define their floats and doubles as C 'float' and 'double', so I don't bother with any conversion. I haven't tested it yet, though. -- Ashley Yakeley, Seattle WA

1 0

Layout rule
by Ian Lynagh 30 Sep '01

30 Sep '01

Hi all The report says "The layout rule matches only those open braces that it has inserted" in the lexical structure section. However, in the syntax section function L starts L (t:ts) (m:ms) = } : (L (t:ts) ms) if parse-error(t) (Note 1) which AFAICT will implicitly close an explicit open brace. Testing with "foo = let { x = 5 in x" shows hugs, ghc and nhc98 all seem to agree with me. L (t:ts) (m:ms) = } : (L (t:ts) ms) if m /= 0 && parse-error(t) (Note 1) Along similar lines, I think writing the last two lines as L [] [0] = [] L [] (m:ms) = } : L [] ms if m /=0 (Note 5) would be clearer. In fact as the preeceding text says 'and "" for the empty stream' I think it may be written correctly but have gotten lost in the conversion from whatever it is really written in. Thanks Ian

1 0