Hi,
Am Sonntag, den 24.02.2013, 18:41 + schrieb Tom Ellis:
On Sun, Feb 24, 2013 at 07:12:24PM +0100, Joachim Breitner wrote:
You should try:
million :: () - Int
million _ = 10 ^ (6 :: Int)
many :: () - [Int]
many x = [1..million x]
Thanks Joachim, but that doesn't work
Hi,
Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman:
Quite a while back, Simon Hengel and I put together a proposal[1] for
a new feature in GHC. The basic idea is pretty simple: provide a new
pragma that could be used like so:
error :: String - a
errorLoc :: IO Location -
On Mon, Feb 25, 2013 at 09:57:04AM +0100, Joachim Breitner wrote:
Hi,
Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman:
Quite a while back, Simon Hengel and I put together a proposal[1] for
a new feature in GHC. The basic idea is pretty simple: provide a new
pragma that
On Mon, Feb 25, 2013 at 11:13 AM, Simon Hengel s...@typeful.net wrote:
On Mon, Feb 25, 2013 at 09:57:04AM +0100, Joachim Breitner wrote:
Hi,
Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman:
Quite a while back, Simon Hengel and I put together a proposal[1] for
a new
Hi,
Am Montag, den 25.02.2013, 10:13 +0100 schrieb Simon Hengel:
On Mon, Feb 25, 2013 at 09:57:04AM +0100, Joachim Breitner wrote:
Hi,
Am Montag, den 25.02.2013, 08:06 +0200 schrieb Michael Snoyman:
Quite a while back, Simon Hengel and I put together a proposal[1] for
a new feature
Immediately, the alternative of introducing bound variables in the
environment that is available to rewrite rules comes to mind as a more
general way of doing this.
So this example from the GHC docs:
{-# RULES
map/mapforall f g xs. map f (map g xs) = map (f.g) xs
map/append forall f xs
On 25/02/13 07:06, Michael Snoyman wrote:
Quite a while back, Simon Hengel and I put together a proposal[1] for a new
feature in GHC. The basic idea is pretty simple: provide a new pragma that could
be used like so:
error :: String - a
errorLoc :: IO Location - String - a
{-#
There are lots of Haskell CSV parsers out there. Most have poor
error-reporting, and do not scale to large inputs. I am pleased to announce an
industrial-strength library that is robust, fast, space-efficient, lazy, and
scales to gigantic inputs with no loss of performance.
On 02/25/2013 10:47 AM, Malcolm Wallace wrote:
There are lots of Haskell CSV parsers out there. Most have poor
error-reporting, and do not scale to large inputs. I am pleased to announce an
industrial-strength library that is robust, fast, space-efficient, lazy, and
scales to gigantic
On 25 Feb 2013, at 11:14, Oliver Charles wrote:
Obvious question: How does this compare to cassava? Especially cassava's
Data.CSV.Incremental module? I specifically ask because you mention that it's
It is lazier, faster, more space-efficient, and more flexible in its
treatment of errors,
On 25 February 2013 21:47, Malcolm Wallace malcolm.wall...@me.com wrote:
There are lots of Haskell CSV parsers out there. Most have poor
error-reporting, and do not scale to large inputs. I am pleased to announce
an industrial-strength library that is robust, fast, space-efficient, lazy,
On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote:
I think there is no need to have a separate REWRITE_WITH_LOCATION
rule. What if the compiler instead rewrites 'currentLocation' to the
current location? Then you'd just define the rule:
{-# REWRITE errorLoc error = errorLoc
Package dependencies are modelled by a relation A depends-on B.
Shouldn't this in fact be two relations:
API-depends-on and implementation-depends-on?
(meaning that A API-depends-on B
iff some type of B is visible to the user of A)
So what we currently have is implementation-depends-on
Hi Alexander,
Am 25.02.2013 06:52, schrieb Alexander V Vershilov:
Can you describe if there any difference with latest conduit API
(yield, await) that can be
used to write functions in a very similar style, but without using
exeternal packages:
I have indeed written this library for the 0.5.6
Thanks for explanation.
However I'm still confused as if I'll use one of protocols (protobuf, json,
sereal message, binary message) all of them has
iteration interface i.e. function of type (ByteString - Result a) that
returns
data Result = Error Text ByteString | NeedMore (ByteString - Result a)
On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel s...@typeful.net wrote:
On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote:
I think there is no need to have a separate REWRITE_WITH_LOCATION
rule. What if the compiler instead rewrites 'currentLocation' to the
current
All,
In order to implement some network protocol clients recently, I needed
binary serialization of commands and deserialization of responses
('Command - ByteString' and 'ByteString - Response' functions,
preferably for both strict as well as lazy ByteStrings).
My go-to packages have always been
On Mon, Feb 25, 2013 at 2:15 PM, Alexander Kjeldaas
alexander.kjeld...@gmail.com wrote:
On Mon, Feb 25, 2013 at 12:46 PM, Simon Hengel s...@typeful.net wrote:
On Mon, Feb 25, 2013 at 10:40:29AM +0100, Twan van Laarhoven wrote:
I think there is no need to have a separate
On 25/02/13 13:41, Michael Snoyman wrote:
At that point, we've now made two changes to REWRITE rules:
1. They can takes a new ALWAYS parameters.
2. There's a new, special identifier currentLocation available.
What would be the advantage is of that approach versus introducing a single new
2013/2/25 Michael Snoyman mich...@snoyman.com
At that point, we've now made two changes to REWRITE rules:
1. They can takes a new ALWAYS parameters.
2. There's a new, special identifier currentLocation available.
What would be the advantage is of that approach versus introducing a
single
Of course you don't have to use my library if your library already
solves the same problem.
Am 25.02.2013 13:10, schrieb Alexander V Vershilov:
data Result = Error Text ByteString | NeedMore (ByteString - Result a)
| HaveResult a
I still see an issue with this if you're receiving multiple
On Mon, Feb 25, 2013 at 12:50 PM, Johannes Waldmann
waldm...@imn.htwk-leipzig.de wrote:
Package dependencies are modelled by a relation A depends-on B.
Shouldn't this in fact be two relations:
API-depends-on and implementation-depends-on?
(meaning that A API-depends-on B
iff some type
My initial thought as I read the proposal was to represent currentLocation
as a lexical bound variable, thus error is rewritten to the expression:
let currentLocation = someplace.hs:123
in errorLoc currentLocation
there is no referntial transparency issue in that because there is no
global
Hi, everyone,
In order to merge two type-level key-value pairs
(More specifically, to use TypeNats branch of unittyped:
https://bitbucket.org/xnyhps/haskell-unittyped/commits/all/tip/branch%28%22TypeNats%22%29
)
I'd like to use overlapping type families and the type level Naturals
at the same
I’m afraid the rewrite-rule idea won’t work. RULES are applied during
optimisation, when tons of inlining has happened and the program has been
shaken around a lot. No reliable source location information is available there.
See http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack; and
Alexander Kjeldaas alexander.kjeldaas at gmail.com writes:
There's a third relation, A API-ABI-depends-on B
iff some type of B is used in the hidden binary representation
that is used in backing the API visible to A.
Yes. Does this hold in the example I mentioned?
I think the only
One question - and sorry that I didn't get a chance to try some examples myself
- but can bi-directional conversations be carried between server/client in
interleaving fashion using your library? Something like (simplified):
myClient = receive = send . compute
I have previously accomplished
* Petr Pudlák petr@gmail.com [2013-02-25 14:02:28+0100]
2013/2/25 Michael Snoyman mich...@snoyman.com
At that point, we've now made two changes to REWRITE rules:
1. They can takes a new ALWAYS parameters.
2. There's a new, special identifier currentLocation available.
What
On Sun, Feb 24, 2013 at 02:33:55PM +, Niklas Hambüchen wrote:
You are right, my ghc-7.4.2 was broken in ghc-pkg list; I fixed the
problem by killing my .cabal folder (as so often).
Surely you mean by killing your .ghc folder? I do not see what effect
killing your .cabal folder could
On Mon, Feb 25, 2013 at 9:42 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
One idea I had, which that page does not yet describe, is to have an
implicit parameter,
something like ?loc::Location**
+1
Implicit params has a bad rap in some circles because of counterintuitive
behavior when
Yep, I usually kill ~/.ghc and ~/.cabal for this kind of reset.
On Mon 25 Feb 2013 16:56:56 GMT, Brent Yorgey wrote:
On Sun, Feb 24, 2013 at 02:33:55PM +, Niklas Hambüchen wrote:
You are right, my ghc-7.4.2 was broken in ghc-pkg list; I fixed the
problem by killing my .cabal folder (as so
On Mon, Feb 25, 2013 at 4:42 PM, Simon Peyton-Jones
simo...@microsoft.comwrote:
I’m afraid the rewrite-rule idea won’t work. RULES are applied during
optimisation, when tons of inlining has happened and the program has been
shaken around a lot. No reliable source location information is
On Mon, Feb 25, 2013 at 4:30 AM, Nicolas Trangez nico...@incubaid.comwrote:
- cereal supports chunk-based 'partial' parsing (runGetPartial). It
looks like support for this is introduced in recent versions of 'binary'
as well (runGetIncremental)
Yes. Binary now support an incremental
On Monday, February 25, 2013 at 2:59 PM, Johan Tibell wrote:
On Mon, Feb 25, 2013 at 4:30 AM, Nicolas Trangez nico...@incubaid.com
(mailto:nico...@incubaid.com) wrote:
- cereal supports chunk-based 'partial' parsing (runGetPartial). It
looks like support for this is introduced in recent
Malcolm Wallace malcolm.wall...@me.com writes:
Simple answer - I have never heard of cassava, and suspect it did not exist
when I first did the benchmarking. I'd be happy to re-do my performance
comparison, including cassava and any other recent-ish CSV libraries, if I
can find them.
I
I'd also like to point to a couple of CSV libraries I released a long time ago
and have been maintaining that both target constant-space operation and try
(and hope) for the best in terms of speed. I'd be very interested to know how
they fare in terms of performance benchmarking:
Latest, based
Cassava is quite new, but has the same goals as lazy-csv.
Its about a year old now -
http://blog.johantibell.com/2012/08/a-new-fast-and-easy-to-use-csv-library.html
I know Johan has been working on the benchmarks of late - it would be very
good to know how the two compare in features
On Feb 25,
On Mon, Feb 25, 2013 at 2:32 PM, Don Stewart don...@gmail.com wrote:
Cassava is quite new, but has the same goals as lazy-csv.
Its about a year old now -
http://blog.johantibell.com/2012/08/a-new-fast-and-easy-to-use-csv-library.html
I know Johan has been working on the benchmarks of late -
On Mon, Feb 25, 2013 at 11:59 AM, Johan Tibell johan.tib...@gmail.comwrote:
There are some blog posts and comments out there about merging cereal
and binary, is this what's the goal/going on (cfr runGetIncremental)?
It's most definitely the goal and it's basically done. The only thing I
On Mon, Feb 25, 2013 at 4:51 PM, Alexander Solla alex.so...@gmail.comwrote:
On Mon, Feb 25, 2013 at 11:59 AM, Johan Tibell johan.tib...@gmail.comwrote:
There are some blog posts and comments out there about merging cereal
and binary, is this what's the goal/going on (cfr runGetIncremental)?
On Mon, 2013-02-25 at 00:28 -0500, Dan Cross wrote:
Why go to all that bother? Why not just write code that writes out
the path you want to take and link against it?
{shrug} You could do that too.
I spent a decade doing work in Java-land, a language where by design we
*didn't* have
That sounds reasonable. If someone sends a pull request Lennart or I will
review and merge it.
Doesn't binary already have it?
http://hackage.haskell.org/packages/archive/binary/0.6.4.0/doc/html/Data-Binary.html#g:3
On 26 February 2013 05:06, Johan Tibell johan.tib...@gmail.com wrote:
On
Hello,
I haven't merged the type-nats branch with GHC master recently, so some of
the libraries probably moved forward, which could be the source of the
problem. I'll make sure to fix it over the next couple of days.
-Iavor
On Mon, Feb 25, 2013 at 6:39 AM, Takayuki Muranushi
Thank you Iavor! I'm looking forward for the update.
Takayuki
2013/2/26 Iavor Diatchki iavor.diatc...@gmail.com:
Hello,
I haven't merged the type-nats branch with GHC master recently, so some of
the libraries probably moved forward, which could be the source of the
problem. I'll make sure
44 matches
Mail list logo
