August 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

Haskell report (August release)
by Simon Peyton-Jones 27 Sep '01

27 Sep '01

Gentle colleages As ever, the emission of a draft of the Revised Haskell 98 Report elicited a flood of new corrections. It's quite uncanny. Anyway, I now publish another draft (the August release). http://research.microsoft.com/~simonpj/haskell98-revised Please check it out. My plan is that if I hear nothing for a month, I'll freeze it. Otherwise I'll iterate. Main changes this month: * stuff to do with lexical syntax (Ch 2) * stuff to do with modules (Ch 5) * many minor wording improvements As ever, the bugs list says exactly what has changed (grep for "Aug 2001". Happy days, Simon

2 1

Re: H98: unicode
by Marcin 'Qrczak' Kowalczyk 31 Aug '01

31 Aug '01

Fri, 31 Aug 2001 11:54:29 +0100, Ross Paterson <ross(a)soi.city.ac.uk> pisze: > uniDigit -> any Unicode decimal digit > > One could mix digits from different languages, but the meaning would > be clear (the Unicode tables include the digit value). An alternative > would be to drop uniDigit; octal or hexadecimal numerals are already > limited to ASCII. Some people on linux-utf8 list were *strongly* in favor of not limiting digits to ASCII (in the context of Char.isDigit and Char.digitToInt). Especially as it seems that all characters marked as decimal digits are used in the same way and order as European digits for forming numbers. Unfortunately a predicate for ASCII digits is needed when the syntax we are going to recognize is specified as using only ASCII digits. One can always write c >= '0' && c <= '9', but named predicates like isDigit are handy as arguments to span, dropWhile etc. Perhaps Haskell 2002 should have both; it's not clear how they should be named. The above paragraph this is irrelevant for Haskell 98 clarification of course. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

type signatures with existentially quantified data constructors
by Avi Pfeffer 31 Aug '01

31 Aug '01

Hi all, I'm trying to write an interpreter for a language embedded in Haskell, that "inherits" Haskell types and values. So I create a type Expr a, to represent expressions of type a, and an evaluator that takes an Expr a and produces an a. (To keep things simple, let's assume there are no variables.) I start with data Expr a = Haskell a | If (Expr Bool) (Expr a) (Expr a) eval :: Expr a -> a eval (Haskell x) = x eval (If x y z) = if eval x then eval y else eval z Next, applications. To correctly type an application expression, I need to introduce an existentially quantified type variable: data Expr a = ... | forall b . Appl (Expr (b->a)) (Expr a) eval (Appl x y) = (eval x) (eval y) Works fine. Things get tricky when I try to add pairs. In order to type a pair expression, I find I need to create a Pair class and introduce a class constraint: class Pair a b c | a -> b c, b c -> a instance Pair (b,c) b c data Expr a = ... | forall b c . Pair a b c => MkPair (Expr b) (Expr c) This seems to express the right type relationships. But now I find I can't write eval for MkPair: eval (MkPair x y) = (eval x, eval y) GHC produces the error message Cannot unify the type-signature variable `a' with the type `(t, t1)' Expected type: a Inferred type: (t, t1) in the definition of function `eval': (eval x, eval y) I have tried various ways of adding type annotations, but I can't seem to make it work. The problem seems to be the combination of class constraint with existential variables. How can I tell the compiler that it should in fact unify a with (t,t1) here? Or am I misunderstanding something, and there is a reason it can't? Perhaps there's a way of typing MkPair without introducing the Pair class? Or is there a completely different approach to my problem? All suggestions welcome. --Avi

4 3

H98: unicode
by Simon Peyton-Jones 31 Aug '01

31 Aug '01

Folks, Thanks to Mark and Marcin for reminding me of one other H98 point. The proposal is: In the lexical syntax for 'symbol', replace symbol -> ascSymbol | uniSymbol by symbol -> ascSymbol | uniSymbol_<special | _ | : | " | '> The reasoning is in the message below. Marcin agreed that the change is correct. I'll adopt it unless anyone yells. Simon -----Original Message----- From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of Mark P Jones Sent: 23 July 2001 19:24 To: haskell(a)haskell.org Cc: Marcin 'Qrczak' Kowalczyk; Mark P. Jones Subject: Picky details about Unicode (was RE: Haskell 98 Report possible errors, part one) | 2.2. Identifiers can use small and large Unicode letters ... If we're picking on the report's handling of Unicode, here's another minor quibble to add to the list. In describing the lexical syntax of operator symbols, the report uses: varsym -> (symbol {symbol | :})_<reservedop> symbol -> ascSymbol | uniSymbol uniSymbol -> any Unicode symbol or punctuation The last line seems to include more characters than I'd expect. Specifically: ()[]{} are punctuation (Unicode type Pe, Ps) ` is a symbol, modifier (Unicode type Sk) "':;, are punctuation, other (Unicode type Po) _ is punctuation, connector (Unicode type Pc) And, so, if I read the report correctly, I should be able to define :-) as a consym and `div`, [], and "hello" as varsyms! (Not to mention some altogether more bizarre choices!) I guess the intention here is that: symbol -> ascSymbol | uniSymbol_<special | _ | : | " | '> In fact, since all the characters in ascSymbol are either punctuation or symbols in Unicode, the inclusion of ascSymbol is redundant, and a better specification might be: symbol -> uniSymbol_<special | _ | : | " | '> All the best, Mark P.S. A caveat: I'm not a Unicode expert! Perhaps Marcin can advise ... _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

2 1

Job advert: Compiler designer/architect
by Benedict R. Gaster 31 Aug '01

31 Aug '01

The following job advert has been sent to both the GCC and Pro64 mailing lists and I thought maybe of interest to people on this mailing list. SuperH are not looking for Haskell developers but rather are keen to recruit people with experience in language design and implementation. (The Pro64 is a highly optimizing compiler initially designed by SGI and targeted for the MIPS and IA64 architectures. Recently the Pro64 was made open source and SuperH is in the process of porting this technology to a selection of their current and future microprocessors.) Advert: SuperH, Inc is a new company formed by STMicroelectronics and Hitachi in order to market and develop the SuperH series of microprocessors as an independent company. The SuperH series will be offered as licensable cores for synthesis into embedded applications. See www.superh.com for more information. SuperH is headquartered in San Jose CA with R&D centers in Bristol UK and Tokyo Japan. SuperH will be developing software systems based on Open Source tecnology, including Gnu tools (i.e., gcc, gdb, etc.) and Pro64, and is looking for a range of engineers who have interests and/or experience in the following skill areas: o Code generation and optimization. Software pipelining, register allocation. Specific experience with gcc or Pro64 would be an advantage. o JIT compilation and dynamic optimization. o Linux development. o Architecture design. o Benchmarking. o Debugging technologies including gdb. SuperH will be developing products based on Gnu and Linux technogy as well as carrying out research into new innovative architectures and advanced compiler design, including the Pro64 and dynamic optimization. The main location for these posts is Bristol, UK. SuperH will be offering a comprehensive benefits package as well as an emloyee stock option scheme and bonus schemes. Job Title: Compiler designer/architect. Qualifications. Good knowledge of compiler optimizations, experience with Gnu or Pro64 would be useful. In depth knowledge of C & C++. Java an advantage. Experience in embedded system design. Please send CVs to: benedict.gaster(a)st.com Benedict R. Gaster SuperH, Inc.

1 0

Re: Chaitin's (try)
by Bill Halchin 30 Aug '01

30 Aug '01

1 0

Chaitin's (try)
by Carl McTague 30 Aug '01

30 Aug '01

Does anybody have an interest in something like Gregory Chaitin's function (try) from his custom lisp in Haskell? (Please see http://www.umcs.maine.edu/~chaitin/rov.html for more information.) It would be a function that attempts to evaluate its argument within a specified amount of cpu time, returning something like Maybe's Nothing (but perhaps more informative) in the case that time runs out, and something like Just, otherwise. Would that toy with referential transparency? Carl

2 1

Re: Modules (again)
by Marcin 'Qrczak' Kowalczyk 30 Aug '01

30 Aug '01

Thu, 30 Aug 2001 10:09:59 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > Am I the only one that thinks it's strange that > > module M ( module A ) where > import B as A > > exports the contents of module B? A isn't even a module! A is a name of a module as far as this module source is concerned. You can write A.whatever and names are qualified with module names, so A must be considered a module name... > The old definition claims that 'module M where' is the same as > 'module M (module M) where' which is a nice property. Perhaps we > can clarify the definition so that this is the case. Oops, it's indeed a problem. > One way to do this is to make 'module M' exports refer to the actual > module M, not including any modules renamed to M. I would definitely not do that. A renamed module should be consistently referred to by its new name. The only problem is whether 'module M where' is specified in terms of where definitions come from or in terms of source rewriting to 'module M (explicit export list) where'. I can't decide. What could be the purpose of renaming a module into the same name as the current module? What behavior would be more useful then? I think that both variants are logically explainable, so it should be decided on the basis of usefulness and expectability (is "expectability" an English word?). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0