Given a pair of values of the same type, I can pretend that the pair is a functor. That is, I can "fmap" over it using bimap:bifmap :: Bifunctor f => (a -> b) -> f a a -> f b b bifmap f = bimap f f
Does this always work? (I don't see why it shouldn't)
This must have come up before. Are there any classes that already deal with degenerate bifunctors? Degenerate multi-functors?
Is there a way to make a degenerate bifunctor an instance of Functor, so that fmap can be used?
After yielding the answers that I sought, the discussion in this thread has moved quite a bit above my head. Please excuse me for being a passive reader from this point on :)submitted by haskellStudent
[link] [24 comments]
- March 31st, 2015: Today's #haskell exercise has us looking for a really big pandigital prime http://lpaste.net/6128183741660528640 ... like: REALLY big. Maybe.
- March 30th, 2015: A little math-problem to ease us into the week, suggested by @jamestanton http://lpaste.net/845208190432837632 3 consecutive integers that are co-composed
- March 27th, 2015: Today's #haskell problem is unification of multiple free variables http://lpaste.net/370356889654919168 We find this to be 'CoSimple.' 34 lines (and a new n-to-1 data mapping-type) defining not a 'CoSimple' unifier but now an 'UnSimple' one. http://lpaste.net/8114086012700852224 Ugh!
- March 26th, 2015: Unification is interesting! http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-027.pdf (Functional Unification paper) Let's look at the unification-problem for today's #haskell problem http://lpaste.net/1572781401336446976 We define simple unification (of up to one free logic variable) in a module called unification.simple, oddly enough. http://lpaste.net/5064654031335456768
- March 25th, 2015: In Old Norse, words end with 'R' (not all). For today's #Haskell problem, relations end with 'R' http://lpaste.net/8067966125595426816 Where I learn to speak Old Norse with a slightly better accent: unifying lists with headR and tailR http://lpaste.net/4854317134819360768 with unifyLists
- March 24th, 2015: For today's #haskell problem we learn that 'kayso' is a word, and we edge a bit more toward pure relational calculushttp://lpaste.net/5312260085655797760 A solution to this relational-calculus problem that is defined over Data/Control logic modules: http://lpaste.net/5718036917765799936
- March 23rd, 2015: WHO KNEW a chance meeting with @webyrd at the POPL06 would lead to today's #haskell problem? http://lpaste.net/7445712320312901632 μBikini I mean: μKanren And the solution implies that monadic-list states are logic programming? http://lpaste.net/8325001449901654016 Perhaps.
- March 19th, 2015: We now learn signal spreads ... like ... margarine! for today's #haskell problem http://lpaste.net/4389894538622140416
- March 18th, 2015: For today's #haskell problem we learn that Jupiter's moon Europa is made from Froyo, and custard! Mmmm! http://lpaste.net/127272
- March 17th, 2015: No quaternions were harmed in today's #haskell π-problem IN SPACE! http://lpaste.net/7134990338598371328
- March 16th, 2105: In space, no one can here you scream "@NASA" (nor anything else for that matter. Today's #haskell problem http://lpaste.net/7238728062383161344
- March 14th, 2015: Happy π day! A plain-text version of these NASA π-in-space puzzles are available at http://lpaste.net/7533371868384854016
- March 13th, 2015: Okay, ladies and gentlemen, today, in honor of tomorrow being π day, let's take a #coercive #logic break and π it up! http://lpaste.net/7075392225642807296
- March 12th, 2015: I wonder if the suitor's surname is Quinehttp://lpaste.net/5006337360527360000 for today's #haskell problem #coercive #logic
- March 10th, 2015: For today's #haskell problem, we wonder if Balikaya is Aharmanite or Mazdaysian http://lpaste.net/6972955679380209664 #scheherazade #coercive #logic
- March 9th, 2015: In which Iskandar is asked Kamar's Children's ages in Scheherazade's #haskell metapuzzle http://lpaste.net/8990755663210610688 #coercive #logic
- March 6th, 2015: Champernowne's constant for today's #haskell problem http://lpaste.net/6911025218794291200 Please let me know if you can NOT access this problem: I've marked it private as previous ones are being modified in place. DON'T DO THAT! In which we show @geophf triumphs with brütish-forcisms for today's #haskell solution http://lpaste.net/2944338052937416704
- March 5th, 2015: For today's #haskell problem, we ponder why they aren't calledLEFT-triangles. Is it a plot? http://lpaste.net/121797 Leftist triangles are subject to the (IO) State (monad) ... geddit? #sigh never mind anyway, solution: http://lpaste.net/122143 Or, put another way: in which we see @geophf can not have a function type that includes -> Int -> ... AND, we really need MapReduce here!
- March 4th, 2015: Truncatable primes (11 in all) are asking to be solved in today's projecteuler.com #haskell problem http://lpaste.net/121528 This @1HaskellADay problem turned into a _TWO_day solution! Worth it? Why, yes, after redesigning _TWO_ libraries! http://lpaste.net/122503
- March 3rd, 2015: There's more than a 1-in-a-million chance there are 'sum' double palindromic numbers in today's #haskell problem http://lpaste.net/121470 The solution was not too hard, M. Euler! http://lpaste.net/121471
- March 2nd, 2015: What-what! abcde * fghij is equal to ... well, something, it appears. http://lpaste.net/121421 and the prob1, prob2 winners are ...http://lpaste.net/121466 A solution to today's #haskell problem.
Are there any persistent graph databases which can efficiently support multiple simultaneous states?
This seems to related to Haskell, because many of Haskell's data-structures are persistent, because that provides efficient immutability. If I understand correctly, Haskell does not copy e.g. a large binary tree on each change. It just needs to copy the root of the tree and two huge trees can coexist together. The root of a well-balanced tree will be log(n), which is the cost of taking a snapshot of a tree. That mechanism and immutability would be very useful if one were to desire to be able to provide users with multiple versions of graph data that is queryable, because then you can take efficient snapshots of data and expose multiple versions of data to end users. Are there any projects, whether in Haskell or not, which can provide that functionality? If not, then perhaps any ideas on why it wasn't yet implemented and what technical challenges that might come with?submitted by TheJonManley
[link] [10 comments]
I have trouble remembering which is which of the following two functions:curry :: ((a, b) -> c) -> a -> b -> c uncurry :: (a -> b -> c) -> (a, b) -> c
Any tricks or mnemonic to help remember which one creates a function that takes a pair and which one creates a function that takes multiple arguments?submitted by stasiana
[link] [17 comments]
When the Japanese computer scientist Yukihiro Matsumoto decided to create Ruby, a programming language that has helped build Twitter, Hulu, and much of the modern Web, he was chasing an idea from a 1966 science fiction novel called Babel-17 by Samuel R. Delany. At the book’s heart is an invented language of the same name that upgrades the minds of all those who speak it. “Babel-17 is such an exact analytical language, it almost assures you technical mastery of any situation you look at,” the protagonist says at one point. With Ruby, Matsumoto wanted the same thing: to reprogram and improve the way programmers think....When I meet Yaron Minsky, Jane Street’s head of technology, he’s sitting at a desk with a working Enigma machine beside him, one of only a few dozen of the World War II code devices left in the world. I would think it the clear winner of the contest for Coolest Secret Weapon in the Room if it weren’t for the way he keeps talking about an obscure programming language called OCaml. Minsky, a computer science PhD, convinced his employer 10 years ago to rewrite the company’s entire trading system in OCaml.
Here's a snippet from a type checker I'm writing for an assignment.let newCondType = fromMaybe (error $ "Could not infer type of condition") (getType newCond) newConseqType = fromMaybe (error $ "Could not infer type of consequent") (getType newConseq) newAltType = fromMaybe (error $ "Could not infer type of alternative") (getType newAlt) s3 = fromMaybe (error $ "Could not unify " ++ show (apply s2 $ apply s1 newCondType) ++ " with Bool") (unify (apply s2 $ apply s1 newCondType) Bool) s4 = fromMaybe (error $ "Could not unify " ++ show (apply s3 newAltType) ++ " with " ++ show (apply s3 $ apply s2 newConseqType)) (unify (apply s3 newAltType) (apply s3 $ apply s2 newConseqType))
It looks ugly, especially since there is a monad instance for Maybe that could eliminate it. If I used do notation here, however, the context for the different types of errors would be lost.
Is there a more elegant way to write this without error and all the fromMaybes?submitted by frumsfrums
[link] [8 comments]
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]
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]
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:
- Allow code to compile when there are non-candidate instances that might match.
- 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]
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.