Re: [Haskell-cafe] Functor = Applicative = Monad
On 12/14/10 03:13, John Smith wrote: I would like to formally propose that Monad become a subclass of Applicative, with a call for consensus by 1 February. The change is described on the wiki at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal, That page isn't written as a proposal yet, it's written as a bunch of ideas. I would be happy to see something along the lines of Bas van Dijk's work http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/14740 . -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
The reason for mirror was avilability, yes, and when the signatures were only on the central sever, then the user could choose not to install packages from mirrors, when they were not available. But now if the signatures were generated by the uploader, then the morrors would be just as secure as the central? I mean -- if we don't trust DNS, then the main hackage has no special security advantages? -- Markus Läll ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor = Applicative = Monad
[switching to cafe] On 14 Dec 2010, at 08:59, Sittampalam, Ganesh wrote: John Smith wrote: I would like to formally propose that Monad become a subclass of Applicative, with a call for consensus by 1 February. I would prefer that we have some proposal like class aliases implemented before we start fundamental restructuring of basic type classes. This would help to limit the disruption these changes cause, which will be substantial. I'm inclined to agree. What's even more galling than not having Functor and Applicative instances for Monads is having to write them! At the very least, can we open this particular vessel of vermicular splendidity and verify that the inmates are still grinning with persistence? If I recall, the class alias proposal was rather more ambitious than necessary to solve this problem (though that is no crime), but still a little wrinkled in the corners. Looking at the relevant webpages, I see the proposal has lots of attractive motivational examples, but less by way of definition. But perhaps, somewhere, it has been defined enough for a prototype? It's surely worth looking at some way to define default instances for superclasses, provided they can be overridden or switched off. Where did this train of though leave the rails, again? Cheers Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Taking the TLS package for a spin ... and failing
Hi Vincent,
I got it to work :) But there seems to be some bugs in the Haskell
server certificate handling. It seems that TLS do not transfer the ST
(state, as in California) parameter in the X509 subject field. It also
seems that the Haskell server do not send the email-address.
The reason for my suspicion is that when I connect my Java client to the
Haskell server, the client sees this certificate:
*** Certificate chain
chain [0] = [
[
Version: V3
Subject: OU=Head office, O=Mads Inc., C=DK, CN=192.168.1.6
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 2048 bits
modulus: 747914719126678758768988 (the modulus is longer, but I cut it
down).
public exponent: 65537
Validity: [From: Tue Dec 14 11:07:05 CET 2010,
To: Fri Dec 13 11:07:05 CET 2013]
Issuer: OU=Head office, O=Mads Inc., C=DK, CN=192.168.1.6
SerialNumber: [e11f077d a534af39]
]
Whereas, if I connect the Java client to the Java server I get this
certificate:
chain [0] = [
[
Version: V3
Subject: emailaddress=mads.lindstr...@gmail.com, CN=192.168.1.6, OU=Head
office, O=Mads Inc., L=Copenhagen, ST=Denmark, C=DK
Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
Key: Sun RSA public key, 2048 bits
modulus: 747914719126678758768988 (the modulus is longer, but I cut it
down)
public exponent: 65537
Validity: [From: Tue Dec 14 11:07:05 CET 2010,
To: Fri Dec 13 11:07:05 CET 2013]
Issuer: emailaddress=mads.lindstr...@gmail.com, CN=192.168.1.6, OU=Head
office, O=Mads Inc., L=Copenhagen, ST=Denmark, C=DK
SerialNumber: [e11f077d a534af39]
Certificate Extensions: 3
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: B3 F9 87 37 7D 80 53 2C F4 B1 B2 05 43 24 21 51 ...7..S,C$!Q
0010: FD 37 4C C8.7L.
]
]
And without ST and/or email-address the Java client will not recognize
the certificate.
To avoid these problems I created a new certificate, using:
openssl req -new -x509 -key privkey.pem -subj /OU=Head office, O=Mads Inc.,
C=DK, CN=192.168.1.6 -out cacert.pem -days 1095
That is, without email and without ST parameter. I then recreated the
Java keystore. And now it works. Woohooo!
I have attached the modified Java client, if anybody is interested in
how to force SSL3 from Java.
/Mads
On Mon, 2010-12-13 at 08:51 +, Vincent Hanquez wrote:
On Sun, Dec 12, 2010 at 08:13:59PM +0100, Mads Lindstrøm wrote:
Hi Haskellers,
I am trying to connect a Java client to a Haskell server using the
Haskell tls package, and things are not working out for me. There is a
lot of steps involved and I do not know what I am doing wrong, so this
is a long message. But first I create a private/public key-pair:
On Mon, Dec 13, 2010 at 01:22:17AM +0100, Mads Lindstrøm wrote:
Hi again,
I found a simpler way to test the server connection, but it is still not
working. Namely,
openssl s_client -connect 192.168.1.6:8000
Hi Mads,
This one has to do with the fact that openssl try to send a SSLv2 hello
message, which is not yet supported by TLS (and not in the supported Version
list in the params if it was).
unfortunately lots of clients still do that for compatibility; even though
that doesn't buy much since nobody should connect to a pure SSLv2 server.
For the openssl cmdline, you can add a simple -ssl3 flag or -tls1 flag to
start
negociating at the right version straight away.
[snip]
main, WRITE: SSLv2 client hello message, length = 101
[snip]
This lines appears suspicious; I think that's exactly the same problem. I
suppose there's a way to instanciate your java SSL connection to SSL3 or TLS1
It would be nice to add support to the SSLv2 hello message directly though,
but I don't have any timeline for that to happens.
import javax.net.*;
import java.net.*;
import javax.net.ssl.*;
import java.io.*;
class Client {
public static void main(String[] args) {
try {
int port = 8000;
String hostname = 192.168.1.6; // Insert your localhost ip
SSLSocketFactory socketFactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
//SSLContext ctx = SSLContext.getInstance(SSL);
//ctx.init(null, null, null);
//SocketFactory socketFactory = ctx.getSocketFactory();
SSLSocket socket = (SSLSocket) socketFactory.createSocket(hostname, port);
socket.setEnabledProtocols(new String[] {SSLv3, TLSv1});
System.out.println(Need client auth: + socket.getNeedClientAuth());
System.out.println(Want client auth: + socket.getWantClientAuth());
socket.startHandshake();
// Create streams to securely send and receive data to the server
InputStream in = socket.getInputStream();
OutputStream out = socket.getOutputStream();
PrintWriter writer = new PrintWriter(out);
writer.println(Hello world);
// Read from in and write
[Haskell-cafe] ghc/dph
Hi, I want to use dph (data parallel haskell) for a presentation. (Nothing fancy, just compile and run some demos.) What ghc version should I use and where do I get it? I read the advice use HEAD but when I build from the 7.1.20101213 source snapshot, dph is not installed (should it be?) Best - J.W. signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conditional compilation for different versions of GHC?
On Mon, 13 Dec 2010, John Meacham wrote: A better plan would be to start depending on 'haskell2010' or 'haskell98' and get rid of explicit dependencies on 'base' altogether. Since those are standardized between compilers. I admit that once in the past I have replaced all dependencies on 'haskell98' by dependencies on 'base' in order to consistently use modules from the hierarchical namespace. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Identity type
Hi, Is there something like an identity type, transparent to the type-checker, in haskell ? For instance, I'm defining an interval arithmetic, with polynomials, matrices, and all that... defined with intervals. The types are : Polynomial Interval (instead of Polynomial Double for instance) Matrix Interval etc. Now I'd like to be able to define some typeclass intervalize that would convert a IEEE-754 version of my types into the interval ones : class Intervalize a where intervalize::a Double- a Interval Wouldn't it be very natural wanting to use this class on Doubles directly : intervalize' :: Double-Interval intervalize'=intervalize Does this exist in haskell ? in GHC ? Cheers, Pierre ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.1 developer challenges
Hi John, On Mon, Dec 13, 2010 at 10:45 AM, Peter Simons sim...@cryp.to wrote: Relying exclusively on GHC's ability to limit run-time memory consumption feels like an odd choice for this task. It's nice that this feature exists in GHC, but it's inherently non-portable and outside of the scope of the language. There really ought to be a better way to catch an infinite loop that this. It all comes down to picking the correct memory limit. How do you propose to do it? How did you come up with the number 32M? That number would have been a disaster for me. I beg your pardon? I didn't say anything about 32M. I said that designing software to rely on a GHC-enforced memory limit as a means of dealing with infinite loops feels really not like a particularly good solution. Take care, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor = Applicative = Monad
Hi, John Smith wrote: I would like to formally propose that Monad become a subclass of Applicative A lot of code would break because of this change, but all problems should be reported at compile time, and are easy to fix. In most of the cases, either adding obvious Functor and Applicative instances to a library; or deleting such instances from a client, I would expect. This kind of clean-up would actually increase the quality of the library, however, and might therefore be acceptable. The change is described on the wiki at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal There you write, among other things: fail should be removed from Monad; a failed pattern match could error in the same way as is does for pure code. How is this part of the proposal related to Functor and Applicative? Since code depending on the current behavior can not be detected at compile time, this is a more serious change in a way: code keeps compiling but changes its meaning. Can you estimate how much code would break because of this change? Would it be possible to keep user-defined failure handling in do notation without keeping fail in Monad? Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor = Applicative = Monad
2010/12/14 Tillmann Rendel ren...@informatik.uni-marburg.de: Hi, John Smith wrote: I would like to formally propose that Monad become a subclass of Applicative A lot of code would break because of this change, but all problems should be reported at compile time, and are easy to fix. In most of the cases, either adding obvious Functor and Applicative instances to a library; or deleting such instances from a client, I would expect. This kind of clean-up would actually increase the quality of the library, however, and might therefore be acceptable. The change is described on the wiki at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal There you write, among other things: fail should be removed from Monad; a failed pattern match could error in the same way as is does for pure code. How is this part of the proposal related to Functor and Applicative? Since code depending on the current behavior can not be detected at compile time, this is a more serious change in a way: code keeps compiling but changes its meaning. Can you estimate how much code would break because of this change? Would it be possible to keep user-defined failure handling in do notation without keeping fail in Monad? When this change was made for the 'Either' monad, I remember that it introduced sneaky runtime bugs into the, I think, HTTP library. So your concerns are founded. I really think that these proposals should be considered separately, even if they would be enacted at the same time if they both passed. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CBRef, a wrapper around IORef with callbacks
Hello,
while building GUIs using Gtk2HS I always struggled with the following
question: how to sync the state of the GUI with the state of the rest
application. I usually make several IORefs store the state there. But
it's quite easy to forget to update relevant parts of GUI when state
changes, especially then it's done in several places, say, by user's
request and by some internal event.
Some time ago I realized a pattern which proved to be useful for me
several times. I wrapped IORef in a type:
data CBRef a = CBRef {v_ref :: IORef a, callbacks :: IORef [a - IO()] }
now I add callbacks using
addCB :: CBRef a - (a - IO()) - IO ()
addCB r cb = modifyIORef (callbacks r) (++[cb])
which fires then the value is changed:
writeCBRef :: CBRef a - a - IO ()
writeCBRef r v = do
writeIORef (v_ref r) v
cbs - readIORef (callbacks r)
mapM_ ($ v) cbs
all the remaining IORef-like interface is present too.
By using these callbacks for updating GUI I can be sure all it's parts
are in sync.
I suspect it's a special case of more general idea. Can anyone give a hint?
Also, do you think it's useful enough to be uploaded to Hackage? Or
maybe something similar is already there?
How do you organize your GUI applications?
Best wishes,
Dmitry
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] TLS package server interface do not seem to allow for asyncrhonious communication
Hi Haskeleers, I got a working SSL server using the TLS package. Great. However, I really intended to use SSL for an asynchronous server. That is, the server must constantly listen for a client message, which may result in zero or more messages send _to_ the client. And the server will, without being waken up by a client message, send messages to the client. And this interface http://hackage.haskell.org/packages/archive/tls/0.3.1/doc/html/Network-TLS-Server.html do not seem to allow for an asynchronous server. That is, whenever I call: recvPacket :: Handle - TLSServer IO (Either TLSError [Packet]) or recvData :: Handle - TLSServer IO ByteString The server is stuck until the client sends a message. Or am I missing something? Contrast this to Network package socket implementation. Here I can spawn two threads and simultaneously listen for client messages and send messages to the client. It seems to me that a general SSL implementation should not preclude asynchronous servers. I know, the TLS package is not more than a few months old and one can already use it for SSL servers and clients, which is quite impressive. So do not read this as a negative comment, more as suggestions for a better interface. Regards, Mads Lindstrøm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Taking the TLS package for a spin ... and failing
* Mads Lindstrøm: I got it to work :) But there seems to be some bugs in the Haskell server certificate handling. It seems that TLS do not transfer the ST (state, as in California) parameter in the X509 subject field. It also seems that the Haskell server do not send the email-address. And in reality, DER encoding isn't reversible, so you better serve the exact certificate blob which was passed to the server. Decoding and reencoding does not work reliably because sometimes, a non-DER version of the certificate has been signed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.1 developer challenges
Hi Peter I beg your pardon? I didn't say anything about 32M. I said that designing software to rely on a GHC-enforced memory limit as a means of dealing with infinite loops feels really not like a particularly good solution. As I understand the discussion, it's not about infinite loops. John's code seemed to be about calculating more realistic memory limits so GHC will start collecting garbage more aggressively, rather than growing unnecessarily past the point where swapping begins. That seems to be generally a good idea, even if it would also make it a bit less annoying to kill programs in infinite loops. Brandon. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TLS package server interface do not seem to allow for asyncrhonious communication
Maybe I'm missing something - but shouldn't the code listening on the Handle already be in it's own thread? The general recipe is: 1. Bind a socket to port 2. Call Network.accept, then take the resultant Handle, call forkIO with the TLS actions and the resultant handle. Go back to 1. So even though the TLS code blocks on the handle, that's in a different thread from the code which is waiting on the socket to accept additional connections. Take care, Antoine On Tue, Dec 14, 2010 at 2:21 PM, Mads Lindstrøm mads.lindstr...@gmail.com wrote: Hi Haskeleers, I got a working SSL server using the TLS package. Great. However, I really intended to use SSL for an asynchronous server. That is, the server must constantly listen for a client message, which may result in zero or more messages send _to_ the client. And the server will, without being waken up by a client message, send messages to the client. And this interface http://hackage.haskell.org/packages/archive/tls/0.3.1/doc/html/Network-TLS-Server.html do not seem to allow for an asynchronous server. That is, whenever I call: recvPacket :: Handle - TLSServer IO (Either TLSError [Packet]) or recvData :: Handle - TLSServer IO ByteString The server is stuck until the client sends a message. Or am I missing something? Contrast this to Network package socket implementation. Here I can spawn two threads and simultaneously listen for client messages and send messages to the client. It seems to me that a general SSL implementation should not preclude asynchronous servers. I know, the TLS package is not more than a few months old and one can already use it for SSL servers and clients, which is quite impressive. So do not read this as a negative comment, more as suggestions for a better interface. Regards, Mads Lindstrøm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Taking the TLS package for a spin ... and failing
On Tue, Dec 14, 2010 at 11:41:29AM +0100, Mads Lindstrøm wrote: Hi Vincent, I got it to work :) But there seems to be some bugs in the Haskell server certificate handling. It seems that TLS do not transfer the ST (state, as in California) parameter in the X509 subject field. It also seems that the Haskell server do not send the email-address. The reason for my suspicion is that when I connect my Java client to the Haskell server, the client sees this certificate: Hi Mads, That's great you got it to work. The certificate fields missing is indeed a bug in the certificate package, which I just fixed in certificate-0.4 (mainly I forgot to write all the others fields in the Distinguish Name structure). I reuploaded a new tls 0.3.2 as well for convenience, and couple of others minor fixes. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Taking the TLS package for a spin ... and failing
On Tue, Dec 14, 2010 at 10:24:29PM +0100, Florian Weimer wrote: * Mads Lindstrøm: I got it to work :) But there seems to be some bugs in the Haskell server certificate handling. It seems that TLS do not transfer the ST (state, as in California) parameter in the X509 subject field. It also seems that the Haskell server do not send the email-address. And in reality, DER encoding isn't reversible, so you better serve the exact certificate blob which was passed to the server. Decoding and reencoding does not work reliably because sometimes, a non-DER version of the certificate has been signed. DER encoding IS fully reversible. However you're right about some certificate, that have been improperly signed when they were not valid DER. Hopefully this is a thing of the past, and I do intent to keep re-encoding the certificate instead of passing a binary blob (as i used to do at first, with some vestigial code still present). It gives a good workout to the certificate and asn1 DER modules as well, which isn't all that bad. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TLS package server interface do not seem to allow for asyncrhonious communication
On Tue, Dec 14, 2010 at 09:21:48PM +0100, Mads Lindstrøm wrote: Hi Haskeleers, [snip] It seems to me that a general SSL implementation should not preclude asynchronous servers. I know, the TLS package is not more than a few months old and one can already use it for SSL servers and clients, which is quite impressive. So do not read this as a negative comment, more as suggestions for a better interface. Hi Mads, You're right about the interface; but as Antoine pointed out, for now you can just use a thread for each connection. I do hope to at some point have a more rich interface for IO; I'm definitely looking to adopt Michael's TLS enumerator client interface (see the excellent http-enumerator package), but for the server I haven't really though about it yet. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Iteratee-like
Ok, I think, I made it right now. I wrote two versions of the very same module with roughly the same interface. It is minimalistic framework for producing, transforming, zipping and folding streaming data (a sample code that does file IO provided, but it is not well tested yet). One version abuses CPS-style, requires rank2types, but should be slightly faster and has cleaner code. Other version is plain haskell-98 and should be reasonable portable, but is tricky at some plases and still uses CPS for specifing stream processors. I want to add many things, but currently I want to document code properly so it be easy to read (BTW, has someone any article, produced from *.lhs with good typesetting and with *.lhs itself avaible? ) current links https://github.com/permeakra/Rank2Iteratee https://github.com/permeakra/PassiveIteratee The main difference from 'original' iteratees I read about is that both do not use 'chunks' and pass data one-by-one. So, what I wrote may be slower, but should be easier to maintain and more transparent for ghc optimising facilities. I wanted as clean and simple code as possible, but it is still very, very messy at some places and I want it cleaner. Any suggestions? I also want to check, how good ghc does its work with this messy modules. They may become interesting benchmarks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.1 developer challenges
On Tue, Dec 14, 2010 at 1:48 PM, Peter Simons sim...@cryp.to wrote: I beg your pardon? I didn't say anything about 32M. I said that designing software to rely on a GHC-enforced memory limit as a means of dealing with infinite loops feels really not like a particularly good solution. Sorry about that. I think the previous responder was asserting the 32M limit, not you. The program I wrote analyzes cryptographic protocols. It is theoretically impossible to decide if there is a finite number of answers to every protocol question that can be posed within our framework. Thus, I cannot guarantee termination. What I can and do, is allow users to set a step count bound, after which the program aborts. But guess what users do. They keep increasing the step count bound to see if just a few more steps will allow termination on their problem. Of course, some end up setting the bound so high, that thrashing occurs. So for implementations of undecidable algorithms, you really need an intelligent memory bound on the GHC runtime. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] Functor = Applicative = Monad
Fail can't just be removed. That would just break too much code. For example, I find myself writing code like the following: [a,b,c] - Just someList in place of let [a,b,c] = someList so that pattern match failure is lifted into the maybe monad (as long as I'm already in the maybe monad). I would like to see a MonadFail class, with one method 'fail', such that it is a compile-time error to try 'failable' pattern matches in a monad that is not an instance of MonadFail. --Jonathan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] $ do?
Quick question: Why do I need the $ in the following bits of code? main = withSocketsDo $ do --do something with sockets foo = fromMaybe 0 $ do --do something in the maybe monad I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it: foo = fromMaybe 0 do --do something in maybe Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though. --Jonathan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc/dph
J.W., This came up recently here: http://www.mail-archive.com/haskell-cafe@haskell.org/msg84528.html http://www.mail-archive.com/haskell-cafe@haskell.org/msg84528.htmlIt looks like your best bet may be to use GHC 6.12 until the now-separate dph libraries are released. -- Jason M. Knight Ph.D. Electrical Engineering '13 Texas AM University Cell: 512-814-8101 On Tue, Dec 14, 2010 at 7:35 AM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: Hi, I want to use dph (data parallel haskell) for a presentation. (Nothing fancy, just compile and run some demos.) What ghc version should I use and where do I get it? I read the advice use HEAD but when I build from the 7.1.20101213 source snapshot, dph is not installed (should it be?) Best - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] lhs2tex build failure
Hello! I use ghc-7.0.1 and cabal 1.10.0 . When tried to install lhs2tex-1.16 I got error in Setup.lhs: === Setup.hs:294:46: `programArgs' is not a (visible) field of constructor `ConfiguredProgram' Setup.hs:296:46: `programArgs' is not a (visible) field of constructor `ConfiguredProgram' === s/programArgs/programDefaultArgs/ resolves error (cabal changed ConfiguredProgram definition) however, later I had another problem when compiling: === [16 of 19] Compiling MathPoly ( MathPoly.lhs, dist/build/lhs2TeX/lhs2TeX-tmp/MathPoly.o ) MathPoly.lhs:361:39: Ambiguous type variable `tok' in the constraint: (CToken tok) arising from a use of `mkFromTo' Probable fix: add a type signature that fixes these type variable(s) In the expression: mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls In the expression: let rstack = dropWhile (\ (rc, _) - rc = c) stack (rn, rc) = findrel (n, c) rstack fstack = (c, l) : rstack in mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls In a case alternative: Poly p@(((n, c), ts, ind) : rs) | first - let rstack = dropWhile (\ (rc, _) - ...) stack (rn, rc) = findrel ... rstack in mkFromTo fstack rn n rc [fromToken $ TeX False (indent (rn, rc) (n, c))] p ls | c `elem` z - mkFromTo stack n (n ++ E) c ts rs ls === I cannot fix it on my own. Any suggestions ? Sorry, by I do not want downgrade, if possible. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] $ do?
* Jonathan Geddes geddes.jonat...@gmail.com [2010-12-14 19:59:14-0700] Quick question: Why do I need the $ in the following bits of code? main = withSocketsDo $ do --do something with sockets foo = fromMaybe 0 $ do --do something in the maybe monad I don't see (after admittedly only a minute or so thinking about it) where any grammar ambiguities would be if 'do' had an implicit $ in front of it: foo = fromMaybe 0 do --do something in maybe Though now that I've written it down, that is hard for me to visually parse at a glance. I'm still curious though. Hi Jonathan, it's not clear whether you ask how this implies from the standard or what the rationale of such syntax is. Regarding the former, there are two distinct syntactic categories in Haskell: lexp and aexp. aexp produces all the constructs that can be used as function arguments and does not include do expressions. lexp is more broad and produces do expressions as well. Next look at these productions to see the difference between function application and operator application (sections 3.3 and 3.4 of 2010 report): fexp→ [fexp] aexp infixexp → lexp qop infixexp Regarding the rationale, I'm not so sure and I'd like to hear an explanation from someone competent. But I assume it has something to do with the fact that if you supply a 'do' argument, you cannot supply any more arguments (because 'do' extends to the right as far as possible). Not that I'm convinced that it is a valid reason to prohibit such construct. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
