My family and I might be moving down there and I wanted to learn a little more about the FP scene. If you hang out here and live in NOLA, I'd love to hear your thoughts about the FP community there. How big is it? Is it mostly hobbyists dipping their toes in the water, or are there a lot of people doing FP professionally? How is the overall local tech community?
Feel free to send me a direct message if you prefer.
I know there is a local FP meetup group, and I got in touch with the organizers.submitted by pchiusano
[link] [4 comments]
In the Curry-Howard isomorphism mapping logical implication to function types, how is it that False -> True is inhabited, but True -> False uninhabited?
Here's my understanding:
In classical logic, we define logical implication such that False -> P is true regardless of what proposition P is (even if P is false), and we define P -> False to be true if and only if P is false; P -> False is false if P is true.
Therefore, in intuitionistic logic, we say that False -> P is inhabited for all P, and P -> False is only inhabited if P is uninhabited, and vice versa.
Therefore, according to the the Curry-Howard isomorphism, there exists some function with the type Bottom -> P regardless of what type P is. There also exists some function of type Bottom -> Bottom. However, there does not exist any function of type P -> Bottom, unless P is the Bottom type.
And yet I can think of how to implement a function of type P -> Bottom (I believe in Haskell, it'd be something like const undefined; in imperative languages, you could just enter an infinite loop or throw an exception or something), but I can't see how to implement a function of type Bottom -> P without knowing P ahead of time.
How do I reconcile this?submitted by Nebu
[link] [33 comments]
In this thread, someone is told that an INI parser doesn't exist on Hackage yet,
Really? There's that low level hanging fruit available? I've never contributed to Haskell open source because I see such intimidating things on a regular basis that I just assumed that most trivial things were done a long time ago.
but later is told that it does.
However, this comment
OTOH, It's low-hanging fruit that a clever guy like you could just write and contribute. (How else did the other systems evolve....?)
got me thinking. (Not a "clever guy" by any stretch of the imagination, btw.)
Instead of jumping head-first into my Vim clone, is there any similar thing that a newbie like me could try to do? Let's get a small list going, so that everyone who'd like a project has something easy to chew on. It doesn't have to be something unsolved as such, though: anything that you think would make for a cool weekend project for someone with basic Haskell knowledge would be nice.
This is a good example of what I'm looking for. (tl;dr - it's the asm monad thing)
Edit: Whoa, I've just finished LYAH. Easy.submitted by octatoan
[link] [16 comments]
Every year I try to list some Google Summer of Code projects that I think are worthwhile. Here's this year's list. The focus is, as usual, on infrastructure projects. I think they are the most likely to succeed and give the community the highest long-term value.Generalize cabal to work with collections of packages instead of having a single package focus
Today most cabal commands assume that there's a "current" package that's the focus of most operations. As code bases grow users will end up with multiple-package projects and thus a need to build/test subsets of those packages together. We should generalize most commands (e.g. build, test, bench, and repl) to take a list of targets. You can already today specify local targets (i.e. only run these N test suites in my .cabal file). We'd extend the syntax to allow forcabal test [[PACKAGE DIR]:[SECTION]]...
Example:cabal test my-pkg1-dir:test1 my-pkg1-dir:test2 my-pkg2-dir
Implementation wise this means that the working dir (i.e. dist/ today) needs to be able to live outside the some "current" package's dir. It would live in the project "root" (e.g. some director that contains all the packages that are checked out in source form.)
We should also make it more convenient to create these collections of packages. Today you can get half way there by creating a sandbox and manually add-source all your packages. That doesn't scale well to 100-1000s of packages. We should have more clever defaults (e.g. scan subdirs for .cabal files and consider them part of the package set.)Cabal PVP compliance checker
Today GHC doesn't know if it has installed e.g. both the vanilla and profiling versions of a library. This leads to annoying error messages and an unpleasant experience when users want to profile something. If GHC tracked which versions of a library it had installed cabal could easily and automatically installed the missing profiling versions.
This is a project for a student with some background in compilers, perhaps even with some experience working on GHC.
As an experiment in language design I'd like to add two language pragmas to GHC, Strict and StrictData, the latter being a subset of the former. These pragmas would give better control over the strictness of code, on a per-module basis. The design is quite well fleshed out on the wiki. There's also the beginings of an implementation of StrictData available.