- Haskell - 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

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

RE: Modules (again)
by Simon Marlow 30 Aug '01

30 Aug '01

> Section 5.2 (Export lists) doesn't anticipate this question; note the > separation between items (5) and (6), whose wording I reproduce below. > > Thus provoked, I have come up with another formulation that simplifies > the specification, and evades both this problem and others. > Here it is: > > Replace (5) and (6) by: > > (5') The form 'module M' abbreviates the set of all entities > whose unqualified name, 'e', is in scope, and for which > the qualified name 'M.e' is also in scope. This set may > be empty. > > It is an error to use module M in an export list unless M is > the module bearing the export list, or M is imported by at > least one import declaration (qualified or unqualified). 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! 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. One way to do this is to make 'module M' exports refer to the actual module M, not including any modules renamed to M. Since module names are unique, this is a much simpler formulation and doesn't end up exporting entities from several different modules. I suggest just changing the phrase "or `import A as M [impspec]'" to "or `import M as A [impspec]'" in point (5). Note that this change is slightly strange in a different way - exporting 'module M' doesn't necessarily export the entities which can be referred to by 'M.foo'. Anyway, I thought I'd throw this out as an alternative. Cheers, Simon

1 0

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

30 Aug '01

Thu, 30 Aug 2001 00:56:25 -0700, Simon Peyton-Jones <simonpj(a)microsoft.com> pisze: > As you gather your wits for ICFP, you may like to consider the following > nice point (thanks to the OGI folk) in the Haskell 98 Report. Is > the following legal? And if so, what is exported? > > | module M(module M) where > | import A as M Legal. Exported is everything defined in this module and everything exported from A. Unless there are name conflicts, when it's an error. Now let's see if it agrees with your proposal: > The second paragraph is unchanged. The first paragraph encapsulates > rather neatly what we want. It answers questions like the one I opened > with (answer: all local defns and everything imported from A is > exported). Yes! I like your formulation. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Prefix negation
by Marcin 'Qrczak' Kowalczyk 30 Aug '01

30 Aug '01

Wed, 29 Aug 2001 16:34:52 +0200, Rijk-Jan van Haaften <rjchaaft(a)cs.uu.nl> pisze: > -3 ^ 2 = -9 > > In most programming languages as well as in mathematics > it is quite unusual to have infix operators with a higher > priority than prefix operators. In mathematics the prefix negation is handled like in Haskell: 2 -3 = -9 I agree that many languages got it wrong :-) -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

Modules (again)
by Simon Peyton-Jones 30 Aug '01

30 Aug '01

Folks, As you gather your wits for ICFP, you may like to consider the following nice point (thanks to the OGI folk) in the Haskell 98 Report. Is the following legal? And if so, what is exported? | module M(module M) where | import A as M Section 5.2 (Export lists) doesn't anticipate this question; note the separation between items (5) and (6), whose wording I reproduce below. Thus provoked, I have come up with another formulation that simplifies the specification, and evades both this problem and others. Here it is: Replace (5) and (6) by: (5') The form 'module M' abbreviates the set of all entities whose unqualified name, 'e', is in scope, and for which the qualified name 'M.e' is also in scope. This set may be empty. It is an error to use module M in an export list unless M is the module bearing the export list, or M is imported by at least one import declaration (qualified or unqualified). The second paragraph is unchanged. The first paragraph encapsulates rather neatly what we want. It answers questions like the one I opened with (answer: all local defns and everything imported from A is exported). Comments? Simon ========================= The current wording: (5) The form `module M' abbreviates the set of all entities whose names are brought into scope by one or more unqualified import declarations of the form `import M [impspec]' or `import A as M [impspec]'. This set may be empty. For example: module Queue( module Stack, enqueue, dequeue ) where import Stack ... Here the module Queue uses the module name Stack in its export list to abbreviate all the entities imported from Stack. (6) Additionally, a module can name its own local definitions in its export list using its name in the `module m' syntax. For example: module Mod1(module Mod1, module Mod2) where import Mod2 import Mod3 Here module Mod1 exports all local definitions as well as those imported from Mod2 but not those imported from Mod3. Note that module M where is the same as using module M(module M) where It is an error to use module M in an export list unless M is the module bearing the export list, or M is imported by at least one import declaration (qualified or unqualified).

1 0

Hiding non-existent entities
by Simon Marlow 30 Aug '01

30 Aug '01

The Haskell 98 errata page currently contains this item related to a hiding clause on an import declaration which refers to a non-existent entity: [Aug 2001] Page 66, Section 5.3, Import Declarations, numbered item 2. Add "It is not an error to hide an entity that is not, in fact, exported by the imported module, although compilers are encouraged to flag a warning in this case." (This is different from what I proposed by email, which made this case an error, but it allow a bit more flexibility as modules change.) IMO allowing a hiding clause to refer to a non-existent entity is a bit odd. Haskell doesn't have any other features like this: it's always an error to refer to an entity that isn't defined anywhere, even if the reference is otherwise harmless. Does anyone else have any opinions on this? Cheers, Simon

2 1

Efficient way to perform independent processing of list from IO?
by mctague＠one.net 29 Aug '01

29 Aug '01

Hi, I've written a program that reads in a list of things from stdin and performs an independent computation on each one and prints the results as a list back to stdout. I've implemented it as in the following simple example: import IO getIntsFromHandle :: Handle -> IO [Int] getIntsFromHandle handle = do string<-hGetContents handle return (read string) writeToHandle :: (Show a)=> a -> Handle -> IO () writeToHandle x handle = do hPutStr handle (show x) hClose handle main :: IO () main = do ints<-getIntsFromHandle stdin writeToHandle (map (^2) ints) stdout but with this approach, all the data are read before they are written, or at least so it seems from memory utilization and by using the keyboard interactively to type into stdin. Is there a more memory-efficient approach, perhaps exploiting laziness somehow? Thanks, Carl

2 1