July 2019 - Haskell-Cafe

Workshop in OCL and Textual Modeling (OCL 2019) - Deadline Extension
by Achim D. Brucker 14 Jul '19

14 Jul '19

CALL FOR PAPERS 19th International Workshop on OCL and Textual Modeling Co-located with MODELS 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and System, September 15-20, 2019, Munich, Germany http://oclworkshop.github.io ******************************************************************* **** Deadline Extension: One week (21st of July, 2019 - AoE) **** **** left to submit your papers! **** ******************************************************************* 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 (e.g., OCL, textual MOF, Epsilon, or Alloy) 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 Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - 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) - Model-driven security using textual modeling languages - 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 We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Submissions Four types of submissions will be considered: * Presentation only submission (not included in the workshop proceedings), e.g., for already published work. Authors should submit a short (1 page) abstract of their presentation. * Short papers (between 5 and 7 pages) describing new ideas or position papers. * Tool papers (between 5 and 7 pages) describing tools supporting textual modeling tools * Full papers (between 10 and 14 pages). All submissions should follow the LNCS format guidelines and should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2019). Accepted papers will be published online in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: 21 Jul 2019, AoE (extended) - Notification: 25 Aug 2019, AoE - Pre-Workshop CRC: 9 Sep 2019, AoE - Post-Workshop CRC: 5 Oct 2019, AoE -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Re: [Haskell-cafe] "Quantization" of computations, or step-wise termination, as an extension of Logic Monads
by Olaf Klinke 12 Jul '19

12 Jul '19

Dear Juan, Is the following problem of the class you are considering? Given a predicate p :: (Integer -> Integer) -> Bool enumerate all functions f :: Integer -> Integer for which p f == True. The search space (Integer -> Integer) can be rendered into a tree of infinite width and depth: On the first level, branch on the value of f(0), on the next level branch on the value of f(1) and so forth. If the above problem were tractable, then you'd have an enumeration of the real numbers. If the target is to find whether there is at least one such f, then you have proven compactness of Baire space. So there must be something about your problem that remained unclear to me. Care to explain? Regards, Olaf P.S.: Infinite branching trees could be modeled as data Tree a = Tree (Integer -> Maybe (a,Tree a)) Maybe this can help bringing your algorithms closer to the literature on computable functions and recursion theory.

2 1

Huffman Library Maintainership
by Callan McGill 12 Jul '19

12 Jul '19

The huffman library (http://hackage.haskell.org/package/huffman) is very useful, but unfortunately hasn't been maintained in several years and does not compile with new versions of the containers library. We are incorporating huffman encoding as part of the American Museum of Natural History's PCG project (https://github.com/amnh/pcg) We have a locally "repaired" version of the huffman library that we have used in a prototype and would like to share the updates with the Haskell community. Nine months ago I contacted Maxime Henrion, the listed maintainer of the huffman library, about a pull request to incorporate the changes or taking up maintainership responsibility, whatever they would prefer to update the library and share the huffman encoding library updates with the rest of the community. Unfortunately I didn't receive any response from them. Per the listed protocol for requesting maintainership of a hackage package if the current maintainer cannot be reached ( https://wiki.haskell.org/Taking_over_a_package#If_you_cannot_contact_the_au…) I'm letting the Haskell community know that I am quite interested in taking over maintainership of the huffman library. I intend to update the library to compile with new versions of GHC and updated versions of the containers package. ~Alex Washburn, (recursion-ninja)

1 0

Haskell Symposium: early reg deadline is next week
by Richard Eisenberg 12 Jul '19

12 Jul '19

The early registration deadline is **18 July**. That's next week! Accepted papers are at https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview We will have two keynotes: • Mary Sheeran, of Chalmers University, will present Gender Equality in Academia: Meeting the Challenge on Thursday, 22 August. • Lennart Augustsson and Satnam Singh, both of Google Research, will co-present Haskell Use and Abuse at Scale on Friday, 23 August. Come join! Symposium details are below. I hope to see you there! Richard ================================================================================ ACM SIGPLAN CALL FOR PARTICIPATION Haskell Symposium 2019 Berlin, Germany 22--23 August, 2019 https://icfp19.sigplan.org/home/haskellsymp-2019 ================================================================================ The ACM SIGPLAN Haskell Symposium 2019 will be co-located with the 2019 International Conference on Functional Programming (ICFP). The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * System Demonstrations, based on running software rather than novel research results.

1 0

Fwd: CFP: 4th Workshop on Meta-Programming Techniques and Reflection (Meta’19), Co-located with SPLASH 2019
by Artem Pelenitsyn 12 Jul '19

12 Jul '19

---------- Forwarded message --------- De: Guido Chari <charig(a)gmail.com> Date: vie., 12 jul. 2019 a las 12:22 Subject: CFP: 4th Workshop on Meta-Programming Techniques and Reflection (Meta’19), Co-located with SPLASH 2019 To: <seworld(a)sigsoft.org> ======================================================================== Call for Papers 4th Workshop on Meta-Programming Techniques and Reflection (Meta’19) Co-located with SPLASH 2019 October 20, 2019, Athens, Greece https://2019.splashcon.org/track/meta-2019 Follow us on twitter @MetaAtSPLASH ======================================================================== The Meta’19 workshop aims to bring together researchers working on metaprogramming and reflection, as well as users building applications, language extensions and/or software tools using them. The challenges which metaprogramming faces are manifold. They start with formal reasoning about reflective programs, continue with performance and tooling, and reach into the empirical field to understand how metaprogramming is used and how it affects software maintainability. While industry accepted metaprogramming on a wide scale with Ruby, Scala, JavaScript, R and others, there is still a long road ahead to bring the same level of convenience, tooling, and understanding as for direct programming styles. Contributions to the workshop are welcome on a wide range of topics related to the design, implementation, and application of metaprogramming techniques, as well as empirical studies and formal methods for such systems and languages. ### Topics of Interest The workshop is a venue for all approaches that embrace metaprogramming, from static to dynamic techniques: - reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs - optimization techniques - contract systems, or typing of reflective programs - reflection and metaobject protocols to enable tooling - case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools - empirical evaluation of metaprogramming solutions - security in reflective systems and capability-based designs - meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) - surveys, conceptualization, taxonomization, and formalization of existing approaches ### Workshop Format and Submissions This workshop welcomes the presentation of new ideas and emerging problems as well as mature work as part of a mini-conference format. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. Papers submitted by the first deadline will be considered for publication in the ACM DL, if not requested otherwise by the authors. Thus, they will be part of SPLASH workshop proceedings. For all papers, use of the SIGPLAN acmart style is mandatory: http://www.sigplan.org/Resources/Author/. Please use the provided double-column templates for Latex or Word. technical paper: max. 8 pages, excluding references position and work-in-progress paper: 1-4 pages, excluding references technology demos or a posters: 1-page abstract Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work, but will not be considered for publication in the ACM DL. For the submission, please use the submission system at: https://meta19.hotcrp.com/ ### Important Dates (TODO) 26 Jul 2019 - Abstract Submission 2 Aug 2019 - Paper Submission (considered for ACM DL) 23 Aug 2019 - Notification 28 Aug 2019 - Demo, position or work-in-progress paper submission 20 Sep 2019 - Demo, position or work-in-progress paper notification ### Steering Committee Elisa Gonzalez Boix, Vrije Universiteit Brussel Stefan Marr, University of Kent ### Organizing Committee Guido Chari, Czech Technical University Christophe Scholliers, Ghent University ### Program Committee Nada Amin, University of Cambridge, UK Edwin Brady, University of St Andrews, UK Andrei Chis, Feenk, Switzerland David Thrane Christiansen, Galois, Portland, Oregon, USA Tom Van Cutsem, Bell Labs, Belgium Ryan Culpepper, Czech Technical University, Prague, Czechia Jennifer Hacket, University of Nottingham, UK Robert Hirschfield, Hasso Plattner Institute, Germany James Noble, Victoria University Wellington, New Zealand Bruno C. d. S. Oliveira, The University of Hong Kong Cyrus Omar, University of Chicago, USA Guillermo Polito, Inria Lille, France Eric Tanter, Universidad de Chile, Chile ### Contact Information For further inquiries, do not hesitate to contact the organizers via meta-at-splash19 AT googlegroups.com http://2019.splashcon.org/track/meta-2019 -- You received this message because you are subscribed to the Google Groups "PRL-jv" group. To unsubscribe from this group and stop receiving emails from it, send an email to PRL-jv+unsubscribe(a)googlegroups.com. To post to this group, send email to PRL-jv(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/PRL-jv/CAO4Coc-WQ21XZQNPLCiXCE2ZTXoPYT4i7… <https://groups.google.com/d/msgid/PRL-jv/CAO4Coc-WQ21XZQNPLCiXCE2ZTXoPYT4i7…> . For more options, visit https://groups.google.com/d/optout.

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 191, Issue 7
by Information The FLOSS 12 Jul '19

12 Jul '19

Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/

1 0

"Quantization" of computations, or step-wise termination, as an extension of Logic Monads
by Juan Casanova 12 Jul '19

12 Jul '19

Dear all, I just subscribed to this list so I'm not familiar with the usual way to go about things here. I hope you'll excuse any cultural mistakes I might make. I'll also try to keep this message as short as possible, but this is hard for me and it is a complex topic, so I will presumably fail. Apologies for that in advance. Short introduction. I'm a PhD student at University of Edinburgh. My research is not on programming languages itself, but during the course of it I ended up programming in Haskell and more particularly faced a problem that I developed a strategy (and eventually a library) for. After some discussions with my supervisors and with some more Haskell experienced people around university, they suggested that I looked into some existing work and also that I posted on this list, and here I am. Let me introduce the problem that I'm trying to solve itself. I have a particular (yet somehow typical) case of non-determinism (search) in the program that I have been writing. It is characterized by: - No joining back of branches ever. - Potentially infinite depth (this is usual). - Potentially infinite width. Meaning that at a single point I may have an infinite amount of possible paths to follow. - It is critical that the search is complete. After reading a bit, I have realized this is usually referred to as being a fair search order. For me this means that there can be many (infinite) valid solutions in the search space, and I want to find all of them (i.e. for every valid solution, the program will eventually output it). As I said, I developed my own (particular) approach to this, then generalized it in a library, and then, after talking to some people, realized this might be something quite interesting to share, but first had to check that it's not something that has already been done. Long story short, the most relevant piece of research I was pointed to was "Backtracking, interleaving and terminating monad transformers", by O Kiselyov, C Shan, DP Friedman and A Sabry, published in 2005. (https://dl.acm.org/citation.cfm?id=1086390) I also know that this approach is embodied in Haskell through the Control.Monad.Logic library. I read the paper and skimmed through some related work, and gave a try to the library. Indeed, it seems to be doing mostly what I need. In particular, it can deal with infinite breadth/infinite width searches through a process of what I call "diagonalization". That is, a combination of breadth-first and depth-first that ensures fairness. Note that the library actually does a lot more things that I didn't consider because they were not relevant for my problem, for instance cuts. However, I find that there is something that this library does not take into account, and after trying with the Haskell library I have verified that indeed it does not work, whereas my library does work. I am wondering if I have overlooked some work in which this is also taken into account or if I may be onto some useful extension of Control.Monad.Logic that hasn't been done yet. I still have to find a stable name for the feature that I am talking about, but I usually refer to it as "step-wise termination" or "quantization of computations". To understand it consider an example (that I have actually implemented): 1. Whenever I have a non-deterministic enumeration, I should have a way to output a fair search among that non-deterministic search (a list), following the properties that I indicated above. 2. I can make an enumeration that non-deterministically produces all multiples of a certain number. 3. I can make an enumeration that non-deterministically produces all powers of a certain number. 4. I can make a function that, given an enumeration, filters it through a boolean function. 5. I can monadically combine computations, so that I can, for instance, produce a computation that is the result of producing all multiples of a number, and for each of those, producing all their powers. 6. So what happens if I combine the three of them. In particular, what if I output all *odd* powers of all multiples of 1 (all naturals)? (multiples 1) >>= (\x -> filter odd (powers x))? If I do this using the Control.Monad.Logic library (and using the >>- operator provided there, of course), this does not produce a fair search. Specifically, it outputs 1 and then hangs up. The reason? The order in which the search is produced picks one value from each sublist at a time, but because there are no odd powers of an even number (say 2), it never finds any element in the sublist of powers of 2, and therefore never gets to even try with the powers of 3. My library can deal with this by "quantizing" computation, making sure that each individual step of a computation always terminates (in Haskell terms, I wrap things up in a way that I can guarantee that a single look-ahead on the list will always produce a head normal form in finite time, even if that is still a continuation of the computation). Therefore, while it keeps trying to find powers of 2 that are odd, this does not stop the search over all the other sublists. This mail is already quite long, but let me make a few precisions. You may stop reading here if you don't wanna get your hands dirty, I've said the most important bits. I know a bit of what I say here will be confusing if you don't think about it yourself, so skip it if it gets confusing. It's mainly to answer some questions/comments I can foresee. Of course, this only works if the embedding into the monad is terminating itself. So, when you do "pure x" for my monad, you need to guarantee that "x" will produce a head normal form in finite time). But as long as you guarantee this atomic notion and you only use the monadic transformation functions that are not labelled as "unsafe" (which are only the unnatural ones for the semantics that I am considering, such as appending in a list sense), then I can guarantee the search will always be fair. Also, a thing I've been thinking quite a bit is whether you can consider this notion of "quantization" of computation separately from the notion of an enumeration of a non-deterministic search space. Of course you can, but the interesting bit is to do this diagonalization over non-deterministic search spaces in a quantized way so that rabbit holes like the odd powers of 2 are not a problem. I tried to implement this in a generic way that you can later on "combine" with Control.Monad.Logic in a non-specific way, but it won't work, due to the particular reason that you'd need to do pattern matching over the structure of the logic monad, and there's no way to type check that for an arbitrary data type (because the pattern matching could give literally any potential sub-types). Implementing the quantization separately and then the combination individually as a one-of thing could be done, of course, but it would essentially be the same that I have right now. A different story would be had if ghci actually had monadic functions to enable the evaluation of *any* thunk one-step-at-a-time (that is, one function evaluation or one pattern match). This is absolutely not what seq does, because seq evaluates until it is a weak head normal form, which is not what I want. Precisely, bottom seq a = bottom, and my quantized computation does not fulfill this equation (and it should not). My library is not perfect now, and after having read and understood the Control.Monad.Logic library, I think the best thing would be to extend it, which is something I don't do right now. But still so, unless I have missed an already existing implementation of something like this, or I am seeing something in a really convoluted way. Please feel free to drop any questions or comments at all. I'm attaching an example of why Control.Monad.Logic does not work in the case that I said. It also includes an example using my library, which I am not attaching. This example works. Just comment it. I'm not attaching my library now because it's not "polished" and because it is a lot for people to randomly look at, but feel free to ask for it and I'll happily send it over, so that you can run the example with it. Again, any questions or comments are welcome. Lead me the right direction with this. ... And sorry for the wall of text. Thank you very much for all of your time and attention, Juan Casanova. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 3

Hidden types and scope
by Lana Black 11 Jul '19

11 Jul '19

Hello cafe, While writing some code, I stumbled upon quite an interesting behavior. See the code example below. ------------------------------------------------------------- {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE RankNTypes #-} data Wrapper = forall m. Monad m => Wrapper { runAction :: forall a. m a -> IO a , someAction :: String -> m () } newtype MyIO a = MyIO { runIO :: IO a } deriving (Monad) ex :: Wrapper ex = Wrapper runIO (\s -> MyIO (putStrLn s)) {- This doesn't work -} --main :: IO () --main = do let Wrapper r a = ex -- r (a "Hello") {- This works -} main :: IO () main = case ex of Wrapper r a -> r (a "Hello") ------------------------------------------------------------- The idea is to hide the exact type `m` used in the wrapper, making the wrapper somewhat opaque to the user, while exposing some functionality and making sure that using `runAction` with the rest of the members of Wrapper is type-safe and `m` is always the same type within one instance of Wrapper. The problem that I ran into is that the first version of `main` doesn't compile with the following error: • Couldn't match expected type ‘p’ with actual type ‘forall a. m a -> IO a’ because type variable ‘m’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: Wrapper :: forall (m :: * -> *). Monad m => (forall a. m a -> IO a) -> (String -> m ()) -> Wrapper, in a pattern binding at wildcards.hs:18:15-25 • In the pattern: Wrapper r a In a pattern binding: Wrapper r a = ex In the expression: do let Wrapper r a = ex r (a "Hello") This is repeated for every member of Wrapper that is matched in a let expression. However, if let expression is replaced with case, everything builds and works just fine. Is there a way to make it work with let expressions? That way the code is a lot cleaner, especially with RecordWildCards involved.

4 5

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 191, Issue 6
by Information The FLOSS 11 Jul '19

11 Jul '19

Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/

1 0

[ldap-client] Project takeover initiation
by Brian C. Jones 10 Jul '19

10 Jul '19

Hello, I have attempted to contact the author via PR and direct email with no response in 3 weeks. This is my final attempt before engaging the Hackage admins. https://github.com/supki/ldap-client/pull/16 Brian Jones

1 0