Ryan Ingram wrote:
Apfelmus, I hope you don't abandon your efforts, at least for the selfish
reason that I enjoy reading your blog entries about trying to implement it!
:D My reasoning was that a temporary demand-driven implementation would
allow me to release the library sooner; I want
2011/4/26 Trevor Elliott tre...@galois.com:
Hot on the heels of the last release, cereal-0.3.3.0 [1] adds support
for parsing and rendering lazy ByteStrings. Most running functions in
Data.Serialize.Get and Data.Serialize.Put now have lazy analogues, and
Data.Serialize has gained encodeLazy
Hello,
the final RNG state from the first execution of your code and passing it as
the initial state to the second
original intention of my question: How can I change the runOneRandom
function (with RNG updates) to return [ThingK True...] samples instead
of Int?
My solution so far:
import
I like to apply for the quote of the week. :-)
If Haskell is great because of its laziness,
then Python must be even greater,
since it is lazy at the type level.
Dynamically typed languages only check types if they have to, that is if
expressions are actually computed. Does this prove
On behalf of the Feldspar team, I'm happy to announce version 0.4.0.2 of
feldspar-language and feldspar-compiler:
http://hackage.haskell.org/package/feldspar-language
http://hackage.haskell.org/package/feldspar-compiler
Feldspar is an embedded domain-specific language for generating code
2011/4/27 Henning Thielemann lemm...@henning-thielemann.de:
I like to apply for the quote of the week. :-)
If Haskell is great because of its laziness,
then Python must be even greater,
since it is lazy at the type level.
Dynamically typed languages only check types if they have to,
Henning Thielemann lemm...@henning-thielemann.de writes:
I like to apply for the quote of the week. :-)
If Haskell is great because of its laziness,
then Python must be even greater,
since it is lazy at the type level.
Well, this is indeed (an elegant reformulation of) a common
2011/4/27 Ketil Malde ke...@malde.org:
Henning Thielemann lemm...@henning-thielemann.de writes:
That Haskell is great because of its laziness is arguable, see Robert
Harper's blog for all the arguing. (http://existentialtype.wordpress.com/)
I think that author sin't quite right there.
Eric Rasmussen schrieb:
Also, in the spirit of this discussion, is there a resource that
attempts to compare libraries for common tasks so developers can make
informed decisions without having to research each library or approach
on their own? As an example, in other languages you might read
On 27 Apr 2011, at 10:30, Henning Thielemann wrote:
I like to apply for the quote of the week. :-)
If Haskell is great because of its laziness,
then Python must be even greater,
since it is lazy at the type level.
Dynamically typed languages only check types if they have to, that
Hello all,
I'm very glad that I have been accepted again this year for the Google
Summer of Code [1] program for haskell.org. My project aims to improve
the text [2] library by converting it to internally use UTF-8 instead
of UTF-16.
UTF-8 and UTF-16 both have advantages and disadvantages, which
First, thanks to everyone for your input! It is really appreciated, and
I will be checking out the resources you provided.
Also, a correction: /Haskell: The Craft of Functional Programming /is
written by Simon Thompson, not Peyton-Jones. Mixup on my part there :)
On 04/27/2011 01:44 AM, Eric
On Wed, Apr 27, 2011 at 8:24 AM, Jasper Van der Jeugt
jasper...@gmail.com wrote:
UTF-8 and UTF-16 both have advantages and disadvantages, which
actually makes it a pretty complicated choice. I've written about this
a little in my [3] (especially see Tom Harper's master dissertation if
you're
On 27/04/11 20:02, Thomas Davie wrote:
This completely misses what laziness gives Haskell – it gives a way of
completing a smaller number of computations than it otherwise would have to
at run time. The hope being that this speeds up the calculation of the
result after the overhead of
It would be, if only it checked the (necessary) types during compile time. As
it is now, it seems like a claim that C is lazy just because any pointer can be
null.
Отправлено с iPhone
Apr 27, 2011, в 13:30, Henning Thielemann lemm...@henning-thielemann.de
написал(а):
I like to apply for
2011/4/27 MigMit miguelim...@yandex.ru:
It would be, if only it checked the (necessary) types during compile time. As
it is now, it seems like a claim that C is lazy just because any pointer can
be null.
Strictness analysis is only an optimization, you don't need it to be
lazy in the
Thomas Davie wrote:
This completely misses what laziness gives Haskell – it gives a way of
completing a smaller number of computations than it otherwise would have to at
run time. (...)
Tony Morris continues the ping-pong:
This is not what laziness gives us. Rather, it gives us terminating
Dear all,
It is not yet too late to contribute to the 20th edition of the
Haskell Communities Activities Report
http://tinyurl.com/haskcar
Submission deadline: this weekend
(please
I think this book may have been mentioned before, Functional
programming: practice and theory by MacLennan, Bruce J gives a
fundamental idea of what it's all about. :)
On Wed, Apr 27, 2011 at 4:28 AM, Christopher Svanefalk
christopher.svanef...@gmail.com wrote:
First, thanks to everyone for
Thank you -- I will try your spreadsheet package for sure, and when I have
more expertise in this area I'd be happy to contribute to the wiki.
On Wed, Apr 27, 2011 at 3:00 AM, Henning Thielemann
schlepp...@henning-thielemann.de wrote:
Eric Rasmussen schrieb:
Also, in the spirit of this
Hi Haskellers,
I'm currently serializing / unserializing a bunch of bytestrings
which are somehow related to each others and I'm wondering if
there was a way in Haskell to ease my pain.
The first thing I'm looking for, is to be able to automatically
derive Serializable objects, for example:
On Wed, 2011-04-27 at 20:16 +0200, John Obbele wrote:
Hi Haskellers,
I'm currently serializing / unserializing a bunch of bytestrings
which are somehow related to each others and I'm wondering if
there was a way in Haskell to ease my pain.
The first thing I'm looking for, is to be able
John Meacham's DrIFT tool used to get extended faster than GHC for
things that should be automatic. I'm not sure of its current status,
though:
http://repetae.net/computer/haskell/DrIFT/
For your second problem, something like this:
getAB :: Get (Either A B)
getAB = do
len - getWord16be
On Wed, Apr 27, 2011 at 6:07 AM, Jerzy Karczmarczuk
jerzy.karczmarc...@unicaen.fr wrote:
Thomas Davie wrote:
This completely misses what laziness gives Haskell – it gives a way of
completing a smaller number of computations than it otherwise would have to
at run time. (...)
Tony Morris
On Wed, Apr 27, 2011 at 11:16 AM, John Obbele john.obb...@gmail.com wrote:
Hi Haskellers,
I'm currently serializing / unserializing a bunch of bytestrings
which are somehow related to each others and I'm wondering if
there was a way in Haskell to ease my pain.
The first thing I'm looking
On 27 April 2011 21:28, Alexander Solla alex.so...@gmail.com wrote:
On Wed, Apr 27, 2011 at 11:16 AM, John Obbele john.obb...@gmail.com wrote:
Second issue, I would like to find a way to dispatch parsers. I'm
not very good at expressing my problem in english, so I will use
another code
Alexander Solla comments my comment :
Alright, my turn. I never wanted to write non-terminating programs
(what for?),
Daemons/servers/console interfaces/streaming clients?
Come on, not THIS kind of non-termination. This has little to do with
strictness/laziness, I think. Endless
so, as a n00b to haskell i can't say much about its laziness, and not
knowing much about how python works i'm about the same there. though i do
know ruby, and afaik ruby doesn't _care_ what type something is, just if it
can do something. example from the rails framework:
#---
class NilClass
On 11-04-27 05:30 AM, Henning Thielemann wrote:
I like to apply for the quote of the week. :-)
If Haskell is great because of its laziness,
then Python must be even greater,
since it is lazy at the type level.
Using Data.Dynamic, Haskell has a story for laziness at the type level, too.
On 26/04/2011 12:17, Malcolm Wallace wrote:
On 25 Apr 2011, at 11:13, Andrew Coppin wrote:
On 24/04/2011 06:33 PM, Jason Dagit wrote:
This is because of a deliberate choice that was made by David Roundy.
In darcs, you never have multiple branches within a single darcs
repository
Good thing I didn't send too soon this time:)
On Tuesday 26 April 2011 02:00:32, jutaro wrote:
Please try to run Leksah with the default config
(~/.leksah-0.10/packageSources)
Indeed leksah may use more memory on the first run (actually it is ghc,
which uses it).
But on consecutive
Welcome to issue 179 of the HWN, a newsletter covering developments in
the Haskell community. This release covers the week of April 16 to 23, 2011.
Announcements
Alex Mason announced (http://goo.gl/2qtyM) the second annual
Australian Haskell Hackathon to be heald from Friday July 8th
Now that GHC has a git
repositoryhttp://hackage.haskell.org/trac/ghc/wiki/Repositories,
could that change be reflected in the docshttp://www.haskell.org/ghc/download
?
It's hard to work with folks on Trac to debug GHC when I can't find the
latest version (changesets are now git, not svn).
Perhaps the linker ran out of memory.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
34 matches
Mail list logo
