July 2006 - Libraries

cabal install doesn't use PATH
by Frederik Eaton 26 Jul '06

26 Jul '06

Hi, What's the reason for not resolving executables through PATH in the cabal Makefile? $ pwd /home/frederik/cabal-1.1.4 $ which ghc /home/frederik/arch/i386/bin/ghc $ make install mkdir -p dist/tmp /usr/bin/ghc --make -Wall -fno-warn-unused-matches -cpp -i. -odir dist/tmp -hidir dist/tmp Setup.lhs -o setup make: /usr/bin/ghc: Command not found make: *** [setup] Error 127 If I want to specify a different version of GHC than the one I normally use, then I could do: $ PATH=special-version-dir:$PATH make install Why the cabal makefile has to introduce a new variable HCBASE to achieve this functionality, I don't understand. It makes the normal user's life much harder by breaking a standard Unix abstraction layer; and at the same time it barely makes anyone else's life any easier. Also, I think it is more standard to use PREFIX to refer to what appears as PREF in the makefile. Frederik -- http://ofb.net/~frederik/

2 2

ANN: TextRegexLazy 0.44
by Chris Kuklewicz 24 Jul '06

24 Jul '06

TextRegexLazy: The Text.Regex.Lazy replacement and enhancement for Text.Regex New Version: 0.44 Where: http://sourceforge.net/projects/lazy-regex Changes from 0.33 to 0.44 * Cabal * Compile with -Wall -Werror * Change DFAEngineFPS from Data.FastPackedString to Data.ByteString (still fairly untested) This was my first time packaging with cabal, and I am hoping it works for you. The tests have been cleaned up and now Cabal can run them. The change from FPS to ByteString was trivial. Question 1: What more would people want from a Regex engine for Data.ByteString? Question 2: Is there interest in getting this into an official release of the base libraries? The Compat module could at least replace or sit alongside the performance sink of the current Text.Regex code. -- Chris "I define UNIX as 30 definitions of regular expressions living under one roof." * Donald Knuth: Chapter 33 of the book Digital Typography, p. 649.

4 9

Re: Package "mounting" proposal
by Simon Marlow 24 Jul '06

24 Jul '06

Stefan Karrmann wrote: > My 2 cents: > > Sven Moritz Hallberg (Sun, Jul 16, 2006 at 01:24:43AM +0200): > >>[...] >>She must specify it somehow. Two possibilities come to mind: >> >> 1. Add a field to the package description of foo (v1.4, say) that says >> "I'm backwards-compatible with 1.3." When building, this relation >> would have to be inspected to see whether any currently installed >> version of foo satisfies the dependency specified by the mount. >> 2. Declare a convention for version numbers to carry compatibility >> information, like the OpenGL standard, for example: If the new >> version is backwards-compatible, only the minor version number >> changes. If it isn't, the major version number must be incremented. >> > > > I prefer 1. The FSF use 2 for its GNU software and others started with it, > too. But after a while most of them tend to increase major numbers. E.g. > 3.0, 3.11, 95, 98, 2000 I think we should do (1). But we should also keep the current mechanism of allowing a package to specify a range of dependencies, the reason being that even when an interface upgrade isn't fully compatible, the package might still work with it, and this is a property of the consuming package, not the package that is depended on. (incedentally .NET has both of these facilities too, but only for runtime dependencies, not build-time AFAIK). Cheers, Simon

2 1

Re: [Haskell] Package "mounting" proposal
by Sven Moritz Hallberg 22 Jul '06

22 Jul '06

Stefan Karrmann <S.Karrmann(a)web.de>, 2006-07-17 21.21 +0100: > > 1. Add a field to the package description of foo (v1.4, say) that says > > "I'm backwards-compatible with 1.3." When building, this relation > > would have to be inspected to see whether any currently installed > > version of foo satisfies the dependency specified by the mount. > > 2. Declare a convention for version numbers to carry compatibility > > information, like the OpenGL standard, for example: If the new > > version is backwards-compatible, only the minor version number > > changes. If it isn't, the major version number must be incremented. > > I prefer 1. The FSF use 2 for its GNU software and others started with it, > too. But after a while most of them tend to increase major numbers. E.g. > 3.0, 3.11, 95, 98, 2000 Remember, that I would be proposing a _formal_ requirement of this convention. And also that we're talking about Haskell libraries, not commercial software like MS Windows, as your example seems to suggest. Further, I suspect your mention of GNU projects starting with and later forgetting about such a convention to be moot: They most likely didn't have a documented standard requiring it and large body of software (and users) that assumes it. But the former is what we could form and the latter is what will form. Like I said, OpenGL is an example where such a scheme is in place, and everyone is very happy. Also note my later remark in the original mail about "shifting" the convention down by one component of the version number to free the major version for increments at "psychologically" desirable points, whatever that means. Sven

1 0

Re: [Haskell-cafe] Re: Why is there no splitBy in the list module?
by Jon Fairbairn 21 Jul '06

21 Jul '06

On 2006-07-12 at 23:24BST "Brian Hulley" wrote: > Christian Maeder wrote: > > Donald Bruce Stewart schrieb: > >> Question over whether it should be: > >> splitBy (=='a') "aabbaca" == ["","","bb","c",""] > >> or > >> splitBy (=='a') "aabbaca" == ["bb","c"] > >> > >> I argue the second form is what people usually want. > > > > Yes, the second form is needed for "words", but the first form is > > needed for "lines", where one final empty element needs to be removed > > from your version! > > > > Prelude> lines "a\nb\n" > > ["a","b"] > > Prelude> lines "a\n\nb\n\n" > > ["a","","b",""] > > Prelude.lines and Prelude.unlines treat '\n' as a terminator instead of a > separator. I'd argue that this is poor design, since information is lost ie > lines . unlines === id whereas unlines . lines =/= id whereas if '\n' had > been properly conceived of as a separator, the identity would hold. Hooray! I've been waiting to ask "Why aren't we asking what laws hold for these operations?" but now you've saved me the effort. I've been bitten by unlines . lines /= id already; it's something we could gainfully change without wrecking too much code, methinks. > So I vote for the first option ie: > > splitBy (=='a') "aabbaca" == ["","","bb","c",""] Seconded. As far as naming is concerned, since this is a declarative language, surely we shouldn't be using active verbs like this? (OK I lost that argument way back in the mists of Haskell 0.0 with take. Before then I called "take" "first": "first n some_list" reads perfectly well). Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

4 5

HSQL-MySQL: non-standard port
by Quan Ta 21 Jul '06

21 Jul '06

1 0

System.Info.os is wrong, Was Re: HDBC-ODBC compile problem
by Neil Mitchell 19 Jul '06

19 Jul '06

Hi, > let isWindows = "mingw" `isPrefixOf` System.Info.os Eeeeekkkkkk!!!!! Arrrrrggggghhhhh!!!! You're relying on the fact that System.Info.os is wrong to do a conditional test. Certainly for something like WinHugs/Yhc they may have never seen the evil horrors that is mingw, and certainly don't ship with any of the mingw tools. (Of course, with Hugs and GHC this code does exactly what you want, so this does work in practice) I am hoping that Yhc will return "windows" for the answer to System.Info.os, but perhaps this issue needs exploring more deeply - maybe an enumeration for os with an other field or something... Thanks Neil

3 5

HDBC-ODBC compile problem
by Robert Dockins 18 Jul '06

18 Jul '06

Hello all, I'm having a problem compiling a HDBC-ODBC on Windows. I'm not sure if the problem is with hdbc-odbc or with the Windows GHC package or if I've done something stupid or what. Windows is not my native habitat, so forgive me if I've left out something obvious. I'm using a Cygwin shell, but I don't think that matters. As far as I can tell, the GHC package contains all the mingw stuff it needs. I'm using the GHC 6.4.2 package from http://www.haskell.org/ghc/ download_ghc_642.html on a pretty standard Windows XP setup. The compile is failing during preprocessing: it looks like hsc2hs isn't finding something. It generates a bunch of syntax errors for basic types like ULONG, etc. Any help is appreciated. Thanks. Here is the output from the attempted compile session: $ runhaskell.exe Setup.lhs configure -v Setup.lhs: Warning: No license-file field. Configuring HDBC-odbc-1.0.0.0... configure: searching for ghc in path. configure: found ghc at c:\ghc\ghc-6.4.2\bin\ghc.exe "c:\ghc\ghc-6.4.2\bin\ghc.exe" --version >tmp724 configure: looking for package tool: ghc-pkg near compiler in c:\ghc \ghc-6.4.2\b in\ghc.exe configure: found package tool in c:\ghc\ghc-6.4.2\bin\ghc-pkg.exe configure: Reading installed packages... "c:\ghc\ghc-6.4.2\bin\ghc-pkg.exe" --global list >tmp724 configure: Dependency base-any: using base-1.0 configure: Dependency mtl-any: using mtl-1.0 configure: Dependency HDBC>=1.0.0: using HDBC-1.0.0 configure: Dependency parsec-any: using parsec-1.0 configure: Using install prefix: C:\Program Files configure: Binaries installed in: C:\Program Files\HDBC-odbc-1.0.0.0 configure: Libraries installed in: C:\Program Files\Haskell\HDBC- odbc-1.0.0.0\gh c-6.4.2 configure: Private binaries installed in: C:\Program Files\HDBC- odbc-1.0.0.0 configure: Data files installed in: C:\Program Files\Common Files \HDBC-odbc-1.0. 0.0 configure: Using compiler: c:\ghc\ghc-6.4.2\bin\ghc.exe configure: Compiler flavor: GHC configure: Compiler version: 6.4.2 configure: Using package tool: c:\ghc\ghc-6.4.2\bin\ghc-pkg.exe configure: Using ar found on system at: C:\cygwin\bin\ar.exe configure: No haddock found configure: No pfesetup found configure: Using ranlib found on system at: C:\cygwin\bin\ranlib.exe configure: Using runghc found on system at: c:\ghc\ghc-6.4.2\bin \runghc.exe configure: No runhugs found configure: No happy found configure: No alex found configure: Using hsc2hs: c:\ghc\ghc-6.4.2\bin\hsc2hs.exe configure: No c2hs found configure: No cpphs found configure: No greencard found $ runhaskell.exe Setup.lhs build -v 2> log.txt Preprocessing library HDBC-odbc-1.0.0.0... c:\ghc\ghc-6.4.2\bin\hsc2hs.exe -D__GLASGOW_HASKELL__=604 -I. -o Database\HDBC\O DBC\Connection.hs Database\HDBC\ODBC\Connection.hsc ---------------------- log.txt ------------------------ In file included from c:/ghc/ghc-6.4.2/include/mingw/sql.h:13, from Database\HDBC\ODBC\Connection.hsc:41: c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:17: error: syntax error before "UDWORD" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:18: error: syntax error before "UWORD" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:24: error: syntax error before "PTR" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:25: error: syntax error before "HENV" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:26: error: syntax error before "HDBC" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:27: error: syntax error before "HSTMT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:29: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:34: error: syntax error before "SQLUINTEGER" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:36: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:37: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:50: error: syntax error before "SQLHWND" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:51: error: syntax error before "BOOKMARK" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:71: error: syntax error before "SQLTCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:90: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:94: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:96: error: syntax error before "second" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:100: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:102: error: syntax error before "hour" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:103: error: syntax error before "minute" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:104: error: syntax error before "second" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:105: error: syntax error before "fraction" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:108: error: syntax error before "SQL_DATE_STRUCT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:109: error: syntax error before "SQL_TIME_STRUCT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:110: error: syntax error before "SQL_TIMESTAMP_STRUCT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:118: error: syntax error before "SQLUINTEGER" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:122: error: syntax error before "SQLUINTEGER" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:124: error: syntax error before "minute" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:125: error: syntax error before "second" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:126: error: syntax error before "fraction" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:132: error: syntax error before "SQL_YEAR_MONTH_STRUCT" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:135: error: syntax error before '}' token c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:138: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:140: error: syntax error before "sign" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:141: error: syntax error before "val" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:142: error: syntax error before '}' token c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:154: error: syntax error before "DWORD" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:156: error: syntax error before "Data3" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:157: error: syntax error before "Data4" c:/ghc/ghc-6.4.2/include/mingw/sqltypes.h:158: error: syntax error before '}' token In file included from Database\HDBC\ODBC\Connection.hsc:41: c:/ghc/ghc-6.4.2/include/mingw/sql.h:346: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:348: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:349: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:351: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:352: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:357: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:358: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:360: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:362: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:363: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:364: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:365: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:366: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:367: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:368: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:369: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:370: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:372: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:373: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:374: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:375: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:376: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:377: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:378: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:379: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:382: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:384: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sql.h:389: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:390: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:391: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:393: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:394: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sql.h:395: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:396: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:397: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:398: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:400: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:401: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sql.h:402: error: syntax error before "SQLPOINTER" In file included from Database\HDBC\ODBC\Connection.hsc:42: c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1184: error: syntax error before "SQLHWND" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1185: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1186: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1187: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1188: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1189: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1190: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1192: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1194: error: syntax error before "SQLUINTEGER" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1195: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1196: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1197: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1198: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1199: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1200: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1201: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1202: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1203: error: syntax error before "ODBCGetTryWaitValue" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1204: error: syntax error before "ODBCSetTryWaitValue" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1207: error: syntax error before "TraceReturn" c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1208: error: syntax error before "TraceVersion" In file included from c:/ghc/ghc-6.4.2/include/mingw/sqlext.h:1214, from Database\HDBC\ODBC\Connection.hsc:42: c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:22: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:24: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:25: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:26: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:27: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:28: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:30: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:32: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:34: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:35: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:36: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:37: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:38: error: syntax error before "SQLHWND" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:39: error: syntax error before "SQLHWND" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:40: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:41: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:42: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:44: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:46: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:48: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:49: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:50: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:51: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:52: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:54: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:55: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:58: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:60: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:62: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:64: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:66: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:68: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:69: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:70: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:71: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:72: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:74: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:75: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:76: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:77: error: syntax error before "SQLUSMALLINT" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:78: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:80: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:83: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:84: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:85: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:86: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:87: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:89: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:90: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:91: error: syntax error before "SQLCHAR" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:93: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:94: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:95: error: syntax error before "SQLPOINTER" c:/ghc/ghc-6.4.2/include/mingw/sqlucode.h:96: error: syntax error before "SQLPOINTER" Database\HDBC\ODBC\Connection.hsc: In function `main': Database\HDBC\ODBC\Connection.hsc:134: error: syntax error before "int" Database\HDBC\ODBC\Connection.hsc:204: error: syntax error before "int" Database\HDBC\ODBC\Connection.hsc:212: error: syntax error before "int" Database\HDBC\ODBC\Connection.hsc:223: error: syntax error before "int" Setup.lhs: got error code while preprocessing: Database.HDBC.ODBC.Connection Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

5 9

Re: Why is there no splitBy in the list module?
by Simon Marlow 18 Jul '06

18 Jul '06

Evan Laforge wrote: >> >> splitBy :: (a -> Bool) -- ^ whether element is a seperator >> >> -> [a] -- ^ list to split >> >> -> [[a]] >> >> P.S. inspecting more than one element looks like an over-generalization >> to me and should be left to parsers or regexp libs. > > > It's more generally useful if you don't drop the separators from the > output: > > splitSepWith f = map (dropWhile f) . splitWith f > spaces = splitSepWith Char.isSpace > > But this still won't let you split on comma and spaces. Either > regexes, or pass in a [tok] -> ([conumed], [rest]) type parser: > > splitWith :: ([a] -> ([a], [a])) -> [a] -> [[a]] > > ... but why not make it take parsec parsers and put it in a parsec > util module or something (if it isn't already there!): > > splitWith (Parsec.char ',' >> Parsec.spaces) > > ... of course, then you might ask why not use Parsec.sepBy :) but > maybe the "split on elt" concept is easier to learn than "write a > whole parser". > > I guess the problem with the splitWith thing is that it's a slippery > path that leads right up to full-on parsers. Exactly, and this is why we didn't reach a concensus last time. Would someone like to make a concrete proposal (with code!) for 2-3 functions we could reasonably add to Data.List? Cheers, Simon

8 16

Package "mounting" proposal
by Sven Moritz Hallberg 16 Jul '06

16 Jul '06

Hi lists, (I hope my cross-posting is okay, but somehow this post seems to apply to all of you, so here goes...) I've recently noticed that folks at GHC HQ are working on a way to resolve the problem of importing two modules with the same name from different packages. There is a proposal[1] on the GHC wiki calling for a syntax extension for 'import' statements in Haskell modules so that the package (and version) to import from can be specified explicitly. There is a second ("extended") proposal[2], which calls for the ability to import (subtrees of) the module hierarchy exposed by a package and attach it to the global module namespace at an arbitrary point, analogous to mounting a filesystem in Unix. This proposal was appearently inspired by a post to the libraries mailing list by Frederik Eaton[3]. I agree with Frederik that it would be very nice to remove the burden of writing out long package or hierarchy prefixes in modules, and just work in some previously defined context. I'd like to propose yet another alternative to the existing two proposals that follows [2] in trying to satisfy [3] but differes from it in the following ways: - It doesn't require an extension of the existing Haskell syntax. - It can be implemented by extending Cabal alone (AFAICT). In particular, I propose to drop the assumption that Haskell modules are closed entities but rather always consider them to be seen in the context of a particular _package_. The package is now made responsible for assembling an appropriate (hierarchical) module namespace to which imports in the packaged modules are taken to refer. To this end, the current 'depends:' entry in a package description would be replaced by a more general "mounting" construct, i.e. "mount package foo at Foo.Bar in the module hierarchy". Optionally, as in [2], only a subtree of "foo" could be selected, or only a specific version of "foo". While I'm at it, I had to evaluate how this proposal would interact with the "ECT" module versioning scheme, I've proposed earlier[4]. I'd like to rework that scheme to this proposal. In ECT, a library author guarantees to his users that their imports will never break by providing different (numbered) variants of the library modules whenever their interface changes. By keeping the old variants as re-exports of updated versions, the author can record compatibilities. This carries the burden for users to annotate each import with a version number. If we lift the principles of ECT to the package level in accord with this proposal, that burden largely evaporates. Keeping the promise of "eternal backwards-compatibility", however, requires an (obvious) extension to the way Cabal deals with version numbers... First of all, package "mounts" must be able to say "this version, or any compatible one". Obviously, that's actually always what one wants, so it can be taken to be the only meaning of specifying "mount foo-1.3 at Foo.Bar". Then the question is just when to consider another version of foo compatible to 1.3. Obviously, only later versions should be considered, but when does compatibility end? Only the author of foo knows! She must specify it somehow. Two possibilities come to mind: 1. Add a field to the package description of foo (v1.4, say) that says "I'm backwards-compatible with 1.3." When building, this relation would have to be inspected to see whether any currently installed version of foo satisfies the dependency specified by the mount. 2. Declare a convention for version numbers to carry compatibility information, like the OpenGL standard, for example: If the new version is backwards-compatible, only the minor version number changes. If it isn't, the major version number must be incremented. I'd personally favour 2, as it would be easier to maintain for the author of foo (no compatiblity-field in the package description to update all the time) and also to implement in the build system (just a simple version comparison instead of a relation traversal to check a dependency). As a (more conservative?) variant of alternative 2, the third (instead of second) version component could be declared as "stays compatible", i.e. if only the third (or later) version component changes, the new version is assumed backwards-compatible, otherwise it's assumed incompatible. This would allow frequent incompatible updates without quickly getting large major version numbers... As for wasting space by keeping old versions around: Of course, if the new one is backwards-compatible, any old version can be removed. Otherwise, if it's "half-way" compatible, the author of foo can release a new backwards-compatible revision of the old version that reimplements (part of) the functionality in terms of the new operations, so the old version can be replaced by this leaner revision. Comments? Best regards, Sven [1]: http://cvs.haskell.org/trac/ghc/wiki/GhcPackages [2]: http://cvs.haskell.org/trac/ghc/wiki/GhcPackageNamespaces [3]: http://www.haskell.org/pipermail/libraries/2005-June/004009.html [4]: http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

2 2