- Haskell-Cafe - Haskell.org

Symmetric Difference for Data.Set and Data.IntSet?
by Zemyla 08 Jul '15

08 Jul '15

Could this be implemented as a primitive? I know it can be made from union and difference, or doing toList on both of them, taking the symmetric difference, and using fromDistinctAscList on the result, but it'd probably be much faster if it could be done natively, like can be done with Data.Map.mergeWithKey. Alternatively, could we get a merge interface for Set and IntSet roughly matching Map and IntMap?

5 4

Strange "ambiguity" problems thanks to GADTs
by wren romano 07 Jul '15

07 Jul '15

Hi all, In my latest project I've been using a bunch of GADTs, which unfortunately disables let-polymorphism (i.e., where-polymorphism) in the most annoying way. For the most part I've been able to hack around that limitation via judicious use of ScopedTypeVariables, but I've run into an issue that I can't for the life of me figure out why GHC doesn't like it. I have something like the following function, where @a@ and @b@ happen to be GADTs: foo :: (A a, B b) => a i -> M (b i) foo a = case view a of ... SomePattern a1 a2 -> do b1 <- foo a1 b2 <- foo a2 return . unview $ SomePattern b1 b2 It seems to me that the recursive calls should work just fine, using the same @b@ as we'll ultimately be returning. However, for some reason GHC complains about the recursive calls using some other @b0@ can can't deduce @B b0@ from @B b@. Why doesn't GHC unify these two types? How can I force them to unify without adding type annotations at every recursive call? -- Live well, ~wren

2 1

stm onCommit
by Silvio Frischknecht 07 Jul '15

07 Jul '15

I need a onCommit functionality for stm. I know there is the stm-io-hooks [1] package. But it seems so big for such a small thing and then I have to translate everything to their monad. lift lift lift ... So I thought of a little hack to solve the issue and I'm wondering if this is safe to use. My understanding of stm internals is very limited. It's basically just a TChan with IO actions in it and there is another thread waiting to execute anything inserted into it. import Control.Concurrent.STM.TChan onCommitChan :: TChan (IO ()) {-# NOINLINE onCommit #-} onCommitChan = unsafePerformIO $ do chan <- newTChanIO forkIO $ forever $ atomically $ readTChan chan return chan onCommit :: IO () -> STM () onCommit = writeTChan onCommitChan It would be cool if an onCommit hook could be directly added to the stm package. Silvio [1] https://hackage.haskell.org/package/stm-io-hooks-1.0.1

5 9

OCL 2015: Final Call for Papers - Only 10 Days Left
by Achim D. Brucker 07 Jul '15

07 Jul '15

(Apologies for duplicates) If you are working on the foundations, methods, or tools for OCL or textual modelling, you should now prepare your submission for the OCL workshop! CALL FOR PAPERS 15th International Workshop on OCL and Textual Modeling Tools and Textual Model Transformations Co-located with ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS 2015) September 28th, 2015, Ottawa, Canada http://ocl2015.lri.fr Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but some of their features are difficult to formalize and lack the level of precision required to create complete and unambiguous specifications. Limitations of the graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. Topics of interest include (but are not limited to) =================================================== - Mappings between textual modeling languages and other languages/formalisms - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for -- validation, verification, and testing, -- model transformation and code generation, -- meta-modeling and DSLs, and -- query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports -- usage of textual modeling languages and tools in complex domains, -- usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks This year, we particularly encourage submissions describing tools that support - in a very broad sense - textual modeling languages (if you have implemented OCL.js to run OCL in a web browser, this is the right workshop to present your work) as well as textual model transformations. Venue ===== The workshop will be organized as a part of MODELS 2015 Conference in Ottawa, Canada. It continues the series of OCL workshops held at UML/MODELS conferences: York (2000), Toronto (2001), San Francisco (2003), Lisbon (2004), Montego Bay (2005), Genova (2006), Nashville (2007), Toulouse (2008), Denver (2009), Oslo (2010), Zurich (2011, at the TOOLs conference), 2012 in Innsbruck, 2013 in Miami, and 2014 in Valencia, Spain. Similar to its predecessors, the workshop addresses both people from academia and industry. The aim is to provide a forum for addressing integration of OCL and other textual modeling languages, as well as tools for textual modeling, and for disseminating good practice and discussing the new requirements for textual modeling. Workshop Format =============== The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. Submissions =========== Three types of papers will be considered: * short papers (between 6 and 8 pages) describing ideas, * tool papers (between 6 and 8 pages), and * full papers (between 12 and 16 pages) in LNCS format. Submissions should be uploaded to EasyChair (https://easychair.org/conferences/?conf=ocl20150) The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online in a pre-conference edition of CEUR (http://www.ceur-ws.org) Important Dates =============== Submission of papers: July 17, 2015 Notification: August 21, 2015 Workshop date: September 28, 2015 Organizers ========== Achim D. Brucker, SAP SE, Germany Marina Egea, Indra Sistemas S.A., Spain Martin Gogolla, University of Bremen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Programme Committee =================== Mira Balaban, Ben-Gurion University of the Negev, Israel Tricia Balfe, Nomos Software, Ireland Achim D. Brucker, SAP SE, Germany Fabian Buettner, Inria - Ecole des Mines de Nantes, France Jordi Cabot, Inria - Ecole des Mines de Nantes, France Dan Chiorean, Babes-Bolyai University, Romania Robert Clariso, Universitat Oberta de Catalunya, Spain Tony Clark, Middlesex University, UK Manuel Clavel, IMDEA Software Institute, Spain Carolina Dania, IMDEA Software Institute, Spain Birgit Demuth, Technische Universitat Dresden, Germany Marina Egea, Indra Sistemas S.A., Spain Geri Georg, Colorado State University, USA Martin Gogolla, University of Bremen, Germany Shahar Maoz, Tel Aviv University, Israel Istvan Rath, Budapest University of Technology and Economics, Hungary Bernhard Rumpe, RWTH Aachen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Claas Wilke, Technische Universitat Dresden, Germany Edward Willink, Willink Transformations Ltd., UK Burkhart Wolff, Univ. Paris-Sud - LRI, France Steffen Zschaler, King's College, UK -- Dr. Achim D. Brucker, SAP SE, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch/

1 0

Fwd: Efficient records with arbitrarily many fields [was: Extensible states]
by Alexander V Vershilov 07 Jul '15

07 Jul '15

(forgot to reply to cafe list Hi. You can take a look at vector-fixed-hetero [1], that can act as anonymous structure with arbitrary number of fields, convertion to and from datatypes with the same structure and many more features. It's missing field names though and syntactic sugar that 'records' package have. If you like to reinvent a wheel, then you can use following appoach: introduce some typelevel info data a :? (b :: Symbol) data FieldName (t :: Symbol) = FieldName introduce generic structure for records with any number of fiels newtype ARec (m :: [*]) = ARec { unRec :: Array Any } type instance TProxy (ARec m) = m type instance VProxy (ARec m) = ARec rerec :: ARec a -> ARec b rerec = ARec . unRec indexRec :: (KnownNat (FieldIndex name m), FieldType name m ~ a) => proxy name -> ARec m -> a indexRec name v = unsafeCoerce $ indexArray (unRec v) (fromIntegral (natVal (indexProxy name v))) updateRec :: (KnownNat (Length m), KnownNat (FieldIndex name m), FieldType name m ~ a) => proxy name -> a -> ARec m -> ARec m updateRec name b v = runST $ do out <- newArray len undefined copyArray out 0 (unRec v) 0 len writeArray out idx (unsafeCoerce b) ARec <$> unsafeFreezeArray out where idx = fromIntegral (natVal (indexProxy name v)) len = fromIntegral (natVal (lengthProxy v)) you'll need some typelevel magic for that: type family FieldType (n :: Symbol) m where FieldType n ((a :? n) ': z) = a FieldType n (b ': z) = FieldType n z type family FieldIndex (n::Symbol) m :: Nat where FieldIndex n ((a :? n) ': z) = 0 FieldIndex n ( b ': z) = 1 + FieldIndex n z indexProxy :: (KnownNat c, FieldIndex n m ~ c) => proxy1 n -> proxy2 m -> Proxy c indexProxy _ _ = Proxy type family Length m where Length '[] = 0 Length (x ': xs) = 1 + Length xs lengthProxy :: (KnownNat c, Length n ~ c) => proxy n -> Proxy c lengthProxy _ = Proxy then you can implement lenses: instance (KnownNat (FieldIndex n m), KnownNat (Length m), FieldType n m ~ a) => HasField (n :: Symbol) (ARec m) a where getField = indexRec updateField p = flip (updateRec p) fieldLens' :: (HasField name z a, FieldType name (TProxy z) ~ a) => FieldName name -> Lens z z a a fieldLens' name = \f m -> fmap (updateField name m) (f $ getField name m) type family UpdateType (n :: Symbol) z a b where UpdateType n ((a :? n) ': z ) a b = (b :? n) ': z UpdateType n ( z ': zs) a b = z ': UpdateType n zs a b fieldLens :: ( ARec m ~ z, ARec m' ~ z', m' ~ UpdateType name m a b , FieldType name m ~ a, FieldType name m' ~ b , KnownNat (FieldIndex name m), KnownNat (FieldIndex name m') , KnownNat (Length m), KnownNat (Length m') ) => FieldName name -> Lens z z' a b fieldLens name = \f m -> fmap (updateField name (rerec m)) (f $ getField name m) this approach is more or less the same as records package with only one datastructure and almost the same syntactic sugar can be applied, the only missing thing is that pattern matching will be more difficult that with records. At this point it's not possible to write strict fields, but it can be easily extended. If someone is interested in this sort of wheel, I can prepare a package and some docs about and with coercion with other solutions like fixed-vector-hetero and records. [1] https://hackage.haskell.org/package/fixed-vector-hetero On Sat, Jul 4, 2015, 16:08 Ben Franksen <ben.franksen(a)online.de> wrote: > > Marcin Mrotek wrote: > > Okay, perhaps I'm too newbie to understand the big picture, but it > > seems to me you can get either: > > > > a) O(1) access to any, arbitrarily selected (at runtime) field > > b) O(1) append > > > > I guess option a) is better performance-wise, as appending is usually > > done less often than selecting (an O(1) slice is already possible with > > independently typed regular Haskell records) but > > dependently-typed-list-based implementation, or at the very least > > Vinyl (I haven't ever used HList) has the advantage of being dead > > simple in both implementation and usage. I mean, with Vinyl, you can > > write manual recursion over Rec's like: > > > > foo :: Rec ... -> Rec ... > > foo RNil = ... > > foo (r :& rs) = ... > > > > whenever GHC's typechecker gives up and goes on a strike; and I dare > > to say, with commonly used record sizes (have you ever used a record > > with more than, let's say, 10 fields?) the speed tradeoff is not > > noticeable. > > While more than 10 fields in a record is uncommon for typical library APIs > and simple programs, real world projects can grow much larger records. One > example is configuration data for complex programs (like Darcs or even GHC) > with many options. It would be so nice if we could use record types for the > configuration! Another application could in control system toolkits like > EPICS [1], which currently has (actually: generates) C records with > potentially hundreds of fields. > > If lookup is / remains linear we can never efficiently support these kinds > of applications and that would be very sad. > > I think the most reasonable default is O(1) for lookup and O(n) for > extension, like in Nikita Volkov's record package. It is quite unfortunate > that this package limits the number of fields! If GHC would offer generic > support for tuples of arbitrary size (with the same efficiency as today) > this limitation could be avoided and all would be well. > > Cheers > Ben > > [1] http://www.aps.anl.gov/epics/ > -- > "Make it so they have to reboot after every typo." ― Scott Adams > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Alexander

3 5

New Functional Programming Job Opportunities
by Functional Jobs 07 Jul '15

07 Jul '15

Here are some functional programming job opportunities that were posted recently: Senior Developer at Elsen, Inc. http://functionaljobs.com/jobs/8840-senior-developer-at-elsen-inc Cheers, Sean Murphy FunctionalJobs.com

1 0

SPJ's Venn diagram on type-correctness
by Mathijs Kwik 06 Jul '15

06 Jul '15

Hi all, Sometime in the past, I came across a presentation from SPJ in which he showed a Venn diagram showing "programs that compile" and "programs that are correct". Unfortunately, I cannot remember the exact wording and I'm unable to find the slides/talk on google/youtube. Does anyone remember the exact details of the diagram? Or the title of the talk? Is there still a link to it? Thanks, Mathijs

2 2

ANN: stack-0.1.2.0
by Emanuel Borsboom 06 Jul '15

06 Jul '15

New release of stack, a build tool. Changes: https://github.com/commercialhaskell/stack/releases/tag/v0.1.2.0 General information and download links (now with package repositories for CentOS, Fedora, and Debian): https://github.com/commercialhaskell/stack#readme If you already have stack-0.1.1.0, you can upgrade using: stack upgrade --git && stack upgrade [normally just 'stack upgrade' will suffice, but due to my flub in the last release we ended up with a stack-9.9.9 on hackage which can't be removed (see https://github.com/haskell/hackage-server/issues/382) and you have to get the stack version that knows to ignore it first]

1 0

ANN: zoom-refs - zoom and pairing for mutable references
by Marcin Mrotek 06 Jul '15

06 Jul '15

Hello, I've just uploaded my package zoom-refs: http://hackage.haskell.org/package/zoom-refs-0.0.0.0 It's a "port" of State monad zoom (from lens) to mutable references: zoomTVar :: Lens' a b -> TVar a -> TVar b These TVars aren't actually the raw TVars from STM, but wrappers that provide the same functionality. Similar functions are provided for STRefs and IORefs. Additionally, TVars and STRefs can be paired to create composite references: pairTVars :: TVar a -> TVar b -> TVar (a,b) No such functionality is provided for IORefs, as there would be no way to guarantee atomicity of operations on the underlying references. Together. mutable references can be used sort of like Functors and Applicatives, though one needs to use lenses rather than plain functons to map them. Finally, there are multiple references that use traversals instead of lenses to zoom: readMultiTVar :: Monoid a -> MultiTVar a -> STM a readMultiTVarList :: MultiTVar a -> STM [a] readMultiTVarHead :: MultiTVar a -> STM (Maybe a) Best regards, Marcin Mrotek

1 0

Extensible states
by Alberto G. Corona 06 Jul '15

06 Jul '15

Hi, Anyone used some of the extensible record packages to create a kind of extensible state monad? I mean something that besides having "get", "gets" and "put" would have some kind of "add" and "gets": add :: a -> State () gets :: State (Maybe a) or add :: LabelName -> a -> State () gets :: LabelName -> State (Maybe a) So that I can extend the state without using additional monad transformers. Monad transformers are very hard for beginners and scramble error messages I did the first option for MFlow, hplayground and Transient packages (setSData and getSData). But my solution uses a map indexed by type and this requires a lookup for each access. I would like to know if there is an alternative with no lookups. I´m not obsessed with speed but In some applications the speed may be important.... Anyone? -- Alberto.

10 17