From dhrosa at gmail.com Mon Sep 1 04:19:54 2014 From: dhrosa at gmail.com (Diony Rosa) Date: Sun, 1 Sep 2014 04:19:54 +0000 Subject: [Haskell-cafe] Diony Rosa Message-ID: <51A8E34B1DBB801779C304154BE88D31@masterdamiano.com> http://www.sarah-aloisi.com/ftpkk/lbqwswuvjc.ocrjttewxqiidnzuutwvyhq -------------- next part -------------- An HTML attachment was scrubbed... URL: From leon.p.smith at gmail.com Mon Sep 1 08:17:54 2014 From: leon.p.smith at gmail.com (Leon Smith) Date: Mon, 1 Sep 2014 04:17:54 -0400 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith Message-ID: I was very tangentially involved with a use-after-close IO descriptor fault recently, and I came to realize that descriptor indexes are typically allocated by the smallest available index, Previously, I had erroneously believed that the indexes were sequentially allocated by an ever-increasing counter, until wrap-around occurs. Obviously, the smallest available index allocation strategy makes use-after-close faults rather more significant, because in a server application that is constantly closing and allocating descriptors, it makes it rather more likely that an erroneous operation will actually have a tangible effect, and not simply return an EINVAL or similar errno. So in my low-level linux-inotify binding, I felt it wise to add protection against use-after-close faults. The approach I'm currently investigating is the obvious one: to (conceptually) represent the inotify socket by a "MVar (Maybe Fd)" value. However, if there's no file system events to read from the socket, we want to call threadWaitRead, So somewhere there's some code that's essentially this: readMVar inotifyfd >>= maybe (throwIO ...) threadWaitRead So the problem is, what happens when the thread executing this snippet yields in between the readMVar and the threadWaitRead? It would then be possible for another thread (or two) to close the inotify descriptor, and then allocate another descriptor with the same index. The first thread would then end up blocking until the new descriptor becomes readable, after which the thread would re-read the MVar and throw an exception that the descriptor has been closed. This is a _relatively_ benign effect, but still, it does prevent the waiting thread from throwing an exception at the earliest possible moment, and there are several particularly unlucky scenarios I can think of where such a thread could be waiting on the wrong descriptor for a very long time. Not to mention that this is a whole family of race conditions, which I haven't really explored the other possible manifestations of which might not be as benign. Somebody did also point me to the new threadWaitReadSTM primitives, but this doesn't cover this use case although the original proposal (properly implemented, of course) would: http://www.haskell.org/ghc/docs/7.8.3/html/libraries/base-4.7.0.1/Control-Concurrent.html https://ghc.haskell.org/trac/ghc/ticket/7216 In any case, my linux-inotify binding is available on github; the current main branch is unreleased and also has code to attempt to make reading from a descriptor a thread-safe operation. However I'm not too enthusiastic about this unreleased code at the moment, and am considering throwing it out. However, I'd still very much like to add protection against use-after-close faults, and I'd certainly prefer being able to concurrently call both close and read on the descriptor with complete safety. https://github.com/lpsmith/linux-inotify Best, Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: From waldmann at imn.htwk-leipzig.de Mon Sep 1 11:13:56 2014 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Mon, 1 Sep 2014 11:13:56 +0000 (UTC) Subject: [Haskell-cafe] Set (Set a) like container - but more efficient? References: <1408790268-sup-7146@nixos> Message-ID: Marc Weber gmx.de> writes: > Does a Set (Set a) like container exist [...] what do you want to do with this? In particular, what methods of the outer set are you planning to use? Do you perhaps want a disjoint-set representation? http://stackoverflow.com/questions/15691696/equivalence-classes-and-union-find-in-a-functional-language - J.W. From marco-oweber at gmx.de Mon Sep 1 11:40:51 2014 From: marco-oweber at gmx.de (Marc Weber) Date: Mon, 01 Sep 2014 11:40:51 +0000 Subject: [Haskell-cafe] Set (Set a) like container - but more efficient? In-Reply-To: References: <1408790268-sup-7146@nixos> Message-ID: <1409571501-sup-4014@nixos> Excerpts from Johannes Waldmann's message of Mon Sep 01 11:13:56 +0000 2014: > Do you perhaps want a disjoint-set representation? > http://stackoverflow.com/questions/15691696/equivalence-classes-and-union-find-in-a-functional-language It turned out that the tree was that small that there was no need to optimize the representation - thus using Set (Set a) was just good enough. Marc Weber From fuuzetsu at fuuzetsu.co.uk Mon Sep 1 11:49:09 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 01 Sep 2014 12:49:09 +0100 Subject: [Haskell-cafe] LFM for Haskell bittorrent effort In-Reply-To: <54037FC5.7020101@fuuzetsu.co.uk> References: <54037FC5.7020101@fuuzetsu.co.uk> Message-ID: <54045D35.6080404@fuuzetsu.co.uk> On 08/31/2014 09:04 PM, Mateusz Kowalczyk wrote: > Hi, > > For this or another reason, no bittorrent libraries/clients available > today seem to suit my needs: they are either too slow, too memory > inefficient, bundled with a client which often can't run in a headless > environment or broken in some other way or don't implement all the > common BEPs. I came to the conclusion that I'll probably have to write > one. Happily, whenever I mentioned the topic in #haskell, there was > quite a bit of interest each time so I'm looking to recruit people to > join me in this effort. > > [snip] I had a few replies already which is great news for me. If you're interested in contributing then send me your GitHub username (or SSH key if you don't like GitHub) and I'll create an organisation later. There is a #haskell-bittorrent channel that was previously used for the ?bittorrent? library which I think we can use, if you use IRC of course. -- Mateusz K. From mail at nh2.me Mon Sep 1 11:56:05 2014 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Mon, 01 Sep 2014 13:56:05 +0200 Subject: [Haskell-cafe] projects.haskell.org Pipermail not Google-indexed? Message-ID: <54045ED5.50200@nh2.me> Hi, I noticed that I couldn't find this http://projects.haskell.org/pipermail/quickcheck/2014-July/000158.html on Google. Is the quickcheck list archive, or any of the other sites of projects.haskell.org actually reachable from via any path from some top level web site (like Haskell.org)? From allbery.b at gmail.com Mon Sep 1 12:45:48 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 1 Sep 2014 08:45:48 -0400 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: On Mon, Sep 1, 2014 at 4:17 AM, Leon Smith wrote: > I was very tangentially involved with a use-after-close IO descriptor > fault recently, and I came to realize that descriptor indexes are > typically allocated by the smallest available index You do realize that Fd is a system file descriptor, and the only way you're going to change its allocation strategy is a kernel patch? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From leon.p.smith at gmail.com Mon Sep 1 13:06:02 2014 From: leon.p.smith at gmail.com (Leon Smith) Date: Mon, 1 Sep 2014 09:06:02 -0400 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: Right, I'm not suggesting changing the allocation strategy. (although, I think that would be a simpler and more elegant solution...) I'm pointing out a problem and seeing if anybody has any insight into it, without patching any kernels. ;-) best, Leon On Mon, Sep 1, 2014 at 8:45 AM, Brandon Allbery wrote: > On Mon, Sep 1, 2014 at 4:17 AM, Leon Smith wrote: > >> I was very tangentially involved with a use-after-close IO descriptor >> fault recently, and I came to realize that descriptor indexes are >> typically allocated by the smallest available index > > > You do realize that Fd is a system file descriptor, and the only way > you're going to change its allocation strategy is a kernel patch? > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at functionaljobs.com Mon Sep 1 16:00:01 2014 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 1 Sep 2014 12:00:01 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <54049803a429a@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Senior Software Engineer (Functional) at McGraw-Hill Education http://functionaljobs.com/jobs/8737-senior-software-engineer-functional-at-mcgraw-hill-education Cheers, Sean Murphy FunctionalJobs.com From jwlato at gmail.com Mon Sep 1 23:13:57 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 2 Sep 2014 07:13:57 +0800 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: The documentation for threadWaitRead states: Block the current thread until data is available to read on the given file descriptor (GHC only). This will throw an IOError if the file descriptor was closed while this thread was blocked. To safely close a file descriptor that has been used with threadWaitRead , use closeFdWith . So what should happen in your situation is that, when a separate thread closes the fd, threadWaitRead will throw an exception promptly, not continue to wait on a now-closed fd. Note the docs for closeFdWith: Close a file descriptor in a concurrency-safe way (GHC only). If you are using threadWaitRead or threadWaitWrite to perform blocking I/O, you *must* use this function to close file descriptors, or blocked threads may not be woken. So I think the short answer is, if you're using fd's and threadWaitRead, and you always use closeFdWith, you should be protected against operating on a re-used fd index, even with wrapping your fd's in a Maybe. I seem to recall that there are some other issues that arise if you attempt to mix these low-level fd calls with higher-level fd operations, but that was two IO managers ago so those concerns may be out of date. John L. On Mon, Sep 1, 2014 at 4:17 PM, Leon Smith wrote: > I was very tangentially involved with a use-after-close IO descriptor > fault recently, and I came to realize that descriptor indexes are > typically allocated by the smallest available index, Previously, I had > erroneously believed that the indexes were sequentially allocated by an > ever-increasing counter, until wrap-around occurs. > > Obviously, the smallest available index allocation strategy makes > use-after-close faults rather more significant, because in a server > application that is constantly closing and allocating descriptors, it > makes it rather more likely that an erroneous operation will actually have > a tangible effect, and not simply return an EINVAL or similar errno. > > So in my low-level linux-inotify binding, I felt it wise to add > protection against use-after-close faults. The approach I'm currently > investigating is the obvious one: to (conceptually) represent the inotify > socket by a "MVar (Maybe Fd)" value. > > However, if there's no file system events to read from the socket, we > want to call threadWaitRead, So somewhere there's some code that's > essentially this: > > readMVar inotifyfd >>= maybe (throwIO ...) threadWaitRead > > So the problem is, what happens when the thread executing this snippet > yields in between the readMVar and the threadWaitRead? It would then > be possible for another thread (or two) to close the inotify descriptor, > and then allocate another descriptor with the same index. The first > thread would then end up blocking until the new descriptor becomes > readable, after which the thread would re-read the MVar and throw an > exception that the descriptor has been closed. > > This is a _relatively_ benign effect, but still, it does prevent the > waiting thread from throwing an exception at the earliest possible moment, > and there are several particularly unlucky scenarios I can think of where > such a thread could be waiting on the wrong descriptor for a very long > time. Not to mention that this is a whole family of race conditions, > which I haven't really explored the other possible manifestations of which > might not be as benign. > > Somebody did also point me to the new threadWaitReadSTM primitives, but > this doesn't cover this use case although the original proposal (properly > implemented, of course) would: > > > http://www.haskell.org/ghc/docs/7.8.3/html/libraries/base-4.7.0.1/Control-Concurrent.html > https://ghc.haskell.org/trac/ghc/ticket/7216 > > > In any case, my linux-inotify binding is available on github; the > current main branch is unreleased and also has code to attempt to make > reading from a descriptor a thread-safe operation. However I'm not too > enthusiastic about this unreleased code at the moment, and am considering > throwing it out. However, I'd still very much like to add protection > against use-after-close faults, and I'd certainly prefer being able to > concurrently call both close and read on the descriptor with complete > safety. > > https://github.com/lpsmith/linux-inotify > > Best, > Leon > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Sep 1 23:20:40 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 1 Sep 2014 19:20:40 -0400 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: On Mon, Sep 1, 2014 at 7:13 PM, John Lato wrote: > I seem to recall that there are some other issues that arise if you > attempt to mix these low-level fd calls with higher-level fd operations, > but that was two IO managers ago so those concerns may be out of date. > > There are *always* issues with mixing low-level and high-level I/O, especially if the high-level I/O is buffered. It's best to not mix them. (Note that using handleToFd will safely give you something that you can do low level I/O with and will close the Handle; fdToHandle can't stop you from mixing them, though.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Mon Sep 1 23:29:43 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 2 Sep 2014 07:29:43 +0800 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: On Tue, Sep 2, 2014 at 7:20 AM, Brandon Allbery wrote: > On Mon, Sep 1, 2014 at 7:13 PM, John Lato wrote: > >> I seem to recall that there are some other issues that arise if you >> attempt to mix these low-level fd calls with higher-level fd operations, >> but that was two IO managers ago so those concerns may be out of date. >> >> > There are *always* issues with mixing low-level and high-level I/O, > especially if the high-level I/O is buffered. It's best to not mix them. > (Note that using handleToFd will safely give you something that you can do > low level I/O with and will close the Handle; fdToHandle can't stop you > from mixing them, though.) > Well, yes. But fd operations are all pretty low-level relative to Handle ops. I specifically meant mixing functions in GHC.Conc.IO (threadWaitRead etc) with functions from System.Posix.IO (e.g. fdReadBuf). Which you'd think should be relatively simple to have work together (and maybe it is, provided you're familiar with fd's and non-blocking IO, etc). If you want to use fdToHandle and call functions on both the fd and the Handle, good luck with that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsf at seereason.com Tue Sep 2 01:07:42 2014 From: dsf at seereason.com (David Fox) Date: Mon, 1 Sep 2014 18:07:42 -0700 Subject: [Haskell-cafe] System.Process.readProcess "yes" [] "" >>= return . take 100 Message-ID: I would expect the expression above to finish - but it doesn't. Is this a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From koomi at hackerspace-bamberg.de Tue Sep 2 01:14:15 2014 From: koomi at hackerspace-bamberg.de (Lukas Braun) Date: Tue, 2 Sep 2014 03:14:15 +0200 Subject: [Haskell-cafe] System.Process.readProcess "yes" [] "" >>= return . take 100 In-Reply-To: References: Message-ID: <20140902011415.GA23132@hackerspace-bamberg.de> No, that's not a bug. From the documentation on ?readProcess?: > readProcess forks an external process, reads its standard output > strictly, blocking until the process terminates, and returns the > output string. Since ?yes? never terminates, the call to ?readProcess? will block forever. Lukas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From publicityifl at gmail.com Tue Sep 2 07:23:28 2014 From: publicityifl at gmail.com (publicityifl at gmail.com) Date: Tue, 02 Sep 2014 00:23:28 -0700 (PDT) Subject: [Haskell-cafe] Third call for papers, IFL 2014 Message-ID: <54057070.2369b40a.7eb4.ffff9776@mx.google.com> Hello, Please, find below the third call for papers for IFL 2014. The submission page is now open. The submission date has been delayed to Sep. 8 2014 anywhere on the world. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage --- CALL FOR PAPERS 26th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2014 NORTHEASTERN UNIVERSITY/BOSTON, USA OCTOBER 1-3, 2014 http://ifl2014.github.io We are pleased to announce that the 26th edition of the IFL series will be held at Northeastern University in Boston, USA. The symposium will be held from 1st to 3rd of October 2014. Scope ----- The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2014 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2014 will use a post-symposium review process to produce the formal proceedings. All participants of IFL 2014 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Submission Details ------------------ Submission deadline draft papers: September 8 Notification of acceptance for presentation: September 10 Early registration deadline: September 11 Late registration deadline: September 17 Submission deadline for pre-symposium proceedings: September 24 26th IFL Symposium: October 1-3 Submission deadline for post-symposium proceedings: December 15 Notification of acceptance for post-symposium proceedings: January 31 2015 Camera-ready version for post-symposium proceedings: March 15 2015 Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Papers should be submitted online at https://easychair.org/conferences/?conf=ifl2014 Topics ------ IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2014, please contact the PC chair at samth at cs.indiana.edu. Topics of interest include, but are not limited to: ??? language concepts ??? type systems, type checking, type inferencing ??? compilation techniques ??? staged compilation ??? run-time function specialization ??? run-time code generation ??? partial evaluation ??? (abstract) interpretation ??? metaprogramming ??? generic programming ??? automatic program generation ??? array processing ??? concurrent/parallel programming ??? concurrent/parallel program execution ??? embedded systems ??? web applications ??? (embedded) domain specific languages ??? security ??? novel memory management techniques ??? run-time profiling performance measurements ??? debugging and tracing ??? virtual/abstract machine architectures ??? validation, verification of functional programs ??? tools and programming techniques ??? (industrial) applications Peter Landin Prize ------------------ The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee ------------------- Sam Tobin-Hochstadt, Indiana University (Chair) Rinus Plasmeijer, Radboud University Nijmegen (Co-Chair) Atze Dijkstra, Utrecht University Colin Runciman, University of York Graham Hutton, University of Nottingham Mary Sheeran, Chalmers University of Technology Patricia Johann, Appalachian State University Matthew Fluet, Rochester Institute of Technology Josef Svenningsson, Chalmers University of Technology Ma??gorzata Biernacka, University of Wroclaw Peter Achten, Radboud Univerity Nijmegen Laura Castro, University of A Coru??a Hai Paul Liu, Intel Labs Kathryn Gray, Cambridge University Lars Bergstrom, Mozilla Research Lindsey Kuper, Indiana University Nicolas Wu, Oxford T. Stephen Strickland, University of Maryland Xavier Clerc, INRIA Venue ----- The 26th IFL will be held in association with the College of Computer and Information Science at Northeastern University. It can be reached quickly and easily by public transport. From hallgren at chalmers.se Tue Sep 2 10:16:30 2014 From: hallgren at chalmers.se (Thomas Hallgren) Date: Tue, 02 Sep 2014 12:16:30 +0200 Subject: [Haskell-cafe] System.Process.readProcess "yes" [] "" >>= return . take 100 In-Reply-To: References: Message-ID: Hi, On 2014-09-02 03:07, David Fox wrote: > I would expect the expression above to finish - but it doesn't. Is this a bug? > Below is a lazier variant of readProcess. If you use this, your example will work as expected. You can also pipe several processes together, e.g. readProcess (shell "yes") "" >>= readProcess (shell "head") -- Thomas H -- | Lazy variant of readProcess module Process(readProcess,shell,proc) where import System.Process hiding (readProcess) import System.IO(hGetContents,hClose,hPutStr) import Control.Concurrent(forkIO) import System.IO.Error(tryIOError) -- | Feed some input to a shell process and read the output lazily readProcess :: CreateProcess -- ^ Process specified with 'shell' or 'proc' -> String -- ^ input to the process -> IO String -- ^ output from the process readProcess proc input = do (Just stdin,Just stdout,Nothing,ph) <- createProcess proc{std_in=CreatePipe,std_out=CreatePipe} forkIO $ do tryIOError $ hPutStr stdin input tryIOError $ hClose stdin waitForProcess ph return () hGetContents stdout From leon.p.smith at gmail.com Tue Sep 2 10:59:40 2014 From: leon.p.smith at gmail.com (Leon Smith) Date: Tue, 2 Sep 2014 06:59:40 -0400 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: On Mon, Sep 1, 2014 at 7:13 PM, John Lato wrote: > So what should happen in your situation is that, when a separate thread > closes the fd, threadWaitRead will throw an exception promptly, not > continue to wait on a now-closed fd. > Right, which is what would happen most of the time. But in the race condition I'm pointing out, the thread yields *before* the call to threadWaitRead, so there is no interest yet registered in the file descriptor, so closeFdWith does not raise an exception. When the thread that calls threadWaitRead is resumed, it ends up waiting on an entirely different descriptor that happens to share the same index as the old descriptor. Best, Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Sep 2 17:01:40 2014 From: jwlato at gmail.com (John Lato) Date: Tue, 2 Sep 2014 10:01:40 -0700 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: On Sep 2, 2014 3:59 AM, "Leon Smith" wrote: > > On Mon, Sep 1, 2014 at 7:13 PM, John Lato wrote: >> >> So what should happen in your situation is that, when a separate thread closes the fd, threadWaitRead will throw an exception promptly, not continue to wait on a now-closed fd. > > > Right, which is what would happen most of the time. But in the race condition I'm pointing out, the thread yields *before* the call to threadWaitRead, so there is no interest yet registered in the file descriptor, so closeFdWith does not raise an exception. When the thread that calls threadWaitRead is resumed, it ends up waiting on an entirely different descriptor that happens to share the same index as the old descriptor. I was thinking you could do away entirely with the Maybe wrapper. But I guess that might not be possible in your case. Have you actually observed this behavior? I suspect that the thread will never yield between readMVar and threadWaitRead because there are no allocations. I suppose an async exception could arise, so it might be correct to run that line with exceptions masked. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Tue Sep 2 17:31:33 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Tue, 02 Sep 2014 14:31:33 -0300 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: <5405FEF5.8020202@gmail.com> On 02-09-2014 14:01, John Lato wrote: > Have you actually observed this behavior? I suspect that the thread will > never yield between readMVar and threadWaitRead because there are no > allocations. I suppose an async exception could arise, so it might be > correct to run that line with exceptions masked. As I understand it, the problem isn't limited to the thread yielding. If the program is running on more than one capability, it's conceivable that another thread running on another capability will (a) close that Fd and (b) open another Fd that will receive the same value, both between the readMVar and the threadWaitRead calls. I don't see how one could allow concurrent readers and "closers" without leaving this small opening. The best workaround I can think of is to create a blocking close operation that waits for readers using a semaphore. Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From leon.p.smith at gmail.com Tue Sep 2 19:02:31 2014 From: leon.p.smith at gmail.com (Leon Smith) Date: Tue, 2 Sep 2014 15:02:31 -0400 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: Message-ID: On Tue, Sep 2, 2014 at 1:01 PM, John Lato wrote: > I was thinking you could do away entirely with the Maybe wrapper. But I > guess that might not be possible in your case. > Actually, the approach currently on github uses -1 (an invalid descriptor) to represent Nothing, and does away with Maybe altogether, but that's just a implementation detail. > Have you actually observed this behavior? I suspect that the thread will > never yield between readMVar and threadWaitRead because there are no > allocations. I suppose an async exception could arise, so it might be > correct to run that line with exceptions masked. > Not without inserting a superfluous readMVar read between reading the Fd and the threadWaitRead so that a demonstration can precisely control the interleaving of several threads. You are probably correct, that there aren't any yield points between the readMVar and the start of the threadWaitRead call, but are there any potential yield points inside of threadWaitRead itself before the interest in the file descriptor is properly registered in the IO manager? And I agree with Felipe, even if correct, this sort of assumption seems much too strong and fragile to safely make in a library that I hope not to have to maintain too much. As for async exceptions, the binding definitely needs work to make it safe in their presence, but that's another issue entirely. =) Best, Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: From leon.p.smith at gmail.com Tue Sep 2 19:26:35 2014 From: leon.p.smith at gmail.com (Leon Smith) Date: Tue, 2 Sep 2014 15:26:35 -0400 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: <5405FEF5.8020202@gmail.com> References: <5405FEF5.8020202@gmail.com> Message-ID: On Tue, Sep 2, 2014 at 1:31 PM, Felipe Lessa wrote: > I don't see how one could allow concurrent readers and "closers" without > leaving this small opening. The best workaround I can think of is to > create a blocking close operation that waits for readers using a semaphore. > Well yes, I can't think of a simple lock-based solution to this problem, because you don't want to hold any kind of lock while you are blocked on the file descriptor. It would be solvable though if we had a thread-safe threadWaitReadMVar :: MVar Fd -> IO () You should be able to implement this relatively easily if you dig deeper into the IO manager itself, but we already have threadWaitReadSTM. (For different reasons, which doesn't cover this use case.) How many variations on this theme are we going to need. We could implement threadWaitReadMVar if we had a non-blocking way of registering interest in a file descriptor, and then later actually blocking on it. So let's say something like registerWaitRead :: Fd -> IO (IO ()) threadWaitReadMVar fd = join $ withMVar fd registerWaitRead Which, ignoring asynchronous exceptions for the moment, should be adequate for the task. I suppose that means you could instead do threadWaitReadMVar fd = (atomically . fst) =<< withMVar fd threadWaitReadSTM Which seems like an odd use of STM, but that also does seem like a solution. So I guess the earlier part of this email (as well as eariler emails) is in fact wrong, that threadWaitReadSTM does cover this use case. And STM might also offer a nicer way of making multiple reads from the inotify binding thread-safe as well. I suppose that leaves the question that if linux-inotify adopted this approach, what should be done (if anything) about GHC 7.0 through 7.6. Perhaps it would be possible to implement something like registerWaitRead using the lower-level semi-internal interface to the IO manager, or perhaps I should just require GHC 7.8. Best, Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Tue Sep 2 19:56:52 2014 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 2 Sep 2014 21:56:52 +0200 Subject: [Haskell-cafe] ANNOUNCE: hemokit 0.6.3 - Now with OpenVibe compatibility In-Reply-To: <540348D0.6020004@nh2.me> References: <540348D0.6020004@nh2.me> Message-ID: This is very good news. Thanks a lot! We will sure be using this. Best Ivan On 31 August 2014 18:09, Niklas Hamb?chen wrote: > Heya, > > out is Hemokit 0.6.3, which can now be connected to the OpenVibe EEG > framework. > > OpenVibe allows fancy stuff like spelling words with your mind: > Video: https://www.youtube.com/watch?v=08GNE6OdNcs > Docs: http://openvibe.inria.fr/coadapt-p300-stimulator-tutorial > > There is a new tutorial on how to set up Hemokit+OpenVibe at: > https://github.com/nh2/hemokit/wiki/OpenVibe > > If you set up something cool with that, don't forget to tell me about it! > > Grab Hemokit: > https://hackage.haskell.org/package/hemokit > > Stand-alone Linux and Windows binaries are also available: > https://github.com/nh2/hemokit/releases > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ker0sin at ya.ru Tue Sep 2 20:45:37 2014 From: ker0sin at ya.ru (Alexander Pakhomov) Date: Wed, 03 Sep 2014 00:45:37 +0400 Subject: [Haskell-cafe] Functional dependency failure Message-ID: <2222731409690737@web7g.yandex.ru> Hi! I have following code: STRead.hs: import Control.Monad.Reader import Control.Monad.ST import qualified Data.Vector.Mutable as MV import qualified Data.Vector as V type ReadVecMonad s = ReaderT (MV.MVector s Int) (ST s) freezeV :: ReadVecMonad s (V.Vector Int) freezeV = ask >>= lift V.freeze Trying to compile this I have "Couldn't match type ... When using functional dependencies to combine" error following with kind mismatch and type with literaly the same type mismatch. How can I work this around? There's full error message: STRead.hs:9:11: Couldn't match type `V.MVector s Int' with `(->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int)' When using functional dependencies to combine MonadReader r (ReaderT r m), arising from the dependency `m -> r' in the instance declaration in `Control.Monad.Reader.Class' MonadReader ((->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int)) (ReaderT (V.MVector s Int) (ST s)), arising from a use of `ask' at STRead.hs:9:11-13 In the first argument of `(>>=)', namely `ask' In the expression: ask >>= lift V.freeze STRead.hs:9:19: Couldn't match kind `* -> *' with `*' Expected type: (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) Actual type: (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) Kind incompatibility when matching types: (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) :: * -> * (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) :: * In the return type of a call of `lift' In the second argument of `(>>=)', namely `lift V.freeze' STRead.hs:9:24: Couldn't match kind `*' with `* -> *' Expected type: V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) Actual type: V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) Kind incompatibility when matching types: (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) :: * (->) (V.MVector (Control.Monad.Primitive.PrimState (ReaderT (V.MVector s Int) (ST s))) Int) :: * -> * In the first argument of `lift', namely `V.freeze' In the second argument of `(>>=)', namely `lift V.freeze' From ker0sin at ya.ru Tue Sep 2 20:59:13 2014 From: ker0sin at ya.ru (Alexander Pakhomov) Date: Wed, 03 Sep 2014 00:59:13 +0400 Subject: [Haskell-cafe] Functional dependency failure In-Reply-To: <2222731409690737@web7g.yandex.ru> References: <2222731409690737@web7g.yandex.ru> Message-ID: <13859751409691553@web26j.yandex.ru> Looks fixed in ghc master. I used 7.6.3 Anyhow, does anybody know a workout? 03.09.2014, 00:46, "Alexander Pakhomov" : > Hi! > > I have following code: > > STRead.hs: > > import Control.Monad.Reader > import Control.Monad.ST > import qualified Data.Vector.Mutable as MV > import qualified Data.Vector as V > > type ReadVecMonad s = ReaderT (MV.MVector s Int) (ST s) > > freezeV :: ReadVecMonad s (V.Vector Int) > freezeV = ask >>= lift V.freeze > > Trying to compile this I have "Couldn't match type ... When using functional dependencies to combine" error > following with kind mismatch and type with literaly the same type mismatch. > > How can I work this around? > > There's full error message: > > STRead.hs:9:11: > ????Couldn't match type `V.MVector s Int' > ??????????????????with `(->) > ??????????????????????????(V.MVector > ?????????????????????????????(Control.Monad.Primitive.PrimState > ????????????????????????????????(ReaderT (V.MVector s Int) (ST s))) > ?????????????????????????????Int)' > ????When using functional dependencies to combine > ??????MonadReader r (ReaderT r m), > ????????arising from the dependency `m -> r' > ????????in the instance declaration in `Control.Monad.Reader.Class' > ??????MonadReader > ????????((->) > ???????????(V.MVector > ??????????????(Control.Monad.Primitive.PrimState > ?????????????????(ReaderT (V.MVector s Int) (ST s))) > ??????????????Int)) > ????????(ReaderT (V.MVector s Int) (ST s)), > ????????arising from a use of `ask' at STRead.hs:9:11-13 > ????In the first argument of `(>>=)', namely `ask' > ????In the expression: ask >>= lift V.freeze > > STRead.hs:9:19: > ????Couldn't match kind `* -> *' with `*' > ????Expected type: (->) > ?????????????????????(V.MVector > ????????????????????????(Control.Monad.Primitive.PrimState > ???????????????????????????(ReaderT (V.MVector s Int) (ST s))) > ????????????????????????Int) > ???????????????????-> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) > ??????Actual type: (->) > ?????????????????????(V.MVector > ????????????????????????(Control.Monad.Primitive.PrimState > ???????????????????????????(ReaderT (V.MVector s Int) (ST s))) > ????????????????????????Int) > ???????????????????-> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) > ????Kind incompatibility when matching types: > ??????(->) > ????????(V.MVector > ???????????(Control.Monad.Primitive.PrimState > ??????????????(ReaderT (V.MVector s Int) (ST s))) > ???????????Int) :: * -> * > ??????(->) > ????????(V.MVector > ???????????(Control.Monad.Primitive.PrimState > ??????????????(ReaderT (V.MVector s Int) (ST s))) > ???????????Int) :: * > ????In the return type of a call of `lift' > ????In the second argument of `(>>=)', namely `lift V.freeze' > > STRead.hs:9:24: > ????Couldn't match kind `*' with `* -> *' > ????Expected type: V.MVector > ?????????????????????(Control.Monad.Primitive.PrimState > ????????????????????????(ReaderT (V.MVector s Int) (ST s))) > ?????????????????????Int > ???????????????????-> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) > ??????Actual type: V.MVector > ?????????????????????(Control.Monad.Primitive.PrimState > ????????????????????????(ReaderT (V.MVector s Int) (ST s))) > ?????????????????????Int > ???????????????????-> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) > ????Kind incompatibility when matching types: > ??????(->) > ????????(V.MVector > ???????????(Control.Monad.Primitive.PrimState > ??????????????(ReaderT (V.MVector s Int) (ST s))) > ???????????Int) :: * > ??????(->) > ????????(V.MVector > ???????????(Control.Monad.Primitive.PrimState > ??????????????(ReaderT (V.MVector s Int) (ST s))) > ???????????Int) :: * -> * > ????In the first argument of `lift', namely `V.freeze' > ????In the second argument of `(>>=)', namely `lift V.freeze' > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From fuuzetsu at fuuzetsu.co.uk Tue Sep 2 21:16:59 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 02 Sep 2014 22:16:59 +0100 Subject: [Haskell-cafe] [ANN] haddock-2.15-0, haddock-api-2.15-0, haddock-library-1.1.1 In-Reply-To: <54032824.103@fuuzetsu.co.uk> References: <54032824.103@fuuzetsu.co.uk> Message-ID: <540633CB.7040401@fuuzetsu.co.uk> On 08/31/2014 02:50 PM, Mateusz Kowalczyk wrote: > Hello, > > I'd like to announce the release of Haddock 2.15.0. > > [snip] > > Thanks! > > [1]: https://github.com/haskell/haddock/issues > Oops, something I forgot to mention: 1. {-# OPTIONS_HADDOCK show-extensions #-} will probably become the default from next release. Of course you'll be able to switch it off if you don't like it but you'll have to do so explicitly. 2. We will remove ?frames? unless someone want to step up and fix the two issues related to them: #114 and #274. Hackage strips the link out from the JavaScript we ship so barely anyone knows or uses them but if you uploaded your own docs then you'll have them. If you like them then please step up to fix them or they will have to go. Thanks! -- Mateusz K. From ivan.miljenovic at gmail.com Wed Sep 3 00:00:39 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 3 Sep 2014 10:00:39 +1000 Subject: [Haskell-cafe] [ANN] haddock-2.15-0, haddock-api-2.15-0, haddock-library-1.1.1 In-Reply-To: <540633CB.7040401@fuuzetsu.co.uk> References: <54032824.103@fuuzetsu.co.uk> <540633CB.7040401@fuuzetsu.co.uk> Message-ID: On 3 September 2014 07:16, Mateusz Kowalczyk wrote: > On 08/31/2014 02:50 PM, Mateusz Kowalczyk wrote: >> Hello, >> >> I'd like to announce the release of Haddock 2.15.0. >> >> [snip] >> >> Thanks! >> >> [1]: https://github.com/haskell/haddock/issues >> > > Oops, something I forgot to mention: > > 1. {-# OPTIONS_HADDOCK show-extensions #-} will probably become the > default from next release. Of course you'll be able to switch it off if > you don't like it but you'll have to do so explicitly. If this is the case, will there be any way of documenting why a potentially "scary" extension (e.g. UndecidableInstances) is being used? > > 2. We will remove ?frames? unless someone want to step up and fix the > two issues related to them: #114 and #274. Hackage strips the link out > from the JavaScript we ship so barely anyone knows or uses them but if > you uploaded your own docs then you'll have them. If you like them then > please step up to fix them or they will have to go. > > Thanks! > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From fuuzetsu at fuuzetsu.co.uk Wed Sep 3 03:45:45 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Wed, 03 Sep 2014 04:45:45 +0100 Subject: [Haskell-cafe] [ANN] haddock-2.15-0, haddock-api-2.15-0, haddock-library-1.1.1 In-Reply-To: References: <54032824.103@fuuzetsu.co.uk> <540633CB.7040401@fuuzetsu.co.uk> Message-ID: <54068EE9.1050005@fuuzetsu.co.uk> On 09/03/2014 01:00 AM, Ivan Lazar Miljenovic wrote: > On 3 September 2014 07:16, Mateusz Kowalczyk wrote: >> On 08/31/2014 02:50 PM, Mateusz Kowalczyk wrote: >>> Hello, >>> >>> I'd like to announce the release of Haddock 2.15.0. >>> >>> [snip] >>> >>> Thanks! >>> >>> [1]: https://github.com/haskell/haddock/issues >>> >> >> Oops, something I forgot to mention: >> >> 1. {-# OPTIONS_HADDOCK show-extensions #-} will probably become the >> default from next release. Of course you'll be able to switch it off if >> you don't like it but you'll have to do so explicitly. > > If this is the case, will there be any way of documenting why a > potentially "scary" extension (e.g. UndecidableInstances) is being > used? No official way and no plan to ever support documenting extensions: adding the code to the GHC lexer and extracting it back out of the API is a lot of work. Trying to decide how the show it in the documentation is probably equally as hard. If someone *really* thinks they need this, I'll be happy to review their patch for the whole thing ;). I don't actually know of anyone ever asking for such a thing (yet!). Personally I recommend using either the module header to say why the extension is used or documenting your class/instance. Header is probably better for consistency if you do this a lot and in the HTML it appears near the box that houses the extension list. >> >> 2. We will remove ?frames? unless someone want to step up and fix the >> two issues related to them: #114 and #274. Hackage strips the link out >> from the JavaScript we ship so barely anyone knows or uses them but if >> you uploaded your own docs then you'll have them. If you like them then >> please step up to fix them or they will have to go. >> >> Thanks! >> >> -- >> Mateusz K. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- Mateusz K. From me at jspha.com Wed Sep 3 06:03:55 2014 From: me at jspha.com (Joseph Abrahamson) Date: Tue, 02 Sep 2014 23:03:55 -0700 (PDT) Subject: [Haskell-cafe] "Lower case" infix type operator variables Message-ID: <1409724235571.1768b819@Nodemailer> I spent a few moments confused by the fact the TypeOperators was insufficient to allow the following type to be parsed ? ? constA :: Arrow (~>) => b -> (a ~> b) My current intuition is that since I *can* write things like ? ? newtype (~>) a b = A (a -> b) there is clashing in the type operator space for ?upper case? and ?lower case? identifiers. Is it possible or advisable to mitigate this clash and provide some syntax for ?type operator variables?? Joseph -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Wed Sep 3 07:19:02 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 3 Sep 2014 09:19:02 +0200 Subject: [Haskell-cafe] "Lower case" infix type operator variables In-Reply-To: <1409724235571.1768b819@Nodemailer> References: <1409724235571.1768b819@Nodemailer> Message-ID: Hi Joseph, The type operator type variable used to be possible, but this was changed in (I think) 7.8. See the discussion in threads [0] and [1]. There were some proposals for alternate syntax for operator type variables, but I don't think any of them were implemented. Currently, the best you can do is infix textual names, something like: constA :: Arrow arr => b -> (a `arr` b) Erik [0] http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021611.html [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2012-September/022845.html On Wed, Sep 3, 2014 at 8:03 AM, Joseph Abrahamson wrote: > I spent a few moments confused by the fact the TypeOperators was > insufficient to allow the following type to be parsed > > constA :: Arrow (~>) => b -> (a ~> b) > > My current intuition is that since I *can* write things like > > newtype (~>) a b = A (a -> b) > > there is clashing in the type operator space for ?upper case? and ?lower > case? identifiers. Is it possible or advisable to mitigate this clash and > provide some syntax for ?type operator variables?? > Joseph > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jwlato at gmail.com Wed Sep 3 08:21:24 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 3 Sep 2014 01:21:24 -0700 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: <5405FEF5.8020202@gmail.com> Message-ID: On Tue, Sep 2, 2014 at 12:26 PM, Leon Smith wrote: > On Tue, Sep 2, 2014 at 1:31 PM, Felipe Lessa > wrote: > >> I don't see how one could allow concurrent readers and "closers" without >> leaving this small opening. The best workaround I can think of is to >> create a blocking close operation that waits for readers using a >> semaphore. > > > Well yes, I can't think of a simple lock-based solution to this problem, > because you don't want to hold any kind of lock while you are blocked on > the file descriptor. > If you wanted to go this route, you could use an MVar (Maybe (Int,Fd)), where the Int is a count of interested threads. Instead of using readMVar before threadWaitRead, you would use modifyMVar to atomically increment the counter and retrieve the fd. Then, after threadWaitRead returns, decrement the counter. You'd need to make sure that you never close an fd when the counter is greater than 0. This would work better with a TMVar, because then the close operation could block until the counter has changed. > It would be solvable though if we had a thread-safe > > threadWaitReadMVar :: MVar Fd -> IO () > > You should be able to implement this relatively easily if you dig deeper > into the IO manager itself, but we already have threadWaitReadSTM. (For > different reasons, which doesn't cover this use case.) How many > variations on this theme are we going to need. > > We could implement threadWaitReadMVar if we had a non-blocking way of > registering interest in a file descriptor, and then later actually > blocking on it. So let's say something like > > registerWaitRead :: Fd -> IO (IO ()) > > threadWaitReadMVar fd = join $ withMVar fd registerWaitRead > > Which, ignoring asynchronous exceptions for the moment, should be > adequate for the task. I suppose that means you could instead do > > threadWaitReadMVar fd = (atomically . fst) =<< withMVar fd > threadWaitReadSTM > > Which seems like an odd use of STM, but that also does seem like a > solution. So I guess the earlier part of this email (as well as eariler > emails) is in fact wrong, that threadWaitReadSTM does cover this use > case. And STM might also offer a nicer way of making multiple reads > from the inotify binding thread-safe as well. > This should work even in the presence of async exceptions, barring bugs in withMVar and threadWaitReadSTM. You can implement your registerWaitRead using forkIO and MVars, but I think the only reason to do so would be for compatibility with older ghcs. It's probably more sensible to just copy the definition of threadWaitReadSTM in that case, unless you want to target pre-STM compiler versions. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Wed Sep 3 08:28:38 2014 From: adam at bergmark.nl (Adam Bergmark) Date: Wed, 3 Sep 2014 10:28:38 +0200 Subject: [Haskell-cafe] "Lower case" infix type operator variables In-Reply-To: References: <1409724235571.1768b819@Nodemailer> Message-ID: it was changed in 7.6 even! On Wed, Sep 3, 2014 at 9:19 AM, Erik Hesselink wrote: > Hi Joseph, > > The type operator type variable used to be possible, but this was > changed in (I think) 7.8. See the discussion in threads [0] and [1]. > There were some proposals for alternate syntax for operator type > variables, but I don't think any of them were implemented. Currently, > the best you can do is infix textual names, something like: > > constA :: Arrow arr => b -> (a `arr` b) > > Erik > > [0] > http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021611.html > [1] > http://www.haskell.org/pipermail/glasgow-haskell-users/2012-September/022845.html > > On Wed, Sep 3, 2014 at 8:03 AM, Joseph Abrahamson wrote: > > I spent a few moments confused by the fact the TypeOperators was > > insufficient to allow the following type to be parsed > > > > constA :: Arrow (~>) => b -> (a ~> b) > > > > My current intuition is that since I *can* write things like > > > > newtype (~>) a b = A (a -> b) > > > > there is clashing in the type operator space for ?upper case? and ?lower > > case? identifiers. Is it possible or advisable to mitigate this clash and > > provide some syntax for ?type operator variables?? > > Joseph > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neto at netowork.me Wed Sep 3 08:48:17 2014 From: neto at netowork.me (Ernesto Rodriguez) Date: Wed, 3 Sep 2014 04:48:17 -0400 Subject: [Haskell-cafe] Package bounds approximation Message-ID: Dear Cafe, I was wondering if there exists a tool to approximate what would be the minimal versions of the dependencies required by a package. I know that calculating this exactly is a bit intractable, but I was considering whether a tool that works as follows would work: 1) Compile the package with known to work dependencies 2) For each version of dependency as d: For each function in d used by My Package: * Perform unification of the resulting type when compiled with known to work dependencies and the type exported by the api of the version of the dependency in consideration. If all unifications succeeds, mark the version as compatible, incompatible otherwise This approximation is obviously not complete. Nevertheless, I would like to get opinions about whether this would be a good/useful/feasible approximation? Does the current GHC api export enough functionality for this package to be feasible? Are there alternatives? I was consider doing this as my `hack` during the high energy, intense no-sleep jacobsHack! hackathon, do you think it would be a good idea? Thank you for the opinions and best regards, Ernesto Rodriguez -- Ernesto Rodriguez Masters Student Computer Science Utrecht University www.netowork.me github.com/netogallo -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Wed Sep 3 09:40:58 2014 From: adam at bergmark.nl (Adam Bergmark) Date: Wed, 3 Sep 2014 11:40:58 +0200 Subject: [Haskell-cafe] Package bounds approximation In-Reply-To: References: Message-ID: It might be interesting to revive this PR: https://github.com/haskell/cabal/pull/1309 - Adam On Wed, Sep 3, 2014 at 10:48 AM, Ernesto Rodriguez wrote: > Dear Cafe, > > I was wondering if there exists a tool to approximate what would be the > minimal versions of the dependencies required by a package. > > I know that calculating this exactly is a bit intractable, but I was > considering whether a tool that works as follows would work: > > 1) Compile the package with known to work dependencies > 2) For each version of dependency as d: > For each function in d used by My Package: > * Perform unification of the resulting type when compiled > with known to work dependencies > and the type exported by the api of the version of the > dependency in consideration. > If all unifications succeeds, mark the version as compatible, > incompatible otherwise > > This approximation is obviously not complete. Nevertheless, I would like > to get opinions about whether this would be a good/useful/feasible > approximation? Does the current GHC api export enough functionality for > this package to be feasible? Are there alternatives? I was consider doing > this as my `hack` during the high energy, intense no-sleep jacobsHack! > hackathon, do you think it would be a good idea? > > Thank you for the opinions and best regards, > > Ernesto Rodriguez > > -- > Ernesto Rodriguez > > Masters Student > Computer Science > Utrecht University > > www.netowork.me > github.com/netogallo > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kjeldaas at gmail.com Wed Sep 3 10:04:01 2014 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Wed, 3 Sep 2014 12:04:01 +0200 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: <5405FEF5.8020202@gmail.com> Message-ID: On Wed, Sep 3, 2014 at 10:21 AM, John Lato wrote: > On Tue, Sep 2, 2014 at 12:26 PM, Leon Smith > wrote: > >> On Tue, Sep 2, 2014 at 1:31 PM, Felipe Lessa >> wrote: >> >>> I don't see how one could allow concurrent readers and "closers" without >>> leaving this small opening. The best workaround I can think of is to >>> create a blocking close operation that waits for readers using a >>> semaphore. >> >> >> Well yes, I can't think of a simple lock-based solution to this problem, >> because you don't want to hold any kind of lock while you are blocked on >> the file descriptor. >> > > If you wanted to go this route, you could use an MVar (Maybe (Int,Fd)), > where the Int is a count of interested threads. Instead of using readMVar > before threadWaitRead, you would use modifyMVar to atomically increment the > counter and retrieve the fd. Then, after threadWaitRead returns, decrement > the counter. You'd need to make sure that you never close an fd when the > counter is greater than 0. This would work better with a TMVar, because > then the close operation could block until the counter has changed. > > Or a reader/writer lock. Hold the lock as a reader across the blocking operation. Alexander > It would be solvable though if we had a thread-safe >> >> threadWaitReadMVar :: MVar Fd -> IO () >> >> You should be able to implement this relatively easily if you dig deeper >> into the IO manager itself, but we already have threadWaitReadSTM. (For >> different reasons, which doesn't cover this use case.) How many >> variations on this theme are we going to need. >> >> We could implement threadWaitReadMVar if we had a non-blocking way of >> registering interest in a file descriptor, and then later actually >> blocking on it. So let's say something like >> >> registerWaitRead :: Fd -> IO (IO ()) >> >> threadWaitReadMVar fd = join $ withMVar fd registerWaitRead >> >> Which, ignoring asynchronous exceptions for the moment, should be >> adequate for the task. I suppose that means you could instead do >> >> threadWaitReadMVar fd = (atomically . fst) =<< withMVar fd >> threadWaitReadSTM >> > >> Which seems like an odd use of STM, but that also does seem like a >> solution. So I guess the earlier part of this email (as well as eariler >> emails) is in fact wrong, that threadWaitReadSTM does cover this use >> case. And STM might also offer a nicer way of making multiple reads >> from the inotify binding thread-safe as well. >> > > This should work even in the presence of async exceptions, barring bugs in > withMVar and threadWaitReadSTM. You can implement your registerWaitRead > using forkIO and MVars, but I think the only reason to do so would be for > compatibility with older ghcs. It's probably more sensible to just copy > the definition of threadWaitReadSTM in that case, unless you want to target > pre-STM compiler versions. > > John > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neto at netowork.me Wed Sep 3 12:34:39 2014 From: neto at netowork.me (Ernesto Rodriguez) Date: Wed, 3 Sep 2014 08:34:39 -0400 Subject: [Haskell-cafe] Package bounds approximation In-Reply-To: References: Message-ID: Hi Adam, Thanks for your suggestion. As I undersdand, the flag looks at the dependencies specified by the cabal file and simply inverts the package version solving algorithm to try out older packages before newer. I am trying to solve a different problem. Sometime, (at least myself) I specify a particular lower bound in my cabal file that simply matches whatever was installed when I did cabal install. The package might work with older versions but checking this manually is a bit tedious. I would like to have a tool which I can run on my project and it will give me an approximation of the lowest possible version I can use for each of the dependencies in my project. If all packages included more faithful information about what is the lowest possible bound, it would reduce a lot of dependency hell. Cheers, Ernesto On Wed, Sep 3, 2014 at 5:40 AM, Adam Bergmark wrote: > It might be interesting to revive this PR: > https://github.com/haskell/cabal/pull/1309 > > - Adam > > > > On Wed, Sep 3, 2014 at 10:48 AM, Ernesto Rodriguez > wrote: > >> Dear Cafe, >> >> I was wondering if there exists a tool to approximate what would be the >> minimal versions of the dependencies required by a package. >> >> I know that calculating this exactly is a bit intractable, but I was >> considering whether a tool that works as follows would work: >> >> 1) Compile the package with known to work dependencies >> 2) For each version of dependency as d: >> For each function in d used by My Package: >> * Perform unification of the resulting type when compiled >> with known to work dependencies >> and the type exported by the api of the version of the >> dependency in consideration. >> If all unifications succeeds, mark the version as compatible, >> incompatible otherwise >> >> This approximation is obviously not complete. Nevertheless, I would like >> to get opinions about whether this would be a good/useful/feasible >> approximation? Does the current GHC api export enough functionality for >> this package to be feasible? Are there alternatives? I was consider doing >> this as my `hack` during the high energy, intense no-sleep jacobsHack! >> hackathon, do you think it would be a good idea? >> >> Thank you for the opinions and best regards, >> >> Ernesto Rodriguez >> >> -- >> Ernesto Rodriguez >> >> Masters Student >> Computer Science >> Utrecht University >> >> www.netowork.me >> github.com/netogallo >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -- Ernesto Rodriguez Masters Student Computer Science Utrecht University www.netowork.me github.com/netogallo -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Wed Sep 3 12:51:27 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 3 Sep 2014 14:51:27 +0200 Subject: [Haskell-cafe] Package bounds approximation In-Reply-To: References: Message-ID: Hi Ernesto, I was looking to solve this problem a while ago, but I didn't found a satisfactory tool. What I do atm, is trying to compile using versions of an old haskell platform (like last year or something...) I hope that help, and I would to find an automated way of doing it. Cheers On Sep 3, 2014 2:35 PM, "Ernesto Rodriguez" wrote: > Hi Adam, > > Thanks for your suggestion. As I undersdand, the flag looks at the > dependencies specified by the cabal file and simply inverts the package > version solving algorithm to try out older packages before newer. I am > trying to solve a different problem. > > Sometime, (at least myself) I specify a particular lower bound in my cabal > file that simply matches whatever was installed when I did cabal install. > The package might work with older versions but checking this manually is a > bit tedious. I would like to have a tool which I can run on my project and > it will give me an approximation of the lowest possible version I can use > for each of the dependencies in my project. If all packages included more > faithful information about what is the lowest possible bound, it would > reduce a lot of dependency hell. > > Cheers, > > Ernesto > > > On Wed, Sep 3, 2014 at 5:40 AM, Adam Bergmark wrote: > >> It might be interesting to revive this PR: >> https://github.com/haskell/cabal/pull/1309 >> >> - Adam >> >> >> >> On Wed, Sep 3, 2014 at 10:48 AM, Ernesto Rodriguez >> wrote: >> >>> Dear Cafe, >>> >>> I was wondering if there exists a tool to approximate what would be the >>> minimal versions of the dependencies required by a package. >>> >>> I know that calculating this exactly is a bit intractable, but I was >>> considering whether a tool that works as follows would work: >>> >>> 1) Compile the package with known to work dependencies >>> 2) For each version of dependency as d: >>> For each function in d used by My Package: >>> * Perform unification of the resulting type when compiled >>> with known to work dependencies >>> and the type exported by the api of the version of the >>> dependency in consideration. >>> If all unifications succeeds, mark the version as compatible, >>> incompatible otherwise >>> >>> This approximation is obviously not complete. Nevertheless, I would like >>> to get opinions about whether this would be a good/useful/feasible >>> approximation? Does the current GHC api export enough functionality for >>> this package to be feasible? Are there alternatives? I was consider doing >>> this as my `hack` during the high energy, intense no-sleep jacobsHack! >>> hackathon, do you think it would be a good idea? >>> >>> Thank you for the opinions and best regards, >>> >>> Ernesto Rodriguez >>> >>> -- >>> Ernesto Rodriguez >>> >>> Masters Student >>> Computer Science >>> Utrecht University >>> >>> www.netowork.me >>> github.com/netogallo >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> > > > -- > Ernesto Rodriguez > > Masters Student > Computer Science > Utrecht University > > www.netowork.me > github.com/netogallo > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leon.p.smith at gmail.com Wed Sep 3 17:40:41 2014 From: leon.p.smith at gmail.com (Leon Smith) Date: Wed, 3 Sep 2014 13:40:41 -0400 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: <5405FEF5.8020202@gmail.com> Message-ID: On Wed, Sep 3, 2014 at 4:21 AM, John Lato wrote: > On Tue, Sep 2, 2014 at 12:26 PM, Leon Smith > wrote: > >> On Tue, Sep 2, 2014 at 1:31 PM, Felipe Lessa >> wrote: >> >>> I don't see how one could allow concurrent readers and "closers" without >>> leaving this small opening. The best workaround I can think of is to >>> create a blocking close operation that waits for readers using a >>> semaphore. >> >> >> Well yes, I can't think of a simple lock-based solution to this problem, >> because you don't want to hold any kind of lock while you are blocked on >> the file descriptor. >> > > If you wanted to go this route, you could use an MVar (Maybe (Int,Fd)), > where the Int is a count of interested threads. Instead of using readMVar > before threadWaitRead, you would use modifyMVar to atomically increment the > counter and retrieve the fd. Then, after threadWaitRead returns, decrement > the counter. You'd need to make sure that you never close an fd when the > counter is greater than 0. This would work better with a TMVar, because > then the close operation could block until the counter has changed. > I think the semantics should probably be for a concurrent close to immediately close the descriptor, with exceptions raised in any threads that are blocked on the descriptor. It seems that any sort of use-case along these lines is going to result in an exception eventually... so you might as well make it prompt. So I still don't see any lock-based solution for my intended semantics. > threadWaitReadMVar fd = (atomically . fst) =<< withMVar fd >> threadWaitReadSTM >> > >> This should work even in the presence of async exceptions, barring bugs > in withMVar and threadWaitReadSTM. You can implement your registerWaitRead > using forkIO and MVars, but I think the only reason to do so would be for > compatibility with older ghcs. It's probably more sensible to just copy > the definition of threadWaitReadSTM in that case, unless you want to target > pre-STM compiler versions. > I think you are right; I suppose an async exception could result in interest registered in the descriptor without ever waiting on it, but this really isn't a big deal, especially as the callback will be removed from the IO manager once the descriptor becomes readable or the descriptor is closed. And it shouldn't prevent the higher-level inotify "descriptor" from being garbage-collected either, as the IO manager doesn't know anything about that, so the finalizer can still close the descriptor. Best, Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Wed Sep 3 17:57:35 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed, 03 Sep 2014 14:57:35 -0300 Subject: [Haskell-cafe] Race conditions with threadWait(Read/Write) and closeFdWith In-Reply-To: References: <5405FEF5.8020202@gmail.com> Message-ID: <5407568F.50703@gmail.com> On 03-09-2014 14:40, Leon Smith wrote: > I think the semantics should probably be for a concurrent close to > immediately close the descriptor, with exceptions raised in any threads > that are blocked on the descriptor. It seems that any sort of > use-case along these lines is going to result in an exception > eventually... so you might as well make it prompt. So I still don't > see any lock-based solution for my intended semantics. How far are you willing to go? :) Instead of an Int, you could use [ThreadId] as a set (or any other data structure). The only problem I can see with this approach is: - Thread A adds itself to the [ThreadId] and waits for the Fd. - Thread B starts closing the Fd. - Thread A is awakened from the Fd. - Thread B closes the Fd and sends async exceptions to all [ThreadId], including thread A. - Thread A tries to modify the [ThreadId] again to remove itself, but sees Nothing instead. At this point, thread A has not yet received the async exception, but it *knows* that the exception is coming! Poor thread A :(. Cheers! -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From daniel.trstenjak at gmail.com Wed Sep 3 18:45:05 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Wed, 3 Sep 2014 20:45:05 +0200 Subject: [Haskell-cafe] Package bounds approximation In-Reply-To: References: Message-ID: <86D297E3-883C-451C-ABBA-526768CB4247@gmail.com> > What I do atm, is trying to compile using versions of an old haskell platform (like last year or something...) > Now cabal-bounds[1] really has the option '--haskell-platform' ;). So now you can call: cabal-bounds update --haskell-platform=2013.2.0.0 project.cabal or more convenient cabal-bounds update --haskell-platform=previous project.cabal Greetings, Daniel [1] https://github.com/dan-t/cabal-bounds -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstcruz at gmail.com Thu Sep 4 05:41:23 2014 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Wed, 3 Sep 2014 23:41:23 -0600 Subject: [Haskell-cafe] Haskell Weekly News: Issue 304 Message-ID: Welcome to issue 304 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from August 24 to 30, 2014 Quotes of the Week * pjdelport: Haskell: Lazy evaluation, eager debugging. * trap_exit: isn't hoogle awesome? the first time I used it, I was like "for the first time in my life, google sucks" Top Reddit Stories * Hython - a Haskell-powered Python 3 interpreter Domain: github.com, Score: 95, Comments: 22 Original: [1] http://goo.gl/aI16qA On Reddit: [2] http://goo.gl/N67fnX * Using Emacs for Haskell development Domain: github.com, Score: 89, Comments: 47 Original: [3] http://goo.gl/tuPL91 On Reddit: [4] http://goo.gl/RxVWFQ * Ivory Language Domain: ivorylang.org, Score: 70, Comments: 36 Original: [5] http://goo.gl/xJJ68c On Reddit: [6] http://goo.gl/Vz9cTX * A taste of Cabalized Backpack : Inside 206-105 Domain: blog.ezyang.com, Score: 61, Comments: 73 Original: [7] http://goo.gl/8MpD3U On Reddit: [8] http://goo.gl/3kVQOG * Introducing /r/haskellgamedev Domain: self.haskell, Score: 58, Comments: 20 Original: [9] http://goo.gl/B2nzhq On Reddit: [10] http://goo.gl/B2nzhq * Acme.StringlyTyped Domain: hackage.haskell.org, Score: 44, Comments: 11 Original: [11] http://goo.gl/IfK2Uf On Reddit: [12] http://goo.gl/Z0wT5E * A new version of Yampa is out (0.9.6) Domain: keera.co.uk, Score: 43, Comments: 16 Original: [13] http://goo.gl/EHxFdd On Reddit: [14] http://goo.gl/EXGLdX * On CodeWorld and Haskell Domain: cdsmith.wordpress.com, Score: 41, Comments: 23 Original: [15] http://goo.gl/C7tkHk On Reddit: [16] http://goo.gl/qu3l04 * Introduction to Dependent Types: Haskell on Steroids Domain: jozefg.bitbucket.org, Score: 37, Comments: 17 Original: [17] http://goo.gl/fg8Rfo On Reddit: [18] http://goo.gl/YLmHNQ * Evaluation order and state tokens - School of Haskell Domain: fpcomplete.com, Score: 35, Comments: 24 Original: [19] http://goo.gl/v0D1HQ On Reddit: [20] http://goo.gl/jiiLRl * IO Monad and Purity Domain: stackoverflow.com, Score: 34, Comments: 13 Original: [21] http://goo.gl/zkBxl1 On Reddit: [22] http://goo.gl/yVQY4F * [ANN] Haste 0.4, now with GHC 7.8 support and binary packages Domain: groups.google.com, Score: 33, Comments: 5 Original: [23] http://goo.gl/DU4QYT On Reddit: [24] http://goo.gl/xcqxU0 * darcs 2.8.5 released Domain: lists.osuosl.org, Score: 30, Comments: 0 Original: [25] http://goo.gl/FbjpuA On Reddit: [26] http://goo.gl/TM6D7E * Yarr - image processing library and partial Repa clone Domain: hackage.haskell.org, Score: 28, Comments: 8 Original: [27] http://goo.gl/cfHAH8 On Reddit: [28] http://goo.gl/oyK3xF * conduit stream fusion Domain: fpcomplete.com, Score: 28, Comments: 15 Original: [29] http://goo.gl/9e57M2 On Reddit: [30] http://goo.gl/kFL5Pu * New blog post: Dealing with Asynchronous Exceptions during Resource Acquisition Domain: well-typed.com, Score: 28, Comments: 34 Original: [31] http://goo.gl/WS05yN On Reddit: [32] http://goo.gl/5hp59d Top StackOverflow Questions * Zipper Comonads, Generically votes: 43, answers: 3 Read on SO: [33] http://goo.gl/NDzqR1 * Test if a value matches a constructor votes: 25, answers: 3 Read on SO: [34] http://goo.gl/3Sa7hX * What is the difference between a cyclic list and an infinite list in haskell? votes: 16, answers: 2 Read on SO: [35] http://goo.gl/q7f7pu * Powerset Function 1-Liner votes: 13, answers: 1 Read on SO: [36] http://goo.gl/cez03g * How to make a binary tree zipper an instance of Comonad? votes: 13, answers: 1 Read on SO: [37] http://goo.gl/Zc1wr4 * Is there a better performing alternative to read and show in Haskell? votes: 11, answers: 1 Read on SO: [38] http://goo.gl/Y0m0wX * QuickCheck: How to use exhaustiveness checker to prevent forgotten constructors of a sum type votes: 11, answers: 2 Read on SO: [39] http://goo.gl/b8YbtB * Why does FRP consider time as a factor for values? votes: 10, answers: 2 Read on SO: [40] http://goo.gl/Yo65J8 Until next time, [41]+Daniel Santa Cruz References 1. https://github.com/mattgreen/hython 2. http://www.reddit.com/r/haskell/comments/2ejlxm/hython_a_haskellpowered_python_3_interpreter/ 3. https://github.com/serras/emacs-haskell-tutorial/blob/master/tutorial.md 4. http://www.reddit.com/r/haskell/comments/2efpx4/using_emacs_for_haskell_development/ 5. http://ivorylang.org/ 6. http://www.reddit.com/r/haskell/comments/2epdwp/ivory_language/ 7. http://blog.ezyang.com/2014/08/a-taste-of-cabalized-backpack/ 8. http://www.reddit.com/r/haskell/comments/2eoett/a_taste_of_cabalized_backpack_inside_206105/ 9. http://www.reddit.com/r/haskell/comments/2f0xm0/introducing_rhaskellgamedev/ 10. http://www.reddit.com/r/haskell/comments/2f0xm0/introducing_rhaskellgamedev/ 11. http://hackage.haskell.org/package/acme-stringly-typed-1.0.0.0/docs/Acme-StringlyTyped.html 12. http://www.reddit.com/r/haskell/comments/2f01jl/acmestringlytyped/ 13. http://keera.co.uk/blog/2014/08/29/new-version-yampa-0-9-6/ 14. http://www.reddit.com/r/haskell/comments/2ex7c9/a_new_version_of_yampa_is_out_096/ 15. http://cdsmith.wordpress.com/2014/08/26/on-codeworld-and-haskell/ 16. http://www.reddit.com/r/haskell/comments/2en20t/on_codeworld_and_haskell/ 17. http://jozefg.bitbucket.org/posts/2014-08-25-dep-types-part-1.html 18. http://www.reddit.com/r/haskell/comments/2er003/introduction_to_dependent_types_haskell_on/ 19. https://www.fpcomplete.com/user/snoyberg/general-haskell/advanced/evaluation-order-and-state-tokens 20. http://www.reddit.com/r/haskell/comments/2eiqwv/evaluation_order_and_state_tokens_school_of/ 21. http://stackoverflow.com/a/25576375/1651941 22. http://www.reddit.com/r/haskell/comments/2f191i/io_monad_and_purity/ 23. https://groups.google.com/forum/#!topic/haste-compiler/mel9aO9Jako 24. http://www.reddit.com/r/haskell/comments/2ev19m/ann_haste_04_now_with_ghc_78_support_and_binary/ 25. http://lists.osuosl.org/pipermail/darcs-users/2014-August/027041.html 26. http://www.reddit.com/r/haskell/comments/2ekjmx/darcs_285_released/ 27. http://hackage.haskell.org/package/yarr 28. http://www.reddit.com/r/haskell/comments/2eg1nk/yarr_image_processing_library_and_partial_repa/ 29. https://www.fpcomplete.com/blog/2014/08/conduit-stream-fusion 30. http://www.reddit.com/r/haskell/comments/2es8oj/conduit_stream_fusion/ 31. http://www.well-typed.com/blog/97/ 32. http://www.reddit.com/r/haskell/comments/2ety9f/new_blog_post_dealing_with_asynchronous/ 33. http://stackoverflow.com/questions/25554062/zipper-comonads-generically 34. http://stackoverflow.com/questions/25587501/test-if-a-value-matches-a-constructor 35. http://stackoverflow.com/questions/25498431/what-is-the-difference-between-a-cyclic-list-and-an-infinite-list-in-haskell 36. http://stackoverflow.com/questions/25476248/powerset-function-1-liner 37. http://stackoverflow.com/questions/25519767/how-to-make-a-binary-tree-zipper-an-instance-of-comonad 38. http://stackoverflow.com/questions/25496672/is-there-a-better-performing-alternative-to-read-and-show-in-haskell 39. http://stackoverflow.com/questions/25535616/quickcheck-how-to-use-exhaustiveness-checker-to-prevent-forgotten-constructors 40. http://stackoverflow.com/questions/25568712/why-does-frp-consider-time-as-a-factor-for-values 41. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From neto at netowork.me Thu Sep 4 08:51:13 2014 From: neto at netowork.me (Ernesto Rodriguez) Date: Thu, 4 Sep 2014 04:51:13 -0400 Subject: [Haskell-cafe] Package bounds approximation In-Reply-To: References: Message-ID: Hi Alois, That certainly is an option. How well does it work with packages that are not part of the Haskell Platform. Do you simply try the oldest compatible versions of those packages? Cheers On Wed, Sep 3, 2014 at 8:51 AM, Alois Cochard wrote: > Hi Ernesto, > > I was looking to solve this problem a while ago, but I didn't found a > satisfactory tool. > > What I do atm, is trying to compile using versions of an old haskell > platform (like last year or something...) > > I hope that help, and I would to find an automated way of doing it. > > Cheers > On Sep 3, 2014 2:35 PM, "Ernesto Rodriguez" wrote: > >> Hi Adam, >> >> Thanks for your suggestion. As I undersdand, the flag looks at the >> dependencies specified by the cabal file and simply inverts the package >> version solving algorithm to try out older packages before newer. I am >> trying to solve a different problem. >> >> Sometime, (at least myself) I specify a particular lower bound in my >> cabal file that simply matches whatever was installed when I did cabal >> install. The package might work with older versions but checking this >> manually is a bit tedious. I would like to have a tool which I can run on >> my project and it will give me an approximation of the lowest possible >> version I can use for each of the dependencies in my project. If all >> packages included more faithful information about what is the lowest >> possible bound, it would reduce a lot of dependency hell. >> >> Cheers, >> >> Ernesto >> >> >> On Wed, Sep 3, 2014 at 5:40 AM, Adam Bergmark wrote: >> >>> It might be interesting to revive this PR: >>> https://github.com/haskell/cabal/pull/1309 >>> >>> - Adam >>> >>> >>> >>> On Wed, Sep 3, 2014 at 10:48 AM, Ernesto Rodriguez >>> wrote: >>> >>>> Dear Cafe, >>>> >>>> I was wondering if there exists a tool to approximate what would be the >>>> minimal versions of the dependencies required by a package. >>>> >>>> I know that calculating this exactly is a bit intractable, but I was >>>> considering whether a tool that works as follows would work: >>>> >>>> 1) Compile the package with known to work dependencies >>>> 2) For each version of dependency as d: >>>> For each function in d used by My Package: >>>> * Perform unification of the resulting type when compiled >>>> with known to work dependencies >>>> and the type exported by the api of the version of the >>>> dependency in consideration. >>>> If all unifications succeeds, mark the version as compatible, >>>> incompatible otherwise >>>> >>>> This approximation is obviously not complete. Nevertheless, I would >>>> like to get opinions about whether this would be a good/useful/feasible >>>> approximation? Does the current GHC api export enough functionality for >>>> this package to be feasible? Are there alternatives? I was consider doing >>>> this as my `hack` during the high energy, intense no-sleep jacobsHack! >>>> hackathon, do you think it would be a good >>>> idea? >>>> >>>> Thank you for the opinions and best regards, >>>> >>>> Ernesto Rodriguez >>>> >>>> -- >>>> Ernesto Rodriguez >>>> >>>> Masters Student >>>> Computer Science >>>> Utrecht University >>>> >>>> www.netowork.me >>>> github.com/netogallo >>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> >> >> >> -- >> Ernesto Rodriguez >> >> Masters Student >> Computer Science >> Utrecht University >> >> www.netowork.me >> github.com/netogallo >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -- Ernesto Rodriguez Masters Student Computer Science Utrecht University www.netowork.me github.com/netogallo -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at blitzcode.net Thu Sep 4 09:33:19 2014 From: tim at blitzcode.net (Tim C. Schroeder) Date: Thu, 4 Sep 2014 11:33:19 +0200 Subject: [Haskell-cafe] ANN: Ray Marching Distance Fields with Haskell and GLSL Message-ID: https://github.com/blitzcode/ray-marching-distance-fields "This project is a Haskell and GLSL program containing my distance field / ray marching related experiments. The Haskell viewing application is doing the pre-processing, functioning as a development and debugging aid, allowing different shaders to be explored. It automatically reloads and recompiles shaders when they change, showing an overlay displaying any errors. There's a flexible frame buffer system, supporting under and super sampling and saving of screenshots. Tiled rendering avoids shader timeouts and unresponsive UI. It also features offline convolution of environment maps with a filter kernel to enable fast lighting of diffuse and glossy surfaces. Finally, there's an implementation of the Mandelbulb fractal as well as several simpler ones like Mandelbrot and Julia sets. There's some more functionality in the program, try it out and / or visit my website." Cheers, Tim From alois.cochard at gmail.com Thu Sep 4 09:47:21 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Thu, 4 Sep 2014 10:47:21 +0100 Subject: [Haskell-cafe] Package bounds approximation In-Reply-To: References: Message-ID: Hi Ernesto, What I do in that case it that I browse thru the old version number on hackage until I find one which match ~ the time of the platform I'm targeting, and I try to compile with it. That is the theory, and it can work not so bad if you do each you had a new dep... a pain if you have to do it retroactively though. Thanks Daniel! I'll definitely give it a try :-) On 4 September 2014 09:51, Ernesto Rodriguez wrote: > Hi Alois, > > That certainly is an option. How well does it work with packages that are > not part of the Haskell Platform. Do you simply try the oldest compatible > versions of those packages? > > Cheers > > > On Wed, Sep 3, 2014 at 8:51 AM, Alois Cochard > wrote: > >> Hi Ernesto, >> >> I was looking to solve this problem a while ago, but I didn't found a >> satisfactory tool. >> >> What I do atm, is trying to compile using versions of an old haskell >> platform (like last year or something...) >> >> I hope that help, and I would to find an automated way of doing it. >> >> Cheers >> On Sep 3, 2014 2:35 PM, "Ernesto Rodriguez" wrote: >> >>> Hi Adam, >>> >>> Thanks for your suggestion. As I undersdand, the flag looks at the >>> dependencies specified by the cabal file and simply inverts the package >>> version solving algorithm to try out older packages before newer. I am >>> trying to solve a different problem. >>> >>> Sometime, (at least myself) I specify a particular lower bound in my >>> cabal file that simply matches whatever was installed when I did cabal >>> install. The package might work with older versions but checking this >>> manually is a bit tedious. I would like to have a tool which I can run on >>> my project and it will give me an approximation of the lowest possible >>> version I can use for each of the dependencies in my project. If all >>> packages included more faithful information about what is the lowest >>> possible bound, it would reduce a lot of dependency hell. >>> >>> Cheers, >>> >>> Ernesto >>> >>> >>> On Wed, Sep 3, 2014 at 5:40 AM, Adam Bergmark wrote: >>> >>>> It might be interesting to revive this PR: >>>> https://github.com/haskell/cabal/pull/1309 >>>> >>>> - Adam >>>> >>>> >>>> >>>> On Wed, Sep 3, 2014 at 10:48 AM, Ernesto Rodriguez >>>> wrote: >>>> >>>>> Dear Cafe, >>>>> >>>>> I was wondering if there exists a tool to approximate what would be >>>>> the minimal versions of the dependencies required by a package. >>>>> >>>>> I know that calculating this exactly is a bit intractable, but I was >>>>> considering whether a tool that works as follows would work: >>>>> >>>>> 1) Compile the package with known to work dependencies >>>>> 2) For each version of dependency as d: >>>>> For each function in d used by My Package: >>>>> * Perform unification of the resulting type when compiled >>>>> with known to work dependencies >>>>> and the type exported by the api of the version of the >>>>> dependency in consideration. >>>>> If all unifications succeeds, mark the version as compatible, >>>>> incompatible otherwise >>>>> >>>>> This approximation is obviously not complete. Nevertheless, I would >>>>> like to get opinions about whether this would be a good/useful/feasible >>>>> approximation? Does the current GHC api export enough functionality for >>>>> this package to be feasible? Are there alternatives? I was consider doing >>>>> this as my `hack` during the high energy, intense no-sleep jacobsHack! >>>>> hackathon, do you think it would be a good >>>>> idea? >>>>> >>>>> Thank you for the opinions and best regards, >>>>> >>>>> Ernesto Rodriguez >>>>> >>>>> -- >>>>> Ernesto Rodriguez >>>>> >>>>> Masters Student >>>>> Computer Science >>>>> Utrecht University >>>>> >>>>> www.netowork.me >>>>> github.com/netogallo >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>> >>> >>> -- >>> Ernesto Rodriguez >>> >>> Masters Student >>> Computer Science >>> Utrecht University >>> >>> www.netowork.me >>> github.com/netogallo >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> > > > -- > Ernesto Rodriguez > > Masters Student > Computer Science > Utrecht University > > www.netowork.me > github.com/netogallo > > > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Thu Sep 4 13:47:14 2014 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu, 4 Sep 2014 15:47:14 +0200 Subject: [Haskell-cafe] heroku-buildpack-haste Message-ID: Just to let you know that I created an heroku buildpack that install GHC and Haste in the running environment, so that web applications can invoke ghc, cabal, hastec haste-inst etc. I use it for the creation of an Haste IDE. But it may have other uses. https://github.com/agocorona/heroku-buildpack-haste -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.marek.spartz at gmail.com Thu Sep 4 13:55:01 2014 From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz) Date: Thu, 4 Sep 2014 08:55:01 -0500 Subject: [Haskell-cafe] heroku-buildpack-haste In-Reply-To: References: Message-ID: <6ad04024-608f-48f7-b64d-2b6074dbb0f9@highlander> Cool! If other packages are needed, do they need to be installed in the buildpack, or can they be specified in a cabal file in the repo? ? Kyle Marek-Spartz On Sep 4, 2014, 8:47:14 AM, Alberto G. Corona wrote: Just to let you know that I created an heroku buildpack that install GHC and Haste in the running environment, so that web applications can invoke ghc, cabal, hastec haste-inst etc. I use it for the creation of an Haste IDE. But it may have other uses. https://github.com/agocorona/heroku-buildpack-haste -- Alberto. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Thu Sep 4 14:00:21 2014 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu, 4 Sep 2014 16:00:21 +0200 Subject: [Haskell-cafe] heroku-buildpack-haste In-Reply-To: <6ad04024-608f-48f7-b64d-2b6074dbb0f9@highlander> References: <6ad04024-608f-48f7-b64d-2b6074dbb0f9@highlander> Message-ID: Just specify them in the cabal file 2014-09-04 15:55 GMT+02:00 Kyle Marek-Spartz : > Cool! > > If other packages are needed, do they need to be installed in the > buildpack, or can they be specified in a cabal file in the repo? > > ? > Kyle Marek-Spartz > > > > On Sep 4, 2014, 8:47:14 AM, Alberto G. Corona wrote: > ------------------------------ > Just to let you know that I created an heroku buildpack that install GHC > and Haste in the running environment, so that web applications can invoke > ghc, cabal, hastec haste-inst etc. > > I use it for the creation of an Haste IDE. But it may have other uses. > > https://github.com/agocorona/heroku-buildpack-haste > > > -- > Alberto. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.j.thompson at kent.ac.uk Thu Sep 4 14:58:59 2014 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Thu, 4 Sep 2014 15:58:59 +0100 Subject: [Haskell-cafe] Jobs at the University of Kent Message-ID: <79E7D413-78B2-4FE5-9A00-70C86D72A322@kent.ac.uk> We've been doing functional programming at Kent for more than thirty years, and it would be great to recruit more people in FP, theory, type theory, programming languages, verification, concurrency ... Details of three positions here: https://jobs.kent.ac.uk/fe/tpl_kent01.asp?s=4A515F4E5A565B1A&jobid=38618,1240724854&key=41286990&c=545876250256&pagestamp=sedufjhfxtuvnjtwsc If you're interested in discussing, just send us an email. Simon Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From rmason at mun.ca Thu Sep 4 17:06:14 2014 From: rmason at mun.ca (Roger Mason) Date: Thu, 04 Sep 2014 14:36:14 -0230 Subject: [Haskell-cafe] diagrams fails to install Message-ID: Hello, I'm trying to install Diagrams on FreeBSD 10. It fails thus: cabal install diagrams Resolving dependencies... Configuring arithmoi-0.4.1.1... Building arithmoi-0.4.1.1... Preprocessing library arithmoi-0.4.1.1... [ 1 of 34] Compiling Math.NumberTheory.Primes.Sieve.Indexing ( Math/NumberTheory/Primes/Sieve/Indexing.hs, dist/build/Math/NumberTheory/Primes/Sieve/Indexing.o ) : Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt Failed to install arithmoi-0.4.1.1 cabal-install: Error: some packages failed to install: arithmoi-0.4.1.1 failed during the building phase. The exception was: ExitFailure 1 diagrams-1.2 depends on arithmoi-0.4.1.1 which failed to install. diagrams-contrib-1.1.2.1 depends on arithmoi-0.4.1.1 which failed to install. ghc --info reports: [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","gcc47") ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSFreeBSD") ,("target arch","ArchX86") ,("target word size","4") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","i386-portbld-freebsd") ,("Host platform","i386-portbld-freebsd") ,("Target platform","i386-portbld-freebsd") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.6.3") ,("Global Package DB","/usr/local/lib/ghc-7.6.3/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ] opt is installed as /usr/local/bin/opt32, so I tried symlinking /usr/local/bin/opt to it, but the error remains. Is there some workaround? Thanks, Roger From tifonzafel at gmail.com Thu Sep 4 18:00:46 2014 From: tifonzafel at gmail.com (felipe zapata) Date: Thu, 4 Sep 2014 14:00:46 -0400 Subject: [Haskell-cafe] Parallel evaluation of code dependencies Message-ID: Hi Cafe, Suppose that I have a representation of a DSL in Haskell (a physical number crunching simulation using quasiquoting for instance) and I want to evaluate the resulting Haskell representation by splitting it into chunks and send these chunk to some cluster, a supercomputer, etc. It doesn't matter for the moment the distribution protocol. My advisor suggested me that the best way of doing such a thing, is through a call by value strategy. Where I simply evaluate in parallel all the arguments of the functions. The problem with this alternative is that I must manipulate the Haskell representation and use some library ( or write some code) to identify the dependencies and evaluate them in parallel. Can please someone suggest me the best way to tackle this problem? I really appreciate any help. Felipe Z. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmason at mun.ca Thu Sep 4 18:38:55 2014 From: rmason at mun.ca (Roger Mason) Date: Thu, 04 Sep 2014 16:08:55 -0230 Subject: [Haskell-cafe] diagrams fails to install In-Reply-To: (Mike Meyer's message of "Thu, 4 Sep 2014 13:06:51 -0500") References: Message-ID: Hello Mike, Mike Meyer writes: > You should have a /usr/local/llvm32 directory. If so, try: > > PATH=/usr/local/llvm32/bin:$PATH cabal install diagrams. > > I have llvm34 installed, and it worked for me using > /usr/local/llvm34/bin:$PATH. > Thank you, that worked. best wishes, Roger From petr.mvd at gmail.com Thu Sep 4 20:06:33 2014 From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=) Date: Thu, 4 Sep 2014 22:06:33 +0200 Subject: [Haskell-cafe] Fwd: an idea for improving 'shrink' In-Reply-To: References: Message-ID: Hi, since I got no response from the QuickCheck mail address, so I'm resending it here, if someone wants to comment on the idea. Best regards, Petr ---------- Forwarded message ---------- From: Petr Pudl?k Date: 2014-07-06 20:13 GMT+02:00 Subject: an idea for improving 'shrink' To: QuickCheck developers Hi, I was learning about 'shrink' lately and I was trying to create some instances. It felt quite awkward until I realized that the operation for producing shrunk tuples is an applicative functor. I was playing with the idea for a while and I'm sending an experimental patch against QuickCheck master that shows the basics of the idea and how it can help constructing 'shrink' instances. If you feel that this is a good idea, let me know, I'll work on a full patch. Best regards, Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- diff --git a/Test/QuickCheck/Arbitrary.hs b/Test/QuickCheck/Arbitrary.hs index e924696..d8b4101 100644 --- a/Test/QuickCheck/Arbitrary.hs +++ b/Test/QuickCheck/Arbitrary.hs @@ -88,6 +88,17 @@ import Data.List , nub ) +import Data.Traversable + ( traverse + ) + +import Control.Applicative + ( Applicative(..) + , (<$>) + , liftA2 + , liftA3 + ) + import Control.Monad ( liftM , liftM2 @@ -105,6 +116,27 @@ import Data.Typeable #endif -------------------------------------------------------------------------- +-- ** class Shrink + +-- | Captures a value together with its shrunk variants. +data Shrink a = Shrink { sOriginal :: a + , fromShrink :: [a] + } + deriving (Eq, Ord, Show) + +instance Functor Shrink where + fmap f (Shrink x xs) = Shrink (f x) (map f xs) + +instance Applicative Shrink where + pure x = Shrink x [] + (Shrink f fs) <*> (Shrink x xs) = + Shrink (f x) (map ($ x) fs ++ map f xs) + +-- | Adds more shrunk values to the current ones. +(>.) :: [a] -> Shrink a -> Shrink a +ys >. Shrink x xs = Shrink x (ys ++ xs) +infixr 2 >. + -- ** class Arbitrary -- | Random generation and shrinking of values. @@ -179,7 +211,28 @@ class Arbitrary a where -- after deriving @Generic@ and @Typeable@ for your type. However, if your data type has any -- special invariants, you will need to check that 'genericShrink' can't break those invariants. shrink :: a -> [a] - shrink _ = [] + shrink = fromShrink . shrinkA + + -- ... + -- + -- For example, suppose we have the following implementation of binary trees: + -- + -- > data Tree a = Nil | Branch a (Tree a) (Tree a) + -- + -- We can then define 'shrinkA' as follows: + -- + -- > shrink (Branch x l r) = + -- > -- shrink Branch to Nil + -- > [Nil] ++ + -- > -- shrink to subterms + -- > [l, r] >. + -- > -- recursively shrink subterms + -- > Branch <$> shrinkA x <*> shrinkA l <*> shrinkA r + -- > shrink x = pure x + -- + -- ... + shrinkA :: a -> Shrink a + shrinkA = pure #ifndef NO_GENERICS -- | Shrink a term to any of its immediate subterms, @@ -263,33 +316,29 @@ instance Arbitrary Ordering where instance Arbitrary a => Arbitrary (Maybe a) where arbitrary = frequency [(1, return Nothing), (3, liftM Just arbitrary)] - shrink (Just x) = Nothing : [ Just x' | x' <- shrink x ] - shrink _ = [] + shrinkA (Just x) = [Nothing] >. Just <$> shrinkA x + shrinkA v = pure v instance (Arbitrary a, Arbitrary b) => Arbitrary (Either a b) where arbitrary = oneof [liftM Left arbitrary, liftM Right arbitrary] - shrink (Left x) = [ Left x' | x' <- shrink x ] - shrink (Right y) = [ Right y' | y' <- shrink y ] + shrinkA (Left x) = Left <$> shrinkA x + shrinkA (Right y) = Right <$> shrinkA y instance Arbitrary a => Arbitrary [a] where arbitrary = sized $ \n -> do k <- choose (0,n) sequence [ arbitrary | _ <- [1..k] ] - shrink xs = shrinkList shrink xs + shrinkA xs = shrinkList shrinkA xs -- | Shrink a list of values given a shrinking function for individual values. -shrinkList :: (a -> [a]) -> [a] -> [[a]] +shrinkList :: (a -> Shrink a) -> [a] -> Shrink [a] shrinkList shr xs = concat [ removes k n xs | k <- takeWhile (>0) (iterate (`div`2) n) ] - ++ shrinkOne xs + >. traverse shr xs where n = length xs - shrinkOne [] = [] - shrinkOne (x:xs) = [ x':xs | x' <- shr x ] - ++ [ x:xs' | xs' <- shrinkOne xs ] - removes k n xs | k > n = [] | null xs2 = [[]] @@ -312,8 +361,7 @@ instance (Integral a, Arbitrary a) => Arbitrary (Ratio a) where instance (RealFloat a, Arbitrary a) => Arbitrary (Complex a) where arbitrary = liftM2 (:+) arbitrary arbitrary - shrink (x :+ y) = [ x' :+ y | x' <- shrink x ] ++ - [ x :+ y' | y' <- shrink y ] + shrinkA (x :+ y) = liftA2 (:+) (shrinkA x) (shrinkA y) #ifndef NO_FIXED instance HasResolution a => Arbitrary (Fixed a) where @@ -326,18 +374,14 @@ instance (Arbitrary a, Arbitrary b) where arbitrary = liftM2 (,) arbitrary arbitrary - shrink (x, y) = - [ (x', y) | x' <- shrink x ] - ++ [ (x, y') | y' <- shrink y ] + shrinkA (x, y) = liftA2 (,) (shrinkA x) (shrinkA y) instance (Arbitrary a, Arbitrary b, Arbitrary c) => Arbitrary (a,b,c) where arbitrary = liftM3 (,,) arbitrary arbitrary arbitrary - shrink (x, y, z) = - [ (x', y', z') - | (x', (y', z')) <- shrink (x, (y, z)) ] + shrinkA (x, y, z) = liftA3 (,,) (shrinkA x) (shrinkA y) (shrinkA z) instance (Arbitrary a, Arbitrary b, Arbitrary c, Arbitrary d) => Arbitrary (a,b,c,d) From agocorona at gmail.com Thu Sep 4 20:23:55 2014 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu, 4 Sep 2014 22:23:55 +0200 Subject: [Haskell-cafe] Elm-like IDE for Haste projects Message-ID: Following the thread on lightweight Web interfaces for Haskell: http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/112586 I finished an Elm-like IDE for Haste projects. The software is at: https://github.com/agocorona/tryhplay Running in a heroku instance: http://tryplayg.herokuapp.com Besides to edit-compile and run, it can also import , compile and run haste projects from git repositories (Although this, like the rest of the project is experimental). I use it for my hplayground framework but it can run any haste project. Using playground is easy to translate console programs to the browser and have reactive effects A simple example: http://tryplayg.herokuapp.com/try/console.hs/edit the hello-haste example: http://tryplayg.herokuapp.com/try/hello-haste.hs/edit Or something more complicated: the todo application, from todoMVC.com written in Haste and hplayground: http://tryplayg.herokuapp.com/try/todo.hs/edit rename the programs if you modify them. Follow the instructions to download the HTML generated, that include the Javascript generated. At this time there are no permission controls so it is more or less like a wiki, but heroku from time to time will reset the application. It is a free instance on heroku so expect delays and request timeouts when many people access to the application. I do not know what will happen. Feedback welcome My heroku instance is limited but It is easy to create your own instance in heroku. Follow the install instructions. Haste: https://github.com/valderman/haste-compiler http://haste-lang.org hplayground: https://github.com/agocorona/hplayground -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From creswick at gmail.com Thu Sep 4 20:36:47 2014 From: creswick at gmail.com (Rogan Creswick) Date: Thu, 4 Sep 2014 13:36:47 -0700 Subject: [Haskell-cafe] Maintaining test-suite dependencies with cabal In-Reply-To: References: Message-ID: On Fri, Aug 22, 2014 at 10:22 AM, Omari Norman wrote: > > > But a tool like Cartel does nothing about compile times. If compile times > are really a concern, I would just put the library in a completely separate > package and package the executables and tests separately. > One way to help reduce compile times (a bit anyway) is to separate the executables and tests into parallel source directories from your library code. I generally use a layout like this: / - project.cabal - src/ - apps/ - tests/resources/ - tests/src/ Library code goes in src, application Main's go in apps/, test source goes in tests/src/ and any necessary data files go in tests/resources. Then tests and apps defined in the cabal file depend on the library, and the source for the library is not rebuilt for each executable/test declaration in the cabal file (generally speaking; with flags and custom builds you can cause just about anything...) --Rogan -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Fri Sep 5 01:14:21 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 05 Sep 2014 02:14:21 +0100 Subject: [Haskell-cafe] Elm-like IDE for Haste projects In-Reply-To: References: Message-ID: <54090E6D.7070801@fuuzetsu.co.uk> On 09/04/2014 09:23 PM, Alberto G. Corona wrote: > Following the thread on lightweight Web interfaces for Haskell: > > http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/112586 > > I finished an Elm-like IDE for Haste projects. The software is at: > > https://github.com/agocorona/tryhplay > > Running in a heroku instance: > > http://tryplayg.herokuapp.com > > Besides to edit-compile and run, it can also import , compile and run haste > projects from git repositories (Although this, like the rest of the project > is experimental). > > I use it for my hplayground framework but it can run any haste project. > > Using playground is easy to translate console programs to the browser and > have reactive effects > > A simple example: > > http://tryplayg.herokuapp.com/try/console.hs/edit > > the hello-haste example: > > http://tryplayg.herokuapp.com/try/hello-haste.hs/edit > > Or something more complicated: the todo application, from todoMVC.com > written in Haste and hplayground: > > http://tryplayg.herokuapp.com/try/todo.hs/edit This makes my browser segfault ;( I'm using ?dwb?. > rename the programs if you modify them. Follow the instructions to download > the HTML generated, that include the Javascript generated. At this time > there are no permission controls so it is more or less like a wiki, but > heroku from time to time will reset the application. > > It is a free instance on heroku so expect delays and request timeouts when > many people access to the application. I do not know what will happen. > Feedback welcome > > > > My heroku instance is limited but It is easy to create your own instance in > heroku. Follow the install instructions. > > > Haste: https://github.com/valderman/haste-compiler > http://haste-lang.org > > hplayground: https://github.com/agocorona/hplayground > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Mateusz K. From kyle.marek.spartz at gmail.com Thu Sep 4 21:46:13 2014 From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz) Date: Thu, 4 Sep 2014 16:46:13 -0500 Subject: [Haskell-cafe] Parallel evaluation of code dependencies In-Reply-To: References: Message-ID: <38931504-444d-4c16-a4ce-96e506d47519@highlander> If you can infer dependencies from the DSL, it should be reasonable to use those dependencies to inform your use of something like Control.Parallel.Strategies. I?ve been working through Simon Marlow?s Parallel and Concurrent Haskell book, and it covers the latter half of this. The first half (inferring dependencies from the DSL) depends a lot on how your DSL is structured. http://chimera.labs.oreilly.com/books/1230000000929/ch03.html ? Kyle Marek-Spartz On Sep 4, 2014, 1:00:46 PM, felipe zapata wrote: Hi Cafe, Suppose that I have a representation of a DSL in Haskell (a physical number crunching simulation using quasiquoting for instance) and I want to evaluate the resulting Haskell representation by splitting it into chunks and send these chunk to some cluster, a supercomputer, etc. It doesn't matter for the moment the distribution protocol. My advisor suggested me that the best way of doing such a thing, is through a call by value strategy. Where I simply evaluate in parallel all the arguments of the functions. The problem with this alternative is that I must manipulate the Haskell representation and use some library ( or write some code) to identify the dependencies and evaluate them in parallel. Can please someone suggest me the best way to tackle this problem? I really appreciate any help. Felipe Z. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Fri Sep 5 16:22:43 2014 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri, 5 Sep 2014 09:22:43 -0700 Subject: [Haskell-cafe] Fwd: an idea for improving 'shrink' In-Reply-To: References: Message-ID: On Thu, Sep 4, 2014 at 1:06 PM, Petr Pudl?k wrote: > since I got no response from the QuickCheck mail address, so I'm resending > it here, if someone wants to comment on the idea. > I don't think it pays its way: it makes shrink a bit tidier, at the cost of breaking backwards compatibility in a widely used library. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai at kzhang.org Fri Sep 5 21:02:54 2014 From: kai at kzhang.org (Kai Zhang) Date: Fri, 5 Sep 2014 14:02:54 -0700 Subject: [Haskell-cafe] Can't create a static Linux executable when using hmatrix Message-ID: Hi Cafe, I am trying to build a static exec to be run on another machine, and I failed probably due to hmatrix. How can I fix this? Thanks! Test code: import Numeric.LinearAlgebra.Data main = print (fromLists [[2,3,3], [2,3,3]] :: Matrix Double) When complied with "ghc -O2 -static -optc-static -optl-static test.hs -optl-pthread", gave me lots of errors: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In function `dgees_': (.text+0xbc4): undefined reference to `dcopy_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In function `dgees_': (.text+0xed9): undefined reference to `dswap_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In function `dgees_': (.text+0x1304): undefined reference to `dswap_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In function `dgees_': (.text+0x1377): undefined reference to `dswap_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0xf9a): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0xfd4): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x1022): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x103b): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x109c): undefined reference to `idamax_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x1125): undefined reference to `drot_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x12aa): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x12e4): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x1332): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x134b): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x13ac): undefined reference to `idamax_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x143d): undefined reference to `drot_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x148e): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x14bc): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x14fe): undefined reference to `dnrm2_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In function `dgeev_': (.text+0x152c): undefined reference to `dscal_' /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgehrd.o): In function `dgehrd_': (.text+0x65d): undefined reference to `dtrmm_' . . . -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.mvd at gmail.com Sat Sep 6 09:17:30 2014 From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=) Date: Sat, 6 Sep 2014 11:17:30 +0200 Subject: [Haskell-cafe] Fwd: an idea for improving 'shrink' In-Reply-To: References: Message-ID: 2014-09-05 18:22 GMT+02:00 Bryan O?Sullivan : > On Thu, Sep 4, 2014 at 1:06 PM, Petr Pudl?k wrote: > >> since I got no response from the QuickCheck mail address, so I'm >> resending it here, if someone wants to comment on the idea. >> > > I don't think it pays its way: it makes shrink a bit tidier, at the cost > of breaking backwards compatibility in a widely used library. > That?s a problem. But I believe it the patch addresses it. QuickCheck always uses ?shrink?, not ?shrinkA?, and as the default implementation of ?shrink? is defined in terms of ?shrinkA?, then it?s possible to define instances both using ?shrink? and using ?shrinkA?. So both old code and new code that wants to take advantage of the Applicative interface work. I believe that in the long term this change would pay off: Compare the old code shrinkOne [] = [] shrinkOne (x:xs) = [ x':xs | x' <- shr x ] ++ [ x:xs' | xs' <- shrinkOne xs ] shrink (x, y) = [ (x', y) | x' <- shrink x ] ++ [ (x, y') | y' <- shrink y ] shrink (x, y, z) = [ (x', y', z') | (x', (y', z')) <- shrink (x, (y, z)) ] against the improved piece traverse shr xs -- replaces the whole shrinkOne shrinkA (x, y) = liftA2 (,) (shrinkA x) (shrinkA y) shrinkA (x, y, z) = liftA3 (,,) (shrinkA x) (shrinkA y) (shrinkA z) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bneijt at gmail.com Sat Sep 6 10:19:47 2014 From: bneijt at gmail.com (Bram Neijt) Date: Sat, 6 Sep 2014 12:19:47 +0200 Subject: [Haskell-cafe] Maintaining test-suite dependencies with cabal In-Reply-To: References: Message-ID: I have split up my dependencies and placed them in separate directories. This was all pretty easy to do, however I do have one thing I don't understand. My Main.hs[1] includes: import After (afterPartialCmdline, afterPid) And my after.cabal[2] has a library exposing the After module. It looks like me that Main.hs only uses functions from After, however if I don't list "Process" in the "exposed-modules:" I get a linker error: Linking dist/build/after/after ... /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.text+0x90a): undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine4_closure' /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.text+0x945): undefined reference to `afterzm0zi1zi2zi0_Process_psListing2_closure' /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.text+0x4a3): undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine1_info' /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.text+0x6ca): undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine1_info' /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.data+0xf0): undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine1_closure' /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.data+0x108): undefined reference to `afterzm0zi1zi2zi0_Process_psListing2_closure' /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.data+0x118): undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine4_closure' collect2: error: ld returned 1 exit status Why do I have to mention "Process" in the exposed modules list? Doesn't this mean that I eventuall have to mention all my modules in the exposed modules list, and then what is the point of having to mention them in the first place? Greetings, Bram [1] https://github.com/bneijt/after/blob/master/src/main/Main.hs [2] https://github.com/bneijt/after/blob/master/after.cabal On Thu, Sep 4, 2014 at 10:36 PM, Rogan Creswick wrote: > > On Fri, Aug 22, 2014 at 10:22 AM, Omari Norman > wrote: >> >> >> But a tool like Cartel does nothing about compile times. If compile times >> are really a concern, I would just put the library in a completely separate >> package and package the executables and tests separately. > > > One way to help reduce compile times (a bit anyway) is to separate the > executables and tests into parallel source directories from your library > code. I generally use a layout like this: > > / > - project.cabal > - src/ > - apps/ > - tests/resources/ > - tests/src/ > > Library code goes in src, application Main's go in apps/, test source goes > in tests/src/ and any necessary data files go in tests/resources. > > Then tests and apps defined in the cabal file depend on the library, and the > source for the library is not rebuilt for each executable/test declaration > in the cabal file (generally speaking; with flags and custom builds you can > cause just about anything...) > > --Rogan > From corentin.dupont at gmail.com Sat Sep 6 10:35:10 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Sat, 6 Sep 2014 12:35:10 +0200 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: References: Message-ID: Nobody on those parallel interruptible computations/events? I believe this is related to FRP: we register on several events but only a part of them is enough to compute the result. But I don't see such operator in FRP frameworks such as reactive-banana... On Fri, Sep 5, 2014 at 12:59 PM, Corentin Dupont wrote: > Hi guys! > I'm wondering if there is an abstraction (for example a typeclass) for > parallel interruptible computations. > I want several things to be computed in parallel. Those computations will > not finish at the same time, but as soon as enough result is gathered, the > remaining computations can be cancelled and the final result computed. > Clearly a Monad is not suited here: Monad are by definition for sequential > computation (since the result of the first computation is fed to the next). > > -> So the question is: is there an abstraction for parallel computations? > > Note that I'm not interrested with real implementations (such as with > threads) but with the abstraction. > For now I came up with: > > ShortcutEvents :: [Event a] -> ([a] -> Maybe b) -> Event b > > This takes a list of events and a function. The events can fire at > whatever moment, and as soon as one of the events fires, the function is > called with the results available so far. If the function returns Just, the > remaining events are cancelled and the final result is returned. > This is working fine, but I'd like a way to generalize this, especially to > generalize the list to any structure... > > The use case is a voting system: people can vote at whatever moment, but > sometime the result of the vote is known even if not everybody voted yet. > > Thanks! > Corentin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Sat Sep 6 10:58:53 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Sat, 6 Sep 2014 12:58:53 +0200 Subject: [Haskell-cafe] Maintaining test-suite dependencies with cabal In-Reply-To: References: Message-ID: You shoud list 'Process' in the 'other-modules' section of your library. Every module should be either in the exposed or other modules list. Ideally cabal would check this for you, see https://github.com/haskell/cabal/pull/1455 Regards, Erik On Sat, Sep 6, 2014 at 12:19 PM, Bram Neijt wrote: > I have split up my dependencies and placed them in separate > directories. This was all pretty easy to do, however I do have one > thing I don't understand. > > My Main.hs[1] includes: import After (afterPartialCmdline, afterPid) > And my after.cabal[2] has a library exposing the After module. > > It looks like me that Main.hs only uses functions from After, however > if I don't list "Process" in the "exposed-modules:" I get a linker > error: > > Linking dist/build/after/after ... > /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.text+0x90a): > undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine4_closure' > /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.text+0x945): > undefined reference to `afterzm0zi1zi2zi0_Process_psListing2_closure' > /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.text+0x4a3): > undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine1_info' > /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.text+0x6ca): > undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine1_info' > /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.data+0xf0): > undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine1_closure' > /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.data+0x108): > undefined reference to `afterzm0zi1zi2zi0_Process_psListing2_closure' > /home/bram/program/after/dist/build/libHSafter-0.1.2.0.a(After.o):(.data+0x118): > undefined reference to `afterzm0zi1zi2zi0_Process_psCmdLine4_closure' > collect2: error: ld returned 1 exit status > > Why do I have to mention "Process" in the exposed modules list? > > Doesn't this mean that I eventuall have to mention all my modules in > the exposed modules list, and then what is the point of having to > mention them in the first place? > > Greetings, > > Bram > > [1] https://github.com/bneijt/after/blob/master/src/main/Main.hs > [2] https://github.com/bneijt/after/blob/master/after.cabal > > On Thu, Sep 4, 2014 at 10:36 PM, Rogan Creswick wrote: >> >> On Fri, Aug 22, 2014 at 10:22 AM, Omari Norman >> wrote: >>> >>> >>> But a tool like Cartel does nothing about compile times. If compile times >>> are really a concern, I would just put the library in a completely separate >>> package and package the executables and tests separately. >> >> >> One way to help reduce compile times (a bit anyway) is to separate the >> executables and tests into parallel source directories from your library >> code. I generally use a layout like this: >> >> / >> - project.cabal >> - src/ >> - apps/ >> - tests/resources/ >> - tests/src/ >> >> Library code goes in src, application Main's go in apps/, test source goes >> in tests/src/ and any necessary data files go in tests/resources. >> >> Then tests and apps defined in the cabal file depend on the library, and the >> source for the library is not rebuilt for each executable/test declaration >> in the cabal file (generally speaking; with flags and custom builds you can >> cause just about anything...) >> >> --Rogan >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From bertram.felgenhauer at googlemail.com Sat Sep 6 14:56:55 2014 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat, 6 Sep 2014 16:56:55 +0200 Subject: [Haskell-cafe] Functional dependency failure In-Reply-To: <2222731409690737@web7g.yandex.ru> References: <2222731409690737@web7g.yandex.ru> Message-ID: <20140906145655.GA6459@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Alexander Pakhomov wrote: > I have following code: > > import Control.Monad.Reader > import Control.Monad.ST > import qualified Data.Vector.Mutable as MV > import qualified Data.Vector as V > > type ReadVecMonad s = ReaderT (MV.MVector s Int) (ST s) > > freezeV :: ReadVecMonad s (V.Vector Int) > freezeV = ask >>= lift V.freeze You are asking to lift a function of type MV.MVector s Int -> ST s (V.Vector Int) to another one of type MV.MVector s Int -> ReaderT (MV.MVector s Int) (ST s) (V.Vector Int) However, `lift` works on monad actions. This works: freezeV :: ReadVecMonad s (V.Vector Int) freezeV = ask >>= lift . V.freeze > Trying to compile this I have "Couldn't match type ... When using functional dependencies to combine" error > following with kind mismatch and type with literaly the same type mismatch. Ghc's error message is wonderfully convoluted. Let's try to follow. We know that freezeV :: ReadVecMonad s (V.Vector Int) and (>>=) :: Monad m => m a -> (a -> m b) -> m b, so that ask :: ReadVecMonad s r lift V.freeze :: r -> ReadVecMonad s (V.Vector Int) ghc infers the following type for `lift V.freeze`: lift V.freeze :: (Control.Monad.Primitive.PrimMonad m, MonadTrans t) => t ((->) (V.MVector (Control.Monad.Primitive.PrimState m) a)) (m (V.Vector a)) To unify the two types for `lift V.freeze`, we let t = (->) r = (->) (V.MVector (Control.Monad.Primitive.PrimState m) a) m = ReadVecMonad s a = Int Therefore, we must have ask :: ReadVecMonad s ((->) (V.MVector (Control.Monad.Primitive.PrimState (ReadVecMonad s)) Int)) ask :: ReaderT (MV.MVector s Int) (ST s) ((->) (V.MVector (Control.Monad.Primitive.PrimState (ReadVecMonad s)) Int)) We also know that ask :: MonadReader m r => m r. In our case, m = ReaderT (MV.MVector s Int) (ST s). From the instance MonadReader r (ReaderT r m) and the functional dependency m -> r, we conclude that r = MV.MVector s Int. This, of course, is in contradiction with the already established r = (->) (V.MVector (Control.Monad.Primitive.PrimState (ReadVecMonad s)) Int) Phew. The kind errors later on arise from the fact that we have replaced t :: (* -> *) -> * -> * (t is supposed to be a monad transformer) by (->) :: * -> * -> *, and r :: * by something of kind * -> *. Newer ghc versions seem to arrive at r = MV.MVector s Int before r = (->) (V.MVector (Control.Monad.Primitive.PrimState (ReadVecMonad s)) Int) and do not mention functional dependencies as a result. Hope that helps, Bertram > There's full error message: > > STRead.hs:9:11: > Couldn't match type `V.MVector s Int' > with `(->) > (V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int)' > When using functional dependencies to combine > MonadReader r (ReaderT r m), > arising from the dependency `m -> r' > in the instance declaration in `Control.Monad.Reader.Class' > MonadReader > ((->) > (V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int)) > (ReaderT (V.MVector s Int) (ST s)), > arising from a use of `ask' at STRead.hs:9:11-13 > In the first argument of `(>>=)', namely `ask' > In the expression: ask >>= lift V.freeze > > > STRead.hs:9:19: > Couldn't match kind `* -> *' with `*' > Expected type: (->) > (V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int) > -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) > Actual type: (->) > (V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int) > -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) > Kind incompatibility when matching types: > (->) > (V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int) :: * -> * > (->) > (V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int) :: * > In the return type of a call of `lift' > In the second argument of `(>>=)', namely `lift V.freeze' > > STRead.hs:9:24: > Couldn't match kind `*' with `* -> *' > Expected type: V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int > -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) > Actual type: V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int > -> ReaderT (V.MVector s Int) (ST s) (V.Vector Int) > Kind incompatibility when matching types: > (->) > (V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int) :: * > (->) > (V.MVector > (Control.Monad.Primitive.PrimState > (ReaderT (V.MVector s Int) (ST s))) > Int) :: * -> * > In the first argument of `lift', namely `V.freeze' > In the second argument of `(>>=)', namely `lift V.freeze' From bos at serpentine.com Sat Sep 6 17:17:07 2014 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat, 6 Sep 2014 10:17:07 -0700 Subject: [Haskell-cafe] Fwd: an idea for improving 'shrink' In-Reply-To: References: Message-ID: On Sat, Sep 6, 2014 at 2:17 AM, Petr Pudl?k wrote: > That?s a problem. But I believe it the patch addresses it. QuickCheck > always uses ?shrink?, not ?shrinkA?, and as the default implementation of > ?shrink? is defined in terms of ?shrinkA?, then it?s possible to define > instances both using ?shrink? and using ?shrinkA?. Ah, if you can retain backwards compatibility, then it becomes a lot more interesting... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Sun Sep 7 00:13:39 2014 From: lambda.fairy at gmail.com (Chris Wong) Date: Sun, 7 Sep 2014 12:13:39 +1200 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: References: Message-ID: Hi Corentin, On Sat, Sep 6, 2014 at 10:35 PM, Corentin Dupont wrote: > Nobody on those parallel interruptible computations/events? > I believe this is related to FRP: we register on several events but only a > part of them is enough to compute the result. > But I don't see such operator in FRP frameworks such as reactive-banana... FRP libraries don't expose such a combinator, because ultimately it can be decomposed into three problems: 1. Listening to multiple events 2. Maintaining internal state 3. Filtering out events that fit specific criteria --- For (1), we use something like: merge :: Event a -> Event a -> Event a For (2), we can use a Mealy machine: collect :: (s -> a -> (b, s)) -> s -> Event a -> Event b For (3), we expose a filtering combinator filterJust :: Event (Maybe a) -> Event a which discards Nothing events. --- Now plug it all together: listenN :: Int -> [Event a] -> Event a listenN n = filterJust . collect f [] . merge where f xs x | length xs >= n = (Just xs, xs) -- ignore | otherwise = (Nothing, x : xs) -- accumulate Hope this helps. Chris > On Fri, Sep 5, 2014 at 12:59 PM, Corentin Dupont > wrote: >> >> Hi guys! >> I'm wondering if there is an abstraction (for example a typeclass) for >> parallel interruptible computations. >> I want several things to be computed in parallel. Those computations will >> not finish at the same time, but as soon as enough result is gathered, the >> remaining computations can be cancelled and the final result computed. >> Clearly a Monad is not suited here: Monad are by definition for sequential >> computation (since the result of the first computation is fed to the next). >> >> -> So the question is: is there an abstraction for parallel computations? >> >> Note that I'm not interrested with real implementations (such as with >> threads) but with the abstraction. >> For now I came up with: >> >> ShortcutEvents :: [Event a] -> ([a] -> Maybe b) -> Event b >> >> This takes a list of events and a function. The events can fire at >> whatever moment, and as soon as one of the events fires, the function is >> called with the results available so far. If the function returns Just, the >> remaining events are cancelled and the final result is returned. >> This is working fine, but I'd like a way to generalize this, especially to >> generalize the list to any structure... >> >> The use case is a voting system: people can vote at whatever moment, but >> sometime the result of the vote is known even if not everybody voted yet. >> >> Thanks! >> Corentin > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From nomeata at debian.org Sun Sep 7 08:10:38 2014 From: nomeata at debian.org (Joachim Breitner) Date: Sun, 07 Sep 2014 10:10:38 +0200 Subject: [Haskell-cafe] [ANN] haddock-2.15-0, haddock-api-2.15-0, haddock-library-1.1.1 In-Reply-To: <54032824.103@fuuzetsu.co.uk> References: <54032824.103@fuuzetsu.co.uk> Message-ID: <1410077438.24043.3.camel@debian.org> Hi, Am Sonntag, den 31.08.2014, 14:50 +0100 schrieb Mateusz Kowalczyk: > I'd like to announce the release of Haddock 2.15.0. Cool. How compatible are the .haddock files? In particular, and not only related to this upgrade: Under what condition can Debian upgrade haddock (resp. haddock-api resp. haddock-library) so that the .haddock files generated by the compiler build, using the haddock version that was shipped with GHC, can still be used? Greetings, Joacihm -- Joachim "nomeata" Breitner Debian Developer nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gesh at gesh.uni.cx Sun Sep 7 09:33:24 2014 From: gesh at gesh.uni.cx (Gesh) Date: Sun, 07 Sep 2014 12:33:24 +0300 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: References: Message-ID: <540C2664.2020102@gesh.uni.cx> For what it's worth, Conal Elliott did a series of blog posts on a similar subject[0]. One use case of the library he wrote for this is to write zip as lazily as possible[1], i.e. in such a way that, even if xs=undefined, zip [] xs = zip xs [] = undefined. Hopefully, this example can help you. Gesh [0] - http://conal.net/blog/posts/merging-partial-values [1] - http://www.haskell.org/pipermail/haskell-cafe/2009-January/053966.html From fuuzetsu at fuuzetsu.co.uk Sun Sep 7 11:31:33 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 07 Sep 2014 12:31:33 +0100 Subject: [Haskell-cafe] [ANN] haddock-2.15-0, haddock-api-2.15-0, haddock-library-1.1.1 In-Reply-To: <1410077438.24043.3.camel@debian.org> References: <54032824.103@fuuzetsu.co.uk> <1410077438.24043.3.camel@debian.org> Message-ID: <540C4215.2070407@fuuzetsu.co.uk> On 09/07/2014 09:10 AM, Joachim Breitner wrote: > Hi, > > > Am Sonntag, den 31.08.2014, 14:50 +0100 schrieb Mateusz Kowalczyk: >> I'd like to announce the release of Haddock 2.15.0. > > Cool. > > How compatible are the .haddock files? If you're coming from 2.14.3 then there is no problem. I think the last change was at 2.14.0 so if you're on then you should be good to update. If you're on 2.13.x or earlier then you'll have to regenerate all the docs but IIRC the GHC versions that 2.13 and 2.14/15 are compatible with are different anyway so you can't have both co-existing. You can check what your current cversion is at through haddock --compatible-interface-versions although that flag has been a fairly recent addition (2.14.0). For 2.14.0-2.15.0 it is version ?25?. > In particular, and not only related to this upgrade: Under what > condition can Debian upgrade haddock (resp. haddock-api resp. > haddock-library) so that the .haddock files generated by the compiler > build, using the haddock version that was shipped with GHC, can still be > used? tl;dr: as long as the interface doesn't change but when that actually happens, depends. Personally I try to time this with a GHC release so that people don't tend to notice as you normally don't mix the files generated by different versions. cheat sheet: GHC 7.6.3 -> 7.8.3, no good, interface changed 2.14.0 ->* 2.15.0, all good, same interface 2.15.0 ->* future, no idea! At the moment I think we don't have any changes in plans. If GHC 7.10 doesn't result in some big changes or we don't have new, breaking features then it well may be possible that Haddock 2.16 or whatever it will be at next GHC will be compatible with 7.8.2/7.8.3/7.10.x through some CPP on our end to account for API changes. If it adds new structures and stuff we need to store information about (PatternSynonyms are an example of a thing that we'd need to store info about but that wasn't around for 7.6.3) then we have to bump it. It may well be that we could improve the way we store the interfaces, such as store GHC version too and read that off so we know what we're working with. This could make it a bit more future-proof but it'd be difficult to maintain. Ironically, such a change would itself result in an interface version bump. Long-winded answer: First a brief overview. ?haddock? is now simply a Main module over ?haddock-api?, I think the updates to ?haddock? in the future will simply be bumping the ?haddock-api? version in its cabal file so that it's easy to keep track. ?haddock-api? is where the bulk of the work is, all the nasty ?talk to GHC? stuff and serialisation. This depends on ?haddock-library? which means that if ?haddock-library? has breaking changes then ?haddock-api? has to be updated too. ?haddock-library? is the bits that don't need GHC, currently only the parser but hopefully more in the future. Ideally you want to use the latest version of each together with each other but you can freely update ?haddock-library? as long as it didn't have breaking changes. Currently ?haddock-api? has 1.1.1.* constraint. and it should work with all matching versions. In summary, if ?haddock? updates, you want to update ?haddock-api? too. If ?haddock-library? makes a minor release, you can (but don't have to) update it on its own. If it makes a breaking release then ?haddock-api? will be updated too. We'll basically make sure that the latest ?haddock-api? compiles with its ?haddock-library? constraint. Now to try and answer your question: it's fairly easy to find out if you're compatible simply with --compatible-interface-versions. We update either when: 1. there was new markup 2. there was a GHC change that results in different binary format So far I have not seen 2. happen yet but if it does happen, it will be at new GHC release, changing this CPP: binaryInterfaceVersion :: Word16 #if __GLASGOW_HASKELL__ == 708 binaryInterfaceVersion = 25 binaryInterfaceVersionCompatibility :: [Word16] binaryInterfaceVersionCompatibility = [binaryInterfaceVersion] #else #error Unsupported GHC version #endif The 1. point doesn't happen often but it does happen, such as when I added the new syntax for headers or bold; another example was when I wanted to store language extensions used in the module. This was coordinated with 7.8.x release so that most people wouldn't have noticed there was interface change. > Greetings, > Joacihm > -- Mateusz K. From corentin.dupont at gmail.com Sun Sep 7 20:23:21 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Sun, 7 Sep 2014 22:23:21 +0200 Subject: [Haskell-cafe] Parallel interruptible computations Message-ID: Hi guys, thanks for the nice answers! I'll give you a little bit more context: I'm designing an event engine. I have instances for Applicative, Alternative, Monad, MonadPlus. It's like that: -- | Composable events data Event a where SumEvent :: Event a -> Event a -> Event a -- The first event to fire will be returned. AppEvent :: Event (a -> b) -> Event a -> Event b -- Both events should fire, and then the result is returned. PureEvent :: a -> Event a -- Create a fake event. The result is useable with no delay. EmptyEvent :: Event a -- An event that is never fired. BindEvent :: Event a -> (a -> Event b) -> Event b -- The first event should fire, then a second event is created using the result. BaseEvent :: BaseEvent a -> Event a -- Embed a base event. ShortcutEvents :: [Event a] -> ([Maybe a] -> Maybe b) -> Event b -- The function is called each time an event fires, as soon as the result can be computed from the available data, it is returned, dismissing the events that haven't fired yet. instance Functor Event where fmap f a = pure f <*> a instance Applicative Event where pure = PureEvent (<*>) = AppEvent instance Alternative Event where (<|>) = SumEvent empty = EmptyEvent instance Monad Event where (>>=) = BindEvent return = PureEvent instance MonadPlus Event where mplus = SumEvent mzero = EmptyEvent The Applicative instance is good if you have two events and you want both of them to fire ("and"). The Alternative instance is good if you have two events and you need only one to fire ("or"). But what if you have several events, but you need only a part of them to fire in order to construct a final result? Say you have 10 events, but the 5 first to fire will give you enough data to construct a result. You cannot do that with Applicative/Alternative because with Applicative, you need *all* events results, with Alternative you need *only one*. That's why I added this primitive "ShortcutEvents" in my DSL, but I'm not convinced by it. So my questions are: 1. is ShortcutEvents expressible in term of Applicative/Alternative/Monad/MonadPlus? 2. if not is their a well known typeclass that covers this case? 3. if not is their a better way to write it? I especially don't like the list of Event, I'd prefer a more generic writing. What if I want a structure containing the events, instead of a list? What if I want event of various types (say a pair (Event a, Event b) for example)? Note that I'm not working with streams of events (like in traditional FRP frameworks): just with single events (the "BaseEvents") that I want to combine with each other. Those "BaseEvents" will fire only once. The final result of the combination of events will trigger a callback. Cheers, Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Sep 8 00:41:18 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 8 Sep 2014 02:41:18 +0200 Subject: [Haskell-cafe] Can't create a static Linux executable when using hmatrix In-Reply-To: References: Message-ID: The error says all, you need to install blas / lapack on the target system OR static link those same libs. Adding ransom flags that use the word static wont do that :-) On Sep 5, 2014 5:03 PM, "Kai Zhang" wrote: > Hi Cafe, > > I am trying to build a static exec to be run on another machine, and I > failed probably due to hmatrix. How can I fix this? Thanks! > > Test code: > > import Numeric.LinearAlgebra.Data > > main = print (fromLists [[2,3,3], [2,3,3]] :: Matrix Double) > > When complied with "ghc -O2 -static -optc-static -optl-static test.hs > -optl-pthread", gave me lots of errors: > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In > function `dgees_': > > (.text+0xbc4): undefined reference to `dcopy_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In > function `dgees_': > > (.text+0xed9): undefined reference to `dswap_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In > function `dgees_': > > (.text+0x1304): undefined reference to `dswap_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): In > function `dgees_': > > (.text+0x1377): undefined reference to `dswap_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0xf9a): undefined reference to `dnrm2_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0xfd4): undefined reference to `dnrm2_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x1022): undefined reference to `dscal_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x103b): undefined reference to `dscal_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x109c): undefined reference to `idamax_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x1125): undefined reference to `drot_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x12aa): undefined reference to `dnrm2_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x12e4): undefined reference to `dnrm2_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x1332): undefined reference to `dscal_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x134b): undefined reference to `dscal_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x13ac): undefined reference to `idamax_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x143d): undefined reference to `drot_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x148e): undefined reference to `dnrm2_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x14bc): undefined reference to `dscal_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x14fe): undefined reference to `dnrm2_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): In > function `dgeev_': > > (.text+0x152c): undefined reference to `dscal_' > > /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgehrd.o): > In function `dgehrd_': > > (.text+0x65d): undefined reference to `dtrmm_' > > . > > . > > . > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Sep 8 00:42:30 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 8 Sep 2014 02:42:30 +0200 Subject: [Haskell-cafe] Can't create a static Linux executable when using hmatrix In-Reply-To: References: Message-ID: I'm just landing after 12-14 hours of travel or I'd probably have q more actionable suggestion. On Sep 7, 2014 8:41 PM, "Carter Schonwald" wrote: > The error says all, you need to install blas / lapack on the target system > OR static link those same libs. Adding ransom flags that use the word > static wont do that :-) > On Sep 5, 2014 5:03 PM, "Kai Zhang" wrote: > >> Hi Cafe, >> >> I am trying to build a static exec to be run on another machine, and I >> failed probably due to hmatrix. How can I fix this? Thanks! >> >> Test code: >> >> import Numeric.LinearAlgebra.Data >> >> main = print (fromLists [[2,3,3], [2,3,3]] :: Matrix Double) >> >> When complied with "ghc -O2 -static -optc-static -optl-static test.hs >> -optl-pthread", gave me lots of errors: >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): >> In function `dgees_': >> >> (.text+0xbc4): undefined reference to `dcopy_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): >> In function `dgees_': >> >> (.text+0xed9): undefined reference to `dswap_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): >> In function `dgees_': >> >> (.text+0x1304): undefined reference to `dswap_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgees.o): >> In function `dgees_': >> >> (.text+0x1377): undefined reference to `dswap_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0xf9a): undefined reference to `dnrm2_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0xfd4): undefined reference to `dnrm2_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x1022): undefined reference to `dscal_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x103b): undefined reference to `dscal_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x109c): undefined reference to `idamax_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x1125): undefined reference to `drot_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x12aa): undefined reference to `dnrm2_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x12e4): undefined reference to `dnrm2_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x1332): undefined reference to `dscal_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x134b): undefined reference to `dscal_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x13ac): undefined reference to `idamax_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x143d): undefined reference to `drot_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x148e): undefined reference to `dnrm2_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x14bc): undefined reference to `dscal_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x14fe): undefined reference to `dnrm2_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgeev.o): >> In function `dgeev_': >> >> (.text+0x152c): undefined reference to `dscal_' >> >> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapack.a(dgehrd.o): >> In function `dgehrd_': >> >> (.text+0x65d): undefined reference to `dtrmm_' >> >> . >> >> . >> >> . >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Sep 8 00:44:42 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 7 Sep 2014 20:44:42 -0400 Subject: [Haskell-cafe] Can't create a static Linux executable when using hmatrix In-Reply-To: References: Message-ID: On Sun, Sep 7, 2014 at 8:41 PM, Carter Schonwald wrote: > The error says all, you need to install blas / lapack on the target system > OR static link those same libs. Adding ransom flags that use the word > static wont do that :-) > More to the point, lapack is static there but the missing functions are provided by the blas library, which either wasn't included in the link or isn't available on your system as a static library. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.sorokin at gmail.com Mon Sep 8 01:53:48 2014 From: david.sorokin at gmail.com (David Sorokin) Date: Mon, 8 Sep 2014 05:53:48 +0400 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: References: Message-ID: <530F1984-580F-4738-988C-A16FD863431C@gmail.com> Corentin, As far as I understand, it is similar in implementation to what I have in my simulation library Aivika [1]. Please correct me if I am wrong: -- | Execute the specified computations in parallel within -- the current computation and return their results. The cancellation -- of any of the nested computations affects the current computation. -- The exception raised in any of the nested computations is propagated -- to the current computation as well. processParallel :: [Process a] -> Process [a] It looks like that my Process type is an equivalent of your type Event in some sense. Only here we would have to cancel (or, interrupt in your terms) all other Process computations right after we receive a final result. So, if it is true then it is possible to write a new function based on the stated above so that it would be similar to the ShortcutEvents function: shortcutProcesses: [Process a] -> ([Maybe a] -> Maybe b) -> Process b Probably, I should add such a function to my library too. Thanks, David [1] http://hackage.haskell.org/package/aivika 08 ????. 2014 ?., ? 0:23, Corentin Dupont ???????(?): > Hi guys, > thanks for the nice answers! > I'll give you a little bit more context: I'm designing an event engine. I have instances for Applicative, Alternative, Monad, MonadPlus. > It's like that: > > > -- | Composable events > data Event a where > SumEvent :: Event a -> Event a -> Event a -- The first event to fire will be returned. > AppEvent :: Event (a -> b) -> Event a -> Event b -- Both events should fire, and then the result is returned. > PureEvent :: a -> Event a -- Create a fake event. The result is useable with no delay. > EmptyEvent :: Event a -- An event that is never fired. > BindEvent :: Event a -> (a -> Event b) -> Event b -- The first event should fire, then a second event is created using the result. > BaseEvent :: BaseEvent a -> Event a -- Embed a base event. > ShortcutEvents :: [Event a] -> ([Maybe a] -> Maybe b) -> Event b -- The function is called each time an event fires, as soon as the result can be computed from the available data, it is returned, dismissing the events that haven't fired yet. > > > instance Functor Event where > fmap f a = pure f <*> a > > instance Applicative Event where > pure = PureEvent > (<*>) = AppEvent > > instance Alternative Event where > (<|>) = SumEvent > empty = EmptyEvent > > instance Monad Event where > (>>=) = BindEvent > return = PureEvent > > instance MonadPlus Event where > mplus = SumEvent > mzero = EmptyEvent > > > The Applicative instance is good if you have two events and you want both of them to fire ("and"). The Alternative instance is good if you have two events and you need only one to fire ("or"). > But what if you have several events, but you need only a part of them to fire in order to construct a final result? Say you have 10 events, but the 5 first to fire will give you enough data to construct a result. > You cannot do that with Applicative/Alternative because with Applicative, you need *all* events results, with Alternative you need *only one*. > > That's why I added this primitive "ShortcutEvents" in my DSL, but I'm not convinced by it. So my questions are: > 1. is ShortcutEvents expressible in term of Applicative/Alternative/Monad/MonadPlus? > 2. if not is their a well known typeclass that covers this case? > 3. if not is their a better way to write it? I especially don't like the list of Event, I'd prefer a more generic writing. What if I want a structure containing the events, instead of a list? What if I want event of various types (say a pair (Event a, Event b) for example)? > > > Note that I'm not working with streams of events (like in traditional FRP frameworks): just with single events (the "BaseEvents") that I want to combine with each other. Those "BaseEvents" will fire only once. The final result of the combination of events will trigger a callback. > > Cheers, > Corentin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.sorokin at gmail.com Mon Sep 8 02:11:09 2014 From: david.sorokin at gmail.com (David Sorokin) Date: Mon, 8 Sep 2014 06:11:09 +0400 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: <530F1984-580F-4738-988C-A16FD863431C@gmail.com> References: <530F1984-580F-4738-988C-A16FD863431C@gmail.com> Message-ID: Corentin, Only in my case the computations are executed ultimately from the event queue and they are bound up with the modeling time. If the time as a factor is not needed in your case, then this is not a problem to exclude the queue from consideration. The main idea is how we can use continuations, one of which is invoked when canceling (interrupting) the computation. David 08 ????. 2014 ?., ? 5:53, David Sorokin ???????(?): > Corentin, > > As far as I understand, it is similar in implementation to what I have in my simulation library Aivika [1]. Please correct me if I am wrong: > > -- | Execute the specified computations in parallel within > -- the current computation and return their results. The cancellation > -- of any of the nested computations affects the current computation. > -- The exception raised in any of the nested computations is propagated > -- to the current computation as well. > processParallel :: [Process a] -> Process [a] > > It looks like that my Process type is an equivalent of your type Event in some sense. Only here we would have to cancel (or, interrupt in your terms) all other Process computations right after we receive a final result. > > So, if it is true then it is possible to write a new function based on the stated above so that it would be similar to the ShortcutEvents function: > > shortcutProcesses: [Process a] -> ([Maybe a] -> Maybe b) -> Process b > > Probably, I should add such a function to my library too. > > Thanks, > David > > [1] http://hackage.haskell.org/package/aivika > > > 08 ????. 2014 ?., ? 0:23, Corentin Dupont ???????(?): > >> Hi guys, >> thanks for the nice answers! >> I'll give you a little bit more context: I'm designing an event engine. I have instances for Applicative, Alternative, Monad, MonadPlus. >> It's like that: >> >> >> -- | Composable events >> data Event a where >> SumEvent :: Event a -> Event a -> Event a -- The first event to fire will be returned. >> AppEvent :: Event (a -> b) -> Event a -> Event b -- Both events should fire, and then the result is returned. >> PureEvent :: a -> Event a -- Create a fake event. The result is useable with no delay. >> EmptyEvent :: Event a -- An event that is never fired. >> BindEvent :: Event a -> (a -> Event b) -> Event b -- The first event should fire, then a second event is created using the result. >> BaseEvent :: BaseEvent a -> Event a -- Embed a base event. >> ShortcutEvents :: [Event a] -> ([Maybe a] -> Maybe b) -> Event b -- The function is called each time an event fires, as soon as the result can be computed from the available data, it is returned, dismissing the events that haven't fired yet. >> >> >> instance Functor Event where >> fmap f a = pure f <*> a >> >> instance Applicative Event where >> pure = PureEvent >> (<*>) = AppEvent >> >> instance Alternative Event where >> (<|>) = SumEvent >> empty = EmptyEvent >> >> instance Monad Event where >> (>>=) = BindEvent >> return = PureEvent >> >> instance MonadPlus Event where >> mplus = SumEvent >> mzero = EmptyEvent >> >> >> The Applicative instance is good if you have two events and you want both of them to fire ("and"). The Alternative instance is good if you have two events and you need only one to fire ("or"). >> But what if you have several events, but you need only a part of them to fire in order to construct a final result? Say you have 10 events, but the 5 first to fire will give you enough data to construct a result. >> You cannot do that with Applicative/Alternative because with Applicative, you need *all* events results, with Alternative you need *only one*. >> >> That's why I added this primitive "ShortcutEvents" in my DSL, but I'm not convinced by it. So my questions are: >> 1. is ShortcutEvents expressible in term of Applicative/Alternative/Monad/MonadPlus? >> 2. if not is their a well known typeclass that covers this case? >> 3. if not is their a better way to write it? I especially don't like the list of Event, I'd prefer a more generic writing. What if I want a structure containing the events, instead of a list? What if I want event of various types (say a pair (Event a, Event b) for example)? >> >> >> Note that I'm not working with streams of events (like in traditional FRP frameworks): just with single events (the "BaseEvents") that I want to combine with each other. Those "BaseEvents" will fire only once. The final result of the combination of events will trigger a callback. >> >> Cheers, >> Corentin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai at kzhang.org Mon Sep 8 05:15:10 2014 From: kai at kzhang.org (Kai Zhang) Date: Sun, 7 Sep 2014 22:15:10 -0700 Subject: [Haskell-cafe] Can't create a static Linux executable when using hmatrix In-Reply-To: References: Message-ID: I have both libblas.a and liblapck.a. locate libblas.a /etc/alternatives/libblas.a /usr/lib/libblas.a /usr/lib/libblas/libblas.a On Sun, Sep 7, 2014 at 5:44 PM, Brandon Allbery wrote: > On Sun, Sep 7, 2014 at 8:41 PM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> The error says all, you need to install blas / lapack on the target >> system OR static link those same libs. Adding ransom flags that use the >> word static wont do that :-) >> > > More to the point, lapack is static there but the missing functions are > provided by the blas library, which either wasn't included in the link or > isn't available on your system as a static library. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Mon Sep 8 05:55:24 2014 From: lambda.fairy at gmail.com (Chris Wong) Date: Mon, 8 Sep 2014 17:55:24 +1200 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: References: Message-ID: Hi Corentin On Mon, Sep 8, 2014 at 8:23 AM, Corentin Dupont wrote: > Hi guys, > thanks for the nice answers! > I'll give you a little bit more context: I'm designing an event engine. I > have instances for Applicative, Alternative, Monad, MonadPlus. > It's like that: > > ... snip ... > > The Applicative instance is good if you have two events and you want both of > them to fire ("and"). The Alternative instance is good if you have two > events and you need only one to fire ("or"). > But what if you have several events, but you need only a part of them to > fire in order to construct a final result? Say you have 10 events, but the 5 > first to fire will give you enough data to construct a result. > You cannot do that with Applicative/Alternative because with Applicative, > you need *all* events results, with Alternative you need *only one*. > > That's why I added this primitive "ShortcutEvents" in my DSL, but I'm not > convinced by it. So my questions are: > 1. is ShortcutEvents expressible in term of > Applicative/Alternative/Monad/MonadPlus? > 2. if not is their a well known typeclass that covers this case? > 3. if not is their a better way to write it? I especially don't like the > list of Event, I'd prefer a more generic writing. What if I want a structure > containing the events, instead of a list? What if I want event of various > types (say a pair (Event a, Event b) for example)? > > Note that I'm not working with streams of events (like in traditional FRP > frameworks): just with single events (the "BaseEvents") that I want to > combine with each other. Those "BaseEvents" will fire only once. The final > result of the combination of events will trigger a callback. There's one thing I don't quite understand: why is Event expressed as a free monad/applicative structure? Based on your description alone, it sounds like type Event a = Maybe (BaseEvent a) would suffice. Or am I missing something? Chris From mikolaj at well-typed.com Mon Sep 8 06:20:20 2014 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Mon, 8 Sep 2014 08:20:20 +0200 Subject: [Haskell-cafe] Can't create a static Linux executable when using hmatrix In-Reply-To: References: Message-ID: When I messed around with hmatrix I remember doing sudo apt-get install libblas-dev libatlas-dev liblapack-dev libgsl0-dev though that might have been an overkill. From vigalchin at gmail.com Mon Sep 8 07:11:10 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Mon, 8 Sep 2014 02:11:10 -0500 Subject: [Haskell-cafe] FFI question Message-ID: Hello, I need memory refreshing about FFI because I need to fix a bug (plus I got down a rat hole because of Ukraine war :-(). Following a snippet of something I wrote: -- | lock all of the memory space of a process lockAllMemory :: LockAllFlags -> IO () lockAllMemory flags = do throwErrnoIfMinus1 "lockAllMemory" (c_mlockall cflags) return () where cflags = case flags of CURRENT -> (#const MCL_CURRENT) FUTURE -> (#const MCL_FUTURE) CURRENTandFUTURE -> (#const MCL_CURRENTandFUTURE) it is a file called LockedMem.hsc and the third arm CURRENTandFUTURE I just added to fix the this bug .. MCL_CURRENTandFUTURE ends up in LockedMem_make.c(sp??) but I get a undeclared nasty message when I try to build LockedMem.hsc... my bad... . Please help so I can go back to help Ukraine. Kind regarsd, Vasya From corentin.dupont at gmail.com Mon Sep 8 08:22:00 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 8 Sep 2014 10:22:00 +0200 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: <530F1984-580F-4738-988C-A16FD863431C@gmail.com> References: <530F1984-580F-4738-988C-A16FD863431C@gmail.com> Message-ID: Interresting! Could you make your type "Process" an instance of MonadParallel? https://hackage.haskell.org/package/monad-parallel-0.7.1.2/docs/Control-Monad-Parallel.html This way you could use Control.Monad.Parallel.sequence instead of processParallel. But as you can see, processParallel, albeit making the computations in parallel, as to wait for all processes to finish. In my case, I want to be able to cancel some of the remaining events: so Control.Monad.Parallel doesn't seem to be a good fit. On Mon, Sep 8, 2014 at 3:53 AM, David Sorokin wrote: > Corentin, > > As far as I understand, it is similar in implementation to what I have in > my simulation library Aivika [1]. Please correct me if I am wrong: > > -- | Execute the specified computations in parallel within > -- the current computation and return their results. The cancellation > -- of any of the nested computations affects the current computation. > -- The exception raised in any of the nested computations is propagated > -- to the current computation as well. > processParallel :: [Process a] -> Process [a] > > It looks like that my Process type is an equivalent of your type Event in > some sense. Only here we would have to cancel (or, interrupt in your terms) > all other Process computations right after we receive a final result. > > So, if it is true then it is possible to write a new function based on the > stated above so that it would be similar to the ShortcutEvents function: > > shortcutProcesses: [Process a] -> ([Maybe a] -> Maybe b) -> Process b > > Probably, I should add such a function to my library too. > > Thanks, > David > > [1] http://hackage.haskell.org/package/aivika > > > 08 ????. 2014 ?., ? 0:23, Corentin Dupont > ???????(?): > > Hi guys, > thanks for the nice answers! > I'll give you a little bit more context: I'm designing an event engine. I > have instances for Applicative, Alternative, Monad, MonadPlus. > It's like that: > > > -- | Composable events > data Event a where > SumEvent :: Event a -> Event a -> Event a -- The first > event to fire will be returned. > AppEvent :: Event (a -> b) -> Event a -> Event b -- Both > events should fire, and then the result is returned. > PureEvent :: a -> Event a -- Create a > fake event. The result is useable with no delay. > EmptyEvent :: Event a -- An event > that is never fired. > BindEvent :: Event a -> (a -> Event b) -> Event b -- The first > event should fire, then a second event is created using the result. > BaseEvent :: BaseEvent a -> Event a -- Embed a > base event. > ShortcutEvents :: [Event a] -> ([Maybe a] -> Maybe b) -> Event b -- The > function is called each time an event fires, as soon as the result can be > computed from the available data, it is returned, dismissing the events > that haven't fired yet. > > > instance Functor Event where > fmap f a = pure f <*> a > > instance Applicative Event where > pure = PureEvent > (<*>) = AppEvent > > instance Alternative Event where > (<|>) = SumEvent > empty = EmptyEvent > > instance Monad Event where > (>>=) = BindEvent > return = PureEvent > > instance MonadPlus Event where > mplus = SumEvent > mzero = EmptyEvent > > > The Applicative instance is good if you have two events and you want both > of them to fire ("and"). The Alternative instance is good if you have two > events and you need only one to fire ("or"). > But what if you have several events, but you need only a part of them to > fire in order to construct a final result? Say you have 10 events, but the > 5 first to fire will give you enough data to construct a result. > You cannot do that with Applicative/Alternative because with Applicative, > you need *all* events results, with Alternative you need *only one*. > > That's why I added this primitive "ShortcutEvents" in my DSL, but I'm not > convinced by it. So my questions are: > 1. is ShortcutEvents expressible in term of > Applicative/Alternative/Monad/MonadPlus? > 2. if not is their a well known typeclass that covers this case? > 3. if not is their a better way to write it? I especially don't like the > list of Event, I'd prefer a more generic writing. What if I want a > structure containing the events, instead of a list? What if I want event of > various types (say a pair (Event a, Event b) for example)? > > > Note that I'm not working with streams of events (like in traditional FRP > frameworks): just with single events (the "BaseEvents") that I want to > combine with each other. Those "BaseEvents" will fire only once. The final > result of the combination of events will trigger a callback. > > Cheers, > Corentin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Mon Sep 8 08:44:55 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Mon, 8 Sep 2014 03:44:55 -0500 Subject: [Haskell-cafe] FFI question In-Reply-To: References: Message-ID: Following is a fragment generated by hsc2hs from LockedMem.hsc: #line 93 "LockedMem.hsc" hsc_const (MCL_CURRENTandFUTURE); hsc_fputs (")\n" "", hsc_stdout()); hsc_line (94, "LockedMem.hsc"); hsc_fputs ("\n" "foreign import ccall unsafe \"sys/mman.h mlockall\"\n" " c_mlockall :: CInt -> IO CInt\n" "\n" "\n" "-- | unlock all mapped pages of a process!\n" "unlockAllMemory :: IO () \n" "unlockAllMemory = do\n" " throwErrnoIfMinus1 \"unlockAllMemory\" (c_munlockall)\n" " return ()\n" "\n" "foreign import ccall unsafe \"sys/mman.h munlockall\"\n" " c_munlockall :: IO CInt\n" "", hsc_stdout()); return 0; On Mon, Sep 8, 2014 at 2:11 AM, Vasili I. Galchin wrote: > Hello, > > I need memory refreshing about FFI because I need to fix a bug > (plus I got down a rat hole because of Ukraine war :-(). Following a > snippet of something I wrote: > > -- | lock all of the memory space of a process > lockAllMemory :: LockAllFlags -> IO () > lockAllMemory flags = do > throwErrnoIfMinus1 "lockAllMemory" (c_mlockall cflags) > return () > where > cflags = case flags of > CURRENT -> (#const MCL_CURRENT) > FUTURE -> (#const MCL_FUTURE) > CURRENTandFUTURE -> (#const MCL_CURRENTandFUTURE) > > > it is a file called LockedMem.hsc and the third arm CURRENTandFUTURE I > just added to fix the this bug .. > > MCL_CURRENTandFUTURE ends up in LockedMem_make.c(sp??) but I get a > undeclared nasty message when I try to build LockedMem.hsc... my > bad... . Please help so I can go back to help Ukraine. > > Kind regarsd, > > Vasya From corentin.dupont at gmail.com Mon Sep 8 08:51:06 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 8 Sep 2014 10:51:06 +0200 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: References: Message-ID: On Mon, Sep 8, 2014 at 7:55 AM, Chris Wong wrote: > Hi Corentin > > On Mon, Sep 8, 2014 at 8:23 AM, Corentin Dupont > wrote: > > Hi guys, > > thanks for the nice answers! > > I'll give you a little bit more context: I'm designing an event engine. I > > have instances for Applicative, Alternative, Monad, MonadPlus. > > It's like that: > > > > ... snip ... > > > > The Applicative instance is good if you have two events and you want > both of > > them to fire ("and"). The Alternative instance is good if you have two > > events and you need only one to fire ("or"). > > But what if you have several events, but you need only a part of them to > > fire in order to construct a final result? Say you have 10 events, but > the 5 > > first to fire will give you enough data to construct a result. > > You cannot do that with Applicative/Alternative because with Applicative, > > you need *all* events results, with Alternative you need *only one*. > > > > That's why I added this primitive "ShortcutEvents" in my DSL, but I'm not > > convinced by it. So my questions are: > > 1. is ShortcutEvents expressible in term of > > Applicative/Alternative/Monad/MonadPlus? > > 2. if not is their a well known typeclass that covers this case? > > 3. if not is their a better way to write it? I especially don't like the > > list of Event, I'd prefer a more generic writing. What if I want a > structure > > containing the events, instead of a list? What if I want event of various > > types (say a pair (Event a, Event b) for example)? > > > > Note that I'm not working with streams of events (like in traditional FRP > > frameworks): just with single events (the "BaseEvents") that I want to > > combine with each other. Those "BaseEvents" will fire only once. The > final > > result of the combination of events will trigger a callback. > > There's one thing I don't quite understand: why is Event expressed as > a free monad/applicative structure? Based on your description alone, > it sounds like > > type Event a = Maybe (BaseEvent a) > > would suffice. Or am I missing something? > > Hi Chris! "Event" is a small DSL that I interpret in the back end. It allows me to write nice expressions about events. Say you have functions to create text fields and buttons on the GUI: -- Create an event binded to a text field, with the first argument as a title. -- Once validated, the event returns the content of the text field. inputText :: String -> Event String -- Create an event binded to a button, with the first argument as a title. inputButton :: String -> Event () You could then express nice combinations: -- using Applicative: create a form with two fields data NameSurname = NameSurname String String form1 :: Event NameSurname form1 = NameSurname <$> onInputText "Name:" <*> onInputText "Surname:" -- using Alternative: create two buttons, first button clicked returns False, the second True form2 :: Event Boolean form2 = True <$ inputButton "click here for True" <|> False <$ inputButton "click here for False" -- using Monad: create the two buttons of form2, if "True" button is clicked, then a text field appears asking for a name. form3 :: Event String form3 = do myBool <- form2 if myBool then onInputText "Name:" else return "No name" But I am lacking a way to express the situation where I have a bunch of events, which can be cancelled as soon as a result can be calculated: ShortcutEvents :: [Event a] -> ([Maybe a] -> Maybe b) -> Event b You can think of it as a generalization of the "or" shortcut, where the evaluation is cut short if the first argument evaluates to True. With your type: type Event a = Maybe (BaseEvent a) Could you express the combinations above?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Mon Sep 8 10:36:36 2014 From: lambda.fairy at gmail.com (Chris Wong) Date: Mon, 8 Sep 2014 22:36:36 +1200 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: References: Message-ID: > "Event" is a small DSL that I interpret in the back end. > It allows me to write nice expressions about events. Say you have functions > to create text fields and buttons on the GUI: > > -- Create an event binded to a text field, with the first argument as a > title. > -- Once validated, the event returns the content of the text field. > inputText :: String -> Event String > > -- Create an event binded to a button, with the first argument as a title. > inputButton :: String -> Event () > > > You could then express nice combinations: > > -- using Applicative: create a form with two fields > data NameSurname = NameSurname String String > form1 :: Event NameSurname > form1 = NameSurname <$> onInputText "Name:" <*> onInputText "Surname:" > > -- using Alternative: create two buttons, first button clicked returns > False, the second True > form2 :: Event Boolean > form2 = True <$ inputButton "click here for True" <|> False <$ inputButton > "click here for False" > > -- using Monad: create the two buttons of form2, if "True" button is > clicked, then a text field appears asking for a name. > form3 :: Event String > form3 = do > myBool <- form2 > if myBool then onInputText "Name:" > else return "No name" Oh, I see now. So we need to reflect on the structure of the computation, to figure out what widgets to show. That makes sense. Chris > But I am lacking a way to express the situation where I have a bunch of > events, which can be cancelled as soon as a result can be calculated: > ShortcutEvents :: [Event a] -> ([Maybe a] -> Maybe b) -> Event b > > You can think of it as a generalization of the "or" shortcut, where the > evaluation is cut short if the first argument evaluates to True. > > > With your type: > type Event a = Maybe (BaseEvent a) > Could you express the combinations above?? > > From jkarni at gmail.com Mon Sep 8 11:01:36 2014 From: jkarni at gmail.com (Julian K. Arni) Date: Mon, 8 Sep 2014 13:01:36 +0200 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: References: Message-ID: <20140908110136.GB14028@jkarni.celeraone.com> Are you looking for something like amb/unamb? [0] In particular, if you look at the comments in the source for 'race', it should be pretty intuitive how to go from there to "run x computations, kill the remaining ones after y return". You just need to fiddle with the MVar, possibly adding another thread and MVar that represents whether the calculation can already be completed. [0] https://hackage.haskell.org/package/unamb-0.2.5/docs/src/Data-Unamb.html#amb From ivan.miljenovic at gmail.com Mon Sep 8 13:32:52 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 8 Sep 2014 23:32:52 +1000 Subject: [Haskell-cafe] ANNOUNCE: buildable-0.1.0.0 Message-ID: Have you ever wanted to deal with the builders for various data types in a polymorphic/overloaded fashion? I'm needing to do so and couldn't find any existing code that did so, so I decided to rectify this: http://hackage.haskell.org/package/buildable As a (very contrived) example: ?> build ((365 :: Dec Int) <| fromValue (Char7 ' ') |> (365 :: BigEndian Int16) |> (" omega=? " :: Utf8 String) |> Utf16 (LE ("hello" :: LT.Text))) :: SB.ByteString "365 \SOHm omega=\240\157\159\130 h\NULe\NULl\NULl\NULo\NUL" -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From mail at tobias-neumann.eu Mon Sep 8 14:05:20 2014 From: mail at tobias-neumann.eu (Tobias Neumann) Date: Mon, 8 Sep 2014 14:05:20 +0000 (UTC) Subject: [Haskell-cafe] Use Haskell shared library with foreign exports with dlopen/dlsym Message-ID: Hello Cafe, I am trying to use a Haskell shared library with foreign exports from Haskell again via dlopen/dlsym. Sadly it segfaults, and the segfaults happen on dlclose during garbage collection points (as figured out by monochrom in #haskell). So right now I can only open a library once and may not dlclose it. Can someone point me to a mistake I made, or is this rather a ghc (7.8.3) bug? Please see attached minimal example. Regards, Tobias test.hs: module Main where import qualified System.Posix.DynamicLinker as DL import Foreign foreign import ccall "dynamic" mkTest :: FunPtr Int -> Int main = do DL.withDL ("./libtest.so") [DL.RTLD_NOW] $ \dl -> do dimPtr <- DL.dlsym dl "test" let test = mkTest dimPtr print test libtest.hs: module Test() where import Foreign foreign export ccall test :: Int test :: Int test = 124 build with: ghc --make -shared -dynamic -fPIC libtest.hs -o libtest.so ghc --make -dynamic test.hs From kai at kzhang.org Mon Sep 8 16:06:42 2014 From: kai at kzhang.org (Kai Zhang) Date: Mon, 8 Sep 2014 09:06:42 -0700 Subject: [Haskell-cafe] Can't create a static Linux executable when using hmatrix In-Reply-To: References: Message-ID: I have all these libraries installed, and I have no problem install hmatrix and use it in regular haskell programs. But I would like to run my executable on another computer which do not have lapack and some other libraries. Currently I have to resort to setting up a virtual machine matching the target system where I compile my program, and then move it and shared libraries to the system. On Sun, Sep 7, 2014 at 11:20 PM, Mikolaj Konarski wrote: > When I messed around with hmatrix I remember doing > > sudo apt-get install libblas-dev libatlas-dev liblapack-dev libgsl0-dev > > though that might have been an overkill. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Sep 8 16:22:43 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 8 Sep 2014 12:22:43 -0400 Subject: [Haskell-cafe] Can't create a static Linux executable when using hmatrix In-Reply-To: References: Message-ID: On Mon, Sep 8, 2014 at 12:06 PM, Kai Zhang wrote: > I have all these libraries installed, and I have no problem install > hmatrix and use it in regular haskell programs. But I would like to run my > executable on another computer which do not have lapack and some other > libraries. Currently I have to resort to setting up a virtual machine > matching the target system where I compile my program, and then move it and > shared libraries to the system. > Then you need to find out why either BLAS is not being linked or its static library is missing those functions. "cabal install -v3" might help, as might inspecting config.log if it is using configure. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Sep 8 16:47:33 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 8 Sep 2014 12:47:33 -0400 Subject: [Haskell-cafe] Use Haskell shared library with foreign exports with dlopen/dlsym In-Reply-To: References: Message-ID: what OS and other things? what does ghc --info say? Also, when calling haskell code as if it were C code, you need to init the RTS its using, its not going to magically know you're linking to it from haskell.(though maybe you can arrange things to use the pre inited hs runtime, but i'm not familiar with how to do so) http://www.haskell.org/haskellwiki/Calling_Haskell_from_C On Mon, Sep 8, 2014 at 10:05 AM, Tobias Neumann wrote: > Hello Cafe, > > I am trying to use a Haskell shared library with foreign exports from > Haskell again via dlopen/dlsym. Sadly it segfaults, and the segfaults > happen on dlclose during garbage collection points (as figured out by > monochrom in #haskell). So right now I can only open a library once and > may not dlclose it. Can someone point me to a mistake I made, or is this > rather a ghc (7.8.3) bug? Please see attached minimal example. > > Regards, Tobias > > > test.hs: > module Main where > > import qualified System.Posix.DynamicLinker as DL > import Foreign > > foreign import ccall "dynamic" > mkTest :: FunPtr Int -> Int > > main = do > DL.withDL ("./libtest.so") [DL.RTLD_NOW] $ \dl -> do > dimPtr <- DL.dlsym dl "test" > let test = mkTest dimPtr > print test > > libtest.hs: > module Test() where > > import Foreign > > foreign export ccall test :: Int > > test :: Int > test = 124 > > build with: > ghc --make -shared -dynamic -fPIC libtest.hs -o libtest.so > ghc --make -dynamic test.hs > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at tobias-neumann.eu Mon Sep 8 17:31:02 2014 From: mail at tobias-neumann.eu (Tobias Neumann) Date: Mon, 8 Sep 2014 17:31:02 +0000 (UTC) Subject: [Haskell-cafe] Use Haskell shared library with foreign exports with dlopen/dlsym References: Message-ID: > what OS and other things? I'm on GNU/Linux. > Also, when calling haskell code as if it were C code, you need to init > the RTS its using, its not going to magically know you're linking to it > from haskell.(though maybe you can arrange things to use the pre inited > hs runtime, but i'm not familiar with how to do so) > http://www.haskell.org/haskellwiki/Calling_Haskell_from_C You mean I should foreign import hs_init and call it from within my haskell code, then dlopen the library and use dlsym "__stginit_Test" to call the foreign imported hs_add_root with it before calling test? (I tested that this doesn't fix it) I'm already calling test from within an initialized runtime system (since I call it from haskell code), otherwise I'd probably get no result at all and not just an error when dlclose is called and a garbage collection occurs. From roma at ro-che.info Mon Sep 8 21:59:57 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 9 Sep 2014 00:59:57 +0300 Subject: [Haskell-cafe] End of support for test-framework-smallcheck and test-framework-golden Message-ID: <20140908215957.GA32279@sniper> I'm going to stop maintaining the test-framework-smallcheck and test-framework-golden packages. I recommend switching to tasty's tasty-smallcheck and tasty-golden, respectively. If you are interested in taking over these test-framework packages, let me know. Otherwise, I will continue supporting them for the next 3 months and abandon/deprecate them afterwards. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From corentin.dupont at gmail.com Tue Sep 9 08:07:18 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 9 Sep 2014 10:07:18 +0200 Subject: [Haskell-cafe] Parallel interruptible computations In-Reply-To: <20140908110136.GB14028@jkarni.celeraone.com> References: <20140908110136.GB14028@jkarni.celeraone.com> Message-ID: Hi Julian, how are you?? Yes I've looked into amb. In practice I have no problem with the back-end implementation, I just wanted to provide a nice front-end for my DSL. I wonder if there is a way to generalize the concept, especially in the case with events of different types running in parallel: ShortcutEvents :: [Event a] -> ([Maybe a] -> Maybe b) -> Event b ShortcutEvents2 :: [Event a] -> [Event b] -> ([Maybe a] -> [Maybe b] -> Maybe c) -> Event c ShortcutEventsX ... My use case is the voting system of Nomyx, for which I need to run in parallel all the players votes plus a timer. Cheers Corentin On Mon, Sep 8, 2014 at 1:01 PM, Julian K. Arni wrote: > Are you looking for something like amb/unamb? [0] In particular, if you > look at > the comments in the source for 'race', it should be pretty intuitive how > to go > from there to "run x computations, kill the remaining ones after y > return". You > just need to fiddle with the MVar, possibly adding another thread and MVar > that > represents whether the calculation can already be completed. > > [0] > https://hackage.haskell.org/package/unamb-0.2.5/docs/src/Data-Unamb.html#amb > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbv at dcc.fc.up.pt Tue Sep 9 09:09:05 2014 From: pbv at dcc.fc.up.pt (Pedro Vasconcelos) Date: Tue, 9 Sep 2014 10:09:05 +0100 Subject: [Haskell-cafe] Specifying build flags in cabal depencies Message-ID: <20140909100905.17b599d1@khaki> Hello, I've run across an annoyance with a Haskell project of mine that requires Snap built with SSL: I couldn't find a way to specify the flag "-fopensll" to pass when building the snap-server package. This means that building on a new machine requires either manually installing the right version of snap-server with -fopenssl or re-installing with after the Cabal build. Is there a better way to do this? Thanks, Pedro From iricanaycan at gmail.com Tue Sep 9 09:32:31 2014 From: iricanaycan at gmail.com (Aycan iRiCAN) Date: Tue, 9 Sep 2014 12:32:31 +0300 Subject: [Haskell-cafe] Specifying build flags in cabal depencies In-Reply-To: <20140909100905.17b599d1@khaki> References: <20140909100905.17b599d1@khaki> Message-ID: Hi Pedro, You may want to add a cabal.config file to your project which includes constraints like: "constraints: snap-server == 0.9.4.5, snap-server +fopenssl" On Tue, Sep 9, 2014 at 12:09 PM, Pedro Vasconcelos wrote: > > Hello, > > I've run across an annoyance with a Haskell project of mine that > requires Snap built with SSL: I couldn't find a way to specify the flag > "-fopensll" to pass when building the snap-server package. This means > that building on a new machine requires either manually installing > the right version of snap-server with -fopenssl or re-installing with > after the Cabal build. > > Is there a better way to do this? > > Thanks, > > Pedro > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- http://www.google.com/profiles/iricanaycan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Tue Sep 9 12:38:34 2014 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Tue, 09 Sep 2014 14:38:34 +0200 Subject: [Haskell-cafe] Warnings for unhandled exceptions Message-ID: L.S., I was reading about the Aardvark language [0] and the robustness they intend to implement in it by, amongst others, catching each possible exception. I wonder, is it possible to implement compiler warnings for unhandled exceptions in Haskell? One of the strong points of Haskell is the type checking and clearly identifying functions with side effects, but exceptions are not reflected by the type of a function. It would be useful if the compiler gave a warning for each type of exception, for each expression, that is not handled by the program. Regards, Henk-Jan van Tuyl [0] http://aardvarklanguage.sourceforge.net/ -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From kyle.marek.spartz at gmail.com Tue Sep 9 12:44:28 2014 From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz) Date: Tue, 9 Sep 2014 07:44:28 -0500 Subject: [Haskell-cafe] Warnings for unhandled exceptions In-Reply-To: References: Message-ID: An alternative to exceptions would be to use ADTs to wrap return values, e.g. Maybe, Either. Static analysis is much easier with these. ? Kyle Marek-Spartz On Sep 9, 2014, 7:38:34 AM, Henk-Jan van Tuyl wrote: L.S., I was reading about the Aardvark language [0] and the robustness they intend to implement in it by, amongst others, catching each possible exception. I wonder, is it possible to implement compiler warnings for unhandled exceptions in Haskell? One of the strong points of Haskell is the type checking and clearly identifying functions with side effects, but exceptions are not reflected by the type of a function. It would be useful if the compiler gave a warning for each type of exception, for each expression, that is not handled by the program. Regards, Henk-Jan van Tuyl [0] http://aardvarklanguage.sourceforge.net/ -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- _______________________________________________ Haskell-Cafe mailing list mailto:Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodo at theshire.org Tue Sep 9 12:55:31 2014 From: frodo at theshire.org (Cristiano Paris) Date: Tue, 9 Sep 2014 14:55:31 +0200 Subject: [Haskell-cafe] Reversing a fixed-length vector Message-ID: Hi, I'm playing around with Type Families so I decided to implement a simple fixed-length Vect of Integers. Here is my straightforward implementation (ghc 7.8.3): https://gist.github.com/anonymous/d838e68ce6a02412859f As you can see, I'm trying to implement a reverse function for my vectors which guarantees that the output vector is the same size as the input one. I tried to express this constraint at the type level. The problem is that I can't have ghc to type check the reverse function in the non-trivial case: _________________ Could not deduce (Plus n1 (S m) ~ S (Plus n1 m)) from the context (n ~ S n1) bound by a pattern with constructor CV :: forall n. Int -> Vect n -> Vect (S n), in an equation for ?vecReverse? at vect3.hs:30:13-18 Expected type: Vect (Plus n m) Actual type: Vect (Plus n1 (S m)) _________________ Iit has to do with the fact that the type checker can't deduce that: Plus n1 (S m) ~ S (Plus n1 m) ~ Plus (S n1) m ~Plus n m I tried to insert the following instance to the family: Plus n (S m) = S (Plus n m) but to no avail. Any clue? Thanks. C. -- GPG Key: 4096R/C17E53C6 2010-02-22 Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k at ioctl.it Tue Sep 9 13:02:09 2014 From: k at ioctl.it (Karsten Gebbert) Date: Tue, 09 Sep 2014 15:02:09 +0200 Subject: [Haskell-cafe] api-tools questions Message-ID: <86ppf5gd66.fsf@fook.fritz.box> Hi All, I have a question concerning the api-tools package. Its not clear from the tests, sources or the tutorial how I can use other date/time formats that the default `utc` type can handle. I'm trying to wrap a JSON API that is not under my control, so I have to adhere to whatever I get back from it. Could anybody with experience with the package point me to some example, relevant bits in the sources or a tip how to do it? I'm planning to create some more documentation around the package to contribute back once I figured out a few more details, because I think its quite a useful abstraction when dealing with (foreign) APIs IMO. Thanks already for any hints, karsten From allbery.b at gmail.com Tue Sep 9 13:55:45 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 9 Sep 2014 09:55:45 -0400 Subject: [Haskell-cafe] Warnings for unhandled exceptions In-Reply-To: References: Message-ID: On Tue, Sep 9, 2014 at 8:38 AM, Henk-Jan van Tuyl wrote: > It would be useful if the compiler gave a warning for each type of > exception, for each expression, that is not handled by the program. A problem with this idea is that some exceptions can be potentially thrown by any expression at any time, based solely on things external to the program, compiler or runtime. Only software exceptions can reliably be handled this way --- and those arguably should not be implemented as exceptions, but as e.g. Maybe/Either/etc. (Floating point exceptions are, as usual for IEEE floating point, a weird corner case.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Sep 9 13:56:11 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 9 Sep 2014 09:56:11 -0400 Subject: [Haskell-cafe] Reversing a fixed-length vector In-Reply-To: References: Message-ID: heres a version richard eisenburg helped me write https://gist.github.com/cartazio/9340008 see the linked gist for the full code but heres the meat of it data Shape (rank :: Nat) a where Nil :: Shape Z a (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a {-# INLINE reverseShape #-} reverseShape :: Shape n a -> Shape n a reverseShape Nil = Nil reverseShape list = go SZero Nil list where go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a go snat acc Nil = gcastWith (plus_id_r snat) acc go snat acc (h :* (t :: Shape n3 a)) = gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) (go (SSucc snat) (h :* acc) t) On Tue, Sep 9, 2014 at 8:55 AM, Cristiano Paris wrote: > Hi, > > I'm playing around with Type Families so I decided to implement a simple > fixed-length Vect of Integers. > > Here is my straightforward implementation (ghc 7.8.3): > > https://gist.github.com/anonymous/d838e68ce6a02412859f > > As you can see, I'm trying to implement a reverse function for my vectors > which guarantees that the output vector is the same size as the input one. > I tried to express this constraint at the type level. > > The problem is that I can't have ghc to type check the reverse function in > the non-trivial case: > > _________________ > Could not deduce (Plus n1 (S m) ~ S (Plus n1 m)) > from the context (n ~ S n1) > bound by a pattern with constructor > CV :: forall n. Int -> Vect n -> Vect (S n), > in an equation for ?vecReverse? > at vect3.hs:30:13-18 > Expected type: Vect (Plus n m) > Actual type: Vect (Plus n1 (S m)) > _________________ > > Iit has to do with the fact that the type checker can't deduce that: > > Plus n1 (S m) ~ S (Plus n1 m) ~ Plus (S n1) m ~Plus n m > > I tried to insert the following instance to the family: > > Plus n (S m) = S (Plus n m) > > but to no avail. > > Any clue? > > Thanks. > > C. > > -- > GPG Key: 4096R/C17E53C6 2010-02-22 > Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodo at theshire.org Tue Sep 9 14:07:43 2014 From: frodo at theshire.org (Cristiano Paris) Date: Tue, 9 Sep 2014 16:07:43 +0200 Subject: [Haskell-cafe] Reversing a fixed-length vector In-Reply-To: References: Message-ID: Gosh! I suspected I hit a non-trivial problem... cool! C. On Tue, Sep 9, 2014 at 3:56 PM, Carter Schonwald wrote: > heres a version richard eisenburg helped me write > https://gist.github.com/cartazio/9340008 > see the linked gist for the full code but heres the meat of it > > > data Shape (rank :: Nat) a where > Nil :: Shape Z a > (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a > {-# INLINE reverseShape #-} > reverseShape :: Shape n a -> Shape n a > reverseShape Nil = Nil > reverseShape list = go SZero Nil list > where > go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a > go snat acc Nil = gcastWith (plus_id_r snat) acc > go snat acc (h :* (t :: Shape n3 a)) = > gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) > (go (SSucc snat) (h :* acc) t) > > > On Tue, Sep 9, 2014 at 8:55 AM, Cristiano Paris > wrote: > >> Hi, >> >> I'm playing around with Type Families so I decided to implement a simple >> fixed-length Vect of Integers. >> >> Here is my straightforward implementation (ghc 7.8.3): >> >> https://gist.github.com/anonymous/d838e68ce6a02412859f >> >> As you can see, I'm trying to implement a reverse function for my vectors >> which guarantees that the output vector is the same size as the input one. >> I tried to express this constraint at the type level. >> >> The problem is that I can't have ghc to type check the reverse function >> in the non-trivial case: >> >> _________________ >> Could not deduce (Plus n1 (S m) ~ S (Plus n1 m)) >> from the context (n ~ S n1) >> bound by a pattern with constructor >> CV :: forall n. Int -> Vect n -> Vect (S n), >> in an equation for ?vecReverse? >> at vect3.hs:30:13-18 >> Expected type: Vect (Plus n m) >> Actual type: Vect (Plus n1 (S m)) >> _________________ >> >> Iit has to do with the fact that the type checker can't deduce that: >> >> Plus n1 (S m) ~ S (Plus n1 m) ~ Plus (S n1) m ~Plus n m >> >> I tried to insert the following instance to the family: >> >> Plus n (S m) = S (Plus n m) >> >> but to no avail. >> >> Any clue? >> >> Thanks. >> >> C. >> >> -- >> GPG Key: 4096R/C17E53C6 2010-02-22 >> Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -- GPG Key: 4096R/C17E53C6 2010-02-22 Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From portnov at iportnov.ru Tue Sep 9 14:09:23 2014 From: portnov at iportnov.ru (Ilya Portnov) Date: Tue, 09 Sep 2014 20:09:23 +0600 Subject: [Haskell-cafe] Warnings for unhandled exceptions In-Reply-To: References: Message-ID: <540F0A13.6010500@iportnov.ru> Hello. There is an implementation of Java-like "checked exceptions" for Haskell: http://hackage.haskell.org/package/control-monad-exception :) On 09.09.2014 18:38, Henk-Jan van Tuyl wrote: > > L.S., > > I was reading about the Aardvark language [0] and the robustness they > intend to implement in it by, amongst others, catching each possible > exception. I wonder, is it possible to implement compiler warnings for > unhandled exceptions in Haskell? One of the strong points of Haskell is > the type checking and clearly identifying functions with side effects, > but exceptions are not reflected by the type of a function. It would be > useful if the compiler gave a warning for each type of exception, for > each expression, that is not handled by the program. > > Regards, > Henk-Jan van Tuyl > > > [0] http://aardvarklanguage.sourceforge.net/ > > From vogt.adam at gmail.com Tue Sep 9 14:12:19 2014 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 9 Sep 2014 10:12:19 -0400 Subject: [Haskell-cafe] Reversing a fixed-length vector In-Reply-To: References: Message-ID: Hi Cristiano, You can also convince ghc about (Plus n1 (S m) ~ S (Plus n1 m)) by writing VecReverse as a class: https://gist.github.com/aavogt/15399cbdd5e74d0e9cd8 Regards, Adam On Tue, Sep 9, 2014 at 10:07 AM, Cristiano Paris wrote: > Gosh! I suspected I hit a non-trivial problem... cool! > > C. > > On Tue, Sep 9, 2014 at 3:56 PM, Carter Schonwald > wrote: >> >> heres a version richard eisenburg helped me write >> https://gist.github.com/cartazio/9340008 >> see the linked gist for the full code but heres the meat of it >> >> >> data Shape (rank :: Nat) a where >> Nil :: Shape Z a >> (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a >> >> {-# INLINE reverseShape #-} >> reverseShape :: Shape n a -> Shape n a >> reverseShape Nil = Nil >> reverseShape list = go SZero Nil list >> where >> go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a >> go snat acc Nil = gcastWith (plus_id_r snat) acc >> go snat acc (h :* (t :: Shape n3 a)) = >> gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) >> (go (SSucc snat) (h :* acc) t) >> >> >> On Tue, Sep 9, 2014 at 8:55 AM, Cristiano Paris >> wrote: >>> >>> Hi, >>> >>> I'm playing around with Type Families so I decided to implement a simple >>> fixed-length Vect of Integers. >>> >>> Here is my straightforward implementation (ghc 7.8.3): >>> >>> https://gist.github.com/anonymous/d838e68ce6a02412859f >>> >>> As you can see, I'm trying to implement a reverse function for my vectors >>> which guarantees that the output vector is the same size as the input one. I >>> tried to express this constraint at the type level. >>> >>> The problem is that I can't have ghc to type check the reverse function >>> in the non-trivial case: >>> >>> _________________ >>> Could not deduce (Plus n1 (S m) ~ S (Plus n1 m)) >>> from the context (n ~ S n1) >>> bound by a pattern with constructor >>> CV :: forall n. Int -> Vect n -> Vect (S n), >>> in an equation for ?vecReverse? >>> at vect3.hs:30:13-18 >>> Expected type: Vect (Plus n m) >>> Actual type: Vect (Plus n1 (S m)) >>> _________________ >>> >>> Iit has to do with the fact that the type checker can't deduce that: >>> >>> Plus n1 (S m) ~ S (Plus n1 m) ~ Plus (S n1) m ~Plus n m >>> >>> I tried to insert the following instance to the family: >>> >>> Plus n (S m) = S (Plus n m) >>> >>> but to no avail. >>> >>> Any clue? >>> >>> Thanks. >>> >>> C. >>> >>> -- >>> GPG Key: 4096R/C17E53C6 2010-02-22 >>> Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > > > -- > GPG Key: 4096R/C17E53C6 2010-02-22 > Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From adam at well-typed.com Tue Sep 9 14:16:47 2014 From: adam at well-typed.com (Adam Gundry) Date: Tue, 09 Sep 2014 15:16:47 +0100 Subject: [Haskell-cafe] api-tools questions In-Reply-To: <86ppf5gd66.fsf@fook.fritz.box> References: <86ppf5gd66.fsf@fook.fritz.box> Message-ID: <540F0BCF.8040004@well-typed.com> Hi Karsten, This isn't very well documented, but there is a (hidden) feature of api-tools that should do what you want. If you say something like mt :: MyTime = basic string with inj_MyTime, prj_MyTime then you can define your own type MyTime and give conversion functions inj_MyTime and prj_MyTime to convert back and forth from a newtype-wrapped Text. (In fact, you could probably use UTCTime as MyTime...). More precisely, api-tools will generate something like newtype REP__MyTime = REP__MyTime Text and you will need to implement inj_MyTime :: REP__MyTime -> ParserWithErrs MyTime prj_MyTime :: MyTime -> REP__MyTime I hope this helps, and further questions or documentation contributions are very welcome! Cheers, Adam On 09/09/14 14:02, Karsten Gebbert wrote: > Hi All, > > I have a question concerning the api-tools package. > > Its not clear from the tests, sources or the tutorial how I can use > other date/time formats that the default `utc` type can handle. I'm > trying to wrap a JSON API that is not under my control, so I have to > adhere to whatever I get back from it. Could anybody with experience > with the package point me to some example, relevant bits in the sources > or a tip how to do it? > > I'm planning to create some more documentation around the package to > contribute back once I figured out a few more details, because I think > its quite a useful abstraction when dealing with (foreign) APIs IMO. > > Thanks already for any hints, > > karsten -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From hesselink at gmail.com Tue Sep 9 14:21:58 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 9 Sep 2014 16:21:58 +0200 Subject: [Haskell-cafe] Reversing a fixed-length vector In-Reply-To: References: Message-ID: The problem with a class based approach is that the class context will show up everywhere, even though all instances have already been defined. Erik On Tue, Sep 9, 2014 at 4:12 PM, adam vogt wrote: > Hi Cristiano, > > You can also convince ghc about (Plus n1 (S m) ~ S (Plus n1 m)) by > writing VecReverse as a class: > https://gist.github.com/aavogt/15399cbdd5e74d0e9cd8 > > Regards, > Adam > > On Tue, Sep 9, 2014 at 10:07 AM, Cristiano Paris wrote: >> Gosh! I suspected I hit a non-trivial problem... cool! >> >> C. >> >> On Tue, Sep 9, 2014 at 3:56 PM, Carter Schonwald >> wrote: >>> >>> heres a version richard eisenburg helped me write >>> https://gist.github.com/cartazio/9340008 >>> see the linked gist for the full code but heres the meat of it >>> >>> >>> data Shape (rank :: Nat) a where >>> Nil :: Shape Z a >>> (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a >>> >>> {-# INLINE reverseShape #-} >>> reverseShape :: Shape n a -> Shape n a >>> reverseShape Nil = Nil >>> reverseShape list = go SZero Nil list >>> where >>> go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a >>> go snat acc Nil = gcastWith (plus_id_r snat) acc >>> go snat acc (h :* (t :: Shape n3 a)) = >>> gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) >>> (go (SSucc snat) (h :* acc) t) >>> >>> >>> On Tue, Sep 9, 2014 at 8:55 AM, Cristiano Paris >>> wrote: >>>> >>>> Hi, >>>> >>>> I'm playing around with Type Families so I decided to implement a simple >>>> fixed-length Vect of Integers. >>>> >>>> Here is my straightforward implementation (ghc 7.8.3): >>>> >>>> https://gist.github.com/anonymous/d838e68ce6a02412859f >>>> >>>> As you can see, I'm trying to implement a reverse function for my vectors >>>> which guarantees that the output vector is the same size as the input one. I >>>> tried to express this constraint at the type level. >>>> >>>> The problem is that I can't have ghc to type check the reverse function >>>> in the non-trivial case: >>>> >>>> _________________ >>>> Could not deduce (Plus n1 (S m) ~ S (Plus n1 m)) >>>> from the context (n ~ S n1) >>>> bound by a pattern with constructor >>>> CV :: forall n. Int -> Vect n -> Vect (S n), >>>> in an equation for ?vecReverse? >>>> at vect3.hs:30:13-18 >>>> Expected type: Vect (Plus n m) >>>> Actual type: Vect (Plus n1 (S m)) >>>> _________________ >>>> >>>> Iit has to do with the fact that the type checker can't deduce that: >>>> >>>> Plus n1 (S m) ~ S (Plus n1 m) ~ Plus (S n1) m ~Plus n m >>>> >>>> I tried to insert the following instance to the family: >>>> >>>> Plus n (S m) = S (Plus n m) >>>> >>>> but to no avail. >>>> >>>> Any clue? >>>> >>>> Thanks. >>>> >>>> C. >>>> >>>> -- >>>> GPG Key: 4096R/C17E53C6 2010-02-22 >>>> Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >> >> >> >> -- >> GPG Key: 4096R/C17E53C6 2010-02-22 >> Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From frodo at theshire.org Tue Sep 9 14:45:40 2014 From: frodo at theshire.org (Cristiano Paris) Date: Tue, 9 Sep 2014 16:45:40 +0200 Subject: [Haskell-cafe] Reversing a fixed-length vector In-Reply-To: References: Message-ID: I almost got there with Type Equalities, but I can't really understand the "VecReverse n (S m)" constraint in the instance bit of "VecReverse (S n) m". C. On Tue, Sep 9, 2014 at 4:12 PM, adam vogt wrote: > Hi Cristiano, > > You can also convince ghc about (Plus n1 (S m) ~ S (Plus n1 m)) by > writing VecReverse as a class: > https://gist.github.com/aavogt/15399cbdd5e74d0e9cd8 > > Regards, > Adam > > On Tue, Sep 9, 2014 at 10:07 AM, Cristiano Paris > wrote: > > Gosh! I suspected I hit a non-trivial problem... cool! > > > > C. > > > > On Tue, Sep 9, 2014 at 3:56 PM, Carter Schonwald > > wrote: > >> > >> heres a version richard eisenburg helped me write > >> https://gist.github.com/cartazio/9340008 > >> see the linked gist for the full code but heres the meat of it > >> > >> > >> data Shape (rank :: Nat) a where > >> Nil :: Shape Z a > >> (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a > >> > >> {-# INLINE reverseShape #-} > >> reverseShape :: Shape n a -> Shape n a > >> reverseShape Nil = Nil > >> reverseShape list = go SZero Nil list > >> where > >> go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a > >> go snat acc Nil = gcastWith (plus_id_r snat) acc > >> go snat acc (h :* (t :: Shape n3 a)) = > >> gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) > >> (go (SSucc snat) (h :* acc) t) > >> > >> > >> On Tue, Sep 9, 2014 at 8:55 AM, Cristiano Paris > >> wrote: > >>> > >>> Hi, > >>> > >>> I'm playing around with Type Families so I decided to implement a > simple > >>> fixed-length Vect of Integers. > >>> > >>> Here is my straightforward implementation (ghc 7.8.3): > >>> > >>> https://gist.github.com/anonymous/d838e68ce6a02412859f > >>> > >>> As you can see, I'm trying to implement a reverse function for my > vectors > >>> which guarantees that the output vector is the same size as the input > one. I > >>> tried to express this constraint at the type level. > >>> > >>> The problem is that I can't have ghc to type check the reverse function > >>> in the non-trivial case: > >>> > >>> _________________ > >>> Could not deduce (Plus n1 (S m) ~ S (Plus n1 m)) > >>> from the context (n ~ S n1) > >>> bound by a pattern with constructor > >>> CV :: forall n. Int -> Vect n -> Vect (S n), > >>> in an equation for ?vecReverse? > >>> at vect3.hs:30:13-18 > >>> Expected type: Vect (Plus n m) > >>> Actual type: Vect (Plus n1 (S m)) > >>> _________________ > >>> > >>> Iit has to do with the fact that the type checker can't deduce that: > >>> > >>> Plus n1 (S m) ~ S (Plus n1 m) ~ Plus (S n1) m ~Plus n m > >>> > >>> I tried to insert the following instance to the family: > >>> > >>> Plus n (S m) = S (Plus n m) > >>> > >>> but to no avail. > >>> > >>> Any clue? > >>> > >>> Thanks. > >>> > >>> C. > >>> > >>> -- > >>> GPG Key: 4096R/C17E53C6 2010-02-22 > >>> Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 > >>> > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>> > >> > > > > > > > > -- > > GPG Key: 4096R/C17E53C6 2010-02-22 > > Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- GPG Key: 4096R/C17E53C6 2010-02-22 Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From k at ioctl.it Tue Sep 9 15:20:22 2014 From: k at ioctl.it (Karsten Gebbert) Date: Tue, 09 Sep 2014 17:20:22 +0200 Subject: [Haskell-cafe] api-tools questions In-Reply-To: <540F0BCF.8040004@well-typed.com> References: <86ppf5gd66.fsf@fook.fritz.box> <540F0BCF.8040004@well-typed.com> Message-ID: <86iokwhlc9.fsf@fook.fritz.box> Excellent, thanks a lot Adam. I'll open a PR when I'm through with this project :) Adam Gundry writes: > Hi Karsten, > > This isn't very well documented, but there is a (hidden) feature of > api-tools that should do what you want. If you say something like > > mt :: MyTime = basic string with inj_MyTime, prj_MyTime > > then you can define your own type MyTime and give conversion functions > inj_MyTime and prj_MyTime to convert back and forth from a > newtype-wrapped Text. (In fact, you could probably use UTCTime as > MyTime...). More precisely, api-tools will generate something like > > newtype REP__MyTime = REP__MyTime Text > > and you will need to implement > > inj_MyTime :: REP__MyTime -> ParserWithErrs MyTime > prj_MyTime :: MyTime -> REP__MyTime > > I hope this helps, and further questions or documentation contributions > are very welcome! > > Cheers, > > Adam > > > On 09/09/14 14:02, Karsten Gebbert wrote: >> Hi All, >> >> I have a question concerning the api-tools package. >> >> Its not clear from the tests, sources or the tutorial how I can use >> other date/time formats that the default `utc` type can handle. I'm >> trying to wrap a JSON API that is not under my control, so I have to >> adhere to whatever I get back from it. Could anybody with experience >> with the package point me to some example, relevant bits in the sources >> or a tip how to do it? >> >> I'm planning to create some more documentation around the package to >> contribute back once I figured out a few more details, because I think >> its quite a useful abstraction when dealing with (foreign) APIs IMO. >> >> Thanks already for any hints, >> >> karsten > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ From frodo at theshire.org Tue Sep 9 15:43:37 2014 From: frodo at theshire.org (Cristiano Paris) Date: Tue, 9 Sep 2014 17:43:37 +0200 Subject: [Haskell-cafe] Reversing a fixed-length vector In-Reply-To: References: Message-ID: In the meantime I factored out the "Plus" type family. https://gist.github.com/anonymous/77fe0d1a6525c9e78d42 I wonder whether it'd be possible to move the Type Equality at a more general level in order to hold in any context where Plus appears. C. On Tue, Sep 9, 2014 at 4:45 PM, Cristiano Paris wrote: > I almost got there with Type Equalities, but I can't really understand the > "VecReverse n (S m)" constraint in the instance bit of "VecReverse (S n) m". > > C. > > On Tue, Sep 9, 2014 at 4:12 PM, adam vogt wrote: > >> Hi Cristiano, >> >> You can also convince ghc about (Plus n1 (S m) ~ S (Plus n1 m)) by >> writing VecReverse as a class: >> https://gist.github.com/aavogt/15399cbdd5e74d0e9cd8 >> >> Regards, >> Adam >> >> On Tue, Sep 9, 2014 at 10:07 AM, Cristiano Paris >> wrote: >> > Gosh! I suspected I hit a non-trivial problem... cool! >> > >> > C. >> > >> > On Tue, Sep 9, 2014 at 3:56 PM, Carter Schonwald >> > wrote: >> >> >> >> heres a version richard eisenburg helped me write >> >> https://gist.github.com/cartazio/9340008 >> >> see the linked gist for the full code but heres the meat of it >> >> >> >> >> >> data Shape (rank :: Nat) a where >> >> Nil :: Shape Z a >> >> (:*) :: !(a) -> !(Shape r a ) -> Shape (S r) a >> >> >> >> {-# INLINE reverseShape #-} >> >> reverseShape :: Shape n a -> Shape n a >> >> reverseShape Nil = Nil >> >> reverseShape list = go SZero Nil list >> >> where >> >> go :: SNat n1 -> Shape n1 a-> Shape n2 a -> Shape (n1 + n2) a >> >> go snat acc Nil = gcastWith (plus_id_r snat) acc >> >> go snat acc (h :* (t :: Shape n3 a)) = >> >> gcastWith (plus_succ_r snat (Proxy :: Proxy n3)) >> >> (go (SSucc snat) (h :* acc) t) >> >> >> >> >> >> On Tue, Sep 9, 2014 at 8:55 AM, Cristiano Paris >> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> I'm playing around with Type Families so I decided to implement a >> simple >> >>> fixed-length Vect of Integers. >> >>> >> >>> Here is my straightforward implementation (ghc 7.8.3): >> >>> >> >>> https://gist.github.com/anonymous/d838e68ce6a02412859f >> >>> >> >>> As you can see, I'm trying to implement a reverse function for my >> vectors >> >>> which guarantees that the output vector is the same size as the input >> one. I >> >>> tried to express this constraint at the type level. >> >>> >> >>> The problem is that I can't have ghc to type check the reverse >> function >> >>> in the non-trivial case: >> >>> >> >>> _________________ >> >>> Could not deduce (Plus n1 (S m) ~ S (Plus n1 m)) >> >>> from the context (n ~ S n1) >> >>> bound by a pattern with constructor >> >>> CV :: forall n. Int -> Vect n -> Vect (S n), >> >>> in an equation for ?vecReverse? >> >>> at vect3.hs:30:13-18 >> >>> Expected type: Vect (Plus n m) >> >>> Actual type: Vect (Plus n1 (S m)) >> >>> _________________ >> >>> >> >>> Iit has to do with the fact that the type checker can't deduce that: >> >>> >> >>> Plus n1 (S m) ~ S (Plus n1 m) ~ Plus (S n1) m ~Plus n m >> >>> >> >>> I tried to insert the following instance to the family: >> >>> >> >>> Plus n (S m) = S (Plus n m) >> >>> >> >>> but to no avail. >> >>> >> >>> Any clue? >> >>> >> >>> Thanks. >> >>> >> >>> C. >> >>> >> >>> -- >> >>> GPG Key: 4096R/C17E53C6 2010-02-22 >> >>> Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 >> >>> >> >>> >> >>> _______________________________________________ >> >>> Haskell-Cafe mailing list >> >>> Haskell-Cafe at haskell.org >> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >>> >> >> >> > >> > >> > >> > -- >> > GPG Key: 4096R/C17E53C6 2010-02-22 >> > Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > > > > -- > GPG Key: 4096R/C17E53C6 2010-02-22 > Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 > > -- GPG Key: 4096R/C17E53C6 2010-02-22 Fingerprint = 4575 4FB5 DC8E 7641 D3D8 8EBE DF59 B4E9 C17E 53C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From efsubenovex at gmail.com Tue Sep 9 16:27:05 2014 From: efsubenovex at gmail.com (Schell Scivally) Date: Tue, 9 Sep 2014 09:27:05 -0700 Subject: [Haskell-cafe] Temporarily taking over hdevtools on Hackage Message-ID: I talked with Erik the admin at hackage about taking over hdevtools and he suggested waiting another week before invading. In the meantime he suggested asking a hackage trustee to please upload this git branch to hackage (https://github.com/schell/hdevtools/tree/cabal-support-ghc7.8). Thank you and let me know if there is anything else I can do to help! -- Schell Scivally | github | twitter | blog | wiki -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Sep 9 17:35:47 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 9 Sep 2014 13:35:47 -0400 Subject: [Haskell-cafe] Temporarily taking over hdevtools on Hackage In-Reply-To: References: Message-ID: the libraries list the list for making the official requests please :) On Tue, Sep 9, 2014 at 12:27 PM, Schell Scivally wrote: > I talked with Erik the admin at hackage about taking over hdevtools and he > suggested waiting another week before invading. In the meantime he > suggested asking a hackage trustee to please upload this git branch to > hackage (https://github.com/schell/hdevtools/tree/cabal-support-ghc7.8). > Thank you and let me know if there is anything else I can do to help! > > -- > Schell Scivally | github | twitter > | blog | wiki > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Tue Sep 9 18:53:56 2014 From: gale at sefer.org (Yitzchak Gale) Date: Tue, 9 Sep 2014 21:53:56 +0300 Subject: [Haskell-cafe] 2014 haskell cabal update hangs on mac In-Reply-To: <1397DF7E-BDB9-46F8-B7D8-4887681F91C2@dc.uba.ar> References: <59D8EF48-B854-407B-A067-C87DCDF1C9B7@gmail.com> <1397DF7E-BDB9-46F8-B7D8-4887681F91C2@dc.uba.ar> Message-ID: Daniel Gor?n wrote: > I had the same problem. It turned out to be that for some unknown reason I ended up with: > > /Library/Haskell/ghc-7.8.3-x86_64/bin/cabal -> cabal.wrap > /Library/Haskell/ghc-7.8.3-x86_64/bin/cabal.real -> cabal.wrap > /Library/Haskell/ghc-7.8.3-x86_64/bin/cabal.wrap > > where cabal.wrap is a shell script that checks if a new cabal.config > should be created and then calls? cabal.real. Replacing cabal.real with a binary version of cabal solves it. > > I don?t know why this happened, I suspect that it might occur if you had ghc 7.8.2 already installed... I believe this is a bug in the scripts activate-hs and uninstall-hs provided by the Haskell Platform installer for Mac OS X. I have reported it here: https://github.com/haskell/haskell-platform/issues/147 -Yitz From spicydonuts at gmail.com Tue Sep 9 22:06:57 2014 From: spicydonuts at gmail.com (Michael Trotter) Date: Tue, 09 Sep 2014 15:06:57 -0700 (PDT) Subject: [Haskell-cafe] =?utf-8?q?cabal-install_fails_=28osx_10=2E10=29?= =?utf-8?b?4oCL?= In-Reply-To: <1410276540710.c9d9bd7e@Nodemailer> References: <1410276540710.c9d9bd7e@Nodemailer> Message-ID: <1410300417605.ec894b46@Nodemailer> I'm having trouble getting cabal-install to work. ?I used homebrew (brew install cabal-install), which successfully installed the ghc dependency and then attempted to install cabal-install. ?The problem looks like it's either with my ghc install or maybe an issue with cabal-install and osx 10.10. ?This is my first haskell experience though, so I'm not really sure how to proceed. Here's the console output: setup: Error: Could not find module: Distribution.Compat.CreatePipe with any suffix: ["dyn_hi"] in the search path: ["dist/build"] cabal: Error: some packages failed to install: Cabal-1.20.0.2 failed during the final install step. The exception was: ExitFailure 1 cabal-install-1.20.0.3 depends on Cabal-1.20.0.2 which failed to install. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at chrisdornan.com Tue Sep 9 21:32:06 2014 From: chris at chrisdornan.com (Chris Dornan) Date: Tue, 09 Sep 2014 23:32:06 +0200 Subject: [Haskell-cafe] api-tools questions In-Reply-To: <86iokwhlc9.fsf@fook.fritz.box> References: <86ppf5gd66.fsf@fook.fritz.box> <540F0BCF.8040004@well-typed.com> <86iokwhlc9.fsf@fook.fritz.box> Message-ID: You might also find the keystore[0] package useful as it makes use of This technique in several places. See, for example the definition of Pattern in the `Data.Keystore.Types.Schema`[1] and `Data.Keystore.Types`[2]. Chris [0]-http://hackage.haskell.org/package/keystore [1]-https://github.com/cdornan/keystore/blob/master/src/Data/KeyStore/Types /Schema.hs#L179 [2]-https://github.com/cdornan/keystore/blob/master/src/Data/KeyStore/Types .hs#L68 On 09/09/2014 17:20, "Karsten Gebbert" wrote: >Excellent, thanks a lot Adam. I'll open a PR when I'm through with this >project :) > >Adam Gundry writes: > >> Hi Karsten, >> >> This isn't very well documented, but there is a (hidden) feature of >> api-tools that should do what you want. If you say something like >> >> mt :: MyTime = basic string with inj_MyTime, prj_MyTime >> >> then you can define your own type MyTime and give conversion functions >> inj_MyTime and prj_MyTime to convert back and forth from a >> newtype-wrapped Text. (In fact, you could probably use UTCTime as >> MyTime...). More precisely, api-tools will generate something like >> >> newtype REP__MyTime = REP__MyTime Text >> >> and you will need to implement >> >> inj_MyTime :: REP__MyTime -> ParserWithErrs MyTime >> prj_MyTime :: MyTime -> REP__MyTime >> >> I hope this helps, and further questions or documentation contributions >> are very welcome! >> >> Cheers, >> >> Adam >> >> >> On 09/09/14 14:02, Karsten Gebbert wrote: >>> Hi All, >>> >>> I have a question concerning the api-tools package. >>> >>> Its not clear from the tests, sources or the tutorial how I can use >>> other date/time formats that the default `utc` type can handle. I'm >>> trying to wrap a JSON API that is not under my control, so I have to >>> adhere to whatever I get back from it. Could anybody with experience >>> with the package point me to some example, relevant bits in the sources >>> or a tip how to do it? >>> >>> I'm planning to create some more documentation around the package to >>> contribute back once I figured out a few more details, because I think >>> its quite a useful abstraction when dealing with (foreign) APIs IMO. >>> >>> Thanks already for any hints, >>> >>> karsten >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe at haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From vigalchin at gmail.com Wed Sep 10 03:36:55 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 9 Sep 2014 22:36:55 -0500 Subject: [Haskell-cafe] FFI question In-Reply-To: References: Message-ID: On Tue, Sep 9, 2014 at 10:36 PM, Vasili I. Galchin wrote: > Adam, > > Did a find/grep under my posix-realtime directory .. no > definition of MCL_CURRENT, MCL_FUTURE or MCL_CURRENTandFUTURE!! But If > I comment out the case arm MCL_CURRENTandFUTURE in my LockMem.hsc file > and run "cabal build" from the directory where my *.cabal file lives > .. clean compile ... Sigh!??!! > > Vasya > > On Mon, Sep 8, 2014 at 7:36 AM, adam vogt wrote: >> Hi Vasili >> >> Does the sys/mman.h or another included header actually define >> MCL_CURRENTandFUTURE? >> >> Regards, >> Adam >> >> On Sep 8, 2014 4:45 AM, "Vasili I. Galchin" wrote: >>> >>> Following is a fragment generated by hsc2hs from LockedMem.hsc: >>> >>> #line 93 "LockedMem.hsc" >>> hsc_const (MCL_CURRENTandFUTURE); >>> hsc_fputs (")\n" >>> "", hsc_stdout()); >>> hsc_line (94, "LockedMem.hsc"); >>> hsc_fputs ("\n" >>> "foreign import ccall unsafe \"sys/mman.h mlockall\"\n" >>> " c_mlockall :: CInt -> IO CInt\n" >>> "\n" >>> "\n" >>> "-- | unlock all mapped pages of a process!\n" >>> "unlockAllMemory :: IO () \n" >>> "unlockAllMemory = do\n" >>> " throwErrnoIfMinus1 \"unlockAllMemory\" (c_munlockall)\n" >>> " return ()\n" >>> "\n" >>> "foreign import ccall unsafe \"sys/mman.h munlockall\"\n" >>> " c_munlockall :: IO CInt\n" >>> "", hsc_stdout()); >>> return 0; >>> >>> On Mon, Sep 8, 2014 at 2:11 AM, Vasili I. Galchin >>> wrote: >>> > Hello, >>> > >>> > I need memory refreshing about FFI because I need to fix a bug >>> > (plus I got down a rat hole because of Ukraine war :-(). Following a >>> > snippet of something I wrote: >>> > >>> > -- | lock all of the memory space of a process >>> > lockAllMemory :: LockAllFlags -> IO () >>> > lockAllMemory flags = do >>> > throwErrnoIfMinus1 "lockAllMemory" (c_mlockall cflags) >>> > return () >>> > where >>> > cflags = case flags of >>> > CURRENT -> (#const MCL_CURRENT) >>> > FUTURE -> (#const MCL_FUTURE) >>> > CURRENTandFUTURE -> (#const MCL_CURRENTandFUTURE) >>> > >>> > >>> > it is a file called LockedMem.hsc and the third arm CURRENTandFUTURE I >>> > just added to fix the this bug .. >>> > >>> > MCL_CURRENTandFUTURE ends up in LockedMem_make.c(sp??) but I get a >>> > undeclared nasty message when I try to build LockedMem.hsc... my >>> > bad... . Please help so I can go back to help Ukraine. >>> > >>> > Kind regarsd, >>> > >>> > Vasya >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe From allbery.b at gmail.com Wed Sep 10 03:41:12 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 9 Sep 2014 23:41:12 -0400 Subject: [Haskell-cafe] FFI question In-Reply-To: References: Message-ID: On Tue, Sep 9, 2014 at 11:36 PM, Vasili I. Galchin wrote: > > Did a find/grep under my posix-realtime directory .. no > > definition of MCL_CURRENT, MCL_FUTURE or MCL_CURRENTandFUTURE!! But If > > I comment out the case arm MCL_CURRENTandFUTURE in my LockMem.hsc file > > and run "cabal build" from the directory where my *.cabal file lives > > .. clean compile ... Sigh!??!! > The fact that they start with uppercase tells me that they are from C, not Haskell. The implication of their relationship with mlockall is that they come from a related system header file, namely . I note that neither my FreeBSD nor my OS X system defines MCL_CURRENTandFUTURE in /usr/include/sys/mman.h, although the other two are defined. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Wed Sep 10 03:53:35 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 9 Sep 2014 22:53:35 -0500 Subject: [Haskell-cafe] FFI question In-Reply-To: References: Message-ID: oops ... let me check .. on the other hand after rereading man page on POSIX mlockall I noticed that "flags" formal parameter .. .I noticed that can be OR'd .. hence I want to OR MCL_CURRENT and MCL_FUTURE ... fix this then ... back to helping Ukraina before V.V.Putin does more nastiness .... Kind thanks, Vasya On Tue, Sep 9, 2014 at 10:41 PM, Brandon Allbery wrote: > On Tue, Sep 9, 2014 at 11:36 PM, Vasili I. Galchin > wrote: >> >> > Did a find/grep under my posix-realtime directory .. no >> > definition of MCL_CURRENT, MCL_FUTURE or MCL_CURRENTandFUTURE!! But If >> > I comment out the case arm MCL_CURRENTandFUTURE in my LockMem.hsc file >> > and run "cabal build" from the directory where my *.cabal file lives >> > .. clean compile ... Sigh!??!! > > > The fact that they start with uppercase tells me that they are from C, not > Haskell. The implication of their relationship with mlockall is that they > come from a related system header file, namely . > > I note that neither my FreeBSD nor my OS X system defines > MCL_CURRENTandFUTURE in /usr/include/sys/mman.h, although the other two are > defined. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From vigalchin at gmail.com Wed Sep 10 04:50:38 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 9 Sep 2014 23:50:38 -0500 Subject: [Haskell-cafe] FFI question In-Reply-To: References: Message-ID: Bottom line is how can I do arithmetic (addition) on two #const's ??? I can hard code a "3" => nasty solution ... Kind thanks, Vasili On Tue, Sep 9, 2014 at 10:53 PM, Vasili I. Galchin wrote: > oops ... let me check .. > > on the other hand after rereading man page on POSIX mlockall I noticed > that "flags" formal parameter .. .I noticed that can be OR'd .. hence > I want to OR MCL_CURRENT and MCL_FUTURE ... fix this then ... > > back to helping Ukraina before V.V.Putin does more nastiness .... > > Kind thanks, > > Vasya > > On Tue, Sep 9, 2014 at 10:41 PM, Brandon Allbery wrote: >> On Tue, Sep 9, 2014 at 11:36 PM, Vasili I. Galchin >> wrote: >>> >>> > Did a find/grep under my posix-realtime directory .. no >>> > definition of MCL_CURRENT, MCL_FUTURE or MCL_CURRENTandFUTURE!! But If >>> > I comment out the case arm MCL_CURRENTandFUTURE in my LockMem.hsc file >>> > and run "cabal build" from the directory where my *.cabal file lives >>> > .. clean compile ... Sigh!??!! >> >> >> The fact that they start with uppercase tells me that they are from C, not >> Haskell. The implication of their relationship with mlockall is that they >> come from a related system header file, namely . >> >> I note that neither my FreeBSD nor my OS X system defines >> MCL_CURRENTandFUTURE in /usr/include/sys/mman.h, although the other two are >> defined. >> >> -- >> brandon s allbery kf8nh sine nomine associates >> allbery.b at gmail.com ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net From donn at avvanta.com Wed Sep 10 06:19:08 2014 From: donn at avvanta.com (Donn Cave) Date: Tue, 9 Sep 2014 23:19:08 -0700 (PDT) Subject: [Haskell-cafe] FFI question In-Reply-To: References: Message-ID: <20140910061908.E492093C2E@mail.avvanta.com> quoth "Vasili I. Galchin", > Bottom line is how can I do arithmetic (addition) on two #const's ??? I'm sorry to say I haven't been following the thread, but on the face of it, this seems easy to me - you just use the (C) addition operator! like, (#const CPPSYMA + CPPSYMB) I assume you're using hsc2hs. Donn From arnaud.oqube at gmail.com Wed Sep 10 06:55:17 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Wed, 10 Sep 2014 08:55:17 +0200 Subject: [Haskell-cafe] Persistent Journal/Event queue Implementation Message-ID: Hello Cafe, I am looking for a Haskell implementation (or library binding) to some persistent journal/event queue software, something like Apache Kafka. My google-fu is lacking so I was not able to find anything but I might have been doing it wrong. Thanks, -- Arnaud Bailly FoldLabs Associate: http://foldlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Wed Sep 10 09:43:54 2014 From: adam at bergmark.nl (Adam Bergmark) Date: Wed, 10 Sep 2014 11:43:54 +0200 Subject: [Haskell-cafe] =?utf-8?q?cabal-install_fails_=28osx_10=2E10=29?= =?utf-8?b?4oCL?= In-Reply-To: <1410300417605.ec894b46@Nodemailer> References: <1410276540710.c9d9bd7e@Nodemailer> <1410300417605.ec894b46@Nodemailer> Message-ID: Hi Michael, It seems the consensus is that using homebrew to install GHC is a bad idea, it causes problems and is not actively maintained. Instead I'd recommend using either the Haskell Platform [1] or GHC for OS X [2], both include more recent versions of GHC and cabal-install. Cheers, Adam [1] https://www.haskell.org/platform/ [2] http://ghcformacosx.github.io/ On Wed, Sep 10, 2014 at 12:06 AM, Michael Trotter wrote: > I'm having trouble getting cabal-install to work. I used homebrew (brew > install cabal-install), which successfully installed the ghc dependency and > then attempted to install cabal-install. The problem looks like it's > either with my ghc install or maybe an issue with cabal-install and osx > 10.10. This is my first haskell experience though, so I'm not really sure > how to proceed. > > Here's the console output: > > setup: Error: Could not find module: Distribution.Compat.CreatePipe with > any > suffix: ["dyn_hi"] in the search path: ["dist/build"] > cabal: Error: some packages failed to install: > Cabal-1.20.0.2 failed during the final install step. The exception was: > ExitFailure 1 > cabal-install-1.20.0.3 depends on Cabal-1.20.0.2 which failed to install. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at functorgroup.com Wed Sep 10 12:22:35 2014 From: j at functorgroup.com (Johan Glimming) Date: Wed, 10 Sep 2014 14:22:35 +0200 Subject: [Haskell-cafe] LinkedIn job ad link for openings for several enthusiastic great Haskell developers (geoloc. globally) at Swedish spin-off Functor Group with subsidiaries + three Scala developer (geoloc. Sweden) with spear-edge / very strong qualifications and high-end industry salary for Functor Consulting AB Message-ID: Dear Haskell developers, type theory developers, Agda/Epigram/Idris/Coq developers/enthusiasts abound in this community, We are searching the planet for great Haskell and Scala programmers right now for a really interesting spin-off now growing and flourishing after 2.5 years since it was founded. If you are a functional programmer this might be the most exciting job around with e.g. a very exciting customer "as close as a space station as you can get", and industrially entirely unique heavily research-based technology that we have developed now for several years. ? https://www.linkedin.com/jobs2/view/19207355 You would help us develop our products further, the new constructive programming paradigm based on type theory carrying languages including domain-specific languages as never done before in the software industry ? ( And yes, we are entirely based on (Martin-L?f) type theory, that's what we are all about. And we use Haskell for our development internally almost entirely, with some Ocaml etc on top ... ) We look for three experienced Scala developers (for being based in Sweden, Stockholm-area) at Functor Group AB, Functor AB and Functor Consulting AB. These developers are recruited into Functor Consulting AB which is to become the spear-edge partner to Typesafe in Scandinavia, specifically Sweden, while interacting with our other two teams at Functor AB to a certain extent, focusing on DSL development, DDD and more. We bring type theory to the industry in the new constructive programming paradigm and with a new static analysis technique combined with testing and dependent types, all based on the same core technology ? The three Scala developers, for extreme FP consultancy, are offered very competitive Swedish salary, plus added potential for also other benefits via Functor Group AB and the product company Functor AB. Experience from Scala development and documented skills with Scala and related technologies (such as Java) is must be considerable to be considered for these three positions. If you are not based in Sweden, we would assist as much as possible in moving to Stockholm/Uppsala, Sweden, where these three Scala spear-edge developers will be based, with a consultancy manager of considerable experience handling administration and co-ordination in what we expect to be an otherwise quite self-organised business targeting the hardest and most challenging projects at any given time. You can apply on LinkedIn ? or, if you prefer, email your resum?, references, credentials, and cover letter to jobs at functorgroup.com. ? https://www.linkedin.com/jobs2/view/19207355. Best wishes, Johan Glimming ? Company website: http://www.functorgroup.com Twitter feeds to follow: @FunctorGroup @Functors @FunctorTech -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Functional+Dependencies+-+with+texts+and+logos+-+2013-12-12.png Type: image/png Size: 39524 bytes Desc: not available URL: From carter.schonwald at gmail.com Wed Sep 10 13:25:59 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 10 Sep 2014 09:25:59 -0400 Subject: [Haskell-cafe] =?utf-8?q?cabal-install_fails_=28osx_10=2E10=29?= =?utf-8?b?4oCL?= In-Reply-To: References: <1410276540710.c9d9bd7e@Nodemailer> <1410300417605.ec894b46@Nodemailer> Message-ID: I second Adam's remark. don't use brew for ghc/haskell, it aint maintained properly. (and no one seems inclined to maintain it) On Wed, Sep 10, 2014 at 5:43 AM, Adam Bergmark wrote: > Hi Michael, > > It seems the consensus is that using homebrew to install GHC is a bad > idea, it causes problems and is not actively maintained. Instead I'd > recommend using either the Haskell Platform [1] or GHC for OS X [2], both > include more recent versions of GHC and cabal-install. > > Cheers, > Adam > > [1] https://www.haskell.org/platform/ > [2] http://ghcformacosx.github.io/ > > > On Wed, Sep 10, 2014 at 12:06 AM, Michael Trotter > wrote: > >> I'm having trouble getting cabal-install to work. I used homebrew >> (brew install cabal-install), which successfully installed the ghc >> dependency and then attempted to install cabal-install. The problem looks >> like it's either with my ghc install or maybe an issue with cabal-install >> and osx 10.10. This is my first haskell experience though, so I'm not >> really sure how to proceed. >> >> Here's the console output: >> >> setup: Error: Could not find module: Distribution.Compat.CreatePipe with >> any >> suffix: ["dyn_hi"] in the search path: ["dist/build"] >> cabal: Error: some packages failed to install: >> Cabal-1.20.0.2 failed during the final install step. The exception was: >> ExitFailure 1 >> cabal-install-1.20.0.3 depends on Cabal-1.20.0.2 which failed to install. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trevor.j.cook at gmail.com Wed Sep 10 15:13:43 2014 From: trevor.j.cook at gmail.com (trevor cook) Date: Wed, 10 Sep 2014 11:13:43 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) Message-ID: Hi Haskell Cafe, In Vector-space-0.8.7, there is the cited inconsistency of the definition of AdditiveGroup (Maybe a). I've posted the source, including comment, below for reference. Following the logic of the counterexample and Conal's (and or Andy Gill's) comment, the problem hinges on the equality, Nothing = Just (zeroV :: a). I'm curious about the catigorical description of this situation. Does this mean that the category of Additive Groups and Maybe Additive Groups are equivalent as categories? I'm not proposing that this is somehow a resolution to vector-space, but rather trying to gain some insight into equivalence, naturalitity, adjunction, etc. My thinking as to why equivalence is that if we have the instance below defined using: zeroV = Just zeroV and making appropriate changes following that new decision. Nothing ^+^ Nothing = zeroV a ^+^ Nothing = a Nothing ^+^ b = b negateV Nothing = zeroV negateV a = fmap negateV then we pretty much defer the group structure of (Maybe a) to be based totally on the structure of a. And since `a` and `Maybe a` are not isomorphic then "hey, I just learned about this new thing so maybe its that." Its a horrible argument, hopefully the cafe will show some better thinking for me. Regards, Trevor -- Maybe is handled like the Maybe-of-Sum monoidinstance AdditiveGroup a => AdditiveGroup (Maybe a) where zeroV = Nothing Nothing ^+^ b' = b' a' ^+^ Nothing = a' Just a' ^+^ Just b' = Just (a' ^+^ b') negateV = fmap negateV{-Alexey Khudyakov wrote: I looked through vector-space package and found lawless instance. Namely Maybe's AdditiveGroup instance It's group so following relation is expected to hold. Otherwise it's not a group. > x ^+^ negateV x == zeroV Here is counterexample: > let x = Just 2 in x ^+^ negateV x == zeroV False I think it's not possible to sensibly define group instance for Maybe a at all.I see that the problem here is in distinguishing 'Just zeroV' fromNothing. I could fix the Just + Just line to use Nothing instead of JustzeroV when a' ^+^ b' == zeroV, although doing so would require Eq a andhence lose some generality. Even so, the abstraction leak would probablyshow up elsewhere.Hm.-} -------------- next part -------------- An HTML attachment was scrubbed... URL: From spicydonuts at gmail.com Wed Sep 10 15:54:48 2014 From: spicydonuts at gmail.com (Michael Trotter) Date: Wed, 10 Sep 2014 08:54:48 -0700 (PDT) Subject: [Haskell-cafe] =?utf-8?q?cabal-install_fails_=28osx_10=2E10=29?= =?utf-8?b?4oCL?= In-Reply-To: References: Message-ID: <1410364488368.bb82b27@Nodemailer> Ok, I'll give that a shot. ?Thank you both! On Wed, Sep 10, 2014 at 7:26 AM, Carter Schonwald wrote: > I second Adam's remark. don't use brew for ghc/haskell, it aint maintained > properly. (and no one seems inclined to maintain it) > On Wed, Sep 10, 2014 at 5:43 AM, Adam Bergmark wrote: >> Hi Michael, >> >> It seems the consensus is that using homebrew to install GHC is a bad >> idea, it causes problems and is not actively maintained. Instead I'd >> recommend using either the Haskell Platform [1] or GHC for OS X [2], both >> include more recent versions of GHC and cabal-install. >> >> Cheers, >> Adam >> >> [1] https://www.haskell.org/platform/ >> [2] http://ghcformacosx.github.io/ >> >> >> On Wed, Sep 10, 2014 at 12:06 AM, Michael Trotter >> wrote: >> >>> I'm having trouble getting cabal-install to work. I used homebrew >>> (brew install cabal-install), which successfully installed the ghc >>> dependency and then attempted to install cabal-install. The problem looks >>> like it's either with my ghc install or maybe an issue with cabal-install >>> and osx 10.10. This is my first haskell experience though, so I'm not >>> really sure how to proceed. >>> >>> Here's the console output: >>> >>> setup: Error: Could not find module: Distribution.Compat.CreatePipe with >>> any >>> suffix: ["dyn_hi"] in the search path: ["dist/build"] >>> cabal: Error: some packages failed to install: >>> Cabal-1.20.0.2 failed during the final install step. The exception was: >>> ExitFailure 1 >>> cabal-install-1.20.0.3 depends on Cabal-1.20.0.2 which failed to install. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From trevor.j.cook at gmail.com Wed Sep 10 16:20:12 2014 From: trevor.j.cook at gmail.com (trevor cook) Date: Wed, 10 Sep 2014 12:20:12 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) Message-ID: Here's that vector-space code, formatted better. -- Maybe is handled like the Maybe-of-Sum monoid instance AdditiveGroup a => AdditiveGroup (Maybe a) where zeroV = Nothing Nothing ^+^ b' = b' a' ^+^ Nothing = a' Just a' ^+^ Just b' = Just (a' ^+^ b') negateV = fmap negateV {- Alexey Khudyakov wrote: I looked through vector-space package and found lawless instance. Namely Maybe's AdditiveGroup instance It's group so following relation is expected to hold. Otherwise it's not a group. > x ^+^ negateV x == zeroV Here is counterexample: > let x = Just 2 in x ^+^ negateV x == zeroV False I think it's not possible to sensibly define group instance for Maybe a at all.I see that the problem here is in distinguishing 'Just zeroV' fromNothing. I could fix the Just + Just line to use Nothing instead of JustzeroV when a' ^+^ b' == zeroV, although doing so would require Eq a andhence lose some generality. Even so, the abstraction leak would probablyshow up elsewhere.Hm. -} -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Wed Sep 10 19:05:14 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Wed, 10 Sep 2014 15:05:14 -0400 Subject: [Haskell-cafe] Use Haskell shared library with foreign exports with dlopen/dlsym In-Reply-To: References: Message-ID: <5410A0EA.4080803@vex.net> This is going to be very cunning. hs_init is not needed in this case because the executable comes from ghc --make -dynamic test.hs The "-dynamic" causes the exemption. This is similar to the case of ghci 7.8 on Linux. (I agree that there are differences too. For now, the similarity dominates. The executable has already brought in a dynamic RTS, and it has already been hs_inited and running. Subsequently, any dynamic library that looks for a dynamic RTS will simply find the running one.) Here is the story of the segfault: 1. "foreign export" causes the following dynamic library constructor to be included in the dynamic library: static void stginit_export_Test_zdfstableZZC0ZZCmainZZCTestZZCtest() __attribute__((constructor)); static void stginit_export_Test_zdfstableZZC0ZZCmainZZCTestZZCtest() { foreignExportStablePtr((StgPtr) &Test_zdfstableZZC0ZZCmainZZCTestZZCtest_closure); } foreignExportStablePtr is in the RTS (and we do have a dynamic RTS already running). Test_zdfstableZZC0ZZCmainZZCTestZZCtest_closure is in the dynamic library representing the test::Int in module Test. I found out by -keep-tmp-files and examining the tmp files. 2. dlopen causes a mmap, and the closure's address is in that mmap region. 3. dlopen also causes the constructor to be invoked. I suppose it means a StablePtr is created, therefore the closure's address is registered in the global table of StablePtrs. 4. dlclose causes a munmap. The closure's address is now invalid. 5. Garbage collection visits everything registered in the global table of StablePtrs (among other roots). But one of the registered addresses is invalid. Segfault. I found out by asking gdb for backtrace. So in fact I can specifically point at "evacuate()". At this point, my recommendation: Don't use "-dynamic" on the executable. Do it static. This implies you will have two RTSes, the static one used by the executable for itself, and the dynamic one used by the dynamic library for itself. This is a good thing because the static GCtor will never visit the closure in the dynamic library, hell it will never hear of it. The dynamic library will find and use foreignExportStablePtr from the dynamic RTS only. It doesn't see the static RTS, or any static library for that matter. The dynamic GCtor is the only one who knows of the closure, but this GCtor no longer runs after dlclose, hell it no longer exists. The down side is that you now have to do the full thing to the dynamic library: http://www.vex.net/~trebla/haskell/so.xhtml section "Making The Library" P.S. I believe that those things about hs_add_root and __stginit_* are outdated. On 14-09-08 12:47 PM, Carter Schonwald wrote: > what OS and other things? > what does ghc --info say? > Also, when calling haskell code as if it were C code, you need to init > the RTS its using, its not going to magically know you're linking to it > from haskell.(though maybe you can arrange things to use the pre inited > hs runtime, but i'm not familiar with how to do so) > http://www.haskell.org/haskellwiki/Calling_Haskell_from_C > > On Mon, Sep 8, 2014 at 10:05 AM, Tobias Neumann > wrote: > > Hello Cafe, > > I am trying to use a Haskell shared library with foreign exports from > Haskell again via dlopen/dlsym. Sadly it segfaults, and the segfaults > happen on dlclose during garbage collection points (as figured out by > monochrom in #haskell). So right now I can only open a library once and > may not dlclose it. Can someone point me to a mistake I made, or is this > rather a ghc (7.8.3) bug? Please see attached minimal example. > > Regards, Tobias > > > test.hs: > module Main where > > import qualified System.Posix.DynamicLinker as DL > import Foreign > > foreign import ccall "dynamic" > mkTest :: FunPtr Int -> Int > > main = do > DL.withDL ("./libtest.so") [DL.RTLD_NOW] $ \dl -> do > dimPtr <- DL.dlsym dl "test" > let test = mkTest dimPtr > print test > > libtest.hs: > module Test() where > > import Foreign > > foreign export ccall test :: Int > > test :: Int > test = 124 > > build with: > ghc --make -shared -dynamic -fPIC libtest.hs -o libtest.so > ghc --make -dynamic test.hs > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From k at ioctl.it Wed Sep 10 20:05:54 2014 From: k at ioctl.it (Karsten Gebbert) Date: Wed, 10 Sep 2014 22:05:54 +0200 Subject: [Haskell-cafe] api-tools questions In-Reply-To: References: <86ppf5gd66.fsf@fook.fritz.box> <540F0BCF.8040004@well-typed.com> <86iokwhlc9.fsf@fook.fritz.box> Message-ID: <8761gvmeal.fsf@fook.i-did-not-set--mail-host-address--so-tickle-me> Chris, thank you for the pointer, that is really helpful indeed! I see that you are using Haskell types for some fields, rather than types defined in your API. When I, for instance, try to use Map as field type, with String as both key and value type, I get an error: myrec :: MyRec // a map = record myfield :: Map String String Exception when trying to run compile-time code: Syntax error at line 345, column 20 (@8596): [(AlexPn 8596 345 20,TypeIden "String"),(AlexPn 8603 345 27,TypeIden "String")] I suspect this is only the case with types that are parameterized over others, as a type synonym seems to make this possible anyways. Is there a better way to deal with this than the one I mentioned? Thanks for your help, karsten Chris Dornan writes: > You might also find the keystore[0] package useful as it makes use of > This technique in several places. See, for example the definition of > Pattern in the `Data.Keystore.Types.Schema`[1] and > `Data.Keystore.Types`[2]. > > Chris > > [0] http://hackage.haskell.org/package/keystore > [1] > https://github.com/cdornan/keystore/blob/master/src/Data/KeyStore/Types/Sch > ema.hs#L179 > [2] > https://github.com/cdornan/keystore/blob/master/src/Data/KeyStore/Types.hs# > L68 > [3] http://hackage.haskell.org/package/keystore-0.5.0.4 > > > On 09/09/2014 17:20, "Karsten Gebbert" wrote: > >>Excellent, thanks a lot Adam. I'll open a PR when I'm through with this >>project :) >> >>Adam Gundry writes: >> >>> Hi Karsten, >>> >>> This isn't very well documented, but there is a (hidden) feature of >>> api-tools that should do what you want. If you say something like >>> >>> mt :: MyTime = basic string with inj_MyTime, prj_MyTime >>> >>> then you can define your own type MyTime and give conversion functions >>> inj_MyTime and prj_MyTime to convert back and forth from a >>> newtype-wrapped Text. (In fact, you could probably use UTCTime as >>> MyTime...). More precisely, api-tools will generate something like >>> >>> newtype REP__MyTime = REP__MyTime Text >>> >>> and you will need to implement >>> >>> inj_MyTime :: REP__MyTime -> ParserWithErrs MyTime >>> prj_MyTime :: MyTime -> REP__MyTime >>> >>> I hope this helps, and further questions or documentation contributions >>> are very welcome! >>> >>> Cheers, >>> >>> Adam >>> >>> >>> On 09/09/14 14:02, Karsten Gebbert wrote: >>>> Hi All, >>>> >>>> I have a question concerning the api-tools package. >>>> >>>> Its not clear from the tests, sources or the tutorial how I can use >>>> other date/time formats that the default `utc` type can handle. I'm >>>> trying to wrap a JSON API that is not under my control, so I have to >>>> adhere to whatever I get back from it. Could anybody with experience >>>> with the package point me to some example, relevant bits in the sources >>>> or a tip how to do it? >>>> >>>> I'm planning to create some more documentation around the package to >>>> contribute back once I figured out a few more details, because I think >>>> its quite a useful abstraction when dealing with (foreign) APIs IMO. >>>> >>>> Thanks already for any hints, >>>> >>>> karsten >>> >>> >>> -- >>> Adam Gundry, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >>_______________________________________________ >>Haskell-Cafe mailing list >>Haskell-Cafe at haskell.org >>http://www.haskell.org/mailman/listinfo/haskell-cafe From trtoaster at googlemail.com Wed Sep 10 20:33:25 2014 From: trtoaster at googlemail.com (Thorsten Rangwich) Date: Wed, 10 Sep 2014 22:33:25 +0200 Subject: [Haskell-cafe] What happened to hugs? Message-ID: <-3701248786196244697@unknownmsgid> Hi, I suppose this question is not new, but neither google nor a manual search file be file through the archives brought enlightement. www.haskell.org/hugs still exists, but none of the links there does work. Documentation and source point to cvs.haskell.org ("server does not exist") and development points to http://hackage.haskell.org/trac/hugs ("page does not exist"). Was it migrated to somewhere else or is it dead - in latter case the page would not make sense any more. "Raskell" (iPad app) provided a development environment usinh hugs, so I would at least like to install hugs on my Mac as well... Thank you very much in advance. Thorsten. Sent from my mobile phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From rf at rufflewind.com Wed Sep 10 21:35:52 2014 From: rf at rufflewind.com (Phil Ruffwind) Date: Wed, 10 Sep 2014 17:35:52 -0400 Subject: [Haskell-cafe] Cabal doesn't reset the search-path when invoking GHC: potential subtleties Message-ID: It seems that even when invoked via Cabal, GHC will look in the local directory *first* and then in the list of modules and dependencies supplied by Cabal. I was aware of this behavior subconsciously but I hadn't realized the implications until now. Normally, it's not a big problem, other than for the occasional situation where I forget to add those local modules to 'other-modules'. This would cause 'cabal sdist' to generate an incomplete package, even though 'cabal build && cabal install' works just fine! But there are more subtle "bugs": it breaks if the executable and library share the same directory, but the library has some hidden modules stashed away in a different directory! The conditions required to reproduce this is somewhat difficult to explain, so let me show a simple example: 1. Make a Cabal package: -- ./foo.cabal name: foo version: 0.0.0.0 build-type: Simple cabal-version: >=1.8 library exposed-modules: Exposed other-modules: Hidden build-depends: base hs-source-dirs: ., hidden executable main main-is: Main.hs build-depends: base, foo 2. Add a library with two modules at the given paths: -- ./Exposed.hs module Exposed where import Hidden -- ./hidden/Hidden.hs module Hidden where 3. Add an executable: -- ./Main.hs module Main where import Exposed main = return () 4. Now run `cabal build`. This would cause an error message akin to: > Could not find module Hidden The problem is that despite the dependency on the library `foo` being specified in Cabal, GHC still chose the *local* `Exposed` module over the `Exposed` module in the library `foo`. This means when it tries to recompile the `Exposed` module, it is unaware that `Hidden` is located in another directory. The error message is unhelpful because it doesn't point to the actual cause of the problem and led me astray thinking that something was wrong with my Cabal configuration. In the end, the problem has to do with GHC deciding to look up packages in locations outside Cabal's control. There are many other ways to trigger this problem -- the above was only one that I just happened to run into. For now, a workaround would be to use `-i` with all the executables to avoid this subtle issue in the future. RF From jmccarty at sent.com Thu Sep 11 00:01:24 2014 From: jmccarty at sent.com (Jason McCarty) Date: Wed, 10 Sep 2014 20:01:24 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: References: Message-ID: <20140911000124.GA26544@tensor> Hi Trevor, On Wed, Sep 10, 2014 at 11:13:43AM -0400, trevor cook wrote: > Hi Haskell Cafe, > > In Vector-space-0.8.7, there is the cited inconsistency of the definition > of AdditiveGroup (Maybe a). I've posted the source, including comment, > below for reference. Following the logic of the counterexample and Conal's > (and or Andy Gill's) comment, the problem hinges on the equality, Nothing = > Just (zeroV :: a). > > I'm curious about the catigorical description of this situation. Does this > mean that the category of Additive Groups and Maybe Additive Groups are > equivalent as categories? I'm not proposing that this is somehow a > resolution to vector-space, but rather trying to gain some insight into > equivalence, naturalitity, adjunction, etc. It depends on what you want the morphisms to be in the category of "Maybe Additive Groups." Let G be the category of additive groups and MG be the category of "Maybe Additive Groups" with objects Maybe g, for g in G. If Hom_MG(Maybe a, Maybe b) := { fmap f | f <- Hom_G(a, b) }, then G is equivalent to MG. But you probably expect to have some more morphisms in MG, like e.g. (+ Just x) :: Maybe a -> Maybe a, which doesn't have the form (fmap f) for any f :: a -> a. In particular, Maybe a has at least two morphisms for any a in G (this and the identity). This is bad, because an equivalence of categories F: G -> MG must be a full functor; i.e., Hom_G(a, b) -> Hom_MG(Maybe a, Maybe b) must be surjective. If () in G is the trivial group, then Hom_G((), ()) has cardinality 1, but Hom_MG(Maybe (), Maybe ()) has at cardinality at least 2, so this is impossible. I don't know if there are any other structures you can put on MG that would make it equivalent to G...there certainly aren't if you want F = Maybe to be the equivalence. However, if s is a semigroup, then Maybe s is a monoid (with unit Nothing). So let S be the category of semigroups and M the category of monoids. Then Maybe is a functor S -> M. I think it is left adjoint to the forgetful functor U: M -> S. It might be a good exercise to check. But this still isn't an equivalence of categories, even if you restrict to the image { Maybe s : s <- S }, for the same reason as before. IMO this is probably the best "categorical" description of the situation. > My thinking as to why equivalence is that if we have the instance below > defined using: > zeroV = Just zeroV > > and making appropriate changes following that new decision. > Nothing ^+^ Nothing = zeroV > a ^+^ Nothing = a > Nothing ^+^ b = b > negateV Nothing = zeroV > negateV a = fmap negateV > then we pretty much defer the group structure of (Maybe a) to be based > totally on the structure of a. And since `a` and `Maybe a` are not > isomorphic then "hey, I just learned about this new thing so maybe its > that." Unfortunately this isn't even a monoid since it doesn't have a unit (Nothing + u /= Nothing for any u). So this just gives a functor G -> S; I'm not sure you can say much more about it. I hope that helps a little, sorry natural transformations didn't come into play. -- Jason McCarty From jwlato at gmail.com Thu Sep 11 00:20:38 2014 From: jwlato at gmail.com (John Lato) Date: Thu, 11 Sep 2014 08:20:38 +0800 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: <20140911000124.GA26544@tensor> References: <20140911000124.GA26544@tensor> Message-ID: On Thu, Sep 11, 2014 at 8:01 AM, Jason McCarty wrote: > Hi Trevor, > > On Wed, Sep 10, 2014 at 11:13:43AM -0400, trevor cook wrote: > > Hi Haskell Cafe, > > > > In Vector-space-0.8.7, there is the cited inconsistency of the definition > > of AdditiveGroup (Maybe a). I've posted the source, including comment, > > below for reference. Following the logic of the counterexample and > Conal's > > (and or Andy Gill's) comment, the problem hinges on the equality, > Nothing = > > Just (zeroV :: a). > > > > I'm curious about the catigorical description of this situation. Does > this > > mean that the category of Additive Groups and Maybe Additive Groups are > > equivalent as categories? I'm not proposing that this is somehow a > > resolution to vector-space, but rather trying to gain some insight into > > equivalence, naturalitity, adjunction, etc. > > It depends on what you want the morphisms to be in the category of > "Maybe Additive Groups." Let G be the category of additive groups and MG > be the category of "Maybe Additive Groups" with objects Maybe g, for g > in G. If Hom_MG(Maybe a, Maybe b) := { fmap f | f <- Hom_G(a, b) }, then > G is equivalent to MG. > > But you probably expect to have some more morphisms in MG, like e.g. > (+ Just x) :: Maybe a -> Maybe a, which doesn't have the form (fmap f) > for any f :: a -> a. In particular, Maybe a has at least two morphisms > for any a in G (this and the identity). This is bad, because an > equivalence of categories F: G -> MG must be a full functor; i.e., > Hom_G(a, b) -> Hom_MG(Maybe a, Maybe b) must be surjective. If () in G > is the trivial group, then Hom_G((), ()) has cardinality 1, but > Hom_MG(Maybe (), Maybe ()) has at cardinality at least 2, so this is > impossible. > > I don't know if there are any other structures you can put on MG that > would make it equivalent to G...there certainly aren't if you want > F = Maybe to be the equivalence. > > However, if s is a semigroup, then Maybe s is a monoid (with unit > Nothing). So let S be the category of semigroups and M the category of > monoids. Then Maybe is a functor S -> M. I think it is left adjoint to > the forgetful functor U: M -> S. It might be a good exercise to check. > But this still isn't an equivalence of categories, even if you restrict > to the image { Maybe s : s <- S }, for the same reason as before. > > IMO this is probably the best "categorical" description of the > situation. > > > My thinking as to why equivalence is that if we have the instance below > > defined using: > > zeroV = Just zeroV > > > > and making appropriate changes following that new decision. > > Nothing ^+^ Nothing = zeroV > > a ^+^ Nothing = a > > Nothing ^+^ b = b > > negateV Nothing = zeroV > > negateV a = fmap negateV > > then we pretty much defer the group structure of (Maybe a) to be based > > totally on the structure of a. And since `a` and `Maybe a` are not > > isomorphic then "hey, I just learned about this new thing so maybe its > > that." > > Unfortunately this isn't even a monoid since it doesn't have a unit > (Nothing + u /= Nothing for any u). So this just gives a functor G -> S; > I'm not sure you can say much more about it. > Well, this is the crux of the problem. If you want to define > zeroV = Just zeroV , you'll run into abstraction leaks unless you also have > Nothing == Just zeroV = True (and this should commute too), because it explicitly makes the two units (Nothing and zeroV) equivalent. But even if that were possible to write, you probably don't really want it. Even if you have > newtype MaybeAG a = MaybeAG (Maybe a) and suitably hide everything, so that a `MaybeAG a` is observably identical to just `a`, you may as well use `a` directly. Unfortunately the other proposed solution, of making 'Just a ^+^ Just b' use Nothing if 'a^+^b == zeroV', in addition to being less general, looks like trouble if `a` is a Float or Double. John L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmccarty at sent.com Thu Sep 11 00:51:00 2014 From: jmccarty at sent.com (Jason McCarty) Date: Wed, 10 Sep 2014 20:51:00 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: References: <20140911000124.GA26544@tensor> Message-ID: <20140911005100.GB26544@tensor> On Thu, Sep 11, 2014 at 08:20:38AM +0800, John Lato wrote: > On Thu, Sep 11, 2014 at 8:01 AM, Jason McCarty wrote: > > [...] > > Unfortunately this isn't even a monoid since it doesn't have a unit > > (Nothing + u /= Nothing for any u). So this just gives a functor G -> S; > > I'm not sure you can say much more about it. > > > > Well, this is the crux of the problem. If you want to define > > > zeroV = Just zeroV > > , you'll run into abstraction leaks unless you also have > > > Nothing == Just zeroV = True > > (and this should commute too), because it explicitly makes the two units > (Nothing and zeroV) equivalent. But even if that were possible to write, > you probably don't really want it. Even if you have > > > newtype MaybeAG a = MaybeAG (Maybe a) > > and suitably hide everything, so that a `MaybeAG a` is observably identical > to just `a`, you may as well use `a` directly. Yes, it seemed that way to me -- trying to make Nothing coincide with Just zeroV collapses Maybe a to a. > Unfortunately the other proposed solution, of making 'Just a ^+^ Just b' > use Nothing if 'a^+^b == zeroV', in addition to being less general, looks > like trouble if `a` is a Float or Double. Obviously this also fails for e.g. computable reals. So is the hope here to treat Maybe v like a vector space over F if v is a vector space over F? I don't think it can be done consistently. But you should be able to make Maybe v a /semi/-vector space over F (inventing terminology here); i.e. Maybe v satisfies all the vector space axioms except (negate a) *^ v == a *^ (negateV v), which doesn't make sense. But I don't know that you can do much linear algebra without negation! -- Jason McCarty From dstcruz at gmail.com Thu Sep 11 03:30:11 2014 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Wed, 10 Sep 2014 21:30:11 -0600 Subject: [Haskell-cafe] Haskell Weekly News: Issue 304 Message-ID: Welcome to issue 305 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from August 31 to September 06, 2014 Quotes of the Week * srhb: segfaults sure are easier to come by doing FFI stuff Top Reddit Stories * Pandoc author working with industry on Markdown spec Domain: standardmarkdown.com, Score: 68, Comments: 7 Original: [1] http://goo.gl/JBte8k On Reddit: [2] http://goo.gl/LWT42a * ICFP 2014 Talks Domain: youtube.com, Score: 56, Comments: 0 Original: [3] http://goo.gl/2zRte4 On Reddit: [4] http://goo.gl/NvWBBa * ICFP 2014 Workshops (Videos) Domain: youtube.com, Score: 53, Comments: 6 Original: [5] http://goo.gl/gpfI8T On Reddit: [6] http://goo.gl/Bj5SwB * Let's Build a Browser Engine in Haskell Domain: hrothen.github.io, Score: 45, Comments: 18 Original: [7] http://goo.gl/FkOM49 On Reddit: [8] http://goo.gl/rXM38x * Open type families are not modular Domain: blog.ezyang.com, Score: 41, Comments: 52 Original: [9] http://goo.gl/XO1bVK On Reddit: [10] http://goo.gl/ROxxUA * IDE for Haste projects Domain: haskell-web.blogspot.com.es, Score: 36, Comments: 5 Original: [11] http://goo.gl/uvjZUC On Reddit: [12] http://goo.gl/3Ra4dt * Real world one-liner examples Domain: github.com, Score: 33, Comments: 7 Original: [13] http://goo.gl/E5wFiW On Reddit: [14] http://goo.gl/9gipjb * Planning Yesod 1.4 Domain: yesodweb.com, Score: 32, Comments: 8 Original: [15] http://goo.gl/7Kul02 On Reddit: [16] http://goo.gl/erCRmZ * Practical Machines: A simple tutorial for the Machines streaming library Domain: statusfailed.com, Score: 32, Comments: 24 Original: [17] http://goo.gl/bmRQot On Reddit: [18] http://goo.gl/0QSdOL * Anecdotes and Advice on Hiring Junior or Summer/Co-Op Students for Haskell Work Domain: self.haskell, Score: 32, Comments: 29 Original: [19] http://goo.gl/M7NOJO On Reddit: [20] http://goo.gl/M7NOJO * Write your compiler passes in Coq for great good! Domain: megacz.com, Score: 30, Comments: 13 Original: [21] http://goo.gl/l7MU6n On Reddit: [22] http://goo.gl/oSqi3Z * IntelliJ IDEA haskell-idea-plugin + Hasklig Domain: self.haskell, Score: 28, Comments: 3 Original: [23] http://goo.gl/cNWkLh On Reddit: [24] http://goo.gl/cNWkLh * Upcast, a declarative cloud infrastructure orchestration tool that leverages Nix Domain: github.com, Score: 27, Comments: 12 Original: [25] http://goo.gl/vPpXcn On Reddit: [26] http://goo.gl/MHj0Le * Ray Marching Distance Fields with Haskell and GLSL Domain: github.com, Score: 27, Comments: 13 Original: [27] http://goo.gl/HZSjFq On Reddit: [28] http://goo.gl/w0IZ0w * A Pretty-Printer that Says What It Means (or, Why Idris's Pretty-Printer is a Functor) Domain: davidchristiansen.dk, Score: 25, Comments: 14 Original: [29] http://goo.gl/vfdISz On Reddit: [30] http://goo.gl/mHU49x * The Ivory Language is an eDSL for safe systems programming. You can think of Ivory as a safer C, embedded in Haskell. Domain: ivorylang.org, Score: 23, Comments: 3 Original: [31] http://goo.gl/xJJ68c On Reddit: [32] http://goo.gl/RLljxg * Pre-published the slide "Writing NetBSD Sound Drivers in Haskell" for Haskell Symposium 2014. #icfp2014 Domain: slideshare.net, Score: 23, Comments: 4 Original: [33] http://goo.gl/gsENVq On Reddit: [34] http://goo.gl/mWH3zH * Haskell 2014 talk: Reflection without Remorse: Revealing a hidden sequence to speed up monadic reflection Domain: youtube.com, Score: 23, Comments: 8 Original: [35] http://goo.gl/Dffhnx On Reddit: [36] http://goo.gl/UFPUu3 * Wadler's Blog: Howard on Curry-Howard Domain: wadler.blogspot.com, Score: 21, Comments: 0 Original: [37] http://goo.gl/Fz90FG On Reddit: [38] http://goo.gl/P5kemv Top StackOverflow Questions * Infinite lazy bitmap votes: 11, answers: 2 Read on SO: [39] http://goo.gl/4zDwFX * Correct terminology for continuations votes: 11, answers: 4 Read on SO: [40] http://goo.gl/QHVRWI * How do I make MonadRandom a Functor? votes: 9, answers: 1 Read on SO: [41] http://goo.gl/vvD7bR * Why does Haskell's foldr NOT stackoverflow while the same Scala implementation does? votes: 9, answers: 4 Read on SO: [42] http://goo.gl/zdxgAM Until next time, [43]+Daniel Santa Cruz References 1. http://standardmarkdown.com/ 2. http://www.reddit.com/r/haskell/comments/2fgtuu/pandoc_author_working_with_industry_on_markdown/ 3. https://www.youtube.com/playlist?list=PL4UWOFngo5DVBqifWX6ZlXJ7idxWaOP69 4. http://www.reddit.com/r/haskell/comments/2f8o3x/icfp_2014_talks/ 5. http://www.youtube.com/playlist?list=PL4UWOFngo5DXuUiMCNumrFhaDfMx54QgV 6. http://www.reddit.com/r/haskell/comments/2f60hd/icfp_2014_workshops_videos/ 7. http://hrothen.github.io/2014/09/05/lets-build-a-browser-engine-in-haskell/ 8. http://www.reddit.com/r/haskell/comments/2flosm/lets_build_a_browser_engine_in_haskell/ 9. http://blog.ezyang.com/2014/09/open-type-families-are-not-modular/ 10. http://www.reddit.com/r/haskell/comments/2fi4zc/open_type_families_are_not_modular/ 11. http://haskell-web.blogspot.com.es/2014/09/ide-for-haste-projects.html 12. http://www.reddit.com/r/haskell/comments/2fk91p/ide_for_haste_projects/ 13. https://github.com/sjoerdvisscher/blog/blob/master/2014/2014-09-03%20real%20world%20one-liner%20examples.md 14. http://www.reddit.com/r/haskell/comments/2feen3/real_world_oneliner_examples/ 15. http://www.yesodweb.com/blog/2014/09/planning-yesod-1-4 16. http://www.reddit.com/r/haskell/comments/2f4kym/planning_yesod_14/ 17. http://statusfailed.com/blog/2014/09/02/practical-machines-in-60-seconds.html 18. http://www.reddit.com/r/haskell/comments/2fao00/practical_machines_a_simple_tutorial_for_the/ 19. http://www.reddit.com/r/haskell/comments/2fj0v5/anecdotes_and_advice_on_hiring_junior_or/ 20. http://www.reddit.com/r/haskell/comments/2fj0v5/anecdotes_and_advice_on_hiring_junior_or/ 21. http://www.megacz.com/berkeley/coq-in-ghc/ 22. http://www.reddit.com/r/haskell/comments/2f8bu9/write_your_compiler_passes_in_coq_for_great_good/ 23. http://www.reddit.com/r/haskell/comments/2fb1j5/intellij_idea_haskellideaplugin_hasklig/ 24. http://www.reddit.com/r/haskell/comments/2fb1j5/intellij_idea_haskellideaplugin_hasklig/ 25. https://github.com/zalora/upcast 26. http://www.reddit.com/r/haskell/comments/2f2meq/upcast_a_declarative_cloud_infrastructure/ 27. https://github.com/blitzcode/ray-marching-distance-fields 28. http://www.reddit.com/r/haskell/comments/2ffmys/ray_marching_distance_fields_with_haskell_and_glsl/ 29. http://www.davidchristiansen.dk/2014/09/06/pretty-printing-idris/ 30. http://www.reddit.com/r/haskell/comments/2fntec/a_prettyprinter_that_says_what_it_means_or_why/ 31. http://ivorylang.org/ 32. http://www.reddit.com/r/haskell/comments/2f6p2h/the_ivory_language_is_an_edsl_for_safe_systems/ 33. http://www.slideshare.net/master_q/writing-netbsd-sound-drivers-in-haskell 34. http://www.reddit.com/r/haskell/comments/2fd02w/prepublished_the_slide_writing_netbsd_sound/ 35. https://www.youtube.com/watch?v=_XoI65Rxmss&index=31&list=UUP9g4dLR7xt6KzCYntNqYcw 36. http://www.reddit.com/r/haskell/comments/2fnj6p/haskell_2014_talk_reflection_without_remorse/ 37. http://wadler.blogspot.com/2014/08/howard-on-curry-howard.html 38. http://www.reddit.com/r/haskell/comments/2f9v8e/wadlers_blog_howard_on_curryhoward/ 39. http://stackoverflow.com/questions/25621889/infinite-lazy-bitmap 40. http://stackoverflow.com/questions/25648332/correct-terminology-for-continuations 41. http://stackoverflow.com/questions/25622571/how-do-i-make-monadrandom-a-functor 42. http://stackoverflow.com/questions/25622959/why-does-haskells-foldr-not-stackoverflow-while-the-same-scala-implementation-d 43. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From tifonzafel at gmail.com Thu Sep 11 03:50:45 2014 From: tifonzafel at gmail.com (felipe zapata) Date: Wed, 10 Sep 2014 23:50:45 -0400 Subject: [Haskell-cafe] understanding cloud Haskell serialization Message-ID: Dear Cafe, I'm trying to understand the implementation of Cloud Haskell, specially the closures. According to the documentation, the serialization of a function uses a map from Label to values (RemoteTable), where Remotable is implemented as: newtype RemoteTable = RemoteTable (Map String Dynamic) Where Dynamic is given by, data Dynamic = Dynamic TypeRep GHC.Any The question is then, How does this Dynamic data type encodes functions? And how is related this Dynamic type to the decoder function? closure :: Static (ByteString -> a) -- Decoder -> ByteString -- Encoded closure environment -> Closure a Static provides two function, one function related to the label to lookup at the RemoteTable and one used for composition. But how is this related to Dynamic? Any guide will be appreciated. Felipe Z. -------------- next part -------------- An HTML attachment was scrubbed... URL: From awick at galois.com Thu Sep 11 04:52:29 2014 From: awick at galois.com (Adam Wick) Date: Wed, 10 Sep 2014 21:52:29 -0700 Subject: [Haskell-cafe] HaLVM Talk in NYC on Monday Message-ID: Howdy - For those of you in the New York City area, I?ll be giving a talk this coming Monday, the 15th, on Galois?s use of the HaLVM ? the Haskell Lightweight Virtual Machine ? over the last many years. The talk ("Unikernels: Who, What, Where, When, Why") will be part of the Xen User Summit at the Lighthouse Executive Conference Center: http://events.linuxfoundation.org/events/xen-project-user-summit/program/schedule I believe you can get 50% off using the offer code ?XenUser50off?. The talk will mostly about the general concept of unikernels like the HaLVM, and how we?ve used them well (and poorly!) on various projects, and so will be light on technical details. But if you?d like to chat with me about any aspect of the HaLVM, stop on by, and we can talk functional languages at a system?s conference. It?ll be great. - Adam From ok at cs.otago.ac.nz Thu Sep 11 05:17:58 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 11 Sep 2014 17:17:58 +1200 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: <20140911005100.GB26544@tensor> References: <20140911000124.GA26544@tensor> <20140911005100.GB26544@tensor> Message-ID: <42F4874C-0DAD-4707-89B1-6BE08156B694@cs.otago.ac.nz> This is a fool rushing in where angels fear to tread, but having Nothing or Maybe v where v is in an additive group reminds me a bit of Grassman Algebra and makes me wonder if Maybe is really what's wanted here. From hesselink at gmail.com Thu Sep 11 07:35:20 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 11 Sep 2014 09:35:20 +0200 Subject: [Haskell-cafe] Cabal doesn't reset the search-path when invoking GHC: potential subtleties In-Reply-To: References: Message-ID: I think the solution to this problem usually is to have a separate source directory for each component of your package (library, executable, test suite, etc). For example, put the library in 'src', and the executable in 'exe'. This way source files won't mix, and the executable can depend on the library in the same package, so that source files are only compiled once. I don't think a solution with all files in a single directory is possible in general, since the executable might also need more source files not included in the library. Erik On Wed, Sep 10, 2014 at 11:35 PM, Phil Ruffwind wrote: > It seems that even when invoked via Cabal, GHC will look in the local > directory *first* and then in the list of modules and dependencies supplied by > Cabal. I was aware of this behavior subconsciously but I hadn't realized the > implications until now. > > Normally, it's not a big problem, other than for the occasional situation > where I forget to add those local modules to 'other-modules'. This would > cause 'cabal sdist' to generate an incomplete package, even though 'cabal > build && cabal install' works just fine! > > But there are more subtle "bugs": it breaks if the executable and library > share the same directory, but the library has some hidden modules stashed away > in a different directory! The conditions required to reproduce this is > somewhat difficult to explain, so let me show a simple example: > > 1. Make a Cabal package: > > -- ./foo.cabal > name: foo > version: 0.0.0.0 > build-type: Simple > cabal-version: >=1.8 > library > exposed-modules: Exposed > other-modules: Hidden > build-depends: base > hs-source-dirs: ., hidden > executable main > main-is: Main.hs > build-depends: base, foo > > 2. Add a library with two modules at the given paths: > > -- ./Exposed.hs > module Exposed where > import Hidden > > -- ./hidden/Hidden.hs > module Hidden where > > 3. Add an executable: > > -- ./Main.hs > module Main where > import Exposed > main = return () > > 4. Now run `cabal build`. This would cause an error message akin to: > > > Could not find module Hidden > > The problem is that despite the dependency on the library `foo` being > specified in Cabal, GHC still chose the *local* `Exposed` module over the > `Exposed` module in the library `foo`. This means when it tries to recompile > the `Exposed` module, it is unaware that `Hidden` is located in another > directory. > > The error message is unhelpful because it doesn't point to the actual cause of > the problem and led me astray thinking that something was wrong with my Cabal > configuration. > > In the end, the problem has to do with GHC deciding to look up packages in > locations outside Cabal's control. There are many other ways to trigger this > problem -- the above was only one that I just happened to run into. > > For now, a workaround would be to use `-i` with all the executables to avoid > this subtle issue in the future. > > RF > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From magnus at therning.org Thu Sep 11 07:59:16 2014 From: magnus at therning.org (Magnus Therning) Date: Thu, 11 Sep 2014 09:59:16 +0200 Subject: [Haskell-cafe] HaLVM Talk in NYC on Monday In-Reply-To: References: Message-ID: <20140911075916.GB4542@mtcomp.evidente.local> On Wed, Sep 10, 2014 at 09:52:29PM -0700, Adam Wick wrote: > Howdy - > > For those of you in the New York City area, I?ll be giving a talk > this coming Monday, the 15th, on Galois?s use of the HaLVM ? the > Haskell Lightweight Virtual Machine ? over the last many years. The > talk ("Unikernels: Who, What, Where, When, Why") will be part of the > Xen User Summit at the Lighthouse Executive Conference Center: > > http://events.linuxfoundation.org/events/xen-project-user-summit/program/schedule > > I believe you can get 50% off using the offer code ?XenUser50off?. > > The talk will mostly about the general concept of unikernels like > the HaLVM, and how we?ve used them well (and poorly!) on various > projects, and so will be light on technical details. But if you?d > like to chat with me about any aspect of the HaLVM, stop on by, and > we can talk functional languages at a system?s conference. It?ll be > great. Please let us know if a video is posted somewhere afterwards. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus What gets measured, gets done. -- Tom Peters -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From agocorona at gmail.com Thu Sep 11 08:36:30 2014 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu, 11 Sep 2014 10:36:30 +0200 Subject: [Haskell-cafe] understanding cloud Haskell serialization In-Reply-To: References: Message-ID: Hi Felipe: plainly speaking, it stores and send a pointer, it is not necessary to serialize the code. It just send the pointer, since all the copies of the program are the same in all the nodes. The code to be called is at the same address in the other node. That is the reason why the closures must be in a static address. 2014-09-11 5:50 GMT+02:00 felipe zapata : > Dear Cafe, > I'm trying to understand the implementation of Cloud Haskell, specially > the closures. According to the documentation, the serialization of a > function uses a map from Label to values (RemoteTable), where Remotable is > implemented as: > > newtype RemoteTable = RemoteTable (Map String Dynamic) > > Where Dynamic is given by, > > data Dynamic = Dynamic TypeRep GHC.Any > > The question is then, How does this Dynamic data type encodes functions? > And how is related this Dynamic type to the decoder function? > > closure :: Static (ByteString -> a) -- Decoder > -> ByteString -- Encoded closure environment > -> Closure a > > Static provides two function, one function related to the label to lookup > at the RemoteTable and one used for composition. But how is this related > to Dynamic? > > Any guide will be appreciated. > > Felipe Z. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From han.joosten.han at gmail.com Thu Sep 11 11:57:48 2014 From: han.joosten.han at gmail.com (Han Joosten) Date: Thu, 11 Sep 2014 04:57:48 -0700 (PDT) Subject: [Haskell-cafe] XML <--> Haskell Data Structure using HXT Message-ID: <2ecb0934-848a-46e6-a745-5989ceb0694d@googlegroups.com> I would like to write code to enable importing data to and fro from a Haskell data structure. It makes sense to have some XSD or so that specifies how the XML should be structured. The HDS is already in place. I have been looking into hte HXT library and I think it could be used for this job. However, I am not familiar (yet) with Arrows and the like. Also the use of picklers is new to me. It would help me a lot if someone has a neat example of how coversion between XML and some Haskell data structure can be implemented in het HXT-style. Do such examples exist? Where can I find them? For those interested: Here is the Haskell Data Structure: https://sourceforge.net/p/ampersand/code/HEAD/tree/trunk/src/lib/Database/Design/Ampersand/Core/ParseTree.hs Cheers & Thanks for reading! Han Joosten -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Thu Sep 11 12:14:27 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 11 Sep 2014 14:14:27 +0200 Subject: [Haskell-cafe] XML <--> Haskell Data Structure using HXT In-Reply-To: <2ecb0934-848a-46e6-a745-5989ceb0694d@googlegroups.com> References: <2ecb0934-848a-46e6-a745-5989ceb0694d@googlegroups.com> Message-ID: We use HXT's picklers, and have written a blog post about it [1]. I just saw that the code isn't formatted that great on our new blog, I'll see if we can fix that. We also wrote a library [2] for generically deriving instances for picklers, which we also blogged about [3]. I hope that helps! Regards, Erik [1] http://engineering.silk.co/post/31921413529/haskell-data-types-and-xml [2] http://hackage.haskell.org/package/regular-xmlpickler [3] http://engineering.silk.co/post/31922245822/writing-a-generic-xml-pickler On Thu, Sep 11, 2014 at 1:57 PM, Han Joosten wrote: > I would like to write code to enable importing data to and fro from a > Haskell data structure. It makes sense to have some XSD or so that specifies > how the XML should be structured. The HDS is already in place. I have been > looking into hte HXT library and I think it could be used for this job. > However, I am not familiar (yet) with Arrows and the like. Also the use of > picklers is new to me. It would help me a lot if someone has a neat example > of how coversion between XML and some Haskell data structure can be > implemented in het HXT-style. > Do such examples exist? Where can I find them? > > For those interested: Here is the Haskell Data Structure: > https://sourceforge.net/p/ampersand/code/HEAD/tree/trunk/src/lib/Database/Design/Ampersand/Core/ParseTree.hs > > Cheers & Thanks for reading! > > Han Joosten > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dominic at steinitz.org Thu Sep 11 12:58:23 2014 From: dominic at steinitz.org (Dominic Steinitz) Date: Thu, 11 Sep 2014 13:58:23 +0100 Subject: [Haskell-cafe] Mapping over Type Level Literals Message-ID: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> I was playing around with Haar functions and realised I could encode the constraints in the types > > {-# LANGUAGE DataKinds #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE KindSignatures #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE Rank2Types #-} > > {-# LANGUAGE ScopedTypeVariables #-} > > > import GHC.TypeLits > > import Data.Proxy > > > data Haar (a :: Nat) (b :: Nat) = Haar { unHaar :: Double -> Double } > > > haar :: forall n k . > > (KnownNat n, KnownNat k, (2 * k - 1 <=? 2^n - 1) ~ 'True) => > > Haar n (2 * k - 1) > > haar = Haar g where > > g t | (k' - 1) * 2 ** (-n') < t && t <= k' * 2 ** (-n') = 2 ** ((n' - 1) / 2) > > | k' * 2 ** (-n') < t && t <= (k' + 1) * 2 ** (-n') = -2 ** ((n' - 1) / 2) > > | otherwise = 0 > > where > > n' = fromIntegral (natVal (Proxy :: Proxy n)) > > k' = 2 * (fromIntegral (natVal (Proxy :: Proxy k))) - 1 So now I can do e.g. > *Main> unHaar (haar :: Haar 3 7) 0.05 > 0.0 > *Main> unHaar (haar :: Haar 3 6) 0.05 > > :359:9: > Couldn't match type ?2 * k0? with ?7? > The type variable ?k0? is ambiguous > Expected type: 'True > Actual type: ((2 * k0) - 1) <=? ((2 ^ 3) - 1) > In the first argument of ?unHaar?, namely ?(haar :: Haar 3 6)? > In the expression: unHaar (haar :: Haar 3 6) 0.05 > In an equation for ?it?: it = unHaar (haar :: Haar 3 6) 0.05 > *Main> unHaar (haar :: Haar 3 9) 0.05 > > :360:9: > Couldn't match type ?'False? with ?'True? > Expected type: 'True > Actual type: ((2 * 5) - 1) <=? ((2 ^ 3) - 1) > In the first argument of ?unHaar?, namely ?(haar :: Haar 3 9)? > In the expression: unHaar (haar :: Haar 3 9) 0.05 > In an equation for ?it?: it = unHaar (haar :: Haar 3 9) 0.05 > *Main> So errors get rejected at compilation time as one would like and with moderately informative error messages. But now of course I would like to map over n and k but these are at the type level. Can this be done? I imagine unsafeCoerce would have to come into it somewhere. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From han.joosten.han at gmail.com Thu Sep 11 13:38:18 2014 From: han.joosten.han at gmail.com (Han Joosten) Date: Thu, 11 Sep 2014 15:38:18 +0200 Subject: [Haskell-cafe] XML <--> Haskell Data Structure using HXT In-Reply-To: References: <2ecb0934-848a-46e6-a745-5989ceb0694d@googlegroups.com> Message-ID: Thanks a lot for the pointers. They are spot on, and just what I was looking for! 2014-09-11 14:14 GMT+02:00 Erik Hesselink : > We use HXT's picklers, and have written a blog post about it [1]. I > just saw that the code isn't formatted that great on our new blog, > I'll see if we can fix that. We also wrote a library [2] for > generically deriving instances for picklers, which we also blogged > about [3]. I hope that helps! > > Regards, > > Erik > > [1] http://engineering.silk.co/post/31921413529/haskell-data-types-and-xml > [2] http://hackage.haskell.org/package/regular-xmlpickler > [3] > http://engineering.silk.co/post/31922245822/writing-a-generic-xml-pickler > > On Thu, Sep 11, 2014 at 1:57 PM, Han Joosten > wrote: > > I would like to write code to enable importing data to and fro from a > > Haskell data structure. It makes sense to have some XSD or so that > specifies > > how the XML should be structured. The HDS is already in place. I have > been > > looking into hte HXT library and I think it could be used for this job. > > However, I am not familiar (yet) with Arrows and the like. Also the use > of > > picklers is new to me. It would help me a lot if someone has a neat > example > > of how coversion between XML and some Haskell data structure can be > > implemented in het HXT-style. > > Do such examples exist? Where can I find them? > > > > For those interested: Here is the Haskell Data Structure: > > > https://sourceforge.net/p/ampersand/code/HEAD/tree/trunk/src/lib/Database/Design/Ampersand/Core/ParseTree.hs > > > > Cheers & Thanks for reading! > > > > Han Joosten > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Haskell-cafe" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/haskell-cafe/YkePH-LbeSo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > haskell-cafe+unsubscribe at googlegroups.com. > To post to this group, send email to haskell-cafe at googlegroups.com. > Visit this group at http://groups.google.com/group/haskell-cafe. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Thu Sep 11 16:31:35 2014 From: michael at orlitzky.com (Michael Orlitzky) Date: Thu, 11 Sep 2014 12:31:35 -0400 Subject: [Haskell-cafe] XML <--> Haskell Data Structure using HXT In-Reply-To: <2ecb0934-848a-46e6-a745-5989ceb0694d@googlegroups.com> References: <2ecb0934-848a-46e6-a745-5989ceb0694d@googlegroups.com> Message-ID: <5411CE67.9000400@orlitzky.com> On 09/11/2014 07:57 AM, Han Joosten wrote: > I would like to write code to enable importing data to and fro from a > Haskell data structure. It makes sense to have some XSD or so that > specifies how the XML should be structured. The HDS is already in place. > I have been looking into hte HXT library and I think it could be used > for this job. However, I am not familiar (yet) with Arrows and the like. > Also the use of picklers is new to me. It would help me a lot if someone > has a neat example of how coversion between XML and some Haskell data > structure can be implemented in het HXT-style. > Do such examples exist? Where can I find them? I use these extensively in, http://hackage.haskell.org/package/htsn-import Each module under the TSN.XML namespace is basically a big XML <-> Haskell converter along with some database stuff. From k at ioctl.it Thu Sep 11 16:49:28 2014 From: k at ioctl.it (Karsten Gebbert) Date: Thu, 11 Sep 2014 18:49:28 +0200 Subject: [Haskell-cafe] api-tools questions In-Reply-To: <540F0BCF.8040004@well-typed.com> References: <86ppf5gd66.fsf@fook.fritz.box> <540F0BCF.8040004@well-typed.com> Message-ID: <86bnqmhzl3.fsf@fook.fritz.box> Hi Adam, somehow I can't get it to work according to yours and Chris' examples. I have the following test-case: ----- stamp :: TimeStamp = basic string with inj_TimeStamp, prj_TimeStamp test :: TestRec = record created_at :: TimeStamp ----- $(generate tests) -- created_at parses with: -- parseTime defaultTimeLocale "%Y-%m-%d %H:%M:%S%Q" a type TimeStamp = Maybe UTCTime inj_TimeStamp :: REP__TimeStamp -> ParserWithErrs TimeStamp inj_TimeStamp (REP__TimeStamp as) = return $ parseTime defaultTimeLocale "%Y-%m-%d %H:%M:%S%Q" (Text.unpack as) prj_TimeStamp :: TimeStamp -> REP__TimeStamp prj_TimeStamp (Just mp) = REP__TimeStamp $ Text.pack $ formatTime defaultTimeLocale "%Y-%m-%d %H:%M:%S%Q" mp prj_TimeStamp Nothing = REP__TimeStamp $ Text.pack "" $(generateAPITools tests [enumTool, jsonTool]) But, when I use it like this, I still get the format error: ? import qualified Data.ByteString.Lazy as LBS ? import Mytest.Types ? let a = "{ \"created_at\": \"2014-09-10 14:06:48.13972\" }" :: LBS.ByteString ? decodeWithErrs a :: Either [(JSONError, Position)] TestRec Left [(BadFormat FmtUTC "UTC" "2014-09-10 14:06:48.13972",[InField "created_at"])] It seems its not using the functions provided to parse the result at all, if I put in some bogus stuff the conversion functions and set the type of TimeStamp to Text, the created_at string appears in the output: inj_TimeStamp :: REP__TimeStamp -> ParserWithErrs TimeStamp inj_TimeStamp (REP__TimeStamp _) = return $ Text.pack "heheheheh" prj_TimeStamp :: TimeStamp -> REP__TimeStamp prj_TimeStamp _ = REP__TimeStamp $ Text.pack "Hohoho" ? let a = "{ \"created_at\": \"2014-09-10 14:06:48.13972\" }" :: LBS.ByteString ? decodeWithErrs a :: Either [(JSONError, Position)] TextRec Right (TextRec {_test_created_at = "2014-09-10 14:06:48.13972"}) I'm probably missing something really simple here, but maybe you can spot it quicker than I do.. I'll investigate more when I'm back home anyways. Thanks for any hints! k Adam Gundry writes: > Hi Karsten, > > This isn't very well documented, but there is a (hidden) feature of > api-tools that should do what you want. If you say something like > > mt :: MyTime = basic string with inj_MyTime, prj_MyTime > > then you can define your own type MyTime and give conversion functions > inj_MyTime and prj_MyTime to convert back and forth from a > newtype-wrapped Text. (In fact, you could probably use UTCTime as > MyTime...). More precisely, api-tools will generate something like > > newtype REP__MyTime = REP__MyTime Text > > and you will need to implement > > inj_MyTime :: REP__MyTime -> ParserWithErrs MyTime > prj_MyTime :: MyTime -> REP__MyTime > > I hope this helps, and further questions or documentation contributions > are very welcome! > > Cheers, > > Adam > > > On 09/09/14 14:02, Karsten Gebbert wrote: >> Hi All, >> >> I have a question concerning the api-tools package. >> >> Its not clear from the tests, sources or the tutorial how I can use >> other date/time formats that the default `utc` type can handle. I'm >> trying to wrap a JSON API that is not under my control, so I have to >> adhere to whatever I get back from it. Could anybody with experience >> with the package point me to some example, relevant bits in the sources >> or a tip how to do it? >> >> I'm planning to create some more documentation around the package to >> contribute back once I figured out a few more details, because I think >> its quite a useful abstraction when dealing with (foreign) APIs IMO. >> >> Thanks already for any hints, >> >> karsten > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Thu Sep 11 20:43:58 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 11 Sep 2014 16:43:58 -0400 Subject: [Haskell-cafe] Mapping over Type Level Literals In-Reply-To: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> References: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> Message-ID: <0A3EF0FF-FF82-4E0E-BCFF-54616D0E5090@cis.upenn.edu> On Sep 11, 2014, at 8:58 AM, Dominic Steinitz wrote: > > But now of course I would like to map over n and k but these are at the type level. Can this be done? I imagine unsafeCoerce would have to come into it somewhere. Mapping at the type level is probably possible, but I don't see exactly what you mean -- there aren't any lists around to map with. If you make the example a little more concrete, I may be able to help. Richard From dominic at steinitz.org Thu Sep 11 21:53:02 2014 From: dominic at steinitz.org (Dominic Steinitz) Date: Thu, 11 Sep 2014 22:53:02 +0100 Subject: [Haskell-cafe] Mapping over Type Level Literals In-Reply-To: <0A3EF0FF-FF82-4E0E-BCFF-54616D0E5090@cis.upenn.edu> References: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> <0A3EF0FF-FF82-4E0E-BCFF-54616D0E5090@cis.upenn.edu> Message-ID: If I were not using type literals then I would do something like this but then errors would occur at runtime. > > haarEtouffe :: Int -> Int -> Double -> Double > > haarEtouffe n k t > > | n <= 0 = error "n must be >= 1" > > | k `mod`2 == 0 = error "k must be odd" > > | k < 0 || k > 2^n - 1 = error "k must be >=0 and <= 2^n -1" > > | (k' - 1) * 2 ** (-n') < t && t <= k' * 2 ** (-n') = 2 ** ((n' - 1) / 2) > > | k' * 2 ** (-n') < t && t <= (k' + 1) * 2 ** (-n') = -2 ** ((n' - 1) / 2) > > | otherwise = 0 > > where > > k' = fromIntegral k > > n' = fromIntegral n > > > n :: Int > > n = 100 > > > xss :: [[(Double, Double)]] > > xss = map (\(m, k) -> map (\i -> let x = fromIntegral i / fromIntegral n in (x, haarEtouffe m k x)) [0..n - 1]) [(1,1), (2,1), (2,3), (3,1), (3,3), (3,5), (3,7)] Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com On 11 Sep 2014, at 21:43, Richard Eisenberg wrote: > > On Sep 11, 2014, at 8:58 AM, Dominic Steinitz wrote: >> >> But now of course I would like to map over n and k but these are at the type level. Can this be done? I imagine unsafeCoerce would have to come into it somewhere. > > Mapping at the type level is probably possible, but I don't see exactly what you mean -- there aren't any lists around to map with. If you make the example a little more concrete, I may be able to help. > > Richard From k at ioctl.it Fri Sep 12 08:54:08 2014 From: k at ioctl.it (Karsten Gebbert) Date: Fri, 12 Sep 2014 10:54:08 +0200 Subject: [Haskell-cafe] api-tools questions In-Reply-To: <86bnqmhzl3.fsf@fook.fritz.box> References: <86ppf5gd66.fsf@fook.fritz.box> <540F0BCF.8040004@well-typed.com> <86bnqmhzl3.fsf@fook.fritz.box> Message-ID: <868ulpi5hr.fsf@fook.fritz.box> Hi, I managed to my example working by using a record type to convert from/to (similar to the examples in your library Chris). Yay! I am still not sure why it didn't work when I used newtype/type to serialize to/from. Thanks for your help anyways :) k Karsten Gebbert writes: > Hi Adam, > > somehow I can't get it to work according to yours and Chris' examples. I > have the following test-case: > > ----- > > stamp :: TimeStamp > = basic string > with inj_TimeStamp, prj_TimeStamp > > test :: TestRec > = record > created_at :: TimeStamp > > ----- > > $(generate tests) > > -- created_at parses with: > -- parseTime defaultTimeLocale "%Y-%m-%d %H:%M:%S%Q" a > > type TimeStamp = Maybe UTCTime > > inj_TimeStamp :: REP__TimeStamp -> ParserWithErrs TimeStamp > inj_TimeStamp (REP__TimeStamp as) = > return $ parseTime defaultTimeLocale "%Y-%m-%d %H:%M:%S%Q" (Text.unpack as) > > prj_TimeStamp :: TimeStamp -> REP__TimeStamp > prj_TimeStamp (Just mp) = REP__TimeStamp $ > Text.pack $ formatTime defaultTimeLocale "%Y-%m-%d %H:%M:%S%Q" mp > prj_TimeStamp Nothing = REP__TimeStamp $ > Text.pack "" > > $(generateAPITools tests [enumTool, jsonTool]) > > > But, when I use it like this, I still get the format error: > > ? import qualified Data.ByteString.Lazy as LBS > ? import Mytest.Types > ? let a = "{ \"created_at\": \"2014-09-10 14:06:48.13972\" }" :: LBS.ByteString > ? decodeWithErrs a :: Either [(JSONError, Position)] TestRec > Left [(BadFormat FmtUTC "UTC" "2014-09-10 14:06:48.13972",[InField "created_at"])] > > It seems its not using the functions provided to parse the result at > all, if I put in some bogus stuff the conversion functions and set the > type of TimeStamp to Text, the created_at string appears in the output: > > inj_TimeStamp :: REP__TimeStamp -> ParserWithErrs TimeStamp > inj_TimeStamp (REP__TimeStamp _) = > return $ Text.pack "heheheheh" > > prj_TimeStamp :: TimeStamp -> REP__TimeStamp > prj_TimeStamp _ = REP__TimeStamp $ Text.pack "Hohoho" > > ? let a = "{ \"created_at\": \"2014-09-10 14:06:48.13972\" }" :: LBS.ByteString > ? decodeWithErrs a :: Either [(JSONError, Position)] TextRec > Right (TextRec {_test_created_at = "2014-09-10 14:06:48.13972"}) > > I'm probably missing something really simple here, but maybe you can > spot it quicker than I do.. I'll investigate more when I'm back home > anyways. > > Thanks for any hints! > > k > > Adam Gundry writes: > >> Hi Karsten, >> >> This isn't very well documented, but there is a (hidden) feature of >> api-tools that should do what you want. If you say something like >> >> mt :: MyTime = basic string with inj_MyTime, prj_MyTime >> >> then you can define your own type MyTime and give conversion functions >> inj_MyTime and prj_MyTime to convert back and forth from a >> newtype-wrapped Text. (In fact, you could probably use UTCTime as >> MyTime...). More precisely, api-tools will generate something like >> >> newtype REP__MyTime = REP__MyTime Text >> >> and you will need to implement >> >> inj_MyTime :: REP__MyTime -> ParserWithErrs MyTime >> prj_MyTime :: MyTime -> REP__MyTime >> >> I hope this helps, and further questions or documentation contributions >> are very welcome! >> >> Cheers, >> >> Adam >> >> >> On 09/09/14 14:02, Karsten Gebbert wrote: >>> Hi All, >>> >>> I have a question concerning the api-tools package. >>> >>> Its not clear from the tests, sources or the tutorial how I can use >>> other date/time formats that the default `utc` type can handle. I'm >>> trying to wrap a JSON API that is not under my control, so I have to >>> adhere to whatever I get back from it. Could anybody with experience >>> with the package point me to some example, relevant bits in the sources >>> or a tip how to do it? >>> >>> I'm planning to create some more documentation around the package to >>> contribute back once I figured out a few more details, because I think >>> its quite a useful abstraction when dealing with (foreign) APIs IMO. >>> >>> Thanks already for any hints, >>> >>> karsten >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From marcin.jan.mrotek at gmail.com Fri Sep 12 15:13:44 2014 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Fri, 12 Sep 2014 17:13:44 +0200 Subject: [Haskell-cafe] Mapping over Type Level Literals In-Reply-To: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> References: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> Message-ID: (sorry, I think I wrote this to Dominic only originally) You mean something like this: http://hub.darcs.net/mjm/type-list/browse/src/Data/Type/List.hs ? I'll push this library to Hackage in a moment. Regards, Marcin From maximum.yellow at gmail.com Fri Sep 12 20:56:44 2014 From: maximum.yellow at gmail.com (Tslil Clingman) Date: Fri, 12 Sep 2014 22:56:44 +0200 Subject: [Haskell-cafe] Hello and type-level SKI Message-ID: <871trgmub7.fsf@gmail.com> Greetings all, I've been reading this list for a short while and I thought I'd like to begin to contribute where possible. This message pretty much serves to say: - Hello, Haskell! - This community is great, and it's always been a great pleasure to read the newsgroup(s) - Here is a small and likely multiply re-re-discovered `proof' of why the type system is Turing Complete > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, > FlexibleInstances, FlexibleContexts, UndecidableInstances #-} > data S2 x y > data S1 x > data S > data K1 x > data K > data I > class Apply a b c | a b -> c > instance Apply K x (K1 x) > instance Apply S x (S1 x) > instance Apply (S1 x) y (S2 x y) > instance Apply I x x > instance Apply (K1 x) y x > instance (Apply x z xz, Apply y z yz, Apply xz yz a) => Apply (S2 x y) z a > -- The core function > apply :: (Apply a b c) => a -> b -> c > apply _ _ = undefined > -- Hereendeththelesson -- > -- For `ease of use', but not strictly necessary > data X > data Y > data Z > s = undefined :: S > k = undefined :: K > i = undefined :: I > x = undefined :: X > y = undefined :: Y > z = undefined :: Z > -- Example > reverse = apply (apply s (apply k (apply s i))) k I just thought I'd share this snippet here, but if this is not the right place, or it's too long or something please don't hesitate to let me know. Thanks for your attention, Yours &c., Tslil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From jays at panix.com Fri Sep 12 23:25:07 2014 From: jays at panix.com (Jay Sulzberger) Date: Fri, 12 Sep 2014 19:25:07 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: <871trgmub7.fsf@gmail.com> References: <871trgmub7.fsf@gmail.com> Message-ID: On Fri, 12 Sep 2014, Tslil Clingman wrote: > Greetings all, > > I've been reading this list for a short while and I thought I'd like to > begin to contribute where possible. This message pretty much serves to > say: > > - Hello, Haskell! > - This community is great, and it's always been a great pleasure to read > the newsgroup(s) > - Here is a small and likely multiply re-re-discovered `proof' of why the type > system is Turing Complete > >> {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, >> FlexibleInstances, FlexibleContexts, UndecidableInstances #-} > >> data S2 x y >> data S1 x >> data S >> data K1 x >> data K >> data I > >> class Apply a b c | a b -> c >> instance Apply K x (K1 x) >> instance Apply S x (S1 x) >> instance Apply (S1 x) y (S2 x y) >> instance Apply I x x >> instance Apply (K1 x) y x >> instance (Apply x z xz, Apply y z yz, Apply xz yz a) => Apply (S2 x y) z a > >> -- The core function >> apply :: (Apply a b c) => a -> b -> c >> apply _ _ = undefined >> -- Hereendeththelesson -- > >> -- For `ease of use', but not strictly necessary >> data X >> data Y >> data Z >> s = undefined :: S >> k = undefined :: K >> i = undefined :: I >> x = undefined :: X >> y = undefined :: Y >> z = undefined :: Z >> -- Example >> reverse = apply (apply s (apply k (apply s i))) k > > I just thought I'd share this snippet here, but if this is not the right > place, or it's too long or something please don't hesitate to let me know. > > Thanks for your attention, > Yours &c., > Tslil But this is impossible! The type system of Haskell can be handled by a Hindley-Milner-Damas style type checker. Such a type checker always comes to a halt with a Yea or Nay answer. So one cannot get a simulation of the combinators S, K, I inside the Haskell type system. What have I misunderstood? And, in case GHC really does now handle stuff beyond the HMD horizon, what does the New Core language look like? oo--JS. From allbery.b at gmail.com Fri Sep 12 23:30:06 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 12 Sep 2014 19:30:06 -0400 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: > But this is impossible! The type system of Haskell can be > handled by a Hindley-Milner-Damas style type checker. Such a > type checker always comes to a halt with a Yea or Nay answer. So > one cannot get a simulation of the combinators S, K, I inside the > Haskell type system. > > What have I misunderstood? And, in case GHC really does now > handle stuff beyond the HMD horizon, what does the New Core > language look like? > Standard Haskell is (or was) H-M extended with typeclasses. GHC moved beyond that years ago; internally it's System Fw ( http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core language reflects this. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Fri Sep 12 23:46:20 2014 From: tikhon at jelv.is (Tikhon Jelvis) Date: Fri, 12 Sep 2014 16:46:20 -0700 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: Note how the provided code enables a bunch of language extensions, most notably UndecidableInstances. (Yep, that's exactly what it sounds like!) It's quite far removed from standard Haskell or full type inference. On Sep 12, 2014 4:30 PM, "Brandon Allbery" wrote: > On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: > >> But this is impossible! The type system of Haskell can be >> handled by a Hindley-Milner-Damas style type checker. Such a >> type checker always comes to a halt with a Yea or Nay answer. So >> one cannot get a simulation of the combinators S, K, I inside the >> Haskell type system. >> >> What have I misunderstood? And, in case GHC really does now >> handle stuff beyond the HMD horizon, what does the New Core >> language look like? >> > > Standard Haskell is (or was) H-M extended with typeclasses. GHC moved > beyond that years ago; internally it's System Fw ( > http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core > language reflects this. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sat Sep 13 03:28:53 2014 From: gershomb at gmail.com (Gershom B) Date: Fri, 12 Sep 2014 23:28:53 -0400 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: On September 12, 2014 at 7:30:28 PM, Brandon Allbery (allbery.b at gmail.com) wrote: > On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: > > > > > What have I misunderstood? And, in case GHC really does now > > handle stuff beyond the HMD horizon, what does the New Core > > language look like? > > > > Standard Haskell is (or was) H-M extended with typeclasses. GHC moved > beyond that years ago; internally it's System Fw ( > http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core > language reflects this. It has now moved beyond that too and is system FC (https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/FC) which adds equality constraints and coercions. Also note that, as I understand it, typeclass constraints are dealt with in the typechecker, before core is generated. So if you use a terrible combination of features and instances and produce something at the type level that loops, then the typechecker just doesn?t terminate (well, it actually runs out of context stack typically?). You can find more details in the commentary (https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HscMain) which now looks way clearer than last time I checked. -g From jays at panix.com Sat Sep 13 04:02:38 2014 From: jays at panix.com (Jay Sulzberger) Date: Sat, 13 Sep 2014 00:02:38 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: On Fri, 12 Sep 2014, Gershom B wrote: > > On September 12, 2014 at 7:30:28 PM, Brandon Allbery (allbery.b at gmail.com) wrote: > > On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: > > > > > > > > What have I misunderstood? And, in case GHC really does now > > > handle stuff beyond the HMD horizon, what does the New Core > > > language look like? > > > > > > > Standard Haskell is (or was) H-M extended with typeclasses. GHC moved > > beyond that years ago; internally it's System Fw ( > > http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core > > language reflects this. > > It has now moved beyond that too and is system FC > (https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/FC) > which adds equality constraints and coercions. > > Also note that, as I understand it, typeclass constraints are > dealt with in the typechecker, before core is generated. So if > you use a terrible combination of features and instances and > produce something at the type level that loops, then the > typechecker just doesn???t terminate (well, it actually runs out > of context stack typically???). You can find more details in the > commentary > (https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HscMain) > which now looks way clearer than last time I checked. > > -g Thanks, Gershom! I just glanced at the page. I know that GHC is a serious compiler, but just the high level flow diagram impresses. The compiler deals with stuff more logically complex than the usual presentations of System FC deal with, such as "strictness". To think that sometimes it runs without dumping core, and even, I believe this part of Haskell propaganda, often produces correct programs, ah, well, I say MORE FUNDING and don't worry about success. oo--JS. PS. I just looked at https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CoreSynType I am reassured. From jays at panix.com Sat Sep 13 04:06:09 2014 From: jays at panix.com (Jay Sulzberger) Date: Sat, 13 Sep 2014 00:06:09 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: On Fri, 12 Sep 2014, Brandon Allbery wrote: > On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: > >> But this is impossible! The type system of Haskell can be >> handled by a Hindley-Milner-Damas style type checker. Such a >> type checker always comes to a halt with a Yea or Nay answer. So >> one cannot get a simulation of the combinators S, K, I inside the >> Haskell type system. >> >> What have I misunderstood? And, in case GHC really does now >> handle stuff beyond the HMD horizon, what does the New Core >> language look like? >> > > Standard Haskell is (or was) H-M extended with typeclasses. GHC moved > beyond that years ago; internally it's System Fw ( > http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core > language reflects this. Thanks, Brandon! OK, so the way one simulates, ridiculous word, a Turing machine is to write code for a function in Haskell. The (simulation of) running of the Turing machine, if I understand correctly, is Haskell's attempt to calculate a type for the function. Specifically, the type inferencer's attempt. I will look at the implementation of S, K, and I, and try to figure out how this works. oo--JS. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > From corentin.dupont at gmail.com Sat Sep 13 10:41:30 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Sat, 13 Sep 2014 12:41:30 +0200 Subject: [Haskell-cafe] policy for new packages Message-ID: Hi guys, In my software I developped some piece of code that I think are sufficiently generic to be useful for others (some datatypes and typeclasses). Should I put them in a separate package and annonce them? What is the best pratice here? Namely it's a datatype called Data.Todo allowing to keep track of actions left to do to complete a computation, and the other is a typeclass called Control.Shortcut designed for computations that can be run in parralel and shortcuted if necessary. So they are small (but useful) things, I'm wondering if creating one package for each is worth it, or another policy can apply. Cheers, Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tslil.clingman at gmail.com Sat Sep 13 10:43:10 2014 From: tslil.clingman at gmail.com (Tslil Clingman) Date: Sat, 13 Sep 2014 12:43:10 +0200 Subject: [Haskell-cafe] Hello and type-level SKI References: <871trgmub7.fsf@gmail.com> Message-ID: <87y4tnyf5t.fsf@gmail.com> Right, so to be fair a more accurate description would have been: `It can be shown that GHC with numerous extensions gives rise to a type system which is Turing Complete', my mistake. I certainly didn't mean to mislead anyone. All too often I conflate Haskell (2010 or so) and the capabilities of GHC -- this is a trap which ensnares many, I suspect. -- Yours &c., Tslil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From trevor.j.cook at gmail.com Sat Sep 13 18:12:48 2014 From: trevor.j.cook at gmail.com (trevor cook) Date: Sat, 13 Sep 2014 14:12:48 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) Message-ID: Jason, John, Thanks for the in depth descriptions, it was just what I was looking for. Trevor -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Sat Sep 13 19:10:27 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 13 Sep 2014 20:10:27 +0100 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: References: Message-ID: <541496A3.2070103@fuuzetsu.co.uk> On 09/13/2014 07:12 PM, trevor cook wrote: > Jason, John, > > Thanks for the in depth descriptions, it was just what I was looking for. > > Trevor > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Hi, Please set up your client to reply to threads properly or it makes it very difficult for others to follow. -- Mateusz K. From byorgey at gmail.com Sat Sep 13 19:56:32 2014 From: byorgey at gmail.com (Brent Yorgey) Date: Sat, 13 Sep 2014 15:56:32 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: <541496A3.2070103@fuuzetsu.co.uk> References: <541496A3.2070103@fuuzetsu.co.uk> Message-ID: Hi Mateusz, Can you please explain what you mean by "properly"? -Brent On Sat, Sep 13, 2014 at 3:10 PM, Mateusz Kowalczyk wrote: > On 09/13/2014 07:12 PM, trevor cook wrote: > > Jason, John, > > > > Thanks for the in depth descriptions, it was just what I was looking for. > > > > Trevor > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > Hi, > > Please set up your client to reply to threads properly or it makes it > very difficult for others to follow. > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Sep 13 21:00:31 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 13 Sep 2014 22:00:31 +0100 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: References: <541496A3.2070103@fuuzetsu.co.uk> Message-ID: <20140913210031.GG14961@weber> On Sat, Sep 13, 2014 at 03:56:32PM -0400, Brent Yorgey wrote: > Hi Mateusz, > > Can you please explain what you mean by "properly"? I'm not Mateusz, but from my point of view setting the "References:" and "In-Reply-To:" headers would be helpful, as would be quoting the message that is being replied to. Tom From roma at ro-che.info Sat Sep 13 22:09:03 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 14 Sep 2014 01:09:03 +0300 Subject: [Haskell-cafe] ANN: haskell-src-exts-1.16.0 Message-ID: <1410646143.682.5.camel@sniper.lan> I am pleased to announce the release of haskell-src-exts-1.16.0! Hackage: https://hackage.haskell.org/package/haskell-src-exts-1.16.0 GitHub: https://github.com/haskell-suite/haskell-src-exts This release brings many bugfixes, as well as the following language features: * DoRec * Closed type families * GADT records * ExplicitNamespaces * Type equality constraints * PolyKinds * DataKinds * Default associated types * Instance signatures * OVERLAP pragma * Parallel arrays * MINIMAL pragma * Default signatures * Safe Haskell * Binary literals * Qualified record puns * Type splices The full changelog is available at https://github.com/haskell-suite/haskell-src-exts/blob/1.16.0/CHANGELOG This release is brought to you by: Alan Zimmerman Erik de Castro Lopo klapaucius Lars Corbijn Leonid Onokhov Peter A. Jonsson phischu Roman Cheplyaka Stefan Wehr Stijn van Drongelen yuriy0 Special thanks to Peter Jonsson who has done an incredible job for this release and fixed many of the longstanding issues in haskell-src-exts. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jmccarty at sent.com Sun Sep 14 02:47:44 2014 From: jmccarty at sent.com (Jason McCarty) Date: Sat, 13 Sep 2014 22:47:44 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: References: Message-ID: <1410662864.3813756.167203117.5BD2B222@webmail.messagingengine.com> On Sat, Sep 13, 2014, at 02:12 PM, trevor cook wrote: > Jason, John, > > Thanks for the in depth descriptions, it was just what I was looking for. Glad I could help. I should correct a couple things, though. Rather than wanting (+ Just x) as a morphism, you'd probably want const Nothing, which is a monoid morphism if Nothing is the unit of the monoid. But then the argument about equivalence remains the same. Also, I think Maybe v isn't even what I called a semi-vector space if v is; 0 *^ Just x should be Nothing, but it's Just zeroV instead. I have some more thoughts about this when I get a chance. -- Jason McCarty From KAction at gnu.org Sun Sep 14 14:32:45 2014 From: KAction at gnu.org (Dmitry Bogatov) Date: Sun, 14 Sep 2014 18:32:45 +0400 Subject: [Haskell-cafe] Type union Message-ID: <20140914143245.GA21099@self.lan> Hello! I am trying to create type safe boolean formula representation. Main operation is substion of particular value, to get another formula, and function that accept formula to calculate it's value. So target is: a = Conjunction (Var X) (Var Y) is 2 variable formula value (apply (X, True) . apply (Y, True) $ a) -- True and neither value a apply (X, True) . apply (X, False) $ a typechecks. How can I archive it? class Union a b c instance (a ~ b) => Union a b b instance Union a b (a, b) data P = P deriving Show data Q = Q deriving Show class (Show a) => Variable a instance Variable P instance Variable Q data Formula t where Prop :: (Variable b) => b -> Formula b Conjunction :: (Union t1 t2 t3) => Formula t1 -> Formula t2 -> Formula t3 deriving instance Show (Formula t) main = print (Conjunction (Prop P) (Prop Q) :: Int) This complains on ambitious t3. Attempt by typefamilies fails, since type family Union t1 t2 :: * data Void type instance Union a a = a type instance Union (a, b) a = (a, b) type instance Union (a, b) b = (a, b) type instance Union (a, b) c = (a, b, c) type instance Union a (a, b) = (a, b) type instance Union b (a, b) = (a, b) type instance Union c (a, b) = (a, b, c) type instance Union (a, b, c) a = (a, b, c) type instance Union (a, b, c) b = (a, b, c) type instance Union (a, b, c) c = (a, b, c) type instance Union (a, b, c) d = Void type instance Union a (a, b, c) = (a, b, c) type instance Union b (a, b, c) = (a, b, c) type instance Union c (a, b, c) = (a, b, c) type instance Union d (a, b, c) = Void this is somewhy conflicting instances. I am out of ideas. -- Best regards, Dmitry Bogatov , Free Software supporter, esperantisto and netiquette guardian. GPG: 54B7F00D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From fuuzetsu at fuuzetsu.co.uk Sun Sep 14 16:09:14 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 14 Sep 2014 17:09:14 +0100 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: <20140913210031.GG14961@weber> References: <541496A3.2070103@fuuzetsu.co.uk> <20140913210031.GG14961@weber> Message-ID: <5415BDAA.1010107@fuuzetsu.co.uk> On 09/13/2014 10:00 PM, Tom Ellis wrote: > On Sat, Sep 13, 2014 at 03:56:32PM -0400, Brent Yorgey wrote: >> Hi Mateusz, >> >> Can you please explain what you mean by "properly"? > > I'm not Mateusz, but from my point of view setting the "References:" and > "In-Reply-To:" headers would be helpful, as would be quoting the message > that is being replied to. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Precisely the above. As seen at [1], there are 3 top-level threads from the user in question and if you sort by most recent activity in thread, it makes it even harder to find the actual discussion. [1]: http://fuuzetsu.co.uk/images/1410710789.png -- Mateusz K. From jays at panix.com Sun Sep 14 16:46:40 2014 From: jays at panix.com (Jay Sulzberger) Date: Sun, 14 Sep 2014 12:46:40 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: On Fri, 12 Sep 2014, Tikhon Jelvis wrote: > Note how the provided code enables a bunch of language extensions, most > notably UndecidableInstances. (Yep, that's exactly what it sounds like!) > > It's quite far removed from standard Haskell or full type inference. Yes. One thing that I now know is that, to date, there is a clean separation of estimation of the type of a function from the next stage of the GHC pipeline. In particular you cannot see in the Core code for the function the effect of the extensions, except possibly, whether or not any code is produced. I say "know", but all I have done is look at the high level explanations. I have not looked at any compiler code. So my understanding is not good and likely to be largely mistaken. oo--JS. > On Sep 12, 2014 4:30 PM, "Brandon Allbery" wrote: > >> On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: >> >>> But this is impossible! The type system of Haskell can be >>> handled by a Hindley-Milner-Damas style type checker. Such a >>> type checker always comes to a halt with a Yea or Nay answer. So >>> one cannot get a simulation of the combinators S, K, I inside the >>> Haskell type system. >>> >>> What have I misunderstood? And, in case GHC really does now >>> handle stuff beyond the HMD horizon, what does the New Core >>> language look like? >>> >> >> Standard Haskell is (or was) H-M extended with typeclasses. GHC moved >> beyond that years ago; internally it's System Fw ( >> http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core >> language reflects this. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > From jays at panix.com Sun Sep 14 16:51:27 2014 From: jays at panix.com (Jay Sulzberger) Date: Sun, 14 Sep 2014 12:51:27 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: On Sun, 14 Sep 2014, Jay Sulzberger wrote: > > > > On Fri, 12 Sep 2014, Tikhon Jelvis wrote: > >> Note how the provided code enables a bunch of language extensions, most >> notably UndecidableInstances. (Yep, that's exactly what it sounds like!) >> >> It's quite far removed from standard Haskell or full type inference. > > Yes. One thing that I now know is that, to date, there is a > clean separation of estimation of the type of a function from the > next stage of the GHC pipeline. In particular you cannot see in > the Core code for the function the effect of the extensions, > except possibly, whether or not any code is produced. > > I say "know", but all I have done is look at the high level > explanations. I have not looked at any compiler code. So my > understanding is not good and likely to be largely mistaken. > > oo--JS. I should have in my first post distinguished "inference" from "checking". I believe checking is still decidable, but inference no longer is, if you call GHC with given options. oo--JS. > > >> On Sep 12, 2014 4:30 PM, "Brandon Allbery" wrote: >> >>> On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: >>> >>>> But this is impossible! The type system of Haskell can be >>>> handled by a Hindley-Milner-Damas style type checker. Such a >>>> type checker always comes to a halt with a Yea or Nay answer. So >>>> one cannot get a simulation of the combinators S, K, I inside the >>>> Haskell type system. >>>> >>>> What have I misunderstood? And, in case GHC really does now >>>> handle stuff beyond the HMD horizon, what does the New Core >>>> language look like? >>>> >>> >>> Standard Haskell is (or was) H-M extended with typeclasses. GHC moved >>> beyond that years ago; internally it's System Fw ( >>> http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core >>> language reflects this. >>> >>> -- >>> brandon s allbery kf8nh sine nomine >>> associates >>> allbery.b at gmail.com >>> ballbery at sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad >>> http://sinenomine.net >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> > > From trebla at vex.net Sun Sep 14 17:18:56 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Sun, 14 Sep 2014 13:18:56 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: <5415BDAA.1010107@fuuzetsu.co.uk> References: <541496A3.2070103@fuuzetsu.co.uk> <20140913210031.GG14961@weber> <5415BDAA.1010107@fuuzetsu.co.uk> Message-ID: <5415CE00.1070203@vex.net> On 14-09-14 12:09 PM, Mateusz Kowalczyk wrote: > On 09/13/2014 10:00 PM, Tom Ellis wrote: >> On Sat, Sep 13, 2014 at 03:56:32PM -0400, Brent Yorgey wrote: >>> Hi Mateusz, >>> >>> Can you please explain what you mean by "properly"? >> >> I'm not Mateusz, but from my point of view setting the "References:" and >> "In-Reply-To:" headers would be helpful, as would be quoting the message >> that is being replied to. >> > > Precisely the above. As seen at [1], there are 3 top-level threads from > the user in question and if you sort by most recent activity in thread, > it makes it even harder to find the actual discussion. > > > [1]: http://fuuzetsu.co.uk/images/1410710789.png You know, this is very strange. The client software in question seems to be GMail's web interface, and this one has had many examples of doing the right thing, both elsewhere and in haskell-cafe, even in this very thread (Brent Yorgey's message). It may be useful to exchange notes on which buttons to press to get which behaviour. From allbery.b at gmail.com Sun Sep 14 18:01:13 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 14 Sep 2014 14:01:13 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: <5415CE00.1070203@vex.net> References: <541496A3.2070103@fuuzetsu.co.uk> <20140913210031.GG14961@weber> <5415BDAA.1010107@fuuzetsu.co.uk> <5415CE00.1070203@vex.net> Message-ID: On Sun, Sep 14, 2014 at 1:18 PM, Albert Y. C. Lai wrote: > It may be useful to exchange notes on which buttons to press to get which > behaviour. Probably the big obvious COMPOSE button instead of the potentially less obvious left-arrow icon at top right of the message header. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at karlv.net Sun Sep 14 19:40:56 2014 From: karl at karlv.net (Karl Voelker) Date: Sun, 14 Sep 2014 12:40:56 -0700 Subject: [Haskell-cafe] Control.Monad.Error deprecated? Message-ID: <1410723656.2499764.167365017.29EBD0DE@webmail.messagingengine.com> Hello everyone, I just discovered that Control.Monad.Error [1] has recently become deprecated in favor of Control.Monad.Except [2], and I am curious about what motivated the change. Can anyone explain? Thanks, Karl 1: http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Error.html 2: http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Except.html From fa-ml at ariis.it Sun Sep 14 20:13:21 2014 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 14 Sep 2014 22:13:21 +0200 Subject: [Haskell-cafe] Control.Monad.Error deprecated? In-Reply-To: <1410723656.2499764.167365017.29EBD0DE@webmail.messagingengine.com> References: <1410723656.2499764.167365017.29EBD0DE@webmail.messagingengine.com> Message-ID: <20140914201321.GA11766@x60s.casa> On Sun, Sep 14, 2014 at 12:40:56PM -0700, Karl Voelker wrote: > I just discovered that Control.Monad.Error [1] has recently become > deprecated in favor of Control.Monad.Except [2], and I am curious about > what motivated the change. Can anyone explain? I discovered it recently too, in a search for a package similar to ``either`` but which didn't rely on template-haskell. Not a maintainer, so just a wild guess: maybe it is because the new module hasn't got the ``class Error`` (and people wanted to get rid of it) and general less hairiness? The commits/changelog don't contain other info: https://github.com/ekmett/mtl/commits/master/Control/Monad/Except.hs From suhorng at gmail.com Mon Sep 15 04:08:07 2014 From: suhorng at gmail.com (suhorng Y) Date: Mon, 15 Sep 2014 12:08:07 +0800 Subject: [Haskell-cafe] Control.Monad.Error deprecated? In-Reply-To: <20140914201321.GA11766@x60s.casa> References: <1410723656.2499764.167365017.29EBD0DE@webmail.messagingengine.com> <20140914201321.GA11766@x60s.casa> Message-ID: That's probably because Control.Monad.Trans.Error is deprecated since transformers-0.4 [1] [2]. Indeed, the `Error` class does not exist anymore. For `ExceptT`, we don't need to deal with `Error` anymore and there is no restriction on the error type. >From the change log of mtl-2.2.1: - Fix deprecation warnings caused by transformers 0.4 deprecating `ErrorT` https://github.com/ekmett/mtl/blob/master/CHANGELOG.markdown [1] https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Monad-Trans-Error.html [2] https://hackage.haskell.org/package/transformers-0.4.1.0/docs/Control-Monad-Trans-Except.html 2014-09-15 4:13 GMT+08:00 Francesco Ariis : > On Sun, Sep 14, 2014 at 12:40:56PM -0700, Karl Voelker wrote: > > I just discovered that Control.Monad.Error [1] has recently become > > deprecated in favor of Control.Monad.Except [2], and I am curious about > > what motivated the change. Can anyone explain? > > I discovered it recently too, in a search for a package similar to > ``either`` > but which didn't rely on template-haskell. > > Not a maintainer, so just a wild guess: maybe it is because the new module > hasn't got the ``class Error`` (and people wanted to get rid of it) and > general less hairiness? > > The commits/changelog don't contain other info: > > https://github.com/ekmett/mtl/commits/master/Control/Monad/Except.hs > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0slemi0 at gmail.com Mon Sep 15 08:11:43 2014 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Mon, 15 Sep 2014 10:11:43 +0200 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: -XUndecidableInstances gives it away in its name. Neither type checking or inference is decidable if you turn this extension on. It lifts some serious restrictions from type classes and type families that normally ensure that constraint computation/type functions normalise. I have also written a "proof" of turing completeness of UndecidableInstances a while ago: https://github.com/exFalso/TypeRegister This implements register machines in the type system, which are known to be turing complete. There are a few examples at the bottom, including an infinite loop. If you load it up in ghci and say (1 :: Inf) - which is just checking the type - it will stack overflow. On 14 September 2014 18:51, Jay Sulzberger wrote: > > > > On Sun, 14 Sep 2014, Jay Sulzberger wrote: > > >> >> >> On Fri, 12 Sep 2014, Tikhon Jelvis wrote: >> >> Note how the provided code enables a bunch of language extensions, most >>> notably UndecidableInstances. (Yep, that's exactly what it sounds like!) >>> >>> It's quite far removed from standard Haskell or full type inference. >>> >> >> Yes. One thing that I now know is that, to date, there is a >> clean separation of estimation of the type of a function from the >> next stage of the GHC pipeline. In particular you cannot see in >> the Core code for the function the effect of the extensions, >> except possibly, whether or not any code is produced. >> >> I say "know", but all I have done is look at the high level >> explanations. I have not looked at any compiler code. So my >> understanding is not good and likely to be largely mistaken. >> >> oo--JS. >> > > I should have in my first post distinguished "inference" from > "checking". I believe checking is still decidable, but inference > no longer is, if you call GHC with given options. > > > oo--JS. > > > >> >> On Sep 12, 2014 4:30 PM, "Brandon Allbery" wrote: >>> >>> On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: >>>> >>>> But this is impossible! The type system of Haskell can be >>>>> handled by a Hindley-Milner-Damas style type checker. Such a >>>>> type checker always comes to a halt with a Yea or Nay answer. So >>>>> one cannot get a simulation of the combinators S, K, I inside the >>>>> Haskell type system. >>>>> >>>>> What have I misunderstood? And, in case GHC really does now >>>>> handle stuff beyond the HMD horizon, what does the New Core >>>>> language look like? >>>>> >>>>> >>>> Standard Haskell is (or was) H-M extended with typeclasses. GHC moved >>>> beyond that years ago; internally it's System Fw ( >>>> http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core >>>> language reflects this. >>>> >>>> -- >>>> brandon s allbery kf8nh sine nomine >>>> associates >>>> allbery.b at gmail.com >>>> ballbery at sinenomine.net >>>> unix, openafs, kerberos, infrastructure, xmonad >>>> http://sinenomine.net >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>>> >>> >> >> _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Sep 15 12:56:05 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 15 Sep 2014 08:56:05 -0400 Subject: [Haskell-cafe] Type union In-Reply-To: <20140914143245.GA21099@self.lan> References: <20140914143245.GA21099@self.lan> Message-ID: Have you tried using closed type families with the type-level (==) operator from GHC 7.8's Data.Type.Equality? That's how I've done unions before. The key step is to use a closed type family to write a type family equation that triggers when two types do *not* equal. Let me know if you need more info... Richard On Sep 14, 2014, at 10:32 AM, Dmitry Bogatov wrote: > Hello! > > I am trying to create type safe boolean formula representation. Main > operation is substion of particular value, to get another formula, and > function that accept formula to calculate it's value. > > So target is: > > a = Conjunction (Var X) (Var Y) is 2 variable formula > value (apply (X, True) . apply (Y, True) $ a) -- True > > and neither > > value a > apply (X, True) . apply (X, False) $ a > > typechecks. > > How can I archive it? > > class Union a b c > instance (a ~ b) => Union a b b > instance Union a b (a, b) > > data P = P deriving Show > data Q = Q deriving Show > class (Show a) => Variable a > instance Variable P > instance Variable Q > > data Formula t where > Prop :: (Variable b) => b -> Formula b > Conjunction :: (Union t1 t2 t3) => > Formula t1 -> Formula t2 -> Formula t3 > > deriving instance Show (Formula t) > main = print (Conjunction (Prop P) (Prop Q) :: Int) > > This complains on ambitious t3. > > Attempt by typefamilies fails, since > > type family Union t1 t2 :: * > data Void > type instance Union a a = a > type instance Union (a, b) a = (a, b) > type instance Union (a, b) b = (a, b) > type instance Union (a, b) c = (a, b, c) > type instance Union a (a, b) = (a, b) > type instance Union b (a, b) = (a, b) > type instance Union c (a, b) = (a, b, c) > type instance Union (a, b, c) a = (a, b, c) > type instance Union (a, b, c) b = (a, b, c) > type instance Union (a, b, c) c = (a, b, c) > type instance Union (a, b, c) d = Void > type instance Union a (a, b, c) = (a, b, c) > type instance Union b (a, b, c) = (a, b, c) > type instance Union c (a, b, c) = (a, b, c) > type instance Union d (a, b, c) = Void > > this is somewhy conflicting instances. I am out of ideas. > > -- > Best regards, Dmitry Bogatov , > Free Software supporter, esperantisto and netiquette guardian. > GPG: 54B7F00D > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From arnaud.oqube at gmail.com Mon Sep 15 13:08:00 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Mon, 15 Sep 2014 15:08:00 +0200 Subject: [Haskell-cafe] Using cabal repl with tests Message-ID: Hello, I have a classical project with cabal file split between a library, an executable and a test-suite. When I run `cabal repl` I got all modules from the library loaded, which is somewhat logical. I would like to launch a repl with test modules loaded, how can I achieve this? Adding `--enable-tests` does not help for the repl... Thanks, -- Arnaud Bailly FoldLabs Associate: http://foldlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgorin at dc.uba.ar Mon Sep 15 13:14:24 2014 From: dgorin at dc.uba.ar (=?iso-8859-1?Q?Daniel_Gor=EDn?=) Date: Mon, 15 Sep 2014 14:14:24 +0100 Subject: [Haskell-cafe] Using cabal repl with tests In-Reply-To: References: Message-ID: <357474FB-2459-486B-8278-802707D431C9@dc.uba.ar> Try: cabal repl The same works for executables. Daniel On 15 Sep 2014, at 14:08, Arnaud Bailly wrote: > Hello, > I have a classical project with cabal file split between a library, an executable and a test-suite. When I run `cabal repl` I got all modules from the library loaded, which is somewhat logical. > > I would like to launch a repl with test modules loaded, how can I achieve this? > Adding `--enable-tests` does not help for the repl... > > Thanks, > -- > Arnaud Bailly > FoldLabs Associate: http://foldlabs.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From arnaud.oqube at gmail.com Mon Sep 15 13:14:55 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Mon, 15 Sep 2014 15:14:55 +0200 Subject: [Haskell-cafe] Type union In-Reply-To: References: <20140914143245.GA21099@self.lan> Message-ID: Hello, I have a somewhat similar problem, trying to achieve union types but for the purpose of defining the set of allowable outcomes of a function. I have tried naively to define a type operator a :| b and I would like to be able to define a function like : f :: Int -> Int :| String :| Bool f 1 = in 1 1 f 2 = in 2 "foo" f 3 = in 3 True e.g. the codomain type is indexed by integers. I think this should be possible, even without full dependent typing given that I only expect to use literals My type-level-fu is really lacking so help would be appreciated. Regards, -- Arnaud Bailly FoldLabs Associate: http://foldlabs.com On Mon, Sep 15, 2014 at 2:56 PM, Richard Eisenberg wrote: > Have you tried using closed type families with the type-level (==) > operator from GHC 7.8's Data.Type.Equality? That's how I've done unions > before. The key step is to use a closed type family to write a type family > equation that triggers when two types do *not* equal. > > Let me know if you need more info... > > Richard > > On Sep 14, 2014, at 10:32 AM, Dmitry Bogatov wrote: > > > Hello! > > > > I am trying to create type safe boolean formula representation. Main > > operation is substion of particular value, to get another formula, and > > function that accept formula to calculate it's value. > > > > So target is: > > > > a = Conjunction (Var X) (Var Y) is 2 variable formula > > value (apply (X, True) . apply (Y, True) $ a) -- True > > > > and neither > > > > value a > > apply (X, True) . apply (X, False) $ a > > > > typechecks. > > > > How can I archive it? > > > > class Union a b c > > instance (a ~ b) => Union a b b > > instance Union a b (a, b) > > > > data P = P deriving Show > > data Q = Q deriving Show > > class (Show a) => Variable a > > instance Variable P > > instance Variable Q > > > > data Formula t where > > Prop :: (Variable b) => b -> Formula b > > Conjunction :: (Union t1 t2 t3) => > > Formula t1 -> Formula t2 -> Formula t3 > > > > deriving instance Show (Formula t) > > main = print (Conjunction (Prop P) (Prop Q) :: Int) > > > > This complains on ambitious t3. > > > > Attempt by typefamilies fails, since > > > > type family Union t1 t2 :: * > > data Void > > type instance Union a a = a > > type instance Union (a, b) a = (a, b) > > type instance Union (a, b) b = (a, b) > > type instance Union (a, b) c = (a, b, c) > > type instance Union a (a, b) = (a, b) > > type instance Union b (a, b) = (a, b) > > type instance Union c (a, b) = (a, b, c) > > type instance Union (a, b, c) a = (a, b, c) > > type instance Union (a, b, c) b = (a, b, c) > > type instance Union (a, b, c) c = (a, b, c) > > type instance Union (a, b, c) d = Void > > type instance Union a (a, b, c) = (a, b, c) > > type instance Union b (a, b, c) = (a, b, c) > > type instance Union c (a, b, c) = (a, b, c) > > type instance Union d (a, b, c) = Void > > > > this is somewhy conflicting instances. I am out of ideas. > > > > -- > > Best regards, Dmitry Bogatov , > > Free Software supporter, esperantisto and netiquette guardian. > > GPG: 54B7F00D > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Mon Sep 15 13:14:56 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 15 Sep 2014 23:14:56 +1000 Subject: [Haskell-cafe] Using cabal repl with tests In-Reply-To: References: Message-ID: >From `cabal repl --help`: Examples: cabal repl The first component in the package cabal repl foo A named component (i.e. lib, exe, test suite) The `foo' in this case is the name of the test-suite or executable. On 15 September 2014 23:08, Arnaud Bailly wrote: > Hello, > I have a classical project with cabal file split between a library, an > executable and a test-suite. When I run `cabal repl` I got all modules from > the library loaded, which is somewhat logical. > > I would like to launch a repl with test modules loaded, how can I achieve > this? > Adding `--enable-tests` does not help for the repl... > > Thanks, > -- > Arnaud Bailly > FoldLabs Associate: http://foldlabs.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From arnaud.oqube at gmail.com Mon Sep 15 13:18:20 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Mon, 15 Sep 2014 15:18:20 +0200 Subject: [Haskell-cafe] Using cabal repl with tests In-Reply-To: <357474FB-2459-486B-8278-802707D431C9@dc.uba.ar> References: <357474FB-2459-486B-8278-802707D431C9@dc.uba.ar> Message-ID: Wow! Works like a charm... Thanks a lot. And it is documented in the cabal user guide! So I should have looked there before, apologies for the noise. -- Arnaud Bailly FoldLabs Associate: http://foldlabs.com On Mon, Sep 15, 2014 at 3:14 PM, Daniel Gor?n wrote: > Try: cabal repl > > The same works for executables. > > Daniel > > On 15 Sep 2014, at 14:08, Arnaud Bailly wrote: > > > Hello, > > I have a classical project with cabal file split between a library, an > executable and a test-suite. When I run `cabal repl` I got all modules from > the library loaded, which is somewhat logical. > > > > I would like to launch a repl with test modules loaded, how can I > achieve this? > > Adding `--enable-tests` does not help for the repl... > > > > Thanks, > > -- > > Arnaud Bailly > > FoldLabs Associate: http://foldlabs.com > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Sep 15 13:38:57 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 15 Sep 2014 09:38:57 -0400 Subject: [Haskell-cafe] Type union In-Reply-To: References: <20140914143245.GA21099@self.lan> Message-ID: <092F633C-CA27-42D0-BB76-87FCA3F68157@cis.upenn.edu> On Sep 15, 2014, at 9:14 AM, Arnaud Bailly wrote: > Hello, > I have a somewhat similar problem, trying to achieve union types but for the purpose of defining the set of allowable outcomes of a function. I have tried naively to define a type operator a :| b and I would like to be able to define a function like : > > f :: Int -> Int :| String :| Bool > f 1 = in 1 1 > f 2 = in 2 "foo" > f 3 = in 3 True How is this different from `Either Int (Either String Bool)`? Richard From tmcdonell at cse.unsw.edu.au Mon Sep 15 14:04:14 2014 From: tmcdonell at cse.unsw.edu.au (Trevor L. McDonell) Date: Mon, 15 Sep 2014 10:04:14 -0400 Subject: [Haskell-cafe] [ANN] accelerate-0.15 Message-ID: <412E5260-16D1-48F0-86B5-8D94C5665C82@cse.unsw.edu.au> Friends, I am pleased to announce the release of the Accelerate 0.15 family of packages. Accelerate defines an embedded language of array computations for high performance computing in Haskell. Computations on multi-dimensional, regular arrays are expressed in the form of parameterised collective operations, such as maps, reductions, and permutations. These computations may then be online compiled and executed on a range of architectures, such as GPUs. This release brings mainly bug fixes and performance improvements. The following packages are available on Hackage: accelerate The language definition and reference implementation accelerate-cuda A high performance parallel backend targeting NVIDIA GPUs accelerate-io Fast conversion between Accelerate arrays and other formats, including ?vector? and ?repa?. accelerate-fft Discrete Fourier transforms, backed by CUFFT where available accelerate-examples Computational kernels and applications showcasing Accelerate The code can be found on GitHub, where you can also submit issues: https://github.com/AccelerateHS https://github.com/AccelerateHS/accelerate/issues Finally, there is also a mailing list that can be used for both use and development discussions: accelerate-haskell at googlegroups.com http://groups.google.com/group/accelerate-haskell -The Accelerate Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Mon Sep 15 14:08:44 2014 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Mon, 15 Sep 2014 16:08:44 +0200 Subject: [Haskell-cafe] [accelerate-haskell] [ANN] accelerate-0.15 In-Reply-To: <412E5260-16D1-48F0-86B5-8D94C5665C82@cse.unsw.edu.au> References: <412E5260-16D1-48F0-86B5-8D94C5665C82@cse.unsw.edu.au> Message-ID: <5416F2EC.5070508@nh2.me> Excellent! Now here comes my number 1 feature request for the next version: IO/ST arrays/computations in accelerate, so that I can implement stuff that can work on a 1GB device array with interleaved IO, without having to download and-re-upload that array every time. Keep up the good work! From alpmestan at gmail.com Mon Sep 15 14:10:08 2014 From: alpmestan at gmail.com (Alp Mestanogullari) Date: Mon, 15 Sep 2014 16:10:08 +0200 Subject: [Haskell-cafe] [ANN] accelerate-0.15 In-Reply-To: <412E5260-16D1-48F0-86B5-8D94C5665C82@cse.unsw.edu.au> References: <412E5260-16D1-48F0-86B5-8D94C5665C82@cse.unsw.edu.au> Message-ID: Hey Trevor, Congrats for the new release. Tried to get back to my CUBLAS binding work recently, but it was a bit hard as the accelerate repos were transitionning to getting ready for 0.15. Just a quick question: is there any plan to make what's in http://www.cse.unsw.edu.au/~tmcdonell/papers/acc-multidev-icfp2014-sub.pdf land in accelerate any time soon? On Mon, Sep 15, 2014 at 4:04 PM, Trevor L. McDonell < tmcdonell at cse.unsw.edu.au> wrote: > Friends, > > I am pleased to announce the release of the Accelerate 0.15 family of > packages. > > Accelerate defines an embedded language of array computations for high > performance computing in Haskell. Computations on multi-dimensional, > regular arrays are expressed in the form of parameterised collective > operations, such as maps, reductions, and permutations. These computations > may then be online compiled and executed on a range of architectures, such > as GPUs. > > This release brings mainly bug fixes and performance improvements. > > > The following packages are available on Hackage: > > accelerate The language > definition and reference implementation > accelerate-cuda A > high performance parallel backend targeting NVIDIA GPUs > accelerate-io Fast > conversion between Accelerate arrays and other formats, including ?vector? > and ?repa?. > accelerate-fft Discrete > Fourier transforms, backed by CUFFT where available > accelerate-examples > Computational > kernels and applications showcasing Accelerate > > > The code can be found on GitHub, where you can also submit issues: > > https://github.com/AccelerateHS > https://github.com/AccelerateHS/accelerate/issues > > Finally, there is also a mailing list that can be used for both use and > development discussions: > > accelerate-haskell at googlegroups.com > http://groups.google.com/group/accelerate-haskell > > > -The Accelerate Team > > -- > You received this message because you are subscribed to the Google Groups > "parallel-haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to parallel-haskell+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Alp Mestanogullari -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.oqube at gmail.com Mon Sep 15 14:30:20 2014 From: arnaud.oqube at gmail.com (Arnaud Bailly) Date: Mon, 15 Sep 2014 16:30:20 +0200 Subject: [Haskell-cafe] Type union In-Reply-To: <092F633C-CA27-42D0-BB76-87FCA3F68157@cis.upenn.edu> References: <20140914143245.GA21099@self.lan> <092F633C-CA27-42D0-BB76-87FCA3F68157@cis.upenn.edu> Message-ID: Technically it is not different but it allows one to write things in a much more compact way. And I would like the :| types to be of arbitrary size, meaning each `in x y` invocation would inject a value at the right position in the sum type without having to declare all the possible sizes of coproducts. But maybe I could simply do that for some arbitrarily large number of types.... -- Arnaud Bailly FoldLabs Associate: http://foldlabs.com On Mon, Sep 15, 2014 at 3:38 PM, Richard Eisenberg wrote: > On Sep 15, 2014, at 9:14 AM, Arnaud Bailly wrote: > > > Hello, > > I have a somewhat similar problem, trying to achieve union types but for > the purpose of defining the set of allowable outcomes of a function. I have > tried naively to define a type operator a :| b and I would like to be able > to define a function like : > > > > f :: Int -> Int :| String :| Bool > > f 1 = in 1 1 > > f 2 = in 2 "foo" > > f 3 = in 3 True > > How is this different from `Either Int (Either String Bool)`? > > Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From KAction at gnu.org Mon Sep 15 16:58:18 2014 From: KAction at gnu.org (Dmitry Bogatov) Date: Mon, 15 Sep 2014 20:58:18 +0400 Subject: [Haskell-cafe] Type union In-Reply-To: References: <20140914143245.GA21099@self.lan> Message-ID: <20140915165818.GA22658@self.lan> * Richard Eisenberg [2014-09-15 08:56:05-0400] > Have you tried using closed type families with the type-level (==) > operator from GHC 7.8's Data.Type.Equality? That's how I've done > unions before. The key step is to use a closed type family to write a > type family equation that triggers when two types do *not* equal. > > Let me know if you need more info... Thanks. I will take a look for my education, but I am on Debian, so no more, then ghc 7.6.3. I found type-settheory package, but it fails to build. -- Best regards, Dmitry Bogatov , Free Software supporter, esperantisto and netiquette guardian. GPG: 54B7F00D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From felipe.lessa at gmail.com Mon Sep 15 17:05:55 2014 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Mon, 15 Sep 2014 14:05:55 -0300 Subject: [Haskell-cafe] [accelerate-haskell] [ANN] accelerate-0.15 In-Reply-To: <5416F2EC.5070508@nh2.me> References: <412E5260-16D1-48F0-86B5-8D94C5665C82@cse.unsw.edu.au> <5416F2EC.5070508@nh2.me> Message-ID: <54171C73.1020204@gmail.com> On 15-09-2014 11:08, Niklas Hamb?chen wrote: > Excellent! > > Now here comes my number 1 feature request for the next version: > > IO/ST arrays/computations in accelerate, so that I can implement stuff > that can work on a 1GB device array with interleaved IO, without having > to download and-re-upload that array every time. Do you mean using mmap'd memory? Cheers! -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From carter.schonwald at gmail.com Mon Sep 15 17:24:16 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 15 Sep 2014 13:24:16 -0400 Subject: [Haskell-cafe] Type union In-Reply-To: <20140915165818.GA22658@self.lan> References: <20140914143245.GA21099@self.lan> <20140915165818.GA22658@self.lan> Message-ID: i should point out the HList package has a lot of tooling for things like this, and the author Adam says that its quite usable (aside from the dearth of docs beyond the crazy typeful haddocks :) ) https://hackage.haskell.org/package/HList On Mon, Sep 15, 2014 at 12:58 PM, Dmitry Bogatov wrote: > * Richard Eisenberg [2014-09-15 08:56:05-0400] > > Have you tried using closed type families with the type-level (==) > > operator from GHC 7.8's Data.Type.Equality? That's how I've done > > unions before. The key step is to use a closed type family to write a > > type family equation that triggers when two types do *not* equal. > > > > Let me know if you need more info... > Thanks. I will take a look for my education, but > I am on Debian, so no more, then ghc 7.6.3. > > I found type-settheory package, but it fails to build. > > -- > Best regards, Dmitry Bogatov , > Free Software supporter, esperantisto and netiquette guardian. > GPG: 54B7F00D > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmcdonell at cse.unsw.edu.au Mon Sep 15 17:27:04 2014 From: tmcdonell at cse.unsw.edu.au (Trevor L. McDonell) Date: Mon, 15 Sep 2014 13:27:04 -0400 Subject: [Haskell-cafe] [ANN] accelerate-0.15 In-Reply-To: References: <412E5260-16D1-48F0-86B5-8D94C5665C82@cse.unsw.edu.au> Message-ID: <103A6AB2-18D5-47F0-85AD-9B81EA5ED80C@cse.unsw.edu.au> On 15 Sep 2014, at 10:10 am, Alp Mestanogullari wrote: > Just a quick question: is there any plan to make what's in http://www.cse.unsw.edu.au/~tmcdonell/papers/acc-multidev-icfp2014-sub.pdf land in accelerate any time soon? Yes, we have plans to revive and fully bake this work in the near future. Stay tuned! (: -Trev -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at rjlewis.me.uk Mon Sep 15 17:38:09 2014 From: richard at rjlewis.me.uk (Richard Lewis) Date: Mon, 15 Sep 2014 18:38:09 +0100 Subject: [Haskell-cafe] Hackage package "synopsis" sections Message-ID: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Hi there, If any of you have ever used CPAN you may agree with me that the synopsis sections customarily included in each package's POD are generally invaluable for getting a quick overview of how to use the facilities provided by that package. I wonder if we might be able to encourage the Hackage community to do something similar? Perhaps in the cabal description authors could include a synopsis with a few code examples? Obviously, I ought to start the ball rolling but I don't actually have any code published on Hackage. Any thoughts? Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis @lewisrichard http://web.rjlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From michael at snoyman.com Mon Sep 15 17:40:35 2014 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 15 Sep 2014 20:40:35 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Message-ID: On Mon, Sep 15, 2014 at 8:38 PM, Richard Lewis wrote: > Hi there, > > If any of you have ever used CPAN you may > agree with me that the synopsis sections > customarily included in each package's POD > are generally invaluable for getting a quick > overview of how to use the facilities > provided by that package. > > I wonder if we might be able to encourage > the Hackage community to do something > similar? Perhaps in the cabal description > authors could include a synopsis with a > few code examples? > > Obviously, I ought to start the ball rolling but > I don't actually have any code published on > Hackage. > > Any thoughts? > > Richard > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Richard Lewis > @lewisrichard > http://web.rjlewis.me.uk/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > I'd love to see it work similar to the new changelog feature. Imagine if you could add a `Synopsis.md` file to your cabal sdist, and Hackage rendered it to HTML and displayed it? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Mon Sep 15 18:28:38 2014 From: tikhon at jelv.is (Tikhon Jelvis) Date: Mon, 15 Sep 2014 11:28:38 -0700 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Message-ID: Genuinely curious: do you think a `Synopsis.md` would be that much easier than the current system with a potentially long description in the .cabal file? I could see a case either way. Or maybe I'm just misunderstanding the distinction. On the one hand, a separate file makes organization easier and markdown is a known quantity; on the other, it seems functionally equivalent to what we *can* do now albeit with Haddock syntax and in a file full of other details. I could see why a file would be easier, and maybe that's enough to encourage more people to write one. We could even have .cabal just render the existing README file or something! On the other hand, that would take some effort and sometimes using Haddock markup and sometimes using markdown would be confusing. Maybe we could have a guerrilla campaign of pull requests adding examples and a bit of explanation to every package you like that doesn't have them... That could also be a good way for beginners who want to contribute to start. On Mon, Sep 15, 2014 at 10:40 AM, Michael Snoyman wrote: > > > On Mon, Sep 15, 2014 at 8:38 PM, Richard Lewis > wrote: > >> Hi there, >> >> If any of you have ever used CPAN you may >> agree with me that the synopsis sections >> customarily included in each package's POD >> are generally invaluable for getting a quick >> overview of how to use the facilities >> provided by that package. >> >> I wonder if we might be able to encourage >> the Hackage community to do something >> similar? Perhaps in the cabal description >> authors could include a synopsis with a >> few code examples? >> >> Obviously, I ought to start the ball rolling but >> I don't actually have any code published on >> Hackage. >> >> Any thoughts? >> >> Richard >> -- >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Richard Lewis >> @lewisrichard >> http://web.rjlewis.me.uk/ >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > I'd love to see it work similar to the new changelog feature. Imagine if > you could add a `Synopsis.md` file to your cabal sdist, and Hackage > rendered it to HTML and displayed it? > > Michael > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amiribarksdale at gmail.com Mon Sep 15 18:46:37 2014 From: amiribarksdale at gmail.com (Amiri Barksdale) Date: Mon, 15 Sep 2014 11:46:37 -0700 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Message-ID: <20140915184637.GF28346@amiri-laptop.hq.campusexplorer.com> On Mon, Sep 15, 2014 at 11:28:38AM -0700, Tikhon Jelvis wrote: | Maybe we could have a guerrilla campaign of pull requests adding examples | and a bit of explanation to every package you like that doesn't have | them... That could also be a good way for beginners who want to contribute | to start. I am a beginner, also coming from the Perl world of lovely synopses, and I would love to contribute in this fashion! I haven't started yet, but this is a great idea. Let it be said that Michael's packages are better documented than most, I've noticed. Amiri From adam at well-typed.com Mon Sep 15 19:48:08 2014 From: adam at well-typed.com (Adam Gundry) Date: Mon, 15 Sep 2014 20:48:08 +0100 Subject: [Haskell-cafe] Type union In-Reply-To: References: <20140914143245.GA21099@self.lan> Message-ID: <54174278.3090408@well-typed.com> Hi Arnaud, You can't quite write what you asked for, but you can get pretty close, as long as you don't mind Peano naturals rather than integer literals, and an extra (partially-defined) element: {-# LANGUAGE GADTs, TypeOperators #-} type (:|) = Either infixr 5 :| data In x xs where Zero :: In x (x :| xs) Suc :: In x xs -> In x (y :| xs) inj :: In x xs -> x -> xs inj Zero = Left inj (Suc n) = Right . inj n data Void f :: Int -> Int :| String :| Bool :| Void f 0 = inj Zero 1 f 1 = inj (Suc Zero) "foo" f 2 = inj (Suc (Suc Zero)) True I'm not sure how useful this is in practice, however. Hope this helps, Adam On 15/09/14 14:14, Arnaud Bailly wrote: > Hello, > I have a somewhat similar problem, trying to achieve union types but for > the purpose of defining the set of allowable outcomes of a function. I > have tried naively to define a type operator a :| b and I would like to > be able to define a function like : > > f :: Int -> Int :| String :| Bool > f 1 = in 1 1 > f 2 = in 2 "foo" > f 3 = in 3 True > > e.g. the codomain type is indexed by integers. I think this should be > possible, even without full dependent typing given that I only expect to > use literals > > My type-level-fu is really lacking so help would be appreciated. > > Regards, > > -- > Arnaud Bailly > FoldLabs Associate: http://foldlabs.com -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From michael at snoyman.com Mon Sep 15 20:11:55 2014 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 15 Sep 2014 23:11:55 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Message-ID: I've had cases where some code I wanted to put in an example could not be expressed in haddock due to escaping rules. I would much rather be able to write a synopsis in markdown, or asciidoc, or HTML, rather than haddock markup. On Monday, September 15, 2014, Tikhon Jelvis wrote: > Genuinely curious: do you think a `Synopsis.md` would be that much easier > than the current system with a potentially long description in the .cabal > file? I could see a case either way. Or maybe I'm just misunderstanding the > distinction. > > On the one hand, a separate file makes organization easier and markdown is > a known quantity; on the other, it seems functionally equivalent to what we > *can* do now albeit with Haddock syntax and in a file full of other > details. > > I could see why a file would be easier, and maybe that's enough to > encourage more people to write one. We could even have .cabal just render > the existing README file or something! On the other hand, that would take > some effort and sometimes using Haddock markup and sometimes using markdown > would be confusing. > > Maybe we could have a guerrilla campaign of pull requests adding examples > and a bit of explanation to every package you like that doesn't have > them... That could also be a good way for beginners who want to contribute > to start. > > On Mon, Sep 15, 2014 at 10:40 AM, Michael Snoyman > wrote: > >> >> >> On Mon, Sep 15, 2014 at 8:38 PM, Richard Lewis > > wrote: >> >>> Hi there, >>> >>> If any of you have ever used CPAN you may >>> agree with me that the synopsis sections >>> customarily included in each package's POD >>> are generally invaluable for getting a quick >>> overview of how to use the facilities >>> provided by that package. >>> >>> I wonder if we might be able to encourage >>> the Hackage community to do something >>> similar? Perhaps in the cabal description >>> authors could include a synopsis with a >>> few code examples? >>> >>> Obviously, I ought to start the ball rolling but >>> I don't actually have any code published on >>> Hackage. >>> >>> Any thoughts? >>> >>> Richard >>> -- >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> Richard Lewis >>> @lewisrichard >>> http://web.rjlewis.me.uk/ >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> I'd love to see it work similar to the new changelog feature. Imagine if >> you could add a `Synopsis.md` file to your cabal sdist, and Hackage >> rendered it to HTML and displayed it? >> >> Michael >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jays at panix.com Mon Sep 15 20:56:26 2014 From: jays at panix.com (Jay Sulzberger) Date: Mon, 15 Sep 2014 16:56:26 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: On Mon, 15 Sep 2014, Andras Slemmer <0slemi0 at gmail.com> wrote: > -XUndecidableInstances gives it away in its name. Neither type checking or > inference is decidable if you turn this extension on. It lifts some serious > restrictions from type classes and type families that normally ensure that > constraint computation/type functions normalise. > I have also written a "proof" of turing completeness of > UndecidableInstances a while ago: https://github.com/exFalso/TypeRegister > This implements register machines in the type system, which are known to be > turing complete. There are a few examples at the bottom, including an > infinite loop. > If you load it up in ghci and say (1 :: Inf) - which is just checking the > type - it will stack overflow. So, now we have not only S, K, I, as Turing machine components, but also Eval with its supporting instruction set. ad checking vs inference: I will think about this. ad UndecidableInstances: The two Turing machine realizations offer evidence that one should not be naive about believing in "Ex Falso, quodlibet.". Part of the propaganda for Haskell goes like so: "Haskell has a rigorous compile time type checker which catches a certain kind of bug, and catches every one of this kind! (assuming a bugless Haskell compiler)." But S, K, I and Eval show that, if one takes "Ex Falso, quodlibet." too seriously, this cannot be true. It cannot be true, because once one invokes the Greater Options, the Universal Machine is summoned, whether your program realizes an instance of it or not. Then, according to the Ancient Books of Logic^W^W^W^W^Wmany recent textbooks, by "Ex Falso, quodlibet.", the mere summoning, by internal over-pressure, explodes the type checker, taking everything with it. But of course this is not true. This should be enough to make the Wikipedia editors take Carl Hewitt back! http://irobust.org [Above is a Google Doc, oi] oo--JS. > > On 14 September 2014 18:51, Jay Sulzberger wrote: > >> >> >> >> On Sun, 14 Sep 2014, Jay Sulzberger wrote: >> >> >>> >>> >>> On Fri, 12 Sep 2014, Tikhon Jelvis wrote: >>> >>> Note how the provided code enables a bunch of language extensions, most >>>> notably UndecidableInstances. (Yep, that's exactly what it sounds like!) >>>> >>>> It's quite far removed from standard Haskell or full type inference. >>>> >>> >>> Yes. One thing that I now know is that, to date, there is a >>> clean separation of estimation of the type of a function from the >>> next stage of the GHC pipeline. In particular you cannot see in >>> the Core code for the function the effect of the extensions, >>> except possibly, whether or not any code is produced. >>> >>> I say "know", but all I have done is look at the high level >>> explanations. I have not looked at any compiler code. So my >>> understanding is not good and likely to be largely mistaken. >>> >>> oo--JS. >>> >> >> I should have in my first post distinguished "inference" from >> "checking". I believe checking is still decidable, but inference >> no longer is, if you call GHC with given options. >> >> >> oo--JS. >> >> >> >>> >>> On Sep 12, 2014 4:30 PM, "Brandon Allbery" wrote: >>>> >>>> On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: >>>>> >>>>> But this is impossible! The type system of Haskell can be >>>>>> handled by a Hindley-Milner-Damas style type checker. Such a >>>>>> type checker always comes to a halt with a Yea or Nay answer. So >>>>>> one cannot get a simulation of the combinators S, K, I inside the >>>>>> Haskell type system. >>>>>> >>>>>> What have I misunderstood? And, in case GHC really does now >>>>>> handle stuff beyond the HMD horizon, what does the New Core >>>>>> language look like? >>>>>> >>>>>> >>>>> Standard Haskell is (or was) H-M extended with typeclasses. GHC moved >>>>> beyond that years ago; internally it's System Fw ( >>>>> http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core >>>>> language reflects this. >>>>> >>>>> -- >>>>> brandon s allbery kf8nh sine nomine >>>>> associates >>>>> allbery.b at gmail.com >>>>> ballbery at sinenomine.net >>>>> unix, openafs, kerberos, infrastructure, xmonad >>>>> http://sinenomine.net >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From jays at panix.com Mon Sep 15 21:30:23 2014 From: jays at panix.com (Jay Sulzberger) Date: Mon, 15 Sep 2014 17:30:23 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> Message-ID: On Mon, 15 Sep 2014, Jay Sulzberger wrote: > > > > On Mon, 15 Sep 2014, Andras Slemmer <0slemi0 at gmail.com> wrote: > >> -XUndecidableInstances gives it away in its name. Neither type checking or >> inference is decidable if you turn this extension on. It lifts some serious >> restrictions from type classes and type families that normally ensure that >> constraint computation/type functions normalise. >> I have also written a "proof" of turing completeness of >> UndecidableInstances a while ago: https://github.com/exFalso/TypeRegister >> This implements register machines in the type system, which are known to be >> turing complete. There are a few examples at the bottom, including an >> infinite loop. >> If you load it up in ghci and say (1 :: Inf) - which is just checking the >> type - it will stack overflow. Thanks, Andras! Indeed here is what we get:
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :load "register.hs" [1 of 1] Compiling Main ( register.hs, interpreted ) Ok, modules loaded: Main. *Main> (1 :: Inf) :5:2: Context reduction stack overflow; size = 201 Use -fcontext-stack=N to increase stack size to N Eval ((':) * (RP * * Zero Zero) ('[] *) :!: Zero) ((':) * (RP * * Zero Zero) ('[] *)) (Update uf1 Zero (Succ *)) ~ uf0 In the expression: (1 :: Inf) In an equation for `it': it = (1 :: Inf) *Main>
oo--JS. < nothing new in stuff below /> > > So, now we have not only S, K, I, as Turing machine components, > but also Eval with its supporting instruction set. > > ad checking vs inference: I will think about this. > > ad UndecidableInstances: The two Turing machine realizations > offer evidence that one should not be naive about believing in > "Ex Falso, quodlibet.". Part of the propaganda for Haskell goes like so: > > "Haskell has a rigorous compile time type checker which catches > a certain kind of bug, and catches every one of this kind! > (assuming a bugless Haskell compiler)." > > But S, K, I and Eval show that, if one takes "Ex Falso, > quodlibet." too seriously, this cannot be true. It cannot be > true, because once one invokes the Greater Options, the Universal > Machine is summoned, whether your program realizes an instance of > it or not. Then, according to the Ancient Books of > Logic^W^W^W^W^Wmany recent textbooks, by "Ex Falso, quodlibet.", the > mere summoning, by internal over-pressure, explodes the type > checker, taking everything with it. But of course this is not > true. This should be enough to make the Wikipedia editors take > Carl Hewitt back! > > http://irobust.org > [Above is a Google Doc, oi] > > oo--JS. > > >> >> On 14 September 2014 18:51, Jay Sulzberger wrote: >> >>> >>> >>> >>> On Sun, 14 Sep 2014, Jay Sulzberger wrote: >>> >>> >>>> >>>> >>>> On Fri, 12 Sep 2014, Tikhon Jelvis wrote: >>>> >>>> Note how the provided code enables a bunch of language extensions, most >>>>> notably UndecidableInstances. (Yep, that's exactly what it sounds like!) >>>>> >>>>> It's quite far removed from standard Haskell or full type inference. >>>>> >>>> >>>> Yes. One thing that I now know is that, to date, there is a >>>> clean separation of estimation of the type of a function from the >>>> next stage of the GHC pipeline. In particular you cannot see in >>>> the Core code for the function the effect of the extensions, >>>> except possibly, whether or not any code is produced. >>>> >>>> I say "know", but all I have done is look at the high level >>>> explanations. I have not looked at any compiler code. So my >>>> understanding is not good and likely to be largely mistaken. >>>> >>>> oo--JS. >>>> >>> >>> I should have in my first post distinguished "inference" from >>> "checking". I believe checking is still decidable, but inference >>> no longer is, if you call GHC with given options. >>> >>> >>> oo--JS. >>> >>> >>> >>>> >>>> On Sep 12, 2014 4:30 PM, "Brandon Allbery" wrote: >>>>> >>>>> On Fri, Sep 12, 2014 at 7:25 PM, Jay Sulzberger wrote: >>>>>> >>>>>> But this is impossible! The type system of Haskell can be >>>>>>> handled by a Hindley-Milner-Damas style type checker. Such a >>>>>>> type checker always comes to a halt with a Yea or Nay answer. So >>>>>>> one cannot get a simulation of the combinators S, K, I inside the >>>>>>> Haskell type system. >>>>>>> >>>>>>> What have I misunderstood? And, in case GHC really does now >>>>>>> handle stuff beyond the HMD horizon, what does the New Core >>>>>>> language look like? >>>>>>> >>>>>>> >>>>>> Standard Haskell is (or was) H-M extended with typeclasses. GHC moved >>>>>> beyond that years ago; internally it's System Fw ( >>>>>> http://en.wikipedia.org/wiki/System_F#System_F.CF.89), and its Core >>>>>> language reflects this. >>>>>> >>>>>> -- >>>>>> brandon s allbery kf8nh sine nomine >>>>>> associates >>>>>> allbery.b at gmail.com >>>>>> ballbery at sinenomine.net >>>>>> unix, openafs, kerberos, infrastructure, xmonad >>>>>> http://sinenomine.net >>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > From jpaugh at gmx.us Mon Sep 15 22:54:29 2014 From: jpaugh at gmx.us (Jonathan Paugh) Date: Mon, 15 Sep 2014 17:54:29 -0500 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Message-ID: <54176E25.5080109@gmx.us> Hi all, Using Markdown would be a great idea. And, if Haddock were to support Markdown, and packages were migrated gradually to that, the inconsistency would disappear (eventually). IIRC, adding Markdown to Hadock was suggested on this list before, and the major argument against it was that Markdown didn't have a standard. Now, it has one, called CommonMark[1]. Barring any (further) copyright issues with the name, that looks to be a great step forward for Markdown. [1]: http://commonmark.org Regards, Jonathan Paugh On 09/15/2014 03:11 PM, Michael Snoyman wrote: > I've had cases where some code I wanted to put in an example could not be expressed in haddock due to escaping rules. I would much rather be able to write a synopsis in markdown, or asciidoc, or HTML, rather than haddock markup. > > On Monday, September 15, 2014, Tikhon Jelvis > wrote: > > Genuinely curious: do you think a `Synopsis.md` would be that much easier than the current system with a potentially long description in the .cabal file? I could see a case either way. Or maybe I'm just misunderstanding the distinction. > > On the one hand, a separate file makes organization easier and markdown is a known quantity; on the other, it seems functionally equivalent to what we *can* do now albeit with Haddock syntax and in a file full of other details. > > I could see why a file would be easier, and maybe that's enough to encourage more people to write one. We could even have .cabal just render the existing README file or something! On the other hand, that would take some effort and sometimes using Haddock markup and sometimes using markdown would be confusing. > > Maybe we could have a guerrilla campaign of pull requests adding examples and a bit of explanation to every package you like that doesn't have them... That could also be a good way for beginners who want to contribute to start. > > On Mon, Sep 15, 2014 at 10:40 AM, Michael Snoyman > wrote: > > > > On Mon, Sep 15, 2014 at 8:38 PM, Richard Lewis > wrote: > > Hi there, > > If any of you have ever used CPAN you may > agree with me that the synopsis sections > customarily included in each package's POD > are generally invaluable for getting a quick > overview of how to use the facilities > provided by that package. > > I wonder if we might be able to encourage > the Hackage community to do something > similar? Perhaps in the cabal description > authors could include a synopsis with a > few code examples? > > Obviously, I ought to start the ball rolling but > I don't actually have any code published on > Hackage. > > Any thoughts? > > Richard > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Richard Lewis > @lewisrichard > http://web.rjlewis.me.uk/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > I'd love to see it work similar to the new changelog feature. Imagine if you could add a `Synopsis.md` file to your cabal sdist, and Hackage rendered it to HTML and displayed it? > > Michael > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From allbery.b at gmail.com Mon Sep 15 23:22:46 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 15 Sep 2014 19:22:46 -0400 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <54176E25.5080109@gmx.us> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54176E25.5080109@gmx.us> Message-ID: On Mon, Sep 15, 2014 at 6:54 PM, Jonathan Paugh wrote: > IIRC, adding Markdown to Hadock was suggested on this list before, and > the major argument against it was that Markdown didn't have a standard. > The biggest argument against it is that several Markdown conventions conflict with existing Haddock conventions, so you don't get to mix and match and you may have to specify which convention you're using. Note that a flag day to deprecate the old Haddock is not an option, unless you are offering to rewrite the haddocks of every existing package. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Mon Sep 15 23:27:07 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 16 Sep 2014 00:27:07 +0100 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <54176E25.5080109@gmx.us> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54176E25.5080109@gmx.us> Message-ID: <541775CB.2050405@fuuzetsu.co.uk> On 09/15/2014 11:54 PM, Jonathan Paugh wrote: > Hi all, > > Using Markdown would be a great idea. And, if Haddock were to support > Markdown, and packages were migrated gradually to that, the > inconsistency would disappear (eventually). > > IIRC, adding Markdown to Hadock was suggested on this list before, and > the major argument against it was that Markdown didn't have a standard. > Now, it has one, called CommonMark[1]. Barring any (further) copyright > issues with the name, that looks to be a great step forward for Markdown. > > [1]: http://commonmark.org > > Regards, > Jonathan Paugh > It was more than proposed, it was the original plan of my GSOC in 2013. In the end it went into a different direction because after actually hacking on Haddock I came to the conclusion that Markdown was actually not a good idea. You can find reasons in caf? archives I'm sure. Standardisation was only one of the problems. The biggest problem is is that Haddock and Markdown simply serve a different purpose and there is no clear 1:1 mapping between the two. There is also the question of who's going to maintain it. We are severely understaffed. Haddock has only two maintainers, Simon Hengel and myself and Simon tends to be quite busy so it's mostly myself, and I also have about a billion projects I want to spend time on. I don't want to maintain another parser, there are more important things to hack. Honestly, it's sad that such a core project is so understaffed. Alas, complaining is not my main aim here. I simply want to point out that after some work, the Haddock parser and the required types now don't depend on GHC or any other libs that don't ship (bar for internal attoparsec dependency) with the compiler. This means that recent Pandoc now has both reader and writer modules for Haddock which means you can go Haddock <=> Markdown if you wish and get some results. I have not tried it myself however. Incidentally, implementing such reader/writer Pandoc modules was my initial submission in 2013. In summary, if you really want to write Markdown instead of Haddock, use pandoc to convert between the two. I really wonder if the hassle is worth it though. -- Mateusz K. From fuuzetsu at fuuzetsu.co.uk Mon Sep 15 23:30:32 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 16 Sep 2014 00:30:32 +0100 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54176E25.5080109@gmx.us> Message-ID: <54177698.9090605@fuuzetsu.co.uk> On 09/16/2014 12:22 AM, Brandon Allbery wrote: > On Mon, Sep 15, 2014 at 6:54 PM, Jonathan Paugh wrote: > >> IIRC, adding Markdown to Hadock was suggested on this list before, and >> the major argument against it was that Markdown didn't have a standard. >> > > The biggest argument against it is that several Markdown conventions > conflict with existing Haddock conventions, so you don't get to mix and > match and you may have to specify which convention you're using. Note that > a flag day to deprecate the old Haddock is not an option, unless you are > offering to rewrite the haddocks of every existing package. > This part is actually only an implementation detail, the original idea was to have a {-# OPTIONS_HADDOCK Markdown #-} pragma. It would require we re-order how we deal with pragmas but this is not a good argument against. You would of course have problems if you tried to use older Haddock on a new, Markdown'd module but it could be mostly mitigated by co-ordinating with GHC release + talking with the Hackage folk to use a new version. -- Mateusz K. From fuuzetsu at fuuzetsu.co.uk Mon Sep 15 23:36:34 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 16 Sep 2014 00:36:34 +0100 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Message-ID: <54177802.4060704@fuuzetsu.co.uk> On 09/15/2014 09:11 PM, Michael Snoyman wrote: > I've had cases where some code I wanted to put in an example could not be > expressed in haddock due to escaping rules. The parser has been improved and the escaping rules have been made saner. You shouldn't have real problems since 2.14 release which came out along with GHC 7.8.1. If you have problems with escaping then I'd like to hear about it on the issue tracker rather than stumbling upon complaints on caf?. I think just about the only thing nowadays that might surprise people is that tokens stretch over newlines but this is by design, especially considering one can embed code. > I would much rather be able to > write a synopsis in markdown, or asciidoc, or HTML, rather than haddock > markup. > As I mention on the other e-mail, you can now use pandoc to achieve this. If people really care then it should not be difficult to co-ordinate with cabal + Hackage and make it parse your favourite format and splice it into synopsis. I'd quite like the complaints about the existing Haddock markup, the rules are pretty damn close to what Markdown uses. -- Mateusz K. From jpaugh at gmx.us Mon Sep 15 23:55:20 2014 From: jpaugh at gmx.us (Jonathan Paugh) Date: Mon, 15 Sep 2014 18:55:20 -0500 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <541775CB.2050405@fuuzetsu.co.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54176E25.5080109@gmx.us> <541775CB.2050405@fuuzetsu.co.uk> Message-ID: <54177C68.3090601@gmx.us> On 09/15/2014 06:27 PM, Mateusz Kowalczyk wrote: > On 09/15/2014 11:54 PM, Jonathan Paugh wrote: >> Hi all, >> >> Using Markdown would be a great idea. And, if Haddock were to support >> Markdown, and packages were migrated gradually to that, the >> inconsistency would disappear (eventually). >> >> IIRC, adding Markdown to Hadock was suggested on this list before, and >> the major argument against it was that Markdown didn't have a standard. >> Now, it has one, called CommonMark[1]. Barring any (further) copyright >> issues with the name, that looks to be a great step forward for Markdown. >> >> [1]: http://commonmark.org >> >> Regards, >> Jonathan Paugh >> > > It was more than proposed, it was the original plan of my GSOC in 2013. > In the end it went into a different direction because after actually > hacking on Haddock I came to the conclusion that Markdown was actually > not a good idea. You can find reasons in caf? archives I'm sure. Okay, thanks for the correction & info. > There is also the question of > who's going to maintain it. Now, that would be a bigger obstacle than any technical ones. Also, there's the fact that CommonMark hasn't been vetted by the community at large, yet. In case it changes any, this might be a bad time to base a core Haskell component on it. (Aside from these obstacles, I'm all for it!) > We are severely understaffed. Haddock has > only two maintainers, Simon Hengel and myself and Simon tends to be > quite busy so it's mostly myself, and I also have about a billion > projects I want to spend time on. I don't want to maintain another > parser, there are more important things to hack. Honestly, it's sad that > such a core project is so understaffed. Thanks for all your hard work! > > Alas, complaining is not my main aim here. I simply want to point out > that after some work, the Haddock parser and the required types now > don't depend on GHC or any other libs that don't ship (bar for internal > attoparsec dependency) with the compiler. This means that recent Pandoc > now has both reader and writer modules for Haddock which means you can > go Haddock <=> Markdown if you wish and get some results. I have not > tried it myself however. Incidentally, implementing such reader/writer > Pandoc modules was my initial submission in 2013. > > In summary, if you really want to write Markdown instead of Haddock, use > pandoc to convert between the two. I really wonder if the hassle is > worth it though. > Regards, Jonathan Paugh From djsamperi at gmail.com Tue Sep 16 00:10:18 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Mon, 15 Sep 2014 20:10:18 -0400 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Message-ID: I think this is a great idea, but it probably needs a complementary "nudge" if it is going to have a significant impact. This could be incorporated into the package submission process where the submitter runs a final check and is warned when examples are not provided for exported functions (unless an "opt out" flag is turned on for functions that have "obvious" semantics). On Mon, Sep 15, 2014 at 1:38 PM, Richard Lewis wrote: > Hi there, > > If any of you have ever used CPAN you may > agree with me that the synopsis sections > customarily included in each package's POD > are generally invaluable for getting a quick > overview of how to use the facilities > provided by that package. > > I wonder if we might be able to encourage > the Hackage community to do something > similar? Perhaps in the cabal description > authors could include a synopsis with a > few code examples? > > Obviously, I ought to start the ball rolling but > I don't actually have any code published on > Hackage. > > Any thoughts? > > Richard > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Richard Lewis > @lewisrichard > http://web.rjlewis.me.uk/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From chak at cse.unsw.edu.au Tue Sep 16 00:42:06 2014 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Tue, 16 Sep 2014 10:42:06 +1000 Subject: [Haskell-cafe] [accelerate-haskell] [ANN] accelerate-0.15 In-Reply-To: <5416F2EC.5070508@nh2.me> References: <412E5260-16D1-48F0-86B5-8D94C5665C82@cse.unsw.edu.au> <5416F2EC.5070508@nh2.me> Message-ID: [Sorry for duplicates, but I first had the wrong sender address.] We always very gladly accept pull requests! :) In any case, please add feature requests as tickets to the GitHub issue tracker (so they don?t get lost): https://github.com/AccelerateHS/accelerate/issues We are trying our best to add requested functionality, but our resources are also very limited ? hence, any contributions are most welcome. Manuel Niklas Hamb?chen : > Excellent! > > Now here comes my number 1 feature request for the next version: > > IO/ST arrays/computations in accelerate, so that I can implement stuff > that can work on a 1GB device array with interleaved IO, without having > to download and-re-upload that array every time. > > Keep up the good work! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jays at panix.com Tue Sep 16 02:37:59 2014 From: jays at panix.com (Jay Sulzberger) Date: Mon, 15 Sep 2014 22:37:59 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: <87y4tnyf5t.fsf@gmail.com> References: <871trgmub7.fsf@gmail.com> <87y4tnyf5t.fsf@gmail.com> Message-ID: On Sat, 13 Sep 2014, Tslil Clingman wrote: > Right, so to be fair a more accurate description would have been: `It > can be shown that GHC with numerous extensions gives rise to a type > system which is Turing Complete', my mistake. I certainly didn't mean to > mislead anyone. > > All too often I conflate Haskell (2010 or so) and the capabilities of > GHC -- this is a trap which ensnares many, I suspect. > > -- > Yours &c., > Tslil Dear Tslil, my exclamation was with tongue part way in cheek, so no worry as far as I am concerned. I do not know much about Haskell, and less about GHC, but I am slowly learning. I am still not sure how far modifications to the type inferencer/checker affect the code produced, beyond whether any code at all is output. My guess today is that that most of the time, no matter what extensions are invoked, if the source type-checks, then we get the same Core output. I am still smiling at your S, K, I, and Andras's Eval. oo--JS. From michael at snoyman.com Tue Sep 16 04:13:37 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 16 Sep 2014 07:13:37 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <54177802.4060704@fuuzetsu.co.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> Message-ID: On Tue, Sep 16, 2014 at 2:36 AM, Mateusz Kowalczyk wrote: > On 09/15/2014 09:11 PM, Michael Snoyman wrote: > > I've had cases where some code I wanted to put in an example could not be > > expressed in haddock due to escaping rules. > > The parser has been improved and the escaping rules have been made > saner. You shouldn't have real problems since 2.14 release which came > out along with GHC 7.8.1. If you have problems with escaping then I'd > like to hear about it on the issue tracker rather than stumbling upon > complaints on caf?. > > I ran into these issues over four years ago, discussed them at the time, and the general consensus I got at the time was that these issues weren't going to be resolved, so I didn't follow up. I've seen nothing in recent release announcements to imply otherwise. To test this out, I put together a simple demonstration of a Hamlet synopsis in Markdown[1], and then converted it via Pandoc to Haddock[2]. I copied that Haddock content into a cabal file's description, then indented it, ran cabal haddock, and got: cabal: hamlet.cabal:30: unexpected span: "!" For some reason, the trailing exclamation point is rejected by cabal. I tried removing the exclamation point, and it *did* generate content. However, all of the content was on the same line, because I needed to add periods between each block to deal with cabal's description parsing. After adding those periods, things *mostly* worked, except that my first code sample came out as:

Hi, my name is # Notice how the {name} portion has been stripped away. So I see a number of ways that this current situation for writing synopses is inferior: 1. Far more people are comfortable writing Markdown than writing Haddock, even those of us who write a lot of Haddock. Tooling support for editing Markdown is also superior. 2. Having the synopsis in a separate file means that it's easy to give a link to the file on Github and get readable docs, which is *not* the case with linking to a cabal file. 3. I don't have to go through any preprocess step to convert from Markdown to Haddock if that's the way I want to edit. 4. Putting the synopsis in the cabal file means we have to deal with cabal rules *in addition to* Haddock rules, such as the periods between blocks and not having an exclamation point at the end of the line[3]. 5. On top of all that, Haddock still can't handle the documentation I want to write for Hamlet, to demonstrate #{variable} interpolation. So again, I really like the idea of doing the same thing for synopses as we have already for changelogs. Michael [1] http://lpaste.net/111103 [2] http://lpaste.net/111104 [3] For the record, I was completely unaware of this limitation, and stumbled upon it by accident when putting together this example. > I think just about the only thing nowadays that might surprise people is > that tokens stretch over newlines but this is by design, especially > considering one can embed code. > > > I would much rather be able to > > write a synopsis in markdown, or asciidoc, or HTML, rather than haddock > > markup. > > > > As I mention on the other e-mail, you can now use pandoc to achieve > this. If people really care then it should not be difficult to > co-ordinate with cabal + Hackage and make it parse your favourite format > and splice it into synopsis. > > I'd quite like the complaints about the existing Haddock markup, the > rules are pretty damn close to what Markdown uses. > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Tue Sep 16 04:24:22 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 16 Sep 2014 14:24:22 +1000 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> Message-ID: On 16 September 2014 14:13, Michael Snoyman wrote: > > > On Tue, Sep 16, 2014 at 2:36 AM, Mateusz Kowalczyk > wrote: >> >> On 09/15/2014 09:11 PM, Michael Snoyman wrote: >> > I've had cases where some code I wanted to put in an example could not >> > be >> > expressed in haddock due to escaping rules. >> >> The parser has been improved and the escaping rules have been made >> saner. You shouldn't have real problems since 2.14 release which came >> out along with GHC 7.8.1. If you have problems with escaping then I'd >> like to hear about it on the issue tracker rather than stumbling upon >> complaints on caf?. >> > > I ran into these issues over four years ago, discussed them at the time, and > the general consensus I got at the time was that these issues weren't going > to be resolved, so I didn't follow up. I've seen nothing in recent release > announcements to imply otherwise. To test this out, I put together a simple > demonstration of a Hamlet synopsis in Markdown[1], and then converted it via > Pandoc to Haddock[2]. I copied that Haddock content into a cabal file's > description, then indented it, ran cabal haddock, and got: > > cabal: hamlet.cabal:30: unexpected span: "!" > > For some reason, the trailing exclamation point is rejected by cabal. I > tried removing the exclamation point, and it *did* generate content. > However, all of the content was on the same line, because I needed to add > periods between each block to deal with cabal's description parsing. After > adding those periods, things *mostly* worked, except that my first code > sample came out as: > >

Hi, my name is # > > Notice how the {name} portion has been stripped away. So I see a number of > ways that this current situation for writing synopses is inferior: > > 1. Far more people are comfortable writing Markdown than writing Haddock, > even those of us who write a lot of Haddock. Tooling support for editing > Markdown is also superior. > 2. Having the synopsis in a separate file means that it's easy to give a > link to the file on Github and get readable docs, which is *not* the case > with linking to a cabal file. > 3. I don't have to go through any preprocess step to convert from Markdown > to Haddock if that's the way I want to edit. > 4. Putting the synopsis in the cabal file means we have to deal with cabal > rules *in addition to* Haddock rules, such as the periods between blocks and > not having an exclamation point at the end of the line[3]. > 5. On top of all that, Haddock still can't handle the documentation I want > to write for Hamlet, to demonstrate #{variable} interpolation. > > So again, I really like the idea of doing the same thing for synopses as we > have already for changelogs. I would instead prefer to have a Github-esque README that might be displayed on Hackage pages, and keep the synopsis as a slightly longer version of the description. The description field is used by various Cabal-based package creation tools for various *nix distributions to provide a short blurb about what a package is, whereas the short guide as to how to use a package is better suited to a README. > > Michael > > [1] http://lpaste.net/111103 > [2] http://lpaste.net/111104 > [3] For the record, I was completely unaware of this limitation, and > stumbled upon it by accident when putting together this example. > >> >> I think just about the only thing nowadays that might surprise people is >> that tokens stretch over newlines but this is by design, especially >> considering one can embed code. >> >> > I would much rather be able to >> > write a synopsis in markdown, or asciidoc, or HTML, rather than haddock >> > markup. >> > >> >> As I mention on the other e-mail, you can now use pandoc to achieve >> this. If people really care then it should not be difficult to >> co-ordinate with cabal + Hackage and make it parse your favourite format >> and splice it into synopsis. >> >> I'd quite like the complaints about the existing Haddock markup, the >> rules are pretty damn close to what Markdown uses. >> >> -- >> Mateusz K. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From michael at snoyman.com Tue Sep 16 04:28:18 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 16 Sep 2014 07:28:18 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> Message-ID: On Tue, Sep 16, 2014 at 7:24 AM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 16 September 2014 14:13, Michael Snoyman wrote: > > > > > > On Tue, Sep 16, 2014 at 2:36 AM, Mateusz Kowalczyk < > fuuzetsu at fuuzetsu.co.uk> > > wrote: > >> > >> On 09/15/2014 09:11 PM, Michael Snoyman wrote: > >> > I've had cases where some code I wanted to put in an example could not > >> > be > >> > expressed in haddock due to escaping rules. > >> > >> The parser has been improved and the escaping rules have been made > >> saner. You shouldn't have real problems since 2.14 release which came > >> out along with GHC 7.8.1. If you have problems with escaping then I'd > >> like to hear about it on the issue tracker rather than stumbling upon > >> complaints on caf?. > >> > > > > I ran into these issues over four years ago, discussed them at the time, > and > > the general consensus I got at the time was that these issues weren't > going > > to be resolved, so I didn't follow up. I've seen nothing in recent > release > > announcements to imply otherwise. To test this out, I put together a > simple > > demonstration of a Hamlet synopsis in Markdown[1], and then converted it > via > > Pandoc to Haddock[2]. I copied that Haddock content into a cabal file's > > description, then indented it, ran cabal haddock, and got: > > > > cabal: hamlet.cabal:30: unexpected span: "!" > > > > For some reason, the trailing exclamation point is rejected by cabal. I > > tried removing the exclamation point, and it *did* generate content. > > However, all of the content was on the same line, because I needed to add > > periods between each block to deal with cabal's description parsing. > After > > adding those periods, things *mostly* worked, except that my first code > > sample came out as: > > > >

Hi, my name is # > > > > Notice how the {name} portion has been stripped away. So I see a number > of > > ways that this current situation for writing synopses is inferior: > > > > 1. Far more people are comfortable writing Markdown than writing Haddock, > > even those of us who write a lot of Haddock. Tooling support for editing > > Markdown is also superior. > > 2. Having the synopsis in a separate file means that it's easy to give a > > link to the file on Github and get readable docs, which is *not* the case > > with linking to a cabal file. > > 3. I don't have to go through any preprocess step to convert from > Markdown > > to Haddock if that's the way I want to edit. > > 4. Putting the synopsis in the cabal file means we have to deal with > cabal > > rules *in addition to* Haddock rules, such as the periods between blocks > and > > not having an exclamation point at the end of the line[3]. > > 5. On top of all that, Haddock still can't handle the documentation I > want > > to write for Hamlet, to demonstrate #{variable} interpolation. > > > > So again, I really like the idea of doing the same thing for synopses as > we > > have already for changelogs. > > I would instead prefer to have a Github-esque README that might be > displayed on Hackage pages, and keep the synopsis as a slightly longer > version of the description. The description field is used by various > Cabal-based package creation tools for various *nix distributions to > provide a short blurb about what a package is, whereas the short guide > as to how to use a package is better suited to a README. > > I'm not implying that we should get rid of any existing functionality: cabal fields should remain exactly as they are now. I was proposing that, in addition, if a Synopsis.md file is present, that it be displayed on the Hackage page. But now that you bring up Github READMEs, that's clearly the right name for this proposal, so consider it amended: if a README or README.md file is present, that's what should be used. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From berdario at gmail.com Tue Sep 16 12:20:38 2014 From: berdario at gmail.com (Dario Bertini) Date: Tue, 16 Sep 2014 14:20:38 +0200 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> Message-ID: I have a Python background, and this proposal reminded me of pbr, a tool that I happened to enjoy in the last year: http://docs.openstack.org/developer/pbr/ pasted here are its features: Version: Manage version number based on git revisions and tags AUTHORS: Generate AUTHORS file from git log ChangeLog: Generate ChangeLog from git log Sphinx Autodoc: Generate autodoc stub files for your whole module Requirements: Store your dependencies in a pip requirements file long_description: Use your README file as a long_description Smart find_packages: Smartly find packages under your root package the dependencies are probably already handled sufficiently by cabal alone, but it might be interesting to handle all these things together. (I'm not big on depending on git, but pragmatically support for other vcs might be added if there's demand and contributions for it) From fuuzetsu at fuuzetsu.co.uk Tue Sep 16 15:58:36 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 16 Sep 2014 16:58:36 +0100 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> Message-ID: <54185E2C.6030006@fuuzetsu.co.uk> On 09/16/2014 05:13 AM, Michael Snoyman wrote: > On Tue, Sep 16, 2014 at 2:36 AM, Mateusz Kowalczyk > wrote: > >> On 09/15/2014 09:11 PM, Michael Snoyman wrote: >>> I've had cases where some code I wanted to put in an example could not be >>> expressed in haddock due to escaping rules. >> >> The parser has been improved and the escaping rules have been made >> saner. You shouldn't have real problems since 2.14 release which came >> out along with GHC 7.8.1. If you have problems with escaping then I'd >> like to hear about it on the issue tracker rather than stumbling upon >> complaints on caf?. >> >> > I ran into these issues over four years ago, discussed them at the time, > and the general consensus I got at the time was that these issues weren't > going to be resolved, so I didn't follow up. I've seen nothing in recent > release announcements to imply otherwise. Really? [1] has quite a few things and I even made a visual guide to each change which was quite widely circulated. IIRC it was on main list, cafe, Planet Haskell, reddit, circulated on Twitter, posted in #haskell? My nginx says the post demonstrating the changes had ~3000 hits. I don't know what more I can do to make people aware of the releases. > To test this out, I put together > a simple demonstration of a Hamlet synopsis in Markdown[1], and then > converted it via Pandoc to Haddock[2]. I copied that Haddock content into a > cabal file's description, then indented it, ran cabal haddock, and got: > > cabal: hamlet.cabal:30: unexpected span: "!" Cabal problem, no idea why it happens however, I have not looked into it. > For some reason, the trailing exclamation point is rejected by cabal. I > tried removing the exclamation point, and it *did* generate content. > However, all of the content was on the same line, because I needed to add > periods between each block to deal with cabal's description parsing. Also Cabal problem but you raise an important issue. Cabal's synopsis parsing sucks so if it could instead read from a separate file without these weird limitations, that'd be a big improvement in itself and a lot easier to automated if one wants to. > After > adding those periods, things *mostly* worked, except that my first code > sample came out as: > >

Hi, my name is # > > Notice how the {name} portion has been stripped away. So I see a number of > ways that this current situation for writing synopses is inferior: Maybe this is to do with Haddock issue #308 which was fixed in June and made it into 7.8.3 release. In fact, here[2] is the AST the parser (found in ?haddock-library? package which you can trivially install and try yourself) produces. This means I have to ask for your Haddock version. If you're on 7.8.2 or 7.8.3 you should be able to upgrade to 2.15.0 (that's right, we had another release since) simply by cabal install haddock which should demonstrate the correct behaviour. I'm surprised that you have a version without this fix unless you're stuck on 7.6.3 or something. > 1. Far more people are comfortable writing Markdown than writing Haddock, > even those of us who write a lot of Haddock. Tooling support for editing > Markdown is also superior. As usual, I point out that there are tens of different Markdown flavours. Of course today I will be pointed to the recent common Markdown creation but as far as I'm concerned, we had 14 standards and this is the 15th until it gets established. More importantly, Markdown is not suited for documenting code. We'd have to introduce new identifiers if we wanted to link to some functions from our synopsis. 16th standard aside, this is quickly starts looking like Haddock. I'm pretty sure that if you only used Haddock features that Markdown also has, you could tell someone your Haddock is a flavour of Markdown and they'd believe you. In any case, I'm not here to wage war against Markdown people but to find out why your Haddock experience is bad so let's move on. Bah, regarding tooling, with the parser now being in its own small package it's trivial to get out the AST for any snippet of text. If someone is eager then they can write emacs modes or whatever people use pretty easily now. > 2. Having the synopsis in a separate file means that it's easy to give a > link to the file on Github and get readable docs, which is *not* the case > with linking to a cabal file. I am not against this at all, I would quite like to see a separate file, it would make for much easier editing and you don't have to post-process anything spit out by tools to conform to additional cabal gotchas. > 3. I don't have to go through any preprocess step to convert from Markdown > to Haddock if that's the way I want to edit. Seems like something cabal could handle for you if it sees pandoc on your system. > 4. Putting the synopsis in the cabal file means we have to deal with cabal > rules *in addition to* Haddock rules, such as the periods between blocks > and not having an exclamation point at the end of the line[3]. Solved by your point 2. > 5. On top of all that, Haddock still can't handle the documentation I want > to write for Hamlet, to demonstrate #{variable} interpolation. As the AST at [2] demonstrates, it can. Bah, just for you I used your pandoc-generated Haddock, stuck it in a module and produced the HTML file at [3]. It looks fine to me. We probably want to teach pandoc that it can put the anchors on the same line as the headers and that it can put content on the very next line from the header which would remove excessive spacing but other than that, it looks fine to me. Notably your #{name} problem is not present. [4] houses the Haskell file used to generate the HTML. Generated with Haddock HEAD but it only is 4 commits ahead of 2.15.0 release with the only changes being some documentation stuff. > So again, I really like the idea of doing the same thing for synopses as we > have already for changelogs. I also do, I am here merely to investigate why Markdown is so strongly preferred when Haddock does the job. Yes, the escaping was really bad in the past. Yes, it had some weird bugs. Yes, it has been fixed. To my knowledge, we have zero bugs open on the issue tracker[5]. There are some that are to do with GHC lexer + parser but those are not relevant at all here. If you know of bugs then please report them. > Michael > > [1] http://lpaste.net/111103 > [2] http://lpaste.net/111104 > [3] For the record, I was completely unaware of this limitation, and > stumbled upon it by accident when putting together this example. > > >> I think just about the only thing nowadays that might surprise people is >> that tokens stretch over newlines but this is by design, especially >> considering one can embed code. >> >>> I would much rather be able tom >>> write a synopsis in markdown, or asciidoc, or HTML, rather than haddock >>> markup. >>> >> >> As I mention on the other e-mail, you can now use pandoc to achieve >> this. If people really care then it should not be difficult to >> co-ordinate with cabal + Hackage and make it parse your favourite format >> and splice it into synopsis. >> >> I'd quite like the complaints about the existing Haddock markup, the >> rules are pretty damn close to what Markdown uses. >> >> -- >> Mateusz K. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > [1]: https://github.com/haskell/haddock/blob/master/CHANGES#L55 [2]: http://lpaste.net/111124 [3]: http://fuuzetsu.co.uk/misc/md/MarkdownToHaddock.html [4]: http://lpaste.net/111125 [5]: https://github.com/haskell/haddock/issues -- Mateusz K. From dominic at steinitz.org Tue Sep 16 16:26:30 2014 From: dominic at steinitz.org (Dominic Steinitz) Date: Tue, 16 Sep 2014 17:26:30 +0100 Subject: [Haskell-cafe] Mapping over Type Level Literals In-Reply-To: References: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> Message-ID: <100F2535-7D6A-42A2-AF90-2FC448B0887D@steinitz.org> Maybe - do I need to write my own type level lists to use it? E.g. > data HList (xs :: [*]) where > Nil :: HList '[] > (:+:) :: x -> HList xs -> HList (x ': xs) Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com On 12 Sep 2014, at 16:13, Marcin Mrotek wrote: > (sorry, I think I wrote this to Dominic only originally) > > You mean something like this: > http://hub.darcs.net/mjm/type-list/browse/src/Data/Type/List.hs ? I'll > push this library to Hackage in a moment. > > Regards, > Marcin From michael at snoyman.com Tue Sep 16 17:04:16 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 16 Sep 2014 20:04:16 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <54185E2C.6030006@fuuzetsu.co.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> <54185E2C.6030006@fuuzetsu.co.uk> Message-ID: On Tue, Sep 16, 2014 at 6:58 PM, Mateusz Kowalczyk wrote: > On 09/16/2014 05:13 AM, Michael Snoyman wrote: > > > So again, I really like the idea of doing the same thing for synopses as > we > > have already for changelogs. > > I also do, I am here merely to investigate why Markdown is so strongly > preferred when Haddock does the job. Yes, the escaping was really bad in > the past. Yes, it had some weird bugs. Yes, it has been fixed. To my > knowledge, we have zero bugs open on the issue tracker[5]. There are > some that are to do with GHC lexer + parser but those are not relevant > at all here. If you know of bugs then please report them. > > I don't think I can make my point any clearer. I demonstrated that the bug I brought up four years ago still exists, that a separate file makes more sense, that people are more familiar with markdown, that existing tools (editors and sites like Github) already have very solid Markdown support. You've used the same argument multiple times: Markdown has multiple flavors. I get it, you don't like Markdown. You made that clear. But many others- myself included- *do* like Markdown, and want to be able to use it. Your arguments don't convince me that my desires are invalid. I'm not opposed to Hackage supporting multiple flavors of README files (much like Github does). But I really dislike someone saying "you shouldn't be able to edit in the file format that you like, because I have an objection to it." If you don't like Markdown, don't use it. But please don't tell me "Haddock markup is sufficient, you should use that." If you're hearing that "Markdown is so strongly preferred," maybe you should accept that people prefer Markdown. So my ideal is: Hackage chooses some Markdown implementation- I don't really care which too much- and adds support for README.md files. It can also add support for README.html, README.haddock, README.asciidoc, and README.klingon for all I care. If people run into problems because Github flavored Markdown is different than Hackage flavored Markdown... well, that's a situation that people using Markdown are used to already, and have come to terms with. I won't be put off by that. I already encounter that when I copy-paste something from a Stack Overflow answer into a Reddit comment. I can deal with it. People with objections to Markdown are perfectly free to use whatever syntax they want as well. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Tue Sep 16 17:16:31 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 16 Sep 2014 18:16:31 +0100 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> <54185E2C.6030006@fuuzetsu.co.uk> Message-ID: <5418706F.9090508@fuuzetsu.co.uk> On 09/16/2014 06:04 PM, Michael Snoyman wrote: > On Tue, Sep 16, 2014 at 6:58 PM, Mateusz Kowalczyk > wrote: > >> On 09/16/2014 05:13 AM, Michael Snoyman wrote: >> >>> So again, I really like the idea of doing the same thing for synopses as >> we >>> have already for changelogs. >> >> I also do, I am here merely to investigate why Markdown is so strongly >> preferred when Haddock does the job. Yes, the escaping was really bad in >> the past. Yes, it had some weird bugs. Yes, it has been fixed. To my >> knowledge, we have zero bugs open on the issue tracker[5]. There are >> some that are to do with GHC lexer + parser but those are not relevant >> at all here. If you know of bugs then please report them. >> >> > I don't think I can make my point any clearer. I demonstrated that the bug > I brought up four years ago still exists, ?what? I just showed you that it no longer exists, linked to the source files used to generate it with your own input and linked to output. The bug was fixed, there's nothing more to it. > that a separate file makes more sense Yes. > , that people are more familiar with markdown, that existing tools > (editors and sites like Github) already have very solid Markdown support. > You've used the same argument multiple times: Markdown has multiple > flavors. I get it, you don't like Markdown. You made that clear. But many > others- myself included- *do* like Markdown, and want to be able to use it. > Your arguments don't convince me that my desires are invalid. I don't neither dislike Markdown nor think your desires are invalid. I am only trying to understand what your problem with Haddock is. That's it. You say there's a bug, I show that it's fixed. What else is there? I only mention various Markdown flavours for a simple reason: it is to deter any potential ?Haddock should just support Markdown? posts, like seen early in this thread. > I'm not opposed to Hackage supporting multiple flavors of README files > (much like Github does). But I really dislike someone saying "you shouldn't > be able to edit in the file format that you like, because I have an > objection to it." If you don't like Markdown, don't use it. But please > don't tell me "Haddock markup is sufficient, you should use that." If > you're hearing that "Markdown is so strongly preferred," maybe you should > accept that people prefer Markdown. No, again, I didn't say what you have to use and I even told you about a tool which can make it easy for you to write whatever you want in the existing system. > So my ideal is: Hackage chooses some Markdown implementation- I don't > really care which too much- and adds support for README.md files. It can > also add support for README.html, README.haddock, README.asciidoc, and > README.klingon for all I care. If people run into problems because Github > flavored Markdown is different than Hackage flavored Markdown... well, > that's a situation that people using Markdown are used to already, and have > come to terms with. I won't be put off by that. I already encounter that > when I copy-paste something from a Stack Overflow answer into a Reddit > comment. I can deal with it. People with objections to Markdown are > perfectly free to use whatever syntax they want as well. > > Michael > OK, great. I'd still like to hear about this bug you mention as the only thing you pointed out has been fixed in June. Lastly, who is going to implement all this stuff? It's easy to wish but I'm sure you have even less time than I do. -- Mateusz K. From 0slemi0 at gmail.com Tue Sep 16 17:26:53 2014 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Tue, 16 Sep 2014 19:26:53 +0200 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> <87y4tnyf5t.fsf@gmail.com> Message-ID: > I am still not sure how far modifications to the type inferencer/checker affect the code produced, beyond whether any code at all is output. Most extensions are safe, there are a few that are known to cause (or to have caused) trouble. Safe (type-system) extensions include: MultiParamTypeClasses, FunctionalDependencies, FlexibleContexts, FlexibleInstances, LiberalTypeSynonyms, DataKinds, ConstraintKinds, GADTs, ExistentialQuantification, RankNTypes, GeneralizedNewtypeDeriving(since ghc 7.8), TypeFamilies. I would also put UndecidableInstances here, as it will not produce incorrect code, it's just that the compiler may give up on type checking. There are a couple of more, this is just to give you an idea.. Safe but never to be used extensions(except if you know -exactly- what you're doing): OverlappingInstances, IncoherentInstances Unsafe extensions: GeneralizedNewtypeDeriving(before ghc 7.8), with which one was able to implement coerce :: a -> b Regarding inference: if a type is not inferable that doesn't mean the term in question is incorrect. For example if you switch on RankNTypes very simple terms can inhabit several types. For example take f = (\x -> x). You may think f must have type :: a -> a, but a completely different type, :: (forall a. a) -> b also works (although it's not very useful). On 16 September 2014 04:37, Jay Sulzberger wrote: > > > > On Sat, 13 Sep 2014, Tslil Clingman wrote: > > Right, so to be fair a more accurate description would have been: `It >> can be shown that GHC with numerous extensions gives rise to a type >> system which is Turing Complete', my mistake. I certainly didn't mean to >> mislead anyone. >> >> All too often I conflate Haskell (2010 or so) and the capabilities of >> GHC -- this is a trap which ensnares many, I suspect. >> >> -- >> Yours &c., >> Tslil >> > > Dear Tslil, my exclamation was with tongue part way in cheek, so > no worry as far as I am concerned. I do not know much about > Haskell, and less about GHC, but I am slowly learning. I am > still not sure how far modifications to the type > inferencer/checker affect the code produced, beyond whether any > code at all is output. My guess today is that that most of the > time, no matter what extensions are invoked, if the source > type-checks, then we get the same Core output. > > I am still smiling at your S, K, I, and Andras's Eval. > > oo--JS. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Tue Sep 16 17:29:55 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 16 Sep 2014 18:29:55 +0100 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> <87y4tnyf5t.fsf@gmail.com> Message-ID: <54187393.6040608@fuuzetsu.co.uk> On 09/16/2014 06:26 PM, Andras Slemmer wrote: >> I am still not sure how far modifications to the type inferencer/checker > affect the code produced, beyond whether any code at all is output. > > Most extensions are safe, there are a few that are known to cause (or to > have caused) trouble. > > Safe (type-system) extensions include: MultiParamTypeClasses, > FunctionalDependencies, FlexibleContexts, FlexibleInstances, > LiberalTypeSynonyms, DataKinds, ConstraintKinds, GADTs, > ExistentialQuantification, RankNTypes, GeneralizedNewtypeDeriving(since ghc > 7.8), TypeFamilies. I would also put UndecidableInstances here, as it will > not produce incorrect code, it's just that the compiler may give up on type > checking. There are a couple of more, this is just to give you an idea.. > > Safe but never to be used extensions(except if you know -exactly- what > you're doing): OverlappingInstances, IncoherentInstances > > Unsafe extensions: GeneralizedNewtypeDeriving(before ghc 7.8), with which > one was able to implement coerce :: a -> b > > Regarding inference: if a type is not inferable that doesn't mean the term > in question is incorrect. For example if you switch on RankNTypes very > simple terms can inhabit several types. For example take f = (\x -> x). You > may think f must have type :: a -> a, but a completely different type, :: > (forall a. a) -> b also works (although it's not very useful). > > I don't know if I'd put TypeFamilies on there today due to https://ghc.haskell.org/trac/ghc/ticket/9562 > On 16 September 2014 04:37, Jay Sulzberger wrote: > >> >> >> >> On Sat, 13 Sep 2014, Tslil Clingman wrote: >> >> Right, so to be fair a more accurate description would have been: `It >>> can be shown that GHC with numerous extensions gives rise to a type >>> system which is Turing Complete', my mistake. I certainly didn't mean to >>> mislead anyone. >>> >>> All too often I conflate Haskell (2010 or so) and the capabilities of >>> GHC -- this is a trap which ensnares many, I suspect. >>> >>> -- >>> Yours &c., >>> Tslil >>> >> >> Dear Tslil, my exclamation was with tongue part way in cheek, so >> no worry as far as I am concerned. I do not know much about >> Haskell, and less about GHC, but I am slowly learning. I am >> still not sure how far modifications to the type >> inferencer/checker affect the code produced, beyond whether any >> code at all is output. My guess today is that that most of the >> time, no matter what extensions are invoked, if the source >> type-checks, then we get the same Core output. >> >> I am still smiling at your S, K, I, and Andras's Eval. >> >> oo--JS. >> >> -- Mateusz K. From spam at scientician.net Tue Sep 16 17:42:32 2014 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 16 Sep 2014 19:42:32 +0200 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <54185E2C.6030006@fuuzetsu.co.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> <54185E2C.6030006@fuuzetsu.co.uk> Message-ID: On 2014-09-16 17:58, Mateusz Kowalczyk wrote: > Also Cabal problem but you raise an important issue. Cabal's synopsis > parsing sucks so if it could instead read from a separate file without > these weird limitations, that'd be a big improvement in itself and a lot > easier to automated if one wants to. +1 Personally, I don't care whether it's markdown or Haddock(*), but having the ability to have the Description (and/or synopsis) in a separate file would be a definite improvement, IMO. The layering of the .cabal file format rules on top of the Haddock ones is weird and annoying in practice (extra indentation, a single . for empty lines, etc) and it would be good to be rid of those, at least. Regards, (*) Both equally misguided/flawed in my opinion, but whatevs. It's what people are using. From 0slemi0 at gmail.com Tue Sep 16 17:57:37 2014 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Tue, 16 Sep 2014 19:57:37 +0200 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: <54187393.6040608@fuuzetsu.co.uk> References: <871trgmub7.fsf@gmail.com> <87y4tnyf5t.fsf@gmail.com> <54187393.6040608@fuuzetsu.co.uk> Message-ID: > I don't know if I'd put TypeFamilies on there today due to https://ghc.haskell.org/trac/ghc/ticket/9562 Huh! you learn something everyday:D On 16 September 2014 19:29, Mateusz Kowalczyk wrote: > On 09/16/2014 06:26 PM, Andras Slemmer wrote: > >> I am still not sure how far modifications to the type inferencer/checker > > affect the code produced, beyond whether any code at all is output. > > > > Most extensions are safe, there are a few that are known to cause (or to > > have caused) trouble. > > > > Safe (type-system) extensions include: MultiParamTypeClasses, > > FunctionalDependencies, FlexibleContexts, FlexibleInstances, > > LiberalTypeSynonyms, DataKinds, ConstraintKinds, GADTs, > > ExistentialQuantification, RankNTypes, GeneralizedNewtypeDeriving(since > ghc > > 7.8), TypeFamilies. I would also put UndecidableInstances here, as it > will > > not produce incorrect code, it's just that the compiler may give up on > type > > checking. There are a couple of more, this is just to give you an idea.. > > > > Safe but never to be used extensions(except if you know -exactly- what > > you're doing): OverlappingInstances, IncoherentInstances > > > > Unsafe extensions: GeneralizedNewtypeDeriving(before ghc 7.8), with which > > one was able to implement coerce :: a -> b > > > > Regarding inference: if a type is not inferable that doesn't mean the > term > > in question is incorrect. For example if you switch on RankNTypes very > > simple terms can inhabit several types. For example take f = (\x -> x). > You > > may think f must have type :: a -> a, but a completely different type, :: > > (forall a. a) -> b also works (although it's not very useful). > > > > > > I don't know if I'd put TypeFamilies on there today due to > https://ghc.haskell.org/trac/ghc/ticket/9562 > > > On 16 September 2014 04:37, Jay Sulzberger wrote: > > > >> > >> > >> > >> On Sat, 13 Sep 2014, Tslil Clingman wrote: > >> > >> Right, so to be fair a more accurate description would have been: `It > >>> can be shown that GHC with numerous extensions gives rise to a type > >>> system which is Turing Complete', my mistake. I certainly didn't mean > to > >>> mislead anyone. > >>> > >>> All too often I conflate Haskell (2010 or so) and the capabilities of > >>> GHC -- this is a trap which ensnares many, I suspect. > >>> > >>> -- > >>> Yours &c., > >>> Tslil > >>> > >> > >> Dear Tslil, my exclamation was with tongue part way in cheek, so > >> no worry as far as I am concerned. I do not know much about > >> Haskell, and less about GHC, but I am slowly learning. I am > >> still not sure how far modifications to the type > >> inferencer/checker affect the code produced, beyond whether any > >> code at all is output. My guess today is that that most of the > >> time, no matter what extensions are invoked, if the source > >> type-checks, then we get the same Core output. > >> > >> I am still smiling at your S, K, I, and Andras's Eval. > >> > >> oo--JS. > >> > >> > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 16 18:13:21 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 16 Sep 2014 14:13:21 -0400 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> <87y4tnyf5t.fsf@gmail.com> Message-ID: On Tue, Sep 16, 2014 at 1:26 PM, Andras Slemmer <0slemi0 at gmail.com> wrote: > Safe but never to be used extensions(except if you know -exactly- what > you're doing): OverlappingInstances, IncoherentInstances Are we sure that different parts of a program inferring different instances can't create at least a limited form of unsafeCoerce? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 16 18:16:08 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 16 Sep 2014 14:16:08 -0400 Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> <87y4tnyf5t.fsf@gmail.com> Message-ID: On Tue, Sep 16, 2014 at 2:13 PM, Brandon Allbery wrote: > On Tue, Sep 16, 2014 at 1:26 PM, Andras Slemmer <0slemi0 at gmail.com> wrote: > >> Safe but never to be used extensions(except if you know -exactly- what >> you're doing): OverlappingInstances, IncoherentInstances > > > Are we sure that different parts of a program inferring different > instances can't create at least a limited form of unsafeCoerce? > ...and I think the already mentioned ticket just confirmed that it's at least potentially possible via hs-boot files, although I was thinking of a slightly more "direct" mechanism. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From britt.mathis at gmail.com Tue Sep 16 18:23:28 2014 From: britt.mathis at gmail.com (Britt Mathis) Date: Tue, 16 Sep 2014 14:23:28 -0400 Subject: [Haskell-cafe] Hackage package "synopsis" sections Message-ID: I meant to post this about 30 minutes ago, but I accidentally sent it only to Michael Snoyman. It seems to me that there are two use cases here - documentation inside code and documentation that stands alone. I agree with you, Michael, that there is no reason why you shouldn't be able to use whichever documentation method you prefer in your readme file. Since it stands alone, it should be trivial to include support for a multitude of formats and display the resulting documentation on Hackage. I think where Mateusz' opinion differs is on the inclusion of markdown in source files (correct me if I am wrong): > More importantly, Markdown > is not suited for documenting code. We'd have to introduce new > identifiers if we wanted to link to some functions from our synopsis. > 16th standard aside, this is quickly starts looking like Haddock. As he says, there are problems with using markdown this way. I think it would be beneficial to have a defacto standard for documentation that lives inside source files - this would prevent it from changing from file to file and provide consistency across the community's code-base. Because the haskell community controls haddock it is in a better position to evolve to our needs. Some flavor of markdown that has a user-base outside the haskell community may not be willing to incorporate changes that make it a better fit for living inside haskell source files, so we would have to maintain our own fork of it anyway. Why duplicate the work that has already been done? I think if the community has a problem with haddock syntax that can be discussed and, if need be, changed. But I do believe that there should be consistency in source file documentation. The last problem I see is the cabal problem. It seems that cabal has trouble handling edge cases, and I think that is again something we can work on (I may even look into it myself - I have been looking for a project). It seems like it would be a good idea to only include small blurbs about the project in the .cabal file, and to separate the larger documentation into a README file, like is done on github. The reasoning behind this is two-fold: 1) Cabal files are human readable. They give us insight into the dependencies a project requires, and including full documentation here would make it harder to get a quick overview of the project (I know most people use hackage for this, but cabal was chosen over formats like XML specifically because it was meant to be read and understood by humans). 2) Separating the README file allows users to choose their favorite format, and be certain that it will be formatted as it was intended (cabal can't be expected to handle every edge case of every format - there are far too many, and Pandoc already does a great job translating between formats). From allbery.b at gmail.com Tue Sep 16 18:24:09 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 16 Sep 2014 14:24:09 -0400 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> <54185E2C.6030006@fuuzetsu.co.uk> Message-ID: On Tue, Sep 16, 2014 at 1:04 PM, Michael Snoyman wrote: > I don't think I can make my point any clearer. I demonstrated that the bug > I brought up four years ago still exists, that a separate file makes more > sense, that people are more familiar with markdown, that existing tools > (editors and sites like Github) already have very solid Markdown support. > You've used the same argument multiple times: Markdown has multiple > flavors. I get it, you don't like Markdown. You made that clear. But many > others- myself included- *do* like Markdown, and want to be able to use it. > Your arguments don't convince me that my desires are invalid. I don;t see where you have, ever, even tried to address the concerns of incompatibility, including backward incompatibility. Should I assume that, since you have never had trouble with this (probably because you consider it a "bug" in haddock, the claim to said bug of course actually being that it ever existed in the first place --- if you actually think about the implications...), nobody else should ever have had such problems either? Basically, while you claim that Mateusz's entire argument is "he doesn't like Markdown", *your* entire argument boils down to "everyone but Me is wrong with a side helping of "whoever invented Haddock forgot to get My blessing first". Talking past each other in such way is not constructive. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Sep 16 18:36:11 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 16 Sep 2014 14:36:11 -0400 Subject: [Haskell-cafe] Mapping over Type Level Literals In-Reply-To: <100F2535-7D6A-42A2-AF90-2FC448B0887D@steinitz.org> References: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> <100F2535-7D6A-42A2-AF90-2FC448B0887D@steinitz.org> Message-ID: if you're going that route, the Hlist package has a lot of machinery! https://hackage.haskell.org/package/HList worth checking out On Tue, Sep 16, 2014 at 12:26 PM, Dominic Steinitz wrote: > Maybe - do I need to write my own type level lists to use it? E.g. > > > data HList (xs :: [*]) where > > Nil :: HList '[] > > (:+:) :: x -> HList xs -> HList (x ': xs) > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > > On 12 Sep 2014, at 16:13, Marcin Mrotek > wrote: > > > (sorry, I think I wrote this to Dominic only originally) > > > > You mean something like this: > > http://hub.darcs.net/mjm/type-list/browse/src/Data/Type/List.hs ? I'll > > push this library to Hackage in a moment. > > > > Regards, > > Marcin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Sep 16 18:38:09 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 16 Sep 2014 21:38:09 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <5418706F.9090508@fuuzetsu.co.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> <54185E2C.6030006@fuuzetsu.co.uk> <5418706F.9090508@fuuzetsu.co.uk> Message-ID: On Tue, Sep 16, 2014 at 8:16 PM, Mateusz Kowalczyk wrote: > On 09/16/2014 06:04 PM, Michael Snoyman wrote: > > On Tue, Sep 16, 2014 at 6:58 PM, Mateusz Kowalczyk < > fuuzetsu at fuuzetsu.co.uk> > > wrote: > > > >> On 09/16/2014 05:13 AM, Michael Snoyman wrote: > >> > >>> So again, I really like the idea of doing the same thing for synopses > as > >> we > >>> have already for changelogs. > >> > >> I also do, I am here merely to investigate why Markdown is so strongly > >> preferred when Haddock does the job. Yes, the escaping was really bad in > >> the past. Yes, it had some weird bugs. Yes, it has been fixed. To my > >> knowledge, we have zero bugs open on the issue tracker[5]. There are > >> some that are to do with GHC lexer + parser but those are not relevant > >> at all here. If you know of bugs then please report them. > >> > >> > > I don't think I can make my point any clearer. I demonstrated that the > bug > > I brought up four years ago still exists, > > ?what? I just showed you that it no longer exists, linked to the source > files used to generate it with your own input and linked to output. The > bug was fixed, there's nothing more to it. > > I think you're discussing a strawman. The original proposal I made is "let's do Markdown in a separate file, because the current cabal + Haddock situation doesn't work." I demonstrated that. You're now saying that "it's not Haddock, it's cabal." That may be true, but it doesn't negate my point in the least: we could realize use an alternative, and the alternative I'd like is README.md. > > that a separate file makes more sense > > Yes. > > > , that people are more familiar with markdown, that existing tools > > (editors and sites like Github) already have very solid Markdown support. > > You've used the same argument multiple times: Markdown has multiple > > flavors. I get it, you don't like Markdown. You made that clear. But many > > others- myself included- *do* like Markdown, and want to be able to use > it. > > Your arguments don't convince me that my desires are invalid. > > I don't neither dislike Markdown nor think your desires are invalid. I > am only trying to understand what your problem with Haddock is. That's > it. You say there's a bug, I show that it's fixed. What else is there? > > I only mention various Markdown flavours for a simple reason: it is to > deter any potential ?Haddock should just support Markdown? posts, like > seen early in this thread. > > It comes down to the fact that I like writing Markdown. Honestly, that's enough. As for the *reason* I like Markdown: it's because I'm __always__ writing Markdown. When I'm on Github's wiki or issue tracker, on Reddit, on Stack Overflow, on School of Haskell, or my blog. If you pay attention, even this email is Markdown-formatted. To my knowledge, Github does *not* support Haddock format, so I'd have to maintain both a README.md and README.haddock (part of the tooling issue I brought up). And on top of all that: I believe there are things that can be expressed in Markdown (via HTML blocks) that simply cannot be expressed in Haddock, such as tables. I could be mistaken on that point, however, can you clarify? > > I'm not opposed to Hackage supporting multiple flavors of README files > > (much like Github does). But I really dislike someone saying "you > shouldn't > > be able to edit in the file format that you like, because I have an > > objection to it." If you don't like Markdown, don't use it. But please > > don't tell me "Haddock markup is sufficient, you should use that." If > > you're hearing that "Markdown is so strongly preferred," maybe you should > > accept that people prefer Markdown. > > No, again, I didn't say what you have to use and I even told you about a > tool which can make it easy for you to write whatever you want in the > existing system. > > That's a non-starter and a cop-out. Saying "Hackage will only support Haddock, but you can use Markdown and manually convert to Haddock and hope that the conversion is lossless" is just another way of saying "you have to use Haddock." > > So my ideal is: Hackage chooses some Markdown implementation- I don't > > really care which too much- and adds support for README.md files. It can > > also add support for README.html, README.haddock, README.asciidoc, and > > README.klingon for all I care. If people run into problems because Github > > flavored Markdown is different than Hackage flavored Markdown... well, > > that's a situation that people using Markdown are used to already, and > have > > come to terms with. I won't be put off by that. I already encounter that > > when I copy-paste something from a Stack Overflow answer into a Reddit > > comment. I can deal with it. People with objections to Markdown are > > perfectly free to use whatever syntax they want as well. > > > > Michael > > > > OK, great. I'd still like to hear about this bug you mention as the only > thing you pointed out has been fixed in June. > > Lastly, who is going to implement all this stuff? It's easy to wish but > I'm sure you have even less time than I do. > > That's a great question, but irrelevant to whether this is a good feature. I'd rather figure out the first than conflate it with the second. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Sep 16 18:41:37 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 16 Sep 2014 21:41:37 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> <54185E2C.6030006@fuuzetsu.co.uk> Message-ID: On Tue, Sep 16, 2014 at 9:24 PM, Brandon Allbery wrote: > On Tue, Sep 16, 2014 at 1:04 PM, Michael Snoyman > wrote: > >> I don't think I can make my point any clearer. I demonstrated that the >> bug I brought up four years ago still exists, that a separate file makes >> more sense, that people are more familiar with markdown, that existing >> tools (editors and sites like Github) already have very solid Markdown >> support. You've used the same argument multiple times: Markdown has >> multiple flavors. I get it, you don't like Markdown. You made that clear. >> But many others- myself included- *do* like Markdown, and want to be able >> to use it. Your arguments don't convince me that my desires are invalid. > > > I don;t see where you have, ever, even tried to address the concerns of > incompatibility, including backward incompatibility. Should I assume that, > since you have never had trouble with this (probably because you consider > it a "bug" in haddock, the claim to said bug of course actually being that > it ever existed in the first place --- if you actually think about the > implications...), nobody else should ever have had such problems either? > > Basically, while you claim that Mateusz's entire argument is "he doesn't > like Markdown", *your* entire argument boils down to "everyone but Me is > wrong with a side helping of "whoever invented Haddock forgot to get My > blessing first". Talking past each other in such way is not constructive. > > > I can honestly say I don't understand what you're ascribing to me here. The parenthetical in your first paragraph is particularly confusing to me. Anyway, I *did* clarify quite clearly my opinion on incompatibility: Hackage should pick an implementation and advertise that's what it's using. It's what everyone else does, and people are mostly happy with it. Are there rough edges? Certainly. Would it be better if there was a single, perfect Markdown implementation? Yup. But I'd be OK with just any implementation. Your last paragraph completely and utterly misrepresented my entire argument. I said I wanted support for Markdown as one of an array of options for a README file. How on earth did you derive from this that I needed to bless Haddock? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Tue Sep 16 18:57:38 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 16 Sep 2014 19:57:38 +0100 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> <54185E2C.6030006@fuuzetsu.co.uk> <5418706F.9090508@fuuzetsu.co.uk> Message-ID: <54188822.6060503@fuuzetsu.co.uk> On 09/16/2014 07:38 PM, Michael Snoyman wrote: > On Tue, Sep 16, 2014 at 8:16 PM, Mateusz Kowalczyk > wrote: > >> On 09/16/2014 06:04 PM, Michael Snoyman wrote: >>> On Tue, Sep 16, 2014 at 6:58 PM, Mateusz Kowalczyk < >> fuuzetsu at fuuzetsu.co.uk> >>> wrote: >>> >>>> On 09/16/2014 05:13 AM, Michael Snoyman wrote: >>>> >>>>> So again, I really like the idea of doing the same thing for synopses >> as >>>> we >>>>> have already for changelogs. >>>> >>>> I also do, I am here merely to investigate why Markdown is so strongly >>>> preferred when Haddock does the job. Yes, the escaping was really bad in >>>> the past. Yes, it had some weird bugs. Yes, it has been fixed. To my >>>> knowledge, we have zero bugs open on the issue tracker[5]. There are >>>> some that are to do with GHC lexer + parser but those are not relevant >>>> at all here. If you know of bugs then please report them. >>>> >>>> >>> I don't think I can make my point any clearer. I demonstrated that the >> bug >>> I brought up four years ago still exists, >> >> ?what? I just showed you that it no longer exists, linked to the source >> files used to generate it with your own input and linked to output. The >> bug was fixed, there's nothing more to it. >> >> > I think you're discussing a strawman. The original proposal I made is > "let's do Markdown in a separate file, because the current cabal + Haddock > situation doesn't work." I demonstrated that. You're now saying that "it's > not Haddock, it's cabal." That may be true, but it doesn't negate my point > in the least: we could realize use an alternative, and the alternative I'd > like is README.md. OK, if that's what you want then that's fine. I am simply trying to clarify that it's not ?let's use Markdown because Haddock can't do X, Y and Z?. > >>> that a separate file makes more sense >> >> Yes. >> >>> , that people are more familiar with markdown, that existing tools >>> (editors and sites like Github) already have very solid Markdown support. >>> You've used the same argument multiple times: Markdown has multiple >>> flavors. I get it, you don't like Markdown. You made that clear. But many >>> others- myself included- *do* like Markdown, and want to be able to use >> it. >>> Your arguments don't convince me that my desires are invalid. >> >> I don't neither dislike Markdown nor think your desires are invalid. I >> am only trying to understand what your problem with Haddock is. That's >> it. You say there's a bug, I show that it's fixed. What else is there? >> >> I only mention various Markdown flavours for a simple reason: it is to >> deter any potential ?Haddock should just support Markdown? posts, like >> seen early in this thread. >> >> > It comes down to the fact that I like writing Markdown. Honestly, that's > enough. As for the *reason* I like Markdown: it's because I'm __always__ > writing Markdown. When I'm on Github's wiki or issue tracker, on Reddit, on > Stack Overflow, on School of Haskell, or my blog. If you pay attention, > even this email is Markdown-formatted. To my knowledge, Github does *not* > support Haddock format, so I'd have to maintain both a README.md and > README.haddock (part of the tooling issue I brought up). Fair. > And on top of all that: I believe there are things that can be expressed in > Markdown (via HTML blocks) that simply cannot be expressed in Haddock, such > as tables. I could be mistaken on that point, however, can you clarify? It is correct you can't include HTML for the same reason we don't allow embedding LaTeX: we want to be able to target multiple back-ends and it is unclear what to do with HTML when rendering as LaTeX and vice-versa. So you're correct that Haddock is not suited as a formatting tool for web pages, it's a code documentation tool. It does go the other way too by the way, Markdown won't let you link to modules, identifiers and all that, so Markdown is not suited for code documentation. It really depends what you're after I suppose. > >>> I'm not opposed to Hackage supporting multiple flavors of README files >>> (much like Github does). But I really dislike someone saying "you >> shouldn't >>> be able to edit in the file format that you like, because I have an >>> objection to it." If you don't like Markdown, don't use it. But please >>> don't tell me "Haddock markup is sufficient, you should use that." If >>> you're hearing that "Markdown is so strongly preferred," maybe you should >>> accept that people prefer Markdown. >> >> No, again, I didn't say what you have to use and I even told you about a >> tool which can make it easy for you to write whatever you want in the >> existing system. >> >> > That's a non-starter and a cop-out. Saying "Hackage will only support > Haddock, but you can use Markdown and manually convert to Haddock and hope > that the conversion is lossless" is just another way of saying "you have to > use Haddock." I specifically said ?existing system?. If you *right now* wanted to be able to write your comments/synopsis in Markdown then you can, it's just not Hackage-native. > >>> So my ideal is: Hackage chooses some Markdown implementation- I don't >>> really care which too much- and adds support for README.md files. It can >>> also add support for README.html, README.haddock, README.asciidoc, and >>> README.klingon for all I care. If people run into problems because Github >>> flavored Markdown is different than Hackage flavored Markdown... well, >>> that's a situation that people using Markdown are used to already, and >> have >>> come to terms with. I won't be put off by that. I already encounter that >>> when I copy-paste something from a Stack Overflow answer into a Reddit >>> comment. I can deal with it. People with objections to Markdown are >>> perfectly free to use whatever syntax they want as well. >>> >>> Michael >>> >> >> OK, great. I'd still like to hear about this bug you mention as the only >> thing you pointed out has been fixed in June. >> >> Lastly, who is going to implement all this stuff? It's easy to wish but >> I'm sure you have even less time than I do. >> >> > That's a great question, but irrelevant to whether this is a good feature. > I'd rather figure out the first than conflate it with the second. > > Michael > OK, to summarise: * separate file for synopsis is a good idea * Currently Hackage only supports Haddock descriptions * Ideally Hackage should support more formats * You want to use Markdown as one of the formats because you like it rather than because Haddock has bugs which stop you from doing so. * The workaround to be able to use Markdown before this proposal is implemented is to use pandoc As long as there is no disagreement as to this summary, we are on the same page, I consider the previous exchange more of a miscommunication rather than disagreement. -- Mateusz K. From richard at rjlewis.me.uk Tue Sep 16 21:10:08 2014 From: richard at rjlewis.me.uk (Richard Lewis) Date: Tue, 16 Sep 2014 22:10:08 +0100 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> Message-ID: <87r3zb1dcf.wl%richard@rjlewis.me.uk> So there's clearly an important technical hurdle to be overcome for this: what markup language is to be used?; and where should the synposis be stored? But I can't help thinking that the real work is in getting the synopses written. Encouraging package authors/maintainers to add them to their own packages is one possible way forward. At Mon, 15 Sep 2014 11:28:38 -0700, Tikhon Jelvis wrote: > Maybe we could have a guerrilla campaign of pull requests adding > examples and a bit of explanation to every package you like that > doesn't have them... That could also be a good way for beginners who > want to contribute to start. Another, as Tikhon suggests, would be for others to write them and send pull requests (or whatever) to the maintainers. At Mon, 15 Sep 2014 20:10:18 -0400, Dominick Samperi wrote: > I think this is a great idea, but it probably needs a complementary > "nudge" if it is going to have a significant impact. This could be > incorporated into the package submission process where the submitter > runs a final check and is warned when examples are not provided for > exported functions (unless an "opt out" flag is turned on for > functions that have "obvious" semantics). And yet another, as Dominick suggests, is effectively to require a synposis when a package is submitted. In CPAN, it's just become part of the culture, but it's also not required and you do find packages without a synposis. If there's interest, I'd like to solicit some discussion on this part of the proposal on this thread... There may also be a potentially significant difference between Hackage/Haskell and CPAN/Perl: most CPAN packages tend to be quite small and specific in their purpose and consequently have just a few, simple common use cases which suit a synposis very well. Hackage packages, on the other hand, are quite often more broad in their scope, often comprising many modules. Also, Perl has only one semantics for organising code at the finest level: sequential, imperative statements. In Haskell, some packages actually define whole coding styles. As a result, it's always pretty obvious how to write a few isolated lines of Perl code, but not necessarily so with Haskell code. Anyway, I'm sure all this can be overcome, and/or argued against. Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis j: ironchicken at jabber.earth.li @: lewisrichard http://www.richardlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From jays at panix.com Tue Sep 16 21:54:35 2014 From: jays at panix.com (Jay Sulzberger) Date: Tue, 16 Sep 2014 17:54:35 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> <87y4tnyf5t.fsf@gmail.com> Message-ID: On Tue, 16 Sep 2014, Andras Slemmer <0slemi0 at gmail.com> wrote: >> I am still not sure how far modifications to the type inferencer/checker > affect the code produced, beyond whether any code at all is output. > > Most extensions are safe, there are a few that are known to cause (or to > have caused) trouble. > > Safe (type-system) extensions include: MultiParamTypeClasses, > FunctionalDependencies, FlexibleContexts, FlexibleInstances, > LiberalTypeSynonyms, DataKinds, ConstraintKinds, GADTs, > ExistentialQuantification, RankNTypes, GeneralizedNewtypeDeriving(since ghc > 7.8), TypeFamilies. I would also put UndecidableInstances here, as it will > not produce incorrect code, it's just that the compiler may give up on type > checking. There are a couple of more, this is just to give you an idea.. > > Safe but never to be used extensions(except if you know -exactly- what > you're doing): OverlappingInstances, IncoherentInstances > > Unsafe extensions: GeneralizedNewtypeDeriving(before ghc 7.8), with which > one was able to implement coerce :: a -> b > > Regarding inference: if a type is not inferable that doesn't mean the term > in question is incorrect. For example if you switch on RankNTypes very > simple terms can inhabit several types. For example take f = (\x -> x). You > may think f must have type :: a -> a, but a completely different type, :: > (forall a. a) -> b also works (although it's not very useful). Thanks, Andras! OK, I have read further in the thread and now looked at https://ghc.haskell.org/trac/ghc/ticket/9562 and at http://www.haskell.org/haskellwiki/GHC/Type_families ad TypeFamilies: One may distinguish two kinds of extensions of a type inferencer/checker: 1. a pure syntactical sugar extension 2. an extension that modifies the type inferencer/checker A pure sugar extension works as follows: The source code is re-written and the re-written code is passed to the usual type inferencer/checker, from which point all proceeds same as before. An extension of kind 2 is a modification of the usual type inferencer/checker, which modified engine is then run. Of course there might be some source to source rewriting before running the modified engine. Question: Is TypeFamilies an extension of kind 1, or of kind 2? oo--JS. > > > On 16 September 2014 04:37, Jay Sulzberger wrote: > >> >> >> >> On Sat, 13 Sep 2014, Tslil Clingman wrote: >> >> Right, so to be fair a more accurate description would have been: `It >>> can be shown that GHC with numerous extensions gives rise to a type >>> system which is Turing Complete', my mistake. I certainly didn't mean to >>> mislead anyone. >>> >>> All too often I conflate Haskell (2010 or so) and the capabilities of >>> GHC -- this is a trap which ensnares many, I suspect. >>> >>> -- >>> Yours &c., >>> Tslil >>> >> >> Dear Tslil, my exclamation was with tongue part way in cheek, so >> no worry as far as I am concerned. I do not know much about >> Haskell, and less about GHC, but I am slowly learning. I am >> still not sure how far modifications to the type >> inferencer/checker affect the code produced, beyond whether any >> code at all is output. My guess today is that that most of the >> time, no matter what extensions are invoked, if the source >> type-checks, then we get the same Core output. >> >> I am still smiling at your S, K, I, and Andras's Eval. >> >> oo--JS. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From mail at nh2.me Tue Sep 16 22:07:42 2014 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Wed, 17 Sep 2014 00:07:42 +0200 Subject: [Haskell-cafe] Temporarily taking over hdevtools on Hackage In-Reply-To: References: Message-ID: <5418B4AE.6060500@nh2.me> Would you mind following up on this? This is sorely needed. Or what carter said to ask for trustee upload on libraries at haskell.org. On 09/09/14 18:27, Schell Scivally wrote: > I talked with Erik the admin at hackage about taking over hdevtools and he > suggested waiting another week before invading. In the meantime he > suggested asking a hackage trustee to please upload this git branch to > hackage (https://github.com/schell/hdevtools/tree/cabal-support-ghc7.8). > Thank you and let me know if there is anything else I can do to help! From carter.schonwald at gmail.com Tue Sep 16 22:10:28 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 16 Sep 2014 18:10:28 -0400 Subject: [Haskell-cafe] Temporarily taking over hdevtools on Hackage In-Reply-To: <5418B4AE.6060500@nh2.me> References: <5418B4AE.6060500@nh2.me> Message-ID: no, i'm saying please make this request via the libraries list On Tue, Sep 16, 2014 at 6:07 PM, Niklas Hamb?chen wrote: > Would you mind following up on this? > > This is sorely needed. > > Or what carter said to ask for trustee upload on libraries at haskell.org. > > On 09/09/14 18:27, Schell Scivally wrote: > > I talked with Erik the admin at hackage about taking over hdevtools and he > > suggested waiting another week before invading. In the meantime he > > suggested asking a hackage trustee to please upload this git branch to > > hackage (https://github.com/schell/hdevtools/tree/cabal-support-ghc7.8). > > Thank you and let me know if there is anything else I can do to help! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Sep 16 22:47:25 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 16 Sep 2014 18:47:25 -0400 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <87r3zb1dcf.wl%richard@rjlewis.me.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <87r3zb1dcf.wl%richard@rjlewis.me.uk> Message-ID: the Elephant in the room of course is that making anything happen requires people contribute to hackage :) https://github.com/haskell/hackage-server/ PRs are welcome, fire the missiles On Tue, Sep 16, 2014 at 5:10 PM, Richard Lewis wrote: > So there's clearly an important technical hurdle to be overcome for > this: what markup language is to be used?; and where should the > synposis be stored? > > But I can't help thinking that the real work is in getting the > synopses written. Encouraging package authors/maintainers to add them > to their own packages is one possible way forward. > > At Mon, 15 Sep 2014 11:28:38 -0700, > Tikhon Jelvis wrote: > > > Maybe we could have a guerrilla campaign of pull requests adding > > examples and a bit of explanation to every package you like that > > doesn't have them... That could also be a good way for beginners who > > want to contribute to start. > > Another, as Tikhon suggests, would be for others to write them and > send pull requests (or whatever) to the maintainers. > > At Mon, 15 Sep 2014 20:10:18 -0400, > Dominick Samperi wrote: > > > I think this is a great idea, but it probably needs a complementary > > "nudge" if it is going to have a significant impact. This could be > > incorporated into the package submission process where the submitter > > runs a final check and is warned when examples are not provided for > > exported functions (unless an "opt out" flag is turned on for > > functions that have "obvious" semantics). > > And yet another, as Dominick suggests, is effectively to require a > synposis when a package is submitted. In CPAN, it's just become part > of the culture, but it's also not required and you do find packages > without a synposis. > > If there's interest, I'd like to solicit some discussion on this part > of the proposal on this thread... > > There may also be a potentially significant difference between > Hackage/Haskell and CPAN/Perl: most CPAN packages tend to be quite > small and specific in their purpose and consequently have just a few, > simple common use cases which suit a synposis very well. Hackage > packages, on the other hand, are quite often more broad in their > scope, often comprising many modules. Also, Perl has only one > semantics for organising code at the finest level: sequential, > imperative statements. In Haskell, some packages actually define whole > coding styles. As a result, it's always pretty obvious how to write a > few isolated lines of Perl code, but not necessarily so with Haskell > code. Anyway, I'm sure all this can be overcome, and/or argued > against. > > Richard > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Richard Lewis > j: ironchicken at jabber.earth.li > @: lewisrichard > http://www.richardlewis.me.uk/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Tue Sep 16 23:17:35 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Tue, 16 Sep 2014 19:17:35 -0400 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <87r3zb1dcf.wl%richard@rjlewis.me.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <87r3zb1dcf.wl%richard@rjlewis.me.uk> Message-ID: For an example of this kind of policy see the R system. Here the final check issues warnings when exported functions are not documented. This strategy is not perfect as a submitter can always provide dummy docs that keep the checker quiet but do not provide much assistance to the end user. On the other hand, R functions tend to be documented well, and almost always include working examples in the help page that can be run from the command prompt via: help(function-name). On Tue, Sep 16, 2014 at 5:10 PM, Richard Lewis wrote: > So there's clearly an important technical hurdle to be overcome for > this: what markup language is to be used?; and where should the > synposis be stored? > > But I can't help thinking that the real work is in getting the > synopses written. Encouraging package authors/maintainers to add them > to their own packages is one possible way forward. > > At Mon, 15 Sep 2014 11:28:38 -0700, > Tikhon Jelvis wrote: > >> Maybe we could have a guerrilla campaign of pull requests adding >> examples and a bit of explanation to every package you like that >> doesn't have them... That could also be a good way for beginners who >> want to contribute to start. > > Another, as Tikhon suggests, would be for others to write them and > send pull requests (or whatever) to the maintainers. > > At Mon, 15 Sep 2014 20:10:18 -0400, > Dominick Samperi wrote: > >> I think this is a great idea, but it probably needs a complementary >> "nudge" if it is going to have a significant impact. This could be >> incorporated into the package submission process where the submitter >> runs a final check and is warned when examples are not provided for >> exported functions (unless an "opt out" flag is turned on for >> functions that have "obvious" semantics). > > And yet another, as Dominick suggests, is effectively to require a > synposis when a package is submitted. In CPAN, it's just become part > of the culture, but it's also not required and you do find packages > without a synposis. > > If there's interest, I'd like to solicit some discussion on this part > of the proposal on this thread... > > There may also be a potentially significant difference between > Hackage/Haskell and CPAN/Perl: most CPAN packages tend to be quite > small and specific in their purpose and consequently have just a few, > simple common use cases which suit a synposis very well. Hackage > packages, on the other hand, are quite often more broad in their > scope, often comprising many modules. Also, Perl has only one > semantics for organising code at the finest level: sequential, > imperative statements. In Haskell, some packages actually define whole > coding styles. As a result, it's always pretty obvious how to write a > few isolated lines of Perl code, but not necessarily so with Haskell > code. Anyway, I'm sure all this can be overcome, and/or argued > against. > > Richard > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Richard Lewis > j: ironchicken at jabber.earth.li > @: lewisrichard > http://www.richardlewis.me.uk/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jays at panix.com Wed Sep 17 02:20:46 2014 From: jays at panix.com (Jay Sulzberger) Date: Tue, 16 Sep 2014 22:20:46 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: References: <871trgmub7.fsf@gmail.com> <87y4tnyf5t.fsf@gmail.com> Message-ID: On Tue, 16 Sep 2014, Jay Sulzberger wrote: > > On Tue, 16 Sep 2014, Andras Slemmer <0slemi0 at gmail.com> wrote: > >>> I am still not sure how far modifications to the type inferencer/checker >> affect the code produced, beyond whether any code at all is output. >> >> Most extensions are safe, there are a few that are known to cause (or to >> have caused) trouble. >> >> Safe (type-system) extensions include: MultiParamTypeClasses, >> FunctionalDependencies, FlexibleContexts, FlexibleInstances, >> LiberalTypeSynonyms, DataKinds, ConstraintKinds, GADTs, >> ExistentialQuantification, RankNTypes, GeneralizedNewtypeDeriving(since ghc >> 7.8), TypeFamilies. I would also put UndecidableInstances here, as it will >> not produce incorrect code, it's just that the compiler may give up on type >> checking. There are a couple of more, this is just to give you an idea.. >> >> Safe but never to be used extensions(except if you know -exactly- what >> you're doing): OverlappingInstances, IncoherentInstances >> >> Unsafe extensions: GeneralizedNewtypeDeriving(before ghc 7.8), with which >> one was able to implement coerce :: a -> b >> >> Regarding inference: if a type is not inferable that doesn't mean the term >> in question is incorrect. For example if you switch on RankNTypes very >> simple terms can inhabit several types. For example take f = (\x -> x). You >> may think f must have type :: a -> a, but a completely different type, :: >> (forall a. a) -> b also works (although it's not very useful). > > Thanks, Andras! > > OK, I have read further in the thread and now looked at > > https://ghc.haskell.org/trac/ghc/ticket/9562 > > and at > > http://www.haskell.org/haskellwiki/GHC/Type_families > > ad TypeFamilies: One may distinguish two kinds of extensions of > a type inferencer/checker: > > 1. a pure syntactical sugar extension > > 2. an extension that modifies the type inferencer/checker > > A pure sugar extension works as follows: > > The source code is re-written and the re-written code is passed > to the usual type inferencer/checker, from which point all > proceeds same as before. > > An extension of kind 2 is a modification of the usual type > inferencer/checker, which modified engine is then run. Of course > there might be some source to source rewriting before running the > modified engine. > > Question: Is TypeFamilies an extension of kind 1, or of kind 2? > > oo--JS. OK, my guess after looking at the paper System F with Type Equality Coercions by M. Sulzmann et al pointed to on the page http://www.cse.unsw.edu.au/~chak/papers/SCPD07.html is that GHC's type inferencer/checker is today different from what it was before TypeFamilies, and a few other recent faculties. In related news, Brent Abraham Yorgey has a version of his thesis "Combinatorial Species and Labelled Structures" available via: http://byorgey.wordpress.com/2014/08/10/readers-wanted/ oo--JS. > > > >> >> >> On 16 September 2014 04:37, Jay Sulzberger wrote: >> >>> >>> >>> >>> On Sat, 13 Sep 2014, Tslil Clingman wrote: >>> >>> Right, so to be fair a more accurate description would have been: `It >>>> can be shown that GHC with numerous extensions gives rise to a type >>>> system which is Turing Complete', my mistake. I certainly didn't mean to >>>> mislead anyone. >>>> >>>> All too often I conflate Haskell (2010 or so) and the capabilities of >>>> GHC -- this is a trap which ensnares many, I suspect. >>>> >>>> -- >>>> Yours &c., >>>> Tslil >>>> >>> >>> Dear Tslil, my exclamation was with tongue part way in cheek, so >>> no worry as far as I am concerned. I do not know much about >>> Haskell, and less about GHC, but I am slowly learning. I am >>> still not sure how far modifications to the type >>> inferencer/checker affect the code produced, beyond whether any >>> code at all is output. My guess today is that that most of the >>> time, no matter what extensions are invoked, if the source >>> type-checks, then we get the same Core output. >>> >>> I am still smiling at your S, K, I, and Andras's Eval. >>> >>> oo--JS. >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > From kazu at iij.ad.jp Wed Sep 17 03:41:39 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 17 Sep 2014 12:41:39 +0900 (JST) Subject: [Haskell-cafe] a question about cabal files Message-ID: <20140917.124139.409336689002464402.kazu@iij.ad.jp> Hi cafe, I'm developing a library. In this package, some tools for development are included. I would like to compile these tools when I'm developing but I don't want users to compile them. Are there any ways to express such modes in cabal files? ("Executable" cannot be located under "if".) Or should I prepare a separated package for the development tools? Regards, --Kazu From michael at snoyman.com Wed Sep 17 03:46:58 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 17 Sep 2014 06:46:58 +0300 Subject: [Haskell-cafe] a question about cabal files In-Reply-To: <20140917.124139.409336689002464402.kazu@iij.ad.jp> References: <20140917.124139.409336689002464402.kazu@iij.ad.jp> Message-ID: You can use `buildable` properties inside the executable section, and put an `if` inside those. The `ifi` can depend on, e.g., a flag or the OS. On Wed, Sep 17, 2014 at 6:41 AM, Kazu Yamamoto wrote: > Hi cafe, > > I'm developing a library. In this package, some tools for development > are included. I would like to compile these tools when I'm developing but > I don't want users to compile them. > > Are there any ways to express such modes in cabal files? ("Executable" > cannot be located under "if".) > > Or should I prepare a separated package for the development tools? > > Regards, > > --Kazu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Sep 17 03:55:35 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 17 Sep 2014 06:55:35 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <54188822.6060503@fuuzetsu.co.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <54177802.4060704@fuuzetsu.co.uk> <54185E2C.6030006@fuuzetsu.co.uk> <5418706F.9090508@fuuzetsu.co.uk> <54188822.6060503@fuuzetsu.co.uk> Message-ID: On Tue, Sep 16, 2014 at 9:57 PM, Mateusz Kowalczyk wrote: > On 09/16/2014 07:38 PM, Michael Snoyman wrote: > > On Tue, Sep 16, 2014 at 8:16 PM, Mateusz Kowalczyk < > fuuzetsu at fuuzetsu.co.uk> > > wrote: > > > >> On 09/16/2014 06:04 PM, Michael Snoyman wrote: > >>> On Tue, Sep 16, 2014 at 6:58 PM, Mateusz Kowalczyk < > >> fuuzetsu at fuuzetsu.co.uk> > >>> wrote: > >>> > >>>> On 09/16/2014 05:13 AM, Michael Snoyman wrote: > >>>> > >>>>> So again, I really like the idea of doing the same thing for synopses > >> as > >>>> we > >>>>> have already for changelogs. > >>>> > >>>> I also do, I am here merely to investigate why Markdown is so strongly > >>>> preferred when Haddock does the job. Yes, the escaping was really bad > in > >>>> the past. Yes, it had some weird bugs. Yes, it has been fixed. To my > >>>> knowledge, we have zero bugs open on the issue tracker[5]. There are > >>>> some that are to do with GHC lexer + parser but those are not relevant > >>>> at all here. If you know of bugs then please report them. > >>>> > >>>> > >>> I don't think I can make my point any clearer. I demonstrated that the > >> bug > >>> I brought up four years ago still exists, > >> > >> ?what? I just showed you that it no longer exists, linked to the source > >> files used to generate it with your own input and linked to output. The > >> bug was fixed, there's nothing more to it. > >> > >> > > I think you're discussing a strawman. The original proposal I made is > > "let's do Markdown in a separate file, because the current cabal + > Haddock > > situation doesn't work." I demonstrated that. You're now saying that > "it's > > not Haddock, it's cabal." That may be true, but it doesn't negate my > point > > in the least: we could realize use an alternative, and the alternative > I'd > > like is README.md. > > OK, if that's what you want then that's fine. I am simply trying to > clarify that it's not ?let's use Markdown because Haddock can't do X, Y > and Z?. > > > > >>> that a separate file makes more sense > >> > >> Yes. > >> > >>> , that people are more familiar with markdown, that existing tools > >>> (editors and sites like Github) already have very solid Markdown > support. > >>> You've used the same argument multiple times: Markdown has multiple > >>> flavors. I get it, you don't like Markdown. You made that clear. But > many > >>> others- myself included- *do* like Markdown, and want to be able to use > >> it. > >>> Your arguments don't convince me that my desires are invalid. > >> > >> I don't neither dislike Markdown nor think your desires are invalid. I > >> am only trying to understand what your problem with Haddock is. That's > >> it. You say there's a bug, I show that it's fixed. What else is there? > >> > >> I only mention various Markdown flavours for a simple reason: it is to > >> deter any potential ?Haddock should just support Markdown? posts, like > >> seen early in this thread. > >> > >> > > It comes down to the fact that I like writing Markdown. Honestly, that's > > enough. As for the *reason* I like Markdown: it's because I'm __always__ > > writing Markdown. When I'm on Github's wiki or issue tracker, on Reddit, > on > > Stack Overflow, on School of Haskell, or my blog. If you pay attention, > > even this email is Markdown-formatted. To my knowledge, Github does *not* > > support Haddock format, so I'd have to maintain both a README.md and > > README.haddock (part of the tooling issue I brought up). > > Fair. > > > And on top of all that: I believe there are things that can be expressed > in > > Markdown (via HTML blocks) that simply cannot be expressed in Haddock, > such > > as tables. I could be mistaken on that point, however, can you clarify? > > It is correct you can't include HTML for the same reason we don't allow > embedding LaTeX: we want to be able to target multiple back-ends and it > is unclear what to do with HTML when rendering as LaTeX and vice-versa. > So you're correct that Haddock is not suited as a formatting tool for > web pages, it's a code documentation tool. > > It does go the other way too by the way, Markdown won't let you link to > modules, identifiers and all that, so Markdown is not suited for code > documentation. It really depends what you're after I suppose. > > > > >>> I'm not opposed to Hackage supporting multiple flavors of README files > >>> (much like Github does). But I really dislike someone saying "you > >> shouldn't > >>> be able to edit in the file format that you like, because I have an > >>> objection to it." If you don't like Markdown, don't use it. But please > >>> don't tell me "Haddock markup is sufficient, you should use that." If > >>> you're hearing that "Markdown is so strongly preferred," maybe you > should > >>> accept that people prefer Markdown. > >> > >> No, again, I didn't say what you have to use and I even told you about a > >> tool which can make it easy for you to write whatever you want in the > >> existing system. > >> > >> > > That's a non-starter and a cop-out. Saying "Hackage will only support > > Haddock, but you can use Markdown and manually convert to Haddock and > hope > > that the conversion is lossless" is just another way of saying "you have > to > > use Haddock." > > I specifically said ?existing system?. If you *right now* wanted to be > able to write your comments/synopsis in Markdown then you can, it's just > not Hackage-native. > > > > >>> So my ideal is: Hackage chooses some Markdown implementation- I don't > >>> really care which too much- and adds support for README.md files. It > can > >>> also add support for README.html, README.haddock, README.asciidoc, and > >>> README.klingon for all I care. If people run into problems because > Github > >>> flavored Markdown is different than Hackage flavored Markdown... well, > >>> that's a situation that people using Markdown are used to already, and > >> have > >>> come to terms with. I won't be put off by that. I already encounter > that > >>> when I copy-paste something from a Stack Overflow answer into a Reddit > >>> comment. I can deal with it. People with objections to Markdown are > >>> perfectly free to use whatever syntax they want as well. > >>> > >>> Michael > >>> > >> > >> OK, great. I'd still like to hear about this bug you mention as the only > >> thing you pointed out has been fixed in June. > >> > >> Lastly, who is going to implement all this stuff? It's easy to wish but > >> I'm sure you have even less time than I do. > >> > >> > > That's a great question, but irrelevant to whether this is a good > feature. > > I'd rather figure out the first than conflate it with the second. > > > > Michael > > > > OK, to summarise: > > * separate file for synopsis is a good idea > > * Currently Hackage only supports Haddock descriptions > > * Ideally Hackage should support more formats > > * You want to use Markdown as one of the formats because you like it > rather than because Haddock has bugs which stop you from doing so. > > * The workaround to be able to use Markdown before this proposal is > implemented is to use pandoc > > As long as there is no disagreement as to this summary, we are on the > same page, I consider the previous exchange more of a miscommunication > rather than disagreement. > > Good summary. I've opened up an issue for this: https://github.com/haskell/hackage-server/issues/262 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Sep 17 03:58:08 2014 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 17 Sep 2014 06:58:08 +0300 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: <87r3zb1dcf.wl%richard@rjlewis.me.uk> References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <87r3zb1dcf.wl%richard@rjlewis.me.uk> Message-ID: On Wed, Sep 17, 2014 at 12:10 AM, Richard Lewis wrote: > So there's clearly an important technical hurdle to be overcome for > this: what markup language is to be used?; and where should the > synposis be stored? > > But I can't help thinking that the real work is in getting the > synopses written. Encouraging package authors/maintainers to add them > to their own packages is one possible way forward. > > Actually, if we get the README support in place, I think it should be much easier to get package authors to write synopses. Most projects have a README file already, and getting it included in Hackage would now be a one-line pull request (adding `extra-source-files: README.extension`). It will hopefully be easier to get authors to elaborate on their READMEs then because: 1. They're serving double duty, both in the project repository and on Hackage. 2. It's trivial for outside developers to send pull requests against a simple text file. I've received quite a few such contributions on projects I maintain, even from people not ready to work on the code itself. > At Mon, 15 Sep 2014 11:28:38 -0700, > Tikhon Jelvis wrote: > > > Maybe we could have a guerrilla campaign of pull requests adding > > examples and a bit of explanation to every package you like that > > doesn't have them... That could also be a good way for beginners who > > want to contribute to start. > > Another, as Tikhon suggests, would be for others to write them and > send pull requests (or whatever) to the maintainers. > > At Mon, 15 Sep 2014 20:10:18 -0400, > Dominick Samperi wrote: > > > I think this is a great idea, but it probably needs a complementary > > "nudge" if it is going to have a significant impact. This could be > > incorporated into the package submission process where the submitter > > runs a final check and is warned when examples are not provided for > > exported functions (unless an "opt out" flag is turned on for > > functions that have "obvious" semantics). > > And yet another, as Dominick suggests, is effectively to require a > synposis when a package is submitted. In CPAN, it's just become part > of the culture, but it's also not required and you do find packages > without a synposis. > > If there's interest, I'd like to solicit some discussion on this part > of the proposal on this thread... > > There may also be a potentially significant difference between > Hackage/Haskell and CPAN/Perl: most CPAN packages tend to be quite > small and specific in their purpose and consequently have just a few, > simple common use cases which suit a synposis very well. Hackage > packages, on the other hand, are quite often more broad in their > scope, often comprising many modules. Also, Perl has only one > semantics for organising code at the finest level: sequential, > imperative statements. In Haskell, some packages actually define whole > coding styles. As a result, it's always pretty obvious how to write a > few isolated lines of Perl code, but not necessarily so with Haskell > code. Anyway, I'm sure all this can be overcome, and/or argued > against. > > Richard > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Richard Lewis > j: ironchicken at jabber.earth.li > @: lewisrichard > http://www.richardlewis.me.uk/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmccarty at sent.com Wed Sep 17 04:20:46 2014 From: jmccarty at sent.com (Jason McCarty) Date: Wed, 17 Sep 2014 00:20:46 -0400 Subject: [Haskell-cafe] Categorical description for vector-space instance of AdditiveGroup (Maybe a) In-Reply-To: <1410662864.3813756.167203117.5BD2B222@webmail.messagingengine.com> References: <1410662864.3813756.167203117.5BD2B222@webmail.messagingengine.com> Message-ID: <20140917042046.GA19299@tensor> Warning: the following post contains graphic abstract algebra and category theory, and may not be suitable for all viewers. This post is literate Haskell. I want to revisit our bogus instances for Maybe v and provide some partial resolutions. The IMO best one is given by an operator (*.^) near the end. I'll abbreviate the categories AdditiveSemigroup, AdditiveMonoid, AdditiveGroup as S, M, G. The package vector-space has the instance instance AdditiveGroup v => AdditiveGroup (Maybe v) which we found was bogus because Just zeroV /= Nothing, so Maybe v doesn't have well-defined negation. Let's pretend the class hierarchy is the following. > {-# LANGUAGE FlexibleContexts, FlexibleInstances, TypeFamilies #-} > module Maybe where > import Control.Monad (join) > class AdditiveSemigroup a where > (^+^) :: a -> a -> a -- commutative, associative operator > class AdditiveSemigroup a => AdditiveMonoid a where > zeroV :: a -- unit for (^+^) > class AdditiveMonoid a => AdditiveGroup a where > negateV :: a -> a -- inverse for (^+^) and zeroV > class Semigroup a where > (^*^) :: a -> a -> a -- associative operator > class Semigroup a => Monoid a where > oneV :: a -- unit for (^*^) > class (AdditiveGroup a, Monoid a) => Ring a > -- (^*^) distributes over (^+^) > class (AdditiveMonoid a, Monoid a) => Semiring a > -- (^*^) distributes over (^+^) and zeroV ^*^ x == zeroV == x ^*^ zeroV > class (AdditiveSemigroup a, Monoid a) => WeakSemiring a > -- (^*^) distributes over (^+^) We can give Hom_C(u, v) some algebraic structure depending on the category C. > -- represents Hom_C(u, v) for any concrete category C, which is > -- unfortunate but too annoying to fix here > type Hom u v = u -> v > type End v = Hom v v -- represents End_C(v) = Hom_C(v, v) Morphisms can be added pointwise: > instance AdditiveSemigroup v => AdditiveSemigroup (Hom u v) where > f ^+^ g = \x -> f x ^+^ g x > instance AdditiveMonoid v => AdditiveMonoid (Hom u v) where > zeroV = const zeroV > instance AdditiveGroup v => AdditiveGroup (Hom u v) where > negateV f = negateV . f We can view End_C(v) as a monoid with composition: > instance Semigroup (End v) where > f ^*^ g = f . g > instance Monoid (End v) where > oneV = id (^*^) distributes over (^+^) in End_C(v): > instance AdditiveSemigroup v => WeakSemiring (End v) > instance AdditiveMonoid v => Semiring (End v) > -- zeroV ^*^ y = zeroV = x ^*^ zeroV too > instance AdditiveGroup v => Ring (End v) With this in place, if c, d are objects in categories C, D, then an action of c on d can be viewed as an element of Hom_C(c, End_D(d)), provided End_D(d) can be viewed as an object in C. In particular, a field f acts on a vector space v by a ring morphism f -> End_G(v). For the purpose of this discussion, we ignore multiplicative inverses; our scalars can be any ring. > class Action v where > type Scalar v > (*^) :: Scalar v -> End v > class (Action v, Ring (Scalar v), AdditiveGroup v) => VectorSpace v > -- (*^) must be a ring morphism Our structure on Maybe v is: > instance AdditiveSemigroup v => AdditiveSemigroup (Maybe v) where > x ^+^ Nothing = x > Nothing ^+^ y = y > Just x ^+^ Just y = Just $ x ^+^ y > instance AdditiveSemigroup v => AdditiveMonoid (Maybe v) where > zeroV = Nothing Since Maybe v isn't a group, we can't define an instance VectorSpace (Maybe v). But Maybe v is a monoid, so End_M(Maybe v) is a semiring. So I figured I could just weaken vector spaces a little: > class (Action v, Semiring (Scalar v), AdditiveMonoid v) => SemiVectorSpace v > -- (*^) must be a semiring morphism I guessed that fmap :: End_M(v) -> End_M(Maybe v) would be a semiring morphism, which gives: > instance Action v => Action (Maybe v) where > type Scalar (Maybe v) = Scalar v > (*^) = fmap . (*^) instance SemiVectorSpace v => SemiVectorSpace (Maybe v) -- (*^) = fmap . (*^) is a composite of semiring morphisms? I was wrong about fmap: although fmap preserves (^+^), (^*^), and oneV, the Just zeroV /= Nothing problem strikes again! We have fmap (zeroV :: End_M(v)) = fmap (const zeroV), but (zeroV :: End_M(Maybe v)) = const Nothing. I should have known better: fmap actually has type End_S(v) -> End_M(Maybe v), so there's no reason to expect it to preserve zeroV, even if v happens to have it. That forces you to weaken things even further: > class (Action v, WeakSemiring (Scalar v), AdditiveSemigroup v) => WeakSemiVectorSpace v > -- (*^) must be a weaksemiring morphism > instance WeakSemiVectorSpace v => WeakSemiVectorSpace (Maybe v) > -- (*^) = fmap . (*^) is a composite of weaksemiring morphisms So this is one "solution," but to me not very satisfying. Then I thought that, since Maybe is a monad, perhaps Hom_M(v, Maybe v) and/or Hom_S(v, Maybe v) are monoids under Kleisli composition. Are these semigroups under Kleisli composition? > instance Semigroup (Hom v (Maybe v)) where > f ^*^ g = join . fmap f . g -- = \x -> g x >>= f Here join is a semigroup morphism and fmap f is a monoid morphism if f is a semigroup morphism. In fact, join (zeroV :: Maybe (Maybe v)) == zeroV :: Maybe v, so join is also a monoid morphism. Hence f ^*^ g is a composite of appropriate morphisms, making Hom_M(v, Maybe v) and Hom_S(v, Maybe v) semigroups. To make this a monoid, we'd have to have oneV = Just, which is a semigroup morphism, but not a monoid morphism. > instance Monoid (Hom v (Maybe v)) where > oneV = return -- only valid for Hom_S(v, Maybe v)! This also makes (^*^) distribute over (^+^), so Hom_S(v, Maybe v) is a semiring if v is an additive semigroup, and Hom_M(v, Maybe v) is a semiring without one if v is an additive monoid (this is called a semirng because the "i" in "ring" supposedly stands for "multiplicative identity!"). > instance AdditiveSemigroup v => Semiring (Hom v (Maybe v)) > -- only valid for Hom_S(v, Maybe v) > class (AdditiveMonoid v, Semigroup v) => Semirng v > -- (^*^) distributes over (^+^) > instance AdditiveMonoid v => Semirng (Hom v (Maybe v)) > -- valid for Hom_M(v, Maybe v) Now we can hypothetically define a semiring morphism f -> Hom_S(v, Maybe v) if v is a SemiVectorSpace over f; we just need a semiring morphism End_M(v) -> Hom_S(v, Maybe v). > kleisli :: SemiVectorSpace v => (End v -> Hom v (Maybe v)) -> Scalar v > -> Hom v (Maybe v) > kleisli mor = mor . (*^) This would also define a semirng morphism f -> Hom_M(v, Maybe v) from a semirng morphism End_M(v) -> Hom_M(v, Maybe v). Only problem: I can't think of any natual semiring morphism End_M(v) -> Hom_S(v, Maybe v) or semirng morphism End_M(v) -> Hom_M(v, Maybe v), except for const (const Nothing). Perhaps this would be useful if you have such a map handy, but not in general. If you only want a weaksemir(i)ng morphism, you can use mor f = Just . f, but this is no better than the WeakVectorSpace instance above. What about the CoKleisli category? Maybe isn't just a monad on S, it's also a comonad on M! In fact, let's look at arbitrary comonads on M. > class Functor m => MonoidComonad m where > coreturn :: AdditiveMonoid v => Hom (m v) v > cojoin :: AdditiveMonoid v => Hom (m v) (m (m v)) > -- cojoin and coreturn must be monoid morphisms > -- fmap must take monoid morphisms to monoid morphisms > -- cojoin, coreturn, and fmap must satisfy the comonad laws Hopefully Hom_M(m v, v) is a monoid under CoKleisli composition. > instance (MonoidComonad m, AdditiveMonoid v) > => Semigroup (Hom (m v) v) where > f ^*^ g = f . fmap g . cojoin This is a composite of monoid morphisms if f and g are. The map coreturn is also a monoid morphism, so Hom_M(m v, v) is a monoid. > instance (MonoidComonad m, AdditiveMonoid v) > => Monoid (Hom (m v) v) where > oneV = coreturn This also implies that (^*^) distributes over (^+^), so I would expect this to be a semiring. It's easy to check that zeroV ^*^ g == zeroV, but f ^*^ zeroV doesn't necessarily equal zeroV when v is not cancellative (m = Maybe and v = Bool with (^+^) = (||) is a counterexample). So this isn't necessarily a semiring when v is just a monoid. However, all groups are cancellative, so we get the following better result. > instance (MonoidComonad m, AdditiveGroup v) => Ring (Hom (m v) v) Hom_M(m v, v) is a ring when v is an additive group! Finally, we can get a ring morphism f -> Hom_M(m v, v) if v is a vector space over f, given a ring morphism End_G(v) -> Hom_M(m v, v). > coKleisliWith :: (MonoidComonad m, VectorSpace v) > => (End v -> Hom (m v) v) -> Scalar v -> Hom (m v) v > coKleisliWith mor = mor . (*^) The obvious candidate for such a morphism is mor f = f . coreturn, and it's easy to see that mor preserves zeroV and oneV. Moreover, mor (f ^+^ g) = (f ^+^ g) . coreturn = \x -> (f ^+^ g) (coreturn x) = \x -> f (coreturn x) ^+^ g (coreturn x) = f . coreturn ^+^ g . coreturn = mor f ^+^ mor g mor f ^*^ mor g = (f . coreturn) ^*^ (g . coreturn) = f . coreturn . fmap (g . coreturn) . cojoin = f . g . coreturn . coreturn . cojoin = f . g . coreturn = (f ^*^ g) . coreturn = mor (f ^*^ g) So mor also preserves (^+^) and (^*^), making it a ring morphism. Let's give the result a slick name. > (*.^) :: (MonoidComonad m, VectorSpace v) => Scalar v -> Hom (m v) v > (*.^) = coKleisliWith (. coreturn) Actually, this simplifies a lot: s *.^ x = s *^ coreturn x Since (*.^) is a ring morphism, this satisfies a modified version of the vector space laws: 1. oneV *.^ x = coreturn x 2. (s1 ^*^ s2) *.^ x = ((*.^) s1 ^*^ (*.^) s2) x = s1 *.^ ((s2 *^) <$> x) 3. s *.^ (x ^+^ y) = (s *.^ x) ^+^ (s *.^ y) 4. (s1 ^+^ s2) *.^ x = (s1 *.^ x) ^+^ (s2 *.^ x) So what comonads are there on M? Any adjunction (F: C -> M, G: M -> C) gives rise to a comonad FG: M -> M. The Maybe comonad comes from an adjunction of semigroups and monoids, where F adds a new zeroV, and G forgets that a monoid has a zeroV. > instance MonoidComonad Maybe where > coreturn = maybe zeroV id > cojoin = fmap return It seems reasonable to use lists as well, since we all know [v] is the free monoid on v, giving an adjunction between Haskell types and monoids. But [v] isn't commutative, you say. It doesn't matter. We can just use Hom_M'([v], v) instead, where M' is the category of all monoids. Everything else stays the same. > instance MonoidComonad [] where > coreturn = foldr (^+^) zeroV > cojoin = fmap return We can just as easily use a comonad on G or G', the category of all groups. For example, the free group functor, the free abelian group functor, the free abelian monoid functor, and tensoring with a fixed abelian group are all left adjoints with codomain G', G, M, and G, respectively, so they give rise to comonads on these categories. Although, to implement these in Haskell, I think you need an Ord/Eq constraint (you might get away without it if you restrict to finite- dimensional vector spaces over finite fields, in which case you also get the free vector space functor). Abelianization is also a left adjoint, but it's the identity on vector spaces, so that's rather pointless. There are probably lots of other examples. I suspect you could get a monadic version with Kleisli composition to work too. The problem with Maybe was that it's a monad on S, not M. In summary, the (*.^) operator is the most flexible and principled approach I can think of to treat Maybe v like a vector space. Is it useful? I don't know! -- Jason McCarty From kazu at iij.ad.jp Wed Sep 17 04:52:46 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 17 Sep 2014 13:52:46 +0900 (JST) Subject: [Haskell-cafe] a question about cabal files In-Reply-To: References: <20140917.124139.409336689002464402.kazu@iij.ad.jp> Message-ID: <20140917.135246.2217922395284447237.kazu@iij.ad.jp> Hi Michael, > You can use `buildable` properties inside the executable section, and put > an `if` inside those. The `ifi` can depend on, e.g., a flag or the OS. This works perfectly for me. Thanks! --Kazu From mike at izbicki.me Wed Sep 17 06:21:33 2014 From: mike at izbicki.me (Mike Izbicki) Date: Tue, 16 Sep 2014 23:21:33 -0700 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <87r3zb1dcf.wl%richard@rjlewis.me.uk> Message-ID: One problem with using the README file as the synopsis is that a lot of the standard information in a README file would be out of place when displayed on hackage. For example, many READMEs have: * installation instructions * a list of contributors * a list of known bugs * how to contribute bug reports * licensing information Some of this information is very out of place on hackage, some of it is duplication of the standard fields in the cabal file, and some of it is just not things that a new user needs to see on their first visit to the package documentation. Maybe this could be solved by having the name of the synopsis file as a variable the author can specify. It can default to README(.md) but can be overridden to something else for authors who choose to do so. On Tue, Sep 16, 2014 at 11:20 PM, Mike Izbicki wrote: > One problem with using the README file as the synopsis is that a lot > of the standard information in a README file would be out of place > when displayed on hackage. For example, many READMEs have: > > * installation instructions > * a list of contributors > * a list of known bugs > * how to contribute bug reports > * licensing information > > Some of this information is very out of place on hackage, some of it > is duplication of the standard fields in the cabal file, and some of > it is just not things that a new user needs to see on their first > visit to the package documentation. > > Maybe this could be solved by having the name of the synopsis file as > a variable the author can specify. It can default to README(.md) but > can be overridden to something else for authors who choose to do so. > > On Tue, Sep 16, 2014 at 8:58 PM, Michael Snoyman wrote: >> >> >> On Wed, Sep 17, 2014 at 12:10 AM, Richard Lewis >> wrote: >>> >>> So there's clearly an important technical hurdle to be overcome for >>> this: what markup language is to be used?; and where should the >>> synposis be stored? >>> >>> But I can't help thinking that the real work is in getting the >>> synopses written. Encouraging package authors/maintainers to add them >>> to their own packages is one possible way forward. >>> >> >> Actually, if we get the README support in place, I think it should be much >> easier to get package authors to write synopses. Most projects have a README >> file already, and getting it included in Hackage would now be a one-line >> pull request (adding `extra-source-files: README.extension`). It will >> hopefully be easier to get authors to elaborate on their READMEs then >> because: >> >> 1. They're serving double duty, both in the project repository and on >> Hackage. >> 2. It's trivial for outside developers to send pull requests against a >> simple text file. I've received quite a few such contributions on projects I >> maintain, even from people not ready to work on the code itself. >> >>> >>> At Mon, 15 Sep 2014 11:28:38 -0700, >>> Tikhon Jelvis wrote: >>> >>> > Maybe we could have a guerrilla campaign of pull requests adding >>> > examples and a bit of explanation to every package you like that >>> > doesn't have them... That could also be a good way for beginners who >>> > want to contribute to start. >>> >>> Another, as Tikhon suggests, would be for others to write them and >>> send pull requests (or whatever) to the maintainers. >>> >>> At Mon, 15 Sep 2014 20:10:18 -0400, >>> Dominick Samperi wrote: >>> >>> > I think this is a great idea, but it probably needs a complementary >>> > "nudge" if it is going to have a significant impact. This could be >>> > incorporated into the package submission process where the submitter >>> > runs a final check and is warned when examples are not provided for >>> > exported functions (unless an "opt out" flag is turned on for >>> > functions that have "obvious" semantics). >>> >>> And yet another, as Dominick suggests, is effectively to require a >>> synposis when a package is submitted. In CPAN, it's just become part >>> of the culture, but it's also not required and you do find packages >>> without a synposis. >>> >>> If there's interest, I'd like to solicit some discussion on this part >>> of the proposal on this thread... >>> >>> There may also be a potentially significant difference between >>> Hackage/Haskell and CPAN/Perl: most CPAN packages tend to be quite >>> small and specific in their purpose and consequently have just a few, >>> simple common use cases which suit a synposis very well. Hackage >>> packages, on the other hand, are quite often more broad in their >>> scope, often comprising many modules. Also, Perl has only one >>> semantics for organising code at the finest level: sequential, >>> imperative statements. In Haskell, some packages actually define whole >>> coding styles. As a result, it's always pretty obvious how to write a >>> few isolated lines of Perl code, but not necessarily so with Haskell >>> code. Anyway, I'm sure all this can be overcome, and/or argued >>> against. >>> >>> Richard >>> -- >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> Richard Lewis >>> j: ironchicken at jabber.earth.li >>> @: lewisrichard >>> http://www.richardlewis.me.uk/ >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> From stefan.wehr at gmail.com Wed Sep 17 09:01:17 2014 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Wed, 17 Sep 2014 11:01:17 +0200 Subject: [Haskell-cafe] ANN: HacBerlin - Haskell Hackathon in Berlin, 26-28 Sep 2014 Message-ID: Hi everyone, this is just a quick reminder: The Haskell Hackathon in Berlin starts in 9 days and there are very few places left. Please register now: http://goo.gl/aLfnWu Where: Berlin, Germany When: Fri 26 - Sun 28 September 2014 We will do lots of Haskell hacking and listen to two excellent talks: * Beyond Parsec -- Revisiting Parser Combinators, by Andres L?h * Chordify: Advanced Functional Programming for Fun and Profit, by Jos? Pedro Magalh?es Meet in Berlin, discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! For all details, visit our wiki page (http://www.haskell.org/haskellwiki/HacBerlin2014) and make sure to register now! Cheers, Stefan From petr.mvd at gmail.com Wed Sep 17 09:51:28 2014 From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=) Date: Wed, 17 Sep 2014 11:51:28 +0200 Subject: [Haskell-cafe] [QuickCheck] Fwd: an idea for improving 'shrink' In-Reply-To: <20140911193702.GB5231@localhost.localdomain> References: <20140911193702.GB5231@localhost.localdomain> Message-ID: Hi Nick, you're right, this example is indeed problematic. I'll try to think about it how to get around that, keeping backward compatibility. Petr Dne 11. 9. 2014 21:37 "Nick Smallbone" napsal(a): > Hi Petr, > > My attitude has always been "just use the shrink instance for tuples". > I don't think there's all that much difference between: > shrink (C x y) = [ C x' y' | (x', y') <- shrink (x, y) ] > and: > shrink (C x y) = C <$> shrink x <*> shrink y > The second is certainly nicer, but neither way is really very painful. > > However, your shrinkOne example shows a case where shrinking tuples > doesn't work and you really need a shrinking Applicative. > So this is a good reason to add a shrinking Applicative to QuickCheck > and I would probably like to do it at some point. > > There is a problem with your current patch, though. Namely the default > implementation of shrinkA: > shrinkA = pure > If someone defines shrink but not shrinkA, then shrinkA will not > shrink! In fact, one of your examples exhibits this bug: > shrinkA (Branch x l r) = > Branch <$> shrinkA x <*> shrinkA l <*> shrinkA r > If the Arbitrary instance for whatever x is defines shrink but not > shrinkA, then this will do the wrong thing. > > So we can't provide a default implementation for shrink in terms of > shrinkA, or vice versa, because we want the user to be able to define > either. We can't even define both in terms of the other because then > the default implementation will loop instead of returning []. > > Probably we would just have to move shrinkA outside of the Arbitrary > class. This does make using the Applicative more cumbersome, e.g.: > shrink (C x y) = fromShrink (C <$> shrinkA x <*> shrinkA y) > shrinkOne shr = fromShrink . traverse (Shrink . shr) > but maybe this would still be useful for defining trickier shrink > functions. > > Anyway, this is the only worry I have - how to integrate the > traditional and applicative-based shrinking without too much syntactic > overhead. If we can come up with a good solution for that then I'd be > very eager to add this to QuickCheck. Or maybe calling fromShrink > isn't so painful and we should add it anyway. I will think it over a > bit... > > Nick > > On Saturday 06 September, 2014 at 11:17 am, Petr Pudl?k wrote: > > 2014-09-05 18:22 GMT+02:00 Bryan O?Sullivan : > > > > > > > On Thu, Sep 4, 2014 at 1:06 PM, Petr Pudl?k > wrote: > > > > > >> since I got no response from the QuickCheck mail address, so I'm > > >> resending it here, if someone wants to comment on the idea. > > >> > > > > > > I don't think it pays its way: it makes shrink a bit tidier, at the > cost > > > of breaking backwards compatibility in a widely used library. > > > > > That?s a problem. But I believe it the patch addresses it. QuickCheck > > always uses ?shrink?, not ?shrinkA?, and as the default implementation of > > ?shrink? is defined in terms of ?shrinkA?, then it?s possible to define > > instances both using ?shrink? and using ?shrinkA?. So both old code and > new > > code that wants to take advantage of the Applicative interface work. > > > > I believe that in the long term this change would pay off: Compare the > old > > code > > > > shrinkOne [] = [] > > shrinkOne (x:xs) = [ x':xs | x' <- shr x ] > > ++ [ x:xs' | xs' <- shrinkOne xs ] > > > > shrink (x, y) = > > [ (x', y) | x' <- shrink x ] > > ++ [ (x, y') | y' <- shrink y ] > > > > shrink (x, y, z) = > > [ (x', y', z') > > | (x', (y', z')) <- shrink (x, (y, z)) ] > > > > against the improved piece > > > > traverse shr xs -- replaces the whole shrinkOne > > shrinkA (x, y) = liftA2 (,) (shrinkA x) (shrinkA y) > > shrinkA (x, y, z) = liftA3 (,,) (shrinkA x) (shrinkA y) (shrinkA z) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at okmij.org Wed Sep 17 10:33:41 2014 From: oleg at okmij.org (oleg at okmij.org) Date: Wed, 17 Sep 2014 06:33:41 -0400 (EDT) Subject: [Haskell-cafe] Type union Message-ID: <20140917103341.EF844C3827@www1.g3.pair.com> Type unions are also necessary for extensible effects. In fact, they are the foundation of extensible effects. One implementation http://okmij.org/ftp/Haskell/extensible/TList.hs uses only common and uncontroversial extensions (No Typeable). It could be converted to closed type families. The other, more optimal implementation, relies on Typeable, so that injection and projection become constant time, regardless of the size of the union. The Typeable constraint can be dispensed with; see the HList implementation of type-indexed coproducts (TIC), which are essentially open unions. From oleg at okmij.org Wed Sep 17 10:43:03 2014 From: oleg at okmij.org (oleg at okmij.org) Date: Wed, 17 Sep 2014 06:43:03 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI Message-ID: <20140917104303.0AF9AC3827@www1.g3.pair.com> Yet another demonstration of Turing completeness of the type checker (given the unrestricted context reduction stack) was lambda-calculator in types, posted back in 2006. http://okmij.org/ftp/Computation/lambda-calc.html#haskell-type-level The examples included the Fibonacci function (encoded using the fix-point combinator) and the SKI calculator (expressing combinators as lambda-terms). From marcin.jan.mrotek at gmail.com Wed Sep 17 10:45:22 2014 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 17 Sep 2014 12:45:22 +0200 Subject: [Haskell-cafe] Mapping over Type Level Literals In-Reply-To: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> References: <06ADDD0E-89F7-4C23-898F-B04FD8CE30E7@steinitz.org> Message-ID: Now I see that since you don't have a type list anywhere in the return type, you might try to use type classes: (works with GHC context stack set to at least one more than the value of N) ------- {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE Rank2Types #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE PolyKinds #-} import GHC.TypeLits import Data.Proxy import Data.Singletons data Haar (a :: Nat) (b :: Nat) = Haar { unHaar :: Double -> Double } haar :: forall n k . (KnownNat n, KnownNat k, (2 * k - 1 <=? 2^n - 1) ~ 'True) => Haar n (2 * k - 1) haar = Haar g where g t | (k' - 1) * 2 ** (-n') < t && t <= k' * 2 ** (-n') = 2 ** ((n' - 1) / 2) | k' * 2 ** (-n') < t && t <= (k' + 1) * 2 ** (-n') = -2 ** ((n' - 1) / 2) | otherwise = 0 where n' = fromIntegral (natVal (Proxy :: Proxy n)) k' = 2 * (fromIntegral (natVal (Proxy :: Proxy k))) - 1 data Natural = Z | S Natural type family FromNat n where FromNat Z = 0 FromNat (S n) = 1 + (FromNat n) type family ToNat i where ToNat 0 = Z ToNat n = S (ToNat (n - 1)) class Upto n where upto :: sing n -> [Integer] instance Upto Z where upto _ = [] instance (KnownNat (FromNat n), Upto n) => Upto (S n) where upto _ = natVal (undefined :: sing (FromNat n)) : upto (undefined :: sing n) class MapHaar (n :: Nat) (xs :: [(Nat,Nat)]) where maphaar :: sing1 n -> sing2 xs -> [[(Double, Double)]] instance MapHaar n '[] where maphaar _ _ = [] instance (Upto (ToNat n), MapHaar n xs, b ~ (2 * k - 1), b <= 2^a - 1, KnownNat n, KnownNat k, KnownNat a) => MapHaar n ('(a,b) ': xs) where maphaar sn _ = h : t where l = map (\i -> fromIntegral i / fromIntegral (natVal sn)) $ upto (undefined :: sing (ToNat n)) h = map (\x -> (x, unHaar (haar :: Haar a b) x)) l t = maphaar sn (undefined :: sing xs) data instance Sing 100 = S100 foo = maphaar S100 (undefined :: sing '[ '(1,1), '(2,1), '(2,3), '(3,1), '(3,5), '(3,7)]) ----- Regards, Marcin From jan.stolarek at p.lodz.pl Wed Sep 17 11:10:13 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 17 Sep 2014 13:10:13 +0200 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals Message-ID: <201409171310.13929.jan.stolarek@p.lodz.pl> Haskellers, there is some discussion going on at the moment about implementing injective type families in GHC [1]. I'd like to hear your opinions on proposed syntax for this new feature. == Problem == Currently GHC assumes that type families are not injective. This is of course conservative and the idea behind implementing injective type families is to allow the programmer to explicitly declare that a type family has the injectivity property (which GHC will of course verify). == Forms of injectivity == Injectivity can take forms more complicated than just determining the LHS from RHS: A. RHS determines all arguments on the LHS. Example: type family Id a where Id a = a Here the RHS uniquely determines LHS. B. RHS determines some but not all arguments on the LHS. Example (contrieved): type family G a b c where G Int Char Bool = Bool G Int Char Int = Bool G Bool Int Int = Int Here RHS uniquely determines `a` and `b` but not `c`. C. RHS and some LHS arguments uniquely determine some LHS arguments. Example: type family Plus a b where Plus Z m = m Plus (S n) m = S (Plus n m) Here knowing the RHS and one of LHS arguments uniqely determines the other LHS argument. At the moment we've only seen use cases for A, which means that we will most likely only implement A. If someone comes up with compelling examples of either B or C we will revise and consider implementing these more involved forms of injectivity. == Syntax == So the most important decission to make is what syntax do we want for this new feature :-) One of the features we would like is extensibility, ie. if we only implement injectivity of type A we still want to be able to add injectivities B and C sometime in the future without breaking A. When thinking about syntax an important (and open) question is whether injectivity becomes part of TypeFamilies language extension or do we add a new InjectiveTypeFamilies extension for this feature. The problem with incorporating injectivity into existing TypeFamilies is that we would have to come up with syntax that is fully backwards compatible with what we have now. Below is a list of proposals that have come up until now in the discussion between developers. Note that all proposals are given for closed type families. For open type families things would be identical except that the `where` keyword would be skipped. === Proposal 1 === Use syntax similar to functional dependencies. The injectivity declaration begins with `|` following type family declaration head. `|` is followed by a list of comma-separated injectivity conditions. Each injectivity condition has the form: {{{ result A -> B }}} where `A` is a possibly-empty list of type variables declared in type family head and `B` is non-empty list of said type variables. Things on the left and right of `->` are called LHS and RHS of an injectivity condition, respectively. `result` becomes a restricted word that cannot be used as a type variable's identifier in a type family head. Examples: type family Id a | result -> a where type family G a b c | result -> a b where type family Plus a b | result a -> b, result b -> a where Pros: * has natural reading: `result a -> b` reads as "knowing the result and the type variable a determines b". * extensible for the future Cons: * steals `result` identifier in the type family head. This means it would be illegal to have a type variable named `result` in a type family. * the above also makes this proposal backwards incompatible with TypeFamilies extension. Further proposals are based on this one in an attempt to solve the problem of stealing syntax and backwards incompatibility. === Proposal 2 === Use `Result` instead of `result`: type family Id a | Result -> a where type family G a b c | Result -> a b where type family Plus a b | Result a -> b, Result b -> a where Pros: * has natural reading * extensible for the future * allows to have type variables named `result` (does not steal syntax) Cons: * all other keywords in Haskell are lowercase. This would be the first one that is capitalized. * confusion could arise if we have a type `Result` and use it in the type family head. Unknowns (for me): * not sure if it would be possible to avoid name clash between `Result` and type of the same name. If not then this proposal would also be backwards incompatible with TypeFamilies. === Proposal 3 === Use `type` instead of `result`: type family Id a | type -> a where type family G a b c | type -> a b where type family Plus a b | type a -> b, type b -> a where Pros: * extensible for the future * no syntax stealing Cons: * no natural reading * usage of `type` here might seem unintuitive === Proposal 4 === Use name of the type family instead of `result`: type family Id a | Id -> a where type family G a b c | G -> a b where type family Plus a b | Plus a -> b, Plus b -> a where Pros: * extensible for the future * no syntax stealing Cons: * writing something like `Plus a` might be confusing. It looks as if Plus could be partially applied. == Further discussion == I'd like to hear what you think about these proposals. Neither of them is perfect so perhaps someone can come with something better. You can also check out the GHC Trac ticket [1] and the GHC Wiki page [2] (which repeats most of this but has some more details as well). [1] https://ghc.haskell.org/trac/ghc/ticket/6018 [2] https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies Janek From allbery.b at gmail.com Wed Sep 17 13:25:46 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 17 Sep 2014 09:25:46 -0400 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: <201409171310.13929.jan.stolarek@p.lodz.pl> References: <201409171310.13929.jan.stolarek@p.lodz.pl> Message-ID: On Wed, Sep 17, 2014 at 7:10 AM, Jan Stolarek wrote: > Use syntax similar to functional dependencies. The injectivity declaration > begins with `|` following type family declaration head. `|` is followed by > a > list of comma-separated injectivity conditions. Each injectivity condition > has > the form: > > {{{ > result A -> B > }}} > Was `_` considered here as the result token? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Sep 17 13:35:49 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 17 Sep 2014 09:35:49 -0400 Subject: [Haskell-cafe] Hackage package "synopsis" sections In-Reply-To: References: <3ce02f71-bda2-4722-ada2-cfce918ddd48@email.android.com> <87r3zb1dcf.wl%richard@rjlewis.me.uk> Message-ID: On Wed, Sep 17, 2014 at 2:21 AM, Mike Izbicki wrote: > Some of this information is very out of place on hackage, some of it > is duplication of the standard fields in the cabal file, and some of > it is just not things that a new user needs to see on their first > visit to the package documentation. > I question that; a README is pretty much the first thing I end up digging for when looking at something on Hackage. (I really like how github formats the README for a repo automatically. I'm lukewarm on GH otherwise but that one feature is very useful.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Wed Sep 17 14:02:43 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 17 Sep 2014 16:02:43 +0200 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: References: <201409171310.13929.jan.stolarek@p.lodz.pl> Message-ID: <201409171602.43247.jan.stolarek@p.lodz.pl> > > Use syntax similar to functional dependencies. The injectivity > > declaration begins with `|` following type family declaration head. `|` > > is followed by a > > list of comma-separated injectivity conditions. Each injectivity > > condition has > > the form: > > > > {{{ > > result A -> B > > }}} > > Was `_` considered here as the result token? No, it wasn't. Also, I think it's best to actually take a look at the wiki as new proposals are being added there. Janek From patrick.browne at dit.ie Wed Sep 17 14:03:41 2014 From: patrick.browne at dit.ie (PATRICK BROWNE) Date: Wed, 17 Sep 2014 15:03:41 +0100 Subject: [Haskell-cafe] Constructors on left and right hand sides of equation Message-ID: Dear list In Eq 1 is (NewGlass i) on the LHS distinct from (NewGlass i) on the RHS? In Eq2 are the occurrences of the data constructor Fill on the LHS and RHS distinct? Thanks Pat data Glass = NewGlass Int | Fill Glass Int deriving Show drink :: Glass -> Int -> Glass drink (NewGlass i) j = (NewGlass i) -- Eq 1 drink (Fill m i) j | full (Fill m i) = Fill (NewGlass (size m)) ((size m) - j) -- Eq 2 | (i >= j) = Fill m (i-j) | otherwise = drink m (j-1) size :: Glass -> Int size (NewGlass i) = i size (Fill m i) = size m level :: Glass -> Int level (NewGlass i) = 0 level (Fill m i) | (level m) + i > (size m) = size m | otherwise = (level m) + i empty :: Glass -> Bool empty m = (level m) == 0 full :: Glass -> Bool full m = (level m) == (size m) {- drink (Fill (NewGlass 4) 5) 5 drink (Fill (NewGlass 4) 3) 3 -} -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ? ITB?C a th?inig an r?omhphost seo. M? fuair t? an r?omhphost seo tr? earr?id, scrios de do ch?ras ? le do thoil. Tabhair ar aird, mura t? an seola? ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon ch?ipe?il, aon d?ileadh n? ar aon ghn?omh a dh?anfar bunaithe ar an ?bhar at? sa r?omhphost n? sna hiat?in seo. www.dit.ie T? ITB?C ag aistri? go Gr?inseach Ghorm?in ? DIT is on the move to Grangegorman -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Sep 17 14:32:59 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 17 Sep 2014 10:32:59 -0400 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: <201409171602.43247.jan.stolarek@p.lodz.pl> References: <201409171310.13929.jan.stolarek@p.lodz.pl> <201409171602.43247.jan.stolarek@p.lodz.pl> Message-ID: Jan, I notice two things 1) that where notation in the style of closed type families is quite nice! 2) what about adding some annotation to the args that act injectively wrt the result? eg type family Foo *a *b -- or some other marking annotation rather than type family Foo a b | $syntaxPlaceHolder -> a b -- or Or should we actually think of the solver process as being analagous to fundeps? On Wed, Sep 17, 2014 at 10:02 AM, Jan Stolarek wrote: > > > Use syntax similar to functional dependencies. The injectivity > > > declaration begins with `|` following type family declaration head. `|` > > > is followed by a > > > list of comma-separated injectivity conditions. Each injectivity > > > condition has > > > the form: > > > > > > {{{ > > > result A -> B > > > }}} > > > > Was `_` considered here as the result token? > No, it wasn't. > > Also, I think it's best to actually take a look at the wiki as new > proposals are being added > there. > > Janek > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flickyfrans at gmail.com Wed Sep 17 16:13:29 2014 From: flickyfrans at gmail.com (flicky frans) Date: Wed, 17 Sep 2014 20:13:29 +0400 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: References: <201409171310.13929.jan.stolarek@p.lodz.pl> <201409171602.43247.jan.stolarek@p.lodz.pl> Message-ID: Maybe it's worth adding an explicit type variable for the result? Something like: type family Id a -> r | r -> a where type family G a b c -> res | res -> a b where type family Plus a b -> result | result a -> b, result b -> a where It's a little verbose, but certainly is not confusing, since LHS really determines RHS. From chriswarbo at googlemail.com Wed Sep 17 16:49:56 2014 From: chriswarbo at googlemail.com (Chris Warburton) Date: Wed, 17 Sep 2014 17:49:56 +0100 Subject: [Haskell-cafe] Constructors on left and right hand sides of equation In-Reply-To: (PATRICK BROWNE's message of "Wed, 17 Sep 2014 15:03:41 +0100") References: Message-ID: <86a95yur7v.fsf@gmail.com> PATRICK BROWNE writes: > drink (NewGlass i) j = (NewGlass i) -- Eq 1 > > In Eq 1 is (NewGlass i) on the LHS distinct from (NewGlass i) on the > RHS? > drink (Fill m i) j > | full (Fill m i) = Fill (NewGlass (size m)) ((size m) - j) -- Eq2 > In Eq2 are the occurrences of the data constructor Fill on the LHS and > RHS distinct? Yes they're distinct. This is important since their types can be different. Here's an extreme example: > data Proxy a = Proxy > > foo :: Proxy Int -> Proxy Bool > foo Proxy = Proxy It looks like "foo" is the identity function, returning its argument value, similar to these "bar" functions: > bar1 :: () -> () > bar1 () = () > > bar2 :: () -> () > bar2 = id However, it's not: > foo2 :: Proxy Int -> Proxy Bool > foo2 = id > [1 of 1] Compiling Main ( test.hs, interpreted ) > > test.hs:7:8: > Couldn't match type `Int' with `Bool' > Expected type: Proxy Int -> Proxy Bool > Actual type: Proxy Int -> Proxy Int > In the expression: id > In an equation for `foo2': foo2 = id > Failed, modules loaded: none. Hence, in general, we must assume that they're different values. We tend to use different terminology too, for example "patterns" on the left, "expressions" on the right; "destructing" on the left, "constructing" on the right. Cheers, Chris From tifonzafel at gmail.com Wed Sep 17 18:02:44 2014 From: tifonzafel at gmail.com (felipe zapata) Date: Wed, 17 Sep 2014 14:02:44 -0400 Subject: [Haskell-cafe] DSL implementation Message-ID: HI all, as a part of a project for physical simulation, I'm was given the task to help with the implementation of an Small DSL that is a minimal functional language. Point is that this small language contains some dependent typed theory, because we want to be able to check statically the shapes of vector and matrices, among other things. Haskell of course seems the tool for the job. But my boss insists that the implementation should be done in C, but I think that it is madness. Can someone please point me to relevant literature, discussions or general information that can help me to show my boss that Haskell is the right tool? any help would be appreciated. Felipe Z. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Wed Sep 17 18:06:51 2014 From: tikhon at jelv.is (Tikhon Jelvis) Date: Wed, 17 Sep 2014 11:06:51 -0700 Subject: [Haskell-cafe] DSL implementation In-Reply-To: References: Message-ID: One option to consider is using Haskell as the host language for your DSL but then generating either C or LLVM bytecode directly. Haskell has a few DSLs in this vein like Ivory, Copilot and Atom which you can look to for inspiration. This can give you Haskell's expressiveness and type system coupled with the speed, portability and compatibility of C or LLVM. On Sep 17, 2014 11:03 AM, "felipe zapata" wrote: > HI all, > as a part of a project for physical simulation, I'm was given the task to > help with the implementation of an Small DSL that is a minimal functional > language. Point is that this small language contains some dependent typed > theory, because we want to be able to check statically the shapes of vector > and matrices, among other things. Haskell of course seems the tool for the > job. > But my boss insists that the implementation should be done in C, but I > think that it is madness. > Can someone please point me to relevant literature, discussions or general > information that can help me to show my boss that Haskell is the right tool? > > any help would be appreciated. > > Felipe Z. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Wed Sep 17 18:31:43 2014 From: magnus at therning.org (Magnus Therning) Date: Wed, 17 Sep 2014 20:31:43 +0200 Subject: [Haskell-cafe] DSL implementation In-Reply-To: References: Message-ID: <20140917183143.GB3095@tatooine.lan> On Wed, Sep 17, 2014 at 02:02:44PM -0400, felipe zapata wrote: > HI all, > as a part of a project for physical simulation, I'm was given the > task to help with the implementation of an Small DSL that is a > minimal functional language. Point is that this small language > contains some dependent typed theory, because we want to be able to > check statically the shapes of vector and matrices, among other > things. Haskell of course seems the tool for the job. > But my boss insists that the implementation should be done in C, but > I think that it is madness. > Can someone please point me to relevant literature, discussions or > general information that can help me to show my boss that Haskell is > the right tool? > > any help would be appreciated. Why try to convince him? ;) There is always the option of disregarding what the boss says and just do it in Haskell and face the music later. I've done this kind of thing a few times, but only when all of the following hold: 1. I am 100% sure I am right and the other party is wrong 2. I am confident I can tackle a large enough part of the problem and have something to show before reaching a point of no return (i.e. I must be able to show something that convincingly shows that I am going down the correct path before reaching the point where switching to the "inferior path" becomes impossible) 3. I feel safe enough in my employment that I can handle a spectacular failure, or I don't care enough about my employment to worry a spectacular failure If you want to try to convince him I would urge you to not spend too much time on the technical superiority of using Haskell to implement the DSL. Instead you should spend time on finding out what makes your boss suggest using C. Is it familiarity? Is it worry about future maintenance? Is it just habit? C is almost *always* an inferior choice so anyone arguing in favour of it is probably doing it for emotional reasons, not technical! (Only slightly tongue-in cheek.) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus In a hierarchy, every employee tends to rise to his level of incompetence. -- The Peter Principle -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From jmccarty at sent.com Wed Sep 17 18:54:57 2014 From: jmccarty at sent.com (Jason McCarty) Date: Wed, 17 Sep 2014 14:54:57 -0400 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: <201409171310.13929.jan.stolarek@p.lodz.pl> References: <201409171310.13929.jan.stolarek@p.lodz.pl> Message-ID: <20140917185457.GA20408@tensor> Hi, I have some code that currently needs AllowAmbiguousTypes to compile in 7.8, but didn't need it in 7.6. It's actually an example of your form of injectivity C. The crux is that for list concatenation (like Conal's example of addition), any two of the inputs/result determines the other input/result. So it might be useful to have the following. type family (as :: [Nat]) ++ (bs :: [Nat]) :: [Nat] | result as -> bs, result bs -> as where '[] ++ bs = bs (a ': as) ++ bs = a ': (as ++ bs) I have serious doubts that GHC could check this injectivity, though. Fortunately I only use this at concrete enough types that AllowAmbiguousTypes is sufficient. But really, the types aren't ambiguous, GHC just doesn't know about the injectivity of (++). The code below is simplified from code that computes a tensor product of a tensor with an identity matrix whose size is determined from the shapes of the input and output tensors. \begin{code} {-# LANGUAGE AllowAmbiguousTypes, DataKinds, KindSignatures, TypeFamilies, TypeOperators #-} module Test where import GHC.TypeLits type family (as :: [Nat]) ++ (bs :: [Nat]) :: [Nat] type instance '[] ++ bs = bs type instance (a ': as) ++ bs = a ': (as ++ bs) data Tensor (s :: [Nat]) = Tensor -- content elided -- apparently GHC reduces (++) enough to see that n is determined leftUnit :: Tensor s -> Tensor ('[n, n] ++ s) leftUnit Tensor = Tensor -- accepted in 7.6, not accepted in 7.8 without AllowAmbiguousTypes rightUnit :: Tensor s -> Tensor (s ++ '[n, n]) rightUnit Tensor = Tensor -- also accepted without AllowAmbiguousTypes outsideUnit :: Tensor s -> Tensor ('[n] ++ s ++ '[n]) outsideUnit Tensor = Tensor useleftUnit :: Tensor '[1,1,2] useleftUnit = leftUnit Tensor -- type of Tensor is inferred userightUnit :: Tensor '[1,2,2] userightUnit = rightUnit (Tensor :: Tensor '[1]) -- type must be provided \end{code} On Wed, Sep 17, 2014 at 01:10:13PM +0200, Jan Stolarek wrote: > Haskellers, > > there is some discussion going on at the moment about implementing injective > type families in GHC [1]. I'd like to hear your opinions on proposed syntax for this > new feature. > > == Problem == > > Currently GHC assumes that type families are not injective. This is of course > conservative and the idea behind implementing injective type families is to > allow the programmer to explicitly declare that a type family has the > injectivity property (which GHC will of course verify). > > == Forms of injectivity == > > Injectivity can take forms more complicated than just determining the LHS from > RHS: > > A. RHS determines all arguments on the LHS. Example: > > type family Id a where > Id a = a > > Here the RHS uniquely determines LHS. > > B. RHS determines some but not all arguments on the LHS. Example (contrieved): > > type family G a b c where > G Int Char Bool = Bool > G Int Char Int = Bool > G Bool Int Int = Int > > Here RHS uniquely determines `a` and `b` but not `c`. > > C. RHS and some LHS arguments uniquely determine some LHS arguments. Example: > > type family Plus a b where > Plus Z m = m > Plus (S n) m = S (Plus n m) > > Here knowing the RHS and one of LHS arguments uniqely determines the other > LHS argument. > > At the moment we've only seen use cases for A, which means that we will most likely only > implement A. If someone comes up with compelling examples of either B or C we > will revise and consider implementing these more involved forms of injectivity. > > > == Syntax == > > So the most important decission to make is what syntax do we want for this new > feature :-) One of the features we would like is extensibility, ie. if we only > implement injectivity of type A we still want to be able to add injectivities B > and C sometime in the future without breaking A. > > When thinking about syntax an important (and open) question is whether > injectivity becomes part of TypeFamilies language extension or do we add a new > InjectiveTypeFamilies extension for this feature. The problem with incorporating > injectivity into existing TypeFamilies is that we would have to come up with > syntax that is fully backwards compatible with what we have now. > > Below is a list of proposals that have come up until now in the discussion > between developers. Note that all proposals are given for closed type families. > For open type families things would be identical except that the `where` keyword > would be skipped. > > > === Proposal 1 === > > Use syntax similar to functional dependencies. The injectivity declaration > begins with `|` following type family declaration head. `|` is followed by a > list of comma-separated injectivity conditions. Each injectivity condition has > the form: > > {{{ > result A -> B > }}} > > where `A` is a possibly-empty list of type variables declared in type family > head and `B` is non-empty list of said type variables. Things on the left and > right of `->` are called LHS and RHS of an injectivity condition, > respectively. `result` becomes a restricted word that cannot be used as a type > variable's identifier in a type family head. Examples: > > type family Id a | result -> a where > type family G a b c | result -> a b where > type family Plus a b | result a -> b, result b -> a where > > Pros: > > * has natural reading: `result a -> b` reads as "knowing the result and the > type variable a determines b". > > * extensible for the future > > Cons: > > * steals `result` identifier in the type family head. This means it would be > illegal to have a type variable named `result` in a type family. > > * the above also makes this proposal backwards incompatible with TypeFamilies > extension. > > Further proposals are based on this one in an attempt to solve the problem of > stealing syntax and backwards incompatibility. > > > === Proposal 2 === > > Use `Result` instead of `result`: > > type family Id a | Result -> a where > type family G a b c | Result -> a b where > type family Plus a b | Result a -> b, Result b -> a where > > Pros: > > * has natural reading > > * extensible for the future > > * allows to have type variables named `result` (does not steal syntax) > > Cons: > > * all other keywords in Haskell are lowercase. This would be the first one > that is capitalized. > > * confusion could arise if we have a type `Result` and use it in the type > family head. > > Unknowns (for me): > > * not sure if it would be possible to avoid name clash between `Result` and > type of the same name. If not then this proposal would also be backwards > incompatible with TypeFamilies. > > > === Proposal 3 === > > Use `type` instead of `result`: > > type family Id a | type -> a where > type family G a b c | type -> a b where > type family Plus a b | type a -> b, type b -> a where > > Pros: > > * extensible for the future > > * no syntax stealing > > Cons: > > * no natural reading > > * usage of `type` here might seem unintuitive > > > === Proposal 4 === > > Use name of the type family instead of `result`: > > type family Id a | Id -> a where > type family G a b c | G -> a b where > type family Plus a b | Plus a -> b, Plus b -> a where > > Pros: > > * extensible for the future > > * no syntax stealing > > Cons: > > * writing something like `Plus a` might be confusing. It looks as if Plus > could be partially applied. > > > == Further discussion == > > I'd like to hear what you think about these proposals. Neither of them is > perfect so perhaps someone can come with something better. You can also check > out the GHC Trac ticket [1] and the GHC Wiki page [2] (which repeats most of this but has some > more details as well). > > [1] https://ghc.haskell.org/trac/ghc/ticket/6018 > [2] https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies > > Janek > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Jason McCarty From KAction at gnu.org Wed Sep 17 19:48:49 2014 From: KAction at gnu.org (Dmitry Bogatov) Date: Wed, 17 Sep 2014 23:48:49 +0400 Subject: [Haskell-cafe] Boolean formula: part2 Message-ID: <20140917194849.GA4478@self.lan> Hello! I have following code: buildFormulas :: [Variable] -> Int -> [Formula] buildFormulas vars 0 = map Var vars buildFormulas vars n = join $ forM [0 .. n - 1 ] $ \i -> do x <- buildFormulas vars i y <- buildFormulas vars (n - i - 1) z <- buildFormulas vars (n - 1) let t1 = case z of (Negation _) -> [] _ -> [Negation z] t1 ++ [conj x y, impl x y, disj x y] It is correct, typechecks, but it is insanely slow (calculating take 35 (buildFormulas [P, Q, R] 5) hangs my computer). My guess is that it builds too much before returning first results. Can you suggest more efficent way enumerate formulas of set of variables? -- Best regards, Dmitry Bogatov , Free Software supporter, esperantisto and netiquette guardian. GPG: 54B7F00D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jays at panix.com Wed Sep 17 19:58:39 2014 From: jays at panix.com (Jay Sulzberger) Date: Wed, 17 Sep 2014 15:58:39 -0400 (EDT) Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: <201409171310.13929.jan.stolarek@p.lodz.pl> References: <201409171310.13929.jan.stolarek@p.lodz.pl> Message-ID: On Wed, 17 Sep 2014, Jan Stolarek wrote: > Haskellers, > > there is some discussion going on at the moment about implementing injective > type families in GHC [1]. I'd like to hear your opinions on proposed syntax for this > new feature. As an old Lisper I look forward to an all sexp version of Haskell source code. I do note your ':-)' below ;) oo--JS. > > == Problem == > > Currently GHC assumes that type families are not injective. This is of course > conservative and the idea behind implementing injective type families is to > allow the programmer to explicitly declare that a type family has the > injectivity property (which GHC will of course verify). > > == Forms of injectivity == > > Injectivity can take forms more complicated than just determining the LHS from > RHS: > > A. RHS determines all arguments on the LHS. Example: > > type family Id a where > Id a = a > > Here the RHS uniquely determines LHS. > > B. RHS determines some but not all arguments on the LHS. Example (contrieved): > > type family G a b c where > G Int Char Bool = Bool > G Int Char Int = Bool > G Bool Int Int = Int > > Here RHS uniquely determines `a` and `b` but not `c`. > > C. RHS and some LHS arguments uniquely determine some LHS arguments. Example: > > type family Plus a b where > Plus Z m = m > Plus (S n) m = S (Plus n m) > > Here knowing the RHS and one of LHS arguments uniqely determines the other > LHS argument. > > At the moment we've only seen use cases for A, which means that we will most likely only > implement A. If someone comes up with compelling examples of either B or C we > will revise and consider implementing these more involved forms of injectivity. > > > == Syntax == > > So the most important decission to make is what syntax do we want for this new > feature :-) One of the features we would like is extensibility, ie. if we only > implement injectivity of type A we still want to be able to add injectivities B > and C sometime in the future without breaking A. > > When thinking about syntax an important (and open) question is whether > injectivity becomes part of TypeFamilies language extension or do we add a new > InjectiveTypeFamilies extension for this feature. The problem with incorporating > injectivity into existing TypeFamilies is that we would have to come up with > syntax that is fully backwards compatible with what we have now. > > Below is a list of proposals that have come up until now in the discussion > between developers. Note that all proposals are given for closed type families. > For open type families things would be identical except that the `where` keyword > would be skipped. > > > === Proposal 1 === > > Use syntax similar to functional dependencies. The injectivity declaration > begins with `|` following type family declaration head. `|` is followed by a > list of comma-separated injectivity conditions. Each injectivity condition has > the form: > > {{{ > result A -> B > }}} > > where `A` is a possibly-empty list of type variables declared in type family > head and `B` is non-empty list of said type variables. Things on the left and > right of `->` are called LHS and RHS of an injectivity condition, > respectively. `result` becomes a restricted word that cannot be used as a type > variable's identifier in a type family head. Examples: > > type family Id a | result -> a where > type family G a b c | result -> a b where > type family Plus a b | result a -> b, result b -> a where > > Pros: > > * has natural reading: `result a -> b` reads as "knowing the result and the > type variable a determines b". > > * extensible for the future > > Cons: > > * steals `result` identifier in the type family head. This means it would be > illegal to have a type variable named `result` in a type family. > > * the above also makes this proposal backwards incompatible with TypeFamilies > extension. > > Further proposals are based on this one in an attempt to solve the problem of > stealing syntax and backwards incompatibility. > > > === Proposal 2 === > > Use `Result` instead of `result`: > > type family Id a | Result -> a where > type family G a b c | Result -> a b where > type family Plus a b | Result a -> b, Result b -> a where > > Pros: > > * has natural reading > > * extensible for the future > > * allows to have type variables named `result` (does not steal syntax) > > Cons: > > * all other keywords in Haskell are lowercase. This would be the first one > that is capitalized. > > * confusion could arise if we have a type `Result` and use it in the type > family head. > > Unknowns (for me): > > * not sure if it would be possible to avoid name clash between `Result` and > type of the same name. If not then this proposal would also be backwards > incompatible with TypeFamilies. > > > === Proposal 3 === > > Use `type` instead of `result`: > > type family Id a | type -> a where > type family G a b c | type -> a b where > type family Plus a b | type a -> b, type b -> a where > > Pros: > > * extensible for the future > > * no syntax stealing > > Cons: > > * no natural reading > > * usage of `type` here might seem unintuitive > > > === Proposal 4 === > > Use name of the type family instead of `result`: > > type family Id a | Id -> a where > type family G a b c | G -> a b where > type family Plus a b | Plus a -> b, Plus b -> a where > > Pros: > > * extensible for the future > > * no syntax stealing > > Cons: > > * writing something like `Plus a` might be confusing. It looks as if Plus > could be partially applied. > > > == Further discussion == > > I'd like to hear what you think about these proposals. Neither of them is > perfect so perhaps someone can come with something better. You can also check > out the GHC Trac ticket [1] and the GHC Wiki page [2] (which repeats most of this but has some > more details as well). > > [1] https://ghc.haskell.org/trac/ghc/ticket/6018 > [2] https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies > > Janek > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From KAction at gnu.org Wed Sep 17 20:00:06 2014 From: KAction at gnu.org (Dmitry Bogatov) Date: Thu, 18 Sep 2014 00:00:06 +0400 Subject: [Haskell-cafe] Boolean formula: part2 In-Reply-To: <20140917194849.GA4478@self.lan> References: <20140917194849.GA4478@self.lan> Message-ID: <20140917200006.GA8923@self.lan> * Dmitry Bogatov [2014-09-17 23:48:49+0400] Sorry for followup, I found that problem is not in this function per-se, but in filtering one. Since I require formula to be complicated enough, I have to filter out simple ones, and simple ones gets constructed before any more complicated. I get all formulas only about P before it even touches Q. How can I speed things up? -- Set of hacks, that tries to formalize my opinion what -- good formula is. goodFormula :: Formula -> Bool goodFormula = \case (Function2 t x y) -> x /= y && goodFormula x && goodFormula y && case (x, y) of (Negation u, Negation v) -> u /= v (Negation u, y) -> u /= y (x, Negation v) -> x /=v (Function2 t' u' v', _) -> t' /= t' || ((y /= u') && (y /= v')) _ -> True (Negation x) -> goodFormula x _ -> True flenght :: Formula -> Int flenght fmt = case value fmt of Right _ -> 0 Left l -> length (toList l) main = do -- mapM_ print $ take (buildFormulas [P, Q, R] 7) print $ filter (\f -> goodFormula f && flenght f == 3) (buildFormulas [P, Q, R] 4) !! 1 -- print $ (buildFormulas [P, Q, R] 5) !! 1 > Hello! I have following code: > > buildFormulas :: [Variable] -> Int -> [Formula] > buildFormulas vars 0 = map Var vars > buildFormulas vars n = join $ > forM [0 .. n - 1 ] $ \i -> do > x <- buildFormulas vars i > y <- buildFormulas vars (n - i - 1) > z <- buildFormulas vars (n - 1) > let t1 = case z of > (Negation _) -> [] > _ -> [Negation z] > t1 ++ [conj x y, impl x y, disj x y] > > It is correct, typechecks, but it is insanely slow (calculating > take 35 (buildFormulas [P, Q, R] 5) hangs my computer). > > My guess is that it builds too much before returning first results. > Can you suggest more efficent way enumerate formulas of set of > variables? -- Best regards, Dmitry Bogatov , Free Software supporter, esperantisto and netiquette guardian. GPG: 54B7F00D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From ok at cs.otago.ac.nz Thu Sep 18 02:08:52 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 18 Sep 2014 14:08:52 +1200 Subject: [Haskell-cafe] Constructors on left and right hand sides of equation In-Reply-To: References: Message-ID: On 18/09/2014, at 2:03 AM, PATRICK BROWNE wrote: > Dear list > In Eq 1 is (NewGlass i) on the LHS distinct from (NewGlass i) on the RHS? > In Eq2 are the occurrences of the data constructor Fill on the LHS and RHS distinct? > > data Glass = NewGlass Int | Fill Glass Int deriving Show > drink :: Glass -> Int -> Glass > drink (NewGlass i) j = (NewGlass i) -- Eq 1 > drink (Fill m i) j > | full (Fill m i) = Fill (NewGlass (size m)) ((size m) - j) -- Eq 2 > | (i >= j) = Fill m (i-j) > | otherwise = drink m (j-1) The question question is "what do you MEAN by 'are they distinct'"? They are two distinct references to a single binding occurrence of an identifier. In Eq1, the first occurrence is in a pattern, and the second is in an expression. I wonder if you were interested in the question whether the second occurrence of NewGlass i would allocate new storage or whether it would use whatever the first occurrence matched? In that case, I believe the answer is "it's up to the compiler". You can *ask* for the matched data to be shared: drink g@(NewGlass _) _ = g drink g@(Fill m i ) j | full g = Fill (NewGlass (size m)) (size m - j) | i >= j = Fill m (i - j) | True = drink m (j - 1) Someone else has already pointed out data Proxy a = Proxy -- foo :: Proxy a -> Proxy b foo Proxy = Proxy -- Eq3 where the two occurrences of Proxy in Eq3 can have different types. But note that -- bar :: Proxy a -> Proxy a bar p at Proxy = p -- Eq4 The two occurrences of the variable p in Eq4 must have the same type (and the same value). From fuuzetsu at fuuzetsu.co.uk Thu Sep 18 02:38:07 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 18 Sep 2014 03:38:07 +0100 Subject: [Haskell-cafe] optional ghc-options based on GHC version? Message-ID: <541A458F.6080207@fuuzetsu.co.uk> Hi, I have a project here where GHC's option -flate-dmd-anal gets out some extra speed but the flag is not available on 7.6.3. How can I specify in the cabal file that I only want to pass this through when building with 7.8.3 or newer? It'd be a shame to not take advantage of the extra speed on 7.8.3 just because we want to support 7.6.3 too for a bit longer. I was unable to find the info online. Thanks. -- Mateusz K. From ivan.miljenovic at gmail.com Thu Sep 18 03:33:00 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 18 Sep 2014 13:33:00 +1000 Subject: [Haskell-cafe] optional ghc-options based on GHC version? In-Reply-To: <541A458F.6080207@fuuzetsu.co.uk> References: <541A458F.6080207@fuuzetsu.co.uk> Message-ID: Something like this: if True Ghc-Options: -O -Wall if impl(ghc >= 7.8.1) Ghc-Options: -flate-dmd-anal (I'm not sure if the "if True" hack is still needed, but at one stage it was.) On 18 September 2014 12:38, Mateusz Kowalczyk wrote: > Hi, > > I have a project here where GHC's option -flate-dmd-anal gets out some > extra speed but the flag is not available on 7.6.3. How can I specify in > the cabal file that I only want to pass this through when building with > 7.8.3 or newer? It'd be a shame to not take advantage of the extra speed > on 7.8.3 just because we want to support 7.6.3 too for a bit longer. I > was unable to find the info online. > > Thanks. > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From dstcruz at gmail.com Thu Sep 18 04:28:08 2014 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Wed, 17 Sep 2014 22:28:08 -0600 Subject: [Haskell-cafe] Haskell Weekly News: Issue 306 Message-ID: Welcome to issue 306 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from September 07 to 13, 2014 Quotes of the Week * prophile: at this point ekmett is more part of the language than a practitioner of it * Qfwfq: Simon is a title, not a forename. Top Reddit Stories * Haskell for all: Morte: an intermediate language for super-optimizing functional programs Domain: haskellforall.com, Score: 110, Comments: 83 Original: [1] http://goo.gl/MjPyyr On Reddit: [2] http://goo.gl/v2btl4 * AMP has landed in GHC Main! Domain: haskell.org, Score: 88, Comments: 71 Original: [3] http://goo.gl/giu1Xh On Reddit: [4] http://goo.gl/ZGJ76S * [Meta] What's with all these downvotes on beginner questions? Domain: self.haskell, Score: 69, Comments: 67 Original: [5] http://goo.gl/ik2uu2 On Reddit: [6] http://goo.gl/ik2uu2 * Haskell Implementors Workshop 2014 videos [youtube] Domain: youtube.com, Score: 59, Comments: 11 Original: [7] http://goo.gl/ijM6hs On Reddit: [8] http://goo.gl/48GOSr * FP Complete is hiring: Haskell web UI developer Domain: fpcomplete.com, Score: 59, Comments: 14 Original: [9] http://goo.gl/0kPlFl On Reddit: [10] http://goo.gl/WtivSo * How to get (approx) stack traces with profiled builds Domain: self.haskell, Score: 46, Comments: 15 Original: [11] http://goo.gl/ZAurK6 On Reddit: [12] http://goo.gl/ZAurK6 * Hakaru: An embedded probabilistic programming language Domain: indiana.edu, Score: 40, Comments: 10 Original: [13] http://goo.gl/PLcCGW On Reddit: [14] http://goo.gl/aP7giY * Why does David Turner say type classes were a bad idea? Domain: self.haskell, Score: 37, Comments: 96 Original: [15] http://goo.gl/WqRLZQ On Reddit: [16] http://goo.gl/WqRLZQ * Let's Build a Browser Engine in Haskell: Part 2 Domain: hrothen.github.io, Score: 33, Comments: 14 Original: [17] http://goo.gl/PyxMOy On Reddit: [18] http://goo.gl/45L7hs * Proposal for copatterns in Idris Domain: github.com, Score: 30, Comments: 38 Original: [19] http://goo.gl/7Zv7U1 On Reddit: [20] http://goo.gl/pPIq8p * GHC Blog: Static pointers and serialisation (by SPJ) Domain: ghc.haskell.org, Score: 28, Comments: 2 Original: [21] http://goo.gl/HJrm4t On Reddit: [22] http://goo.gl/kPxJj5 * introduction to the basic lens operators Domain: intolerable.me, Score: 26, Comments: 12 Original: [23] http://goo.gl/VXlKnm On Reddit: [24] http://goo.gl/b0bLfE * Prisms lead to typeclasses for subtractive types Domain: gelisam.blogspot.ca, Score: 22, Comments: 6 Original: [25] http://goo.gl/l9QIIm On Reddit: [26] http://goo.gl/GMD5Cj * Preventing memoization in (AI) search problems Domain: okmij.org, Score: 22, Comments: 16 Original: [27] http://goo.gl/oEb6WD On Reddit: [28] http://goo.gl/jqVKPS * A shallow survey of formal methods for C code Domain: imperialviolet.org, Score: 21, Comments: 7 Original: [29] http://goo.gl/rJgycy On Reddit: [30] http://goo.gl/RrXwns * Haskell Lectures Domain: shuklan.com, Score: 21, Comments: 1 Original: [31] http://goo.gl/Ef0E4 On Reddit: [32] http://goo.gl/VASdCX * A Netwire 5 Tutorial Domain: self.haskell, Score: 20, Comments: 5 Original: [33] http://goo.gl/BmcKWr On Reddit: [34] http://goo.gl/BmcKWr * Haskell Symposium talk on inline Objective-C in Haskell Domain: speakerdeck.com, Score: 20, Comments: 0 Original: [35] http://goo.gl/VDHOiP On Reddit: [36] http://goo.gl/TyL90G * HaLVM / Unikernel talk at the Xen User Summit on Monday, September 15th Domain: sched.co, Score: 19, Comments: 8 Original: [37] http://goo.gl/HoVwWT On Reddit: [38] http://goo.gl/9lqCE0 * Fun with (Extended Kalman) Filters Domain: idontgetoutmuch.wordpress.com, Score: 18, Comments: 2 Original: [39] http://goo.gl/8EGSQR On Reddit: [40] http://goo.gl/aTASRU Top StackOverflow Questions * Why does OCaml sometimes require eta expansion? votes: 12, answers: 1 Read on SO: [41] http://goo.gl/TsBuz5 * Can Haskell evaluate and not garbage collect random indexes in a list? votes: 11, answers: 2 Read on SO: [42] http://goo.gl/zXsBT1 * How do I install dependencies when cross compiling haskell code? votes: 10, answers: 1 Read on SO: [43] http://goo.gl/3qH6zK * Haskell lenses: how to make view play nicely with traverse? votes: 10, answers: 3 Read on SO: [44] http://goo.gl/EWrR5j * Is there an instance of Monad but not of MonadFix? votes: 10, answers: 2 Read on SO: [45] http://goo.gl/EAh0qc * How can the continuation monad be expressed using the free monad? votes: 10, answers: 3 Read on SO: [46] http://goo.gl/ymMoFw Until next time, [47]+Daniel Santa Cruz References 1. http://www.haskellforall.com/2014/09/morte-intermediate-language-for-super.html 2. http://www.reddit.com/r/haskell/comments/2g6wsx/haskell_for_all_morte_an_intermediate_language/ 3. http://www.haskell.org/pipermail/ghc-devs/2014-September/006265.html 4. http://www.reddit.com/r/haskell/comments/2fxqts/amp_has_landed_in_ghc_main/ 5. http://www.reddit.com/r/haskell/comments/2g3em9/meta_whats_with_all_these_downvotes_on_beginner/ 6. http://www.reddit.com/r/haskell/comments/2g3em9/meta_whats_with_all_these_downvotes_on_beginner/ 7. https://www.youtube.com/playlist?list=PL4UWOFngo5DW6nKDjK0UB5Oy9zmdWdo7K 8. http://www.reddit.com/r/haskell/comments/2frhfn/haskell_implementors_workshop_2014_videos_youtube/ 9. https://www.fpcomplete.com/blog/2014/09/hiring-haskell-web-ui-dev 10. http://www.reddit.com/r/haskell/comments/2g4mdu/fp_complete_is_hiring_haskell_web_ui_developer/ 11. http://www.reddit.com/r/haskell/comments/2fwwx3/how_to_get_approx_stack_traces_with_profiled/ 12. http://www.reddit.com/r/haskell/comments/2fwwx3/how_to_get_approx_stack_traces_with_profiled/ 13. http://indiana.edu/~ppaml/ 14. http://www.reddit.com/r/haskell/comments/2g4q81/hakaru_an_embedded_probabilistic_programming/ 15. http://www.reddit.com/r/haskell/comments/2foggq/why_does_david_turner_say_type_classes_were_a_bad/ 16. http://www.reddit.com/r/haskell/comments/2foggq/why_does_david_turner_say_type_classes_were_a_bad/ 17. http://hrothen.github.io/2014/09/08/lets-build-a-browser-engine-in-haskell-part-2/ 18. http://www.reddit.com/r/haskell/comments/2fu2l5/lets_build_a_browser_engine_in_haskell_part_2/ 19. https://github.com/idris-lang/Idris-dev/wiki/Copatterns 20. http://www.reddit.com/r/haskell/comments/2fy1hj/proposal_for_copatterns_in_idris/ 21. https://ghc.haskell.org/trac/ghc/blog/simonpj/StaticPointers 22. http://www.reddit.com/r/haskell/comments/2g4vvf/ghc_blog_static_pointers_and_serialisation_by_spj/ 23. http://intolerable.me/lens-operators-intro/ 24. http://www.reddit.com/r/haskell/comments/2fud8k/introduction_to_the_basic_lens_operators/ 25. http://gelisam.blogspot.ca/2014/09/prisms-lead-to-typeclasses-for.html 26. http://www.reddit.com/r/haskell/comments/2foz4a/prisms_lead_to_typeclasses_for_subtractive_types/ 27. http://okmij.org/ftp/Haskell/#memo-off 28. http://www.reddit.com/r/haskell/comments/2g9akh/preventing_memoization_in_ai_search_problems/ 29. https://www.imperialviolet.org/2014/09/07/provers.html 30. http://www.reddit.com/r/haskell/comments/2fsvns/a_shallow_survey_of_formal_methods_for_c_code/ 31. http://shuklan.com/haskell/ 32. http://www.reddit.com/r/haskell/comments/2g672e/haskell_lectures/ 33. http://www.reddit.com/r/haskell/comments/2fs4mv/a_netwire_5_tutorial/ 34. http://www.reddit.com/r/haskell/comments/2fs4mv/a_netwire_5_tutorial/ 35. https://speakerdeck.com/mchakravarty/foreign-inline-code-in-haskell-haskell-symposium-2014 36. http://www.reddit.com/r/haskell/comments/2fve6k/haskell_symposium_talk_on_inline_objectivec_in/ 37. http://sched.co/1rFBMed 38. http://www.reddit.com/r/haskell/comments/2g2sa0/halvm_unikernel_talk_at_the_xen_user_summit_on/ 39. http://idontgetoutmuch.wordpress.com/2014/09/09/fun-with-extended-kalman-filters-4/ 40. http://www.reddit.com/r/haskell/comments/2fwbhd/fun_with_extended_kalman_filters/ 41. http://stackoverflow.com/questions/25763412/why-does-ocaml-sometimes-require-eta-expansion 42. http://stackoverflow.com/questions/25751194/can-haskell-evaluate-and-not-garbage-collect-random-indexes-in-a-list 43. http://stackoverflow.com/questions/25765893/how-do-i-install-dependencies-when-cross-compiling-haskell-code 44. http://stackoverflow.com/questions/25773444/haskell-lenses-how-to-make-view-play-nicely-with-traverse 45. http://stackoverflow.com/questions/25814489/is-there-an-instance-of-monad-but-not-of-monadfix 46. http://stackoverflow.com/questions/25827271/how-can-the-continuation-monad-be-expressed-using-the-free-monad 47. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Thu Sep 18 04:38:34 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Wed, 17 Sep 2014 23:38:34 -0500 Subject: [Haskell-cafe] cryptography and homomorphic library support? Message-ID: Hi, I just perused the crypto section of Hackage and I didn't see any support for homomorphc functions. I didn't see anything .. maybe I missed. If no support, I wouldn't mind giving a shot at working on this as long as no one has already implemented. If someone is working on this, please inform me of contact info so perhaps I can join the team. Kind regards, Vasya From jan.stolarek at p.lodz.pl Thu Sep 18 05:40:10 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 18 Sep 2014 07:40:10 +0200 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: References: <201409171310.13929.jan.stolarek@p.lodz.pl> Message-ID: <201409180740.11032.jan.stolarek@p.lodz.pl> Thank you all for replies. To Carter: > what about adding some annotation to the args that act injectively wrt the result? I'm afraid that's not enough. How would you annotate Plus using this syntax? type family Plus a b | Plus a -> b, Plus b -> a where ... > Or should we actually think of the solver process as being analagous to fundeps? I think that injectivity will be very similar to fundeps: you'll have some types determining the others, except for type families not type classes. To flicky frans: > Maybe it's worth adding an explicit type variable for the result? Oh, this sounds good. But we must remember that type families already allow providing the kind of the result like this: ? ?type family Id a :: * where ? ?type family G a b c :: * where ? ?type family Plus a b :: Nat where So we'd have to do this: ? ?type family Id a :: (r :: *) | r -> a where ? ?type family G a b c :: (res :: *) | res -> a b where ? ?type family Plus a b :: (result :: Nat) | result a -> b, result b -> a where This would effectively force the user to provide kind annotation for the result but that doesn't seem to be a high price to pay. To Jason: > I have some code that currently needs AllowAmbiguousTypes to compile in > 7.8, but didn't need it in 7.6. It's actually an example of your form of > injectivity C. I took the liberty of reporting this as a GHC bug: #9607. However, I don't see how injectivity would help here. I of course see that '++ is injective in the same way as Plus but I don't see how this would aid in type checking of rightUnit (especially that it used to work!). The error message mentions injectivity but that doesn't mean that injectivity would really help. Janek From jan.stolarek at p.lodz.pl Thu Sep 18 06:10:38 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 18 Sep 2014 08:10:38 +0200 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: <201409180740.11032.jan.stolarek@p.lodz.pl> References: <201409171310.13929.jan.stolarek@p.lodz.pl> <201409180740.11032.jan.stolarek@p.lodz.pl> Message-ID: <201409180810.38472.jan.stolarek@p.lodz.pl> A follow up on flicky frans' proposal: we already allow introducing type variables to name a type family result, so this new syntax should be a straightforward addition. From dominic at steinitz.org Thu Sep 18 06:12:49 2014 From: dominic at steinitz.org (Dominic Steinitz) Date: Thu, 18 Sep 2014 06:12:49 +0000 (UTC) Subject: [Haskell-cafe] DSL implementation References: Message-ID: You have looked at the latest HMatrix with its static guarantees: Numeric.LinearAlgebra.Static? I think it is brilliant. It actually caught a bug in my mathematical derivation. I had written out the equations in LaTeX and then coded them up and couldn't understand why I was getting a type error until I realised it was my derivation that was wrong. Have a look here at its use: http://idontgetoutmuch.wordpress.com/2014/09/09/fun-with-extended-kalman-filters-4/. From jan.stolarek at p.lodz.pl Thu Sep 18 06:49:12 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 18 Sep 2014 08:49:12 +0200 Subject: [Haskell-cafe] Bound and free variables Message-ID: <201409180849.12784.jan.stolarek@p.lodz.pl> Hi *, I have a simple question about terminology regarding bound and free variables. Assume I have: let f x = let g y = ... in g c in ... Now: - `c` is free in `g` and `f` - `y` is bound in `g` - `x` is free in `g`. - `x` is bound in `f` What about `y` in `f`? Is it also bound in `f`? If so then it certainly is bound in a different way that `x`. Is there a terminology that allows to distinguish these different forms of bound variables? Janek From jwlato at gmail.com Thu Sep 18 07:09:12 2014 From: jwlato at gmail.com (John Lato) Date: Thu, 18 Sep 2014 00:09:12 -0700 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <201409180849.12784.jan.stolarek@p.lodz.pl> References: <201409180849.12784.jan.stolarek@p.lodz.pl> Message-ID: Is 'y' even referred to in `f`? I don't think it is, so it doesn't make sense to say if it's bound or free. My $.01 (half-off because I don't know what I'm talking about) John L. On Wed, Sep 17, 2014 at 11:49 PM, Jan Stolarek wrote: > Hi *, > > I have a simple question about terminology regarding bound and free > variables. Assume I have: > > let f x = let g y = ... > in g c > in ... > > Now: > - `c` is free in `g` and `f` > - `y` is bound in `g` > - `x` is free in `g`. > - `x` is bound in `f` > > What about `y` in `f`? Is it also bound in `f`? If so then it certainly is > bound in a different > way that `x`. Is there a terminology that allows to distinguish these > different forms of bound > variables? > > Janek > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at paccrat.org Thu Sep 18 07:13:37 2014 From: toby at paccrat.org (Toby Goodwin) Date: 18 Sep 2014 07:13:37 -0000 Subject: [Haskell-cafe] Improving ghc error messages Message-ID: <1411024417.458.hydrogen.mv6.co.uk@hydrogen.mpv6.com> Interesting article: https://izbicki.me/blog/error-messages-in-ghc-vs-g++.html I do hope some of these changes make it into a future ghc. I'd particularly like to highlight this one: No instance for (Show ([a0] -> Int)) arising from a use of `show' Possible fix: add an instance declaration for (Show ([a0] -> Int)) The second line looks like it was added by someone who'd read an article about making error messages helpful: "suggest a possible way to fix the error". Like creating a Show instance for a function type!?! I must have seen that "possible fix" 1000 times, and 999 of them it was nothing like the right fix. Now I know just to ignore it. Simply removing the second line would be an improvement: it doesn't add anything to the first line. Toby. From emax at chalmers.se Thu Sep 18 07:22:53 2014 From: emax at chalmers.se (Emil Axelsson) Date: Thu, 18 Sep 2014 09:22:53 +0200 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <201409180849.12784.jan.stolarek@p.lodz.pl> References: <201409180849.12784.jan.stolarek@p.lodz.pl> Message-ID: <541A884D.30601@chalmers.se> I think bound and free usually refers to *occurrences* of variables in an expression. In your example you only have occurrences of g and c, but there may be more hiding in the ... part. A variable is free in an expression if the path from the root to the variable does not include a binder for the variable. In your example, g is bound in the whole expression, but free in the sub-expression g c. However, I think that "bound" is also sometimes used to mean "in scope", and this seems to be mainlyyour interpretation. When you say "y is bound in g", you really mean that y is in scope in *the body* of g (i.e. in the ...) / Emil Den 2014-09-18 08:49, Jan Stolarek skrev: > Hi *, > > I have a simple question about terminology regarding bound and free variables. Assume I have: > > let f x = let g y = ... > in g c > in ... > > Now: > - `c` is free in `g` and `f` > - `y` is bound in `g` > - `x` is free in `g`. > - `x` is bound in `f` > > What about `y` in `f`? Is it also bound in `f`? If so then it certainly is bound in a different > way that `x`. Is there a terminology that allows to distinguish these different forms of bound > variables? > > Janek > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From emax at chalmers.se Thu Sep 18 07:25:51 2014 From: emax at chalmers.se (Emil Axelsson) Date: Thu, 18 Sep 2014 09:25:51 +0200 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <201409180849.12784.jan.stolarek@p.lodz.pl> References: <201409180849.12784.jan.stolarek@p.lodz.pl> Message-ID: <541A88FF.8030608@chalmers.se> [The previous message went off prematurely.] I think bound and free usually refers to *occurrences* of variables in an expression. In your example you only have occurrences of g and c, but there may be more hiding in the ... part. A variable is free in an expression if the path from the root to the variable does not include a binder for the variable. In your example, g is bound in the whole expression, but free in the sub-expression g c. However, I think that "bound" is also sometimes used to mean "in scope", and this seems to be mainly your interpretation. When you say "y is bound in g", you really mean that y is in scope in *the body* of g (i.e. in the ...), or, alternatively that every occurrence of y in the body of g is bound. (IIUC...) / Emil Den 2014-09-18 08:49, Jan Stolarek skrev: > Hi *, > > I have a simple question about terminology regarding bound and free variables. Assume I have: > > let f x = let g y = ... > in g c > in ... > > Now: > - `c` is free in `g` and `f` > - `y` is bound in `g` > - `x` is free in `g`. > - `x` is bound in `f` > > What about `y` in `f`? Is it also bound in `f`? If so then it certainly is bound in a different > way that `x`. Is there a terminology that allows to distinguish these different forms of bound > variables? > > Janek > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jan.stolarek at p.lodz.pl Thu Sep 18 07:30:33 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 18 Sep 2014 09:30:33 +0200 Subject: [Haskell-cafe] Improving ghc error messages In-Reply-To: <1411024417.458.hydrogen.mv6.co.uk@hydrogen.mpv6.com> References: <1411024417.458.hydrogen.mv6.co.uk@hydrogen.mpv6.com> Message-ID: <201409180930.33456.jan.stolarek@p.lodz.pl> Toby, perhaps this short talk from this year's Haskell Implementators Workshop will interest you: http://www.youtube.com/watch?v=rdVqQUOvxSU Janek From jpm at cs.uu.nl Thu Sep 18 07:42:03 2014 From: jpm at cs.uu.nl (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=) Date: Thu, 18 Sep 2014 08:42:03 +0100 Subject: [Haskell-cafe] Improving ghc error messages In-Reply-To: <1411024417.458.hydrogen.mv6.co.uk@hydrogen.mpv6.com> References: <1411024417.458.hydrogen.mv6.co.uk@hydrogen.mpv6.com> Message-ID: On Thu, Sep 18, 2014 at 8:13 AM, Toby Goodwin wrote: > Interesting article: > https://izbicki.me/blog/error-messages-in-ghc-vs-g++.html > > I do hope some of these changes make it into a future ghc. I'd > particularly like to highlight this one: > > No instance for (Show ([a0] -> Int)) arising from a use of `show' > Possible fix: add an instance declaration for (Show ([a0] -> Int)) > > The second line looks like it was added by someone who'd read an article > about making error messages helpful: "suggest a possible way to fix the > error". Like creating a Show instance for a function type!?! > That's a bit unfair. The second line does add a valuable tip in many cases, because often you might indeed just have forgotten to give an instance. That being said, the error reporting mechanism could use a bit of tweaking when it comes to the Show class and the function type, because: 1) Show is used all the time (namely in ghci), and 2) Functions are very often involved in newbie errors (such as forgetting to supply an argument to a function, or doing things like |map(succ [1,2,3])|. Cheers, Pedro > > I must have seen that "possible fix" 1000 times, and 999 of them it was > nothing like the right fix. Now I know just to ignore it. Simply removing > the second line would be an improvement: it doesn't add anything to the > first line. > > Toby. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Thu Sep 18 07:44:17 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 18 Sep 2014 09:44:17 +0200 Subject: [Haskell-cafe] Constructors on left and right hand sides of equation In-Reply-To: References: Message-ID: On Thu, Sep 18, 2014 at 4:08 AM, Richard A. O'Keefe wrote: > > On 18/09/2014, at 2:03 AM, PATRICK BROWNE wrote: > >> Dear list >> In Eq 1 is (NewGlass i) on the LHS distinct from (NewGlass i) on the RHS? >> In Eq2 are the occurrences of the data constructor Fill on the LHS and RHS distinct? >> >> data Glass = NewGlass Int | Fill Glass Int deriving Show >> drink :: Glass -> Int -> Glass >> drink (NewGlass i) j = (NewGlass i) -- Eq 1 >> drink (Fill m i) j >> | full (Fill m i) = Fill (NewGlass (size m)) ((size m) - j) -- Eq 2 >> | (i >= j) = Fill m (i-j) >> | otherwise = drink m (j-1) > > The question question is "what do you MEAN by 'are they distinct'"? > > They are two distinct references to a single binding occurrence > of an identifier. In Eq1, the first occurrence is in a pattern, > and the second is in an expression. > > I wonder if you were interested in the question whether > the second occurrence of NewGlass i would allocate new storage > or whether it would use whatever the first occurrence matched? > In that case, I believe the answer is "it's up to the compiler". > You can *ask* for the matched data to be shared: > > drink g@(NewGlass _) _ = g > drink g@(Fill m i ) j > | full g = Fill (NewGlass (size m)) (size m - j) > | i >= j = Fill m (i - j) > | True = drink m (j - 1) > > Someone else has already pointed out > > data Proxy a = Proxy > > -- foo :: Proxy a -> Proxy b > foo Proxy = Proxy -- Eq3 > > where the two occurrences of Proxy in Eq3 can have different types. > But note that > > -- bar :: Proxy a -> Proxy a > bar p at Proxy = p -- Eq4 > > The two occurrences of the variable p in Eq4 must have > the same type (and the same value). Since we're talking about allocating new storage: even though 'Eq3' has a second occurrence of 'Proxy' on the right hand side, I believe in GHC's implementation these are shared and there is only one Proxy at runtime. Of course this is implementation dependent. Regards, Erik From patrick.browne at dit.ie Thu Sep 18 07:56:39 2014 From: patrick.browne at dit.ie (PATRICK BROWNE) Date: Thu, 18 Sep 2014 08:56:39 +0100 Subject: [Haskell-cafe] Constructors on left and right hand sides of equation In-Reply-To: References: Message-ID: On 18 September 2014 03:08, Richard A. O'Keefe wrote: > The question question is "what do you MEAN by 'are they distinct'"? > > They are two distinct references to a single binding occurrence > of an identifier. In Eq1, the first occurrence is in a pattern, > and the second is in an expression. > Thanks for the feedback. If both occurrences of (NewGlass i) in Eq1 reference the same object in memory then I would consider them to be the same. If they reference different objects I would consider them to be equal but not the same. Is (Fill m i ) in Eq 2 a type constructor? Is it treated the same as the data constructor (NewGlass i)? -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ? ITB?C a th?inig an r?omhphost seo. M? fuair t? an r?omhphost seo tr? earr?id, scrios de do ch?ras ? le do thoil. Tabhair ar aird, mura t? an seola? ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon ch?ipe?il, aon d?ileadh n? ar aon ghn?omh a dh?anfar bunaithe ar an ?bhar at? sa r?omhphost n? sna hiat?in seo. www.dit.ie T? ITB?C ag aistri? go Gr?inseach Ghorm?in ? DIT is on the move to Grangegorman -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Thu Sep 18 08:02:17 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 18 Sep 2014 10:02:17 +0200 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <541A88FF.8030608@chalmers.se> References: <201409180849.12784.jan.stolarek@p.lodz.pl> <541A88FF.8030608@chalmers.se> Message-ID: <201409181002.17411.jan.stolarek@p.lodz.pl> Thanks Emil. > I think bound and free usually refers to *occurrences* of variables in > an expression. Right. I think I was a bit confused here. > However, I think that "bound" is also sometimes used to mean "in scope", > and this seems to be mainly your interpretation. Yup, I think that was it. Thanks for clearing this up for me. Janek From dominic at steinitz.org Thu Sep 18 09:10:48 2014 From: dominic at steinitz.org (Dominic Steinitz) Date: Thu, 18 Sep 2014 09:10:48 +0000 (UTC) Subject: [Haskell-cafe] DSL implementation References: Message-ID: I don't know if this is helpful but the example I gave also uses automatic differentiation. Of course, one can get that in C++ using STAN. From ky3 at atamo.com Thu Sep 18 11:19:16 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 18 Sep 2014 18:19:16 +0700 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: References: <201409180849.12784.jan.stolarek@p.lodz.pl> Message-ID: On Thu, Sep 18, 2014 at 2:09 PM, John Lato wrote: > Is 'y' even referred to in `f`? I don't think it is, so it doesn't make > sense to say if it's bound or free. > > My $.01 (half-off because I don't know what I'm talking about) > Here, I'll add another penny for payment in full. :) I think you do know what you're talking about and I don't see a reference to 'y' in 'f' either, modulo the ... that has already been pointed out. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From anandc at mcmaster.ca Thu Sep 18 13:18:10 2014 From: anandc at mcmaster.ca (Dr Christopher Anand) Date: Thu, 18 Sep 2014 09:18:10 -0400 Subject: [Haskell-cafe] DSL implementation In-Reply-To: References: Message-ID: <1E01D921-7A6F-4F84-A4FE-C2F98C8B41A7@mcmaster.ca> Hi Felipe, We performed an (unplanned) experiment relevant to your case. We developed a DSL in Haskell and a library of math functions while IBM was doing the same thing in C. http://doi.ieeecomputersociety.org/10.1109/TC.2008.223 The C library was 4X slower, and less accurate. More recently we have wrapped-up a prototype for type-safe physical models and there is a preprint and three example implementations which might be of help in constructing your own. http://www.cas.mcmaster.ca/~anand/papers/preprints.html Good luck explaining why Haskell is so good for DSLs. You might find http://cacm.acm.org/magazines/2011/7/109910-dsl-for-the-uninitiated/fulltext helpful. Christopher On Sep 17, 2014, at 2:02 PM, felipe zapata wrote: > HI all, > as a part of a project for physical simulation, I'm was given the task to help with the implementation of an Small DSL that is a minimal functional language. Point is that this small language contains some dependent typed theory, because we want to be able to check statically the shapes of vector and matrices, among other things. Haskell of course seems the tool for the job. > But my boss insists that the implementation should be done in C, but I think that it is madness. > Can someone please point me to relevant literature, discussions or general information that can help me to show my boss that Haskell is the right tool? > > any help would be appreciated. > > Felipe Z. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From audunskaugen at gmail.com Thu Sep 18 15:00:45 2014 From: audunskaugen at gmail.com (Audun Skaugen) Date: Thu, 18 Sep 2014 17:00:45 +0200 Subject: [Haskell-cafe] Confused about AllowAmbiguousTypes Message-ID: I am confused about the behaviour of the AllowAmbiguousTypes extension. I tried the basic example of the user manual: > class C a where > f :: C a => Int > f = 3 > main = print f Using ghc 7.8.3, without the extension, this will cause a type error at the type signature (line 2). Adding AllowAmbgiuousTypes causes an error at the call site instead (line 4). So far so good. However, if I replace the (C a) constraint with (Num a), no type error is reported, and the example runs fine! This is true with or without the extension. Using ghc 7.6.3, however, the example is still rejected with an "ambiguous constraint" error. Is this a bug in ghc 7.8? Is ghc somehow able to prove the Num constraint even though a is universally quantified? -- Audun Skaugen From flickyfrans at gmail.com Thu Sep 18 15:02:53 2014 From: flickyfrans at gmail.com (flicky frans) Date: Thu, 18 Sep 2014 19:02:53 +0400 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: <201409180810.38472.jan.stolarek@p.lodz.pl> References: <201409171310.13929.jan.stolarek@p.lodz.pl> <201409180740.11032.jan.stolarek@p.lodz.pl> <201409180810.38472.jan.stolarek@p.lodz.pl> Message-ID: Plus a b :: (result :: Nat) That looks quite unintuitive to me, since `result' reads like a variable of type Nat. This is similar to legal (with KindSignatures) (5 :: (Int :: *)). Maybe it would be better to use something like associated type synonyms? type family (r ~ *) => Id a :: r | r -> a where type family (res ~ *) => G a b c :: r | res -> a b where type family (result ~ Nat) => Plus a b :: result | result a -> b, result b -> a where From byorgey at gmail.com Thu Sep 18 17:38:27 2014 From: byorgey at gmail.com (Brent Yorgey) Date: Thu, 18 Sep 2014 13:38:27 -0400 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: References: <201409171310.13929.jan.stolarek@p.lodz.pl> <201409180740.11032.jan.stolarek@p.lodz.pl> <201409180810.38472.jan.stolarek@p.lodz.pl> Message-ID: On Thu, Sep 18, 2014 at 11:02 AM, flicky frans wrote: > Plus a b :: (result :: Nat) > > That looks quite unintuitive to me, since `result' reads like a > variable of type Nat. But isn't that exactly what it is supposed to be? -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From flickyfrans at gmail.com Thu Sep 18 19:59:41 2014 From: flickyfrans at gmail.com (flicky frans) Date: Thu, 18 Sep 2014 23:59:41 +0400 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: References: <201409171310.13929.jan.stolarek@p.lodz.pl> <201409180740.11032.jan.stolarek@p.lodz.pl> <201409180810.38472.jan.stolarek@p.lodz.pl> Message-ID: 2014-09-18 21:38 GMT+04:00, Brent Yorgey : > On Thu, Sep 18, 2014 at 11:02 AM, flicky frans > wrote: > >> Plus a b :: (result :: Nat) >> >> That looks quite unintuitive to me, since `result' reads like a >> variable of type Nat. > > > But isn't that exactly what it is supposed to be? At least (Plus a b :: Nat) /= (Plus a b :: (result :: Nat)), since a variable of type Nat is not the type of Plus a b. In (a :: (b :: c)) `a' is a variable, `b' is a type, `c' is a kind (in System F, of course) But yes, I made a mistake, `result' should be a variable. Maybe this? type family Plus a b = r :: * | r a -> b, r b -> a where From jays at panix.com Thu Sep 18 20:11:12 2014 From: jays at panix.com (Jay Sulzberger) Date: Thu, 18 Sep 2014 16:11:12 -0400 (EDT) Subject: [Haskell-cafe] Hello and type-level SKI In-Reply-To: <20140917104303.0AF9AC3827@www1.g3.pair.com> References: <20140917104303.0AF9AC3827@www1.g3.pair.com> Message-ID: On Wed, 17 Sep 2014, oleg at okmij.org wrote: > > Yet another demonstration of Turing completeness of the type checker > (given the unrestricted context reduction stack) was lambda-calculator > in types, posted back in 2006. > > http://okmij.org/ftp/Computation/lambda-calc.html#haskell-type-level > > The examples included the Fibonacci function (encoded using the > fix-point combinator) and the SKI calculator (expressing combinators > as lambda-terms). Oleg, thanks! I have run my eyes over the code, but not yet run it. Heaven forwarding, I will within a few days. Of course, it would be good to have translators between all three Turing machine implementations ;) oo--JS. From flickyfrans at gmail.com Thu Sep 18 20:17:49 2014 From: flickyfrans at gmail.com (flicky frans) Date: Fri, 19 Sep 2014 00:17:49 +0400 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: References: <201409171310.13929.jan.stolarek@p.lodz.pl> <201409180740.11032.jan.stolarek@p.lodz.pl> <201409180810.38472.jan.stolarek@p.lodz.pl> Message-ID: Sorry. type family Plus a b = r :: Nat | r a -> b, r b -> a where From fuuzetsu at fuuzetsu.co.uk Fri Sep 19 01:22:03 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 19 Sep 2014 02:22:03 +0100 Subject: [Haskell-cafe] optional ghc-options based on GHC version? In-Reply-To: References: <541A458F.6080207@fuuzetsu.co.uk> Message-ID: <541B853B.1060703@fuuzetsu.co.uk> On 09/18/2014 04:33 AM, Ivan Lazar Miljenovic wrote: > Something like this: > > > if True > Ghc-Options: -O -Wall > > if impl(ghc >= 7.8.1) > Ghc-Options: -flate-dmd-anal > > (I'm not sure if the "if True" hack is still needed, but at one stage it was.) > > On 18 September 2014 12:38, Mateusz Kowalczyk wrote: >> Hi, >> >> I have a project here where GHC's option -flate-dmd-anal gets out some >> extra speed but the flag is not available on 7.6.3. How can I specify in >> the cabal file that I only want to pass this through when building with >> 7.8.3 or newer? It'd be a shame to not take advantage of the extra speed >> on 7.8.3 just because we want to support 7.6.3 too for a bit longer. I >> was unable to find the info online. >> >> Thanks. >> >> -- >> Mateusz K. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > Seems to work great, thanks. -- Mateusz K. From haskell.ye.yan at gmail.com Fri Sep 19 04:32:28 2014 From: haskell.ye.yan at gmail.com (ye yan) Date: Thu, 18 Sep 2014 21:32:28 -0700 (PDT) Subject: [Haskell-cafe] Haskell FFI Question Message-ID: <9b03570d-2f98-4c0b-aa24-e4a003bf365c@googlegroups.com> I have been play around with Haskell FFI. My question is for ByteString (Strict) is there a trailing null append to it when pass to it C functions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Fri Sep 19 04:55:20 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 19 Sep 2014 06:55:20 +0200 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: References: <201409171310.13929.jan.stolarek@p.lodz.pl> Message-ID: <201409190655.20575.jan.stolarek@p.lodz.pl> > type family Plus a b = r :: Nat | r a -> b, r b -> a where Identical proposal was also made on GHC Trac and at the moment it looks likely that we'll go with that. Janek From ok at cs.otago.ac.nz Fri Sep 19 05:05:25 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 19 Sep 2014 17:05:25 +1200 Subject: [Haskell-cafe] Constructors on left and right hand sides of equation In-Reply-To: References: Message-ID: On 18/09/2014, at 7:56 PM, PATRICK BROWNE wrote: > Thanks for the feedback. > If both occurrences of (NewGlass i) in Eq1 reference the same object in memory then I would consider them to be the same. > If they reference different objects I would consider them to be equal but not the same. > Is (Fill m i ) in Eq 2 a type constructor? Is it treated the same as the data constructor (NewGlass i)? Let's repeat the original code. data Glass -- missing comment = NewGlass Int -- missing comment | Fill Glass Int -- missing comment deriving Show drink :: Glass -> Int -> Glass drink (NewGlass i) j = (NewGlass i) -- Eq 1 drink (Fill m i) j | full (Fill m i) = Fill (NewGlass (size m)) ((size m) - j) -- Eq 2 | i >= j = Fill m (i-j) | otherwise = drink m (j-1) First, (Fill m i) isn't *any* kind of constructor. Second, the first occurrence of (Fill m i) is a (data) pattern containing the (data) constructor Fill, and the second occurrence of (Fill m i) is an expression containing the (data) constructor Fill. We may not know what Glass, NewGlass, and Fill *mean*, but we know what they *are* (as Haskell thingies). There are no objects, and "are these the same object" is not a question that can meaningfully be asked about values in a Haskell program. (It IS a question that CAN meaningfully be asked about the related language Clean, because Clean has, or is alleged to have, a semantics in terms of graph rewriting, where "node in graph" is not entirely unlike "object".) As has been previously noted, two occurrences of "the same" term need not have the same type. I have often been tripped up by this: emap :: (a -> b) -> Either String a -> Either String b emap _ (Left msg) = Left msg emap f (Right val) = Right (f val) works but emap _ e@(Left msg) = e emap f (Right val) = Right (f val) does not work because the two occurrences of Left msg have different types. When the two occurrences *do* have the same type, it is up to the compiler to decide whether they will refer to the same place in memory or whether a copy will be made. There is no test you can perform in Haskell to distinguish. (It's the same in Prolog and Erlang and SML and F#.) If it comes to that, consider a much simpler question. f :: Integer -> Integer f 123456789123456789123456789 = 123456789123456789123456789 f _ = error "just an example" Are the two occurrences of that big integer "the same"? Who knows? How could you tell? Now consider g :: (Char,Int) -> (Char,Int) g pair@(_,_) = pair I would like to tell you that multiple occurrences of the same *variable* refer to a single copy of the data value, but I can't find anything in the Haskell report to guarantee this. Maybe I didn't look hard enough. From haskell at nand.wakku.to Fri Sep 19 05:34:58 2014 From: haskell at nand.wakku.to (Niklas Haas) Date: Fri, 19 Sep 2014 07:34:58 +0200 Subject: [Haskell-cafe] Injective type families for GHC - syntax proposals In-Reply-To: References: <201409171310.13929.jan.stolarek@p.lodz.pl> <201409180740.11032.jan.stolarek@p.lodz.pl> <201409180810.38472.jan.stolarek@p.lodz.pl> Message-ID: <20140919073458.GB29061@nanodesu.localdomain> On Fri, 19 Sep 2014 00:17:49 +0400, flicky frans wrote: > Sorry. > > type family Plus a b = r :: Nat | r a -> b, r b -> a where +1 Simple, intuitive and backwards compatible. I don't have to introduce a variable if I don't want to, either. From haskell.ye.yan at gmail.com Fri Sep 19 06:08:09 2014 From: haskell.ye.yan at gmail.com (ye yan) Date: Thu, 18 Sep 2014 23:08:09 -0700 (PDT) Subject: [Haskell-cafe] Haskell FFI Question In-Reply-To: <9b03570d-2f98-4c0b-aa24-e4a003bf365c@googlegroups.com> References: <9b03570d-2f98-4c0b-aa24-e4a003bf365c@googlegroups.com> Message-ID: <209a6745-0284-43f6-a050-cdc2aeb8e54a@googlegroups.com> Another question is how to pass a raw buffer (binary content) from Haskell to C functions? Assume we are using ByteString as the content container in Haskell. Is there a way to convert ByteString to C void * ? On Friday, September 19, 2014 2:02:29 PM UTC+9:30, ye yan wrote: > > I have been play around with Haskell FFI. My question is for ByteString > (Strict) is there a trailing null append to it when pass to it C functions? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Fri Sep 19 07:20:21 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Fri, 19 Sep 2014 09:20:21 +0200 Subject: [Haskell-cafe] Haskell FFI Question In-Reply-To: <9b03570d-2f98-4c0b-aa24-e4a003bf365c@googlegroups.com> References: <9b03570d-2f98-4c0b-aa24-e4a003bf365c@googlegroups.com> Message-ID: Yes, see the documentation for useAsCString [0]. [0] http://hackage.haskell.org/package/bytestring-0.10.4.0/docs/Data-ByteString.html#v:useAsCString Erik On Fri, Sep 19, 2014 at 6:32 AM, ye yan wrote: > I have been play around with Haskell FFI. My question is for ByteString > (Strict) is there a trailing null append to it when pass to it C functions? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From wangbj at gmail.com Fri Sep 19 08:00:19 2014 From: wangbj at gmail.com (Baojun Wang) Date: Fri, 19 Sep 2014 01:00:19 -0700 Subject: [Haskell-cafe] preventing space leaks? Message-ID: Hi Cafe, I'm very new to Haskell, and I'm confused about haskell space leaks, even I read some wiki pages from haskell.org. Below is the scenario I''m facing at: When I use listArray to create either IArray or UArray, I found it could lead to space leaks (very high GC time), is there a way to prevent this, and why there is no fusion when create IArray/UArray from the list? I don't need the list anyway after array is created. (I used this few times for DP, based on this link: http://jelv.is/blog/Lazy-Dynamic-Programming/). Further more, suppose if I create a IArray A from list 1, later I create UArray B based some computations based on A (also I need discard another list 2). After B is generated, I don't need A anymore (so this lead to space leaks, correct)? Another quetion, by the way, after the lazy IArray is created (say from a DP), is there a way convert it to UArray for better performance (IArray -> UArray)? How can I improve the space leak problems with above use case? Best Regards Baojun -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Sep 19 08:05:46 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 19 Sep 2014 09:05:46 +0100 Subject: [Haskell-cafe] preventing space leaks? In-Reply-To: References: Message-ID: <20140919080546.GL27848@weber> On Fri, Sep 19, 2014 at 01:00:19AM -0700, Baojun Wang wrote: > When I use listArray to create either IArray or UArray, I found it could > lead to space leaks (very high GC time), is there a way to prevent this, > and why there is no fusion when create IArray/UArray from the list? I don't > need the list anyway after array is created. (I used this few times for DP, > based on this link: http://jelv.is/blog/Lazy-Dynamic-Programming/). Could you post some code? From wangbj at gmail.com Fri Sep 19 08:23:06 2014 From: wangbj at gmail.com (Baojun Wang) Date: Fri, 19 Sep 2014 01:23:06 -0700 Subject: [Haskell-cafe] preventing space leaks? In-Reply-To: <20140919080546.GL27848@weber> References: <20140919080546.GL27848@weber> Message-ID: I'm trying to solve this issue: http://www.spoj.com/problems/NFACTOR/ I'm not asking how to solve this issue, you could try if you like, I found it's pretty hard with Haskell :p Basically I'm trying to find numbers of distinct prime factors in [1..10^6], and because the query (begin, end, k) could be huge, so I create a dedicate UArray for each size k, so that for every (begin, end, k) query, I only need to binary search the UArray with given size k, no need to iterate from begin to end. important steps are: 1) sieve [1..10^6]; (generate UArray a) 2) compute number of distinct prime factors from above result; (generate IArray b with little bit DP) 3) generate a IArray Int (UArray Int Int) for each given size k (generate 10 UArray Int Int from 10 lists, and then another UArray Int (UArray Int Int) wrap the 10 UArray to a 2D IArray. source code is nfactor4.hs from the attachment. -- Below is the sample input I'm using (/tmp/n2.txt): 15 1 3 1 1 10 2 1 10 3 1 100 3 1 1000 0 1 1000000 1 1 1000000 2 1 1000000 3 1 1000000 4 1 1000000 5 1 1000000 6 1 1000000 7 1 1000000 8 1 1000000 9 1 1000000 10 -- Here is the output: $ time cat /tmp/n2.txt | ./nfactor4 +RTS -sstderr -p 2 2 0 8 1 78734 288726 379720 208034 42492 2285 8 0 0 0 923,210,584 bytes allocated in the heap 996,236,400 bytes copied during GC 321,372,456 bytes maximum residency (7 sample(s)) 4,069,728 bytes maximum slop 496 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1450 colls, 0 par 0.74s 0.74s 0.0005s 0.0195s Gen 1 7 colls, 0 par 1.00s 1.00s 0.1424s 0.3483s INIT time 0.00s ( 0.00s elapsed) MUT time 0.62s ( 0.61s elapsed) GC time 1.73s ( 1.73s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.00s ( 0.00s elapsed) EXIT time 0.09s ( 0.09s elapsed) Total time 2.44s ( 2.44s elapsed) %GC time 71.0% (71.2% elapsed) Alloc rate 1,500,811,457 bytes per MUT second Productivity 28.9% of total user, 29.0% of total elapsed [1]+ Done emacs nfactor4.hs real 0m2.445s user 0m2.095s sys 0m0.351s -- >From profiling data (nfactor4.prof is the full profiling data), below functions leak hell lot of space: buildnfactscache.go Main 138 1000000 30.8 54.9 41.3 54.9 buildnfactorsmemo.memo Main 133 1 10.4 26.7 39.0 42.3 buildnfactorsmemo.go Main 139 1000000 24.8 15.6 28.6 15.6 On Fri, Sep 19, 2014 at 1:05 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Fri, Sep 19, 2014 at 01:00:19AM -0700, Baojun Wang wrote: > > When I use listArray to create either IArray or UArray, I found it could > > lead to space leaks (very high GC time), is there a way to prevent this, > > and why there is no fusion when create IArray/UArray from the list? I > don't > > need the list anyway after array is created. (I used this few times for > DP, > > based on this link: http://jelv.is/blog/Lazy-Dynamic-Programming/). > > Could you post some code? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nfactor4.prof Type: application/octet-stream Size: 10555 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nfactor4.hs Type: text/x-haskell Size: 5821 bytes Desc: not available URL: From corentin.dupont at gmail.com Fri Sep 19 10:13:29 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Fri, 19 Sep 2014 12:13:29 +0200 Subject: [Haskell-cafe] move sandboxes Message-ID: Hi guys, is there a pratical way to move a sandbox? I see the absolute path are hard-coded in all the .conf files. I ask the question because I have an application that uses Hint. So it needs to run with the same object files that it was compiled with. If I want to deploy the application on a server, I need to send the whole sandbox there: this way Hint/GHC finds the database when I start with "cabal exec". But this forces me to deploy it on the same path it was compiled, which is not very practical. Cheers C -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjwchoy at gmail.com Fri Sep 19 13:58:00 2014 From: jjwchoy at gmail.com (Jason Choy) Date: Fri, 19 Sep 2014 14:58:00 +0100 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws Message-ID: The Monoid instances for Sum and Product do not respect the Monoid laws. The instances are: Num a => instance Monoid (Sum a) Num a => instance Monoid (Product a) Float and Double are instances of the Num typeclass, however, floating point addition and multiplication are not associative. Here's an example: > (Sum 1234.567 `mappend` Sum 45.67834) `mappend` Sum 0.0004 Sum {getSum = 1280.2457399999998} > Sum 1234.567 `mappend` (Sum 45.67834 `mappend` Sum 0.0004) Sum {getSum = 1280.24574} Shouldn't these instances be constrained to Integral types? Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidleothomas at gmail.com Fri Sep 19 14:31:56 2014 From: davidleothomas at gmail.com (David Thomas) Date: Fri, 19 Sep 2014 07:31:56 -0700 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: Message-ID: Restricting to Integral only would be overconstraining - Sum Rational is perfectly well behaved as a monoid. I could go either way on whether Double and Float should be excluded - I'm actually slightly sympathetic to the notion that they shouldn't even be Num. On Fri, Sep 19, 2014 at 6:58 AM, Jason Choy wrote: > The Monoid instances for Sum and Product do not respect the Monoid laws. > > The instances are: > > Num a => instance Monoid (Sum a) > Num a => instance Monoid (Product a) > > Float and Double are instances of the Num typeclass, however, floating point > addition and multiplication are not associative. Here's an example: > >> (Sum 1234.567 `mappend` Sum 45.67834) `mappend` Sum 0.0004 > Sum {getSum = 1280.2457399999998} > >> Sum 1234.567 `mappend` (Sum 45.67834 `mappend` Sum 0.0004) > Sum {getSum = 1280.24574} > > Shouldn't these instances be constrained to Integral types? > > Jason > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From patrick.browne at dit.ie Fri Sep 19 14:49:53 2014 From: patrick.browne at dit.ie (PATRICK BROWNE) Date: Fri, 19 Sep 2014 15:49:53 +0100 Subject: [Haskell-cafe] Constructors on left and right hand sides of equation In-Reply-To: References: Message-ID: On 19 September 2014 06:05, Richard A. O'Keefe wrote: > drink (NewGlass i) j = (NewGlass i) -- Eq 1 > drink (Fill m i) j > | full (Fill m i) = Fill (NewGlass (size m)) ((size m) - j) -- Eq 2 > | i >= j = Fill m (i-j) > | otherwise = drink m (j-1) > > First, (Fill m i) isn't *any* kind of constructor. > Second, the first occurrence of (Fill m i) is a (data) pattern > containing the (data) constructor Fill, and the second occurrence > of (Fill m i) is an expression containing the (data) constructor > Fill. We may not know what Glass, NewGlass, and Fill *mean*, > but we know what they *are* (as Haskell thingies). Your response has clarified most of my confusion. Please bear with my naivety as seek to ride my mind of confusion over these two point: 1) I do not know what the phrase "(Fill m i) isn't *any* kind of constructor." means. 2) Does "Fill (NewGlass (size m)) ((size m) - j) " create two Glass Haskell thingies? The context of this code is an attempt to formalize the drinking operation[1]. [1] www.ncgia.ucsb.edu/Publications/Tech_Reports/95/95-7.pdf -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ? ITB?C a th?inig an r?omhphost seo. M? fuair t? an r?omhphost seo tr? earr?id, scrios de do ch?ras ? le do thoil. Tabhair ar aird, mura t? an seola? ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon ch?ipe?il, aon d?ileadh n? ar aon ghn?omh a dh?anfar bunaithe ar an ?bhar at? sa r?omhphost n? sna hiat?in seo. www.dit.ie T? ITB?C ag aistri? go Gr?inseach Ghorm?in ? DIT is on the move to Grangegorman -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Fri Sep 19 16:48:36 2014 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Fri, 19 Sep 2014 11:48:36 -0500 Subject: [Haskell-cafe] Craig Gentry of IBM Message-ID: Hi, Gentry is doing on homomorphic functions cryptography. I looked on Hackage but did see a homomorphic function library. Is there.any effort in this area in Haskell? If so by whom and is contact info? Vasya -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Sep 19 17:26:13 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 19 Sep 2014 10:26:13 -0700 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: Message-ID: Indeed, Also Floating point numbers are *NOT* real numbers, they are approximate points on the real line that we pretend are exact reals but really are a very different geometry all together! :) If you want to get extra precision in a floating point computation in a way avoids the "discrepancy" when permuting the numbers, the compensated library by Edward Kmett http://hackage.haskell.org/package/compensated lets you easily double or quadruple the number of bits of precision you get in sums and products, which makes a lot of these problems go way quite nicely! Floats and Doubles are not exact numbers, dont use them when you expect things to behave "exact". NB that even if you have *exact* numbers, the exact same precision issues will still apply to pretty much any computation thats interesting (ignoring what the definition of interesting is). Try defining things like \ x -> SquareRoot x or \x-> e^x on the rational numbers! Questions of precision still creep in! So I guess phrased another way, a lot of the confusion / challenge in writing floating point programs lies in understanding the representation, its limits, and the ways in which it will implicitly manage that precision tracking book keeping for you. Computational mathematics is a really rich and complicated topic! Theres many more (valid and different) constructive models of different classes of numbers than you'd expect! On Fri, Sep 19, 2014 at 7:31 AM, David Thomas wrote: > Restricting to Integral only would be overconstraining - Sum Rational > is perfectly well behaved as a monoid. I could go either way on > whether Double and Float should be excluded - I'm actually slightly > sympathetic to the notion that they shouldn't even be Num. > > On Fri, Sep 19, 2014 at 6:58 AM, Jason Choy wrote: > > The Monoid instances for Sum and Product do not respect the Monoid laws. > > > > The instances are: > > > > Num a => instance Monoid (Sum a) > > Num a => instance Monoid (Product a) > > > > Float and Double are instances of the Num typeclass, however, floating > point > > addition and multiplication are not associative. Here's an example: > > > >> (Sum 1234.567 `mappend` Sum 45.67834) `mappend` Sum 0.0004 > > Sum {getSum = 1280.2457399999998} > > > >> Sum 1234.567 `mappend` (Sum 45.67834 `mappend` Sum 0.0004) > > Sum {getSum = 1280.24574} > > > > Shouldn't these instances be constrained to Integral types? > > > > Jason > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Fri Sep 19 22:32:00 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 20 Sep 2014 01:32:00 +0300 Subject: [Haskell-cafe] Confused about AllowAmbiguousTypes In-Reply-To: References: Message-ID: <541CAEE0.7050105@ro-che.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I imagine defaulting is involved here. On 09/18/2014 06:00 PM, Audun Skaugen wrote: > I am confused about the behaviour of the AllowAmbiguousTypes > extension. I tried the basic example of the user manual: > >> class C a where f :: C a => Int f = 3 main = print f > > Using ghc 7.8.3, without the extension, this will cause a type > error at the type signature (line 2). Adding AllowAmbgiuousTypes > causes an error at the call site instead (line 4). So far so good. > > However, if I replace the (C a) constraint with (Num a), no type > error is reported, and the example runs fine! This is true with or > without the extension. Using ghc 7.6.3, however, the example is > still rejected with an "ambiguous constraint" error. > > Is this a bug in ghc 7.8? Is ghc somehow able to prove the Num > constraint even though a is universally quantified? > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUHK7gAAoJEOkNLkFQ6mTVRXwP/iyO0j/6/nrA9Ill4B9xqlBR jvrPNchVjorz3z6CvWpG3CJT/GG3uPDETcyFtw8V0Pbs4kQXDfCYAuSQxorzg2TQ jwZ8tWTo2xEX195YT45ghuohMyWM6DF2Q/Kl4DceU+WnRbJo2hsvYnmdXVN/ZhjU B5woPiqzQSd4b4irhM/uyPt69DbFnq+EmsNtD40V/WSpeczLQCFr+gd9/9KUSM3q LplJGXg2X3992ABt4+8Um+0BW4Gq0i1m3gDKjth6QIBMxoNlVexTKsbqlZAaQBd3 RzB5Gi6uXqWzPJclEyTiRfmDn18Wou7waMzlCH25biFz7uFq6uaLDbilmIiv2kpm Y7ycpC0Zmi2Lrf/hqS5bOaJkz+DvjKgQhGoxsmfWyNfoqTnX0MePTgZ1mbvPnfoQ FMN/J86XPa20m3zOGayUZ/YQ4tNmkC57ssj5mpxilqvgGCHPD/p4GharBfP/eC6M 13j4jpXBZI4m86j/kIoExl7MxWahF+aDoiU5m0w77/1x4x5NSOQ7D62KY8nVqvc7 TcnMEjI4MvJU80EuOwAsDIOR2WnYYV+mh2vYaliS4jC7tCNTZouHAa+uKbh/vVIx ZQVwhm45fp7Du5DZzCwMjxU6lrG3xsDrNVI325EVnxxOn1IyK6VLHz7kOtkd3yRe GHKKTVrSwia2TxhJLc4+ =USJg -----END PGP SIGNATURE----- From martin.drautzburg at web.de Sat Sep 20 01:14:00 2014 From: martin.drautzburg at web.de (martin) Date: Sat, 20 Sep 2014 03:14:00 +0200 Subject: [Haskell-cafe] Chaining modifications using (>>>) Message-ID: <541CD4D8.8030502@web.de> Hello all, I've been playing with Data.Graph.Inductive, which provides functions to modify a graph. I take these functions and build something more complex from them. To do so, I have to apply several such modifications one after the other. I can write this using ($) or (.), but I didn't like to write things backwards (last function to apply comes first), so I use (>>>) from the Arrows module to chain functions Graph -> Graph (aka GraphTransforms) and my complex function looks like f >>> g >>> h. To actually build a Graph I have to apply my function to some Graph (often "empty"). This works okay as long as the inidividual functions f,g,h do not need access to the graph. However, there is one function where I use "pre" (predecessors) and "suc" (succerssors), which need the Graph as a parameter. groupNodes :: DynGraph gr => (Label,[Node]) -> GraphTransform gr pl groupNodes (lbl,ids) gr = let id = head $ newNodes 1 gr oldEdgesTo = [(toOld, old) | old <- ids, toOld <- pre gr old] -- <== here "pre" oldEdgesFrom = [(old, fromOld) | old <- ids, fromOld <- suc gr old] oldEdges = oldEdgesTo ++ oldEdgesFrom oldEdgesWithin = [ (i,j) | (i,j) <- oldEdges, i `elem` ids, j `elem` ids] newEdges = map (uncurry e0) $ uniq $ map (setDest id) (oldEdgesTo \\ oldEdgesWithin) ++ map (setOrig id) (oldEdgesFrom \\ oldEdgesWithin) in --------------- look here: ----------------------- ( insNode (id, (NN lbl)) >>> delNodes ids >>> delEdges oldEdges >>> insEdges newEdges ) gr This works, but I don't like the "in" part and I'd rather omit the braces and the gr argument. Without the gr argument to the whole function this would work, however with the gr I have to kinda eta expand (?) it. Is there a way I can write this more point free and still have access to gr for pre and suc? From haskell.ye.yan at gmail.com Sat Sep 20 07:40:14 2014 From: haskell.ye.yan at gmail.com (ye yan) Date: Sat, 20 Sep 2014 00:40:14 -0700 (PDT) Subject: [Haskell-cafe] Haskell FFI Question In-Reply-To: References: <9b03570d-2f98-4c0b-aa24-e4a003bf365c@googlegroups.com> Message-ID: <7a94f162-a4d2-4955-9692-194be64f1ec9@googlegroups.com> Thank you guys, I finally make the FFI working. But I found a *interesting* behavior with in my C++ side of code. I have made a simple thumbnail generation function in C++ side which include the following snippet of code ``` Blob blob; try { On Friday, September 19, 2014 4:50:57 PM UTC+9:30, Erik Hesselink wrote: > > Yes, see the documentation for useAsCString [0]. > > [0] > http://hackage.haskell.org/package/bytestring-0.10.4.0/docs/Data-ByteString.html#v:useAsCString > > Erik > > On Fri, Sep 19, 2014 at 6:32 AM, ye yan > wrote: > > I have been play around with Haskell FFI. My question is for ByteString > > (Strict) is there a trailing null append to it when pass to it C > functions? > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskel... at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell.ye.yan at gmail.com Sat Sep 20 07:47:53 2014 From: haskell.ye.yan at gmail.com (ye yan) Date: Sat, 20 Sep 2014 00:47:53 -0700 (PDT) Subject: [Haskell-cafe] Haskell FFI Question In-Reply-To: <9b03570d-2f98-4c0b-aa24-e4a003bf365c@googlegroups.com> References: <9b03570d-2f98-4c0b-aa24-e4a003bf365c@googlegroups.com> Message-ID: <591b51da-02a6-4bdc-9136-5aae3071dd68@googlegroups.com> Sorry, accidentally clicked post; in haskell FFI c++ side Blob db; try { sb.update(src, src_len); } catch (Magick::Exception &error) { //do something with error } if I compile my program in to c++ program this code works perfectly fine. The exception can be handled correctly. But if link this piece of code into haskell (main is in haskell side), the exception handle code will never be triggered. However if I change the code to Blob db; try { sb.update(src, src_len); } catch (...) { //can really do any thing but tell user this function failed } the exception handle part can be triggered in this way. My question is : how can I catch exception without using (...) in Haskell FFI? On Friday, September 19, 2014 2:02:29 PM UTC+9:30, ye yan wrote: > > I have been play around with Haskell FFI. My question is for ByteString > (Strict) is there a trailing null append to it when pass to it C functions? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Sat Sep 20 16:23:50 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 20 Sep 2014 17:23:50 +0100 Subject: [Haskell-cafe] Chaining modifications using (>>>) In-Reply-To: <541CD4D8.8030502@web.de> References: <541CD4D8.8030502@web.de> Message-ID: <541DAA16.9000802@fuuzetsu.co.uk> On 09/20/2014 02:14 AM, martin wrote: > Hello all, > > I've been playing with Data.Graph.Inductive, which provides functions to modify a graph. I take these functions and > build something more complex from them. To do so, I have to apply several such modifications one after the other. > > I can write this using ($) or (.), but I didn't like to write things backwards (last function to apply comes first), so > I use (>>>) from the Arrows module to chain functions Graph -> Graph (aka GraphTransforms) and my complex function looks > like f >>> g >>> h. To actually build a Graph I have to apply my function to some Graph (often "empty"). > > This works okay as long as the inidividual functions f,g,h do not need access to the graph. However, there is one > function where I use "pre" (predecessors) and "suc" (succerssors), which need the Graph as a parameter. > > groupNodes :: DynGraph gr => (Label,[Node]) -> GraphTransform gr pl > groupNodes (lbl,ids) gr = > let > id = head $ newNodes 1 gr > oldEdgesTo = [(toOld, old) | old <- ids, toOld <- pre gr old] -- <== here "pre" > oldEdgesFrom = [(old, fromOld) | old <- ids, fromOld <- suc gr old] > oldEdges = oldEdgesTo ++ oldEdgesFrom > oldEdgesWithin = [ (i,j) | (i,j) <- oldEdges, i `elem` ids, j `elem` ids] > newEdges = map (uncurry e0) $ uniq $ > map (setDest id) (oldEdgesTo \\ oldEdgesWithin) ++ > map (setOrig id) (oldEdgesFrom \\ oldEdgesWithin) > in --------------- look here: ----------------------- > ( > insNode (id, (NN lbl)) > >>> delNodes ids > >>> delEdges oldEdges > >>> insEdges newEdges > ) gr > > This works, but I don't like the "in" part and I'd rather omit the braces and the gr argument. Without the gr argument > to the whole function this would work, however with the gr I have to kinda eta expand (?) it. > > Is there a way I can write this more point free and still have access to gr for pre and suc? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Did you look at the arrow syntax extension? -- Mateusz K. From hjgtuyl at chello.nl Sat Sep 20 18:30:07 2014 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 20 Sep 2014 20:30:07 +0200 Subject: [Haskell-cafe] Linking/uploading a PDF file in HaskellWiki Message-ID: L.S., I am trying to link a PDF file, that is to be uploaded to the HaskellWiki environment, but I encounter several problems: - The link [[File:wxhaskell.pdf | wxHaskell - A Portable and Concise GUI Library for Haskell]] is displayed as File:wxhaskell.pdf instead of wxHaskell - A Portable and Concise GUI Library for Haskell If I leave out the vertical bar, the entire string between the brackets is displayed and used as filename - If I click the link, I am asked to upload the file; the resulting file should be http://www.haskell.org/haskellwiki/File:Wxhaskell.pdf but this URL results in a blank page - The list of uploaded files should be at http://www.haskell.org/haskellwiki/Special:ListFiles but this URL results in a blank page as well Am I doing something wrong, or are these Wiki bugs? Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From gershomb at gmail.com Sun Sep 21 01:26:52 2014 From: gershomb at gmail.com (Gershom B) Date: Sat, 20 Sep 2014 21:26:52 -0400 Subject: [Haskell-cafe] Linking/uploading a PDF file in HaskellWiki In-Reply-To: References: Message-ID: For the information of all, I just fixed this! Sorry for the mess. Jost had pinged me earlier as well. It turns out that this probably broke with an upgrade to the haskell wiki, which as we sadly know runs on mediawiki. While it has been claimed that PHP (which Phab also runs on) is about ?Powerful Haskell Programming?, in fact this is not the case. A further upgrade might have fixed this, but since I don?t know the surface area of that, I just found and fixed the bugs, which were delightful. Three instances of null pointer errors caused by a type error of assuming that all uploads would be images and not e.g. pdfs or the like. Hence a ?feature? of creating thumbnail galleries instead just broke everything flat out for uses such as ours. In a true php fashion I just shrugged, threw in a few null pointer checks, and moved on. Well, always nice to confirm that the Haskell way indeed has virtue. Prior uploads should actually have worked, but were simply inaccessible due to this mess. Now, those files should be available. Cheers, Gershom On September 20, 2014 at 2:30:28 PM, Henk-Jan van Tuyl (hjgtuyl at chello.nl) wrote: > > L.S., > > I am trying to link a PDF file, that is to be uploaded to the HaskellWiki > environment, but I encounter several problems: > - The link > [[File:wxhaskell.pdf | wxHaskell - A Portable and Concise GUI Library > for Haskell]] > is displayed as > File:wxhaskell.pdf > instead of > wxHaskell - A Portable and Concise GUI Library for Haskell > If I leave out the vertical bar, the entire string between > the brackets is displayed and used as filename > > - If I click the link, I am asked to upload the file; the resulting file > should be > http://www.haskell.org/haskellwiki/File:Wxhaskell.pdf > but this URL results in a blank page > > - The list of uploaded files should be at > http://www.haskell.org/haskellwiki/Special:ListFiles > but this URL results in a blank page as well > > Am I doing something wrong, or are these Wiki bugs? > > Regards, > Henk-Jan van Tuyl > > > -- > Folding at home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://folding.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From sol at typeful.net Sun Sep 21 14:44:10 2014 From: sol at typeful.net (Simon Hengel) Date: Sun, 21 Sep 2014 22:44:10 +0800 Subject: [Haskell-cafe] ANN: vimus - An MPD client with vim-like key bindings Message-ID: <20140921144410.GA8374@x200> Hi, I just uploaded vimus [1] to Hackage. vimus is an MPD client with vim-like key bindings. I've been using it as my exclusive music player since early 2010. It comes with it's own quick & dirty ncurses bindings, which is one of the reasons why I was reluctant to push it to Hackage so far. Check the README for installation and usage: https://github.com/vimus/vimus#readme vimus is not a masterpiece of coding beauty** , but it's incredibly useful to me and a couple of other people over at #vimus on Freenode. Patches are welcome as long as they - reduce code bloat and improve hackability - do not conflict with my use cases (in case of doubt we make things configurable) - do not require lots of work from my side (vimus already works incredibly well for me and I can not spend too many cycles on it) vimus would not be what it is today without the help of others. In particular I'm grateful to - Niklas Haas for being the second user of vimus and contributing many useful features - Joachim Fasting for his work on libmpd and contributing high quality patches to vimus - Markus Klinik for contributing documentation and features - Matvey Aksenov for adding even more features Cheers, Simon ** Indeed, vimus served me as a testing ground for experimenting with both Haskell and lean software development. [1] http://hackage.haskell.org/package/vimus [2] https://github.com/vimus/vimus#using-vimus From sol at typeful.net Sun Sep 21 15:00:27 2014 From: sol at typeful.net (Simon Hengel) Date: Sun, 21 Sep 2014 23:00:27 +0800 Subject: [Haskell-cafe] ANN: vimus - An MPD client with Emacs-style key bindings (was: ANN: vimus - An MPD client with vim-like key bindings) In-Reply-To: <20140921144410.GA8374@x200> References: <20140921144410.GA8374@x200> Message-ID: <20140921150027.GA14611@x200> Hey, one more thing, there are Emacs key bindings as well (courtesy of Joachim Fasting): https://github.com/vimus/vimus#emacs--keybindings Cheers. On Sun, Sep 21, 2014 at 10:44:10PM +0800, Simon Hengel wrote: > Hi, > I just uploaded vimus [1] to Hackage. > > vimus is an MPD client with vim-like key bindings. > > I've been using it as my exclusive music player since early 2010. It > comes with it's own quick & dirty ncurses bindings, which is one of the > reasons why I was reluctant to push it to Hackage so far. > > Check the README for installation and usage: > > https://github.com/vimus/vimus#readme > > vimus is not a masterpiece of coding beauty** , but it's incredibly > useful to me and a couple of other people over at #vimus on Freenode. > > Patches are welcome as long as they > > - reduce code bloat and improve hackability > > - do not conflict with my use cases (in case of doubt we make things > configurable) > > - do not require lots of work from my side (vimus already works > incredibly well for me and I can not spend too many cycles on it) > > vimus would not be what it is today without the help of others. In > particular I'm grateful to > > - Niklas Haas for being the second user of vimus and contributing many > useful features > > - Joachim Fasting for his work on libmpd and contributing high quality > patches to vimus > > - Markus Klinik for contributing documentation and features > > - Matvey Aksenov for adding even more features > > Cheers, > Simon > > ** Indeed, vimus served me as a testing ground for experimenting with > both Haskell and lean software development. > > [1] http://hackage.haskell.org/package/vimus > [2] https://github.com/vimus/vimus#using-vimus > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ollie at ocharles.org.uk Sun Sep 21 18:13:28 2014 From: ollie at ocharles.org.uk (Oliver Charles) Date: Sun, 21 Sep 2014 19:13:28 +0100 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage Message-ID: Hi all, I'd like to start a conversation around the ghc-prof-options option that can be used in Cabal-ized libraries. As you may know, this option specifies extra GHC options that are used when --enable-library-profiling is enabled. This is very convenient for local development, but I argue that it can be counter-productive for releases onto Hackage. To provide an example, I'm currently working on a little game engine that uses JuicyPixels to load images. I have a problem in my code that needs optimizing, but the current state of things results in profiles that are very difficult to work with. JuicyPixels specifies -auto-all in its cabal file, which means I have no alternative but to profile JuicyPixels code. In this scenario, the bottleneck is actually within my FRP game loop and nothing to do with image loading! As a result, the profiles are fairly useless to me. Roman Cheplyaka also points out that by doing this, profiles are skewed - -auto-all is not free, so we actually pay in runtime performance every time a library does this. I would like to hear from others if we should consider managing this option a little more. My personal feeling is that this flag shouldn't be used unless in local development, so guarded by an off-by-default build flag. I think cabal should also warn authors who are using this flag, and encourage them to place a guard around this option. Thoughts? - ocharles -------------- next part -------------- An HTML attachment was scrubbed... URL: From holdenlee at alum.mit.edu Sun Sep 21 19:26:46 2014 From: holdenlee at alum.mit.edu (Holden Lee) Date: Sun, 21 Sep 2014 15:26:46 -0400 Subject: [Haskell-cafe] Fwd: Pointers by using functions In-Reply-To: References: Message-ID: What is the best way to implement data structures that use pointers in Haskell? My first thought is as follows. Suppose for simplicity the labels are just integers, and each object need to point to one other one. I would have a getObject:: Int -> a f:: Int -> Int But I don't understand how Haskell maintains functions in memory, and in particular whether lookup/update is efficient. So suppose I define a f f x = case x of 1 -> 2 2 -> 3 .... (etc.) Q: if there are n entries here, how long does looking up (f m) take? Suppose later I update, with something like this: update::Int->Int->(Int->Int)->(Int->Int) update x y f z = (if z==x then y else f x) Q: how is "update x y f" maintained? Is using a f::Int->Int like using a pointer in terms of time complexity, and if not, what data structure should I use instead? Thanks, Holden -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Sep 21 19:42:03 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 21 Sep 2014 20:42:03 +0100 Subject: [Haskell-cafe] Fwd: Pointers by using functions In-Reply-To: References: Message-ID: <20140921194203.GC27848@weber> On Sun, Sep 21, 2014 at 03:26:46PM -0400, Holden Lee wrote: > What is the best way to implement data structures that use pointers in > Haskell? How about IORef or STRef? From ky3 at atamo.com Sun Sep 21 19:54:09 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 22 Sep 2014 02:54:09 +0700 Subject: [Haskell-cafe] Fwd: Pointers by using functions In-Reply-To: References: Message-ID: On Mon, Sep 22, 2014 at 2:26 AM, Holden Lee wrote: > What is the best way to implement data structures that use pointers in > Haskell? Think at a higher level. Those structures are used to solve what problem? How could that problem be solved haskell-y? But if you just want some simulation, there's the state monad. You could simulate a malloc-ish memory heap using vanilla Data.Map. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Sep 21 20:45:45 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 21 Sep 2014 22:45:45 +0200 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage In-Reply-To: References: Message-ID: Agreed. Cabal should warn. On Sep 21, 2014 8:13 PM, "Oliver Charles" wrote: > Hi all, > > I'd like to start a conversation around the ghc-prof-options option that > can be used in Cabal-ized libraries. As you may know, this option specifies > extra GHC options that are used when --enable-library-profiling is enabled. > This is very convenient for local development, but I argue that it can be > counter-productive for releases onto Hackage. > > To provide an example, I'm currently working on a little game engine that > uses JuicyPixels to load images. I have a problem in my code that needs > optimizing, but the current state of things results in profiles that are > very difficult to work with. JuicyPixels specifies -auto-all in its cabal > file, which means I have no alternative but to profile JuicyPixels code. In > this scenario, the bottleneck is actually within my FRP game loop and > nothing to do with image loading! As a result, the profiles are fairly > useless to me. > > > Roman Cheplyaka also points out that by doing this, profiles are skewed - > -auto-all is not free, so we actually pay in runtime performance every time > a library does this. > > I would like to hear from others if we should consider managing this > option a little more. My personal feeling is that this flag shouldn't be > used unless in local development, so guarded by an off-by-default build > flag. I think cabal should also warn authors who are using this flag, and > encourage them to place a guard around this option. > > Thoughts? > - ocharles > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eseidel at cs.ucsd.edu Sun Sep 21 20:52:06 2014 From: eseidel at cs.ucsd.edu (Eric Seidel) Date: Sun, 21 Sep 2014 13:52:06 -0700 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage In-Reply-To: References: Message-ID: > To provide an example, I'm currently working on a little game engine that > uses JuicyPixels to load images. I have a problem in my code that needs > optimizing, but the current state of things results in profiles that are > very difficult to work with. JuicyPixels specifies -auto-all in its cabal > file, which means I have no alternative but to profile JuicyPixels code. In > this scenario, the bottleneck is actually within my FRP game loop and > nothing to do with image loading! As a result, the profiles are fairly > useless to me. While in this case the extra profiling data may be useless, it seems to me that in general you won't know a priori. I would prefer to have as much data available as possible, and then filter it. HPC works sort of like this, it gathers coverage data for all of the modules compiled with -fhpc, but has command-line options to only report coverage for certain modules. Perhaps GHC's rts could add a similar flag to only report profiling data from certain modules or functions? From ivan.miljenovic at gmail.com Sun Sep 21 22:58:21 2014 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 22 Sep 2014 08:58:21 +1000 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage In-Reply-To: References: Message-ID: On 22 September 2014 06:52, Eric Seidel wrote: >> To provide an example, I'm currently working on a little game engine that >> uses JuicyPixels to load images. I have a problem in my code that needs >> optimizing, but the current state of things results in profiles that are >> very difficult to work with. JuicyPixels specifies -auto-all in its cabal >> file, which means I have no alternative but to profile JuicyPixels code. In >> this scenario, the bottleneck is actually within my FRP game loop and >> nothing to do with image loading! As a result, the profiles are fairly >> useless to me. > > While in this case the extra profiling data may be useless, it seems to me that in general you won't know a priori. I would prefer to have as much data available as possible, and then filter it. Agreed: I've often had to do a "cabal unpack ", edit the .cabal file to add the profiling options and re-install that package (which is admittedly easier/nicer now with sandboxes). -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From jwlato at gmail.com Sun Sep 21 23:28:41 2014 From: jwlato at gmail.com (John Lato) Date: Mon, 22 Sep 2014 07:28:41 +0800 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage In-Reply-To: References: Message-ID: On Mon, Sep 22, 2014 at 4:52 AM, Eric Seidel wrote: > > To provide an example, I'm currently working on a little game engine that > > uses JuicyPixels to load images. I have a problem in my code that needs > > optimizing, but the current state of things results in profiles that are > > very difficult to work with. JuicyPixels specifies -auto-all in its cabal > > file, which means I have no alternative but to profile JuicyPixels code. > In > > this scenario, the bottleneck is actually within my FRP game loop and > > nothing to do with image loading! As a result, the profiles are fairly > > useless to me. > > While in this case the extra profiling data may be useless, it seems to me > that in general you won't know a priori. I would prefer to have as much > data available as possible, and then filter it. > > HPC works sort of like this, it gathers coverage data for all of the > modules compiled with -fhpc, but has command-line options to only report > coverage for certain modules. Perhaps GHC's rts could add a similar flag to > only report profiling data from certain modules or functions? I am sympathetic to this concern, but the main problem here is that -fprof-auto isn't free. It can interfere quite heavily with optimization passes, meaning that it ends up attributing much higher costs to certain functions than they would have in a normal compilation path, actively misleading users. I for one would have no confidence that profiles were pointing to the correct place if everything were built with -fprof-auto from the start. It's much better to start with just a few high-level cost-centers and drill down from there. This can be a tedious process, but it's much more reliable. As an alternative, compiling libraries with -fprof-auto-exported is fairly reasonable IMHO. John L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.marek.spartz at gmail.com Mon Sep 22 01:31:46 2014 From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz) Date: Sun, 21 Sep 2014 20:31:46 -0500 Subject: [Haskell-cafe] DSL implementation In-Reply-To: <1E01D921-7A6F-4F84-A4FE-C2F98C8B41A7@mcmaster.ca> References: <1E01D921-7A6F-4F84-A4FE-C2F98C8B41A7@mcmaster.ca> Message-ID: <8d1e8304-69a0-4be7-8c26-f42b2cc2fcc9@highlander> You may be interested in using C-DSL to generate your DSL?s output. It should keep your output readable. https://bitbucket.org/jozefg/c-dsl ? Kyle Marek-Spartz On Sep 18, 2014, 8:18:10 AM, Dr Christopher Anand wrote: Hi Felipe, We performed an (unplanned) experiment relevant to your case. We developed a DSL in Haskell and a library of math functions while IBM was doing the same thing in C. http://doi.ieeecomputersociety.org/10.1109/TC.2008.223 The C library was 4X slower, and less accurate. More recently we have wrapped-up a prototype for type-safe physical models and there is a preprint and three example implementations which might be of help in constructing your own. http://www.cas.mcmaster.ca/~anand/papers/preprints.html Good luck explaining why Haskell is so good for DSLs. You might find http://cacm.acm.org/magazines/2011/7/109910-dsl-for-the-uninitiated/fulltext helpful. Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at operationaldynamics.com Mon Sep 22 01:49:37 2014 From: andrew at operationaldynamics.com (Andrew Cowie) Date: Mon, 22 Sep 2014 11:49:37 +1000 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage In-Reply-To: References: Message-ID: <1411350577.19991.3.camel@operationaldynamics.com> On Mon, 2014-09-22 at 07:28 +0800, John Lato wrote: > compiling libraries with -fprof-auto-exported That's what I was going to pipe up with. In my usage, having dependencies at -fprof-auto-exported seems to work quite well. On the rare occasion that I need *more*, then off to `cabal unpack` we go, but that's a better trade off I think. AfC Sydney -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ajnsit at gmail.com Mon Sep 22 05:37:23 2014 From: ajnsit at gmail.com (Anupam Jain) Date: Mon, 22 Sep 2014 02:37:23 -0300 Subject: [Haskell-cafe] Haskell job opportunity in Santiago, Chile Message-ID: Hi all, We are looking to hire an experienced Haskell developer for our startup in Santiago, Chile. This will be a 6-8 week project involving web development using Yesod and you will be building a key component of our product. Part time is OK. We would prefer someone who can work out of our office, however, working remote is also a possibility. If remote, being in India would be a plus. Good english communication ability is essential. Please email me directly if interested. Thanks, Anupam Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Mon Sep 22 06:44:25 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 22 Sep 2014 08:44:25 +0200 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage In-Reply-To: References: Message-ID: <20140922064425.GA2488@machine> On Mon, Sep 22, 2014 at 07:28:41AM +0800, John Lato wrote: > As an alternative, compiling libraries with -fprof-auto-exported is fairly reasonable IMHO. It would be nice to be able to overwrite e.g. the ghc-prof-options, then you could just build everything in a cabal sandbox with the desired options. Greetings, Daniel From michael at snoyman.com Mon Sep 22 06:58:47 2014 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 22 Sep 2014 09:58:47 +0300 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage In-Reply-To: References: Message-ID: On Sun, Sep 21, 2014 at 11:45 PM, Johan Tibell wrote: > Agreed. Cabal should warn. > +1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon Sep 22 07:25:14 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 22 Sep 2014 10:25:14 +0300 Subject: [Haskell-cafe] ghc-prof-options and libraries on Hackage In-Reply-To: References: Message-ID: <541FCEDA.5030402@ro-che.info> On 22/09/14 01:58, Ivan Lazar Miljenovic wrote: > On 22 September 2014 06:52, Eric Seidel wrote: >>> To provide an example, I'm currently working on a little game engine that >>> uses JuicyPixels to load images. I have a problem in my code that needs >>> optimizing, but the current state of things results in profiles that are >>> very difficult to work with. JuicyPixels specifies -auto-all in its cabal >>> file, which means I have no alternative but to profile JuicyPixels code. In >>> this scenario, the bottleneck is actually within my FRP game loop and >>> nothing to do with image loading! As a result, the profiles are fairly >>> useless to me. >> >> While in this case the extra profiling data may be useless, it seems to me that in general you won't know a priori. I would prefer to have as much data available as possible, and then filter it. > > Agreed: I've often had to do a "cabal unpack ", edit the .cabal > file to add the profiling options and re-install that package (which > is admittedly easier/nicer now with sandboxes). Why would you need to edit the cabal file? Are you aware of --ghc-options? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From k.bleijenberg at lijbrandt.nl Mon Sep 22 08:16:36 2014 From: k.bleijenberg at lijbrandt.nl (Kees Bleijenberg) Date: Mon, 22 Sep 2014 10:16:36 +0200 Subject: [Haskell-cafe] how to use hs_init_ghc and pass runtime params to a dll Message-ID: <000001cfd63d$8742e110$95c8a330$@bleijenberg@lijbrandt.nl> Can someone provide a (pointer to a) working basic example of C code that uses a Windows dll created by ghc that calls hs_init_ghc? Can someone confirm that hs_init_ghc uses stdcall in a windows dll. Is ghc -no-hs-main -shared -threaded -O2 -o TBGlas.dll TBGlasDll.hs a correct way to create the dll? Do I have to use the ghc parameter -dynamic? if I use this parameter, the ghc tells me to install the 'dyn' libraries for package base. Sounds aweful. I'am using ghc version 7.8.3. and the 32 bits Haskell Platform on 64 bits Windows 7. Background: I create a dll with ghc. The program that uses the dll starts with a lookup for all functions I want to use from the dll. The result is a bunch of function pointers. I use a function pointer to call the real function. Then I call the defaultRtsConfig function from the dll. I get a pointer to a struct with a byte for the enumarable RTSOptEnabled followed by a pointer to a string. In the returned struct this pointer is nil. Then I set the pointer in the struct to the string "-N -s". After that I call hs_init_ghc(nil,nil,defaultRtsConcfigStruct). This works fine. I get a overview of the sparks created, the elapsed times, there is a speedup from the parallel code etc. But sometimes (1 out of 100) the program crashes. Any ideas what could be wrong? Kees -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Mon Sep 22 08:59:44 2014 From: alois.cochard at gmail.com (Alois Cochard) Date: Mon, 22 Sep 2014 09:59:44 +0100 Subject: [Haskell-cafe] [ANN] codex 0.2.0.0 Message-ID: Hi Cafe, I released a new version of my tool `codex`[1] (a ctags file generator for cabal project dependencies). This new version include: - By default, the current project is now included in the generated `codex.tags` file - Resolve dependencies in the "benchmarks" of your cabal project - Fix tags file header to respect specification (to make them work in Sublime) - Cache eviction mechanism (no need of using `--force` in default use cases) - Add default configuration for Sublime Thanks to everyone for bug fixes and feature requests! Cheers [1] https://github.com/aloiscochard/codex -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Mon Sep 22 23:30:33 2014 From: michael at orlitzky.com (Michael Orlitzky) Date: Mon, 22 Sep 2014 19:30:33 -0400 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <201409180849.12784.jan.stolarek@p.lodz.pl> References: <201409180849.12784.jan.stolarek@p.lodz.pl> Message-ID: <5420B119.1090903@orlitzky.com> On 09/18/2014 02:49 AM, Jan Stolarek wrote: > Hi *, > > I have a simple question about terminology regarding bound and free > variables. Assume I have: > > let f x = let g y = ... in g c in ... > > Now: - `c` is free in `g` and `f` - `y` is bound in `g` - `x` is free > in `g`. - `x` is bound in `f` > > What about `y` in `f`? Is it also bound in `f`? If so then it > certainly is bound in a different way that `x`. Is there a > terminology that allows to distinguish these different forms of bound > variables? > It's hard to tell from your example, but if you want, you can translate the let binding directly to lambda calculus and then go from there where the rules are simple. In Haskell, let = in translates to, (\ -> ) The "let f x = ..." is just defining a function (\x -> ...), but it hides the body of the function at the end of all the nested lets. Once you have the entire thing written out in curried form you can find out whether or not y is bound by assigning it as homework. From kazu at iij.ad.jp Tue Sep 23 05:27:34 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 23 Sep 2014 14:27:34 +0900 (JST) Subject: [Haskell-cafe] usage of traversal Message-ID: <20140923.142734.1065963489639742112.kazu@iij.ad.jp> Hi, Recently, I need to write the following code: getModTime :: Maybe FilePath -> IO (Maybe UTCTime) getModTime mfile = case mfile of Nothing -> return Nothing Just file -> Just <$> getModificationTime file I feel that this is redundant. So, I used 'traverse' instead: getModTime :: Maybe FilePath -> IO (Maybe UTCTime) getModTime mfile = getModificationTime `traverse` mfile First, I would like to know whether or not this is a good coding style. Second, if this is acceptable, why don't we define an operator? For instance, (<:>) :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) (<:>) = traverse getModTime :: Maybe FilePath -> IO (Maybe UTCTime) getModTime mfile = getModificationTime <:> mfile Is there such an operator already? Regards, --Kazu From ok at cs.otago.ac.nz Tue Sep 23 07:06:26 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 23 Sep 2014 19:06:26 +1200 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: Message-ID: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> On 20/09/2014, at 5:26 AM, Carter Schonwald wrote: > Indeed, > > Also Floating point numbers are NOT real numbers, they are approximate points on the real line that we pretend are exact reals but really are a very different geometry all together! :) Floating point numbers are *PRECISE* numbers with approximate *OPERATIONS*. This is the way they are defined in the IEEE standard and its successors; this is the way they are defined in LIA-1 and its successors. If you do not understand that it is the OPERATIONS that are approximate, not the numbers, you have not yet begun to understand floating point arithmetic. > Floats and Doubles are not exact numbers, dont use them when you expect things to behave "exact". NB that even if you have *exact* numbers, the exact same precision issues will still apply to pretty much any computation thats interesting (ignoring what the definition of interesting is). Try defining things like \ x -> SquareRoot x or \x-> e^x on the rational numbers! Questions of precision still creep in! You're not talking about precision here but about approximation. And you can simply work with finite representations of algebraic numbers. I have a Smalltalk class that implements QuadraticSurds so that I can represent (1 + sqrt 5)/2 *exactly*. You can even compare QuadraticSurds with the same surd exactly. (This all works so much better in Haskell, where you can make the "5" part a type-level parameter.) Since e is not a rational number, it's not terribly interesting that e^x (usually) isn't when x is rational. If we want to compute with a richer range of numbers than the rationals, we can do that. We could, for example, compute with continued fractions. Haskell makes that a small matter of programming, and I expect someone has already done it. > So I guess phrased another way, a lot of the confusion / challenge in writing floating point programs lies in understanding the representation, its limits, and the ways in which it will implicitly manage that precision tracking book keeping for you. Exactly so. There are even people who think the representation is approximate instead of the operations! For things like doubled-double, it really matters that the numbers are precise and combine in predictable ways. Interestingly, while floating point addition and multiplication are not associative, they are not wildly or erratically non-associative, and it is possible to reason about the results of operations. From michael at snoyman.com Tue Sep 23 07:14:23 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 23 Sep 2014 10:14:23 +0300 Subject: [Haskell-cafe] usage of traversal In-Reply-To: <20140923.142734.1065963489639742112.kazu@iij.ad.jp> References: <20140923.142734.1065963489639742112.kazu@iij.ad.jp> Message-ID: Forgot to CC the list: I'd be -1 on an operator, I think having a named function for this is a good thing for readability of code. As far as good style: I personally think it is. In classy-prelude, I actually export the Foldable-based `mapM` by default, and will regularly use that (or forM) for this kind of code. On Tue, Sep 23, 2014 at 8:27 AM, Kazu Yamamoto wrote: > Hi, > > Recently, I need to write the following code: > > getModTime :: Maybe FilePath -> IO (Maybe UTCTime) > getModTime mfile = case mfile of > Nothing -> return Nothing > Just file -> Just <$> getModificationTime file > > I feel that this is redundant. So, I used 'traverse' instead: > > getModTime :: Maybe FilePath -> IO (Maybe UTCTime) > getModTime mfile = getModificationTime `traverse` mfile > > First, I would like to know whether or not this is a good coding style. > > Second, if this is acceptable, why don't we define an operator? For > instance, > > (<:>) :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) > (<:>) = traverse > > getModTime :: Maybe FilePath -> IO (Maybe UTCTime) > getModTime mfile = getModificationTime <:> mfile > > Is there such an operator already? > > Regards, > > --Kazu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Sep 23 07:23:06 2014 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 23 Sep 2014 10:23:06 +0300 Subject: [Haskell-cafe] usage of traversal In-Reply-To: <20140923.161236.403022575179684661.kazu@iij.ad.jp> References: <20140923.142734.1065963489639742112.kazu@iij.ad.jp> <20140923.161236.403022575179684661.kazu@iij.ad.jp> Message-ID: On Tue, Sep 23, 2014 at 10:12 AM, Kazu Yamamoto wrote: > Hi Michael, > > Probably, you forgot to Cc: to haskell-cafe. > > > I'd be -1 on an operator, I think having a named function for this is a > > good thing for readability of code. > > > > As far as good style: I personally think it is. In classy-prelude, I > > actually export the Foldable-based `mapM` by default, and will regularly > > use that (or forM) for this kind of code. > > With AMP, 'fmap' and 'liftM' are identical and we use <$> instead > recently. Likewise, 'traverse' and 'mapM' are identical. If we > introduce an operator, say <:>, we can forget 'traverse' and 'mapM' > when writing code and can write: > > getModificationTime <:> mfile > > This looks like function application like Applicative style. > > Just a thought. > > --Kazu > It's definitely true that with AMP the situation will be much improved, and it makes more sense to use an operator here since it will cover what is today two distinct functions. However, I think I'm overall still in favor of sticking to the named function, since both `mapM` and `traverse` are well known. This may just be a chicken-and-egg argument, however, and once <:> takes hold it's just as readable as `mapM`. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From iago.abal at gmail.com Tue Sep 23 08:14:39 2014 From: iago.abal at gmail.com (Iago Abal) Date: Tue, 23 Sep 2014 10:14:39 +0200 Subject: [Haskell-cafe] ANNOUNCE: bv-0.3.0 Message-ID: I am pleased to announce a new release of the bv package, a library for bit-vector arithmetic. http://hackage.haskell.org/package/bv This is essentially a maintenance release to support newest versions of GHC and base. Yet, I took the opportunity to do some code and documentation clean up. A changelog is available at https://bitbucket.org/iago/bv-haskell/src/v0.3.0/CHANGES.md. Iago -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Sep 23 08:16:24 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 23 Sep 2014 10:16:24 +0200 Subject: [Haskell-cafe] Copyright field vs. License file Message-ID: <1411460184.2660.3.camel@joachim-breitner.de> Dear package maintainers, a lot of our LICENSE file start like tihs: ==> haskell-lens-4.1.2.1/LICENSE <== Copyright 2012-2014 Edward Kmett All rights reserved. ... ==> haskell-cryptocipher-0.6.2/LICENSE <== Copyright (c) 2010-2013 Vincent Hanquez All rights reserved. ... ==> haskell-http-client-0.3.2.1/LICENSE <== The MIT License (MIT) Copyright (c) 2013 Michael Snoyman Permission is hereby granted, free of charge, to any person obtaining a copy of ... i.e. they mix the copyright information with the license. I know, of course, why that is: "cabal init" prepares it that way, and those not using cabal init probably copy it from an existing file. A notable exception are the GPL-licensed packages; these usually don?t have copyright information in the license. The problem is that this information is not structured, and hard to parse, i.e. to create license reports or (my use case) create distribution packages with much less manual labor. Cabal describes the fields as license-file: filename or license-files: filename list The name of a file(s) containing the precise copyright license for this package. The license file(s) will be installed with the package. If you have multiple license files then use the license-files field instead of (or in addition to) the license-file field. copyright: freeform The content of a copyright notice, typically the name of the holder of the copyright on the package and the year(s) from which copyright is claimed. For example: Copyright: (c) 2006-2007 Joe Bloggs which suggest to put the copyright data into the cabal file only and leave the license file alone. It would also have the advantage that after cabal init, you?d only have to modify one file, and the copyright information is easily visible on hackage. I know that there it is highly unlikely that a significant number of maintainers will change their existing files. But I?d still like to get feedback: Do you agree that this make sense? Should I try to make "cabal init" set it up this way? And would you accept pull requests for this? Thanks, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From roma at ro-che.info Tue Sep 23 08:34:24 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 23 Sep 2014 11:34:24 +0300 Subject: [Haskell-cafe] Copyright field vs. License file In-Reply-To: <1411460184.2660.3.camel@joachim-breitner.de> References: <1411460184.2660.3.camel@joachim-breitner.de> Message-ID: <54213090.2010809@ro-che.info> It's not just cabal init; the copyright information traditionally is part of the BSD and MIT license templates. On 23/09/14 11:16, Joachim Breitner wrote: > Dear package maintainers, > > a lot of our LICENSE file start like tihs: > > ==> haskell-lens-4.1.2.1/LICENSE <== > Copyright 2012-2014 Edward Kmett > > All rights reserved. > ... > > ==> haskell-cryptocipher-0.6.2/LICENSE <== > Copyright (c) 2010-2013 Vincent Hanquez > > All rights reserved. > ... > > ==> haskell-http-client-0.3.2.1/LICENSE <== > The MIT License (MIT) > > Copyright (c) 2013 Michael Snoyman > > Permission is hereby granted, free of charge, to any person > obtaining a copy of > ... > > i.e. they mix the copyright information with the license. > > I know, of course, why that is: "cabal init" prepares it that way, and > those not using cabal init probably copy it from an existing file. > > A notable exception are the GPL-licensed packages; these usually don?t > have copyright information in the license. > > The problem is that this information is not structured, and hard to > parse, i.e. to create license reports or (my use case) create > distribution packages with much less manual labor. > > Cabal describes the fields as > > license-file: filename or license-files: filename list > > The name of a file(s) containing the precise copyright > license for this package. The license file(s) will be installed > with the package. > > If you have multiple license files then use the > license-files field instead of (or in addition to) the > license-file field. > > copyright: freeform > > The content of a copyright notice, typically the name of the > holder of the copyright on the package and the year(s) from > which copyright is claimed. > For example: Copyright: (c) 2006-2007 Joe Bloggs > > > which suggest to put the copyright data into the cabal file only and > leave the license file alone. > > It would also have the advantage that after cabal init, you?d only have > to modify one file, and the copyright information is easily visible on > hackage. > > > I know that there it is highly unlikely that a significant number of > maintainers will change their existing files. But I?d still like to get > feedback: > > Do you agree that this make sense? Should I try to make "cabal init" set > it up this way? And would you accept pull requests for this? > > > Thanks, > Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mail at joachim-breitner.de Tue Sep 23 08:50:20 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 23 Sep 2014 10:50:20 +0200 Subject: [Haskell-cafe] Copyright field vs. License file In-Reply-To: <54213090.2010809@ro-che.info> References: <1411460184.2660.3.camel@joachim-breitner.de> <54213090.2010809@ro-che.info> Message-ID: <1411462220.2660.7.camel@joachim-breitner.de> Hi, Am Dienstag, den 23.09.2014, 11:34 +0300 schrieb Roman Cheplyaka: > It's not just cabal init; the copyright information traditionally is > part of the BSD and MIT license templates. hmm, fair point. I guess that?s because in most other applications, there is no canonical and well-defined place to put the copyright information, and also because historically, both were simply pasted above the program code. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ky3 at atamo.com Tue Sep 23 10:34:22 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 23 Sep 2014 17:34:22 +0700 Subject: [Haskell-cafe] usage of traversal In-Reply-To: References: <20140923.142734.1065963489639742112.kazu@iij.ad.jp> <20140923.161236.403022575179684661.kazu@iij.ad.jp> Message-ID: > With AMP, 'fmap' and 'liftM' are identical and we use <$> instead > recently. Likewise, 'traverse' and 'mapM' are identical. Both Kazu and Michael are perfectly aware of the following but it's important to set the record straight: The function liftM is a specialization of fmap. Both functions operate the same (which is what is meant by 'identical') on mutually admissible values, but liftM restricts the domain of admissibility only to functors that are also monadic. Similarly, mapM is a specialization of traverse. Here, two functors are involved where one is weakened and the other strengthened. If we introduce an operator, say <:>, we can forget 'traverse' and 'mapM' Have you considered the traditional way of using your own operators, i.e. by spinning one's own Missing Haskell library, like John Goerzen did? The direction you're suggesting requires familiarity with the libraries-haskell process. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From barak at cs.nuim.ie Tue Sep 23 13:01:29 2014 From: barak at cs.nuim.ie (Barak A. Pearlmutter) Date: Tue, 23 Sep 2014 14:01:29 +0100 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: References: Message-ID: <87iokemqxi.fsf@cs.nuim.ie> On Mon, 22 Sep 2014 19:30:33 -0400, Michael Orlitzky wrote: > It's hard to tell from your example, but if you want, you can > translate the let binding directly to lambda calculus and then go from > there where the rules are simple. > > In Haskell, > > let = in > > translates to, > > (\ -> ) Although this list might not be for homework problems, there is an element of terminological confusion and a quest for nomenclature in the question that don't seem entirely unreasonable. Even if we're not going to answer the question per se, we shouldn't give hints that are misleading, or true in Scheme and lambda calculus but false in Haskell. $ ghci Prelude> let b = 3:b in take 3 b [3,3,3] Prelude> (\b -> take 3 b) (3:b) :3:21: Not in scope: `b' From kyle.marek.spartz at gmail.com Tue Sep 23 13:10:12 2014 From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz) Date: Tue, 23 Sep 2014 08:10:12 -0500 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <87iokemqxi.fsf@cs.nuim.ie> References: <87iokemqxi.fsf@cs.nuim.ie> Message-ID: <1bb96700-4c53-4464-b131-a1976be9100d@highlander> Additionally, since let is ?let rec?, it can?t be translated into a lambda expression using that method in all cases, e.g. let f x = g x g x = 1 in f 2 ==> (\f -> (\g -> f 2)) (\x -> g x) (\x -> 1) In the lambda expression, the second g is free, whereas the corresponding g in Haskell is bound. ? Kyle Marek-Spartz On Sep 23, 2014, 8:01:29 AM, Barak A. Pearlmutter wrote: On Mon, 22 Sep 2014 19:30:33 -0400, Michael Orlitzky wrote: > It's hard to tell from your example, but if you want, you can > translate the let binding directly to lambda calculus and then go from > there where the rules are simple. > > In Haskell, > > let = in > > translates to, > > ( -> ) Although this list might not be for homework problems, there is an element of terminological confusion and a quest for nomenclature in the question that don't seem entirely unreasonable. Even if we're not going to answer the question per se, we shouldn't give hints that are misleading, or true in Scheme and lambda calculus but false in Haskell. $ ghci Prelude> let b = 3:b in take 3 b [3,3,3] Prelude> ( -> take 3 b) (3:b) :3:21: Not in scope: `b' _______________________________________________ Haskell-Cafe mailing list mailto:Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.gunton at gmail.com Tue Sep 23 15:14:09 2014 From: ben.gunton at gmail.com (Ben Gunton) Date: Tue, 23 Sep 2014 09:14:09 -0600 Subject: [Haskell-cafe] Multicast receiver thread fails to receive last few messages Message-ID: I am trying to send multicast messages from one thread, and receive them on another. The sending thread reads lines from a file and sends them. However, the receiving thread does not receive all the messages - it seems to miss the last 10 message or so. If I run other programs to listen for the multicast message, they receive them fine. So I think the issue is something to do with receiving, not sending. I keep the program alive with a threadDelay, so it shouldn't be halting prematurely. If I add a small delay after each send, it works fine. And if I make the input file smaller, it works fine. On the provided data file, on my system (64-bit Ubuntu, GHC 7.8.2), the receiver fails to receive lines 125-140. Compiled with no optimizations. Thanks for any help! The relevant code snippets are below, and the sample data file and full program are attached. -- Loop to receive all the packets let receiveMulticast = do (msg, _) <- recvFrom recvSock 32628 putStrLn . BS.unpack $ BS.take 100 msg receiveMulticast _ <- forkIO receiveMulticast -- Send every line from a file as multicast message inputFile <- openFile "data" ReadMode fileLines <- BS.lines <$> BS.hGetContents inputFile let sendMulticast msg = do sendTo sendSock msg addr -- Receiver FAILS to receive last few messages unless this -- thread delay exists... why?! -- threadDelay (1) mapM_ sendMulticast fileLines hClose inputFile threadDelay (1000*1000*1000) -- Delay for 1000 seconds -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: data Type: application/octet-stream Size: 72591 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.hs Type: text/x-haskell Size: 2237 bytes Desc: not available URL: From roma at ro-che.info Tue Sep 23 15:31:13 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 23 Sep 2014 18:31:13 +0300 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <87iokemqxi.fsf@cs.nuim.ie> References: <87iokemqxi.fsf@cs.nuim.ie> Message-ID: <54219241.8040807@ro-che.info> On 23/09/14 16:01, Barak A. Pearlmutter wrote: > On Mon, 22 Sep 2014 19:30:33 -0400, Michael Orlitzky wrote: > >> It's hard to tell from your example, but if you want, you can >> translate the let binding directly to lambda calculus and then go from >> there where the rules are simple. >> >> In Haskell, >> >> let = in >> >> translates to, >> >> (\ -> ) > > Although this list might not be for homework problems, there is an > element of terminological confusion and a quest for nomenclature in the > question that don't seem entirely unreasonable. Even if we're not going > to answer the question per se, we shouldn't give hints that are > misleading, or true in Scheme and lambda calculus but false in Haskell. I am not sure which question in this thread you regard as a homework problem and suggest not answering. Roman From ky3 at atamo.com Tue Sep 23 15:40:18 2014 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 23 Sep 2014 22:40:18 +0700 Subject: [Haskell-cafe] usage of traversal In-Reply-To: References: <20140923.142734.1065963489639742112.kazu@iij.ad.jp> <20140923.161236.403022575179684661.kazu@iij.ad.jp> Message-ID: On Tue, Sep 23, 2014 at 5:34 PM, Kim-Ee Yeoh wrote: > Similarly, mapM is a specialization of traverse. Here, two functors are > involved where one is weakened and the other strengthened. Wait, that's not right. Both functors are weakened going from mapM to traverse. They are sharpened going the other way round. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.marek.spartz at gmail.com Tue Sep 23 15:46:16 2014 From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz) Date: Tue, 23 Sep 2014 10:46:16 -0500 Subject: [Haskell-cafe] Multicast receiver thread fails to receive last few messages In-Reply-To: References: Message-ID: I would try forking your sending thread, too, rather than using the main thread for sending. Alternatively, use the main thread for receiving and fork your sending thread. ? Kyle Marek-Spartz On Sep 23, 2014, 10:14:09 AM, Ben Gunton wrote: I am trying to send multicast messages from one thread, and receive them on another. The sending thread reads lines from a file and sends them. However, the receiving thread does not receive all the messages - it seems to miss the last 10 message or so. If I run other programs to listen for the multicast message, they receive them fine. So I think the issue is something to do with receiving, not sending. I keep the program alive with a threadDelay, so it shouldn't be halting prematurely. If I add a small delay after each send, it works fine. And if I make the input file smaller, it works fine. On the provided data file, on my system (64-bit Ubuntu, GHC 7.8.2), the receiver fails to receive lines 125-140. Compiled with no optimizations. Thanks for any help! The relevant code snippets are below, and the sample data file and full program are attached. -- Loop to receive all the packets let receiveMulticast = do (msg, _) <- recvFrom recvSock 32628 putStrLn . BS.unpack $ BS.take 100 msg receiveMulticast _ <- forkIO receiveMulticast -- Send every line from a file as multicast message inputFile <- openFile "data" ReadMode fileLines <- BS.lines <$> BS.hGetContents inputFile let sendMulticast msg = do sendTo sendSock msg addr -- Receiver FAILS to receive last few messages unless this -- thread delay exists... why?! -- threadDelay (1) mapM_ sendMulticast fileLines hClose inputFile threadDelay (1000*1000*1000) -- Delay for 1000 seconds - data, 71 KB - Main.hs, 2.2 KB _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Tue Sep 23 15:55:54 2014 From: michael at orlitzky.com (Michael Orlitzky) Date: Tue, 23 Sep 2014 11:55:54 -0400 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <54219241.8040807@ro-che.info> References: <87iokemqxi.fsf@cs.nuim.ie> <54219241.8040807@ro-che.info> Message-ID: <5421980A.4000909@orlitzky.com> On 09/23/2014 11:31 AM, Roman Cheplyaka wrote: > > I am not sure which question in this thread you regard as a homework > problem and suggest not answering. > I made a joke. It didn't work. From ben.gunton at gmail.com Tue Sep 23 15:58:24 2014 From: ben.gunton at gmail.com (Ben Gunton) Date: Tue, 23 Sep 2014 09:58:24 -0600 Subject: [Haskell-cafe] Multicast receiver thread fails to receive last few messages In-Reply-To: References: Message-ID: Thanks Kyle. Tried forking both (http://lpaste.net/111477), and also receiving from the main thread while forking the sending, and the results were the same... still not receiving the last bunch of lines. On Tue, Sep 23, 2014 at 9:46 AM, Kyle Marek-Spartz < kyle.marek.spartz at gmail.com> wrote: > I would try forking your sending thread, too, rather than using the main > thread for sending. Alternatively, use the main thread for receiving and > fork your sending thread. > > ? > Kyle Marek-Spartz > > > > > > On Sep 23, 2014, 10:14:09 AM, Ben Gunton wrote: > ------------------------------ > I am trying to send multicast messages from one thread, and receive them > on another. The sending thread reads lines from a file and sends them. > However, the receiving thread does not receive all the messages - it seems > to miss the last 10 message or so. If I run other programs to listen for > the multicast message, they receive them fine. So I think the issue is > something to do with receiving, not sending. I keep the program alive with > a threadDelay, so it shouldn't be halting prematurely. If I add a small > delay after each send, it works fine. And if I make the input file smaller, > it works fine. > > On the provided data file, on my system (64-bit Ubuntu, GHC 7.8.2), the > receiver fails to receive lines 125-140. Compiled with no optimizations. > > Thanks for any help! > > The relevant code snippets are below, and the sample data file and full > program are attached. > > -- Loop to receive all the packets > let receiveMulticast = do > (msg, _) <- recvFrom recvSock 32628 > putStrLn . BS.unpack $ BS.take 100 msg > receiveMulticast > _ <- forkIO receiveMulticast > > -- Send every line from a file as multicast message > inputFile <- openFile "data" ReadMode > fileLines <- BS.lines <$> BS.hGetContents inputFile > let sendMulticast msg = do > sendTo sendSock msg addr > -- Receiver FAILS to receive last few messages unless this > -- thread delay exists... why?! > -- threadDelay (1) > mapM_ sendMulticast fileLines > hClose inputFile > > threadDelay (1000*1000*1000) -- Delay for 1000 seconds > ------------------------------ > - data, 71 KB > - Main.hs, 2.2 KB > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Sep 23 15:59:57 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 23 Sep 2014 16:59:57 +0100 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <5421980A.4000909@orlitzky.com> References: <87iokemqxi.fsf@cs.nuim.ie> <54219241.8040807@ro-che.info> <5421980A.4000909@orlitzky.com> Message-ID: <20140923155957.GJ27848@weber> On Tue, Sep 23, 2014 at 11:55:54AM -0400, Michael Orlitzky wrote: > On 09/23/2014 11:31 AM, Roman Cheplyaka wrote: > > I am not sure which question in this thread you regard as a homework > > problem and suggest not answering. > > I made a joke. It didn't work. It did for me at least :) From allbery.b at gmail.com Tue Sep 23 16:09:44 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 23 Sep 2014 12:09:44 -0400 Subject: [Haskell-cafe] Bound and free variables In-Reply-To: <20140923155957.GJ27848@weber> References: <87iokemqxi.fsf@cs.nuim.ie> <54219241.8040807@ro-che.info> <5421980A.4000909@orlitzky.com> <20140923155957.GJ27848@weber> Message-ID: On Tue, Sep 23, 2014 at 11:59 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Tue, Sep 23, 2014 at 11:55:54AM -0400, Michael Orlitzky wrote: > > On 09/23/2014 11:31 AM, Roman Cheplyaka wrote: > > > I am not sure which question in this thread you regard as a homework > > > problem and suggest not answering. > > > > I made a joke. It didn't work. > > It did for me at least :) It just confused me, fwiw. (I think Scalzi has a relevant comment.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Sep 23 16:26:32 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 23 Sep 2014 12:26:32 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> Message-ID: well said! and thanks for taking the time to clarify some of the imprecision in how i was trying to answer the earlier points On Tue, Sep 23, 2014 at 3:06 AM, Richard A. O'Keefe wrote: > > On 20/09/2014, at 5:26 AM, Carter Schonwald wrote: > > > Indeed, > > > > Also Floating point numbers are NOT real numbers, they are approximate > points on the real line that we pretend are exact reals but really are a > very different geometry all together! :) > > Floating point numbers are *PRECISE* numbers with > approximate *OPERATIONS*. This is the way they are > defined in the IEEE standard and its successors; > this is the way they are defined in LIA-1 and its > successors. If you do not understand that it is > the OPERATIONS that are approximate, not the numbers, > you have not yet begun to understand floating point > arithmetic. > > > Floats and Doubles are not exact numbers, dont use them when you expect > things to behave "exact". NB that even if you have *exact* numbers, the > exact same precision issues will still apply to pretty much any computation > thats interesting (ignoring what the definition of interesting is). Try > defining things like \ x -> SquareRoot x or \x-> e^x on the rational > numbers! Questions of precision still creep in! > > You're not talking about precision here but about > approximation. And you can simply work with finite representations > of algebraic numbers. I have a Smalltalk class that implements > QuadraticSurds so that I can represent (1 + sqrt 5)/2 *exactly*. > You can even compare QuadraticSurds with the same surd exactly. > (This all works so much better in Haskell, where you can make > the "5" part a type-level parameter.) > > Since e is not a rational number, it's not terribly interesting > that e^x (usually) isn't when x is rational. > > If we want to compute with a richer range of numbers than > the rationals, we can do that. We could, for example, compute > with continued fractions. Haskell makes that a small matter > of programming, and I expect someone has already done it. > > > So I guess phrased another way, a lot of the confusion / challenge in > writing floating point programs lies in understanding the representation, > its limits, and the ways in which it will implicitly manage that precision > tracking book keeping for you. > > Exactly so. There are even people who think the representation > is approximate instead of the operations! For things like > doubled-double, it really matters that the numbers are precise > and combine in predictable ways. > > Interestingly, while floating point addition and multiplication > are not associative, they are not wildly or erratically > non-associative, and it is possible to reason about the results > of operations. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Sep 23 16:30:25 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 23 Sep 2014 12:30:25 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> Message-ID: well said and thanks for taking the time to clarify some of the imprecision in what I was saying! On Tue, Sep 23, 2014 at 3:06 AM, Richard A. O'Keefe wrote: > > On 20/09/2014, at 5:26 AM, Carter Schonwald wrote: > > > Indeed, > > > > Also Floating point numbers are NOT real numbers, they are approximate > points on the real line that we pretend are exact reals but really are a > very different geometry all together! :) > > Floating point numbers are *PRECISE* numbers with > approximate *OPERATIONS*. This is the way they are > defined in the IEEE standard and its successors; > this is the way they are defined in LIA-1 and its > successors. If you do not understand that it is > the OPERATIONS that are approximate, not the numbers, > you have not yet begun to understand floating point > arithmetic. > > > Floats and Doubles are not exact numbers, dont use them when you expect > things to behave "exact". NB that even if you have *exact* numbers, the > exact same precision issues will still apply to pretty much any computation > thats interesting (ignoring what the definition of interesting is). Try > defining things like \ x -> SquareRoot x or \x-> e^x on the rational > numbers! Questions of precision still creep in! > > You're not talking about precision here but about > approximation. And you can simply work with finite representations > of algebraic numbers. I have a Smalltalk class that implements > QuadraticSurds so that I can represent (1 + sqrt 5)/2 *exactly*. > You can even compare QuadraticSurds with the same surd exactly. > (This all works so much better in Haskell, where you can make > the "5" part a type-level parameter.) > > Since e is not a rational number, it's not terribly interesting > that e^x (usually) isn't when x is rational. > > If we want to compute with a richer range of numbers than > the rationals, we can do that. We could, for example, compute > with continued fractions. Haskell makes that a small matter > of programming, and I expect someone has already done it. > > > So I guess phrased another way, a lot of the confusion / challenge in > writing floating point programs lies in understanding the representation, > its limits, and the ways in which it will implicitly manage that precision > tracking book keeping for you. > > Exactly so. There are even people who think the representation > is approximate instead of the operations! For things like > doubled-double, it really matters that the numbers are precise > and combine in predictable ways. > > Interestingly, while floating point addition and multiplication > are not associative, they are not wildly or erratically > non-associative, and it is possible to reason about the results > of operations. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno.fuenfstueck at gmail.com Tue Sep 23 16:44:19 2014 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Tue, 23 Sep 2014 18:44:19 +0200 Subject: [Haskell-cafe] Multicast receiver thread fails to receive last few messages In-Reply-To: References: Message-ID: I think the problem here is that the receiver thread never gets a chance to run. Because the send loop doesn't perform any allocations and the GHC scheduler only switches threads when allocations occur, the receiver thread never runs and thus the packets just get queued up (and after a certain amount of data, the queue is full so packets are dropped). The fix is to explicitly `yield` to the other thread, so it gets a chance to run too: import Control.Concurrent (yield) ... let sendMulticast msg = do sendTo sendSock msg addr yield The `threadDelay` call had the same effect as the yield. This also explains why the file size matters. -- Benno 2014-09-23 17:58 GMT+02:00 Ben Gunton : > Thanks Kyle. Tried forking both (http://lpaste.net/111477), and also > receiving from the main thread while forking the sending, and the results > were the same... still not receiving the last bunch of lines. > > On Tue, Sep 23, 2014 at 9:46 AM, Kyle Marek-Spartz < > kyle.marek.spartz at gmail.com> wrote: > >> I would try forking your sending thread, too, rather than using the main >> thread for sending. Alternatively, use the main thread for receiving and >> fork your sending thread. >> >> ? >> Kyle Marek-Spartz >> >> >> >> >> >> On Sep 23, 2014, 10:14:09 AM, Ben Gunton wrote: >> ------------------------------ >> I am trying to send multicast messages from one thread, and receive >> them on another. The sending thread reads lines from a file and sends them. >> However, the receiving thread does not receive all the messages - it seems >> to miss the last 10 message or so. If I run other programs to listen for >> the multicast message, they receive them fine. So I think the issue is >> something to do with receiving, not sending. I keep the program alive with >> a threadDelay, so it shouldn't be halting prematurely. If I add a small >> delay after each send, it works fine. And if I make the input file smaller, >> it works fine. >> >> On the provided data file, on my system (64-bit Ubuntu, GHC 7.8.2), the >> receiver fails to receive lines 125-140. Compiled with no optimizations. >> >> Thanks for any help! >> >> The relevant code snippets are below, and the sample data file and full >> program are attached. >> >> -- Loop to receive all the packets >> let receiveMulticast = do >> (msg, _) <- recvFrom recvSock 32628 >> putStrLn . BS.unpack $ BS.take 100 msg >> receiveMulticast >> _ <- forkIO receiveMulticast >> >> -- Send every line from a file as multicast message >> inputFile <- openFile "data" ReadMode >> fileLines <- BS.lines <$> BS.hGetContents inputFile >> let sendMulticast msg = do >> sendTo sendSock msg addr >> -- Receiver FAILS to receive last few messages unless this >> -- thread delay exists... why?! >> -- threadDelay (1) >> mapM_ sendMulticast fileLines >> hClose inputFile >> >> threadDelay (1000*1000*1000) -- Delay for 1000 seconds >> ------------------------------ >> - data, 71 KB >> - Main.hs, 2.2 KB >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Tue Sep 23 16:46:56 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Tue, 23 Sep 2014 09:46:56 -0700 Subject: [Haskell-cafe] Multicast receiver thread fails to receive last few messages In-Reply-To: References: Message-ID: Since this is UDP, you may be overflowing your device queue. Linux helpfully won't return ENOBUFS in this case but will instead just drop the packet on the floor. The threadDelay fixes this by yielding the processor so that the consumer thread can dequeue packets. G On Tue, Sep 23, 2014 at 8:14 AM, Ben Gunton wrote: > I am trying to send multicast messages from one thread, and receive them > on another. The sending thread reads lines from a file and sends them. > However, the receiving thread does not receive all the messages - it seems > to miss the last 10 message or so. If I run other programs to listen for > the multicast message, they receive them fine. So I think the issue is > something to do with receiving, not sending. I keep the program alive with > a threadDelay, so it shouldn't be halting prematurely. If I add a small > delay after each send, it works fine. And if I make the input file smaller, > it works fine. > > On the provided data file, on my system (64-bit Ubuntu, GHC 7.8.2), the > receiver fails to receive lines 125-140. Compiled with no optimizations. > > Thanks for any help! > > The relevant code snippets are below, and the sample data file and full > program are attached. > > -- Loop to receive all the packets > let receiveMulticast = do > (msg, _) <- recvFrom recvSock 32628 > putStrLn . BS.unpack $ BS.take 100 msg > receiveMulticast > _ <- forkIO receiveMulticast > > -- Send every line from a file as multicast message > inputFile <- openFile "data" ReadMode > fileLines <- BS.lines <$> BS.hGetContents inputFile > let sendMulticast msg = do > sendTo sendSock msg addr > -- Receiver FAILS to receive last few messages unless this > -- thread delay exists... why?! > -- threadDelay (1) > mapM_ sendMulticast fileLines > hClose inputFile > > threadDelay (1000*1000*1000) -- Delay for 1000 seconds > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From eual.jp at gmail.com Tue Sep 23 17:01:53 2014 From: eual.jp at gmail.com (Alexander Batischev) Date: Tue, 23 Sep 2014 20:01:53 +0300 Subject: [Haskell-cafe] Copyright field vs. License file In-Reply-To: <1411460184.2660.3.camel@joachim-breitner.de> References: <1411460184.2660.3.camel@joachim-breitner.de> Message-ID: <20140923170153.GC15512@antaeus> On Tue, Sep 23, 2014 at 10:16:24AM +0200, Joachim Breitner wrote: > A notable exception are the GPL-licensed packages; these usually don?t > have copyright information in the license. JFTR: they put it into the source files. Into *each one*. Quoting "How to use GNU licenses for your own software"[1]: > Whichever license you plan to use, the process involves adding two > elements to each source file of your program: a copyright notice (such > as ?Copyright 1999 Terry Jones?), and a statement of copying > permission, saying that the program is distributed under the terms of > the GNU General Public License (or the Lesser GPL). Now that's what I'd call "hard to parse". [1]: https://gnu.org/licenses/gpl-howto.html -- Regards, Alexander Batischev PGP key 356961A20C8BFD03 Fingerprint: CE6C 4307 9348 58E3 FD94 A00F 3569 61A2 0C8B FD03 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From clint at debian.org Tue Sep 23 17:31:43 2014 From: clint at debian.org (Clint Adams) Date: Tue, 23 Sep 2014 17:31:43 +0000 Subject: [Haskell-cafe] foreign ccall export / ghc 7.6.3 Message-ID: <20140923173143.GA28096@scru.org> Are there examples of "foreign ccall export" that work with GHC 7.6.3? From ben.gunton at gmail.com Tue Sep 23 18:26:49 2014 From: ben.gunton at gmail.com (Ben Gunton) Date: Tue, 23 Sep 2014 12:26:49 -0600 Subject: [Haskell-cafe] Multicast receiver thread fails to receive last few messages In-Reply-To: References: Message-ID: Indeed, this was the issue. Took Benno's advice and added a yield, and it works as I hoped it would. Thanks! On Tue, Sep 23, 2014 at 10:46 AM, Gregory Collins wrote: > Since this is UDP, you may be overflowing your device queue. Linux > helpfully won't return ENOBUFS in this case but will instead just drop the > packet on the floor. The threadDelay fixes this by yielding the processor > so that the consumer thread can dequeue packets. > > G > > On Tue, Sep 23, 2014 at 8:14 AM, Ben Gunton wrote: > >> I am trying to send multicast messages from one thread, and receive them >> on another. The sending thread reads lines from a file and sends them. >> However, the receiving thread does not receive all the messages - it seems >> to miss the last 10 message or so. If I run other programs to listen for >> the multicast message, they receive them fine. So I think the issue is >> something to do with receiving, not sending. I keep the program alive with >> a threadDelay, so it shouldn't be halting prematurely. If I add a small >> delay after each send, it works fine. And if I make the input file smaller, >> it works fine. >> >> On the provided data file, on my system (64-bit Ubuntu, GHC 7.8.2), the >> receiver fails to receive lines 125-140. Compiled with no optimizations. >> >> Thanks for any help! >> >> The relevant code snippets are below, and the sample data file and full >> program are attached. >> >> -- Loop to receive all the packets >> let receiveMulticast = do >> (msg, _) <- recvFrom recvSock 32628 >> putStrLn . BS.unpack $ BS.take 100 msg >> receiveMulticast >> _ <- forkIO receiveMulticast >> >> -- Send every line from a file as multicast message >> inputFile <- openFile "data" ReadMode >> fileLines <- BS.lines <$> BS.hGetContents inputFile >> let sendMulticast msg = do >> sendTo sendSock msg addr >> -- Receiver FAILS to receive last few messages unless this >> -- thread delay exists... why?! >> -- threadDelay (1) >> mapM_ sendMulticast fileLines >> hClose inputFile >> >> threadDelay (1000*1000*1000) -- Delay for 1000 seconds >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > -- > Gregory Collins > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Sep 23 19:14:51 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 23 Sep 2014 15:14:51 -0400 Subject: [Haskell-cafe] Multicast receiver thread fails to receive last few messages In-Reply-To: References: Message-ID: altenratively, you can compile your module with -fno-omit-yields, which adds a yield to no allocation loops On Tue, Sep 23, 2014 at 2:26 PM, Ben Gunton wrote: > Indeed, this was the issue. Took Benno's advice and added a yield, and it > works as I hoped it would. Thanks! > > On Tue, Sep 23, 2014 at 10:46 AM, Gregory Collins > wrote: > >> Since this is UDP, you may be overflowing your device queue. Linux >> helpfully won't return ENOBUFS in this case but will instead just drop the >> packet on the floor. The threadDelay fixes this by yielding the processor >> so that the consumer thread can dequeue packets. >> >> G >> >> On Tue, Sep 23, 2014 at 8:14 AM, Ben Gunton wrote: >> >>> I am trying to send multicast messages from one thread, and receive them >>> on another. The sending thread reads lines from a file and sends them. >>> However, the receiving thread does not receive all the messages - it seems >>> to miss the last 10 message or so. If I run other programs to listen for >>> the multicast message, they receive them fine. So I think the issue is >>> something to do with receiving, not sending. I keep the program alive with >>> a threadDelay, so it shouldn't be halting prematurely. If I add a small >>> delay after each send, it works fine. And if I make the input file smaller, >>> it works fine. >>> >>> On the provided data file, on my system (64-bit Ubuntu, GHC 7.8.2), the >>> receiver fails to receive lines 125-140. Compiled with no optimizations. >>> >>> Thanks for any help! >>> >>> The relevant code snippets are below, and the sample data file and full >>> program are attached. >>> >>> -- Loop to receive all the packets >>> let receiveMulticast = do >>> (msg, _) <- recvFrom recvSock 32628 >>> putStrLn . BS.unpack $ BS.take 100 msg >>> receiveMulticast >>> _ <- forkIO receiveMulticast >>> >>> -- Send every line from a file as multicast message >>> inputFile <- openFile "data" ReadMode >>> fileLines <- BS.lines <$> BS.hGetContents inputFile >>> let sendMulticast msg = do >>> sendTo sendSock msg addr >>> -- Receiver FAILS to receive last few messages unless this >>> -- thread delay exists... why?! >>> -- threadDelay (1) >>> mapM_ sendMulticast fileLines >>> hClose inputFile >>> >>> threadDelay (1000*1000*1000) -- Delay for 1000 seconds >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Gregory Collins >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Sep 24 03:19:30 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 23 Sep 2014 23:19:30 -0400 Subject: [Haskell-cafe] Numerals in input vs numerals in source Message-ID: <201409240319.s8O3JUm6011606@coolidge.cs.dartmouth.edu> Consider e1 = read "1" :: Integer e2 = read "1" :: Rational e3 = read "1" :: Double e1 and e3 evaluate to 1 and 1.0 respectively e2 produces an error: "Prelude.read: no parse" Yet (1::Integer, 1::Rational, 1::Double) evaluates to (1, 1%1, 1.0) Is the inconsistent parsing defensible, or just an (irrational!) fact? I believe a reconciliation would break nothing. Doug McIlroy From allbery.b at gmail.com Wed Sep 24 03:49:15 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 23 Sep 2014 23:49:15 -0400 Subject: [Haskell-cafe] Numerals in input vs numerals in source In-Reply-To: <201409240319.s8O3JUm6011606@coolidge.cs.dartmouth.edu> References: <201409240319.s8O3JUm6011606@coolidge.cs.dartmouth.edu> Message-ID: On Tue, Sep 23, 2014 at 11:19 PM, Doug McIlroy wrote: > Yet (1::Integer, 1::Rational, 1::Double) evaluates to (1, 1%1, 1.0) > > Is the inconsistent parsing defensible, or just an (irrational!) fact? > I believe a reconciliation would break nothing. > The parsing is the same; read is not expected to throw a fromIntegral into the mix, whereas the compiler is required to. (The 1 is parsed as Integer by the compiler in all three cases, but the resulting AST is (fromIntegral 1) in all three cases.) I suspect a Read instance that included a fromIntegral would be even more irrational. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Sep 24 03:54:17 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 23 Sep 2014 23:54:17 -0400 Subject: [Haskell-cafe] Numerals in input vs numerals in source In-Reply-To: References: <201409240319.s8O3JUm6011606@coolidge.cs.dartmouth.edu> Message-ID: On Tue, Sep 23, 2014 at 11:49 PM, Brandon Allbery wrote: > (The 1 is parsed as Integer by the compiler in all three cases, but the > resulting AST is (fromIntegral 1) in all three cases.) Actually, to be pedantic, it's fromInteger and the resulting AST node is something like ((fromInteger :: Num a => Integer -> a) (1 :: Integer)) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Wed Sep 24 07:24:56 2014 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Wed, 24 Sep 2014 09:24:56 +0200 Subject: [Haskell-cafe] [ANN] Declarative Game Programming & haskanoid (FRP, SDL, Android) Message-ID: Hi Caf? A few weeks ago Henrik Nilsson gave a tutorial at PPDP 14 on Declarative Game Programming, demoing an SDL game using the FRP implementation Yampa. Additional material has been made available now: * Announcement and slides: http://fplab.bitbucket.org/posts/2014-09-23-declarative-game-programm.html * Game: http://github.com/ivanperez-keera/haskanoid The game includes wiimote support, SDL graphics and sound. We have other versions working with a kinect, if anyone is particularly interested. This is, IMHO, very fun to play, since you have to actually run around the room. Also, Keera Studios (my company) is working on an Android version of the game and a video of an early demo running on a Galaxy Tab is available ( http://keera.co.uk/blog/2014/09/24/game-programming-videos-code/ ). Our internal, latest version runs now much faster than the ones in either video (new videos will be released soon). I hope we can soon give you a great excuse to be playing games at the office ;) All the best Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Wed Sep 24 07:30:21 2014 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Wed, 24 Sep 2014 08:30:21 +0100 Subject: [Haskell-cafe] Nottingham Research Fellowships (deadline 20th October) Message-ID: <237518B0-E0BB-43FA-A309-17361A517865@exmail.nottingham.ac.uk> Dear all, The University of Nottingham is seeking applications for a number of Nottingham Research Fellowships: http://tinyurl.com/notts-fellows These are highly prestigious three-year fellowships, which are normally expected to lead into permenant academic positions. Candidates should have no more than 8 years postdoctoral experience, and fellowships normally start in October 2015. The deadline for submission of initial Expressions of Interest is ** 20th October 2014 **. Applicants in the area of the Functional Programming (FP) lab would be most welcome. The FP lab is keen to receive applications from outstanding candidates with an excellent publication record, experience in combining theory with practice, and the ability to secure external funding to support their research. Further information about the FP lab is available from http://fp.cs.nott.ac.uk As an approximate guideline, candidates in the area of the FP lab would normally be expected to have at least 3 years postdoc experience, and a number of strong publications in leading international venues such as ICFP, POPL, LICS, JFP, Haskell Symposium, etc. Best wishes, Graham Hutton -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From ivanperezdominguez at gmail.com Wed Sep 24 08:51:56 2014 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Wed, 24 Sep 2014 10:51:56 +0200 Subject: [Haskell-cafe] [ANN] Declarative Game Programming & haskanoid (FRP, SDL, Android) In-Reply-To: References: Message-ID: Hi Mikolaj, (CC haskell-cafe) Thanks, Mikolaj! Indeed, the original links to the slides were broken (deployment env vs production env, yikes!). That has been fixed now. Bitbucket seeems to be taking some time to refresh the page, though. In the meantime: http://fplab.bitbucket.org/uploads/ppdp2014-tutorial.pdf http://fplab.bitbucket.org/uploads/ppdp2014-tutorial-4up.pdf Best Ivan On 24 September 2014 10:27, Mikolaj Konarski wrote: > > * Announcement and slides: > > > http://fplab.bitbucket.org/posts/2014-09-23-declarative-game-programm.html > > Hi! Thank you for the post. Both slides links are dead for me, though. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Wed Sep 24 09:14:54 2014 From: dominic at steinitz.org (Dominic Steinitz) Date: Wed, 24 Sep 2014 09:14:54 +0000 (UTC) Subject: [Haskell-cafe] Numerals in input vs numerals in source References: <201409240319.s8O3JUm6011606@coolidge.cs.dartmouth.edu> Message-ID: I am not sure this is an answer but languages like Python and R are much less fussy and if you want to use data that they parse quite happily then you have to do something like newtype LaxDouble = LaxDouble { laxDouble :: Double } and write your own Read instance. From lemming at henning-thielemann.de Wed Sep 24 11:00:54 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 24 Sep 2014 13:00:54 +0200 (CEST) Subject: [Haskell-cafe] code.haskell.org down Message-ID: code.haskell.org seems to be down :-( From lars at hupel.info Wed Sep 24 11:49:10 2014 From: lars at hupel.info (Lars Hupel) Date: Wed, 24 Sep 2014 13:49:10 +0200 Subject: [Haskell-cafe] Separate compilation Message-ID: <5422AFB6.2020109@hupel.info> Hi all, I'm trying to compile a couple of file separately. The main purpose for that is that we're checking student-submitted exercises, and we want to compile them with -XSafe. The test suite doesn't require -XSafe. There are basically three files: * Exercise.hs -- uploaded by the student * Exercise_Interface.hs -- imports the 'Exercise' module and creates new bindings with appropriate types * Exercise_Test.hs -- imports the interface module and contains the test code and 'main' Here's how I try to compile these files: TEMP="$(mktemp -d -p /tmp ghcXXX)" ghc -c -XSafe -outputdir "$TEMP" Exercise.hs ghc -c -outputdir "$TEMP" -i"$TEMP" Exercise_Interface.hs ghc -o "$TEMP/runner" -outputdir "$TEMP" -i"$TEMP" Exercise_Test.hs This works except for the last step: GHC complains that it can't find the module 'Exercise_Interface'. Upon closer inspection with '-v', it turns out that it's actually looking for the .hs file, which I find odd. If I add '-c' to the last invocation, it works, but I don't get an executable. What am I doing wrong? Cheers Lars From joe at joefiorini.com Wed Sep 24 14:50:05 2014 From: joe at joefiorini.com (Joe Fiorini) Date: Wed, 24 Sep 2014 10:50:05 -0400 Subject: [Haskell-cafe] Combining LoggingT with another library's monad Message-ID: <1411570205.2390638.171262457.426B8EF7@webmail.messagingengine.com> As I've been learning Haskell, I've found I constantly get tripped up on combining monads with transformers to form stacks. This seems to be very common in web development, which is my primary use case for Haskell. I'm using the Wheb framework as it's been the simplest to understand of all the frameworks I've seen. To get a better understanding of monad transformers, I'm trying to implement logging in a small app I wrote. I'm attempting to use Control.Monad.Logger to add LoggingT to my monad stack, that way I can use runStdoutLoggingT to log straight to stdout (without having to deal with implementing my own monadLoggerLog method). I added LoggingT to the top of my monad stack, but ran into lots of problems and moved the LoggingT type to one of my route handlers (you can see my latest attempt & the compiler error here https://gist.github.com/joefiorini/9e89bdf86e28e6b98bf0). I'm at a point now where I believe my problem is either a) I'm just not understanding something about how monad transformers work, in which case I just need to do some more reading or b) the LoggingT transformer is simply not "compatible" with the WhebT transformer, in which case I need to completely change my approach. I'm not looking for someone to solve my problem for me; I'm just trying to get a little guidance. Am I heading in the right direction here or should I change up my approach? If the latter, can anyone give me a little direction as to where to look? Thanks! From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Sep 24 15:08:08 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 24 Sep 2014 16:08:08 +0100 Subject: [Haskell-cafe] Combining LoggingT with another library's monad In-Reply-To: <1411570205.2390638.171262457.426B8EF7@webmail.messagingengine.com> References: <1411570205.2390638.171262457.426B8EF7@webmail.messagingengine.com> Message-ID: <20140924150807.GN27848@weber> On Wed, Sep 24, 2014 at 10:50:05AM -0400, Joe Fiorini wrote: > I added LoggingT to the top of my monad stack, but ran into lots of > problems and moved the LoggingT type to one of my route handlers (you > can see my latest attempt & the compiler error here > https://gist.github.com/joefiorini/9e89bdf86e28e6b98bf0). Don't you want `lift` instead of `return` in `handleHome`? From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Sep 24 15:14:27 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 24 Sep 2014 16:14:27 +0100 Subject: [Haskell-cafe] Combining LoggingT with another library's monad In-Reply-To: <20140924150807.GN27848@weber> References: <1411570205.2390638.171262457.426B8EF7@webmail.messagingengine.com> <20140924150807.GN27848@weber> Message-ID: <20140924151426.GO27848@weber> On Wed, Sep 24, 2014 at 04:08:08PM +0100, Tom Ellis wrote: > On Wed, Sep 24, 2014 at 10:50:05AM -0400, Joe Fiorini wrote: > > I added LoggingT to the top of my monad stack, but ran into lots of > > problems and moved the LoggingT type to one of my route handlers (you > > can see my latest attempt & the compiler error here > > https://gist.github.com/joefiorini/9e89bdf86e28e6b98bf0). > > Don't you want `lift` instead of `return` in `handleHome`? `lift` is in `Control.Monad.Trans.Class`, by the way. From joe at joefiorini.com Wed Sep 24 17:09:41 2014 From: joe at joefiorini.com (Joe Fiorini) Date: Wed, 24 Sep 2014 10:09:41 -0700 (PDT) Subject: [Haskell-cafe] Combining LoggingT with another library's monad In-Reply-To: <20140924151426.GO27848@weber> References: <1411570205.2390638.171262457.426B8EF7@webmail.messagingengine.com> <20140924150807.GN27848@weber> <20140924151426.GO27848@weber> Message-ID: Thanks, good to know I was on the right track. This gets me a new error I can work on now :) On Wednesday, September 24, 2014 11:14:44 AM UTC-4, Tom Ellis wrote: > > On Wed, Sep 24, 2014 at 04:08:08PM +0100, Tom Ellis wrote: > > On Wed, Sep 24, 2014 at 10:50:05AM -0400, Joe Fiorini wrote: > > > I added LoggingT to the top of my monad stack, but ran into lots of > > > problems and moved the LoggingT type to one of my route handlers (you > > > can see my latest attempt & the compiler error here > > > https://gist.github.com/joefiorini/9e89bdf86e28e6b98bf0). > > > > Don't you want `lift` instead of `return` in `handleHome`? > > `lift` is in `Control.Monad.Trans.Class`, by the way. > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at joefiorini.com Wed Sep 24 17:09:41 2014 From: joe at joefiorini.com (Joe Fiorini) Date: Wed, 24 Sep 2014 10:09:41 -0700 (PDT) Subject: [Haskell-cafe] Combining LoggingT with another library's monad In-Reply-To: <20140924151426.GO27848@weber> References: <1411570205.2390638.171262457.426B8EF7@webmail.messagingengine.com> <20140924150807.GN27848@weber> <20140924151426.GO27848@weber> Message-ID: Thanks, good to know I was on the right track. This gets me a new error I can work on now :) On Wednesday, September 24, 2014 11:14:44 AM UTC-4, Tom Ellis wrote: > > On Wed, Sep 24, 2014 at 04:08:08PM +0100, Tom Ellis wrote: > > On Wed, Sep 24, 2014 at 10:50:05AM -0400, Joe Fiorini wrote: > > > I added LoggingT to the top of my monad stack, but ran into lots of > > > problems and moved the LoggingT type to one of my route handlers (you > > > can see my latest attempt & the compiler error here > > > https://gist.github.com/joefiorini/9e89bdf86e28e6b98bf0). > > > > Don't you want `lift` instead of `return` in `handleHome`? > > `lift` is in `Control.Monad.Trans.Class`, by the way. > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskellcafe at futurenotfound.com Wed Sep 24 18:03:08 2014 From: haskellcafe at futurenotfound.com (Sean Parsons) Date: Wed, 24 Sep 2014 19:03:08 +0100 Subject: [Haskell-cafe] Taking over the thrift package. Message-ID: <5423075C.2040004@futurenotfound.com> Hi there. As per the instructions on the Haskell wiki I'm posting here as I'm interested in either taking over the thrift package or helping out with getting more recent builds uploaded as it's wildly out of date: https://hackage.haskell.org/package/thrift Does anyone have any contact details for the current maintainer? Thanks, Sean. From jozefg at cmu.edu Wed Sep 24 18:09:03 2014 From: jozefg at cmu.edu (Danny Gratzer) Date: Wed, 24 Sep 2014 14:09:03 -0400 Subject: [Haskell-cafe] Taking over the thrift package. In-Reply-To: <5423075C.2040004@futurenotfound.com> References: <5423075C.2040004@futurenotfound.com> Message-ID: <87lhp899hc.fsf@cmu.edu> Googling the uploaders name turned up this: http://www.haskellers.com/user/clavoie The email address is listed there :) From cma at bitemyapp.com Wed Sep 24 18:38:38 2014 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 24 Sep 2014 13:38:38 -0500 Subject: [Haskell-cafe] Taking over the thrift package. In-Reply-To: <87lhp899hc.fsf@cmu.edu> References: <5423075C.2040004@futurenotfound.com> <87lhp899hc.fsf@cmu.edu> Message-ID: Doesn't the Thrift project have official Haskell bindings that were updated recently? On Wed, Sep 24, 2014 at 1:09 PM, Danny Gratzer wrote: > > Googling the uploaders name turned up this: > http://www.haskellers.com/user/clavoie > > The email address is listed there :) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpaugh at gmx.us Wed Sep 24 14:28:53 2014 From: jpaugh at gmx.us (Jonathan Paugh) Date: Wed, 24 Sep 2014 09:28:53 -0500 Subject: [Haskell-cafe] Numerals in input vs numerals in source In-Reply-To: References: <201409240319.s8O3JUm6011606@coolidge.cs.dartmouth.edu> Message-ID: <5422D525.7020200@gmx.us> On 09/24/2014 04:14 AM, Dominic Steinitz wrote: > I am not sure this is an answer but languages like Python and R are > much less fussy and if you want to use data that they parse quite > happily then you have to do something like > > newtype LaxDouble = LaxDouble { laxDouble :: Double } > > and write your own Read instance. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe The following works just fine. I think this is correct behavior. read "1%1" :: Rational -- Jonathan Paugh jpaugh at gmx.us From howard_b_golden at yahoo.com Wed Sep 24 21:56:01 2014 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Wed, 24 Sep 2014 14:56:01 -0700 Subject: [Haskell-cafe] Replacement for Ptr () in FFI declaration? Message-ID: <1411595761.70671.YahooMailNeo@web120804.mail.ne1.yahoo.com> Hi, Apparently, before GHC 7.8, it was possible to specify FFI declarations using Ptr (). However, it now gets an error message: This is from com-1.2.3.1 when I try to compile it: ------ message follows ----- [12 of 21] Compiling System.Win32.Com.Automation.TypeLib ( System\Win32\Com\Automation\TypeLib.hs, dist\build\System\Win 32\Com\Automation\TypeLib.o ) System\Win32\Com\Automation\TypeLib.hs:1379:1: Unacceptable argument type in foreign declaration: Ptr () When checking declaration: foreign import stdcall safe "dynamic" prim_System_Win32_Com_Automation_TypeLib_setGuid :: Ptr () -> Ptr () -> Ptr GUID -> IO Int32 ------ end of message ----- What is the proper declaration to use instead of Ptr () ? Thanks. Howard B. Golden From dstcruz at gmail.com Thu Sep 25 03:54:24 2014 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Wed, 24 Sep 2014 21:54:24 -0600 Subject: [Haskell-cafe] Haskell Weekly News: Issue 307 Message-ID: Welcome to issue 307 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from September 14 to 20, 2014 Quotes of the Week * Qfwfq: I seq what you mean. * trap_exit_: if haskell makes programmers 10x more productive, then why are there not better haskell ides? :-) Fuuzetsu: trap_exit_: because you don't need one when you're 10x more productive already ;P * joshcough: im just surprised when im looking for something and i dont find a package by ed kmett. Top Reddit Stories * Wayward Tide is Being Written in Haskell Domain: blog.chucklefish.org, Score: 131, Comments: 30 Original: [1] http://goo.gl/00xr22 On Reddit: [2] http://goo.gl/kJBqTe * Hython: The simplest possible language Domain: callcc.io, Score: 82, Comments: 16 Original: [3] http://goo.gl/T95xQ3 On Reddit: [4] http://goo.gl/LBKTks * Hey /r/haskell, we're hiring! Domain: blog.chucklefish.org, Score: 79, Comments: 49 Original: [5] http://goo.gl/93gW3N On Reddit: [6] http://goo.gl/zULSci * hindent: A Haskell indenter Domain: chrisdone.com, Score: 58, Comments: 18 Original: [7] http://goo.gl/4XlJpL On Reddit: [8] http://goo.gl/SCXxOS * Reflecting strictness in Haskell types Domain: h2.jaguarpaw.co.uk, Score: 51, Comments: 27 Original: [9] http://goo.gl/lfPkYD On Reddit: [10] http://goo.gl/hx6XtM * Towards Shake 1.0 Domain: neilmitchell.blogspot.com, Score: 49, Comments: 7 Original: [11] http://goo.gl/RPlddo On Reddit: [12] http://goo.gl/ckKD2m * Formatting in Haskell (Chris Done) Domain: chrisdone.com, Score: 49, Comments: 11 Original: [13] http://goo.gl/eq7hAF On Reddit: [14] http://goo.gl/f1Amec * Haskell Dice of Doom - Part 1 Domain: derekmcloughlin.github.io, Score: 39, Comments: 6 Original: [15] http://goo.gl/oF3ot3 On Reddit: [16] http://goo.gl/oLz2Fv * Beginner error messages in C++ vs Haskell Domain: izbicki.me, Score: 39, Comments: 65 Original: [17] http://goo.gl/j05AXH On Reddit: [18] http://goo.gl/ZOLvZW * Blog: GHC Weekly News - 2014/09/15 Domain: ghc.haskell.org, Score: 28, Comments: 0 Original: [19] http://goo.gl/8Dt0e8 On Reddit: [20] http://goo.gl/P4uz3y * Let's Build a Browser Engine in Haskell: part 3 Domain: hrothen.github.io, Score: 27, Comments: 8 Original: [21] http://goo.gl/0ckGRH On Reddit: [22] http://goo.gl/vZXZOy * ANN: best-haskell - haskell download ranking Domain: best-haskell.herokuapp.com, Score: 24, Comments: 11 Original: [23] http://goo.gl/9RtgrI On Reddit: [24] http://goo.gl/3zO7SN * ICFP "The Ghost of Church" - writeup by Olle Fredriksson who was the first to solve it! Domain: reddit.com, Score: 23, Comments: 3 Original: [25] http://goo.gl/9j7hG3 On Reddit: [26] http://goo.gl/nDxc4T * What is wrong with the Monoid instance for Maybe? Domain: self.haskell, Score: 21, Comments: 21 Original: [27] http://goo.gl/kgVlFf On Reddit: [28] http://goo.gl/kgVlFf * Inferring Algebraic Effects Domain: lmcs-online.org, Score: 20, Comments: 0 Original: [29] http://goo.gl/Wjklhq On Reddit: [30] http://goo.gl/PBJY7N * Are typeclasses essential? (includes Luke Palmer's view on it) Domain: stackoverflow.com, Score: 19, Comments: 30 Original: [31] http://goo.gl/5rh2dq On Reddit: [32] http://goo.gl/RuX5i7 * Built on Haskell: Findmelike - visual search for art Domain: findmelike.com, Score: 19, Comments: 1 Original: [33] http://goo.gl/MgM69t On Reddit: [34] http://goo.gl/Vzrc6R * Let's Build a Browser Engine in Haskell: setting up tests Domain: hrothen.github.io, Score: 17, Comments: 9 Original: [35] http://goo.gl/qwLXRq On Reddit: [36] http://goo.gl/mUqX6w Top StackOverflow Questions * Are typeclasses essential? votes: 20, answers: 4 Read on SO: [37] http://goo.gl/5rh2dq * Ambigous instance resolution in Haskell votes: 14, answers: 2 Read on SO: [38] http://goo.gl/KzV5jC * Understanding the casts involved in patterns matching a datatype that is indexed over a user defined kind votes: 11, answers: 1 Read on SO: [39] http://goo.gl/TppaAg * What does fixIO do? votes: 10, answers: 2 Read on SO: [40] http://goo.gl/yECrrk Until next time, [41]+Daniel Santa Cruz References 1. http://blog.chucklefish.org/?p=154 2. http://www.reddit.com/r/haskell/comments/2glk10/wayward_tide_is_being_written_in_haskell/ 3. http://callcc.io/hython-the-simplest-possible-language/ 4. http://www.reddit.com/r/haskell/comments/2go4v6/hython_the_simplest_possible_language/ 5. http://blog.chucklefish.org/?p=322 6. http://www.reddit.com/r/haskell/comments/2gyn1w/hey_rhaskell_were_hiring/ 7. http://chrisdone.com/posts/hindent 8. http://www.reddit.com/r/haskell/comments/2gyaw7/hindent_a_haskell_indenter/ 9. http://h2.jaguarpaw.co.uk/posts/strictness-in-types/ 10. http://www.reddit.com/r/haskell/comments/2gk51p/reflecting_strictness_in_haskell_types/ 11. http://neilmitchell.blogspot.com/2014/09/towards-shake-10.html 12. http://www.reddit.com/r/haskell/comments/2gnat7/towards_shake_10/ 13. http://chrisdone.com/posts/formatting 14. http://www.reddit.com/r/haskell/comments/2gyrvp/formatting_in_haskell_chris_done/ 15. http://derekmcloughlin.github.io/2014/09/13/Haskell-Dice-Of-Doom-Part-1/ 16. http://www.reddit.com/r/haskell/comments/2gg3um/haskell_dice_of_doom_part_1/ 17. https://izbicki.me/blog/error-messages-in-ghc-vs-g++.html 18. http://www.reddit.com/r/haskell/comments/2go92u/beginner_error_messages_in_c_vs_haskell/ 19. https://ghc.haskell.org/trac/ghc/blog/weekly20140915 20. http://www.reddit.com/r/haskell/comments/2gia13/blog_ghc_weekly_news_20140915/ 21. http://hrothen.github.io/2014/09/19/lets-build-a-browser-engine-in-haskell-part-3/ 22. http://www.reddit.com/r/haskell/comments/2gw2bw/lets_build_a_browser_engine_in_haskell_part_3/ 23. http://best-haskell.herokuapp.com/ 24. http://www.reddit.com/r/haskell/comments/2gsjk0/ann_besthaskell_haskell_download_ranking/ 25. http://www.reddit.com/r/theghostofchurch/comments/2fccjw/i_found_this_trinket_by_a_rho_of_trees/ckh62js 26. http://www.reddit.com/r/haskell/comments/2gkjij/icfp_the_ghost_of_church_writeup_by_olle/ 27. http://www.reddit.com/r/haskell/comments/2guo44/what_is_wrong_with_the_monoid_instance_for_maybe/ 28. http://www.reddit.com/r/haskell/comments/2guo44/what_is_wrong_with_the_monoid_instance_for_maybe/ 29. http://www.lmcs-online.org/ojs/viewarticle.php?id=1469 30. http://www.reddit.com/r/haskell/comments/2gdl31/inferring_algebraic_effects/ 31. http://stackoverflow.com/questions/25855507/are-typeclasses-essential 32. http://www.reddit.com/r/haskell/comments/2gjqop/are_typeclasses_essential_includes_luke_palmers/ 33. http://findmelike.com/ 34. http://www.reddit.com/r/haskell/comments/2gn81y/built_on_haskell_findmelike_visual_search_for_art/ 35. http://hrothen.github.io/2014/09/14/lets-build-a-browser-engine-in-haskell-setting-up-tests/ 36. http://www.reddit.com/r/haskell/comments/2ge7om/lets_build_a_browser_engine_in_haskell_setting_up/ 37. http://stackoverflow.com/questions/25855507/are-typeclasses-essential 38. http://stackoverflow.com/questions/25854072/ambigous-instance-resolution-in-haskell 39. http://stackoverflow.com/questions/25934209/understanding-the-casts-involved-in-patterns-matching-a-datatype-that-is-indexed 40. http://stackoverflow.com/questions/25876042/what-does-fixio-do 41. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Thu Sep 25 04:04:35 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 25 Sep 2014 00:04:35 -0400 Subject: [Haskell-cafe] Replacement for Ptr () in FFI declaration? In-Reply-To: <1411595761.70671.YahooMailNeo@web120804.mail.ne1.yahoo.com> References: <1411595761.70671.YahooMailNeo@web120804.mail.ne1.yahoo.com> Message-ID: <54239453.80800@vex.net> On 14-09-24 05:56 PM, Howard B. Golden wrote: > Unacceptable argument type in foreign declaration: Ptr () > When checking declaration: > foreign import stdcall safe "dynamic" prim_System_Win32_Com_Automation_TypeLib_setGuid > :: Ptr () -> Ptr () -> Ptr GUID -> IO Int32 It is not just 7.8 (I just tried 7.6), and it is not just GHC. It is about "dynamic", and it is in Haskell 98 with the FFI Addendum or Haskell 2010. "The type of a dynamic stub has to be of the form (FunPtr ft) -> ft, where ft may be any foreign type." In retrospect, I think you completely mistook the meaning of "dynamic". From waldmann at imn.htwk-leipzig.de Thu Sep 25 09:07:46 2014 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Thu, 25 Sep 2014 09:07:46 +0000 (UTC) Subject: [Haskell-cafe] Separate compilation References: <5422AFB6.2020109@hupel.info> Message-ID: > If I add '-c' to the last invocation, it works, but I don't get an > executable. add an extra step for linking, like this: 'ghc -o Foo *.o' From chris at chrisdornan.com Thu Sep 25 12:10:22 2014 From: chris at chrisdornan.com (Chris Dornan) Date: Thu, 25 Sep 2014 12:10:22 -0000 Subject: [Haskell-cafe] api-tools questions In-Reply-To: <540F0BCF.8040004@well-typed.com> References: <86ppf5gd66.fsf@fook.fritz.box> <540F0BCF.8040004@well-typed.com> Message-ID: You might also find the keystore[0] package useful as it makes use of this technique in several places. See, for example the definition of Pattern in the `Data.Keystore.Types.Schema`[1] and `Data.Keystore.Types`[2]. (Btw, the keystone docs are not building on Hackage for the latest version; they build on our private Hackage server and they did for earlier versions of Hackage[3]; I will try to fix them tonight.) Chris [0] http://hackage.haskell.org/package/keystore [1] https://github.com/cdornan/keystore/blob/master/src/Data/KeyStore/Types/Sch ema.hs#L179 [2] https://github.com/cdornan/keystore/blob/master/src/Data/KeyStore/Types.hs# L68 [3] http://hackage.haskell.org/package/keystore-0.5.0.4 On 09/09/2014 16:16, "Adam Gundry" wrote: >Hi Karsten, > >This isn't very well documented, but there is a (hidden) feature of >api-tools that should do what you want. If you say something like > > mt :: MyTime = basic string with inj_MyTime, prj_MyTime > >then you can define your own type MyTime and give conversion functions >inj_MyTime and prj_MyTime to convert back and forth from a >newtype-wrapped Text. (In fact, you could probably use UTCTime as >MyTime...). More precisely, api-tools will generate something like > > newtype REP__MyTime = REP__MyTime Text > >and you will need to implement > > inj_MyTime :: REP__MyTime -> ParserWithErrs MyTime > prj_MyTime :: MyTime -> REP__MyTime > >I hope this helps, and further questions or documentation contributions >are very welcome! > >Cheers, > >Adam > > >On 09/09/14 14:02, Karsten Gebbert wrote: >> Hi All, >> >> I have a question concerning the api-tools package. >> >> Its not clear from the tests, sources or the tutorial how I can use >> other date/time formats that the default `utc` type can handle. I'm >> trying to wrap a JSON API that is not under my control, so I have to >> adhere to whatever I get back from it. Could anybody with experience >> with the package point me to some example, relevant bits in the sources >> or a tip how to do it? >> >> I'm planning to create some more documentation around the package to >> contribute back once I figured out a few more details, because I think >> its quite a useful abstraction when dealing with (foreign) APIs IMO. >> >> Thanks already for any hints, >> >> karsten > > >-- >Adam Gundry, Haskell Consultant >Well-Typed LLP, http://www.well-typed.com/ >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe at haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From chris at chrisdornan.com Thu Sep 25 12:10:23 2014 From: chris at chrisdornan.com (Chris Dornan) Date: Thu, 25 Sep 2014 12:10:23 -0000 Subject: [Haskell-cafe] api-tools questions In-Reply-To: <86iokwhlc9.fsf@fook.fritz.box> References: <86ppf5gd66.fsf@fook.fritz.box> <540F0BCF.8040004@well-typed.com> <86iokwhlc9.fsf@fook.fritz.box> Message-ID: You might also find the keystore[0] package useful as it makes use of this technique in several places. See, for example the definition of Pattern in the `Data.Keystore.Types.Schema`[1] and `Data.Keystore.Types`[2]. Chris [0]-http://hackage.haskell.org/package/keystore [1]-https://github.com/cdornan/keystore/blob/master/src/Data/KeyStore/Types /Schema.hs#L179 [2]-https://github.com/cdornan/keystore/blob/master/src/Data/KeyStore/Types .hs#L68 On 09/09/2014 17:20, "Karsten Gebbert" wrote: >Excellent, thanks a lot Adam. I'll open a PR when I'm through with this >project :) > >Adam Gundry writes: > >> Hi Karsten, >> >> This isn't very well documented, but there is a (hidden) feature of >> api-tools that should do what you want. If you say something like >> >> mt :: MyTime = basic string with inj_MyTime, prj_MyTime >> >> then you can define your own type MyTime and give conversion functions >> inj_MyTime and prj_MyTime to convert back and forth from a >> newtype-wrapped Text. (In fact, you could probably use UTCTime as >> MyTime...). More precisely, api-tools will generate something like >> >> newtype REP__MyTime = REP__MyTime Text >> >> and you will need to implement >> >> inj_MyTime :: REP__MyTime -> ParserWithErrs MyTime >> prj_MyTime :: MyTime -> REP__MyTime >> >> I hope this helps, and further questions or documentation contributions >> are very welcome! >> >> Cheers, >> >> Adam >> >> >> On 09/09/14 14:02, Karsten Gebbert wrote: >>> Hi All, >>> >>> I have a question concerning the api-tools package. >>> >>> Its not clear from the tests, sources or the tutorial how I can use >>> other date/time formats that the default `utc` type can handle. I'm >>> trying to wrap a JSON API that is not under my control, so I have to >>> adhere to whatever I get back from it. Could anybody with experience >>> with the package point me to some example, relevant bits in the sources >>> or a tip how to do it? >>> >>> I'm planning to create some more documentation around the package to >>> contribute back once I figured out a few more details, because I think >>> its quite a useful abstraction when dealing with (foreign) APIs IMO. >>> >>> Thanks already for any hints, >>> >>> karsten >> >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe at haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From jjwchoy at gmail.com Thu Sep 25 12:47:32 2014 From: jjwchoy at gmail.com (Jason Choy) Date: Thu, 25 Sep 2014 13:47:32 +0100 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> Message-ID: Thanks for the responses. I appreciate that floating point arithmetic is imprecise, and anyone using it should be aware of the ramifications, however it still feels strange to me that Sum Double claims to be a monoid. Is this is a case where convenience is favoured over correctness? Are there any other monoids with an "almost associative" binary operator? I think I would feel a little less uneasy if the types were called ImpreciseSum and ImpreciseProduct when it is not associative. On 23 September 2014 17:30, Carter Schonwald wrote: > well said and thanks for taking the time to clarify some of the > imprecision in what I was saying! > > On Tue, Sep 23, 2014 at 3:06 AM, Richard A. O'Keefe > wrote: > >> >> On 20/09/2014, at 5:26 AM, Carter Schonwald wrote: >> >> > Indeed, >> > >> > Also Floating point numbers are NOT real numbers, they are approximate >> points on the real line that we pretend are exact reals but really are a >> very different geometry all together! :) >> >> Floating point numbers are *PRECISE* numbers with >> approximate *OPERATIONS*. This is the way they are >> defined in the IEEE standard and its successors; >> this is the way they are defined in LIA-1 and its >> successors. If you do not understand that it is >> the OPERATIONS that are approximate, not the numbers, >> you have not yet begun to understand floating point >> arithmetic. >> >> > Floats and Doubles are not exact numbers, dont use them when you expect >> things to behave "exact". NB that even if you have *exact* numbers, the >> exact same precision issues will still apply to pretty much any computation >> thats interesting (ignoring what the definition of interesting is). Try >> defining things like \ x -> SquareRoot x or \x-> e^x on the rational >> numbers! Questions of precision still creep in! >> >> You're not talking about precision here but about >> approximation. And you can simply work with finite representations >> of algebraic numbers. I have a Smalltalk class that implements >> QuadraticSurds so that I can represent (1 + sqrt 5)/2 *exactly*. >> You can even compare QuadraticSurds with the same surd exactly. >> (This all works so much better in Haskell, where you can make >> the "5" part a type-level parameter.) >> >> Since e is not a rational number, it's not terribly interesting >> that e^x (usually) isn't when x is rational. >> >> If we want to compute with a richer range of numbers than >> the rationals, we can do that. We could, for example, compute >> with continued fractions. Haskell makes that a small matter >> of programming, and I expect someone has already done it. >> >> > So I guess phrased another way, a lot of the confusion / challenge in >> writing floating point programs lies in understanding the representation, >> its limits, and the ways in which it will implicitly manage that precision >> tracking book keeping for you. >> >> Exactly so. There are even people who think the representation >> is approximate instead of the operations! For things like >> doubled-double, it really matters that the numbers are precise >> and combine in predictable ways. >> >> Interestingly, while floating point addition and multiplication >> are not associative, they are not wildly or erratically >> non-associative, and it is possible to reason about the results >> of operations. >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Sep 25 17:54:02 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 25 Sep 2014 13:54:02 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> Message-ID: No. It is associative, just not in the way you expect. ? On Thursday, September 25, 2014, Jason Choy wrote: > Thanks for the responses. > > I appreciate that floating point arithmetic is imprecise, and anyone using > it should be aware of the ramifications, however it still feels strange to > me that Sum Double claims to be a monoid. Is this is a case where > convenience is favoured over correctness? Are there any other monoids with > an "almost associative" binary operator? > > I think I would feel a little less uneasy if the types were called > ImpreciseSum and ImpreciseProduct when it is not associative. > > > On 23 September 2014 17:30, Carter Schonwald > wrote: > >> well said and thanks for taking the time to clarify some of the >> imprecision in what I was saying! >> >> On Tue, Sep 23, 2014 at 3:06 AM, Richard A. O'Keefe > > wrote: >> >>> >>> On 20/09/2014, at 5:26 AM, Carter Schonwald wrote: >>> >>> > Indeed, >>> > >>> > Also Floating point numbers are NOT real numbers, they are approximate >>> points on the real line that we pretend are exact reals but really are a >>> very different geometry all together! :) >>> >>> Floating point numbers are *PRECISE* numbers with >>> approximate *OPERATIONS*. This is the way they are >>> defined in the IEEE standard and its successors; >>> this is the way they are defined in LIA-1 and its >>> successors. If you do not understand that it is >>> the OPERATIONS that are approximate, not the numbers, >>> you have not yet begun to understand floating point >>> arithmetic. >>> >>> > Floats and Doubles are not exact numbers, dont use them when you >>> expect things to behave "exact". NB that even if you have *exact* numbers, >>> the exact same precision issues will still apply to pretty much any >>> computation thats interesting (ignoring what the definition of interesting >>> is). Try defining things like \ x -> SquareRoot x or \x-> e^x on the >>> rational numbers! Questions of precision still creep in! >>> >>> You're not talking about precision here but about >>> approximation. And you can simply work with finite representations >>> of algebraic numbers. I have a Smalltalk class that implements >>> QuadraticSurds so that I can represent (1 + sqrt 5)/2 *exactly*. >>> You can even compare QuadraticSurds with the same surd exactly. >>> (This all works so much better in Haskell, where you can make >>> the "5" part a type-level parameter.) >>> >>> Since e is not a rational number, it's not terribly interesting >>> that e^x (usually) isn't when x is rational. >>> >>> If we want to compute with a richer range of numbers than >>> the rationals, we can do that. We could, for example, compute >>> with continued fractions. Haskell makes that a small matter >>> of programming, and I expect someone has already done it. >>> >>> > So I guess phrased another way, a lot of the confusion / challenge in >>> writing floating point programs lies in understanding the representation, >>> its limits, and the ways in which it will implicitly manage that precision >>> tracking book keeping for you. >>> >>> Exactly so. There are even people who think the representation >>> is approximate instead of the operations! For things like >>> doubled-double, it really matters that the numbers are precise >>> and combine in predictable ways. >>> >>> Interestingly, while floating point addition and multiplication >>> are not associative, they are not wildly or erratically >>> non-associative, and it is possible to reason about the results >>> of operations. >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lane at s.eppa.la Thu Sep 25 19:55:17 2014 From: lane at s.eppa.la (Lane Seppala) Date: Thu, 25 Sep 2014 14:55:17 -0500 Subject: [Haskell-cafe] SIGVTALRM and Unbound threads Message-ID: Howdy, I've banged into this issue of FFI errors stemming from a C library improperly handling system call interrupts caused by the SIGVTALRM/SIGALRMs emitted by the Haskell runtime. Usually the 'proper' solution is to fix the C library?easier said than done for most C quagmires. The most popular workaround, described by Bryan O'Sullivan[1] and several others, is to block the culprit signals from reaching the FFI call. I found another workaround using unbound threads, and it seems to work generally for this problem. However, I'm not satisfied with my understanding about *why* it works given what I know about FFI, bound vs unbound threads, and sys calls. As the simplest example, compiled with the threaded runtime (and neglecting imports): main = void $ sleep 10 will be interrupted, whereas main = void $ runInUnboundThread $ sleep 10 will complete its 10 second sleep. How does running the FFI call on an unbound thread block SIGVTALRM or otherwise avoid the interrupt? My understanding is that these signals *should* reach the FFI process, since they're on the same OS thread the timers were set. Is there any danger to consider before saying that this is a viable workaround? Kindly, Lane [1]: http://www.serpentine.com/blog/2010/09/04/dealing-with-fragile-c-libraries-e-g-mysql-from-haskell/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Thu Sep 25 20:59:26 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 25 Sep 2014 16:59:26 -0400 Subject: [Haskell-cafe] SIGVTALRM and Unbound threads In-Reply-To: References: Message-ID: <5424822E.5010009@vex.net> On 14-09-25 03:55 PM, Lane Seppala wrote: > As the simplest example, compiled with the threaded runtime (and > neglecting imports): > > main = void $ sleep 10 > > will be interrupted, whereas > > main = void $ runInUnboundThread $ sleep 10 > > will complete its 10 second sleep. Before you commit to your understanding, consider one more experiment that changes everything: main = void $ runInUnboundThread (runInBoundThread $ sleep 10) Also, consider hitting CTRL-C (or sending SIGINT any way), see what does not happen. Do you want this behaviour? From lane at s.eppa.la Thu Sep 25 22:51:14 2014 From: lane at s.eppa.la (Lane Seppala) Date: Thu, 25 Sep 2014 17:51:14 -0500 Subject: [Haskell-cafe] SIGVTALRM and Unbound threads In-Reply-To: <5424822E.5010009@vex.net> References: <5424822E.5010009@vex.net> Message-ID: Hmm. Using your experiment, I didn't see any differing behavior from my original example (both GHC 7.6.3 and 7.8.3). What should I have expected? That being said, I hadn't tried sending SIGINT to the running process as you suggested. Thanks for this idea. Both for my example and yours, it takes two SIGINTs to kill the process. Interesting and surely not desired behavior, but I might not understand what the implications are. I ran each program with strace and sent SIGINTs to it while running. I found it interesting that each program had paused emitting SIGVTALRMs until I sent the first SIGINT, which then it resumed without interrupting the sleep. The second SIGINT exited the process. I'm even more curious &/ confused about the interaction of unbounded threads and signals now, or if there's any interaction at all. The pausing of the SIGVTALTRMs mentioned above makes me wonder whether it's the unbounded thread or some auxiliary mechanism that helps prevent interrupts. I'd love to have a deeper understanding of this interworking between signals and unbounded threads. My own web scouring hasn't turned up anything, but I'd be happy to be pointed somewhere. Kindly, Lane On Thu, Sep 25, 2014 at 3:59 PM, Albert Y. C. Lai wrote: > On 14-09-25 03:55 PM, Lane Seppala wrote: > >> As the simplest example, compiled with the threaded runtime (and >> neglecting imports): >> >> main = void $ sleep 10 >> >> will be interrupted, whereas >> >> main = void $ runInUnboundThread $ sleep 10 >> >> will complete its 10 second sleep. >> > > Before you commit to your understanding, consider one more experiment that > changes everything: > > main = void $ runInUnboundThread (runInBoundThread $ sleep 10) > > Also, consider hitting CTRL-C (or sending SIGINT any way), see what does > not happen. Do you want this behaviour? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Fri Sep 26 02:56:03 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Thu, 25 Sep 2014 21:56:03 -0500 Subject: [Haskell-cafe] Hackage bad gateway? Message-ID: Today (9/25/2014) Hackage is not reachable due to "bad gateway." Is there a status page? Thanks, Dominick From tonymorris at gmail.com Fri Sep 26 02:57:19 2014 From: tonymorris at gmail.com (Tony Morris) Date: Fri, 26 Sep 2014 12:57:19 +1000 Subject: [Haskell-cafe] Hackage bad gateway? In-Reply-To: References: Message-ID: <5424D60F.6050305@gmail.com> There is this: http://www.reddit.com/r/haskell/comments/2hh96i/note_hackage_is_down_disk_space_needs/ On 26/09/14 12:56, Dominick Samperi wrote: > Today (9/25/2014) Hackage is not reachable due to "bad gateway." > > Is there a status page? > > Thanks, > Dominick > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From clint at debian.org Fri Sep 26 02:57:41 2014 From: clint at debian.org (Clint Adams) Date: Fri, 26 Sep 2014 02:57:41 +0000 Subject: [Haskell-cafe] Hackage bad gateway? In-Reply-To: References: Message-ID: <20140926025741.GA26995@scru.org> On Thu, Sep 25, 2014 at 09:56:03PM -0500, Dominick Samperi wrote: > Today (9/25/2014) Hackage is not reachable due to "bad gateway." > > Is there a status page? http://status.haskell.org/ From rustompmody at gmail.com Fri Sep 26 03:57:08 2014 From: rustompmody at gmail.com (Rustom Mody) Date: Fri, 26 Sep 2014 09:27:08 +0530 Subject: [Haskell-cafe] What happened to hugs? In-Reply-To: <-3701248786196244697@unknownmsgid> References: <-3701248786196244697@unknownmsgid> Message-ID: On Thu, Sep 11, 2014 at 2:03 AM, Thorsten Rangwich wrote: > Hi, > > I suppose this question is not new, but neither google nor a manual search > file be file through the archives brought enlightement. > > www.haskell.org/hugs > > still exists, but none of the links there does work. Documentation and > source point to cvs.haskell.org ("server does not exist") and development > points to http://hackage.haskell.org/trac/hugs ("page does not exist"). > > Was it migrated to somewhere else or is it dead - in latter case the page > would not make sense any more. > > Sad that hugs links are now dead. There is still gofer (the predecessor to hugs). The original of Mark Jones and modifications made by me in the early 90s and the whys of these modifications are at http://blog.languager.org/2014/09/pugofer.html > "Raskell" (iPad app) provided a development environment usinh hugs, so I > would at least like to install hugs on my Mac as well... > Dont know about macs but last I knew it was compiling with gcc on linux (in all of 10 seconds!) -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Sep 26 04:04:57 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 26 Sep 2014 00:04:57 -0400 Subject: [Haskell-cafe] What happened to hugs? In-Reply-To: References: <-3701248786196244697@unknownmsgid> Message-ID: https://code.google.com/p/corehugs/ has some source snapshots of hugs if some brave person wants to resuscitate it :) On Thu, Sep 25, 2014 at 11:57 PM, Rustom Mody wrote: > > > On Thu, Sep 11, 2014 at 2:03 AM, Thorsten Rangwich < > trtoaster at googlemail.com> wrote: > >> Hi, >> >> I suppose this question is not new, but neither google nor a manual >> search file be file through the archives brought enlightement. >> >> www.haskell.org/hugs >> >> still exists, but none of the links there does work. Documentation and >> source point to cvs.haskell.org ("server does not exist") and >> development points to http://hackage.haskell.org/trac/hugs ("page does >> not exist"). >> >> Was it migrated to somewhere else or is it dead - in latter case the page >> would not make sense any more. >> >> > > Sad that hugs links are now dead. > > There is still gofer (the predecessor to hugs). > The original of Mark Jones and modifications made by me in the early 90s > and the whys of these modifications are at > http://blog.languager.org/2014/09/pugofer.html > > >> "Raskell" (iPad app) provided a development environment usinh hugs, so I >> would at least like to install hugs on my Mac as well... >> > > Dont know about macs but last I knew it was compiling with gcc on linux > (in all of 10 seconds!) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Fri Sep 26 04:11:01 2014 From: gershomb at gmail.com (Gershom B) Date: Fri, 26 Sep 2014 00:11:01 -0400 Subject: [Haskell-cafe] What happened to hugs? In-Reply-To: References: <-3701248786196244697@unknownmsgid> Message-ID: We know where the old contents of the hugs documentation and source are, and are going to get them back online sometime soon. They were the last remaining holdouts on a server hosted at galois that we decomissioned, and they were lost in the shuffle for a bit. Cheers, Gershom On September 26, 2014 at 12:05:37 AM, Carter Schonwald (carter.schonwald at gmail.com) wrote: > https://code.google.com/p/corehugs/ has some source snapshots of hugs if > some brave person wants to resuscitate it :) > > On Thu, Sep 25, 2014 at 11:57 PM, Rustom Mody wrote: > > > > > > > On Thu, Sep 11, 2014 at 2:03 AM, Thorsten Rangwich < > > trtoaster at googlemail.com> wrote: > > > >> Hi, > >> > >> I suppose this question is not new, but neither google nor a manual > >> search file be file through the archives brought enlightement. > >> > >> www.haskell.org/hugs > >> > >> still exists, but none of the links there does work. Documentation and > >> source point to cvs.haskell.org ("server does not exist") and > >> development points to http://hackage.haskell.org/trac/hugs ("page does > >> not exist"). > >> > >> Was it migrated to somewhere else or is it dead - in latter case the page > >> would not make sense any more. > >> > >> > > > > Sad that hugs links are now dead. > > > > There is still gofer (the predecessor to hugs). > > The original of Mark Jones and modifications made by me in the early 90s > > and the whys of these modifications are at > > http://blog.languager.org/2014/09/pugofer.html > > > > > >> "Raskell" (iPad app) provided a development environment usinh hugs, so I > >> would at least like to install hugs on my Mac as well... > >> > > > > Dont know about macs but last I knew it was compiling with gcc on linux > > (in all of 10 seconds!) > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From fuuzetsu at fuuzetsu.co.uk Fri Sep 26 06:25:44 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 26 Sep 2014 07:25:44 +0100 Subject: [Haskell-cafe] Hackage bad gateway? In-Reply-To: <5424D60F.6050305@gmail.com> References: <5424D60F.6050305@gmail.com> Message-ID: <542506E8.9060100@fuuzetsu.co.uk> On 09/26/2014 03:57 AM, Tony Morris wrote: > There is this: > > http://www.reddit.com/r/haskell/comments/2hh96i/note_hackage_is_down_disk_space_needs/ > > On 26/09/14 12:56, Dominick Samperi wrote: >> Today (9/25/2014) Hackage is not reachable due to "bad gateway." >> >> Is there a status page? >> >> Thanks, >> Dominick It'd be nice if such things went out to mailing lists/IRC channels rather than random comments on reddit that many people don't browse: it's not exactly an ?official? outlet? -- Mateusz K. From jjwchoy at gmail.com Fri Sep 26 10:33:01 2014 From: jjwchoy at gmail.com (Jason Choy) Date: Fri, 26 Sep 2014 11:33:01 +0100 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> Message-ID: On 25 September 2014 18:54, Carter Schonwald wrote: > No. It is associative, just not in the way you expect. ? >From What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg: "Due to roundoff errors, the associative laws of algebra do not necessarily hold for floating-point numbers. For example, the expression (x+y)+z has a totally different answer than x+(y+z) when x = 10^30, y = -10^30 and z = 1 (it is 1 in the former case, 0 in the latter)." On Thursday, September 25, 2014, Jason Choy wrote: > >> Thanks for the responses. >> >> I appreciate that floating point arithmetic is imprecise, and anyone >> using it should be aware of the ramifications, however it still feels >> strange to me that Sum Double claims to be a monoid. Is this is a case >> where convenience is favoured over correctness? Are there any other monoids >> with an "almost associative" binary operator? >> >> I think I would feel a little less uneasy if the types were called >> ImpreciseSum and ImpreciseProduct when it is not associative. >> >> >> On 23 September 2014 17:30, Carter Schonwald >> wrote: >> >>> well said and thanks for taking the time to clarify some of the >>> imprecision in what I was saying! >>> >>> On Tue, Sep 23, 2014 at 3:06 AM, Richard A. O'Keefe >>> wrote: >>> >>>> >>>> On 20/09/2014, at 5:26 AM, Carter Schonwald wrote: >>>> >>>> > Indeed, >>>> > >>>> > Also Floating point numbers are NOT real numbers, they are >>>> approximate points on the real line that we pretend are exact reals but >>>> really are a very different geometry all together! :) >>>> >>>> Floating point numbers are *PRECISE* numbers with >>>> approximate *OPERATIONS*. This is the way they are >>>> defined in the IEEE standard and its successors; >>>> this is the way they are defined in LIA-1 and its >>>> successors. If you do not understand that it is >>>> the OPERATIONS that are approximate, not the numbers, >>>> you have not yet begun to understand floating point >>>> arithmetic. >>>> >>>> > Floats and Doubles are not exact numbers, dont use them when you >>>> expect things to behave "exact". NB that even if you have *exact* numbers, >>>> the exact same precision issues will still apply to pretty much any >>>> computation thats interesting (ignoring what the definition of interesting >>>> is). Try defining things like \ x -> SquareRoot x or \x-> e^x on the >>>> rational numbers! Questions of precision still creep in! >>>> >>>> You're not talking about precision here but about >>>> approximation. And you can simply work with finite representations >>>> of algebraic numbers. I have a Smalltalk class that implements >>>> QuadraticSurds so that I can represent (1 + sqrt 5)/2 *exactly*. >>>> You can even compare QuadraticSurds with the same surd exactly. >>>> (This all works so much better in Haskell, where you can make >>>> the "5" part a type-level parameter.) >>>> >>>> Since e is not a rational number, it's not terribly interesting >>>> that e^x (usually) isn't when x is rational. >>>> >>>> If we want to compute with a richer range of numbers than >>>> the rationals, we can do that. We could, for example, compute >>>> with continued fractions. Haskell makes that a small matter >>>> of programming, and I expect someone has already done it. >>>> >>>> > So I guess phrased another way, a lot of the confusion / challenge in >>>> writing floating point programs lies in understanding the representation, >>>> its limits, and the ways in which it will implicitly manage that precision >>>> tracking book keeping for you. >>>> >>>> Exactly so. There are even people who think the representation >>>> is approximate instead of the operations! For things like >>>> doubled-double, it really matters that the numbers are precise >>>> and combine in predictable ways. >>>> >>>> Interestingly, while floating point addition and multiplication >>>> are not associative, they are not wildly or erratically >>>> non-associative, and it is possible to reason about the results >>>> of operations. >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Fri Sep 26 12:06:37 2014 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Sat, 27 Sep 2014 00:06:37 +1200 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> Message-ID: <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> On 26/09/2014, at 10:33 PM, Jason Choy wrote: > On 25 September 2014 18:54, Carter Schonwald wrote: > No. It is associative, just not in the way you expect. ? > > From What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg: "Due to roundoff errors, the associative laws of algebra do not necessarily hold for floating-point numbers. For example, the expression (x+y)+z has a totally different answer than x+(y+z) when x = 10^30, y = -10^30 and z = 1 (it is 1 in the former case, 0 in the latter)." Knuth Volume 2, second edition: (u [*] v) [*] w = uvw(1+d1)(1+d2) u [*] (v [*] w) = uvw(1+d3)(1+d4) where each |di| < 1/2 b**(1-p), so (u [*] v) [*] w --------------- = 1 + d u [*] (v [*] w) where |d| < 2 b**(1-p)/(1 - 1/2 b**(1-p))**2 = 2 ulp/(1 - 1/2 ulp)**2 subject to certain caveats. It's not unfair to say that floating point multiplication is (nearly) associative "within a few ulp". Goldberg's example involves addition, not multiplication. (Checking addition of numbers *with the same sign* is left as an exercise for the reader.) From jjwchoy at gmail.com Fri Sep 26 13:28:35 2014 From: jjwchoy at gmail.com (Jason Choy) Date: Fri, 26 Sep 2014 14:28:35 +0100 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> Message-ID: > > subject to certain caveats. It's not unfair to say that > floating point multiplication is (nearly) associative > "within a few ulp". > I'm not disputing this. However, you can't deny that this monoid law is broken for the floating point operations: mappend x (mappend y z) = mappend (mappend x y) z Perhaps I'm being pedantic, but this law should hold for all x, y, z, and it clearly doesn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Fri Sep 26 13:31:34 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 26 Sep 2014 09:31:34 -0400 Subject: [Haskell-cafe] What happened to hugs? Message-ID: <201409261331.s8QDVYPN010883@coolidge.cs.dartmouth.edu> > We know where the old contents of the hugs documentation and source are, > and are going to get them back online sometime soon. Welcome news! For my purposes, there is no substitute. GHCi's disregard for "default" is a fatal flaw. Doug McIlroy From trebla at vex.net Fri Sep 26 16:40:00 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Fri, 26 Sep 2014 12:40:00 -0400 Subject: [Haskell-cafe] SIGVTALRM and Unbound threads In-Reply-To: References: <5424822E.5010009@vex.net> Message-ID: <542596E0.6090308@vex.net> On 14-09-25 06:51 PM, Lane Seppala wrote: > Hmm. Using your experiment, I didn't see any differing behavior from my > original example (both GHC 7.6.3 and 7.8.3). What should I have expected? You should revise your theory. Hypothesis: C sleep in a bound thread quits prematurely. Experiment: Put C sleep in a bound thread, just not main's. Result: this C sleep in this bound thread does not quit prematurely. What does this tell us about the hypothesis? I'm doing the scientific method. From carter.schonwald at gmail.com Fri Sep 26 19:41:58 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 26 Sep 2014 15:41:58 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> Message-ID: for equational laws to be sensible requires a sensible notion of equality, the Eq for Floating point numbers is meant for handling corner cases (eg: am i about to divide by zero), not "semantic/denotational equivalence" Exact equality is fundamentally incorrect for finite precision mathematical computation. You typically want to have something like nearlyEq tolerance a b = if distance a b <= tolerance then True else False Floating point is geometry, not exact things https://hackage.haskell.org/package/ieee754-0.7.3/docs/Data-AEq.html is a package that provides an approx equality notion. Basically, floating points work the way they do because its a compromise that works decently for those who really need it. If you dont need to use floating point, dont! :) On Fri, Sep 26, 2014 at 9:28 AM, Jason Choy wrote: > subject to certain caveats. It's not unfair to say that >> floating point multiplication is (nearly) associative >> "within a few ulp". >> > > I'm not disputing this. > > However, you can't deny that this monoid law is broken for the floating > point operations: > > mappend x (mappend y z) = mappend (mappend x y) z > > Perhaps I'm being pedantic, but this law should hold for all x, y, z, and > it clearly doesn't. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Sep 26 19:55:44 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 26 Sep 2014 15:55:44 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> Message-ID: I guess what I'm saying is that while you have a valid perspective, such design changes don't really improve things for people who don't need floating point tools, and immediately makes things a lot more onerous for those who DO need them. I think a more interesting matter is the lack of good userland visiblility into choices of rounding modes and having nice tools for estimate forwards/backwards error of computations. Many computations (even with "exact") types, still have similar issues. But thats a fun topic about relative vs absolute error bounds etc that can wait for another time! :) On Fri, Sep 26, 2014 at 3:41 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > for equational laws to be sensible requires a sensible notion of equality, > the Eq for Floating point numbers is > meant for handling corner cases (eg: am i about to divide by zero), not > "semantic/denotational equivalence" > > Exact equality is fundamentally incorrect for finite precision > mathematical computation. > You typically want to have something like > > nearlyEq tolerance a b = if distance a b <= tolerance then True else False > > Floating point is geometry, not exact things > https://hackage.haskell.org/package/ieee754-0.7.3/docs/Data-AEq.html > is a package that provides an approx equality notion. > > Basically, floating points work the way they do because its a compromise > that works decently for those who really need it. > If you dont need to use floating point, dont! :) > > > > On Fri, Sep 26, 2014 at 9:28 AM, Jason Choy wrote: > >> subject to certain caveats. It's not unfair to say that >>> floating point multiplication is (nearly) associative >>> "within a few ulp". >>> >> >> I'm not disputing this. >> >> However, you can't deny that this monoid law is broken for the floating >> point operations: >> >> mappend x (mappend y z) = mappend (mappend x y) z >> >> Perhaps I'm being pedantic, but this law should hold for all x, y, z, and >> it clearly doesn't. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonslists at gmail.com Sat Sep 27 01:46:22 2014 From: noonslists at gmail.com (Noon Silk) Date: Sat, 27 Sep 2014 11:46:22 +1000 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> Message-ID: > for equational laws to be sensible requires a sensible notion of equality, > the Eq for Floating point numbers is could it not be then that for floating points to be a monoid you must specify a satisfying notion of equality? (well, i guess nothing is stopping anyone from doing that themselves; and your point is that simply not having floats as a monoid is somehow "bad"?) On Sat, Sep 27, 2014 at 5:41 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > for equational laws to be sensible requires a sensible notion of equality, > the Eq for Floating point numbers is > meant for handling corner cases (eg: am i about to divide by zero), not > "semantic/denotational equivalence" > > Exact equality is fundamentally incorrect for finite precision > mathematical computation. > You typically want to have something like > > nearlyEq tolerance a b = if distance a b <= tolerance then True else False > > Floating point is geometry, not exact things > https://hackage.haskell.org/package/ieee754-0.7.3/docs/Data-AEq.html > is a package that provides an approx equality notion. > > Basically, floating points work the way they do because its a compromise > that works decently for those who really need it. > If you dont need to use floating point, dont! :) > > > > On Fri, Sep 26, 2014 at 9:28 AM, Jason Choy wrote: > >> subject to certain caveats. It's not unfair to say that >>> floating point multiplication is (nearly) associative >>> "within a few ulp". >>> >> >> I'm not disputing this. >> >> However, you can't deny that this monoid law is broken for the floating >> point operations: >> >> mappend x (mappend y z) = mappend (mappend x y) z >> >> Perhaps I'm being pedantic, but this law should hold for all x, y, z, and >> it clearly doesn't. >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Noon Silk, ? https://sites.google.com/site/noonsilk/ "Every morning when I wake up, I experience an exquisite joy ? the joy of being this signature." -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Sep 27 03:38:03 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 26 Sep 2014 23:38:03 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> Message-ID: For anything to be a Monoid (or any type class with laws), you implicitly have a definition of equivalence you want your laws to use. And for many classes, those laws are using an equivalence not definable using Eq. A good example Is monad! You can not define Eq instances for arbitrary a-> m b. We can still define and talk about lawful monads. Point of order though, no Num a instance has a Monoid a instance. Instead Sum a and Product a are the Monoid Instances. On Sep 26, 2014 9:46 PM, "Noon Silk" wrote: > > for equational laws to be sensible requires a sensible notion of > equality, > > the Eq for Floating point numbers is > > could it not be then that for floating points to be a monoid you must > specify a satisfying notion of equality? (well, i guess nothing is stopping > anyone from doing that themselves; and your point is that simply not having > floats as a monoid is somehow "bad"?) > > > > On Sat, Sep 27, 2014 at 5:41 AM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> for equational laws to be sensible requires a sensible notion of >> equality, the Eq for Floating point numbers is >> meant for handling corner cases (eg: am i about to divide by zero), not >> "semantic/denotational equivalence" >> >> Exact equality is fundamentally incorrect for finite precision >> mathematical computation. >> You typically want to have something like >> >> nearlyEq tolerance a b = if distance a b <= tolerance then True else >> False >> >> Floating point is geometry, not exact things >> https://hackage.haskell.org/package/ieee754-0.7.3/docs/Data-AEq.html >> is a package that provides an approx equality notion. >> >> Basically, floating points work the way they do because its a compromise >> that works decently for those who really need it. >> If you dont need to use floating point, dont! :) >> >> >> >> On Fri, Sep 26, 2014 at 9:28 AM, Jason Choy wrote: >> >>> subject to certain caveats. It's not unfair to say that >>>> floating point multiplication is (nearly) associative >>>> "within a few ulp". >>>> >>> >>> I'm not disputing this. >>> >>> However, you can't deny that this monoid law is broken for the floating >>> point operations: >>> >>> mappend x (mappend y z) = mappend (mappend x y) z >>> >>> Perhaps I'm being pedantic, but this law should hold for all x, y, z, >>> and it clearly doesn't. >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > -- > Noon Silk, ? > > https://sites.google.com/site/noonsilk/ > > "Every morning when I wake up, I experience an exquisite joy ? the joy > of being this signature." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat Sep 27 09:13:45 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 27 Sep 2014 10:13:45 +0100 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> Message-ID: <20140927091345.GF20195@weber> On Fri, Sep 26, 2014 at 11:38:03PM -0400, Carter Schonwald wrote: > For anything to be a Monoid (or any type class with laws), you implicitly > have a definition of equivalence you want your laws to use. And for many > classes, those laws are using an equivalence not definable using Eq. A > good example Is monad! You can not define Eq instances for arbitrary a-> m > b. We can still define and talk about lawful monads. Definable in Haskell or not, this supposed fuzzy equality for Double won't be transitive will it? It sounds like it will just raise another problem. Tom From hjgtuyl at chello.nl Sat Sep 27 11:39:26 2014 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 27 Sep 2014 13:39:26 +0200 Subject: [Haskell-cafe] foreign ccall export / ghc 7.6.3 In-Reply-To: <20140923173143.GA28096@scru.org> References: <20140923173143.GA28096@scru.org> Message-ID: On Tue, 23 Sep 2014 19:31:43 +0200, Clint Adams wrote: > Are there examples of "foreign ccall export" that work with GHC > 7.6.3? The example at http://www.haskell.org/haskellwiki/Calling_Haskell_from_C works with GHC 7.8.3 Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From hoerdegen at funktional.info Sat Sep 27 12:46:08 2014 From: hoerdegen at funktional.info (=?ISO-8859-15?Q?Heinrich_H=F6rdegen?=) Date: Sat, 27 Sep 2014 14:46:08 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting Message-ID: <5426B190.4040107@funktional.info> Dear all, our next Haskell meeting in Munich takes place at Cafe Puck at 19h30 on Mon, 29th of September. Please go to http://www.haskell-munich.de/dates and click the button if you plan to join. Everyone is welcome! Heinrich From carter.schonwald at gmail.com Sat Sep 27 14:02:29 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 27 Sep 2014 10:02:29 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: <20140927091345.GF20195@weber> References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> <20140927091345.GF20195@weber> Message-ID: Its approximately transitive. Distances always obey the triangle Inequality. Good enough for geometry. Also the emphasis is on the geometry / distance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Sat Sep 27 17:12:30 2014 From: trebla at vex.net (Albert Y. C. Lai) Date: Sat, 27 Sep 2014 13:12:30 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> <20140927091345.GF20195@weber> Message-ID: <5426EFFE.4040408@vex.net> On 14-09-27 10:02 AM, Carter Schonwald wrote: > Its approximately transitive. Distances always obey the triangle > Inequality. Good enough for geometry. Also the emphasis is on the > geometry / distance. You've got me curious. How do we define "approximately transitive"? (I am not one of those who want to rid floating point of Eq and Ord, or rid of floating point altogether.) From carter.schonwald at gmail.com Sat Sep 27 19:36:56 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 27 Sep 2014 15:36:56 -0400 Subject: [Haskell-cafe] Sum and Product do not respect the Monoid laws In-Reply-To: <5426EFFE.4040408@vex.net> References: <4CB9EAE4-9D00-4259-9E96-BD200BC27F8C@cs.otago.ac.nz> <15D7C726-B81A-45E5-9733-85C21C60CC95@cs.otago.ac.nz> <20140927091345.GF20195@weber> <5426EFFE.4040408@vex.net> Message-ID: To replicate the explanation i gave on IRC, (to use subscripting in pseudo haskell) for any type where we can define some sort of distance (induced via a norm via dist a b = norm (a -b ), ignoring overflow issues) lets define a quantitative version of equality a ==_{r} b = if dist a b <= r then True else False then we use the triangle inequality (dist a c <= dist a b + dist b c) to get the following quantitative analogue of transitivity a ==_{r1} b && b ==_{r2} c IMPLIES a ==_{r1 + r2} c this is a bit more general (and weaker) than the notion of equality that we're accustomed to, but still a pretty natural idea. you can consider more general things than using the + function too, like min/max/sum of squares etc. But I leave that as a fun exercise for the reader. this gets into talking about reasoning about things using tools from Analysis rather than Algebra, and that sort of modeling is pretty powerful. http://en.wikipedia.org/wiki/Normed_vector_space and the associated page on Hilber tSpaces can be a useful starting point i guess. I guess my point is Analysis is a very powerful far reaching mathematical tool, and only considering models that elide that is ... :) On Sat, Sep 27, 2014 at 1:12 PM, Albert Y. C. Lai wrote: > On 14-09-27 10:02 AM, Carter Schonwald wrote: > >> Its approximately transitive. Distances always obey the triangle >> Inequality. Good enough for geometry. Also the emphasis is on the >> geometry / distance. >> > > You've got me curious. How do we define "approximately transitive"? > > (I am not one of those who want to rid floating point of Eq and Ord, or > rid of floating point altogether.) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkscrg at gmail.com Sat Sep 27 21:54:09 2014 From: mkscrg at gmail.com (Mike Craig) Date: Sat, 27 Sep 2014 14:54:09 -0700 Subject: [Haskell-cafe] Cabal Testing Pain Message-ID: Hey all, I'm trying to setup an executable cabal project, the options for cabal-based testing seem poor. I poked around for discussions of this but didn't find much. My apologies if I'm beating a dead horse. The current options, as I understand them, are 1. Split code into library, executable, and test-suite. This gets you single compilation but you have to list every source file in the library's exposed/other-modules sections. 2. Split code into executable and test-suite. You don't have to list the source files, but you get double compilation and you have to declare every dependency (and version!) twice. Am I missing a third (better) option, or is this the state of things? -- Mike Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Sep 27 22:17:31 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 27 Sep 2014 18:17:31 -0400 Subject: [Haskell-cafe] Cabal Testing Pain In-Reply-To: References: Message-ID: You always have to list the other modules AFAIK, otherwise cabal sdist won't copy them! (Or at least I can't imagine why that wouldn't be the case when writing an application. ) On Sep 27, 2014 5:54 PM, "Mike Craig" wrote: > Hey all, I'm trying to setup an executable cabal project, the options for > cabal-based testing seem poor. I poked around for discussions of this but > didn't find much. My apologies if I'm beating a dead horse. > > The current options, as I understand them, are > > 1. Split code into library, executable, and test-suite. This gets you > single compilation but you have to list every source file in the library's > exposed/other-modules sections. > 2. Split code into executable and test-suite. You don't have to list the > source files, but you get double compilation and you have to declare every > dependency (and version!) twice. > > Am I missing a third (better) option, or is this the state of things? > > -- > Mike Craig > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob at stanley.io Sat Sep 27 23:49:29 2014 From: jacob at stanley.io (Jacob Stanley) Date: Sun, 28 Sep 2014 09:49:29 +1000 Subject: [Haskell-cafe] Deploying bash completion with cabal? Message-ID: Hi All I'm looking for a good way to deploy a bash completion script somewhere appropriate for the given operating system. Has anyone tackled this before? I was considering packaging the script in to the install using cabal data files, then having an 'install--bash-completion' option that tries to detect the right place to install it depending on the OS. Cheers Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Sun Sep 28 00:42:26 2014 From: djsamperi at gmail.com (Dominick Samperi) Date: Sat, 27 Sep 2014 20:42:26 -0400 Subject: [Haskell-cafe] Debugging with ghci Message-ID: For a long time I've worked under the assumption that a breakpoint can only be used once in a ghci session, because if you run the function (main say) again, it runs to completion, ignoring the breakpoint. Restarting ghci and resetting the break point resolves the problem, but does not explain why a breakpoint cannot be used more than once. How can this behavior be explained? Also, when I stop at a breakpoint :step works as expected, but :trace does not? It simply runs the rest of the function, and using :back subsequently results in the message "not stopped at a breakpoint." Any comments on this behavior? Thanks, Dominick From u3502350 at connect.hku.hk Sun Sep 28 07:42:01 2014 From: u3502350 at connect.hku.hk (PENG, BO YA) Date: Sun, 28 Sep 2014 15:42:01 +0800 Subject: [Haskell-cafe] Arrow key functionality for REPL written in Haskell Message-ID: Hi, I'm trying to implement the arrow key functionality for a systemf REPL to recall previously entered lines. I think I should save the previous lines in a list and then traverse through the list when an arrow key is pressed, but I'm no sure how to detect an arrow key and implement this functionality. Can anyone give a brief description about the implementation or point me to some other resources? Thanks! Emma -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickolay.kudasov at gmail.com Sun Sep 28 08:00:58 2014 From: nickolay.kudasov at gmail.com (Nickolay Kudasov) Date: Sun, 28 Sep 2014 12:00:58 +0400 Subject: [Haskell-cafe] =?utf-8?q?=5BANN=5D_lxc-0=2E2_and_bindings-0=2E2_?= =?utf-8?q?=E2=80=93_Haskell_LXC_API_bindings?= Message-ID: Greetings, I am pleased to announce the Haskell LXC API bindings. Bindings are represented by 2 cabal packages: lxc and bindings-lxc. LXC is a userspace interface for the Linux kernel containment features. For more information see https://linuxcontainers.org. http://hackage.haskell.org/package/lxc High level Haskell bindings to LXC (Linux containers). Git repository: https://github.com/fizruk/lxc http://hackage.haskell.org/package/bindings-lxc Direct Haskell bindings to LXC (Linux containers) C API. Git repository: https://github.com/fizruk/bindings-lxc === Before installation make sure you have LXC installed on your system with header files and static library. Packages have been tested with Ubuntu 12.04 and 14.04. On Ubuntu 14.04 LTS (Trusty Tahr): $ sudo apt-get install lxc-dev On previous Ubuntu versions (including 12.04 LTS Precise Pangolin) standard repositories do not contain liblxc1 package. You might want to use ppa:ubuntu-lxc/stable repository instead: $ sudo apt-get install software-properties-common python-software-properties $ sudo add-apt-repository ppa:ubuntu-lxc/stable $ sudo apt-get update $ sudo apt-get install lxc-dev === To get the latest stable version of both packages: $ cabal install lxc === While Haddock documentation is absent one can either build haddock documentation locally or view it online on GitHub Pages: lxc documentation: http://fizruk.github.io/lxc/docs/ bindings-lxc documentation: http://fizruk.github.io/bindings-lxc/docs/ See also Usage section of lxc package README file: https://github.com/fizruk/lxc/blob/master/README.md#usage === Feedback of any kind is welcome! Cheers, Nickolay Kudasov -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis.cardwell at extellisys.com Sun Sep 28 08:43:41 2014 From: travis.cardwell at extellisys.com (Travis Cardwell) Date: Sun, 28 Sep 2014 17:43:41 +0900 Subject: [Haskell-cafe] Arrow key functionality for REPL written in Haskell In-Reply-To: References: Message-ID: <5427CA3D.8030700@extellisys.com> On 2014?09?28? 16:42, PENG, BO YA wrote: > I'm trying to implement the arrow key functionality for a systemf REPL to > recall previously entered lines. I think I should save the previous lines > in a list and then traverse through the list when an arrow key is pressed, > but I'm no sure how to detect an arrow key and implement this functionality. > Can anyone give a brief description about the implementation or point me to > some other resources? > Thanks! Perhaps readline would work for you? http://hackage.haskell.org/package/readline Cheers, Travis From fuuzetsu at fuuzetsu.co.uk Sun Sep 28 09:01:14 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sun, 28 Sep 2014 10:01:14 +0100 Subject: [Haskell-cafe] Arrow key functionality for REPL written in Haskell In-Reply-To: <5427CA3D.8030700@extellisys.com> References: <5427CA3D.8030700@extellisys.com> Message-ID: <5427CE5A.9030605@fuuzetsu.co.uk> On 09/28/2014 09:43 AM, Travis Cardwell wrote: > On 2014?09?28? 16:42, PENG, BO YA wrote: >> I'm trying to implement the arrow key functionality for a systemf REPL to >> recall previously entered lines. I think I should save the previous lines >> in a list and then traverse through the list when an arrow key is pressed, >> but I'm no sure how to detect an arrow key and implement this functionality. >> Can anyone give a brief description about the implementation or point me to >> some other resources? >> Thanks! > > Perhaps readline would work for you? > > http://hackage.haskell.org/package/readline > > Cheers, > > Travis > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > For keeping track itself, you can use something like a pointed list[1] pretty easily which frees you from having to keep track of indexes, looping around, going back and forth &c. I use it for quick-and-dirty selection in a menu in the game I'm writing. Once you have a way to get key presses, it becomes trivial (+ some lenses for clarity): whenM (keyPress KeyUp) $ screenState . maps %= C.previous whenM (keyPress KeyDown) $ screenState . maps %= C.next where ?maps? is my PointedList and C is Data.List.Pointed.Circular. [1]: http://hackage.haskell.org/package/pointedlist -- Mateusz K. From u3502350 at connect.hku.hk Sun Sep 28 09:15:39 2014 From: u3502350 at connect.hku.hk (Emma Peng) Date: Sun, 28 Sep 2014 02:15:39 -0700 (PDT) Subject: [Haskell-cafe] Arrow key functionality for REPL written in Haskell In-Reply-To: <5427CE5A.9030605@fuuzetsu.co.uk> References: <5427CA3D.8030700@extellisys.com> <5427CE5A.9030605@fuuzetsu.co.uk> Message-ID: Hi Travis & Mateusz, Thanks for your advice! However I just found out that I didn't need to implement this functionality by hand since Haskeline does exactly what I need... Cheers, Emma On Sunday, September 28, 2014 5:01:30 PM UTC+8, Mateusz Kowalczyk wrote: > > On 09/28/2014 09:43 AM, Travis Cardwell wrote: > > On 2014?09?28? 16:42, PENG, BO YA wrote: > >> I'm trying to implement the arrow key functionality for a systemf REPL > to > >> recall previously entered lines. I think I should save the previous > lines > >> in a list and then traverse through the list when an arrow key is > pressed, > >> but I'm no sure how to detect an arrow key and implement this > functionality. > >> Can anyone give a brief description about the implementation or point > me to > >> some other resources? > >> Thanks! > > > > Perhaps readline would work for you? > > > > http://hackage.haskell.org/package/readline > > > > Cheers, > > > > Travis > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskel... at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > For keeping track itself, you can use something like a pointed list[1] > pretty easily which frees you from having to keep track of indexes, > looping around, going back and forth &c. I use it for quick-and-dirty > selection in a menu in the game I'm writing. Once you have a way to get > key presses, it becomes trivial (+ some lenses for clarity): > > whenM (keyPress KeyUp) $ screenState . maps %= C.previous > whenM (keyPress KeyDown) $ screenState . maps %= C.next > > where ?maps? is my PointedList and C is Data.List.Pointed.Circular. > > [1]: http://hackage.haskell.org/package/pointedlist > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From u3502350 at connect.hku.hk Sun Sep 28 09:15:39 2014 From: u3502350 at connect.hku.hk (Emma Peng) Date: Sun, 28 Sep 2014 02:15:39 -0700 (PDT) Subject: [Haskell-cafe] Arrow key functionality for REPL written in Haskell In-Reply-To: <5427CE5A.9030605@fuuzetsu.co.uk> References: <5427CA3D.8030700@extellisys.com> <5427CE5A.9030605@fuuzetsu.co.uk> Message-ID: Hi Travis & Mateusz, Thanks for your advice! However I just found out that I didn't need to implement this functionality by hand since Haskeline does exactly what I need... Cheers, Emma On Sunday, September 28, 2014 5:01:30 PM UTC+8, Mateusz Kowalczyk wrote: > > On 09/28/2014 09:43 AM, Travis Cardwell wrote: > > On 2014?09?28? 16:42, PENG, BO YA wrote: > >> I'm trying to implement the arrow key functionality for a systemf REPL > to > >> recall previously entered lines. I think I should save the previous > lines > >> in a list and then traverse through the list when an arrow key is > pressed, > >> but I'm no sure how to detect an arrow key and implement this > functionality. > >> Can anyone give a brief description about the implementation or point > me to > >> some other resources? > >> Thanks! > > > > Perhaps readline would work for you? > > > > http://hackage.haskell.org/package/readline > > > > Cheers, > > > > Travis > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskel... at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > For keeping track itself, you can use something like a pointed list[1] > pretty easily which frees you from having to keep track of indexes, > looping around, going back and forth &c. I use it for quick-and-dirty > selection in a menu in the game I'm writing. Once you have a way to get > key presses, it becomes trivial (+ some lenses for clarity): > > whenM (keyPress KeyUp) $ screenState . maps %= C.previous > whenM (keyPress KeyDown) $ screenState . maps %= C.next > > where ?maps? is my PointedList and C is Data.List.Pointed.Circular. > > [1]: http://hackage.haskell.org/package/pointedlist > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at hupel.info Sun Sep 28 11:56:43 2014 From: lars at hupel.info (Lars Hupel) Date: Sun, 28 Sep 2014 13:56:43 +0200 Subject: [Haskell-cafe] Separate compilation In-Reply-To: References: <5422AFB6.2020109@hupel.info> Message-ID: <5427F77B.1050102@hupel.info> Hi, > add an extra step for linking, like this: 'ghc -o Foo *.o' that did the trick. Thanks! Lars From hesselink at gmail.com Sun Sep 28 12:11:52 2014 From: hesselink at gmail.com (Erik Hesselink) Date: Sun, 28 Sep 2014 14:11:52 +0200 Subject: [Haskell-cafe] Deploying bash completion with cabal? In-Reply-To: References: Message-ID: That sounds like a solution that would work. An alternative is to use the hooks available in cabal to install the completion file immediately on 'cabal install'. See the cabal docs [1] for more details. The downside is that you don't have a way to specify dependencies for your Setup.hs [2], so the hooks have to be pretty simple (you can basically only use base and ghc's bootlibs reliably). Regards, Erik [1] http://hackage.haskell.org/package/Cabal-1.20.0.2/docs/Distribution-Simple.html [2] https://github.com/haskell/cabal/issues/948 On Sun, Sep 28, 2014 at 1:49 AM, Jacob Stanley wrote: > Hi All > > I'm looking for a good way to deploy a bash completion script somewhere > appropriate for the given operating system. > > Has anyone tackled this before? I was considering packaging the script in to > the install using cabal data files, then having an > 'install--bash-completion' option that tries to detect the right place to > install it depending on the OS. > > Cheers > Jacob > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dburke.gw at gmail.com Sun Sep 28 14:25:37 2014 From: dburke.gw at gmail.com (Doug Burke) Date: Sun, 28 Sep 2014 10:25:37 -0400 Subject: [Haskell-cafe] Cabal Testing Pain In-Reply-To: References: Message-ID: Just to comment on your "have to declare every dependency and version twice" point. You don't need to have the version information listed in the test section, since you've already defined your constraints in the library section. You can also list your package as a dependency for the test suite, which can remove a lot of repeated dependencies (although that depends very-much on what sort of interface your library exposes). So you can get away with name: bob Library Build-Depends: base >= 3, conduit < 0.99, pipes > 47.2, text == 0.1.2.3 ... Test-Suite test-bob1 Build-Depends: base, bob, text, tasty, tasty-hunit == 0.9.* ... Test-Suite test-bob2 Build-Depends: base, bob, text, conduit ... Or at least that's my understanding/how I use it - e.g. https://bitbucket.org/doug_burke/swish/src/28b828bc806d8c1e66a06c3dceb92ae165bfe543/swish.cabal?at=default HTH, Doug On Sat, Sep 27, 2014 at 5:54 PM, Mike Craig wrote: > Hey all, I'm trying to setup an executable cabal project, the options for > cabal-based testing seem poor. I poked around for discussions of this but > didn't find much. My apologies if I'm beating a dead horse. > > The current options, as I understand them, are > > 1. Split code into library, executable, and test-suite. This gets you > single compilation but you have to list every source file in the library's > exposed/other-modules sections. > 2. Split code into executable and test-suite. You don't have to list the > source files, but you get double compilation and you have to declare every > dependency (and version!) twice. > > Am I missing a third (better) option, or is this the state of things? > > -- > Mike Craig > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bneijt at gmail.com Sun Sep 28 15:45:42 2014 From: bneijt at gmail.com (Bram Neijt) Date: Sun, 28 Sep 2014 17:45:42 +0200 Subject: [Haskell-cafe] Cabal Testing Pain In-Reply-To: References: Message-ID: I have head the same experience. Splitting the main code into a library seems like a good thing to do. For example, my main executable depends on the options package for option parsing, while the rest of the code (library part) does not. So I'm now in favour of splitting the code up. However having to expose every source file you use seems stupid to me as well. There is talk on the internet[2] saying that cabal init could find the listing (which would allow for a scripted update of the list) but when I use it on my source[1] it finds to many modules (rm after.cabal; cabal init -n --is-library --source-dir=src/lib) If you find a solution to that problem please consider mailing me directly because I have been looking for this. Greetings, Bram [1] https://github.com/bneijt/after [2] https://stackoverflow.com/questions/18084265/cabal-expose-all-modules-while-building-library On Sun, Sep 28, 2014 at 12:17 AM, Carter Schonwald wrote: > You always have to list the other modules AFAIK, otherwise cabal sdist won't > copy them! (Or at least I can't imagine why that wouldn't be the case when > writing an application. ) > > On Sep 27, 2014 5:54 PM, "Mike Craig" wrote: >> >> Hey all, I'm trying to setup an executable cabal project, the options for >> cabal-based testing seem poor. I poked around for discussions of this but >> didn't find much. My apologies if I'm beating a dead horse. >> >> The current options, as I understand them, are >> >> 1. Split code into library, executable, and test-suite. This gets you >> single compilation but you have to list every source file in the library's >> exposed/other-modules sections. >> 2. Split code into executable and test-suite. You don't have to list the >> source files, but you get double compilation and you have to declare every >> dependency (and version!) twice. >> >> Am I missing a third (better) option, or is this the state of things? >> >> -- >> Mike Craig >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From briand at aracnet.com Sun Sep 28 19:55:53 2014 From: briand at aracnet.com (briand at aracnet.com) Date: Sun, 28 Sep 2014 12:55:53 -0700 Subject: [Haskell-cafe] the complex package is hidden Message-ID: <20140928125553.75c56b19@pebble.deldotd.com> Hi, surprisingly i can't seem to google an answer to this: Could not find module `Complex' It is a member of the hidden package `haskell98-2.0.0.2'. Use -v to see a list of the files searched for. it's been quite a while since I've used ghci, and I'm just about positive I've solved this problem before, but can't seem to figure it out. Thanks for any help. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Sep 28 19:58:42 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 28 Sep 2014 20:58:42 +0100 Subject: [Haskell-cafe] the complex package is hidden In-Reply-To: <20140928125553.75c56b19@pebble.deldotd.com> References: <20140928125553.75c56b19@pebble.deldotd.com> Message-ID: <20140928195842.GL20195@weber> On Sun, Sep 28, 2014 at 12:55:53PM -0700, briand at aracnet.com wrote: > surprisingly i can't seem to google an answer to this: > > Could not find module `Complex' > It is a member of the hidden package `haskell98-2.0.0.2'. > Use -v to see a list of the files searched for. I believe `Complex` was renamed `Data.Complex`. From briand at aracnet.com Sun Sep 28 20:38:55 2014 From: briand at aracnet.com (briand at aracnet.com) Date: Sun, 28 Sep 2014 13:38:55 -0700 Subject: [Haskell-cafe] the complex package is hidden In-Reply-To: <20140928195842.GL20195@weber> References: <20140928125553.75c56b19@pebble.deldotd.com> <20140928195842.GL20195@weber> Message-ID: <20140928133855.3c4150db@pebble.deldotd.com> On Sun, 28 Sep 2014 20:58:42 +0100 Tom Ellis wrote: > On Sun, Sep 28, 2014 at 12:55:53PM -0700, briand at aracnet.com wrote: > > surprisingly i can't seem to google an answer to this: > > > > Could not find module `Complex' > > It is a member of the hidden package `haskell98-2.0.0.2'. > > Use -v to see a list of the files searched for. > > I believe `Complex` was renamed `Data.Complex`. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe aha. i thought it was something like that. But there's a bit of a weirdness. Prelude> import Data.Complex Prelude Data.Complex> :browse data Complex a = !a :+ !a cis :: RealFloat a => a -> Complex a conjugate :: RealFloat a => Complex a -> Complex a imagPart :: RealFloat a => Complex a -> a magnitude :: RealFloat a => Complex a -> a mkPolar :: RealFloat a => a -> a -> Complex a phase :: RealFloat a => Complex a -> a polar :: RealFloat a => Complex a -> (a, a) realPart :: RealFloat a => Complex a -> a Prelude Data.Complex> So that works, but import Data.Complex in my code does _not_ work. btw. ghc 7.6.1. Thanks, Brian From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Sep 28 20:46:22 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 28 Sep 2014 21:46:22 +0100 Subject: [Haskell-cafe] the complex package is hidden In-Reply-To: <20140928133855.3c4150db@pebble.deldotd.com> References: <20140928125553.75c56b19@pebble.deldotd.com> <20140928195842.GL20195@weber> <20140928133855.3c4150db@pebble.deldotd.com> Message-ID: <20140928204622.GM20195@weber> On Sun, Sep 28, 2014 at 01:38:55PM -0700, briand at aracnet.com wrote: > On Sun, 28 Sep 2014 20:58:42 +0100 > Tom Ellis wrote: > > On Sun, Sep 28, 2014 at 12:55:53PM -0700, briand at aracnet.com wrote: > > > surprisingly i can't seem to google an answer to this: > > > > > > Could not find module `Complex' > > > It is a member of the hidden package `haskell98-2.0.0.2'. > > > Use -v to see a list of the files searched for. > > > > I believe `Complex` was renamed `Data.Complex`. > > aha. i thought it was something like that. > > But there's a bit of a weirdness. > > Prelude> import Data.Complex > Prelude Data.Complex> :browse > data Complex a = !a :+ !a > cis :: RealFloat a => a -> Complex a > conjugate :: RealFloat a => Complex a -> Complex a > imagPart :: RealFloat a => Complex a -> a > magnitude :: RealFloat a => Complex a -> a > mkPolar :: RealFloat a => a -> a -> Complex a > phase :: RealFloat a => Complex a -> a > polar :: RealFloat a => Complex a -> (a, a) > realPart :: RealFloat a => Complex a -> a > Prelude Data.Complex> > > So that works, but > > import Data.Complex > > in my code does _not_ work. > > btw. ghc 7.6.1. So what's the error message? From briand at aracnet.com Sun Sep 28 20:56:48 2014 From: briand at aracnet.com (briand at aracnet.com) Date: Sun, 28 Sep 2014 13:56:48 -0700 Subject: [Haskell-cafe] the complex package is hidden In-Reply-To: <20140928204622.GM20195@weber> References: <20140928125553.75c56b19@pebble.deldotd.com> <20140928195842.GL20195@weber> <20140928133855.3c4150db@pebble.deldotd.com> <20140928204622.GM20195@weber> Message-ID: <20140928135648.6220bb77@pebble.deldotd.com> On Sun, 28 Sep 2014 21:46:22 +0100 Tom Ellis wrote: > On Sun, Sep 28, 2014 at 01:38:55PM -0700, briand at aracnet.com wrote: > > On Sun, 28 Sep 2014 20:58:42 +0100 > > Tom Ellis wrote: > > > On Sun, Sep 28, 2014 at 12:55:53PM -0700, briand at aracnet.com wrote: > > > > surprisingly i can't seem to google an answer to this: > > > > > > > > Could not find module `Complex' > > > > It is a member of the hidden package `haskell98-2.0.0.2'. > > > > Use -v to see a list of the files searched for. > > > > > So what's the error message? yes. well it pays to read carefully. once i fixed it in the top level module another module also be called had the wrong import, i didn't notice that at first, thought i had the same error. well i did, but in a different file. all fixed and i'm good to go. thanks for your help ! p.s. is there documentation that makes it clear that Data.Complex is required ? I'm looking at the haskell hierarchial libraries and it's not at all obvious that Complex comes under Data. Here's the link I'm using: http://www.haskell.org/ghc/docs/latest/html/libraries/ Brian From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Sep 28 20:59:40 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 28 Sep 2014 21:59:40 +0100 Subject: [Haskell-cafe] the complex package is hidden In-Reply-To: <20140928135648.6220bb77@pebble.deldotd.com> References: <20140928125553.75c56b19@pebble.deldotd.com> <20140928195842.GL20195@weber> <20140928133855.3c4150db@pebble.deldotd.com> <20140928204622.GM20195@weber> <20140928135648.6220bb77@pebble.deldotd.com> Message-ID: <20140928205940.GN20195@weber> On Sun, Sep 28, 2014 at 01:56:48PM -0700, briand at aracnet.com wrote: > On Sun, 28 Sep 2014 21:46:22 +0100 > Tom Ellis wrote: > > > On Sun, Sep 28, 2014 at 01:38:55PM -0700, briand at aracnet.com wrote: > > > On Sun, 28 Sep 2014 20:58:42 +0100 > > > Tom Ellis wrote: > > > > On Sun, Sep 28, 2014 at 12:55:53PM -0700, briand at aracnet.com wrote: > > > > > surprisingly i can't seem to google an answer to this: > > > > > > > > > > Could not find module `Complex' > > > > > It is a member of the hidden package `haskell98-2.0.0.2'. > > > > > Use -v to see a list of the files searched for. > > > > > > > > So what's the error message? > > yes. well it pays to read carefully. > > once i fixed it in the top level module another module also be called had the wrong import, i didn't notice that at first, thought i had the same error. well i did, but in a different file. > > all fixed and i'm good to go. > > thanks for your help ! > > p.s. is there documentation that makes it clear that Data.Complex is required ? > > I'm looking at the haskell hierarchial libraries and it's not at all obvious that Complex comes under Data. Here's the link I'm using: > > http://www.haskell.org/ghc/docs/latest/html/libraries/ Glad you got it sorted! Complex is mentioned there because it is still around for compatibility with Haskell 98, but it's not enabled by default. You'll also see Data.Complex in that list. Arguably there should be a warning on the page of the former to use the latter instead. Tom From briand at aracnet.com Sun Sep 28 21:08:30 2014 From: briand at aracnet.com (briand at aracnet.com) Date: Sun, 28 Sep 2014 14:08:30 -0700 Subject: [Haskell-cafe] the complex package is hidden In-Reply-To: <20140928205940.GN20195@weber> References: <20140928125553.75c56b19@pebble.deldotd.com> <20140928195842.GL20195@weber> <20140928133855.3c4150db@pebble.deldotd.com> <20140928204622.GM20195@weber> <20140928135648.6220bb77@pebble.deldotd.com> <20140928205940.GN20195@weber> Message-ID: <20140928140830.24aa9494@pebble.deldotd.com> On Sun, 28 Sep 2014 21:59:40 +0100 Tom Ellis wrote: > Complex is mentioned there because it is still around for compatibility with > Haskell 98, but it's not enabled by default. You'll also see Data.Complex > in that list. Arguably there should be a warning on the page of the former > to use the latter instead. > aha. i see that now. ok. at least now i know how to fix this. this is fairly old code, and i'm getting a lot of these sorts of things. slowly but surely working through them :-) thanks again. Brian From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Sep 28 21:11:45 2014 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 28 Sep 2014 22:11:45 +0100 Subject: [Haskell-cafe] the complex package is hidden In-Reply-To: <20140928140830.24aa9494@pebble.deldotd.com> References: <20140928125553.75c56b19@pebble.deldotd.com> <20140928195842.GL20195@weber> <20140928133855.3c4150db@pebble.deldotd.com> <20140928204622.GM20195@weber> <20140928135648.6220bb77@pebble.deldotd.com> <20140928205940.GN20195@weber> <20140928140830.24aa9494@pebble.deldotd.com> Message-ID: <20140928211145.GO20195@weber> On Sun, Sep 28, 2014 at 02:08:30PM -0700, briand at aracnet.com wrote: > On Sun, 28 Sep 2014 21:59:40 +0100 > Tom Ellis wrote: > > Complex is mentioned there because it is still around for compatibility with > > Haskell 98, but it's not enabled by default. You'll also see Data.Complex > > in that list. Arguably there should be a warning on the page of the former > > to use the latter instead. > > aha. i see that now. > > ok. at least now i know how to fix this. > > this is fairly old code, and i'm getting a lot of these sorts of things. > > slowly but surely working through them :-) Depending on exactly what you are doing, you may just want to enable Haskell 98 compatibility instead. Tom From briand at aracnet.com Sun Sep 28 21:23:02 2014 From: briand at aracnet.com (briand at aracnet.com) Date: Sun, 28 Sep 2014 14:23:02 -0700 Subject: [Haskell-cafe] the complex package is hidden In-Reply-To: <20140928211145.GO20195@weber> References: <20140928125553.75c56b19@pebble.deldotd.com> <20140928195842.GL20195@weber> <20140928133855.3c4150db@pebble.deldotd.com> <20140928204622.GM20195@weber> <20140928135648.6220bb77@pebble.deldotd.com> <20140928205940.GN20195@weber> <20140928140830.24aa9494@pebble.deldotd.com> <20140928211145.GO20195@weber> Message-ID: <20140928142302.20f6996e@pebble.deldotd.com> On Sun, 28 Sep 2014 22:11:45 +0100 Tom Ellis wrote: > On Sun, Sep 28, 2014 at 02:08:30PM -0700, briand at aracnet.com wrote: > > On Sun, 28 Sep 2014 21:59:40 +0100 > > Tom Ellis wrote: > > > Complex is mentioned there because it is still around for compatibility with > > > Haskell 98, but it's not enabled by default. You'll also see Data.Complex > > > in that list. Arguably there should be a warning on the page of the former > > > to use the latter instead. > > > > aha. i see that now. > > > > ok. at least now i know how to fix this. > > > > this is fairly old code, and i'm getting a lot of these sorts of things. > > > > slowly but surely working through them :-) > > Depending on exactly what you are doing, you may just want to enable Haskell > 98 compatibility instead. nah. it's fine. just a bit of Data.This and System.That. all fixed. didn't take long at all. the code wasn't _that_ old :-) Brian From fuuzetsu at fuuzetsu.co.uk Tue Sep 30 02:32:42 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 30 Sep 2014 03:32:42 +0100 Subject: [Haskell-cafe] Cabal Testing Pain In-Reply-To: References: Message-ID: <542A164A.20109@fuuzetsu.co.uk> On 09/27/2014 10:54 PM, Mike Craig wrote: > Hey all, I'm trying to setup an executable cabal project, the options for > cabal-based testing seem poor. I poked around for discussions of this but > didn't find much. My apologies if I'm beating a dead horse. > > The current options, as I understand them, are > > 1. Split code into library, executable, and test-suite. This gets you > single compilation but you have to list every source file in the library's > exposed/other-modules sections. > 2. Split code into executable and test-suite. You don't have to list the > source files, but you get double compilation and you have to declare every > dependency (and version!) twice. > > Am I missing a third (better) option, or is this the state of things? > > -- > Mike Craig > > 1. is a fine option, it's not like you add 20 modules a minute. It's a bit cumbersome at the beginning but that's about it. All other options either greatly prolong compilation or make testing/shipping inconvenient. 2. is bad precisely because you end up hiding your library part. Not only does it mean double compilation for you, there's nothing more frustrating than finding a package on Hackage that does what you want just to find it's executable-only. -- Mateusz K. From corentin.dupont at gmail.com Tue Sep 30 10:31:52 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 30 Sep 2014 12:31:52 +0200 Subject: [Haskell-cafe] ANN: Nomyx 0.7 beta, the only game where you can change the rules Message-ID: Hello everybody! I released Nomyx V0.7, the only game where You can change the rules! Here is the website: www.nomyx.net Here is a video introduction of the game: http://vimeo.com/58265498 I created a tutorial to learn how to play: http://www.corentindupont.info/blog/posts/2014-09-23-first-Nomyx-tutorial.html Let's start a new game! I propose to call it "The Space Merchants". Dear rulers, this part of the Galaxy is yours... Please login to the game here: www.nomyx.net:8000/Nomyx. The corresponding forum thread is here: http://www.nomyx.net/forum/viewtopic.php?f=4&t=1525&p=1739 Please also register on the mailing list to follow the game: nomyx-game at googlegroups.com Some background: this is an implementation of a Nomic [1] game in Haskell (I believe the first complete implementation of a Nomic game on a computer). In a Nomyx game you can change the rules of the game itself while playing it. The players can submit new rules or modify existing ones, thus completely changing the behaviour of the game through time. The rules are managed and interpreted by the computer. They must be written in the Nomyx language , which is a subset of Haskell. At the beginning, the initial rules are describing: - how to add new rules and change existing ones. For example a unanimity vote is necessary to have a new rule accepted. - how to win the game. For example you win the game if you have 5 rules accepted. But of course even that can be changed! New in this beta release: - the Nomyx language is now based on functional reactive programming - the language also embeds a mechanism to separate effectful instructions from effectless ones - ability to fork an existing game into a new one - ability to type-check rules before submitting them - ability to create new games If you wanna help developing Nomyx, join us on the dev mailing-list: dev-game at googlegroups.com Cheers, Corentin [1] www.nomic.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.marek.spartz at gmail.com Tue Sep 30 14:00:40 2014 From: kyle.marek.spartz at gmail.com (Kyle Marek-Spartz) Date: Tue, 30 Sep 2014 09:00:40 -0500 Subject: [Haskell-cafe] ANN: Nomyx 0.7 beta, the only game where you can change the rules In-Reply-To: References: Message-ID: <662fc0e2-ccb0-455e-9f20-566c5399ddc2@highlander> It doesn?t call itself a nomic, but the Schemaverse may also qualify: https://schemaverse.com/ ? Kyle Marek-Spartz On Sep 30, 2014, 5:31:52 AM, Corentin Dupont wrote: Hello everybody! I released Nomyx(http://www.nomyx.net) V0.7, the only game where You can change the rules! Here is the website: www.nomyx.net(http://www.nomyx.net) Here is a video introduction of the game: http://vimeo.com/58265498 I created a tutorial to learn how to play: http://www.corentindupont.info/blog/posts/2014-09-23-first-Nomyx-tutorial.html Let's start a new game! I propose to call it "The Space Merchants". Dear rulers, this part of the Galaxy is yours... Please login to the game here: www.nomyx.net:8000/Nomyx(http://www.nomyx.net:8000/Nomyx). The corresponding forum thread is here: http://www.nomyx.net/forum/viewtopic.php?f=4&t=1525&p=1739 Please also register on the mailing list to follow the game: nomyx-game at googlegroups.com(mailto:nomyx-game at googlegroups.com) Some background: this is an implementation of a Nomic [1] game in Haskell (I believe the first complete implementation of a Nomic game on a computer). In a Nomyx game you can change the rules of the game itself while playing it. The players can submit new rules or modify existing ones, thus completely changing the behaviour of the game through time. The rules are managed and interpreted by the computer. They must be written in the Nomyx language(http://hackage.haskell.org/package/Nomyx-Language), which is a subset of Haskell. At the beginning, the initial rules are describing: - how to add new rules and change existing ones. For example a unanimity vote is necessary to have a new rule accepted. - how to win the game. For example you win the game if you have 5 rules accepted. But of course even that can be changed! New in this beta release: - the Nomyx language is now based on functional reactive programming - the language also embeds a mechanism to separate effectful instructions from effectless ones - ability to fork an existing game into a new one - ability to type-check rules before submitting them - ability to create new games If you wanna help developing Nomyx, join us on the dev mailing-list: dev-game at googlegroups.com(mailto:nomyx-game at googlegroups.com) Cheers, Corentin [1] www.nomic.net(http://www.nomic.net) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Tue Sep 30 17:52:54 2014 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 30 Sep 2014 13:52:54 -0400 Subject: [Haskell-cafe] context deduction in GHC Message-ID: <201409301752.s8UHqs6P022012@coolidge.cs.dartmouth.edu> Why does ghci 7.6.3 not like this example, which section 4.3.2 of the language definition says is valid Haskell? class Foo a class Foo a => Bar a instance (Eq a, Show a) => Foo [a] instance Num a => Bar [a] Ghci complains, "Could not deduce (Show a) arising from the superclasses of an instance declaration from the context (Num a)". Yet Show is a superclass of Num. Hugs accepts the code. Doug McIlroy From miguelimo38 at yandex.ru Tue Sep 30 18:07:15 2014 From: miguelimo38 at yandex.ru (MigMit) Date: Tue, 30 Sep 2014 22:07:15 +0400 Subject: [Haskell-cafe] context deduction in GHC In-Reply-To: <201409301752.s8UHqs6P022012@coolidge.cs.dartmouth.edu> References: <201409301752.s8UHqs6P022012@coolidge.cs.dartmouth.edu> Message-ID: <55E1E58C-3F51-4485-830E-58F723B38DA0@yandex.ru> Because believe it or not, Show is not a superclass of Num. ?????????? ? iPad > 30 ????. 2014 ?., ? 21:52, Doug McIlroy ???????(?): > > Why does ghci 7.6.3 not like this example, which section > 4.3.2 of the language definition says is valid Haskell? > > class Foo a > class Foo a => Bar a > instance (Eq a, Show a) => Foo [a] > instance Num a => Bar [a] > > Ghci complains, "Could not deduce (Show a) arising from > the superclasses of an instance declaration from the > context (Num a)". Yet Show is a superclass of Num. > Hugs accepts the code. > > Doug McIlroy > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From allbery.b at gmail.com Tue Sep 30 18:11:31 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 30 Sep 2014 14:11:31 -0400 Subject: [Haskell-cafe] context deduction in GHC In-Reply-To: <201409301752.s8UHqs6P022012@coolidge.cs.dartmouth.edu> References: <201409301752.s8UHqs6P022012@coolidge.cs.dartmouth.edu> Message-ID: On Tue, Sep 30, 2014 at 1:52 PM, Doug McIlroy wrote: > Ghci complains, "Could not deduce (Show a) arising from > the superclasses of an instance declaration from the > context (Num a)". Yet Show is a superclass of Num. > Hugs accepts the code. > Show used to be a superclass of Num. It's not in current ghc, and will probably be removed from the next version of the language standard. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: