RE: [Fwd: F#]

[Ashley Yakeley]

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 Haskell can do it by itself and you don't need a 
function in the library to do it.

Perhaps there are exceptions for maths libraries.

It seems to me the simplest thing for foreign libraries is to make all 
calls monadic. Certainly I do this in JVM-Bridge, all raw FFI calls are 
in the IO monad and I don't use "unsafe" anything anywhere. There are no 
particular "pure" Java library functions that are worth making an 
exception for.

-- 
Ashley Yakeley, Seattle WA

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Manuel M. T. Chakravarty]

"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 languages have to do on
> .NET.

That's certainly not a .NET-specific issue and it sounds a
bit like the arguments against statically-typed languages
while everybody else thought that without dynamic typing
languages are too restricted.

> As for monads, this is hardly the place to go into an
> argument about their relative merits re. all those
> slightly more widespread approaches to imperative
> programming.  If you think driving imperative libraries
> using monads will be so great then a Haskell.NET would
> certainly be a perfect place to try out that theory. 

As I said, this is hardly .NET-specific and we have had no
problems with huge libraries, such as GTK+ and HOpenGL.

Manuel
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Fwd: F#]

[Pixel]

"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 languages have to do on .NET.

am I wrong to think that

  would .NET had const'ness a la C++, purity annotations wouldn't be
  needed?

hum, not really. const methods can still modify global state (but not
object state)... but at least no need to annotate non-const methods :)



off topic:
 On the subject of const'ness, I've been messing around with it.
 I've been quite surprised to discover that Java&C# do not have C++'s
 const (Java has "final" on parameters, but it is dumb)

 About this: http://merd.net/inoutness.html 
 (beware, half of it is still investigations)
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Don Syme]

Hi Manuel,
 
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 languages have to do on .NET.  
 
As for monads, this is hardly the place to go into an argument about their relative 
merits re. all those slightly more widespread approaches to imperative programming.  
If you think driving imperative libraries using monads will be so great then a 
Haskell.NET would certainly be a perfect place to try out that theory.
 
Don
 

-Original Message- 
From: Manuel M. T. Chakravarty [mailto:[EMAIL PROTECTED]] 
Sent: Fri 31.05.2002 03:27 
To: Don Syme 
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] 
Subject: 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 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)
[..]
> IMHO problem (a) will always be the thing that stops Haskell becoming
> very very big.  But then being non-imperative it's also its main selling
> point...

So, you are saying that Haskell's problem with .NET is that
it is not imperative, but at the same time you don't want to
resort to Haskell's imperative sublanguage (the IO monad).
I don't quite understand this.

Personally, I find[1] Haskell to be very pleasant for
imperative programming.  In fact, I agree with SPJ, who
wrote[2] (slightly provocatively), Haskell is the world's
finest imperative programming language.

Cheers,
Manuel

[1] After having written piles of low-level imperative code
in Haskell.

[2] In ``Tackling the Awkward Squad''



Ú²G¥–f¢–)à–+-«$zYajÉ–Z+‚m§ÿðÃZ²G¥–Šàþf¢–f§þX¬¶)ߣøZ²G¥

RE: [Fwd: F#]

[Don Syme]

> GHC supports concurrency, exceptions, weak pointers, foreign calls,
> etc, etc.  All these need to be mapped onto .NET.  ... GHC comes 
> with a large collection of libraries of its own.  These need to be 
> still available in the .NET version.

I don't really agree with these points.  If someone tried to support all
of this they'd be unlikely to appear out the other end of the swamp.

Having actually tried both ways myself, I'd suggest that GHC is simply
not the right starting point for a Haskell.NET compiler.  Much better to
start a fresh compiler, essentially from scratch, with a suitable
selection of optimizations, language extensions, library features and
interop extensions given the platform and kind of programming you're
aiming to support.  If you look at history successful compiler projects
do not tend to some out of attempts to graft 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#]


| 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 complicated in the context of the 
| .NET architecture or in any implementation?

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 care; to deal with parametric polymorphism you
need Generic IL, which isn't "out" yet; and even then, higher kinded
type variables are a serious problem.   Being verifiable almost 
certainly requires some runtime checked type casts, which hurt
performance -- and reducing them to a minimum complicates the
compiler.

* My conclusion: best plan is to generate unverifiable IL, and
run it unverified.  Situation is then just like an existing code
generator:
you have to trust the compiler.  But it's fast and it's much simpler.

* The resulting code will still run quite a bit slower than GHC-complied
code.  So why would anyone want to use it?  Presumably, to get access
to the .NET libraries.   So that has to be very convenient.  Tools are
needed to read .NET library meta-data and generate impedence
matching glue to make them easily callable from Haskell.  Haskell needs
some new 'foreign import' stuff to make it easy to call the libraries.

There's a big design space here about how much to extend Haskell
to make calling .NET convenient.

* GHC supports concurrency, exceptions, weak pointers, foreign calls,
etc, etc.  All these need to be mapped onto .NET.   Some might not
fit well; for example, Concurrent Haskell assumes extremely lightweight
concurrency, whereas .NET threads are OS threads; and asynchronous
exceptions might be tricky too.

* GHC comes with a large collection of libraries of its own.  These
need to be still available in the .NET version, so the .NET
implementation
of GHC needs to be pretty fully-featured (because the libraries use
a lot of features).


What all this means is that GHC.NET is a lot more than just a code
generator.   That is, I think, what Don meant when he said that
GHC is complicated.   (In our defence, it is the very fact that GHC is a
rich system that makes it useful.  Its complexity is not gratuitous.)   

Part of my reason for writing this is to encourage anyone out there
to take up the challenge. There's nothing too difficult -- it's "just
work".
Simon and I don't have immediate plans to do anything about this,
but we'd be delighted if someone else did.

Congratulations to Sigbjorn to doing a great job with Hugs.  

Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Fwd: F#]

[Fergus Henderson]

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 care; to deal with parametric polymorphism you
> need Generic IL, which isn't "out" yet;

You don't _need_ Generic IL.  You can deal with parametric polymorphism
by translating polymorphic types to "System.Object".

> and even then, higher kinded type variables are a serious problem.

I think System.Object helps here too.

> Being verifiable almost 
> certainly requires some runtime checked type casts, which hurt
> performance -- and reducing them to a minimum complicates the
> compiler.

It's certainly true that being verifiable is likely to cost some
performance.  But I don't think it would be difficult to implement.

For the Mercury compiler's .Net back-end, there's a --verifiable
option which controls whether the generated IL code is verifiable or not.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
The University of Melbourne |  of excellence is a lethal habit"
WWW:   | -- the last words of T. S. Garp.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Simon Peyton-Jones]

| 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 complicated in the context of the 
| .NET architecture or in any implementation?

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 care; to deal with parametric polymorphism you
need Generic IL, which isn't "out" yet; and even then, higher kinded
type variables are a serious problem.   Being verifiable almost 
certainly requires some runtime checked type casts, which hurt
performance -- and reducing them to a minimum complicates the
compiler.

* My conclusion: best plan is to generate unverifiable IL, and
run it unverified.  Situation is then just like an existing code
generator:
you have to trust the compiler.  But it's fast and it's much simpler.

* The resulting code will still run quite a bit slower than GHC-complied
code.  So why would anyone want to use it?  Presumably, to get access
to the .NET libraries.   So that has to be very convenient.  Tools are
needed to read .NET library meta-data and generate impedence
matching glue to make them easily callable from Haskell.  Haskell needs
some new 'foreign import' stuff to make it easy to call the libraries.

There's a big design space here about how much to extend Haskell
to make calling .NET convenient.

* GHC supports concurrency, exceptions, weak pointers, foreign calls,
etc, etc.  All these need to be mapped onto .NET.   Some might not
fit well; for example, Concurrent Haskell assumes extremely lightweight
concurrency, whereas .NET threads are OS threads; and asynchronous
exceptions might be tricky too.

* GHC comes with a large collection of libraries of its own.  These
need to be still available in the .NET version, so the .NET
implementation
of GHC needs to be pretty fully-featured (because the libraries use
a lot of features).


What all this means is that GHC.NET is a lot more than just a code
generator.   That is, I think, what Don meant when he said that
GHC is complicated.   (In our defence, it is the very fact that GHC is a
rich system that makes it useful.  Its complexity is not gratuitous.)   

Part of my reason for writing this is to encourage anyone out there
to take up the challenge. There's nothing too difficult -- it's "just
work".
Simon and I don't have immediate plans to do anything about this,
but we'd be delighted if someone else did.

Congratulations to Sigbjorn to doing a great job with Hugs.  

Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Ronald Legere]

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 get .net interop? Would that be
easier?

The problem is that ghc (seems) to be a research
language aimed at playing with all kinds of possible
type systems and such (which I am not saying is a bad
thing..).  Of course, I dont really know to much about
how ghc is implemented... maybe the bits that do the
fancy stuff is easy :)

Cheers!
Ron
Haskell Fan.


__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Manuel M. T. Chakravarty]

"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 .NET actually fulfills one of its
> `promises' to be OS neutral) to decrease the amount of work to keep one of
> the two Haskell remaining compilers (GHC, NHC) viable and up-to-date.

As I see it, .NET is just generating more work.  I seriously
doubt that the efficiency of a .NETed Haskell would be
anywhere close to what GHC delivers today.  This is judging
from the various attempts to compile Haskell to JVM (sure
there are some differences between JVM and .NET, but I am
pretty sceptical that this will significantly close the
gap).

What we need is some seriously new technology.  See

  http://www.cse.unsw.edu.au/~chak/project/poc/

for some ideas.

Cheers
Manuel
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[D. Tweed]

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 just Haskell, but widely used languages like C++
> run into this problem, too (see .NET's Managed C++).

That may (or may not) be the case; I don't know. I was more wondering
about `what really makes it so daunting for some working at a Microsoft
(and who thus has more knowledge available about .NET than external
people) to implement a Haskell for .NET, especially given the existance of
F#?'

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 .NET actually fulfills one of its
`promises' to be OS neutral) to decrease the amount of work to keep one of
the two Haskell remaining compilers (GHC, NHC) viable and up-to-date.

___cheers,_dave_
www.cs.bris.ac.uk/~tweed/  |  `It's no good going home to practise
email:[EMAIL PROTECTED]  |   a Special Outdoor Song which Has To Be
work tel:(0117) 954-5250   |   Sung In The Snow' -- Winnie the Pooh


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Manuel M. T. Chakravarty]

"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 from scratch.  I like the idea that a .NET compiler should be
> > under 10K lines of code if at all possible, as is the case for F#.
> 
> 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 complicated in
> the context of the .NET architecture or in any implementation? (I'm just
> interested in that there's little chance of Haskell becoming more
> widespread if it's daunting enough to dissuade implementors.)

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 just Haskell, but widely used languages like C++
run into this problem, too (see .NET's Managed C++).

Cheers,
Manuel

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Manuel M. T. Chakravarty]

"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 Haskell interop with imperative
> libraries, requiring you to reach for monads quite often (or to wrap the
> libraries yourself) 
[..]
> IMHO problem (a) will always be the thing that stops Haskell becoming
> very very big.  But then being non-imperative it's also its main selling
> point...

So, you are saying that Haskell's problem with .NET is that
it is not imperative, but at the same time you don't want to
resort to Haskell's imperative sublanguage (the IO monad).
I don't quite understand this.

Personally, I find[1] Haskell to be very pleasant for
imperative programming.  In fact, I agree with SPJ, who
wrote[2] (slightly provocatively), Haskell is the world's
finest imperative programming language.

Cheers,
Manuel

[1] After having written piles of low-level imperative code
in Haskell.

[2] In ``Tackling the Awkward Squad''
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Don Syme]

> > ... 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 stops Haskell
becoming
> > very very big.  But then being non-imperative it's also its main
> > selling point...
> 
> Are you saying that Haskell users would reject this?  (to which I
would
> disagree, since that's what we would expect)  Or new users?  (to which
I
> would say that the jury is out)

I was meaning "hundreds of thousands of new users", which is why I put
"very very big".  There's still plenty of scope for Haskell to become
just "very big" without fully solving this problem.

> I would think that the biggest impediment to Haskell.NET would be
> efficiency, in both the generated code (primarily because of lazy
> evaluation) and in compile time (at least with an optimizing compiler
> such as GHC).

These are problems, though not unique to a Haskell.NET.  You are right
that the code performance of Hasekll.NET will not typically be as good
as say GHC and this may require more optimizations that take
considerable time.  But I think a clean re-implementation of a
judiciously chosen subset of the GHC optimizations with a focus on
getting good compilation speeds (i.e. the same agenda that the Caml team
have followed) would see you over this hurdle.  You'd be able to get the
performance needed to attract new programmers, though of course other
Haskell compiler writers may still claim the overall performance crown.


Best wishes,
Don


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Fwd: F#]

[Paul Hudak]

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 you to reach for monads quite often (or to wrap
> the libraries yourself) and (b) ...
>
> IMHO problem (a) will always be the thing that stops Haskell becoming
> very very big.  But then being non-imperative it's also its main
> selling point...

Are you saying that Haskell users would reject this?  (to which I would
disagree, since that's what we would expect)  Or new users?  (to which I
would say that the jury is out)

I would think that the biggest impediment to Haskell.NET would be
efficiency, in both the generated code (primarily because of lazy
evaluation) and in compile time (at least with an optimizing compiler
such as GHC).

  -Paul
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Don Syme]

Sigbjorn has already shown how a non-IL-generating approach is possible.
I think a simple implementation of a Haskell.NET compiling to IL is
feasible, especially if you're willing to do the interop with .NET
components by extending the language as with F# or SML.NET.  It's more
that GHC is a bit of a complex point to start from.

Of course doing a full Haskell implementation from scratch requires an
intimate knowledge of all the features you mention, and is the sort of
thing one only tends to get right on the second or third time you do it.
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 Haskell interop with imperative
libraries, requiring you to reach for monads quite often (or to wrap the
libraries yourself) and (b) the well-known problems of combining type
inference, subtyping and overloading, to which you can take a high-tech
approach by using a fancy constraint or inference system, or a low-tech
approach by requiring the programmer to add a few more type annotations
than they may wish.  F# takes the latter approach.

IMHO problem (a) will always be the thing that stops Haskell becoming
very very big.  But then being non-imperative it's also its main selling
point...

Best wishes,
Don



-Original Message-
From: D. Tweed [mailto:[EMAIL PROTECTED]] 
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 libraries in so many places I decided to implement a simpler
> language from scratch.  I like the idea that a .NET compiler should be
> under 10K lines of code if at all possible, as is the case for F#.

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 complicated
in
the context of the .NET architecture or in any implementation? (I'm just
interested in that there's little chance of Haskell becoming more
widespread if it's daunting enough to dissuade implementors.)

___cheers,_dave_
www.cs.bris.ac.uk/~tweed/  |  `It's no good going home to practise
email:[EMAIL PROTECTED]  |   a Special Outdoor Song which Has To Be
work tel:(0117) 954-5250   |   Sung In The Snow' -- Winnie the Pooh

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Don Syme]

Hey Sigbjorn, that looks great!  I'll look forward to trying it out.
Perhaps when the source release is available someone could look at
getting hugs98.net to be able to interop. with ILX components as well,
making combined F#/hugs98.net apps feasible.  I'm one who believe both
Haskell and 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 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
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Fwd: F#]

[Sigbjorn Finne]

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
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: [Fwd: F#]

[Jon Fairbairn]

> 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 570179 (after 14:00 only, please!)


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[D. Tweed]

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 .NET compiler should be
> under 10K lines of code if at all possible, as is the case for F#.

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 complicated in
the context of the .NET architecture or in any implementation? (I'm just
interested in that there's little chance of Haskell becoming more
widespread if it's daunting enough to dissuade implementors.)

___cheers,_dave_
www.cs.bris.ac.uk/~tweed/  |  `It's no good going home to practise
email:[EMAIL PROTECTED]  |   a Special Outdoor Song which Has To Be
work tel:(0117) 954-5250   |   Sung In The Snow' -- Winnie the Pooh

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [Fwd: F#]

[Don Syme]

Hi Paul,

The attached message doesn't give the link you might be after, which is
http://research.microsoft.com/projects/fsharp.  You might also be
interested in SML.NET.

Re Haskell.NET... We (OK, basically just me) got a fair amount of the
way through a .NET backend for GHC, including a fully working compiler,
but we got sidetracked into implementation issues that weren't related
what we wanted to achieve in the first instance.  In particular, (a) GHC
is a complex beast, (b) you have to decide what to do about the
libraries and (c) I wanted a much "lighter" end system than GHC was
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 .NET compiler should be
under 10K lines of code if at all possible, as is the case for F#.

Those of us at MSR have no particular plans to push further on
Haskell.NET right now, but I know a number of other people have talked
about taking a crack at it.

Best wishes,
Don Syme
MSR Cambridge


-Original Message-
From: Paul 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://www.haskell.org/mailman/listinfo/haskell