Re: [Haskell-cafe] Haskell Weekly News: Issue 212
On Thu, 2012-01-26 at 22:52 -0500, Daniel Santa Cruz wrote: * shachaf: Haskell's type system is the perfect mix of useless and stupid. ...btw, what's the context of this quote? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Papers - Haskell Symposium 2012
Haskell 2012 ACM SIGPLAN Haskell Symposium 2012 Copenhagen, Denmark 13th September, 2012 CALL FOR PAPERS http://www.haskell.org/haskell-symposium/2012/ The ACM SIGPLAN Haskell Symposium 2012 will be co-located with the 2012 International Conference on Functional Programming (ICFP), in Copenhagen, Denmark. The purpose of the Haskell Symposium is to discuss experiences with Haskell and future developments for the language. Topics of interest include, but are not limited to: * Language Design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal treatments of the semantics of the present language or future extensions, type systems, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management as well as foreign function and component interfaces; * Tools, in the form of profilers, tracers, debuggers, pre-processors, testing tools, and suchlike; * Applications, using Haskell for scientific and symbolic computing, database, multimedia, telecom and web applications, and so forth; * Functional Pearls, being elegant, instructive examples of using Haskell; * Experience Reports, general practice and experience with Haskell, e.g., in an education or industry context. Papers in the latter three categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, reusable programming idioms, or elegant new ways of approaching a problem. (Links with more advice appear on the symposium web page.) The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a program! Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work (also for other languages where appropriate). In addition, we solicit proposals for system demonstrations, based on running (perhaps prototype) software rather than necessarily on novel research results. Such short demo proposals should explain why a demonstration would be of interest to the Haskell community. Travel Support: === Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page (http://www.sigplan.org/PAC.htm). Proceedings: There will be formal proceedings published by ACM Press. In addition to printed proceedings, accepted papers will be included in the ACM Digital Library. Authors must transfer copyright to ACM upon acceptance (for government work, to the extent transferable), but retain various rights (http://www.acm.org/publications/policies/copyright_policy). Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Accepted demo proposals, assessed for relevance by the PC, will be published on the symposium web page, but not formally published in the proceedings. Submission Details: === * Abstract Submission: 31st May 2012 * Submission Deadline: 3rd June 2012, 11:00 am, UTC * Author Notification: 27th June 2012 * Final Papers Due : 10th July 2012 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines (9pt format, more details appear on the symposium web page). The length is restricted to 12 pages, except for Experience Report papers, which are restricted to 6 pages. Each paper submission must adhere to SIGPLAN's republication policy, as explained on the web. Demo proposals are limited to 2-page abstracts, in the same format. Functional Pearls, Experience Reports, and Demo Proposals should be marked as such with those words in the title at time of submission. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Programme Committee: * Amal Ahmed, Northeastern University * Jost Berthold, University of Copenhagen * Nils Anders Danielsson, University of
[Haskell-cafe] Terminology: different levels of strictness
If I consider the functions head, length, elem sum, each is of them is strict, as: head/length/elem x/sum _|_ are always _|_. However: head (x:_|_) is never _|_. length [_|_, _|_, _|_ ...] is also never _|_. elem x [4,5,6,8,2,90,_|_,_|_ ...] is *only sometimes *_|_ (depending on x value). In fact, only sum [4,5,6,8,2,90,_|_,_|_ ...] is always _|_. Which shows they don't have the same level of strictness. So can you say things like all these functions are strict, but some are *more *than other, or sum is *deeply strict* ...? What terms can you use to compare those functions? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Terminology: different levels of strictness
There are some terms for these cases, but they are a bit ad hoc. length is what we might call spine-strict; head is head-strict. Projection analysis takes the approach that we can more precisely characterize the strictness only by considering both what is passed to the function as input, as well as how much is demanded by the context (for example, you might return a tuple, one of the values of which causes lots of evaluation, and the other of which doesn't.) Unfortunately, this is not enough precision to consider elem. Edward Excerpts from Yves Parès's message of Fri Jan 27 10:13:54 -0500 2012: If I consider the functions head, length, elem sum, each is of them is strict, as: head/length/elem x/sum _|_ are always _|_. However: head (x:_|_) is never _|_. length [_|_, _|_, _|_ ...] is also never _|_. elem x [4,5,6,8,2,90,_|_,_|_ ...] is *only sometimes *_|_ (depending on x value). In fact, only sum [4,5,6,8,2,90,_|_,_|_ ...] is always _|_. Which shows they don't have the same level of strictness. So can you say things like all these functions are strict, but some are *more *than other, or sum is *deeply strict* ...? What terms can you use to compare those functions? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name
Hi guys, There is an effort underway to make Haskell's Records better. The discussion is ongoing on the ghc-users mail list, feel free to join, or at least read on gmane. The wiki pages are up to date. Please note that we are moving in the direction of making the most minimal changes possible to achieve some simple record name-spacing. Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] help with safecopy + acid-state
Dear all,
I can't quite get safecopy to work with acid-state:
old version of code :
data T = T Foo
$(deriveSafeCopy 0 'base ''T)
new version :
data T_orig = T_orig Foo
$(deriveSafeCopy 0 'base ''T_orig)
data T = T Foo Bar
$(deriveSafeCopy 0 'extension ''T)
instance Migrate T where type MigrateFrom T = T_Orig ...
but when my (new) application reads the state from disk
(written by the old application) I get
Could not parse saved checkpoint due to the following error:
Failed reading: Duplicate version tags: [0,0]
When I change the version number in deriveSafeCopy, I get
Failed reading: safecopy: Map: Cannot find getter associated
with this version number: Version {unVersion = 2}
I don't even know where the 2 comes from.
Any hints appreciated - J.W.
signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help with safecopy + acid-state
On Fri, Jan 27, 2012 at 3:04 PM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: data T_orig = T_orig Foo $(deriveSafeCopy 0 'base ''T_orig) data T = T Foo Bar $(deriveSafeCopy 0 'extension ''T) instance Migrate T where type MigrateFrom T = T_Orig ... As you can read from deriveSafeCopy's documentation [1], you need to increase the version of your data type (e.g. change that zero to one). HTH, [1] http://hackage.haskell.org/packages/archive/safecopy/0.6.1/doc/html/Data-SafeCopy.html#v:deriveSafeCopy -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Contributing to http-conduit
the fromJust should never fail, beceause of the guard statement: | 300 = code code 400 isJust l'' isJust l' = Just $ req Because of the order of the operators, it will only evaluate fromJust after it makes sure that the argument isJust. That function in particular shouldn't throw any exceptions - it should only return Nothing. Knowing that, I don't quite think I understand what your concern is. Can you elaborate? Thanks, Myles On Thu, Jan 26, 2012 at 12:59 AM, Michael Snoyman mich...@snoyman.comwrote: I'm a little worried about the use of `fromJust`, it will give users a very confusing error message, and the error might be trigged at the wrong point in the computation. I'd feel better if checkRedirect lived in either some Failure, an Either, or maybe even in IO itself. IO might make sense if we want to implement some cookie jar functionality in the future via mutable references. Michael On Thu, Jan 26, 2012 at 10:29 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Here is a patch regarding getRedirectedRequest. Comments are very welcome. --Myles C. Maxfield On Wed, Jan 25, 2012 at 10:21 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I was planning on making the caller deal with keeping track of cookies between requests. My cookie idea only solves the problem of cookies persisting through a redirect chain - not between subsequent request chains. Do you think that Network.HTTP.Conduit should have a persistent cookie jar between caller's requests? I don't really think so. --Myles On Wed, Jan 25, 2012 at 9:28 PM, Michael Snoyman mich...@snoyman.com wrote: On Wed, Jan 25, 2012 at 8:18 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Alright, that's fine. I just wanted to be explicit about the interface we'd be providing. Taking the Request construction code out of 'http' and putting it into its own function should be a quick change - I'll have it to you soon. One possible wrench - The existing code copies some fields (like the proxy) from the original request. In order to keep this functionality, the signature would have to be: checkRedirect :: Request m - Response - Maybe (Request m) Is that okay with you? I think I'd also like to call the function something different, perhaps 'getRedirectedRequest'. Is that okay? I'll also add an example to the documentation about how a caller would get the redirection chain by re-implementing redirection (by using the example in your previous email). Sounds great. As for cookie handling - I think Network.Browser has a pretty elegant solution to this. They allow a CookieFilter which has type of URI - Cookie - IO Bool. Cookies are only put in the cookie jar if the function returns True. There is a default CookieFilter, which behaves as we would expect, but the user can override this function. That way, if you don't want to support cookies, you can just pass in (\ _ _ - return False). Also sounds good. If we're already expecting people that want specific functionality to re-implement the redirect-following code, this solution might be unnecessary. Do you think that such a concept would be beneficial for Network.HTTP.Conduit to implement? Yes, I can imagine that some people would want more fine-grained control of which cookies are accepted. Either way, I'll probably end up making a solution similar to your checkRedirect function that will just allow people to take SetCookies out of a Response and put Cookies into a Request. I'll probably also provide a default function which converts a SetCookie into a cookie by looking up the current time, inspecting the Request, etc. This will allow me to not have to change the type of Request or Response - the functions I'll be writing can deal with the raw Headers that are already in Requests and Responses. Modifying 'http' to use these functions will be straightforward. How does this sound to you? Sounds like a good plan to me. I'm not entirely certain how you're planning on implementing the cookie jar itself. In other words, if I make a request, have a cookie set, and then make another request later, where will the cookie be stored in the interim, and how will the second request know to use it? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Natural Transformations and fmap
I know a bit of category theory, but I'm trying to look at it from a
fundamental perspective; I know that I intend (m :- n) to mean natural
transformation from functor m to functor n, but the type itself (forall x.
m x - n x) doesn't necessarily enforce that.
However, the type of natural transformations comes with a free theorem, for
example
concat :: [[a]] - [a]
has the free theorem
forall f :: a - b, f strict and total, fmap f . concat = concat . fmap
(fmap f)
The strictness condition is needed; consider
broken_concat :: [[a]] - [a]
broken_concat _ = [undefined]
f = const ()
fmap f (broken_concat []) = fmap f [undefined] = [()]
broken_concat (fmap (fmap f) []) = broken_concat [] = [undefined]
The 'taming selective strictness' version of the free theorem generator[1]
allows removing the totality condition on f, but not the strictness
condition.
But in the case of concat, you can prove a stronger theorem:
forall f :: a - b, fmap f . concat = concat . fmap (fmap f)
My suspicion is that this stronger theorem holds for all strict and total
natural transformations, but I don't know how to go about proving that
suspicion. I'm a hobbyist mathematician and a professional programmer, not
the other way around :)
I think it's probably easy to prove that the monoid laws imply that mult'
and one' are strict and total.
Thus, you can in principle define plenty of natural transformations which
do not have the type f :: forall X. M X - N X.
Can you suggest one? I don't see how you can get around f needing to act
at multiple types since it can occur before and after g's fmap:
fmap g . f = f . fmap g
M A --fmap_M g-- M B
| |
f_A f_B
| |
v v
N A --fmap_N g-- N B
You can have n = m, of course, but that just means f :: M :- M.
-- ryan
[1] http://www-ps.iai.uni-bonn.de/cgi-bin/polyseq.cgi
Use this term:
/\a. let flipappend =(\xs :: [a]. fix (\rec :: [a] - [a]. \ys :: [a].
case ys of { [] - xs; y:zs - y : rec zs })) in
let concat = fix (\rec :: [[a]] - [a]. \xss :: [[a]].
case xss of { [] - []_{a}; xs:yss - flipappend
(rec yss) xs}) in
concat
[2] See http://hpaste.org/56903 Summary:
-- both of these types have obvious Functor instances
newtype (f :. g) x = O (f (g x))
data Id x = Id x
class Functor m = Monad m where
one' :: Id :- m
mult' :: (m :. m) :- m
-- instances are required to satisfy monoid laws:
--one' is a left/right identity for mult':
--forall x :: m a
--mult' . O . one' . Id $ x = x = mult' . O . fmap (one' . Id)
$ x
--mult' is associative:
--forall x :: m (m (m a))).
--mult' . O . mult' . O $ x = mult' . O . fmap (mult' . O) $ x
On Thu, Jan 26, 2012 at 9:30 PM, wren ng thornton w...@freegeek.org wrote:
On 1/23/12 10:39 PM, Ryan Ingram wrote:
type m :- n = (forall x. m x - n x)
class Functor f where fmap :: forall a b. (a - b) - f a - f b
-- Functor identity law: fmap id = id
-- Functor composition law fmap (f . g) = fmap f . fmap g
Given Functors m and n, natural transformation f :: m :- n, and g :: a -
b, how can I prove (f . fmap_m g) = (fmap_n g . f)?
That is the defining property of natural transformations. To prove it for
polymorphic functions in Haskell you'll probably want to leverage
parametricity.
I assume you don't know category theory, based on other emails in this
thread. But the definition of a natural transformation is that it is a
family of morphisms/functions { f_X :: M X - N X | X an object/type } such
that for all g :: a - b we have that f_b . fmap_m g == fmap_n g . f_a
Thus, you can in principle define plenty of natural transformations which
do not have the type f :: forall X. M X - N X. The only requirement is
that the family of morphisms obeys that equation. It's nice however that if
a function has that type, then it is guaranteed to satisfy the equation (so
long as it doesn't break the rules by playing with strictness or other
things that make it so Hask isn't actually a category).
--
Live well,
~wren
__**_
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Natural Transformations and fmap
On 1/27/12 7:56 PM, Ryan Ingram wrote:
Thus, you can in principle define plenty of natural transformations which
do not have the type f :: forall X. M X - N X.
Can you suggest one? I don't see how you can get around f needing to act
at multiple types since it can occur before and after g's fmap:
Right. A natural transformation is a family of functions (one for each
type).
My point was, forall is one way of defining a family of functions, but
it's not the only one. For instance, we could use a type class, or some
fancy generics library, or a non-parametric forall in languages which
allow type-case.
Or we could use some way of defining it which is outside of the language
in which the component functions exist. For example, consider the simply
typed lambda calculus. STLC doesn't have quantifiers so we can't define
(f :: forall X. M X - N X) as a natural transformation from within the
language, but we could still talk about the family of simply-typed
functions { f_X :: M X - N X | X - type }. Calling a family of
functions a natural transformation is an extralinguistic statement about
the functions; there are, in general, more natural transformations than
can be defined from within the language in question. Just as there are,
in general, more endofunctors than can be defined within the language
(let alone other functors).
The naturality behind natural transformations is just the fact that
(forall g, fmap g . f = f . fmap g). Satisfying the equation means that
the family of fs is parametric enough, regardless of how we've defined
the family or how/whether we can implement the family as polymorphism
within the language.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Something's weird about System.Directory.removeDirectoryRecursive
http://hackage.haskell.org/packages/archive/directory/1.1.0.1/doc/html/System-Directory.html#v:removeDirectoryRecursive The documentation says that removeDirectoryRecursive follows symlinks. However, the implementation doesn't (in most cases, see below). $ mkdir test-removeDirectoryRecursive $ cd test-removeDirectoryRecursive $ mkdir a b $ touch a/a.txt b/b.txt $ ln -s $PWD/b a/ $ ln -s $PWD/b/b.txt a/ $ ls -l a total 8.2k -rw-rw-r-- 1 john john 0 2012-01-27 23:33 a.txt lrwxrwxrwx 1 john john 65 2012-01-27 23:33 b - /home/john/test-removeDirectoryRecursive/b lrwxrwxrwx 1 john john 71 2012-01-27 23:34 b.txt - /home/john/test-removeDirectoryRecursive/b/b.txt # OK, a/ has a normal file and two symlinks in it. Let's recursively remove a/ and see what happens. $ ghci Prelude import System.Directory Prelude System.Directory removeDirectoryRecursive a Prelude System.Directory Leaving GHCi. $ ls -l a b ls: cannot access a: No such file or directory b: total 0 -rw-rw-r-- 1 john john 0 2012-01-27 23:33 b.txt # a/ was removed -- good! # # b/ and its contents are untouched, good, but goes against the docs Now, there is one case where this function *will* follow symlinks. However, I believe it is a bug because it produces odd behavior: $ sudo mkdir a [sudo] password for john: $ sudo ln -s $PWD/b a/ $ ls -l a b a: total 4.1k lrwxrwxrwx 1 root root 65 2012-01-27 23:38 b - /home/john/test-removeDirectoryRecursive/b b: total 0 -rw-rw-r-- 1 john john 0 2012-01-27 23:33 b.txt # Now a/ has a symlink, which cannot be deleted, because its containing directory is read-only to the current user. $ rm a/b rm: remove symbolic link `a/b'? y rm: cannot remove `a/b': Permission denied # What happens if removeDirectoryRecursive is called now? $ ghci Prelude import System.Directory Prelude System.Directory removeDirectoryRecursive a *** Exception: a/b: removeDirectory: permission denied (Permission denied) Prelude System.Directory Leaving GHCi. $ ls -l a b a: total 4.1k lrwxrwxrwx 1 root root 65 2012-01-27 23:38 b - /home/john/test-removeDirectoryRecursive/b b: total 0 # a/ is untouched, but b/ has been emptied! So what is the expected behavior of this function? What should it do in the presence of symlinks? IMO, the function should be documented as *not* following symlinks, and the directory check should be changed so that it returns False for symlink-to-directory. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
