"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
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
[copied to Zhong Shao and Cordelia Hall]
> [snip - full text included at end]
>
> But the moral for the current discussion: a more intelligent list
> representation could have substantially more benefits for the
> average Haskell program than any compiler optimization twiddling,
> and I'd really
Long away and far ago (or something like that;), there was a
discussion on Lists implemented as arrays rather than linked
structures, during which Jerzy Karczmarczuk commented:
> What bothers me quite strongly is the algorithmic side of operations
> upon such objects.
>
> Typical iterations ma
Hi Haskellers,
> "Max" == Max Kirillov <[EMAIL PROTECTED]> writes:
Max> So why one might need it? I've never used Rational, but, if
Max> asked, I would say that they are for exact representation of
Max> numbers (some symbolic calcs).
that's true. I'm using rationals intensively
So why one might need it? I've never used Rational, but, if
asked, I would say that they are for exact representation
of numbers (some symbolic calcs). On the other side, 'real'
dotted numbers always represent some real values with finite
accuracy. That's look like a bad idea to me to call Rationa
> 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 some
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#.
Jon Fairbairn <[EMAIL PROTECTED]> writes:
> Why "-f" anyway? It took me ages to work out what
> "-fallow-overlapping-instances" meant -- I wondered how
> "fallow" could apply to overlapping instances.
I suppose it's a GCCism, where options starting with -f specifiy
*f*lags. (Which doesn't seem
×ð¾´µÄÐÂÀÏ¿Í»§£º
ÄúºÃ£¡
Êý×ÖÒýÇæ(www.9dns.net)ΪÁË´ðлÄúÒÔ¼°¹ã´ó¿Í»§¶ÔÎÒ˾µÄÖ§³ÖºÍÐÅÈΣ¬ÎÒÃÇÔÙ´ÎÌá¸ßоɷþÎñÆ÷µÄÐÔÄÜ£¬ÈÃÄúµÄÍøÕ¾¿Õ¼äÔË×÷¸ü¿ì¡¢¸ü
Îȶ¨¡¢¸ü°²È«£¬Í¬Ê±ÎÒÃÇ»¹½µµÍÁ˲úÆ·
¼Û¸ñ£¬ÈÃÄúÏíÊܸüÓÅÖʵķþÎñ¡££¨ÎÒ˾ÍøÕ¾ÏÖÒÑȫиİ棺www.9dns.net£©
200M HTML¿Õ¼ä+1¸ö¹
14 matches
Mail list logo
