- Haskell-Cafe - Haskell.org

Is this functional reactive programming
by Clinton Mead 12 May '15

12 May '15

What I want to be able to do is something like this: do x <- newSTRef 2 y <- newSTRef 3 z <- letSTRef (x + y) r1 <- readSTRef z writeSTRef x 5 r2 <- readSTRef z return (r1, r2) This should return (6,15) The "letSTRef" is what's new. The value it returns can change based on the parts that make up it's function changing. I understand this syntax above isn't going to work (I'd have to use applicative at least I'd imagine) but my main question is that does something like this exist? Is it functional reactive programming or is it something else? I don't want to be reinventing the wheel if this type of idea is already implemented but I haven't recognised it.

3 3

Call for participation: Applied Functional Programming (AFP) Summerschool 6-17 July 2015, Utrecht, Netherlands
by Atze Dijkstra 12 May '15

12 May '15

=========== AFP Summerschool 2015 =========== Applied Functional Programming (AFP) Summerschool July 6-17, 2015 Utrecht University, Department of Information and Computing Sciences Utrecht, The Netherlands Summerschool & registration website: http://www.utrechtsummerschool.nl/courses/science/applied-functional-progra… AFP website : http://www.cs.uu.nl/wiki/USCS contact : Uscs-afp(a)lists.science.uu.nl *** The 2015 edition of the Applied Functional Programming (AFP) Summerschool in Utrecht, Netherlands will be held from 6-17 July 2015. The summerschool teaches Haskell on both beginners and advanced levels via lectures and lab exercises. More info can be found via the references above, included here is a summary from the summerschool info: ``Typed functional programming in Haskell allows for the development of compact programs in minimal time and with maximal guarantees about robustness and correctness. The course introduces Haskell as well as its theoretical underpinnings such as typed lambda calculus, and Damas-Milner type inference. There is ample opportunity to put this all in practice during lab sessions. Typed functional programming languages allow for the development of robust, concise programs in a short amount of time. The key advantages are higher-order functions as an abstraction mechanism, and an advanced type system for safety and reusability. This course introduces Haskell, a state-of-the-art functional programming language, together with some of its theoretical background, such as typed lambda calculi, referential transparency, Damas-Milner type inference, type level programming, and functional design patterns. We will combine this with applications of functional programming, concentrating on topics such as language processing, building graphical user interfaces, networking, databases, and programming for the web. The goal of the course is not just to teach the programming language and underlying theory, but also to learn about the Haskell community and to get hands-on experience by doing lab exercises or a Haskell project of your own.'' *** This year is somewhat special in that the Tour de France starts in Utrecht the weekend before the start of the summerschool. It is an opportunity for enjoying the related festivities. It also implies that housing may be more difficult the weekend before the summerschool, something to keep in mind when you wait with registration until the latest. regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze(a)uu.nl ............... / |___\ _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

Multiway tree vs rose tree
by Tara Athan 12 May '15

12 May '15

Hi - I am new to this list, and the only archive I could find is the Mailman archive, which is next to impossible to search. So this may be a topic that has been previously discussed, I don't know... The documentation at https://hackage.haskell.org/package/containers-0.3.0.0/docs/Data-Tree.html says that a rose tree is another name for multiway tree. But this is not true according to my understanding of the accepted definition in the CS literature (see e.g. http://doc.utwente.nl/66626/1/db-utwente-0000003528.pdf) Rose trees do not have labels at the nodes, only at the leaves (aka tips). There is another page https://wiki.haskell.org/Algebraic_data_type#Rose_tree that also uses this divergent definition. To further propagate this problem, the Wikipedia page https://en.wikipedia.org/wiki/Rose_tree uses these Haskell wiki pages as the definitive source. Tara

3 4

3rd CFP FARM 2015 -- final reminder
by Anton Kholomiov 12 May '15

12 May '15

************************************************************ 3rd CFP FARM 2015 3rd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Vancouver, Canada, 5 September, 2015 affiliated with ICFP 2015 Full Paper and Demo Abstract submission Deadline: 17 May ************************************************************ The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional (“mostly functional” is fine), and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2015 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: farm-2015(a)easychair.org KEY DATES: Full Paper and Demo Abstract submission Deadline: 17 May Author Notification: 26 June Camera Ready: 19 July Workshop: 5 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair: https://easychair.org/conferences/?conf=farm2015 PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. WORKSHOP ORGANISATION Workshop Chair: Henrik Nilsson, University of Nottingham Program Chair: David Janin, University of Bordeaux Publicity Chair: Samuel Aaron, University of Cambridge Program Committee: Samuel Aaron, University of Cambridge Jean Bresson, IRCAM Paris David Broman, KTH and UC Berkeley David Janin (chair), University of Bordeaux Anton Kholomiov, Orffeus instrumental ensemble Moscow Alex Mclean, University of Leeds Carin Meier, Outpace Systems Henrik Nilsson, University of Nottingham Yann Orlarey, GRAME Lyon Donya Quick, Yale University Shigeki Sagayama, Meiji University Chung-chieh Shan, Indiana University Michael Sperber, Active Group GmbH Bodil Stokke, FutureAdLabs For further details, see the FARM website: http://functional-art.org

1 0

ANN: codec: easy bidirectional serialization and first-class record construction
by Patrick Chilton 12 May '15

12 May '15

Tired of writing complementary parseJSON/toJSON, peek/poke or Binary get/put functions? codec <https://github.com/chpatrick/codec> provides easy bidirectional serialization of plain Haskell records in any Applicative context. All you need to do is provide a de/serializer for every record field in any order you like, and you get a de/serializer for the whole structure. The type system ensures that you provide every record exactly once. It also includes a library for general record construction in an Applicative context, of which creating codecs is just one application. *JSON:* data User = User { username :: Text , userEmail :: Text , userLanguages :: [ Text ] , userReferrer :: Maybe User } deriving Show genFields ''User userCodec :: JSONCodec User userCodec = obj "user object" $ User $>> f_username >-< "user" >>> f_userEmail >-< "email" >>> f_userLanguages >-< "languages" >>> f_userReferrer >-< opt "referrer" instance FromJSON User where parseJSON = parseVal userCodec instance ToJSON User where toJSON = produceVal userCodec *Bit fields:* ipv4Codec :: BinaryCodec IPv4 ipv4Codec = toBytes $ IPv4 $>> f_version >-< word8 4 >>> f_ihl >-< word8 4 >>> f_dscp >-< word8 6 >>> f_ecn >-< word8 2 >>> f_totalLength >-< word16be 16 >>> f_identification >-< word16be 16 >>> f_flags >-< word8 3 >>> f_fragmentOffset >-< word16be 13 >>> f_timeToLive >-< word8 8 >>> f_protocol >-< word8 8 >>> f_headerChecksum >-< word16be 16 >>> f_sourceIP >-< word32be 32 >>> f_destIP >-< word32be 32 instance Binary IPv4 where get = parse ipv4Codec put = produce ipv4Codec The same types and combinators can be used to make Storable or Binary instances, or used with pretty much any de/serialization library. The implementation only uses a little bit of Template Haskell to generate the f_... structures for each field and the rest is very basic in terms of extensions (no DataKinds or type families needed). Please take a look at the docs and the examples. I'd love to get some feedback before I put it on Hackage. :) All the best, Patrick

1 0

using scoped type variables in proofs...
by Nicholls, Mark 12 May '15

12 May '15

Hello, I have written the below proof as an exercise. I want to explicitly annotate the proof with type variables.....but I cant get a line to work... > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P > data Nat where > Z :: Nat > S :: Nat -> Nat > data SNat (a :: Nat) where > SZ :: SNat 'Z > SS :: SNat a -> SNat ('S a) here a nice plus > type family (n :: Nat) :+ (m :: Nat) :: Nat > type instance Z :+ m = m > type instance (S n) :+ m = S (n :+ m) lets try to do > data val1 :== val2 where > Refl :: val :== val If I prove its abelian then we get it... the "proof" works if we remove the type annotation but I want the annotation to convince myself I know whats going on. > theoremPlusAbelian :: SNat a -> SNat b -> (a :+ b) :== (b :+ a) > theoremPlusAbelian (SZ :: SNat a) (SZ :: SNat b) = > -- forall 0 and 0 > (Refl :: (a :+ b) :== (b :+ a)) > theoremPlusAbelian ((SS a) :: SNat a) (SZ :: SNat b) = > -- forall a + 1 and 0 > case theoremPlusAbelian (a :: (a ~ 'S a1) => SNat a1) (SZ :: SNat b) of > (Refl :: (a1 :+ b) :== (b :+ a1)) -> > (Refl :: (a :+ b) :== (b :+ a)) > theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = > -- forall 0 and a + 1 > case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat b1) of > (Refl :: (a :+ b1) :== (b1 :+ a)) -> > (Refl :: (a :+ b) :== (b :+ a)) > -- cant seem to prove this... > theoremPlusAbelian ((SS a) :: (SNat a)) ((SS b) :: (SNat b)) = > -- forall a+1 and b+1 > -- 1st prove (a + 1) + b = b + (a + 1)...from above > case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => SNat b1) of THE COMMENTED LINE FAILS. Could not deduce ((b1 :+ 'S a1) ~ (a2 :+ 'S a1)) from the context (a ~ 'S a1) bound by a pattern with constructor SS :: forall (a :: Nat). SNat a -> SNat ('S a), in an equation for 'theoremPlusAbelian' at Cafe2.lhs:57:24-27 or from (b ~ 'S a2) bound by a pattern with constructor SS :: forall (a :: Nat). SNat a -> SNat ('S a), in an equation for 'theoremPlusAbelian' at Cafe2.lhs:57:45-48 NB: ':+' is a type function, and may not be injective The type variable 'b1' is ambiguous Expected type: (a :+ a2) :== (a2 :+ a) Actual type: (a :+ b1) :== (b1 :+ a) Relevant bindings include b :: SNat a2 (bound at Cafe2.lhs:57:48) a :: SNat a1 (bound at Cafe2.lhs:57:27) In the pattern: Refl :: (a :+ b1) :== (b1 :+ a) In a case alternative: (Refl :: (a :+ b1) :== (b1 :+ a)) -> case theoremPlusAbelian a (SS b) of { Refl -> case theoremPlusAbelian a b of { Refl -> Refl } } In the expression: case theoremPlusAbelian ((SS a) :: SNat a) (b :: b ~ S b1 => SNat b1) of { (Refl :: (a :+ b1) :== (b1 :+ a)) -> case theoremPlusAbelian a (SS b) of { Refl -> case theoremPlusAbelian a b of { Refl -> ... } } } > -- (Refl :: (a :+ b1) :== (b1 :+ a)) -> > Refl -> > -- now prove a + (b + 1) = (b + 1) + a...from above > case theoremPlusAbelian a (SS b) of > Refl -> > -- now prove a + b = b + a > case theoremPlusAbelian a b of > -- which seems to have proved a + b = b + a > Refl -> Refl CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

3 4

New Functional Programming Job Opportunities
by Functional Jobs 12 May '15

12 May '15

Here are some functional programming job opportunities that were posted recently: Haskell Web Engineer at Front Row Education http://functionaljobs.com/jobs/8823-haskell-web-engineer-at-front-row-educa… Sr. Software Engineer at McGraw-Hill Education http://functionaljobs.com/jobs/8822-sr-software-engineer-at-mcgraw-hill-edu… Cheers, Sean Murphy FunctionalJobs.com

1 0

FFI nested structs - malloc - free
by Proclivis 11 May '15

11 May '15

FFI Gurus, I created a c2hs FFI of a nested C structure, where struct A has a pointer to a struct B. To do so, I used a malloc, but I am unsure if the memory will be freed when the resulting Ptr is freed. The example at this link uses the same technique, so it will serve as an example. https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.h… Line 48 and 51 do the malloc and assign the pointer in the struct, from inside a Storable poke implementation. But, there is no explicit free, nor a finalizer. Will the memory be freed when the Ptr of the Storable is freed? If it is, it implies that some magic keeps track of mallocs inside a poke, and creates finalizers. Or, this example leaks. If it leaks, how do I create a finalizer from inside a poke implementation? Mike

5 8

First Call for Papers for IFL 2015
by publicityifl＠gmail.com 11 May '15

11 May '15

Hello, Please, find below the first call for papers for IFL 2015. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- IFL 2015 - Call for papers 27th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2015 University of Koblenz-Landau, Koblenz, Germany In cooperation with ACM SIGPLAN September 14-16, 2015 http://ifl2015.wikidot.com/ 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 2015 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. Peer-review Following the IFL tradition, IFL 2015 will use a post-symposium review process to produce the formal proceedings. All participants of IFL2015 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. Important dates August 10: Submission deadline draft papers August 12: Notification of acceptance for presentation August 14: Early registration deadline August 21: Late registration deadline September 7: Submission deadline for pre-symposium proceedings September 14-16: IFL Symposium December 1: Submission deadline for post-symposium proceedings January 15, 2016: Notification of acceptance for post-symposium proceedings March 1, 2016: Camera-ready version for post-symposium proceedings Submission details 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 Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2015 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 2015, please contact the PC chair at rlaemmel(a)acm.org. 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 honored 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 Chair: Ralf Lämmel, University of Koblenz-Landau, Germany - Malgorzata Biernacka, University of Wroclaw, Poland - Laura M. Castro, University of A Coruña, Spain - Martin Erwig, Oregon State University, USA - Dan Ghica, University of Birmingham, UK - Andrew Gill, University of Kansas, USA - Stephan Herhut, Google, USA - Zhenjiang Hu, National Institute of Informatics (NII), Japan - Mauro Jaskelioff, CIFASIS/Universidad Nacional de Rosario, Argentina - Frédéric Jouault, ESEO, France - Oleg Kiselyov, Tohoku University, Japan - Lindsey Kuper, Indiana University, USA - Rita Loogen, Philipps-Universität Marburg, Germany - Akimasa Morihata, University of Tokyo, Japan - Atsushi Ohori, Tohoku University, Japan - Bruno C. D. S. Oliveira, The University of Hong Kong, Hong Kong - Frank Piessens, Katholieke Universiteit Leuven, Belgium - Norman Ramsey, Tufts University, USA - Matthew Roberts, Macquarie University, Australia - Manfred Schmidt-Schauss, Goethe-University Frankfurt, Germany - Simon Thompson, University of Kent, UK - Stephanie Weirich, University of Pennsylvania, USA - Steve Zdancewic, University of Pennsylvania , USA Venue The 27th IFL will be held in association with the Faculty of Computer Science, University of Koblenz-Landau, Campus Koblenz. Koblenz is well connected by train to several international airports. For instance, Koblenz can be reached from Frankfurt by high-speed train ICE within an hour. The modern Koblenz campus is close to the city center and can be reached by foot, bus, or cab. See the website for more information on the venue.

1 0

Automatic liftIO or how to write this shorter?
by Gleb Popov 10 May '15

10 May '15

Hello haskell-cafe@ I'm writing a GUI app in Haskell and bindings to the widget toolkit i'm using in parallel. These bindings are very simple and all its functions have return type (IO something). So far so good, i wrote the following code to create an config window: createConfigUI root = do box <- Box.add root -- first field addToPackEnd box =<< do f <- Fr.add box setPartText f Nothing "E-mail" setPartContent f Nothing =<< do box <- Box.add box addToPackEnd box =<< do e <- Ent.add box Ent.singleLineSet e True -- Here onEvent "changed,user" e $ do reactOnUserInput e objectShow e return e objectShow box return box objectShow f return f -- next field addToPackEnd box =<< do ... Initially, i was quite satisfied with flipped bind use for creating UI elements and arranging them. Nested do scopes allow copypasting code without renaming variables and also provide some visual representation on widget hierarchy. But at some point i need to return some stuff from some inner do block into outmost. For example, at the line with comment "Here" i defined let setText t = entrySet e t and wanted to return it from whole createConfigUI action. Moreover, createConfigUI have much more fields, for each of them i want to do the same. My initial thought was to wrap everything with runWriter and just call tell setText wherever i want to gather all setter functions into a list, but i can't do this because i would need to put liftIO before every IO action all over the place. If only there was i way to turn an (IO a) into (MonadIO m => m a), it would be easy. Another solution is to make my bindings return (MonadIO m => m a). This would be equal effort of plugging liftIO's everywhere, but at least it would be hidden from user of bindings. I'd gone this way, but looked at gtk bindings first and found that (IO a) is used there. So, my questions are: 1. What would you recommend in my situation? Is it possible yield values from inner do blocks into outer without much hassle? 2. If there is nothing wrong with switching bindings from (IO a) to MonadIO typeclass, why not to do this for gtk, wxWidgets and nearly every FFI binding? Thanks in advance.

2 3