It's a perf bug in 6.6, happily fixed in 6.8.1
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Bernd Brassel
| Sent: 14 December 2007 12:59
| To: glasgow-haskell-users@haskell.org
| Subject: Hugs faster than GHC
|
| The following program
| However when I do this:
|
| newtype Quaternion = Q (Vec4 Double)
|
| Everything is ruined. Functions like peek and vadd are no longer inlined,
| intermediate linked lists are created all over the place. The Quaternion
| Storable instance looks like this
Turns out this is a perf bug in 6.8 that
I've typechecked this by hand, and indeed it looks to me as if it should work.
(Admittedly, your inAssocL function is making an unsubstantiated claim (since
you define it as 'undefined'), but that is still sound since any attempt to run
the program will diverge. But it should tpyecheck.)
Here
| If it really would work ok we should get it fully specified and
| implemented so we can fix the most obvious class hierarchy problems in a
| nice backwards compatible way. Things are only supposed to be candidates
| for Haskell' if they're already implemented.
Getting it fully specified is the
| I'm using ghc 6.6.1 under Ubuntu Gutsy on a Pentium 4 machine, and I
| was working to get some code running in an acceptable time. I was
| surprised to find that turning on profiling switches made the code run
| over 40x faster!
That is indeed strange. Things to try:
* Try without -O.
* Try
| Nothing deep. Just that = means so many things that it seemed better
| to use a different notation.
|
|
| How about ==? Only one meaning so far, and that both on the term level and
| equivalent to the constraint
I'm quite happy with ~! It's sufficiently different from = that someone
@haskell.org; Simon Peyton-Jones
| Subject: type equality symbol
|
| conv :: (a~b) = a - b
| conv = id
|
| is there any particular reason that '~' is the symbol for type equality
| constraints? I would think '=' would be the obvious choice, (although
| perhaps it is already over-used
| And here we know that y=Bool; yet since we don't write the type sig
| directly we can't say it. So GHC's implementation of fundeps rejects
| this program; again it can't be translated into System F.
|
| Conveniently, this is a good example of my other problem with fundeps :-)
| I can work
| I did originally intend to try all this with the
| HEAD, but one obstacle to this is the lack of recent linux
| binaries in http://www.haskell.org/ghc/dist/current/dist/
Ian is fixing that. We'd missed the fact that the bindists weren't being built.
Hold on a day or two.
Simon
Better still, could you add a section to that page about DLLs and Excel? That'd
be useful for others.
Simon
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Boudry
Sent: 30 November 2007 18:09
To: glasgow-haskell-users@haskell.org
Subject: Re: GHC generated dll makes Excel
GHC definitely does not assume that the top bit is of an address is clear. But
I don't know that anyone has explicitly tested it on a 3Gb program.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Bulat Ziganshin
| Sent: 02 December 2007 14:12
| I'm trying to understand what fundeps do and don't let me do. One
| particular source of confusion is why the following program doesn't
| typecheck:
|
| {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
| module Fundeps where
|
| class Dep a b | a - b, b - a
|
| conv :: (Dep a
| Is it really a good idea to permit a type signature to include
| equality constraints among unifiable types? Does the above type
| signature mean something different from a -a? Does the type signature:
| foo :: (a~Bar b) = a - Bar b
| mean something different from:
| foo :: Bar b -
).
If not, let's see why not. It'd be better to put your new material in with the
other FFI stuff; it'll be easier to find that way.
THanks
SImon
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Boudry
Sent: 03 December 2007 14:28
To: Simon Peyton-Jones
Cc: glasgow-haskell
Alex,
| Ok, I'm game to default to haskell98 in the presence of ambiguity, but
| in most cases the extension involves new syntax and that should be enough.
Trying to compile the program both ways (or 2^n ways) to check for ambiguity
sounds like a pretty heavy hammer to crack this nut.
GHC is
| Nice feature but feel like a band-aid. In particular it makes SYB style
| programming more difficult because field labels aren't types.
|
| Almost every other record syntax plan involves field labels as types so
| you can do interesting type dispatch.
Record systems are indeed an interesting
| So, my suggestion is that in any case where the compiler currently
| suggests use of a particular pragma in an error message, it should
| instead turn that pragma on and produce a warning.
In the cases where the compiler makes that suggestion, yes what you suggest
would be feasible I think.
| So what is DisambiguateRecordFields?
It's documented in the user manual (for the HEAD):
http://www.haskell.org/ghc/dist/current/docs/users_guide/syntax-extns.html#disambiguate-fields
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-
| [EMAIL PROTECTED] On
You probably want -ddump-simpl to print Core
Yes, the bindings should be in dependency order. They certainly seem to be for
me
Simon
Foo.hs
data Numeral = Zero | Succ Numeral
zero = Zero
one = Succ zero
ten = Succ one
ghc -c -ddump-stg -ddump-simpl Foo.hs
Tidy Core
Using concurrency in GC usually implies one of
- Parallel GC. Stop the mutator(s) and use multiple processors to do GC; when
they are done, start the mutators. This isn't real-time, because there's an
unbounded pause for GC. This is what Simon and Roshan's parallel collector
does.
-
Urk. Well spotted!
I omitted a prime (writing env instead of env') in a late fix, and as a result
practically no top-level rules and specialisations are being applied.
What an egregious bug. The good news is that a one-character fix should make
6.8.2 perform quite a bit better than 6.8.1!
What would you expect to happen for this?
fib :: Int - Int#
fib n = ...
x :: Int#
x = fib 100#
'x' cannot be bound to a thunk. So the top-level computation would have to be
evaluated eagerly. But when? Perhaps when the program starts? Maybe one
could do that, but we have not done so.
| That's not a problem in GHC's configure.ac or other .ac files. It's just
If it's nothing to worry about, and has a sensible explanation, can someone add
it to the Building GHC FAQ? (If this page doesn't exist, it ought to!)
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
| There seems to be widespread agreement that the current situation wrt
| records is unacceptable, but the official GHC policy is that there are too
| many good ideas to choose from - so nothing gets done! I hence humbly
| propose that
O2 mainly switches on two transformations: liberate case and call-pattern
specialisation. (I think it also gets passed on to gcc.)
Trying -O2 -fno-liberate-case,
and -O2 -fno-spec-constr
might tell which was making the difference.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
I've updated the Getting the GHC sources page -- you might want to check I
got it right.
http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources In general,
though, yes it's a Wiki and you are not only welcome but positively encouraged
to make it more helpful. So go right ahead.
| I just finished a running Bluespec's regression suite on a version of
| our tools compiled with ghc 6.8.1. The results were impressive on two
| fronts:
|
| 1. All of our tests (almost 14,000) had the same behavior as with ghc 6.6.1
| 2. Our Haskell code was roughly 33% faster (relative to ghc
The current documentation is laughably sparse. Documentation patches would be
hugely welcomed. Thank you!
Alfonso is also working actively on TH at the moment. I'm ccing him
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Richard Giraud
-level equations and arbitrary local constraints.
Simon
| -Original Message-
| From: Philip K.F. Hölzenspies [mailto:[EMAIL PROTECTED]
| Sent: 19 October 2007 09:38
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Why only inference in type checking?
|
| Dear
You probably need to compile with -package-name base. When you compiled
Err.lhs-boot you need to say that it belongs to package base.
S
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Victor Nazarov
| Sent: 07 November 2007 14:28
| To:
Well it's debatable. Suppose we have
newtype Foo = MkFoo String deriving( Num )
Do you want to generate
instance Num String = Num Foo
? I suspect not -- usually we generate an error message right away if we need
a Num String instance and one is not available.
Now you could argue that
|
Ganesh
Sorry to be slow on this. Thanks for the bug report.
| Now 6.6 is happy. But 6.8 doesn't believe they are the same, and rejects
| it. I finally got it to work with both by removing the forall in the
| So, is there a good explanation of the errors from 6.8? Is 6.8 behaving
| as expected?
We are working on a substantial re-engineering of GHC's code generation, so
this problem will eventually go away. But think 2008 not Christmas 2007.
Meanwhile does -fasm work?
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Duncan Coutts
| Pragmas all take the form {-# word ... #-} where word indicates the type of
| pragma, and is followed optionally by information specific to that type of
| pragma. Case is ignored in word.
|
| However, when I use Language CPP instead of LANGUAGE CPP in the pragma,
| the pragma is ignored. Is
to an unexpected
interaction that I have yet to sort out!
http://hackage.haskell.org/trac/ghc/ticket/1496)
Simon
| -Original Message-
| From: Remi Turk [mailto:[EMAIL PROTECTED]
| Sent: 20 October 2007 21:25
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org; Jean-Philippe
I don't see how that could *ever* have compiled.
From MinHeap:
data Min h a = E | M a h deriving (Eq)
From UnbalancedSet:
data Set a = E | T (Set a) a (Set a)
So the type synoynm for FastClasus is ill-kinded, as GHC says.
Simon
| -Original Message-
| From: [EMAIL
| What does this imply for 6.8 support for FD's, as they now use
| the same type-coercions?
Actually FDs do not use type coercions, in GHC at least. As Mark originally
described them, FDs guide inference; and in particular, they give rise to some
unifications that would not otherwise occur.
|
| Of course none of this is implemented!
|
| But it all sounds very cool. I would like it. :-)
...and you shall have it :-)
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
| But the problem in the HList example is that two equations apply where the
| most specific one should be taken.
There is no difficulty in principle with this. You just need to state (and
implement) the rule that the most specific equation applies. That is, there's
no reason in principle you
| To: glasgow-haskell-users@haskell.org
| Subject: Re: type families not advertised for 6.8
|
| Am Freitag, 19. Oktober 2007 09:25 schrieb Simon Peyton-Jones:
| […]
|
| Our current plan is to regard FDs as syntactic sugar for indexed type
| families. We think this can be done -- see our IFL
| - the list of outstanding issues for 6.8 branch is suspiciously long. has
| this been reviewed in detail?
Good point, Claus. Lots of people are using GHC for lots of things. This is a
nice problem to have! But it does lead to lots of bug reports. We have
limited resources, so we have
| For actual arguments of f, there is no issue whatsoever with
| decidability. The type checker in my brain uses unification, i.e.
| top-down. The type checker in GHC uses inference, i.e. bottom-up. Why
| inference potentially suffers from non-termination for this program, I
| understand.
I think you'll find it useful to be explicit about what you are relying on.
For example I think that if your program contains two calls
unsafePerformIO e1
unsafePerformIO e2
then
* You don't care about the *order* in which these are performed
* You do care that they are both
| Absolutely not; quite the reverse. It means that some of the *code* for
| type functions happens to be in the 6.8 release --- but that code has bugs.
| It's only in 6.8 for our convenience (to avoid too great a divergence between
| the HEAD and 6.8), but we do not plan to *support* type
|
| simonpj writes there:
| Manuel is about to nuke the old GADT stuff in favour of the new type-
| family
| stuff.
|
| This doesn’t mean that GADTs are being dropped in favor of type
| families, does
| it?
|
No... it's an implementation matter only, invisible to programmers
Simon
Looks wrong! You don't say what version. Not happening with 6.6.1 or the 6.8
release candidate
ghc-6.8.0.20070916 -c -ddump-stg T1.hs -O
STG syntax:
T1.map =
\r [f_s6M ds_s6H]
case ds_s6H of wild_s6S {
[] - [] [];
:
| For example:
|
| f =
|let g = (THUNK h x)
|in (CONS g y)
|
| Is this exactly the same as (right variant following the paper)
|
| f =
|let g = (THUNK h x)
|in let freshvar = (CONS g y)
|in freshvar
Yes that's right. The only problem with the latter is that it's
I believe this is a known problem with OPTIONS_GHC, and will work on the
command line. I think Ian is working on it. Ian?
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Bas van Dijk
| Sent: 19 September 2007 13:20
| To:
| BTW, should I be reporting bugs with the release candidate on this
| list or via the usual trac?
Via Trac please. Can you give instructions to reproduce, please?
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Adrian Hey
| Sent: 19
You're asking for something tricky here.
|type family NameCmp n m
|
| which totally orders datatypes. More precisely, it should return one
| of the following types:
|
|data NameLT = NameLT
|data NameEQ = NameEQ
|data NameGT = NameGT
Now, whenever you declare a new
[Redirecting to GHC Users which is the right place for questions about GHC.]
Yes, the garbage collector will (well, certainly should) find and kill such
threads. By kill I mean that they get sent an asynchronous exception of some
kind (I hope the documentation says which) so that the thread
case e of b { pati - rhsi }
* evaluates 'e',
* binds the resulting value to 'b',
* performs case analysis on the result to find which alternative to choose
* binds the variables of the pattern to the components of the value
This is described in the GHC commentary:
:[EMAIL PROTECTED] On
| Behalf Of Matthias Neubauer
| Sent: 11 September 2007 22:04
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@haskell.org; benedikth; Peter Tanski
| Subject: Re: FFI Bindings to Libraries using GMP
|
| Simon Peyton-Jones [EMAIL PROTECTED] writes:
|
| Peter Tanski did exactly
| I've been struggling using FFI bindings to libraries which rely on the
| GNU Mp Bignum library (gmp) - this is apparently a well known problem
| (http://hackage.haskell.org/trac/ghc/ticket/311,
| http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes).
| I do rely on using such libraries,
| I know this is a sensitive issue and I absolutely don't want to start any
| kind of discussion about the merits or otherwise of LGPL, but I was
| wondering if there are any plans to remove the GNU mp library from the
| runtime so that it would be possible to distribute native executables
|
I'm not sure what you are suggesting here. Can you be more explicit?
| -Original Message-
| From: Isaac Dupree [mailto:[EMAIL PROTECTED]
| Sent: 09 August 2007 10:51
| To: Simon Peyton-Jones
| Cc: GHC Users
| Subject: Re: wondering about -ddump-parsed, rn
|
| Simon Peyton-Jones wrote
| I see Simon PJ has removed the wrong -ddump-parsed parentheses :)
Ah yes, should have mentioned that. I think it's better now; turned out to be
quick and easy. -dppr-debug shows the old form, for GHC debugging.
Simon
___
Glasgow-haskell-users
-ddump-parsed shows the program after parsing. All operator application are
parsed *left-associative* with one precedence. Then the renamer re-associates
them to respect precedence and associativity.
So, no, -ddump-parsed will definitely not give syntactically valid Haskell.
-ddump-rn
| I was wondering why we don't have an annotation or pragma for function to tell
| the compiler that we _need_ this particular recursive function to be unfolded.
| If the compiler cannot do this for some reason it should produce an error
| message to help you modifying your code. I have regularly
| However my point was more on a semantic point of view: If I write a function
| in a recursive way, but actually do nothing else than a loop, I would like
| a) that the compiler unrolls it to a loop and
| b) that I can specify such a requirement, while violating it emits an error.
What does it
| {-# INLINE f #-}
| f x y z = ... f x' y' z' ...
|
| into this:
|
| {-# INLINE f #-}
| f x y z = f' x y z
| where f' x y z = ... f' x' y' z' ...
|
| That is, shoving (all of) the recursion in a level. Then inlining f
| results in a fresh loop, which presumably can be specialized
Very curious. It does indeed look as though the strictness analyser is
confused; but it should certainly not be confused by mutual recursion. I'll
definitely look into it. But don't hold your breath -- it's a very busy
fortnight.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
| Add {-# OPTIONS_GHC -fno-mono-pat-binds #-}
|
| You are the fourth person to discover monomorphic pattern bindings :)
Yes, the details are here
http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphicPatternBindings
If you could snip out the code that gave rise to the error,
| You might expect there to be a prefix form of the unboxed tuple:
|
| Prelude case (#,#) 1 2 of (# a , b #) - error $ show (a,b)
| interactive:1:7: parse error on input `,'
|
| But there isn't.
No real reason why not. If you write
foo :: a - b - (# a,b #)
foo x y = (# x, y #)
then foo should
| one particular feature i wanted in my fast io/serialization libs is
| ability to return unboxed tuple from IO action. is this also possible?
No -- that's an example of instantiating a polymorphic type with an unboxed
one. Sorry.
S
___
Philip
Have you read Understanding functional dependencies via Constraint Handling
Rules?
http://research.microsoft.com/~simonpj/papers/fd-chr
If not, I urge you to consider doing so. It goes into the whole thing in great
detail. I'm submerged for the next 3 weeks, though others may
| I've started using template haskell (replacing some preprocessor stuff)
|
| However I had real trouble when trying to convert
| instance (Show d) = Show (C d)
| where show _ = C ++ (show (undefined :: d))
This isn't a bug. Haskell 98 doesn't have scoped type variables, so your
program
| BTW: I don't really like Windows .. but I want to see Haskell
| succeed. Trying to do Haskell on Windows without MSVC++ toolchain
| is like trying to work on Linux without binutils... :)
|
| This is a fine point, and probably the biggest reason for doing a
| Windows native
| port. I'd like
| Meanwhile, I should probably do no w/w for NOINLINE things.
I've now done this in the HEAD: no worker/wrapper split for NOINLINE things.
Yell if anything breaks, but I don't see that anything bad should happen.
Simon
___
Glasgow-haskell-users
| The rules do not fire. They only seem to fire if the specialized
| function is called directly, such as
|
| doSomethingWith ( zipWith (-) (u :: Vec Three Double) v )
That's probably because to fire
distance must be inlined
but sumV and mapV must not
which is obviously a bit
| No, I don't want to duplicate. But in my example the let var was only
| used once, so there was no sharing problem.
Not so in general -- floating outside a lambda that is called many times can
dramatically increase sharing.
You're right that all you want is to *forgo* an optimisation; but I
| This is a bit disappointing of course, so how do we fix it. There are
| two possibilities as far as I can see. Either don't let float it, or
| have the rule matcher look through the indirection.
This is a tricky one. One possibility would be to postpone full laziness until
later in the
| So it seems to me that NOINLINE should prevent inlining but not prevent
| calling the worker rather than the wrapper. I don't fully understand how
| NOINLINE interacts with the worker/wrapper transform (or I wouldn't have
| been surprised by this behaviour). I'm guessing that it works by doing
|
| But that allows it to be inlined in phase 0, and that's exactly what I
| don't want. I really do not want this function inlined, I want it to be
| a join point.
Remind me why you really don't want it inlined, ever? Even if it's small etc.
S
___
| Another question: was there any significant optimization or
| performance change in the front-end (ie.: generation of Core/STG tree)
| since GHC 6.2.2?
Well, I think the core code is a bit better (i.e. more optimised) but it's the
same old Core.
Simon
Good questions.
Fwding to GHC users, to get myself out of the inner loop
Simon
-Original Message-
From: Kenny Zhuo Ming Lu [mailto:[EMAIL PROTECTED]
Sent: 30 May 2007 12:44
To: Simon Peyton-Jones
Subject: GHC as a library
Dear Simon,
I would like to bother you with some questions
| In typecheckedSource, I can only access the function definitions with
| type annotations, but not the data type declaration.
| In checkedModuleInfo, I can only access the Names of the exported
| entities, and but not their (inferred) types are not present.
You have easy access to the data
| is there any plan to improve GHC's extensibility by providing a
| simpler way to integrante new backends? I worked at Haskell.NET
...
| in GHC's code! I haven't yet figured out how to call the .NET code
| generator from GHC 6.6.1's main function. Further, it would be great
| if there was a
That is indeed odd. As I recall unsafeRead doesn't do array-bound checking, and
that ought to be faster, always. I don't have time to look into this myself
(soon, anyway), but
a) if someone does (look at Core!) I'd be interested to know the outcome
b) unless it turns out to be a red herring,
Maxime, it's a UK holiday today, but I expect Ian will get back to you about
this on Tuesday.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Maxime Henrion
| Sent: 27 May 2007 02:59
| To: glasgow-haskell-users@haskell.org
| Subject: How to
Perhaps you can just write a client to the GHC library that
- constructs a string for your program
- asks GHC to evaluate it just as if you'd typed it at the command line
You may say that a string is a silly thing -- your GA will construct a tree, so
the GHC API should supply a function that
Try -fomit-interface-pragmas
Regardless of optimisation level, this tells GHC to generate only *essential*
info in interface files (notably type signatures). That will kill all
cross-module inlinings, but it will also dramatically reduce cross-module
recompilation dependencies; in fact it'll
| I remember the reason that was unsatisfactory now. The RULES only fire
| at high optimisation levels, whereas for this particular program the
| CAF/unCAF-ness of a function effects whether the program gives the
| correct answer.
That is indeed scary. Would you like to give a small example of
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Neil Mitchell
| Sent: 16 May 2007 10:16
| To: glasgow-haskell-users@haskell.org
| Subject: Avoiding CAF's
|
| Hi,
|
| I'm trying to avoid CAF's being created, and I was wondering how is
| the best way
Duncan
I've been meaning to reply to this.
It's very difficult to get inlining right all the time. Even for a function
marked INLINE, there's really no point in inlining in some contexts. E.g.
map f xs
(don't inline f). Furthermore, for parameter-less things like 'word8' GHC has
to
| I'm replying to a rather old thread here, about unboxing in functions. Duncan
| had a continuation monad which passed around some data type that would be nice
| to unbox. You discussed strictness annotations in function types as a
potential
| solution. I have a different tack on the problem
| Also if stmt =
|
| SomeModule.prettyPrinter foobar
|
| and SomeModule contains
|
| prettyPrinter x = putStrLn $ Pretty: ++ x
|
| then the let binding will not catch it.
Indeed, that's exactly what I meant in my original msg. I have always thought
it ugly that stdin and stdout are
Aha! So the problem is a library change rather than a compiler change. That's
a relief.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Christian Maeder
| Sent: 08 May 2007 22:33
| To: [EMAIL PROTECTED]; GHC Users Mailing List; [EMAIL
| Can we expect a 6.6.1 binary and/or installer for windows sometime?
Sigbjorn Finne, the guy who builds our Windows installer, is totally snowed at
work at the moment. Stay tuned!
Simon
___
Glasgow-haskell-users mailing list
| I am trying to use GHC as a library (see
| http://haskell.org/haskellwiki/GHC/As_a_library ). I want to get all the
| output from an interactive session and put in a GUI. This
| http://haskell.org/sitewiki/images/5/51/Interactive.hs seemed to be a
| nice starting point.
If you want to collect
the base library is in a bit of a sad state.
I think I have fixed it. Try pulling (both compiler and libraries) and try
again
S
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Bas van Dijk
| Sent: 03 May 2007 11:32
| To: Bertram Felgenhauer
|
Following the snapshot distribution link on GHC's download page yields this
http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070404-i386-unknown-mingw32.tar.bz2
That seems to be a tar bundle for Windows; it's not an msi but if you unpack it
you should be able to run it
| Making it possible to use Haskell in mixed language projects with C++
| and Java is obviously a good thing, but it's not really a scalable
| solution to distribute them all together. We should look at how to
| improve cabal+ghc to make it easier to use them as a component of a
| larger system.
Duncan,
I implemented this a couple of weeks ago but forgot to push it. Now INLINE
pragmas survive across interface files. I hope it's useful.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Duncan Coutts
| Sent: 14 March 2007 11:59
| To:
| You can put site:haskell.org in your Google query to eliminate all of
| those sites. Add inurl:WORD for even greater precision.
Good idea.
| Any chance some GHC person could politely request that some of these
| get removed? Having the manual easily searchable is a good thing.
I think you
Tris
Would you care to add some platform-specific notes to
http://hackage.haskell.org/trac/ghc/wiki/Building
?
There is a section for such notes, and they allow you to help other people
falling into the same hole that you did.
THanks
Simon
| -Original Message-
| From: [EMAIL
Ext-core is not a library; spitting it out and sucking it in is an integral
part of GHC.
That said, I think there may be a library for processing the ext-core code
itself (parsing, typechecking etc). I don't think Aaron is working on that.
Also, what you need for your PhD is the spitting-out
| What are the plans for the esc branch?
|
| Are the changing going to be merged?
(For others, Rene is referring to extended static checking for Haskell; see
http://www.cl.cam.ac.uk/~nx200/)
Dana is working hard on it right now. Yes, I very much hope that it'll be
merged back into the HEAD in
Go here:
http://hackage.haskell.org/trac/ghc/roadmap
and click on the active tickets for 6.6.2
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of David Roundy
| Sent: 16 April 2007 18:01
| To: glasgow-haskell-users@haskell.org
|
| - left-to-right impredicative instantiation: runST $ foo
|
| This concerns me. With each ad-hoc extension of the type system, I
| worry that soon the GHC type system will become so byzantine and
| ill-specified that the type checker can only be cloned, not
| substantially improved on
On this
701 - 800 of 1383 matches
Mail list logo
