- Glasgow-haskell-users

RE: eta-expansion
by Simon Peyton-Jones 29 Apr '03

29 Apr '03

| v = \a1 ... an -> f a1 ... an | ===> v = \a1 ...an ... am -> f a1 ... an ...am | | assuming f has arity m > n. | | arity is something like "how many arguments can be applied, without | perfoming work" | | My questions: | 1) How do you compute this arity. Take a look at ghc/compiler/coreSyn/CoreUtils.exprEtaExpandArity. Basically, we just look for partial applications of functions with already-known arity. We consider an expression to have arity N if eta-expansion to put N lambdas at the front would not waste a significant amoutn of work. So (+) 3 would eta expand do \x -> (+) 3 x but (+) (g 3) would not, unless g has arity greater than 1. The idea is to avoid pushing an arbitrarily expensive redex (or in the worst case, bottom) inside a lambda. | 2) What's the expression f in the general rule, is it a variable or | a term, or could it be both? As I mention above, it can be an expression, provided adding the lambda doesn't duplicate work, even if the lambda is applied more than once. | In the same paper is the case-eta-expansion, but I don't understand | the correctness of this transformation: | | case e of {p1 -> e1,...,pn -> en} | ===> \y -> case e of {p1 -> e1 y, ..., pn -> en y} | | The rhs is a WHNF, but the lhs isn't, so the rule | can't be correct in general. For example, assume that e is bot. Right. It's only done if 'e' is cheap (a variable, or something like that). Eta expansion is very important in practice, because it makes head-normal forms show up more, which in turn makes more inlining happen, which can be a really big win. Simon

1 0

RE: Sockets again
by Simon Marlow 29 Apr '03

29 Apr '03

> The attached short program (compile with "ghc VServer.hs -o v > -package net") > is supposed to set up a server on port 15151, wait for a > connection, read > the first character from the connection, and print it out. > Unfortunately > if I test it, by running it, and starting up "telnet [machine] 15151" > somewhere else, and then type some random text, EG > "foo[RETURN]", it does > not work. It looks as if the problem is that VServer.hs issues the > command > hSetBuffering handle (BlockBuffering (Just 4096)) > on the connection, because when I change it to > hSetBuffering handle NoBuffering > the program works. > > However this is not what I want to do!! Because setting > NoBuffering on the > handle is going to mean that when the Server *outputs* > something, it will > potentially be done very expensively character by character. How do I > get block buffering on the Server's output, but not have input to the > server held up? Hmm. I rather think that hGetChar should always return a character immediately if there is one available, regardless of the buffering mode. Looking at the source, it appears that hGetLine behaves like this, as does lazy reading with hGetContents. I can't see any reason for waiting for the buffer to be completely full before returning anything. If you have a source tree handy, try the enclosed patch. If not, make a copy of hGetChar from the sources in libraries/base/GHC/IO.hs, apply the patch, and compile it separately (you'll need to import GHC.Handle explicitly, amongst other things). Cheers, Simon

3 4

How to diagnose exception <<loop>> ?
by Guest, Simon 28 Apr '03

28 Apr '03

Hi all, I'm using GHC 5.04.2 on Windows. I made some changes which broke my application, in that certain input now causes *** Exception: <<loop>> I can't work out what I did to introduce an infinite loop. Is there something I can do to extract more information to narrow this down? Any pointers appreciated. cheers, Simon

2 1

Arkadasa yardimci olalim
by Dr. Ahmet Yalcin 27 Apr '03

27 Apr '03

Arkadaslar, lütfen dikkate alin, yardimci olalim: Merhaba, cok zor durumda ve baska caresi kalmamis biri olarak hosgörünüze ve insan sevginize siginarak sizden bana cok kisada olsa kulak vermenizi rica edecegim. Ben, 34 yasinda evli ve 4 yasinda olan bir cocuk babasiyim. Aile hayatimizin sorunsuz ve mutlu sekilde devam ederken biricik oglumuz aniden rahatsizlandi. Uzun süren arastirmalar sonucu oglumuz Ali Can'in kalbinde hayati bir fonksiyon bozuklugunun bulundugu doktorlar tarafindan tespit edildi. Oglumuz cok acil sekilde ameliyat olmazsa maalesef hayata gözlerini yumacak. Ancak ne varki ameliyat icin gerekli olan parayi ödememiz bizim icin mümkün gözükmüyor. Bu nedenle uzun ugraslar sonucu iki önemli Internet sirketi ile yaptigimiz görüsme sonucu, bize her mailde gönderecegimiz link'in tiklanmasi durumunda cocugumuzun ameliyat masraflarina 10 Cent (= 0,10 Euro) katkida bulunacaklari yönünde anlasmaya varabildik. Bu dogrultuda sizden rica edecegimiz, sizi sözkonusu sirketlerin sayfalarina yönelten bu linki tiklamaniz. Bu linki tiklayarak sizinde ameliyat masraflarini karsilamamizda katkiniz olabilir. Sizden bu zor durumumuzda istedigimiz sadece bir tik. >> TIKLAYINIZ --> http://partners.webmasterplan.com/click.asp?ref=160073&site=2514&type=text&… Bunun yaninda bu emaili tüm tanidiklariniza gönderirseniz bize son derece yardimci olursunuz. Ne kadar kisi linki tiklarsa, gerekli olan ameliyat masrafini yakalayabilmemiz o kadar olasi olur. Hos görünüz icin tesekkür eder, saygilarimi sunarim. Mehmet Can Yakupoglu.

1 0

irg.ssu.ac.kr
by CoolStats Reseller 26 Apr '03

26 Apr '03

BECOME A COOLSTATS RESELLER TODAY! Hi, Are you earning enough revenue from your web space and web traffic? Have you thought about reselling other companies' products from irg.ssu.ac.kr I would like to offer you the opportunity to resell our popular CoolStats website tracking and analysis service to your own site visitors. -------------------------------------------------------------------------- RESELLER BENEFITS! -------------------------------------------------------------------------- 1. Offer CoolStats to your site visitors - directly from your own site. To learn more, click at http://www.coolstats.com! 2. Earn $10 commission EVERY TIME you refer a sale to CoolStats. 3. Track your sales through an online Reseller Account Manager. 4. Receive monthly commission payment for the sale you refer. 5. Attractive monthly performance incentives. For more info, click at http://www.coolstats.com/reseller/benefits.html 6. 24/7 dedicated toll-free customer support. 7. It is FREE to Join. Click at http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000007226.2212.11.c14RXWfc5nUFux to Sign Up now! Sign up today to exploit this great revenue generating opportunity. We look forward to working together with you! Best regards CoolStats Reseller Support Team Email:reseller@coolstats.com Http://www.coolstats.com Not interested in becoming a CoolStats Reseller? To be taken off our mailing list, please follow the instructions here: http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000007226.2212.1.XXDlCoW4Gj0yJ0

1 0

RE: Immutable CStrings
by Simon Marlow 24 Apr '03

24 Apr '03

> How would one implement an CStringLen-style type that > (a) was efficient, in particular could be read and written to Handles > efficiently; > (b) would get automatically deallocated by the Haskell > garbage collector, > when Haskell no longer referred to it; > (c) was immutable, so that once created the character data could not > be changed; > (d) consequently had the property that conversion to and from > String would > be a pure operation; > (e) could be passed to and from C using the FFI. (Of course > C would need you > to split the length and character data up; the character data > would presumably > have type "const char *".) > ? > It would be rather nice to have such a type. Data.PackedString is *almost* what you want, and could be tweaked to do the right thing (at least in GHC). There are two problems: (1) the representation is currently as an array of 32-bit unicode chars, whereas you probably want 8-bit ISO-8859 or something. (2) Passing to FFI functions: to make this work you can use pinned byte-arrays instead of ordinary byte-arrays to store the string, and an explicit touch# after the FFI call. Cheers, Simon

3 3

RE: Immutable CStrings
by Simon Marlow 24 Apr '03

24 Apr '03

> | How would one implement an CStringLen-style type that > | [...] > > Take a look at: > > http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Lab2/Chunk.hs > > Is that what you want? Only one comment: use mallocForeignPtr and it'll go a lot faster with GHC! Cheers, Simon

1 0

RE: Immutable CStrings
by Simon Marlow 24 Apr '03

24 Apr '03

> Other options may exist using packed string objects, pinning them in > the GHC heap, etc. but they are not portable and probably not much > more efficient. If you use mallocForeignPtr and don't need finalizers, then I agree - the ForeignPtr method is about as efficient as PackedStrings. But if you need finalizers and real ForeignPtrs then it will be significantly less efficient in GHC. I guess it depends on whether the reference count is important for George's application. Cheers, Simon

1 0

Chipworks' Image Sensor, Analog, RF, and Memory Reports
by Chipworks 23 Apr '03

23 Apr '03

1 0

eta-expansion
by David Sabel 23 Apr '03

23 Apr '03

I have some questions about the eta-expansion, which is perfomed in the simplifier. I found in [1], that the transformation "eta-expansion" is of the form v = \a1 ... an -> f a1 ... an ===> v = \a1 ...an ... am -> f a1 ... an ...am assuming f has arity m > n. arity is something like "how many arguments can be applied, without perfoming work" My questions: 1) How do you compute this arity. 2) What's the expression f in the general rule, is it a variable or a term, or could it be both? In the same paper is the case-eta-expansion, but I don't understand the correctness of this transformation: case e of {p1 -> e1,...,pn -> en} ===> \y -> case e of {p1 -> e1 y, ..., pn -> en y} The rhs is a WHNF, but the lhs isn't, so the rule can't be correct in general. For example, assume that e is bot. Regards, David [1] André Santos, Compilation by Transformation in Non-Strict Functional Languages, PhD thesis, TR-1995-17, Department of Computing Science, University of Glasgow, 1995. --------------------------------------------------------------------- David Sabel sabel(a)cs.uni-frankfurt.de JWGU Frankfurt

1 0