- Glasgow-haskell-users

RE: instance inference
by Simon Peyton-Jones 06 Feb '06

06 Feb '06

Ross, and Martin, Thanks! But I'm not certain that your fix is correct. Let's ask Martin. I've added comments below. | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 06 February 2006 11:36 | To: Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Subject: Re: instance inference | | A patch implementing a relaxed termination constraint is at | | http://www.soi.city.ac.uk/~ross/instance-termination.patch | | Here is the description: | | With -fglasgow-exts but not -fallow-undecidable-instances, GHC 6.4 | requires that instances be of the following form: | | (1-GHC) each assertion in the context must constrain distinct variables | mentioned in the head, and | | (2-GHC) at least one argument of the head must be a non-variable type. Yes, (1-GHC) certainly contradicts the FD paper that Martin and I wrote. I think (1) should be: (1-fixed) Each assertion in the context must constrain type variables, and those type variables must all be mentioned in the head. That is, there is no requirement that the type variables should be distinct (they can be repeated). But they must all appear in the HEAD. Do you agree, Martin? For example class D a b | a -> b instance C a b b a => D a b where ... is fine. Now, you propose something new and interesting: | This patch replaces these rules with the requirement that each | assertion in the context satisfy | | (1-Ross) no variable has more occurrences in the assertion than in the | head, and | | (2-Ross) the assertion has fewer constructors and variables (taken together | and counting repetitions) than the head. | | This allows all instances permitted by the old rule, plus such | instances as | | instance C a | instance Show (s a) => Show (Sized s a) | instance (Eq a, Show b) => C2 a b | instance C2 Int a => C3 Bool [a] | instance C2 Int a => C3 [a] b | instance C4 a a => C4 [a] [a] | | but still ensures that under any substitution assertions in the context | will be smaller than the head, so context reduction must terminate. Your (1-Ross) ensures that every variable in the assertion does occur in the head. But I'm not sure that the size-reduction argument is watertight in the presence of fundeps. (E.g. in example 15 it *looks* as if the size goes down, but it doesn't.) I bet Martin could tell us if it's watertight though. It certainly looks useful. However, notice that (1-Ross) is more also more restrictive than (1-fixed), because it rules out the C/D example I give above. So is it a win? Simon

2 2

overlapping instances in ghc-6.5
by Christian Maeder 03 Feb '06

03 Feb '06

Hi, with 6.5.20060201 I get now an error for some overlapping instances that were ok for ghc-6.4.1. Did some options change? I use: -fglasgow-exts -fno-monomorphism-restriction \ -fallow-overlapping-instances -fallow-undecidable-instances Christian Common/ATerm/ConvInstances.hs:39:0: Overlapping instances for Typeable (Common.Lib.Graph.Gr a b) arising from the superclasses of an instance declaration at Common/ATerm/ConvInstances.hs:39:0 Matching instances: instance (Data.Typeable.Typeable1 s, Typeable a) => Typeable (s a) -- Imported from Data.Typeable instance [overlap ok] (Typeable a, Typeable b) => Typeable (Common.Lib.Graph.Gr a b) -- Defined at Common/ATerm/ConvInstances.hs:34:0 In the instance declaration for `ShATermConvertible (Common.Lib.Graph.Gr a b)'

1 0

RE: Linking with C++ produced by Visual Studio .NET on Windows XP?
by Simon Peyton-Jones 03 Feb '06

03 Feb '06

GHC now makes it easy for all users to contribute new documentation about GHC to help other users, by adding to the GHC documentation wiki. See the "Collaborative documentation" heading on http://haskell.org/haskellwiki/GHC:Documentation Linking to C++ would be an ideal topic. It's a regular question, and not one of our strengths at GHC HQ! Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Cyril Schmidt | Sent: 23 January 2006 09:57 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: Linking with C++ produced by Visual Studio .NET on Windows XP? | | I am far from being an expert, but I have seen no answer to your question | so far, so I'll tell how I'd do it (however ugly that might be). I don't | have a sample project, but it should be fairly easy to make it. | | 1. Make a DLL project in Visual Studio. VS will create a .vcproj and | .sln files for you. Add your C++ source files to this project. | | 2. Create a .def file for your DLL. It might look like | LIBRARY MyDLL | EXPORTS | function1 | function2 | | where function1 and function2 are the names of the C++ functions that | you want to invoke from Haskell (there can be more of them, of course), | MyDLL is the name of your DLL. | | 3. Create an import library that can be used by ghc: | dlltool -d MyDLL.def -l libMyDLL.a | | where MyDLL.def is the name of the .def file, libMyDLL.a is the import | library. | | 4. Link your Haskell project, adding the library: | ghc --make main.hs -optl-lMyDLL -optl-L. | (-optl switch passes its argument as an option to the linker). | | Hope this helps. | | Cheers, | | Cyril | | ___ | | >Hi - | >I'm wondering if anyone has a simple Visual Studio .NET C++ project that | >would demonstrate how to link C++ with Haskell (or vice versa). Ie a .sln, | >.vcproj, .cpp, and .h file containing one C++ function and a Haskell file | >main.hs that calls this function, so that if I click on the .sln file and | >hit F6 the VS project will build then on the command line if I type | >ghc --make main.hs the Haskell program will be built so that when I type | >"main" on the command line it will run and call the C++ function. | | >Sorry if this all sounds too basic but I don't know how to compile C++ from | >the command line at all or how to use make files, and I need to use the | >Visual Studio compiler because my own C++ code relies on Microsoft | >extensions...

5 4

RE: Re[2]: new i/o library
by Simon Marlow 03 Feb '06

03 Feb '06

On 03 February 2006 08:34, Bulat Ziganshin wrote: >>> moreover - we can implement locking as special "converter" type, >>> that can be applied to any mutable object - stream, collection, >>> counter. that allows to simplify implementations and add locking >>> only to those Streams where we really need it. like these: >>> >>> h <- openFD "test" >>> >>= addUsingOfSelect >>> >>= addBuffering 65536 >>> >>= addCharEncoding utf8 >>> >>= attachUserData dictionary >>> >>= addLocking > >> This is really nice - exactly what I'd like to see in the I/O >> library. The trick is making it perform well, though... but I'm >> sure that's your main focus too. > > basically idea is very simple - every stream implements the Stream > interface, what is clone of Handle interface. Stream transformers is > just a types what has Stream parameters and in turn implement the same > interface. all Stream operations are translated to calls of inner > Stream. typical example: > > data WithLocking h = WithLocking h (MVar ()) There's a choice here; I did it with existentials: data ThreadSafeStream = forall h . Stream h => TSStream h !(MVar ()) instance Stream ThreadSafeStream where ... What are the tradeoffs? Well, existentials aren't standard for one thing, but what about performance? Every stream operation on the outer stream translates to a dynamic call through the dictionary stored in the stream. Lots of layers means lots of dynamic calls, which probably won't be efficient. What about compared to your version: > instance (Stream IO h) => Stream IO (WithLocking h) where so a stream might have a type like this: WithLocking (WithCharEncoding (WithBuffer FileStream)) and calling any overloaded stream operation will have to build a *new* dictionary as deep as the layering. GHC might be able to share these dictionaries across multiple calls within a function, but I bet you'll end up building dictionaries a lot. Compare this with the existential version, which builds the dictionary once per stream. On the other hand, you can also use {-# SPECIALISE #-} with your version to optimise common combinations of layers. I don't know if there's a way to get specialisation with the existential version, it seems like a high priority though, at least for the layers up to the buffering layer. Also, your version is abstracted over the monad, which is another layer to optimise away (good luck :-). >> Still, I'm not sure that putting both input and output streams in the >> same type is the right thing, I seem to remember a lot of things >> being simpler with them separate. > > i'm interested to hear that things was simpler? in my design it seems > vice versa - i will need to write far more code to separate read, > write and read-write FDs, for example. may be, the difference is > because i have one large Stream class that implements all the > functions while your design had a lot of classes with a few functions > in each Not dealing with the read/write case makes things a lot easier. Read/write files are very rare, I don't think there's any problem with requiring the file to be opened twice in this case. Read/write sockets are very common, of course, but they are exactly the same as separate read & write streams because they don't share any state (no file pointer). Having separate input/output streams means you have to do less checking, so perforamnce will be better, and there are fewer error cases. Each class has fewer methods, again better for performance. The types are more informative, and hence more useful. Also, you can do cool stuff like: -- | Takes an output stream, and returns an input stream that will yield -- all the data that is written to the output stream. streamOutputToInput :: (OutputStream s) => s -> IO StreamInputStream -- | Takes an output stream and an input stream, and pipes all the -- data from the former into the latter. streamConnect :: (OutputStream o, InputStream i) => o -> i -> IO () Sure you can do these with one Stream class, but the types aren't nearly as nice. Oh, one more thing: if you have a way to turn a ForeignPtr into a Stream, then this can be used both for mmap'd files and for turning (say) a PackedString into a Stream. Cheers, Simon

2 1

new i/o library
by Bulat Ziganshin 03 Feb '06

03 Feb '06

Hello Simon i'm now write some sort of new i/o library. one area where i currently lacks in comparision to the existing Handles implementation in GHC, is the asynchronous i/o operations. can you please briefly describe how this is done in GHC and partially - why the multiple buffers are used? i'm now use just one buffer, which can contain read or write data, but not both - this buffer is just flushed before switching "mode" of operations. am i lose something due to this simplified algorithm? moreover, i have an idea how to implement async i/o without complex burecreacy: use mmapped files, may be together with miltiple buffers. for example, we can allocate four 16kb buffers. when one buffer is filled with written data, the program unmaps it and switches to use the next buffer. i don't tested it, but OS can guess that unmapped buffer now should be asynchronously written to disk. the same for reading - when we completely read one buffer, we can unmap it, switch to the second buffer and map the third so that the OS can asynchronously fill the third buffer while we are reading second. should this work, at least on the main desktop OSes? at least, mmap/VirtualAlloc available afaik on the all ghc-supported platforms, so this should work anywhere. of course, this scheme omits async i/o on sockets in Windows -- Best regards, Bulat mailto:bulatz@HotPOP.com

4 10

RE: Lexically scoped type variables
by Simon Peyton-Jones 02 Feb '06

02 Feb '06

It'll be the HEAD, when I commit; I'll send a message. SImon | -----Original Message----- | From: Christian Maeder [mailto:maeder@tzi.de] | Sent: 18 January 2006 16:18 | To: Simon Peyton-Jones | Cc: GHC Users Mailing List | Subject: Re: Lexically scoped type variables | | Simon Peyton-Jones wrote: | > I'm very interested to know whether you like it or hate it. | > In the latter case, I'd also like to know whether you also | > have programs that will be broken by the change. | | I don't use GADTs yet and I assume this change will not (seriously) | break our code, but let me/us know which compiler we should use for testing. | | Cheers Christian

2 1

ghci from darcs HEAD buggy on MacOS X?
by Geoffrey Alan Washburn 27 Jan '06

27 Jan '06

I just installed the Darwin Ports ghc-devel package, which grabs the latest from the darcs repository. It seems to build fine, but when I run ghci it seems to run and work (as far as I've tested) just fine except that it beeps continuously. Any ideas?

1 0

Full Release Notes for GHC 6.4.1?
by Rich Fought 26 Jan '06

26 Jan '06

Hello, I'm wondering if there exists a full description of bug fixes between GHC 6.4 and 6.4.1. The short one on the GHC web site only details new features. Specifically, I'm interested to know if there were any changes to the concurrency/threading portion of GHC? I'm encountering some nasty FFI/threading issues that are causing GHC 6.4 to crash. Thanks, Rich

2 1

ghc and gcc-4
by Johannes Waldmann 24 Jan '06

24 Jan '06

are there known problems with ghc-6.4.* and gcc-4.*? It seems that -O2 does not work (on i386), as gcc says something like "Prologue junk". (Suse linux 10.0 comes with gcc-4.?`as default compiler). -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 4

Re: Linking with C++ produced by Visual Studio .NET on Windows XP?
by Cyril Schmidt 24 Jan '06

24 Jan '06

Brian Hulley wrote: > Thanks. The only problem is that dlltool doesn't work because I don't > have > cygwin installed. dlltool usually comes with the Windows distribution of GHC (at least GHC 6.4 and 6.4.1 have it; check gcc-lib directory). Cheers Cyril

2 3