Re: Assembly decoding help?
On Tue, Mar 04, 2008 at 05:07:03PM -0800, Justin Bailey wrote: I'm trying to get a feel for the assembly output by GHC on my platform. Below is a module containing one function and the associated assembly. I've put in comments what I think is going on, but I'd appreciate it if anyone could give me some pointers. I'd really like to know three things: * Why does _Add_unsafeShiftR_info check if (%esi) is 3? * What's going on in _s86_info? * At the end of _s87_info, 8 is added to %ebp and then jumped to. Is that a jump to the I# constructor and, if so, how did it's address get to that offset from %ebp? Thanks in advance for any assistance! It would be more helpful if you didn't try to go from Haskell to assembly in one step - it's a lot easier to understand each big step of the GHC pipeline individually. Haskell | \- Core (ghc -ddump-simpl Foo.hs Foo.core; or -fext-core if you want something ugly but parsable; an unrestricted but simple expression-functional language) | \- STG (ghc -ddump-stg ...) (Much more regular than Core; more like functional C) | \- C-- (ghc -ddump-cmm) (just what it says: Simplified C for compiler writers. The universal assembly language for the 21st century) | \- assembly Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: a help for install
On Mon, Feb 18, 2008 at 12:46:19PM -0600, Carlos Gomez A. wrote: hi, my name is carlos I need information for correct installor what are dependencies on ghc ? I have a Debian System. I have this message error to install the ghc: Debian-System/haskell/ghc-6.8.2# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Canonicalised to: i386-unknown-linux checking for ghc... no checking for ghc-pkg matching ... no checking for ghc-pkg... no checking whether ghc has readline package... no checking for nhc... no checking for nhc98... no checking for hbc... no checking for ld... /usr/bin/ld configure: error: GHC is required unless bootstrapping from .hc files. Debian-System/haskell/ghc-6.8.2# As the message indicatied, you need GHC if you want to install from source. If you don't have GHC, get a binary (there is one in apt). Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci feature request: partially read modules
On Sat, Feb 16, 2008 at 04:53:24PM +0100, Johannes Waldmann wrote:
Hello.
Here is one ghci feature that I find mildly annoying:
If ghci (re-)reads a module that contains some error,
then it considers the module loading as a complete failure,
and at the prompt I get the Prelude environment.
I'd like to have at least the import statements executed,
and possibly the declarations that were error-free.
That would help me in interactively debugging
the erraneous part of the module.
(Often the error is some type error, related to some imported entity;
but when my module contains the error, then the imports are gone.)
Perhaps I'm doing something wrong, then please educate me;
or perhaps there's an easy way to implement partial reading
and typechecking. (It'd be enough to have this for the current
module, of course.)
Thanks - Johannes Waldmann.
This is fairly easy for type errors - just have the 'type of expression'
function return errors using Either etc, and at the top level drop all
expressions with error type.
As for parse errors - good luck. Haskell is incredibly difficult to
parse even if you ignore several of its less-friendly features. If you
allow them... for a long time I said it had never even been proven
possible, but then I found a workable algorithm exponential in the file
size. Now, how do you propose handling parse errors? Here's an example
of why it's hardly trivial:
foo = x + y + z where {
x = 2;
y = 3;
z = 4;
}
Stefan
signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci feature request: partially read modules
On Sat, Feb 16, 2008 at 06:58:29PM +0100, Johannes Waldmann wrote: Sure. Syntax errors are usually easy to spot and fix (for the programmer who uses some reasonable code layout); the motivation for my proposal was type errors. I think it would be perfectly acceptable if ghci rejects modules with parse errors (as it does now) but handles modules with type errors more gracefully. Since type checking a group of declarations (= a module) often considers all declarations at the same time, there may be no sensible way to proceed after a type error. Then it would even be OK to not bind any of the identifiers of the module, as long as the import declarations are available at ghci prompt. (This would still be an improvement over the present situation.) Implementing Haskell polymorphism requires that the functions be sorted into dependancy groups, so that undepended definitions can be generalized. Example: foo x = 2 bar = foo 'a' + foo True If this were typechecked all at once (using the standard Damas-Milner algorithm) you would get a cannot match Bool to Char type error. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC lazy eval optimization bug
On Sun, Feb 03, 2008 at 02:37:42PM -0500, Adam P Jenkins wrote: The haskell program below demonstrates an optimization bug with the GHC compiler. I have tried this with ghc 6.8.1 on my MacBook Pro and on a Linux i686 machine. This email should build as a literate haskell program. Build the program as While this may be unfortunate, it is a consequence of document behavior; thus I would not consider it a bug per-se. Try with -fno-state-hack; the documentation for this option, I believe, should explain what is going on. (Hint: IO a ~ State# - (State#, a)) Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: there isn't any difference, is there, with unboxed tuples?
On Fri, Jan 04, 2008 at 09:36:33PM -0500, Isaac Dupree wrote: -- unboxed types in function results are automatically lifted... or what was the term meaning they could be _|_, failing to terminate, (because of the function-ness)? -- unboxed tuples are specially restricted to be only allowed, among useful places, in function results. Therefore (... - ( a, b, c ) ) and (... - (# a, b, c #)) are identical, assuming both are kind-correct (identical in terms of optimization and semantics, not type equality, of course). Is that right? If so, there's never an excuse to use unboxed tuples except to contain unboxed values (because then you don't have the choice of using boxed tuples, which can only contain boxed values of kind *). Semantically, you are absolutely correct. However, there is a very subtle difference in sharing. Consider these two functions: foo (a,b) = (a,b) bar tuple = tuple These two functions are denotationally identical, but at runtime one performs more allocations. If we use unboxed tuples, then the caller must always allocate if a tuple is needed; thus effectively we always get the allocation behavior of foo. That is, return unboxing is not always an optimization! However, it *is* always safe if the tuple is constructed in the function itself, for then it could not possibly be shared with anything. Having explicit unboxed tuples in the language allows this complexity to be moved out of the code generator, which is a Good Thing. (Incidentally, this is what the CPR analysis is all about - identifying places where a Constructed Product is Returned.) Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: whole program optimization
On Thu, Dec 27, 2007 at 01:47:44PM +0100, Wolfgang Jeltsch wrote: Am Sonntag, 23. Dezember 2007 13:35 schrieb Isaac Dupree: GHC optimizes less effectively when parts of a program are in different modules, or are exported from a module. By the way, does GHC do cross-package optimization (not just cross-module optimization within packages)? Yes. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: whole program optimization
On Sun, Dec 23, 2007 at 07:35:20AM -0500, Isaac Dupree wrote: GHC optimizes less effectively when parts of a program are in different modules, or are exported from a module. Therefore, merging all the code into one module Main (main) would help. Unfortunately, Haskell source syntax is ill-suited to this; for example: ... So it's more complicated than it seems on the surface, but it could be done; I only wonder how effective it would be on various programs. I assume GHC doesn't currently implement any optimizations that can _only_ be whole-program, so it would still not be quite like Jhc, though this basic support might allow some such optimizations to be implemented. It's been done. http://www.cs.utah.edu/~hal/HAllInOne/index.html Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr performance
On Mon, Dec 17, 2007 at 02:12:31PM +0300, Bulat Ziganshin wrote: Hello Simon, Monday, December 17, 2007, 1:33:19 PM, you wrote: My question is: what exactly does GHC.Prim.touch# do? This appears to it's a no-op (for ghc 6.6+ at least). its only task is to notify ghc optimizer that data were accessed so it doesn't free the memory Yes, exactly. touch# generates no code, but it is vitally important because if the ForeignPtr is referencing data in the heap (like mallocForeignPtrBytes does), it prevents the data from being GC'd before the operation completes. a bit more details for Scott: generated code is like this: ptr - unsafeForeignPtrToPtr fptr yourAction ptr touch# fptr without touch, the *last* action where fptr involved is its conversion to ptr. GHC Runtime (not optimizer as i said) have no idea that ptr and fptr is the same object, so after conversion it feels free to dispose object pointed by fptr if GC occurs. this means that during execution of your action data pointed by fptr/ptr may be suddenly freed, allocated by other object, bang! I'd like to elaborate that ptr, as far as the GC is concerned is *not a pointer at all*, it is an integer memory address. So it doesn't keep anything alive, you need to hold on to fptr if you want the value to exist. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: newtypes and optimization
On Wed, Dec 12, 2007 at 11:02:15AM -0700, Scott Dillard wrote: with strictness annotations and INLINEs for everything. I also tried automatic newtype deriving, with no luck. Why does a newtype defeat so much of the optimization? Thanks, Scott (Not a GHC developer, but someone fairly familiar with how the Simons work) What version of GHC are you using? The implementation of newtypes was completely redone in the 6.7.x period. Do you have a fairly small complete working example? If so, link to or attach a tarball - will make their jobs much easier. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] class default method proposal
On Tue, Dec 11, 2007 at 02:20:52PM +, Duncan Coutts wrote:
I'd just like to float an idea that's related to the Class Alias
proposal[1] but is perhaps somewhat simpler.
We all know that Functor should have been a superclass of Monad, and
indeed we now know that Applicative should be too. Making such a change
would break lots of things however so the change does not happen.
However in this case the Monad operations can be used to implement the
Functor and Applicative class methods. So it would be nice if we could
get them for free if the author did not choose to write the Functor and
Applicative instances.
So my suggestion is that we let classes declare default implementations
of methods from super-classes.
class Functor m = Monad m where
{- the ordinary bits -}
fmap f m= m = return . f
So if there already is a Functor instance for m then the default
implementation of fmap is not used.
Does this proposal have any unintended consequences? I'm not sure.
Please discuss :-)
Duncan
[1] http://repetae.net/recent/out/classalias.html
This is almost exactly the
http://haskell.org/haskellwiki/Class_system_extension_proposal; that
page has some discussion of implementation issues.
Stefan
signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
On Wed, Nov 21, 2007 at 01:16:34PM -0500, Olivier Boudry wrote: On Nov 21, 2007 1:07 PM, Greg Fitzgerald [EMAIL PROTECTED] wrote: Running 6.8.1 on Windows XP, typing 'main' while :r is still processing causes the 'm' in 'main' to morph to a 'g'. :r [1 of 2] Compiling Language.QidlTypeLibrary.Parser ( Language/QidlTypeLibrary/Parser.hs, interpreted ) Ok, modules loaded: Main, Language.QidlTypeLibrary.Parser. main interactive:1:0: Not in scope: `gain' Thanks, Greg What a weird bug. It sounds like a joke but it isn't one. I just reproduced it (also works with :l). P:\5. Tools\Cleansing\CustomerMasterghci GHCi, version 6.8.1: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude :l CustomerMaster.hs [1 of 1] Compiling Main ( CustomerMaster.hs, interpreted ) Ok, modules loaded: Main. *Main main interactive:1:0: Not in scope: `gain' I wonder if it's a Windows only bug. It's very old. http://hackage.haskell.org/trac/ghc/ticket/831 Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci changing 'm' to 'g'
On Thu, Nov 22, 2007 at 01:12:16AM +0200, Yitzchak Gale wrote: Greg Fitzgerald wrote: Running 6.8.1 on Windows XP, typing 'main' while :r is still processing causes the 'm' in 'main' to morph to a 'g'. Olivier Boudry wrote: it (also works with :l). Stefan O'Rear wrote: It's very old. http://hackage.haskell.org/trac/ghc/ticket/831 But these observations indicate several clues that do not yet appear in the Trac ticket: 1. Occurs on Windows (I can't reproduce it in on Mac OS X Intel or Debian Lenny) That *is* in the ticket - look at the Operating System field. 2. Occurs also with :r and :l, not just evaluating an expression. Personally I think that this is the least relatively suprising behavior, and it would be most noteworthy if it only affected expressions. But others may disagree. Perhaps someone with with a Trac login should make note of them. You have one! User 'guest', password 'guest'. In fact, it says this at the bottom of every page! (Spammers are smart enough to try and create accounts, but can't read page footers - go figure). Remember to sign your comment with contact info. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Exposed module still hidden, why?
On Tue, Nov 20, 2007 at 12:18:57PM -0800, Greg Fitzgerald wrote: Using GHC 6.8.1 on Windows XP, after having used ghc-pkg to expose ' directory-1.0.0.0', I am getting an error when I build haddock that says the package is hidden. When I type ghc-pkg list, the package is not in parenthesis. Typing ghc -v says that it is using the file from C:\ghc\ghc-6.8.1\package.conf. That package.conf file has the 'exposed' set to True for that file. Why does GHC still think the package is hidden? ...\haddock-0.8runhaskell Setup.lhs configure Configuring haddock-0.8... ...\haddock-0.8runhaskell Setup.lhs build Preprocessing executables for haddock-0.8... shift/reduce conflicts: 5 Building haddock-0.8... src/Main.hs:49:7: Could not find module `System.Directory': it is a member of package directory-1.0.0.0, which is hidden ...\haddock-0.8ghc-pkg list C:/ghc/ghc-6.8.1\package.conf: Cabal-1.2.2.0, HUnit-1.2.0.0, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, Win32-2.1.0.0, array-0.1.0.0, base-3.0.0.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.0, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.1), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.1, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, xhtml-3000.0.2.1 This is a Cabal FAQ. Cabal passes -hide-all-packages to GHC to prevent undeclared dependancied from creeping in; so you have to explicitly depend on all used packages. (Would someone who is involved with the cabal web site PLEASE put this up somewhere? FAQs do no good if they have to be typed by humans!) Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
On Sun, Nov 11, 2007 at 03:02:56PM +0300, Bulat Ziganshin wrote: Hello Barney, Sunday, November 11, 2007, 2:34:14 PM, you wrote: An important application which is made impossible by this approach is i propose to start Records project by composing list of requirements/applications to fulfill; we can keep it on Wiki page. this will create base for language theorists to investigate various solutions. i think they will be more motivated seeing our large interest in this extension +1 Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
On Sat, Nov 10, 2007 at 06:35:34PM -0500, Seth Kurtzberg wrote: 6.10? I think that's a typo as the current version is 6.8.1. Or did I misunderstand what you were saying? 6.8.1 is released, there is abolutely no way new features are going to enter a published version. Hence, 6.10. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible Records
On Sat, Nov 10, 2007 at 06:35:34PM -0500, Seth Kurtzberg wrote: Is there any chance of seeing extensible records in GHC 6.10? There seems to be widespread agreement that the current situation is unacceptable, but the official GHC policy is that there are too many good ideas to choose from - so nothing gets done! I hence humble propose that http://www.cs.uu.nl/~daan/download/papers/scopedlabels.pdf be adapted to GHC. In my naivete, I assume that porting an existing implementation would be much easier than starting from scratch. Is this reasonable? N.B. I am aware that GHC has limited resources - many thanks to Simon Simon and all other contributors either way. I second this request. Yes, I know you *could* do something in a library; but it's MUCH nicer as a built-in feature. Sadly. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prevent optimization from tempering with unsafePerformIO
On Tue, Oct 16, 2007 at 04:06:26PM +0200, Bernd Brassel wrote: Hi Neil, hi Don! Nice meeting you at ICFP by the way. Can you give a specific example of what you have tried to do, and how it failed? I have attached a short synopsis of what our Curry to Haskell conceptually does. I could explain what all the parts mean and why they are defined this way, if it is important. On first glance it looks as if we were doing unsafe things in the very worst way. But the invariants within the generated code clean up things again. E.g., the result of main does not at all depend on whether or not the program is evaluated eagerly or lazily. I hope it is okay that I did not add any no-inline pragmata or something like that. Unfortunately, I forgot all the things we have tried more than a year ago to make optimization work. Might I suggest, that the problem is your use of unsafePerformIO? If you use unsafePerformIO in accordance with the rules listed in the specification (which happens to be the FFI addendum), -O options will have no effect. (Not that what you are trying to do is achievable with correct use of unsafePerformIO; why do you want to do this unsafely, instead of just using 'length'? unsafePerformIO is a very slow function, remember) Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Generics in 6.8.0 RC
On Sat, Sep 22, 2007 at 10:45:50AM +0200, Dirk Kleeblatt wrote: Dear *, I just failed to get generic classes working with snapshot ghc-6.8.0.20070920-i386-unknown-linux.tar.bz2. Are generics broken in the RC, or am I doing something wrong? I tried the following module: ... Gen.hs:13:0: Can't find interface-file declaration for variable GHC.Base.$gfromBool Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the first argument of `a', namely `(GHC.Base.$gfromBool b)' In the first argument of `(\ a - a)', namely `(a (GHC.Base.$gfromBool b))' In the expression: (\ a - a) (a (GHC.Base.$gfromBool b)) Failed, modules loaded: none. This is definitely a GHC bug: http://hackage.haskell.org/trac/ghc/wiki/ReportABug Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unique id for data types
On Tue, Sep 18, 2007 at 04:41:33PM +0100, Barney Hilken wrote: Hi Simon, thanks for the response. In fact I really only need NameCmp to be defined for datatypes of the form data T = T but it's still a lot, so I was expecting to need an extension. Lexical comparison of fully qualified names is what I had in mind, but I wanted some confirmation that such things exist! I could post a GHC feature request, but unless I get someone else interested in this, it would probably just sit in Trac indefinitely. Where should I look in the ghc source if I want to add it myself? As usual, Oleg solved this problem long ago. I don't remember a citation, but the gist of the procedure is: data HCons a b data HNil type family TTypeOf a :: * type instance TTypeOf Int = ...ascii code for 'I' 'n' 't' represented using HCons/HNil... ... type family Combine a b :: * type instance Combine LT a = LT type instance Combine EQ a = a type instance Combine GT a = GT type family NumCmp a b :: * type instance NumCmp HNil HNil = EQ type instance NumCmp HNil (HCons a b) = LT type instance NumCmp (HCons a b) HNil = GT type instance NumCmp (HCons a b) (HCons c d) = Combine (NumCmp a c) (NumCmp b d) type family TypeCmp a b :: * type instance TypeCmp a b = NumCmp (TTypeOf a) (TTypeOf b) The O(n) remaining instances can be automated with my Data.Derive.TTypable, if you're willing to switch back to functional dependancies. (Simon, can a TF 'wrapper' for a fundep be meaningfully done?) Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 RC debugger only breaking on first evaluation of a function
On Tue, Sep 18, 2007 at 02:26:38PM -0400, Olivier Boudry wrote: Hi all, I just tried the new GHCi debugger. A great new feature of GHCi 6.8.1. When debugging a function, as for example the qsort function given as an example in the 3.5 The GHCi Debugger documentation page, the debugger will only break on first function evaluation. As haskell is pure and lazy it's probably a normal behavior (reuse last result instead of recompute) but it's not very practical in a debugger. I tried to reload (:r) but it doesn't seems to help. Is there a way to force the function to be re-evalutated without quitting, starting, loading prog and setting breakpoints again, other than making the function part of the IO monad. ;-) There is a flag to do this, and it's even In The Manual! http://haskell.org/ghc/dist/current/docs/users_guide/ghci-set.html#id313085 3.8.1. GHCi options GHCi options may be set using :set and unset using :unset. The available GHCi options are: +r Normally, any evaluation of top-level expressions (otherwise known as CAFs or Constant Applicative Forms) in loaded modules is retained between evaluations. Turning on +r causes all evaluation of top-level expressions to be discarded after each evaluation (they are still retained during a single evaluation). This option may help if the evaluated top-level expressions are consuming large amounts of space, or if you need repeatable performance measurements. ... Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Status of GHC runtime dependency on GNU multi precision arithmetic library
On Wed, Aug 22, 2007 at 10:32:36AM +0100, Simon Peyton-Jones wrote: | There is an interest in removing GMP, motivated partly by licensing but | also due to portabiltity concerns and the fact that the use of GHC's | memory manager in GMP prevents FFI code from using GMP safely. | | http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes Just to summarise our position at GHC HQ on this question: * We don't much like bundling GMP either. But it works and it's fast. ... * We'd be very happy to have others work on a replacement (a) using a another C library (b) using a Haskell library ... * To replace GMP altogether we'd need to be convinced that we would not lose much performance. ... * There are one or two arbitrary precision libraries in Haskell eg http://www.haskell.org/pipermail/libraries/2007-August/007909.html Another possibility that occured to me recently, is to switch Integer to a simpler (perhaps even pure-Haskell) representation, and provide (core? extra? Hackage?) a hsgmp package. If you have big numbers, switching is easy: import Prelude hiding(Integer) import Data.Integer.GMP type Integer = MPZ Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Qualified identifiers opinion
On Fri, Aug 17, 2007 at 12:53:11PM +0200, Christian Maeder wrote: Hi Isaac, just to give you a reply at all, see below. I reply glasgow-haskell-users@haskell.org since I'm not subscribed to haskell-prime. And I don't want to subscribe, because I'm more interested that Haskell becomes more stable (and standard). So here is my opinion: 1. The lexer should recognize keywords. 2. I would not mind if Haskel98 rejected all keywords that are also rejected by extensions, so that the lexer is extension independent. (Starting with Haskell98, removing conflicting identifiers as soon as I switch on valuable extensions does not make sense.) 3. I'm against qualified identifiers, with the unqualified part being a keyword like Foo.where. (The choice of qualification should be left to the user, usually one is not forced to used qualified names.) 4. However, Foo.where should always be rejected and not changed to Foo.wher e! (Longest matching, aka maximal munch, must not consider keywords!) (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) I would not mind if a name F. is plainly rejected. It only makes sense, when a data constructor is the first argument of the composition operator (.) Maybe . and $ as operators should require white spaces on both sides, since $( also indicates template haskell. What's wrong with the status quo? Our current lexical rules *seem* complicated to newbies, but just like everything else in Haskell it carries a deep simplicity; having only one rule (maximal-munch) gives a certain elegance that the proposals all lack. I'd hate to see Haskell become complex all the way down just to fix a few corner cases; I see this pattern of simplicity degerating through well-intentioned attempts to fix things all over the language... Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Status of GHC runtime dependency on GNU multi precision arithmetic library
On Wed, Aug 15, 2007 at 06:41:53PM +0100, Brian Hulley wrote: Hi, 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 compiled with GHC without having to deal with the additional issues raised by the current inclusion of this LGPL component in the runtime. (Afaik everything else in ghc is under a BSD3 license.) There is an interest in removing GMP, motivated partly by licensing but also due to portabiltity concerns and the fact that the use of GHC's memory manager in GMP prevents FFI code from using GMP safely. http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes It's less of an issue on Linux where libgmp is dynamically linked but when thinking about using Haskell ghc for creating Windows apps it is for me a real problem, because it would mean I'd have to distribute the code for my app as a library along with the code as an executable, thus doubling the download size for my apps as well as having to include a license that has to explain to a possibly non-technical user that although the program includes code that is libre/gratis free the program is not itself free etc etc... Huh? AFAIK the LGPL is only an issue for the commercial/proprietary users of Haskell; gratis/libre works would continue to be gratis/libre after linking with GMP. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: (Compile ghc 6.7) Cannot find package base
On Sun, Aug 12, 2007 at 10:05:17AM +0200, Mads Lindstrøm wrote: Hi all I tried compiling ghc 6.7 during the night. I used the following script: ... Failed to load interface for `System.IO': Use -v to see a list of the files searched for. ghc-6.7.20070810: panic! (the 'impossible' happened) (GHC version 6.7.20070810 for i386-unknown-linux): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Is this really a bug or am I doing something wrong? This is almost certainly a bug, and you are at least the fourth person affected. Magnus Therning claimed on the #ghc IRC channel earlier to have a complete fix, which will be published in a few hours after he's awake again. (As a check, you may want to try *compiling* a trivial module. The symptom seen by the previous three people was Failed to load interface for `Prelude', and the 'ghc-pkg list' reveals only ghc and rts.) Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: wondering about -ddump-parsed, rn
On Thu, Aug 09, 2007 at 06:51:12AM -0300, Isaac Dupree wrote:
Simon Peyton-Jones wrote:
-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 probably will though.
yes, in that case, would anyone mind if I find an easy way to change GHC to
parenthesize those non-infix uses of operators? :) hmm... maybe _I_ would
mind, since it makes what GHC is doing just a tiny bit less transparent
to the user of -ddump-{rn,parsed}. :-)
I fixed an identical bug in a copy of the code a few months ago.
http://haskell.org/pipermail/libraries/2007-April/007317.html
Unfortunately, I think TH was forked off from the in-compiler syntax
tree too long ago for my fix to be useful...
Stefan
signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?)
On Fri, Aug 03, 2007 at 09:01:18PM -0300, Isaac Dupree wrote: Tim Chevalier wrote: On 8/3/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Stefan is right here. - It's not surprising that with -Onot you get different code from different source programs, even if one can readily be transformed into the other. That's what -O does. Yes, but I found it surprising that just removing a type signature should result in markedly different code. Are there other known situations where that can happen? It is not _just_ removing a type signature, it is also changing the type from `Bool` to `forall a. a`. An explicit type signature of the latter would have produced the same results as no type signature, I believe. The surprise is that an unconstrained type-variable being variable rather than instantiated to an arbitrary type, makes any difference (since it doesn't, normally, at runtime). I would guess the programs `Bool` and `a` are the same once optimizations are turned on? Maybe GHC could avoid the creation of type-lambdas that are unused (in some sense)... with -Onot... I'm dubious about that. It *does not change the designed semantics at all*. It *tickles a bug*. In the *absence of code generator bugs* it generates *semantically equivalent code*. Do you want inserting or removing type signatures to always tickle the same bugs? Seems like an awfully constraining desgin choice to me. Inserting a preemption test in non-allocating loops seems like a good idea to me (I hate the invisible threat that my program might not thread as threading should work)... any idea how bad the performance impact could be (I guess the test could be specified to branch-predict that the loop wouldn't be interrupted), and whether there could be a pragma to disable that test in certain loops? Is -threaded versus not, relevant here? signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Annotation for unfolding wanted
On Wed, Aug 01, 2007 at 09:42:54AM +0200, Georg Martius wrote: Hi, I am sorry for using the wrong terminology here. Let me ask again: Does it sound reasonable to extend the compiler with a pragma that specifies that a certain function should be compiled to a loop? And if the compiler can not do it, it helps with some error message. Unfortunately, that's still almost useless in the presence of laziness. Take the following (contrived) example: fib :: Int - (Int,Int) - (Int,Int) fib 0 p = p fib k p = fib (k-1) (snd p, fst p + snd p) That compiles to a perfectly reasonable loop: (minor code rearrangement and bounds-checks deleted for clarity) X_zdszdwfib_info: Hp = Hp + 16; _sjD = I32[Sp + 8]; if (_sjD == 0) goto clk; _sjF = _sjD - 1; I32[Hp - 12] = sjC_info; I32[Hp - 4] = I32[Sp + 4]; I32[Hp] = I32[Sp]; I32[Sp + 8] = _sjF; I32[Sp + 4] = I32[Sp]; I32[Sp] = Hp - 12; jump X_zdszdwfib_info (); clk: I32[Hp - 12] = base_DataziTuple_Z2T_con_info; I32[Hp - 8] = I32[Sp + 4]; I32[Hp - 4] = I32[Sp]; R1 = Hp - 12; Sp = Sp + 12; Hp = Hp - 4; jump I32[Sp] (); Yet still: Prelude X fib 1000 (1,1) (*** Exception: stack overflow Since while *your function* may be a loop, the thunks it builds are evaluated in a way that isn't. Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problem compiling an older Haskell program with GHC 6.6.1
On Sat, Jul 07, 2007 at 03:59:48PM -0400, Scott Stoller wrote: hi, I really appreciate the amazingly fast and helpful feedback to my previous message. that problem (FiniteMap not found) is solved. but a new problem came up... I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with GHC 6.6.1 (the Solaris 10 / x86 binary distribution). now I get the error Data.hs:760:20: Not in scope: 'bounds' Data.hs is one of the files in the program. here is the nearby code: updateTable :: Hash a = a - IO b - Table a b - IO b updateTable x my (MkTable ref) = do MkHTab n arr - readIORef ref let (_,size) = bounds arr hashx= hash x i= hashx `mod` size ... in case it's helpful, the entire paradox source code is at http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz just delete -package lang from the Makefile before running make. Bounds was removed in 6.4.x to allow for dynamically sized arrays; it should work as: updateTable :: Hash a = a - IO b - Table a b - IO b updateTable x my (MkTable ref) = do MkHTab n arr - readIORef ref (_,size) - getBounds arr let hashx= hash x i= hashx `mod` size Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: type error when compiling an older Haskell program
On Sat, Jul 07, 2007 at 10:53:17PM -0400, Scott Stoller wrote:
hi,
thanks to Stefan, I am past the second problem in compiling this program
(needed to change 'bounds' to 'getBounds'). now I get a more intimidating
error message...
I am trying to compile paradox 1.0, an older (GHC 5) Haskell program, with
GHC 6.6.1. I get the intimidating error message shown below. I would
appreciate any advice about how to fix this. I am guessing that the
problem might be a change in the type of some library function.
best regards,
scott
p.s. the file causing the error is in the paradox source code at
http://www.cs.sunysb.edu/~stoller/out/paradox-1.0-casc.tar.gz
Add {-# OPTIONS_GHC -fno-mono-pat-binds #-}
You are the fourth person to discover monomorphic pattern bindings :)
As an experiment, the GHC team has changed GHC to make pattern bindings
(like MkT m = tm) default to only produce values usable at one type.
The full generality of Haskell-98's rules complicated the
implementation, and the idea was that if sufficiently few people
complained, the next version of Haskell could use simpler rules. (at
least that's how *I* remember the explanation.)
Another workaround is to do it with an explicit unwrap:
where m = case tm of MkT m - m
instead of
where MkT m = tm
Stefan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
On Mon, Jun 18, 2007 at 11:56:57AM -0400, Peter Tanski wrote: Now each GHC-Haskell-based program installer would search /usr/local/ lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall? The same thing you get on Windows when you have another program using a particular .DLL--the uninstall of that version of the library would fail but for unix systems _only_ if you also have another program using at while you are doing the uninstall. So if you did not break everything on each install, eventually you have a complete mess of different versions of GHC libraries in /usr/local/lib that may have no current use but at one time were used for several GHC-Haskell-based programs that have now been upgraded to use something different. Hopefully those who distributed the binary programs adopted a convention of using the full version of the library instead of symlinking libHSrts_dyn-6.6.1 to libHSrts_dyn, or as a user several of your older programs might break after a later one installed a new version of the library and symlinked that the new version... That is why I think your idea was good: put everything into distinct directories. Debian's high level package manager will automatically garbage collect dependancies, such that every package on your system is either manually selected for install or a dependant of one. Thus there is no library leak problem. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Crosscompile
On Mon, Jun 18, 2007 at 05:49:29PM -0700, Anatoly Yakovenko wrote: how portable are the .hc files? do they depend on some library that needs to be built for the target? Would they generate read only position independent object code (no writable global variables)? Thanks, Anatoly You're probably better off just installing GHC/Alpha. (You do have a simulator!) It won't take as long as getting hc to work :) Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
On Wed, Jun 13, 2007 at 03:00:04PM +0200, Clemens Fruhwirth wrote: 3) Running programs Let's see how libtool handles this situation. I would recommend against following libtool's lead in this area. Libtool's fondness for cooking RPATH into binaries makes it very difficult to deal with, because it's quite common for those binaries to get installed and distributed, RPATH and all. RPATH should only be used by a user who knows they have a large-calibre weapon pointed at their foot. Did I understand that correctly that you don't want to see binaries with rpath's pointing to install directories such as /usr/lib/gcc-6.6? So, this forces us to use a wrapper in all cases. Please think seriously about mangling the names of Haskell libraries to include version information and dropping them in $PREFIX/lib with every other language's libraries. Haskell is not special, and users expect libraries to be in /usr/lib. No wrapper needed, no RPATH needed, as far as I can see no fanciness at all. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
On Wed, Jun 13, 2007 at 10:05:11AM -0500, Rich Neswold wrote: On 6/13/07, Stefan O'Rear [EMAIL PROTECTED] wrote: Did I understand that correctly that you don't want to see binaries with rpath's pointing to install directories such as /usr/lib/gcc-6.6? So, this forces us to use a wrapper in all cases. Please think seriously about mangling the names of Haskell libraries to include version information and dropping them in $PREFIX/lib with every other language's libraries. Haskell is not special, and users expect libraries to be in /usr/lib. No wrapper needed, no RPATH needed, as far as I can see no fanciness at all. Actually, Haskell libraries ought to be placed in /usr/local/lib (or /usr/pkg/lib for systems that use the Package System: http://www.pkgsrc.org). Haskell libraries shouldn't mingle with the base OS libraries. But it shouldn't be separate from the other third-party libraries, either. No, haskell libraries ought to be placed in /usr/lib when they are being installed by the OS. I don't want my GHC 6.8 debian install to pollute /usr/local. (/usr/local is fine for local builds of course; that's why I used $PREFIX). Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Locating shared libraries
On Wed, Jun 13, 2007 at 11:33:36AM -0700, Bryan O'Sullivan wrote: Clemens Fruhwirth wrote: Libtool's fondness for cooking RPATH into binaries makes it very difficult to deal with, because it's quite common for those binaries to get installed and distributed, RPATH and all. RPATH should only be used by a user who knows they have a large-calibre weapon pointed at their foot. Did I understand that correctly that you don't want to see binaries with rpath's pointing to install directories such as /usr/lib/gcc-6.6? That's right. So, this forces us to use a wrapper in all cases. Not necessarily. Many systems provide a global mechanism to manage the paths that ld.so searches for shared objects. This is the standard on Linux, for example (/etc/ld.so.conf). For systems that don't provide this mechanism, one possibility would be to provide an option that cooks the rpath in. Or better yet, put them directly in one of the LD_LIBRARY_PATH dirs. $PREFIX/lib/ghc-$VERSION is a relic of the static library system and IMO shouldn't be duplicated. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.6.1 on Debian Etch?
On Tue, Jun 05, 2007 at 10:13:41PM +0200, Wagner Ferenc wrote: Hi, what's the best way to install GHC 6.6.1 on a Debian Etch system? Basically: are there installable packages available somewhere, or should I recompile the Sid packages, or create a stub package from a binary .tar.gz bundle, or some other option I didn't think of? Yes. Install the binary .tar.gz bundle *without creating a stub package* It installs in /usr/local, so dpkg must not know about it. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Prelude not in haskell98?
On Wed, Jun 06, 2007 at 12:39:20AM +0100, Ian Lynagh wrote: On Tue, Jun 05, 2007 at 11:23:57PM +0100, Neil Mitchell wrote: All this seems to indicate that the Prelude is not a part of the haskell98 package. Is this the case, and if so, is this intentional? It would be nice if we could create Cabal packages that explicitly indicate that the library depends only on Haskell 98 libraries. Its true, and its intentional. The trend nowadays is to make programs depend only on base, not only on haskell98 - i.e. import System.Environment (and others) instead of System. hakell98 will be around forever, but base is the new standard libraries set. Right, the problem is that if Prelude was in haskell98 then it wouldn't be possible to have a program that /didn't/ depend on haskell98 (short of -fno-implicit-prelude extensions, or having a Prelude in both (which would mean you couldn't depend on both base and haskell98)). There's also a pragmatic reason. Currently it is impossible to have a cycle of module imports cross package boundaries; so if the Prelude was in haskell98, then (since the Prelude depends on non-haskell98 base modules for its implementation) *Nothing* in base could use the prelude. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 2-days old in Haskell
On Fri, Jun 01, 2007 at 04:00:51PM +0200, TOPE KAREM wrote: I am very new to Haskell, and I am using this webpage as a learning source: http://www.haskell.org/haskellwiki/Haskell_in_5_steps#Install_Haskell I downloaded and instal GHC and it works as was said. I tried to write my first Haskell program: prelude Hello World! Hello World, World! it works as said. Then: (This is the problem) I would like to create a source code and compile it using GHC compiler. I opened a notepad and type this program: main = putStrLn Hello, Word! I saved this file as hello.hs in the same directory GHCi 6.6.1 was installed. When I tried to compile it as instucted on the webpage ( $ ghc -o hello hello.hs), I got this error message. interactive: 1:0: parse error on input '$' please what am I doing wrong. Thank you and sorry for your time. Three things: 1. The $ is just a sample prompt, a convention used to indicate what you should typed. 2. The command is for a shell (CMD or COMMAND), not GHCi. 3. The command is wrong! for Windows it should be ghc -o hello.exe hello.hs. Assuming you aren't knowledgable yet on the differences between Windows and Unix programming environments, it might be a good idea to pick another tutorial. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacing select() in the non-threaded RTS?
On Wed, May 30, 2007 at 09:21:36PM -0700, Bryan O'Sullivan wrote: I notice that select is a bit of a bottleneck in the non-threaded RTS once lots of sockets are in play. Between kernel and userspace, many a cycle are wasted once we go past a few hundred clients. On some operating systems, the fixed nature of fd_set imposes a surprisingly low ceiling on the maximum number of concurrently open file descriptors. I gather there's some kind of longish-term plan to build a more pluggable RTS, but it seems like a nearer-term solution could be implemented relatively cheaply, and wouldn't conflict with the ultimate goal. Would the GHC team be interested in receiving a patch that replaced select, where possible, with an operating system's native, and hopefully faster, event wait mechanism? I don't beleive the GHC team would be interested in receiving any patches to the non-threaded RTS, since it is scheduled for removal in 6.8 IIRC (leaving only threaded). Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC.Prim problem
On Tue, May 29, 2007 at 09:58:38PM -0400, Alec Berryman wrote: Simon Marlow on 2007-05-29 16:05:49 +0100: Ben Sinclair wrote: Hello, I've had a problem with GHC.Prim when compiling the darcs HEAD lately. When I compile it in the normal way with no special options sh boot ./configure make make install It works for me, with last night's HEAD build. Are you running GHC from the build tree, or installing it first? (not that it ought to make a difference). If you say 'ghc-pkg describe base', does it list GHC.Prim as exposed? I built a clean HEAD from today and installed it with 'make install'. It works well enough to compile libraries like zlib and binary as well as applications like xmonad. When I try to compile the example file Ben gave using the installed ghc, it fails as Ben described - no GHC.Prim. 'ghc-pkg describe base' does not list GHC.Prim as exported, even though base's cabal file does. When I use the GHC from the build tree, it compiles fine. While importing GHC.Prim should work, the right way is to import GHC.Exts instead. GHC.Exts doesn't appear to export unsafeCoerce#, which hs-plugins and gtk2hs both want. I'd like to point out one other major application which depends on the availability of GHC.Prim: GHC (As of 20070518) GHC HEAD cannot compile itself for exactly this reason. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: capabilities of GHC API
On Sat, May 19, 2007 at 06:09:45PM +0100, Frederik Eaton wrote: If you have GHC-6.6 or greater, try: let n = 2 in GHC.Base.breakpoint () Interesting, apparently that statement also contains the word 'print': :) $ ghci fly:~ ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.20070420, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. let n = 2 in GHC.Base.breakpoint interactive:1:0: No instance for (Show (a - a)) arising from use of `print' at interactive:1:0-31 Possible fix: add an instance declaration for (Show (a - a)) In the expression: print it In a 'do' expression: print it You forgot the () at the end. (And btw, ghci's autoprinting works by wrapping your code in print) Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cost of Overloading vs. HOFs
On Fri, May 04, 2007 at 09:02:03PM +0100, Neil Mitchell wrote: Hi Adrian The GHC users guide says overloading is death to performance if left to linger in an inner loop and one thing I noticed while playing about with the AVL lib was that using a HOF and passing the (overloaded) compare function as an explicit argument at the start seemed to give noticable a performance boost (compared with dictionary passing presumably). I'm not sure why that should be, but has anyone else noticed this? A HOF is one box, the Ord dictionary is an 8-box tuple containing HOF boxes. When you invoke compare out of Ord, you are taking something out of the tuple, whereas when you use the HOF its directly there. This is also the reason you get a performance decrease moving from a 1-element class to a 2-element class. What ever happened to OccurAnal? Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cost of Overloading vs. HOFs
On Sat, May 05, 2007 at 10:29:54AM +1000, Matthew Brecknell wrote: Stefan O'Rear: Data.Sequence doesn't use overloading Data.Sequence uses overloading for subtree size annotations. The structural recursion seems to make it quite awkward to express size annotations without overloading. Ah yes, I'd forgotten about that use. I was thinking of the fact that Data.Sequence is monomorphic in the measurement type. Thanks for the correction. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why do we have stack overflows?
On Thu, May 03, 2007 at 05:36:45PM -0700, Brandon Michael Moore wrote: On Thu, May 03, 2007 at 04:59:58PM -0700, John Meacham wrote: I believe it is because a stack cannot be garbage collected, and must be traversed as roots for every garbage collection. I don't think there are any issues with a huge stack per se, but it does not play nice with garbage collection so may hurt your performance and memory usage in unforeseen ways. Isn't it just the top of the stack that has to be treadted as a root? (maybe you need to walk the stack to find exception handlers and so on.) Maybe it shouldn't be so much worse than a heap. The Chicken Scheme system allocates everything on the C stack, and runs some sort of compacting collector when it is about to fill. GHC uses a simple exponential-backoff algorithm for handling stacks. When the stack pointer passes the stack limit, the thread yields to the scheduler, where the stack size is doubled, and the old stack is moved. Perhaps instead we could modify the algorithm such that up to 16K stack size the behaivor is the same, but use linked lists for larger? 1. Allocate a new chunk, of size 16KB. 2. Copy the topmost 1KB of stack to the new block. This decreases storage efficiency slightly (but not much in time - memcpy is several times faster than anything the current ghc code generator can generate), but it avoids a nasty corner case (stack size fluctuating across 0 mod 16K) by acting as a form of hysteresis. 3. Create a special frame at the bottom of the new stack chunk that returns into a stack underflow handler, thus avoiding the need for yet another conditional. Yes, 16KB unrolled linked lists are virtually as fast as flat byte arrays; see Data.ByteString.Lazy if you want proof. The only hard part appears to be step 3, as it requires finding an appropriate place to insert the trampoline frame; it seems plausible that stack frames are sufficiently self describing to make this a simple exercise of loops, but it could be much much harder. With this change GHC stacks could fill the whole heap with little more performance degradation than ordinary objects already give. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: non-owner-writable files generated in ghc build process?
On Sun, Apr 29, 2007 at 09:12:00AM -0400, Isaac Dupree wrote: When I was doing `rm -r` on a build tree it pointed out that driver/split/ghc-split.prl and driver/mangler/ghc-asm.prl were write-protected. Tacking this down, they're generated from .lprl with unlit... then (in mk/suffix.mk) they are `chmod 444`-ed. Is this a problem? Is the purpose to remind people that those are generated files, so don't change them? (hmm... if someone has a restrictive umask like 027, will this circumvent it? would `chmod -w` make more sense?) umask only affects file creation, not chmod. I know, I can use `rm -rf` in order to unquestioningly follow UNIX permissions model... Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
On Mon, Apr 16, 2007 at 03:54:56PM +0100, Simon Marlow wrote: - 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. I personally have a type checker idea I am working on, but I doubt I will ever be able to implement features such as this, because the type checking abstraction is now leaking badly. Once the Hindley-Damas-Milner algorithm is exposed, I fear programmers will rely on it and progress in Haskell typechecker implementation will be effectively halted. (Yes, I know I'm a bit late in complaining...) - list fusion Nitpick - you did mean stream fusion, right? We think the above feature set makes for a pretty strong 6.8 release. What do you think of this plan? Are there features/bug-fixes that you really want to see in 6.8? Good code generation for loops. I understand they are rare in practice, but it's kinda disheartening to write memset() and see in the asm loop 11 memory references, 9 to the stack (numbers from unreliable memory). I don't mind the plan, either. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT + Newtype deriving = Erroneous errors
On Wed, Mar 28, 2007 at 12:03:41PM +0100, Chris Kuklewicz wrote: Stefan O'Rear wrote: On Tue, Mar 27, 2007 at 11:32:29AM +0100, Chris Kuklewicz wrote: Stefan O'Rear wrote: newtype Foo = Foo Int deriving(IsIntC) Note that (Foo 2) + 2 is an attempt to add a Foo and an Int, which cannot possibly compile. So I replaced it with just a 2. Why not? They are the same type, and I have Curry-Howard proof of this fact. Stefan Foo is isomorphic to Int in structure. But it is not the same type. Foo is a new type that is distinct from Int. That means I get type safety -- you cannot pass an Int to a function that expects a Foo and vice versa. Since (+) is defined as (Num a = a-a-a) it cannot add type different types and thus you *cannot* add a Foo and an Int. Well, I thought I had a non-bottom value of type IsIntT Foo, but when I tried to seq it ghc crashed: http://hackage.haskell.org/trac/ghc/ticket/1251 Let's postpone this discussion until the people who maintain the typechecker have a chance to rule :) Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADT + Newtype deriving = Erroneous errors
On Tue, Mar 27, 2007 at 11:32:29AM +0100, Chris Kuklewicz wrote:
Stefan O'Rear wrote:
This code causes GHC to incorrectly fail - the case *is* reachable.
(I invented this technique in an attempt to directly access the
internal System FC newtype coercion; it promised until a few minutes
ago to solve all the EnumMap performance concerns.)
[EMAIL PROTECTED]:/tmp$ cat A.lhs
{-# OPTIONS_GHC -fglasgow-exts #-}
data IsIntT x where IsIntT :: IsIntT Int
class IsIntC a where isInt :: IsIntT a
instance IsIntC Int where isInt = IsIntT
newtype Foo = Foo Int deriving(IsIntC)
x :: IsIntT Foo - Int
x IsIntT = (Foo 2) + 2
IsIntT Foo is a concrete type.
IsIntT has concrete type IsInt Int.
These types cannot possibly match.
Sure they can. This is an attempt to torture-test GHC. Using newtype
deriving, I have constructed a non-bottom value of type IsIntT Foo.
Thus, the value is evidence of the fact that the newtype is isomorphic
to the base type. In the language of GHC HEAD, it is a value-level
reification of the coercion used to implement the newtype in System FC
(although the same bogus error occurs with 6.4.2, 6.6, 6.7.20070213,
6.7.20070223, and 6.7.20070323). GHC seems to be making the
(unwaranted!) assumption that distinct concrete types can never be
unified - but they CAN, and the compiler is failing my torture test.
(BTW, why is the inaccessible alternative an error rather than a
warning?)
Note that (Foo 2) + 2 is an attempt to add a Foo and an Int, which cannot
possibly compile. So I replaced it with just a 2.
Why not? They are the same type, and I have Curry-Howard proof of this fact.
Stefan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: chr and ord not in standard prelude
On Fri, Mar 09, 2007 at 03:40:08PM -0500, Colletta, Edward wrote: When I try to use functions chr or ord, I get a not in scope error. If I :browse Prelude I do not see these functions. Is there another module I should load? Don't use chr and ord - they aren't polymorphic, they restrict your code to work only on Chars. Use fromEnum and toEnum (which are in the Prelude) instead. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: size of snapshot archive
On Sun, Feb 18, 2007 at 10:19:05PM +0200, Dinko Tenev wrote: On 2/18/07, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello glasgow-haskell-users, i'm tried to download newer snapshot of 6.6 and found that now it's 74 mb! why it is so large and why it's so enlarged after 6.6 release? isn't it possible to reduce size of this package? Does this include darcs version info? I've noticed that darcs generates suspiciously large quantities of context info for very small patches (e.g. ~7000 lines of context for a ~700 line patch) -- for what I've seen so far, the context section might be growing linearly with the file's history. Darcs send packs data much tighter than darcs itself does, and the results are highly compressable. I have a HEAD tree, obtained with ./darcs-all --extra get --complete (you're not misreading that); darcs sending everything (incl. subrepositoried) into an empty repo, and 7zipping the patch bundles, produces a single 28mbyte file containing the entire history of ghc+extralibs. (I still have the file but can't share - 10mb webhost quota) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Thoughts on the design of External Core
Would it be feasable to discard the IfaceSyn typechecker entirely, replacing it with an single invocation of Core Lint? Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
