New-to-Haskell, i.e. elementary, Haskell questions; extended discussions

Re: [ANN] Crypto-API 0.9 Release

On Tue, Jan 31, 2012 at 9:36 PM, Thomas DuBuisson
<thomas.dubuisson <at> gmail.com> wrote:
> Release 0.9 Changes:
> * Crypto.Classes now exports 'Data.Serialize.encode'
> * AsymCipher now has proper fundeps
> * cpolysArr is no longer one big line

Also:

 * MacKey has phantom types.

This seems to be the only breaking change [1].

Cheers,

[1] http://hdiff.luite.com/cgit/crypto-api/commit?id=0.9

--

-- 
Felipe.

headers

Albert Y. C. Lai | 1 Feb 02:40

Re: Stuck on HXT basics

On 12-01-30 08:06 AM, Pēteris Paikens wrote:
> import Text.XML.HXT.Core
> import Text.XML.HXT.DOM.XmlTreeFilter
> selectAllText	:: ArrowXml a =>  a XmlTree XmlTree
> selectAllText  = deep isXText

Delete "import Text.XML.HXT.DOM.XmlTreeFilter". Change "isXText" to 
"isText". That is,

import Text.XML.HXT.Core
selectAllText :: ArrowXml a =>  a XmlTree XmlTree
selectAllText = deep isText

I am going to change that on Haskell Wiki.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

headers

Thomas DuBuisson | 1 Feb 03:12

Re: [ANN] Crypto-API 0.9 Release

Oh, sorry for the omission!  I've worked out of HEAD for long enough
that I though that was in 0.8.

On Tue, Jan 31, 2012 at 5:36 PM, Felipe Almeida Lessa
<felipe.lessa <at> gmail.com> wrote:
> Also:
>
>  * MacKey has phantom types.
>
> This seems to be the only breaking change [1].

headers

Richard O'Keefe | 1 Feb 03:13

Re: Some thoughts on Type-Directed Name Resolution

On 1/02/2012, at 11:38 AM, AntC wrote:
> As soon as you decide to make 'virtual record selectors' just ordinary 
> functions (so they select but not update), then you can see that field names 
> are also just ordinary functions (for selection purposes). So the semantics 
> for field 'selection' (whether or not you use dot notation) is just function 
> application. So Type-Directed Name resolution is just instance resolution. So 
> it all gets much easier.

I'm reminded of Pop-2, where f(x) and x.f meant exactly the same thing.
Overloading was a (dynamic) property of f, not a property of dot.

Ada had two reasons for adding dot syntax, and much as I admire Ada,
I'm not sure that I agree with either of them.
One was to be more familiar to programmers from other languages, but
since there remain interesting differences between x.f in Ada and x.f
in other languages, it's not clear to me how much of a kindness that
really is.  The other is that x.f means basically what f(x) would have,
*had f(x) been legal*; the aim was to be able to use methods without
having to important everything from a module.

Now that might have some relevance to Haskell.  Making f x and x.f the
same is pretty appealing, but it is imaginable that the former might
require importing the name of f from a module and the latter might not.
That is to say, it lets f and .f have completely different meanings.
Oh the joy!  Oh the improved readability!  -- on some other planet, maybe.

headers

Myles C. Maxfield | 1 Feb 03:37

Re: Contributing to http-conduit

Here are my initial ideas about supporting cookies. Note that I'm using Chrome for ideas since it's open source.

Network/HTTP/Conduit/Cookies.hs file
Exporting the following symbols:

type StuffedCookie = SetCookie

A regular SetCookie can have Nothing for its Domain and Path attributes. A StuffedCookie has to have these fields set.

type CookieJar = [StuffedCookie]

Chrome's cookie jar is implemented as (the C++ equivalent of) Map W.Ascii StuffedCookie. The key is the "eTLD+1" of the domain, so lookups for all cookies for a given domain are fast.
I think I'll stay with just a list of StuffedCookies just to keep it simple. Perhaps a later revision can implement the faster map.

getRelevantCookies :: Request m -> CookieJar -> UTCTime -> (CookieJar, Cookies)

Gets all the cookies from the cookie jar that should be set for the given Request.
The time argument is whatever "now" is (it's pulled out of the function so the function can remain pure and easily testable)
The function will also remove expired cookies from the cookie jar (given what "now" is) and return the filtered cookie jar

putRelevantCookies :: Request m -> CookieJar -> [StuffedCookie] -> CookieJar

Insert cookies from a server response into the cookie jar.
The first argument is only used for checking to see which cookies are valid (which cookies match the requested domain, etc, so site1.com can't set a cookie for site2.com)

stuffCookie :: Request m -> SetCookie -> StuffedCookie

If the SetCookie's fields are Nothing, fill them in given the Request from which it originated

getCookies :: Response a -> ([SetCookie], Response a)

Pull cookies out of a server response. Return the response with the Set-Cookie headers filtered out

putCookies :: Request a -> Cookies -> Request a

A wrapper around renderCookies. Inserts some cookies into a request.
Doesn't overwrite cookies that are already set in the request

These functions will be exported from Network.HTTP.Conduit as well, so callers can use them to re-implement redirection chains
I won't implement a cookie filtering function (like what Network.Browser has)

If you want to have arbitrary handling of cookies, re-implement redirection following. It's not very difficult if you use the API provided, and the 'http' function is open source so you can use that as a reference.

I will implement the functions according to RFC 6265
I will also need to write the following functions. Should they also be exported?

canonicalizeDomain :: W.Ascii -> W.Ascii

turns "..a.b.c..d.com..." to "a.b.c.d.com"
Technically necessary for domain matching (Chrome does it)
Perhaps unnecessary for a first pass? Perhaps we can trust users for now?

domainMatches :: W.Ascii -> W.Ascii -> Maybe W.Ascii

Does the first domain match against the second domain?
If so, return the prefix of the first that isn't in the second

pathMatches :: W.Ascii -> W.Ascii -> Bool

Do the paths match?

In order to implement domain matching, I have to have knowledge of the Public Suffix List so I know that sub1.sub2.pvt.k12.wy.us can set a cookie for sub2.pvt.k12.wy.us but not for k12.wy.us (because pvt.k12.wy.us is a "suffix"). There are a variety of ways to implement this.

As far as I can tell, Chrome does it by using a script (which a human periodically runs) which parses the list at creates a .cc file that is included in the build.

I might be wrong about the execution of the script; it might be a build step. If it is a build step, however, it is suspicious that a build target would try to download a file...

Any more elegant ideas?

Feedback on any/all of the above would be very helpful before I go off into the weeds on this project.

Thanks,

Myles C. Maxfield

On Sat, Jan 28, 2012 at 8:17 PM, Michael Snoyman <michael <at> snoyman.com> wrote:

Thanks, looks great! I've merged it into the Github tree.

On Sat, Jan 28, 2012 at 8:36 PM, Myles C. Maxfield
<myles.maxfield <at> gmail.com> wrote:
> Ah, yes, you're completely right. I completely agree that moving the
> function into the Maybe monad increases readability. This kind of function
> is what the Maybe monad was designed for.
>
> Here is a revised patch.
>
>
> On Sat, Jan 28, 2012 at 8:28 AM, Michael Snoyman <michael <at> snoyman.com>
> wrote:
>>
>> On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield
>> <myles.maxfield <at> gmail.com> wrote:
>> > 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?
>>
>> You're right, but I had to squint really hard to prove to myself that
>> you're right. That's the kind of code that could easily be broken in
>> future updates by an unwitting maintainer (e.g., me). To protect the
>> world from me, I'd prefer if the code didn't have the fromJust. This
>> might be a good place to leverage the Monad instance of Maybe.
>>
>> Michael
>
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

headers

Myles C. Maxfield | 1 Feb 06:30

Re: Contributing to http-conduit

Well, this is embarrassing. Please disregard my previous email. I should learn to read the RFC *before* submitting proposals.

--Myles

On Tue, Jan 31, 2012 at 6:37 PM, Myles C. Maxfield <myles.maxfield <at> gmail.com> wrote:

Here are my initial ideas about supporting cookies. Note that I'm using Chrome for ideas since it's open source.

Network/HTTP/Conduit/Cookies.hs file

Exporting the following symbols:

type StuffedCookie = SetCookie

A regular SetCookie can have Nothing for its Domain and Path attributes. A StuffedCookie has to have these fields set.

type CookieJar = [StuffedCookie]

Chrome's cookie jar is implemented as (the C++ equivalent of) Map W.Ascii StuffedCookie. The key is the "eTLD+1" of the domain, so lookups for all cookies for a given domain are fast.

I think I'll stay with just a list of StuffedCookies just to keep it simple. Perhaps a later revision can implement the faster map.

getRelevantCookies :: Request m -> CookieJar -> UTCTime -> (CookieJar, Cookies)

Gets all the cookies from the cookie jar that should be set for the given Request.

The time argument is whatever "now" is (it's pulled out of the function so the function can remain pure and easily testable)

The function will also remove expired cookies from the cookie jar (given what "now" is) and return the filtered cookie jar

putRelevantCookies :: Request m -> CookieJar -> [StuffedCookie] -> CookieJar

Insert cookies from a server response into the cookie jar.

The first argument is only used for checking to see which cookies are valid (which cookies match the requested domain, etc, so site1.com can't set a cookie for site2.com)

stuffCookie :: Request m -> SetCookie -> StuffedCookie

If the SetCookie's fields are Nothing, fill them in given the Request from which it originated

getCookies :: Response a -> ([SetCookie], Response a)

Pull cookies out of a server response. Return the response with the Set-Cookie headers filtered out

putCookies :: Request a -> Cookies -> Request a

A wrapper around renderCookies. Inserts some cookies into a request.

Doesn't overwrite cookies that are already set in the request

These functions will be exported from Network.HTTP.Conduit as well, so callers can use them to re-implement redirection chains

I won't implement a cookie filtering function (like what Network.Browser has)

If you want to have arbitrary handling of cookies, re-implement redirection following. It's not very difficult if you use the API provided, and the 'http' function is open source so you can use that as a reference.

I will implement the functions according to RFC 6265

I will also need to write the following functions. Should they also be exported?

canonicalizeDomain :: W.Ascii -> W.Ascii

turns "..a.b.c..d.com..." to "a.b.c.d.com"

Technically necessary for domain matching (Chrome does it)

Perhaps unnecessary for a first pass? Perhaps we can trust users for now?

domainMatches :: W.Ascii -> W.Ascii -> Maybe W.Ascii

Does the first domain match against the second domain?

If so, return the prefix of the first that isn't in the second

pathMatches :: W.Ascii -> W.Ascii -> Bool

Do the paths match?

In order to implement domain matching, I have to have knowledge of the Public Suffix List so I know that sub1.sub2.pvt.k12.wy.us can set a cookie for sub2.pvt.k12.wy.us but not for k12.wy.us (because pvt.k12.wy.us is a "suffix"). There are a variety of ways to implement this.

As far as I can tell, Chrome does it by using a script (which a human periodically runs) which parses the list at creates a .cc file that is included in the build.

I might be wrong about the execution of the script; it might be a build step. If it is a build step, however, it is suspicious that a build target would try to download a file...

Any more elegant ideas?

Feedback on any/all of the above would be very helpful before I go off into the weeds on this project.

Thanks,

Myles C. Maxfield

On Sat, Jan 28, 2012 at 8:17 PM, Michael Snoyman <michael <at> snoyman.com> wrote:
Thanks, looks great! I've merged it into the Github tree.

On Sat, Jan 28, 2012 at 8:36 PM, Myles C. Maxfield
<myles.maxfield <at> gmail.com> wrote:
> Ah, yes, you're completely right. I completely agree that moving the
> function into the Maybe monad increases readability. This kind of function
> is what the Maybe monad was designed for.
>
> Here is a revised patch.
>
>
> On Sat, Jan 28, 2012 at 8:28 AM, Michael Snoyman <michael <at> snoyman.com>
> wrote:
>>
>> On Sat, Jan 28, 2012 at 1:20 AM, Myles C. Maxfield
>> <myles.maxfield <at> gmail.com> wrote:
>> > 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?
>>
>> You're right, but I had to squint really hard to prove to myself that
>> you're right. That's the kind of code that could easily be broken in
>> future updates by an unwitting maintainer (e.g., me). To protect the
>> world from me, I'd prefer if the code didn't have the fromJust. This
>> might be a good place to leverage the Monad instance of Maybe.
>>
>> Michael
>
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

headers

Anthony Clayden | 1 Feb 07:10

Re: Some thoughts on Type-Directed Name Resolution


> On 1/02/2012, at 11:38 AM, AntC wrote:
> > As soon as you decide to make 'virtual record selectors'
> > just ordinary  functions (so they select but not update)
> > , then you can see that field names  are also just
> ordinary functions (for selection purposes). So the
> > semantics  for field 'selection' (whether or not you use
> > dot notation) is just function  application. So
> Type-Directed Name resolution is just instance resolution.
> > So  it all gets much easier.
> 
> 
> Richard O'Keefe wrote:
> ...  Making f x
> and x.f the same is pretty appealing, but it is imaginable
> that the former might require importing the name of f from
> a module and the latter might not. That is to say, it lets
> f and .f have completely different meanings. Oh the joy! 
> Oh the improved readability!  -- on some other planet,
> maybe.
> 
Hi Richard, I'm not sure I understand what you're saying.

I'm proposing x.f is _exactly_ f x. That is, the x.f gets
desugared at an early phase in compilation.
If the one needs importing some name from a module, than so
does the other.

A 'one-sided dot doesn't mean anything. (Also, I feel
vaguely nauseous even seeing it written down.)
Under my proposal, the only thing .f could mean is:
     \z -> z.f
which desugars to
     \z -> f z
which means (by eta-reduction)
      f

And to complete the story: the only thing (x.) could mean
is:
     \g -> x.g
So a use like:
     (x.) f            -- or z f, where z = (x.)
would desugar to
      f x
which is the same as x.f
A use like (x.)f (no spaces around the parens) would amount
to the same thing.

This is all so weird I'm inclined to say that one-sided dot
is probably a syntax error, and reject it. It's too
dangerously ambiguous between the syntax for 'proper' dot
notation and function composition.

Or is there something I'm not understanding?
[Good to see another NZ'er on the list, by the way.]

AntC

headers

wren ng thornton | 1 Feb 07:53

Re: ANN: combinatorics

On 1/30/12 12:55 PM, Balazs Komuves wrote:
>> --------------------------------------------
>> -- combinatorics 0.1.0
>> --------------------------------------------
>>
>> The combinatorics package offers efficient *exact* computation of common
>> combinatorial functions like the binomial coefficients and factorial.
>> (For fast *approximations*, see the math-functions package instead.)
>
> Shameless self-promotion: The combinat package (which deliberately
> does not try to own the valuable namespace Math.Combinatorics) is
> a more extensive combinatorics library:
>
> http://hackage.haskell.org/package/combinat
>
> While the main focus is the generation of combinatorial objects themselves,
> counting functions and common number sequences like the above are
> also offered.

I came across that package when looking around, but I only noticed the 
generation of combinatorial objects rather than the counting functions.

As for namespacing, I'd be happy to move things further down to 
Math.Combinatorics.Exact (or similar)[1] it's just that 
Math.Combinatorics.* seemed not to be used by the numerous packages 
floating around this area with different purposes[2], and it seems the 
natural place for this sort of work. I think it'd be nice to get a bit 
more collaboration among folks doing this stuff so we can (a) clean up 
the namespace for this topic, and (b) reduce the amount of duplicated 
effort.

[1] I'll probably end up doing that anyways, if I follow through with 
the proposed pure solution to the space-leak issue about storing the primes.

[2] HaskellForMaths, gamma, statistics, erf, math-functions, combinat,...

> Even though the binomial and factorial definition in this package are the
> naive ones, a quick experiment imply that the differences start show
> themselves around 100,000 factorial, or choosing 50,000 elements out
> of 100,000, which is probably a rather specialized use case.

In my experiments the threshold was a bit lower, but yes it's special 
purpose for people who need exact answers for big problems.

> The primes function in the combinat package is based on an old Cafe
> thread, and actually seems to be faster than the one in the combinatorics
> package.

The primes generator was some old code I had laying around for one of 
those online programming challenges; fast enough for the task. I'll 
probably trade it in for your algorithm though. One of the things I'm 
disappointed by about the current implementation is the memory overhead 
for storing the primes. It'd be nice to use chunked arrays of unboxed 
integers in order to remove all the pointers; but my attempt at doing so 
had catastrophic performance...

--

-- 
Live well,
~wren

headers

wren ng thornton | 1 Feb 08:07

Re: ANN: combinatorics

On 1/30/12 3:54 PM, Roman Cheplyaka wrote:
> Makes sense; but doesn't making the monad abstract and putting all
> functions in the monad address the fragility issue?

The primary issue with monads is that the syntax is extremely cumbersome 
for the expected use case. It'd be like paranoid C where, since order of 
evaluation is unspecified, all subexpressions are floated out into 
let-bindings. At that point (a) the verbosity is ugly, (b) the code is 
much harder to follow, and (c) it's all too easy to introduce errors 
where you use x instead of x' or the like.

The semantic model of monads just isn't a good fit for this domain. 
There really aren't any side effects going on, there's no sequencing of 
actions, there's no "little language" that's being implemented,... I 
love me some monads and all, but they just don't fit here.

--

-- 
Live well,
~wren

headers

wren ng thornton | 1 Feb 08:14

Re: ANN: combinatorics

On 1/31/12 8:58 AM, Jean-Marie Gaillourdet wrote:
> A slight variation on that approach is to use implicit parameters to parameterize your functions by the
primes. Something allong the following lines:

That is another option. However, implicit parameters are GHC-only and 
seldom used even in GHC. The RTS-hacking I mentioned in the announcement 
would also be GHC-only, which is part of the reason I'd prefer to find a 
non-cumbersome way of dealing with the issue purely. As it stands the 
library is Haskell98 (with some trivial CPP to make the Haddocks pretty) 
and it'd be nice to stay that way.

--

-- 
Live well,
~wren

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29

341	May 2012
433	April 2012
684	March 2012
723	February 2012
822	January 2012
933	December 2011
684	November 2011
726	October 2011
619	September 2011
637	August 2011
735	July 2011
1007	June 2011
995	May 2011
824	April 2011
846	March 2011
876	February 2011
840	January 2011
1035	December 2010
1030	November 2010
1507	October 2010
1279	September 2010
1692	August 2010
1619	July 2010
1195	June 2010
1302	May 2010
1498	April 2010
1605	March 2010
1180	February 2010
1133	January 2010
1649	December 2009
1481	November 2009
1287	October 2009
1156	September 2009
1131	August 2009
1085	July 2009
1521	June 2009
1444	May 2009
1698	April 2009
2224	March 2009
2166	February 2009
1988	January 2009
1420	December 2008
1206	November 2008
1640	October 2008
1556	September 2008
1193	August 2008
839	July 2008
1100	June 2008
1438	May 2008
1116	April 2008
1087	March 2008
1168	February 2008
1622	January 2008
1698	December 2007
1754	November 2007
1387	October 2007
1253	September 2007
1456	August 2007
2006	July 2007
1387	June 2007
1351	May 2007
991	April 2007
1040	March 2007
1011	February 2007
954	January 2007
1087	December 2006
760	November 2006
602	October 2006
856	September 2006
698	August 2006
641	July 2006
476	June 2006
389	May 2006
380	April 2006
439	March 2006
576	February 2006
558	January 2006
1085	December 2005
545	November 2005
421	October 2005
385	September 2005
201	August 2005
355	July 2005
343	June 2005
466	May 2005
242	April 2005
267	March 2005
287	February 2005
767	January 2005
452	December 2004
415	November 2004
389	October 2004
228	September 2004
186	August 2004
212	July 2004
128	June 2004
89	May 2004
99	April 2004
150	March 2004
63	February 2004
138	January 2004
91	December 2003
154	November 2003
231	October 2003
132	September 2003
238	August 2003
185	July 2003
153	June 2003
208	May 2003
88	April 2003
101	March 2003
127	February 2003
104	January 2003
141	December 2002
109	November 2002
109	October 2002
78	September 2002
108	August 2002
69	July 2002
62	June 2002
73	May 2002
26	April 2002