News aggregator

ClassyPrelude vs. Haskell.Language.Interpreter

haskell-cafe - 50 min 2 sec ago
No answer on -beginners, so I'm trying -cafe. I'm trying to run interpreted code via ClassyPrelude, and getting some results that make me suspect a bug in the Prelude's type system. Or maybe the interpreter. Anyway, here's a bit of code that works as expected: {-# LANGUAGE NoImplicitPrelude #-} import ClassyPrelude import Language.Haskell.Interpreter main :: IO () main = do fun <- runInterpreter $ makeFun "reverse" case fun of Left e -> print e Right f -> readFile "/etc/motd" >>= hPut stdout . f makeFun expr = do set [languageExtensions := [NoImplicitPrelude]] setImportsQ [("ClassyPrelude", Nothing)] interpret expr (as :: Text -> Text) I don't think I can simplify this any further. It works as expected, and also works as expected, and prints out the contents of /etc/motd reversed. However, if you change the type signature in the last line from Text -> Text to LText -> Ltext (to get lazy text), you get no output. But if you change the function in the first line after main from "rever
Categories: Offsite Discussion

Brent Yorgey: Thoughts on grade inflation, part I: is grade inflation bad?

Planet Haskell - 5 hours 39 min ago

Grade inflation.  It’s terrible, horrible, no good, very bad, and ruining everything.  …right?

Well… I’m not so sure.  What I do know is that the typical conversation around grade inflation frustrates me. At best, it often leaves many important assumptions unstated and unquestioned.  Is grade inflation really bad? If so, why? What are the underlying assumptions and values that drive us to think of it in one way or another? At worst, the conversation is completely at the wrong level.  Grade inflation is actually a symptom pointing at a much deeper question, one that gets at the heart of education and pedagogy: what do grades mean? Or, put another way, what do grades measure?

This will be a two-part series.  In this first post, I consider the first question: is grade inflation bad?  In most conversations I have been a part of, this is taken as given, but I think it deserves more careful thought. I don’t know of any reasons to think that grade inflation is good, but I also don’t buy many of the common arguments (often implied rather than explicitly stated) as to why it is bad; in this post I consider three common ones.

What is grade inflation?

Just to make sure everyone is on the same page: by grade inflation I mean the phenomenon where average student grades are increasing over time, that is, the average student now receives higher grades than the average student of n years ago. (You could also think of it as the average value of a given grade going down over time.) This phenomenon is widespread in the US. I am only really familiar with the educational system in the US, so this post will of necessity be rather US-centric; I would be interested to hear about similarities and differences with other countries.

Let’s now consider some common arguments as to why grade inflation is bad.

The “Back in my day…” argument

This is not so much an “argument” as an attitude, and it goes something like this: “Back in MY day, a C really meant a C! These ungrateful, entitled young whippersnappers don’t understand the true value of grades…”

This is a caricature, of course, but I have definitely encountered variants of this attitude. This makes about as much sense to me as complaining “back in MY day, a dollar was really worth a dollar! And now my daughter is asking me for twenty dollars to go to a movie with her friends. TWENTY DOLLARS! These ungrateful, entitled young whippersnappers don’t understand the true value of money…” Nonsense, of course they do.  It just costs $20 to go to a movie these days. A dollar is worth what it is now worth; a C is worth what it is now worth. Get over it.  It’s not that students don’t understand “the true value of grades”, it’s just that the value of grades is different than it used to be.

There are a couple important caveats here: first, one can, of course, argue about what the value of a C ought to be, based on some ideas or assumptions about what grades (should) mean. I will talk about this at length in my next post. But you cannot blame students for not understanding your idea of what grades ought to mean! Second, it is certainly possible (even likely) that student attitudes towards grades have changed, and one can (and I do!) complain about those attitudes as compared to student attitudes in the past. But that is different than claiming that students don’t understand the value of grades.

If I may hazard a guess, I think what this often boils down to is that people blame grade inflation on student attitudes of entitlement. As a potential contributing factor to grade inflation (and insofar as we would like to teach students different attitudes), that is certainly worth thinking about. But grade inflation potentially being caused by something one dislikes is not an argument that grade inflation itself is bad.

The compression argument

Of course, there’s one important difference between money and grades: amounts of money have no upper limit, whereas grades are capped at A+.  This brings us to what I often hear put forth as the biggest argument against grade inflation, that it compresses grades into a narrower and narrower band, squeezed from above by that highest possible A+.  The problem with this, some argue, is that grade compression causes information to be lost.  The “signal” of grades becomes noisier, and it becomes harder for, say, employers and grad schools to be able to distinguish between different students.

My first, more cynical reaction is this: well, cry me a river for those poor, poor employers and grad schools, who will now have to assess students on real accomplishments, skills, and personal qualities, or (more likely) find some other arbitrary measurement to use. Do we really think grades are such a high-quality signal in the first place? Do they really measure something important and intrinsic about a student? (More on this in my next post.)  If the signal is noisy or arbitrary in the first place then compressing it really doesn’t matter that much.

Less cynically, let’s suppose the grade-signal really is that high-quality and important, and we are actually worried about the possibility of losing information. Consider the extreme situation, where grade inflation has progressed to such a degree that professors only give one of two possible grades: A (“outstandingly excellent”) or A+ (“superlatively superb”). An A- is so insultingly low that professors never give it (for fear of lawsuits, perhaps); for simplicity’s sake let’s suppose that no one ever fails, either. In this hypothetical scenario, at an institution like Williams where students take 32 courses, there are only 33 possible GPAs: you could get 32 A+’s, or one A and 31 A+’s, or two A’s and 30 A+’s… all the way down to getting all A’s (“straight-A student” means something rather different in this imaginary universe!).

But here’s the thing: I think 33 different GPAs would still be enough! I honestly don’t think companies or grad schools can meaningfully care about distinctions finer than having 33 different buckets of students. (If you think differently, I’d love to hear your argument.) If student GPAs are normally distributed, this even means that the top few buckets have much less than 1/33 of all the students. So if the top grad schools and companies want to only consider the top 1% of all students (or whatever), they can just look at the top bucket or two. You might say this is unfair for the students, but really, I can’t see how this would be any more or less fair than the current system.

Of course, under this hypothetical two-grade system, GPAs might not be normally distributed. For one thing, if grade inflation kept going, the distribution might become more and more skewed to the right, until, for example, half of all students were getting straight A+’s, or, in the theoretical limit, all students get only A+’s. But I really don’t think this would actually happen; I think you would see some regulating effects kick in far before this theoretical limit was reached. Professors would not actually be willing to give all A+’s (or even, for that matter, all A’s and A+’s).

The GPAs could also be very bimodal, if, for example, students are extremely consistent: a student who consistently scores in the top 40% of every class would get the same grades (all A+’s) as a student who consistently scores in the top 10%. However, I doubt this is how it would work (as any professor knows, “consistent” and “student” are a rare pairing). It would be interesting to actually work out what GPA distributions would result from various assumptions about student behavior.

The moving target argument

The final argument against grade inflation that I sometimes hear goes like this: the problem is not so much that the average GPA is going up but simply that it is moving at all, which makes it harder for grad schools and employers to know how to calibrate their interpretations. But I don’t really buy this one either. The value of money is moving too, and yes, in some grand sense I suppose that makes it slightly harder for people to figure out how much things are worth. But somehow, everyone seems to manage just fine. I think employers and grad schools will manage just fine too. I don’t think GPAs are changing anywhere near fast enough for it to make much difference. And in any case, most of the time, the only thing employers and grad schools really care about is comparing the GPAs of students who graduated around the same time, in which case the absolute average GPA doesn’t matter at all. (One can make an argument about the difficulties caused by different schools having different average GPAs, but that is always going to be an issue, grade inflation or no.)

In the end, then, I am not so sure that grade inflation per se is such a terrible thing. However, it is well worth pondering the causes of grade inflation, and the deeper questions it leads to: what are grades? Why do we give them? What purposes do they serve, and what do they measure? I’ll take up these questions in a subsequent post.


Categories: Offsite Blogs

286 Microsoft users (Windows and .Net) express their needs for Haskell improvements -- and it's a long list

Haskell on Reddit - 6 hours 3 min ago

Using the published data from the large-scale Haskell needs survey, I extracted only the 286 respondents (36% of of 797) to v1.0 who rated improvements in Windows (89% of these respondents) and/or .Net support (38%) as important or crucial in their future choice of Haskell for a project.

For these users, here are other topics where they said improvements to this area would be crucial or important to their choice of Haskell for a future project.

  • Package management & cabal. 42% crucial + 34% important
  • Debugging & profiling. 41% crucial + 30% important
  • Documentation & learning resources. 39% crucial + 34% important
  • Colleagues' perception of Haskell. 38% crucial + 27% important
  • IDE improvement. 33% crucial + 35% important
  • Ease of writing high-performance programs. 26% crucial + 39% important
  • Availability of skilled personnel. 29% crucial + 29% important
  • Deployment features. 21% crucial + 33% important
  • Installation. 21% crucial + 25% important
  • Application templates, frameworks, design patterns, reusable samples, etc. 19% crucial + 34% important
  • Scalability to large datasets. 18% crucial + 31% important
  • Server-side web application support. 22% crucial + 20% important
  • Thorough support for math or data analysis (as you might see in Matlab, R, or NumPy). 19% crucial + 25% important

That's a lot of strong concerns! Of the 231 non-students, only 17% of them said their current organization uses Haskell, and only 20% said agree or strongly agree to "My organization would soon use a lot more Haskell in our work." Even so, 55% would recommend Haskell for a project at their workplace, about the same as the non-Windows respondents.

submitted by FPguy
[link] [4 comments]
Categories: Incoming News

How do I abstract reads on a distributed key-value store (am I justified in using unsafePerformIO)?

Haskell on Reddit - 6 hours 55 min ago

In Scala, I might have code like:

trait KeyValueStore { def get(key: String): Option[String] } class InMemoryKeyValueStore(map: Map[String, String]) extends KeyValueStore { def get(key: String): Option[String] = map.get(key) } class DistributedKeyValueStore extends KeyValueStore { def get(key: String): Option[String] = // do network ops... }

In Haskell, ideally, I'd have something like:

type KeyValueStore = String -> Maybe String

However, in Haskell, network accesses aren't pure. As such, computations would need to be wrapped in an IO monad. However, this feels somewhat problematic to me, since Monadic IO is used to sequence operations, and the order of accesses to the key-value store is irrelevant. Moreover, it would be nice to get the benefits of lazy evaluation (so that keys aren't requested if their contents aren't actually used).

So, it seems like this may be a potential use case for unsafePerformIO. However, am I justified in using unsafePerformIO in this case? Is there a better way of getting to what I'm looking for?

EDIT: I intend the key-value store to be immutable, so when a key is requested shouldn't matter.

submitted by haskellrocks
[link] [13 comments]
Categories: Incoming News

54 Haskell developers describe the templates & samples they would like to see

Haskell on Reddit - 7 hours 41 min ago

Here's another easy but useful extract from the thousand-plus user Haskell needs survey. You can do your own analyses too, since all the raw data is there for download.

Using only the v1.0 result set (71% of total respondents) I filtered for only the users who met the following criteria:

  • I would recommend Haskell for a project at my workplace = agree or strongly agree
  • Current occupation = developer or manager
  • Improvements in application templates, frameworks, design patterns, reusable samples, etc. would be = helpful (82 respondents) or important (97) or crucial (61)

Of the 240 matching users, 54 provided comments on that question. The needs aren't uniform, but the comments are still interesting. Here they are (longest first).

  • Frameworks (e.g. yesod) could help a lot of businesses ease their way into the Haskell world. Sadly, while technically brilliant, yesod's and snap's documentation can only be described as crappy. Design patterns are IMHO popular to deal with some general conceptual weaknesses in the OO software design, I'm not sure how pure functional programm would (or could) benefit...
  • It would be helpful to see real life solutions in an annotated way... there was a youtube series 'deconstructing' programs like pandoc. More of that would be great. You can find a plethora of sources on github which are as 'real life' as it can get, but oftentimes it takes a huge amount of effort to get some basic understanding of how things work
  • Many libraries seems to assume sticking the uncommented source code on Github is adequate documentation. This isn't really unique to Haskell, but the smaller community means there's often very little in the way of community generated documentation in the form of blog posts or StackOverflow answers.
  • The big pain people here see in Haskell is there are not enough "real-world" libraries for web application purposes. I personally rather like Yesod, but it's a bit intimidating and seeing sample code for different aspects of it would aid in peoples' understanding.
  • I mentioned how much I am looking for this kind of info in another comment. I want this so bad. If I were better armed to discuss this kind of thing with our teams they would be much more inclined to believe Haskell is a viable alternative and not just a gimmick.
  • People learning Haskell often start by understanding what applicatives, functors and monads are. This is crucial but few books till date demonstrates how Haskell can be a general purpose programming language. Good example is "Real World Haskell"
  • Application templates and frameworks for GUI development would be awesome. We are currently using Qt with C++ but I would love to switch to some kind of web framework architecture with an even better separation between design and implementation.
  • I think templates and reusable samples are important for inexperienced devs/teams to feel they can get started. If haskell works for small projects built on a framework, then people get experience and trust it for larger/more bespoke work.
  • highly customizable, simple yet concise and powerful micro-framework (e.g. Wheb) centered around plugging-in other frameworks, and re-implementation of HaskellDB (or other rel-algebra monad combinator) with all the new stuff in language
  • One very good developer: "I probably will never learn Haskell because I can do everything with Node and I don't care about nice syntax." There is need to describe WHY Haskell. Visually, shortly, nicely. "They" don't get it.
  • I wouldn't go on the level of frameworks. Application templates are often unclear how to extend or modify. Design patterns and reusable samples (or just practical libraries like servant) are the way to go, in my opinion.
  • All of it exists I think. Easier integration with JVM would be better. I never used it actually, I don't know whether or not it is good. But as this integration is crucial every effort towards making it better counts.
  • very helpful for training and learning by example. but haskells functional concepts are good patterns once understood. but sometimes the extreme abstraction makes it hard to understand the value of new concepts.
  • Good practical tutorials/ samples would be great, the rest not interesting to me personally. I want my haskell programmers to get better at using haskell to deliver on features in a pragmatic way.
  • It would probably help to have samples and documentation on how to integrate Haskell into mobile applications. It would certainly help to have bindings to native mobile app development APIs.
  • It's important to have design patterns in functional programming and reusable examples as an adoption strategy for OO programmers and people without much of a mathematical background
  • Built in Frameworks will be crucial as developer can concentrate on the app specific need rather trying to implement some basic functions such as how to open file (just an example)
  • Sample are always good. Haskell is above design patterns. Or said differently: monads, comonads and arrows are all you need, you just need to work a the right semantic level.
  • I think this may aid adoption, but I also think it would be hard to find a balance between code that's simple enough to understand/follow vs. actually does something useful.
  • Code samples would be very important I believe, especially best patterns around exception handling, concurrency, monad transformers and their creation / usage / evaluation.
  • The haskell integration with continuous development chains - I know its there, but documentation would help (barrier of use reduction) - especially some best-practice
  • Right now all the FRP frameworks out there are terrible. They're cumbersome, and I hate to admit this: Microsoft is doing it better with their reactive extensions.
  • We're not afraid to start from scratch, but a library of design patterns and samples would be useful to introduce colleagues to the language and its utility.
  • Library support is crucial for the whole 'time to market' thing. Don't want to be reinventing the wheel when other languages have a ready-to-go solution.
  • Templates are very very useful. Scala ecosystem has grown rapidly because of the amazing templates from Typesafe. And most of them are user contributed.
  • Much like the documentation gap mentioned earlier. Haskell has fewer of these online than many other languages. Those that exist are often out-of-date.
  • really killer solutions that makes a real difference. Not just "Hey I ported this to Haskell, and since haskell is type safe, that is great".
  • This is something I picked up by trial and error myself, and asking in the #haskell irc channel. It would be nice to see more material here.
  • Documentation in Haddock is NOT example-driven. This needs to change. Too many crucial libraries are too esoteric at the moment.
  • For example an equivalent of composure-api in Haskell would be helpful. Also a reagent-like project for frontal applications.
  • we definitely need more samples to figure out some of the more advanced libraries (Edward Kmett, I'm looking at you)
  • Sure, always helpful to get started quickly but in the end nothing replaces good docs with lots of examples.
  • Haskell already has many great libraries but more systems examples would be the biggest factor in my field.
  • If the Haskell functions could be imported out of the box from python, that would make a big change
  • More of this would be of particular help to my workmates who are just getting started with Haskell
  • Monkey see, monkey do. The more successful leaders we have, the more likely people will follow.
  • There are common things we do like generating statistics that could be helped by such tools.
  • Having working samples does help a lot. The docs on the aeson home page for example.
  • More helpful for education, but also to get people to be productive faster
  • I guess there is still a lack of Haskell literature on practical tasks.
  • Real world experience, patterns, practical knowledge are essential.
  • Examples to learn and understand from I find very useful.
  • This is expected of a good language these days.
  • Especially error handling and design patterns.
  • This would be incredibly helpful.
  • Learn by example would be great.
  • Reusable examples are important
  • Yesod (and co) do a great job.
  • classes and modules are enough
  • To even begin a conversation!
  • Web/persistence frameworks
  • Lots and lots of samples
  • These would be great!
  • Proof of concept
submitted by FPguy
[link] [4 comments]
Categories: Incoming News

VFILES is hiring! (New York)

Haskell on Reddit - 7 hours 45 min ago

VFILES is the hippest and foulest-mouthed unification of community, content, and commerce in the fashion world today. To spare you a longer, platitudinous spiel about the brand, here's some things to watch/read about us:

We've recently relaunched our old monolithic application as a decoupled suite of Snap services serving an increasingly mature Angular frontend. You'll not only get to work with Haskell every day, but also fun tools like Neo4j, ZeroMQ, ElasticSearch, and more. Engineers here always have the right to experiment with new techniques and technology to solve problems.

You'll join a team of three engineers in a company of about twenty people amongst the editorial team, shop team, video production, etc. Everybody here is at the top of their game; it's a very refreshing environment to work in, regardless of your interest or lack thereof in fashion and pop culture.

As for fringe benefits, we throw the best parties in town [1][2], have company trips to gorgeous Montauk, organize funky Soul Cycle rides and boxing workouts with designers, models, and other personalities, and are invited to essentially everything that happens in New York.

We'll also soon be hiring a mobile engineer. The exact nature of that position is yet to be written up, but feel free to write expressing your preliminary interest if so inclined. As we're in the midst of a relaunch and redesign, those who join us in either position will have as much input as desired in both the technical direction of the company and the product itself.

You can write me directly at tim ∀ vfiles ∘ com if you are interested in hearing more and coming in to meet us.

At this time we can only consider local applicants willing and legally able to work at our Soho offices without sponsorship.

submitted by timmy_tofu
[link] [comment]
Categories: Incoming News

54 Haskell developers describe the templates & samples they would like to see

Haskell on Reddit - 9 hours 4 min ago

Here's another easy but useful extract from the thousand-plus user Haskell needs survey. You can do your own analyses too, since all the raw data is there for download.

Using only the v1.0 result set (71% of total respondents) I filtered for only the users who met the following criteria:

  • I would recommend Haskell for a project at my workplace = agree or strongly agree
  • Current occupation = developer or manager
  • Improvements in application templates, frameworks, design patterns, reusable samples, etc. would be = helpful (82 respondents) or important (97) or crucial (61)

Of the 240 matching users, 54 provided comments on that question. The needs aren't uniform, but the comments are still interesting. Here they are (longest first).

  • Frameworks (e.g. yesod) could help a lot of businesses ease their way into the Haskell world. Sadly, while technically brilliant, yesod's and snap's documentation can only be described as crappy. Design patterns are IMHO popular to deal with some general conceptual weaknesses in the OO software design, I'm not sure how pure functional programm would (or could) benefit...
  • It would be helpful to see real life solutions in an annotated way... there was a youtube series 'deconstructing' programs like pandoc. More of that would be great. You can find a plethora of sources on github which are as 'real life' as it can get, but oftentimes it takes a huge amount of effort to get some basic understanding of how things work
  • Many libraries seems to assume sticking the uncommented source code on Github is adequate documentation. This isn't really unique to Haskell, but the smaller community means there's often very little in the way of community generated documentation in the form of blog posts or StackOverflow answers.
  • The big pain people here see in Haskell is there are not enough "real-world" libraries for web application purposes. I personally rather like Yesod, but it's a bit intimidating and seeing sample code for different aspects of it would aid in peoples' understanding.
  • I mentioned how much I am looking for this kind of info in another comment. I want this so bad. If I were better armed to discuss this kind of thing with our teams they would be much more inclined to believe Haskell is a viable alternative and not just a gimmick.
  • People learning Haskell often start by understanding what applicatives, functors and monads are. This is crucial but few books till date demonstrates how Haskell can be a general purpose programming language. Good example is "Real World Haskell"
  • Application templates and frameworks for GUI development would be awesome. We are currently using Qt with C++ but I would love to switch to some kind of web framework architecture with an even better separation between design and implementation.
  • I think templates and reusable samples are important for inexperienced devs/teams to feel they can get started. If haskell works for small projects built on a framework, then people get experience and trust it for larger/more bespoke work.
  • highly customizable, simple yet concise and powerful micro-framework (e.g. Wheb) centered around plugging-in other frameworks, and re-implementation of HaskellDB (or other rel-algebra monad combinator) with all the new stuff in language
  • One very good developer: "I probably will never learn Haskell because I can do everything with Node and I don't care about nice syntax." There is need to describe WHY Haskell. Visually, shortly, nicely. "They" don't get it.
  • I wouldn't go on the level of frameworks. Application templates are often unclear how to extend or modify. Design patterns and reusable samples (or just practical libraries like servant) are the way to go, in my opinion.
  • All of it exists I think. Easier integration with JVM would be better. I never used it actually, I don't know whether or not it is good. But as this integration is crucial every effort towards making it better counts.
  • very helpful for training and learning by example. but haskells functional concepts are good patterns once understood. but sometimes the extreme abstraction makes it hard to understand the value of new concepts.
  • Good practical tutorials/ samples would be great, the rest not interesting to me personally. I want my haskell programmers to get better at using haskell to deliver on features in a pragmatic way.
  • It would probably help to have samples and documentation on how to integrate Haskell into mobile applications. It would certainly help to have bindings to native mobile app development APIs.
  • It's important to have design patterns in functional programming and reusable examples as an adoption strategy for OO programmers and people without much of a mathematical background
  • Built in Frameworks will be crucial as developer can concentrate on the app specific need rather trying to implement some basic functions such as how to open file (just an example)
  • Sample are always good. Haskell is above design patterns. Or said differently: monads, comonads and arrows are all you need, you just need to work a the right semantic level.
  • I think this may aid adoption, but I also think it would be hard to find a balance between code that's simple enough to understand/follow vs. actually does something useful.
  • Code samples would be very important I believe, especially best patterns around exception handling, concurrency, monad transformers and their creation / usage / evaluation.
  • The haskell integration with continuous development chains - I know its there, but documentation would help (barrier of use reduction) - especially some best-practice
  • Right now all the FRP frameworks out there are terrible. They're cumbersome, and I hate to admit this: Microsoft is doing it better with their reactive extensions.
  • We're not afraid to start from scratch, but a library of design patterns and samples would be useful to introduce colleagues to the language and its utility.
  • Library support is crucial for the whole 'time to market' thing. Don't want to be reinventing the wheel when other languages have a ready-to-go solution.
  • Templates are very very useful. Scala ecosystem has grown rapidly because of the amazing templates from Typesafe. And most of them are user contributed.
  • Much like the documentation gap mentioned earlier. Haskell has fewer of these online than many other languages. Those that exist are often out-of-date.
  • really killer solutions that makes a real difference. Not just "Hey I ported this to Haskell, and since haskell is type safe, that is great".
  • This is something I picked up by trial and error myself, and asking in the #haskell irc channel. It would be nice to see more material here.
  • Documentation in Haddock is NOT example-driven. This needs to change. Too many crucial libraries are too esoteric at the moment.
  • For example an equivalent of composure-api in Haskell would be helpful. Also a reagent-like project for frontal applications.
  • we definitely need more samples to figure out some of the more advanced libraries (Edward Kmett, I'm looking at you)
  • Sure, always helpful to get started quickly but in the end nothing replaces good docs with lots of examples.
  • Haskell already has many great libraries but more systems examples would be the biggest factor in my field.
  • If the Haskell functions could be imported out of the box from python, that would make a big change
  • More of this would be of particular help to my workmates who are just getting started with Haskell
  • Monkey see, monkey do. The more successful leaders we have, the more likely people will follow.
  • There are common things we do like generating statistics that could be helped by such tools.
  • Having working samples does help a lot. The docs on the aeson home page for example.
  • More helpful for education, but also to get people to be productive faster
  • I guess there is still a lack of Haskell literature on practical tasks.
  • Real world experience, patterns, practical knowledge are essential.
  • Examples to learn and understand from I find very useful.
  • This is expected of a good language these days.
  • Especially error handling and design patterns.
  • This would be incredibly helpful.
  • Learn by example would be great.
  • Reusable examples are important
  • Yesod (and co) do a great job.
  • classes and modules are enough
  • To even begin a conversation!
  • Web/persistence frameworks
  • Lots and lots of samples
  • These would be great!
  • Proof of concept
submitted by Concise_Pirate
[link] [comment]
Categories: Incoming News

CFP: GPCE' 15 (COMLAN Special Issue), Deadline June 8

General haskell list - 9 hours 51 min ago
Call for Papers: Computer Languages, Systems and Structures COMLAN Special Issue on the 14th International Conference on Generative Programming: Concepts & Experiences (GPCE'15) Papers will be selected among top ranked papers from GPCE'15: ACM SIGPLAN GPCE 2015 14th International Conference on Generative Programming: Concepts & Experiences Oct 26-27, 2015, Pittsburgh, PA, USA http://www.gpce.org GPCE keynote speaker: Prof. Priya Narasimhan (CMU, USA) GPCE is co-located with: ACM SIGPLAN conference on Systems, Programming, Languages and Applications: Software for Humanity (SPLASH 2015) and ACM SIGPLAN 8th International Conference on Software Language Engineering (SLE) 2015 ----------------------------------------------------------------- IMPORTANT DATES GPCE abstract submission : June 8, 2015 GPCE full paper submission: June 15, 2015 GPCE authors notification : July 24, 2015 GPCE camera-ready : Aug 7, 2015
Categories: Incoming News

TIL you can write `Show a => Read a => a -> a` instead of `(Show a, Read a) => a -> a`

Haskell on Reddit - 10 hours 19 min ago

I had no idea. Example:

Prelude> let f :: Show a => Read a => a -> a; f = read.show in f () ()

This could come in handy as a nice way to separate out class constraints vs equality constraints, or to generally group constraints together in big type signatures.

submitted by chrisdoner
[link] [12 comments]
Categories: Incoming News

something went wrong

del.icio.us/haskell - 12 hours 36 min ago
Categories: Offsite Blogs

help with glfw seg-fault

haskell-cafe - 13 hours 17 min ago
Hi, GLFW.swapBuffers w is the culprit. Not sure where to go from there. That's a pretty low level failure. Any suggestions. Brian
Categories: Offsite Discussion

Jan Stolarek: Injective type families for Haskell

Planet Haskell - 13 hours 19 min ago

For the last few months I have been working on extending Glasgow Haskell Compiler with injective type families. At first this seemed like a fairly simple project but in the end it turned out to be much more interesting than initially thought. (I suppose that’s how research mostly turns out.) There are still some rough edges in the implementation and it will take a few more weeks before my branch gets merged into the master development branch of GHC. But for now there is a draft paper “Injective type families for Haskell” written by me, Simon Peyton Jones, and Richard Eisenberg, that we submitted for this year’s Haskell Symposium. This is not yet the final version of the paper so any feedback will be appreciated.

The idea behind injective type families is to infer the arguments of a type family from the result. For example, given a definition:

type family F a = r | r -> a where F Char = Bool F Bool = Char F a = a

if we know (F a ~ Bool)1 then we want to infer (a ~ Char). And if we know (F a ~ Double) then we want to infer (a ~ Double). Going one step further from this, if we know (F a ~ F b) then – knowing that F is injective – we want to infer (a ~ b).

Notice that in order to declare F as injective I used new syntax. Firstly, I used “= r” to introduce a name for the result returned by the type family. Secondly, I used syntax borrowed from functional dependencies to declare injectivity. For multi-argument type families this syntax allows to declare injectivity in only some of the arguments, e.g.:

type family G a b c = r | r -> a c

Actually, you can even have kind injectivity, assuming that type arguments have polymorphic kinds.

Obviously, to make use of injectivity declared by the user GHC needs to check that the injectivity annotation is true. And that’s the really tricky part that the paper focuses on. Here’s an example:

type family T a = r | r -> a where T [a] = a

This type family returns the type of elements stored in a list. It certainly looks injective. Surprisingly, it is not. Say we have (T [T Int]). By the only equation of T this gives us (T [T Int] ~ T Int). And by injectivity we have ([T Int] ~ Int). We just proved that lists and integers are equal, which is a disaster.

The above is only a short teaser. The paper covers much more: more corner cases, our algorithm for verifying user’s injectivity annotations, details of exploiting knowledge of injectivity inside the compiler and relationship of injective type families to functional dependencies. Extended version of the paper also comes with proofs of soundness and completeness of our algorithm.

  1. ~ means unification. Think of “~” as “having a proof that two types are equal”.
Categories: Offsite Blogs

Nom vs Hammer vs Cereal

Haskell on Reddit - Mon, 05/25/2015 - 11:58pm

and someone contributed a cereal parser that beats nom - source

Could not help myself but I read that as "Haskell beats Rust". ;-)

And... looking at the actual benchmark page... the cereal based parser beats the hammer based one by a big margin too.

submitted by goliatskipson
[link] [14 comments]
Categories: Incoming News