- Haskell-Cafe - Haskell.org

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

10 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 10 Jul '18

10 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 09 Jul '18

09 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 09 Jul '18

09 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 09 Jul '18

09 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 09 Jul '18

09 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