Following the helpful call to attend to priorities, I reluctantly return to
the M-R discussion. I believe a point has been missed that should be a part
of this thread.
On 2006 January 30, Josef Svenningsson wrote:
But the most important argument against M-R hasn't been put forward yet.
On 02 February 2006 09:52, John Hughes wrote:
Summary: 2 programs failed to compile due to type errors (anna,
gg).
One program did 19% more allocation, a few other programs
increased
allocation very slightly (2%).
pic +0.28% +19.27% 0.02
Hello John,
Thursday, February 02, 2006, 12:51:58 PM, you wrote:
JH Let me make clear that what concerns me is not the impact of the M-R on
JH space and time
JH performance on average. What concerns me is the difficulty of debugging
JH performance
JH problems.
may be it's better in such case
On Thu, Feb 02, 2006 at 12:34:30PM -, Simon Marlow wrote:
Still, you could argue that it doesn't actually tell you the cause of
the problem: namely that ij are being evaluated twice as often as you
might expect by looking at the code.
Would not the entries count in the profile tip you off
On 31 January 2006 17:48, Andrew Pimlott wrote:
On Tue, Jan 31, 2006 at 10:17:57AM -, Simon Marlow wrote:
On 30 January 2006 21:49, Andrew Pimlott wrote:
In the present case, people aren't (only) opposing the M-R out of
principle, but because they actually use overloaded variable
On Mon, 30 Jan 2006, Simon Marlow [EMAIL PROTECTED] wrote:
Given the new evidence that it's actually rather hard to demonstrate any
performance loss in the absence of the M-R with GHC, I'm attracted to
the option of removing it in favour of a warning.
I also want to remove the M-R, because of
On 01 February 2006 11:42, Nils Anders Danielsson wrote:
However, to stand on more solid ground I suggest that someone runs
some performance tests, with and without
-fno-monomorphism-restriction, to see whether the M-R has any great
impact in practice. There are some performance test suites
I think that given these results, I would have absolutely no issues with
dropping the MR completely. in fact, I'd recommend it.
If we must do something I don't think it is worth eating an operator for
a new type of binding, but some shorthand syntax
(x) = foo
being sugar for the equivalent of
[I have subscribed to the list today, so my mailbox doesn't contain the
post I should respond to (the one that started this thread). BTW, is
there a way to tell mailman to send me all previous postings?]
Concurrent Clean uses =: for Constant Graph Definitions, which seem to
be related.
See
Simon Marlow [EMAIL PROTECTED] writes:
Given the new evidence that it's actually rather hard to demonstrate any
performance loss in the absence of the M-R with GHC, I'm attracted to
the option of removing it in favour of a warning.
As another data point, today for the first time I received an
John Meacham wrote:
interestingly enough, the monomorphism restriction in jhc actually
should apply to all polymorphic values, independently of the type class
system.
x :: a
x = x
will transform into something that takes a type parameter and is hence
not shared.
Interesting. I'd been
[EMAIL PROTECTED] writes:
Nhc didn't use to implement the M-R (maybe it does now). When
porting code to nhc this caused a few code changes. Perhaps
10 lines out of 1 when I tried the Bluespec compiler. So
my gut feeling is that the M-R is a rare beast in practise.
I can confirm that
On 1/30/06, Simon Marlow [EMAIL PROTECTED] wrote:
I've put a wiki page with a summary of this discussion here:
http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/Monomorph
ismRestriction
Hopefully I've captured most of the important points, please let me know
if there's anything
There are a whole lot of ways to ruin the performance of haskell
programs that are a lot more subtle than the MR restriction. I don't see
why we deem this particular one, especially when it is easily solved by
adding a type signature, of special enough import to change the language
over.
Lennart Augustsson wrote:
Jacques Carette wrote:
Personally I think that this ought to be resolved by static means --
and yes, by the linker, as it can't be done properly earlier.
But there are cases that cannot be resolved statically.
On the other hand, they are probably rare enough to
On Fri, Jan 27, 2006 at 06:05:56PM -0500, Robert Dockins wrote:
One aspect of this discussion I've yet to see that I think is
important is, how do the various proposals for removal/modifications
of M-R impact implicit parameters? Are implicit parameters likely to
be in Haskell'? It
On 28/01/06, Taral [EMAIL PROTECTED] wrote:
On 1/28/06, Cale Gibbard [EMAIL PROTECTED] wrote:
Do you have an example of such a program handy?
b = (x, x) where { x :: Num a = a; x = fromInteger 1 }
fromInteger is called twice.
--- mr.hs ---
{-# OPTIONS_GHC -fno-monomorphism-restriction #-}
On 28/01/06, Lennart Augustsson [EMAIL PROTECTED] wrote:
Remove the type signature for b and you will see the
loss of sharing.
Nope, still not seeing it with either profiling or Debug.Trace. Also
-- the type signature I gave was polymorphic, so what's the deal? If
adding a polymorphic type
Oh, I guess I did one more change. I put b in a separate module.
Your type signature isn't the most general, the most general is
b :: (Num a, Num b) = (a, b)
And that is the source of the problem. You need to pass two
dictionaries. To keep sharing you'd need some very clever
runtime machinery
Aha, okay. Yeah, I can reproduce that now, and it makes good sense
what's going on. It is in fact quite sensible that x be evaluated
twice with that sort of polymorphism.
Hmm... however, could we not assign to each instance a unique
identifier which could be compared? Say a cryptographic hash of
On 26 January 2006 16:07, John Hughes wrote:
Simon Marlow wrote:
I wonder if there's an alternative solution along these lines:
- We use ParialTypeSignatures to make bindings monomorphic:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/PartialTyp
eSigs
eg.
One aspect of this discussion I've yet to see that I think is
important is, how do the various proposals for removal/modifications
of M-R impact implicit parameters? Are implicit parameters likely to
be in Haskell'? It seems like the proposal to default to polymorphic
binding and have
John Hughes wrote:
* You can't eta-convert definitions freely, if there is no type signature.
...
* Definitions without a type-signature can change ...
(entering ironic mode, but not quite:)
So, what about making type signatures mandatory,
as the rest of the civilized world does happily for
On 26 January 2006 09:59, John Hughes wrote:
The solution I favour is simply to use *different syntax* for the two
forms of binding, so that a definition is monomorphic, and computed
at most once, if it uses the monomorphic binding operator, and
polymorphic/overloaded, computed at each use,
Simon Marlow [EMAIL PROTECTED] writes:
On 26 January 2006 09:59, John Hughes wrote:
The solution I favour is simply to use *different syntax* for the two
forms of binding,
I wonder if there's an alternative solution along these lines:
- We use ParialTypeSignatures to make bindings
On 2006-01-26, John Hughes [EMAIL PROTECTED] wrote:
I don't think it's hard. I would just teach students to define
functions with =, and variables with :=. I tell my students to write
type signatures at the beginning anyway, so they don't risk being
bitten by the M-R anyway. Beginning students
26 matches
Mail list logo
