- Haskell-Cafe - Haskell.org

Silly I/O question
by John Goerzen 29 Sep '04

29 Sep '04

I'm trying to write a program that will copy an arbitrarily large text file to a destination, and duplicate it 100 times. Thus: ./myprog < Input > Output would be the same as running: cat Input > Output # once cat Input >> Output # 99 times My first attempt was this: import IO main = disp 100 disp 0 = return () disp n = do c <- getContents putStr c hSeek stdin AbsoluteSeek 0 disp (n-1) That failed, though, because getContents closes the file after it's been completely read (ugh -- why?). So then I tried to work on various options around hGetLine and hPutStrLn. But I couldn't figure out a way to make this either properly tail-recursive while handling the exception, or to avoid polling for EOF each time through the function. I also don't want to store the entire file in memory -- the idea is to seek back to the beginning for each iteration. I'm assuming that stdin is a seekable fd. I checked the wiki for a pattern here but didn't see any. Suggestions?

5 7

GHC and OS X (10.4)
by Tom Davie 29 Sep '04

29 Sep '04

Hi, I've been attempting to use GHC on a beta copy of Mac OS X 10.4, I've been attmepting to use the panther version of the install package, but have hit a problem with tinkering with it - I get the following error when I attempt to run ghc: Verenia:~/Documents/Development/XBridgeAI tatd100$ ghc dyld: Library not found: HaskellSupport.framework/Versions/A/HaskellSupport Referenced from: /usr/local/lib/ghc-6.2.1/ghc-6.2.1 Reason: file not found Trace/BPT trap The framework is present in /Library/Frameworks, and /Library/Frameworks is in dyld's framework search path. Any Mac/Haskell gurus able to help I would much appreciate it. Thanks Tom Davie

2 2

Optmiization of recursion
by John Goerzen 29 Sep '04

29 Sep '04

Hello, As I'm investigating Haskell, it's occured to me that most of the Haskell tutorials out there have omitted something that was quite prominent in the OCaml material I had read: making functions properly tail-recursive. The OCaml compiler was able to optimize tail-recursive functions such that they could be compiled using a loop. This would achieve two main benefits: performance due to not needing to allocate/deallocate stack frames, and the ability to work on very large lists since each recursive call did not consume extra stack space. So I have several questions about Haskell: 1. Do Haskell interpreters/compilers perform similar optimizations? 2. If the answer to 1 is No, then am I correct in saying that my ability to handle very large lists in recursive functions is limited by the maximum stack size on my system? 3. Does it make a difference for optimization purposes whether a particular recursive function is tail-recursive? 4. Is a reference available documenting which Prelude/standard functions are properly tail-recursive (and thus suitable for very large lists) and which are not? (OCaml system docs generally specify when a function is not tail-recursive... for instance, one of foldr/foldl is and the other isn't.) 5. Are there any examples/patterns anywhere that illustrate standard tail-recursion practice in Haskell? Thanks!

7 8

Re: [Haskell-cafe] Re: Strings - why [Char] is not nice
by MR K P SCHUPKE 29 Sep '04

29 Sep '04

Can this not be handled in a nicer way by the compiler? What if the compiler tried to allocate the lists in chunks? For example when dealing with strings, why cant the compiler allocate the string as a fixed length unit, terminated with a link to the next unit. (IE allow the atoms in the list to be variable size). In this way functions which return blocks of data (for example reading a file in 8k buffers) can be treated just like reading a normal list. This would not only save memory, but would make IO more efficient, whilst retaining a Haskell-like style of coding. Keean.

1 0

Re: [Haskell-cafe] mutually recursive modules
by Henning Thielemann 28 Sep '04

28 Sep '04

On Fri, 24 Sep 2004, Malcolm Wallace wrote: > Hugs doesn't support mutually-recursive modules at all. Ghc and nhc98 > support them only if you hand-write a .hi-boot file to bootstrap the > compilation. I would guess that better support from the mainstream > implementations is unlikely, because it would be a large amount of > effort for a situation which occurs only very rarely, and for which > there is a relatively easy workaround. Namely? The only workaround I know of is putting all type declarations and functions that depend on each other into one module, import them in the modules they logically belong to and document that the objects should be imported from the redirecting modules rather than from the modules they are defined in. I know of two projects where different tasks had to be merged into one module because of the lack of mutually recursive imports, namely functionalMetaPost and Haskore. It's interesting how other languages solve this problem. In Modula-3 it is solved by explicit module interfaces and partial revelation. One can define type T in module A and type T in module B very abstractly as pointers to something and the complete data structures (which may contain references to either interface) are usually revealed in the implementations of the modules. I'm curious how Oberon solves it, because it doesn't need explicit interfaces but derives them from the implementation files. Probably one can say that Oberon extracts something like a .hiboot file from every module file automatically. Why can't GHC and Hugs go this way?

11 14

job ads I saw on DICE
by Christopher Milton 26 Sep '04

26 Sep '04

It is rare to see ads looking for Haskell programming experience... http://seeker.dice.com/jobsearch/servlet/JobSearch?op=1002&dockey=xml/6/2/6… http://seeker.dice.com/jobsearch/servlet/JobSearch?op=1002&dockey=xml/b/8/b…

1 0

Re: [Haskell-cafe] mutually recursive modules
by Malcolm Wallace 24 Sep '04

24 Sep '04

Henning Thielemann <iakd0(a)clusterf.urz.uni-halle.de> writes: > As far as can see neither Hugs or GHC really support them. Is this still > on the to-do list or is it almost dropped due to implementation > difficulties? Hugs doesn't support mutually-recursive modules at all. Ghc and nhc98 support them only if you hand-write a .hi-boot file to bootstrap the compilation. I would guess that better support from the mainstream implementations is unlikely, because it would be a large amount of effort for a situation which occurs only very rarely, and for which there is a relatively easy workaround. Some lesser-known Haskell implementations do fully support mutually-recursive modules however. hhc (formerly Freja, from Henrik Nilsson) allows multiple modules to be stored in a single file, and hence mutual recursion can be achieved by ensuring all the recursive modules are compiled simultaneously from the same file. The PacSoft Haskell system (from the Programatica project at OGI) also fully supports mutually recursive modules, and I believe they can even be in separate files. Regards, Malcolm

1 0

mutually recursive modules
by Henning Thielemann 24 Sep '04

24 Sep '04

As far as can see neither Hugs or GHC really support them. Is this still on the to-do list or is it almost dropped due to implementation difficulties?

1 0

Job
by Mark Carroll 24 Sep '04

24 Sep '04

The company I'm involved with - Aetion, a tiny defense contractor in Columbus, Ohio - is now looking for an affordable Haskell programmer to hire. So, on the offchance that any of you guys are interested, or know of someone who might be, feel free to e-mail me for more information or to supply your resume. Unfortunately, the nature of the work is such that US citizenship or a security clearance would help, and telecommuting isn't really an option. On the upside, the work should be varied and interesting - more challenging than mundane. Given that fact, we are more interested in aptitude than specific experience. -- Mark

1 0

The implementation of functional languages
by mattr 21 Sep '04

21 Sep '04

I am working thru "Implementing Functional Languages: a tutorial" and I want to look up one of the references to get more details. I am looking for the book "The implementation of Functional Programming languages" by S. L. Peyton Jones. Anyone know how I can get it? I would be willing to pay for a second hand copy if anyone has one. Matt

4 3