Don Syme [EMAIL PROTECTED] wrote,
One point is that in the absence of extensive purity
annotations to imperative libraries you will need to use
monads for operations that shouldn't need them. Having to
add the annotations certainly counts as a complication in
comparison to what many other
At 2002-05-31 12:48, Don Syme wrote:
One point is that in the absence of extensive purity annotations to
imperative libraries you will need to use monads for operations that
shouldn't need them.
But these cases are surely quite rare? In my experience, if it really is
pure, chances are
On Fri, 31 May 2002, Manuel M. T. Chakravarty wrote:
I think, the probelm is .NET, not Haskell. .NET just
doesn't deliver on its promise (= marketing hype) of
language neutrality. The problem is that .NET is language
neutral only as long as all languages are sufficiently close
to C#. Not
D. Tweed [EMAIL PROTECTED] wrote,
One of the thoughts behind this was the knowledge that it's just the two
Simons' at Microsoft Cambridge now maintaining/developing GHC; _if it were
possible_ (and I'll quite concede it may not be) to leverage work on .NET
for other purposes (particularly if
I wonder if ghc is the right place to start for
H#/haskell.net / whatever? GHC is a (wonderfully)
complex beast... it seems to have every feature anyone
ever thought to add to haskell (esp in terms of the
type system).
Maybe one should start with haskell98 + ffi or
whatever
you need to add to
| Idle curiosity: which aspects of the Haskell language are the
| ones that make it complicated -- e.g., long-time stuff like
| lazy evaluation, typeclasses inferrence, etc or newer stuff
| like functional dependencies, etc or something else entirely
| -- and do they only make it
On 31-May-2002, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
General remarks about targetting .NET from GHC.
* There is no reason in principle why one can't write a back end
for GHC to generate .NET IL.
* Generating *verifiable* IL is noticeably harder: you have to
take much more
(unless you've got loads of resources to throw at
the problem).
Cheers,
Don
-Original Message-
From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]]
Sent: 31 May 2002 15:31
To: Don Syme; D. Tweed
Cc: Paul Hudak; haskell
Subject: RE: [Fwd: F#]
| Idle curiosity: which aspects
: RE: [Fwd: F#]
Don Syme [EMAIL PROTECTED] wrote,
And getting top-notch performance is obviously always a huge challenge
for Haskell, and you can't play some common implementation tricks when
compiling to IL. But the only truly
Don Syme [EMAIL PROTECTED] writes:
One point is that in the absence of extensive purity annotations to imperative
libraries you will need to use monads for operations that shouldn't need them.
Having to add the annotations certainly counts as a complication in comparison
to what many other
On Thu, 30 May 2002, Don Syme wrote:
going to provide. Given the general complexity of GHC, the longish
compile times and the reliance of the GHC library implementation on C
and C libraries in so many places I decided to implement a simpler
language from scratch. I like the idea that a
Hey Simon et al at Micro$oft, when will there be an H#?
But H# is C! we don't want that, surely? :-)
Jón
--
Jón Fairbairn [EMAIL PROTECTED]
31 Chalmers Road [EMAIL PROTECTED]
Cambridge CB1 3SZ+44 1223
Paul Hudak [EMAIL PROTECTED] writes:
Hey Simon et al at Micro$oft, when will there be an H#?
(Ok, I'll settle for Haskell.NET :-)
There's hugs98.net and it's with us now:
http://galois.com/~sof/hugs98.net/
--sigbjorn
___
Haskell mailing list
their place :-)
Best wishes,
Don
-Original Message-
From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]]
Sent: 30 May 2002 16:21
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [Fwd: F#]
Paul Hudak [EMAIL PROTECTED] writes:
Hey Simon et al at Micro$oft, when will there be an H
May 2002 15:25
To: Don Syme
Cc: Paul Hudak; haskell
Subject: RE: [Fwd: F#]
On Thu, 30 May 2002, Don Syme wrote:
going to provide. Given the general complexity of GHC, the longish
compile times and the reliance of the GHC library implementation on C
and C libraries in so many places I decided
Hi Don --
Thanks for all the informative stuff regarding FP implementations on
.NET. However I am a little surprised by one thing you say:
... But the only truly serious complications added by .NET
itself are (a) the general problem of Haskell interop with imperative
libraries, requiring
... But the only truly serious complications added by .NET
itself are (a) the general problem of Haskell interop with
imperative
libraries, requiring you to reach for monads quite often (or to wrap
the libraries yourself) and (b) ...
IMHO problem (a) will always be the thing that
Don Syme [EMAIL PROTECTED] wrote,
And getting top-notch performance is obviously always a huge challenge
for Haskell, and you can't play some common implementation tricks when
compiling to IL. But the only truly serious complications added by .NET
itself are (a) the general problem of
D. Tweed [EMAIL PROTECTED] wrote,
On Thu, 30 May 2002, Don Syme wrote:
going to provide. Given the general complexity of GHC, the longish
compile times and the reliance of the GHC library implementation on C
and C libraries in so many places I decided to implement a simpler
language
19 matches
Mail list logo
