July 2018 - Haskell-Cafe

Fwd: [livecode] haskell-art is back
by Alfred Matthews 08 Jul '18

08 Jul '18

Here. ---------- Forwarded message --------- From: Alex McLean <alex(a)slab.org> Date: Sun, Jul 8, 2018, 5:16 PM Subject: [livecode] haskell-art is back To: livecode <livecode(a)we.lurk.org> I finally found some time to recreate the haskell-art list here: https://we.lurk.org/postorius/lists/haskell-art.we.lurk.org/ So vivid and other in-depth haskell discussion can move back there. Cheers ! -- blog: http://slab.org/ _______________________________________________ Livecode mailing list -- livecode(a)we.lurk.org To unsubscribe send an email to livecode-leave(a)we.lurk.org -- Alfred.

1 0

Call for paper: Only one *week* left to prepare your paper for the Workshop in OCL and Textual Modeling (OCL 2018)
by Achim D. Brucker 08 Jul '18

08 Jul '18

(Apologies for duplicates) ********************************************************** ** Only one week left until the submission deadline! *** ********************************************************** CALL FOR PAPERS 18th International Workshop on OCL and Textual Modeling Co-located with MODELS 2018: ACM/IEEE 21th International Conference on Model Driven Engineering Languages and System, October 14, 2018, Copenhagen, Denmark http://oclworkshop.github.io Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but they have weaknesses: for example, detailed visual representations bear the risk of becoming overcrowded faster than textual models and some of the visual features lack the level of precision required to create complete and unambiguous specifications. These weaknesses of 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 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. ## Venue This workshop will be organized as a part of MODELS 2018 Conference in Copenhagen, Denmark. 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 Two types of papers will be considered: * Short contributions (between 5 and 7 pages) describing new ideas, innovative tools or position papers. * Full papers (between 10 and 14 pages). in LNCS format. Submissions should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2018). 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, as part of the MODELS workshop proceedings, in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: July 17, 2018 - Notification: August 17, 2018 - Workshop date: October 14, 2018 -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Re: [Haskell-cafe] Bool is not...safe?!
by Olaf Klinke 08 Jul '18

08 Jul '18

Indeed, why use Bool when you can have your own algebraic datatype? Why not data Equality = Equal | NotEqual (==) :: Eq a => a -> a -> Equality when we have essentially the same for 'compare' already? Why not use data Result = Success | Failure as the return type of effectful code? Equality and Result are Booleans with some provenance. But wait! Equality does not come with all the nice functions like (||) and (&&), and Failure still does not tell us what exactly went wrong. Maybe a derivable type class IsomorphicToBool could remedy the former problem. For the latter, Haskell has exception monads. One of the things I love about Haskell is that I do not have to use Int as a return type and remember that negative numbers mean failure of some sort, or worse, the return type is Void but some global variable may now contain the error code of the last function call. In some post in haskell-cafe which I am unable to find right now it was mentioned that the GHC source contains many types that are isomorphic but not equal to Bool. Does anyone know whether the C and C++ folks are now using more informative structs as return types? Cheers, Olaf

7 11

Re: [Haskell-cafe] Bool is not...safe?!
by Olaf Klinke 07 Jul '18

07 Jul '18

>But in Prolog every piece of code is evaluated to TRUTH or to FALSE. Each sentence is a goal which can be achieved and becomes a fact >or can not be – and becomes lie. So, if you inverse semantic in Haskell – program is compiled although with strange behaviour but in >Prolog program become lie. Prolog evaluation model has clean definition in run-time too, not only at compile-time. Execution of >Prolog program is a CHECK: is it truth or lie? I have only very limited Prolog pratice. But what you state about Prolog's semantics is only true for very simple cases, isn't it? As soon as I/O is involved, things get messier. Also, there are actually three outcomes as far as I know: provably true, provably false and "could not be proved" which is different from "false". When I anticipate an exception in an application where the condition prohibits the program from fulfilling its purpose, I simply call error. A common pattern I use is a library function that has return type (Either SomeErr Value), and the application takes it and wraps the result in either (error.show) return, transforming (Either SomeErr Value) into (IO Value). For libraries, one should be more careful, as we don't know what kind of environment the function might be called in - see Joachim Durchholz's post. Olaf

1 0

Re: [Haskell-cafe] Bool is not...safe?!
by Olaf Klinke 07 Jul '18

07 Jul '18

> >> true = return () >> (&&) = liftM2 const >> (||) = mplus >> false = mzero > > I don't think it's by definition yet, but surely by convention, that > this is a restricted form of > > true = pure () > (&&) = (<*) > (||) = (<|>) > false = empty > > All of these functions require only an Applicative or an Alternative, > and except for "true", they're all in the library. True, and after sending I realized I should have used exaclty the definitions you gave. It's just that I don't know whether there exists the concept of "commutative applicative". It is equired for (&&) to be commutative. How could one even state it without the monad bind? The following definitions are from a category theory paper [1] by Anders Kock. import Control.Monad -- tensorial strengths t'' :: (Functor m) => a -> m b -> m (a,b) t'' a mb = fmap (\b -> (a,b)) mb t' :: (Functor m) => m a -> b -> m (a,b) t' ma b = fmap (\a -> (a,b)) ma -- so-called linear extensions in the first and second argument linearext1 :: Functor m => (m c -> c) -> (a -> b -> c) -> m a -> b -> c linearext1 struct f ma b = struct $ (fmap $ uncurry f) $ t' ma b linearext2 :: Functor m => (m c -> c) -> (a -> b -> c) -> a -> m b -> c linearext2 struct f a mb = struct $ (fmap $ uncurry f) $ t'' a mb The first argument to linearext1 and linearext2 is called a "structure map" in the context of [1]. Such structure maps exist when m is a monad. Indeed, we have linearext1 join t'' :: (Monad m) => m a -> m b -> m (a, b) linearext2 join t' :: (Monad m) => m a -> m b -> m (a, b) Now m is called commutative if the above two maps are the same [*]. But join does not exist for applicative functors, it is interdefinable with (>>=). Olaf [1] Anders Kock: "Commutative Monads as a Theory of Distributions". Theory and Applications of Categories, Vol. 26 No. 4 (2012). [*] They are called Fubini maps because a special case is Fubini's theorem about integration by parts.

1 0

ANN: network-2.7.0.2
by evan＠evan-borden.com 07 Jul '18

07 Jul '18

Announcing network-2.7.0.2 * Removing withMVar to avoid the deadlock between "accept" and "close" [#330](https://github.com/haskell/network/pull/330) * "close" does not throw exceptions. A new API: "close'" throws exceptions when necessary. [#337](https://github.com/haskell/network/pull/337) * Fixing the hang of lazy sendAll. [#340](https://github.com/haskell/network/pull/340) * Installing NetDef.h (#334) [#334](https://github.com/haskell/network/pull/334) Thank you to network contributors for this bug fix release. -- Evan Borden

1 0

ANN: network-2.6.3.6
by evan＠evan-borden.com 07 Jul '18

07 Jul '18

Announcing network-2.6.3.6 This is a bug fix release for the 2.6 branch of network. * Removed unnecessary withMVar, which caused locking on close. [#330](https://github.com/haskell/network/pull/330) Thank you to network contributors for finding and diagnosing the bug. -- Evan Borden

1 0

[GSoC 2018] Benchmarking Haskell graph libraries
by Alexandre Moine 06 Jul '18

06 Jul '18

[ Results are here: https://github.com/haskell-perf/graphs/tree/master/results/ ] Hi, I am french 2nd year student in maths and computer sciences and I am running a {Google,Haskell} Summer of Code now. One of my goals is to write a benchmarking suite for graphs libraries in Haskell (Fgl, Alga, Containers and Hash-Graph) and I reached a state where I can produce reasonable numbers. If you are interested, I have wrote a little blog article explaining the results I obtained: https://blog.nyarlathotep.one/2018/07/benchmarking-haskell-graph-libraries/ Feel free to comment or to send feedback on the Github :) -- Alexandre Moine

1 0

Bool is not...safe?!
by PY 06 Jul '18

06 Jul '18

Hello, Cafe! There is an opinion that Bool type has problems. It's "dangerous", because it's not good to be used as flag for success/fail result. I read this post: https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and was shocked. How popular is such opinion? Is it true, that bool is "bad" type? As I understand arguments of the post, Bool is bad because: 1) you don't know what does True/False mean 2) after comparison you get bit (!) only but then you may need to "recover" the comparing value which was "shrink" to bit already. Let's begin from 2. As I understand the author talks about one register computers ;) if he have to "recover" a value. But shown examples are in ML, where function arguments are bound to all function body, so you don't need to "recover" anything, what was bound as function argument or with "let". Sounds totally weird and more close to psychology than to CS :) Argument #1 is more interesting. A Boolean,/b/, is either*true*, or *false*; that’s it. There is no/information/carried by a Boolean beyond its value, and that’s the rub. As Conor McBride puts it, to make use of a Boolean you have to know its/provenance/so that you can know what it/means./ Really, what does True/False mean? How to find semantic of True? It's very simple, because there is A) contract/interface which interprets True/False and also B) there is a help from science. A) There are a lot of languages (Unix shell, ML, Basic, Haskell, C/C++...) with short-circuit expressions. Ex., e1 || e2 e1 && e2 e1 orelse e2 where interface is described by its operations: ||, &&, orelse, etc and it has absolutely accurate and clear meaning: "||" executes e2 iff e1 *fails, was not success*. "&&" executes e2 iff e1 was succeeded. I don't use words "True" and "False". Because, in different languages marker of success/fail is different. For example, in Bash, the fail is any integer except 0. In Haskell fail is False. In C is 0... What does mean False (and True) is defined by contract/interface of short-circuit operations, related to boolean algebra. A rare case when type is bound with semantic! We read them literally (native English): e1 or-else e2! *This means that using of False to indicate success - is error! And no way to miss provenance/knowledge what True or False means.* (the same: what does Right/False mean?) B) The help from science. Math (and CS) has own history. And one of its mail-stones was birth of formal logic and then of Boolean algebra. CS implemented those in declarative languages (Prolog, for example). If we have some predicate in Prolog, "true" for that predicate means "it was achieved", as goal. If that predicate has side-effects, "true" means it was achieved, i.e. all its steps (side-effects) were successfully executed. Predicate write_text_to_file/2 is "true" when it wrote text to file. And no way to return False on success or to think about sacral sense of True/False :) And that sense traditionally is the same in all programming language. If you invert it, you deny contract, semantic and begin to use "inverted" logic :) We can repeat the same logic with 3.1415926.. What does it mean? Meaning, semantic is described, but contract/interface: this magic irrational was born from part of algebra, called trigonometry. And this algebra defines semantic of Pi, not programmer's usage of Pi, programming context, etc. True/False semantic is defining by its algebra: boolean. So, programmer should not change their semantic, am I right? So, my question is: is this post a april 1st trolling or author was serious? :) --- Best regards, Paul

7 9

Measuring memory usage
by Vlatko Basic 04 Jul '18

04 Jul '18

Hello, I've come to some strange results using Weigh package. It shows that HashMap inside 'data' is using much, much more memory. The strange thing is that I'm seeing too large mem usage in my app as well (several "MapData" like in records), and trying to figure out with 'weigh' what's keeping the mem. Noticed that when I change the code to use HashMap directly (not inside 'data', that's the only change), the mem usage observed with top drops down for ~60M, from 850M to 790M. These are the test results for 10K, 5K and 3.3K items for "data MapData k v = MapData (HashMap k v)" (at the end is the full runnable example.) Case Allocated GCs HashMap 262,824 0 HashMap half 58,536 0 HashMap third 17,064 0 MapData 4,242,208 4 I tested by changing the order, disabling all but one etc., and the results were the same. Same 'weigh' behaviour with IntMap and Map. So, if anyone knows and has some experience with such issues, my questions are: 1. Is 'weigh' package reliable/usable, at least to some extent? (the results do show diff between full, half and third) 2. How do you measure mem consumptions of your large data/records? 3. If the results are even approximately valid, what could cause such large discrepancies with 'data'? 4. Is there a way to see if some record has been freed from memory, GCed? module Main where import Prelude import Control.DeepSeq (NFData) import Data.HashMap.Strict (HashMap, fromList) import GHC.Generics (Generic) import Weigh (mainWith, value) data MapData k v = MapData (HashMap k v) deriving Generic instance (NFData k, NFData v) => NFData (MapData k v) full, half, third :: Int full = 10000 half = 5000 third = 3333 main :: IO () main = mainWith $ do value "HashMap" ( mkHMList full) value "HashMap half" ( mkHMList half) value "HashMap third" ( mkHMList third) value "MapData" (MapData $ mkHMList full) mkHMList :: Int -> HashMap Int String mkHMList n = fromList . zip [1..n] $ replicate n "some text"

4 8