In trying to read up on dependent types, i've often read that they give us much more power than we would otherwise have. However, usually the only example provided is a vector whose length is part of its type. This is certainly useful, but surely not the only possible example of the power and utility of DTs.
What are some other day-to-day issues in programming, or mathematics, addressed by dependent types?
 And, i feel, certainly more illustrative than the (imo) ridiculous overuse of the fib function as an example of what programming in a given language is like.submitted by flexibeast
[link] [27 comments]
For all you local folks, I'll be giving a talk about my dissertation on November 5th at 4:00–5:00 in Ballantine Hall 011. For those who've heard me give talks about it before, not much has changed since NLCS 2013. But the majority of current CL/NLP, PL, and logic folks haven't seen the talk, so do feel free to stop by.
Abstract: Many natural languages allow scrambling of constituents, or so-called "free word order". However, most syntactic formalisms are designed for English first and foremost. They assume that word order is rigidly fixed, and consequently these formalisms cannot handle languages like Latin, German, Russian, or Japanese. In this talk I introduce a new calculus —the chiastic lambda-calculus— which allows us to capture both the freedoms and the restrictions of constituent scrambling in Japanese. In addition to capturing these syntactic facts about free word order, the chiastic lambda-calculus also captures semantic issues that arise in Japanese verbal morphology. Moreover, chiastic lambda-calculus can be used to capture numerous non-linguistic phenomena, such as: justifying notational shorthands in category theory, providing a strong type theory for programming languages with keyword-arguments, and exploring metatheoretical issues around the duality between procedures and values.
I recently picked up haskell and started learning it using learnyouahaskell.com I am really enjoying it so far. But tutorials don't challenge me to come up with solutions or really think about problems in this weird language. and so I want to make something using haskell, just a smallish hobby project. But I can't come up with anything interesting that I want to make. And so I was looking for suggestions.
I want something that is challenging, but not something impossible for someone fairly new to haskell. It doesn't have to be original or anything, I just want something interesting.
thanks!submitted by Minkzilla
[link] [12 comments]
A friend of mine was going through LYAH and encountered the example,data Shape = Circle Float Float Float | Rectangle Float Float Float Float surface :: Shape -> Float surface (Circle _ _ r) = pi * r ^ 2 surface (Rectangle x1 y1 x2 y2) = (abs $ x2 - x1) * (abs $ y2 - y1)
Then she asked me how she could write a function that worked only on Circles, e.g. circumference. My first instinct was to reach for DataKinds and to writecircumference :: Circle -> Float circumference (Circle _ _ r) = 2 * pi * r
But this throwsData constructor ‘Circle’ comes from an un-promotable type ‘Shape’ In the type signature for ‘circumference’: circumference :: Circle -> Float
So I guess I don't understand DataKinds as well as I thought :-). My next idea was more complicated:data ShapeType = CircleType | RectangleType data ShapeOfType (t :: ShapeType) where Circle :: Float -> Float -> Float -> Circle Rectangle :: Float -> Float -> Float -> Float -> Rectangle type Circle = ShapeOfType CircleType type Rectangle = ShapeOfType RectangleType type Shape = forall (t :: ShapeType). ShapeOfType t surface :: Shape -> Float surface (Circle _ _ r) = pi * r ^ (2 :: Int) surface (Rectangle x1 y1 x2 y2) = (abs $ x2 - x1) * (abs $ y2 - y1) circumference :: Circle -> Float circumference (Circle _ _ r) = 2 * pi * r
However, this requires extensions that I'm not comfortable introducing to a beginner. Another option would bedata Circle = Circle Float Float Float data Rectangle = Rectangle Float Float Float Float data Shape = CircleShape Circle | RectangleShape Rectangle surface :: Shape -> Float surface (CircleShape (Circle _ _ r)) = pi * r ^ 2 surface (RectangleShape (Rectangle x1 y1 x2 y2)) = (abs $ x2 - x1) * (abs $ y2 - y1) circumference :: Circle -> Float circumference (Circle _ _ r) = 2 * pi * r
But at this point I suppose you'd want to break surface into a class so that you could call it on "wrapped" and "unwrapped" Shapes.
Returning to the first example, you could dodata Shape = Circle Float Float Float | Rectangle Float Float Float Float circumference :: Shape -> Maybe Float circumference (Circle _ _ r) = Just $ 2 * pi * r circumference _ = Nothing
But this is the worst out of all.
So my question is, how would you solve this problem? Am I really overcomplicating things?submitted by markandrus
[link] [22 comments]
I spent a lot of time this past weekend trying to implement some "plugin" functionality for my project. My program processes data written in different, custom file formats, and I thought it would make sense for each format to be handled by a different plugin. Need to read a new kind of file? There's a plugin for that. Drop the plugin into the right location and you're good to go. At least that's the idea. I wasn't looking for anything fancy like supporting arbitrary languages in plugins: just plugins written in Haskell (possibly using C library and bindings) that get used by a Haskell program.
In practice, the waters are rather muddy, and it seemed like every couple of steps I took, I would get some new insight or feedback telling me I was on the wrong path. There are old blog posts, newer blog posts, allegedly "broken" libraries (plugins), arguably newer and working libraries (hlint), the capabilities of the GHC API (again, old vs new) and digging through its scarce documentation and large codebase, pre-compile vs compile the source vs interpret the source, ghc flags -static -dynamic -shared -fPIC, static lib vs shared lib, plugins written in Haskell to be used by other languages and include the GHC RTS inside, cabal flags and options, "home modules", "interface files", including dependencies or not, not being able to find dependencies, current ghci requiring .so files (I think?), interprocess comm, and probably a quite a few other issues. These were the ones I remember off the top of my head.
So after spinning my wheels, I thought I should take a breath and ask the community. What is your experience with writing plugin functionality for Haskell? What scope is feasible, and what is possible? Is it as much a science project as my recent experience suggests? Are there smarter approaches to take? Are there any active projects that successfully make use of plugins? Any insight is much appreciated!submitted by fluffynukeit
[link] [14 comments]
It's been a few weeks since the last message - and I apologize! We actually are changing the posting time to be Friday now, so hopefully this situation will be corrected preeeeetty quickly from this point forward, and hopefully will give better context over the course of a weekly discussion.
That said, let's begin!
- We've seen plenty of changes to GHC itself in the past few weeks. Some of the highlights include:
- Some changes to help make Prelude combinators fuse better. David Feuer has been leading a lot of this work, and it's been quite fruitful, with several new things now fusing (like takeWhile, scanl, scanr, and mapAccumL.
- Relatedly, Data.List.Inits should be far faster thanks to David Feuer (ref: Phab:D329).
- The testsuite driver now has preliminary support for Python 3 - which should be useful for platforms out there that sport it, and ones that will use it as the default eventually (such as Fedora 22, possibly).
- Some of the initial work by Edward Yang to remove HEAP_ALLOCED from the GHC runtime system has landed. Briefly, HEAP_ALLOCED is a check the RTS uses to determine if some address is part of the dynamic heap - but the check is a bit costly. Edward's full patchset hopes to remove this with an 8% speedup or so on average.
- GHC now has a new macro, __GLASGOW_HASKELL_PATCHLEVEL__, which will allow you to determine the point-level release of the GHC you're using. This has been a requested feature in the past we were a little hesitant of adding, but Herbert went through and did it for us. (Ref: Phab:D66)
- Template Haskell now supports LINE pragmas, thanks to Eric Mertens (ref: Phab:D299).
- Sergei Trofimovich revived libbfd debugging support for the runtime system linker, which should be of use to several daring souls out there (ref: Phab:D193).
- Several patches from Gintautas Miliauskas has improved the usability of msys and the testsuite on Windows - and he's not done yet!
- A few improvements to the x86 code generator were committed by Reid Barton and Herbert Valerio Riedel, improving size/space for certain cases (ref: Phab:D320, Phab:D163).
and more besides that, including some linker improvements, and general cleanups as usual.
- The mailing list has been busy (as usual), with some discussions including:
- Austin posted some discussion about the tentative 7.10.1 plans - we're still hoping these are accurate, so take note! We hope to freeze mid-November, and release Feburary 2015! 
- Austin also called for some feedback: GHC HQ has become convinced a 7.8.4 release is needed to fix some showstoppers - so please let him know soon if you're totally incapable of using 7.8 for something! 
- Alan Zimmerman has asked for some feedback on his proposed "AST Annotations", which will hopefully allow GHC API clients to add richer annotations to GHC's syntactic representations. The motivation is for refactoring tools like HaRe - and I'm sure all input would be appreciated. 
- Chris done sparked off a discussion about making GHCi awesomer, and I'm sure everyone can appreciate that! In particular, Chris wanted to discuss programmatic means of controlling GHCi itself, and naturally we need to ask - is the current API not enough, and why? 
- Yuras Shumovich has implemented a proposal for allowing the Haskell FFI to support C structures natively as return values - this involves interfacing with C ABI rules to properly support structure layout. While Yuras has an initial implementation in Phab:D252, some questions about the feature - including its implementation complexity - remain before it gets merged. 
- Richard Eisenberg made a modest request: can Phabricator patches have a 'roadmap', so people can instruct reviewers how to read a diff? The answer: yes, and it should be relatively easy to implement, and Austin can do so Real Soon Now™. 
- Ben Gamari started a big discussion about one-shot event semantics in the I/O manager, with a lot of replies concerning not only the bug, but machines to test the actual change on. With any luck, Ben's fix for the I/O manager and a test machine should come quickly enough. 
- Herbert Valerio Riedel opened an RFC: Should we look into using AsciiDoc for GHC? Historically, GHC's documentation has been written using DocBook, a verbose but very precise and unambiguous documentation format. However, AsciiDoc offers a much nicer markup language, while retaining DocBook support. In short, it looks like GHC may get a much more clean user manual soon. 
- Yuras opened another discussion: Should we namespace proposals we create on our wiki? What seems uncontroversial can lead to surprising discussion, and the results were mixed this time it seems. 
- Geoff Mainland stepped up and fixed Data Parallel Haskell to work with a new version of vector and GHC. Austin had disabled DPH a few weeks prior due to its difficulty to upgrade, and divergent source trees. With 7.10, GHC will hopefully ship a more modern vector and dph to boot.
- Austin asks: can we warn on tabs by default for GHC 7.10? It's an easy change and a minor one - but we should at least ask first. Vote now! 
- Philip Hölzenspies opens up a discussion about Uniques in GHC, and their impact on the compilers current design. Philip has a hopeful design to redo Unique values in GHC, and a patch to support it: Phab:D323. 
- Richard Eisenberg asks: can we somehow integrate GitHub into our development process? While GitHub doesn't have as many nice tools as something like Phabricator, it has a very high inertia factor, and Richard is interested in making the 'first step' as easy as possible for newbies. Discussions about Phab<->GitHub integrations were afoot, as well as general discussion about contributor needs. There were a lot of points brought up, but the conversation has slightly dried up now - but will surely be revived again. 
My assignment is to create two functions to delete any pair from a list of pairs that matches a given "key" (first) or "value" (second). here is my code
module DeleteFromRelation where
deleteWithKey :: (Eq a) => a -> BinaryRelation a b -> BinaryRelation a b
deleteWithValue :: (Eq b) => b -> BinaryRelation a b -> BinaryRelation a b
deleteWithKey a pairs = [c | c <- pairs, x <- fst c, x /= a]
deleteWithValue b pairs = [c | c <- pairs, x <- snd c, x /= b]
BinaryRelation a b = [(a,b)] for reference
The errors are given for the fst c and snd c saying could not deduce (a ~ [a]) from the context (Eq b)
The function type assignment is given and can't be changed.
Any clue as to what is wrong? Thanks.
[link] [13 comments]
We have two new updates to Stackage: providing cabal.config files and including Haddock documentation.Haddock documentation on snapshots
Now all new exclusive snapshots will have haddock links, which you can access via the following steps:
- Go to the stackage.org home page.
- Choose an exclusive snapshot, e.g. GHC 7.8, 2014-10-20.
- On the snapshot page will be a link in the menu entitled Haddocks.
That link will be to an index page like this from which you can view documentation of all packages included in the snapshot. This means you can generally view everything in one place, on one high availability service.Using Stackage without changing your repo
The recommended way to use Stackage is to simply change your remote-repo field in your .cabal/config file and run cabal update. Henceforth your dependencies will be resolved from Stackage, which is backed by high availability Amazon S3 storage servers, and you will have successful build plans, compilation and passing tests. Hurrah!
Try Haskell and the upcoming Haskell.org homepage were both developed with Stackage. This meant I could just specify the Stackage snapshot to use in the README and then the next time I want to upgrade I can just update the snapshot version to get a fresh working build plan.
The issue some people are facing is that they cannot change this remote-repo field, either because they're using a cabal sandbox, which doesn't support this yet, or because they just don't want to.
The solution to this, in my experience, has been for me to manually go and run cabal freeze in a project I've already built to get the cabal.config file and then give these people that file.
Now, it's automated via a cabal.config link on snapshot pages:
For new developers working on an application who want to use Stackage, they can do something like this:$ cabal sandbox init $ curl http://www.stackage.org/<stackage version>/cabal.config > cabal.config $ cabal install --only-dep
Which will install their dependencies from Hackage. We can't guarantee this will always work -- as Stackage snapshots sometimes will have a manual patch in the package to make it properly build with other packages, but otherwise it's as good as using Stackage as a repo.
A cabal freeze output in cabal.config will contain base and similar packages which are tied to the minor GHC version (e.g. GHC 7.8.2 vs GHC 7.8.3 have different base numbers), so if you get a cabal.config and you get a dependencies error about base, you probably need to open up the cabal.config and remove the line with the base constraint. Stackage snapshots as used as repos do not have this constraint (it will use whichever base your GHC major version uses).
Another difference is that cabal.config is more like an “inclusive” Stackage snapshot -- it includes packages not known to build together, unlike “exclusive” snapshots which only contain packages known to build and pass tests together. Ideally every package you need to use (directly or indirectly) will come from an exclusive snapshot. If not, it's recommended that you submit the package name to Stackage, and otherwise inclusive snapshots or cabal.config are the fallbacks you have at your disposal.