Re: [Haskell-cafe] Linking to third party libraries in windows
Not only does your suggestion make more sense than what I was doing, but also it causes the 'matrices' to behave as expected, namely to have the side effects incorporated into their array values. I can't say I fully understand why this is true. In both cases I was wrapping Rmatrix in a monad after every computation. The difference is that the array component had an additional monad wrapper around and now it doesn't. That is, old case newtype Rmatrix = Rmatrix (Int, Int, IO(StorableArray Int CDouble)) new case newtype Rmatrix = Rmatrix (Int, Int, StorableArray Int CDouble) In the old way, the additional IO wrapper forces an additional nesting of do loops for most processing. It is certainly the case that the do loop that performs the withStorableArray operations has the contents of the array modified. Outside that loop, once all actions on the monad are done, I am not convinced the array will mutate unless it's explicitly returned. Now hopefully I won't induce unnecessary copying. Thanks again for your help. Brian Hulley wrote: Hi Matthew - Sorry about the long delay in my reply to your last message - I'd composed the reply but when I tried to send it I was blocked by spamhaus.com because the dynamic IP that my ISP had allocated to me at the time I was connected had been listed on some composite spam blocker database, and even when I tried reconnecting several times I kept ending up being allocated the same client IP. So I did a complete scan of my system and now (several hours later) when I tried to reconnect again, I've been allocated a different client IP so my reply to your last message was sent at last! ... I hope it answers your question relating to the above: the array is not created in the let statement, but twice, in rout - mac r2 (-0.5) rmat and then again in mprint r2 Rmatrix really needs to have type (Int, Int, StorableArray Int CDouble) if your intention is to pass around an actual allocated matrix together with its dimensions, and listtoRmatrix would need to be typed as: listtoRmatrix :: Int - Int - IO Rmatrix so that the let statement could be replaced by r2 - listtoRmatrix 3 2 [1, 1, 1, 1, 1, 1] and for example mprint would be defined as: mprint :: Rmatrix - IO () mprint (Rmatrix cols rows arr) = do -- just print element at (0,0) for the moment readArray arr 0 = print (Of course the above needs to iterate through the rows cols etc but you've already got the code to do this...) Hope this helps, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell RPC
On May 25, 2006, at 7:25 PM, Jason Dagit wrote: I will say that you should add a macro or high order function (depneding on lisp vs. haskell) that is something like (with-client (c args-list) body), that way you can simplify the creation/cleanup of clients. Same idea as with-open-file. You can do the same with server. Yes, thanks for the suggestion. This would indeed be useful. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell RPC
On May 25, 2006, at 8:34 PM, Robert Dockins wrote: If you want to deliver source code to be executed elsewhere, you can use hs-plugins or the GHC API (in GHC HEAD branch). hs-plugins is too heavy since it runs ghc. I don't need to deliver any type of source code, just a function call and its arguments. Beyond that, I'd say there are a few too many free variables in the problem description. What would be the design goals and non-goals for such an RPC mechanism? What problems prompted the original lisp implementation? What about fault tolerance, reliability, security? etc. The design goals is just to have a simple RPC mechanism with synchronous (request/reply) and asynchronous (send a message) facilities. The problem I'm trying to address is running a whole bunch of software servers for scalability. Reliability and fault tolerance are taken care of by having redundant servers and security is not addressed at all. It seems that I can do something similar in Haskell by having heterogenous lists of arguments and making each RPC call into a type class but then I would have to implement the functions myself. I wish Glasgow Distributed Haskell (GdH) was more active and visible! Does anybody know its current state? Shouldn't it be an extension to GHC just like Concurrent Haskell is? Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Linking to third party libraries in windows
Hello Matthew, Friday, May 26, 2006, 11:50:28 AM, you wrote: I can't say I fully understand why this is true. In both cases I was wrapping Rmatrix in a monad after every computation. The difference is that the array component had an additional monad wrapper around and now it doesn't. That is, old case newtype Rmatrix = Rmatrix (Int, Int, IO(StorableArray Int CDouble)) new case newtype Rmatrix = Rmatrix (Int, Int, StorableArray Int CDouble) seems that you just don't understood monads. IO a type means an action that returns value of type 'a' :) just as example - 'getChar' is an action that has type IO Char. this action by itself don't contain any Char, as you can guess :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] request for co-development: improving Data.CharEncoding module
Hello Haskell, i plan to publish new version of Streams library on next week (see http://haskell.org/haskellwiki/Library/Streams if you still don't know about it :) ). one of it's current drawbacks is lack of support for file encodings other than UTF-8 and Latin-1. if someone can work on this support, it will widen usage area of the library i attached to letter current version of this module. it uses monadic approach to encoding and decoding: each encoder is just a function that performs monadic PutChar action via calls to monadic PutByte action, and decoder in the same fashion translates each call to GetChar into calls to GetByte. this allows to use encoders in various environments - for monadic i/o, string conversion and so on this module requires two improvements - first, support for other UTF encodings; second, raising an exception in situations when data can't be encoded (such as char '\255' for Latin-1) or decoded (bad UTF bytes sequence). if you are going to work on this module, please write about this here - to avoid overlapping of work -- Best regards, Bulat mailto:[EMAIL PROTECTED] CharEncoding.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking to third party libraries in windows
Dear friends - I must have clicked reply instead of reply all so here is the reply haskell cafe would have received: Matthew Bromberg wrote: Not only does your suggestion make more sense than what I was doing, but also it causes the 'matrices' to behave as expected, namely to have the side effects incorporated into their array values. I can't say I fully understand why this is true. In both cases I was wrapping Rmatrix in a monad after every computation. The difference is that the array component had an additional monad wrapper around and now it doesn't. That is, old case newtype Rmatrix = Rmatrix (Int, Int, IO(StorableArray Int CDouble)) new case newtype Rmatrix = Rmatrix (Int, Int, StorableArray Int CDouble) In the old way, the additional IO wrapper forces an additional nesting of do loops for most processing. This is the essential difference, but I think you haven't quite understood what it means. When you say The difference is that the array component had an additional monad wrapper around and now it doesn't. this is not correct. IO (StorableArray Int CDouble) is a monadic *value* itself, which represents an *action* which returns a storable array, and since you are filling in the slot in Rmatrix with the action (newListArray a l), this monadic value represents the action of creating a new array whenever the action is executed. Whereas (StorableArray Int CDouble) is the actual array itself. You could also use your old definition of Rmatrix but change the way it is created eg: listtoRmatrix r c es = do arr - newListArray (0, r * c) es return (Rmatrix r c (return arr)) do r2 - listtoRmatrix 3 2 [1, 1, 1, 1, 1, 1] -- the rest is old code and everything would work as expected, because in this case, the monadic action contained in Rmatrix just returns the array arr that was created in the execution of listtoRmatrix 3 2 [1, 1, 1, 1, 1, 1], because listtoRmatrix is the only place where the action of creating a new array, ie (newListArray (0, r * c) es) is actually executed. I think the subtlety is one of these things that's very difficult to understand at first, but once you've grasped the fact that in Haskell expressions can evaluate to actions which are themselves values, and which in turn can create new values when executed, it will hopefully become a lot clearer. Regards, Brian. -- Logic empowers the living and justifies the dead. But societal laws, and religious dogma, empower the dead, to destroy what's living. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] help with MPTC for type proofs?
Hi all, I've been thinking about extending some (experimental) GADT-based proof code that verifies that the darcs patch theory code is properly used. A given patch has type (Patch a b), and I'd like to be able to write something like commute :: (Patch a b, Patch b c) - (Patch a d, Patch d c) in such a way that the type system know that the type d is one particular type, uniquely determined by the types a, b and c. Currently, which I do is to make d be existential with data Pair a c where (:.) :: Patch a d - Patch d c - Pair a c commute :: Pair a c - Pair a c which prevents misuse of the returned pair, but doesn't allow proper use, for example we ought to be able to compile: test (a :. b) = do (b' :. a') - return $ commute (a :. b) (b'' :. a'') - return $ commute (a :. b) (a''' :. b''') - return $ commute (b' :. a'') return () but this will fail, because the compiler doesn't know that b' and b'' have the same type. So I'd like to write something like class Commutable a b d c commute :: Commutable a b d c = (Patch a b, Patch b c) - (Patch a d, Patch d c) But for this to work properly, I'd need to guarantee that 1. if (Commutable a b d c) then (Commutable a d b c) 2. for a given three types (a b c) there exists at most one type d such that (Commutable a b c d) I have a feeling that these may be enforceable using fundeps (or associated types?), but have pretty much no idea to approach this problem, or even if it's soluble. Keep in mind that all these types (a, b, c and d) will be phantom types. Any suggestions would be welcome. -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell RPC
On Fri, May 26, 2006 at 09:20:25AM +0100, Joel Reymont wrote: On May 25, 2006, at 8:34 PM, Robert Dockins wrote: If you want to deliver source code to be executed elsewhere, you can use hs-plugins or the GHC API (in GHC HEAD branch). hs-plugins is too heavy since it runs ghc. I don't need to deliver any type of source code, just a function call and its arguments. Is there a discrete set of functions you want to be able to call, then? If so, why not just define a data type: data MyRPC = LengthIntList [Int] | HeadList [Int] | ... deriving ( Show, Read ) Then you just implement a runfunction (LengthIntList xs) = length xs runfunction (HeadList (x:_) = x ... No trickiness required, all you need is one datatype enumerating the functions you want to be able to call, and a dispatch function. At the cost (over lisp) of having to write these enumerations, you gain the safety of knowing that only that list of functions can be called, and that they all have the appropriate return type (or maybe they'll all return IO (), I don't know). -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help with MPTC for type proofs?
On Thu, 25 May 2006, David Roundy wrote: Hi all, I've been thinking about extending some (experimental) GADT-based proof code that verifies that the darcs patch theory code is properly used. A given patch has type (Patch a b), and I'd like to be able to write something like commute :: (Patch a b, Patch b c) - (Patch a d, Patch d c) in such a way that the type system know that the type d is one particular type, uniquely determined by the types a, b and c. Currently, which I do is to make d be existential with data Pair a c where (:.) :: Patch a d - Patch d c - Pair a c commute :: Pair a c - Pair a c which prevents misuse of the returned pair, but doesn't allow proper use, for example we ought to be able to compile: test (a :. b) = do (b' :. a') - return $ commute (a :. b) (b'' :. a'') - return $ commute (a :. b) (a''' :. b''') - return $ commute (b' :. a'') return () but this will fail, because the compiler doesn't know that b' and b'' have the same type. So I'd like to write something like class Commutable a b d c commute :: Commutable a b d c = (Patch a b, Patch b c) - (Patch a d, Patch d c) But for this to work properly, I'd need to guarantee that 1. if (Commutable a b d c) then (Commutable a d b c) 2. for a given three types (a b c) there exists at most one type d such that (Commutable a b c d) I have a feeling that these may be enforceable using fundeps (or associated types?), but have pretty much no idea to approach this problem, or even if it's soluble. Keep in mind that all these types (a, b, c and d) will be phantom types. Hi David, I've quickly tried to a few alternatives in Hugs using FDs, but I've not been able to fully implement your requirement 1: 1) only FDs class Commutable a b c d | a b c - d, -- 2. a d c - b -- based on 1. + 2. but this does not enforce the existence of mirror instance Commutable a d c b. 2) FD + cyclic class hierarchy Alternatively, I wanted to write the following to capture 1.: class (Commutable a d c b) = -- 1. Commutable a b c d | a b c - d,-- 2. but this is not accepted by Hugs (or GHC) because their type inference algorithms would go into a loop: Class hierarchy for Commutable is not acyclic Perhaps some cycle detection techniques would allow type inference to deal with this sort of code? 3) FDs + Overlapping instances class CommutativePartners b d = Commutable a b c d | a b c - d -- b and d commute class Partners b d -- commutative closure of Partners class class CommutativePartners b d instance Partners b d = CommutativePartners b d instance Partners b d = CommutativePartners d b The last two instances are overlapping. GHC has a flag -fallow-overlapping-instances to allow this. This approach is not entirely safe if additional instances of CommutativePartners can be declared. Support for closed type classes is needed to prevent this. I'm not sure whether there is a way to fully realise requirement 1. AFAIK associated types are no more expressive than FDs. Cheers, Tom -- Tom Schrijvers Department of Computer Science K.U. Leuven Celestijnenlaan 200A B-3001 Heverlee Belgium tel: +32 16 327544 e-mail: [EMAIL PROTECTED] Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell RPC
S. Alexander Jacobson [EMAIL PROTECTED] wrote: Given that we have no easy way to serialize thunks, the whole RPC approach just seems wrong for Haskell. Tom Shackell is developing a simple bytecode reflection API to be implemented in the yhc compiler. This will allow the transmission of arbitrary function code across the network for execution on a remote machine, with the results fed back to the calling machine. e.g. encodeF :: (a-b) - Bytecode (a-b) dynload :: Bytecode (a-b) - (a-b) Work in progress... There are doubtless lots of security issues here, not least type safety Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] request for co-development: improving Data.CharEncoding module
On 5/26/06, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Haskell, i plan to publish new version of Streams library on next week (see http://haskell.org/haskellwiki/Library/Streams if you still don't know about it :) ). one of it's current drawbacks is lack of support for file encodings other than UTF-8 and Latin-1. if someone can work on this support, it will widen usage area of the library i attached to letter current version of this module. it uses monadic approach to encoding and decoding: each encoder is just a function that performs monadic PutChar action via calls to monadic PutByte action, and decoder in the same fashion translates each call to GetChar into calls to GetByte. this allows to use encoders in various environments - for monadic i/o, string conversion and so on this module requires two improvements - first, support for other UTF encodings; second, raising an exception in situations when data can't be encoded (such as char '\255' for Latin-1) or decoded (bad UTF bytes sequence). if you are going to work on this module, please write about this here - to avoid overlapping of work I wonder if it helps any to steal this code from Python and translate it into Haskell. /me goes back to lurking. -jj ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Keeping input separate from output?
ihope wrote: How would I keep the Foo! from conflicting with the Lorem ipsum dolor sit amet.? Well, if two millennia were not enough, I'm not sure any amount of Haskell will help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
