February 2006 - Glasgow-haskell-users

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

06 Feb '06

Interesting example. Yes, GHC builds recursive dictionaries these days. There's a bit of discussion in our SYB paper in ICFP'05. http://research.microsoft.com/%7Esimonpj/papers/hmap/ And Martin Sulzmann has a whole paper about this point. http://www.comp.nus.edu.sg/~sulzmann/ ("Co-induction...") Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 12 December 2005 10:46 | To: glasgow-haskell-users(a)haskell.org | Subject: instance inference | | I'm puzzled that the following is accepted. Is some sort of greatest | fixed point computation used for instances? | | {-# OPTIONS_GHC -fglasgow-exts #-} | module M where | | class C a b where c :: a -> b -> Bool | | instance C b b => C (Maybe a) b where c x y = c y y | | f :: Maybe a -> Bool | f x = c x x | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 7

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

06 Feb '06

| That was exactly my problem. How should I find out the type of | attachListOp (I have not written this bit of code)? Could I somehow ask | ghci-6.4.1 to do it for me? (Unsatisfactory but would work) You could compile with -ddump-ds and look at the output. Simon

2 1

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

06 Feb '06

I took a look. Here's a typical example: newVariableListFromSet :: Ord a => VariableSetSource a -> VariableList a newVariableListFromSet (variableSetSource :: VariableSetSource a) = let attachListOp parallelX (listDrawer :: ListDrawer a pos) = do (posRegistry :: Registry a pos) <- newRegistry groupingCount <- newIORef 0 let updateFn :: VariableSetUpdate a -> IO () updateFn (AddElement a) = do addElement a ... To fix this you'd need to a) Add a 'forall a.' to the sig for newVariableListFromSet. That brings 'a' into scope in the defn of the function. (Arguably, the *implicit* foralls should be in scope too; I'd be interested in what you think.) b) Add a type signature for attachListOp, beginning with forall pos. .... The main thing we're creeping towards is making it clear where scoped type variables are quantified. For example, is attachListOp polymorphic in 'pos'? We are thinking about allowing you to bind the polymorphic type variables of a function in patterns *on the left* of the '='. That would make you happy, I think. Simon | -----Original Message----- | From: Christian Maeder [mailto:maeder@tzi.de] | Sent: 02 February 2006 17:19 | To: Simon Peyton-Jones; 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. | | I've installed now ghc-6.5.20060201 and I get quite a few errors of the | form: | | A pattern type signature cannot bind scoped type variables `s' | unless the pattern has a rigid type context | | (and these are not always easy to fix in unknown non-haskell98 code by | adding a "forall" and/or omitting the pattern type signatures) | | Christian | | You may try to translate the attached sources by: | | ghc --make -cpp -fallow-undecidable-instances -fglasgow-exts | VariableList.hs | | (and tell me how I should fix this)

2 1

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

06 Feb '06

| I have not followed this completely, but do these new rules now allow: | | class F a b c where | f: a -> b -> c | | instance F a a a where Ross's proposal would allow that. Ignore functional dependencies for the moment. To force instance inference to terminate we need the context of the instance declaration to be "smaller" than the head. Otherwise you can get instance Foo [a] => Foo a One way to do that is to require (a) only type variables in the context (b) at least one non-type-variable as a type-class arg in the head Thus instance Foo a => Foo [a] satisifies (b) because [a] is not a type variable. This check is wildly conservative. One can ensure that things get smaller with something weaker, as Ross suggests. And that would be useful, because it'd provide a machine check of termination (necessarily still approximate), which is better than -fallow-undecidable-instances. However matters get significantly more complicated with fundeps. For example (a) and (b) are not enough. Whether Ross's suggestion guarantees termination when we have fundeps I am not sure Simon

1 0

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

06 Feb '06

| > 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. | | Ah, but you added the no-repetition requirement a few weeks ago in | response to the example | | class C a b | instance C b b => C (Maybe a) b Oh yes. And in fact I now remember that this is a bug in the paper: the Basic Conditions should require *distinct* type variables. So I take back that bit. Simon

1 0

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