October 2002 - Glasgow-haskell-users

Hierarchical modules and compilation output redirection
by Martin Norbäck 15 Oct '02

15 Oct '02

I am using hierarchical modules with ghc, and I have a bunch of common modules used by several projects, which should build on serveral platforms. Now, assume I have the following: . |-- Bar | `-- Module.hs |-- Foo | `-- Module.hs `-- Main.hs Main imports both Bar.Module and Foo.module. Currently I am using -osuf ARCHITECTURE.o with ghc --make, which works, but clutters the common modules directory with .o files. (I may want to keep it clean.) So I want to redirect the output with -odir OUTPUT_DIR However it won't work since ghc wll put the compilation output of both modules in OUTPUT_DIR/Module.o and subsequently fail to link. Is there a way to get the files named Bar.Module.o and Foo.Module.o or such? Is there a better way? Another thing that would be good would be a way to redirect output to a directory relative to where the source file is, say for instance that the output of Bar/Module.hs should be put in Bar/ARCHITECTURE/Module.o and the output of Foo/Module.hs should be put in Foo/ARCHITECTURE/Module.o. This is just a cosmetic matter, since I can use -osuf and get a similar effect, but using a separate dir would reduce clutter in the directory. Regards, Martin

2 1

RE: ghc --make and static libraries
by Simon Marlow 15 Oct '02

15 Oct '02

> How do I go about linking to a static library when using --make? > > If i do > > ghc --make Module libmodulelib.a > > then ghc syas: > > chasing modules from Module,libmodulelib.a and complains > about not being > able to find the _module_ modulelib.a. Likewise on windows, if I do > > ghc --make Module modulelib.dll > > it also complains about not finding the _module_ modulelib.dll. > > If I specify the object files that makes up modulelib then > there are no > complaints, likewise, if I link without --make, ghc uses the library > just fine. Thanks, I've fixed this to do The Right Thing, I think. Cheers, Simon

1 0

RE: IO security
by Simon Marlow 14 Oct '02

14 Oct '02

> I'm looking for secure compile and run-time methods to ensure > automatically that Haskell modules cannot perform particular > IO operations. Therefore, I've got some questions that might > be interesting for other people using GHC as well. > > o There are functions like "unsafePerformIO". How many of these > unsafe functions exist and what are their names? Is there > a possibility to tell GHC to reject programs in which > such functions occur? Concerning, e.g., the rewrite-rule system, > how can we prevent that these functions are applied by > some trick, invisible by an automatic inspection of the > source code? > > o Is the function "print" secure in the sense that all stuff > it produces is restricted to go to stdout, even if strange > sequences of control characters appear? > > o Is there a way to tell the GHC run-time system to block > file operations or system calls coming from the > application program, while permitting input/output > via stdin/stdout? Security of a Haskell program is an interesting research area in itself. I suspect the folks at Galois Connections have something to say on the topic. My opinion would be that trying to approach the problem as you have, namely identifying the "unsafe" features and removing them, is likely to be difficult or impossible to verify. A better approach might be to start from a clean slate (ie. remove the IO monad altogether) and incrementally add in safe features separately. Cheers, Simon

1 0

RE: -package-name
by Simon Marlow 14 Oct '02

14 Oct '02

> | Aha. So how will GHC find all the various module imports? > > You install the package using ghc-pkg. That tells GHC where it is. For more information on the interaction between hierarchical libraries and the package mechanism, see http://www.haskell.org/pipermail/glasgow-haskell-users/2002-September/00 4005.html Cheers, Simon

1 0

RE: unsafePerformIO
by Simon Marlow 14 Oct '02

14 Oct '02

> [...] > > > > As for sharing, we currently don't provide any guarnatees, > although we > > should. It is currently the case that if you write > > > > a = unsafePerformIO (putStr "hello") > > b = unsafePerformIO (putStr "hello") > > > > and both a and b are evaluated, then you may get either one or two > > "hello"s on stdout. You can currently make things more > deterministic by > > (a) adding NOINLINE pragmas for a and b, and (b) using the > flag -fno-cse > > to disable common sub-expression elimination. Then you'll > get exactly > > two instances of "hello" on stdout, although we won't guarantee that > > behaviour for ever. At some point we'll fix it so that > unsafePerformIO > > applications are never duplicated or coalesced. > > > Are there any (short) examples available where using of > unsafePerformIO > leads to unexpected behaviour, > especially an example with the terms a and b from above? I don't have any examples to hand, but you ought to be able to make one up without too much difficulty. You just need two identical bindings such as in the example above, and compile with -O. Cheers, Simon

1 0

Reviving GHC on Mac OS X 10.2 (Jaguar)
by Sébastien Carlier 13 Oct '02

13 Oct '02

Hi, The binary snapshot for Mac OS X on http://haskell.cs.yale.edu/ghc/ does not run on Jaguar. After looking into that a bit, I have found that just setting the following two environment variables solves the problem: > export DYLD_INSERT_LIBRARIES=/usr/lib/libtermcap.dylib > export DYLD_FORCE_FLAT_NAMESPACE=1 (I just found out about the version compiled for Jaguar at <http://www.uni-graz.at/imawww/haskell/JaguarGHC.tar.gz> but this trick might bu useful in the future if Apple split libraries again.) -- Sébastien

1 0

Rts.h and C++ Annoyance
by Ashley Yakeley 13 Oct '02

13 Oct '02

It seems I can't compile Rts.h as C++ on Linux. Curiously it compiles OK on Darwin. $ gcc -x c -c /usr/lib/ghc-5.04/include/Rts.h $ gcc -x c++ -c /usr/lib/ghc-5.04/include/Rts.h In file included from /usr/lib/ghc-5.04/include/Stg.h:210, from /usr/lib/ghc-5.04/include/Rts.h:20: /usr/lib/ghc-5.04/include/gmp.h:1970: declaration of C function `class ostream & operator <<(ostream &, const __mpq_struct *)' conflicts with /usr/lib/ghc-5.04/include/gmp.h:1969: previous declaration `class ostream & operator <<(ostream &, const __mpz_struct *)' here /usr/lib/ghc-5.04/include/gmp.h:1971: declaration of C function `class ostream & operator <<(ostream &, const __mpf_struct *)' conflicts with /usr/lib/ghc-5.04/include/gmp.h:1970: previous declaration `class ostream & operator <<(ostream &, const __mpq_struct *)' here /usr/lib/ghc-5.04/include/gmp.h:1973: declaration of C function `class istream & operator >>(istream &, __mpq_struct *)' conflicts with /usr/lib/ghc-5.04/include/gmp.h:1972: previous declaration `class istream & operator >>(istream &, __mpz_struct *)' here /usr/lib/ghc-5.04/include/gmp.h:1974: declaration of C function `class istream & operator >>(istream &, __mpf_struct *)' conflicts with /usr/lib/ghc-5.04/include/gmp.h:1973: previous declaration `class istream & operator >>(istream &, __mpq_struct *)' here $ gcc --version 2.95.4 $ ghc --version The Glorious Glasgow Haskell Compilation System, version 5.04 $ uname -a Linux server 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686 unknown $ -- Ashley Yakeley, Seattle WA

1 0

Save on Chipworks' Technical Publications - Limited Time Offer!
by Info 11 Oct '02

11 Oct '02

<http://www.chipworks.com/mail/10_2002/Pub_mail_10_02.gif> This month, save big on popular new releases as well as some old favorites during this featured event. Discounts valid till 1 November 2002. Group A <http://www.chipworks.com/publications/FTR/embedded_DRAM_0206_004.htm> Embedded DRAM - FTR 0206-004 This first ever study of real world implementations of embedded DRAM provides some background on the issues and detailed analysis of some current products. <http://www.chipworks.com/publications/FTR/embedded_SRAM_0205_002.htm> Embedded SRAM - FTR 0205-002 A comparative analysis of 13 different devices from 11 different manufacturers. This study of Microprocessor, DSP and other types of semiconductor devices looks at real world implementations of embedded SRAM technology. On-Die <http://www.chipworks.com/publications/FTR/on_die_interconnects_0206_00 3.htm> Interconnect Technology - FTR 0206-003 A comparative analysis of 19 different devices from 6 different manufacturers. On-Die Interconnect is an invaluable resource in providing a comparison between different manufacturers backend interconnect processes <http://www.chipworks.com/publications/FTR/shallow_trench_0205_001.htm> Shallow Trench Isolation - FTR 0205-001 A comparative analysis of 20 different devices from 14 different manufacturers. This comparative study provides real world examples of how the STI process has been implemented by a number of different manufacturers. Buy one Group A Publication and save 20% Buy two Group A Publications and save 30% Buy three Group A Publications and save 40% Group B FLASH <http://www.chipworks.com/publications/FTR/Flash_9912_007.htm> Memory Cells - FTR 9912-007 This report describes a comparative analysis of Flash and EEPROM cells on fourteen different devices by twelve manufacture's <http://www.chipworks.com/publications/FTR/FlipChip_9912_001A.htm> Comparative Analysis of Flip-Chip Technology - FTR 9912-001A Fifteen devices using Flip-Chip Technology from seven different manufacturer's are analyzed. New <http://www.chipworks.com/publications/FTR/Wirebonds_9906_006.htm> Designs for Wirebond Pads - FTR 9906-006 This report describes a comparative analysis of new designs for wirebond pads on thirteen different devices by ten manufacturer's. Buy one Group B Publication and save 20% Buy two Group B Publications and save 30% Buy three Group B Publications and save 40% Group C <http://www.chipworks.com/publications/FTR/HighspeedBuffers.htm> Comparative Analysis of High Speed Buffers - FTR 0111-001 Selected from Chipworks library of Circuit Analysis, this report provides a comparative analysis of the Input and Output Buffers of 14 different devices from 12 different manufacturers. Comparative <http://www.chipworks.com/publications/FTR/Analog_Digital_0206_002.htm> Analysis of Interlevel Dielectric (ILD) and Metalization Technologies Products included in the analysis are DRAMS, microprocessors and general logic. New <http://www.chipworks.com/publications/non_volitile.htm> Technologies and Trends in Non-Volatile Memory Learn about the present state of the non-volatile memory market and the new FeRAM and MRAM technologies. <http://www.chipworks.com/publications/str.htm> Successful Technologies Review 2001 (STR) A compilation of the latest "delivered" technologies, this report contains photographic illustrations (typically die photos and cross sections) for each product included, as well as a description of the technology, comments on manufacturing quality and comparison tables of design rules, layer thickness, and materials employed. Save 50% on the purchase of a Group C Publication Group D Analog <http://www.chipworks.com/publications/FTR/Analog_Digital_0206_002.htm> to Digital Converter This report will provide an analysis of 6 different analog-to-digital converter (ADC) circuits from 6 different manufacturers. The circuits selected will represent a variety of ADC types. Phase <http://www.chipworks.com/publications/FTR/PLL_0206_001.htm> Locked Loop (PLL) - FTR 0206-001 Intended for circuit designers, technicians and project managers, this comparative study provides real world examples of how PLL circuitry has been implemented by a number of different manufacturers. See what your competition is doing with regards to PLL design today. Buy one Group D Publication and save 20% Buy two Group D Publications and save 30% Contact Chipworks <mailto:info@chipworks.com?%20subject=Pub%20MK10> to discover more about our services <http://www.chipworks.com/services/consulting.htm> and products <http://www.chipworks.com/products/products.htm> . If you interested in a topic that we have not already completed, please send your idea to info(a)chipworks.com <mailto:info@chipworks.com?%20FTR%20MK> . Search <http://www.chipworks.com/webreports/webreports.asp> our library of analysis reports. <mailto:unsubscribe@chipworks.com?subject=Unsubscribe%20%20please...> Unsubscribe to Chipworks Inside Technology <http://www.chipworks.com/images/footer_600.gif> This e-mail message may contain client privileged and/or confidential information, and is intended only for the use of the individual or entity named above. If you have received this communication in error, please notify us immediately by reply e-mail and delete or discard this message. Thank you.

1 0

RE: non-termination during compilation
by Simon Peyton-Jones 11 Oct '02

11 Oct '02

Yes, it's a known bug. GHC just inlines over and over again. It's discussed in "secrets of the GHC inliner". It's quite tiresome to fix without compromising something else, and I have never found a real program (rather than 'russel') that tickles the bug. I'd better document it, though Simon | -----Original Message----- | From: Christian Maeder [mailto:maeder@Informatik.Uni-Bremen.DE] | Sent: 10 October 2002 16:02 | To: glasgow-haskell-users(a)haskell.org | Subject: non-termination during compilation | | Hi, | | the following example causes ghc to loop (or run rather long): | | --- snip --- | | data U = MkU (U -> Bool) | | russel :: U -> Bool | russel u@(MkU p) = not $ p u | | x :: Bool | x = russel (MkU russel) | | --- snip --- | | I think, a compiler should always terminate, shouldn't it!? | | Compilation succeeds for "russel $ MkU russel" instead of "russel (MkU | russel)". | (Surely, x is bottom and therefore the example is senseless) | | Regards Christian | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: brain explosion in polymorphic state monad
by Simon Peyton-Jones 11 Oct '02

11 Oct '02

Use 'case'. Instead of | let MkStateT m2 = k a | m2 s1 ) say case k a of MkStateT m2 -> m2 s1 Simon | -----Original Message----- | From: mathieu [mailto:tenfingers@ifrance.com] | Sent: 10 October 2002 21:42 | To: ghc users | Subject: brain explosion in polymorphic state monad | | Hello, | | I am trying to define a polymorphic state monad using glasgow extensions and I got a | brain explosion of ghc when i try to compile it. | | Here is the code : | | newtype StateT s m a = MkStateT (s -> m (a, s)) | | instance Monad m => Monad (StateT s m) where | return x = MkStateT (\s -> return (x, s)) | MkStateT m1 >>= k = | MkStateT | (\s0 -> do (a, s1) <- m1 s0 | let MkStateT m2 = k a | m2 s1 ) | | data Thread a = forall b . MkThread (StateT (Thread b) [] a) | | instance Monad Thread where | return = MkThread . return | MkThread p >>= k = MkThread ( do x <- p | let MkThread p' = k x | p' ) | | I got this error : | My brain just exploded. | I can't handle pattern bindings for existentially-quantified constructors. | In the binding group | MkThread p' = k x | In the first argument of `MkThread', namely | `(do | x <- p | let MkThread p' = k x | p')' | In the definition of `>>=': | MkThread (do | x <- p | let MkThread p' = k x | p') | | How can i define (>>=) for my thread monad ? | | Thanks in advance for any piece of advice, | Mathieu | | -- | There are only 10 types of people in the world: | Those who understand binary and those who don't. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0