• Ian Nieves added an answer:
    Is there any logic language to implement quantum programming?
    I am just now interested in explore the capabilities of quantum programming. I found some implementations on literature based on C or C++. Also there is a very promising language QML on top of the functional language Haskell that is based on linear logic, but i'll rather prefer to manage a logic language. Any one know if there is a work on such line?
    Ian Nieves · City University of New York - Hunter College

    QDENSITY appears to have been developed specifically for simulating quantum computation: http://arxiv.org/abs/1101.1785

  • Robin T. Bye added an answer:
    Any suggestions for a good book on Haskell?
    Any book or page that contains good material for language Haskell.
    Robin T. Bye · Aalesund University College

    For a bit more special purpose, the book "Parallel and Concurrent Programming in Haskell" by Simon Marlow (2013) is essential. This O'Reilly book is available for free online: 

  • Robin T. Bye added an answer:
    What are the advantages and disadvantages of using Haskell for artificial intelligence and simulations?

    Specifically, using Haskell for autonomous mobile robots and cooperative control; and for simulations that may be complex, large-scale, scalable, modular, physical, parallel, distributed, etc.

    Robin T. Bye · Aalesund University College

    In an interesting blog post, this guy argues for using Haskell for computational and (physical) simulations using AFRP (Arrowized Functional Reactive Programming) principles: 

  • Peter T Breuer added an answer:
    What are the differences between the Prolog Haskell languages?

    I am a Prolog Programmer looking at the Haskell language -- what are the similarities and differences?  Especially around Prolog predicates of "bagof" and "findall"

    Peter T Breuer · Birmingham City University

    Your question is not particular to Haskell, but applies to modern functional languages. You also need to take into account that the proper comparison is not with basic prolog, which is untyped, but with a typed logic progamming language (take your pick). Running prolog is like running some ancient untyped functional language (SASL?). There are advantages and disadvantages.

    As to "findall", I have no idea what it does. The name suggests that it finds all the elements of a list that satisfy a certain predicate. That would be

    [ x | x<-list, p(x) ]

    in a modern functional language.

    SImilarly, I don't know what "bagof" does. You need to describe these things! From the name, I presume it makes a bag out of a list. A bag is only a list reorganised to count repetitions instead of repeat them! So I would define bagof::[x]->[(x,Int)] as follows:

    bagof (x : xs) = x `bagadd` bagof xs

    bagof  [] = []

    bagadd x [] = [(x, 1)]

    bagadd x ((x, n) : ys) = (x, n+1) : ys

    bagadd x ((y, n) : ys) = (y, n) : bagadd x ys 

    I suppose Haskell already has a library of predefined "standard" bag representations and functions much more sophisticated than my invention above. In particular, I made a decision as how to represent bags that may or may not be what you like. I would have expected that Haskellers had already defined an interface called Bag x to which I could access with

    bagof : [x] -> Bag x

    (whatever they call their function - I have no idea if "bagof" is what they would have chosen). Then I would declare my particular construction above to be something that instantiates the Bag type class, and define the required interface functions.

    Indeed, both list and bag are clearly monadic because it's no problem for me to imagine every single entity in the universe as a list, and/or to imagine every single entity as a bag. So I can certainly apply a bag producing function to a bag and get not a bag of bags but a bag by unioning the pointwise results. That's monadic.

    f * b =(| [(y,n*m) | (x,n)<-b, (y,m)<-f x] |)

    (| bs |) = bag * bs

    bag x = [(x,1)] 

    Blah, blah [ I decided to mystify readers by inventing a (| ... |) notation for the union of bags and leaving you to guess what it means from the context]. I would hope that's all been set up by Haskell folks.

    --

    May I point out that the major difference between LP and FP is not over lists and bags and other such low-level things, but lies in the fact that FP is a higher-order language. `Functions are first-class data' is the mantra. But in LP predicates are not first class data .. you can't really make them on the fly and pass them around and so on. In FP, you want a function that produces a function that produces a function? No trouble. A list of functions that produce lists of functions? No trouble. 

    So you can in one sense think of a FP as a sort of improved Prolog, in that predicates can be results of computations, as well as inputs to them. There is no two-level hierarchy of predicates and the things to which predicates apply.

    In another sense, LP is a sort of improved FP, in that it allows multi-valued functions (predicates). In FP, functions produce one result given certain inputs. In LP, more than one output may satisfy the same predicate for given inputs.

    And I won't even mention directionality, or the operational semantics.

    Yes, of course there are FP/LP laguages that bridge those gaps.  I am particularly reminded of some of the languages that use narrowing instead of graph reduction/combinators or unification as their operational mechanism. They can be seen as higher-order LP, or multi-valued FP. They're pretty ambiguous about direction too! I've seen the newton iteration for square root coded up and then asked "what number gives 2 as a square root", and the answer "4" come back.

    --

    Note that if you want to translate my definitions above to Prolog, it's easy for first order functions such as list operators, and impossible for the higher order operators I defined. The important area of comparison is where you don't know that the possibility exists!

    bagof (B, [X | XS]) :- bagof(B1,  XS), bagadd(B, X, B1).

    bagof ([ ], [ ]).

    etc.

  • Stefan Savev added an answer:
    Scala implicits and type classes
    Do you know of any good material describing systematically the relationship between scala implicits and type classes?
    Stefan Savev · ResearchGate
    Thanks Michael! It's a good reference.

About Haskell

Group for Haskell learners and practitioner

Topic Followers (84) See all