- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Pointer equality for nullary constructors
by David Feuer 23 Feb '18

23 Feb '18

Double-barreled continuations don't seem to work well when you want to abort construction of a recursive structure. Think about Data.HashMap.Strict.insert. We don't really want to have to walk all the way back up to the top if we discover that the value pointer we're inserting is the same as the I've already in the map. On Feb 22, 2018 2:55 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> wrote: David: i'm inclined to agree with Doug here. Phrased differently: what is the example change in overheads in micro or milliseconds? what is an example tiny program where those overheads are a significant part of program overhead? why woulnd't they use something like https://www.microsoft. com/en-us/research/wp-content/uploads/2007/10/compilingwithcontinuationscont inued.pdf aka the so called "double barrelled cps" transform? On Wed, Feb 21, 2018 at 11:21 PM, David Feuer <david.feuer(a)gmail.com> wrote: > Because sometimes the sanctioned way is inefficient. throwIO always > wraps its exception argument in a SomeException constructor before > calling raiseIO# on the result. That extra baggage is likely enough to > make the implementation I'm considering too slow to bother with, so I > care right now in 2018. I'd very much prefer to get an > officially-approved way to do what I want, but barring that I'll take > one that works. > > On Wed, Feb 21, 2018 at 9:33 AM, Doug McIlroy <doug(a)cs.dartmouth.edu> > wrote: > > > >> > Can I use reallyUnsafePtrEquality# reliably to identify whether a > value is > >> a nullary constructor of a particular type? > > > > Can this "optimization" possibly save enough time to justify > > nonstandard trickery? > > This kind of obscure brittle coding may have been OK 50 years > > ago. But why do it now? > > > > Doug > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. >

1 1

Pointer equality for nullary constructors
by David Feuer 23 Feb '18

23 Feb '18

Can I use reallyUnsafePtrEquality# reliably to identify whether a value is a nullary constructor of a particular type? For example, if I have data Foo = Foo Can I write isFoo :: a -> Bool isFoo !a = isTrue# (reallyUnsafePtrEquality# a Foo) instead of isFoo :: forall a. Typeable a => a -> Bool isFoo a | Just Refl <- eqTypeRep (typeRep @a) (typeRep @Foo) , Foo <- a = True | otherwise = False The reason I'm asking is because this would let me (potentially) raiseIO# a nullary constructor and then catch# it and see if it was what I was looking for rather than having to open a SomeException to get to an Exception dictionary, open that to get a TypeRep, and then peer inside that to check a Fingerprint. That is, I'd get lighter-weight exceptions that only carry the information I actually need. Thanks, David

4 6

Re: [Haskell-cafe] Pointer equality for nullary constructors
by Doug McIlroy 23 Feb '18

23 Feb '18

> > Can I use reallyUnsafePtrEquality# reliably to identify whether a value is > a nullary constructor of a particular type? Can this "optimization" possibly save enough time to justify nonstandard trickery? This kind of obscure brittle coding may have been OK 50 years ago. But why do it now? Doug

5 5

VerifyThis 2018: Call for Problems and First Announcement
by Andrei Paskevich 22 Feb '18

22 Feb '18

******************************************************************************* VerifyThis Verification Competition 2018 FIRST ANNOUNCEMENT AND CALL FOR PROBLEMS Competition to be held at ETAPS 2018 http://verifythis.ethz.ch ******************************************************************************** Get involved, even if you cannot participate in the competition: provide a challenge. IMPORTANT DATES Submission deadline: March 9, 2018 Competition: April 14 and 15, 2018 CALL FOR PROBLEMS To extend the problem pool, we are now soliciting algorithms and data structures which could contribute interesting verification challenges for the VerifyThis program verification competition (itself introduced below). We encourage suggestions at any level of detail, in particular submissions without a fully worked out verification task. - a problem may contain an informal statement of the algorithm to be implemented (optionally with complete or partial pseudocode) and the requirement(s) to be verified - a problem should be suitable for a 60-90 minute time slot - submission of reference solutions is welcome but not mandatory - problems with an inherent language- or tool-specific bias should be clearly identified as such - problems that contain several subproblems or other means of difficulty scaling are especially welcome - the organizers reserve the right (but no obligation) to use the problems in the competition, either as submitted or with modifications - submissions from (potential) competition participants are allowed Problems from previous competitions can be seen at http://verifythis.ethz.ch Submissions are to be sent by email to verifythis(a)cs.nuim.ie by the date indicated above. PRIZES The most suitable submission for competition will receive a prize. ABOUT VerifyThis 2018 will take place as part of the European Joint Conferences on Theory and Practice of Software (ETAPS 2018) on April 14 and 15, 2018. It is the 7th event in the VerifyThis competition series. Information on previous events and participants can be found at http://verifythis.ethz.ch The aims of the competition are: - to bring together those interested in formal verification, and to provide an engaging, hands-on, and fun opportunity for discussion - to evaluate the usability of logic-based program verification tools in a controlled experiment that could be easily repeated by others. The competition will offer a number of challenges presented in natural language. Participants have to formalize the requirements, implement a solution, and formally verify the implementation for adherence to the specification. There are no restrictions on the programming language and verification technology used. The correctness properties posed in problems will have the input-output behaviour of programs in focus. Solutions will be judged for correctness, completeness and elegance. ORGANIZERS * Marieke Huisman, University of Twente, the Netherlands * Rosemary Monahan, Maynooth University, Ireland * Peter Müller, ETH Zürich, Switzerland * Andrei Paskevich, Paris-Sud University, France * Gidon Ernst, National Institute of Informatics Tokyo, Japan CONTACT Email: verifythis(a)cs.nuim.ie Web: http://verifythis.ethz.ch

1 0

Arrow laws of Netwire
by KAction＠gnu.org 20 Feb '18

20 Feb '18

Hello! In process of adapting 'netwire-5.0.0' to my needs I discovered following strange thing. Let us consider following simple program: {-# LANGUAGE Arrows #-} import FRP.Netwire import Data.Monoid -- I almost sure this is correct, since it is copied -- from "Programming with Arrows", J. Hughes mapA :: (ArrowChoice a) => a b c -> a [b] [c] mapA f = proc input -> case input of [] -> returnA -< [] z:zs -> do y_ <- f -< z ys_ <- mapA f -< zs returnA -< y_:ys_ mconcatA :: (ArrowChoice a, Monoid m) => a b m -> a [b] m mconcatA f = mapA f >>> arr mconcat -- Note the commented line. wire :: (Monad m, HasTime t s) => Wire s () m a Double wire = pure (Sum 1.0) -- >>> arr (: []) >>> mconcatA returnA >>> arr getSum >>> integral 10 main = testWire (countSession_ 1) wire Problem is that, compiled with ghc-8.0.1 this program hangs if I uncomment second line in body of ``wire`` function[1], which is wierd, since assuming monoid and arrow laws, I believe -- (Arrow a, Monoid e) => a e e arr (: []) >>> mconcatA returnA = returnA Is it false? Any suggestions? .. [1] with that line commented program works and prints sequence of numbers, with every next over previous.

5 13

Tsuru is hiring
by Mikhail Baykov 20 Feb '18

20 Feb '18

Tsuru Capital is hiring, full time and intern positions are available. Haskell knowledge is required, experience with pricing futures/options would be nice but not necessary. Located in Tokyo, company language is English. Casual environment, nice monitors and a big coffee machine. Details how to apply are on our website: http://www.tsurucapital.com/en/ Feel free to ask questions here, in email or #tsurucapital on freenode.

1 0

ANN: stack-1.6.5
by Emanuel Borsboom 20 Feb '18

20 Feb '18

See https://haskellstack.org for installation and upgrade instructions. This is a bug-fix release. Bug fixes: * 1.6.1 introduced a change that made some precompiled cache files use longer paths, sometimes causing builds to fail on windows. This has been fixed. See [#3649](https://github.com/commercialhaskell/stack/issues/3649) * Some unnecessary rebuilds when no files were changed are now avoided, by having a separate build cache for each component of a package. See [#3732](https://github.com/commercialhaskell/stack/issues/3732). * Correct the behavior of promoting a package from snapshot to local package. This would get triggered when version bounds conflicted in a snapshot, which could be triggered via Hackage revisions for old packages. This also should allow custom snapshots to define conflicting versions of packages without issue. See [Stackage issue #3185](https://github.com/fpco/stackage/issues/3185). * When promoting packages from snapshot to local, we were occassionally discarding the actual package location content and instead defaulting to pulling the package from the index. We now correctly retain this information. Note that if you were affected by this bug, you will likely need to delete the binary build cache associated with the relevant custom snapshot. See [#3714](https://github.com/commercialhaskell/stack/issues/3714). * `--no-rerun-tests` has been fixed. Previously, after running a test we were forgetting to record the result, which meant that all tests always ran even if they had already passed before. See [#3770](https://github.com/commercialhaskell/stack/pull/3770). * Includes a patched version of `hackage-security` which fixes both some issues around asynchronous exception handling, and moves from directory locking to file locking, making the update mechanism resilient against SIGKILL and machine failure. See [hackage-security #187](https://github.com/haskell/hackage-security/issues/187) and [#3073](https://github.com/commercialhaskell/stack/issues/3073). Thanks to all our contributors for this release: * Arnaud Spiwack * Artyom * Artyom Kazak * Charles Reilly * Dave Tapley * Emanuel Borsboom * Joshua Simmons * Luke Murphy * Michael Sloan * Michael Snoyman * Nicolas Mattia * Paolo G. Giarrusso * Samuel Lelièvre * Simon Hengel * Thomas Broadley * tswelsh

1 0

Replace data constructors via meta programming
by Vilem-Benjamin Liepelt 19 Feb '18

19 Feb '18

Hi, I am looking for a solution to get rid of this silly boilerplate: eval :: Ord var => Map var Bool -> Proposition var -> Bool eval ctx prop = evalP $ fmap (ctx Map.!) prop where evalP = \case Var b -> b Not q -> not $ evalP q And p q -> evalP p && evalP q Or p q -> evalP p || evalP q If p q -> evalP p ==> evalP q Iff p q -> evalP p == evalP q What I would like to do in essence is to replace the data constructors like so: -- Not valid Haskell!! Can't pattern match on constructor only... magic = \case Var -> id Not -> not And -> (&&) Or -> (||) If -> (==>) Iff -> (==) compile = transformAST magic $ fmap (\case 'P' -> False; 'Q' -> True) >>> compile (Iff (Not (And (Var 'P') (Var 'Q'))) (Or (Not (Var 'P')) (Not (Var 'Q')))) ((==) (not ((&&) (id True) (id False))) ((||) (not (id True)) (not (id False)))) Note how the compiled expression exactly mirrors the AST, so there should be some meta programming technique for this. Does anyone have an idea how I can achieve this? The full source code is here: https://gist.github.com/vimuel/7dcb8a9f1d2b7b72f020d66ec4157d7b I am happy to take any other comments relating to my code... Best, Vilem

10 16

MonadComprehensions madness
by Albert Y. C. Lai 17 Feb '18

17 Feb '18

I am just starting to learn MonadComprehensions and I'm following its type rules to their logical conclusion. So I can have [ x | x <- "abc", then group by EXPR using PNT ] where EXPR is an expression of my choosing, PNT is a function of type forall a. (a -> E) -> [a] -> M (F a) where E is the type of EXPR, M is a Monad instance of my choosing, and F is a Functor instance of my choosing. (And even the [a] can be replaced by N a, as long as "abc" has type N Char.) (My freedom over M and F isn't quite documented in the GHC user's guide, but there is very little you can't discover by putting a few typed holes here and there >:) ) So I choose EXPR = ord x, E = Int, M = IO, F = IntMap, so I can have: {-# LANGUAGE MonadComprehensions, TransformListComp #-} module F where import Data.Char (chr, ord) import qualified Data.IntMap.Strict as IntMap foo :: IO (IntMap.IntMap Char) foo = [ x | x <- "a\r\n", then group by ord x using whee ] whee :: (a -> Int) -> [a] -> IO (IntMap.IntMap a) whee f xs = do print (map (chr . f) xs) return (IntMap.fromList (zip (map f xs) (reverse xs))) Warning: I have only proved that it type-checks; I have not understood what good it does. >:)

1 0

web framework
by Dennis Raddle 17 Feb '18

17 Feb '18

I'd like a recommendation for a way to write web apps in Haskell. Background: I have written code in Python, C++ and Haskell for many years. However I have done no substantial web programming. My goal is mathematics-education-themed apps to run on browsers on any device. At first I'll be happy to run the app on my laptop and connect locally with an iPad or smartphone while I sit with my students. Later I may deploy it at scale "in the cloud" (I mean anyone connected to the internet can run it, and the servers belong to the hosting provider). Why a browser app? I figure it's the best way to get a portable app that will run on phones, tablets, and computers of all OS's. Why Haskell? The goal right now is fast prototyping and experimentation, especially for some fairly complex algorithms. I spent some time with JavaScript, TypeScript, and Scala.JS. I'm just so much more comfortable in Haskell with which I can write clean & sophisticated algorithms quickly. I see lots of mentions of Haskell "platforms" and "stacks" etc. on the Haskell Wiki. But I will confess I don't really know what a "platform" or "stack" is, or which of the options will support my needs. I know close to zero about apps in the browser. Regarding my UI needs, my app will have lots of graphics and lots of things to click on, drag, etc. It will need to be touch-screen responsive. Dennis

5 6