News aggregator

I want to build an Android app, but I'm an amatuer programmer is haskell barking up the wrong tree?

Haskell on Reddit - Fri, 04/03/2015 - 11:47pm

I see a lot of old information around, ajhc, jhc, ghc-backend for android, most over a year old.

Hints of soon like GHC now has a proper portable backend, OpenGL apps running under SDL.

But If I want to make something using for example Material Elements from android 5.

For anyone wondering, I want to make a 3rd party chat app for a site that chat (similar fashion to facebook) only works in desktop mode.

Just to be annoying I also only use Windows at the moment maintaining another OS is a hassle.

If this is out of reach, is there another language with similar philosophy I could use?

submitted by YellowOnion
[link] [28 comments]
Categories: Incoming News

Let's update our versioning policy to bind closer to

Haskell on Reddit - Fri, 04/03/2015 - 10:49pm

An easily spottable plague of an absolute majority of Haskell packages is that they get stuck in the 0.x.x version space, thus forever retaining that "beta" feeling even if the package's API remains stable for years and has dependencies counted by thousands. Simple example: "containers".

My take on the issue is that our current versioning policy basically makes no distinction between the A and the B in A.B.C thus rendering them both as the major version. Besides the mentioned issue this leaves us only the C for both non-breaking updates and bug-fixes, the last being the reason why some authors introduce the 4th variable D for bug-fixes.

Turns out, our policy does not accomodate to the increasingly popular language-agnostic Semver convention, in which our both A and B are united under A', thus producing A'.C.D. I.e., A' is the major version, used for API-changing updates, C is the minor version, used for API-non-changing updates, D is for bugfixes.

The aforementioned incompatibility forms another issue: it is a potential reason of confusion for the newcomers, who've previously applied Semver in other languages.

What I propose is to begin the process of updating our versioning policy to accomodate to the Semver convention.

Let's discuss this.

submitted by nikita-volkov
[link] [89 comments]
Categories: Incoming News

Incoherent Instances: Why does GHC not produce a warning when picking an instance arbitrarily?

Haskell on Reddit - Fri, 04/03/2015 - 6:51pm

For GHC 7.8.4, according to the users guide picking an instance with overlapping instances follows this procedure:

  • Find all instances I that match the target constraint; that is, the target constraint is a substitution instance of I. These instance declarations are the candidates.

  • Find all non-candidate instances that unify with the target constraint. Such non-candidates instances might match when the target constraint is further instantiated. If all of them were compiled with -XIncoherentInstances, proceed; if not, the search fails.

  • Eliminate any candidate IX for which both of the following hold:

    • There is another candidate IY that is strictly more specific; that is, IY is a substitution instance of IX but not vice versa.
    • Either IX or IY was compiled with -XOverlappingInstances.
  • If only one candidate remains, pick it. Otherwise if all remaining candidates were compiled with -XInccoherentInstances, pick an arbitrary candidate.

So IncoherentInstanecs is doing two things:

  1. Allow code to compile when there are non-candidate instances that might match.
  2. If there are multiple remaining candidates, pick one arbitrarily.

Since #1 can occur without #2, why does GHC not produce a warning in case 2? Such a warning would be useful since it would probably indicate an error with your program. If your program is correct, then a warning would be a useful reminder to check that all the candidate instances have the same behavior.

Note: 7.10 adds per instance pragmas, but the users guide does not suggest it adds any warnings.

submitted by llyy6
[link] [7 comments]
Categories: Incoming News

Ken T Takusagawa: [cssohavu] Enabling arbitrary static verification

Planet Haskell - Fri, 04/03/2015 - 2:12pm

As the complexity of programs increase, static verification features of a programming language become relatively more important, compared to say code conciseness or code execution speed (at least, constant factors of code execution speed).  It becomes relatively more important for a machine verifier to be able to "understand" the program and verify correctness properties about it.  That computer verifier might become the only entity that understands the entirety of a large program written over a long period of time by many authors.

Rich type systems such as in Haskell are an example of static verification.  For example, it is useful to be able to annotate which code is stateful and what state it is modifying. Haskell monads accomplish such annotation, and the type checker checks that the annotations are correct.

However, Haskell types are not the be-all-end-all of static verification.  In more complicated code, it is easy to want to express and verify properties which cannot be expressed in its type system.

Design a language whose static verification features are user definable and may be arbitrarily complex, keeping pace with the complexity of the program.

(We will probably eventually want to express static verification of the static verification, and so on.  The difficulty of creating a correct program inherently grows faster than linearly with size of the executable part of the program.  Perhaps this will prevent the technological singularity.)

Language features such as polymorphic types or other type extensions would not be hardcoded into the compiler but imported as one of many possible static verification libraries that a program can invoke in the static verification phase of its compilation.  Theorem provers will also likely be useful as libraries.

Lisp syntax looks nice, with its arbitrary extensibility and ability to treat code as data, which is what the static verification code will be doing.

Categories: Offsite Blogs

How to Sell Excellence

Haskell on Reddit - Fri, 04/03/2015 - 6:31am
Categories: Incoming News

immortal profiling

glasgow-user - Fri, 04/03/2015 - 6:05am Would be really useful to be able to profile code without dying, especially in the context of a long-lived server. Am I missing something that would allow me to do this? cheers mark _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >
Categories: Offsite Discussion

Obfuscated haskell attempt

Haskell on Reddit - Fri, 04/03/2015 - 12:06am
type A = Integer data B = B { u :: !B, j :: B, r :: !A, i :: [A] } | Y c=head k=tail b x y=x(y)y n=map(snd)h m=2:3:5:[7] f=s(flip(a))t s x y z=x(y(z)) e=filter(v)[2..221] z=s(s(s((s)b)(s(s)flip)))s main=mapM_(print)(m++map(fst)h) v=s(flip(all)m)(s((.)(/=0))mod) t=(s(s(s(b))flip)((s)s))(s(B(Y)Y)c)k g=z(:)(z(,)c(b(s((s)map(*))c)))(s(g)k) h=c(q):c(k(q)):d(p(t((c)n))(k(n)))(k((k)q)) q=g(scanl1(+)(11:cycle(zipWith(-)((k)e)e))) a x Y = x a Y x = x a x y = case compare((r)x)(r(y)) of GT -> a(y)x _ -> B(a((j)x)y)(u(x))((r)x)(i(x)) p x y = case compare((r)x)(c(c(y))) of GT -> p(f((c)y)x)(k(y)) _ -> r(x):p(f((i)x)(a(u(x))(j(x))))y d x y = case compare((c)x)(fst(c(y))) of GT -> c(y):(d)x((k)y) LT -> d(k(x))y EQ -> d((k)x)(k(y)) submitted by bwj_pdx
[link] [10 comments]
Categories: Incoming News

Haskell-programming sysadmin opportunity at SFLC

haskell-cafe - Thu, 04/02/2015 - 8:38pm
The Software Freedom Law Center is seeking a motivated systems administrator for our small office, where we use only free and open source software. The Systems Administrator will be responsible for three main areas of work: systems maintenance, user support, and systems development. Our existing systems are a collection of Debian servers that provide central services to the office. In addition to Debian, we use: - Apache - Asterisk - Ceph - deets - dirvish and BoxBackup - Ganeti with Xen and KVM - Gitolite - Hakyll - hledger and hledger-web - Ikiwiki - Monkeysphere - Nginx - OpenLDAP - OpenVPN - Postfix/SpamAssassin/Dovecot - Radicale - Yesod as well as a number of other systems. Ideal candidates will have experience with most of these components and the ability to quickly master the ones they know less about. As our new Systems Administrator, you will be responsible for maintaining and rebuilding our servers as necessary so some knowledge of server components and hardwar
Categories: Offsite Discussion

What is {-# ... #-} in the beginning of most haskell programs?

Haskell on Reddit - Thu, 04/02/2015 - 8:33pm

I am new to Haskell (and programming in general). I have seen many haskell programs that begin with {-# LANGUAGE (something here) #-}. What is this? What does it accomplish? Is it Haskell's version of shebang?

submitted by srivkrani
[link] [55 comments]
Categories: Incoming News

Type and function naming conventions

Haskell on Reddit - Thu, 04/02/2015 - 7:44pm

A substantial program has many names. What conventions do you use to name them? I'm asking about function names and type names that are exported from a module, including data constructors.

I see many random StackOverflow questions on this topic and scattered other blog posts and such, but most of these are about object-oriented languages. Does anyone have good conventions for a functional language?

Also, what suggestions exist for how heavily to rely on the module system to disambiguate names, and how much to use typeclasses purely for naming purposes? I tried the one data type per module style, but I did not find it to be clearly superior and the fact that it breaks too many tools and conventions (makes default Haddocks worthless) led me to abandon that idea.

Sometimes I have to name something so nebulous that I resort to random short, but memorable words. When I saw a package with Biff, Tannen, Joker, and Clown as names, I knew I am not alone in this problem.

I used to routinely name fields using record syntax, but this results in an explosion of mostly useless names so now I tend to avoid records for small types whose data constructors are exported.

what I'm not talking about:

  • short vs long variable names for local bindings that aren't exported from a module

  • whether things like Monoid should not be given allegedly scary-sounding names

  • whether type variables should have long names or use a single letter

submitted by massysett
[link] [10 comments]
Categories: Incoming News

Curry arguments on a structure of functions, then fold with composition

Haskell on Reddit - Thu, 04/02/2015 - 5:59pm


3 == (+) 1 2 -- Apply (+) to 1, and then to 2. 2 == pure (*) <-> 1 <-> 2 -- Apply (*) to 1, and then to 2. [3,2] == [(+),(*)] <-> 1 <-> 2 -- Apply each of [(+), (*)] to 1, and then to 2. 21 == (compose $ [(+),(*)] <-> 3) 4 -- Apply each of [(+), (*)] to 3, compose, and then apply to 4.


infixl 4 <-> (<->) :: (Functor f) => f (a -> b) -> a -> f b fab <-> a = fmap ($ a) fab -- More readable definition for Applicative: -- (<->) :: Applicative f => f (a -> b) -> a -> f b -- fs <-> e = fs <*> pure e -- Applicative interchange law: -- fs <*> pure e = (\f -> f e) <$> fs = fmap ($ e) fs -- ======================================= compose :: Foldable f => f (c -> c) -> c -> c compose = foldr (flip (.)) id -- WARNING: this reverses the order: -- or: compose' = appEndo . foldMap Endo -- thanks, sccrstud92.

Some more toy examples

f :: Int -> Int -> Int f env = compose $ fs <-> env where fs = [const (+3), (*), const (+ (-8))] :: [Int -> Int -> Int] g :: (a -> a) -> (a -> a) -> [a] -> [a] g e1 e2 = compose $ fs <-> e1 <-> e2 where fs = [const map, const . map] :: [(a -> b) -> (a -> b) -> [a] -> [b]] -- f1 10 2 = 42 -- g (+1) (*2) [1..10] = [3,5,7,9,11,13,15,17,19,21]

It seems to me that <-> is applying functions to arguments in a way that is "perpendicular" to function composition.

Operator Label

Apparently, then Lens library contains a function ?? that is defined identically (thanks, zxamt, for pointing this out). In the use-case that I described above, I think that labeling the operator as ?? conveys very little information about what it does. In contrast, something like <-> is more readable because it looks like a function being applied to arguments.


Any comments on this pattern/style?

UPDATE: Bifunctors!

It is easy to generalize the operator to Bifunctors (or indeed multi-functors):

(<-->) :: (Bifunctor f) => f (a -> b) (a -> c) -> a -> f b c fab <--> a = bimap ($a) ($a) fab


split :: Integral a => a -> a -> (a,a) unsplit :: Integral a => a -> (a,a) -> a split k i = (div, mod) <--> i <--> k unsplit k (d, m) = k * d + m -- (split, unsplit) <--> k :: Integral a => (a -> (a,a), (a,a) -> a) composeTuple :: (b -> c, a -> b) -> a -> c composeTuple (f,g) = f . g -- For all k: composeTuple $ (split, unsplit) <--> k = id -- For all k: composeTuple $ (unsplit, split) <--> k = id


Apparently, this is an operation that works on any "representable functor". There is a whole post on it in Comonad.Reader. From the article:

distributeReader :: Functor f => f (r -> a) -> (r -> f a) distributeReader fra = \r -> fmap ($r) fra

As you can see, distributeReader is the same as <->. The article is the third in a series on applicatives. There is also a memoization library based on this idea.

submitted by newestHaskeller
[link] [8 comments]
Categories: Incoming News

wren gayle romano: An introduction to recursive types

Planet Haskell - Thu, 04/02/2015 - 3:37pm

The past couple weeks I've been teaching about recursive types and their encodings in B522. Here's a short annotated bibliography for followup reading:

  • For a basic intro to recursive types, and for the set-theoretic metatheory: see section IV, chapters 20 and 21.
    • Benjamin C. Pierce (2002) Types and Programming Languages. MIT Press.
  • The proof of logical inconsistency and non-termination is "well-known". For every type τ we can define a fixed-point combinator and use that to exhibit an inhabitant of the type:
    • fixτ = λf:(τ→τ). let e = λx:(μα.α→τ). f (x (unroll x)) in e (roll(μα.α→τ) e)
    • ⊥τ = fixτ (λx:τ. x)
  • A category-theoretic proof that having fixed-points causes inconsistency
  • The proof of Turing-completeness is "well-known". Here's a translation from the untyped λ-calculus to STLC with fixed-points:
    • (x)* = x
    • (λx. e)* = roll(μα.α→α) (λx:(μα.α→α). e*)
    • (f e)* = unroll (f*) (e*)
  • Knaster–Tarski (1955): For any monotone function, f, (a) the least fixed-point of f is the intersection of all f-closed sets, and (b) the greatest fixed-point of f is the union of all f-consistent sets.
  • For a quick introduction to category theory, a good place to start is:
    • Benjamin C. Pierce (1991) Basic Category Theory for Computer Scientists. MIT Press.
  • For a more thorough introduction to category theory, consider:
  • The Boehm–Berarducci encoding
  • Church/Boehm–Berarducci encodings are not canonical
    • [citation needed]
  • Surjective pairing cannot be encoded in STLC (i.e., the implicational fragment of intuitionistic propositional logic): see p.155
    • Morten H. Sørensen and Paweł Urzyczyn (2006) Lectures on the Curry–Howard isomorphism. Studies in Logic and the Foundations of Mathematics, v.149.
  • However, adding it is a conservative extension
  • Compiling data types with Scott encodings
  • For more on the difference between Scott and Mogensten–Scott encodings:
  • Parigot encodings
    • M. Parigot (1988) Programming with proofs: A second-order type theory. ESOP, LNCS 300, pp.145–159. Springer.
  • For more on catamorphisms, anamorphisms, paramorphisms, and apomorphisms
  • build/foldr list fusion
    • Andy Gill, John Launchbury, and Simon Peyton Jones (1993) A short cut to deforestation. In Proc. Functional Programming Languages and Computer Architecture, pp.223–232.
    • Many more links at the bottom of this page
  • For another general introduction along the lines of what we covered in class
  • "Iterators" vs "recursors" in Heyting arithmetic and Gödel's System T: see ch.10:
    • Morten H. Sørensen and Paweł Urzyczyn (2006) Lectures on the Curry–Howard isomorphism Studies in Logic and the Foundations of Mathematics, v.149.
  • There are a great many more papers by Tarmo Uustalu, Varmo Vene, Ralf Hinze, and Jeremy Gibbons on all this stuff; just google for it.
Twitter Facebook Google+ Tumblr WordPress

Categories: Offsite Blogs