On Mon, 13 Aug 2012, Alexander Solla wrote:
On Mon, Aug 13, 2012 at 6:25 PM, Jay Sulzberger wrote:
On Mon, 13 Aug 2012, Ryan Ingram wrote:
On Mon, Aug 13, 2012 at 12:30 PM, Jay Sulzberger wrote:
Does Haskell have a word for "existential type" declaration? I
have the impression,
On Mon, Aug 13, 2012 at 6:25 PM, Jay Sulzberger wrote:
>
>
> On Mon, 13 Aug 2012, Ryan Ingram wrote:
>
> On Mon, Aug 13, 2012 at 12:30 PM, Jay Sulzberger wrote:
>>
>> Does Haskell have a word for "existential type" declaration? I
>>> have the impression, and this must be wrong, that "forall"
On Mon, 13 Aug 2012, Ryan Ingram wrote:
On Mon, Aug 13, 2012 at 12:30 PM, Jay Sulzberger wrote:
Does Haskell have a word for "existential type" declaration? I
have the impression, and this must be wrong, that "forall" does
double duty, that is, it declares a "for all" in some sense like
t
Ryan Ingram gmail.com> writes:
>
>
> When I was implementing a toy functional languages compiler I did away with
precedence declarations by number and instead allowed the programmer to
specify a partial order on declarations; this seems to be a much cleaner
solution and avoids arbitrary prec
I have a data-type that is similar to EitherT, however, I have ordered
the type variables like so:
data EitherT (f :: * -> *) (a :: *) (b :: *) = ...
This allows me to declare some desirable instances:
instance Functor f => Bifunctor (EitherT f)
instance Foldable f => Bifoldable (EitherT f)
inst
On Mon, Aug 13, 2012 at 12:30 PM, Jay Sulzberger wrote:
> Does Haskell have a word for "existential type" declaration? I
> have the impression, and this must be wrong, that "forall" does
> double duty, that is, it declares a "for all" in some sense like
> the usual "for all" of the Lower Predica
On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote:
>
> This isn't that hard - a pipe shouldn't be needed anymore. Just require a
> post-2003 glibc.
>
> fexecve is a system call in most BSDs. It is also implemented in glibc using
> a /proc hack.
fexecve is now in the Single Unix Specific
On Thu, 9 Aug 2012, wren ng thornton wrote:
On 8/8/12 9:41 PM, Jay Sulzberger wrote:
Haskell's type classes look to me to be a provision for declaring
a signature in the sense of the above article.
Just to clarify this in the context of my previous post, type classes define
signatures in
llvm is backend for repa package. Try to install llvm on you system. I
think this can be helpful (
http://llvm.org/releases/3.0/docs/GettingStarted.html ).
Mukesh Tiwari
On Tue, Aug 14, 2012 at 2:47 AM, KC wrote:
> The install of repa-algorithms fails saying it can't cannot find an llvm.
>
>
>
The install of repa-algorithms fails saying it can't cannot find an llvm.
In any case why can't the install syntax be
"cabal install repa.algorithms"
then it would be more consistent with the import statement.
On Sun, Aug 12, 2012 at 4:00 PM, Ivan Lazar Miljenovic
wrote:
> I think you need to
> But it would be in line with <- bindings in the do notation, so maybe it
wouldn't feel so wrong.
I was about to post this exact example.
do
x <- return 1
x <- return x
return x
seems to work just fine (the answer is 1). I'd even be ok with =-in-do
being non-recursive like <-
-- ryan
On Mon, 13 Aug 2012, Johan Holmquist wrote:
That pattern looks so familiar. :) Existential types seem to fit in to the
type system really well so I never got why it is not part of the standard.
On Aug 12, 2012 10:36 AM, "Daniel Trstenjak"
wrote:
Does Haskell have a word for "existential ty
When I was implementing a toy functional languages compiler I did away with
precedence declarations by number and instead allowed the programmer to
specify a partial order on declarations; this seems to be a much cleaner
solution and avoids arbitrary precedences between otherwise unrelated
operator
That pattern looks so familiar. :) Existential types seem to fit in to the
type system really well so I never got why it is not part of the standard.
On Aug 12, 2012 10:36 AM, "Daniel Trstenjak"
wrote:
>
> Hi Oleg,
>
> On Sat, Aug 11, 2012 at 08:14:47AM -, o...@okmij.org wrote:
> > I'd like t
On 13.08.2012 20:26, Till Berger wrote:
Terrible! Quite sorry that this seems to be a bug in the monad-par
library.
I'm copying some of the other monad-par authors and we hopefully can
get to
the bottom of this. If it's not possible to create a smaller reproducer,
is it possible to share the ori
On 13.08.2012 19:43, Ryan Newton wrote:
Terrible! Quite sorry that this seems to be a bug in the monad-par library.
I'm copying some of the other monad-par authors and we hopefully can get
to the bottom of this. If it's not possible to create a smaller
reproducer, is it possible to share the o
Terrible! Quite sorry that this seems to be a bug in the monad-par library.
I'm copying some of the other monad-par authors and we hopefully can get to
the bottom of this. If it's not possible to create a smaller reproducer,
is it possible to share the original test that triggers this problem?
Terrible! Quite sorry that this seems to be a bug in the monad-par library.
I'm copying some of the other monad-par authors and we hopefully can get to
the bottom of this. If it's not possible to create a smaller reproducer,
is it possible to share the original test that triggers this problem?
Quoth Brandon Allbery ,
> On Mon, Aug 13, 2012 at 10:23 AM, Donn Cave wrote:
>
>> Though speaking of platforms, I guess one large headache would be
>> what to do about Microsoft operating systems. Given the unusual
>>
>
> Microsoft provides APIs that work as is for this, by my understanding; it's
On Mon, Aug 13, 2012 at 10:23 AM, Donn Cave wrote:
> Though speaking of platforms, I guess one large headache would be
> what to do about Microsoft operating systems. Given the unusual
>
Microsoft provides APIs that work as is for this, by my understanding; it's
the POSIX fork/exec model that m
On Mon, Aug 13, 2012 at 7:26 AM, Alexander Kjeldaas <
alexander.kjeld...@gmail.com> wrote:
> This isn't that hard - a pipe shouldn't be needed anymore. Just require a
> post-2003 glibc.
>
So, we are desupporting the *BSDs and OS X (and Solaris etc.) now? glibc
is only used on Linux and the Hurd
Quoth Evan Laforge ,
...
> ... or at least make sure the haskell version doesn't suffer from
> problems fixed in the python one.
Exactly. This morning I'm reading suggested solutions that would
work only some of the time, or on only some platforms, which wouldn't
be satisfactory in the long run.
Hi.
I'm pleased to announce the first release of Abacate and Chuchu. Chuchu is
a port of Ruby's Cucumber to Haskell, and Abacate is a parser for the Gherkin
language, used by Cucumber.
According to their web site, "Cucumber lets software development teams describe
how software should behave in p
This isn't that hard - a pipe shouldn't be needed anymore. Just require a
post-2003 glibc.
fexecve is a system call in most BSDs. It is also implemented in glibc
using a /proc hack.
http://www.kernel.org/doc/man-pages/online/pages/man3/fexecve.3.html
Apparently, there are proposals/RFCs to get
In Unix, at least, "check, then act" is generally considered unwise:
1. Something can go wrong between checking and acting.
2. You might not be checking the right thing(s). In this case, the fact
that the file exists is not useful if you don't have permission to execute
it. You may not be able to
On Sun, 2012-08-12 at 23:18 -0700, Evan Laforge wrote:
> Yes, I ran into the same thing a while back. The problem is that the
> subprocess has already been forked off before it runs exec() and finds
> out the file doesn't exist.
Given how astonishingly common it is to pass an invalid executable n
26 matches
Mail list logo
