Re: another wash compile problem
Compiling a module which imports the 14 smaller modules takes much less time than compiling the monolithic module - it's almost 5 times faster (see below). We've found the cause of this, and committed a fix. The full HTMLMonda98.hs now compiles in 27 seconds for me, without optimisation (with 6.4 it is several minutes). Let's hope the same issue is affecting other compilations too :-) Wow! That's great. Have you looked at how compile time varies with module size in the fixed version? Frederik ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: another wash compile problem
On 10 August 2005 09:04, Frederik Eaton wrote: Compiling a module which imports the 14 smaller modules takes much less time than compiling the monolithic module - it's almost 5 times faster (see below). We've found the cause of this, and committed a fix. The full HTMLMonda98.hs now compiles in 27 seconds for me, without optimisation (with 6.4 it is several minutes). Let's hope the same issue is affecting other compilations too :-) Wow! That's great. Have you looked at how compile time varies with module size in the fixed version? Not in any detail; but I expect it to be worse than linear but not as bad as quadratic. There are several reasons it might be worse than linear: GC is linear in the residency, for one. And the compiler makes a lot of use of FiniteMap, which will add a (log n) factor to a traversal of the tree. We try to fix instances of quadratic behaviour as we find them. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Internal error: scavenge_one
Hi, i have the following error when running my program interactive: internal error: scavenge_one: strange object 47 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ is this a compiler's bug or my program's ? ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Cabal on OS X; ghc segfault?
Gregory Wright [EMAIL PROTECTED] writes: (snip) the failure is not related to what I am trying to build. It doesn't matter if I run the same command, runhaskell Setup.hs configure in the haskell-src-exts subdirectory. The failure is the same. The failure also occurs if I try to configure an simple homemade application using the cabal method on OS X. The same test application configures and builds correctly using cabal on FreeBSD 5.4 under ghc-6.4. Can you tell us what version of Cabal and GHC you are using? peace, isaac ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: --make and -main-is still not working together?
On 09 August 2005 16:11, Niels wrote: I'm triggering the bug that was first reported here http://sourceforge.net/tracker/index.php ?func=detailatid=108032aid=935792group_id=8032 which was fixed in 6.2.1 im issuing the following ghc command: 'ghc -o out --make -main-is ModName.Main.main ModName/Main.hs' and get: /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function `main': undefined reference to `__stginit_ZCMain' /usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In function `main': undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status I can't reproduce this failure: ~/scratch cat ModName/Main.hs module ModName.Main where main=print hello ~/scratch ghc -o out --make ModName/Main.hs -main-is ModName.Main.main Chasing modules from: ModName/Main.hs Skipping ModName.Main ( ModName/Main.hs, ModName/Main.o ) Linking ... This is 6.4 on x86/Linux. Is there anything I'm missing? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Deriving Typeable instances
On 09 August 2005 17:16, Simon Peyton-Jones wrote: I'm not against this, although you can work around the problem by adding a library that defines the missing type classes (Typeable8, Typeable9 etc), and making your compiler generate the instance itself. There is nothing magic about 'deriving'; it's just convenient. If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: queryFdOption broken
Fixed, thanks! Simon On 09 August 2005 20:45, Adam Sampson wrote: While writing a testcase for another bug (details to follow), I found that System.Posix.IO.queryFdOption doesn't work. The problem appears to be that queryFdOption uses testBit incorrectly; it assumes the second argument is the bitmask, when it's actually the bit *position* to test. It should be an easy fix (just do a bitwise AND and see whether the result's zero instead). Here's how to reproduce the problem on my system -- note that it's getting the correct results from the underlying system calls, but not returning them correctly: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4 $ uname -a Linux cartman.at.fivegeeks.net 2.6.12.2 #1 Thu Jul 14 15:28:07 BST 2005 i686 unknown unknown GNU/Linux $ gcc -v Reading specs from /opt/packages/gcc-3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: ./configure --prefix=/opt --sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/com --enable-__cxa_atexit --enable-threads=posix --enable-shared --enable-languages=c,c++,java,f77,objc Thread model: posix gcc version 3.4.4 $ cat Query.hs import System.Posix.IO showNBR = do v - System.Posix.IO.queryFdOption 0 System.Posix.IO.NonBlockingRead putStr $ NonBlockingRead = ++ (show v) ++ \n main = do showNBR System.Posix.IO.setFdOption 0 System.Posix.IO.NonBlockingRead True showNBR $ ghc -o query -package unix Query.hs $ ./query NonBlockingRead = False NonBlockingRead = False $ strace ./query 21 | grep ETFL [...] fcntl64(0, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(0, F_SETFL, O_RDWR|O_NONBLOCK) = 0 fcntl64(0, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) [...] If you need any more information, please let me know. Thanks, ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: System.Cmd.system/rawSystem set stdin/stdout to non-blocking mode
On 09 August 2005 20:56, Adam Sampson wrote: While tracking down a bug in Ginsu earlier, I found that the cause is an unexpected side-effect of the System.Cmd functions: they set FD 0 (and consequently anything that it's been dupped to, so probably FD 1 and FD 2 as well) to non-blocking mode. This will break any future usage of stdin/stdout that doesn't expect to get an EAGAIN error -- for example, Ginsu uses the curses library which won't update the screen correctly if FD 1 is non-blocking. Worse, this is done before the fork(), so the program that's run is also given its FDs in non-blocking mode, and will thus suffer the same problems. It appears that this is a consequence of System.Process.Internals.runProcessPosix using stdin, which sets FD 0 to be non-blocking. GHC puts any file descriptor it uses into O_NONBLOCK mode, so that it can do I/O multiplexing amongst lightweight threads. The first time you evaluate stdin, stdout, or stderr they will be put into non-blocking mode. We could change runProcessPosix to avoid evaluating stdin, but that doesn't really solve the problem (and it would change the semantics of runProcess, albeit in a minor way). A workaround, if you don't intend to use stdin in your Haskell code and/or you don't care about concurrency, is to evaluate stdin first and then explicitly clear the O_NONBLOCK flag: do stdin `seq` return () setFdOption 0 NonBlockingRead False I think it's a bug in Unix that there's no way to set O_NONBLOCK privately for a single file descriptor. It just so happens I came across this same bug recently: someone else reported that you can't pipe the output of GHC through tee $ ghc -ddump-simpl Foo.hs -c | tee log because tee reports a write error. This is due to GHC putting stdout into non-blocking mode, again. If anyone has any good suggestions, I'm all ears. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1248208 ] Result type signatures and lexically scoped type variables
Bugs item #1248208, was opened at 2005-07-31 03:03 Message generated for change (Comment added) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1248208group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler (Type checker) Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Result type signatures and lexically scoped type variables Initial Comment: Dear ghc developers, The ghc documentation (7.4.10.) states that A lexically scoped type variable can be bound by: [...] A result type signature However, actually trying to use them causes some unexpected behavior: import Data.Typeable foo :: Typeable b = b foo :: a = typeOf (undefined :: a) `seq` (undefined :: a) bar :: forall b. Typeable b = b bar :: a = typeOf (undefined :: a) `seq` (undefined :: a) baz :: forall a. Typeable a = a baz :: a = typeOf (undefined :: a) `seq` (undefined :: a) All three examples give rise to basically the same error message, namely Inferred type is less polymorphic than expected Quantified type variable `b' is mentioned in the environment: Scoped type variable `a' = b (bound at: test135.hs:4:7) When trying to generalise the type inferred for `foo' Signature type: forall b. (Typeable b) = b Type to generalise: b In the type signature for `foo' When generalising the type(s) for `foo' If I understand the documentation correctly, they should all compile. An especially interesting case is 'baz', where the 'a' from the result type annotation seems to shadow the a from the type signature (that doesn't happen with pattern type annotations). Another curiosity happens if we alpha-rename foo: qux :: Typeable a = a qux :: a = typeOf (undefined :: a) `seq` (undefined :: a) The error message becomes All of the type variables in the constraint `Typeable a' are already in scope (at least one must be universally quantified here) In the type signature: qux :: (Typeable a) = a This is just my wild speculation, but does this really mean that the 'a' in qux's signature is bound by qux :: a? ghc6.2 gives the same error messages, where of course 'bar' behaves like 'foo' and 'baz' like 'qux'. Thanks you, -- Thomas Jäger -- Comment By: Simon Peyton Jones (simonpj) Date: 2005-08-10 10:30 Message: Logged In: YES user_id=50165 This isn't a bug; read Section 7.4.10.5 carefully, esp the stuff about 'rev'. In all your examples, your type variable is taking as a pattern signature, not a result signature, as the manual explains. This might not be what you expect, but it obeys the rule that the scope of the type variable is the same as the scope of the variable in the pattern. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1248208group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Deriving Typeable instances
Yes, you could I suppose. But then there'd be a different peculiar change in behaviour at arity 7. I'm not sure that'd be an advantage. Simon | -Original Message- | From: Simon Marlow | Sent: 10 August 2005 10:58 | To: Simon Peyton-Jones; Frank Huch; glasgow-haskell-bugs@haskell.org | Subject: RE: Deriving Typeable instances | | On 09 August 2005 17:16, Simon Peyton-Jones wrote: | | I'm not against this, although you can work around the problem by | adding a library that defines the missing type classes (Typeable8, | Typeable9 etc), and making your compiler generate the instance | itself. There is nothing magic about 'deriving'; it's just | convenient. | | If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? | It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. | | Cheers, | Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Deriving Typeable instances
(I agree with the two Simons; just want to throw in a few more considerations.) Just curious ... What's the use case, Frank? (It is probably related to debugging or assertion checking; do you have code details that you want to share?) Do you *really* want to do type-case on those multi-arity parametric types in the sense that you would care about keeping n, n-1, n-2, ..., 1 type positions polymorphic when casting? If you don't, then monomorphic instances of Typeable would be fine. And they are much easier to generate, indeed. (Typeable.h in the Data/include dir (ghc cvs) could be of help to solve the problem before GHC catches up.) It's perhaps useful to recall that the arity-sensitive Typeable business was introduced for the purpose of polymorphic type-case in the context of generic programming with SYB1 and 2 (a bit less at level 3) BTW, for the ICFP 2005 style of SYB (level 3), Typeable instances may be entirely avoidable, depending on programming style and scenario. All the best, Ralf (Once again, sounds like kind-polymorphism would simplify the implementation and the use of Haskell.) -Original Message- From: Simon Peyton-Jones Sent: Wednesday, August 10, 2005 3:32 AM To: Simon Marlow; 'Frank Huch'; 'glasgow-haskell-bugs@haskell.org' Cc: Ralf Lammel Subject: RE: Deriving Typeable instances Yes, you could I suppose. But then there'd be a different peculiar change in behaviour at arity 7. I'm not sure that'd be an advantage. Simon | -Original Message- | From: Simon Marlow | Sent: 10 August 2005 10:58 | To: Simon Peyton-Jones; Frank Huch; glasgow-haskell-bugs@haskell.org | Subject: RE: Deriving Typeable instances | | On 09 August 2005 17:16, Simon Peyton-Jones wrote: | | I'm not against this, although you can work around the problem by | adding a library that defines the missing type classes (Typeable8, | Typeable9 etc), and making your compiler generate the instance | itself. There is nothing magic about 'deriving'; it's just | convenient. | | If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? | It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. | | Cheers, | Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Deriving Typeable instances
Hi and thanks for your discussion. Our programs have (at the moment) nothing to do with debugging or assertions. We are implementing a Curry-to-Haskell-Compiler. Curry is a functional-logic language, extending Haskell with needed narrowing (efficient (lazy) search for free, logic variables). In the generated Haskell program we need a mapping for bindings of logic variables. The only way we were able to built this mapping is a map from variable identifiers to dynamically typed values. Since Curry provides tuples up to arity 15, we have to provide an instance of the class Typeable to store bindings in the mapping of logic variables. Hence, for the predefined data structures it would be nice to have instances up to 15. However, in Curry programmers are also allowed to define own type constructors with an arity larger than 15 (or seven), as in Haskell. To translate such Curry programs it would be nice to have derivable instances for Typeable for type constructors of arbitrary arity, like ghc-6.2 provided it. For us it is nicer to derive Typeable instance for all data types rather than defining these instances by hand. For the moment, it would be nice if you could provide a restriction to 15 type variables. Otherwise we will define these instances for tuples up to 15 by hand and think about generating instances for arbitrary types later. Thanks and regards, Frank Ralf Lammel schrieb: (I agree with the two Simons; just want to throw in a few more considerations.) Just curious ... What's the use case, Frank? (It is probably related to debugging or assertion checking; do you have code details that you want to share?) Do you *really* want to do type-case on those multi-arity parametric types in the sense that you would care about keeping n, n-1, n-2, ..., 1 type positions polymorphic when casting? If you don't, then monomorphic instances of Typeable would be fine. And they are much easier to generate, indeed. (Typeable.h in the Data/include dir (ghc cvs) could be of help to solve the problem before GHC catches up.) It's perhaps useful to recall that the arity-sensitive Typeable business was introduced for the purpose of polymorphic type-case in the context of generic programming with SYB1 and 2 (a bit less at level 3) BTW, for the ICFP 2005 style of SYB (level 3), Typeable instances may be entirely avoidable, depending on programming style and scenario. All the best, Ralf (Once again, sounds like kind-polymorphism would simplify the implementation and the use of Haskell.) -Original Message- From: Simon Peyton-Jones Sent: Wednesday, August 10, 2005 3:32 AM To: Simon Marlow; 'Frank Huch'; 'glasgow-haskell-bugs@haskell.org' Cc: Ralf Lammel Subject: RE: Deriving Typeable instances Yes, you could I suppose. But then there'd be a different peculiar change in behaviour at arity 7. I'm not sure that'd be an advantage. Simon | -Original Message- | From: Simon Marlow | Sent: 10 August 2005 10:58 | To: Simon Peyton-Jones; Frank Huch; glasgow-haskell-bugs@haskell.org | Subject: RE: Deriving Typeable instances | | On 09 August 2005 17:16, Simon Peyton-Jones wrote: | | I'm not against this, although you can work around the problem by | adding a library that defines the missing type classes (Typeable8, | Typeable9 etc), and making your compiler generate the instance | itself. There is nothing magic about 'deriving'; it's just | convenient. | | If the arity is 7, couldn't we just generate a Typeable instance, rather than the TypeableN instance? | It would mean you wouldn't get the benefits of TypeableN, but at least you'd have Typeable. | | Cheers, | Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635718 ] Bad space behaviour with huge input file
Bugs item #635718, was opened at 2002-11-08 21:43 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635718group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Compiler Group: 5.04 Status: Closed Resolution: Rejected Priority: 6 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Simon Peyton Jones (simonpj) Summary: Bad space behaviour with huge input file Initial Comment: The attached files (actually, just UnicodeData.hs but the other file is imported by it) trigger very bad space and time behaviour in ghc during compilation. One attempt went up to 500 MB of virtual memory (256 physical available) on my i386 machine. The compilation ran for more than an hour until killed (stuck in the rename phase). I had another version (available on request) of this that has all the data in a string, compiled into an object file using gcc (in no time!), accessed using FFI and then using read made into a real data structure. The program, looking up one entry in the resulting FiniteMap, has a memory hit of approximately 130 MB and runs in one minute (which, while still too much, is bearable). So it seems there is lots to improve in the compiler in this case (we are essentially talking about the same process taking way too much time and memory when done by the compiler, compared to the program itself doing it - and even then the memory requirement is outrageous). Even some sort of special-casing pragma that allows me to ask for lighter treatment of pure data would be good (and a way to statically initialize a FiniteMap...) I'm sorry but I do not have any simpler input files to offer. -- Comment By: Simon Marlow (simonmar) Date: 2005-08-10 15:03 Message: Logged In: YES user_id=48280 This source file is simply huge (6M) and contains a single large nested non-constant expression. Also, it isn't syntactically correct, and even when the syntax errors are fixed it has type errors. I'm going to close this bug. Feel free to submit more examples of code that GHC takes too long to compile, but there's not much we can do with this one. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635718group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
stdin set to nonblocking mode
Why do we set file descriptors to nonblocking mode anyway if they are waited on by a select. there shouldn't be a need to use both mechanisms. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ANN: C-Haskell version 0.14.3 Travelling Lightly
I like to announce version 0.14.3 of C-Haskell, which brings the following advances over 0.14.1: * gcc's asm construct is supported, which is apparently important for some libraries on Mac OS X (thanks to Duncan Coutts for the patch); * C-Haskell supports cross compilation (see details below); [NB: C-Haskell now generates completely portable Haskell code (needs only H98 + FFI) and can target C compilers on platforms that cannot build C-Haskell itself; eg, PalmOS. In particular, C-Haskell generated bindings are suitable for nhc98 and Hugs, too.] * hierarchical modules syntax can be used in import hooks (again thanks to Duncan for the patch); and * two new built-in translation functions upcaseFirstLetter and downcaseFirstLetter are supported to generated suitable Haskell names from C names (eg, for variants of enums). Source code is available as a tar ball from http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ or via Darcs (binary packages may appear later). Happy Hacking, Manuel -=- Cross compilation -=- C-Haskell needs to take system-specific parameters of the C compiler used to compile the libraries for which an interface is generated into account (most notably when bitfields are used in this library). By default C-Haskell uses the conventions of the C compiler that was used to build C-Haskell itself. From this version, C-Haskell accepts the --platform=PLATFORM flag that enables the explicit specification of the target platform. This works only for platforms that are in C-Haskell's platform specification database. At the moment, that's only i686-pc-linux-gnu and m68k-palmos. However, it is very easy to determine the platform specification for any platform on which you can build C-Haskell: Just invoke it as `c2hs --version' and it will tell you. If you send me the output of `c2hs --version', I'll happily add it to the database. (If you'd like to target a platform on which you cannot build C-Haskell, such as an embedded system, let me know.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: -odir behaviour change in 6.4.1?
On 10 August 2005 00:05, Andres Loeh wrote: Is this change in behaviour between ghc-6.4 and ghc-6.4.1 desired: ~/trans $ ls foo foo.c ~/trans $ ghc-6.4 -odir foo -c foo/foo.c ~/trans $ ls foo foo.c foo.o ~/trans $ rm foo/foo.o ~/trans $ ls foo foo.c ~/trans $ ghc-6.4.1.20050804 -odir foo -c foo/foo.c ~/trans $ ls foo foo foo.c ~/trans $ ls foo/foo foo.o It seems to break cabal-1.1.1, in the case that I have something like c-sources: foo/foo.c in my .cabal file ... Yes, this change was made for consistency (someone else reported the breakage). I've also patched Cabal, so perhaps you're using a version from before the fix? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.4.1 release candidate testing on Solaris
ghc-6.4.1.20050806 (and before ghc-6.4.1.20050731) built successfully on Solaris (Sparc). bash-2.05$ uname -aSunOS kleopatra 5.9 Generic_118558-04 sun4u sparc SUNW,Sun-Fire-V240bash-2.05$ gcc -vReading specs from /export/home/haskells/geisler/sw/lib/gcc/sparc-sun-solaris2.9/3.4.4/specsConfigured with:./configure --prefix=/export/home/haskells/geisler/sw --with-ld=/export/home/haskells/geisler/sw/bin/ld --with-as=/export/home/haskells/geisler/sw/bin/asThread model: posixgcc version 3.4.4bash-2.05$ ld -vGNU ld version 2.16bash-2.05$ as -vGNU assembler version 2.16 (sparc-sun-solaris2.9) using BFD version 2.16 ghc was configured with: ./configure --prefix=/export/home/haskells/geisler/sw --disable-opengl --disable-glut --disable-openal To build ghc-6.4.1.20050806, I used ghc-6.4.1.20050731 which was built with Christian Maeder's binary distribution for Solaris(http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2.tar.bz2) from June 2005. I was able to build all our Haskell code. Some first tests were successful. Tim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: [Haskell] proposal about declaring language version and language extensions used in specific module
Hello Ross,
Wednesday, August 10, 2005, 4:24:53 AM, you wrote:
RP On Tue, Aug 09, 2005 at 03:37:01PM -0700, John Meacham wrote:
I thought there was talk of a standardized {-# LANGUAGE ... #-} pragma
somewhere.. but I can't seem to find it.
RP http://www.haskell.org//pipermail/haskell/2003-September/012692.html
RP http://www.haskell.org//pipermail/libraries/2004-October/002589.html
of course, my proposed extension is very trivial. but compared to
above mentioned variants, it moves definition of language used in
module from pseudocomments to language itself. i also propose moving
of all pragmas from pseudocomments to special language statements
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
RE: Re[2]: [Haskell] proposal about declaring language version andlanguage extensions used in specific module
On 10 August 2005 08:03, Bulat Ziganshin wrote:
Hello Ross,
Wednesday, August 10, 2005, 4:24:53 AM, you wrote:
On Tue, Aug 09, 2005 at 03:37:01PM -0700, John Meacham wrote:
I thought there was talk of a standardized {-# LANGUAGE ... #-}
pragma somewhere.. but I can't seem to find it.
http://www.haskell.org//pipermail/haskell/2003-September/012692.html
http://www.haskell.org//pipermail/libraries/2004-October/002589.html
of course, my proposed extension is very trivial. but compared to
above mentioned variants, it moves definition of language used in
module from pseudocomments to language itself. i also propose moving
of all pragmas from pseudocomments to special language statements
The language declaration affects the grammar of the language, and even
whether the source is preprocessed or not, so you can't put the
declaration into the language itself. {-# LANGUAGE #-} is the right
thing (and we should implement it in GHC, really).
Cheers,
Simon
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] pros and cons of static typing and side effects ?
[thnk 4 the previous answers !] Good [morning, afternoon, night], I try to better understand some things... maybe you can help me. Id' like to know what are the pros and cons of (not) having static typing. Same question for (direct support of) side effects. To help you to find answers, here I quote this page : http://paulgraham.com/lispfaq1.html [Most hackers I know have been disappointed by the ML family. Languages with static typing would be more suitable if programs were something you thought of in advance, and then merely translated into code. But that's not how programs get written. The inability to have lists of mixed types is a particularly crippling restriction. It gets in the way of exploratory programming (it's convenient early on to represent everything as lists), and it means you can't have real macros.] Thanks a lot, minh thu ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[4]: [Haskell] proposal about declaring language version andlanguage extensions used in specific module
Hello Simon,
Wednesday, August 10, 2005, 6:27:45 PM, you wrote:
SM The language declaration affects the grammar of the language, and even
SM whether the source is preprocessed or not, so you can't put the
SM declaration into the language itself. {-# LANGUAGE #-} is the right
SM thing (and we should implement it in GHC, really).
yes, you are right in both statements ;) my variant can be interesting
only for Haskell 2.0, if we will need to break compatibility anyway
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] HaXml ANYContent
Hi, I have some problems with the ANYContent type in HaXml. Currently (1.13) ANYContent is defined as data ANYContent = ANYContent which means I cannot store anything in there. I need two things: 1) Parse a file where some elements have ANY content, but be able to use the content. 2) Create a data structure and fill the ANYContent field and be able to write that to an XML file. I suggest the following sollution: newtype Unparsed = Unparsed String data ANYContent = forall a . XmlContent a = Either UnParsed (ANYContent a) If an XML file is parsed we don't know the type yet. Therefore we put everything in Unparsed field. Later on one can use a Parser on that explicitly. It would also make the roundtrip XML-Haskell -XML more stable. Cheers, Georg -- Georg Martius, Tel: (+49 34297) 89434 --- http://www.flexman.homeip.net - pgpJAjmgegubt.pgp Description: PGP signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Creating a Haskell app to do crosstabs
Hi everyone - I'm a relative newcomer to Haskell, and am very much besotted with it - it's a great language! :-) At the moment, I'm in the early stages of putting together a little Haskell-like language using the Spirit parser framework (Spirit is part of the Boost C++ libraries). Spirit also has a functional-programming sister library (Phoenix), which includes lambdas, lazy functions and lots more. Phoenix is currently being merged with the Boost Lambda Library. ( Sorry for the off-topic digression - just giving the background to what I'm doing ;-) ) I've done a couple of toy parsers for Spirit already, but now I'm looking to do something that is more of a challenge - doing a small-ish Haskell-like language. The language is aimed at being able to read in a comma-delimited file (with column-headings), and putting the data into columns. ( I envisage maybe a Haskell pair. The first item being the column heading, the second being a list, with the data in it. ) Then, the user would select one of those columns for a page variable (that one would be optional), and one or more columns for the crosstab rows and columns. What I'm needing to do is to first put together the code in Haskell itself, and get it running. Then, that will give me a good feel as to how much of core Haskell I need to implement, in order to do the crosstab app. So, I was wondering - has anyone in the Haskell community used Haskell to do crosstabs? ( And if so, is there any code available? ). Any help in the two areas - a) Using Haskell to read a delimited file (with column-headings) into a columnar or tabular data-structure - b) Using Haskell to do crosstabs - - would be very welcome! I should also stress that full credit will be given to the writers of any code supplied. Very many thanks in advance for any help received! - - Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Creating a Haskell app to do crosstabs
Hello Andy, Thursday, August 11, 2005, 5:18:12 AM, you wrote: AEI'm a relative newcomer to Haskell, and am very much besotted with it AE - it's a great language! :-) AE At the moment, I'm in the early stages of putting together a little AE Haskell-like language using the Spirit parser framework (Spirit is AE part of the Boost C++ libraries). Spirit also has a AE functional-programming sister library (Phoenix), which includes AE lambdas, lazy functions and lots more. Phoenix is currently being AE merged with the Boost Lambda Library. btw, afaik Spirit is modeled after ParseC (parsing combinators) haskell library and Phoenix was needed for this library because parser combinators require lazy functional language to work :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Practical introduction to monads
Hello Paul, Wednesday, August 03, 2005, 12:03:49 AM, you wrote: PM One thing I haven't found a really good discussion of, is practical PM examples of building monads. There's plenty of discussion of the IO i recall one more usage of monads - to do parsing. read the following: http://www.cs.nott.ac.uk/~gmh//pearl.pdf http://www.cs.nott.ac.uk/~gmh//pearl.hs that is really beatiful - parsing monad used both for holding state (position in input stream) and to backtrack to alternative rules when parsing with current rule fails. these ideas also used in ParseC (parser combinators) library, which are widely used (read http://www.cs.uu.nl/people/daan/download/parsec/parsec.html) btw, just obstacles with creating more advanced parsing libraries with help of monads lead to inventing of arrows - more generalized variant of monads (see http://www.cs.chalmers.se/~rjmh/Papers/arrows.pdf) ps: another example can be CPS (continuation passing style) monads, but i know nothing about it, except for name :) may be someone can point me to tutorial? :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
