May 2017 - Haskell-Cafe

Deadline extension may 15: Trends in Functional Programming, 19-21 june 2017, University of Kent, Canterbury
by Peter Achten 08 May '17

08 May '17

TFP 2017 EXTENSION: Deadline extension until Monday, 15 May (anywhere on earth). -------------------------------------------------------------------------------- We encourage anyone who wants to present their work at TFP in Canterbury, England this June to submit a 2-10 page abstract if time is too short to put together a full paper. ----------------------------- F I N A L C A L L F O R P A P E R S ----------------------------- ======== TFP 2017 =========== 18th Symposium on Trends in Functional Programming 19-21 June, 2017 University of Kent, Canterbury https://www.cs.kent.ac.uk/events/tfp17/index.html The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. TFP 2017 will be the main event of a pair of functional programming events. TFP 2017 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on 22 June. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in * Edinburgh (Scotland) in 2003; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * Soesterberg (The Netherlands) in 2014; * Inria Sophia-Antipolis (France) in 2015; * and Maryland (USA) in 2016. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/) == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2017 program chairs, Scott Owens and Meng Wang. == BEST PAPER AWARDS == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == PAPER SUBMISSIONS == Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which ALL authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. We use EasyChair for the refereeing process. Papers must be submitted at: https://easychair.org/conferences/?conf=tfp17 Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site: http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0 == INVITED SPEAKERS == Conor McBride University of Strathclyde (UK) Cătălin Hriţcu INRIA Paris (FR) == IMPORTANT DATES == Submission of draft papers: ***15 May, 2017*** extension Notification: 12 May, 2017 Registration: 11 June, 2017 TFP Symposium: 19-21 June, 2017 Student papers feedback: 29 June, 2017 Submission for formal review: 2 August, 2017 Notification of acceptance: 3 November, 2017 Camera ready paper: 2 December, 2017 == PROGRAM COMMITTEE == Co-Chairs Meng Wang University of Kent (UK) Scott Owens University of Kent (UK) PC Jeremy Yallop University of Cambridge (UK) Nicolas Wu University of Bristol (UK) Laura Castro University of A Coruña (ES) Gabriel Scherer Northeastern University (US) Edwin Brady University of St Andrews (UK) Janis Voigtländer Radboud University Nijmegen (NL) Peter Achten Radboud University Nijmegen (NL) Tom Schrijvers KU Leuven (BE) Matthew Fluet Rochester Institute of Technology (US) Mauro Jaskelioff CIFASIS/Universidad Nacional de Rosario (AG) Patricia Johann Appalachian State University (US) Bruno Oliveira The University of Hong Kong (HK) Rita Loogen Philipps-Universität Marburg (GE) David Van Horn University of Marylan (US) Soichiro Hidaka Hosei University (JP) Michał Pałka Chalmers University of Technology (SE) Sandrine Blazy University of Rennes 1 - IRISA (FR)

1 0

[ANN] New release of SBV, now with optimization
by Levent Erkok 08 May '17

08 May '17

I'm happy to announce a new release of SBV (v6.0); a library for seamlessly integrating SMT solvers with Haskell: http://hackage.haskell.org/package/sbv <https://hackage.haskell.org/package/sbv> This version brings optimization features to SBV, where arithmetic goals can be minimized or maximized. The algorithms employed are particularly suitable for linear-optimization problems, over bounded/unbounded integers and reals. Multiple objective functions with optimization priorities are also supported: http://hackage.haskell.org/package/sbv-6.0/docs/Data-SBV.html#g:44 Objective values that assume their optimal values at infinity and epsilon are also supported, allowing the user to express arbitrary combinations of goals. Furthermore, soft-goals (i.e., those that can be violated with a user-specified penalty) are included as well. Such goals can be used to expressed "nice-to-have" constraints, for instance as they appear in classic scheduling problems. (Optimization is currently only supported by the z3-backend, and leverages the features of the z3 SMT solver. Please make sure you get a fresh copy of it from github <https://github.com/Z3Prover/z3>.) A few basic examples: - Basic linear optimization over reals <https://hackage.haskell.org/package/sbv-6.0/docs/Data-SBV-Examples-Optimiza…> - Workshop product allocation <https://hackage.haskell.org/package/sbv-6.0/docs/Data-SBV-Examples-Optimiza…> - Allocating virtual-machines in data-centers <https://hackage.haskell.org/package/sbv-6.0/docs/Data-SBV-Examples-Optimiza…> This release also comes with a number of other changes/features, including support for user given tactics, mainly aimed for advanced users. See here <https://hackage.haskell.org/package/sbv-6.0/changelog> for details. Bug reports, as always, are most welcome. -Levent.

1 0

Re: [Haskell-cafe] Seeking Help with IHaskell Maintenance/Development
by Jonathan Wheaton 07 May '17

07 May '17

As a Haskell newbie and someone who uses IHaskell as a way of exploring Haskell from anywhere (work, various laptops and Chromebooks at home, my mobile phone even), I would be really sad to see IHaskell go away. I'm very much hoping the project can find a maintainer, as it's been invaluable to me. Jonathan Wheaton On May 7, 2017 11:52 AM, "Andrew Gibiansky" <andrew.gibiansky(a)gmail.com> wrote: Hey folks, For the past several months, I have not been able to put any effort into maintaining IHaskell, a front-end for Jupyter for Haskell. I do not know how useful IHaskell has been in the past to the community, but as it becomes more and more outdated it becomes less useful. If anyone is interested in helping out (or taking over) IHaskell maintenance and development, please let me know. Best, Andrew -- – Andrew _______________________________________________ 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 0

[ANN] ble: Bluetooth Low Energy in Haskell
by Julian K. Arni 07 May '17

07 May '17

Dear list, I've released the package 'ble' a little while ago, but hadn't announced it so far because I wanted to make sure the API stabilized somewhat, and at least some bugs were addressed, in the course of dealing with our own needs. But now feels like a good time to announce it. 'ble' allows writing Bluetooth Low Energy peripherals in Haskell (and soon, centrals too). Currently only Linux (with Bluez >= 5.41) is supported. Mostly it exposes the GATT API. The README (in the github repo and in the Hackage main page) provide a simple example application. Github: https://github.com/plow-technologies/ble Hackage: http://hackage.haskell.org/package/ble Enjoy, ~~~ Julian Arni Haskell Consultant https://turingjump.com/

1 0

Seeking Help with IHaskell Maintenance/Development
by Andrew Gibiansky 07 May '17

07 May '17

Hey folks, For the past several months, I have not been able to put any effort into maintaining IHaskell, a front-end for Jupyter for Haskell. I do not know how useful IHaskell has been in the past to the community, but as it becomes more and more outdated it becomes less useful. If anyone is interested in helping out (or taking over) IHaskell maintenance and development, please let me know. Best, Andrew -- – Andrew

1 0

Partial type family application
by mniip 06 May '17

06 May '17

So I've been thinking of a type system extension: partial type family application. If we look at the type system used by modern GHC, in it, type family application is very distinct from constructor/constraint application: it is somewhat opaque in the sense that a type family must always appear fully applied. As such, it doesn't make sense to talk about a type family's kind, if we have: type family Id (a :: *) :: * where Id x = x then saying that 'Id :: * -> *' would be wrong, because Id cannot be used interchangeably with things that are truly of kind * -> *, such as Maybe or []. The reason for the "fully applied" restriction is that if we allowed partially applied type functions, then their equality would be undecidable. Still, I think, in a lot of cases we could benefit from partially applied type functions, even without extensional equality. Writing type level list folds, filters, zips, you name it. As stated above, we can't add the proposition 'Id :: * -> *' to our type system, so, what if, instead, we added a different kind of arrow kind for type families? I like the look of (~>), so 'Id :: * ~> *'. (~>) :: * -> * -> * This rule of inference, similar to the usual, would supersede all the type family kinding rules: f :: k ~> l, x :: k ------------------- f x :: l As such, the juxtaposition operator would very clearly have two different "kinds": (k -> l) --> k --> l and (k ~> l) --> k --> l, and there is no N-ary "type family application" operator. In order for the type checker to not fall apart, we need to have at least intesional (structural) equality on (~>), which we can have because it is decidable. We could then write stuff like type family Foldr (f :: k ~> l ~> l) (z :: l) (xs :: [k]) :: l where Foldr f z '[] = z Foldr f z (x ': xs) = f x (Foldr f z xs)

4 8

Generalized concatMap for lenses?
by Tyson Whitehead 06 May '17

06 May '17

I am writing some code to do some web-page parsing using the lens library. The folded (or traverse) functions let me go sequence -> lens fold It would be nice to be able to go back again lens fold -> sequence The general idea being move it into a lens-fold sequence representation, work with it there, and then recover the original sequence representation. As a more concrete example, the following works for lists (folded .) :: Getter s [a] -> Fold s a (to . toListOf) :: Fold s a -> Getter s [a] I think I'm maybe thinking of something like a generalized concatMap for lenses magic :: Fold s a -> Getter (f s) (f a) Possibly there is already a function for this or some other way it should be done? Haven't found it yet though, so thought I would ask the list for some enlightenment. Thanks! -Tyson

1 0

Functor instance for FunPB
by Alex Wede 06 May '17

06 May '17

Hey Everyone, ich have a algebraic data type: data FunPB a b = FunPB { runFunPB :: a -> (a,[b]) } I got a Monoid Instance instance Monoid (FunPB a b) where mempty = FunPB $ \k -> (k,mempty) mappend pb1 pb2 = FunPB $ \n -> (,) n $ msum . (<$>) (uncurry (flip const).((flip runFunPB) n)) $ [pb1,pb2] Now I need to write a functor instance instance Functor (FunPB a) where fmap f b = ? How can I map over a->(a,[b])? Lg Alex

6 7

Hunting for ghci manual input vs. file input differences again
by MarLinn 05 May '17

05 May '17

Hi, I've been working on a kind of constrained version of Data.Dynamic: data Dynamic (c :: * -> Constraint) where Dynamic :: (Typeable a, c a) => a -> Dynamic c The idea is that Data.Dynamic gives up all compile time type information. In this variant I can at least keep a bit of the information around that I have. (In fact I can even "lift" a type into a constraint, thereby keeping /all/ information.) Most of my functions are nailed down, including mappings and traversals. But one group of functions eludes me: functions to change only the constraint, while keeping the value. Here is one of my goal types: castDynamic :: ( Typeable a, c a, d a ) => Dynamic c -> Dynamic d I'm pretty sure I'll have to sprinkle in a Proxy a, but so be it. I've thrown all typing tricks at this function that I know of, from unsafeCoerce over case-of instead of pattern matching, to ScopedTypeVariables. But I couldn't convince ghci to accept my code. So I tried something simpler. castDynamic' :: (Typeable a, c a) => Dynamic Show -> Maybe (Dynamic c) Here's where it gets funny: I can implement this function in ghci interactively just fine. >>> :t \(d :: Dynamic Show) -> case d of Dynamic a -> Dynamic <$> cast a \(d :: Dynamic Show) -> case d of Dynamic a -> Dynamic <$> cast a :: (Typeable a, c a) => Dynamic Show -> Maybe (Dynamic c) But when I enter the exact same code in a file and load it, ghci balks at me because a is too ambiguous. Again, I've tried if it's the monomorphism restriction, or if I need to sprinkle in more (scoped) signatures or explicit forall's etc… nothing helped. What is the difference here? Am I missing an extension? Am I doing something I shouldn't and the interactive mode is just doing me a favor? There was a discussion on this list less than a month ago where it was mentioned that ghci handles polymorphic types differently depending on the source of the code. Is there some documentation on these differences? Any help would be appreciated. Cheers, MarLinn

3 3

http-client(-tls) or http-conduit?
by Baojun Wang 05 May '17

05 May '17

Hi cafe, It seems both(all) packages are actively maintained, however, they seem to provide a lots of similar functionalities, is there any preferences to use any one of them, and the reason why (Personally I'd prefer the former because of familiarity)? I've read [ https://haskell-lang.org/library/http-client] but it doesn't have recommendation. Thanks baojun

2 2