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 Ha
"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 man
"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
bject: 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
large code bases for
alternative purposes (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#]
|
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
| 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 complicate
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 g
"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 (particula
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#.
"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
"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 o
> > ... 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 thin
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
ROTECTED]]
Sent: 30 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 librarie
nd ML have 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 wi
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 li
> 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 57017
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
Hudak [mailto:[EMAIL PROTECTED]]
Sent: 30 May 2002 14:12
To: [EMAIL PROTECTED]
Subject: [Fwd: F#]
Hey Simon et al at Micro$oft, when will there be an H#?
(Ok, I'll settle for Haskell.NET :-)
-Paul
___
Haskell mailing list
[EMAIL PROTECTED]
http:
Hey Simon et al at Micro$oft, when will there be an H#?
(Ok, I'll settle for Haskell.NET :-)
-Paul
--- Begin Message ---
Title: Message
Paul, I just saw this,
and I think you and I were talking about using ML. Let me know if we need
to follow-up on this further.
Scott
21 matches
Mail list logo
