August 2006 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Replacement for GMP: Update
by Peter Tanski 23 Jan '07

23 Jan '07

Simon PJ, Simon, Esa and John, Here is an update on what I have been doing so far in making a grand attempt to replace GMP. (1) evaluate replacement libraries LibTomMath: Pros- * has all the operators GMP offered Cons- * slow; about half as fast as OpenSSL in my tests for simple mathematical operations, much slower if you account for time to write or resize memory. (There is another MP library, which LibTomMath is based on, that is also very slow--student work) * not even reentrant; needs significant modification * beta-release; needs a bit of work to get it to production level * configuration needs to be written (not really portable, messy) ARPREC: Pros- * very fast (essentially does everything through the Floating Point Unit of a CPU) * complex mathematical operations * very precise * already thread safe (through C++ thread-safe statics) Cons- * no bitwise operations (not even left and right-shifts) * difficult configuration (everything runs by setting a precision level; ("precision level" ~= number of words (doubles) in array) it does not automatically resize memory; conversion from MP Real to Integer relies specially on careful precision-level) * memory inefficient (underestimates the number of real digits you can fit into a double, i.e., a 64-bit double has 48 bits of precision, holding about 9.6 digits per byte, resulting in an 848-byte array to hold an MP number with 1000 digits). OpenSSL: Crypto++ (http://www.eskimo.com/~weidai/cryptlib.html) Botan (http://botan.randombit.net/) Pros- * all of these are fast, since all use Integers to support cryptography; (Crypto++ and Botan are C++ crypto-libraries, all licenses good) * all of these provide most basic mathematical operations Cons- * none of these provide &, |, ^(xor) bitwise operators * Botan has least mathematical operators of the three * none provide lcm operator * all would realistically have to have the Integer libraries stripped out of the distribution and repackaged for GHC Summary: I finally settled on modifying OpenSSL, since that would be the easiest to work with under GHC's hood (plain C code, not C++). I have to: a. make OpenSSL's BN thread-safe (add thread local storage, at least) b. optimally add configure-conditional parallelism to BN (through PVM) c. add &, |, ^, lcm and a few other operations d. separate the BN from the rest of OpenSSL and rename the symbols to avoid conflicts (necessary because I have to modify the library anyway) (2) work on GHC: * finally understand C--; know what I need to modify * work through Makefiles: touch and go; I haven't mapped out all the variable settings from configure.in on down when it comes to DLLs Comment: for the Makefile in ghc/rts, in lines 300-346, GC_HC_OPTS += -optc-O3 --isn't this problematic? gcc, from -O2 on includes -fgcse which may *reduce* runtime performance in programs using computed gotos; -fgcse is actually run twice, because -frerun-cse-after-loop is also set at -O2. Would it be better to pass individual flags, such as -funroll-loops and -falign-loops=16 (ppc, Intel setting)? (3) I have been looking at how to implement a dual-constructor-in-a- pointer for Integer (i.e., merge constructors of small Integers and big Integers into the Int#). Would that solution be workable or might it break current Haskell programs? Just a thought. -Peter

11 29

GHC 6.4.1 and Win32 DLLs: Bug in shutdownHaskell?
by Michael Marte 24 Oct '06

24 Oct '06

Hello *, before filing a bug report, I want others to comment on my problem. Maybe it's my fault, not ghc's. I wrapped up some Haskell modules in a Win32 DLL. Loading the DLL dynamically (with LoadLibrary) works fine. However, whether I actually use the library or not, the program (an application with MFC GUI) crashes upon termination. To find the reason for the crash, I added a new function for unloading the DLL using FreeLibrary. FreeLibrary works fine, however the program crashes when it returns to the main event loop. Interestingly, when I reload the library (FreeLibrary followed by LoadLibrary) the program continues working. However, every reload cycle causes the virtual size of the process to increase by about 300K and the fourth reload fails with the error message "getMBlock: VirtualAlloc failed with: 8" (appears in a message window) accompanied by many repetitions of the message "Timer proc: wait failed -- error code: 6" (appears on stderr) and followed by the message "getMBlocks: misaligned block returned" (again in a message window). Then the programm crashes. Development takes place on Windows XP Professional using MS Visual Studio 6.0 SP 5 and ghc 6.4.1. There are no references from the C++ side to the Haskell heap. I build the DLL using the command ghc --mk-dll -optdll--def -optdllFoo.def -o Foo.dll Foo.o Foo_stub.o dllMain.c dllMain.c looks as follows: #include <windows.h> #include <Rts.h> extern void __stginit_EUzu3820zu85(void); static char* args[] = { "ghcDll", NULL }; /* N.B. argv arrays must end with NULL */ BOOL STDCALL DllMain(HANDLE hModule, DWORD reason, void* reserved) { if (reason == DLL_PROCESS_ATTACH) { /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */ startupHaskell(1, args, __stginit_Foo); return TRUE; } else if (reason == DLL_PROCESS_DETACH) { shutdownHaskell(); } return TRUE; } I played around with hs_exit instead of shutdownHaskell, I moved initialization and clean-up from DllMain to my library loader, nothing helps. Even doing no clean-up whatsoever does not change the behaviour. Any ideas? Michael

7 16

6.4.3 and threaded RTS problems
by Simon Marlow 16 Oct '06

16 Oct '06

Hi Folks, Roman Leshchinskiy and I looked into the 6.4.3 crashes on Sparc/Solaris yesterday. I think we may have found the problem, and it seems likely that this is the same problem affecting 6.4.3 on MacOS X. The threaded RTS is assuming in a couple of places that pthread_cond_wait() doesn't spuriously wake up, which is apparently the case on Linux but not true in general. I don't think this bug affects 6.6. I could be wrong, however. Does anyone on MacOS X have a recent testsuite run with the HEAD? I'll try to put together a fix for 6.4.3 when the 6.6 release cycle has died down. Cheers, Simon

6 13

Re: Packages in GHC 6.6
by Peter Tanski 24 Sep '06

24 Sep '06

Simon, >> ... At the moment, >> the only packages you can add in this way are: >> >> ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, >> fgl, haskell-src, html, mtl, network, parsec, time, xhtml > > ... instead include smaller and more "fundamental" > packages: ByteString, regexps, Collections, Edisson, Filepath, Time, > networking, web. I agree with your original idea and Bulat's: the libraries packaged with a compiler should, as a general rule, be those that support the core features of the language or usage of the language itself. Not far off from that are things like being able to work with the operating system--these are essentially related to I/O--because without them your machinations would only be able to operate on themselves. Without getting philosophical about what is and is not necessary for a language to "speak," I'm just looking at the general big-libraries packaged with mature languages like Ada and C++. So here is my vote: Top priority: those you already mentioned, with Bulat's vote for Edison, ByteString, Filepath and Time; I vote for fgl (in my experience fgl is as useful in its own way as Data.Map), mtl, and haskell-src. So the core list might be: *base, haskell98, template-haskell, stm, mtl, haskell-src, *ByteString, Edison, fgl --only because for Edison and fgl there are no reasonable alternatives, so these are in a sense "standard" *readline, unix, Win32, Filepath and Time (they really complement unix and Win32) *Cabal--though this is an extraordinary convenience, it is not strictly necessary (Haskell-GHC users could always be forced to Include everything outside of a standard system directory. I don't mean a GHC-system directory--there are far too many language-specific directory structures crawling around, it's like trying to hide from Wal-Mart.) ... well, that's how I had started the email, but I think your original idea is right: stick with only what you absolutely need and with what is part of the Haskell "standard" library: *base, haskell98, template-haskell, stm, mtl, haskell-src and Cabal are fine; the rest can go together in a special "distribution." Why add mtl and haskell-src? Those seem to be situations where you would have to install a specific library (mtl, say) and specially integrate it into your build of another. At some point the dependencies merit the adoption of a "standard." Extra-Haskell parsing is a good example of leaving things out. HaXml's parser (HuttonMeijerWallace, PolyLazy) is roughly interchangeable with Parsec in many ways--though reasonable people may differ on which is actually better--and installing or uninstalling either would be easy. Things that are missing... There are some library systems that really should come standard and therefore need development. The most specific I can think of are deep-core Haskell debugging libraries (would you think of grabbing gcc without gdb?)--a GHC "HAT." Things that allow specialised code such as haskell-src-exts's dynamic loading modules would also be good--this is like having dynamic libraries for Haskell. Sorry for the length; I've been literally bugged-out with getting a commercially and GPL-usable comparable replacement for GMP going... Personally I would love to give GHC a built-in interface to a real high-level math library (vectors, arbitrary-precision Reals?) but that would be as bad as forcing all gcc users to uninstall a hypothetical gcc-BLAS before they could install their own system- tuned or more precise library. I have been realising more and more that Integers are not a math-library but a data-type (hence bitwise operations). -Pete

7 8

HOpenAL and Haskore
by Juan Rodríguez Hortalá 24 Sep '06

24 Sep '06

Hello everybody, I have a suggestion and a question. The first is about Haskore, I think it would be cool if it could be included in the distribution of GHC. And the later is about HOpenAL. Some information is found in http://www.haskell.org/HOpenGL/newAPI/index.html , on the entry for Sound, but I wonder if there is some tutorial or additional documentation anywhere. Because in http://www.haskell.org/communities/11-2005/html/report.html it is said that "The OpenAL and ALUT packages have not been released yet, but they are already usable and almost feature-complete", and the are supplied with GHC, so maybe I could start learning HOpenAL right now. I have searched for the HOpenAL home page in http://haskell.org/haskellwiki/Libraries_and_tools/Music_and_sound and in google but I haven't found it. Can anybody help me? Thanks in advance -- ________________________________________________________________________ Juan Rodríguez Hortalá

2 1

Floating point problems
by Jamie Brandon 05 Sep '06

05 Sep '06

I recently defied my supervisor and used Haskell to write my coursework instead of C. All went well until I needed floating point and started having odd results. As far as I can tell it isn't substantially affecting my results but it is rather embarrassing after slagging off C so much. Here are some examples: *Main> 0.2 + 0.1 0.30000000000000004 *Main> 0.200000000000000 + 0.100000000000000000 0.30000000000000004 *Main> 0.3 + 0.1 0.4 *Main> 0.2 + 0.1 0.30000000000000004 *Main> it + 0.1 0.4 I assume this is a result of the discrepancy between binary and decimal representations of the numbers. Is there any way around? For a start, it would be nice to have a simple way to get 0.1 + 0.2 == 0.3 = True This is with GHC 6.4.1 and GCC 4.0.3 Thanks, Jamie

9 16

Re[2]: [GHC] #876: stack overflow on 'length . filter odd $ [0 .. 999999999]'
by Bulat Ziganshin 04 Sep '06

04 Sep '06

Hello GHC, Tuesday, August 29, 2006, 10:54:07 PM, you wrote: > It makes sense to me that the above behaviour is seen: length is now a > good > consumer, but it generates 1+(1+(1+(1+... as it is consuming, and this > causes a stack overflow. I don't think we can fix this while staying with > fold/build fusion, so it looks to me like the patch should be reverted and > the whole problem looked at post-6.6. in general, for any function we can either implement 1) good consumer based on using foldr 2) tail-recursion are you agree? in particular, filterM, replicateM and other *M list operations (their problems was mentioned earlier) can be implemented in first or second way, but not both may be this can be fixed with some smart rules, which selects first or second implementation depending on context? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 7

tickets that important for me
by Bulat Ziganshin 01 Sep '06

01 Sep '06

Hello Bulat, Can you please fix the following problems in GHC 6.6.* (uncertainly in 6.6, 6.6.1 will be also good enough) http://hackage.haskell.org/trac/ghc/ticket/814 http://hackage.haskell.org/trac/ghc/ticket/637 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 3

RE: Coverage Condition woes
by Simon Peyton-Jones 31 Aug '06

31 Aug '06

| The following code (coming from Vertigo), which compiles OK with | ghc-6.4.2, is rejected by ghc in HEAD (from this week-end) : | | data Range = Range String Float Float Float | | class AsRange nrs ns | nrs -> ns where | asRange :: nrs -> (ns, [Range]) | | instance (AsRange rsa nsa, AsRange rsb nsb) | => AsRange (rsa, rsb) (nsa, nsb) where | asRange (a, b) = ((nsa, nsb), rsa++rsb) | where | (nsa, rsa) = asRange a | (nsb, rsb) = asRange b | | produces: | Illegal instance declaration for `AsRange (rsa, rsb) (nsa, nsb)' | (the Coverage Condition fails for one of the functional | dependencies) | In the instance declaration for `AsRange (rsa, rsb) (nsa, nsb)' | | Is it normal ? Yes, this is exactly as expected. (The fact that 6.4.2 allowed it was really a bug.) The behaviour is documented here: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions .html#instance-decls (in 7.4.4.1). You can find the background here http://research.microsoft.com/%7Esimonpj/papers/fd%2Dchr/ However, if you add -fallow-undecidable-instances it'll be allowed (see section 7.4.4.2). Simon

1 0