Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[geremy condra]

On Thu, Sep 2, 2010 at 3:07 PM, Sebastian Fischer
 wrote:
>
> On Aug 27, 2010, at 11:12 AM, Heinrich Apfelmus wrote:
>
>> Is it actually necessary to use a type class here? The situation is very
>> similar to
>>
>>  Luke Palmer. Haskell Antipattern: Existential Typeclass.
>>  http://lukepalmer.wordpress.com/2010/01/24/
>>
>> I suggest to use good old data types
>>
>>  data Key = Key {
>>               encrypt   :: B.ByteString -> B.ByteString,
>>               decrypt   :: B.ByteString -> B.ByteString,
>>               keyLength :: BitLength,
>>               serialize :: B.ByteString}
>>
>>  rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g)
>
> In general, I like this approach, but what are
>
>    encrypt privateKey
>
> or
>
>    decrypt publicKey
>
> supposed to do? A type-class solution also does not *prevent* programmers to
> perform such non-sensical calls, but the data-type solution *forces*
> programmers to provide non-sensical encrypt and decrypt functions when
> creating the public and private keys.

Just thought I would mention, for RSA at least these operations are
identical modular exponentiation steps, differing only in the exponent
used.

Geremy Condra
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[John Millikin]

On Thu, Sep 2, 2010 at 21:14, Mark Lentczner  wrote:
> I choose to switch Haddock's output from HTML to XHTML mostly because I have 
> found the consistency of rendering cross-browser to be greater and easier to 
> achieve with XHTML. I'm not alone in this opinion: Many well respected web 
> design authorities have promoted, and publish their own sites, in XHTML.[1] 
> Even Microsoft's own developer web site uses it[2]!

You're not generating anything browsers will parse as XHTML, so I find
it unlikely that attaching the correct doctype will cause problems. I
am extremely skeptical that using an HTML4 doctype will render
incorrectly when an unrecognized doctype works as expected across all
browsers.

> [1] See, for example:
>        http://www.alistapart.com/
>        http://www.csszengarden.com/
>        http://www.quirksmode.org/
>        http://happycog.com/
>        http://www.w3.org/
>
>        all of which are published as XHTML
>
> [2] See: http://msdn.microsoft.com/en-us/default.aspx

Browsers treat any data sent using the "text/html" MIME-type as HTML.
Those pages are being served as HTML, so browsers treat them as HTML
with an unknown doctype. In particular, CSS and JS behavior on these
sites will be that of HTML, *not* XHTML.

Firefox will show you how the page is being rendered (HTML or XHTML)
in the "page info" dialog. I don't know of any similar feature in
Chrome.

> [5] I can't find any evidence for your assertion that Internet Explorer 
> doesn't support XHTML, or the way Haddock names the files (and hence URLs).

IE versions 8 and below (I've not tested IE9) will not render XHTML --
they pop up a "save as" dialog box. You're welcome to verify this by
opening an XHTML page (such as < http://ianen.org/haskell/dbus/ >) in
IE. You may be confused, because the pages you mentioned earlier *are*
rendering in IE. However, they are not being rendered as XHTML --
again, browsers are rendering them as HTML with an unrecognized
doctype.

Haddock is generating files with an .html extension, which causes
webservers to serve it using "text/html", the incorrect MIME-type. The
correct extension for XHTML content is .xhtml.

For some reason, it is common to use XHTML doctypes in HTML documents
-- I assume because people think the "X" makes it more modern.
However, this is incorrect behavior. It is better to serve a page
correctly as HTML4 than incorrectly as tag soup.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Restricted type classes

[Ivan Lazar Miljenovic]

When I released the first version of container-classes (which I hacked
on during AusHac), some people said I should split out the various
folding, etc. into duplicates of the current Foldable class, etc.
rather than having large monolithic classes.

I've been working on this (see my more recent email with the subject
along the lines of "fighting the type system"), and I think I've
worked out how to do this:

* Have one version of the class (when this makes sense) for values of kind *

* Have another version that's closer to the original class for kind *
-> *  but allowing restrictions (e.g. allowing Set to be an instance
of Functor).  This is based upon Ganesh Sittampalam's rmonad package
(http://hackage.haskell.org/package/rmonad).

Rather than my original goal of forcing all kind * -> * values to be
instances of the kind * classes, my new approach is to write instances
that automatically make all instances of a * ->  * class to also be an
instance of the kind * class, and to use a newtype wrapper with a
phantom type value to allow lifting/promotion of a kind * value to a
kind * -> * value (e.g. "foo :: (Word8 -> Word8) -> ByteString ->
ByteString; foo f = unpromote . fmap f . Promote" is a valid usage,
rather than using the kind * function of rigidMap).

My goal with this is that if I have duplicated a class Foo to allow
restricted values, then it should be a drop-in replacement for the
original in terms of _usage_ (i.e. the class and method/function names
are the same, but the type signatures are not).  However, I would
appreciate the communities advice on a few matters:

1) How should I name the kind * versions?  For example, the kind *
version of Functor is currently called Mappable with a class method of
rigidMap.  What should I call the kind * version of Foldable and its
corresponding methods?  Is there a valid system I can use for these?

2) How far should I go?  Should I restrict myself to the
"data-oriented" classes such as Functor, Traversable, etc. or should I
try to make restricted versions of Applicative and Monad?  Assuming I
should:

2a) Which namespace to use?  Should Monad go in Data.Restricted.Monad
to keep it in the same namespace as the other classes, or should I
make it closer to base with Control.Restricted.Monad?

2b) Is it OK to promote functions that use a class to being class
methods?  When I was discussing this in #haskell several people
mentioned that defining something like liftA2 for the Set instance of
(restricted) Applicative would make more sense than the default <*>
(since (a -> b) isnt' an instance of Ord).

2c) Should I keep the classes as-is, or should I explicitly put in the
constraints mentioned in the Typeclassopedia (e.g. make Applicative an
explicit superclass of Monad, and define return = pure for
compatability reasons)?  If so, should I bring over Pointed, etc. from
category-extras to round out the set or just stick with classes that
are already in base?

3) Am I wasting my time with this?

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Mark Lentczner]

I am well aware of the differences between HTML and XHTML.

I choose to switch Haddock's output from HTML to XHTML mostly because I have 
found the consistency of rendering cross-browser to be greater and easier to 
achieve with XHTML. I'm not alone in this opinion: Many well respected web 
design authorities have promoted, and publish their own sites, in XHTML.[1] 
Even Microsoft's own developer web site uses it[2]!

Indeed, there is just one kind of validation error in the pages: the ids for 
section headings within a page are pure numbers and need an alphabetic prefix. 
That said, they work just fine in all browsers. I did fix the very bad 
validation problems with other ids (those that link to specific program 
symbols), and several other classes of ids. I will push my fix for the 
remaining ids and it will appear in the next release.[3,4]

As for extensions and doctypes, I believe that we are following best practices 
for the most interoperable result among browsers, and given that we need to 
produce output that will be served in a variety of ways including different web 
servers, and being browsed directly off the file system.[5]

Of course, as soon as it is viable, I would love to move Haddock's output to 
HTML 5. However, given the pace of adoption of such standards, and the range, 
age and mix of browsers that readers of Haddock's output use, it is likely to 
be two years off.

- Mark

[1] See, for example:
http://www.alistapart.com/
http://www.csszengarden.com/
http://www.quirksmode.org/
http://happycog.com/
http://www.w3.org/

all of which are published as XHTML

[2] See: http://msdn.microsoft.com/en-us/default.aspx

[3] Considerable thought was put into both making identifiers validating, while 
maximizing browser interoperability and forward/backward compatibility. See:
http://projects.haskell.org/pipermail/haddock/2010-August/000623.html

[4] Given that the prior Haddock produced pages with much more significant 
validation errors and they didn't seem to cause issues, I don't think we should 
rush a point fix just for this change.

[5] I can't find any evidence for your assertion that Internet Explorer doesn't 
support XHTML, or the way Haddock names the files (and hence URLs). 


Mark Lentczner
http://www.ozonehouse.com/mark/
IRC: mtnviewmark



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Ivan Lazar Miljenovic]

On 3 September 2010 04:57, Arie Peterson  wrote:
> On Thu, 2 Sep 2010 19:30:17 +0200, Daniel Fischer
>  wrote:
>> Why would one consider using Ord for Map an abuse?
>> A kludge, for performance reasons, but an abuse?
>
> Because it forces one to declare Ord instances for types which have no
> natural ordering. It is useful to *not* have such instances, in order to
> catch programming errors.

What precisely do you mean by natural ordering?

> A separate type class for types which can be ordered in some (possibly
> arbitrary) way, for use in Data.Map, would remedy this.

Sure... except that the way Data.Map and Data.Set are implemented is
by a binary tree, and you typically want some kind of ordering for
those.

How is a type class that represents arbitrary ordering any different
from what we already have?  The notation might not be the best if you
consider the ordering to be arbitrary, but what else would you use?
"isArbitrarilyBefore :: (ArbitraryOrdering a) => a -> a -> Bool" ?

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Ivan Lazar Miljenovic]

On 3 September 2010 11:57, John Millikin  wrote:
> Is there any particular reason you're using XHTML instead of HTML?
>
> [snip]
>
> XHTML is supported by most modern browsers (Firefox, Chrome,
> Safari, Opera, etc), but not by any currently released version of
> Internet Explorer.

Sounds like a good enough reason to me... :p

-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[John Millikin]

Is there any particular reason you're using XHTML instead of HTML?
You're using a transitional doctype, invalid IDs, and the .html file
extension -- in short, HTML with an incorrect doctype. The markup
doesn't even validate.

In case you're not aware, HTML and XHTML are separate file formats.
HTML is a dialect of SGML, whereas XHTML is a dialect of XML. They
have different parsers, generators, markup rules, and encoding
handling. XHTML is supported by most modern browsers (Firefox, Chrome,
Safari, Opera, etc), but not by any currently released version of
Internet Explorer.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On to applicative

[michael rice]

Cool, I'll go looking for it. I couldn't find anything on Hoogle.

Thanks,

Michael

--- On Thu, 9/2/10, David Menendez  wrote:

From: David Menendez 
Subject: Re: [Haskell-cafe] On to applicative
To: "michael rice" 
Cc: haskell-cafe@haskell.org
Date: Thursday, September 2, 2010, 9:26 PM

On Thu, Sep 2, 2010 at 9:16 PM, michael rice  wrote:

This may be a dumb question, but here goes.

Types Maybe, Either, List, are types and also instances of Functor (and Monad).


Assuming (->) is also a type, where can I find its type definition?

(->) is a built-in type. You could say its definition is in the Haskell Report.


-- 
Dave Menendez 





  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On to applicative

[David Menendez]

On Thu, Sep 2, 2010 at 9:16 PM, michael rice  wrote:

> This may be a dumb question, but here goes.
>
> Types Maybe, Either, List, are types and also instances of Functor (and
> Monad).
>
> Assuming (->) is also a type, where can I find its type definition?
>

(->) is a built-in type. You could say its definition is in the Haskell
Report.

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] On to applicative

[michael rice]

This may be a dumb question, but here goes.

Types Maybe, Either, List, are types and also instances of Functor (and Monad).

Assuming (->) is also a type, where can I find its type definition?

Michael




  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Daniel Peebles]

Is there a reason this belongs under the Data. prefix? Why not break it out
into Crypto, so future implementers of algorithms can also put their stuff
under there. Everything at some level can be seen as Data, and it would be
nice to start moving out of the overcrowded module hierarchy.


On Fri, Sep 3, 2010 at 1:59 AM, Thomas DuBuisson  wrote:

> On Thu, Sep 2, 2010 at 3:07 PM, Sebastian Fischer
>  wrote:
> >>  data Key = Key {
> >>   encrypt   :: B.ByteString -> B.ByteString,
> >>   decrypt   :: B.ByteString -> B.ByteString,
> >>   keyLength :: BitLength,
> >>   serialize :: B.ByteString}
> >>
> >>  rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g)
>
> One reason against this is simply that all the other constructs
> (block/stream cipher, hashes) are classes, it would be odd for there
> to be a single exception.  A better reason is the data structure has
> no way to implement generateKeyPair.
>
> > Why not use
> >
> >generateKeypair :: MonadRandom m => BitLength -> m (Maybe (p,p))
>
> Because MonadRandom dictates mtl, and is heavier weight than a single
> class.  I was hoping to keep this agnostic (mtl is only required for
> testing or benchmarks in crypto-api).  If MR the more agreeable path
> then I'll do it, though this means I use the unholy "fail" function.
> Even if that's the case (and more people weighing in would help) I
> still want to include Data.Crypto.Random and welcome comments.
>
> Cheers,
> Thomas
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://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] CnC Haskell

[Ryan Newton]

Belated update:

The haskell-cnc distribution (if you grab it from darcs) now has a front-end
that parses the graph description files.
http://hackage.haskell.org/package/haskell-cnc

For any readers who haven't seen this before --  CnC is a parallel
programming model that includes both a library and a small DSL for graph
specification.  The specification file describes the structure of an
application and captures various invariants about data access.

The CnC front-end in the haskell-cnc distro is meant to replace existing CnC
spec "translators" and generate code for all host languages that support the
programming model (currently C++, Java, .NET, Haskell).  Also the graph
specification language is getting a refresh in the process (new
features/syntax).  The parser is done with Happy.  What's there right now
only generates C++ code, but the Haskell codegen is straightforward and
should come along shortly (anyone want to help?).

The purpose of such a front-end is to generate code that:
  (1) saves boilerplate in graph construction (more of a problem in
non-haskell languages)
  (2) correctness: enforces invariants expressed in the specification
  (3) performance: generate code that embodies graph analysis and
optimizations (based also on profiling data)

Cheers,
  -Ryan


On Fri, Jun 25, 2010 at 11:02 AM, David Peixotto  wrote:

> There is a reference for the CnC grammar in the repository for the .NET
> implementation.
>
> http://github.com/dmpots/CnC.NET/blob/master/CnC.NET/CnC.NET/cnc.grammar
>
> The parser specification for fsyacc (the F# YACC implementation) is here:
>
> http://github.com/dmpots/CnC.NET/blob/master/CnC.NET/CnC.NET/Parser.fsy
>
> The textual representation is still in flux a bit, but this grammar should
> be enough of a guide for implementing a parser in Haskell. The grammar is
> left recursive, so using a parser generator like Happy would be a good
> choice.
>
> The textual representation will actually be a bit different depending on
> the underlying language since the types of items stored in a collection is
> part of the description. For example in C, an item collection that stores an
> array of ints would be declared like:
>
> [int* A];
>
> but in Haskell we would want to write something like
>
> [Array Int Int A];
>
> I think dealing with type declarations would in the textual representation
> would be the main difference in implementing the parser in Haskell. Once the
> textual representation has been parsed to an AST it should be possible to
> generate the Haskell code that builds the graph using the haskell-cnc
> package.
>
> -David
>
> On Jun 23, 2010, at 3:56 PM, Vasili I. Galchin wrote:
>
>
>
> On Wed, Jun 23, 2010 at 3:47 PM, Don Stewart  wrote:
>
>> vigalchin:
>> > Hello,
>> >
>> >  I have been reading work done at Rice University:  http://
>> > habanero.rice.edu/cnc. Some work has been done by
>> http://www.cs.rice.edu/
>> > ~dmp4866/ on CnC for .Net. One component that David wrote a CnC
>> translator that
>> > translates CnC textual form to the underlying language, e.g. F#. Is
>> anybody
>> > working on a CnC textual form translator for Haskell so a Haskell user
>> of CnC
>> > Haskell can write in a higher level??
>>
>> Ah, so by a translator from high level CnC form to this:
>>
>>
>> http://hackage.haskell.org/packages/archive/haskell-cnc/latest/doc/hml/Intel-Cnc.html
>>
>>^^ exactly what I mean
>
>
>> ? Do you have a reference for the "CnC textual form"?
>>
>  ^^ if you mean something like a context-free grammatical
> definition of the "CnC textual form" ,,, the answer is I haven't seen such a
> reference.
>
> V.
>
>
>
>> -- Don
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://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] creating a type based on a string

[Pierre-Etienne Meunier]

You may also look at Data.Dynamic / Data.Typeable. It may not work really well, 
depending on how you defined A and B. In GHC, it should work with any type 
produced with the haskell 98 use of the keyword "data", though.

This is the "canonical" solution to cope with the GHC API returning values of 
arbitrary type.

Good luck,
Pierre

El 02/09/2010, a las 16:31, Andrew U. Frank escribió:

> I have a user input (string) and need to select one of two types.
> depending what the input is. is this possible? 
> 
> data A
> data B 
> 
> data X n = X String
> 
> op :: String -> X n
> op "a" = X "a" :: X A
> op "b" = X "b" :: X B
> 
> this does obviously not compile. is there a way to achieve that the type
> X A is produced when the input is "a" and X B when the input is "b"?
> 
> thank you for help!
> andrew
> 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://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] Re: Crypto-API is stabilizing

[Thomas DuBuisson]

On Thu, Sep 2, 2010 at 3:07 PM, Sebastian Fischer
 wrote:
>>  data Key = Key {
>>               encrypt   :: B.ByteString -> B.ByteString,
>>               decrypt   :: B.ByteString -> B.ByteString,
>>               keyLength :: BitLength,
>>               serialize :: B.ByteString}
>>
>>  rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g)

One reason against this is simply that all the other constructs
(block/stream cipher, hashes) are classes, it would be odd for there
to be a single exception.  A better reason is the data structure has
no way to implement generateKeyPair.

> Why not use
>
>    generateKeypair :: MonadRandom m => BitLength -> m (Maybe (p,p))

Because MonadRandom dictates mtl, and is heavier weight than a single
class.  I was hoping to keep this agnostic (mtl is only required for
testing or benchmarks in crypto-api).  If MR the more agreeable path
then I'll do it, though this means I use the unholy "fail" function.
Even if that's the case (and more people weighing in would help) I
still want to include Data.Crypto.Random and welcome comments.

Cheers,
Thomas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Alexander Solla]

On Sep 2, 2010, at 9:10 AM, Stephen Sinclair wrote:


Sorry to go a bit off topic, but I find it funny that I never really
noticed you could perform less-than or greater-than comparisons on
Bool values.  What's the semantic reasoning behind allowing relative
comparisons on booleans?  In what context would you use it?


The Boolean values form a Boolean lattice.  That's reason enough.


It seems
to me a throwback to C's somewhat arbitrary assumption that False=0
and True=1.


That's not arbitrary at all. 0 and 1 are very special numbers, because  
of the roles they play in addition and multiplication.  They "absorb"  
and "identify" things.


http://en.wikipedia.org/wiki/Boolean_algebra_(structure)___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Daniel Fischer]

On Friday 03 September 2010 00:22:14, Jan Christiansen wrote:
> Hi,
>
> On 02.09.2010, at 13:41, Daniel Fischer wrote:
> > takes a little to run and keeps the entire file until the first
> > occurrence
> > of pat in memory.
>
> first of all thanks very much for the detailed instructions.
>
> I have rewritten the example slightly using Strings instead of
> Bytestrings. Replacing all occurrences of 'ä' by "ä" in the
> collected works of Shakespeare ; ) has a maximum memory usage of
> around 65MB with the current implementation of intersperse while it
> has a maximum memory usage of only around 5KB with the less strict
> implementation.

No surprise, there aren't many 'ä's in Shakespeare's works, are there?

>
> I think this is due to the Wadler tuple space leak.

Yup.

> The same would apply to the current implementation of lines.
> I wonder whether an implementation of lines analogous to splitBy
> has any disadvantages.
>

Hardly, but yes. 'break' constructs a pair pretty immediately, so

case break p (x:xs) of
(pre, post) -> pre : case post of
   [] -> []
   (y:ys) -> stuff

can only do harm if (p x) diverges, but then it does.
Currently,
lines (_|_ : rest) = _|_ : _|_
while withe the break, we'd have
lines' (_|_ : rest) = _|_

On the other hand, the current implementation of lines does not seem to 
suffer from Wadler's tuple space leak (according to one test I made), so 
I'd stick with the current implementation for the time being.

> >> That is, we could have
> >>
> >>   intersect [] _|_ = []   and   intersect (_|_:_|_) [] = []
> >>
> >> or
> >>
> >>   intersect [] (_|_:_|_) = []   and   intersect _|_ [] = []
> >>
> >> and the current implementation satisfies neither.
> >
> > Right. So the question is, has the current implementation advantages
> > over
> > either of these? (I don't see any.) If not, which of these two
> > behaviours
> > is preferable?
>
> I'd prefer the first one as it is in line with the left to right
> pattern matching of Haskell.
>

Moi aussi.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On to applicative

[michael rice]

Hi Alexander,

Prelude FmapFunc> let s = show :: ((->) Int) String
Prelude FmapFunc> :t s
s :: Int -> String

The notation was throwing me, but after staring at it for a while it finally 
sunk in that show (above) is partially applied.

Thanks, all.

Michael


--- On Thu, 9/2/10, Alexander Solla  wrote:

From: Alexander Solla 
Subject: Re: [Haskell-cafe] On to applicative
To: 
Cc: "haskell-cafe Cafe" 
Date: Thursday, September 2, 2010, 2:46 PM


On Sep 2, 2010, at 11:30 AM, michael rice wrote:
In each case, what does the notation

show:: ...

and

undefined:: ...

accomplish?
They're type annotations.  show is a function in "many" types:
Prelude> :t showshow :: (Show a) => a -> String
If you want to see the type of a "specific" show function, you need to find a 
way to "determine" its type.  This is a slightly different function, but it's 
equivalent in types and semantics:
Prelude> :t \x -> show x\x -> show x :: (Show a) => a -> String
Now we have a named argument, and we can constraint its type with an annotation:
Prelude> :t \x -> show (x :: Int)\x -> show (x :: Int) :: Int -> String

-Inline Attachment Follows-

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://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] creating a type based on a string

[Ben Millwood]

On Thu, Sep 2, 2010 at 9:31 PM, Andrew U. Frank
 wrote:
> I have a user input (string) and need to select one of two types.
> depending what the input is. is this possible?
>
> data A
> data B
>
> data X n = X String
>
> op :: String -> X n
> op "a" = X "a" :: X A
> op "b" = X "b" :: X B
>
> this does obviously not compile. is there a way to achieve that the type
> X A is produced when the input is "a" and X B when the input is "b"?
>
> thank you for help!
> andrew
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

Here's another way of not quite doing what you want:

op :: String -> Either (X A) (X B)
op "a" = Left (X "a")
op "b" = Right (X "b")

which is roughly how I translate the recent discussion about
type-level validity certification:
http://www.haskell.org/pipermail/haskell-cafe/2010-August/082899.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Jan Christiansen]

Hi,

On 02.09.2010, at 13:41, Daniel Fischer wrote:

takes a little to run and keeps the entire file until the first  
occurrence

of pat in memory.


first of all thanks very much for the detailed instructions.

I have rewritten the example slightly using Strings instead of  
Bytestrings. Replacing all occurrences of 'ä' by "ä" in the  
collected works of Shakespeare ; ) has a maximum memory usage of  
around 65MB with the current implementation of intersperse while it  
has a maximum memory usage of only around 5KB with the less strict  
implementation.


replaceBy :: Eq alpha => alpha -> [alpha] -> [alpha] -> [alpha]
replaceBy x sep = concat . intersperse sep . splitBy (==x)

splitBy :: (alpha -> Bool) -> [alpha] -> [[alpha]]
splitBy _ []  = []
splitBy p xs  =
  case break p xs of
(l,ys) -> l : case ys of
[] -> []
(_:zs) -> splitBy p zs

This function only runs in constant space if I use the strict pattern  
matching on the result of break. If I use the following implementation  
I observe a linear memory usage instead.


splitBy' :: (alpha -> Bool) -> [alpha] -> [[alpha]]
splitBy' _ []  = []
splitBy' p xs  =
  l : case  ys of
  [] -> []
  (_:zs) -> splitBy' p zs
  where
(l,ys) = break p xs

I think this is due to the Wadler tuple space leak. The same would  
apply to the current implementation of lines. I wonder whether an  
implementation of lines analogous to splitBy has any disadvantages.



That is, we could have

  intersect [] _|_ = []   and   intersect (_|_:_|_) [] = []

or

  intersect [] (_|_:_|_) = []   and   intersect _|_ [] = []

and the current implementation satisfies neither.


Right. So the question is, has the current implementation advantages  
over
either of these? (I don't see any.) If not, which of these two  
behaviours

is preferable?


I'd prefer the first one as it is in line with the left to right  
pattern matching of Haskell.



I have mixed feelings about those. Part of me dislikes breaking the
symmetry between (<=), (==) and compare.


I think you should not blame (<=) for the existence of a function that  
yields a superset of the information that (<=) yields ; )


Cheers, Jan___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Sebastian Fischer]

On Sep 3, 2010, at 12:07 AM, Sebastian Fischer wrote:


Why not use

   generateKeypair :: MonadRandom m => BitLength -> m (Maybe (p,p))


Or if the choice to generate keys or not should solely depend on the  
BitLength (and not on the random generator):


generateKeypair :: MonadRandom m => BitLength -> Maybe (m (p,p))



--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[David Waern]

2010/9/2 Daniel Peebles :
> Mmm, delicious! Thanks to all involved! Any idea how long it'll take for
> this to make it to hackage and regenerate all the documentation up there?
> It'd be wonderful to do the same to the GHC documentation too.

I don't actually know yet if it's possible to regenerate the
documentation on hackage. We're looking into the matter.

David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Crypto-API is stabilizing

[Sebastian Fischer]

On Aug 27, 2010, at 11:12 AM, Heinrich Apfelmus wrote:

Is it actually necessary to use a type class here? The situation is  
very similar to


  Luke Palmer. Haskell Antipattern: Existential Typeclass.
  http://lukepalmer.wordpress.com/2010/01/24/

I suggest to use good old data types

  data Key = Key {
   encrypt   :: B.ByteString -> B.ByteString,
   decrypt   :: B.ByteString -> B.ByteString,
   keyLength :: BitLength,
   serialize :: B.ByteString}

  rsa :: RandomGen g => BitLength -> g -> ((Key,Key), g)


In general, I like this approach, but what are

encrypt privateKey

or

decrypt publicKey

supposed to do? A type-class solution also does not *prevent*  
programmers to perform such non-sensical calls, but the data-type  
solution *forces* programmers to provide non-sensical encrypt and  
decrypt functions when creating the public and private keys.



class (Binary p, Serialize p) => AsymCipher p where
  generateKeypair :: RandomGen g => g -> BitLength -> Maybe  
((p,p),g)

  encryptAsym :: p -> B.ByteString -> B.ByteString
  decryptAsym :: p -> B.ByteString -> B.ByteString
  asymKeyLength   :: p -> BitLength


Why not use

generateKeypair :: MonadRandom m => BitLength -> m (Maybe (p,p))

where MonadRandom is from [1].

Sebastian

[1]: http://hackage.haskell.org/package/MonadRandom


--
Underestimating the novelty of the future is a time-honored tradition.
(D.G.)



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Crypto-API is stabilizing

[Thomas DuBuisson]

Marcel noted:
> A central interface to get the output of a PRNG would be nice,
> preferably not constrained to Int like RandomGen.

While BOS said:
> Also, don’t use RandomGen for your asymmetric PRNG. The
> default implementation in System.Random gives absolutely
> disastrous performance, and the typeclass is just
> misdesigned (the split function shouldn’t be present).

Ok, ok.  I never liked RandomGen either - I start this whole thing
because of my PRNG and it doesn't fit RandomGen one bit.

I've build Data.Crypto.Random.RandomGenerator - a new class that fixes
the aspects of RandomGen I don't like.  This is something I was
considering anyway, so it's probably best now and not as an API upset
in a couple months.

There is a blog on this [1], but the main points about the new class are:

1) Generates bytestrings, not Ints
2) Generalized PRNG construction and reseeding
3) 'split' is in a different class.
4) Clean failure via Either (RandomGen forced you to use exceptions)

And minor points
- Providing additional entropy while requesting data is allowed and
has a default instance so most users can ignore this all together.
- a newtype wrapper and instance allows all RandomGenerator instances
to be used as RandomGen when needed.

Who cares about this?  Anyone wanting to get random IVs for block
cipher modes (without getIV_IO) and anyone wanting to generate
asymmetric keys using the AsymCipher class.

What can you do?  Accept this API, help improve the API, or argue that
we should stick with RandomGen (despite short-comings noted on the
blog).  Please pick one and get to it!

Cheers,
Thomas

P.S. I would like to get crypto-api onto hackage by the end of the
first week of September, but understand this is a fairly large change
and will slide that date if there is an unusual strong objection.

[1] 
http://tommd.wordpress.com/2010/09/02/a-better-foundation-for-random-values-in-haskell/

>
> Designing a random interface that provides something as high a level
> as monad random, is easy enough to make instances for (like RandomGen)
> and is feature rich enough to allow reseeding, additional entropy
> input, personalization, and failure is a non-trivial design task.
> Having ran into the dilemma of how to provide a reasonable high-level
> interface for DRBG, I agree with your statement but don't know how a
> solution would look.
>
> FYI, BOS had a similar suggestion (on the blog) of moving away from
> RandomGen but I'm not clear on what I'd move toward.
>
> Cheers,
> Thomas
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] creating a type based on a string

[Daniel Peebles]

What you're asking for is essentially a dependent type (something where a
type depends on a value). Haskell doesn't support these, but can approximate
them with GADTs:


{-# LANGUAGE GADTs, EmptyDataDecls, KindSignatures, Rank2Types #-}

data A
data B

-- The data constructors refine the type index
data X :: * -> * where
  A :: X A
  B :: X B

-- We can't return a different type based on the input string (unless you
represent the string as some complex GADT that itself refines the output
type), so instead we have a pseudo-existential type represented as a
polymorphic function parameter.
-- This basically says, "if you give me a string and a function that can
work on X n for all values of n, I'll give you something of the same type as
the return value of that function"
op :: String -> (forall n. X n -> r) -> r
op "a" f = f A
op "b" f = f B


If you give a more detailed example of what you need, we might be able to
tell you better approaches, though. This rank-2/existential approach is
mostly useful for preserving internal (hidden from the end-user) type-level
constraints on GADT indices.


On Thu, Sep 2, 2010 at 10:31 PM, Andrew U. Frank <
fran...@geoinfo.tuwien.ac.at> wrote:

> I have a user input (string) and need to select one of two types.
> depending what the input is. is this possible?
>
> data A
> data B
>
> data X n = X String
>
> op :: String -> X n
> op "a" = X "a" :: X A
> op "b" = X "b" :: X B
>
> this does obviously not compile. is there a way to achieve that the type
> X A is produced when the input is "a" and X B when the input is "b"?
>
> thank you for help!
> andrew
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://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] creating a type based on a string

[Gregory Crosswhite]

 What is stopping you from using an enumeration type?

data Tag = A  | B
data X = X String Tag

op "a" = X "a" A
op "b" = X "b" B

On 9/2/10 1:31 PM, Andrew U. Frank wrote:

I have a user input (string) and need to select one of two types.
depending what the input is. is this possible?

data A
data B

data X n = X String

op :: String ->  X n
op "a" = X "a" :: X A
op "b" = X "b" :: X B

this does obviously not compile. is there a way to achieve that the type
X A is produced when the input is "a" and X B when the input is "b"?

thank you for help!
andrew


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] creating a type based on a string

[Andrew U. Frank]

I have a user input (string) and need to select one of two types.
depending what the input is. is this possible? 

data A
data B 

data X n = X String

op :: String -> X n
op "a" = X "a" :: X A
op "b" = X "b" :: X B

this does obviously not compile. is there a way to achieve that the type
X A is produced when the input is "a" and X B when the input is "b"?

thank you for help!
andrew


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[David Waern]

2010/9/2 Henk-Jan van Tuyl :
> On Thu, 02 Sep 2010 14:00:56 +0200, David Waern 
> wrote:
>
>> 
>> -- Haddock 2.8.0
>> 
>>
>> A new version of Haddock, the Haskell documentation tool, is out!
>>
>
> It doesn't install on Windows + MinGW:
>
>> cabal install --global haddock
>
> Resolving dependencies...
> Downloading haddock-2.8.0...
> :
> :
> [ 9 of 33] Compiling Haddock.Utils    ( src\Haddock\Utils.hs,
> dist\build\Haddock\Utils.o )
>
> src\Haddock\Utils.hs:435:8: parse error on input `import'
> cabal: Error: some packages failed to install:
> haddock-2.8.0 failed during the building phase. The exception was:
> ExitFailure 1
>
> This concerns a line with a foreign import:
>
> #ifdef mingw32_HOST_OS
> foreign import ccall unsafe "_getpid" getProcessID :: IO Int -- relies on
> Int == Int32 on Windows
> #else
> getProcessID :: IO Int
> getProcessID = fmap fromIntegral System.Posix.Internals.c_getpid
> #endif
>
>
> Adding the line:
>  {-# LANGUAGE ForeignFunctionInterface #-}
> to the top of file  src\Haddock\Utils.hs helped.

Thanks for catching this!

I'll wait a little while in case other issues are reported before I
upload 2.8.1.

David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Henk-Jan van Tuyl]

On Thu, 02 Sep 2010 14:00:56 +0200, David Waern   
wrote:




-- Haddock 2.8.0


A new version of Haddock, the Haskell documentation tool, is out!



It doesn't install on Windows + MinGW:


cabal install --global haddock

Resolving dependencies...
Downloading haddock-2.8.0...
:
:
[ 9 of 33] Compiling Haddock.Utils( src\Haddock\Utils.hs,  
dist\build\Haddock\Utils.o )


src\Haddock\Utils.hs:435:8: parse error on input `import'
cabal: Error: some packages failed to install:
haddock-2.8.0 failed during the building phase. The exception was:
ExitFailure 1

This concerns a line with a foreign import:

#ifdef mingw32_HOST_OS
foreign import ccall unsafe "_getpid" getProcessID :: IO Int -- relies on  
Int == Int32 on Windows

#else
getProcessID :: IO Int
getProcessID = fmap fromIntegral System.Posix.Internals.c_getpid
#endif


Adding the line:
  {-# LANGUAGE ForeignFunctionInterface #-}
to the top of file  src\Haddock\Utils.hs helped.


Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Multicore speedup and spark conversion with ghc HEAD

[Eric Rannaud]

Follows three runs of a stupid program that should see a speedup (I believe).

1. Compiled with ghc-6.12.3. Run on 1 thread, 4.0 s (real).
2. Compiled with ghc-6.12.3. Run on 2 threads, spark converted, 5.4 s
(real), 7.7 s (user).
3. Compiled with ghc-6.13.20100831. Run on 2 threads, but spark *not*
converted 4.1 s (real).

All runs with disabled parallel GC, which negatively impacts -N2 runs
(whether the spark is converted or not).

Two questions:

A. Why is run (2) slower than (1)? GC is a bit more expensive, as one
would expect, but not enough to explain the difference (only explains
0.3 s).

B. ghc HEAD doesn't convert the spark. Why is that?

Thanks.


module Main where

import Control.Parallel

fac :: Integer -> Integer
fac n = aux n 1
  where aux 0 _ = 0
aux 1 m = m
aux n m =
  let p = n * m in
  p `pseq` aux (n - 1) p

main = do
  let x = fac 10
  y = fac 11 in
print (x `par` y `pseq` (x + y))



$ ghc-6.12.3 -O2 -threaded -rtsopts Test.hs --make

$ time ./Test +RTS -N1 -qg -sstderr > /dev/null
./Test +RTS -N1 -qg -sstderr
  20,460,660,928 bytes allocated in the heap
   2,492,368 bytes copied during GC
 462,128 bytes maximum residency (3 sample(s))
  76,576 bytes maximum slop
   4 MB total memory in use (1 MB lost due to fragmentation)

  Generation 0: 35093 collections, 0 parallel,  0.14s,  0.17s elapsed
  Generation 1: 3 collections, 0 parallel,  0.00s,  0.00s elapsed

MUT time (elapsed)   GC time  (elapsed)
  Task  0 (worker) :0.00s(  0.00s)   0.00s(  0.00s)
  Task  1 (worker) :0.00s(  3.84s)   0.00s(  0.00s)
  Task  2 (bound)  :3.87s(  3.84s)   0.14s(  0.17s)

  SPARKS: 1 (0 converted, 1 pruned)

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time3.83s  (  3.84s elapsed)
  GCtime0.14s  (  0.17s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time3.97s  (  4.02s elapsed)

  %GC time   3.6%  (4.3% elapsed)

  Alloc rate5,345,814,403 bytes per MUT second

  Productivity  96.4% of total user, 95.2% of total elapsed

gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].steps[0].sync_large_objects: 0
gen[0].steps[1].sync_large_objects: 0
gen[1].steps[0].sync_large_objects: 0

real0m4.022s
user0m3.970s
sys 0m0.051s


$ time ./Test +RTS -N2 -qg -sstderr > /dev/null
./Test +RTS -N2 -qg -sstderr
  20,600,461,512 bytes allocated in the heap
   3,585,432 bytes copied during GC
 458,480 bytes maximum residency (14 sample(s))
  76,576 bytes maximum slop
   5 MB total memory in use (1 MB lost due to fragmentation)

  Generation 0: 34803 collections, 0 parallel,  0.43s,  0.48s elapsed
  Generation 1:14 collections, 0 parallel,  0.00s,  0.00s elapsed

MUT time (elapsed)   GC time  (elapsed)
  Task  0 (worker) :0.00s(  0.00s)   0.00s(  0.00s)
  Task  1 (worker) :3.72s(  4.91s)   0.24s(  0.25s)
  Task  2 (bound)  :3.91s(  4.91s)   0.19s(  0.23s)
  Task  3 (worker) :0.00s(  4.91s)   0.00s(  0.00s)

  SPARKS: 1 (1 converted, 0 pruned)

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time7.29s  (  4.91s elapsed)
  GCtime0.43s  (  0.48s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time7.72s  (  5.39s elapsed)

  %GC time   5.6%  (8.9% elapsed)

  Alloc rate2,824,733,790 bytes per MUT second

  Productivity  94.4% of total user, 135.2% of total elapsed

gc_alloc_block_sync: 0
whitehole_spin: 0
gen[0].steps[0].sync_large_objects: 0
gen[0].steps[1].sync_large_objects: 0
gen[1].steps[0].sync_large_objects: 0

real0m5.397s
user0m7.724s
sys 0m0.443s



$ ghc-6.13.20100831 -O2 -threaded -rtsopts Test.hs

$ time ./Test +RTS -N2 -qg -sstderr > /dev/null
./Test +RTS -N2 -qg -sstderr
  20,458,286,584 bytes allocated in the heap
   2,705,816 bytes copied during GC
 463,520 bytes maximum residency (3 sample(s))
  73,032 bytes maximum slop
   5 MB total memory in use (1 MB lost due to fragmentation)

  Generation 0: 35088 collections, 0 parallel,  0.19s,  0.22s elapsed
  Generation 1: 3 collections, 0 parallel,  0.00s,  0.00s elapsed

MUT time (elapsed)   GC time  (elapsed)
  Task  0 (worker) :0.00s(  0.00s)   0.00s(  0.00s)
  Task  1 (worker) :0.00s(  3.92s)   0.00s(  0.00s)
  Task  2 (bound)  :3.90s(  3.92s)   0.19s(  0.22s)
  Task  3 (worker) :0.00s(  3.92s)   0.00s(  0.00s)

  SPARKS: 1 (0 converted, 1 pruned)

  INIT  time0.00s  (  0.00s elapsed)
  MUT   time3.84s  (  3.92s elapsed)
  GCtime0.19s  (  0.22s elapsed)
  EXIT  time0.00s  (  0.00s elapsed)
  Total time4.03s  (  4.14s elapsed)

  %GC time   4.7%  (5.2% elapsed)

  Alloc rate5,329,874,595 bytes p

Re: [Haskell-cafe] Unnecessarily strict implementations

[Arie Peterson]

On Thu, 2 Sep 2010 19:30:17 +0200, Daniel Fischer
 wrote:
> Why would one consider using Ord for Map an abuse?
> A kludge, for performance reasons, but an abuse?

Because it forces one to declare Ord instances for types which have no
natural ordering. It is useful to *not* have such instances, in order to
catch programming errors.

A separate type class for types which can be ordered in some (possibly
arbitrary) way, for use in Data.Map, would remedy this.


Regards,

Arie

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Projects that could use student contributions?

[Leon Smith]

There is a lot of room for improvement to my NumberSieves package.
The package consists of algorithms I extracted and polished up from
when I was working on Project Euler problems.   It makes solving a
number of problems into quick five minute affairs.  At some point I
would probably do it myself,  but I don't have a pressing reason to do
it.

http://hackage.haskell.org/package/NumberSieves

Possible Improvements I have in mind:
   1.  Make things faster
   2.  Reduce memory requirements
   3.  Parallelize the sieves
   4.  Incrementalize the Factor and Phi sieves,  so that an explicit
upper bound is no longer required
   5.  Remove limitations so that Factor and Phi can sieve  beyond 2^32

It would be a small and self-contained project,  suitable for anybody
who has an interest in Haskell and mathematics!   If somebody is
interested,  by all means contact me via email,  and I will share the
approach I had in mind.

Best,
Leon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On to applicative

[Alexander Solla]

On Sep 2, 2010, at 11:30 AM, michael rice wrote:


In each case, what does the notation

show:: ...

and

undefined:: ...

accomplish?


They're type annotations.  show is a function in "many" types:

Prelude> :t show
show :: (Show a) => a -> String

If you want to see the type of a "specific" show function, you need to  
find a way to "determine" its type.  This is a slightly different  
function, but it's equivalent in types and semantics:


Prelude> :t \x -> show x
\x -> show x :: (Show a) => a -> String

Now we have a named argument, and we can constraint its type with an  
annotation:


Prelude> :t \x -> show (x :: Int)
\x -> show (x :: Int) :: Int -> String

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Missing documentation in Haskell Platform on Windows

[Bas van Dijk]

On Thu, Sep 2, 2010 at 8:20 PM, Daniel Fischer  wrote:
> On Thursday 02 September 2010 20:05:12, Daniel Fischer wrote:
>>
>> Probably not. I'm on Linux and build my GHCs from source. There's no
>> directory mtl-1.1.0.2 in ~/share/doc/ghc/html/libraries although it's
>> linked to from the package index built with the compiler. (Hadn't
>> noticed before because I use the index in ~/.cabal).
>> Seems to be a slip-up in the makefiles.
>
> Also broken:
>
> utf8-string
> haskeline
> terminfo

Note that on Hackage all links in haddock pages to the current base
library (4.2.0.2) are broken. Possibly because the documentation for
base-4.2.0.2 was not build. The docs for base-4.2.0.1 are build fine:
http://hackage.haskell.org/package/base

Regards,

Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On to applicative

[michael rice]

In each case, what does the notation

show:: ...

and

undefined:: ...

accomplish?

Prelude Control.Applicative> :t show::((->) Int) String
show::((->) Int) String :: Int -> String
Prelude Control.Applicative> :t undefined::((->) Int) String
undefined::((->) Int) String :: Int -> String

Michael


--- On Tue, 8/31/10, Ryan Ingram  wrote:

From: Ryan Ingram 
Subject: Re: [Haskell-cafe] On to applicative
To: "michael rice" 
Cc: "Vo Minh Thu" , haskell-cafe@haskell.org
Date: Tuesday, August 31, 2010, 4:17 PM

FmapFunc is just a test module I created with

instance Functor ((->) r) where ...

  -- ryan

On Tue, Aug 31, 2010 at 12:03 PM, michael rice  wrote:


Hi, Ryan and all,

Bingo! I guess my question was all right after all.

I tried creating an instance earlier but 

*Main> :t (->) Int Char

:1:1: parse error on input `->'


What got loaded with FmapFunc? I Hoogled it and got back nothing.

Michael

--- On Tue, 8/31/10, Ryan Ingram  wrote:


From: Ryan Ingram 

Subject: Re: [Haskell-cafe] On to applicative
To: "michael rice" 
Cc: "Vo Minh Thu" , haskell-cafe@haskell.org

Date: Tuesday, August 31, 2010, 2:36 PM

Prelude FmapFunc> let s = show :: ((->) Int) String
Prelude
 FmapFunc> :t s
s :: Int -> String
Prelude FmapFunc> let v = fmap ("hello " ++) s
Prelude FmapFunc> :t v
v :: Int -> String

Prelude FmapFunc> v 1
"hello 1"

  -- ryan

On Tue, Aug 31, 2010 at 11:28 AM, michael rice  wrote:



I'm not sure if my terminology is correct or even if my question makes sense, 
but I can create "instances" of Maybe, List, IO, and Either.

Prelude Data.Either> let m = Just 7
Prelude Data.Either> :t m


m :: Maybe Integer

Prelude Data.Either> let l = 2:[]
Prelude Data.Either> :t l
l :: [Integer]

Prelude Data.Either> let g = getLine
Prelude Data.Either> :t g
g :: IO String

Prelude Data.Either> let e = Right "abc"


Prelude Data.Either> :t e
e :: Either a [Char]

All these instances are functors, each with its own version of fmap that can be 
applied to it.

How can I similarly create an instance of (->) so I can apply (->)'s version of 
fmap



instance Functor ((->) r) where  
    fmap f g = (\x -> f (g x))

to
 it?

Michael

--- On Tue, 8/31/10, Vo Minh Thu  wrote:



From: Vo Minh Thu 
Subject: Re: [Haskell-cafe] On to applicative
To: "michael rice" 


Cc: haskell-cafe@haskell.org
Date: Tuesday, August 31, 2010, 1:50 PM

2010/8/31 michael rice 


>
> So it's a type constructor, not a type? Could you please provide a simple 
> example of its usage?

Sure, although I'm sure you've come by some already.

-- the identity function
id :: a -> a


-- often, we write it like this:
-- id x = x
-- but here we see the relationship between the ananymous function
syntax and the function
 type:
id = \x -> x

In fact, if you write in prefix form, it is quite familiar:
f :: (->) Int Bool
e = Either String Float

Cheers,
Thu

> Michael
>
> --- On Tue, 8/31/10, Vo Minh Thu  wrote:


>
> From: Vo Minh Thu 
> Subject: Re: [Haskell-cafe] On to applicative
> To: "michael rice" 


> Cc: haskell-cafe@haskell.org
> Date: Tuesday, August 31, 2010, 1:17 PM
>
> 2010/8/31 michael rice 


> >
> > "Learn You a Haskell ..."  says that (->) is a type just like Either. Where 
> > can I find its type definition?
>
> You can't define it *in* Haskell as user code. It is a built-in infix


> type constructor (Either or Maybe are type constructors too, not just
> types). In fact, if you want to implement a simple, typed functional
> language, you'll find it is the only built-in type constructor you


> have to implement (as the implementor of the language).
>
> Also,
>   Show a => a
> is a type too, but you won't find a definition for 'a' or for '=>'.
> All those things are defined by the language.


>
> Cheers,
> Thu
>



  
___

Haskell-Cafe mailing list

Haskell-Cafe@haskell.org

http://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] ANNOUNCE: Haddock version 2.8.0

[Yuras Shumovich]

2010/9/2 Mark Lentczner :
> On Sep 2, 2010, at 5:00 AM, David Waern wrote:
> If you'd like to see the new look in action, I've generated some pages for a 
> few packages here:
>        http://www.ozonehouse.com/mark/snap-xhtml/

Is it possible to switch back from frame version to non frame version?
The "Frames" button disappears in frame mode...
Also style changing works only inside the main frame.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Missing documentation in Haskell Platform on Windows

[Daniel Fischer]

On Thursday 02 September 2010 20:05:12, Daniel Fischer wrote:
>
> Probably not. I'm on Linux and build my GHCs from source. There's no
> directory mtl-1.1.0.2 in ~/share/doc/ghc/html/libraries although it's
> linked to from the package index built with the compiler. (Hadn't
> noticed before because I use the index in ~/.cabal).
> Seems to be a slip-up in the makefiles.

Also broken:

utf8-string
haskeline
terminfo
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Missing documentation in Haskell Platform on Windows

[Daniel Fischer]

On Thursday 02 September 2010 19:34:07, Don Stewart wrote:
> andrewcoppin:
> > Arnaud Bailly wrote:
> >> Hello,
> >> I installed (succesfully) HAskell Platform 2010.2 on windows and have
> >> a small but annoying issue: Some links in HTML documentation lead to
> >> broken links. I did not investigate all the links, but I have seen
> >> that all doc under Control.Monad.XXX is missing. What am I doing
> >> wrong ?
> >
> > Almost every release of GHC that I can remember has had the links for
> > the "mtl" package broken. (The Control.Monad.XXX modules are mostly
> > from mtl. But, for example, Control.Monad.Fix is from base. I bet
> > you'll find it works just fine.)
>
> Well spotted, Andrew!
>
> The way to get things like this fixed is to report a bug to the relevant
> project. Click on the 'bug report' button:
>
> http://trac.haskell.org/haskell-platform/
>
> You installed the Haskell Platform on Windows, so please mention this in
> the bug ticket. The problem will likely be in the Windows installer
> script, and what docs were bundled with that specific installer.

Probably not. I'm on Linux and build my GHCs from source. There's no 
directory mtl-1.1.0.2 in ~/share/doc/ghc/html/libraries although it's 
linked to from the package index built with the compiler. (Hadn't noticed 
before because I use the index in ~/.cabal).
Seems to be a slip-up in the makefiles.

>
> Be as detailed in the report as you can, to make sure we can reproduce
> what trouble you have.
>
> In the meantime, you can always read the 'mtl' documentation on its
> package page:
>
> http://hackage.haskell.org/package/mtl
>
> -- Don

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Albert Y. C. Lai]

On 10-09-02 12:10 PM, Stephen Sinclair wrote:

Sorry to go a bit off topic, but I find it funny that I never really
noticed you could perform less-than or greater-than comparisons on
Bool values.  What's the semantic reasoning behind allowing relative
comparisons on booleans?  In what context would you use it?  It seems
to me a throwback to C's somewhat arbitrary assumption that False=0
and True=1.


A boolean algebra is also a lattice. The lattice order reflects 
implication. If the boolean algebra is furthermore 2-valued, the order 
is total too. The only possible dispute among people is over False<=True 
vs True<=False, i.e., should "<=" be "implies" or "implied by". But it 
is always correct to pick one and stick with it. This is useful wherever 
implication is useful. Suppose you wrote two functions and you now want 
to prove or quickcheck-test that they are extensionally equal, except 
you only care about arguments satisfying an assumption. You are checking


  (p x) implies (f x == g x)

If you follow the Haskell choice, it is directly

  (p x) <= (f x == g x)

Implication is pervasively useful, but people pervasively 
underappreciate it; they avoid to think in terms of implication when the 
essence is implication. For example, some people say: you can use "not 
(p x) || f x == g x". To that, I reply firstly: you can use solely NAND 
too, why don't you try that. And I reply secondly: implication is more 
direct, one single operator for the pervasive assume-guarantee paradigm, 
minimum boilerplate. There is no need to bring in negation.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Missing documentation in Haskell Platform on Windows

[Don Stewart]

andrewcoppin:
> Arnaud Bailly wrote:
>> Hello,
>> I installed (succesfully) HAskell Platform 2010.2 on windows and have  
>> a small but annoying issue: Some links in HTML documentation lead to  
>> broken links. I did not investigate all the links, but I have seen  
>> that all doc under Control.Monad.XXX is missing. What am I doing wrong 
>> ?
>
> Almost every release of GHC that I can remember has had the links for  
> the "mtl" package broken. (The Control.Monad.XXX modules are mostly from  
> mtl. But, for example, Control.Monad.Fix is from base. I bet you'll find  
> it works just fine.)

Well spotted, Andrew!

The way to get things like this fixed is to report a bug to the relevant
project. Click on the 'bug report' button:

http://trac.haskell.org/haskell-platform/

You installed the Haskell Platform on Windows, so please mention this in
the bug ticket. The problem will likely be in the Windows installer
script, and what docs were bundled with that specific installer.

Be as detailed in the report as you can, to make sure we can reproduce
what trouble you have.

In the meantime, you can always read the 'mtl' documentation on its
package page:

http://hackage.haskell.org/package/mtl

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] First questions!

[Andrew Coppin]

Eoin C. Bairéad wrote:

Example 2

Prelude> let fac n = if n == 0 then 1 else n * fac (n-1)

How does it know to stop ?
  


Becuase you said "if n == 0 then 1". In other words, if n is zero then 
return one and stop. Only if n does *not* equal zero does it recursively 
so "n * fac (n-1)".



and why does fac 2.5 hang?
  


Because the n == 0 condition never holds. fac 3 yields n=3, n=2, n=1, 
n=0, stop. fac 2.5 yeilds n=2.5, n=1.5, n=0.5, n=-0.5, n=-1.5... forever.


Note carefully that fac (-6) also loops forever.

Now, if you were to change the condition to "n < 1" rather than "n == 0" 
then it would halt in all circumstances. You could also use a type 
signature to state that fac accepts only whole numbers, since this 
function only gives a meaningful answer in that case.


(If you wanted a mathematically correct function, you need the Gamma 
function. But that's scary stuff, and this is a Haskell lesson not an 
advanced math lesson.)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Daniel Fischer]

On Thursday 02 September 2010 18:25:11, Henning Thielemann wrote:
> The Ord instance for Bool might be justified for using Bools as keys of
> Data.Map, however you can also consider using Ord for Map as abuse.

Why would one consider using Ord for Map an abuse?
A kludge, for performance reasons, but an abuse?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Missing documentation in Haskell Platform on Windows

[Andrew Coppin]

Arnaud Bailly wrote:

Hello,
I installed (succesfully) HAskell Platform 2010.2 on windows and have 
a small but annoying issue: Some links in HTML documentation lead to 
broken links. I did not investigate all the links, but I have seen 
that all doc under Control.Monad.XXX is missing. What am I doing wrong ?


Almost every release of GHC that I can remember has had the links for 
the "mtl" package broken. (The Control.Monad.XXX modules are mostly from 
mtl. But, for example, Control.Monad.Fix is from base. I bet you'll find 
it works just fine.)


Today I went and did a thorough check. HP 2009.2.x.x (I forget exactly 
which one) has links that point to


 C:\Program Files\Haskell Platform\2009.2.x.x\doc\ghc-mtl-x.x.x

which does not exist. There is, however, a folder named

 C:\Program Files\Haskell Platform\2009.2.x.x\doc\mtl-x.x.x

which exists just fine, and appears to contain the correct stuff.

In HP 2010.1.0.0 and 2010.2.0.0, the links point to the latter address, 
but no such folder actually exists. The mtl documentation appears to 
simply be missing entirely, rather than being in a different place than 
where the links point to. Various older releases of GHC (before HP 
existed) have had one problem or the other, always with mtl, never with 
any other package.


I have absolutely no idea why mtl is always broken, but all the other 
packages seem to work just fine. The fact that it happens so routinely 
suggests a problem with the build process rather than a one-off mistake.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Neil Brown]

On 02/09/10 17:10, Stephen Sinclair wrote:

On Thu, Sep 2, 2010 at 3:25 AM, Jan Christiansen
  wrote:
   

I prefer

  False<= _|_ = True
 

Sorry to go a bit off topic, but I find it funny that I never really
noticed you could perform less-than or greater-than comparisons on
Bool values.  What's the semantic reasoning behind allowing relative
comparisons on booleans?  In what context would you use it?  It seems
to me a throwback to C's somewhat arbitrary assumption that False=0
and True=1.
   
Comparison on Bool itself is probably not particularly useful.  But it 
is often useful if the Bool is part of a larger data structure.  For 
example, I might want to have Set (String, Bool); without the Ord 
instance on Bool I couldn't do this.  Similarly, you couldn't derive Ord 
on your data types that have Bool in them without the Ord Bool instance.


Thanks,

Neil.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Henning Thielemann]

On Thu, 2 Sep 2010, Stephen Sinclair wrote:


On Thu, Sep 2, 2010 at 3:25 AM, Jan Christiansen
 wrote:

I prefer

 False <= _|_ = True


Sorry to go a bit off topic, but I find it funny that I never really
noticed you could perform less-than or greater-than comparisons on
Bool values.  What's the semantic reasoning behind allowing relative
comparisons on booleans?  In what context would you use it?


You might use or abuse (<=) for implication, however the arrow points to 
the wrong direction.



 It seems to me a throwback to C's somewhat arbitrary assumption that False=0
and True=1.


My feeling is similar.

The Ord instance for Bool might be justified for using Bools as keys of 
Data.Map, however you can also consider using Ord for Map as abuse.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Stephen Sinclair]

On Thu, Sep 2, 2010 at 3:25 AM, Jan Christiansen
 wrote:
> I prefer
>
>  False <= _|_ = True

Sorry to go a bit off topic, but I find it funny that I never really
noticed you could perform less-than or greater-than comparisons on
Bool values.  What's the semantic reasoning behind allowing relative
comparisons on booleans?  In what context would you use it?  It seems
to me a throwback to C's somewhat arbitrary assumption that False=0
and True=1.

Steve
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: HDBC-postgresql and safe/unsafe FFI calls

[John Goerzen]

Hi David,

I've had varying arguments from people that want me to mark things safe 
or unsafe for various performance reasons.  I'm happy to apply your 
change if you like.  Can you send me a diff (and attach your explanation 
here to it, which I'll use as a commit message for future reference)?


Thanks,

-- John

On 09/01/2010 09:40 PM, David Powell wrote:

Greetings,

I'm having an issue with the HDBC-postgresql package that requires me to
manually patch it before installation for most of my use cases.

All the FFI calls in this package are marked "unsafe".  Unfortunately,
this means that whenever I issue a slow sql query, all other processing
stops.  In most places that I want to use this module, I've had to
manually patch it to at least mark the PQexec and PQexecParams calls as
"safe".

Is there any reason these calls should not be marked as "safe"?  I
understand that there a little extra runtime overhead with this, but I'd
have thought that negligible given all the other processing that goes on
with these particular calls under the hood.

Cheers,

--
David Powell


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On to applicative

[David Menendez]

On Thu, Sep 2, 2010 at 10:45 AM, michael rice  wrote:

>
> Can you think of a situation for
>
>  \x -> f x
> or
>  \x y z -> x + ord y - head z
>
> that would require x (y z) to have their type(s) declared (ala Pascal), or
> is it always
> inferred by what appears to the right of "->"?
>

I think Haskell 98 can always infer the type of an anonymous function. There
are some extensions involving more advanced types that can't be inferred,
but you don't need to worry about them yet.


> I guess what I'm asking is can an anonymous function be given a type
> signature?


Sure. Just write (\x -> x + 1) :: Int -> Int. (The parentheses are
important. Without them, the type signature is given to the function body.)

I don't think I've ever needed to give a type for an anonymous function,
though. Generally, the context where the function is being used is
sufficient.

-- 
Dave Menendez 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] On to applicative

[michael rice]

Sorry, my last message got garbled. Hope this is better.

Prelude Control.Monad Control.Monad.Instances Control.Applicative> let f = \x 
-> x:[]
Prelude Control.Monad Control.Monad.Instances Control.Applicative> :t f
f :: a -> [a]
Prelude Control.Monad Control.Monad.Instances Control.Applicative> let g = \x 
-> Just x
Prelude Control.Monad Control.Monad.Instances Control.Applicative> :t g
g :: a -> Maybe a

=

Prelude Control.Monad Control.Monad.Instances Control.Applicative> let z = \x 
-> x+1
Prelude Control.Monad Control.Monad.Instances Control.Applicative> :t z
z :: Integer -> Integer

Prelude Control.Monad Control.Monad.Instances Control.Applicative.Data.Char> 
let y = \x -> ord x
Prelude Control.Monad Control.Monad.Instances Control.Applicative Data.Char> :t 
y
y :: Char -> Int


Can you think of a situation for

 \x -> f x
or
 \x y z -> x + ord y - head z

that would require x (y z) to have their type(s) declared (ala Pascal), or is 
it always
inferred by what appears to the right of "->"?

I guess what I'm asking is can an anonymous function be given a type signature?

Michael

--- On Wed, 9/1/10, Tillmann Rendel  wrote:

From: Tillmann Rendel 
Subject: Re: [Haskell-cafe] On to applicative
To: "michael rice" 
Cc: haskell-cafe@haskell.org
Date: Wednesday, September 1, 2010, 5:28 PM

michael rice wrote:
> Prelude Data.Either> let m = Just 7
> Prelude Data.Either> :t m
> m :: Maybe Integer

So to create a value of type (Maybe ...), you can use Just.

> Prelude Data.Either> let l = 2:[]
> Prelude Data.Either> :t l
> l :: [Integer]

So to create a value of type [...], you can use (:) and [].

> Prelude Data.Either> let g = getLine
> Prelude Data.Either> :t g
> g :: IO String

So to create a value of type (IO ...), you can use getLine.

> Prelude Data.Either> let e = Right "abc"
> Prelude Data.Either> :t e
> e :: Either a [Char]

So to create a value of type (Either ... ...), you can use Right.

> How can I similarly create an instance of (->) [...] ?

An "instance of (->)" is usually called a function. And functions are created 
by lambda abstraction:

  Prelude> let f = \x -> x
  Prelude> :t f
  f :: t -> t

So to create a value of type (... -> ...), you can use \.


Just like Either, -> is a binary type constructor. Just like (Either a b) is a 
type, (a -> b) is a type. And very much like you can create (Either a b) values 
with Left and Right, you can create (a -> b) values with \.

  Tillmann

PS. After studying how to construct values, it may be instructive to study how 
to take them apart. For example, Bool values can be taken apart by if-then-else 
expressions. What about Either, IO and -> values?



  ___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[Mark Lentczner]

On Sep 2, 2010, at 5:00 AM, David Waern wrote:
> -- Haddock 2.8.0
> A new version of Haddock, the Haskell documentation tool, is out!
> 
> The biggest news this time is that we have a shiny new XHTML backend, created
> by Mark Lentczner, ... Included is a new default CSS theme created by Thomas 
> Schilling, Mark and Johan Tibell, as well as the classic theme converted to 
> work with the new backend.

If you'd like to see the new look in action, I've generated some pages for a 
few packages here:
http://www.ozonehouse.com/mark/snap-xhtml/

- Mark

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] random-fu confusion

[Alex Rozenshteyn]

I seem to be having confusion at the runRVar level of random-fu.

I can't figure out how to use the Data.Random.Source.PureMT module to get a
meaningful random source (I can't get my code to type-check).

I wrote a [trivial] flipCoin function
> flipCoin = uniform False True
and am trying to fill in the final place of runRVar
> :t runRVar (replicateM 20 flipCoin)
runRVar (replicateM 20 flipCoin)
  :: (RandomSource m s) => s -> m [Bool]


-- 
  Alex R
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] First questions!

[Miguel Mitrofanov]

02.09.2010 16:49, Eoin C. Bairéad пишет:

Example 2

Prelude>  let fac n = if n == 0 then 1 else n * fac (n-1)

How does it know to stop ?


To stop what? It's not "doing" anything, it's just an equation. So "fac" is the "least" function which satisfies this equation - meaning that it's value would be (_|_) (which is a special value called 
"bottom") whenever possible. When you ask for "fac 3", for example, it's not possible for it to be (_|_), because it has to be 3*fac(2), according to this equation; and "fac 2" isn't bottom either, 
because it has to be 2*fac(1); and fac(1) has to be 1*fac(0), which is also not bottom, because the equation states explicitly that fac 0 = 1.



and why does fac 2.5 hang?


Because there isn't anything to prevent "fac 2.5" from being equal to (_|_); and when you ask for value that happens to be (_|_), your program can either crash or hang forever, it's the only special 
thing about bottom value.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Henning Thielemann]

Jan Christiansen schrieb:
> Hi,
> 
> On 02.09.2010, at 01:35, Daniel Fischer wrote:
> 
>> It's not that it's not as non-strict as possible per se. (Sorry, had
>> to :)
>> It's that intersperse's current definition (in GHC at least) can cause a
>> space leak. In this case, making the function less strict can cure it, in
>> other cases, more strictness might be the solution.
> 
> I would be very happy if you would share this example with me. I am
> looking for an example where the current implementation of intersperse
> or inits causes a space leak for quite a while now.

I'm also annoyed by several space leaks. These are implementation
artifacts, but they seem to be hard to avoid by the existing
implementations. You cannot reason about space leaks, right? That's a pity.

> I think this is a matter of elegance rather than a matter of efficiency.
> In the same way as I prefer
> 
>   False && _|_ = False
> 
> over
> 
>   False && _|_ = _|_

I think this one is justified by the law:
  filter p (filter q xs) = filter (\x -> q x && p x) xs
 which only hold with the first definition of (&&). E.g.
  q x = x/=0
  p x = div n x

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] First questions!

[Johan Tibell]

Hi!

2010/9/2 Eoin C. Bairéad 

> Example 2
>
> Prelude> let fac n = if n == 0 then 1 else n * fac (n-1)
>
> How does it know to stop ?
>

When fac is called with n=0 it returns 1 and stops the recursion.


> and why does fac 2.5 hang?
>

fac, as you defined it, is only defined for integers. As you repeatedly
subtract 1 from n you will never get to 0 (you will get to 0.5 and then
-0.5) and thus the recursion will never terminate.\
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] First questions!

[Daniel Fischer]

On Thursday 02 September 2010 14:49:12, Eoin C. Bairéad wrote:
> Example 2
>
> Prelude> let fac n = if n == 0 then 1 else n * fac (n-1)
>
> How does it know to stop ?

It tests for n == 0. If that returns True, the recursion stops.

> and why does fac 2.5 hang?
>

Because 2.5 is not an integer, so fac gets called with
2.5
1.5
0.5
-0.5
-1.5
-2.5
...
but never with 0, so you get infinite recursion.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: stringsearch 0.3.1, fast searching, splitting and replacing of ByteStrings

[Daniel Fischer]

Changes vs. 0.3.0:
- fixed a space leak in the splitting of lazy ByteStrings

Changes of the 0.3 series vs. 0.2.*:
- improved performance of the searching functions
- new functionality:
  - breaking of ByteStrings at the first occurrence of a substring
  - splitting a ByteString at each occurrence of a substring
  - replacing all occurrences of a substring with another string

Where bytestring provides the same functionality 
(Data.ByteString.breakSubstring, Data.ByteString.findSubstrings), the 
implementations in stringsearch are typically much faster.
By default, stringsearch uses an enhanced Boyer-Moore algorithm to locate a 
pattern, but it also provides other algorithms which may be better in 
special cases (Knuth-Morris-Pratt; DFA).



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] First questions!

[Eoin C . Bairéad]

Example 2

Prelude> let fac n = if n == 0 then 1 else n * fac (n-1)

How does it know to stop ?
and why does fac 2.5 hang?


thanks


Eoin

-- 
--
Eoin C. Bairéad
Dublin, Ireland
Áth Cliath, Éire
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: Haddock version 2.8.0

[David Waern]

-- Haddock 2.8.0


A new version of Haddock, the Haskell documentation tool, is out!

The biggest news this time is that we have a shiny new XHTML backend, created
by Mark Lentczner, which outputs semantically correct XHTML, making it much
easier to create new themes for Haddock.

Mark has made an extraordinary effort by going through and rewriting the old
table based HTML backend, fixing non-standards-compliant quirks, and adding a
bunch of new useful features on top of that. See the changelog for more
details.

Included is a new default CSS theme created by Thomas Schilling, Mark and Johan
Tibell, as well as the classic theme converted to work with the new backend.

Another great new feature is markup support for examples, contributed by Simon
Hengel. The idea is to be able to write examples that function both as
documentation and unit tests.

Last but not least, we now also have a LaTeX backend. It was written by Simon
Marlow and it was used to generate the libraries section of the Haskell 2010
report.

This version is compatible with .haddock files produced by Haddock 2.6.1 and
above, provided that the version of GHC used to build Haddock stays the same.


-- Changes in version 2.8.0


  * HTML backend completely rewritten to generate semantically rich XHTML
using the xhtml package.

  * New default CSS based on the color scheme chosen for the new Haskell
wiki, with a pull-out tab for the synopsis.

  * Theme engine based on CSS files. Themes can be switched from the
header menu. (New flags --built-in-themes and --theme. The latter
is an alias for --css which now has extended semantics).

  * Markup support for executable examples/unit-tests. To be used with an
upcoming version of the DocTest program.

  * Addition of a LaTeX backend.

  * Frames-mode can be enabled from the header menu.

  * Path to source entities can be specified per package, so that source
links work for cross-package documentation.

  * Support for a second form of enumerated lists (1. 2. etc).

  * Additions and changes to the Haddock API.

  * New flag --no-tmp-comp-dir to tell Haddock to read/write
compilation files (.o, .hi, etc) to/from GHC's output directory instead of
to/from a temporary directory.

  * Various bug fixes.


-- Links


Homepage:
 http://www.haskell.org/haddock

Hackage page:
 http://hackage.haskell.org/package/haddock-2.8.0

Bugtracker and wiki:
 http://trac.haskell.org/haddock

Mailing list:
 hadd...@projects.haskell.org

Code repository:
 http://code.haskell.org/haddock


-- Contributors


The following people contributed patches to this release:

 Simon Hengel
 Mark Lentczner
 Ian Lynagh
 Simon Marlow
 Simon Peyton-Jones
 Thomas Schilling
 David Waern


-- Get Involved


We would be very happy to get more contributors. To get involved, start by
grabbing the code:

 http://code.haskell.org/haddock

Then take a look at the bug and feature tracker for things to work on:

 http://trac.haskell.org/haddock
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Daniel Fischer]

On Thursday 02 September 2010 09:25:59, Jan Christiansen wrote:
> Hi,
>
> On 02.09.2010, at 01:35, Daniel Fischer wrote:
> > It's not that it's not as non-strict as possible per se. (Sorry, had
> > to :)
> > It's that intersperse's current definition (in GHC at least) can
> > cause a
> > space leak. In this case, making the function less strict can cure
> > it, in
> > other cases, more strictness might be the solution.
>
> I would be very happy if you would share this example with me. I am
> looking for an example where the current implementation of intersperse
> or inits causes a space leak for quite a while now.
>

I don't see how the current implementation of inits or tails could cause a 
space leak that the lazier versions wouldn't, so you'd have to wait longer 
for such an example.

For intersperse,

$ cabal update && cabal install stringsearch

You need the new version 0.3.1, Data.ByteString.Lazy.Search[.DFA].splitXXX
had their own space leak in 0.3.0 [caused by too much laziness].

Then

===
{-# LANGUAGE BangPatterns #-}
module Main (main) where

import System.Environment (getArgs)
import qualified Data.ByteString as S
import qualified Data.ByteString.Lazy as L
import qualified Data.ByteString.Char8 as C

import Data.ByteString.Lazy.Search (split)

main :: IO ()
main = do
(file : pat : sub : _ ) <- getArgs
let !spat = C.pack pat
!ssub = L.fromChunks [C.pack sub]
work = ical ssub . split spat
L.readFile file >>= L.putStrLn . L.take 100 . work

ical :: L.ByteString -> [L.ByteString] -> L.ByteString
ical new = L.concat . intersperse new

intersperse :: a -> [a] -> [a]
intersperse sep [] = []
intersperse sep (x:xs) = x : go xs
where
go [] = []
go (y:ys) = sep : y : go ys


has no space leak, if you replace the local intersperse with 
Data.List.intersperse (equivalent, ical = L.intercalate), you have a space 
leak.

To expose the leak, take a sufficiently large file (say 10MB or larger) and 
replace a pattern that does not occur in the file or occurs late in the 
file,

$ ./noleak file pat sub

runs fast in small memory, 

$ ./leak file pat sub

takes a little to run and keeps the entire file until the first occurrence 
of pat in memory.

Note that the above implementation of intersperse has different semantics 
from Data.List.intersperse,
Data.List.intersperse ',' ('a':_|_) = _|_
intersperse ',' ('a':_|_) = 'a':_|_
Data.List.intersperse ',' ('a':'b':_|_) = 'a' : ',' : _|_
intersperse ',' ('a':'b':_|_) = 'a' : ',' : 'b' : _|_
etc.

> > On the other hand, we currently have
> >
> > intersect [] _|_ = []
> >
> > and one of intersect _|_ [] and intersect [] _|_ must give _|_.
> > Which one is a matter of choice.
>
> I am sorry for not being precise. You are right. But right now we have
> intersect xs [] = _|_ for every list xs terminated by _|_. But I
> suffices to evaluate xs to head normal to decide that the result
> should be []. That is, we could have
>
>intersect [] _|_ = []   and   intersect (_|_:_|_) [] = []
>
> or
>
>intersect [] (_|_:_|_) = []   and   intersect _|_ [] = []
>
> and the current implementation satisfies neither.
>

Right. So the question is, has the current implementation advantages over 
either of these? (I don't see any.) If not, which of these two behaviours 
is preferable?

> > And before that, the rule intersect [] _ = [] if the current
> > behaviour of
> > intersect [] should be retained.
>
> That's a deal.
>
> >> The implication (<=) :: Bool -> Bool -> Bool is too strict as well.
> >> We
> >> have False <= _|_ = _|_ as well as _|_ <= True = _|_ while one of
> >> these cases could yield True.
> >
> > I'm not convinced either should (nor that they shouldn't).
>
> I think this is a matter of elegance rather than a matter of
> efficiency. In the same way as I prefer
>
>False && _|_ = False
>
> over
>
>False && _|_ = _|_
>
> I prefer
>
>False <= _|_ = True
>
> over
>
>False <= _|_ = _|_
>

I have mixed feelings about those. Part of me dislikes breaking the 
symmetry between (<=), (==) and compare.

> > The last slide lists among the problems
> > "proposes undesirably inefficient functions (reverse)".
> > I wouldn't equate 'not minimally strict' with 'too strict'.
> > Minimal strictness also can have negative effects, one must look at
> > each
> > case individually.
>
> I second this but in my opinion the minimally strict implementation
> should be the default if there is no reason against it.

Agreed - except I have to object to your use of the definite article, some 
functions have several minimally strict implementations.
(Ambiguity of minimal strictness *can* be a reason for a stricter choice, 
though probably rarely.)

>
> Cheers, Jan

Cheers,
Daniel

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Linking issues with HaskellDB/HDBC/ODBC

[Neil Davies]

Hi

Anyone got any hints as to why this linkage error is occurring (GHC 6.12.3, Mac 
OSX 10.6 (and 10.5 has same issue)):

cabal install haskelldb-hdbc-odbc --enable-documentation --root-cmd=sudo 
--global
Resolving dependencies...
Configuring haskelldb-hdbc-odbc-0.13...
Preprocessing library haskelldb-hdbc-odbc-0.13...
Preprocessing executables for haskelldb-hdbc-odbc-0.13...
Building haskelldb-hdbc-odbc-0.13...
[1 of 1] Compiling Database.HaskellDB.HDBC.ODBC ( 
Database/HaskellDB/HDBC/ODBC.hs, dist/build/Database/HaskellDB/HDBC/ODBC.o )
Registering haskelldb-hdbc-odbc-0.13...
[1 of 2] Compiling Database.HaskellDB.HDBC.ODBC ( 
Database/HaskellDB/HDBC/ODBC.hs, 
dist/build/DBDirect-hdbc-odbc/DBDirect-hdbc-odbc-tmp/Database/HaskellDB/HDBC/ODBC.o
 )
[2 of 2] Compiling Main ( DBDirect.hs, 
dist/build/DBDirect-hdbc-odbc/DBDirect-hdbc-odbc-tmp/Main.o )
Linking dist/build/DBDirect-hdbc-odbc/DBDirect-hdbc-odbc ...
Undefined symbols:
  "_CFBundleCopyResourceURL", referenced from:
  _SQLDriverConnect_Internal in libodbc.a(connect.o)
  "___CFConstantStringClassReference", referenced from:
  cfstring=org.iodbc.core in libodbc.a(connect.o)
  cfstring=iODBCadm.bundle in libodbc.a(connect.o)
  "_CFURLCopyFileSystemPath", referenced from:
  _SQLDriverConnect_Internal in libodbc.a(connect.o)
  "_CFRelease", referenced from:
  _SQLDriverConnect_Internal in libodbc.a(connect.o)
  _SQLDriverConnect_Internal in libodbc.a(connect.o)
  "_CFStringGetCString", referenced from:
  _SQLDriverConnect_Internal in libodbc.a(connect.o)
  "_CFBundleGetBundleWithIdentifier", referenced from:
  _SQLDriverConnect_Internal in libodbc.a(connect.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
cabal: Error: some packages failed to install:
haskelldb-hdbc-odbc-0.13 failed during the building phase. The exception was:
ExitFailure 1

Hints gratefully received!...

Cheers

Neil___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] HDBC-postgresql and safe/unsafe FFI calls

[Leon Smith]

On Thu, Sep 2, 2010 at 1:00 AM, David Powell  wrote:
> Thanks Jason, I think I had read that - I quite enjoy Edward's posts.
> Re-reading, seems to confirm what I thought, most (all?) of the FFI calls in
> HDBC-postgresql should be changed to "safe".

Wouldn't that require thread safety on the part of libpq?   Versions
8.4 and earlier requires the library to be configured with the option
--enable-thread-safety,  although version 9.0 has thread safety turned
on by default.

http://www.postgresql.org/docs/8.4/static/libpq-threading.html
http://www.postgresql.org/docs/9.0/static/libpq-threading.html

At least the Ubuntu PostgreSQL 8.4 packages are compiled with thread
safety,  but I can't speak for other distributions.

Best,
Leon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Unnecessarily strict implementations

[Jan Christiansen]

Hi,

On 02.09.2010, at 01:35, Daniel Fischer wrote:

It's not that it's not as non-strict as possible per se. (Sorry, had  
to :)
It's that intersperse's current definition (in GHC at least) can  
cause a
space leak. In this case, making the function less strict can cure  
it, in

other cases, more strictness might be the solution.


I would be very happy if you would share this example with me. I am  
looking for an example where the current implementation of intersperse  
or inits causes a space leak for quite a while now.



On the other hand, we currently have

intersect [] _|_ = []

and one of intersect _|_ [] and intersect [] _|_ must give _|_.
Which one is a matter of choice.


I am sorry for not being precise. You are right. But right now we have  
intersect xs [] = _|_ for every list xs terminated by _|_. But I  
suffices to evaluate xs to head normal to decide that the result  
should be []. That is, we could have


  intersect [] _|_ = []   and   intersect (_|_:_|_) [] = []

or

  intersect [] (_|_:_|_) = []   and   intersect _|_ [] = []

and the current implementation satisfies neither.

And before that, the rule intersect [] _ = [] if the current  
behaviour of

intersect [] should be retained.


That's a deal.

The implication (<=) :: Bool -> Bool -> Bool is too strict as well.  
We

have False <= _|_ = _|_ as well as _|_ <= True = _|_ while one of
these cases could yield True.


I'm not convinced either should (nor that they shouldn't).


I think this is a matter of elegance rather than a matter of  
efficiency. In the same way as I prefer


  False && _|_ = False

over

  False && _|_ = _|_

I prefer

  False <= _|_ = True

over

  False <= _|_ = _|_


The last slide lists among the problems
"proposes undesirably inefficient functions (reverse)".
I wouldn't equate 'not minimally strict' with 'too strict'.
Minimal strictness also can have negative effects, one must look at  
each

case individually.



I second this but in my opinion the minimally strict implementation  
should be the default if there is no reason against it.


Cheers, Jan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe