Re: [Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell)

[José Pedro Magalhães]

Hi Jinjing,

I remember having written a report on Haskore some years ago, together with
a classmate. I think that the example of transformations in twelve-tone
technique (see [1]) is one that looks very nice in Haskore due to its
simplicity. It's also simple to present to people who do not know music
theory, but are (minimally) mathematically inclined.


Cheers,
Pedro

[1] http://en.wikipedia.org/wiki/Twelve-tone_technique#Tone_row

On Tue, Aug 5, 2008 at 10:59, jinjing <[EMAIL PROTECTED]> wrote:

> Hi there,
>
> Here's the project link:
>
> http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown
>
> I found Haskore pretty fun :) so I'm documenting it while learning it.
> Please don't hesitate to give suggestions / corrections.
>
> Questions:
>
> * How much music theory should be there ? ( I'm gonna learn those anyway )
> * What kind of examples would be cool ?
>
> regards,
>
> jinjing
> ___
> 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] more adjunction questions -- where to send them?

[Jason Dusek]

  I've gotten most of my category theory help through the
  Haskell community one way or another, but I hesitate to ask
  more questions on this list if there is a better forum.
  Googling turned up an old, closed list.

  Is there somewhere else I should be asking my questions -- for
  example, I am now working on the adjunction of "right product"
  and "exponentiation" -- or is the Haskell Cafe list a good
  place?

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

Re: [Haskell-cafe] Re: poll: how can we help you contribute to darcs?

[Ketil Malde]

Ben Franksen <[EMAIL PROTECTED]> writes:

>> Can I convert my working repos to darcs-2?  

> No. You cannot push or pull between darcs-2 format repos and darcs-1 or
> hashed format repos. This might not be optimal but is understandable, since
> the theory underlying the darcs-2 repository format is different.

So if I'm pulling from/pushing to a darcs-2-format repo, my local repo
must be darcs-2 as well?

> The more important problem is that conversion to darcs-2 format doesn't
> support multiple branches at all. 

To make this perfectly clear: this is the *conversion process* only,
you can still have multiple branches *after* all repos have been
synced to a single conversion. Right?)

Should something like this work?

darcs convert main main-2
cd branch
mv _darcs old_darcs
cp -a ../main-2/_darcs .
darcs rec -am "amalgam of changes in 'branch'"

(But you'd lose your recorded history specific to the branch.)

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: poll: how can we help you contribute to darcs?

[Adrian Hey]

Brandon S. Allbery KF8NH wrote:

(Hm, I feel a blog rant coming on.)


I take it you mean as the perfect example of how to kill off interest in
your own project :-) I can't help thinking this was so obviously going
to happen that it must have been Davids intent at the time he wrote
that announcement. The only doubt I have is whether he was just in a
grumpy mood at the time and now regrets this, or whether he still feels
this way.

To answer the OP's question, when I first looked at darcs I was quite
enthusastic about it and did indeed consider hacking on it. But a few
hours browsing the source code made me realise I would never be able to
do this easily because of the lack of decent documentation of source. It
was "literate" haskell (which I dislike anyway) and the literate
commentation that I could see told me practically nothing about the code
I was actually looking at. Instead it was just the markup that would
eventually become the user guide (presumably). So as well as having no
useful documentation (for a would be contributor) I had make the extra
mental effort deliberately avoiding reading the distacting and utterly
irrelevant literate commentation clutter. It would have been easier if
there was no comments at all.

The net result was that I couldn't even figure out what the various
functions I was looking at were trying to do (and hence whether of not
they might be the source of the bug or performance bottleneck or
whatever). Put simply, (as someone else observed earlier) it seemed to
me like it was written and organised so as to be unmaintainable by
anyone other than David himself. That said, I think by normal the
standards of OS projects darcs *user* documentation is very good,
but for would be hackers this is not enough (decent source
documentation is needed too IMO).

I also think Neils idea of breaking darcs up from 1 monolithic prog
to a darcs lib suite is a good idea. This would give decent haddock
documentation for most of the code base and an easy way to have
multiple user interfaces (gui/web/command line based).

Regards
--
Adrian Hey

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

[Haskell-cafe] the Haskell "with" "pattern"?

[Galchin, Vasili]

Hello,

1) Is there a common assumed semantics across all of the Haskell "with"
things? withString? withData?

2) If the answer to 1) is yes, then does this imply some kind of
polymorphism? Couldn't "with" be "reduced" to a higher order function then
??

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

[Haskell-cafe] helping you contribute to darcs (poll results so far)

[Eric Y. Kow]

Dear Haskellers,

Last Friday, I had posted a message asking how the darcs community
could a better job recruiting developers to hack on darcs.  Thanks for
all the great responses!  I am gratified by the suggestions you have
offered, as well as the recent uptick in community involvement.

The responses so far fall along three themes: offering new features,
improving code accessibility and shaking up the community:

  Features
   - GUI (david48, Bit Conner)
   - splitting/merging (Luke Palmer, Ben Franksen)
   - binary file handling (Jason Dusek)
   - ... already does what I want (Allan Clark, Andrew Coppin)

  Code accessibility
   - split into libs (Neil Mitchell)
   - unit tests! (Ashley Moran)
   - code documentation (Lele Gaifax)
   - patch theory docs (Apfelmus, Ferenc Wagner)
   - inherent simplicity of model, cf git (Austin Seipp)

  Community
   - release announcements (Brandon Allbery, Neil Mitchell, Don Stewart)
   - showing ways to help  (Wren Ng Thorton, Ferenc Wagner)
   - announcing our need for help (Wren Ng Thorton)
   - easier entry point to darcs code, à la xmonad (Petr Rockai)
   - more active leadership (Don Stewart, Lele Gaifax)

One thing which is clear is that the darcs team have failed to
communicate effectively: the code is not as well-documented as it should
be, patch theory is still not defined clearly or rigorously enough for
Haskellers, the recent release announcements gave people the impression
that darcs was being abandoned, and we haven't made it clear that we
needed your help.

We need your help
-
Hopefully one thing is clearer after this discussion.  We definitely
need your help!

What we need most of all are some Haskell optimisation gurus to join
the project, even in a minor way.  Darcs 2 offers some huge improvements
in safety and core efficiency.  Unfortunately, these improvements are
overshadowed by poor performance.  Paradoxically speaking, darcs 2 just
isn't fast enough for people to notice how much faster it has gotten!
We need somebody to comb through our code and spot the silly things
which are making performance suffer.  Is there something too strict?
Too lazy?  Are going about IO completely the wrong way?

There is no patch theory needed for this!  Anybody with an eye for
performance should be able to rip into this code and find something
to fix.

If you are not an optimisation guru, there are still loads of ways to
help.  For starters, you could help us to improve our support for
Windows, or maybe some of the ProbablyEasy bugs:

  http://bugs.darcs.net/[EMAIL 
PROTECTED],id,activity,status,assignedto&@filter=topic,status&topic=6&status=-1,1,2,3,4,5,6,7

We will communicate better
--
The darcs 2 release announcement was very frank, but it also painted an
inaccurate picture of the situation.

Here is a clearer picture: we are all still very interested in darcs and
want to keep using it!  If you have a large repository and you cannot
wait for us to fix performance bugs, we wish you the best with git
(etc).  But if darcs can handle your repository, we hope you stick
around.

It is true that David is taking a lower profile, but this just means
that he is not following every discussion on the mailing list or
every new bug and feature request.  David is still receiving patches
and reviewing them on a daily basis, providing the usual technical
insight.  So keep sending those patches!

That's all for now
--
I am going to leave things here for now, despite all the interesting
points we could still address and see where else the discussion leads.
In my next reply, I hope to address some of the more of suggestions you
have offered.

Thanks again!

-- 
Eric Kow 
PGP Key ID: 08AC04F9


pgpx2wdQW6wTl.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Show me

[Jonathan Cast]

On Tue, 2008-08-05 at 20:28 +0100, Andrew Coppin wrote:
> Suppose we have the following:
> 
>   data Foo x
>   list_foo :: [x] -> Foo x
>   foo_list :: Foo x -> [x]
> 
> What would be the best way to write a Show instance?
> 
> The thing that I came up with is
> 
>   instance (Show x) => Show (Foo x) where
> show foo = "list_foo " ++ show (foo_list foo)
> 
> But apparently you're supposed to use the strange "showsPrec" method 
> that I don't understand. So can somebody show me a correct instance 
> definition for this type please?

instance Show x => Show (Foo x) where
  showsPrec n foo = ("list_foo "++) . shows (foo_list foo)

You use the n parameter if you've got an infix operator in your syntax
and you want to put parentheses around an instance of it if n has the
wrong value (either too high or too low, I can never remember).

jcc


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

[Haskell-cafe] Show me

[Andrew Coppin]

Suppose we have the following:

 data Foo x
 list_foo :: [x] -> Foo x
 foo_list :: Foo x -> [x]

What would be the best way to write a Show instance?

The thing that I came up with is

 instance (Show x) => Show (Foo x) where
   show foo = "list_foo " ++ show (foo_list foo)

But apparently you're supposed to use the strange "showsPrec" method 
that I don't understand. So can somebody show me a correct instance 
definition for this type please?


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

RE: [Haskell-cafe] Scripting COM Components from Haskell - GreenCard on Hackage

[john lask]

Gunther

Hdirect can be found at: http://www.haskell.org/hdirect/

the Hdirect library was conceived prior to the finalisation of the haskell ffi, 
consequently some work would be required to adapt it to the current ffi. 

What you want is just the automation library which is only part of the overall 
package (the package includes ihc, the interface generator, from memory ), the 
automation library could easily be seporated from the rest of the package, 
stripping away the hdirect marshalling utils to make use of the current ffi 
functions and marshalling utils. This would be a relatively straight forward 
task, for someone that way inclined.


you might also want to have a look at hugs.net:

http://www.galois.com/~sof/hugs98.net/

John.

> Date: Tue, 5 Aug 2008 15:30:49 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [Haskell-cafe] Scripting COM Components from Haskell - GreenCard 
> on Hackage
> CC: haskell-cafe@haskell.org
>
> No! Greencard is another story. The paper describes HDirect.
>
> On Tue, Aug 5, 2008 at 3:02 PM, GüŸnther Schmidt  wrote:
>> Hi,
>>
>> does anybody know if the Greencard package / lib is the same software that
>> is mentioned in the paper "Scripting COM Components from Haskell"?
>>
>> http://research.microsoft.com/~simonpj/papers/com.ps.gz
>>
>> I managed to install the hackage Greencard package on XP with GHC 6.8.3 but
>> it seems to be quite different from what the paper describes.
>>
>> Günther
>>
>> ___
>> 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

_
Meet singles near you. Try ninemsn dating now!
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=773166080&_r=WL_TAGLINE&_m=EXT___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] code review? store server, 220loc.

[Tim Newsham]

On Sat, Aug 2, 2008 at 10:13 PM, Tim Newsham <[EMAIL PROTECTED]> wrote:

  http://www.thenewsh.com/%7Enewsham/store/Server5.hs


You should try profiling this. I can see a few possible problems (such
as reading String from a socket, instead of a ByteString), but it's
difficult to predict what might be causing your code to be so slow.
Haskell code ought to be much more competitive with C for an
application like this.


Profiling didn't turn up anything obvious:
  http://www.thenewsh.com/~newsham/store/Server9.prof

one thing I dont quite understand is that it seems to be crediting
more time to "put8" and "get8" than is warranted, perhaps all of
the "get" and "put" functions...

One suprising result from testing:
  http://www.thenewsh.com/~newsham/store/TestBin.hs

shows that the Data.Binary marshalling is actually very fast, but
when I want to add a length field at the start of the buffer it
has a huge impact on performance.  I've tried several variations without
much luck...  (also the third test case is very odd in that skipping
a conversion to strict bytestring actually makes it slower(!)).

soo... I think thats probably one of the things limiting my performance.
Another one is probably my need to do two reads (one for length one
for the data) for each received record... I think with some trickiness
I could get around that (since recv will return only as many bytes as
are immediately available) but I don't know that its worth the effort
right now

Anyway, any thoughts, especially on how to make the bytestring operations
faster, would be appreciated.

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

Re: [Haskell-cafe] Stripping text of xml tags and special symbols

[Benja Fallenstein]

Hi Pieter,

2008/8/5 Pieter Laeremans <[EMAIL PROTECTED]>:
> But the sphinx indexer complains that the xml isn't valid.  When I look at
> the errors this seems due to some documents containing not well formed
>  html.

If you need to cope with non-well-formed HTML, try HTML Tidy:

http://tidy.sourceforge.net/

All the best,
- Benja
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Stripping text of xml tags and special symbols

[Jeremy Shaw]

At Tue, 5 Aug 2008 23:21:43 +0200,
Pieter Laeremans wrote:

> And is there some haskell function which converts special tokens lik & ->
> & and é -> &egu; ?

By default, xml only has 5 predefined entities: quot, amp, apos, lt,
and gt. Any additional ones are defined in the DTD.

But you can *always* use numeric character references like:

&#; 
or
&#x;

So, you should be able to implement a simple function which whitelists
a few characters ('a'..'z', 'A'..'Z', '0'..'9', ...), and encodes
everything else?

You might look at the source code for Text.XML.HaXml.Escape and
Network.URI.escapeString for inspiration.

j.

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

[Haskell-cafe] Stripping text of xml tags and special symbols

[Pieter Laeremans]

Hi,
I  've got a lot of files which I need to proces in order to make them
indexable by sphinx.
The files contain the data of a website with a custom perl based cms.
 Unfortunatly they sometimes contain xml/html tags like 

And since most of the texts are in dutch and some are in French they also
contain a lot of special characters like ë é, ...

I'm trying to replace the custom based perl based cms by a haskell one.  And
I would like to add search capability. Since someone wrote sphinx
bindings a few weeks ago I thought I try that.

But transforming the files in something that sphinx seems a challenge.  Most
special character problems seem to go aways when I  use encodeString
(Codec.Binary.UTF8.String)
on the indexable data.

But the sphinx indexer complains that the xml isn't valid.  When I look at
the errors this seems due to some documents containing not well formed
 html.
I would like to use a programmatic solution to this problem.

And is there some haskell function which converts special tokens lik & ->
& and é -> &egu; ?

thanks in advance,

Pieter



-- 
Pieter Laeremans <[EMAIL PROTECTED]>

"The future is here. It's just not evenly distributed yet." W. Gibson
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Brainstorming on how to parse IMAP

[John MacFarlane]

+++ John Goerzen [Aug 05 08 10:13 ]:
> >> I'm interested in thoughts people have on parsing libraries and methods.
> >>  I'm a huge fan of Parsec overall -- it lets me have a single-stage
> >> parser, for instance.  But it isn't sufficiently lazy for this task, and
> >> I probably will need to deal with ByteStrings instead of Strings, since
> >> some IMAP messages may be 30MB or more.
> > 
> > You might be interested in Frisby: http://repetae.net/computer/frisby/
> 
> Are there any examples available for it anywhere?

I wrote a markdown parser using Frisby:
http://github.com/jgm/markdown-peg/tree/master

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

[Haskell-cafe] Re: Brainstorming on how to parse IMAP

[ChrisK]

I am glad you asked Ben,

Short answer: It can return a Seq of your values. The values in the Seq are 
lazy, the Seq itself is finite.  It can return what it has so far before it 
finishes parsing (or even before the rest of the input has arrived from the 
network).


Ben Franksen wrote:

ChrisK wrote:

   I recently posted new and fancy binary Get monads in
http://article.gmane.org/gmane.comp.lang.haskell.libraries/9691
and
http://article.gmane.org/gmane.comp.lang.haskell.libraries/9756
which might be of interest since network protocol are usually specified in
bytes at the wire level.

   The latest one takes input which may or may not be complete and returns
   a
stream (a Seq) of results.


IIRC Seq is not a 'Stream' but a strict sequence? Or do you meant 'a stream
(of Seq)'?


I meant it returns many (Seq y), one after the other, while doing parsing in 
between.




Cheers
Ben


Long answer:

The complicated parser looks like this.  Start with the run function:

runCompGet :: (Monad m,Monoid w)
=> CompGet a y r w user m a
-> r -> user -> L.ByteString
-> m (CompResult y w user m a)

This takes a CompGet and a reader state r and a user state user and the 
(initial) input L.ByteString (Data.ByteString.Lazy.ByteString).  It evaluates to 
 the inner monad 'm' returning a CompResult.


The CompResult is a three-fold type:


data CompResult y w user m a =
CFailed (Seq y) !Int64 String
  | CFinished  (Seq y) !L.ByteString !Int64 w user a
  | CPartial (Seq y) (Either ( m (CompResult y w user m a) )
 ( Maybe L.ByteString -> m (CompResult y w user 
m a) ))



All three have (Seq y) which are the Data.Sequence.Seq of things which have been 
queued by "yieldItem".


CFailed also has the Int64 count of bytes parsed successfully and an error 
message String.  Nothing more can be done.


CFinished also has the unused tail of the input as a L.ByteString and an Int64
of the bytes consumed.  And the output of the writer w, the final user state, 
and lastly it has the end value returned by the computation which has type 'a'. 
 Nothing more can be done.


CPartial is the intermediate result.  It also carries Either:
 Left : the rest of the computation, currently suspended, to continue running.
 Right: a function from (Maybe ByteString) to the suspended computation.

The Left is a result of the "flushItems" command and is merely a way to return 
the (Seq y) so far before continuing.


The Right is a result of running out of input data.  This allows the program to 
feed more input into the parser which will be appended to all the previous 
input. One does this by passing (Just someByteString) to the function.  If the 
parser again runs out of data it will again return CPartial with a Right value.


Alternatively, one can pass Nothing.  This tells the parser that there will 
never ever be more input. The parser will never ask for (though it may 
flushItems and return a Right valued CPartial).


A key thing about the (Seq y) is that yielded items are only returned once.  The 
CPartial may be returned many times and each time it will have an empty list or 
fresh list of (Seq y).  The values in the Seq are lazy, the Seq itself is 
finite.  To collect all the value the caller has to concatenate all the (Seq 
y)'s that are returned during parsing.


As for parsing, the module offers the usual BinaryParser interface (package 
binary-strict) and has an interface which mostly overlaps Data.Binary.Get 
(package binary). For example: it has "getByteString" and "getWord64be" and 
"getStorable".


You don't have to use the "yieldItem" command.  You can just return the results 
in the final "a" return value (or the "user" state or the writer "w" value).  In 
this situation you only get an answer when CFinished is returned (and nothing if 
CFailed is returned).  I could not use the writer mechanism for yield-ing 
because the "listen" and "pass" parts of the MonadWriter class ensure it has the 
wrong semantics.


You might wonder:
 *) If the parser code uses MonadPlus to give several alternatives
 *) The first alternative gets more input via CPartial (perhaps several times)
 *) The first alternative then fails
 *) The second alternative starts parsing from the same position the first did
 *) Does the second alternative see the new input passed to CPartial earlier?
The answer is yes.  Changes to the input stream by appending with CPartial 
affect the whole computation and are never rolled back.


You might wonder:
  *) If the first alternative calls "yieldItem foo"
  *) The first alternative fails
  *) The second alternative calls flushItems
  *) Does the CPartial (Seq y) contain "foo"?
The answer is yes.  Items yielded are never rolled back.

[ Doing all of this in the presence of throwError/mzero/fail and lookAhead* and 
callCC was interesting to code. ]


Cheers,
  Chris

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.o

Re: [Haskell-cafe] Capitalization and associated type families

[Ryan Ingram]

On Tue, Aug 5, 2008 at 12:22 PM, Brian Hulley <[EMAIL PROTECTED]> wrote:
> unfortunately there is no corresponding protection when writing types inside
> class decls:
>
>class Zap a where
>g :: a -> 
>^ oops!

Well, I think there's a pretty good protection; instances usually
won't typecheck until it's fixed.

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

[Haskell-cafe] Re: Brainstorming on how to parse IMAP

[Ben Franksen]

ChrisK wrote:
>I recently posted new and fancy binary Get monads in
> http://article.gmane.org/gmane.comp.lang.haskell.libraries/9691
> and
> http://article.gmane.org/gmane.comp.lang.haskell.libraries/9756
> which might be of interest since network protocol are usually specified in
> bytes at the wire level.
> 
>The latest one takes input which may or may not be complete and returns
>a
> stream (a Seq) of results.

IIRC Seq is not a 'Stream' but a strict sequence? Or do you meant 'a stream
(of Seq)'?

Cheers
Ben

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

[Haskell-cafe] Re: Re: Brainstorming on how to parse IMAP

[Ben Franksen]

John Goerzen wrote:
> Ben Franksen wrote:
>> John Goerzen wrote:
>>> I'm interested in writing a library to work with IMAP servers.
>>>
>>> I'm interested in thoughts people have on parsing libraries and methods.
>>>  I'm a huge fan of Parsec overall -- it lets me have a single-stage
>>> parser, for instance.  But it isn't sufficiently lazy for this task, and
>>> I probably will need to deal with ByteStrings instead of Strings, since
>>> some IMAP messages may be 30MB or more.
>> 
>> You might be interested in Frisby: http://repetae.net/computer/frisby/
> 
> Are there any examples available for it anywhere?

I am pretty sure John Meacham has some examples but I personally don't know
any. I have once used it for something but in the end went back to parsec
because it was slightly faster and I had no need for the lazyness.

Cheers
Ben

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

Re: [Haskell-cafe] Capitalization and associated type families

[Brian Hulley]

Tillmann Rendel wrote:

Brian Hulley wrote:


class Foo a where

f :: a -> b -> (a, b)

Here there is no capitalization distinction in the type of (f) but the 
implementation can still insert the "forall b." since (a) is already 
in scope. Therefore similarly, if type constructors like "List" were 
instead written using lowercase, since they would already be in scope 
it would be clear even without explicit quantifiers that (a) and (b), 
but not (list), were to be quantified in the type of (map) (assuming 
of course that there was no top level data decl for (a) or (b)).


So adding b to the export list of an imported module would change the 
type of f?


Yes, if the module in which the above class decl were defined imported a 
data type (b) from some other module (or defined it elsewhere in the 
same module) then (f)'s type would change. (Of course at the moment this 
can't happen because (b) is lowercase so it can't be introduced by 
data/type decls or imported/exported.)


The type of (f) would also change if Haskell were extended to support 
nested classes:


class Bar b where
class Foo a where
f :: a -> b -> (a, b)

But as Jonathan pointed out this behaviour is not really all that ideal 
since even in Haskell at the moment a simple spelling mistake could 
cause silent quantification instead of an error (which is perhaps the 
main justification for why constructors introduced by data/type decls 
must currently be capitalized -- unfortunately there is no corresponding 
protection when writing types inside class decls):


class Zap a where
g :: a -> 
^ oops!
Cheers -
Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Capitalization and associated type families

[Brian Hulley]

Jonathan Cast wrote:


It's weird.  ML-derived languages are functional languages at the value
level (and have regular lambda-bound variables in consequence), but are
logical languages at the type level (and have logical variables in
consequence).  So ordinary lambda-bound variables, like in ML-style
functors (parametrized modules) act more like type constants than like
type variables.


Thanks - the above seems to be a promising avenue of thought to arrive 
at clarity regarding case distinctions at the type level, and I can see 
here the basis for a good argument of why there would actually be no 
inconsistency regarding the use of capitals for module type members and 
lowercase for the class parameters. Perhaps this is also the root of the 
difference between associated type synonyms and class params.


Ie at the type level, uppercase == functional variable (aka "constant") 
and lowercase == logic variable...


The type level now seems to me to be quite significantly more 
complicated than the value level due to the mixing of functional and 
logic programming, not to mention that at the type level "variables" in 
an outer scope become "constants" in an inner scope as far as pattern 
matching is concerned whereas for value patterns variables are always 
fresh and never scoped (over other patterns).


Therefore I've decided to deal with the issue of case at each level 
separately since it seems immediately clear that the case distinction at 
the value level, as in Haskell/OCaml/Moby, is obviously good due to the 
"foolproof" nature of value patterns you pointed out, whereas at the 
type level it may also be good but I'll need a few more months to think 
about it... ;-)


Cheers,
Brian.

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

[Haskell-cafe] Re: poll: how can we help you contribute to darcs?

[Ben Franksen]

Ketil Malde wrote:
> The consequences of moving to the darcs-2 format are a bit unclear to
> me. For instance, I'd like to keep my main (export) repo in darcs-1
> format, in order to make it as accessible as possible (Ubuntu still
> ships with darcs-1.0.9, and that's a fairly cutting edge
> distribution.)  Can I convert my working repos to darcs-2?  

No. You cannot push or pull between darcs-2 format repos and darcs-1 or
hashed format repos. This might not be optimal but is understandable, since
the theory underlying the darcs-2 repository format is different.

The more important problem is that conversion to darcs-2 format doesn't
support multiple branches at all. Some people recommend the use of tailor
for this. However, on some of our repositories this fails to produce
correct results, or crashes somewhere during the conversion. I have tried
it and it is an endless frustration.

BTW, this is a point where projects (such as darcs) cannot be careful
enough: migration paths simply /must/ exists. This should have been top
priority and a milestone for the release of darcs-2.0. As it is, I have
asked twice on the darcs-users list how to convert multible branches before
I even got a single reply. I had the impression the remaining developers
are feeling almost as helpless as me.

> Should I?

No. 

> How about darcs-hashed?

Yes, darcs-hashed can be used together with darcs-1 repos. This works fine,
IME.

>  In short, I'd like to see examples of
> recommended migration strategies, and associated benefits.

Me too.

Cheers
Ben

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

[Haskell-cafe] Re: Brainstorming on how to parse IMAP

[ChrisK]

Hi John,

  I recently posted new and fancy binary Get monads in
http://article.gmane.org/gmane.comp.lang.haskell.libraries/9691
and
http://article.gmane.org/gmane.comp.lang.haskell.libraries/9756
which might be of interest since network protocol are usually specified in bytes 
at the wire level.


  The latest one takes input which may or may not be complete and returns a 
stream (a Seq) of results.  When it reaches the end of the input it pauses and 
asks for more.  This handling of partial input might be good for network 
protocols where you can feed the data from the socket to the parser in pieces. 
(This Get monad eats lazy bytestrings).


  The latest MyGetW.hs allows the Get code to send a Data.Sequence.Seq of 
results by using yieldItem (and perhaps flushItems).  This is in addition to any 
final result of the parser.


It has the usual binary Get interface, so you can pull bytestrings and words and 
(fancy) any Storable off the input.


  I call it "fancy" because the monad is a transformer, and it is a 
MonadError/MonadPlus/Alternative, and it supports lookAhead and callCC/MonadCont 
and Reader/Writer/State.  Whew.


As for IMAP, I use imapfilter (http://imapfilter.hellug.gr/) which uses Lua.

Cheers,
  Chris

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

Re: [Haskell-cafe] Capitalization and associated type families

[Tillmann Rendel]

Brian Hulley wrote:


class Foo a where

f :: a -> b -> (a, b)

Here there is no capitalization distinction in the type of (f) but the 
implementation can still insert the "forall b." since (a) is already in 
scope. Therefore similarly, if type constructors like "List" were 
instead written using lowercase, since they would already be in scope it 
would be clear even without explicit quantifiers that (a) and (b), but 
not (list), were to be quantified in the type of (map) (assuming of 
course that there was no top level data decl for (a) or (b)).


So adding b to the export list of an imported module would change the 
type of f?


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

Re: [Haskell-cafe] Brainstorming on how to parse IMAP

[Donn Cave]

Quoth John Goerzen <[EMAIL PROTECTED]>:
| Donn Cave wrote:
...
|> So I would let the application come up with the data.  In general,
|
| Well, your response here begs the question of how much you want to
| automate from the application.  Yes, there are multiple ways of
| communicating with IMAP servers, but you have the same synchronization
| issues with all of them.  Yes, I plan to let the application supply
| functions to read data.  But in the end, that is pointless if those
| functions can't be written in Haskell!

Sorry, I didn't entirely understand that, but the way I see it, you
might or might not be able to map the set of issues with one transport
vs. another onto some common abstraction.  And anyway it's much easier
and cleaner for you to implement the protocol parser as a pure function
of bytestring -> response, than tangle it up with I/O.  

OK, here's a trivial example of what I see as the virtues of this approach.
I don't think I actually return any size information along with my
`incomplete' failure response, but it occurs to me that I should.  Then
a graphic application can use that to start a progress indicator for
large transfers.  It will be easy for my application to update that
progress indicator, because it got the expected size and is getting the
data.  Harder to make that work through generic I/O functions invoked
inside the parser, I think.

| > I don't think there's any way to specify how much to read - I mean,
| > the counted literal certainly provides that information, but that's the
| > exception - so I would assume the application will need some kind of
| > recv(2)-like function that reads data as available.
|
| Exactly.  But there is no recv()-like function, except the one that
| returns IO String.  There is no recv()-like function that returns IO
| ByteString.

Well, right, that's needed.  I just hacked out my own FFI. (Likewise
for SSL.)  In a platform context where you're forced to use buffered
input semantics, you might use hGetLine and then read fixed amounts
as required for counted literals (so the parser would need to return
a bytes-needed-to-complete value to support that.)

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

Re: [Haskell-cafe] Brainstorming on how to parse IMAP

[John Goerzen]

Donn Cave wrote:
> I mentioned that my parser may return an incomplete status.  In principle,
> something like
> 
>   parseResponse :: ByteString -> Maybe (IMAPResponse, ByteString)
> 
> That means the parse needs to be repeated each time until enough input
> data has accumulated.  I worried a little about how to represent a
> useful incomplete parse state, but decided that it isn't worth the
> trouble - the amount of parsing in an ordinary response is too trivial.

But the problem here is getting that first ByteString in the first place.

Are you suggesting it would be the result of hGetContents or somesuch,
reading from a socket?

I've tried the sort of approach with my FTP library.  It can be done,
but it is exceptionally tricky and I wouldn't do it again.  You have to
make extremely careful use of things like try in Parsec, and even just
regular choices (sometimes it wants to read a character that won't exist
yet.)  Also buffering plays into it too.

The trick with reading from the network in a back-and-forth protocol is
knowing how much to read.  You have to be very careful here.  If you try
to read too much (and are blocking until you read), you will get
deadlock because you are reading data that the other end isn't going to
send yet.

And that, as I see it, is the problem with the above.  It seems to be a
chicken-and-egg problem in my mind: how do you know how much data to
read until you've parsed the last bit of data that tells you how to read
the next bit?

> | 3) The linkage between Parsec and IO is weak.  I cannot write an
> | "IMAPResponse" parser.  I would have a write a set of parsers to parse
> | individual components of the IMAP response as part of the IO monad code
> | that reads the IMAP response, since the result of one dictates how much
> | network data I attempt to read.
> 
> 
> The parser should just parse data, and not read it.
> 
> You don't need to worry about whether you can get recv(2) semantics on
> a socket with bytestrings, and you don't need to saddle users of this
> parser with whatever choice you might make there.  You don't need to
> supply an SSL input function with the same semantics, or account for
> the possibility that data might actually not be coming from a socket
> at all (UNIX pipes are not unheard of.)  You don't need to lock users
> into whatever execution dispatching might be supported by that I/O,
> potentially ruling out graphics libraries etc. that might not be compatible.
> 
> So I would let the application come up with the data.  In general,

Well, your response here begs the question of how much you want to
automate from the application.  Yes, there are multiple ways of
communicating with IMAP servers, but you have the same synchronization
issues with all of them.  Yes, I plan to let the application supply
functions to read data.  But in the end, that is pointless if those
functions can't be written in Haskell!

> I don't think there's any way to specify how much to read - I mean,
> the counted literal certainly provides that information, but that's the
> exception - so I would assume the application will need some kind of
> recv(2)-like function that reads data as available.

Exactly.  But there is no recv()-like function, except the one that
returns IO String.  There is no recv()-like function that returns IO
ByteString.

(I actually notice now a package on Hackage that does this... why it's
not in core, I don't know.)

> By the way, if you haven't already run across this, you may be interested
> to read about the IMAP "IDLE" command, cf. RFC2177.  I think the value
> of this feature can be overstated, but it depends on the server, and some
> IMAP client implementators are very fond of it.  At this point, the reason
> it might be interesting is that it moves away from the call & response
> pattern.

It's on my todo list.

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

[Haskell-cafe] GHC Feature or Bug: f x = (`head` x, ())

[Jeremy Shaw]

Hello,

GHC is happy to compile this code:

> f x = (`head` x, ())

but Hugs does not like it, and Section 3.5 of the Haskell Report does
not give any obvious indications that it is valid. Numerous people
have suggested that some additional parens are required:

> f x = ((`head` x), ())

Is this GHC behavior intentional? If not, is it perhaps a happy
accident? Or is it ambigious in some way with out the additional
parenthesis ?

I am curious because trhsx (the preprocessor for HSP/HSX) currently
does not accept this construct. If it is a bug in GHC (that will
eventually be fixed), then we can leave trhsx alone. If it is a
feature, then a precise definition of the adjusted syntax would be
helpful. (Or, if this construct is valid H98, an explaination of how
to read the report correctly).

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

Re: [Haskell-cafe] Brainstorming on how to parse IMAP

[Donn Cave]

Quoth John Goerzen <[EMAIL PROTECTED]>:
...
| One problem with that is that if I use specific parsing library foo,
| then only others that are familiar with specific parsing library foo can
| hack on it.

Well, you asked.  For me, the parsing is a relatively minor part of the
problem and maybe not one that benefits greatly from external support.
MIME might be a different story.

| 2) A lot of RFC protocols -- and IMAP in particular -- can involve
| complex responses from the server with hierarchical data, and the parse
| of, say, line 1 and of each successive line can indicate whether or not
| to read more data from the server.  Parsing of these lines is a stateful
| activity.

I mentioned that my parser may return an incomplete status.  In principle,
something like

  parseResponse :: ByteString -> Maybe (IMAPResponse, ByteString)

That means the parse needs to be repeated each time until enough input
data has accumulated.  I worried a little about how to represent a
useful incomplete parse state, but decided that it isn't worth the
trouble - the amount of parsing in an ordinary response is too trivial.


| 3) The linkage between Parsec and IO is weak.  I cannot write an
| "IMAPResponse" parser.  I would have a write a set of parsers to parse
| individual components of the IMAP response as part of the IO monad code
| that reads the IMAP response, since the result of one dictates how much
| network data I attempt to read.


The parser should just parse data, and not read it.

You don't need to worry about whether you can get recv(2) semantics on
a socket with bytestrings, and you don't need to saddle users of this
parser with whatever choice you might make there.  You don't need to
supply an SSL input function with the same semantics, or account for
the possibility that data might actually not be coming from a socket
at all (UNIX pipes are not unheard of.)  You don't need to lock users
into whatever execution dispatching might be supported by that I/O,
potentially ruling out graphics libraries etc. that might not be compatible.

So I would let the application come up with the data.  In general,
I don't think there's any way to specify how much to read - I mean,
the counted literal certainly provides that information, but that's the
exception - so I would assume the application will need some kind of
recv(2)-like function that reads data as available.

By the way, if you haven't already run across this, you may be interested
to read about the IMAP "IDLE" command, cf. RFC2177.  I think the value
of this feature can be overstated, but it depends on the server, and some
IMAP client implementators are very fond of it.  At this point, the reason
it might be interesting is that it moves away from the call & response
pattern.

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

Re: [Haskell-cafe] Brainstorming on how to parse IMAP

[John Goerzen]

Hi folks,

Thanks to those that responded on this -- certainly some libraries to
check out here.

One problem with that is that if I use specific parsing library foo,
then only others that are familiar with specific parsing library foo can
hack on it.

In general though, I think this speaks to more generic problems:

1) A lot of network protocols require reading data of arbitrary length
until a certain delimiter is found.  Often that delimiter is \n.
Haskell is really weak at this.  We can turn a Socket into a Handle and
use hGetLine, but this has a security weakness: it has no upper bounds
on the amount of data read, and this is vulnerable to resource
exhaustion DOS from the remote end.  There is, as far as I can tell, no
general-purpose "buffer until I see foo" framework in Haskell.  (Note
that just reading character-by-character is too slow as well).

1a) Even more generally, a "read one packet of data, however much
becomes available" notion is pretty weak.  For a lazy ByteString, my
only two choices are to block until n bytes are available (where n is
specified in advance), or to not block at all.  There is no "block until
some data, however much, becomes available, and return that chunk up to
a maxmimum size x."  Well, Network.Socket.recv may do this, but it
returns a String.  Is there even a way to do this with a ByteString?

2) A lot of RFC protocols -- and IMAP in particular -- can involve
complex responses from the server with hierarchical data, and the parse
of, say, line 1 and of each successive line can indicate whether or not
to read more data from the server.  Parsing of these lines is a stateful
activity.

3) The linkage between Parsec and IO is weak.  I cannot write an
"IMAPResponse" parser.  I would have a write a set of parsers to parse
individual components of the IMAP response as part of the IO monad code
that reads the IMAP response, since the result of one dictates how much
network data I attempt to read.

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

Re: [Haskell-cafe] Re: Brainstorming on how to parse IMAP

[John Goerzen]

Ben Franksen wrote:
> John Goerzen wrote:
>> I'm interested in writing a library to work with IMAP servers.
>>
>> I'm interested in thoughts people have on parsing libraries and methods.
>>  I'm a huge fan of Parsec overall -- it lets me have a single-stage
>> parser, for instance.  But it isn't sufficiently lazy for this task, and
>> I probably will need to deal with ByteStrings instead of Strings, since
>> some IMAP messages may be 30MB or more.
> 
> You might be interested in Frisby: http://repetae.net/computer/frisby/

Are there any examples available for it anywhere?


> 
> Cheers
> Ben
> 
> ___
> 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] Scripting COM Components from Haskell - GreenCard on Hackage

[Krasimir Angelov]

No! Greencard is another story. The paper describes HDirect.

On Tue, Aug 5, 2008 at 3:02 PM, GüŸnther Schmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> does anybody know if the Greencard package / lib is the same software that
> is mentioned in the paper "Scripting COM Components from Haskell"?
>
> http://research.microsoft.com/~simonpj/papers/com.ps.gz
>
> I managed to install the hackage Greencard package on XP with GHC 6.8.3 but
> it seems to be quite different from what the paper describes.
>
> Günther
>
> ___
> 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] ActiveX and COM

[Krasimir Angelov]

Hi Günther,

You can also consider the hscom library:

http://darcs.haskell.org/packages/hscom/

There is a simple demo that automates MS Agent. The library is not
completed but if you are interested only in controlling Excel via
automation it should provide what you need. I started hscom because I
was disappointed from HDirect while working on Visual Haskell. It
overcomes some problems and in addition it is designed to be more in
the style of the modern FFI library. The library is not under active
development but I can assist with simple fixes.

Regards,
  Krasimir



On Mon, Aug 4, 2008 at 11:47 AM, GüŸnther Schmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> what is currently the recommend way to interface with COM from haskell?
>
> I need to create an Excel Sheet and thus need to use Excel via COM.
>
> Günther
>
> ___
> 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] Scripting COM Components from Haskell - GreenCard on Hackage

[GüŸnther Schmidt]

Hi,

does anybody know if the Greencard package / lib is the same software 
that is mentioned in the paper "Scripting COM Components from Haskell"?


http://research.microsoft.com/~simonpj/papers/com.ps.gz

I managed to install the hackage Greencard package on XP with GHC 6.8.3 
but it seems to be quite different from what the paper describes.


Günther

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

Re: [Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell)

[Henning Thielemann]

On Tue, 5 Aug 2008, jinjing wrote:

> Here's the project link:
>
> http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown

Would you like to post this to
   [EMAIL PROTECTED]
 as well?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] array fusion interface

[Henning Thielemann]

On Sat, 2 Aug 2008, Evan Laforge wrote:

> >> I have streams of samples with irregular sampling rates, so they look
> >> like [(Time, SampleVal)].  In practice, this means [(Double, Double)].
> >
> > Maybe I have already mentioned my eventlist package on Hackage which
> > supports such resampling operations - but is based on lists.
> >   http://hackage.haskell.org/cgi-bin/hackage-scripts/package/event-list
>
> Ah, I had seen event-list and even downloaded and read parts of it,
> but it was hard for me to figure out what was going on and how to
> actually use it based on the scattered comments in the source.

I commented only non-trivial parts, because I thought it is clear, that
'mapTime' is a 'map' on the time stamps and so on.

> Apparently there are absolute and relative time variants, but within
> that there are further "body" and "time" variants, and they're built
> on a similarly sparsely documented alternating list library.  Are
> there some simple examples of its use out there?

There are all four variants of whether a list starts and ends with a time
or a data body. The 'midi' package uses 'event-list'.

> Unfortunately, storable vector, unlike ByteString, doesn't export
> 'create' and whatnot so I have to keep a locally patched version of
> it.

Well, it does export 'create':
  
http://hackage.haskell.org/packages/archive/storablevector/0.1.2.2/doc/html/Data-StorableVector-Base.html

However in my applications I could use the safe 'unfoldrN' in most cases.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: Haskore tutorial (programming music using Haskell)

[jinjing]

Hi there,

Here's the project link:

http://github.com/nfjinjing/haskore-guide/tree/master/doc/index.markdown

I found Haskore pretty fun :) so I'm documenting it while learning it.
Please don't hesitate to give suggestions / corrections.

Questions:

* How much music theory should be there ? ( I'm gonna learn those anyway )
* What kind of examples would be cool ?

regards,

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

RE: [Haskell-cafe] Re: ANN: Haddock version 2.2.1

[Simon Marlow]

> > On 2008.08.04 20:47:12 +0200, Christian Maeder
> <[EMAIL PROTECTED]>
> > scribbled 1.1K characters:
> > > Right,
> > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-
> 1.4.0.1
> > > works.
> > >
> > > It seems that the dependencies for ghc-paths could be improved.
> > >
> > > Thanks Christian
> >
> > Yes, I emailed Marlow suggesting that yesterday. (Or perhaps it was the
> > day before.)
>
> Sorry - I fixed the .cabal file and then got sidetracked into trying to
> make it work with Cabal-1.5 too.  I'll upload the version with the fixed
> dependency now.

Hackage won't let me upload a package with cabal-version: >= 1.4 && < 1.5, but 
it will let me upload with just >= 1.4, so I've done that for now.  The package 
will fail to build if you have Cabal 1.5.x installed, presumably.

Cheers,
Simon

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

RE: [Haskell-cafe] Re: ANN: Haddock version 2.2.1

[Simon Marlow]

> On 2008.08.04 20:47:12 +0200, Christian Maeder <[EMAIL PROTECTED]>
> scribbled 1.1K characters:
> > Right,
> > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Cabal-1.4.0.1
> > works.
> >
> > It seems that the dependencies for ghc-paths could be improved.
> >
> > Thanks Christian
>
> Yes, I emailed Marlow suggesting that yesterday. (Or perhaps it was the
> day before.)

Sorry - I fixed the .cabal file and then got sidetracked into trying to make it 
work with Cabal-1.5 too.  I'll upload the version with the fixed dependency now.

Cheers,
Simon

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

Re: [Haskell-cafe] timing question

[Arie Groeneveld]

Acc. to Luke Palmers suggestion this will be the right answer?

*Main> seqList rwhnf(map f $ concat.replicate 100 $ unfoldr (knip 6) an)
()
(3.46 secs, 834240864 bytes)

or with/without  list construction

*Main> let ry = concat.replicate 100 $ unfoldr (knip 6) an
(0.00 secs, 0 bytes)
*Main> seqList rwhnf(map f ry)
()
(4.48 secs, 833668720 bytes)
*Main> seqList rwhnf(map f ry)
()
(3.18 secs, 627071612 bytes)
*Main>



Arie Groeneveld schreef:

Thanks for all the advises so far.

Ok, here's my monster that need to be timed in order to make a comparison:
(it's about the control digit of SEDOL numbers  
http://en.wikipedia.org/wiki/SEDOL ):



knip _ [] = Nothing
knip k xs = Just (splitAt k xs)

ip xs = sum . zipWith (*) xs

an =  ['0'..'9']++['A'..'Z']

s = take 841 $ cycle "0987654321"
f = \xs -> xs ++ [(sna!!).ip [1,3,1,7,3,9]. map (flip (fromJust .) an 
. findIndex . (==))$xs]




Here's my try for timing:

*Main> (foldl1 (\x y -> f y) .concat.replicate 100 $ unfoldr (knip 
6) an)

"UVWXYZ7"
(1.31 secs, 330291000 bytes)

(It's incl. the construction of the test list, as is in the language 
to compare )


I need the whole list to be evaluated.
Interpreted mode IS A MUST :-)

BTW I increased stack size


thanks


Don Stewart schreef:

bradypus:
  

Suppose I've:

f = map g

I want to know how much time it takes (interpreted mode) to fully 
process list xs (at least 1e6 elements) with function g. Is it 
sufficient to execute:


*Main> last . f $ xs

(x.xx secs, yyy bytes)

Are there any hidden difficulties involved?

Reason is: comparing timings Haskell vs an interpreted language without 
laziness.





If you care about timings, it's probably a better idea to compile the
code (with optimisations on), to get a better idea of what the code
would do in a production environment.

You could then just time the binary,

main = print . sum $ 

ghc -O2 A.hs --make
time ./A

-- 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