GHC is bad at CSE. Of course, in general CSE might not be a good idea, but
with strict computations it is. So someone needs to add a CSE pass.
On Sat, Mar 29, 2008 at 2:23 AM, Don Stewart [EMAIL PROTECTED] wrote:
conal:
I'd like to know if it's possible to get GHC to perform some simple
There are no rules written down. But the fast exponentiation
algorithm used by (^) assumes that (*) is associative.
I also don't think that fast exponentiation should ever multiply by 1.
-- Lennart
On Sun, Jun 1, 2008 at 6:34 PM, Serge D. Mechveliani [EMAIL PROTECTED] wrote:
On Sun, Jun 01,
Interesting. The problem seems to be that GHC always inlines toInt
and fromInt early, but this means that the rewrite rule no longer
applies.
And, of course, it doesn't inline toInt and fromInt in the rewrite rule.
I have no idea if you can write a rule that will actually work,
because after
Here's something that actually works. You need to pass
-fno-method-sharing on the command line.
Instead of using rules on methods it uses rules on global functions,
and these global functions don't get inlined until late (after the
rule has fired).
-- Lennart
module F where
-- | Domain of a
'/'toInt'.
claus
Thanks a million, Lennart! -fno-method-sharing was the missing piece. -
Conal
On Sat, Jun 7, 2008 at 5:07 AM, Lennart Augustsson
[EMAIL PROTECTED]
wrote:
Here's something that actually works. You need to pass
-fno-method-sharing on the command line.
Instead of using
I totally agree. Getting the value of the field should just evaluate
x and then use a pointer indirection; there should be no conditional
jumps involved in getting the value.
GHC is just doing the wrong thing.
-- Lennart
On Wed, Oct 15, 2008 at 3:58 PM, Tyson Whitehead [EMAIL PROTECTED]
True, if there can be indirections then that's bad news.
That would make strict fields much less efficient.
But I don't see why indirections should be needed. Simon?
On Wed, Oct 15, 2008 at 4:21 PM, Jan-Willem Maessen
[EMAIL PROTECTED] wrote:
On Oct 15, 2008, at 11:08 AM, Lennart Augustsson
Turning on UndecidableInstances is the same as saying: OK typechcker,
you can loop if I make a mistake.
I've not looked closely at your code, but if you turn on that flag,
looping is probably not a bug.
-- Lennart
2008/12/4 José Pedro Magalhães [EMAIL PROTECTED]:
Hello all,
Please consider
That's a truly awesome feature! I'll shorten all my module names to
single letters tomorrow.
-- Lennart
On Tue, Dec 16, 2008 at 12:43 AM, Don Stewart d...@galois.com wrote:
dons:
Running time as a function of module name length,
http://galois.com/~dons/images/results.png
10 is the
What port is git using for getting the ghc repo via http?
I'm getting this message behind our thick firewall:
fatal: http://darcs.haskell.org/ghc.git/info/refs download error -
Failed connect to darcs.haskell.org:1080; Operation now in progress
It makes me think port 1080 is involved, and I
the 'http_proxy' environment variable to point it at your local proxy
server.
--sigbjorn
On 1/21/2009 07:05, Lennart Augustsson wrote:
What port is git using for getting the ghc repo via http?
I'm getting this message behind our thick firewall:
fatal: http://darcs.haskell.org/ghc.git/info
I'm just guessing, but it looks like a buffering problem.
When a program dies an abnormal death (like the Bug: thing probably
is) then the stdout buffer is not flushed and you'll miss that bit of
the output.
You could set stdout in NoBuffering mode and see if that helps.
-- Lennart
On Fri, Feb
Just Hindley-Milner type inference is exponential, making the type
system more complex isn't going to make things better.
2009/2/26 Ben Franksen ben.frank...@online.de:
Hi
the attached module is a much reduced version of some type-level assurance
stuff (inspired by the Lightweight Monadic
How could you match the first case with less than two case constructs?
There are two (:) to check for, so I'm not sure what you are complaining about.
-- Lennart
On Tue, Mar 24, 2009 at 12:16 AM, Claus Reinke claus.rei...@talk21.com wrote:
I just noticed that GHC (6.11.20090320) seems to
The only way to see the impact of very low level things like which way
branches go is to generate assembly code and the make simple
controlled changes of that.
But even doing that is very dodgy since you are subject to the whims
of cache misses etc.
As far as branching goes, conditional branches
You could imagine a pragma to say which branch is likely.
f p1 = e1
f p2 = {-# LIKELY #-} e2
f p3 = e3
Is there some way to propagate pragmas through core transformations?
-- Lennart
On Wed, Mar 25, 2009 at 9:18 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Indeed GHC does not attempt
When you tried switching Nil and Cons, did you try it on many examples?
For a single example a 2-3% could be easily attributed to random
effects like different instruction cache hit patterns. If you get it
consistently over several programs then it seems likely to mean
something, but I'm not sure
I find this reordering discussion somewhat nonsensical.
Haskell specifies top-to-botton, left-to-right matching.
This specifies exactly which tests that have to be made and in what order,
and ghc does exactly those and in the correct order.
One can have a perception that when there are multiple
Sorting by constructor tag is perfectly safe when done right.
You can read about how to do it in my 1985 FPCA paper or in Simon's book.
When pattern matching against against things that that are not
constructors (like literals etc) it's much trickier to reorder them
since you have to prove harder
And to make many, many peoples life easier the binaries could have
been included in ghc 6.10.2 (but I know there are some philosophical
reasons against it).
-- Lennart
On Sun, Apr 5, 2009 at 5:48 PM, Don Stewart d...@galois.com wrote:
daniel.is.fischer:
Am Sonntag 05 April 2009 10:24:25
If it's easy I think just generating the code and let the type checker
report any problems would be a great thing for standalone deriving.
-- Lennart
On Tue, Apr 14, 2009 at 10:10 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Yes, indeed, see
The exhaustiveness checker in ghc is not good. It reports
non-exhaustive matching a bit too often and also the error messages
are often not in terms of the original source but some desugared
version.
If those things were improved I think it should be always on.
On Mon, May 18, 2009 at 12:53 AM,
Excellent, is there a -fuse-catch flag for ghc? :)
On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell ndmitch...@gmail.com wrote:
... exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds...
Or even people from typed backgrounds. I worship at the
6.10.4 is a bug fix release. A bug fix release cannot remove packages
no matter what state the platform is in, that's just seriously broken.
On Wed, May 27, 2009 at 7:44 AM, Don Stewart d...@galois.com wrote:
Not part of the core libs, so these are slowly disappearing from the
extralibs
At a minimum I think the error message should be better.
I also think it would be natural to use the DisambiguateRecordFields
for the places where RecordWildcards are used.
I mean, if I change from unqualified import to a qualified one, and
then change all visible names to be qualified I would
The usual way to do this would be to include the dependency on the RTS
in the library and then vary the RTS by using LD_PRELOAD.
I think ghc does it the wrong way.
-- Lennart
On Mon, Feb 22, 2010 at 10:00 PM, Max Bolingbroke
batterseapo...@hotmail.com wrote:
Hi Tyson,
This blog post
I would really like to see #3900 in there. On trac it's slated for
the 6.12.2 release, but I don't see it in your list.
#3904 should also be really easy to fix.
On Tue, Mar 23, 2010 at 6:38 PM, Ian Lynagh ig...@earth.li wrote:
Hi all,
This is a summary of our plans for GHC 6.12.2.
We plan
Thanks!
On Sat, Mar 27, 2010 at 11:59 PM, Ian Lynagh ig...@earth.li wrote:
On Thu, Mar 25, 2010 at 10:14:34PM +, Lennart Augustsson wrote:
#3904 should also be really easy to fix.
Yup, done.
Thanks
Ian
___
Glasgow-haskell-users mailing
Encapsulation is essential for constructing robust software.
How could we get rid of that and claim to have a serious language?
On Sat, Jun 19, 2010 at 8:38 PM, Christian Höner zu Siederdissen
choe...@tbi.univie.ac.at wrote:
Hi everybody,
I'd like some input on other peoples' thoughts on this.
Like everyone else I have no good solution.
When I had a ghc branch I used diff and patch to move my patches forward.
Not exactly what you expect to have to do with a version control system.
On Mon, Dec 6, 2010 at 1:57 AM, Iavor Diatchki iavor.diatc...@gmail.com wrote:
Hello,
I am doing some
Also beware that Typeable uses the original names of types, which means that
moving basic types around totally wrecks backwards compatibility for those of
us who use the type name for serialization etc.
-- Lennart (iPhone)
On Aug 19, 2011, at 11:00, Johan Tibell johan.tib...@gmail.com
Henning Thielemann wrote:
On Fri, 5 Nov 2004, Robert Dockins wrote:
What IEEE has done is shoehorned in some values that aren't really
numbers into their representation (NaN certainly; one could make a
convincing argument that +Inf and -Inf aren't numbers).
I wonder why Infinity has a sign in
You pick. :)
It can break referential transparency. It can break type safety.
-- Lennart
Andre Pang wrote:
G'day all,
Just looking at the documentation for System.IO.unsafeInterleaveIO,
what exactly is unsafe about it?
___
Andre Pang wrote:
On 10/06/2005, at 11:16 AM, Remi Turk wrote:
Are you sure you're not talking about unsafePerformIO?
System.IO.Unsafe.unsafePerformIO:: IO a - a
System.IO.Unsafe.unsafeInterleaveIO :: IO a - IO a
[written to Lennert Augustsson]: yes, I think you misread
Simon Marlow wrote:
Is it correct that you use indirect gotos across functions? Such
gotos aren't supported by GCC and work only by accident.
Yes, but cross-function gotos are always to the beginning of a function.
Is that enough to ensure that the constant pool base register
is reloaded
Can't you unpack the ar library and then link the object files
into a shared library?
-- Lennart
Keean Schupke wrote:
GHCI does not load archive libraries. Is it possible (easy?) to get it
to load (.a) archive libraries as well as .o and .so files? The problem
is some optimized
wrote:
Am Samstag, 3. Dezember 2005 14:48 schrieb Lennart Augustsson:
Can't you unpack the ar library and then link the object files
into a shared library?
On most platforms the code in a *.a library is not shared library code, e.g.
it is not PIC or something like that. Nevertheless, I think
ghci with the .o files on the command line.
Regards,
Keean.
Sven Panne wrote:
Am Samstag, 3. Dezember 2005 15:17 schrieb Lennart Augustsson:
And on many platforms (well, at least a few years ago) a shared
library doesn't have to be PIC. The dynamic loader can do relocation
when
Simon,
Don't worry, your implementation (and any implementation)
has strong fairness. Just run it enough times that the
hardware fails in the way peoplewant. ;)
Jest aside, I'm totally on your side in this discussion.
Asking an implementation to promise to generate all possible
interleavings
Donald Bruce Stewart wrote:
Most distros are using binary bootstrapping. I think OpenBSD is the only
one building from .hc src.
And NetBSD.
-- Lennart
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
The memory allocated by the runtime system is never freed.
I've submitted a fix fir this.
-- Lennart
Michael Marte wrote:
Hello *,
before filing a bug report, I want others to comment on my problem.
Maybe it's my fault, not ghc's.
I wrapped up some Haskell modules in a Win32 DLL.
initial heap space, the problems described earlier occur again :-(
Michael
Lennart Augustsson wrote:
The memory allocated by the runtime system is never freed.
I've submitted a fix fir this.
-- Lennart
___
Glasgow-haskell-users mailing list
Glasgow
space, the problems described earlier occur again :-(
Michael
Lennart Augustsson wrote:
The memory allocated by the runtime system is never freed.
I've submitted a fix fir this.
-- Lennart
___
Glasgow-haskell-users mailing list
Glasgow-haskell
Exceptions generated from Haskell you can catch, but the really
bad ones are those that the runtime system itself generates
(when something really bad happens, like a failed malloc).
I have a set of patches that fixes those, so you can actually write
safe DLLs. One of these days I'll file a bug
A more clever representation of Integer could unbox numbers in big
range.
But that would require some runtime support, I think.
-- Lennart
On Jul 31, 2006, at 11:19 , Duncan Coutts wrote:
On Mon, 2006-07-31 at 14:32 +0400, Serge D. Mechveliani wrote:
Dear GHC developers,
Long ago
Actually, you can keep it to one test for add/subtract if you
use a single word that is either a number or a pointer, the
pointer being tagged in lowest bit. Then you can add first
and check for tags after. Having tags is rare, so the machine
should be told so, if possible. This way you can
On Aug 30, 2006, at 14:58 , David Roundy wrote:
On Wed, Aug 30, 2006 at 07:38:35PM +0100, Jamie Brandon wrote:
I recently defied my supervisor and used Haskell to write my
coursework instead of C. All went well until I needed floating point
and started having odd results. As far as I can tell
Slightly tongue in cheek, I think the real problem is that your
courses come in the wrong order. No one should use floating point
numbers without first having a course in numerical analysis. :)
-- Lennart
On Aug 30, 2006, at 14:38 , Jamie Brandon wrote:
I recently defied my
And what would rotating an Integer mean? The only sensible
interpretation I can think of is to make it behave like shift.
On Sep 18, 2006, at 23:46 , Peter Tanski wrote:
Welcome back! Since Data.Bits is not defined in the Haskell 1998
standard, are we free to change the implementation of
If we allow C{..} in patterns we should absolutely have it in
expressions too. Both for symmetry and usefulness.
-- Lennart
On Oct 31, 2006, at 14:06 , Iavor Diatchki wrote:
Hello,
I think the it may be confusing to novices argument tends to be
over-used and we should be careful
GHC doesn't normally do CSE. CSE can cause space leaks, so you can't
do it willy-nilly.
I'm sure there are some strict contexts where it could be done
safely, but I don't think ghc uses that information (yet).
-- Lennart
On Nov 27, 2006, at 08:34 , Christian Maeder wrote:
the
.
-- Lennart
On Nov 28, 2006, at 09:50 , Bertram Felgenhauer wrote:
Dinko Tenev wrote:
On 11/27/06, Lennart Augustsson [EMAIL PROTECTED] wrote:
GHC doesn't normally do CSE. CSE can cause space leaks, so you
can't
do it willy-nilly.
I'm sure there are some strict contexts where it could
And why isn't C a b equivalent to C a b1?
forall a b . C a b = a - a
and
forall a b1 . C a b1 = a - a
look alpha convertible to me. Or is the inferred type
forall a . C a b1 = a - a
Btw, this reminds me again that I'd like to be able to use _ in type
signatures.
With the meaning of _
altogether (but only a few people
advocate this (hello John!)).
-- Lennart
On Dec 7, 2006, at 07:20 , Johannes Waldmann wrote:
Lennart Augustsson wrote:
Btw, this reminds me again that I'd like to be able to use _ in type
signatures.
With the meaning of _ being, there's a type here, but I
I should have said that the situation in H98 is quite bad.
There you can't make default instances.
On Dec 7, 2006, at 07:49 , Johannes Waldmann wrote:
Lennart Augustsson wrote:
Speaking of wishlist, I'd also like to see context synonyms, e.g.,
context C a = (Ord a, Num a)
The current
My (off-the-top-of-my-head) suggestion was much more modest.
A context synonym would only allow you to shorten contexts, it would
not be a new class.
On Dec 7, 2006, at 10:53 , J. Garrett Morris wrote:
On 12/7/06, Lennart Augustsson [EMAIL PROTECTED] wrote:
Speaking of wishlist, I'd also
Your two examples are different, the second one is rejected by the
type checker, with or without a signature. The first one isn't.
Tell me how this make sense:
1. I enter the definition for f.
2. I ask ghc for the type of f and get an answer.
3. I take the answer and tell ghc this is
If the type checker really deduces the type 'forall a b . C a b = a -
a' then an inference algorithm that works seems easy. Do type
inference for f, then check that the signature the user has given is
alpha-convertible with the deduced type (well, in general it's more
complicated than
would still not be able to use the
signature inferred by GHCi, but it would now be clear why
that is the case (and why the signature above does not work).
Claus
- Original Message - From: Simon Peyton-Jones
[EMAIL PROTECTED]
To: Lennart Augustsson [EMAIL PROTECTED]
Cc: GHC users glasgow
, but (b) it affects only very few
programs and ones that are almost certainly ambiguous anyway, and
(c) I can't see an easy way to fix it. So my current plan is: let
it lie.
I'll open a low-priority bug report for it though.
Simon
| -Original Message-
| From: Lennart Augustsson [mailto
Yeah, you really need {-# NOINLINE var #-} to make it reasonable safe.
On Mar 6, 2007, at 23:18 , David Brown wrote:
Seth Kurtzberg wrote:
On Tue, 06 Mar 2007 12:03:05 -0800
David Brown [EMAIL PROTECTED] wrote:
I've noticed quite a few pages referencing constructs such as:
var :: MVar
, Lennart Augustsson [EMAIL PROTECTED] wrote:
Yeah, you really need {-# NOINLINE var #-} to make it reasonable
safe.
Couldn't GHC bake in knowledge about unsafePerformIO, and never inline
it? It is a slightly hacky solution, but since unsafePerformIO is
pretty much only used in hacks, I think its almost
Sorry, but I'm not always connected to the Internet. I'd like to be
able to get flag help easily anyway.
-- Lennart
On Mar 13, 2007, at 14:28 , Simon Peyton-Jones wrote:
Suppose ghc --full-flag-help simply printed the URL
On Apr 16, 2007, at 15:54 , Simon Marlow wrote:
- left-to-right impredicative instantiation: runST $ foo
Is this really a good idea? This will just make people complain that
€ (x € f = f x) doesn't work when you do foo € runST (or maybe it
does?).
-- Lennart
For me the type is important, I want to see it for every top level
function. Using named types it serves as documentation.
-- Lennart
On Sun, 13 May 2007, Joel Reymont wrote:
Date: Sun, 13 May 2007 14:23:42 +0100
From: Joel Reymont [EMAIL PROTECTED]
To: GHC Users Mailing List
Look at the end of http://haskell.org/haskellwiki/GHC/Indexed_types
-- Lennart
On 8/31/07, Jim Apple [EMAIL PROTECTED] wrote:
Regarding
http://www.haskell.org/pipermail/cvs-ghc/2007-August/037655.html
and
Are type functions checked for termination? If so, where can I find the
details?
I'm very much in favor of listing the exact extensions used in each file,
because I try to keep them to a minimum.
I would like to see a LANGUAGE Haskell' which includes the things that are
likely to be in Haskell' (if there is ever a Haskell').
-- Lennart
On Nov 20, 2007 9:42 PM, Alex
This seems very, very wrong. The missing instance(s) might be left out
because of some good reason (e.g. if you have implemented sets with list and
not provided Ord).
On Nov 21, 2007 12:59 AM, Duncan Coutts [EMAIL PROTECTED] wrote:
On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote:
When
Or use a preprocessor that inserts a LANGUAGE pragma. :)
On Nov 22, 2007 9:14 AM, Simon Marlow [EMAIL PROTECTED] wrote:
Alex Jacobson wrote:
In any case, I'm pretty sure the correct answer is not 50 language
pragmas with arbitrary spellings for various language features at the
top of
I don't think it's highly problematic. I agree that it would be nice to
have the type and value levels have a similar structure, but if there are
compelling reasons to do otherwise that fine too.
You could still allow symbol type variables if they have an explicit binding
occurence, which you
I agree. There are other ways that to solve the same problem as the case
distinction does.
On Dec 7, 2007 12:45 PM, Johannes Waldmann [EMAIL PROTECTED]
wrote:
On Fri, 7 Dec 2007, Manuel M T Chakravarty wrote:
The problem is that Haskell 98 already messed that up.
If type functions are
I had it pretty well worked out for single parameter type classes, but I
couldn't see any nice extension to multiple parameters.
On Dec 11, 2007 5:30 PM, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
| If it really would work ok we should get it fully specified and
| implemented so we can fix
Did I understand the strictness of the case statement right:
case z of z' forces that z' (and z) will be in head normalform?
Yes, that's right.
I might have missed some of the context here, but
case z of z' - e
is the same as
let z' = z in e
according to the Haskell semantics, so it
The correct behaviour would be to let the above pattern match fail
in the case of different types at r1 and r2,
because the left-hand side has to have a typing
with equal types for r1 and r2
induced by the right-hand side ``r1 == r2''.
But now you are assuming that there is an intentional
Parting shot: isAlphaNum vs. isAlphanum? Haven't we been here before?
Don't the committee have more amusing (and less pointless and gratuitously
program-breaking) things to tinker with? (I know, nothing to do with
ghc, I'm just in a mood to 'give out'...)
Ah, but each new committee has to
George Russell wrote:
Disagree. I think it's nice fast. I challenge you to write a faster
Haskell parser using a combinator library.
Parser combinators are fine if the grammar is very simple or you don't
care about CPU times. But using them in a serious compiler for Haskell
would be
Simon Marlow wrote:
Nonsense. I contend that you really don't want an error-correcting parser.
- parsing is quick
- error-correction is by definition unreliable
- error-correction is hard to implement well
I agree, I find that I often only fix the first error even
How? RULES similar to ghc? Or built-in compiler magic for this case?
Built in magic. Since this was the only way to convert between floating
types it obviously needed a special case.
-- Lennart
The compiler cannot guess that some primitive Float-Double
function can
be used instead of going through Rational.
If enough inlining is done, then it should be able to deforest the
intermediate Rational and generate the same code. But I agree, using RULES
here is quicker and doesn't
Ken Shan wrote:
such that calling
(*adjustor)({argument values})
is equivalent to calling
(*wptr)(hptr, {undefined/ignored pointer}, {argument values}).
This goal seems difficult to achieve on the Alpha, since its
complicated calling convention puts arguments in registers, and
Yes, they all seem to be right.
You get these funny effects because numbers like 5.2 do not have an
exact representation with floating point numbers in base to (like Float
and Double most likely have on your machine). The number 5.2 is stored
as a slightly different number as a Float, but the
Malcolm Wallace wrote:
Hal Daume III [EMAIL PROTECTED] writes:
Not for me, GHC 5.04.2 (Solaris).
here it goes right the first time, but then i have to type two more
letters (in this case 'b\n') to get it to respond to hello.
Solaris has a slightly bizarre buffering scheme in raw
Aim
To guarantee security of a Haskell program so it can
be used as an applet.
/Aim
Method
Over-ride GHC's code generator to produce an
assembly language that I specify. Also disable
program access to system calls and foreign
functions, except for a single trusted library
that I specify.
/Method
Simon Peyton-Jones wrote:
generate case expressions when there is more
than one string in the list, otherwise use an equality test
Oh, you mean like hbc does? ;-)
Sorry, couldn't resist.
-- Lennart
___
Glasgow-haskell-users mailing list
On Thu, 30 Sep 2004, Serge D. Mechveliani wrote:
I thought naively that the Report function definitions can be treated
more flexy, varied by implementations, with preserving some declared
main properties.
The definitions in the Report are to be treated as specifications.
Any implementation should
What are the defaulting rules for IsList? It needs to be backwards compatible.
-- Lennart (iPhone)
On Sep 30, 2011, at 19:28, George Giorgidze giorgi...@gmail.com wrote:
GHC Users,
I would like to make to the following two proposals:
* Eliminate the default grouping close from
For instance, at your day job, the Array type.
On Wed, Oct 5, 2011 at 12:23 PM, Roman Leshchinskiy r...@cse.unsw.edu.auwrote:
Simon Peyton-Jones wrote:
I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map
String Int. Probably not. Maybe that's a shortcoming... but such
The required context on pattern synonyms isn't just useful, it's
necessary. Since arbitrary computation can happen in both the pattern
matching and construction we need the context.
Take Richard's example, without the context on Positive we would infer the
wrong type for any use of the Positive
88 matches
Mail list logo
