August 2015 - Haskell-Cafe

Fwd: Syntax extension - adding import support to let/where bindings
by Mike Meyer 05 Aug '15

05 Aug '15

Arg. Didn't send this to the list. ---------- Forwarded message --------- From: Mike Meyer <mwm(a)mired.org> Date: Wed, Aug 5, 2015 at 12:16 PM Subject: Re: [Haskell-cafe] Syntax extension - adding import support to let/where bindings To: Evan Laforge <qdunkan(a)gmail.com> On Wed, Aug 5, 2015 at 11:43 AM Evan Laforge <qdunkan(a)gmail.com> wrote: > And while "you don't have to use it" is > always brought up, it seems to me the more successful the feature is > the more likely you do have to use it. > "You don't have to use it" is a canard, and that argument needs to be killed whenever and wherever it arises. Sure, I don't have to use it. But the tools I use have to support it, so it'll make them bigger and slower, so I'm paying the price for "it" even if I don't use it. If I'm on a team, I probably have to either waste time arguing with other people to get them not to use it, or at least explain why I didn't use it. And that latter will come up every time I share code with other people, which we do want to encourage people to do. And that brings us to the real issue of why "You don't have to use it" is simply false. Reusing other people's code is a critical part of any software development environment. If they use, I have to understand it in order to understand their code. Even more than I have to in order to explain why I don't use it. So, no matter what I think of some feature, if it exists, the tools I use will almost certainly have to support it, and I'll have to understand the feature well enough to decipher code that uses it, and probably defend my decision not to use it. I don't see that this is in any way less of a burden on me than if I chose to use it.

3 2

Re: [Haskell-cafe] Syntax extension - adding import support to let/where bindings
by Oliver Charles 05 Aug '15

05 Aug '15

On Wed, Aug 5, 2015 at 3:12 PM Moritz Kiefer <moritz.kiefer(a)gmail.com> wrote: > Am Mittwoch, 5. August 2015 14:59:54 UTC+2 schrieb Mike Ledger: >> >> This would be really handy to have. You could also have import "blocks", >> like >> >> import Foo in { >> ... >> } >> >> Where {...} is a new layout block, I guess. >> > Is *let* not exactly this block feature? > Indeed, in my post I use let bindings to achieve this: let import CSS in [ width (px 50) ] You could also add other local bindings to your scope: let import CSS sizeInPx = px 50 in [ width sizePx, height sizeInPx ] (Note that just like let the other bindings have access to the symbols that were imported) *ocharles*

3 2

Re: [Haskell-cafe] ambiguous module name Network.URI
by Kees Bleijenberg 05 Aug '15

05 Aug '15

Thanks Christopher, -----Oorspronkelijk bericht----- Check out the Hackage page for network-uri: https://hackage.haskell.org/package/network-uri The parseURI function is in the version of network you are using already so there is no need to import modules from network-uri. ---------------------------------------- If I remove the import of Network-URI and leave the import Network.Http and use parseURI, ghc complains: not in scope parseURI. Do I have to change someting in the packages? Kees

3 2

Why is the no tuple syntax for sum types
by Silvio Frischknecht 05 Aug '15

05 Aug '15

Protuct types have this nice tuple syntax (a,Char,Int),(a,'c',1). Why is there no syntax like this for Sum types (a|Char|Int),(||1). This would be very usefull for some more explicit error handling. I.E. You have a library that has errors. Error1, .. ErrorN. Currently there are only two ways of making a function that can throw Error3 and Error8. Use 'Dynamic' typed Exceptions or make a general Error type that is the sum of all Errors. In both cases it is not clear from the type of the function what Errors can occur. With sumTuples you could just return (Result|Error3|Error8). Also, I guess I'm just one of those people who occasionally confuse Left and Right :) Silvio Frischknecht

7 9

Re: [Haskell-cafe] ANNOUNCE: Haskell Platform 7.10.2-a
by Mark Lentczner 04 Aug '15

04 Aug '15

As promised in the Haskell Platform 7.10.2 announcement, we have now release Haskell Platform 7.10.2-a. The only changes from 7.10.2 are: text-1.2.1.3 - to work around the issue with text literals in GHC 7.10.2 fgl-5.5.2.1 - this release changes no APIs, but fixes builds with older GHCs Available, as always, from: https://www.haskell.org/platform/ - Mark

2 2

Typeclassable typeclass?
by Zemyla 04 Aug '15

04 Aug '15

I apologize if this has been discussed and dismissed before, but I figured with Typeable being made entirely automatic by GHC, this might have a shot at working. What if there were a typeclass called Typeclassable, whose definition would be: class (Typeable a) => Typeclassable a where typeClass :: (Typeable c) => proxy c -> proxy' a -> ((c a) => b) -> b -> b So, for a simple example, you might have: nubT :: (Typeclassable a, Eq a) => [a] -> [a] nubT ls = typeClass (Proxy :: Proxy Ord) ls (nubOrd ls) (nub ls) where nubOrd is a suitable implementation of nub that requires Ord a. Basically, my first thought for the implementation of Typeclassable is that it contains all the dictionaries for a in a hashtable, and searches through them with the typeRep of c. So: 1) Can this be implemented with GHC as it is now? 2) Could this be implemented at all with any reasonable amount of work? 3) Should this be implemented? Would the benefits outweigh the costs?

3 2

Freeze/thaw fusion
by William Yager 04 Aug '15

04 Aug '15

Has anyone done any research into fusing operations that involve thawing some data, mutating it, and then freezing it again? Data.Vector does something similar; it turns vectors into streams, operates on the streams, and then turns them back into vectors. It can fuse these operations by removing intermediate However, I've done a bit of preliminary work on a fusion system that works on operations of the form runST $ do x' <- thaw x foo x' freeze x' and yields promising results in some cases. This could be useful for data structures that aren't stream-able, but suffer from lots of unnecessary freezing and unfreezing. This seems like the sort of thing that someone would have already done, so I wanted to check if anyone knew of any previous work on this. Cheers, Will

4 5

STM Finalizers
by Michael Schröder 04 Aug '15

04 Aug '15

Hi everyone, I want to finally announce some work I did as part of my master's thesis [1]. It's an extension to GHC's STM implementation. The main idea is to introduce a new primitive function atomicallyWithIO :: STM a -> (a -> IO b) -> IO b Like the existing atomically operation, atomicallyWithIO performs an STM computation. Additionally, it takes a *finalizer*, which is an arbitrary I/O action that can depend on the result of the STM computation, and combines it with the transaction in such a way that: 1. The finalizer is only performed if the STM transaction is guaranteed to commit. 2. The STM transaction only commits if the finalizer finishes without raising an exception. A motivation of why this is useful: Say we want to save the results of some STM transaction, i.e. persist them to disk. Currently, this is not possible in a transactionally safe way. The naive approach would be to first atomically perform some STM computation and then independently serialise its result: do x <- atomically m serialize x There are two issues with this. First, another thread could perform a second transaction and serialise it before we have finished serialising ours, which could result in an inconsistent state between the memory of our program and what is stored on disk. Secondly, the function serialize might not terminate at all; it could throw an exception or its thread could die. Again we would end up with an inconsistent state and possibly data loss. We might try to simply move serialisation into the atomic block, but to do this we have to circumvent the types, which should already be a huge red flag: atomically $ do x <- m unsafeIOToSTM (serialize x) The problem here is of course that an STM transaction can retry many times, which will also result in serialize being executed many times, which is probably not something we want. Furthermore, if the thread receives an asynchronous exception, the transaction will abort in an orderly fashion, while serialize, with its irrevocable side effects, cannot be undone. But with finalizers, the solution is easy: atomicallyWithIO m serialize I've written a small example application that uses finalizers and other stuff from my thesis to build a lightweight STM database framework: [2] There are more possible uses cases besides serialisation (such as interactive transactions) and some interesting issues surrounding finalizers (like nesting of transactions) which are discussed in greater detail in my thesis [1], which also includes a formal operational semantics of the whole thing. I have implemented finalizers in my fork of GHC [3], if any of you want to play around with them yourself. The atomicallyWithIO function is exported from the GHC.Conc.Sync module. Cheers, Michael [1] https://github.com/mcschroeder/thesis [2] https://github.com/mcschroeder/social-example [3] https://github.com/mcschroeder/ghc

7 14

happstack-authenticate 2
by Corentin Dupont 04 Aug '15

04 Aug '15

Hello, I'm a bit confused about the routeAuthenticate and authenticateState bits in the new happstack-authenticate. It seems that I have to do this in the beginning of my application: (_, routeAuthenticate, authenticateState) <- liftIO $ initAuthentication Nothing (const $ return True) [ initPassword "http://localhost:8000/#resetPassword" "example.org" , initOpenId] Where this should be done? In the main? If possible I'd prefer to delay it because my main is web-agnotic. Where should I store those two values? Should I put them in my monad stack (I have a StateT)? Is the routeAuthenticate really necessary? It looks a bit cumbersome to carry it around everywhere in the states. Thanks, Corentin

2 2

2 PhD studentships in Computer Science at the University of Dundee
by Ekaterina Komendantskaya 04 Aug '15

04 Aug '15

Hello, School of Sciences and Engineering, University of Dundee, advertises two PhD studentships in the area of Computer Science. Applicants interested in Programming languages, Logic and Automated/Interactive theorem proving are encouraged. Further details are available here: https://docs.google.com/document/d/1ggi4S2DBS1IqB3fqyFBkKbrArYJRUiOybIfW7Vd… Best regards, Katya Ekaterina Komendantskaya Senior Lecturer, Head of PhD Studies Room 1.04, Queen Mother Building School of Computing, University of Dundee Scotland, DD14HN Tel: (+44) 01382384820

1 0