broken source link
Hi, when trying to look up the original definition for Data.List.transpose in https://downloads.haskell.org/~ghc/latest/docs/html/libraries/Data-List.html I found that the source link https://downloads.haskell.org/~ghc/latest/docs/html/libraries/src/Data-OldList.html#transpose does not work. Could this be fixed? Or should I look elsewhere for the sources? Cheers Christian P.S. my looking up transpose was inspired by https://mail.haskell.org/pipermail/haskell-prime/2015-March/003933.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Hi, using cpphs is the right way to go! Rewriting it from scratch may be a good exercise but is (essentially) a waste of time. However, always asking Malcolm to get source changes into cpphs would be annoying. Therefore it would be great if the sources were just part of the ghc sources (under git). Another problem might be the dependency polyparse that is currently not part of the core libraries. (I guess that replacing polyparse by something else would also be a nice exercise.) So (for me) the only question is, if Malcolm is willing to transfer control over cpphs to the haskell-community (or ghc head) - of course with due acknowledgements! Cheers Christian On 08.05.2015 08:07, Malcolm Wallace wrote: On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: I think it's important that there be *one* cpp used by Haskell. fpp is under 4 kSLOC of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-beginners] ghc prelude home
23 December 2014 GHC 7.8.4 Released! https://www.haskell.org/ghc/ So 7.8.4 is out! Only the download subpage https://www.haskell.org/ghc/download is not updated yet. Also http://downloads.haskell.org/~ghc/latest/ still refers to http://downloads.haskell.org/~ghc/7.8.3/ (and has a funny 7.8.4 subdirectory). I send this also to glasgow-haskell-users to reach someone who can fix this. Cheers Christian Am 28.12.2014 um 22:28 schrieb Yitzchak Gale: Yes, sorry, neither 7.8.4 nor 7.10.1 is actually out yet. They are both release candidates, and will be out soon. Thanks, Yitz On Sun, Dec 28, 2014 at 9:50 PM, Antoine Latter aslat...@gmail.com wrote: I don't think GHC 7.10 is out yet: https://www.haskell.org/ghc/download Although that page doesn't have 7.8.4 on it. ___ Beginners mailing list beginn...@haskell.org http://www.haskell.org/mailman/listinfo/beginners ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Aliasing current module qualifier
Hi, rather than disambiguating a name from the current module by an abbreviated module name, I would prefer a disambiguation as is done for local names that shadows existing bindings. Then only imported names would need to be qualified (possibly using shorter module names). So names of the current module would simple shadow unqualified imported names. I think, that would only make previously ambiguous modules compile. However, this does not help for the case when the whole module plus some imported names need to be exported. module AnnoyinglyLongModuleName ( module AnnoyinglyLongModuleName , ... ) where (Without re-exports the whole export list could be omitted) Cheers Christian Am 29.09.2014 um 10:19 schrieb Herbert Valerio Riedel: Hello *, Here's a situation I've encountered recently, which mades me wish to be able to define a local alias (in order to avoid CPP use). Consider the following stupid module: module AnnoyinglyLongModuleName ( AnnoyinglyLongModuleName.length , AnnoyinglyLongModuleName.null ) where length :: a - Int length _ = 0 null :: a - Bool null = (== 0) . AnnoyinglyLongModuleName.length Now it'd be great if I could do the following instead: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglyLongModuleName as M -- - does not work length :: a - Int length _ = 0 null :: a - Bool null = (== 0) . M.length However, if I try to compile this, GHC complains about AnnoyinglyLongModuleName.hs:4:1: Bad interface file: AnnoyinglyLongModuleName.hi AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such file or directory) while GHCi tells me: Module imports form a cycle: module ‘AnnoyinglyLongModuleName’ (AnnoyinglyLongModuleName.hs) imports itself Is there some other way (without CPP) to create a local alias for the current module-name? If not, is there a reason GHC couldn't support this special case of self-aliasing the current module name? PS: Alternatively, this could be done as a language extension but that'd require extending the Haskell grammar: module AnnoyinglyLongModuleName as M (M.length, M.null) where Cheers, hvr ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc -M
Hi, using ghc -M with ghc-7.8.2 under linux. I got a message: You must specify at least one -dep-suffix (and a failure). http://www.haskell.org/ghc/docs/7.8.1/html/users_guide/separate-compilation.html#makefile-dependencies I've stopped using ghc -M now, but I think it should be documented better. Maybe dynamic linking complicated matters. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Mac CPP problem with ghc-clang-wrapper
Hi, under mavericks using the ghc-clang-wrapper (ghc-7.6) or using ghc-7.8.20140130 I can no longer install the HaXml package. The source line: putStrLn $ part of HaXml-++show MAJOR.MINOR seems to put spaces around the decimal point between MAJOR and MINOR and fails as shown below. Is this already a known problem? Cheers Christian [14 of 42] Compiling Text.XML.HaXml.Wrappers ( src/Text/XML/HaXml/Wrappers.hs, dist/build/Text/XML/HaXml/Wrappers.o ) src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match type ‛[Char]’ with ‛b0 - c0’ Expected type: b0 - c0 Actual type: String Possible cause: ‛show’ is applied to too many arguments In the first argument of ‛(.)’, namely ‛show 1’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ src/Text/XML/HaXml/Wrappers.hs:34:36: Couldn't match expected type ‛[Char]’ with actual type ‛a0 - c0’ In the second argument of ‛(++)’, namely ‛show 1 . 24’ In the second argument of ‛($)’, namely ‛part of HaXml- ++ show 1 . 24’ In a stmt of a 'do' block: putStrLn $ part of HaXml- ++ show 1 . 24 Failed to install HaXml-1.24 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
haskell xml parsing for larger files?
Hi, I've got some difficulties parsing large xml files ( 100MB). A plain SAX parser, as provided by hexpat, is fine. However, constructing a tree consumes too much memory on a 32bit machine. see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248 I suspect that sharing strings when constructing trees might greatly reduce memory requirements. What are suitable libraries for string pools? Before trying to implement something myself, I'ld like to ask who else has tried to process large xml files (and met similar memory problems)? I have not yet investigated xml-conduit and hxt for our purpose. (These look scary.) In fact, I've basically used the content trees from The (simple) xml package and switching to another tree type is no fun, in particular if this gains not much. Thanks Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: haskell xml parsing for larger files?
I've just tried: import Text.HTML.TagSoup import Text.HTML.TagSoup.Tree main :: IO () main = getContents = putStr . renderTags . flattenTree . tagTree . parseTags which also ends with the getMBlock error. Only renderTags . parseTags works fine (like the hexpat SAX parser). Why should tagsoup be better suited for building trees from large files? C. Am 20.02.2014 15:30, schrieb Chris Smith: Have you looked at tagsoup? On Feb 20, 2014 3:30 AM, Christian Maeder christian.mae...@dfki.de mailto:christian.mae...@dfki.de wrote: Hi, I've got some difficulties parsing large xml files ( 100MB). A plain SAX parser, as provided by hexpat, is fine. However, constructing a tree consumes too much memory on a 32bit machine. see http://trac.informatik.uni-__bremen.de:8080/hets/ticket/__1248 http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248 I suspect that sharing strings when constructing trees might greatly reduce memory requirements. What are suitable libraries for string pools? Before trying to implement something myself, I'ld like to ask who else has tried to process large xml files (and met similar memory problems)? I have not yet investigated xml-conduit and hxt for our purpose. (These look scary.) In fact, I've basically used the content trees from The (simple) xml package and switching to another tree type is no fun, in particular if this gains not much. Thanks Christian _ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.__org mailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/__mailman/listinfo/glasgow-__haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: haskell xml parsing for larger files?
I'm afraid our use case is not a lazy prefix traversal. I'm more shocked that about 100 MB xml content do not fit (as tree) into 3 GB memory. Christian Am 20.02.2014 16:49, schrieb malcolm.wallace: Is your usage pattern over the constructed tree likely to be a lazy prefix traversal? If so, then HaXml supports lazy construction of the parse tree. Some plots appear at the end of this paper, showing how memory usage can be reduced to a constant, even for very large inputs (1 million tree nodes): http://www.cs.york.ac.uk/plasma/publications/pdf/partialparse.pdf Regards, Malcolm On 20 Feb, 2014,at 11:30 AM, Christian Maeder christian.mae...@dfki.de wrote: Hi, I've got some difficulties parsing large xml files ( 100MB). A plain SAX parser, as provided by hexpat, is fine. However, constructing a tree consumes too much memory on a 32bit machine. see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248 I suspect that sharing strings when constructing trees might greatly reduce memory requirements. What are suitable libraries for string pools? Before trying to implement something myself, I'ld like to ask who else has tried to process large xml files (and met similar memory problems)? I have not yet investigated xml-conduit and hxt for our purpose. (These look scary.) In fact, I've basically used the content trees from The (simple) xml package and switching to another tree type is no fun, in particular if this gains not much. Thanks Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org mailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
With TypeableN I mean, Typeable1, Typeable2, etc.
Typeable2 was not supported (below) by ghc-7.8-rc1.
Where is the backward compat?
In fact, Typeable and Typeable2 mean the same thing for ghc-7.8-rc1 and
ghc-7.6 resp.!
C.
Am 20.02.2014 17:00, schrieb Simon Peyton Jones:
| Can you not simply let ghc-7.8 interpret TypeableN as Typeable?
Not really: ghc-7.8 does still support TypeableN I think (for backward compat
reasons). So it can't take it to mean two different things.
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Christian Maeder
| Sent: 20 February 2014 15:51
| To: Daniil Frumin
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: [Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
|
| Yes, changing Typeable2 to Typeable in:
|
| {-# LANGUAGE StandaloneDeriving, DeriveDataTypeable #-} ...
| deriving instance Typeable Gr
|
| goes through with ghc-7.8-rc1.
|
| However, this change refuses to compile with ghc-7.6.3:
|
| Expecting two more arguments to `Gr'
| In the stand-alone deriving instance for `Typeable Gr'
|
| This is unfortunate, because I need to add conditional compilation to
| make my code compilable for the two most recent major versions of GHC.
|
| Can you not simply let ghc-7.8 interpret TypeableN as Typeable?
|
| Cheers Christian
|
| Am 13.02.2014 15:36, schrieb Daniil Frumin:
| I think that the preferred solution is to get rid of the custom
| Typeable(2) instances and just derive Typeable
|
| On Thu, Feb 13, 2014 at 5:22 PM, Christian Maeder
| christian.mae...@dfki.de wrote:
| Hi,
|
| with ghc-7.8.20140130 I get the compilation error:
|
| Not in scope: type constructor or class 'Typeable2'
| Perhaps you meant 'Typeable' (imported from Data.Typeable)
|
| What is the recommend way to adjust my code or my dependencies?
|
| Cheers Christian
|
| Am 03.02.2014 23:35, schrieb Austin Seipp:
|
| We are pleased to announce the first release candidate for GHC
| 7.8.1:
|
|http://www.haskell.org/ghc/dist/7.8.1-rc1/
|http://www.haskell.org/ghc/docs/7.8.1-rc1/html/
|
| This includes the source tarball and bindists for Windows, Linux, OS
| X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy
| of the SHA256 hashes available (attached) using my GPG key (keyid
| 0x3B58D86F).
|
| We plan to make the 7.8.1 RC2 release quite soon, as we're aware of
| some existing issues.
|
| Please test as much as possible; bugs are much cheaper if we find
| them before the release!
|
|
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Solaris bindist] ANNOUNCE: GHC 7.8.1 Release Candidate 1
Am 06.02.2014 15:27, schrieb Páli Gábor János: On Thu, Feb 6, 2014 at 1:39 PM, Merijn Verstraaten mer...@inconsistent.nl wrote: On Feb 6, 2014, at 10:33 , Christian Maeder wrote: or (as I've seen elsewhere) better (?) #!/usr/bin/env bash Definitely use this, FreeBSD (for example) does not ship with bash so /bin/bash will *not* exist. Please, do not introduce dependency on bash unless it is really necessary. In fact ./configure detects /bin/bash as SHELL under Solaris, so this setting could be used (instead of hard coding bin/sh)! (Under FreeBSD a proper other SHELL might be found by ./configure.) Many configure files of libraries also set SHELL this way. Yet, for this ghc-pwd-bindist script it is easier to make the script (Bourne) /bin/sh compatible. Yet, I have not found out, how this script is created! utils/ghc-pwd/ghc.mk contains utils/ghc-pwd_dist-install_WANT_BINDIST_WRAPPER = YES but then I'm lost what build-prog does from rules/build-prog.mk. Maybe somehow the code in libraries/Cabal/Cabal/Distribution/Simple/Program/Script.hs is called, then the second line should be changed from: setEnv (var, Nothing) = [unset ++ var, export ++ var] setEnv (var, Just val) = [export ++ var ++ = ++ quote val] to: setEnv (var, Nothing) = [unset ++ var, export ++ var] setEnv (var, Just val) = [var ++ = ++ quote val, export ++ var] I guess that is still POSIX compliant. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Typeable2] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
Hi, with ghc-7.8.20140130 I get the compilation error: Not in scope: type constructor or class ‛Typeable2’ Perhaps you meant ‛Typeable’ (imported from Data.Typeable) What is the recommend way to adjust my code or my dependencies? Cheers Christian Am 03.02.2014 23:35, schrieb Austin Seipp: We are pleased to announce the first release candidate for GHC 7.8.1: http://www.haskell.org/ghc/dist/7.8.1-rc1/ http://www.haskell.org/ghc/docs/7.8.1-rc1/html/ This includes the source tarball and bindists for Windows, Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of the SHA256 hashes available (attached) using my GPG key (keyid 0x3B58D86F). We plan to make the 7.8.1 RC2 release quite soon, as we're aware of some existing issues. Please test as much as possible; bugs are much cheaper if we find them before the release! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
Hi Karel, Ok, yet I suppose that the #!/bin/sh script in ghc-pwd-bindist will still fail for me on Solaris 10, even if I build ghc from sources. Why was this script changed? (Or was it not?) Is still a (non-trivial) haskell binary needed to compute the current directory for ./configure? Alternatively, if one does not want to make export LD_LIBRARY_PATH ... Bourne shell compatible, one should start the script with: #!/bin/bash or (as I've seen elsewhere) better (?) #!/usr/bin/env bash Cheers Christian Am 05.02.2014 23:43, schrieb Karel Gardas: Hi Christian, the bindist is compiled on Solaris 11.0 so probably of no use for you on Solaris 10. Also I needed to provide separate tarball of compiled and installed libgmp.so as the Solaris 11's provided does not satisfy GHC requirements and GHC refuses to use that... Karel On 02/ 5/14 04:28 PM, Christian Maeder wrote: Hi, I was surprised to find a Solaris bindist. However, on our SunOS 5.10 ./configure failed miserably. -bash-3.2$ ./configure checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: LD_LIBRARY_PATH=libraries/directory/dist-install/build:libraries/unix/dist-install/build:libraries/time/dist-install/build:libraries/old-locale/dist-install/build:libraries/filepath/dist-install/build:libraries/bytestring/dist-install/build:libraries/deepseq/dist-install/build:libraries/array/dist-install/build:libraries/base/dist-install/build:libraries/integer-gmp/dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:/opt/csw/lib: is not an identifier configure: error: cannot determine current directory This happens, because our /bin/sh is a real sh (and not a bash) that only allows to export LD_LIBRARY_PATH as a separate command. The next failure was: ld.so.1: ghc-pwd: fatal: libgmp.so.10: open failed: No such file or directory So I had to extend LD_LIBRARY_PATH manually (by /opt/csw/lib). After this I got: ld.so.1: ghc-pwd: fatal: relocation error: file libraries/unix/dist-install/build/libHSunix-2.7.0.0-ghc7.8.20140130.so: symbol clearenv: referenced symbol not found Which of my libraries is wrong (or too old) despite a matching version number? libdl.so.1 = /lib/libdl.so.1 libgmp.so.10 = /opt/csw/lib/libgmp.so.10 libm.so.2 = /lib/libm.so.2 librt.so.1 = /lib/librt.so.1 libc.so.1 = /lib/libc.so.1 libgcc_s.so.1 = /opt/csw/lib/libgcc_s.so.1 libaio.so.1 = /lib/libaio.so.1 libmd.so.1 = /lib/libmd.so.1 I had to give up! (I'll try to build it from sources if I find time.) Cheers Christian Am 03.02.2014 23:35, schrieb Austin Seipp: We are pleased to announce the first release candidate for GHC 7.8.1: http://www.haskell.org/ghc/dist/7.8.1-rc1/ http://www.haskell.org/ghc/docs/7.8.1-rc1/html/ This includes the source tarball and bindists for Windows, Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of the SHA256 hashes available (attached) using my GPG key (keyid 0x3B58D86F). We plan to make the 7.8.1 RC2 release quite soon, as we're aware of some existing issues. Please test as much as possible; bugs are much cheaper if we find them before the release! ... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
I can no longer build ghc from sources for yet another reason (attached log). sed reports command garbled. I do not even know where to find this call in the makefile infrastructure. I suspect gsed must be used instead (on our Solaris installation). Cheers Christian Am 05.02.2014 23:43, schrieb Karel Gardas: Hi Christian, the bindist is compiled on Solaris 11.0 so probably of no use for you on Solaris 10. Also I needed to provide separate tarball of compiled and installed libgmp.so as the Solaris 11's provided does not satisfy GHC requirements and GHC refuses to use that... Karel On 02/ 5/14 04:28 PM, Christian Maeder wrote: Hi, I was surprised to find a Solaris bindist. However, on our SunOS 5.10 ./configure failed miserably. -bash-3.2$ ./configure checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: LD_LIBRARY_PATH=libraries/directory/dist-install/build:libraries/unix/dist-install/build:libraries/time/dist-install/build:libraries/old-locale/dist-install/build:libraries/filepath/dist-install/build:libraries/bytestring/dist-install/build:libraries/deepseq/dist-install/build:libraries/array/dist-install/build:libraries/base/dist-install/build:libraries/integer-gmp/dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:/opt/csw/lib: is not an identifier configure: error: cannot determine current directory This happens, because our /bin/sh is a real sh (and not a bash) that only allows to export LD_LIBRARY_PATH as a separate command. The next failure was: ld.so.1: ghc-pwd: fatal: libgmp.so.10: open failed: No such file or directory So I had to extend LD_LIBRARY_PATH manually (by /opt/csw/lib). After this I got: ld.so.1: ghc-pwd: fatal: relocation error: file libraries/unix/dist-install/build/libHSunix-2.7.0.0-ghc7.8.20140130.so: symbol clearenv: referenced symbol not found Which of my libraries is wrong (or too old) despite a matching version number? libdl.so.1 = /lib/libdl.so.1 libgmp.so.10 = /opt/csw/lib/libgmp.so.10 libm.so.2 = /lib/libm.so.2 librt.so.1 = /lib/librt.so.1 libc.so.1 = /lib/libc.so.1 libgcc_s.so.1 = /opt/csw/lib/libgcc_s.so.1 libaio.so.1 = /lib/libaio.so.1 libmd.so.1 = /lib/libmd.so.1 I had to give up! (I'll try to build it from sources if I find time.) Cheers Christian Am 03.02.2014 23:35, schrieb Austin Seipp: We are pleased to announce the first release candidate for GHC 7.8.1: http://www.haskell.org/ghc/dist/7.8.1-rc1/ http://www.haskell.org/ghc/docs/7.8.1-rc1/html/ This includes the source tarball and bindists for Windows, Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of the SHA256 hashes available (attached) using my GPG key (keyid 0x3B58D86F). We plan to make the 7.8.1 RC2 release quite soon, as we're aware of some existing issues. Please test as much as possible; bugs are much cheaper if we find them before the release! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users log.gz Description: GNU Zip compressed data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[OS X mavericks and lifted-base] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
cabal install lifted-base finally fails with: [5 of 6] Compiling Control.Exception.Lifted ( Control/Exception/Lifted.hs, dist/build/Control/Exception/Lifted.p_o ) Control/Exception/Lifted.hs:82:1: Warning: The import of ‛Monad’ from module ‛Control.Monad’ is redundant [6 of 6] Compiling Control.Concurrent.Lifted ( Control/Concurrent/Lifted.hs, dist/build/Control/Concurrent/Lifted.p_o ) ld: library not found for -lHSmonad-control-0.3.2.2-ghc7.8.20140130 clang: error: linker command failed with exit code 1 (use -v to see invocation) Failed to install lifted-base-0.2.1.1 base-unicode-symbols-0.2.2.4 monad-control-0.3.2.2 transformers-base-0.4.1 are properly installed. There is a library libHSmonad-control-0.3.2.2.a (but no libHSmonad-control-0.3.2.2-ghc7.8.20140130.a) Cheers Christian Am 03.02.2014 23:35, schrieb Austin Seipp: We are pleased to announce the first release candidate for GHC 7.8.1: http://www.haskell.org/ghc/dist/7.8.1-rc1/ http://www.haskell.org/ghc/docs/7.8.1-rc1/html/ This includes the source tarball and bindists for Windows, Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of the SHA256 hashes available (attached) using my GPG key (keyid 0x3B58D86F). We plan to make the 7.8.1 RC2 release quite soon, as we're aware of some existing issues. Please test as much as possible; bugs are much cheaper if we find them before the release! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
Hi, I was surprised to find a Solaris bindist. However, on our SunOS 5.10 ./configure failed miserably. -bash-3.2$ ./configure checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd-bindist: LD_LIBRARY_PATH=libraries/directory/dist-install/build:libraries/unix/dist-install/build:libraries/time/dist-install/build:libraries/old-locale/dist-install/build:libraries/filepath/dist-install/build:libraries/bytestring/dist-install/build:libraries/deepseq/dist-install/build:libraries/array/dist-install/build:libraries/base/dist-install/build:libraries/integer-gmp/dist-install/build:libraries/ghc-prim/dist-install/build:rts/dist/build:/opt/csw/lib: is not an identifier configure: error: cannot determine current directory This happens, because our /bin/sh is a real sh (and not a bash) that only allows to export LD_LIBRARY_PATH as a separate command. The next failure was: ld.so.1: ghc-pwd: fatal: libgmp.so.10: open failed: No such file or directory So I had to extend LD_LIBRARY_PATH manually (by /opt/csw/lib). After this I got: ld.so.1: ghc-pwd: fatal: relocation error: file libraries/unix/dist-install/build/libHSunix-2.7.0.0-ghc7.8.20140130.so: symbol clearenv: referenced symbol not found Which of my libraries is wrong (or too old) despite a matching version number? libdl.so.1 =/lib/libdl.so.1 libgmp.so.10 = /opt/csw/lib/libgmp.so.10 libm.so.2 = /lib/libm.so.2 librt.so.1 =/lib/librt.so.1 libc.so.1 = /lib/libc.so.1 libgcc_s.so.1 = /opt/csw/lib/libgcc_s.so.1 libaio.so.1 = /lib/libaio.so.1 libmd.so.1 =/lib/libmd.so.1 I had to give up! (I'll try to build it from sources if I find time.) Cheers Christian Am 03.02.2014 23:35, schrieb Austin Seipp: We are pleased to announce the first release candidate for GHC 7.8.1: http://www.haskell.org/ghc/dist/7.8.1-rc1/ http://www.haskell.org/ghc/docs/7.8.1-rc1/html/ This includes the source tarball and bindists for Windows, Linux, OS X, FreeBSD, and Solaris, on x86 and x86_64. There is a signed copy of the SHA256 hashes available (attached) using my GPG key (keyid 0x3B58D86F). We plan to make the 7.8.1 RC2 release quite soon, as we're aware of some existing issues. Please test as much as possible; bugs are much cheaper if we find them before the release! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
Am 05.02.2014 16:45, schrieb Roman Cheplyaka: * Christian Maeder christian.mae...@dfki.de [2014-02-05 16:28:50+0100] This happens, because our /bin/sh is a real sh (and not a bash) that only allows to export LD_LIBRARY_PATH as a separate command. You mean it's a real sh and not a POSIX-compatible one. http://pubs.opengroup.org/onlinepubs/009695399/utilities/export.html Whatever it is, maybe it is a Korn Shell under (older) Solaris, it does not support: export name=word One has to write: name=word export name C. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Solaris bindist] Re: ANNOUNCE: GHC 7.8.1 Release Candidate 1
Am 05.02.2014 17:06, schrieb Brandon Allbery: Whatever it is, maybe it is a Korn Shell under (older) Solaris, it does not support: The Korn shell is where the `export NAME=value` syntax originated. It is a Bourne Shell under (our) SunOS 5.10 (not to be mixed up with Bourne-again shell bash) I think it is easy to stay shell compatible. C. I am tempted to suggest that we verify that this is still in current POSIX standards (the cited one is from 2004); POSIX recently dropped a significant number of Korn-shell-derived behaviors from the standard. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com mailto:allber...@gmail.com ballb...@sinenomine.net mailto:ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.2 Release Candidate 1
worked for me under x86 SunOS 5.10 Cheers Christian OVERALL SUMMARY for test run started at Donnerstag, 3. Januar 2013, 09:52:19 Uhr CET 3402 total tests, which gave rise to 13556 test cases, of which 10 caused framework failures 10486 were skipped 2954 expected passes 47 had missing libraries 36 expected failures 0 unexpected passes 33 unexpected failures Unexpected failures: ../../libraries/base/tests/IOopenFile003 [bad stdout] (normal) ../../libraries/process/tests3994 [bad exit code] (threaded1) ../../libraries/process/testsprocess007 [bad stdout] (normal) ../../libraries/unix/tests 3816 [bad exit code] (normal) ../../libraries/unix/tests user001 [bad stdout] (normal) ../../libraries/unix/tests/libposix posix002 [bad exit code] (normal) ../../libraries/unix/tests/libposix posix005 [bad stdout] (normal) cabal/cabal01cabal01 [bad exit code] (normal) cabal/cabal03cabal03 [bad exit code] (normal) cabal/cabal04cabal04 [bad exit code] (normal) lib/integer IntegerConversionRules [bad stderr] (normal) lib/integer T7041 [bad stderr] (normal) lib/integer integerConstantFolding [bad exit code] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) perf/haddock haddock.compiler [stat too good] (normal) plugins plugins01 [bad exit code] (normal) plugins plugins02 [stderr mismatch] (normal) plugins plugins03 [stderr mismatch] (normal) rts exec_signals [bad exit code] (normal) safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly04 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly05 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly06 [exit code non-0] (normal) safeHaskell/check/pkg01 ImpSafeOnly07 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly08 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly09 [stderr mismatch] (normal) safeHaskell/check/pkg01 ImpSafeOnly10 [exit code non-0] (normal) safeHaskell/check/pkg01 safePkg01 [bad exit code] (normal) simplCore/should_compile T5658b [bad exit code] (normal) simplCore/should_compile T5776 [bad exit code] (normal) On 09/12/12 21:39, Ian Lynagh wrote: We are pleased to announce the first release candidate for GHC 7.6.2: http://www.haskell.org/ghc/dist/7.6.2-rc1/ This includes the source tarball, installers for Windows, and bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64. We plan to make the 7.6.2 release early in 2013. Please test as much as possible; bugs are much cheaper if we find them before the release! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Partial statical linking
Hi, I usually just copy those .a files (that should be linked statically) into `ghc --print-libdir`. HTH Christian Am 19.09.2012 13:06, schrieb Jason Dusek: 2011/12/1 Irene Knapp ireney.kn...@gmail.com: The typical trick to force GHC to statically link a C library is to give the full path to the .a of it as one of the object files in the GHC invocation that does the final linking. This means you don't need any -l or -L flags pertaining to that library. Some libraries are very particular about the order you list them in when doing this, but I don't really understand the issues there. You usually will also have to chase dependencies by hand and list them in the same fashion. I recently tried using this method to create static binary; but I was not able to get it to work. I thought I would revive this old thread and see if anyone else has given it a shot. What I attempted was building a binary with only some C libraries statically linked, with this command line: # Build https://github.com/erudify/sssp on Ubunut 12.04 ghc -outputdir ./tmp -v --make -O2 sssp.hs -o sssp.ubuntu \ /usr/lib/x86_64-linux-gnu/libffi.a \ /usr/lib/x86_64-linux-gnu/libgmp.a \ /usr/lib/x86_64-linux-gnu/libz.a However, this really made no difference. Running `ldd' on the resulting binary reveals that libz and friends are still dynamically linked: ldd sssp.ubuntu linux-vdso.so.1 = (0x7fff94253000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f0ddfdbb000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f0ddfb9e000) libgmp.so.10 = /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f0ddf92f000) libffi.so.6 = /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f0ddf727000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f0ddf42d000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f0ddf224000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0ddf02) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f0ddec63000) /lib64/ld-linux-x86-64.so.2 (0x7f0ddffdb000) There is always -optl-static which, nowadays, results in a truly static executable; but it leads to a lot of warnings, too. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
import Module qualified as
Hi, my import lists would look much nicer und could be sorted more easily if the keyword qualified could be placed before the as keyword instead of after import. Therefore I suggest the alternative syntax: import Data.Map qualified as Map This should be fairly simple to implement, if more users would want it. Note, that this syntax does not work well without as since a list of names to be imported usually follows the module name. Also, usually qualified imports are used together with as to avoid the long module names. Apart from sorting it would also avoid quirks like _eleven_ spaces in: import qualified Data.Map as Map import Data.Map (Map) Cheers Christian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: GADTs in the wild
Am 15.08.2012 23:13, schrieb Yitzchak Gale:
But in my opinion, by far the best solution, using only
GADTs, was submitted by Eric Mertens:
http://hpaste.org/44469/software_stack_puzzle
Eric's solution could now be simplified even further
using data kinds.
Find attached a version (based on Eric's solution) that uses only
ExistentialQuantification.
data Fun a c = First (a - c)
| forall b . Serializable b = Fun b c :. (a - b)
instead of:
data Fun :: * - * - * where
Id :: Fun a a
(:.) :: Serializable b = Fun b c - (a - b) - Fun a c
The main problem seems to be to create a dependently typed list of
functions (the type of the next element depends on the previous one)
For such a list the element type depends on the index, therefore it
seems not possible to define take and drop over Fun a c and compose it
like
serialize . flatten (take n fs) . deserialize
(as would be easily possible with functions of type a - a)
Cheers Christian
Yitz
{-# LANGUAGE ExistentialQuantification #-}
module Puzzle where
import Data.ByteString (ByteString, singleton)
class Serializable a where
serialize :: a - ByteString
deserialize :: ByteString - a
data Fun a c = First (a - c)
| forall b . Serializable b = Fun b c :. (a - b)
infixl 9 :.
-- Simple conversion
flatten :: Fun a b - a - b
flatten (First f) = f
flatten (fs :. f) = flatten fs . f
-- Layering example
runLayers :: (Serializable a, Serializable b)
= Int - Int - Fun a b - ByteString - ByteString
runLayers n m f = case f of
fs :. _ | n 1 - runLayers (n - 1) (m - 1) fs
_ - runLayers' m f . deserialize
runLayers' :: (Serializable a, Serializable b)
= Int - Fun a b - a - ByteString
runLayers' m f = if m = 1 then serialize else case f of
fs :. g - runLayers' (m - 1) fs . g
First g - serialize . g
data Layer1 = Layer1
data Layer2 = Layer2
data Layer3 = Layer3
data Layer4 = Layer4
softwareStack :: Fun Layer1 Layer4
softwareStack =
First (\ Layer3 - Layer4) :. (\ Layer2 - Layer3) :. (\ Layer1 - Layer2)
example1 = runLayers 2 4 softwareStack (singleton 2) == singleton 4
example2 = runLayers 1 3 softwareStack (singleton 1) == singleton 3
-- Boring serialization instances
instance Serializable Layer1 where
serialize Layer1 = singleton 1
deserialize bs | bs == singleton 1 = Layer1
instance Serializable Layer2 where
serialize Layer2 = singleton 2
deserialize bs | bs == singleton 2 = Layer2
instance Serializable Layer3 where
serialize Layer3 = singleton 3
deserialize bs | bs == singleton 3 = Layer3
instance Serializable Layer4 where
serialize Layer4 = singleton 4
deserialize bs | bs == singleton 4 = Layer4
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.1 Release Candidate 1
Am 14.08.2012 16:08, schrieb Simon Hengel: On Tue, Aug 14, 2012 at 03:47:18PM +0200, Christian Maeder wrote: [...] I cannot test much, as long as the text package cannot be installed. Feel free to use my git version: https://github.com/sol/text Thanks, I've use it for http://hackage.haskell.org/trac/ghc/ticket/7150 C. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs in the wild
Well, Either was an adhoc choice and should be application specific. Another h98 solution would be to keep the common part in a single constructor: data UserOrAppData = AppData | UserData UserId UTCTime data AccessToken = AccessToken UserOrAppData AccessTokenData or: data AccessToken a = AccessToken a AccessTokenData C. Am 14.08.2012 18:32, schrieb Felipe Almeida Lessa: 2012/8/14 Christian Maeder christian.mae...@dfki.de: Why not use plain h98? data UserAccessToken = UserAccessToken UserId AccessTokenData UTCTime data AppAccessToken = AppAccessToken AccessTokenData type AccessToken = Either UserAccessToken AppAccessToken Convenience. It's better to write case token of UserAccessToken ... - ... AppAccessToken ... - ... than case token of Left (UserAccessToken ...) - ... Right (UserAccessToken ...) - ... Also, it's easier to write isValid token than isValid (Right token) -- or is it Left? Cheers, =) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs in the wild
Am 15.08.2012 17:58, schrieb Felipe Almeida Lessa: On Wed, Aug 15, 2012 at 12:54 PM, Christian Maeder christian.mae...@dfki.de wrote: Well, Either was an adhoc choice and should be application specific. Another h98 solution would be to keep the common part in a single constructor: data UserOrAppData = AppData | UserData UserId UTCTime data AccessToken = AccessToken UserOrAppData AccessTokenData This is a non-solution since you can't specify anymore that you want an user access token but not an app access token. or: data AccessToken a = AccessToken a AccessTokenData And this one brings us the Either again (although on fewer places). Most functions would be able to get a `AccessToken a` because they don't care about what you called `UserData` above. However, some other functions (such as isValid) do care about that and would need `Either (AccessToken AppData) (AccessToken UserData)`. This type does not share the AccessTokenData and corresponds to AccessToken UserOrAppData. That's not to say that we *couldn't* avoid GADTs. We certainly could. But GADTs allow us to have our cake and eat it, too =). Sure, but portability is a value, too. C. Cheers, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.6.1 Release Candidate 1
Am 12.08.2012 21:57, schrieb Ian Lynagh: We are pleased to announce the first release candidate for GHC 7.6.1: http://www.haskell.org/ghc/dist/7.6.1-rc1/ This includes the source tarball, installers for 32bit and 64bit Windows, and bindists for amd64/Linux, i386/Linux, amd64/OSX and i386/OSX. Please test as much as possible; bugs are much cheaper if we find them before the release! I cannot test much, as long as the text package cannot be installed. dependency integer-gmp needs to be increased and: -bash-3.00$ cabal build Building text-0.11.2.2... Preprocessing library text-0.11.2.2... [26 of 39] Compiling Data.Text.IO.Internal ( Data/Text/IO/Internal.hs, dist/build/Data/Text/IO/Internal.o ) Data/Text/IO/Internal.hs:35:24: Module `Prelude' does not export `catch' C. Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GADTs in the wild
Am 14.08.2012 14:48, schrieb Felipe Almeida Lessa: data AccessToken kind where UserAccessToken :: UserId - AccessTokenData - UTCTime - AccessToken UserKind AppAccessToken :: AccessTokenData - AccessToken AppKind data UserKind data AppKind (Yes, that could be a data kind!) And for convenience we also export some type synonyms: type UserAccessToken = AccessToken UserKind type AppAccessToken = AccessToken AppKind Why not use plain h98? data UserAccessToken = UserAccessToken UserId AccessTokenData UTCTime data AppAccessToken = AppAccessToken AccessTokenData type AccessToken = Either UserAccessToken AppAccessToken C. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] parsec: parserFail multiple error messages
The error message can be improved in your examples by using count 5 instead of many1. C. Am 08.08.2012 21:24, schrieb silly: I am trying to create a parsec parser that parses an integer and then checks if that integer has the right size. If not, it generates an error. I tried the following: 8--- import Text.Parsec import Text.Parsec.String integer :: Parser Int integer = do s - many1 digit let n = read s if n 65535 then parserFail integer overflow else return n 8--- The problem is that when I try this parse integer 7 I get the following error: Left (line 1, column 6): unexpected end of input expecting digit integer overflow ie there are three error messages but I only want the last one. Is there something I can do about this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need help with learning Parsec
Am 22.07.2012 17:21, schrieb C K Kashyap: I've updated the parser here - https://github.com/ckkashyap/LearningPrograms/blob/master/Haskell/Parsing/xml_3.hs The whole thing is less than 100 lines and it can handle comments as well. This code is still not nice: Duplicate code in openTag and withoutExplictCloseTag. The toplevel-try in try withoutExplictCloseTag | withExplicitCloseTag should be avoided by factoring out the common prefix. Again, I would avoid notFollowedBy by using many1. tag - try(char '' many1 (letter | digit)) In quotedChar you do not only want to escape the quote but at least the backslash, too. You could allow to escape any character by a backslash using: quotedChar c = try (char '\\' anyChar) | noneOf [c, '\\'] Writing a separate parser stripLeadingSpaces is overkill. Just use spaces parseXML (or apply dropWhile isSpace to the input string) C. [...] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to select random elements of a Data.Set?
Am 20.07.2012 15:24, schrieb jwaldmann: Dear all, how would I quickly select an element of a Set (as in Data.Set) uniformly at random? If you use a Map a () (or Map a a) you can use Map.elemAt. The initial conversion is still linear, though. -- | convert a set into an identity map setToMap :: Ord a = Set.Set a - Map.Map a a setToMap = Map.fromDistinctAscList . List.map (\ a - (a, a)) . Set.toList HTH C. Via the API, this can only be done in linear time? (via toList) If I could access the tree structure, then of course it could be logarithmic. But probably I'd need a weighted selection sooner or later, and this would require some specific code anyway. Or does it not? Actually I need a sequence of such selections (each selected element is deleted immediately). I don't need all elements (so, computing a random permuation might be too much). J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need help with learning Parsec
Am 19.07.2012 14:53, schrieb C K Kashyap:
Dear gentle Haskellers,
I was trying to whet my Haskell by trying out Parsec today to try and
parse out XML. Here's the code I cam up with -
I wanted some help with the gettext parser that I've written. I had to
do a dummy char ' ') in there just to satisfy the many used in the
xml parser. I'd appreciate it very much if someone could give me some
feedback.
You don't want empty bodies! So use many1 in gettext.
gettext = fmap Body $ many1 $ letter | digit
If you have spaces in your bodies, skip them or allow them with
noneOf .
HTH Christian
data XML = Node String [XML]
| Body String deriving Show
gettext = do
x - many (letter | digit )
if (length x) 0 then
return (Body x)
else (char ' ' (return $ Body ))
xml :: Parser XML
xml = do {
name - openTag
; innerXML - many innerXML
; endTag name
; return (Node name innerXML)
}
innerXML = do
x - (try xml | gettext)
return x
openTag :: Parser String
openTag = do
char ''
content - many (noneOf )
char ''
return content
endTag :: String - Parser String
endTag str = do
char ''
char '/'
string str
char ''
return str
h1 = parse xml aA/a
h2 = parse xml abA/b/a
h3 = parse xml abc/c/b/a
h4 = parse xml ab/bc/c/a
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need help with learning Parsec
Am 19.07.2012 14:53, schrieb C K Kashyap: innerXML = do x - (try xml | gettext) return x Omit try (and return). xml always starts with whereas gettext never does. C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need help with learning Parsec
Am 19.07.2012 15:14, schrieb Christian Maeder: Am 19.07.2012 14:53, schrieb C K Kashyap: innerXML = do x - (try xml | gettext) return x Omit try (and return). xml always starts with whereas gettext never does. I was wrong, you do not want to swallow an endTag as openTag. openTag should start with: try $ char '' notFollowedBy (char '/') and endTag should start with: try $ string / C. C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need help with learning Parsec
Am 19.07.2012 15:26, schrieb Christian Maeder: Am 19.07.2012 15:14, schrieb Christian Maeder: Am 19.07.2012 14:53, schrieb C K Kashyap: innerXML = do x - (try xml | gettext) return x Omit try (and return). xml always starts with whereas gettext never does. I was wrong, you do not want to swallow an endTag as openTag. openTag should start with: try $ char '' notFollowedBy (char '/') and endTag should start with: try $ string / Strictly, the try in endTag is not necessary (only in openTag) C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need help with learning Parsec
Am 19.07.2012 15:41, schrieb Simon Hengel: On Thu, Jul 19, 2012 at 03:34:47PM +0200, Simon Hengel wrote: openTag :: Parser String openTag = char '' * many (noneOf ) * char '' if you disallow empty tags and / within tags, then you can avoid the notFollowedBy construct by: openTag = try (char '' * many1 (noneOf /)) * char '' C. endTag :: String - Parser String endTag str = string / * string str * char '' Well yes, modified to what Christian Maeder just suggested. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: How to describe this bug?
Hi, I think this bug is serious and should be turned into a ticket on http://hackage.haskell.org/trac/ghc/ Would you do so Sönke? The abstraction of floats (Float or Double) is broken if equality considers (random and invisible) excess bits that are not part of the ordinary sign, exponent and fraction representation. It should also hold: show f1 == show f2 = f1 == f2 and: read (show f) == f (apart from NaN) Why do you doubt that we'll ever fix this, Simon? What is the problem to disable -fexcess-precision or enable -msse2 (on most machines) by default? Cheers Christian Am 10.07.2012 14:33, schrieb Simon Marlow: On 10/07/2012 12:21, Aleksey Khudyakov wrote: On Tue, Jul 10, 2012 at 3:06 PM, Sönke Hahn sh...@cs.tu-berlin.de wrote: I've attached the code. The code does not make direct use of unsafePerformIO. It uses QuickCheck, but I don't think, this is a QuickCheck bug. The used Eq-instance is the one for Float. I've only managed to reproduce this bug on 32-bit-linux with ghc-7.4.2 when compiling with -O2. It's expected behaviour with floats. Calculations in FPU are done in maximul precision available. If one evaluation result is kept in registers and another has been moved to memory and rounded and move back to registers number will be not the same indeed. In short. Never compare floating point number for equality unless you really know what are you doing. I consider it a bug, because as the original poster pointed out it is a violation of referential transparency. What's more, it is *not* an inherent property of floating point arithmetic, because if the compiler is careful to do all the operations at the correct precision then you can get determinstic results. This is why GHC has the -fexcess-precision flag: you have to explicitly ask to break referential transparency. The bug is that the x86 native code generator behaves as if -fexcess-precision is always on. I seriously doubt that we'll ever fix this bug: you can get correct behaviour by enabling -msse2, or using a 64-bit machine. I don't off-hand know what the LLVM backend does here, but I would guess that it has the same bug. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to describe this bug?
Am 11.07.2012 10:25, schrieb Simon Marlow: On 11/07/2012 08:36, Christian Maeder wrote: Hi, I think this bug is serious and should be turned into a ticket on http://hackage.haskell.org/trac/ghc/ Would you do so Sönke? The abstraction of floats (Float or Double) is broken if equality considers (random and invisible) excess bits that are not part of the ordinary sign, exponent and fraction representation. It should also hold: show f1 == show f2 = f1 == f2 and: read (show f) == f (apart from NaN) Why do you doubt that we'll ever fix this, Simon? Several reasons: - the fix hurts performance badly, because you have to store floats into memory after every operation. (c.f. gcc's -ffloat-store option) If we sacrifice correctness for performance then we should clearly document this! Is it not enough to store floats into memory just before equality tests (or add rounding in the instance definitions of Float and Double in Eq and Ord)? - the fix is complicated - good workarounds exist (-msse2) - it is rarely a problem Rare cases are extremely hard to track down if they occur! What is the problem to disable -fexcess-precision or enable -msse2 (on most machines) by default? -fexcess-precision cannot be disabled on x86 (that is the bug). -msse2 is not supported on all processors, so we can't enable it by default. Can't configure find this out? C. Cheers, Simon Cheers Christian Am 10.07.2012 14:33, schrieb Simon Marlow: On 10/07/2012 12:21, Aleksey Khudyakov wrote: On Tue, Jul 10, 2012 at 3:06 PM, Sönke Hahn sh...@cs.tu-berlin.de wrote: I've attached the code. The code does not make direct use of unsafePerformIO. It uses QuickCheck, but I don't think, this is a QuickCheck bug. The used Eq-instance is the one for Float. I've only managed to reproduce this bug on 32-bit-linux with ghc-7.4.2 when compiling with -O2. It's expected behaviour with floats. Calculations in FPU are done in maximul precision available. If one evaluation result is kept in registers and another has been moved to memory and rounded and move back to registers number will be not the same indeed. In short. Never compare floating point number for equality unless you really know what are you doing. I consider it a bug, because as the original poster pointed out it is a violation of referential transparency. What's more, it is *not* an inherent property of floating point arithmetic, because if the compiler is careful to do all the operations at the correct precision then you can get determinstic results. This is why GHC has the -fexcess-precision flag: you have to explicitly ask to break referential transparency. The bug is that the x86 native code generator behaves as if -fexcess-precision is always on. I seriously doubt that we'll ever fix this bug: you can get correct behaviour by enabling -msse2, or using a 64-bit machine. I don't off-hand know what the LLVM backend does here, but I would guess that it has the same bug. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to describe this bug?
Am 10.07.2012 13:06, schrieb Sönke Hahn: I've attached the code. The code does not make direct use of unsafePerformIO. It uses QuickCheck, but I don't think, this is a QuickCheck bug. The used Eq-instance is the one for Float. The Eq-instance for floats is broken wrt NaN Prelude (0/0 :: Float) == 0/0 False I do not know if you create NaN in your tests, though. C. I've only managed to reproduce this bug on 32-bit-linux with ghc-7.4.2 when compiling with -O2. (The code might seem a bit odd, but this is the most boiled down version I could come up with. Even removing the module Main where line changes the behaviour.) Cheers, Sönke On 07/10/2012 12:51 PM, malcolm.wallace wrote: Also, it is more likely to be a buggy instance of Eq, than a real loss of referential transparency. Regards, Malcolm On Jul 10, 2012, at 11:49 AM, Christopher Done chrisd...@gmail.com wrote: Depends what the real offending code is. For example, if it contains unsafePerformIO then it's not a bug. On 10 July 2012 12:42, Sönke Hahn sh...@cs.tu-berlin.de mailto:sh...@cs.tu-berlin.de wrote: Hi! I've discovered a strange bug that violates simple equational reasoning. Basically, something similar to this: let a = f x in a == f x evaluates to False. I'd like to report this on ghc-trac, but I realised, that I don't know a good name for behaviour like this. Is there one? Broken referential transparency, perhaps? Thanks, Sönke ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org mailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org mailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to describe this bug?
It also works (exposes the bug on x86) without Quickcheck and Doubles: main = prop 6.0 0.109998815 prop m x = do let a = x * m putStrLn (show a ++ foo) print (x * m == a) 0.65999289 foo False The middle line seems to prevent CSE. C. Am 10.07.2012 13:06, schrieb Sönke Hahn: I've attached the code. The code does not make direct use of unsafePerformIO. It uses QuickCheck, but I don't think, this is a QuickCheck bug. The used Eq-instance is the one for Float. I've only managed to reproduce this bug on 32-bit-linux with ghc-7.4.2 when compiling with -O2. (The code might seem a bit odd, but this is the most boiled down version I could come up with. Even removing the module Main where line changes the behaviour.) Cheers, Sönke On 07/10/2012 12:51 PM, malcolm.wallace wrote: Also, it is more likely to be a buggy instance of Eq, than a real loss of referential transparency. Regards, Malcolm On Jul 10, 2012, at 11:49 AM, Christopher Done chrisd...@gmail.com wrote: Depends what the real offending code is. For example, if it contains unsafePerformIO then it's not a bug. On 10 July 2012 12:42, Sönke Hahn sh...@cs.tu-berlin.de mailto:sh...@cs.tu-berlin.de wrote: Hi! I've discovered a strange bug that violates simple equational reasoning. Basically, something similar to this: let a = f x in a == f x evaluates to False. I'd like to report this on ghc-trac, but I realised, that I don't know a good name for behaviour like this. Is there one? Broken referential transparency, perhaps? Thanks, Sönke ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org mailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org mailto:Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Associative prefix operators in Parsec
Am 08.03.2012 17:16, schrieb Troels Henriksen:
Christian Maederchristian.mae...@dfki.de writes:
The simplest solution is to parse the prefixes yourself and do not put
it into the table.
(Doing the infixes and | by hand is no big deal, too, and
possibly easier then figuring out the capabilities of
buildExpressionParser)
Is there another solution? My post was a simplified example to showcase
the problem; in general I would prefer to use a function to build the
expression parser. I could just write my own that does not have this
problem, and in fact, I already have, I just wanted to know whether
Parsec could be wrangled into shape.
Yes, it certainly could do better. The code for prefix and postfix
currently looks like:
termP = do{ pre - prefixP
; x- term
; post - postfixP
; return (post (pre x))
}
This supports (only) one prefix or postfix (or both), where the prefix
binds stronger than the postfix (although, they have equal precedence).
Problem 1: - - 5 is not supported
Another problem are prefix or postfix operators that bind weaker than
infixes, like infix ^ and prefix -.
Problem 2: 1 ^ -2 is rejected, although no other parsing is possible.
(The same would apply to a weakly binding postfix operator following the
left argument: 4+ ^ 5. This would even need some look ahead to find
out, if + is not an infix and ^ a prefix operator)
(Haskell features these problems, too.)
Maybe the special case of repeated prefixes could be solved by putting
in the prefix entry twice into the table for the
currentbuildExpressionParser, but considering possibly equal symbols for
prefix, postfix or infix symbols seems quite difficult, although only an
ambiguity needs to be reported.
Cheers C.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Associative prefix operators in Parsec
The simplest solution is to parse the prefixes yourself and do not put
it into the table.
(Doing the infixes and | by hand is no big deal, too, and possibly
easier then figuring out the capabilities of buildExpressionParser)
Cheers C.
Am 07.03.2012 13:08, schrieb Troels Henriksen:
Consider a simple language of logical expressions:
import Control.Applicative
import Text.Parsec hiding ((|), many)
import Text.Parsec.String
import Text.Parsec.Expr
data Expr = Truth
| Falsity
| And Expr Expr
| Or Expr Expr
| Not Expr
deriving (Show, Eq)
I define a simple expression parser using Parsec:
expr :: Parser Expr
expr= buildExpressionParser table (lexeme term)
? expression
term :: Parser Expr
term= between (lexeme (char '(')) (lexeme (char ')')) expr
| bool
? simple expression
bool :: Parser Expr
bool = lexeme (string true * pure Truth)
| lexeme (string false * pure Falsity)
lexeme :: Parser a - Parser a
lexeme p = p* spaces
table = [ [prefix ! Not ]
, [binary And AssocLeft ]
, [binary | Or AssocLeft ]
]
binary name fun assoc = Infix (do{ lexeme (string name); return fun }) assoc
prefix name fun = Prefix (do{ lexeme (string name); return fun })
Now this doesn't work:
test1 = parseTest expr !!true
But this does:
test2 = parseTest expr !(!true)
I have studied the code for buildExpressionParser, and I know why this
happens (prefix operators are treated as nonassociative), but it seems
like one would often want right-associative prefix operators (so test1
would work). Is there a common workaround or solution for this problem?
I assume the nonassociativity in Parsec is by design and not a bug.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
auto-orphans?
Hi, in http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/options-sanity.html I've found no description for -fwarn-auto-orphans Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.0.4 recursion while trying to derive type
Am 08.01.2012 04:39, schrieb Bogdan Opanchuk:
Hello,
Consider the following code:
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, OverlappingInstances,
UndecidableInstances, FunctionalDependencies #-}
We have also such (cruel) code using these extension.
t4.hs:17:31:
Context reduction stack overflow; size = 21
Use -fcontext-stack=N to increase stack size to N
Our code compiles with ghc-7-0.4 if we add -fcontext-stack=31 to the ghc
command line.
Does your code compile with an increased (try 100) context-stack?
[..]
So, the question is, could anyone please tell me, is what I am trying
to do actually correct, and what was changed from 7.0.4 to 7.2.2 to
make it work?
I cannot answer this, but our code also compiles with ghc-7.2.2 using a
lower context-stack (of 26).
HTH Christian
Thank you in advance.
Best regards,
Bogdan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.0.4 recursion while trying to derive type
Am 09.01.2012 13:16, schrieb Christian Maeder: I cannot answer this, but our code also compiles with ghc-7.2.2 using a lower context-stack (of 26). Apologies, I've just re-checked and noticed that our code changed and needs consistently -fcontext-stack=26 for ghc-7.2.2 and ghc-7.0.4 (and ghc-7.0.2). C. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] How to split this string.
Am 05.01.2012 11:57, schrieb Steve Horne: [...] groupCut :: (x - x - Bool) - [x] - [[x]] [...] How about a break function that respects an escape character (1. arg) (and drops the delimiter - 2. arg) and use this function for unfolding? import Data.List break' :: (a - Bool) - (a - Bool) - [a] - ([a], [a]) break' e p l = case l of [] - (l, []) c : r | p c - ([], r) | e c - case r of [] - (l, []) d : t - let (f, s) = break' e p t in (c : d : f, s) | otherwise - let (f, s) = break' e p r in (c : f, s) split' :: (a - Bool) - (a - Bool) - [a] - [[a]] split' e p = unfoldr $ \ l - if null l then Nothing else Just $ break' e p l *Main split' (== '\r') (== '\n') string1\nstring2\r\nstring3\nstring4 [string1,string2\r\nstring3,string4] C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to split this string.
Am 05.01.2012 13:04, schrieb Steve Horne: [...] I was going to accuse you of cheating - who says there's a spare value to use? - but you seem to be using Maybe, so well played. You're also using unfoldr, which I really must play with a bit - I don't really have a feel for how unfolding works ATM. You may prefer another variant of unfoldr (without Maybe): unfoldr' :: ([b] - (a, [b])) - [b] - [a] unfoldr' f l = if null l then [] else let (a, r) = f l in a : unfoldr' f r split' :: (a - Bool) - (a - Bool) - [a] - [[a]] split' e p = unfoldr' $ break' e p C. P.S. my break' function fails for \r\r\n (as the first char escapes the second and the second no longer the third) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to split this string.
Am 04.01.2012 17:47, schrieb Steve Horne: On 02/01/2012 11:12, Jon Fairbairn wrote: maxm...@mtw.ru writes: I want to write a function whose behavior is as follows: foo string1\nstring2\r\nstring3\nstring4 = [string1, string2\r\nstring3, string4] Note the sequence \r\n, which is ignored. How can I do this? Why do you have these (unhealthy) different kinds of line breaks (Unix and Windows style) in your string in the first place? I hope, not by something calling unlines (or intercalate \n) earlier. Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to split this string.
Am 02.01.2012 10:44, schrieb max: I want to write a function whose behavior is as follows: foo string1\nstring2\r\nstring3\nstring4 = [string1, string2\r\nstring3, string4] Note the sequence \r\n, which is ignored. How can I do this? replace the sequence by something unique first, i.e. a single \r (and revert this change later). (Replacing a single character is easier using concatMap). HTH Christian -- | replace first (non-empty) sublist with second one in third -- argument list replace :: Eq a = [a] - [a] - [a] - [a] replace sl r = case sl of [] - error replace: empty list _ - concat . unfoldr (\ l - case l of [] - Nothing hd : tl - Just $ case stripPrefix sl l of Nothing - ([hd], tl) Just rt - (r, rt)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
ghc-7.4.1-rc1 recompilation checking
Hi, full recompilation with ghc-7.4.1-rc1 is already triggered by a changed -o option, which is inconvenient when creating different binaries with shared modules. (see below) It is no problem if I always omit the -o option and get binaries named like my input file, though. Can/should this behaviour of ghc-7.4 be relaxed? Cheers Christian -bash-3.00$ ghc B -o b [1 of 2] Compiling C( C.hs, C.o ) [2 of 2] Compiling Main ( B.hs, B.o ) Linking b ... -bash-3.00$ ghc A -o a [1 of 2] Compiling C( C.hs, C.o ) [2 of 2] Compiling Main ( A.hs, A.o ) Linking a ... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Operator precedence and associativity with Polyparse
Am 26.10.2011 01:49, schrieb Tom Hawkins: Can someone provide guidance on how handle operator precedence and associativity with Polyparse? Do you mean parsing something like 1 + 2 * 3 ? I don't think there's any real difference in using Polyparse vs Parsec for this, except for doing p `orElse` q rather than try p| q. Actually, I was looking for something equivalent to Text.ParserCombinators.Parsec.Expr.buildExpressionParser. I suppose I should learn how Parsec implements this under the hood. I would do it as described under chainl1 in http://hackage.haskell.org/packages/archive/parsec2/1.0.0/doc/html/Text-ParserCombinators-Parsec-Combinator.html I believe Parsec.Expr cannot handle a prefix operator (i.e. unary minus) properly, that has lower precedence than an infix operator (i.e. ^ power). If it can parse -x^2 as -(x^2) then if cannot parse x^ -2 as x^(-2). Cheers Christian -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Am 20.10.2011 21:43, schrieb Michael Snoyman: On Wed, Oct 19, 2011 at 9:29 PM, Ketil Maldeke...@malde.org wrote: Michael Snoymanmich...@snoyman.com writes: sense to try and pursue something like what you're suggesting, but I think the default Show (Vector Word8) should be the one most useful, most of the time, and I think the general consensus seems to be the current ByteString instance fits that role. Hm. I think it is slightly weird to display a numeric value (Word8) as a Char. Also, I would prefer a representation making the type explicit (but unlike ByteString, vector seems to add a type annotation.) Would you still support the truncating behavior for 'read' and values above 255? (ByteString has two interfaces, ByteString and .Char8, but as there can be only one Show instance, I see why it works the way it does.) Perhaps the correct semantic approach would be to have: newtype Char8 = Char8 Word8 But I think that will break far too many applications to try to get it would a new Word8 type be better to stay compatible? newtype Word8 = C8 Data.Word.Word8 C. implemented. In an ideal world, I agree with both points: displaying a numeric value as a Char doesn't make sense, and there are definitely issues with the Read instance. However, I still think current behavior is the least of all available evils. Show/Read work properly as a pair and can encode/decode any ByteString, and there's never any presumption that all input to read is valid. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Am 12.10.2011 16:02, schrieb Bas van Dijk:
API DOCS
http://hackage.haskell.org/package/vector-bytestring-0.0.0.0
you could re-export VS.empty, VS.singleton, etc. directly.
Cheers Christian
-- | /O(1)/ The empty 'ByteString'
empty :: ByteString
empty = VS.empty
{-# INLINE empty #-}
-- | /O(1)/ Convert a 'Word8' into a 'ByteString'
singleton :: Word8 - ByteString
singleton = VS.singleton
{-# INLINE [1] singleton #-} -- Inline [1] for intercalate rule
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
I think the cleanest solution (just from a theoretical point of view) is to use a newtype for your byte strings. - it should have the same performance - allows to make ByteString really abstract when hiding the newtype constructor - is portable and supplies control over all other instances (not just Show) I'm not sure if one could make really bad thinks to your ByteString by using the Vector interface, but one would want to disallow vector operations just for compatible with other byte strings. It would require more work just on your side, though. Cheers Christian Am 15.10.2011 16:15, schrieb Bas van Dijk: On 15 October 2011 13:34, Roman Leshchinskiyr...@cse.unsw.edu.au wrote: On 15/10/2011, at 12:26, Roman Leshchinskiy wrote: On 14/10/2011, at 12:37, Bas van Dijk wrote: If there's need for a specific Show instance for Vectors of Word8s we can always add one directly to vector. (Roman, what are your thoughts on this?) Personally, I think that ByteString and especially Vector Word8 aren't strings and shouldn't be treated as such. But I wouldn't be strongly against showing them as strings. However, I *am* strongly against using UndecidableInstances in vector and I don't see how to implement this without using them. I meant OverlappingInstances, of course. To clarify, I would still consider it if everybody thinks it's a really good idea. Roman I agree that you shouldn't use ByteStrings or Vectors of Word8s for Unicode strings. However I can imagine that for quick sessions in ghci it can be quite handy if they are shown as strings. For example, currently we have: import Network.HTTP.Enumerator simpleHttp http://code.haskell.org/~basvandijk/; Chunk html\nheadtitleBas van Dijk/title/head\nbody\nh1Bas van Dijk/h1\n\npEmail:a href=\mailto://v.dijk@gmail.com\;v.dijk@gmail.com/a/p\n\npNick on IRC:ttbasvandijk/tt/p\n\na href=\http://www.haskellers.com/user/basvandijk/\;\nimg src=\http://www.haskellers.com/static/badge.png\; \n alt=\I'm a Haskeller\\n border=\0\\n/a\n\npSee mya href=\https://github.com/basvandijk\;GitHub/a page for a list of projects I work on./p\n\n/body\n/html\n Empty If ByteStrings were not shown as strings this would look like: Chunk ( fromList [60,104,116,109,108,62,10,60,104,101,97,100,62,60,116,105,116,108,101,62,66,97,115,32,118,97,110,32,68,105,106,107,60,47,116,105,116,108,101,62,60,47,104,101,97,100,62,10,60,98,111,100,121,62,10,60,104,49,62,66,97,115,32,118,97,110,32,68,105,106,107,60,47,104,49,62,10,10,60,112,62,69,109,97,105,108,58,32,60,97,32,104,114,101,102,61,34,109,97,105,108,116,111,58,47,47,118,46,100,105,106,107,46,98,97,115,64,103,109,97,105,108,46,99,111,109,34,62,118,46,100,105,106,107,46,98,97,115,64,103,109,97,105,108,46,99,111,109,60,47,97,62,60,47,112,62,10,10,60,112,62,78,105,99,107,32,111,110,32,73,82,67,58,32,60,116,116,62,98,97,115,118,97,110,100,105,106,107,60,47,116,116,62,60,47,112,62,10,10,60,97,32,104,114,101,102,61,34,104,116,116,112,58,47,47,119,119,119,46,104,97,115,107,101,108,108,101,114,115,46,99,111,109,47,117,115,101,114,47,98,97,115,118,97,110,100,105,106,107,47,34,62,10,32,32,60,105,109,103,32,115,114,99,61,34,104,116,116,112,58,47,47,119,119,119,46,104,97,115,107,101,108 ,108,101,114,115,46,99,111,109,47,115,116,97,116,105,99,47,98,97,100,103,101,46,112,110,103,34,32,10,32,32,32,32,32,32,32,97,108,116,61,34,73,39,109,32,97,32,72,97,115,107,101,108,108,101,114,34,10,32,32,32,32,32,32,32,98,111,114,100,101,114,61,34,48,34,62,10,60,47,97,62,10,10,60,112,62,83,101,101,32,109,121,32,60,97,32,104,114,101,102,61,34,104,116,116,112,115,58,47,47,103,105,116,104,117,98,46,99,111,109,47,98,97,115,118,97,110,100,105,106,107,34,62,71,105,116,72,117,98,60,47,97,62,32,112,97,103,101,32,102,111,114,32,97,32,108,105,115,116,32,111,102,32,112,114,111,106,101,99,116,115,32,73,32,119,111,114,107,32,111,110,46,60,47,112,62,10,10,60,47,98,111,100,121,62,10,60,47,104,116,109,108,62,10]) Empty Personally, I don't work in ghci that often so I don't care that much if we have or don't have specialized Show instances for Vectors of Word8s. So what do other people think about this? Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Am 17.10.2011 11:10, schrieb Ertugrul Soeylemez: So please, please, please, if you decide to use a newtype, do /not/ hide the constructor. The better alternative to not hiding the constructor is to supply conversion functions that may or may not do more than the constructor and selector and are named accordingly. (This just disallows pattern matching.) Cheers Christian Greets, Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Am 17.10.2011 12:14, schrieb Bas van Dijk: On 17 October 2011 10:18, Christian Maederchristian.mae...@dfki.de wrote: I think the cleanest solution (just from a theoretical point of view) is to use a newtype for your byte strings. - it should have the same performance - allows to make ByteString really abstract when hiding the newtype constructor But what would a newtype ByteString = ByteString (Vector Word8) abstract over? What's there to hide? Vectors are already abstract so users can't mess with their internals. Maybe some of the functions that start with unsafe? Or why do you use the safe variant (VS.head) in your own implementation? http://hackage.haskell.org/packages/archive/vector/0.9/doc/html/Data-Vector-Storable.html#t:Vector - is portable and supplies control over all other instances (not just Show) What other instances (besides Show) should have different semantics than those of Vector? instance Read (and maybe the vector package will evolve further). I'm not sure if one could make really bad thinks to your ByteString by using the Vector interface, but one would want to disallow vector operations just for compatible with other byte strings. My idea is that when vector-bytestring is as fast as bytestring, it can replace it. When that happens it doesn't matter if users use the vector interface. I would even recommend it over using the bytestring interface so that bytestring can eventually be deprecated in favor of vector. So your package basically supports an unfortunate mix of bytestring and vector functions? How about proposing a better bytestring interface (if it should not just be that of vector)? Btw. a really abstract bytestring could easily be implemented on top of your package. Cheers Christian Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Am 17.10.2011 12:19, schrieb Michael Snoyman: [...] Also, aren't there a few documented cases where newtypes prevent certain GHC rewrite rules from firing? This would be possible to find out with a wrapper module. Cheers Christian I don't see any strong argument to avoid what appears to be the simplest and most straight-forward solution to the problem at hand. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Am 17.10.2011 17:26, schrieb Bas van Dijk: On 17 October 2011 13:12, Christian Maederchristian.mae...@dfki.de wrote: So your package basically supports an unfortunate mix of bytestring and vector functions? No, vector-bytestring exports the same API as bytestring (except for the Show and Read instances which will hopefully be fixed in a new vector release). Yes, but Data.Vector.Storable can be simple imported and used in addition. I suppose, the (derived) Data instances (from vector and the original bytestrings) break the abstraction. (So you must hope nobody is relying on this instance.) How about proposing a better bytestring interface (if it should not just be that of vector)? I'm all for improving the interface but the goal of vector-bytestring is that it can be used as a drop-in replacement for bytestring without changing to much code. Changing back to another drop-in replacement for bytestring will be difficult if functions from Data.Vector.Storable have been used. Thanks Christian Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: vector-bytestring-0.0.0.0
Am 12.10.2011 16:02, schrieb Bas van Dijk: All your ByteString are belong to us... Hello, I'm pleased to announce the beta release of vector-bytestring. This library provides the type ByteString which is defined as a type synonym for a storable Vector of Word8s (from the vector package): type ByteString = Data.Vector.Storable.Vector Word8 It exports the same API as the bytestring package except that the module names are prefixed with: Data.Vector.Storable.ByteString instead of Data.ByteString. The very ambitious goal of this package is that it will eventually replace our beloved bytestring package. By basing this package on vector, we can benefit from all the optimizations (like stream-fusion!) in that library. We will also have just a single library to test, debug and optimize. TEST-SUITE I ported the bytestring test-suite to vector-bytestring. You can run it using: $ cabal configure --enable-tests; cabal build; cabal test All 54800 tests pass! Only one property doesn't hold: prop_show :: ByteString - Bool prop_show x = show x == show (unpack x) This is because I don't provide a custom Show instance for ByteStrings but use the one from Vector which shows a vector like fromList [1,2,3] instead as \SOH\STX\ETX like bytestring does. Hopefully this is not a problem in practice. All derived Show instances for data types using your ByteString will be different, too. Would it not be simple to use a newtype for ByteString (rather than a synonym)? Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question on definition of `parse' function in Parsec library.
Am 08.10.2011 16:04, schrieb Captain Freako: Hi all, In this definition from the Parsec library: parse :: (Stream s Identity t) = Parsec s () a - SourceName - s - Either ParseError a parse p = runP p () what's the significance of `Identity t'? (`t' isn't used anywhere.) http://hackage.haskell.org/packages/archive/parsec/3.1.2/doc/html/Text-Parsec-Prim.html#t:Stream Text.Parsec.Prim contains class Monad m = Stream s m t | s - t where saying that the type s determines t (that is a functional dependency). The instances are: Monad m = Stream ByteString m Char Monad m = Stream ByteString m Char Monad m = Stream Text m Char Monad m = Stream Text m Char Monad m = Stream [tok] m tok so usually you have a character stream. (There are lazy and strict version of Text and ByteString.) The last instance also works for plain strings (String = [Char]). Using Identity for the monad m just means, that you actually do not need a monad (but need to supply a dummy one). If you want to keep thinks simpler you could use packages parsec1 or parsec2 Cheers Christian http://hackage.haskell.org/package/parsec2 http://hackage.haskell.org/package/parsec1 Thanks, -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
In case you further want to discuss this, I've re-opened http://hackage.haskell.org/trac/ghc/ticket/2528#comment:10 So, I'm against your proposal, Cale, but suggest that you revert the order in your example (if you want to exploit this behavior). Cheers Christian Am 08.09.2011 02:07, schrieb Cale Gibbard: I just tried this in ghci-7.0.3: ghci nubBy (=) [1,2,3,4] [1] Think about what this is doing: it is excluding 2 from the list because 2= 1, rather than including it because 1= 2 fails. I think an important convention when it comes to higher order functions on lists is that to the extent which is possible, the function parameters take elements from the list (or things computed from those) in the order in which they occur in the original list. If we reimplement it in the obvious way: ghci let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x) (nubBy f xs) ghci nubBy (=) [1,2,3,4] [1,2,3,4] I'm aware that the Report (strangely!) explicitly leaves the behaviour of nubBy unspecified for functions which are not equivalence relations, but the behaviour given by the Report implementation (the opposite of the current behaviour in GHC) is useful and desirable nonetheless. I'm sure I've written about this before. I'm not entirely sure what happened to the previous thread of discussion about this, but it just came up again for me, and I decided that I was sufficiently irritated by it to post again. Another thing perhaps worth pointing out is that the parameters to mapAccumR have always been backwards (compare it with foldr). Few enough people use this function that I'm fairly sure we could just change it without harm. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
Am 20.09.2011 20:21, schrieb Edward Kmett: [...] I would suggest you rephrase this as a formal proposal, then I can happily vote +1. Seeing the wonderful interrelation between elem, nub, nubBy and i.e. unionBy eq xs ys = xs ++ foldl (flip (deleteBy eq)) (nubBy eq ys) xs intersectBy eq xs ys = [x | x - xs, any (eq x) ys] (note that any (eq x) could be elemBy eq) I see hardly a chance to make a sensible proposal. I think, it is wrong to change the implementation of elem and notElem since I expect the key to be the first argument of the eq-comparison (in contrast to the REPORT_PRELUDE!). But this all would not matter if the eq-function are always symmetric, which may be not the case in practise. So a change could break existing code. I'd also suggest rephrasing rhe mapAccumR as a formal proposal. I'm not sure yet of whether or not I'd be behind that one, but make both proposals separately, so they can pass individually. I also don't see a relation to mapAccumR, so why don't you make such a separate proposal? C. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] Parsec line number off-by-one
Hi, 1. your lookAhead is unnecessary, because your items (atomNames) never start with %. 2. your try fails in (line 12, column 1), because the last item (aka atomName) starts consuming \n, before your eol parser is called. So rather than calling spaces before every real atom, I would call it after every real atom and after your formatDecl (so before your linesOf parser). atomNameBlock = do flagDecl ATOM_NAME formatDecl spaces atomNames - many1 atomName return $ AtomNames atomNames where atomName = do name - countBetween 1 4 (alphaNum | oneOf \'+-) ? atom name spaces return name Since spaces also consume \n, linesOf can just be many1! HTH Christian Am 21.09.2011 05:32, schrieb Ben Gamari: Recently I've been playing around with Parsec for a simple parsing project. While I was able to quickly construct my grammar (simplified version attached), getting it working has been a bit tricky. In particular, I am now stuck trying to figure out why Parsec is mis-reporting line numbers. Parsec seems convinced that line 12 of my input (also attached) has a % character, $ runghc Test.hs Left (unknown) (line 12, column 1): unexpected % expecting space or atom name while my file clearly disagrees, 10 %FLAG ATOM_NAME 11 %FORMAT(20a4) 12 C1 H1 C2 H2 C3 H3 C4 H4 C5 C6 C7 C8 N1 C9 H9 C10 H10 C11 H11 C12 13 H12 C13 H13 C14 C15 N2 C16 C17 C29 H18 C19 H19 C20 H20 C21 H21 C22 H221H222H223 ... 18 %FLAG CHARGE 19 %FORMAT(5E16.8) The task here is to identify the block of data lines (lines 12-17), ending at the beginning of the next block (starting with %). It seems likely that my problem stems from the fact that I use try to accomplish this but this is as far as I can reason. Any ideas what might cause this sort of off-by-one? Does anyone see a better (i.e. working) way to formulate my grammar? Any and all help would be greatly appreciated. Thanks. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
Looking at the code of nubBy http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.4.0.0/src/Data-List.html#nubBy nubBy :: (a - a - Bool) - [a] - [a] #ifdef USE_REPORT_PRELUDE nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\ y - not (eq x y)) xs) #else nubBy eq l = nubBy' l [] where nubBy' [] _ = [] nubBy' (y:ys) xs | elem_by eq y xs = nubBy' ys xs | otherwise = y : nubBy' ys (y:xs) -- Not exported: -- Note that we keep the call to `eq` with arguments in the -- same order as in the reference implementation -- 'xs' is the list of things we've seen so far, -- 'y' is the potential new element elem_by :: (a - a - Bool) - a - [a] - Bool elem_by _ _ [] = False elem_by eq y (x:xs) = y `eq` x || elem_by eq y xs #endif I see that the USE_REPORT_PRELUDE version corresponds to your proposal, but the actual implementation (based on elem_by) behaves differently despite the same order comment! Therefore I support your proposal to change y `eq` x in elem_by (and possibly improve the documentation). Cheers Christian Am 08.09.2011 02:07, schrieb Cale Gibbard: I just tried this in ghci-7.0.3: ghci nubBy (=) [1,2,3,4] [1] Think about what this is doing: it is excluding 2 from the list because 2= 1, rather than including it because 1= 2 fails. I think an important convention when it comes to higher order functions on lists is that to the extent which is possible, the function parameters take elements from the list (or things computed from those) in the order in which they occur in the original list. If we reimplement it in the obvious way: ghci let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x) (nubBy f xs) ghci nubBy (=) [1,2,3,4] [1,2,3,4] I'm aware that the Report (strangely!) explicitly leaves the behaviour of nubBy unspecified for functions which are not equivalence relations, but the behaviour given by the Report implementation (the opposite of the current behaviour in GHC) is useful and desirable nonetheless. I'm sure I've written about this before. I'm not entirely sure what happened to the previous thread of discussion about this, but it just came up again for me, and I decided that I was sufficiently irritated by it to post again. Another thing perhaps worth pointing out is that the parameters to mapAccumR have always been backwards (compare it with foldr). Few enough people use this function that I'm fairly sure we could just change it without harm. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
Apologies for responding to myself, but the difference between the REPORT_PRELUDE and the ghc implementation also applies to elem and notElem. #ifdef USE_REPORT_PRELUDE elem x = any (== x) notElem x = all (/= x) #else elem _ [] = False elem x (y:ys) = x==y || elem x ys notElem _ []= True notElem x (y:ys)= x /= y notElem x ys #endif So the proposal should be to swap the arguments in x==y and x /= y (above) which would also fix the nub implementation! C. Am 20.09.2011 13:46, schrieb Christian Maeder: Looking at the old tickets http://hackage.haskell.org/trac/ghc/ticket/2528 http://hackage.haskell.org/trac/ghc/ticket/3280 the USE_REPORT_PRELUDE version of nub is also different from the implementation, but both variants fulfill nub = nubBy (==) (the prelude version by definition). So when we change the nubBy implmentation we also need to change the nub implementation (which is more difficult, because it uses elem). Cheers Christian Am 20.09.2011 12:59, schrieb Christian Maeder: Looking at the code of nubBy http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.4.0.0/src/Data-List.html#nubBy nubBy :: (a - a - Bool) - [a] - [a] #ifdef USE_REPORT_PRELUDE nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\ y - not (eq x y)) xs) #else nubBy eq l = nubBy' l [] where nubBy' [] _ = [] nubBy' (y:ys) xs | elem_by eq y xs = nubBy' ys xs | otherwise = y : nubBy' ys (y:xs) -- Not exported: -- Note that we keep the call to `eq` with arguments in the -- same order as in the reference implementation -- 'xs' is the list of things we've seen so far, -- 'y' is the potential new element elem_by :: (a - a - Bool) - a - [a] - Bool elem_by _ _ [] = False elem_by eq y (x:xs) = y `eq` x || elem_by eq y xs #endif I see that the USE_REPORT_PRELUDE version corresponds to your proposal, but the actual implementation (based on elem_by) behaves differently despite the same order comment! Therefore I support your proposal to change y `eq` x in elem_by (and possibly improve the documentation). Cheers Christian Am 08.09.2011 02:07, schrieb Cale Gibbard: I just tried this in ghci-7.0.3: ghci nubBy (=) [1,2,3,4] [1] Think about what this is doing: it is excluding 2 from the list because 2= 1, rather than including it because 1= 2 fails. I think an important convention when it comes to higher order functions on lists is that to the extent which is possible, the function parameters take elements from the list (or things computed from those) in the order in which they occur in the original list. If we reimplement it in the obvious way: ghci let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x) (nubBy f xs) ghci nubBy (=) [1,2,3,4] [1,2,3,4] I'm aware that the Report (strangely!) explicitly leaves the behaviour of nubBy unspecified for functions which are not equivalence relations, but the behaviour given by the Report implementation (the opposite of the current behaviour in GHC) is useful and desirable nonetheless. I'm sure I've written about this before. I'm not entirely sure what happened to the previous thread of discussion about this, but it just came up again for me, and I decided that I was sufficiently irritated by it to post again. Another thing perhaps worth pointing out is that the parameters to mapAccumR have always been backwards (compare it with foldr). Few enough people use this function that I'm fairly sure we could just change it without harm. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] GHC/Cabal on AFS
I had similar problems under Solaris with ghc binaries compiled using gcc-4.3.3 http://hackage.haskell.org/trac/ghc/ticket/5013 C. Am 05.09.2011 19:06, schrieb Tristan Ravitch: I have the Haskell Platform (and my home directory with my cabal-installed packages) installed on an AFS (a network filesystem) volume and have been noticing a strange issue. Whenever I install a package using cabal-install and it gets to a phase of the build where it needs to load a bunch of packages, the build fails without a useful error. Example: cabal-dev install yesod Resolving dependencies... Configuring yesod-core-0.9.1.1... Preprocessing library yesod-core-0.9.1.1... Preprocessing test suites for yesod-core-0.9.1.1... Building yesod-core-0.9.1.1... [ 1 of 15] Compiling Yesod.Internal.Session ( Yesod/Internal/Session.hs, dist/build/Yesod/Internal/Session.o ) [ 2 of 15] Compiling Paths_yesod_core (dist/build/autogen/Paths_yesod_core.hs, dist/build/Paths_yesod_core.o) [ 3 of 15] Compiling Yesod.Logger (Yesod/Logger.hs,dist/build/Yesod/Logger.o ) [ 4 of 15] Compiling Yesod.Internal.RouteParsing(Yesod/Internal/RouteParsing.hs,dist/build/Yesod/Internal/RouteParsing.o) [ 5 of 15] Compiling Yesod.Internal (Yesod/Internal.hs,dist/build/Yesod/Internal.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package bytestring-0.9.1.10 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package deepseq-1.1.0.2 ... linking ... done. Loading package text-0.11.0.5 ... cabal: Error: some packages failed to install: yesod-0.9.1.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-auth-0.7.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-core-0.9.1.1 failed during the building phase. The exception was: ExitFailure 7 yesod-form-0.3.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-json-0.2.1 depends on yesod-core-0.9.1.1 which failed to install. yesod-persistent-0.2.1 depends on yesod-core-0.9.1.1 which failed to install. If I keep re-running it, it will eventually succeed. It also always makes forward progress (the next attempt will get past text and a few more packages). It seems to be related to the state of the AFS cache; if all of the required packages are in the local AFS cache it usually just works. If the cache has just been flushed (due to other FS operations), this failure pretty much always shows up. Has anyone else experienced anything like this? Alternatively, does anyone have ideas on getting a more useful error message/tracking it down? I didn't see any relevant bugs filed yet, but I wanted to get more information before adding a report. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with readProcess
Am 11.08.2011 16:45, schrieb Charles-Pierre Astolfi: Hi -cafe, I'm using readProcess and I don't know how to handle this issue: readProcess cmd [opt1,opt2] seems to execute the following: are you sure that your argument strings do not contain the quotes, possibly by calling show on arguments that are already strings. C. $ cmd opt1 opt2 That is usually fine, but I'm using an external program that doesn't understand the quotes, so I need to execute instead: $ cmd opt1 opt2 How should I do that? -- Cp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
FlexibleInstances Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
Hi, I've noticed that with ghc-7.2 many modules with LANGUAGE TypeSynonymInstances now also require FlexibleInstances Two examples are in the HTTP package Network.TCP and Network.BufferType Was ghc-7.0 wrong about this, before? Cheers Christian Am 29.07.2011 20:21, schrieb Ian Lynagh: We are pleased to announce the first release candidate for GHC 7.2.1: http://www.haskell.org/ghc/dist/7.2.1-rc1/ This includes the source and testsuite tarballs, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: FlexibleInstances Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1
I've just found http://hackage.haskell.org/trac/ghc/ticket/5377 which explains it. C. Am 05.08.2011 12:56, schrieb Christian Maeder: Hi, I've noticed that with ghc-7.2 many modules with LANGUAGE TypeSynonymInstances now also require FlexibleInstances Two examples are in the HTTP package Network.TCP and Network.BufferType Was ghc-7.0 wrong about this, before? Cheers Christian Am 29.07.2011 20:21, schrieb Ian Lynagh: We are pleased to announce the first release candidate for GHC 7.2.1: http://www.haskell.org/ghc/dist/7.2.1-rc1/ This includes the source and testsuite tarballs, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Regular Expression Parsing via derivatives
Am 01.08.2011 17:51, schrieb Alex Clemmer: Hi Haskell people, I've been snooping through various mailing lists and the current Haskell implementation of regular expressions and I was wondering if there has been a discussion about implementing regex parsing with derivatives. If so, I haven't seen it. If not, I'd like to have a discussion about it -- if for no other reason than to decide whether I should implement it as a library, or (to attempt to implement it) as a core feature. For those of you who don't know, recent work by Might and Darais http://arxiv.org/abs/1010.5023 indicates that parsing CFGs can be done The paper refers to http://hackage.haskell.org/package/derp C. better (/i.e./, significantly faster) than more traditional approaches http://swtch.com/%7Ersc/regexp/regexp1.html. Might's presenting at ICFP later in September about it. I guess the first thing I should ask is, which mailing list is actually the right place to field this inquiry. I considered dropping it in the main haskell list, but wasn't sure how people would respond. -- Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Inconsistent trailing comma in export list and record syntax
Generally allowing trailing (or leading or repeated) commas would clash with tuple sections. Also the pair constructor (,) is a special case. http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/syntax-extns.html#tuple-sections Cheers Christian Am 11.07.2011 12:09, schrieb Joachim Breitner: Hi, Am Montag, den 11.07.2011, 10:49 +0200 schrieb L Corbijn: You could of course say that I'm using a bad style, but it remains that it seems to be inconsistent to allow a trailing comma in one place and not in the other. So is there an reason for this? there is actually a bug report against the ghc package in Debian from a user, requesting a more liberal comma separated list parsing. We did not patch ghc in Debian to that end, though :-) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511834 Greetings, Joachim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Compiling 32-bit GHC on a 64-bit Mac
Am 06.06.2011 12:08, schrieb Johan Tibell: On Sun, Jun 5, 2011 at 2:38 PM, Ian Lynaghig...@earth.li wrote: On Sun, Jun 05, 2011 at 02:10:39PM +0200, Johan Tibell wrote: I need to reproduce a bug that only appears on 32-bit machines. I don't own such a machine but I was hoping I could compile a 32-bit GHC on my Mac and debug using that. What changes do I need to make (e.g. to build/mk) to build a 32-bit GHC? Install http://www.haskell.org/ghc/dist/7.0.3/ghc-7.0.3-i386-apple-darwin.tar.bz2 and make sure its ghc is first in your path. Then build as normal. Running the OS X installers is a bit intrusive. Is there a way to get a 32-bit version directly from source? You need a 32-bit bootstrapping compiler as binary. The above binary-dist does not use the OS X installer (as it does not end in .pkg) Cheers Christian Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Programming Chalenges: The 3n+1 problem
Am 14.04.2011 12:29, schrieb Dmitri O.Kondratiev: 3n+1 is the first, warm-up problem at Programming Chalenges site: http://www.programming-challenges.com/pg.php?page=downloadproblemprobid=110101format=html http://www.programming-challenges.com/pg.php?page=downloadproblemprobid=110101format=html (This problem illustrates Collatz conjecture: http://en.wikipedia.org/wiki/3n_%2B_1#Program_to_calculate_Collatz_sequences) As long as the judge on this site takes only C and Java solutions, I submitted in Java some add-hock code (see at the end of this message) where I used recursion and a cache of computed cycles. Judge accepted my code and measured 0.292 sec with best overall submissions of 0.008 sec to solve the problem. *** Question: I wonder how to implement cache for this problem in Haskell? At the moment, I am not so much interested in the speed of the code, as in nice implementation. I'ld use something like: import qualified Data.Map as Map addToMap :: Integer - Map.Map Integer Integer - Map.Map Integer Integer addToMap n m = case Map.lookup n m of Nothing - let l = if even n then div n 2 else 3 * n + 1 p = addToMap l m Just s = Map.lookup l p in Map.insert n (s + 1) p Just _ - m addRangeToMap :: Integer - Integer - Map.Map Integer Integer - Map.Map Integer Integer addRangeToMap i j m = if j i then m else addRangeToMap i (j - 1) $ addToMap j m getMaxLength :: Integer - Integer - Map.Map Integer Integer - Integer getMaxLength i j = Map.foldWithKey (\ k l - if i k || k j then id else max l) 0 -- putting it all togeter getRangeMax :: Integer - Integer - Integer getRangeMax i j = getMaxLength i j $ addRangeToMap i j $ Map.singleton 1 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Proposal: add ghc -fwarn-non-ascii warning flag
similar in spirit to the -fwarn-tabs warning. C. P.S. In the mean time you may use http://projects.haskell.org/style-scanner/ (Caveat, it crashes on latin1 files when compiled with ghc-6.12 or greater.) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Colin Paul Adams] Re: Proposal: Define UTF-8 to be the encoding of Haskell source files
Am 07.04.2011 13:09, schrieb Roel van Dijk: Please take a look at the following file: http://code.haskell.org/numerals/src/Text/Numeral/Language/ZH.hs Great, that file made my firefox open infinitely many tabs (so that I had to close it). C. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Colin Paul Adams] Re: Proposal: Define UTF-8 to be the encoding of Haskell source files
Am 07.04.2011 13:09, schrieb Roel van Dijk: Please take a look at the following file: http://code.haskell.org/numerals/src/Text/Numeral/Language/ZH.hs The code would not suffer much if it were pure ASCII. I would prefer (ascii) haddock links to explain the various code points. C. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell-cafe] how to optmize this code?
Am 31.03.2011 05:59, schrieb Felipe Almeida Lessa: On Wed, Mar 30, 2011 at 2:39 PM, Gilberto Garciagiba@gmail.com wrote: fkSum :: Int - [Int] - Int fkSum a [] = 0 fkSum a (b) = foldl (+) 0 (filter (\x - isMultiple x b) [1..a]) Daniel Fischer and Yves Parès gave you good suggestions about implementing a different, better algorithm for you problem. However, there's one small thing about your current code. Instead of foldl, you should use foldl' (use import Data.List), which is strict in the accumulator. Most of the time you want foldl' instead of foldl. You can learn more about the list folds here [1]. Since we don't have a function sum' in the Prelude (should we have it?) I wonder what happens if you just use sum. Will the sum (based on sum' so without -DUSE_REPORT_PRELUDE) be strict enough? #ifdef USE_REPORT_PRELUDE sum = foldl (+) 0 product = foldl (*) 1 #else sum l = sum' l 0 where sum' [] a = a sum' (x:xs) a = sum' xs (a+x) product l = prod l 1 where prod [] a = a prod (x:xs) a = prod xs (a*x) #endif Cheers C. P.S. isMultiple a = any ((== 0) . mod a) HTH, [1] http://www.haskell.org/haskellwiki/Foldr_Foldl_Foldl%27 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fix context reduction stack overflow in dimensional
Am 29.03.2011 13:46, schrieb Bas van Dijk: Dear Bjorn, Attached is a patch that fixes a context reduction stack overflow in your dimensional package. I noticed something weird though (that's why I'm CCing the ghc list). When I cabal build dimensional-0.8.2 I first get the context reduction stack overflow when I then build it again I get the error again (as expected). However when I try to build it for the third time it succeeds! Why is this? Your log shows that it re-compiles fine in the second attempt (don't ask me why) saying 7 of 7. The same happens when compiling for profiling (see .p_o files). C. I attached the build log. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc fails with HOME not set, fixing right now
ghc should not fail if HOME is not set. It certainly cannot look up local packages then, but ghc should work without those, too. ghc is a compiler like gcc. Does gcc need HOME? Cheers Christian Am 25.03.2011 08:26, schrieb Joachim Breitner: Hi, new FTBFS coming up: ghc fails if HOME is not set, which is apparently the case on some buildds. I’m now setting HOME to a dummy variable in debian/rules and building it right now in a pbuilder (with HOME not set...). We’ll need to see if this affects the libraries as well. If that is the case, it can be easily fixed in haskell-devscripts. Greetings, Joachim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC7 (on OSX.5)
Am 21.03.2011 18:40, schrieb wren ng thornton: On 3/21/11 4:16 AM, Christian Maeder wrote: Am 20.03.2011 20:01, schrieb wren ng thornton: So I'm having a go of installing ghc-7.0.2 and haskell-platform-2011.2.0.0 on OSX 10.5. Since 10.5 is no longer supported I've had to compile from source. The good news is, so far as I can tell, everything works right out of the box.[1] [...] [1] OSX 10.5.8 arch x86_64 (though it calls itself i386) Does your ghc-7.0.2 create 32 or 64 bit Code? What does ghc --info say? $ ghc-7.0.2 --info [(Project name,The Glorious Glasgow Haskell Compilation System) ,(Project version,7.0.2) ,(Booter version,6.12.1) ,(Stage,2) ,(Build platform,i386-apple-darwin) ,(Host platform,i386-apple-darwin) ,(Target platform,i386-apple-darwin) ,(Have interpreter,YES) ,(Object splitting,NO) ,(Have native code generator,YES) ,(Have llvm code generator,YES) ,(Support SMP,YES) ,(Unregisterised,NO) ,(Tables next to code,YES) ,(RTS ways,l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn) ,(Leading underscore,YES) ,(Debug on,False) ,(LibDir,/usr/local/lib/ghc-7.0.2) ,(Global Package DB,/usr/local/lib/ghc-7.0.2/package.conf.d) ,(C compiler flags,[\-march=i686\,\-m32\,\-isysroot\,\/Developer/SDKs/MacOSX10.5.sdk\,\-mmacosx-version-min=10.5\,\-fno-stack-protector\]) ,(Gcc Linker flags,[\-march=i686\,\-m32\,\-isysroot\,\/Developer/SDKs/MacOSX10.5.sdk\,\-mmacosx-version-min=10.5\]) ,(Ld Linker flags,[\-arch\,\i386\,\-macosx_version_min\,\10.5\]) This output (the flag -m32 and platform i386) clearly indicates that 32bit binaries (like the bootstrapping ghc-6.12.1) are produced. If you had added darwin to OsSupportsSplitObjs in mk/config.mk.in then Object splitting were YES and binaries were smaller, see http://hackage.haskell.org/trac/ghc/ticket/5008 Cheers Christian Xcode 3.1.2 (not that it matters) gcc 4.0.1 (i686-apple-darwin9-gcc-4.0.1 Apple Inc. build 5490) ghc 6.12.1 / hp 2010.1.0.0 As far as I know there was no 64bit ghc-6.12.x for MacOS. Is it possible to create a 64bit ghc starting with a 32Bit ghc? I don't think so and always used ghc-6.10.4 from macports to create 64bit binary-dists that have the suffix -x86_64-apple-darwin.tar.bz2 rather than -i386-apple-darwin.tar.bz2 for 32bit compilers. The 6.12 is definitely 32bit. I can't say how that affects bootstrapping. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC7 (on OSX.5)
Am 20.03.2011 20:01, schrieb wren ng thornton: So I'm having a go of installing ghc-7.0.2 and haskell-platform-2011.2.0.0 on OSX 10.5. Since 10.5 is no longer supported I've had to compile from source. The good news is, so far as I can tell, everything works right out of the box.[1] [...] [1] OSX 10.5.8 arch x86_64 (though it calls itself i386) Does your ghc-7.0.2 create 32 or 64 bit Code? What does ghc --info say? Xcode 3.1.2 (not that it matters) gcc 4.0.1 (i686-apple-darwin9-gcc-4.0.1 Apple Inc. build 5490) ghc 6.12.1 / hp 2010.1.0.0 As far as I know there was no 64bit ghc-6.12.x for MacOS. Is it possible to create a 64bit ghc starting with a 32Bit ghc? I don't think so and always used ghc-6.10.4 from macports to create 64bit binary-dists that have the suffix -x86_64-apple-darwin.tar.bz2 rather than -i386-apple-darwin.tar.bz2 for 32bit compilers. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: cabal install network was: Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2
Am 23.02.2011 15:41, schrieb Ian Lynagh: On Tue, Feb 22, 2011 at 05:17:35PM +0100, Christian Maeder wrote: Am 22.02.2011 14:47, schrieb Ian Lynagh: On Tue, Feb 22, 2011 at 09:59:20AM +0100, Christian Maeder wrote: Where does cabal get its flags from? (hardcoded?) From the C compiler flags, Gcc Linker flags and Ld Linker flags entries in ghc --info's output. Since the sdk flags will be gone in ghc-7.0.3, re-adding them via the command-line will not pass them to cabal. Should not more flags be passed to cabal? Will there be no chance to produce 10.5 code on 10.6 machines? Can dtrace (and its problems) be disabled on macs? Modifying archives seems to scary: http://hackage.haskell.org/trac/ghc/ticket/4996 Thanks Christian Ok, they are not in bin/ghc script. So where does ghc get them from? Compiled into the compiler, from the cCcOpts/cGccLinkerOpts/cLdLinkerOpts variables in compiler/stage*/build/Config.hs Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
Am 14.03.2011 06:26, schrieb C K Kashyap: Looks like a job for Data.Binary. I'd like to use it with just the libraries that are part of the platform I forgot to mention, Data.Binary does not seem to be in the platform. Right, it is not in the platform, but I would recommend to install those packages that you find useful (and vote for packages to be included into later versions of the platform.) Interestingly, there is a hidden package ghc-binary-0.5.0.2, which almost looks like binary-0.5.0.2. Maybe ghc developers and platform maintainers could comment on any differences. If there are none you could simple ghc-pkg expose ghc-binary. For future versions of ghc and the platform a single ghc-binary or binary version would be better. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
testsuite missing was: Re: ANNOUNCE: GHC version 7.0.2
Why is the file still not being updated? http://www.haskell.org/ghc/dist/7.0.2/testsuite-7.0.2.tar.bz2 C. Am 10.03.2011 03:22, schrieb Jens Petersen: On 4 March 2011 23:14, Christian Maeder christian.mae...@dfki.de wrote: http://www.haskell.org/ghc/dist/7.0.2/testsuite-7.0.2.tar.bz2 This archive does not seem to have the actual tests inside the testsuite subdirectory. At least the README is identical to the top-level one. Not just the readme, but most of the files actually! $ tar jxf ghc-7.0.2-src.tar.bz $ tar jxf testsuite-7.0.2.tar.bz $ mv ghc-7.0.2/testsuite testsuite-7.0.2 $ diff -sr ghc-7.0.2 testsuite-7.0.2 | grep are identical$ | wc -l 1193 A week has passed now - can we please have a fixed testsuite-7.0.2.tar.bz2? :) Thanks, Jens ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Data.ByteString.Lazy.ByteString vs Data.ByteString.Lazy.Internal.ByteString
Am 14.03.2011 06:26, schrieb C K Kashyap: Looks like a job for Data.Binary. I'd like to use it with just the libraries that are part of the platform I forgot to mention, Data.Binary does not seem to be in the platform. Right, it is not in the platform, but I would recommend to install those packages that you find useful (and vote for packages to be included into later versions of the platform.) Interestingly, there is a hidden package ghc-binary-0.5.0.2, which almost looks like binary-0.5.0.2. Maybe ghc developers and platform maintainers could comment on any differences. If there are none you could simple ghc-pkg expose ghc-binary. For future versions of ghc and the platform a single ghc-binary or binary version would be better. Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ghc-7.0.2 on macports wanted
Am 11.03.2011 11:32, schrieb Max Bolingbroke: On 10 March 2011 17:51, Christian Maeder christian.mae...@dfki.de wrote: Why does the base package depend on iconv only on macs? iconv is not needed under linux or solaris (unless you install haskeline, which is not in the platform. I don't have access to a Linux box to check, but according to the source code iconv should be required on any platform except Win32. Maybe it is statically linked into the base package. And maybe this could be done on Macs with a locally installed static iconv lib? Could we do something here to make GHC compatible with either iconv? For example, on OS X we could weakly link base against both iconv_* and libiconv_* and then have the hs_iconv_* functions dispatch to the first non-null function of the two. No idea. Alternatively, perhaps it would be sufficient to have bases' extra-lib-dirs include /usr/lib/? I guess this would only work if GHC arranges to put -L/usr/lib at the very front of the link line, though. It did not help to just add /usr/lib to library-dirs or -L/usr/lib to ld-options of base's package.conf file. Maybe it would help to add /usr/lib to those packages that add /opt/local/lib? Some sort of solution here would eliminate a lot of pain and suffering on the part of OS X GHC users :-) I agree, C. Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc-7.0.2 on macports wanted
Dear All, we would appreciate a ghc-7.0.2 distribution package via macports, because we intend to make macports packages based on ghc and gtk+2.0. Libraries from the Haskell-Platform would be nice, too. Was macports given up? Via port pkg we want to create binary mac packages, however, these packages are only very basic in that they cannot be uninstalled and do not know about their dependencies. Therefore I would also like how to create proper distribution packages. (links are welcome) Thanks Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-7.0.2 on macports wanted
Am 10.03.2011 15:52, schrieb Don Stewart: Does MacPorts still interact badly with libiconv? (The system and MacPorts versions out of sync, making Haskell unbuildable unless in MacPorts). ghc from macports was build against macports's iconv, which works fine with gtk2 from macports. The official ghc is linked and links against /usr/lib/libiconv.dylib, which makes a problem as soon as -L/opt/local/lib is added by some cabal package. But this can be fixed by adding -L/usr/lib as first argument to ghc. C. On Thu, Mar 10, 2011 at 5:50 AM, Christian Maeder christian.mae...@dfki.de wrote: Dear All, we would appreciate a ghc-7.0.2 distribution package via macports, because we intend to make macports packages based on ghc and gtk+2.0. Libraries from the Haskell-Platform would be nice, too. Was macports given up? Via port pkg we want to create binary mac packages, however, these packages are only very basic in that they cannot be uninstalled and do not know about their dependencies. Therefore I would also like how to create proper distribution packages. (links are welcome) Thanks Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-7.0.2 on macports wanted
Why does the base package depend on iconv only on macs? iconv is not needed under linux or solaris (unless you install haskeline, which is not in the platform. Cheers Christian omitting iconv results in: Undefined symbols: _locale_charset, referenced from: _localeEncoding in libHSbase-4.3.1.0.a(PrelIOUtils.o) _iconv_close, referenced from: _hs_iconv_close in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_close) _iconv, referenced from: _hs_iconv in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) _iconv_open, referenced from: _hs_iconv_open in libHSbase-4.3.1.0.a(iconv.o) (maybe you meant: _hs_iconv_open) ld: symbol(s) not found Am 10.03.2011 17:35, schrieb Don Stewart: And that means you can't mix MacPorts and the Mac HP installer. We might want to make that very clear. On Thu, Mar 10, 2011 at 6:58 AM, Christian Maeder christian.mae...@dfki.de wrote: Am 10.03.2011 15:52, schrieb Don Stewart: Does MacPorts still interact badly with libiconv? (The system and MacPorts versions out of sync, making Haskell unbuildable unless in MacPorts). ghc from macports was build against macports's iconv, which works fine with gtk2 from macports. The official ghc is linked and links against /usr/lib/libiconv.dylib, which makes a problem as soon as -L/opt/local/lib is added by some cabal package. But this can be fixed by adding -L/usr/lib as first argument to ghc. C. On Thu, Mar 10, 2011 at 5:50 AM, Christian Maeder christian.mae...@dfki.de wrote: Dear All, we would appreciate a ghc-7.0.2 distribution package via macports, because we intend to make macports packages based on ghc and gtk+2.0. Libraries from the Haskell-Platform would be nice, too. Was macports given up? Via port pkg we want to create binary mac packages, however, these packages are only very basic in that they cannot be uninstalled and do not know about their dependencies. Therefore I would also like how to create proper distribution packages. (links are welcome) Thanks Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Update Cabal
What are the arguments for updating? Are you using ghc-7.0.2? Wait for Haskell Platform 2011.2.0.0 that will be based on cabal-install-0.10.2! Cheers Christian Am 10.03.2011 11:27, schrieb Hauschild, Klaus (EXT): Hallo, I'm using Haskell Platform 2010.2.0.0 on a Windows XP machine. This haskell platform includes cabal-1.8.0.6. Now I want to update cabal by cabal install cabal. Installation works well. Call like runhaskell ./Setup.hs will use the updatetd cabal-1.10.0.0. But cabal --version says still 1.8.0.6 and I have to re-configure. How I update cabal in my current Haskel Platform? Thanks Klaus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
big hello world binary on 32bit intel MacOS
Hi, compiling a simple putStrLn Hello program creates binaries of size: ghc-6.12.3: 719K ghc-7.0.1: 7,4M ghc-7.0.2: 6,9M otool -L for the ghc-7 binaries displays: /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) where /usr/lib/libgcc_s.1.dylib is not referenced for the ghc-6.12.3 binary. I used: http://www.haskell.org/ghc/dist/7.0.2/ghc-7.0.2-i386-apple-darwin.tar.bz2 http://www.haskell.org/ghc/dist/6.12.3/GHC-6.12.3-i386.pkg Any explanations? Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
no testsuite? Re: ANNOUNCE: GHC version 7.0.2
I still cannot make sense out of this testsuite-7.0.2.tar.bz2 C. Am 04.03.2011 15:14, schrieb Christian Maeder: http://www.haskell.org/ghc/dist/7.0.2/testsuite-7.0.2.tar.bz2 This archive does not seem to have the actual tests inside the testsuite subdirectory. At least the README is identical to the top-level one. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: big hello world binary on 32bit intel MacOS
I've created a ticket for it: http://hackage.haskell.org/trac/ghc/ticket/5008 C. Am 09.03.2011 14:06, schrieb Christian Maeder: Hi, compiling a simple putStrLn Hello program creates binaries of size: ghc-6.12.3: 719K ghc-7.0.1: 7,4M ghc-7.0.2: 6,9M otool -L for the ghc-7 binaries displays: /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) where /usr/lib/libgcc_s.1.dylib is not referenced for the ghc-6.12.3 binary. I used: http://www.haskell.org/ghc/dist/7.0.2/ghc-7.0.2-i386-apple-darwin.tar.bz2 http://www.haskell.org/ghc/dist/6.12.3/GHC-6.12.3-i386.pkg Any explanations? Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Overlaping Parsec rules
Am 08.03.2011 13:50, schrieb Christian Maeder: Am 08.03.2011 13:35, schrieb Hauschild, Klaus (EXT): Hi Christian, Thank you for your help. Now the current version of Parse.hs (http://code.google.com/p/hgmltracer/source/browse/trunk/hGmlTracer/src/Gml/Parse.hs) works well for the test file fact.gml. spaces char end The idea is to call spaces _after_ every token. In other words spaces before char end is not needed. So the keyword parser should be extended by spaces and also the number, char, string, binder and identifier parsers. This is not necessary since you skip spaces after parseGml'. skip (A | B) is better than skip A | skip B. C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overlaping Parsec rules
Am 09.03.2011 14:44, schrieb Christian Maeder: Am 08.03.2011 13:50, schrieb Christian Maeder: Am 08.03.2011 13:35, schrieb Hauschild, Klaus (EXT): Hi Christian, Thank you for your help. Now the current version of Parse.hs (http://code.google.com/p/hgmltracer/source/browse/trunk/hGmlTracer/src/Gml/Parse.hs) works well for the test file fact.gml. spaces char end The idea is to call spaces _after_ every token. In other words spaces before char end is not needed. But in your top-level parser you may want to skip leading spaces and check for a final eof to ensure that everything was consumed. spaces liftM2 const parseList eof (Instead of liftM2 const the symbol * from Control.Applicative may be used: spaces * parseList * eof) I defined: infixl 1 () :: Monad m = m a - m b - m a () = liftM2 const and would use: spaces parseList eof C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] have anyone tried GHC 7.0.2
What does ghc-pkg list and ghc-pkg check say? Cabal-1.10.1.0, directory-1.1.0.0 and process-1.0.1.5 should be there after installation of GHC 7.0.2. (I've actually installed cabal-install-0.10.0 using an older cabal, but that does not work on macs and may not be the recommended way.) I think I've used http://www.galois.com/~dons/code/2011.2.0.0/haskell-platform-2011.2.0.0.tar.gz from http://www.galois.com/~dons/code/2011.2.0.0/, but they are not official yet. C. Am 08.03.2011 19:20, schrieb Qi Qi: Hi, After I installed GHC 7.0.2 and cabal-install 0.10.0 using Cabal library 1.10.1, I found that some package failed to install. For example like Happy, I got the following error: cabal install happy Resolving dependencies... command line: cannot satisfy -package Cabal-1.10.1.0: Cabal-1.10.1.0-64e8f05722ea5bbdf07df2e5a3491105 is unusable due to missing or recursive dependencies: directory-1.1.0.0-85d1d0f9d96dffdacf64f3cc6fba6f2f process-1.0.1.5-4cab1bf0666275ac101dd48c7565b64c (use -v for more information) cabal: Error: some packages failed to install: happy-1.18.6 failed during the configure step. The exception was: ExitFailure 1 Besides happy package, some other packages like ghc-mod, hmatrix also failed to install. Does anyone else have the same issue after installed ghc 7.0.2? By the way, does anyone hear anything about Haskell-platform 2011.2 ? Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overlaping Parsec rules
Am 08.03.2011 12:30, schrieb Hauschild, Klaus (EXT):
Hi Christian,
my version of parseList works currently strange.
The input {2\n2} will be parsed fine, but something like { } or so fails
with 'expecting space or }'.
You must skip (possible) spaces after {, too. (Actually after every
lexeme.)
C.
The redefinition of space is not necessary, it was copied from another
tutorial code. How I write a version of parseGml that get gml token separated
by any white space (space, tab, newline)?
Thanks
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Montag, 7. März 2011 14:18
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
Am 07.03.2011 13:48, schrieb Hauschild, Klaus (EXT):
Thanks Christian,
I adapted the keyword parser and now n - negi does not occur.
But there are still other problems to solve. If I activate the parseFunction
the parser will answer to fact.gml unexpected end of input, expecting space
or }.
Your redefinition of spaces (= skipMany1 space) is problematic and:
parseList = sepBy parseGml' spaces
Allow for the original (optional) spaces after parseGml':
parseGml'' = liftM2 const parseGml' spaces
parseList = many parseGml''
C.
P.S. why do you call? many (noneOf )
manyTill anyChar newline
or just: many (noneOf \n)
(a trailing newline will be skipped by spaces)
Any ideas?
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Montag, 7. März 2011 12:23
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
You should parse keywords using:
keyword s = try (string s) notFollowedBy (letter | digit)
C.
Am 07.03.2011 11:34, schrieb Hauschild, Klaus (EXT):
Hi,
to solve this ICFP task _http://www.cs.cornell.edu/icfp/task.htm_ I'm
currnetly working on the parser. With the hint from Thu (reading Phillip
Wadlers monadic parser paper) and consulting
_http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours/Parsing_
I produce a first working version of the parser.
After this great moment I completed the token definition and near all
parsing rules. For the complete code have a look at
_http://code.google.com/p/hgmltracer/source/browse/#svn%2Ftrunk%2FhGmlTracer_
data GmlToken =
-- structures
FunctionToken TokenSequence |
ArrayToken TokenSequence|
-- control operators
ApplyToken |
IfToken |
-- number operators
AddiToken |
AddfToken |
ACosToken |
ASinToken |
ClampfToken |
CosToken|
DiviToken |
DivfToken |
EqiToken|
EqfToken|
FloorToken |
FracToken |
LessiToken |
LessfToken |
ModiToken |
MuliToken |
MulfToken |
NegiToken |
NegfToken |
ToRealToken |
SinToken|
SqrtToken |
SubiToken |
SubfToken |
-- points
GetXToken |
GetYToken |
GetZToken |
PointToken |
-- arrays
GetToken|
LengthToken |
-- environment
IdentifierToken String |
BinderToken String |
-- types
BoolToken Bool |
IntToken Int|
RealToken Double|
StringToken String deriving Show
And
parseGml :: String - [GmlToken]
parseGml input = case parse parseList gml input of
Left err - error (Parse error: ++ (show err))
Right gml - gml
parseList = sepBy parseGml' spaces
Re: [Haskell-cafe] Overlaping Parsec rules
In
http://code.google.com/p/hgmltracer/source/browse/trunk/hGmlTracer/src/Gml/Parse.hs
I see identifier - many (noneOf ). You should at least consume one
character by using many1! This also allows to call many parseGml''
later.
C.
Am 08.03.2011 12:30, schrieb Hauschild, Klaus (EXT):
Hi Christian,
my version of parseList works currently strange.
The input {2\n2} will be parsed fine, but something like { } or so fails
with 'expecting space or }'.
The redefinition of space is not necessary, it was copied from another
tutorial code. How I write a version of parseGml that get gml token separated
by any white space (space, tab, newline)?
Thanks
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Montag, 7. März 2011 14:18
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
Am 07.03.2011 13:48, schrieb Hauschild, Klaus (EXT):
Thanks Christian,
I adapted the keyword parser and now n - negi does not occur.
But there are still other problems to solve. If I activate the parseFunction
the parser will answer to fact.gml unexpected end of input, expecting space
or }.
Your redefinition of spaces (= skipMany1 space) is problematic and:
parseList = sepBy parseGml' spaces
Allow for the original (optional) spaces after parseGml':
parseGml'' = liftM2 const parseGml' spaces
parseList = many parseGml''
C.
P.S. why do you call? many (noneOf )
manyTill anyChar newline
or just: many (noneOf \n)
(a trailing newline will be skipped by spaces)
Any ideas?
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Montag, 7. März 2011 12:23
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
You should parse keywords using:
keyword s = try (string s) notFollowedBy (letter | digit)
C.
Am 07.03.2011 11:34, schrieb Hauschild, Klaus (EXT):
Hi,
to solve this ICFP task _http://www.cs.cornell.edu/icfp/task.htm_ I'm
currnetly working on the parser. With the hint from Thu (reading Phillip
Wadlers monadic parser paper) and consulting
_http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours/Parsing_
I produce a first working version of the parser.
After this great moment I completed the token definition and near all
parsing rules. For the complete code have a look at
_http://code.google.com/p/hgmltracer/source/browse/#svn%2Ftrunk%2FhGmlTracer_
data GmlToken =
-- structures
FunctionToken TokenSequence |
ArrayToken TokenSequence|
-- control operators
ApplyToken |
IfToken |
-- number operators
AddiToken |
AddfToken |
ACosToken |
ASinToken |
ClampfToken |
CosToken|
DiviToken |
DivfToken |
EqiToken|
EqfToken|
FloorToken |
FracToken |
LessiToken |
LessfToken |
ModiToken |
MuliToken |
MulfToken |
NegiToken |
NegfToken |
ToRealToken |
SinToken|
SqrtToken |
SubiToken |
SubfToken |
-- points
GetXToken |
GetYToken |
GetZToken |
PointToken |
-- arrays
GetToken|
LengthToken |
-- environment
IdentifierToken String |
BinderToken String |
-- types
BoolToken Bool |
IntToken Int|
RealToken Double|
StringToken String deriving Show
And
parseGml :: String - [GmlToken]
parseGml input = case parse parseList gml input
Re: [Haskell-cafe] Overlaping Parsec rules
Am 08.03.2011 12:30, schrieb Hauschild, Klaus (EXT):
Hi Christian,
my version of parseList works currently strange.
The input {2\n2} will be parsed fine, but something like { } or so fails
with 'expecting space or }'.
Also } (and ], etc.) should be excluded as identifier letters.
} is the second identifier in { }. (The first one is empty.)
C.
The redefinition of space is not necessary, it was copied from another
tutorial code. How I write a version of parseGml that get gml token separated
by any white space (space, tab, newline)?
Thanks
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Montag, 7. März 2011 14:18
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
Am 07.03.2011 13:48, schrieb Hauschild, Klaus (EXT):
Thanks Christian,
I adapted the keyword parser and now n - negi does not occur.
But there are still other problems to solve. If I activate the parseFunction
the parser will answer to fact.gml unexpected end of input, expecting space
or }.
Your redefinition of spaces (= skipMany1 space) is problematic and:
parseList = sepBy parseGml' spaces
Allow for the original (optional) spaces after parseGml':
parseGml'' = liftM2 const parseGml' spaces
parseList = many parseGml''
C.
P.S. why do you call? many (noneOf )
manyTill anyChar newline
or just: many (noneOf \n)
(a trailing newline will be skipped by spaces)
Any ideas?
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Montag, 7. März 2011 12:23
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
You should parse keywords using:
keyword s = try (string s) notFollowedBy (letter | digit)
C.
Am 07.03.2011 11:34, schrieb Hauschild, Klaus (EXT):
Hi,
to solve this ICFP task _http://www.cs.cornell.edu/icfp/task.htm_ I'm
currnetly working on the parser. With the hint from Thu (reading Phillip
Wadlers monadic parser paper) and consulting
_http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours/Parsing_
I produce a first working version of the parser.
After this great moment I completed the token definition and near all
parsing rules. For the complete code have a look at
_http://code.google.com/p/hgmltracer/source/browse/#svn%2Ftrunk%2FhGmlTracer_
data GmlToken =
-- structures
FunctionToken TokenSequence |
ArrayToken TokenSequence|
-- control operators
ApplyToken |
IfToken |
-- number operators
AddiToken |
AddfToken |
ACosToken |
ASinToken |
ClampfToken |
CosToken|
DiviToken |
DivfToken |
EqiToken|
EqfToken|
FloorToken |
FracToken |
LessiToken |
LessfToken |
ModiToken |
MuliToken |
MulfToken |
NegiToken |
NegfToken |
ToRealToken |
SinToken|
SqrtToken |
SubiToken |
SubfToken |
-- points
GetXToken |
GetYToken |
GetZToken |
PointToken |
-- arrays
GetToken|
LengthToken |
-- environment
IdentifierToken String |
BinderToken String |
-- types
BoolToken Bool |
IntToken Int|
RealToken Double|
StringToken String deriving Show
And
parseGml :: String - [GmlToken]
parseGml input = case parse parseList gml input of
Left err - error (Parse error: ++ (show err))
Right gml - gml
Re: [Haskell-cafe] Overlaping Parsec rules
Am 08.03.2011 13:35, schrieb Hauschild, Klaus (EXT):
Hi Christian,
Thank you for your help. Now the current version of Parse.hs
(http://code.google.com/p/hgmltracer/source/browse/trunk/hGmlTracer/src/Gml/Parse.hs)
works well for the test file fact.gml.
spaces
char end
The idea is to call spaces _after_ every token. So the keyword parser
should be extended by spaces and also the number, char, string,
binder and identifier parsers. Rather than using 'noneOf ]}\n\t' I
would precisely define the identifier letters.
isIdChar :: Char - Bool
isIdChar c = isLetter c || isDigit c ||
and use satisfy isIdChar also in keyword's notFollowedBy.
Now the last thing is parsing the different numbers (integer and float). If
have a rule for parsing integers (parseInteger = liftM (IntToken . read) $
many1 digit) but if have currently no idea how to handle floats.
Look inside
http://hackage.haskell.org/packages/archive/parsec2/1.0.0/doc/html/src/Text-ParserCombinators-Parsec-Token.html
under floating and copy and adjust the code for you.
C.
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Dienstag, 8. März 2011 13:26
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
Am 08.03.2011 12:30, schrieb Hauschild, Klaus (EXT):
Hi Christian,
my version of parseList works currently strange.
The input {2\n2} will be parsed fine, but something like { } or so fails
with 'expecting space or }'.
Also } (and ], etc.) should be excluded as identifier letters.
} is the second identifier in { }. (The first one is empty.)
C.
The redefinition of space is not necessary, it was copied from another
tutorial code. How I write a version of parseGml that get gml token
separated by any white space (space, tab, newline)?
Thanks
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Montag, 7. März 2011 14:18
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
Am 07.03.2011 13:48, schrieb Hauschild, Klaus (EXT):
Thanks Christian,
I adapted the keyword parser and now n - negi does not occur.
But there are still other problems to solve. If I activate the
parseFunction the parser will answer to fact.gml unexpected end of input,
expecting space or }.
Your redefinition of spaces (= skipMany1 space) is problematic and:
parseList = sepBy parseGml' spaces
Allow for the original (optional) spaces after parseGml':
parseGml'' = liftM2 const parseGml' spaces
parseList = many parseGml''
C.
P.S. why do you call? many (noneOf )
manyTill anyChar newline
or just: many (noneOf \n)
(a trailing newline will be skipped by spaces)
Any ideas?
-Ursprüngliche Nachricht-
Von: Christian Maeder [mailto:christian.mae...@dfki.de]
Gesendet: Montag, 7. März 2011 12:23
An: Hauschild, Klaus (EXT)
Cc: haskell-cafe@haskell.org
Betreff: Re: Overlaping Parsec rules
You should parse keywords using:
keyword s = try (string s) notFollowedBy (letter | digit)
C.
Am 07.03.2011 11:34, schrieb Hauschild, Klaus (EXT):
Hi,
to solve this ICFP task _http://www.cs.cornell.edu/icfp/task.htm_ I'm
currnetly working on the parser. With the hint from Thu (reading Phillip
Wadlers monadic parser paper) and consulting
_http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours/Parsing_
I produce a first working version of the parser.
After this great moment I completed the token definition and near all
parsing rules. For the complete code have a look at
_http://code.google.com/p/hgmltracer/source/browse/#svn%2Ftrunk%2FhGmlTracer_
data GmlToken =
-- structures
FunctionToken TokenSequence |
ArrayToken TokenSequence|
-- control operators
ApplyToken |
IfToken |
-- number operators
AddiToken |
AddfToken |
ACosToken |
ASinToken |
ClampfToken |
CosToken|
DiviToken |
DivfToken |
EqiToken|
EqfToken|
FloorToken |
FracToken |
LessiToken |
LessfToken |
ModiToken |
MuliToken
Re: [Haskell-cafe] Overlaping Parsec rules
You should parse keywords using:
keyword s = try (string s) notFollowedBy (letter | digit)
C.
Am 07.03.2011 11:34, schrieb Hauschild, Klaus (EXT):
Hi,
to solve this ICFP task _http://www.cs.cornell.edu/icfp/task.htm_ I'm
currnetly working on the parser. With the hint from Thu (reading Phillip
Wadlers monadic parser paper) and consulting
_http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_Hours/Parsing_
I produce a first working version of the parser.
After this great moment I completed the token definition and near all
parsing rules. For the complete code have a look at
_http://code.google.com/p/hgmltracer/source/browse/#svn%2Ftrunk%2FhGmlTracer_
data GmlToken =
-- structures
FunctionToken TokenSequence |
ArrayToken TokenSequence|
-- control operators
ApplyToken |
IfToken |
-- number operators
AddiToken |
AddfToken |
ACosToken |
ASinToken |
ClampfToken |
CosToken|
DiviToken |
DivfToken |
EqiToken|
EqfToken|
FloorToken |
FracToken |
LessiToken |
LessfToken |
ModiToken |
MuliToken |
MulfToken |
NegiToken |
NegfToken |
ToRealToken |
SinToken|
SqrtToken |
SubiToken |
SubfToken |
-- points
GetXToken |
GetYToken |
GetZToken |
PointToken |
-- arrays
GetToken|
LengthToken |
-- environment
IdentifierToken String |
BinderToken String |
-- types
BoolToken Bool |
IntToken Int|
RealToken Double|
StringToken String deriving Show
And
parseGml :: String - [GmlToken]
parseGml input = case parse parseList gml input of
Left err - error (Parse error: ++ (show err))
Right gml - gml
parseList = sepBy parseGml' spaces
parseGml' =
-- structures
--parseFunction
--| parseArray
-- control operators
parseControlOperators
-- number operators
| parseNumberOperators
-- points
| parsePointOperators
-- arrays
| parseArrayOperators
-- types
| parseBool
| parseInteger
| parseString
-- environment
| parseIdentifier
| parseBinder
parseArray = parseSequence '[' ']'
parseFunction = parseSequence '{' '}'
parseSequence start end = do char start
array - parseList
char end
return $ ArrayToken array
parseControlOperators = parseApply | parseIf
parseApply = do string apply
return $ ApplyToken
parseIf = do string if
return $ IfToken
parseNumberOperators = do string addi
return $ AddiToken
| do string addf
return $ AddfToken
| do string acos
return $ ACosToken
| do string asind
return $ ASinToken
| do string clampf
return $ ClampfToken
| do string cos
