- Haskell-Cafe - Haskell.org

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

help me!!!!
by Garry Hadiwibowo 30 Aug '01

30 Aug '01

3 3

RE: Numeric literals
by Simon Marlow 30 Aug '01

30 Aug '01

> On Tue, 28 Aug 2001, Simon Marlow wrote: > (snip) > > In GHC, you can do this: > > > > import Exception > > > > do result <- catch (evaluate (read "foo" :: Int)) > > (\error -> ... ) > (snip) > > I do like that. Is it likely to become standard someday, do you think? > Errors like this should certainly be catchable in such a way; > I was sad > when I was first looking into this and found that 'catch' seemed to be > inextricably linked to IO. Well, we'd like it to become standard :-) The exception stuff is really very easy to implement - you just use the standard stack-unwinding implementation of throw, and catch has to push a special stack frame. GHC's asynchronous exceptions are slightly harder, but I don't think it was more than a day or two's work. As a bonus you get to use a more efficient implementation of the IO monad, because it doesn't have to deal explicitly with exceptions. And then IO becomes a straightforward instance of ST. I guess I should also document the Exception extension in a self contained way, similar to the way the FFI extension is documented. Cheers, Simon

2 1

RE: Numeric literals
by Simon Marlow 30 Aug '01

30 Aug '01

> I also haven't yet worked out how to tell if a string is "read"able or > not, yet - if (read "45")::Integer or whatever gives an error > (e.g. if I'd > put "af" instead of "45"), it seems to be pretty uncatchable, > which is a > pain. How do I tell if an instance of reading will work, or > catch that it > didn't? In GHC, you can do this: import Exception do result <- catch (evaluate (read "foo" :: Int)) (\error -> ... ) but unfortunately read doesn't raise a useful exception (just error "Prelude.read: no parse"), so you can't filter it very easily. However I don't think that read is likely to raise any other exceptions. Cheers, Simon

3 2

RE: Numeric literals
by Simon Marlow 30 Aug '01

30 Aug '01

> Today's other question has to do with numeric literals. How do I write > literals for interesting IEEE values, e.g. > > Prelude> x > Infinity > Prelude> :type x > Double > Prelude> (read "Infinity") :: Double > *** Exception: Ratio.%: zero denominator > Prelude> This looks like a bug in GHC, which has now been fixed for version 5.02. Note that Haskell leaves the behaviour of these exceptional conditions undefined. Hugs for example will give a program error on divide by zero, and NHC has even more interesting behaviour: Prelude> 1/0 :: Float 34.02823669209384634633746074317682114560000000 Cheers, Simon

4 4

Re: Easy syntax question
by Mike Gunter 30 Aug '01

30 Aug '01

Or, if you need several cases, you can use something like: > funcGuard n | n `elem` [2,5,9] = 5 > | n `elem` [4,18] = 1 > | otherwise = 7 or, if you want an expression: > caseGuard n = case undefined of > _ | n `elem` [2,5,9] -> 5 > | n `elem` [4,18] -> 1 > | otherwise -> 7 mike Dean Herington <heringto(a)cs.unc.edu> writes: > Mark Carroll wrote: > > > I can write a function x :: Integer -> Integer that returns 5 if I give it > > 2, 5 or 9, or 7 otherwise. Say, > > > > x 2 = 5 > > x 5 = 5 > > x 9 = 5 > > x _ = 7 > > > > Generally, this is a question about where multiple cases lead to the same > > thing, maybe even in the middle of a function. (Like C's "case 1: case 2: > > case 3: foo; break;".) > > > > Does it get any better than this, though? I can't convince 'case' to do > > something like, > > > > case n of > > 2,5,9 -> 5 > > otherwise -> 7 > > > > Am I missing some syntax somewhere? I'm lost in the grammar in the Haskell > > report. > > > > -- Mark > > I would write: > > > if elem n [2,5,9] then 5 else 7 > > Dean

2 1

RE: Prefix negation
by Simon Marlow 29 Aug '01

29 Aug '01

> (Moved to haskell-cafe) > > Syntacticly, -x parses as 0-x. That is, there is only one - > operator and the "0" is filled in when it is encountered in a unary > position. Thus > > -3 ^ 2 translates to 0 - 3 ^ 2 Slight correction: '-e' is in fact replaced by 'negate e', after fixity resolution, where negate is a method in class Num. The default definition of negate is 'negate x = 0 - x', but there's no requirement that it means this in general. The above example parses as '-(3^2)' because ^ has a higher precedence than unary '-' (8 vs. 7). Translation turns the expression into 'negate (3^2)'. Someone else will have to comment on *why* the precedences are ordered this way, though. Cheers, Simon

2 1

Re: Prefix negation
by John Peterson 29 Aug '01

29 Aug '01

(Moved to haskell-cafe) Syntacticly, -x parses as 0-x. That is, there is only one - operator and the "0" is filled in when it is encountered in a unary position. Thus -3 ^ 2 translates to 0 - 3 ^ 2 There were many arguments on either side of this debate but I would have to dig deep into the archives to remember what they were. This is certainly a potential source of confusion! Anyway, experienced Haskellers always add parens around unary minus to avoid any ambiguity: (-3) ^ 2 John

2 1

a shorter phrase than "algebraic data type"
by Richard 29 Aug '01

29 Aug '01

does anyone have a shorter name for a "algebraic data type" --the thing that is created by the declaration beginning with the keyword "data"? "ADT" is already in use, meaning "abstract data type", in many textbooks like Essentials of Programming Languages. the best I could come up with is "SPT", short for "sum-of-products" type.

5 5

Re: ~ symbol
by Marcin 'Qrczak' Kowalczyk 29 Aug '01

29 Aug '01

Wed, 29 Aug 2001 12:06:37 +0300, Cagdas Ozgenc <co19(a)cornell.edu> pisze: > What is the use of ~ symbol in Haskell? For example in prelude > function unzip > > unzip = foldr (\(a,b) ~(as,bs) -> (a:as, b:bs)) ([], []) When a lambda abstraction is applied to arguments, objects passed as arguments are matched against patterns in the lambda. The pattern (a,b) causes evaluation of the top-level constructor of the matched value (the constructor must be (,) because of the type) and binds a and b to arguments of the constructor. Matching against the pattern ~(as,bs) succeeds without evaluation of the value. Names as and bs are bound to expressions which cause evaluation of the top-level constructor of the matched value and select appropriate components. So with \(a,b) the constructor is evaluated when the lambda is applied, before evaluation of its body. With \ ~(as,bs) it's evaluated when as or bs are evaluated inside the body. The effect is that laziness is improved: parts of the result are available before the input is consumed. The first argument of foldr should better be lazy in its second argument, so foldr can return something without waiting for the result of the recursive call on the tail of the list being traversed. With this definition unzip ((foo, bar):whatever) can return (foo:whatever', bar:whatever'') where evaluation of whatever' and whatever'' causes further traversal of whatever. It doesn't wait until 'unzip whatever' returns the pair but it returns an object whose components cause evaluation of 'unzip whatever'. There is no ~ on (a,b). This implies that unzip (spam:eggs) does evaluate spam to obtain a pair before returning anything. It delays only the recursive call of 'unzip eggs'. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1