- Haskell-Cafe - Haskell.org

Best way to write endsWith
by John Ky 21 Oct '06

21 Oct '06

Hello, I have this function here: > endsWith :: Eq a => [a] -> [a] -> Bool > endsWith suffix list > | lengthDifference < 0 = False > | otherwise = (drop lengthDifference list) == suffix > where lengthDifference = (length list) - (length suffix) Would this be the preferred function argument order? Or is the reverse (ie. endsWith list suffix) better? I like being able to say "abc" `endsWith` "c", but I also like to be able to say map (endsWith 't') ["cat", dog"] but I can't have both. By the way, is there a better way to write this function to be clearer and more efficient? Thanks -John

4 3

Re: Data.List.join
by Stefan Holdermans 21 Oct '06

21 Oct '06

Samuel wrote: >> But wait! There is also a join in Control.Monad! Josef replied: > Good point. But I don't really see that as a problem. Don't you think > the two 'join's can co-exist? I do think it's a problem, for list are also monads. Instantiating the monadic join with [] we'd wind up with both join :: [[a]] -> [a] and join :: [a] -> [[a]] -> [a] which to me seems just a little too confusing. Cheers, Stefan

1 0

List comparisons and permutation group code
by Mikael Johansson 21 Oct '06

21 Oct '06

Comparing the code for permutationgropus at http://www.polyomino.f2s.com/david/haskell/codeindex.html with my own thoughts on the matter, I discover the one line to figure out whether a specific list represents the identity: isIdentity (PL xs) = all (\(i,j) -> i==j) (zip [1..] xs) Is there any sort of benefit to be won by using this construction instead of isIdentity (PL xs) = xs == [1..(length xs)] and if so, what? Best, -- Mikael Johansson | To see the world in a grain of sand mikael(a)johanssons.org | And heaven in a wild flower http://www.mikael.johanssons.org | To hold infinity in the palm of your hand | And eternity for an hour

12 20

getting a DB library working with ghc 6.6 and PostgreSQL 7.4.7
by Seth Gordon 21 Oct '06

21 Oct '06

I'm looking for an alternative to HSQL for database connectivity -- the lack of prepared statements in HSQL is particularly worrisome. I installed HDBC, but when I tried running a simple program that used it, I get the error message ghc-6.6: /usr/local/lib/HDBC-postgresql-1.0.1.0/ghc-6.6/HSHDBC-postgresql-1.0.1.0.o: unknown symbol `PQserverVersion' Looking more closely at the README.txt file there, it seems that the PostgreSQL driver is expecting 8.1, and I'm using 7.4.7. I installed the ODBC driver, and I know that in theory one can connect to my PostgreSQL server with ODBC, but as far as I can tell from the documentation, I would have to configure a separate DSN for every database instance that I would want to connect to, which makes it kind of useless for a utility that any user could pass database names to on the command line. The takusen package looks interesting, but when I checked it out and tried to build it (with "ghc --make -o setup Setup.hs"), I got the error message Setup.hs:6:7: Could not find module `Distribution.Compat.FilePath': it is hidden (in package Cabal-1.1.6) How do I work around these? Is there another library worth looking into?

2 2

[Haskell-cafe] Re: Strictness, order of IO operations: NewCGI & HDBC
by Tim Smith 20 Oct '06

20 Oct '06

Hello, Haskell Cafe. I posted a question a while ago about this, but didn't receive any responses. I'd like to try again. I've got a test case which uses John Goerzen's HDBC.ODBC. The problem I have is that it appears too lazy - using the results of a query after disconnecting causes an "unknown exception". If I use the results before disconnecting, it works fine. module Main where import Data.List (intersperse) import qualified Database.HDBC as DB import Database.HDBC.ODBC (connectODBC) main :: IO () main = do dbh <- connectODBC "DSN=test" res <- DB.getTables dbh -- print (show ((concat . intersperse ", ") res)) DB.disconnect dbh print (show ((concat . intersperse ", ") res)) Compiling and running this will show: $ ./db-discon db-discon: unknown exception If I uncomment the first 'print' line, then it works as expected: $ ./db-discon "\"d1, foo, odbctest\"" "\"d1, foo, odbctest\"" Am I just expecting the wrong thing from Haskell? Is there a technical reason why HDBC can't synchronize the IO so that everything is resolved before the disconnect? Or is this a bug in HDBC? Thanks, Timothy -- If you're not part of the solution, you're part of the precipitate.

4 6

Error building Edison 1.2.0.1
by Lyle Kopnicky 19 Oct '06

19 Oct '06

Hi folks, I tried to build edison-1.2.0.1-sources with the command 'make system' but got: *** Exception: Line 10: Unknown field 'hs-source-dirs' I am using GHC 6.4.1. Any idea how to fix this? Thanks, Lyle

3 13

A better syntax for qualified operators?
by Brian Hulley 19 Oct '06

19 Oct '06

Hi - Consider the scenario when you want to find a function that returns the i'th element of an array but all you know is that there is a module called Data.Array.IArray that will probably have such a function in it. So you start typing in your program: let ith = Data.Array.IArray. at this point, you'd hope the editor you're using would somehow display a list of avaliable values exported from Data.Array.IArray including the indexing function, so you could select it, thus I would *like* to be able to use the syntax: let ith = Data.Array.IArray.(!) because it's not the user's fault that the person who wrote Data.Array.IArray decided to use a symbol instead of an identifier for this function - the user of Data.Array.IArray in this case just wants to see normal identifiers to use with prefix application so the use of (!) at this point effectively gets rid of the unwanted operatorness associated with the function. However the current syntax of Haskell would not allow this. Instead you have to write: let ith = (Data.Array.IArray.!) The problem is that the user of Data.Array.IArray has to know already in advance, before typing the 'D' of "Data", that the indexing function has been named with a symbol instead of an identifier, but this knowledge is only available later, when the user has typed the '.' after "IArray", so the current syntax would be frustrating for the user because the user then has to go all the way back and insert an opening paren before the 'D'. Also, consider the appearance of: let ith = (Data.Array.IArray.!) arr i b = Data.Array.IArray.bounds arr vs let ith = Data.Array.IArray.(!) arr i b = Data.Array.IArray.bounds arr I'm not sure if I've managed to explain this problem clearly enough, but my proposal is that we might consider changing the lexical syntax of Haskell as follows: varId ::= id varOp ::= symbol varIdOp ::= ` varId varOpId ::= ( varOp ) varOpIdOp ::= ` varOpId qvarId ::= {conId .}+ varId -- { }+ denotes 1 or more times qvarIdOp ::= ` qvarId qvarOp ::= {conId .}+ varOp qvarOpId ::= {conId .}+ varOpId qvarOpIdOp ::= `qvarOpId In other words, to turn an operator symbol into an id, the parentheses would be put immediately around the symbol (with no spaces since this is lexical syntax), and to turn an id into an operator the backquote is put in front of the entire (qualified) id. (Also the trailing backquote in the existing syntax is redundant) The above syntax would have 3 advantages: 1) It allows the client of a module to write code without having to worry if the author of the module used symbols or identifiers to name functions - everything exported from the module can be made to appear as if it was named by an identifier (ie OpId) 2) Moving the parentheses to the lexical syntax makes syntax highlighting easier (because there are no comments to worry about inside the OpId) and also makes parsing simpler because all the mess associated with Ops versus Ids is handled by the lexer 3) It allows an editor to make a distinction between (+) -- an operator turned into an identifier - varOpId ( + ) -- an expression with 2 gaps in it which should be marked as incomplete (+ ) -- a section with 1 gap Some examples of the proposed syntax are: let ith = Data.Array.IArray.(!) arr i foo = k `Math.(+) 6 -- default precendence bar = k Math.+ 6 -- using precedence of + in module Math When you try to write an editor for Haskell (or some subset of it), you quickly discover these areas of Haskell syntax like the above which need to be changed to get an optimum interactive editing experience. I think it *is* possible to adjust the Haskell grammar so that it is LL(1) and the only reason it is not already LL(1) seems to be that the grammar has been designed with compilers (which only need to deal with complete modules) in mind rather than programmers interactively editing in mind. (The other change needed for LL(1) is to give contexts a marker before they appear eg: foo :: {MonadIO m} a -> m a ) By LL(1) I'm really meaning that the grammar for interactive editing needs to be adjusted so that it is possible to maintain the invariant that as code is entered from left to right constructs and identifiers can be highlighted according to their grammatical role and highlighting (modulo incompleteness) must remain unchanged regardless of whatever is typed afterwards to the right otherwise it can become more of a liability than a help, hence my hope that some future revision of Haskell grammar might consider taking the above points into account. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

9 14

Thanks !! (was: Newbie and working with IO Int and Int)
by Víctor A. Rodríguez 19 Oct '06

19 Oct '06

I want to thanks you all for your helps regarding this issue. You've been very helpful and comprehensive. Salute !! -- Víctor A. Rodríguez (http://www.bit-man.com.ar) El bit Fantasma (Bit-Man) Perl Mongers Capital Federal (http://cafe.pm.org/) GNU/Linux User Group - FCEyN - UBA (http://glugcen.dc.uba.ar/)

1 0

Re: [Haskell] Lexically scoped type variables
by Bulat Ziganshin 19 Oct '06

19 Oct '06

Hello Simon, Wednesday, October 18, 2006, 12:09:40 PM, you wrote: > Other alternatives would be: do something about partial type > signatures; or make GADT type inference more sophisticated (and > thereby perhaps less predicatable). just one more problem is that this issue is too complicated. i'm not sure that i correctly understands details, but for me the situation seems like this: in 6.4 it was no distinction between declarations and usages of type variables - first use declared it, while in 6.6 we have exactly defined places to declare type variable. the problem is that sometimes we want to declare variable for one type but the place where it may be declared - function signature - requires to write full type so, if my understanding is correct, may be it's possible to use special syntax for explicit _declaration_ of type variable at any place where it can be used? i mean the following: f (x :: forall a. a) = undefined::a here, we use 'forall' to explicitly declare new type variable. so it is equivalent to the following: f :: forall a. a -> ... f x = undefined::a where '...' used to make partial type signature -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

beginner's problem about lists
by falseep＠gmail.com 19 Oct '06

19 Oct '06

Hi all, I'm trying to implement a function that returns the shorter one of two given lists, something like shorter :: [a] -> [a] -> [a] such that shorter [1..10] [1..5] returns [1..5], and it's okay for shorter [1..5] [2..6] to return either. Simple, right? However, it becomes difficult when dealing with infinite lists, for example, shorter [1..5] (shorter [2..] [3..]) Could this evaluate to [1..5]? I haven't found a proper implementation. Again it's ok for shorter [2..] [3..] to return whatever that can solve the above problem correctly. An infinite list could work, I guess, but I don't know how. Thanks for any help.

17 26