- Haskell-Cafe - Haskell.org

RE: large binaries
by Simon Marlow 19 Jul '02

19 Jul '02

> > Is there some reason haskell binaries have to be statically linked? > > I can't seem to find a way to make them otherwise, at least with > > ghc. > > The ELF dynamic linking format seems to be designed on the assumption > of poor code reuse (e.g., C code) where calls from one module to > another are rare and can therefore be expensive. > > Haskell code has very high levels of reuse and calls from one module > to another (especially calls into Prelude, List, Monad, etc) are very > common so dynamic linking imposes a very high overhead. > > This isn't a reason to not support dynamic linking but it's a reason > to make it a low priority. Incidentally, it avoids confusion between > the performance overhead of lazy evaluation and the performance > overhead of dynamic linking of modular code. Yes, and there are various other reasons too. There's a FAQ question in GHC's (rather well hidden) FAQ: http://www.haskell.org/ghc/docs/latest/html/users_guide/faq.html and a search through the glasgow-haskell-users archives will turn up previous discussions. Also, we do (or did) have support for dynamic libraries on Windows. Cheers, Simon

3 2

Re: large binaries
by Jon Cast 18 Jul '02

18 Jul '02

Abraham Egnor <aegnor(a)antioch-college.edu> wrote: > This is something I just noticed... > hello.hs: > module Main(main) where > main = putStr "Hello world!\n" > hello.c: > #include <stdio.h> > int main(void) > { > printf("Hello world!\n"); > return 0; > } > [abe@shiva:~/src/test] $ ghc hello.hs -o hello_hs > [abe@shiva:~/src/test] $ gcc hello.c -o hello_c > [abe@shiva:~/src/test] $ ls -l hello_* > -rwxr-xr-x 1 abe engy 13712 Jul 18 11:34 hello_c > -rwxr-xr-x 1 abe engy 299900 Jul 18 11:33 hello_hs > > Why is the binary made by ghc 20 times bigger than the one made by gcc? I don't know for certain, but I've got a couple of guesses: 1. hello_hs is probably statically linked. hello_c is probably dynamically linked. 2. "Hello world!\n" in Haskell is boxed; in C it's un-boxed. Ditto for putStr vs. printf. The compiled code for the Haskell main appears to have a lot of code to deal with those complications; multiply that by however many functions are called by putStr. > Abe Jon Cast

4 3

large binaries
by Abraham Egnor 18 Jul '02

18 Jul '02

This is something I just noticed... hello.hs: module Main(main) where main = putStr "Hello world!\n" hello.c: #include <stdio.h> int main(void) { printf("Hello world!\n"); return 0; } [abe@shiva:~/src/test] $ ghc hello.hs -o hello_hs [abe@shiva:~/src/test] $ gcc hello.c -o hello_c [abe@shiva:~/src/test] $ ls -l hello_* -rwxr-xr-x 1 abe engy 13712 Jul 18 11:34 hello_c -rwxr-xr-x 1 abe engy 299900 Jul 18 11:33 hello_hs Why is the binary made by ghc 20 times bigger than the one made by gcc? Abe

1 0

会议提醒
by ee31＠163.com 16 Jul '02

16 Jul '02

1 0

RE: replacing the Prelude (again)
by Simon Peyton-Jones 15 Jul '02

15 Jul '02

I'm fond of the idea proposed by Marcin 'Qrczak' Kowalczyk: | May I propose an alternative way of specifying an alternative Prelude? | Instead of having a command line switch, let's say that 3 always means | Prelude.fromInteger 3 - for any *module Prelude* which is in scope! That's a perfectly reasonable idea, but GHC can't make it the default because it's not H98. It *would* be possible to make GHC's -fno-implicit-prelude flag mean that 3 means Prelude.fromInteger 3 rather than fromInteger 3 I quite like the fact that you would then have to say import MyPrelude as Prelude thereby stressing that you are importing the Prelude stuff. But it would be that *plus* -fno-implicit-prelude, I'm afraid. If there were a consensus in favour of this I'll gladly do it (5 min job). | anymore. What I would like is that the defualting rules refer | to the classes in my version of the Prelude, | not the Standard Prelude. You can always get that (with the -fno-implicit-prelude thing) by adding default [Int, Double] or whatever to your source module, just after the import that gets your new standard Prelude. Doesn't that do it? It would also not be hard to arrange that the "default default" declaration became scoped with -fno-implicit-prelude (like fromInteger), if that was useful. It's a good point; I thought that *all* the numeric stuff was un-coupled from the Prelude with -fno-implicit-prelude, but it isn't quite. Simon

1 0

��ã�
by houshen2 15 Jul '02

15 Jul '02

�װ��Ͽͻ�� ã��ʺ� ��ȸ�л��ǵĹ�ע��ҹ�˾Ϊ��ף��Ƴ��Żݲ�Ʒ�� 1��200M��HTML�ռ䣩+ ��һ��150Ԫ/�� 2��60M�ռ�+60M��ҵ�ʾ� + ֧��ASP��CGI + ��һ��236Ԫ/�� 3��100MP�ռ�+100M��ҵ�ʾ� + ֧��ASP��CGI��ACCESS + ��һ��336Ԫ/�� ҹ�˾��һ��ר��ڸ��缼��Ĺ�˾��Ŷ��ľ��飬�� ž��Ե��ƣ� ��100M�Ŀ��(��ͨ��ŵ��ն˽��˾��)�� ӵ��һ��߼��Ա��Լ��ϸ�� ۶��е��վ��Ƕ��б��ݣ��ʵʱ��ر�֤��ȶ��ԣ� ��ռ��ϣ��ѡ��--��ǵ��վ http://www.88dns.com/�˽��飬 ��ϵE-mail:webmaster@logindns.com лл!�� ף��꼪�顢��С��˳��!!! ��ӯͨԶ��ӿƼ��޹�˾ --------------------------------------------------------------- �е�Ⱥ��ʼ�,��ר��(http://www.21cmm.com) ��CMM��У(http://www.21cmm.com)��Ŀ��ר��

1 0

replacing the Prelude (again)
by Bernard James POPE 14 Jul '02

14 Jul '02

Hi all, Sorry to dig up an old topic, but I think this is an important one. (at least it is for me). I have run into a problem recently. I am writing a debugger for Haskell. It is based on a source-to-source transformation. The important bit is that the type of functions changes under the transformation. If you want to debug calls into the Standard Prelude (yes this is useful) then a transformed Prelude must be used. The idea being that a transformed program imports a transformed Prelude. That's okay, my debugger can transform all of the Standard Prelude since it is just a Haskell module (with provisions for primitive functions of course). The problem is that when I replace the Standard Prelude with a transformed Prelude the defaulting mechanism doesn't work anymore. What I would like is that the defualting rules refer to the classes in my version of the Prelude, not the Standard Prelude. I am using ghc version 5.03, and I don't think -fno-implicit-prelude can help here. I do think that this issue is independent of the Haskell environment, and more an issue of the design of the language. Now there have already been some discussions about replacing the Standard Prelude with a non-Standard Prelude. The trick being that a fair degree of the language definition makes use of things in the Standard Prelude. See for example: Dylan Thurston Replacing the Prelude http://www.haskell.org/pipermail/haskell-cafe/2002-May/003032.html Primitive types and Prelude shenanigans http://www.haskell.org/pipermail/haskell-cafe/2001-February/thread.html#1641 I'm fond of the idea proposed by Marcin 'Qrczak' Kowalczyk: May I propose an alternative way of specifying an alternative Prelude? Instead of having a command line switch, let's say that 3 always means Prelude.fromInteger 3 - for any *module Prelude* which is in scope! That is, one could say: import Prelude () import MyPrelude as Prelude IMHO it's very intuitive, contrary to -fno-implicit-prelude flag. Presuming of course that defaulting would follow this path and refer to the new Prelude. I'm wondering if any further progress has been made towards this? Or perhaps someone can think of a temporary solution to my problem? Cheers, Bernie.

2 1

what's the difference?
by Cagdas Ozgenc 12 Jul '02

12 Jul '02

Greetings. What is the difference between the following two scenarios: 1) class Eq a where (==) :: a -> a -> Bool class Eq a => Ord a where ( < ) :: a -> a -> Bool 2) class Eq a where (==) :: a -> a -> Bool class Ord a where (eq),( < ) :: a -> a -> Bool instance Ord a => Eq a where (==) = eq eq is just a rename for == to avoid the nameclash The second scenario resembles Russell's Paradox. Typeclass of a typeclass. Anyhow we are loosing orthogonality here. Thanks

2 1

Job Advertisment
by Chris Dornan 11 Jul '02

11 Jul '02

The ARM Web site is advertising a Principal Research Engineer position; see http://www.arm.com/hr.nsf/iwpList61/90A8BD2585A0CE2F80256BF10051000F?OpenDo… and the summary attached to the end of this mail message. Note that although the job is for a Principal Research Engineer with a strong emphasis on microprocessor architecture, a high degree of proficiency in programming, preferably Haskell and C, is regarded as essential. Chris Dornan Principal Research Engineer ARM R&D cdornan(a)arm.com +44 (0)1223 400498 Principal Research Engineer, Cambridge Reference: 02MKRD003 The Research and Development Division are seeking a highly motivated individual who has research experience and who's interests lie in the fields of computer languages, microprocessor architecture, and/or microprocessor simulation. The successful candidate will be involved in a team developing next generation microprocessor architectures. As well as architecture development, this role will involve developing, implementing, and integrating a range of sophisticated tools to assist in the analysis of microprocessor architectures and implementations. The successful candidate will be working in an environment which allows experimentation and provides autonomy, but expects innovation and results; hence the candidate will be of a very high caliber. This post would suit a PhD graduate or someone with a background working in research in Industry. Skills Essential * A high degree of proficiency in programming (preferably in Haskell & C). * A good understanding of microprocessor architectures. * A working understanding of computer languages. * A background in Research and innovation.

1 0

�𾴵��Ͽͻ��!
by web 11 Jul '02

11 Jul '02

��http://www.comdns.com��ʺ��л��տ��ʼ��ϵ�ϣ��ܳ�Ϊ��ڹ��Ҫ ��顣��Ϣ��ã��ɾ��ڴ��Ƕ��ʾǸ��!! �� http://www.comdns.com��һ��ר��Ϊ��ҵ��λ�ṩ��վ��衢��ƽ̨��Ϣ��… ˾��Ŀ��ǳ�Ϊ��缼��ƽ̨��֮һ��ǵķ��ɫ�ǣ�˫Ӳ��ʱ��ݣ��ʧ�� ˾�Ƴ��´��⽫��ֵ��ѡ�� 1.��200M��HTML�ռ�+1��150Ԫ/�꣨�ں��ݣ�� 2.��60Masp��վ�ռ�+60��ҵ�ʾ֣��п��䣩+1��246Ԫ/�꣨�ں��ݣ�� 3.��׼��200MASP��վ�ռ�+200��ҵ�ʾ֣��п��䣩+1��+30M Access��ݿ⣬��336Ԫ/�� ں��ݣ�� 4��ʵ��ע��ֻ��500��/�� 5.��Ż��վ��跽��ο�� Ŭ��ã��Ҳ��ʧ��ǲ��һ��Ĳ��ġ��ǳ�ŵ�� ʱ�ɰ�ʵ��˿ ��ף��ģ�˳�� webmaster of www.comdns.com webmaster(a)comdns.com ========================================================================================= ��ʼ��õ��˵��Ϣ��˵��û�ã��ֱ�Ǹ��ʼ�� Գ�ŵֻ��һ�Ρ��ϣ��Ǵ��б��ɾ��ĵ�ַ��Ÿ��ĵ�ַ��лл�� ========================================================================================== --------------------------------------------------------------- �е�Ⱥ��ʼ�,��ר��(http://www.21cmm.com) ��CMM��У(http://www.21cmm.com)��Ŀ��ר��

2 1