http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14734 I think it makes sense because many of the inter-pass dependencies we have in the GHC pipeline today are actually somewhat lenient. For example, something quite sensible will happen if we do CSE before full laziness, it will simply lead to less efficient code. In contrast, it's imperative that we perform strictness analysis before applying worker-wrapper based on the annotations it adds. This is an interesting observation. So, you imagine that the >user program itself< might import the compiler plugins and add a constraint between the phases they export. I'm not sure how many users would really want to do this, but I can see it being useful. Thanks for your input: I've got a lot to think about now. Max Max Bolingbroke 2008-07-05T17:03:30 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14733 If you don't need a dependency and it can be ignored anyway, why would you want to specify it in the first place? I just can't quite imagine a situation in which I would use this. As to cycles, I think just aborting if they occur would be ok. Yeah, I'd prefer the class/instance model. An example: suppose you have two independent libraries which implement two optimisations and you want one of them to run before another. I think we really need this if we want to compose optimisations. True. It's a bit of a hack, though :-) Roman Roman Leshchinskiy 2008-07-05T10:46:40 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14732 Hi Roman, I suspect that when you have multiple plugins all specifying constraints on the phase ordering independently it is possible to end up in a situation where using each plugin individually results in a consistent phase ordering but a combination of multiple plugins causes a cycle to appear in the order. Hence it is useful to let plugin authors flag up dependencies they don't >need< to have so we can intellegently break the cycle using those constraints rather than just giving up. Admittedly I only have a superstition that this will be a practical problem. This in interesting. You're right that it's not possible with this system: to support this you would need a more class + instance rather than single declaration flavour for phases. Do you have a practical example in mind of how you would use it? Ah! This would also let you do what you wanted with your second point: module C where {-# PHASE XAlias = A.X, < B.Y #-} This could indeed be useful, and since it subsumes your other proposal without co Max Bolingbroke 2008-07-05T08:12:00 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14731 Hi Max, sorry for replying so late, I've completely forgotten about this. Three things. Firstly, what would lenient ordering be useful for? You probably had a specific use case in mind? Secondly, I think it is quite important to be able to specify dependencies for already declared phases. That is, I (probably) want to be able to say in module C that phase X from module A should come before phase Y from module B. I suspect that's not quite possible with your current design. Lastly, in addition to < and > I'd also like to have = (i.e., phase X = phase Y which would make X an alias for Y). As to the numeric phase ids, I'm all in favour of dropping them altogether. For legacy code, you could provide wired-in names 0, 1 and 2 for now but I would deprecate them. Also, I'm one of the probably very few people who have ever used phase 3 and beyond and dropping support for that is perfectly fine with me. Thanks for working on this! Roman Roman Leshchinskiy 2008-07-05T01:20:28 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14730 I get no output at all. Christian Christian Maeder 2008-07-03T14:14:06 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14729 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. I am assuming that 6.8.1 is the latest binary release for solaris-sparc? When I try to call ghc, it says ld.so.1: ghc-6.8.1: fatal: relocation error: file /usr/local/lib/libncurses.so.5: symbol main: referenced symbol not found my machine is: sparc-sun-solaris2.10 I think I have all the necessary packages: ldd /home/waldmann/built/lib/ghc-6.8.1/ghc-6.8.1 librt.so.1 => /lib/librt.so.1 libreadline.so.5 => /usr/local/lib/libreadline.so.5 libncurses.so.5 => /usr/local/lib/libncurses.so.5 libdl.so.1 => /lib/libdl.so.1 libm.so.2 => /lib/libm.so.2 libgmp.so.3 => /home/waldmann/built/lib/libgmp.so.3 libpthread.so.1 => /lib/libpthread.so.1 libc.so.1 => /lib/libc.so.1 libaio.so.1 => /lib/libaio.so.1 libmd.so.1 => /lib/libmd.so.1 libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 /platform/SUNW,Sun-Fire-V445/lib/libc_psr Johannes Waldmann 2008-07-03T09:00:19 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14728 Yes. Indeed, it seems so, as Ian Lynagh wrote: Thanks, Ian, for the quick response and the work-around which works fine for me. Cheers Ben Benjamin Franksen 2008-07-02T14:10:54 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14727 I've changed our generation of instances to follow this pattern and indeed the object code size is much smaller! This is a workaround for http://hackage.haskell.org/trac/ghc/ticket/955 Thanks Christian Christian Maeder 2008-07-02T11:25:35 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14726 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Christian Höner zu Siederdissen 2008-07-01T15:37:35 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14724 Since I've switched back from ghc-6.8.3 to ghc-6.8.2 I would like to see a new minor ghc version 6.8.4 with this "bug" fixed. Cheers Christian Simon Peyton-Jones wrote: Christian Maeder 2008-07-01T13:49:34 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14723 What happens when you say: ghc -c Foreign/C/UTF8.hs I expect you get the same error. If so, then this is one for ghc maintainers. If not, then we'll have to do some more digging. Alistair Alistair Bayley 2008-07-01T11:46:21 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14721 I try to build a lite version (e.g. no extra libs) of GHC 6.8.3, I'm using MinGW GCC 4.2.1-2 with dwarf-2 exception and pre-compiled GHC 6.8.3. Here's my configure: sh configure --prefix=/c/ghc-new CFLAGS='-s -O2' LDFLAGS='-s -O2' --with-gmp-includes=/usr/local/gmp/include --with-gmp-libraries=/usr/local/gmp/lib And my make: make bootstrap3 But in the middle, I got this: Preprocessing library hpc-0.5.0.1... In file included from D:/Sources/ghc/ghc-6.8.3-lite/includes/Stg.h:183, from D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:19, from Trace\Hpc\Reflect.hsc:18: D:/Sources/ghc/ghc-6.8.3-lite/includes/Regs.h:28:17: error: gmp.h: No such file or directory In file included from D:/Sources/ghc/ghc-6.8.3-lite/includes/Stg.h:183, from D:/Sources/ghc/ghc-6.8.3-lite/includes/Rts.h:19, from Trace\Hpc\Reflect.hsc:18: D:/Sources/ghc/ghc-6.8.3-lite/includes/Regs.h:121: error: expected specifier-qua lifier-list before 'MP_INT' In file included from Trac leledumbo 2008-06-30T07:35:14 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14720 | > This is the second time I have seen someone comment on implicit | > parameters being planned for removal, so now you have my attention :). | > I'd like to mention that a rather large project where I work (Galois, | > Inc.) uses implicit parameters a lot, so removing support for them | > would make me rather unhappy. | | | Hm, looks like terminology confusion. Implicit parameters are | staying. *Linear* implicit parameters were deprecated in 6.6 and seem | to be gone now. Brandon's right. Linear implicit parameters are gone. Opinions differ about (ordinary) implicit parameters, but they are sometimes jolly useful, and don't seem to impose non-local complications on the type system. We have no plans to remove them from GHC. Simon Simon Peyton-Jones 2008-06-30T07:29:05 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14719 The solution I might have tried is using StateT and and some kind of HList to pass state so that items can be appended and removed easily.. I didn't knew about this features which makes me aware again about how important it is to not stop learning new features.. I'll have a look at it now Marc Marc Weber 2008-06-29T23:08:03 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14718 On 2008 Jun 29, at 4:56, Philip Weaver wrote: Hm, looks like terminology confusion. Implicit parameters are staying. *Linear* implicit parameters were deprecated in 6.6 and seem to be gone now. Brandon S. Allbery KF8NH 2008-06-29T18:43:10 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14717 This is the second time I have seen someone comment on implicit parameters being planned for removal, so now you have my attention :). I'd like to mention that a rather large project where I work (Galois, Inc.) uses implicit parameters a lot, so removing support for them would make me rather unhappy. - Phil Philip Weaver 2008-06-29T08:56:16 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14716 On 2008 Jun 28, at 12:32, Tyson Whitehead wrote: http://www.haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#implicit-parameters It uses ? as the prefix instead of ~ (which already has a meaning in pattern matching). I am under the impression they are deprecated and slated for removal. Brandon S. Allbery KF8NH 2008-06-28T17:00:17 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14715 What do people think about implicit function argument? That is, named function arguments, possibly tagged with something special like a tilde, whereby scoped variables of the same name are automatically passed. The idea is to avoid the pain of a lots of pass through parameters while make it easy to modify one or two of them. For example, in f1 :: ~state::State -> Input -> Output f1 input = f2 input f2 :: ~state::State -> Input -> Output f2 input = <whatever> we don't have to specify ~state for f2 because it picks it up automatically from ~state being in scope from f1. To change it, however, we just do f1 :: ~state::State -> Input -> Output f1 input = f2 input where ~state = <whatever> The advantage over wrapping it in a monad being: 1) it is evident what is being passed around behind the scenes from the type signatures, and 2) we avoiding the lifting issue (to compose multiple implicit arguments we just specifying them -- assuming their are no name clashes). Cheers! -Tyson Tyson Whitehead 2008-06-28T16:32:30 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14714 I've updated the blurb. Thanks Ian Ian Lynagh 2008-06-27T17:46:54 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14713 On Fri, Jun 27, 2008 at 12:34 PM, Christian Maeder <Christian.Maeder< at >dfki.de> wrote: OK, replacing that libgmp with a custom-built version fixed my standalone GCD.hs example. So that confirms the problem. Unfortunately, that doesn't fix it for me; my real issue is that ghc iself is getting the illegal instruction error, in the middle of compiling haddock-0.9. And since ghc is statically linked to libgmp, it can't use the replacement lib for itself. (Ironic, since statically linking gmp is supposed to make installation _easier_ :-) It's not a big problem for me, though; one of the ghc-6.8.2 distributions should work fine, and I can use them to build 6.8.3 myself. Now that we've confirmed it, can someone please update the 6.8.3 downloads page (Replacing "PowerPC" with "PowerPC G5", perhaps)? Thanks, -Judah Judah Jacobson 2008-06-27T17:30:58 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/14712 Yes! Your example works for me. Maybe my libgmp.a in <prefix>/lib/ghc-6.8.3/ (that's used for linking) can be exchanged on a G4? My ghc-6.8.3 itself is linked against this very same libgmp.a (and seems to run). Cheers Christian Christian Maeder 2008-06-27T16:34:35 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.glasgow.user