News aggregator

Types ala carte

del.icio.us/haskell - Sat, 12/28/2013 - 4:16pm
Categories: Offsite Blogs

Roman Cheplyaka: Resources in Tasty (update)

Planet Haskell - Sat, 12/28/2013 - 4:00pm

In a recent article I described how resources were introduced to the Tasty test framework, as well as some alternative approaches. This article describes the new API, introduced in Tasty 0.7.

To recap, there was a function, withResource, that handled creation/acquisition and disposal of resources, but if you needed to access the resource directly in the tests, you had to store the resource in an IORef (or similar) as part of the initialization routine.

At the time it seemed acceptable, but later I discovered that when the number of resources was bigger than one or two, or even not known in advance (when tests are generated rather than just written down), this was inconvenient enough to start looking for a different solution.

One of the major problems with tests receiving the resource value directly, as in

withResource :: IO a -> (a -> IO ()) -> (a -> TestTree) -> TestTree

… was that the resource could be used not only in the tests themselves, but to construct the tests, which is bad/wrong for a number of reasons. For instance, we don’t want to create the resources when we’re not running tests, but we still want to know which tests we have.

The solution I found is to pass not the value of the resource, but an IO action yielding the resource.

withResource :: IO a -> (a -> IO ()) -> (IO a -> TestTree) -> TestTree

Even though it’s an IO action, it doesn’t acquire the resource, because such a resource wouldn’t be shared across multiple tests, which is the semantics we’re after. Instead, it returns the resource which has been acquired (think: reads from an IORef or MVar). But thanks to it being an IO action, it can only be used inside a test, and not to construct or alter tests based on the resource value.

Here’s a modified example from the last article which works with this new API:

import Test.Tasty import Test.Tasty.HUnit -- assumed defintions data Foo acquire :: IO Foo release :: Foo -> IO () testWithFoo :: Foo -> Assertion (acquire, release, testWithFoo) = undefined main = do defaultMain $ withResource acquire release tests tests :: IO Foo -> TestTree tests getResource = testGroup "Tests" [ testCase "x" $ getResource >>= testWithFoo ]
Categories: Offsite Blogs

Segmentation fault/access violation when CPLUS_INCLUDE_PATH not set correctly

haskell-cafe - Sat, 12/28/2013 - 3:30pm
L.S., When I compile an application against an experimental version of wxHaskell*, the application always ends with the message: Segmentation fault/access violation in generated code , unless I set the environment variable CPLUS_INCLUDE_PATH to C:\Program Files\Haskell Platform\2013.2.0.0\mingw\lib\gcc\mingw32\4.5.2\include\c++\ , which is the same value as used when compiling wxHaskell. If I copy the contents of C:\Programs\Haskell Platform\2013.2.0.0\ to some other location and let CPLUS_INCLUDE_PATH point to the new location of directory c++, the segmentation fault message reappears. Why is this and how can create an application that also works on another computer? Regards, Henk-Jan van Tuyl * wxHaskell is a binding to the wxWidgets GUI library, which is written in C++
Categories: Offsite Discussion

Consistency issue with type level numeric literals

haskell-cafe - Sat, 12/28/2013 - 10:54am
GHC 7.6.3 has quite convenient type-level numeric literals. We can use numbers like 1 and 2 in types. However, using the type level numeral has been quite a bit of a challenge, illustrated, for example, by the following SO question. http://stackoverflow.com/questions/20809998/type-level-nats-with-literals-and-an-injective-successor It seems the challenge has the reason: the type level numerals and their operations provided in GHC.TypeLits have a consistency issue. The following code demonstrates the issue: it constructs two distinct values of the type Sing 2. Singletons aren't singletons. {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} module NotSing where import GHC.TypeLits
Categories: Offsite Discussion

www.fpcomplete.com

del.icio.us/haskell - Sat, 12/28/2013 - 9:25am
Categories: Offsite Blogs

cs.mcgill.ca

del.icio.us/haskell - Sat, 12/28/2013 - 7:35am
Categories: Offsite Blogs

hackage.haskell.org

del.icio.us/haskell - Sat, 12/28/2013 - 6:26am
Categories: Offsite Blogs

gist.github.com

del.icio.us/haskell - Sat, 12/28/2013 - 4:26am
Categories: Offsite Blogs

Audrey Tang: Perl 6:冒險的降臨

Planet Haskell - Sat, 12/28/2013 - 1:23am
<article lang="zh-Hant">

(這是 Day 24 – Advent Ventures 的中譯,作者是 Larry Wall。)

人類歷險百萬年到了今夕,
平安夜裡且讓時間暫停,
我們充滿疑問的冒險
再次等待答案的降臨。

我們到了嗎?

粘菌奮鬥十億年到了矽晶,
幸好(大致上)已忘卻不幸的往昔
以及無情天擇留下的血痕,
我們再次銘記未來的回憶。

我們到了嗎?

</article> <article lang="zh-Hant">

這個月是 Perl 降臨以來的第 26 年,
(包括 13 歲的天才小妹)
我們的小家庭一次用 24 個故事,
慶祝回家路上的種種勝利。

我們到了嗎?爹地,我們到那兒了嗎?

我們跟隨先聖,雖然徘徊但從未迷失:
我們跟隨亞伯拉罕,尋找尚未出現的城市;
我們跟隨神行客,守護將重新分配未來的哈比人
我們跟隨法師和巫士、學者和探險家、聖人和科學家。

我在星空下漫步尋思……我是否已經迷失……

無論智者或哈比人,我們總在黑暗裡啟程,
摸索前行,迎向新鮮空氣、一絲希望,
經過怪獸和深淵,追尋<hruby><rb annotation="encapsulated">封印的</rb></hruby>星光,
找到那片樂土,讓疲憊者得以休息,讓悲傷者得以療養。

等等,你們什麼意思,我不能去?——甘道夫

我們所有人都必須在沙漠裡徘徊四十年,
埋葬<hruby><rb annotation="naysayers">酸民</rb>和<rb annotation="yaysayers">鹼民</hruby>的屍骨,
讓他們的孩子有一天能跨過約旦河
進入滿是牛奶、蜂蜜和漂亮手機的新天地!

等等,你們什麼意思,我不能去?——摩西

我們把古老傳說帶進未來,
在雜沓的路途上吟誦,
背包裡裝滿史詩,口袋裡塞滿故事,
把自己的軼事傳聞留在身後。

有些好故事你還沒聽過呢。

所以孩子們,除了古老的傳說,也要收拾新的工具,
輕巧而強大的工具能幫助你們,也能幫助你們來幫助我們。
最輕巧的工具、最強大的工具,就是<hruby><rb annotation="ideas">思想</rb></hruby>,
一定要多收拾一些。我會在這裡等。

我在這兒。就是說我還沒到那兒。快!

挑選一些好朋友,也讓一些好朋友挑選你。
輪流耐心等待、急速奔走,
懷著希望前進、或絕望地爬行,
再次不屈不撓地站起來。或稀裡糊塗地,這也行。

有時你是故事的主角,但並非隨時都是。

相信你的旅程,為你帶來新的同伴;
相信新的同伴,為你帶來旅程的所需;
準備好面對永遠的邂逅,與暫時的告別。
(沒人能為暫時的邂逅、永遠的告別做好準備。)

我還不確定我是否想抵達那裡。

感謝旅途賜給你今日的夥伴,人生本就是苦樂參半。
欣賞悲欣交集的歌曲、酸甜交織的啤酒。
享受戰鬥的痛楚、擁抱的甘美。
對了,還有,享受因此得到的瘀傷,但別傷得太重。

為你還沒有抵達那裡而慶幸。

歡迎我的朋友們來這裡,我們還沒有到那裡。
歡迎來到這個家族,<hruby><rb annotation="quantum superposition">量子疊加</rb></hruby>出無數歡樂、悲傷和憧憬。
歡迎和我們一起不斷努力,盜取更多普羅米修斯之火。
這火燒得真快,卻永遠填不滿生命的篝火坑。

我們更暖和了嗎?

他們說:給人一把火……先等一下,有個即時新聞……
這真是胡扯:天火現在自由開源了⁈ 好吧,呃……
<hruby><rb annotation="blogger">部落客</rb></hruby>聽到雲端天使彈出視窗、放聲歡唱?
嗯……最好<hruby><rb annotation="do some fact checking">看看新聞小幫手</rb></hruby>……稍等一下……<hruby><rb annotation="tum tiddly tum">等等等等</rb></hruby>……

連線品質真是混帳……快收到了……

嘿,你知道嗎⁈ 物理學家琢磨出來了。
整個宇宙剛剛順利編譯完成……
現在,他們正在找人對這玩意兒進行偵錯;
嘿,我知道,我只要用 Perl 6 測試套件就行了。

【……現在你有成千上萬的問題……】

你說什麼?

(大聲)<hruby><rb annotation="sanity test">健全測試</rb></hruby> #1 合格了嗎?結果如何?

前路漫漫而修遠,
穿越河流與森林,
你走陽關道,我走獨木橋,
我們都在通往應許樂土的路上。

TimToady 得到賜福,開始指揮 Perl 朝聖者的合唱。】

我們向錫安山進發,
美麗動人的錫安山
我們要登上錫安山,美啊——

你不能去那裡。

等等,你們什麼意思,我不能去?

錯誤修正 #1:殺掉所有的蹩腳詩人。

噢……胡扯……

</article>
Categories: Offsite Blogs

www.glc.us.es

del.icio.us/haskell - Fri, 12/27/2013 - 11:45pm
Categories: Offsite Blogs

[Fp-nl] Call for participation: Dutch FunctionalProgramming Day 2014

haskell-cafe - Fri, 12/27/2013 - 11:32pm
Dear all, The next Netherlands Functional Programming day (NL-FP 2014) will take place on Friday, January 10, 2014 at the University of Amsterdam at Amsterdam Science Park. You are all cordially invited to participate and, of course, to give a presentation. The day will largely follow the pattern of the previous NL-FP days with a moderately timed start, a day of enjoyable talks in between lunch and coffee breaks and ending with a joint dinner in a nearby restaurant. All further details can be found on the NL-FP 2014 site(s): http://staff.science.uva.nl/~grelck/nl-fp-day-2014.html http://staff.science.uva.nl/~grelck/nl-fp-dag-2014.html Hope to see you all in Amsterdam in January! Best regards, Clemens Grelck
Categories: Offsite Discussion

A glimpse into a new general purpose programming language under development at Microsoft

Lambda the Ultimate - Fri, 12/27/2013 - 6:59pm

Microsoft's Joe Duffy and team have been (quietly) working on a new programming language, based on C# (for productivity, safety), but leveraging C++ features (for performance). I think it's fair to say - and agree with Joe - that a nirvana for a modern general purpose language would be one that satisfies high productivity (ease of use, intuitive, high level) AND guaranteed (type)safety AND high execution performance. As Joe outlines in his blog post (not video!):

At a high level, I classify the language features into six primary categories:

1) Lifetime understanding. C++ has RAII, deterministic destruction, and efficient allocation of objects. C# and Java both coax developers into relying too heavily on the GC heap, and offers only “loose” support for deterministic destruction via IDisposable. Part of what my team does is regularly convert C# programs to this new language, and it’s not uncommon for us to encounter 30-50% time spent in GC. For servers, this kills throughput; for clients, it degrades the experience, by injecting latency into the interaction. We’ve stolen a page from C++ — in areas like rvalue references, move semantics, destruction, references / borrowing — and yet retained the necessary elements of safety, and merged them with ideas from functional languages. This allows us to aggressively stack allocate objects, deterministically destruct, and more.


2) Side-effects understanding. This is the evolution of what we published in OOPSLA 2012, giving you elements of C++ const (but again with safety), along with first class immutability and isolation.


3) Async programming at scale. The community has been ’round and ’round on this one, namely whether to use continuation-passing or lightweight blocking coroutines. This includes C# but also pretty much every other language on the planet. The key innovation here is a composable type-system that is agnostic to the execution model, and can map efficiently to either one. It would be arrogant to claim we’ve got the one right way to expose this stuff, but having experience with many other approaches, I love where we landed.


4) Type-safe systems programming. It’s commonly claimed that with type-safety comes an inherent loss of performance. It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here, versus JIT compiling. (And one only needs to casually audit some recent security bulletins to see why these features have merit.) Other areas include allowing you to do more without allocating. Like having lambda-based APIs that can be called with zero allocations (rather than the usual two: one for the delegate, one for the display). And being able to easily carve out sub-arrays and sub-strings without allocating.


5) Modern error model. This is another one that the community disagrees about. We have picked what I believe to be the sweet spot: contracts everywhere (preconditions, postconditions, invariants, assertions, etc), fail-fast as the default policy, exceptions for the rare dynamic failure (parsing, I/O, etc), and typed exceptions only when you absolutely need rich exceptions. All integrated into the type system in a 1st class way, so that you get all the proper subtyping behavior necessary to make it safe and sound.


6) Modern frameworks. This is a catch-all bucket that covers things like async LINQ, improved enumerator support that competes with C++ iterators in performance and doesn’t demand double-interface dispatch to extract elements, etc. To be entirely honest, this is the area we have the biggest list of “designed but not yet implemented features”, spanning things like void-as-a-1st-class-type, non-null types, traits, 1st class effect typing, and more. I expect us to have a few of these in our mid-2014 checkpoint, but not all of them.


What do you think?

Categories: Offsite Discussion