- Haskell-Cafe - Haskell.org

animation application
by Dennis Raddle 24 Jul '18

24 Jul '18

I'm working on an application for animating words, images, and shapes. I'm actually doing it in Purescript and it will become part of a math game that runs in the browser, but I'm asking my question on the Haskell list because the issues seem central to a functional/pure paradigm. Let's say that the things being animated are "objects." Objects could include photos, text, shapes, lines, etc. They can have fixed positions, colors, and other attributes, or their attributes can change over time. How do I compute attributes that change over time? In some cases, a function with a single argument, the current time, would suffice. I might want state, though -- perhaps an object's movement is pseudorandom and needs to refer to a seed and past position state. Objects might even need to observe each other's state. For instance, imagine we have two words, W1 and W2, and they move according to some stateful algorithm. Meanwhile we want to draw a line connecting their centers, so we need a line object L that can read the centers of W1 and W2. How do I represent the state of W1, W2, and L? I could define a general Object data type: (here there are no fields mentioned) data Object = W1 | W2 | L I will need state and the ability to customize the drawing and positioning functions, so to flesh out the fields of, say , W1. type St = StateT WholeScene IO data Object = W1 { leftEdge :: Int , rightEdge :: Int , topEdge :: Int , bottomEdge :: Int , computePosition :: W1 -> Time -> St W1 , draw :: W1 -> St () , ... other state ... } Okay, so now I could define W2, which will be different in some ways, perhaps needing different state. But it will look a lot alike. It might have the same edge fields. In fact, all my objects will have similar position, color, etc. attributes. I certainly don't want to reinvent the wheel for everything. I also want objects to be able to read each other's state. Consider a basic positioning task: some object Obj1 keeps its left edge 100 pixels to the right of some other object's right edge. So the Obj1 function for computing position needs access to the other objects. Also consider that all these objects need to be put into a list together, to hold the state of the entire scene. They need to be members of the same class, and have a way to look each other up. One way to do this is have a single Object type with numerous constructors, and define similar functions on every constructor type (say, a function for accessing or setting the left edge). I also thought about having an Object be an existential type, and the fields that are custom to one object will be the existentially defined data. I actually implemented this in Purescript, but it got out of hand, probably due to my own weakness of understanding how existential types work. Any ideas? D

1 1

Why does this result in a runtime loop instead of a type error or typechecker loop?
by Theodore Lief Gannon 24 Jul '18

24 Jul '18

λ. :set -XFlexibleContexts -XFlexibleInstances -XMultiParamTypeClasses -XUndecidableInstances λ. import RIO λ. import Data.Has λ. class HasBool a where boolL :: Lens' a Bool λ. instance {-#OVERLAPPABLE#-} HasBool a => Has Bool a where hasLens = boolL λ. instance {-#OVERLAPPABLE#-} Has Bool a => HasBool a where boolL = hasLens λ. runRIO () $ view boolL ^CInterrupted. The RIO environment () doesn't contain a Bool. I can see how the typechecker might get lost in this, but I can compile an equivalent program; it loops on execution.

3 2

Munich Haskell Meeting, 2018-07-25 @ 19:30
by Leah Neukirchen 23 Jul '18

23 Jul '18

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, July 25 at Max Emanuel Brauerei at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jul-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

Job: Haskell developer at GetShop.TV (interactive television platform)
by Nickolay Kudasov 23 Jul '18

23 Jul '18

Hello, Cafe! We are seeking a Haskell developer to join our team and help us build an interactive television platform at scale in Russia! Candidates of all ages, nationalities, genders, etc. are welcome :) Full-time position in Moscow, Russia is preferable, but remote/part-time is possible! Please, feel free to send your CV directly to me via e-mail or via a form at http://getshop.tv/ourteam/sr-haskell-developer/ GetShop.TV is an interactive television platform that connects viewers with advertisers and content providers on both live TV and video-on-demand services. Right now the company is expanding its platform, connecting more TV channels and operators in Russia. At the same time we are working on automation and scalability. Our backend in 100% Haskell (Servant) and some of our internal services rely on GHCJS (Miso). We are seeking a senior Haskell developer to help us build a stable, automated, typesafe service at scale. Some of the challenges and tasks include - dealing and optimising for an uneven, spiky, but predictable load - integration with multiple imperfect services and platforms - automating processes that aren't automated yet - improving our automatic reporting system - performing regular code reviews - tutoring several junior developers Some buzzwords that we use are Git Flow, GitHub, Servant (with servant-swagger), Miso, acid-state, PostgreSQL, hasql, postgresql-query, hspec, HUnit, QuickCheck, critetion, Circle CI, Ansible, Docker, Telegram (via telegram-bot-simple). We expect candidates to be familiar with most of those, as well as having an industry experience in functional programming. We would be thrilled if a candidate were also interested in and/or capable of - DevOps with Ansible/Docker/Nix - technical writing (Russian or English) At the company we encourage learning and knowledge sharing, which include internal tech talks. We also support open source contributions and participations in meetups and conferences. We'll gladly accept submissions from candidates of all ages, nationalities, genders, etc. Our focus will be on the candidates located in Moscow, Russia or willing to relocate. However, remote/part time is possible for strong candidates or after a probationary period. Our office in located right in the center of Moscow, a walking distance from Red Square, Arbat, Hermitage Garden, Moscow Zoo. It's also less than a minute from Pushkinskaya, Tverskaya and Chekhovskaya stations. The office is equipped with a kitchen, microwave, coffee machine, offers tea and fresh fruit. Kind regards, Nickolay Kudasov CTO GetShop.TV

1 0

GHC, cabal and nightlies via Chocolatey
by Phyx 22 Jul '18

22 Jul '18

Hi All, For those that use a cabal based workflow on Windows or are interested in doing Windows testing for their packages using AppVeyor I've written up some instructions on how to do this using Chocolatey https://hub.zhox.com/posts/chocolatey-introduction/. The standard packages are pulled directly from Haskell.org As a trial I'm also making my own Windows Nightlies for GHC and Cabal available via my NuGet package stream. Details available on the post. Thanks, Tamar

1 0

Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?
by Johannes Waldmann 22 Jul '18

22 Jul '18

> - Large-scale refactoring with types: > this is a huge selling point for Haskell in general I fully agree with the general idea, but the specific example > data Shape > = Circle Double > | Square Double > | Rectangle Double Double -- ^ added is not convincing (well, to programmers that know about static typing) Think of a Java program interface Shape { .. } class Circle implement Shape { ... } When you add class Rectangle { } , then Shape foo = new Rectangle () would be an error, until you put class Rectangle implements Shape { } then the compiler tells you what methods are missing. I think the extra value of types in Haskell (for everything, including refactoring) is that they tend to express more of the program's properties (w.r.t. statically typed imperative programs). Examples: the distinction between a and IO a, between IO a and STM a. In Data.Set, function "fromList" has an Ord constraint, but "toList" does not. Does "singleton" need the constraint? I used this as an exam question just last week. - J.W.

2 1

fyi 10 benchmarks game programs broken
by Isaac Gouy 20 Jul '18

20 Jul '18

https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/gh… Several of those programs fail to compile: Variable not in scope: rdeepseq For example: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/fannkuc… best wishes, Isaac

1 0

What is your favourite Haskell "aha" moment?
by Simon Peyton Jones 20 Jul '18

20 Jul '18

Friends In a few weeks I'm giving a talk to a bunch of genomics folk at the Sanger Institute<https://www.sanger.ac.uk/> about Haskell. They do lots of programming, but they aren't computer scientists. I can tell them plenty about Haskell, but I'm ill-equipped to answer the main question in their minds: why should I even care about Haskell? I'm too much of a biased witness. So I thought I'd ask you for help. War stories perhaps - how using Haskell worked (or didn't) for you. But rather than talk generalities, I'd love to illustrate with copious examples of beautiful code. * Can you identify a few lines of Haskell that best characterise what you think makes Haskell distinctively worth caring about? Something that gave you an "aha" moment, or that feeling of joy when you truly make sense of something for the first time. The challenge is, of course, that this audience will know no Haskell, so muttering about Cartesian Closed Categories isn't going to do it for them. I need examples that I can present in 5 minutes, without needing a long setup. To take a very basic example, consider Quicksort using list comprehensions, compared with its equivalent in C. It's so short, so obviously right, whereas doing the right thing with in-place update in C notoriously prone to fencepost errors etc. But it also makes much less good use of memory, and is likely to run slower. I think I can do that in 5 minutes. Another thing that I think comes over easily is the ability to abstract: generalising sum and product to fold by abstracting out a functional argument; generalising at the type level by polymorphism, including polymorphism over higher-kinded type constructors. Maybe 8 minutes. But you will have more and better ideas, and (crucially) ideas that are more credibly grounded in the day to day reality of writing programs that get work done. Pointers to your favourite blog posts would be another avenue. (I love the Haskell Weekly News.) Finally, I know that some of you use Haskell specifically for genomics work, and maybe some of your insights would be particularly relevant for the Sanger audience. Thank you! Perhaps your responses on this thread (if any) may be helpful to more than just me. Simon

44 103

Monads because of I/O?
by Olaf Klinke 19 Jul '18

19 Jul '18

Paul, monads were not invented because I/O could not be presented in another way in Haskell. Monads are way older than Haskell. It is a concept of category theory which was developed in the 1950s. Actually some concepts of algebra that are even older turn out to be monads. Take Galois theory for example. Once you know the pattern, you find a monad under every stone you turn around. It's one of the luckiest things that people like Moggi and Wadler realized that monads can be applied to structure programs. And don't blame them that monads are not composable - it is simply a mathematical fact. Some monads do compose with any other monad, and those are the monad transformers. If you like Prolog's relational programming model so much, then you should play with those programs that have "no business value". Because Haskell's type inference algorithm, together with multi-parameter type classes and maybe type level natural numbers together give rise to Prolog-like capabilities. All the work is done by the compiler this way. What you say about FSM is certainly true to some extent - they are well understood, can be generated automatically, and there is decent theory to reason about them. That is why this model is used in safety-sensitive environments such as aviation. I once applied for a position in verification in the automotive industry, and the interview partner told me that they struggle mightily with the vast state spaces of the FSMs they are checking. All this speaks in favour of Haskell. The semantics is simple and beautiful, because it is a single-paradigm language. And because of that, clever people can leverage theorem provers to mathematically prove correctness of Haskell code. I don't know of many languages where that is possible. (But then, I'm not an expert on verification.) Olaf

4 3

Defining operators via sections
by Tom Ellis 19 Jul '18

19 Jul '18

I can define operators directly or through their parenthesised name: > let x .+ y = x + y > let (.+) x y = (+) x y > let (.+) x = (+) x > let (.+) = (.+) but I can't define them via sections: > let (x .+) = (x +) <interactive>:11:6: Parse error in pattern: x .+ > let (.+ y) = (+ y) <interactive>:12:6: Parse error in pattern: .+ y It seems natural to write, for example instance Monad Maybe where ... (>>= f) = \case Nothing -> Nothing Just a -> f a Is there any particular reason this is not possible? Thanks, Tom

1 0

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

BlockedIndefinitelyOnMVar
by Massimo Zaniboni 16 Jul '18

16 Jul '18

Hi, I have a code like this ``` producer :: Int -> MVar Int -> IO () producer c mvar = case c > 10 of True -> throwIO HighNumberException False -> do putMVar mvar (c + 1) producer (c + 1) mvar consumer :: MVar Int -> IO () consumer mvar = do _ <- takeMVar mvar consumer mvar coordinator :: MVar Int -> IO () coordinator mvar = do withAsync (producer 0 mvar) $ \p -> withAsync (consumer mvar) $ \c -> do wait c wait p main :: IO () main = do mvar <- newEmptyMVar withAsync (coordinator mvar) (wait) putStrLn "done" ``` The producer send the informative exception HighNumberException, but the coordinator job receives a generic BlockedIndefinitelyOnMVar, because the producer stop working. How can I discard the generic exception, and re-throw/catch only HighNumberException? In case the complete source code is on https://github.com/massimo-zaniboni/blocked-on-mvar Thanks in any case, Massimo

1 2

Package takeover: bencoding
by Sergey Vinokurov 16 Jul '18

16 Jul '18

I'd like to take over maintainership of the bencoding package [1]. The package was not updated to work with ghc 8.0 and will likely require more fixes to work with ghc 8.4 and some work to make a Stackage release. There's a PR open for GHC 8.0, but it's still open for a year and a half [2]. I've tried to ask the author in the PR thread to make me a maintainer in January but it still hasn't happened. Cheers, Sergey [1]: http://hackage.haskell.org/package/bencoding [2]: https://github.com/pxqr/bencoding/pull/7

1 0

[ANNOUNCE] GHC 8.6.1-alpha2 available
by Ben Gamari 16 Jul '18

16 Jul '18

The GHC development team is pleased to announce the second alpha release leading up to GHC 8.6.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-alpha2 This alpha fixes many of the bugs reported in the first alpha and brings many of the core libraries to their (hopefully) final release versions. Unfortunately, the documentation troubles affecting the first alpha haven't quite been resolved in this release. Consequently you will again find there is no documentation uploaded. However, let us know if anything else is amiss. Thanks for your help! Cheers, - Ben

1 0

Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?
by Vilem-Benjamin Liepelt 15 Jul '18

15 Jul '18

Dear MarLinn, > Of course you need all that data because there's a ghc in that data, but > it should say so on the tin. So please never send a script with this > line to a "newbie" without big warnings so they can make an informed > decision. That is a very good point. I just happen to use some particular LTS because I have it cached, so it works instantly for all my scripts. Thank you for reminding me that I shouldn't carelessly just pass this on for others to use without mentioning the caveats you pointed to. > Also, while I do like the scripting possibilities, interact is possibly > the worst way to introduce a newcomer to it because you can't really > test it in ghci. Your concern about testability in GHCi is valid but minor; you can just make the string transformation function a top-level declaration like so: ``` main = interact sumCLI sumCLI :: String -> String sumCLI = show @Double . sum . mapMaybe readMaybe . words ``` IMO `interact` is the easiest way for newcomers to write a script that they can actually use, hence why I opted for this instead of `print . sumCLi =<< getContents`. Lastly, SPJ asked for our "aha" moments—this was mine. He always does a good job at serving information in a way that is digestible for the audience, so you need not worry that any lambs will be led astray. Best, Vilem > On 2018-07-14, at 13:00, <haskell-cafe-request(a)haskell.org> <haskell-cafe-request(a)haskell.org> wrote: > > [...] > > Message: 4 > Date: Sat, 14 Jul 2018 13:33:31 +0200 > From: MarLinn <monkleyon(a)gmail.com> > To: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] What is your favourite Haskell "aha" > moment? > Message-ID: <c7a00886-f32b-c4ae-617d-450394278b58(a)gmail.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Warning: I'll be overly harsh in this mail because I assume some people > that are new to Haskell might browse this thread now and in the future. > I don't mean my comments to be considered personal. On the contrary, I > think some of us can learn for their own teaching endeavours. > >> #!/usr/bin/env stack >> -- stack script --resolver lts-10.1 --install-ghc > > Imagine a "newbie" running this script just to see what it does. After > 15 minutes they'll be disappointed why your small demo took so long to > build. Only /then/ do they realize that, what is it today, about half a > gigabyte maybe, of their monthly "high speed" bandwidth and of their > precious space on the cheap but decade-old hard drive is gone. > > Of course you need all that data because there's a ghc in that data, but > it should say so on the tin. So please never send a script with this > line to a "newbie" without big warnings so they can make an informed > decision. Maybe they would want to install ghc at their uni to save on > that precious bandwidth at home or something similar. > > In fact don't even send scripts with this line to seasoned haskellers. > If your code is compatible with the ghc 8.2.1 on my system, why should > your script assume I want stack to install 8.2.2 right now? > > Of course this behaviour is ingrained in the DNA of stack – after all it > values convenience for the professional user more than convenience for > the unprivileged newcomer – but AFAIU it /can/ be persuaded to be more > inclusive. So especially here, we should maybe try to do that. > >> interact >> ( show @Double >> . sum >> . mapMaybe readMaybe >> . words >> ) > > Also, while I do like the scripting possibilities, interact is possibly > the worst way to introduce a newcomer to it because you can't really > test it in ghci. Apart from all the other shortcomings it has. It is > nice in that it hides IO, but… > > Again, not meant as an attack, but since we're talking about giving > newcomers a good experience, I thought these two points important. > > Cheers, > MarLinn >

1 0

[ANNOUNCE] GHC 8.4.3 released
by Ben Gamari 14 Jul '18

14 Jul '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.3. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.3 This release includes a few bug fixes including: * A code generation bug resulting in crashing of some programs using UnboxedSums has been fixed (#15038). * #14381, where Cabal and GHC would disagree about abi-depends, resulting in build failures, has been worked around. Note that the work-around patch has already been shipped by several distributions in previous releases, so this change may not be visible to you. * By popular demand, GHC now logs a message when it reads a package environment file, hopefully eliminating some of the confusion wrought by this feature. * GHC now emits assembler agreeable to newer versions of Gnu binutils, fixing #15068. * SmallArray#s can now be compacted into a compact region Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/TeamGHC Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug

5 11

Package takeover: bencoding
by Sergey Vinokurov 14 Jul '18

14 Jul '18

I'd like to take over maintainership of the bencoding package [1]. The package was not updated to work with ghc 8.0 and will likely require more fixes to work with ghc 8.4 and some work to make a Stackage release. There's a PR open for GHC 8.0, but it's still open for a year and a half [2]. I've tried to ask the author in the PR thread to make me a maintainer in January but it still hasn't happened. Cheers, Sergey [1]: http://hackage.haskell.org/package/bencoding [2]: https://github.com/pxqr/bencoding/pull/7

1 0

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 14 Jul '18

14 Jul '18

Dear Haskell community, the GHC Steering committee is seeking nominations for a new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until July 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?
by Vilem-Benjamin Liepelt 14 Jul '18

14 Jul '18

Dear Simon, I was always impressed by Haskell, but my "aha" moment was when I realised how great it is as a scripting language. How cool is the fact that you can glue together a bunch of small programs and make a bigger program out of it without toil? Haskell helps you get mundane tasks done while being a pleasure to write (in relative terms)! There are much better examples online—I love Gabriel Gonzalez' turtle library—but I find the following compelling enough, and anybody can understand more or less what is going on with some explanation: #!/usr/bin/env stack -- stack script --resolver lts-10.1 --install-ghc {-# LANGUAGE TypeApplications #-} import Data.Maybe (mapMaybe) import Text.Read (readMaybe) main :: IO () main = interact ( show @Double . sum . mapMaybe readMaybe . words ) -- Adapted from a script by Taylor Fausak: https://gist.github.com/tfausak/fcd11dfcec616622033dfb64eb2378e1 Good luck with the presentation! Best, Vilem

3 2

Taking over unicode-show
by Yuji Yamamoto 14 Jul '18

14 Jul '18

Hello Haskellers, I'm trying to take over the unicode-show <http://hackage.haskell.org/package/unicode-show> package, whose author Takayuki Muranushi died about a year ago [1]. We Japanese (and perhaps non-alphabet writers) are often annoyed by the result of the show function, which converts various characters into non-human-readable strings. The unicode-show package solves the problem, and I'm going to introduce the package in an educational content I'm creating to help Japanese Haskell newbies. Thanks to the simple structure, there is nothing to maintain (unfortunately except hard one). It works even on GHC 8.4. [1]: (In Japanese) http://www.asj.or.jp/tennet/archives/msg07622.html -- 山本悠滋 twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep

1 0

Lifetime control of webserver
by ☂Josh Chia (謝任中) 13 Jul '18

13 Jul '18

Hi, My application is not a webserver but needs to run a webserver for part but not all of its lifetime. Particularly, there's a part that does some complex computation and I want a webserver to expose its internal state/progress through HTTP. It seems that the typical and expected way to use a webserver is to designate the entire app itself as a webserver, so that functions like the following are basically infinite loops that serve HTTP: Web.Scotty.scotty: http://hackage.haskell.org/package/scotty-0.11.2/docs/Web-Scotty.html#v:sco… Network.Wai.Handler.Warp.run: http://hackage.haskell.org/package/warp-3.2.22/docs/Network-Wai-Handler-War… Can I run a webserver with explicit control of its lifetime? Particularly, I want to be able to kill it without killing the app or explicitly serve one request at a time. I'm not restricted to scotty or warp. Josh

3 4

Re: [Haskell-cafe] Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?)
by Paul 13 Jul '18

13 Jul '18

Wooow! Yes!! But today there is serious competition (Smalltalk, Python; I planned Scratch – but it’s for children of 7-9 years). I thing you are good teacher 😊 Btw, what do you think: what is better – textual programming or visual programming for children? For me, Labview/G was insight in 90s 😊 Today there is Luna language – it’s visual too. IMHO visual programming better illustrates ideas/concepts, or? From: Chris Smith Sent: 12 июля 2018 г. 21:00 To: aquagnu(a)gmail.com Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavouriteHaskell "aha" moment?) Perhaps you mean something fun and visual like this? https://code.world/#PhFFj32Bx0FcpQvvoVJW0xw Or this? https://code.world/#PO1BKCj-kA9ztKKnE7rOueA These are written in the simplified variant of Haskell that I teach, which uses a custom Prelude that skips type classes and other advanced features, uses rebindable syntax to simplify types (for example, you'll see Number instead of Int, Double, etc.), and automatically provides graphics functions that work in the browser. On Thu, Jul 12, 2018 at 1:54 PM Paul <aquagnu(a)gmail.com> wrote: Hmm, Chris, thanks for answer. Interesting. I was surprised when I first learned that someone somewhere is teaching the children to Haskell, but if you say so – then it’s possible and may be it’s good! 😊 Sometimes children don’t like right things, but like fun. So, I though that more preferable to show them some bright demo: UI, graphics, some simple games, databases, to rise the interest, you know – this feeling of first code. First “wooow! It works!!!” 😊 Haskell, for me, looks pedantic, not for fun. May be I’m not right, I have not such experience. From: Chris Smith Sent: 12 июля 2018 г. 19:59 To: aquagnu(a)gmail.com Subject: Re: [Haskell-cafe] Investing in languages (Was: What is yourfavourite Haskell "aha" moment?) I'll answer this, since I have been teaching Haskell to children for six years or so. :) I think it's important to distinguish between Haskell AS USED in most of the community, and Haskell as it COULD be used. I agree that you don't want to teach the first of those to children. But Haskell is still a great teaching choice, mainly because GHC is so configurable that you can create the environment you want, and just build it with a Haskell compiler. With GHC plugins, this is becoming even more true, but it already arises from a combination of (a) very lightweight and intuitive core syntax in the first place, (b) great support for custom preludes, and (c) the RebindableSyntax extension, and the fact that so much syntax is defined in terms of desugaring. If you're seriously talking about teaching children, then your concerns about web frameworks and such are a bit silly. (Unless by "children" you meant mid to late teens and after, in which case this becomes relevant.) "Advanced" type features are also not particularly relevant (though there's some fuzziness about what counts as "advanced"; for instance, I've recently decided it's better to teach GADT syntax as the only option for defining algebraic data types, even though I never expect most students to take advantage of the extra power of GADTs.) The main concern I have with F#, though, is that the semantics are far too complex. It has all the power of a functional language, but none of the semantic simplicity. If students already struggle with compositional programming (and they do), they struggle even more when the simplest way to understand what's going on -- namely, substitution -- is taken away from them. If you're going to teach a computational model based on sequencing actions on a global state (the state being the screen, network, etc.), then you might as well include mutable variables in that global state, and you might as well teach Python, which will at least be more intuitive, if not simpler. On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu(a)gmail.com> wrote: I am afraid that it can lead to flame again, but F# has super-capacity: you can check measuring units, type providers, computation expressions, active patterns, static/dynamic types constraints, constraints on existing method, etc... It's clean, borrows some ideas from Haskell, some are original and Haskell borrows them (but with worse implementation). IMHO for children teaching to FP F# is the best. Even more, currently C# also has a lot of FP features (https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arit… -- is not it super easy and beauty?). Rust is more low level: you should think about memory "management", OOP has some problems... And serious argument for children teaching: salary trends (joke sure) :-) But you can compare salary in F# and Haskell, for example - people often choice language after check current salaries in the market. Also F# is more focused on realistic tasks and business value. It lacks performance, UWP yet (but in progress)... To feel how F# is sexy compare Web application written in Websharper and in any Haskell framework. Haskell is beauty but I'm afraid its fate unfortunately will be the same as one of Common Lisp, NetBSD, etc - it's ground for ideas and experiments and has disputable design. Also it's more-more difficult to teach children to Haskell than to F#... IMHO is general to teach FP is more easy than to teach OOP if FP is not Haskell (some language which targets more eager/efficient/dynamic/real goals instead of abstract types playing). 12.07.2018 13:28, Vanessa McHale wrote: I wouldn't say Rust has a large capacity for FP. I am not familiar with F#. The thing that makes FP infeasible in Rust is not the lack of purity but rather the fact that affine types make it difficult to treat functions as first-class values. On 07/12/2018 01:40 AM, Brett Gilio wrote: Tony, I am curious on your attitude towards multi-paradigm and ML-like languages. I agree that functional programming is easily the better of the bundle in many forms of application logic and elegance (which is why I have come to love Scheme and Haskell), but do you see any room for those languages like F# or Rust which have large capacities for FP but are either functional-first (but not pure) or a hybrid? Brett Gilio On 07/12/2018 01:35 AM, Tony Morris wrote: I used to teach undergrad OOP nonsense. I have been teaching FP for 15 years. [^1] The latter is *way* easier. Existing programmers are more difficult than children, but still way easier to teach FP than all the other stuff. [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/ On 07/12/2018 04:23 PM, Joachim Durchholz wrote: Am 11.07.2018 um 16:36 schrieb Damian Nadales: I speak only from my own narrow perspective. I'd say programming is hard, but functional programming is harder. Actually it's pretty much the opposite, I hear from teachers. Maybe that's why Java replaced Haskell in some universities curricula The considerations are marketable skills. A considerable fraction of students is looking at the curriculum and at job offers, and if they find that the lists don't match, they will go to another university. Also, industry keeps lobbying for teaching skills that they can use. Industry can give money to universities so this gives them influence on the curriculum (and only if they get time to talk the topic over with the dean). This aspect can vary considerably between countries, depending on how much money the universities tend to acquire from industry. https://chrisdone.com/posts/dijkstra-haskell-java. For some reason most programmers I know are not scared of learning OO, but they fear functional programming. Programmers were *very* scared of OO in the nineties. It took roughly a decade or two (depending on where you put the starting point) to get comfortable with OO. I think the reason might be that OO concepts like inheritance and passing messages between objects are a bit more concrete and easier to grasp (when you present toy examples at least). OO is about how to deal with having to pack everything into its own class (and how to arrange stuff into classes). Functional is about how to deal with the inability to update. Here, the functional camp actually has the easier job, because you can just tell people to just write code that creates new data objects and get over with it. Performance concerns can be handwaved away by saying that the compiler is hyper-aggressive, and "you can look at the intermediate code if you suspect the compiler is the issue". (Functional is a bit similar to SQL here, but the SQL optimizers are much less competent than GHC at detecting optimization opportunities.) Then you have design patterns, which have intuitive names and give some very general guidelines that one can try after reading them (and add his/her own personal twist). I doubt people can read the Monad laws and make any sense out of them at the first try. That's true, but much of the misconceptions around monads from the first days have been cleared up. But yes the monad laws are too hard to read. OTOH you won't be able to read the Tree code in the JDK without the explanations either. _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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.

5 4

Re: [Haskell-cafe] Investing in languages (Was: What is your favourite Haskell "aha" moment?)
by Chris Smith 12 Jul '18

12 Jul '18

Oops, readding the mailing list. On Thu, Jul 12, 2018 at 12:59 PM Chris Smith <cdsmith(a)gmail.com> wrote: > I'll answer this, since I have been teaching Haskell to children for six > years or so. :) > > I think it's important to distinguish between Haskell AS USED in most of > the community, and Haskell as it COULD be used. I agree that you don't > want to teach the first of those to children. But Haskell is still a great > teaching choice, mainly because GHC is so configurable that you can create > the environment you want, and just build it with a Haskell compiler. With > GHC plugins, this is becoming even more true, but it already arises from a > combination of (a) very lightweight and intuitive core syntax in the first > place, (b) great support for custom preludes, and (c) the RebindableSyntax > extension, and the fact that so much syntax is defined in terms of > desugaring. > > If you're seriously talking about teaching children, then your concerns > about web frameworks and such are a bit silly. (Unless by "children" you > meant mid to late teens and after, in which case this becomes relevant.) > "Advanced" type features are also not particularly relevant (though there's > some fuzziness about what counts as "advanced"; for instance, I've recently > decided it's better to teach GADT syntax as the only option for defining > algebraic data types, even though I never expect most students to take > advantage of the extra power of GADTs.) > > The main concern I have with F#, though, is that the semantics are far too > complex. It has all the power of a functional language, but none of the > semantic simplicity. If students already struggle with compositional > programming (and they do), they struggle even more when the simplest way to > understand what's going on -- namely, substitution -- is taken away from > them. If you're going to teach a computational model based on sequencing > actions on a global state (the state being the screen, network, etc.), then > you might as well include mutable variables in that global state, and you > might as well teach Python, which will at least be more intuitive, if not > simpler. > > On Thu, Jul 12, 2018 at 7:46 AM PY <aquagnu(a)gmail.com> wrote: > >> I am afraid that it can lead to flame again, but F# has super-capacity: >> you can check measuring units, type providers, computation expressions, >> active patterns, static/dynamic types constraints, constraints on existing >> method, etc... It's clean, borrows some ideas from Haskell, some are >> original and Haskell borrows them (but with worse implementation). IMHO for >> children teaching to FP F# is the best. Even more, currently C# also has a >> lot of FP features ( >> https://github.com/dotnet/csharplang/blob/master/proposals/patterns.md#arit… >> -- is not it super easy and beauty?). Rust is more low level: you should >> think about memory "management", OOP has some problems... And serious >> argument for children teaching: salary trends (joke sure) :-) But you can >> compare salary in F# and Haskell, for example - people often choice >> language after check current salaries in the market. Also F# is more >> focused on realistic tasks and business value. It lacks performance, UWP >> yet (but in progress)... To feel how F# is sexy compare Web application >> written in Websharper and in any Haskell framework. Haskell is beauty but >> I'm afraid its fate unfortunately will be the same as one of Common Lisp, >> NetBSD, etc - it's ground for ideas and experiments and has disputable >> design. Also it's more-more difficult to teach children to Haskell than to >> F#... >> IMHO is general to teach FP is more easy than to teach OOP if FP is not >> Haskell (some language which targets more eager/efficient/dynamic/real >> goals instead of abstract types playing). >> >> 12.07.2018 13:28, Vanessa McHale wrote: >> >> I wouldn't say Rust has a large capacity for FP. I am not familiar with >> F#. The thing that makes FP infeasible in Rust is not the lack of purity >> but rather the fact that affine types make it difficult to treat >> functions as first-class values. >> >> >> On 07/12/2018 01:40 AM, Brett Gilio wrote: >> >> Tony, >> >> I am curious on your attitude towards multi-paradigm and ML-like >> languages. I agree that functional programming is easily the better of >> the bundle in many forms of application logic and elegance (which is >> why I have come to love Scheme and Haskell), but do you see any room >> for those languages like F# or Rust which have large capacities for FP >> but are either functional-first (but not pure) or a hybrid? >> >> Brett Gilio >> >> On 07/12/2018 01:35 AM, Tony Morris wrote: >> >> I used to teach undergrad OOP nonsense. I have been teaching FP for 15 >> years. [^1] >> >> The latter is *way* easier. Existing programmers are more difficult than >> children, but still way easier to teach FP than all the other stuff. >> >> [^1]: Canberra anyone? https://qfpl.io/posts/2018-canberra-intro-to-fp/ >> >> >> On 07/12/2018 04:23 PM, Joachim Durchholz wrote: >> >> Am 11.07.2018 um 16:36 schrieb Damian Nadales: >> >> >> I speak only from my own narrow perspective. I'd say programming is >> hard, but functional programming is harder. >> >> >> Actually it's pretty much the opposite, I hear from teachers. >> >> >> Maybe that's why Java replaced Haskell in some universities >> curricula >> >> The considerations are marketable skills. >> A considerable fraction of students is looking at the curriculum and >> at job offers, and if they find that the lists don't match, they will >> go to another university. >> Also, industry keeps lobbying for teaching skills that they can use. >> Industry can give money to universities so this gives them influence >> on the curriculum (and only if they get time to talk the topic over >> with the dean). This aspect can vary considerably between countries, >> depending on how much money the universities tend to acquire from >> industry. >> >> >> https://chrisdone.com/posts/dijkstra-haskell-java. For some reason >> most programmers I know are not scared of learning OO, but they fear >> functional programming. >> >> >> Programmers were *very* scared of OO in the nineties. It took roughly >> a decade or two (depending on where you put the starting point) to get >> comfortable with OO. >> >> >> I think the reason might be that OO concepts >> >> like inheritance and passing messages between objects are a bit more >> concrete and easier to grasp (when you present toy examples at least). >> >> >> OO is about how to deal with having to pack everything into its own >> class (and how to arrange stuff into classes). >> Functional is about how to deal with the inability to update. Here, >> the functional camp actually has the easier job, because you can just >> tell people to just write code that creates new data objects and get >> over with it. Performance concerns can be handwaved away by saying >> that the compiler is hyper-aggressive, and "you can look at the >> intermediate code if you suspect the compiler is the issue". >> (Functional is a bit similar to SQL here, but the SQL optimizers are >> much less competent than GHC at detecting optimization opportunities.) >> >> >> Then you have design patterns, which have intuitive names and give >> some very general guidelines that one can try after reading them (and >> add his/her own personal twist). I doubt people can read the Monad >> laws and make any sense out of them at the first try. >> >> >> That's true, but much of the misconceptions around monads from the >> first days have been cleared up. >> But yes the monad laws are too hard to read. OTOH you won't be able to >> read the Tree code in the JDK without the explanations either. >> _______________________________________________ >> 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. >> >> >> >> >> >> _______________________________________________ >> 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. >> >> >> _______________________________________________ >> 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. >> >> >> >> _______________________________________________ >> 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. >> >> >> _______________________________________________ >> 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

LAST CALL for draft papers for presentation at IFL 2018 (deadline this week)
by Jurriaan Hage 12 Jul '18

12 Jul '18

Hello, Please, find below the last call for draft papers for presentation for IFL 2018. 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 --- Call for Draft papers for presentations ============================================================ ==================== IFL 2018 30th Symposium on Implementation and Application of Functional Languages University of Massachusetts Lowell, MA, USA September 5th-7th, 2018 http://iflconference.org ============================================================ ==================== ### 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 2018 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. Topics of interest to IFL 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 ### Keynote Speakers * Adam Chlipala, Massachusetts Institute of Technology CSAIL * Arjun Guha, University of Massachusetts Amherst ### Submissions and peer-review Differently from previous editions of IFL, IFL 2018 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2018. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations 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 post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. 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 ### Important dates Submission of regular papers: May 25, 2018 [PASSED!] Submission of draft papers: July 17, 2018 [UPCOMING!] Regular and draft papers notification: July 20, 2018 Deadline for early registration: August 8, 2018 Submission of pre-proceedings version: August 29, 2018 IFL Symposium: September 5-7, 2018 Submission of papers for post-proceedings: November 7, 2018 Notification of acceptance: December 22, 2018 Camera-ready version: February 10, 2019 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2018 ### 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. ### Organization and Program committee Chairs: Jay McCarthy & Matteo Cimini, University of Massachusetts Lowell, USA Program Committee: * Arthur Chargueraud, Inria, FR * Ben Delaware, Purdue University, USA * Christos Dimoulas, Northwestern University, USA * David Darais, University of Vermont, USA * Dominic Orchard, University of Kent, UK * Ekaterina Komendantskaya, Heriot-Watt University, UK * Garrett Morris, University of Kansas, USA * Heather Miller, EPFL & Northeastern University, CH & USA * Jeremy Yallop, University of Cambridge, UK * Keiko Nakata, SAP Innovation Center Potsdam, DE * Laura Castro, University of A Coruna, ESP * Magnus Myreen, Chalmers University of Technology, SWE * Natalia Chechina, Bournemouth University, UK * Peter Achten, Radboud Universiteit Nijmegen, NL * Peter-Michael Osera, Grinnell College, USA * Richard Eisenberg, Bryn Mawr College, USA * Trevor McDonell, University of New South Wales, AUS * Yukiyoshi Kameyama, University of Tsukuba, JAP ### Venue The 30th IFL is organized by the University of Massachusetts Lowell. The City of Lowell is located at the heart of the Merrimack Valley just 30 miles northwest of Boston. Lowell can be easily reached by train or taxi. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2018 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences.

1 0

higher kind in parametric type
by Olaf Klinke 11 Jul '18

11 Jul '18

Dear cafe, I am writing a library for parsing higher-kinded data, based on the czipwith package [1]. I ran into the following problem. I have a type class class Config p f | f -> p where f :: (* -> *) -> * is the higher-kinded data and p :: * -> * is the associated parser type. I want to add a class member that does not mention f in its type, e.g. heading :: p String Naturally, this would lead to ambiguity checks to fail, as the usage of heading does not tell which Config instance to use. My usual workaround would be to wrap `heading` in a phantom type, e.g. data Heading f p = Heading (p String) and give `heading` the type Heading f p. However, ghc-8.0.2 complains about f not being a type: • Expecting one more argument to ‘f’ Expected a type, but ‘f’ has kind ‘(* -> *) -> *’ • In the first argument of ‘Heading’, namely ‘f’ In the type signature: heading :: Heading f p In the class declaration for ‘Config’ Is there a restriction of the kinds that can be used in parametric types? Cheers, Olaf [1] http://hackage.haskell.org/package/czipwith

4 4

What is your favourite Haskell "aha" moment?
by Olaf Klinke 11 Jul '18

11 Jul '18

Dear Simon, since you'll be talking to genomics people, you might want to look at a Bachelor thesis about sequence alignment [1]. The author is a PhD student in Cambridge now. In a nutshell, the ListT monad transformer [2] is a good abstraction for full-text index structures [*] that are in heavy use among the genomics people. ListT represents the basic state transformation when a symbol is added to the query string. It also facilitates alignment of sequences with uncertain values [+]. Swapping out the monad lets you change the model of uncertainty, but you write your algorithm only once. I can provide code if required. The edit distance algorithm [3] might also go down well at Sanger. It is an example where lazyness and subtle re-arrangement turns a quadratic algorithm into an optimal one. Olaf [1] https://pp.ipd.kit.edu/uploads/publikationen/kuhnle13bachelorarbeit.pdf [2] http://hackage.haskell.org/package/list-t [3] http://users.monash.edu/~lloyd/tildeStrings/Alignment/92.IPL.html [*] Burrows-Wheeler transform, FM-index, suffix arrays, suffix trees, etc. [+] Current index structures hold only one sequence, while known genomic polymorphisms are stored separately.

1 0

Re: [Haskell-cafe] What is your favourite Haskell "aha" moment?
by Johannes Waldmann 11 Jul '18

11 Jul '18

When teaching, I like to present Property based testing - because it is so useful in itself, and it shows the power of type-level computation - the compiler constructs the dictionaries, both for testing (class Testable p), and for generating test data (class Serial a), just from the type of the property to be tested. I guess that Java folks could do this via reflection? But the popular benchmark these days is not Java - it's Python? Then it's good because there's no types that would help. Exact choice of framework - (quick|small|lean)check does not matter much for an introductory presentation. I do have a preference for enumeration by size (leancheck) not by depth (smallcheck) or randomly (quick). But then, smallcheck can enumerate functions, which is useful from the beginning (if you want to show properties of higher order functions). But then, proving is better than testing, so you might want to mention "theorems for free"? But again - the JS programmer's reaction will be: obtain a theorem from a type? what's a type? - J.W.

2 1

Re: [Haskell-cafe] if-then without -else?
by Anthony Clayden 10 Jul '18

10 Jul '18

>* Why require that each "if-then" has an "else"* Never mind the semantics, this is a piece of syntactic history. ALGOL 60 allowed omitted "else". That gave ambiguity: if p then if q then ... ... else ... There was no layout rule. Does the "else" match to the outer "if-then" or the inner? BCPL ~1965 had two constructs if p then test q then ... ... else ... "if-then" has no "else". If you want an "else" use "test-then-else". AntC

1 0

Re: [Haskell-cafe] if-then without -else?
by Johannes Waldmann 09 Jul '18

09 Jul '18

> Therefore (if False then a) would give an exception. Yes. And the question is, why is possible to write this program using "case" but not with "if". For the first part (allow incomplete sets of patterns in "case"): No matter how hard we try, Haskell is not a total language - there'll always be programs that denote bottom, by raising exceptions (e.g., from incomplete patterns), or by non-termination - which cannot be prohibited statically if we want both the language to be Turing complete, and type inference to be decidable. Cf. Agda, which is total, and therefore has a coverage checker (for patterns) as well as a termination checker. But then the second part (do not allow incomplete "if") appears to be an inconsistency in the design. Mind you - I don't propose to change this. The question is just about justification for the design. Are there applications for an incomplete "if"? I can imagine something like assertions, as in "f x = if some-precondition x then some-computation x" Of course, that's only helpful if the exception contains source information. - J.W.

5 4

Announce: Haskell Platform 8.4.3
by Gershom B 09 Jul '18

09 Jul '18

On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.4.3 Now available at https://www.haskell.org/platform/ This includes GHC 8.4.3, cabal-install 2.2.0.0, and stack 1.7.1. A full list of contents is available at https://www.haskell.org/platform/contents.html Outside of the update of the GHC to 8.4.3, the only substantive change in this release is to the new version of the primitive library, which includes a range of fixes and improvements. The list of GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.3-released And the list of changes to Primitive is available at: http://hackage.haskell.org/package/primitive-0.6.4.0/changelog There are (still) currently no 32 bit Windows builds available. We're looking into the issues preventing us from building an installer for that platform. The components all appear to work individually in such a case, and can be installed separately by users who so desire. Happy Haskell Hacking all, Gershom

1 1

Re: [Haskell-cafe] Bool is not...safe?!
by PY 09 Jul '18

09 Jul '18

09.07.2018 11:50, Dušan Kolář wrote: > > Hmm, but CLP has completely different way of evaluation and program > construction than Prolog has. Moreover, stating it is a Prolog is not > so much true then. That's the point as I can see it. > I got you. And this was my point, "declarative" for me, means some declarations/restrictions about answer/answers. No exact algorithm: you can even don't know how this is evaluated/executed. You only find some relations and declare them. And set of solvers tries to find solutions. So, modern Prolog/Logic systems are Prolog as DSL and set of solvers, right. For example, to find factorial as well as it's argument, you need to implement CLP library in Haskell explicitly (if you want to use CLP way). This is the Haskell tradition. Sure, you can do it in Python, in C (sure, such libraries already exist). But it's not declarative tradition: predicates calculus is based on backtracking and variables unification. Haskell, like Scheme is based on lambda calculus. So, evaluation is totally different. But more interesting here (regarding to Bool subj) is that Haskell can return to you 120 as factorial result, but Prolog will answer you (if it finds several results) "do you need next one?" and *result in Prolog is "Yes."*. This is important. Which can be imagine in terms of Haskell like you have not top-level `IO ()` but some `LogicMonad ()`. And all evaluations in Haskell will lead to Boolean (OK, truth/lie/yes/no) result. Evaluated (integers/floats/etc) result must be returned as output variables (your factorial is: `factorial(+N, -F)` i.e. it's one-directional only, so all functions in such Haskell also can return results in some reference/output var and evaluated to Bool). I can imagine this. Also if result is "No.", output variables unifications (bindings - in Haskell terms) will be dropped out. Unfortunately I dont know Curry and absolutely can not say: is it implemented in such way. But I'm sure that it's possible :) Joachim pointed out "cut" operation which leads to more effective code, but eliminates pure logic constructs. There are "green cuts" (does not change semantic) and "red cuts" and this shows that practical real world languages mostly are not pure functional/pure logical. But there is another point: it makes sense to have pure logical application which can be driven from C# or Java application (there are such puzzles and other games, on Android, Windows, tables/plane schedulers, expert systems, etc), but I can not imagine why I'll call for example, Haskell from the Java, because their area mostly are intersected in contrast with Java/Prolog, for example. This is some marker too, about which languages have similar "nature". I have already agreed that are possible another classifications coordinates as well as it's difficult to classify some languages because they are totally hybrid (I remember yet another such: Racket, Oz/Mozart). PS. I'm application developer only, not researcher, but I'm absolutely sure: there are people in the list which are totally in the subject, even may be some of them are devs of Curry or Mercury for example, and maybe they are laughing at me and my naive intuitions now :) > And it has nothing to do with Haskell extensions. In Haskell, the > principle remains the same, though. > > Dušan > > On pondělí 9. července 2018 10:22:15 CEST you wrote: > > > Hello, Dušan! > > > > > > > This is not Prolog, it is a Prolog with CLP extension over integers. > > > > > > as well as Haskell has a lot of extensions. I mentioned CLP as solver > > > but modern Prologs is not ISO only and has a lot of solvers (CHR, > > > different CLP, FuzzyLogic, Tabulating, etc). Actually CLP(x) in included > > > in most modern implementations. > > > > > > 09.07.2018 10:58, Dušan Kolář wrote: > > > > Hello PY/Paul, > > > > > > > > You are using misleading arguments! > > > > > > > > This is not Prolog, it is a Prolog with CLP extension over integers. > > > > > > > > > factorial(0, 1). > > > > > > > > > > factorial(N, F) :- > > > > > > > > > > N #> 0, > > > > > > > > > > N1 #= N - 1, > > > > > > > > > > F #= N * F1, > > > > > > > > > > factorial(N1, F1). > > > > > > > > > > > > > > > > > > > > I can call it: factorial(5, X) => X=120. > > > > > > > > > > But also: factorial(X, 120) => X=5. > > > > > > > > Pure Prolog is: > > > > > > > > factorial(0, 1) :- !. > > > > > > > > factorial(N, F) :- > > > > > > > > NN is N - 1, > > > > > > > > factorial(NN, FF), > > > > > > > > F is FF * N. > > > > > > > > which is a function, not a relation, as you write. > > > > > > > > Dušan Kolář >

1 0

Imperative vs. declarative (was: Bool is not...safe?!)
by Olaf Klinke 09 Jul '18

09 Jul '18

Although there is little to add to Joachim's patient explanations, and there are certainly better resources, here is my own attempt at a definition of imperative vs. declarative. The word "imperative" stems from Latin and means to command, to rule. Imperative programs tell the computer what to do, and when. Now allocate some memory, now assign this value to this variable, now check this condition and branch on it, etc. The word "declarative" also stems from Latin, meaning to make precise. Declarative languages tell the computer what data is, not when and how exactly to compute it. Haskell as a lazy language takes this even further - some code you have declared may actually never get executed. These decisions are abstracted away and made by the Haskell runtime system, in our case. Your own example of factorial is very much declarative in the above sense, because it only declares what the factorial function is, in terms of the relationship between factorial(n) and factorial(n-1). Of course the functional programmer must have a mental model of the runtime's behaviour in mind. (Recursively calling the function, in this case.) But what happens on the lower, imperative level when computing factorial(n) is not relevant for the definition of the function. Whether the principal programming constructs are functions or relations is not relevant to being declarative. In fact, the Prolog beginner can easily run into traps by declaring rules that make the solver (the low-level, imperative part of the execution) go into infinite loops, although all declarations are logically correct. Hence in Haskell as in Prolog, although both are declarative, the programmer must have some knowledge of the imperative nature of the runtime system. Olaf

3 2

Re: [Haskell-cafe] Bool is not...safe?!
by PY 09 Jul '18

09 Jul '18

Hello, Dušan! > This is not Prolog, it is a Prolog with CLP extension over integers. as well as Haskell has a lot of extensions. I mentioned CLP as solver but modern Prologs is not ISO only and has a lot of solvers (CHR, different CLP, FuzzyLogic, Tabulating, etc). Actually CLP(x) in included in most modern implementations. 09.07.2018 10:58, Dušan Kolář wrote: > > Hello PY/Paul, > > You are using misleading arguments! > > This is not Prolog, it is a Prolog with CLP extension over integers. > > > > > > factorial(0, 1). > > > factorial(N, F) :- > > > N #> 0, > > > N1 #= N - 1, > > > F #= N * F1, > > > factorial(N1, F1). > > > > > > I can call it: factorial(5, X) => X=120. > > > But also: factorial(X, 120) => X=5. > > > > > Pure Prolog is: > > factorial(0, 1) :- !. > > factorial(N, F) :- > > NN is N - 1, > > factorial(NN, FF), > > F is FF * N. > > which is a function, not a relation, as you write. > > Dušan Kolář >

1 0

hspec - type issue in error assertion
by Paweł Bałaga 08 Jul '18

08 Jul '18

Hello fellow Haskellers! I'm approaching learning the basics of Haskell by going through https://wiki.haskell.org/99_questions. At the same time I write tests for my code in Hspec. Consider question no. 2: "Find the last but one element of a list". My solution: -- Problem 02 myButLast :: [a] -> a myButLast [] = error "Empty list" myButLast [x] = error "List has only one element" myButLast [x1,x2] = x1 myButLast (x:xs) = myButLast xs and a a test: describe "02 myButLast" $ do it "returns the last but one element of a list" $ do myButLast [] `shouldThrow` anyErrorCall myButLast [1] `shouldThrow` anyErrorCall -- <- this line causes the problem myButLast [1..4] `shouldBe` 3 myButLast ['x','y','z'] `shouldBe` 'y' myButLast "abc" `shouldBe` 'b' Building tests with stack test command causes the below compilation error: • No instance for (Num (IO a0)) arising from the literal ‘1’ > • In the expression: 1 > In the first argument of ‘myButLast’, namely ‘[1]’ > In the first argument of ‘shouldThrow’, namely ‘myButLast [1]’ > | > 27 | myButLast [1] `shouldThrow` anyErrorCall > | > >From what I understand, type of myButLast [1] is different than expected by shouldThrow. What I don't understand is why exactly it behaves so and how to fix this problem. Only that one assertion doesn't compile. The others are fine. Particularly, why does myButLast [] `shouldThrow` anyErrorCall work but with one element it doesn't? Can you please give me a hand?

2 1

functions making their own memos
by Dennis Raddle 08 Jul '18

08 Jul '18

I've been wondering for some time how to handle a common use case in imperative programming, "static" variables that are accessed only inside one function, but not needed elsewhere. I think this probably has something to do with existential quantification, but in any case this is an area I'm ready to learn a lot more about. Any ideas are welcome along with suggested reading. Let's say that I have a function for generating random numbers every time it is called, but I sometimes want it to to re-use the last number depending on the time the last number was geneated: sometimesNew :: Time -> Int -> IO (Time,Int) sometimesNew lastTime lastValue = do currentTime <- <get time for system> if currentTime > lastTime + 10 then do newValue <- <get pseudorandom value> return (currentTime,newValue) else return (lastTime,lastValue) This function depends on the caller to remember its output (last time and last value) and feed that back to it. It would be nice if this function could make some kind of memo inside it itself and no one else needs to know. The case I'm working on right now is doing animation in Purescript on a canvas, in which I can control the motion of an object appearing in the animation by composing functions that control the motion. I might like to write a function that generates an overall circular trajectory, then compose it with a function that generates a slight wobbly motion. The wobbly function needs, basically, to change the motion randomly by interpolating between random positions and changing the random position only occassionally instead of during every animation frame. type MovementFunc = ... So this would generate a large circular movement: circularMovement :: MovementFunc This generates a small wobble. wobble :: MovementFunc Then I can compute the final position once per animation frame by superimposing or composing individual movements: computePosition :: [MovementFunc] -> Time -> IO Position The wobble function might like to have access to a memo of the last randomly chosen position, and how long ago in milliseconds it chose that position. Let's say that every movement function might like to have access to a memo, but the actual data type involved could be different from function to function. I also need to deal with initializing the memo. So the trick is to maintain and initialize these memo types without needing to know the internals of every function. Dennis

3 4

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