- Haskell-Cafe - Haskell.org

cannot upgrade stack
by Roger Mason 19 Jul '18

19 Jul '18

Hello, I'm attempting to upgrade stack on a FreeBSD 11.1 system but it fails: stack upgrade Current Stack version: 1.5.1, available download version: 1.7.1 Newer version detected, downloading Querying for archive location for platform: freebsd-i386-static Querying for archive location for platform: freebsd-i386 Exception occured when trying to perform binary upgrade: Unable to find binary Stack archive for platforms: freebsd-i386-static freebsd-i386 Falling back to source upgrade Selected mirror https://s3.amazonaws.com/hackage.fpcomplete.com/ Downloading timestamp No updates to your package list were found Updating package index Hackage (mirrored at https://s3.amazonaws.com/hackage.fpcomplete.com/) ...Could not parse '/tmp/stack-upgrade2294/stack-1.7.1/stack.yaml': Aeson exception: Error in $['extra-deps'][0]: failed to parse field 'extra-deps': (Invalid package identifier: "rio-0.1.1.0@rev:0","rio-0.1.1.0@rev:0") See http://docs.haskellstack.org/en/stable/yaml_configuration/ If it matters, I'm using ghc-8.0.2_3. Thanks for any help, Roger

3 6

Backpack vs plain old classes and instances
by Clinton Mead 19 Jul '18

19 Jul '18

Hi All I read though Edward Z. Yang's blog post <http://blog.ezyang.com/2016/10/try-backpack-ghc-backpack/> about Backpack but I can't understand what it does above and beyond classes and instances. It seems to me we could just replace a "signature" with a "class" and a "unit" with an "instance" and achieve the same thing. Of course there are issues with orphans instances if we don't own either the class or the associated data, but it would seem to me that "orphan units" are no less problematic than "orphan instances". Edward Kmett's unpacked-containers <https://www.reddit.com/r/haskell/comments/8a5w1n/new_package_unpackedcontai…> gets some speed improvements using Backpack, but is Backpack just optimisation thing, or are there ways you can organise code with Backpack that you couldn't do without just classes and instances? For example, does Backpack solve the issue of packages requiring huge dependency lists to implement instances that most of their users will not use? Thanks, Clinton

3 4

SqlPersistT action in MonadError issue
by Vlatko Basic 18 Jul '18

18 Jul '18

Hello, I'm trying to use SqlPersistT funcs with MonadError, but am failing in writing the runDB correctly. I tried several things, but always getting: • Couldn't match type ‘IOException’ with ‘AppException’ arising from a functional dependency between: constraint ‘MonadError AppException IO’ arising from a use of ‘f1’ instance ‘MonadError IOException IO’ at <no location info> • In the second argument of ‘runPool’, namely ‘f1’ In the second argument of ‘($)’, namely ‘runPool pgConf f1 pgPool’ In a stmt of a 'do' block: liftIO $ runPool pgConf f1 pgPool I understand there already is "instance MonadError IOException IO" and fundep says it can be only one for IO. How to make it compile? Best regards, vlatko Here is the minimal reproducible code: module Test where import Prelude import Control.Exception.Base import Control.Monad.Except import Control.Monad.Trans.Reader import Database.Persist.Postgresql data AppException = ExcText String | ExcIO IOException deriving (Show) type AppM m = ExceptT AppException (ReaderT App m) data App = App { pgConf :: PostgresConf, pgPool :: ConnectionPool} runDB :: (MonadIO m, MonadError AppException m) => AppM m Bool runDB = do App{..} <- lift ask liftIO $ runPool pgConf *f1* pgPool -- error -- liftIO $ runPool pgConf *f2* pgPool -- OK f1 :: (MonadIO m, MonadError AppException m) => SqlPersistT m Bool f1 = throwError $ ExcText "exception" f2 :: MonadIO m => SqlPersistT m Bool f2 = return True

2 4

Re: [Haskell-cafe] Monads vs. monoids
by Olaf Klinke 18 Jul '18

18 Jul '18

>Am 16.07.2018 um 21:48 schrieb Olaf Klinke: >> Joachim Durchholz wrote: >>> Nope, monoid is a special case of monad (the case where all input and >>> output types are the same). >>> (BTW monoid is associativity + neutral element. Not 100% sure whether >>> monad's "return" qualifies as a neutral element, and my >>> monoid-equals-monotyped-monad claim above may fall down if it is not. >> >> For every monad M, the type M () is a monoid, > >That doesn't make M a monoid, just its type. >Besides, type-level monoids aren't relevant to data-level properties. I'm sorry, I misunderstood your question, then. Of course monads are not monoids. You could say that every monad harbors a monoid, and that every monoid arises this way. But of course the whole and the part are not the same. > >> Does every monoid arise this way? Yes: Since base-4.9 there is the >> monad instance >> Monoid a => Monad ((,) a) >> and of course a and (a,()) are isomorphic (disregarding bottoms). > >An isomorphism does not make it the same, just easily mappable. > >This is pretty near to hair-splitting, I know. >However, from a software design perspective, it's important to keep >things separate even if they are easily mappable: temperatures are just >floats, it's an incredibly easy mapping - but the code becomes clearer >and more maintainable if you keep the Temperature type separate from the >Float type. You may even want to forbid multiplying Temperatures (but >you want the ability to multiply with a number, and temperature >quotients can be useful, too). I totally agree. As a domain theorist I am aware that a and (a,()) are not isomorphic because neither is () the terminal object of Hask nor is (,) the categorical product. But in terms of total elements, there is a monoid isomorphism between the two. >Not 100% sure how much of this is really applicable. > >> Also, there is the famous tongue-in-cheek saying "monads are just >> monoids in the category of endofunctors" > >Tongue-in-check does not make it real. >And being a monoid in a category does not make it a monoid directly. That depends on the definition of "monoid". If a monoid is a set with certain structure, then a monad is not a monoid. If a monoid is a monoid object in some monoidal category, then a monad is a monoid. Maybe we can agree on this distinction? monoid = monoid object in Set monoid object = any monoid object in monoidal closed category. > >There's also a final argument: If monad and monoid are really the same, >why do mathematicians still keep the separate terminology? Because they are different, as we hopefully agree. Olaf

3 2

Proper rounding of floating-point values
by Troels Henriksen 17 Jul '18

17 Jul '18

Much to my surprise, there does not seem to be a function in base (let alone the Prelude) that rounds floating point numbers correctly in the presence of NaNs and infinities. For example: > round (0/0 :: Double) :: Int 0 > round (0/0 :: Double) :: Integer -269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824 > round (1/0 :: Double) :: Int 0 > round (1/0 :: Double) :: Integer 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216 This is because the 'round' function must return an instance of Integral, which Double is not. In the presence of NaNs and infinities, this does not fly. In my own code, I ended up just using the FFI to call out to C, which is simple enough: foreign import ccall "round" c_round :: Double -> Double foreign import ccall "roundf" c_roundf :: Float -> Float However, it does disturb me a bit that I cannot find a standard way to do this fairly common operation. (GHC's implementation does seem to avoid many other common pitfalls[0], probably because it does use C's round() under the covers.) [0]: https://www.cockroachlabs.com/blog/rounding-implementations-in-go/ -- \ Troels /\ Henriksen

1 0

Monads vs. monoids
by Olaf Klinke 17 Jul '18

17 Jul '18

Joachim Durchholz wrote: >Nope, monoid is a special case of monad (the case where all input and >output types are the same). >(BTW monoid is associativity + neutral element. Not 100% sure whether >monad's "return" qualifies as a neutral element, and my >monoid-equals-monotyped-monad claim above may fall down if it is not. For every monad M, the type M () is a monoid, with mempty = return () x <> y = x >> y Does every monoid arise this way? Yes: Since base-4.9 there is the monad instance Monoid a => Monad ((,) a) and of course a and (a,()) are isomorphic (disregarding bottoms). Also, there is the famous tongue-in-cheek saying "monads are just monoids in the category of endofunctors" which is explained in numerous blog posts and Youtube videos. The monoid M () above has funny properties. Specialize M = [] and obtain the monoid of natural numbers under multiplication. Since (>>) has the more general type Monad m => m a -> m b -> m b We have a monoid action of M () on any type M b. In case of lists, it multiplies elements: [(),()] >> xs doubles the number of every element of the list xs. Olaf

3 2

if-then without -else?
by Johannes Waldmann 17 Jul '18

17 Jul '18

Dear Cafe, a student in my class detected this inconsistency in the design of Haskell: > Why require that each "if-then" has an "else" > while still allowing incomplete sets of patterns? > We could define "if p then a" > by translating to "case p of { True -> a }" I think that "but then we'd have the dangling-else problem" is not a good answer because this is really about semantics, not surface syntax. For reference, Scheme has short-if, see http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.4.3 (value is "unspecified" if condition is false) and Common LISP does as well https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node84.html#SECTION001160000… (value is "nil") Was this considered at some point in Haskell's design process? There is Section 5.2 on pattern matching in http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf (*) but it does not mention if-then(-else). - J.W. (*) can we please add this to https://www.haskell.org/documentation Upvote this: https://github.com/haskell-infra/hl/issues/86

6 5

Final Call for Talks -- Haskell Implementors' Workshop
by Joachim Breitner 16 Jul '18

16 Jul '18

Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 Important dates --------------- Proposal Deadline: Friday, 20 July, 2018 Notification: Friday, 3 August, 2018 Workshop: Sunday, 23 September, 2018 Keynote speaker --------------- This year, the Haskell Implementors’ Workshop is proud to present Rahul Muttineni as the keynote speaker. Rahul brough the joys of Haskell to the realm of Java by creating the Eta programming language. Title: Let's Go Mainstream with Eta! Eta is a fork of GHC that focuses on three core principles: user experience, performance, and safety. We'll discuss how we used these principles to guide the re-implementation of the GHC runtime and code generator on the JVM. Moreover, will also cover the inner workings of the FFI and the typechecker support we added for subtyping to make it smooth to interact with Java libraries. Finally, we'll round out with a look at where Eta is headed and how Eta and GHC can collaborate in the future. About the Haskell Implementors’ Workshop ---------------------------------------- The 10th Haskell Implementors’ Workshop is to be held alongside ICFP 2018 this year in St. Louis. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2018. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw18.hotcrp.com/ until July 20th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact ------- * Joachim Breitner <joachim(a)cis.upenn.edu> -- Joachim Breitner Post-Doctoral researcher http://cis.upenn.edu/~joachim

1 0

Deadline Extension: Workshop in OCL and Textual Modeling (OCL 2018)
by Achim D. Brucker 16 Jul '18

16 Jul '18

(Apologies for duplicates) ********************************************************** ** Deadline Extension: new deadline 24th of July 2018 * ********************************************************** 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 24, 2018 (extended) - 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

DSLDI 2018: First Call for Talk Proposals
by Sam Tobin-Hochstadt 16 Jul '18

16 Jul '18

********************************************************************* FIRST CALL FOR TALK PROPOSALS DSLDI 2018 Sixth Workshop on Domain-Specific Language Design and Implementation November 6th, 2018 Boston, USA Co-located with SPLASH http://2018.splashcon.org/track/dsldi-2018-talks https://twitter.com/wsdsldi ********************************************************************* Deadline for talk proposals: 17th of August, 2018 Well-designed and implemented domain-specific languages (DSLs) can achieve both usability and performance benefits over general-purpose programming languages. By raising the level of abstraction and exploiting domain knowledge, DSLs can make programming more accessible, increase programmer productivity, and support domain-specific optimizations. ## Workshop Goal Domain-Specific Language Design and Implementation (DSLDI) is a workshop intended to bring together researchers and practitioners interested in discussing how DSLs should be designed, implemented, supported by tools, and applied in realistic contexts. The focus of the workshop is on all aspects of this process, from soliciting domain knowledge from experts, through the design and implementation of the language, to evaluating whether and how a DSL is successful. More generally, we are interested in continuing to build a community that can drive forward the development of modern DSLs. ## Workshop Format DSLDI is a single-day workshop and will consist of an invited speaker followed by moderated audience discussions structured around a series of short talks. The role of the talks is to facilitate interesting and substantive discussion. Therefore, we welcome and encourage talks that express strong opinions, describe open problems, propose new research directions, and report on early research in progress. Proposed talks should be on topics within DSLDI’s area of interest, which include but are not limited to: * solicitation and representation of domain knowledge * DSL design principles and processes * DSL implementation techniques and language workbenches * domain-specific optimizations * human factors of DSLs * tool support for DSL users * community and educational support for DSL users * applications of DSLs to existing and emerging domains * studies of usability, performance, or other benefits of DSLs * experience reports of DSLs deployed in practice ## Call for Talk Proposals We solicit talk proposals in the form of short abstracts (max. 2 pages). A good talk proposal describes an interesting position, open problem, demonstration, or early achievement. The submissions will be reviewed on relevance and clarity, and used to plan the mostly interactive sessions of the workshop day. Publication of accepted abstracts and slides on the website is voluntary. * Deadline for talk proposals: August 17th, 2018 * Notification: September 17th, 2018 * Workshop: November 6th, 2018 * Submission website: https://dsldi18.hotcrp.com/ ## Workshop Organization Co-chairs: * Sam Tobin-Hochstadt (samth(a)indiana.edu) Indiana University * Lindsey Kuper (lindsey(a)composition.al) University of California, Santa Cruz Follow us on Twitter at https://twitter.com/wsdsldi Program committee: * Eric Van Wyk (University of Minnesota) * Katherine Ye (Carnegie Mellon University) * Nate Foster (Cornell University) * Spencer Florence (Northwestern University) * Phitchaya Mangpo Phothilimthana (University of California, Berkeley) * Jeremy Gibbons (University of Oxford) * Edwin Brady (University of St. Andrews)

1 0