On 2019-12-16 1:42 a.m., Viktor Dukhovni wrote:
Not sure where to post about this, and it has likely been noted
elsewhere already, but reading through the report I see in Section
3.17.2
I'm not sure either, but one place you could report it is at
https://github.com/haskell/rfcs/issues
No
On 2019-04-29 3:54 a.m., 佐藤玄基 wrote:
Hello,
I found that the layout interpretation algorithm in Section 10.3 of
Report 2010
produces parse-error when applied to the following code snippet:
[Snippet 1 : The code that fails to be parsed by Report]
main = print t where { t = s where s = 1 ::
On 2019-04-19 12:40 a.m., Gershom B wrote:
I don’t really have a stake in what happens to it. In my opinion at
the very least the domain should point somewhere where there’s a
redirect in place to the old content, or some pointer to it, so links
don’t die :-)
I, for one, was looking up the
On 2019-04-06 10:36 p.m., Solomon Ucko wrote:
In the Haskell 1998 & 2010 reports, I found the names of the tokens for
Haskell's lexical structure / syntax / grammar very hard to read, as
they were highly abbreviated. I might get more familiar with them, but
that doesn't help newcomers, like me
Jan 2019, 8:01 pm Mario Blažević <mailto:mblaze...@stilo.com> wrote:
A month passed since the last call, and I'm sorry to say that the
Applicative/Monad proposal has been rejected. Herbert has vetoed it on
the grounds that it doesn't come packaged with MonadFail and
MonadOfNo
A month passed since the last call, and I'm sorry to say that the
Applicative/Monad proposal has been rejected. Herbert has vetoed it on
the grounds that it doesn't come packaged with MonadFail and
MonadOfNoReturn proposals.
This is very unfortunate because (I thought) there was finally a
On 2018-12-18 7:25 p.m., Doug McIlroy wrote:
I am very glad to see Applicative take its place in the
report: one less mystery in understanding Haskell in the
wild. The following comments pertain to presentation.
Thank you for the comments. I will act on them if we end up accepting
the
On 2018-12-18 2:38 a.m., Herbert Valerio Riedel wrote:
Hello Mario et al.,
On Tue, Dec 18, 2018 at 4:17 AM Mario Blažević wrote:
While you're reviewing AMP, please take a bit of time to also comment on
the related new MonadPlus excise proposal at
https://github.com/haskell/rfcs/pull/23
While you're reviewing AMP, please take a bit of time to also comment on
the related new MonadPlus excise proposal at
https://github.com/haskell/rfcs/pull/23
The proposal is very short so it should be an easy decision. Thank you.
On 2018-12-15 6:46 p.m., Mario Blažević wrote:
The very first
The very first RFC created (https://github.com/haskell/rfcs/pull/1), the
Applicative/Monad Proposal, has now reached the Last Call stage. In
order to ground the discussion, I have taken some time to update the
Prelude and the text of the Haskell Report with its effects before the
call. The
On 2018-11-28 2:17 a.m., Jurriaan Hage wrote:
Dear all,
We’ve been active since September making the Helium compiler more Haskell 2010
compliant.
In particular, we have a branch with support for Haskell 2010 type classes, a
branch that
supports import/export following the standard, and a
Break out the champagne, because the first Haskell 2020 proposal
has been fully merged [1]. By fully merged, I mean that the text of the
report has been updated, so we have accomplished something material.
Should the Haskell 2020 commitee agree so, we now have the option to
declare the
-minute objection or
amendment to the proposal.
On 2018-11-04 8:31 p.m., Mario Blažević wrote:
I hereby officially announce that the RFC for the relaxed dependency
analysis (https://github.com/haskell/rfcs/pull/17) has attained the
rarefied status of Last Call. Please take some time within
I hereby officially announce that the RFC for the relaxed dependency
analysis (https://github.com/haskell/rfcs/pull/17) has attained the
rarefied status of Last Call. Please take some time within the following
two weeks to vote for or against the proposal, or just leave a comment
to indicate
Four weeks having passed since the previous discussion with no
objections, I have now merged the content of the Haskell Report
from https://github.com/haskell/haskell-report
into https://github.com/haskell/rfcs
To remind everybody again, the point of this move was to enable
adding an
On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:
I think the difficulty has always been in finding enough people who are
* Well-informed and well-qualified
* Willing to spend the time to standardise language features
GHC does not help the situation: it's a de-facto standard, which reduces the
On 2018-10-05 09:10 AM, Henrik Nilsson wrote:
Hi,
On 10/05/2018 01:20 PM, Mario Blažević wrote:
I hereby propose we formally disband the present Haskell 2020
committee. Our performance has been so dismal
It has.
And I should apologise in particular: I've just had far less time than
I
On 2018-10-04 09:41 PM, Anthony Clayden wrote:
> There was no Haskell 2020 meeting this year at ICFP. Sadly, interest
seems to have waned here...
Yes that is sad. So either Haskell 2020 won't happen, or it'll be only
minor tweaks over H2010, as that was over H98.
The former seems much more
Related to this, whatever happened to the fully-agreed task of copying
the Haskell report LaTeX files over to the RFCs repository?
https://mail.haskell.org/pipermail/haskell-prime/2017-September/004319.html
https://mail.haskell.org/pipermail/haskell-prime/2017-October/thread.html
:39, Mario Blažević <blama...@ciktel.net> wrote:
On 2017-09-09 09:40 AM, Herbert Valerio Riedel wrote:
Long story short, is everyone ok to stay with (La)TeX, or is there some
compelling reason that would justify migrating to a different
documentation system?
Since nobody said no in the 7
On 2017-09-09 09:40 AM, Herbert Valerio Riedel wrote:
Long story short, is everyone ok to stay with (La)TeX, or is there some
compelling reason that would justify migrating to a different
documentation system?
Since nobody said no in the 7 weeks since, I think it's safe to assume
yes. Can we
On 2017-08-25 06:48 PM, Carter Schonwald wrote:
I'll be this time! :)
We should coord a committee catch-up at icfp.
Also I would like to propose we shift back to email based discussion.
There's still the valid and important need of then taking the
discussion and revisions into a new
On 2017-05-24 10:28 AM, Joachim Breitner wrote:
I've ended up uncertain, so I'll just throw it out there: are unused
value warnings affected by this proposal?
that is a very good point, thanks for raising it. I have two different
answers:
A) You are right. Everything is exported, so without
On 19/05/17 07:12 PM, Francesco Ariis wrote:
On Fri, May 19, 2017 at 06:32:30PM -0400, Joachim Breitner wrote:
I thought about this. But I fear that this will require a language
extension or flag, and then the developers (quite rightly) say that it
does not pull its weight of supporting both
On 2017-05-16 10:18 AM, Joachim Breitner wrote:
Hi,
a very small proposal to be considered for Haskell':
I like it, but it should probably be a GHC proposal first. I don't
think Haskell' is supposed to make any change to the standard that
hasn't been already implemented and tested. In this
On 2016-12-21 02:04 PM, David Feuer wrote:
In the Old Days (some time before Haskell 98), `seq` wasn't fully
polymorphic. It could only be applied to instances of a certain class.
I don't know the name that class had, but let's say Seq. Apparently,
some people didn't like that, and now it's
On 2016-10-12 12:41 PM, Iavor Diatchki wrote:
Hello,
it seems that there isn't much controversy over the TupleSections
propsal, so I'd like to move the we accept it for the next language
standard.
Does anyone have any objections?
I have no objection to the proposal in the abstract, but I
On 2016-10-04 01:09 PM, Iavor Diatchki wrote:
Hello,
Now that we've started with a few proposal, I am realizing that I have
no idea how to proceed from here. In particular:
1. How would I request I proposal to be rejected
2. How would I request that a proposal be accepted
I don't know if
On 2016-09-14 02:17 PM, José Manuel Calderón Trilla wrote:
Richard has also volunteered to act as secretary for the meeting so
that the minutes of the meeting can be posted. Thanks Richard!
Thanks from all of us who can't attend as well. Please do post the minutes!
On 04/29/2016 07:15 AM, Francesco Ariis wrote:
Hello,
personally I would be more likely to read/participate in the
discussions if such discussions were hosted here or on Trac rather
than Github.
There are two or three distinct components we need to keep track
of: the draft standard,
On 15-10-22 09:29 AM, Geoffrey Mainland wrote:
...
1) What is the master plan, and where is it documented, even if this
document is not up to the standard of a proposal? What is the final
target, and when might we expect it to be reached? What is in the
pipeline after MRP?
Relatedly, guidance
I'm hereby self-nominating for the Haskell' commitee. The main reason
I'm applying is because I'm afraid that the commitee might disband like
the previous one. If there are enough members already, feel free to
ignore my nomination.
That being said, here are my qualifications:
I started
On 14-10-21 07:14 AM, Erik Hesselink wrote:
On Mon, Oct 20, 2014 at 11:57 PM, Mario Blažević mblaze...@stilo.com wrote:
On 14-10-19 08:10 AM, Erik Hesselink wrote:
Adding an explicit
import can suddenly cause type errors in completely unrelated places
(when it hides an implicit import
On 14-10-19 08:10 AM, Erik Hesselink wrote:
I feel that this extension, while looking tempting for writing code
from scratch, might hurt maintainability of code.
That depends on how you define maintainability.
Adding an explicit
import can suddenly cause type errors in completely
On 09/29/13 08:20, Edward Kmett wrote:
I don't know that it belongs in the standard libraries, but there
could definitely be a package for something similar.
ConstraintKinds are a pretty hefty extension to throw at it, and the
signature written there prevents it from being used on ByteString,
On 09/13/13 01:51, Michael Snoyman wrote:
On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević blama...@acanac.net
mailto:blama...@acanac.net wrote:
On 09/11/13 19:37, John Lato wrote:
3. I'm not entirely sure that the length* functions belong
here. I
understand why
On 09/13/13 02:28, Michael Snoyman wrote:
On Fri, Sep 13, 2013 at 9:18 AM, Mario Blažević blama...@acanac.net
mailto:blama...@acanac.net wrote:
On 09/13/13 01:51, Michael Snoyman wrote:
On Fri, Sep 13, 2013 at 5:38 AM, Mario Blažević
blama...@acanac.net
On 09/11/13 19:37, John Lato wrote:
I didn't see this message and replied privately to Michael earlier, so
I'm replicating my comments here.
1. Sooner or later I expect you'll want something like this:
class LooseMap c el el' where
lMap :: (el - el') - c el - c el'
It covers the case of
On 09/02/13 06:53, Nicolas Trangez wrote:
# Redirected to haskell-cafe
On Sun, 2013-09-01 at 14:58 +0400, Artyom Kazak wrote:
Would this be an appropriate place to propose adding mapM_ (and then
possibly mapM) to bytestring library?
Was it suggested before? If yes, why was it rejected?
This
On 13-08-22 04:04 PM, Petr Pudlák wrote:
Or, if there are no such definitions, where would be a good place to add
them?
If they are to be added to the base libraries, the Data.Monoid module
would be my choice.
I did wish I had the AppMonoid instance on several occasions, when
using
See also this thread from two years ago:
http://www.haskell.org/pipermail/haskell-cafe/2011-June/091294.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
The new package monoid-subclasses [1] exports a number of classes
that sit between monoids and groups: ReductiveMonoid,
CancellativeMonoid, GCDMonoid, MonoidNull, and FactorialMonoid among
others. The package also comes with class instances for all applicable
data types from base, vector,
On 13-03-11 10:52 PM, Michael Orlitzky wrote:
On 03/11/2013 11:48 AM, Brent Yorgey wrote:
So I'd like to do it again this time around, and am looking for
particular projects I can suggest to them. Do you have an open-source
project with a few well-specified tasks that a relative beginner (see
On 13-03-12 04:47 AM, Joachim Breitner wrote:
...
None of these look particularly appealing. Here some ideas to make it
more convenient for the programmer that require changes to GHC and how
it treats packages:
I. It automatically imports _all_ visible Prelude modules. So
On 13-01-26 05:28 AM, Erik de Castro Lopo wrote:
Thiago Negri wrote:
Do you need advice on what? I didn't understand your last phrase.
Well I have data from two sources, stdin and the calculation
thread. If I was doing this in C, I'd probably use a pipe for the
calculation data and then do
On 12-12-30 02:55 PM, Conal Elliott wrote:
Is there a way to suppress GHC's Duplicate constraints warning? I'm
auto-generating some code, and it's a lot more convenient for me to
leave the duplicates than filter them out.
I second the question. In my case the code is neither generated nor
On 12-09-26 08:07 PM, wren ng thornton wrote:
On 9/25/12 1:57 PM, Sjoerd Visscher wrote:
Maybe we could make a literal [a,b,c] turn into
unpack [a,b,c]#
where
[a,b,c]#
is a statically-allocated vector?
I'm kinda surprised this isn't already being done. Just doing this seems
like it'd
On 12-09-18 07:37 PM, Richard O'Keefe wrote:
On 19/09/2012, at 1:43 AM, Stefan Monnier wrote:
The problem with that is that some people DO end some headings with
a full stop; for them your special syntax is not natural.
Markdown/ReST is already using the no syntax idea (e.g. compared to
On 12-08-15 02:54 PM, Daniel Hlynskyi wrote:
Hello Cafe.
Consider code, that takes input from handle until special substring
matched:
matchInf a res s | a `isPrefixOf` s = reverse res
matchInf a res (c:cs) = matchInf a (c:res) cs
hTakeWhileNotFound str hdl = hGetContents
On 12-05-22 09:55 AM, Benjamin Ylvisaker wrote:
Has anyone ever worked on implementing something like this in Haskell?
http://www.cs.hmc.edu/~stone/papers/ocm-unpublished.pdf
The outline of the idea:
- Concurrent programming is really hard with the popular frameworks
today.
- For most
On 12-04-07 05:35 PM, Myles C. Maxfield wrote:
So here are my questions:
...
3. Are there any parsers that support streaming semantics and being
used as a monad transformer? This would require rewriting my whole
program to use this new parser, but if that's what I have to do, then
so be it.
On 12-03-11 09:09 AM, Paolo Capriotti wrote:
The Category law would be broken, though:
unawait x id == yield x !== unawait x
How did you get this equation? It's not even well-typed:
unawait :: a - Pipe a b m ()
yield :: b - Pipe a b m ()
You're right, it's completely wrong. I was
On 12-03-11 12:39 PM, Chris Smith wrote:
On Sun, Mar 11, 2012 at 10:30 AM, Mario Blaževićblama...@acanac.net wrote:
(p1 unawait x) p2 = (p1 p2)* unawait x -- this one
tripped me up
I don't think this could reasonably hold. For example, you'd expect
that for any p, idP p == idP
On 12-03-11 01:36 PM, Chris Smith wrote:
On Sun, Mar 11, 2012 at 11:22 AM, Mario Blaževićblama...@acanac.net wrote:
No, idP does terminate once it consumes its input. Your idP p first
reproduces the complete input, and then runs p with empty input.
This is just not true. idP consumes
On 12-03-10 05:16 AM, Paolo Capriotti wrote:
On Sat, Mar 10, 2012 at 4:21 AM, Mario Blaževićblama...@acanac.net wrote:
I like your design, it seems to strike a good balance between elegance
and practicality. The only thing missing for the latter is a deeper support
for chunking. Of course,
On 12-03-10 05:19 PM, Twan van Laarhoven wrote:
On 2012-03-10 11:16, Paolo Capriotti wrote:
Another issue is how to deal with unconsumed input. For that, there is
a ChunkPipe type (in pipes-extra) with a specialized monad instance
that threads unconsumed input along. You can see an example of
On 12-03-10 09:05 PM, Twan van Laarhoven wrote:
On 2012-03-11 00:09, Mario Blažević wrote:
On 12-03-10 05:19 PM, Twan van Laarhoven wrote:
-- | Pass some unconsumed input back upstream.
-- The next @await@ will return this input without blocking.
unawait :: Monad m = a - Pipe a b m
On 12-03-09 07:36 PM, Paolo Capriotti wrote:
I'm pleased to announce the release of version 0.0.1 of pipes-core, a
library for efficient, safe and compositional IO, similar in scope to
iteratees and conduits.
I like your design, it seems to strike a good balance between
elegance and
On 12-02-13 10:12 AM, Roel van Dijk wrote:
Hello,
I have a program which I believe can benefit from concurrency. But I
am wondering if the mechanisms I need already exist somewhere on
Hackage.
You can try monad-coroutine. Here is an incomplete transcription of
your code:
import
On 12-01-28 06:56 AM, Felipe Almeida Lessa wrote:
On Sat, Jan 28, 2012 at 9:40 AM, Yves Parèsyves.pa...@gmail.com wrote:
I think there is still no consensus on which iteratee library is the one
to use. There are at least iteratee, enumerator, iterIO, conduit, and
pipes. The reusability of your
On 11-09-05 10:42 AM, Sjoerd Visscher wrote:
This way these laws hold for non-empty lists:
maximumBy f xs = last (sortBy f xs)
minimumBy f xs = head (sortBy f xs)
That's not a bad justification for the way implementation works,
even if it's not the original reason behind it. I think
I was recently surprised to discover that the maximum and maximumBy
functions always return the *last* maximum, while minimum and minimumBy
return the *first* minimum in the list. The following GHCi session
demonstrates this:
$ ghci
GHCi, version 7.2.1: http://www.haskell.org/ghc/ :? for
For anybody interested in programming languages or markup languages,
there is an open job position for a junior developer at Stilo
(http://www.stilo.com/). Haskell is currently used only for prototyping,
but there are plans to begin some major development in Haskell within a
year.
The job
On 11-06-20 10:45 AM, Richard Senington wrote:
Hi all,
I have recently become interested in Dataflow programming and how it
related to functional languages.
I am wondering if the community has any advice on reading matter or
other directions to look at.
So far I have been looking through
On 11-06-09 04:14 PM, Alexander V Vershilov wrote:
Hello.
I'm writing a small tcp server with that can handle connections and
answer by rules writen in a small script that can be interpreted by server.
For this purpose I've written an interpreter that has type
ErrorT MyError (StateT
On 11-06-03 06:00 AM, Yitzchak Gale wrote:
Mario Blažević wrote:
I don't know if this helps, but the incremental-parser library has
exactly the combinator you're looking for.
Wow, that is a beautiful implementation of a general parser
library. So much simpler than Parsec. Thanks
On Thu, Jun 2, 2011 at 10:02 AM, Yitzchak Gale g...@sefer.org wrote:
I often find while using attoparsec and attoparsec-text that I need to
match a number of text parsers consecutively and concatenate the
result. By text parser I mean Parser ByteString for attoparsec and
Parser Text for
On 11-05-30 05:05 AM, Alexey Khudyakov wrote:
On 30.05.2011 12:26, Bas van Dijk wrote:
On 30 May 2011 00:14, Alexey Khudyakovalexey.sklad...@gmail.com wrote:
It always puzzled me why there are no packages for for testing general
type classes laws. (Monoid laws, monad laws etc). It looks like
On 11-05-25 08:52 AM, Johan Tibell wrote:
On Wed, May 25, 2011 at 2:01 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
With my wl-pprint-text package, Jason Dagit suggested to me on
#haskell that it would make sense to make such a pretty-printer be
class-based so that the same API
On 11-05-06 11:15 AM, Alex Mason wrote:
Hi All,
I really love the look of this package, but if this is going be *the* iteratee
package, I would absolutely love to see it fix some of the biggest mistakes in
the other iteratee packages, soecifically naming. A change in naming for the
terms
On 11-05-06 09:58 PM, dm-list-haskell-c...@scs.stanford.edu wrote:
At Fri, 06 May 2011 21:27:21 -0400,
Mario Blažević wrote:
I'd been thinking about using the terms Source and Sink, but Source is
very overloaded, and SinkSource doesn't exactly roll off the tongue
or evoke a particularly helpful
On 11-03-30 05:29 PM, Mathijs Kwik wrote:
Hi all,
I'm playing around a bit with arrows (more specifically, something
like a CPS style streamprocessor as described in Generalising Monads
to Arrows by John Hughes).
I had struggled with the same problem a year ago, and I concluded it
was
On 11-03-26 12:27 AM, Steven Shaw wrote:
Hi Mario,
I wondered if you had an application in mind for your incremental
parser library in Haskell? A little while ago I was following the
development of an open source text editor for Mac OS X called
Kod[.app]. They were wanting an incremental
On 11-03-26 04:33 PM, John A. De Goes wrote:
I noticed this problem some time ago. Beyond just breaking monadic
associativity, there are many other issues with standard definitions
of iteratees:
1. It does not make sense in general to bind with an iteratee that
has already consumed
Packages monad-parallel [1], monad-coroutine [2] and SCC [3] have been
upgraded on Hackage to version 0.7.
The monad-parallel library defines two Monad subclasses,
MonadParallel and MonadFork, that enable some monadic computations to be
executed in parallel and their results combined. The
The first version of incremental-parser has been released on Hackage
[1]. It's yet another parser combinator
library, providing the usual set of Applicative and Monad combinators. Apart
from this, it has three twists that make it
unique.
First, the parser is incremental. That means it can
This seems very interesting. One question:
The MonadPlus and the Alternative instance differ: the former's mplus
combinator equals the asymmetric | choice.
Why?
Good question. Basically, I see MonadPlus as a union of Monad and
Alternative. The class should not exist at all. But as
exist in two
forms, the lazy one and the greedy one, and the only difference is the
underlying choice combinator, (|) vs. (|).
I'm not aware of any other parsing library taking this road, though, and
there must be a good reason. I'll try and see.
2011/3/22 Mario Blažević mblaze...@stilo.com
On Sun, Mar 20, 2011 at 10:50 AM, Christopher Done chrisd...@googlemail.com
wrote:
On 20 March 2011 15:05, Pieter Laeremans pie...@laeremans.org wrote:
Hi all,
The MIME package that can be found on hackage, uses String as input.
Would i be considered better if there would be a version
The first version of incremental-parser has been released on Hackage
[1]. It's yet another parser combinator
library, providing the usual set of Applicative and Monad combinators. Apart
from this, it has three twists that make it
unique.
First, the parser is incremental. That means it can
This seems very interesting. One question:
The MonadPlus and the Alternative instance differ: the former's mplus
combinator equals the asymmetric | choice.
Why?
Good question. Basically, I see MonadPlus as a union of Monad and
Alternative. The class should not exist at all. But as
exist in two
forms, the lazy one and the greedy one, and the only difference is the
underlying choice combinator, (|) vs. (|).
I'm not aware of any other parsing library taking this road, though, and
there must be a good reason. I'll try and see.
2011/3/22 Mario Blažević mblaze...@stilo.com
I've tried to send the verification e-mail from trac.haskell.org to three
different e-mail accounts in the last 24 hours. None arrived.
Note that I'm not trying to create a new account, I'm trying to verify my
e-mail address in order to edit the Wiki pages of my projects.
Can anybody else
I've sent an e-mail to Haskell Café this morning about my troubles
with Trac confirmation e-mails. The e-mail must have reached the server,
because it showed up in the mailing list archive:
http://www.haskell.org/pipermail/haskell-cafe/2011-March/090311.html
This other archive,
of the module, class and its single
method, and what instances to declare inside the module.
-Edward
On Fri, Dec 24, 2010 at 4:51 AM, Stephen Tetley
stephen.tet...@gmail.comwrote:
On 24 December 2010 02:16, Mario Blažević mblaze...@stilo.com wrote:
To turn the proof obligation around, what could
(Foldable f, Pointed f) = Sequence f
or whatever.
On Fri, Dec 24, 2010 at 4:51 AM, Stephen Tetley stephen.tet...@gmail.comwrote:
On 24 December 2010 02:16, Mario Blažević mblaze...@stilo.com wrote:
To turn the proof obligation around, what could possibly be the downside
of
adding a puny
Why are Cofunctor and Comonad classes not a part of the base library?
I recently defined a data type (Control.Cofunctor.Ticker in
monad-coroutine on Hackage) that happens to be a co-functor, or
contra-functor if you prefer. In other words, it can implement the
following function:
cofmap ::
On Thu, Dec 23, 2010 at 5:25 PM, Stephen Tetley stephen.tet...@gmail.comwrote:
On 23 December 2010 21:43, Mario Blažević mblaze...@stilo.com wrote:
Why are Cofunctor and Comonad classes not a part of the base library?
[SNIP]
Later on I found that this question has been raised before
On Thu, Dec 23, 2010 at 11:25 PM, Tony Morris tonymor...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
...regardless of the utility of a contravariant functor type-class, I
strongly advocate for calling it Contrafunctor and not Cofunctor. I
have seen numerous examples of
On 10-11-14 07:36 PM, Jiansen He wrote:
Hi cafe,
I wounder if it is possible to tell a haskell system that two
computations with side effects could be executed concurrently.
Here is an affected example:
Suppose two people want to compare their age, but do not want to leak
their personal
The newly released coroutine-enumerator package can be used as a bridge
between the enumerator and monad-coroutine packages. It provides two-way
conversion functions between an Iteratee and an Await-suspending coroutine,
and also between an Enumerator and a Yield-suspending coroutine.
As a little
Packages monad-coroutine and SCC have been upgraded to version 0.6 on
Hackage.
The monad-coroutine package exports a generic monad transformer
Coroutine: Functor s = MonadTrans (Coroutine s). A
Coroutine-transformed monad can suspend at any point, returning its
resumption wrapped in the
Packages monad-coroutine and SCC have been upgraded to version 0.6 on
Hackage.
The monad-coroutine package exports a generic monad transformer
Coroutine: Functor s = MonadTrans (Coroutine s). A
Coroutine-transformed monad can suspend at any point, returning its
resumption wrapped in the
The newly released coroutine-enumerator package can be used as a bridge
between the enumerator and monad-coroutine packages. It provides two-way
conversion functions between an Iteratee and an Await-suspending coroutine,
and also between an Enumerator and a Yield-suspending coroutine.
As a little
I had the exact same problem in my regional-pointers package in the
withArray function:
withArray ∷ (Storable α, MonadCatchIO pr)
⇒ [α]
→ (∀ s. RegionalPtr α (RegionT s pr) → RegionT s pr β)
→ pr β
I had to replace the original:
withArray vals =
I had the exact same problem in my regional-pointers package in the
withArray function:
withArray ∷ (Storable α, MonadCatchIO pr)
⇒ [α]
→ (∀ s. RegionalPtr α (RegionT s pr) → RegionT s pr β)
→ pr β
I had to replace the original:
withArray vals =
Before uploading a new version of my project on Hackage, I decided to
future-proof it against GHC 7.0. I ran into several compile errors caused by
the changes in let generalization, but these were easy to fix by adding
extra type annotations. But then I ran into another problem that I can't
Before uploading a new version of my project on Hackage, I decided to
future-proof it against GHC 7.0. I ran into several compile errors caused by
the changes in let generalization, but these were easy to fix by adding
extra type annotations. But then I ran into another problem that I can't
Yves Parès wrote:
It helps me understand better, but would you have some simple code that
would do that ?
You can look at the definition of the coroutine monad transformer in
the monad-coroutine package as well:
http://hackage.haskell.org/package/monad-coroutine
The heart of
Patrick LeBoutillier wrote:
...
Basically I'm looking for a bit of feedback/info:
- Does anyone know if there are already similar projets out there?
You've already got some references, you can also look at
http://hackage.haskell.org/package/scc which includes a shell language.
- Does
1 - 100 of 120 matches
Mail list logo
