From p3k at iki.fi Mon Oct 1 04:11:00 2007 From: p3k at iki.fi (Pekka Karjalainen) Date: Mon Oct 1 04:10:02 2007 Subject: [Haskell-cafe] Extract source code from literate Haskell (LHS) files In-Reply-To: <46FFED7C.6070501@telenet.be> References: <46FFED7C.6070501@telenet.be> Message-ID: <233457100710010111o4e54e054u251fd7cd7b880f6e@mail.gmail.com> On 9/30/07, Peter Verswyvelen wrote: > > This is of course very easy to do manually, but does a command line tool > exist for extracting source code from literate Haskell files? There are a lot of good answers already. You can also use some GHC command line options. Please see: http://haskell.org/haddock/haddock-html-0.8/invoking.html#cpp Pekka From ctm at cs.nott.ac.uk Mon Oct 1 06:22:45 2007 From: ctm at cs.nott.ac.uk (Conor McBride) Date: Mon Oct 1 06:21:53 2007 Subject: [Haskell-cafe] Compose In-Reply-To: References: <7.0.1.0.0.20070930152524.01b72860@ntlworld.com> Message-ID: <8EDF8457-2E7C-4619-9DF5-4BF178397C5F@cs.nott.ac.uk> Hi folks (For those of you at ICFP, my best regards and humblest apologies! I have unavoidable and troublesome distractions which keep me within the UK, but at quite a high average speed.) On 30 Sep 2007, at 15:58, Felipe Almeida Lessa wrote: > On 9/30/07, PR Stanley wrote: >> So the question is, does compose as a function or keyword exist in >> Haskell and if so how can the above code frag be corrected? >> O and, is compose in any way related to curry and uncurry? > > You can't write that function in Haskell as the list is heterogeneous. It's not so easy in Haskell 98 (but I know better than to be confident about its impossibility). It's not a problem with GADTs, however. [Rant about gratuitous renaming and revisionist history deleted.] > data Star f s t where > Nil :: Star f r r > (:*) :: f r s -> Star f s t -> Star f r t > squish :: (forall r. f r r) -> (forall r s t . f r s -> f s t -> f r t) -> > Star f s t -> f s t > squish i c Nil = i > squish i c (rs :* st) = c rs (squish i c st) > type Composition = Star (->) > compose :: Composition s t -> s -> t > compose = squish id (flip (.)) Next, the inevitable digression. As dependently typed programmers are beginning to discover, Star is the new []. A bunch of our favourite structures are stellar, from natural numbers and lists... > data NatStep s t where > Suc :: NatStep () () > type Nat = Star NatStep () () > data ListStep a s t where > Cons :: a -> ListStep a () () > type List a = Star (ListStep a) () () ...to vectors and finite sets. > data SUC a = SUC a > data ZERO = ZERO > data VecStep a s t where > VCons :: a -> VecStep a (SUC n) n > type Vector n a = Star (VecStep a) n ZERO > data LO = LO > data HI = HI > data FinStep s t where > Now :: FinStep (SUC n, LO) (ZERO, HI) > Later :: FinStep (SUC n, LO) (n, LO) > type Fin n = Star FinStep (n, LO) (ZERO, HI) In fact, a vector can be seen as a "natural number with labelled edges" whilst a finite set element is a "natural number with a selected edge". When you have genuine dependent types, you can express these labelling and selection patterns once and for all, indexing one instance of Star (Vector, say) by data drawn from another such instance (Nat, say). If you're interested, you can find a generous lump of Agda 2 code devoted to investigating these phenomena here: http://www.cs.chalmers.se/~ulfn/darcs/Agda2/examples/AIM6/Path/ (The code was hacked up earlier this year at the 6th Agda Implementors' Meeting, mostly by Ulf Norell, with a little provocation from me.) It was a real penny-drop moment for us: we coded up a general sequence structure which was parametric in the index discipline, giving a uniform presentation to lists-with-diverse-extra-weirdness. The reusability absolutely relies on indexing datatypes by ordinary data, rather than some type-level analogue. One should bear in mind such examples (amongst others, no doubt) if one is planning to claim that GADTs + this or that = dependent programming. All the best Conor From prstanley at ntlworld.com Mon Oct 1 14:52:27 2007 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Oct 1 14:51:31 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? Message-ID: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> Hi f x = x + x Is the "x" use to create a pattern in the definition and when f is called it's replaced by a value? What's actually happening here? Thanks, Paul From andrewcoppin at btinternet.com Mon Oct 1 15:01:17 2007 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Mon Oct 1 15:08:45 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> Message-ID: <470143FD.6080900@btinternet.com> PR Stanley wrote: > Hi > f x = x + x > Is the "x" use to create a pattern in the definition and when f is > called it's replaced by a value? Basically, uh, yeah. If you say "f 5", this is basically equivilent to "5 + 5" by the above definition. (I'm sure a huge number of others will chime in on this one too...) From malte at gmx-topmail.de Mon Oct 1 15:18:49 2007 From: malte at gmx-topmail.de (Malte Milatz) Date: Mon Oct 1 15:17:54 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> Message-ID: <20071001211849.705415c9@aligatoro.ret> PR Stanley: > f x = x + x > Is the "x" use to create a pattern in the definition and when f is > called it's replaced by a value? Those equation-like definitions are syntactic sugar for lambda abstractions. f could as well be defined as f = \x -> x + x. From prstanley at ntlworld.com Mon Oct 1 16:44:09 2007 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Oct 1 16:43:14 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <20071001211849.705415c9@aligatoro.ret> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> <20071001211849.705415c9@aligatoro.ret> Message-ID: <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> > > f x = x + x > > Is the "x" use to create a pattern in the definition and when f is > > called it's replaced by a value? > >Those equation-like definitions are syntactic sugar for lambda >abstractions. f could as well be defined as f = \x -> x + x. Please elaborate From westondan at imageworks.com Mon Oct 1 17:11:08 2007 From: westondan at imageworks.com (Dan Weston) Date: Mon Oct 1 17:11:54 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> <20071001211849.705415c9@aligatoro.ret> <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> Message-ID: <4701626C.20705@imageworks.com> If you've never been exposed to lambda calculus, then you're in for a real treat! There is no shortage of tutorials on this. If Greek letters and symbol manipulations are not your thing, take a look at http://worrydream.com/AlligatorEggs/ which describes a game that teaches children about lambda calculus. It is fun to read even for experts. I got the above link off the Wikipedia page http://en.wikipedia.org/wiki/Lambda_abstraction which you can take a look at when you're done learning how alligators each other, lay eggs, and die, in color! PR Stanley wrote: > >> > f x = x + x >> > Is the "x" use to create a pattern in the definition and when f is >> > called it's replaced by a value? >> >> Those equation-like definitions are syntactic sugar for lambda >> abstractions. f could as well be defined as f = \x -> x + x. > > Please elaborate > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From byorgey at gmail.com Mon Oct 1 17:33:45 2007 From: byorgey at gmail.com (Brent Yorgey) Date: Mon Oct 1 17:32:45 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> <20071001211849.705415c9@aligatoro.ret> <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> Message-ID: <22fcbd520710011433k562a67f3q3a9c5259be1f0103@mail.gmail.com> On 10/1/07, PR Stanley wrote: > > > > > f x = x + x > > > Is the "x" use to create a pattern in the definition and when f is > > > called it's replaced by a value? > > > >Those equation-like definitions are syntactic sugar for lambda > >abstractions. f could as well be defined as f = \x -> x + x. > > Please elaborate First, the f x = part says that f is a function which takes a single parameter, called x. The other side of the = sign gives the function body: in this case, x + x. This is exactly the same thing that is expressed by the lambda expression \x -> x + x This expression defines a function that takes a single parameter called x, and returns the value of x + x. The only difference is that with the lambda expression, this function is not given a name. But you can easily give the function a name (just as you can give any Haskell expression a name) by writing f = \x -> x + x In general, writing g x y z = blah blah is just a shorthand for g = \x -> \y -> \z -> blah blah. That is, it simultaneously creates a function expression, and assigns it a name. Does that help? -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071001/ce6f77d4/attachment-0001.htm From i.normann at iu-bremen.de Mon Oct 1 18:43:09 2007 From: i.normann at iu-bremen.de (Immanuel Normann) Date: Mon Oct 1 18:42:21 2007 Subject: [Haskell-cafe] Installation of GLFW package Message-ID: <1191278589.10169.17.camel@kant> Hello, I have just read the thread about "installation of GLUT package" started at 9/3/2007 by Ronald Guida. Installation of the GLFW package is very much related to that. However, I haven't found the solution for installing the GLFW successsfully. I have downloaded http://www.cs.yale.edu/homes/hl293/download/GLFW-20070804.zip and followed the compile and installation instructions from the README.txt file. Actually I haven't noticed any error messages. Then I tried SimpleGraphics from SOE (downloaded from http://www.cs.yale.edu/homes/hl293/download/SOE-20070830.zip) with ghci-6.6. Again loading the file did not raise any error. But when I tried to start main = runGraphics ( do w <- openWindow "My First Graphics Program" (300,300) drawInWindow w (text (100,200) "Hello Graphics World") k <- getKey w closeWindow w ) I got this error message: "During interactive linking, GHCi couldn't find the following symbol: GLFWzm0zi1_GraphicsziUIziGLFW_initializze_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi." Here I am lost. What is the missing library? Regards, Immanuel From bjorn.buckwalter at gmail.com Mon Oct 1 21:59:21 2007 From: bjorn.buckwalter at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Buckwalter?=) Date: Mon Oct 1 21:58:21 2007 Subject: [Haskell-cafe] Unfriendly hs-plugins error Message-ID: <8b2a1a960710011859w21710fdcgfe9269002a447e70@mail.gmail.com> Dear all, I'm getting a rather unfriendly error when trying to load a plugin with hs-plugins: my_program: Ix{Int}.index: Index (65536) out of range ((0,7)) The exact numbers in the message vary depending on what I'm trying to do. I'm using GHC-6.6.1 on MacOS X. Here are three files that exhibit the behaviour for me: API.lhs ======= > module API where > data Config = Config { param :: String } Main.lhs ======== > module Main where > import System (getArgs) > import System.Plugins > import API > getConfig :: [String] -> IO Config > getConfig [file] = do > status <- make file [] > obj <- case status of > MakeSuccess _ o -> return o > MakeFailure es -> mapM_ putStrLn es >> error "make failed" > putStrLn $ "### loading " ++ file > m_v <- load_ obj ["."] "config" > putStrLn $ "### checking " ++ file > val <- case m_v of > LoadSuccess _ v -> return v > LoadFailure es -> mapM_ putStrLn es >> error "load failed" > return val > main = getArgs >>= getConfig >>= putStrLn . param CustomConfig.hs =============== >module CustomConfig where > import API > config = Config { param = "Doomed to fail!" } I compile the above with "ghc --make -o my_program PluginTest.lhs" and execute with "./my_program CustomConfig.lhs". Any hints welcome. Thanks, Bjorn Buckwalter From bjorn.buckwalter at gmail.com Mon Oct 1 22:29:34 2007 From: bjorn.buckwalter at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Buckwalter?=) Date: Mon Oct 1 22:28:33 2007 Subject: [Haskell-cafe] Re: Unfriendly hs-plugins error In-Reply-To: <8b2a1a960710011859w21710fdcgfe9269002a447e70@mail.gmail.com> References: <8b2a1a960710011859w21710fdcgfe9269002a447e70@mail.gmail.com> Message-ID: <8b2a1a960710011929s4c2c5bf7wc9446d1582bbed3@mail.gmail.com> By the way, this was with hs-plugins-1.0-rc1. I appear to be unable to install hs-plugins-0.9.10 now (perhaps because of 1.0-rc1). In case it helps this is the not so pretty output from doing a "make check" in 1.0rc1: === testing testsuite/conf/simple ... === testing testsuite/dynload/io ... === testing testsuite/dynload/poly ... === testing testsuite/dynload/should_fail ... === testing testsuite/dynload/should_fail_1 ... === testing testsuite/dynload/should_fail_2 ... === testing testsuite/dynload/should_fail_3 ... === testing testsuite/dynload/simple ... === testing testsuite/eval/eval1 ... === testing testsuite/eval/eval2 ... === testing testsuite/eval/eval3 ... === testing testsuite/eval/eval_ ... === testing testsuite/eval/eval_fn ... === testing testsuite/eval/eval_fn1 ... === testing testsuite/eval/foreign_eval ... ignored. === testing testsuite/eval/foreign_eval1 ... ignored. === testing testsuite/eval/foreign_should_fail ... ignored. === testing testsuite/eval/foreign_should_fail_illtyped ... ignored. === testing testsuite/eval/unsafeidir ... === testing testsuite/hier/hier1 ... === testing testsuite/hier/hier2 ... === testing testsuite/hier/hier3 ... === testing testsuite/hier/hier4 ... === testing testsuite/iface/null ... === testing testsuite/load/io ... === testing testsuite/load/load_0 ... === testing testsuite/load/loadpkg ... === testing testsuite/load/null ... === testing testsuite/load/thiemann0 ... === testing testsuite/load/thiemann2 ... === testing testsuite/load/unloadpkg ... === testing testsuite/loadCLib/null ... === testing testsuite/make/makeall001 ... === testing testsuite/make/null ... === testing testsuite/make/o ... === testing testsuite/make/odir ... === testing testsuite/make/remake001 ... === testing testsuite/make/remake001_should_fail ... === testing testsuite/make/simple ... === testing testsuite/makewith/global_pragma ... === testing testsuite/makewith/io ... === testing testsuite/makewith/merge00 ... === testing testsuite/makewith/mergeto0 ... === testing testsuite/makewith/module_name ... === testing testsuite/makewith/multi_make ... === testing testsuite/makewith/should_fail_0 ... === testing testsuite/makewith/tiny ... === testing testsuite/makewith/unsafeio ... === testing testsuite/misc/mkstemps ... === testing testsuite/multi/3plugins ... === testing testsuite/objc/expression_parser ... ignored. === testing testsuite/pdynload/badint ... === testing testsuite/pdynload/bayley1 ... === testing testsuite/pdynload/null ... === testing testsuite/pdynload/numclass ... === testing testsuite/pdynload/poly ... === testing testsuite/pdynload/poly1 ... === testing testsuite/pdynload/should_fail0 ... === testing testsuite/pdynload/should_fail1 ... === testing testsuite/pdynload/small ... === testing testsuite/pdynload/spj1 ... ignored. === testing testsuite/pdynload/spj2 ... === testing testsuite/pdynload/spj3 ... === testing testsuite/pdynload/spj4 ... === testing testsuite/pdynload/typealias ... === testing testsuite/pdynload/univquant ... === testing testsuite/pkgconf/null ... ignored. === testing testsuite/plugs/plugs ... failed with: / .___/_/\__,_/\__, /____/ Type :? for help /_/ /____/ -Loading package base ... linking ... plugs> plugs> done -453973694165307953197296969697410619233826 +Loading package base ... linking ... plugs> let fibs = 1 : 1 : zipWith (+) fibs (tail fibs) in fibs !! 200 +plugs: +unknown symbol `_base_GHCziList_znzn_closure' +done +plugs: user error (resolvedObjs failed.) + === testing testsuite/plugs/runplugs ... === testing testsuite/reload/null ... === testing testsuite/shell/shell ... ignored. === testing testsuite/shell/simple ... ignored. === testing testsuite/unload/null ... === testing testsuite/unload/sjwtrap ... === testing testsuite/unloadAll/null ... On 10/1/07, Bj?rn Buckwalter wrote: > Dear all, > > I'm getting a rather unfriendly error when trying to load a plugin > with hs-plugins: > > my_program: Ix{Int}.index: Index (65536) out of range ((0,7)) > > The exact numbers in the message vary depending on what I'm trying to > do. I'm using GHC-6.6.1 on MacOS X. Here are three files that exhibit > the behaviour for me: > > API.lhs > ======= > > module API where > > data Config = Config { param :: String } > > Main.lhs > ======== > > module Main where > > import System (getArgs) > > import System.Plugins > > import API > > > getConfig :: [String] -> IO Config > > getConfig [file] = do > > status <- make file [] > > obj <- case status of > > MakeSuccess _ o -> return o > > MakeFailure es -> mapM_ putStrLn es >> error "make failed" > > putStrLn $ "### loading " ++ file > > m_v <- load_ obj ["."] "config" > > putStrLn $ "### checking " ++ file > > val <- case m_v of > > LoadSuccess _ v -> return v > > LoadFailure es -> mapM_ putStrLn es >> error "load failed" > > return val > > > main = getArgs >>= getConfig >>= putStrLn . param > > CustomConfig.hs > =============== > >module CustomConfig where > > import API > > config = Config { param = "Doomed to fail!" } > > > I compile the above with "ghc --make -o my_program PluginTest.lhs" and > execute with "./my_program CustomConfig.lhs". > > Any hints welcome. Thanks, > Bjorn Buckwalter > From dgoldsmith at mac.com Mon Oct 1 22:50:39 2007 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Mon Oct 1 22:49:40 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> Message-ID: Sorry for the long delay, work has been really busy... On Sep 27, 2007, at 12:25 PM, Aaron Denney wrote: > On 2007-09-27, Aaron Denney wrote: >>> Well, not so much. As Duncan mentioned, it's a matter of what the >>> most >>> common case is. UTF-16 is effectively fixed-width for the majority >>> of >>> text in the majority of languages. Combining sequences and surrogate >>> pairs are relatively infrequent. >> >> Infrequent, but they exist, which means you can't seek x/2 bytes >> ahead >> to seek x characters ahead. All such seeking must be linear for both >> UTF-16 *and* UTF-8. >> >>> Speaking as someone who has done a lot of Unicode implementation, I >>> would say UTF-16 represents the best time/space tradeoff for an >>> internal representation. As I mentioned, it's what's used in >>> Windows, >>> Mac OS X, ICU, and Java. > > I guess why I'm being something of a pain-in-the-ass here, is that > I want to use your Unicode implementation expertise to know what > these time/space tradeoffs are. > > Are there any algorithmic asymptotic complexity differences, or all > these all constant factors? The constant factors depend on projected > workload. And are these actually tradeoffs, except between UTF-32 > (which uses native wordsizes on 32-bit platforms) and the other two? > Smaller space means smaller cache footprint, which can dominate. Yes, cache footprint is one reason to use UTF-16 rather than UTF-32. Having no surrogate pairs also doesn't save you anything because you need to handle sequences anyway, such as combining marks and clusters. The best reference for all of this is: http://www.unicode.org/faq/utf_bom.html See especially: http://www.unicode.org/faq/utf_bom.html#10 http://www.unicode.org/faq/utf_bom.html#12 Which data type is best depends on what the purpose is. If the data will primarily be ASCII with an occasional non-ASCII characters, UTF-8 may be best. If the data is general Unicode text, UTF-16 is best. I would think a Unicode string type would be intended for processing natural language text, not just ASCII data. > Simplicity of algorithms is also a concern. Validating a byte > sequence > as UTF-8 is harder than validating a sequence of 16-bit values as > UTF-16. > > (I'd also like to see a reference to the Mac OS X encoding. I know > that > the filesystem interface is UTF-8 (decomposed a certain a way). Is it > just that UTF-16 is a common application choice, or is there some > common framework or library that uses that?) UTF-16 is the native encoding used for Cocoa, Java, ICU, and Carbon, and is what appears in the APIs for all of them. UTF-16 is also what's stored in the volume catalog on Mac disks. UTF-8 is only used in BSD APIs for backward compatibility. It's also used in plain text files (or XML or HTML), again for compatibility. Deborah From allbery at ece.cmu.edu Tue Oct 2 01:00:17 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Oct 2 00:59:21 2007 Subject: [Haskell-cafe] Unfriendly hs-plugins error In-Reply-To: <8b2a1a960710011859w21710fdcgfe9269002a447e70@mail.gmail.com> References: <8b2a1a960710011859w21710fdcgfe9269002a447e70@mail.gmail.com> Message-ID: <07C590FC-E81D-40D6-B5A3-64AEF4A48005@ece.cmu.edu> On Oct 1, 2007, at 21:59 , Bj?rn Buckwalter wrote: > Dear all, > > I'm getting a rather unfriendly error when trying to load a plugin > with hs-plugins: > > my_program: Ix{Int}.index: Index (65536) out of range ((0,7)) This tends to mean that hs-plugins doesn't understand the format of the .hi (compiled haskell module interface) file, which happens every time a new ghc is released. Likely it's not been ported to work with 6.6.1 yet. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From jeeva.suresh at gmail.com Tue Oct 2 01:07:07 2007 From: jeeva.suresh at gmail.com (jeeva suresh) Date: Tue Oct 2 01:06:07 2007 Subject: [Haskell-cafe] Unfriendly hs-plugins error In-Reply-To: <07C590FC-E81D-40D6-B5A3-64AEF4A48005@ece.cmu.edu> References: <8b2a1a960710011859w21710fdcgfe9269002a447e70@mail.gmail.com> <07C590FC-E81D-40D6-B5A3-64AEF4A48005@ece.cmu.edu> Message-ID: <941780b40710012207g7efcc2f9m525dbafc1b482198@mail.gmail.com> I had a similar problem, I solved it by using the development version of hs-plugins (ie. darcs get --set-scripts-executable http://www.cse.unsw.edu.au/~dons/code/hs-plugins) On 02/10/2007, Brandon S. Allbery KF8NH wrote: > > > On Oct 1, 2007, at 21:59 , Bj?rn Buckwalter wrote: > > > Dear all, > > > > I'm getting a rather unfriendly error when trying to load a plugin > > with hs-plugins: > > > > my_program: Ix{Int}.index: Index (65536) out of range ((0,7)) > > This tends to mean that hs-plugins doesn't understand the format of > the .hi (compiled haskell module interface) file, which happens every > time a new ghc is released. Likely it's not been ported to work with > 6.6.1 yet. > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- -Jeeva -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071002/15600090/attachment-0001.htm From bf3 at telenet.be Tue Oct 2 04:49:31 2007 From: bf3 at telenet.be (Peter Verswyvelen) Date: Tue Oct 2 04:48:38 2007 Subject: [Haskell-cafe] Installation of GLFW package In-Reply-To: <1191278589.10169.17.camel@kant> References: <1191278589.10169.17.camel@kant> Message-ID: <4702061B.3080105@telenet.be> Hi Immanuel, Are you using Windows or Linux or OSX? Under Windows, I was able to install it (no need to compile, since the libraries are bundled). I could also run some examples from the SOE book, however IMO the GLFW Haskell wrapper seems to contain some bugs (at least on Windows) that prevented some demos from working. I locally fixed the GLFW.hs file so that all seems to work. But you don't seem to get to that step yet... I had the error you described once when installing another package that had an incomplete cabal file, but that can't be the case here I guess... If you just want to try SOE, you can also try GTK2HS http://haskell.org/gtk2hs (note you'll have to replace each "import SOE" line with "import Graphics.SOE.Gtk) Cheers, Peter Immanuel Normann wrote: > Hello, > > I have just read the thread about "installation of GLUT package" started > at 9/3/2007 by Ronald Guida. Installation of the GLFW package is very > much related to that. However, I haven't found the solution for > installing the GLFW successsfully. > > I have downloaded > > http://www.cs.yale.edu/homes/hl293/download/GLFW-20070804.zip > > and followed the compile and installation instructions from the > README.txt file. Actually I haven't noticed any error messages. > > Then I tried SimpleGraphics from SOE (downloaded from > http://www.cs.yale.edu/homes/hl293/download/SOE-20070830.zip) > with ghci-6.6. Again loading the file did not raise any error. > > But when I tried to start > > main > = runGraphics ( > do w <- openWindow > "My First Graphics Program" (300,300) > drawInWindow w (text (100,200) "Hello Graphics World") > k <- getKey w > closeWindow w > ) > > I got this error message: > > "During interactive linking, GHCi couldn't find the following symbol: > GLFWzm0zi1_GraphicsziUIziGLFW_initializze_closure > This may be due to you not asking GHCi to load extra object files, > archives or DLLs needed by your current session. Restart GHCi, > specifying > the missing library using the -L/path/to/object/dir and -lmissinglibname > flags, or simply by naming the relevant files on the GHCi command line. > Alternatively, this link failure might indicate a bug in GHCi." > > Here I am lost. What is the missing library? > > Regards, > Immanuel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071002/7f1d6ca9/attachment.htm From bjorn.buckwalter at gmail.com Tue Oct 2 06:43:50 2007 From: bjorn.buckwalter at gmail.com (=?ISO-8859-1?Q?Bj=F6rn_Buckwalter?=) Date: Tue Oct 2 06:42:47 2007 Subject: [Haskell-cafe] Unfriendly hs-plugins error In-Reply-To: <941780b40710012207g7efcc2f9m525dbafc1b482198@mail.gmail.com> References: <8b2a1a960710011859w21710fdcgfe9269002a447e70@mail.gmail.com> <07C590FC-E81D-40D6-B5A3-64AEF4A48005@ece.cmu.edu> <941780b40710012207g7efcc2f9m525dbafc1b482198@mail.gmail.com> Message-ID: <8b2a1a960710020343i92cf3bavf6bfed611ea67117@mail.gmail.com> That helped, thanks! On 10/2/07, jeeva suresh wrote: > I had a similar problem, I solved it by using the development version of > hs-plugins (ie. darcs get --set-scripts-executable > http://www.cse.unsw.edu.au/~dons/code/hs-plugins) > > > On 02/10/2007, Brandon S. Allbery KF8NH wrote: > > > > > > On Oct 1, 2007, at 21:59 , Bj?rn Buckwalter wrote: > > > > > Dear all, > > > > > > I'm getting a rather unfriendly error when trying to load a plugin > > > with hs-plugins: > > > > > > my_program: Ix{Int}.index: Index (65536) out of range ((0,7)) > > > > This tends to mean that hs-plugins doesn't understand the format of > > the .hi (compiled haskell module interface) file, which happens every > > time a new ghc is released. Likely it's not been ported to work with > > 6.6.1 yet. > > > > -- > > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] > allbery@kf8nh.com > > system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu > > electrical and computer engineering, carnegie mellon university KF8NH > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > -- > -Jeeva > From haskell at list.mightyreason.com Tue Oct 2 08:11:54 2007 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Oct 2 08:12:42 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> Message-ID: <4702358A.8010003@list.mightyreason.com> Deborah Goldsmith wrote: > UTF-16 is the native encoding used for Cocoa, Java, ICU, and Carbon, and > is what appears in the APIs for all of them. UTF-16 is also what's > stored in the volume catalog on Mac disks. UTF-8 is only used in BSD > APIs for backward compatibility. It's also used in plain text files (or > XML or HTML), again for compatibility. > > Deborah On OS X, Cocoa and Carbon use Core Foundation, whose API does not have a one-true-encoding internally. Follow the rather long URL for details: http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFStrings/index.html?http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFStrings/Articles/StringStorage.html#//apple_ref/doc/uid/20001179 I would vote for an API that not just hides the internal store, but allows different internal stores to be used in a mostly compatible way. However, There is a UniChar typedef on OS X which is the same unsigned 16 bit integer as Java's JNI would use. -- Chris From asandroq at gmail.com Tue Oct 2 09:52:53 2007 From: asandroq at gmail.com (Alex Queiroz) Date: Tue Oct 2 09:51:50 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec Message-ID: <54e12800710020652x383e5611i302b5e392ea545@mail.gmail.com> Hallo, For fun and learning I'm trying to parse R5RS Scheme with Parsec. The code to parse lists follows: -- -- Lists -- parseLeftList :: Parser [SchDatum] parseLeftList = do char '(' many parseDatum >>= return . filter (/= SchAtmosphere) parseDottedList :: [SchDatum] -> Parser SchDatum parseDottedList ls = do char '.' many1 parseAtmosphere d <- parseDatum many parseAtmosphere char ')' return $ SchDottedList ls d parseProperList :: [SchDatum] -> Parser SchDatum parseProperList ls = do char ')' return $ SchList ls parseList :: Parser SchDatum parseList = do ls <- parseLeftList (parseDottedList ls) <|> (parseProperList ls) I've factored out the common left sub-expression in parseLeftList. The problem is that "..." is a valid identifier so when inside the left of the list the parser sees a single dot, it tries to match it with "...", which fails. Can anybody give advice on how to rewrite these list parsing functions? Cheers, -- -alex http://www.ventonegro.org/ From allbery at ece.cmu.edu Tue Oct 2 10:28:42 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Oct 2 10:27:42 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec In-Reply-To: <54e12800710020652x383e5611i302b5e392ea545@mail.gmail.com> References: <54e12800710020652x383e5611i302b5e392ea545@mail.gmail.com> Message-ID: <1ED646C3-033D-4913-A716-C69B30D0BE82@ece.cmu.edu> On Oct 2, 2007, at 9:52 , Alex Queiroz wrote: > (parseDottedList ls) <|> (parseProperList ls) > > I've factored out the common left sub-expression in > parseLeftList. The problem is that "..." is a valid identifier so when > inside the left of the list the parser sees a single dot, it tries to > match it with "...", which fails. Can anybody give advice on how to > rewrite these list parsing functions? try (parseDottedList ls) <|> parseProperList ls Overuse of try is a bad idea because it's slow, but sometimes it's the only way to go; it insures backtracking in cases like this. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From asandroq at gmail.com Tue Oct 2 10:36:52 2007 From: asandroq at gmail.com (Alex Queiroz) Date: Tue Oct 2 10:35:49 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec In-Reply-To: <1ED646C3-033D-4913-A716-C69B30D0BE82@ece.cmu.edu> References: <54e12800710020652x383e5611i302b5e392ea545@mail.gmail.com> <1ED646C3-033D-4913-A716-C69B30D0BE82@ece.cmu.edu> Message-ID: <54e12800710020736s4c0c4ffcg4c046bbfff514441@mail.gmail.com> Hallo, On 10/2/07, Brandon S. Allbery KF8NH wrote: > > On Oct 2, 2007, at 9:52 , Alex Queiroz wrote: > > > (parseDottedList ls) <|> (parseProperList ls) > > > > I've factored out the common left sub-expression in > > parseLeftList. The problem is that "..." is a valid identifier so when > > inside the left of the list the parser sees a single dot, it tries to > > match it with "...", which fails. Can anybody give advice on how to > > rewrite these list parsing functions? > > try (parseDottedList ls) <|> parseProperList ls > > Overuse of try is a bad idea because it's slow, but sometimes it's > the only way to go; it insures backtracking in cases like this. > This does not work. The parser chokes in parseLeftList, because it finds a single dot which is not the beginning of "...". Cheers, -- -alex http://www.ventonegro.org/ From allbery at ece.cmu.edu Tue Oct 2 10:47:41 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Oct 2 10:46:40 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec In-Reply-To: <54e12800710020736s4c0c4ffcg4c046bbfff514441@mail.gmail.com> References: <54e12800710020652x383e5611i302b5e392ea545@mail.gmail.com> <1ED646C3-033D-4913-A716-C69B30D0BE82@ece.cmu.edu> <54e12800710020736s4c0c4ffcg4c046bbfff514441@mail.gmail.com> Message-ID: <667F1056-CDC5-4373-8F54-08F8B5DC4939@ece.cmu.edu> On Oct 2, 2007, at 10:36 , Alex Queiroz wrote: > This does not work. The parser chokes in parseLeftList, because > it finds a single dot which is not the beginning of "...". Sorry, just woke up and still not quite tracking right, so I modified the wrong snippet of code. The trick is to wrap parseLeftList in a try, so the parser retries the next alternative when it fails. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From asandroq at gmail.com Tue Oct 2 10:56:40 2007 From: asandroq at gmail.com (Alex Queiroz) Date: Tue Oct 2 10:55:36 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec In-Reply-To: <667F1056-CDC5-4373-8F54-08F8B5DC4939@ece.cmu.edu> References: <54e12800710020652x383e5611i302b5e392ea545@mail.gmail.com> <1ED646C3-033D-4913-A716-C69B30D0BE82@ece.cmu.edu> <54e12800710020736s4c0c4ffcg4c046bbfff514441@mail.gmail.com> <667F1056-CDC5-4373-8F54-08F8B5DC4939@ece.cmu.edu> Message-ID: <54e12800710020756i5314cfe7s3638f93ac8903a79@mail.gmail.com> Hallo, On 10/2/07, Brandon S. Allbery KF8NH wrote: > > Sorry, just woke up and still not quite tracking right, so I modified > the wrong snippet of code. The trick is to wrap parseLeftList in a > try, so the parser retries the next alternative when it fails. > Since "..." can only appear at the end of a list, I removed "..." from the possible symbols and added a new function: parseThreeDottedList :: [SchDatum] -> Parser SchDatum parseThreeDottedList ls = do string "..." many parseAtmosphere char ')' return $ SchList $ ls ++ [SchSymbol "..."] parseList :: Parser SchDatum parseList = do ls <- parseLeftList try (parseThreeDottedList ls) <|> (parseDottedList ls) <|> (parseProperList ls) Thanks for the help. Cheers, -- -alex http://www.ventonegro.org/ From dgoldsmith at mac.com Tue Oct 2 11:02:30 2007 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Tue Oct 2 11:01:36 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <4702358A.8010003@list.mightyreason.com> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> Message-ID: <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> On Oct 2, 2007, at 5:11 AM, ChrisK wrote: > Deborah Goldsmith wrote: > >> UTF-16 is the native encoding used for Cocoa, Java, ICU, and >> Carbon, and >> is what appears in the APIs for all of them. UTF-16 is also what's >> stored in the volume catalog on Mac disks. UTF-8 is only used in BSD >> APIs for backward compatibility. It's also used in plain text >> files (or >> XML or HTML), again for compatibility. >> >> Deborah > > > On OS X, Cocoa and Carbon use Core Foundation, whose API does not > have a > one-true-encoding internally. Follow the rather long URL for details: > > http://developer.apple.com/documentation/CoreFoundation/Conceptual/ > CFStrings/index.html?http://developer.apple.com/documentation/ > CoreFoundation/Conceptual/CFStrings/Articles/StringStorage.html#// > apple_ref/doc/uid/20001179 > > I would vote for an API that not just hides the internal store, but > allows > different internal stores to be used in a mostly compatible way. > > However, There is a UniChar typedef on OS X which is the same > unsigned 16 bit > integer as Java's JNI would use. UTF-16 is the type used in all the APIs. Everything else is considered an encoding conversion. CoreFoundation uses UTF-16 internally except when the string fits entirely in a single-byte legacy encoding like MacRoman or MacCyrillic. If any kind of Unicode processing needs to be done to the string, it is first coerced to UTF-16. If it weren't for backwards compatibility issues, I think we'd use UTF-16 all the time as the machinery for switching encodings adds complexity. I wouldn't advise it for a new library. Deborah From ninegua at gmail.com Tue Oct 2 11:18:44 2007 From: ninegua at gmail.com (Paul L) Date: Tue Oct 2 11:17:43 2007 Subject: [Haskell-cafe] Installation of GLFW package In-Reply-To: <1191278589.10169.17.camel@kant> References: <1191278589.10169.17.camel@kant> Message-ID: <856033f20710020818h7abe4863v63cd8dc6cb273391@mail.gmail.com> It seems like the GLFW C binaries wasn't included in your GLFW Haskell module installed. Did you do the last step by running install.bat or install.sh instead of "runhaskell Setup install"? Regards, Paul Liu On 10/2/07, Immanuel Normann wrote: > Hello, > > I have just read the thread about "installation of GLUT package" started > at 9/3/2007 by Ronald Guida. Installation of the GLFW package is very > much related to that. However, I haven't found the solution for > installing the GLFW successsfully. > > I have downloaded > > http://www.cs.yale.edu/homes/hl293/download/GLFW-20070804.zip > > and followed the compile and installation instructions from the > README.txt file. Actually I haven't noticed any error messages. > > Then I tried SimpleGraphics from SOE (downloaded from > http://www.cs.yale.edu/homes/hl293/download/SOE-20070830.zip) > with ghci-6.6. Again loading the file did not raise any error. > > But when I tried to start > > main > = runGraphics ( > do w <- openWindow > "My First Graphics Program" (300,300) > drawInWindow w (text (100,200) "Hello Graphics World") > k <- getKey w > closeWindow w > ) > > I got this error message: > > "During interactive linking, GHCi couldn't find the following symbol: > GLFWzm0zi1_GraphicsziUIziGLFW_initializze_closure > This may be due to you not asking GHCi to load extra object files, > archives or DLLs needed by your current session. Restart GHCi, > specifying > the missing library using the -L/path/to/object/dir and -lmissinglibname > flags, or simply by naming the relevant files on the GHCi command line. > Alternatively, this link failure might indicate a bug in GHCi." > > Here I am lost. What is the missing library? > > Regards, > Immanuel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jonathanccast at fastmail.fm Tue Oct 2 11:44:52 2007 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Oct 2 11:43:51 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> Message-ID: <1191339892.5435.3.camel@jcchost> On Tue, 2007-10-02 at 08:02 -0700, Deborah Goldsmith wrote: > On Oct 2, 2007, at 5:11 AM, ChrisK wrote: > > Deborah Goldsmith wrote: > > > >> UTF-16 is the native encoding used for Cocoa, Java, ICU, and > >> Carbon, and > >> is what appears in the APIs for all of them. UTF-16 is also what's > >> stored in the volume catalog on Mac disks. UTF-8 is only used in BSD > >> APIs for backward compatibility. It's also used in plain text > >> files (or > >> XML or HTML), again for compatibility. > >> > >> Deborah > > > > > > On OS X, Cocoa and Carbon use Core Foundation, whose API does not > > have a > > one-true-encoding internally. Follow the rather long URL for details: > > > > http://developer.apple.com/documentation/CoreFoundation/Conceptual/ > > CFStrings/index.html?http://developer.apple.com/documentation/ > > CoreFoundation/Conceptual/CFStrings/Articles/StringStorage.html#// > > apple_ref/doc/uid/20001179 > > > > I would vote for an API that not just hides the internal store, but > > allows > > different internal stores to be used in a mostly compatible way. > > > > However, There is a UniChar typedef on OS X which is the same > > unsigned 16 bit > > integer as Java's JNI would use. > > UTF-16 is the type used in all the APIs. Everything else is > considered an encoding conversion. > > CoreFoundation uses UTF-16 internally except when the string fits > entirely in a single-byte legacy encoding like MacRoman or > MacCyrillic. If any kind of Unicode processing needs to be done to > the string, it is first coerced to UTF-16. If it weren't for > backwards compatibility issues, I think we'd use UTF-16 all the time > as the machinery for switching encodings adds complexity. I wouldn't > advise it for a new library. I would like to, again, strongly argue against sacrificing compatibility with Linux/BSD/etc. for the sake of compatibility with OS X or Windows. FFI bindings have to convert data formats in any case; Haskell shouldn't gratuitously break Linux support (or make life harder on Linux) just to support proprietary operating systems better. Now, if /independent of the details of MacOS X/, UTF-16 is better (objectively), it can be converted to anything by the FFI. But doing it the way Java or MacOS X or Win32 or anyone else does it, at the expense of Linux, I am strongly opposed to. jcc From johan.tibell at gmail.com Tue Oct 2 12:57:19 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Oct 2 12:56:16 2007 Subject: [Haskell-cafe] Using C-c C-l to load .hsc file into ghci in Emacs Message-ID: <90889fe70710020957w2a997e27ob82b9ba0b2282936@mail.gmail.com> How can I get C-c C-l to first run cpp on a .hsc file and then load the .hs file? I checked out the network package from darcs and then did: Start ghci, C-c C-z, then: Prelude> :set -cpp And then pressed load, C-c C-l: Prelude> :load "/Users/tibell/src/haskell/network-bytestring/Network/Socket.hsc" : Could not find module `/Users/tibell/src/haskell/network-bytestring/Network/Socket.hsc': Use -v to see a list of the files searched for. Failed, modules loaded: none. Prelude> :load "/Users/tibell/src/haskell/network-bytestring/Network/Socket.hsc" : Could not find module `/Users/tibell/src/haskell/network-bytestring/Network/Socket.hsc': Use -v to see a list of the files searched for. Failed, modules loaded: none. From miguelimo38 at yandex.ru Tue Oct 2 14:05:38 2007 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Tue Oct 2 14:04:48 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <1191339892.5435.3.camel@jcchost> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <1191339892.5435.3.camel@jcchost> Message-ID: <34CF03B8-5C31-40C5-B4A0-1CA28EB553D6@yandex.ru> > I would like to, again, strongly argue against sacrificing > compatibility > with Linux/BSD/etc. for the sake of compatibility with OS X or > Windows. Ehm? I've used to think MacOS is a sort of BSD... From ryani.spam at gmail.com Tue Oct 2 14:50:24 2007 From: ryani.spam at gmail.com (Ryan Ingram) Date: Tue Oct 2 14:49:23 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec In-Reply-To: <54e12800710020756i5314cfe7s3638f93ac8903a79@mail.gmail.com> References: <54e12800710020652x383e5611i302b5e392ea545@mail.gmail.com> <1ED646C3-033D-4913-A716-C69B30D0BE82@ece.cmu.edu> <54e12800710020736s4c0c4ffcg4c046bbfff514441@mail.gmail.com> <667F1056-CDC5-4373-8F54-08F8B5DC4939@ece.cmu.edu> <54e12800710020756i5314cfe7s3638f93ac8903a79@mail.gmail.com> Message-ID: <2f9b2d30710021150j5cd7b104rdc38d0a95675e718@mail.gmail.com> I don't know if this applies to Scheme parsing, but I find it's often helpful to introduce a tokenizer into the parser to centralize the use of "try" to one place:: type Token = String tokRaw :: Parser Token tokRaw = {- implement this yourself depending on language spec -} tok :: Parser Token tok = do t <- tokRaw many spaces return t -- wrap your outside parser with this; it gets the tokenizer -- started because we only handle eating spaces after tokens, -- not before startParser :: Parser a -> Parser a startParser a = many spaces >> a sat :: (Token -> Maybe a) -> Parser a sat f = try $ do t <- tok case f t of Nothing -> mzero Just a -> return a lit :: Token -> Parser Token lit s = sat (test s) s where test s t = if (s == t) then Just s else Nothing Now if you replace uses of "string" and "char" in your code with "lit", you avoid the problem of parses failing because they consumed some input from the "wrong" token type before failing. On 10/2/07, Alex Queiroz wrote: > Hallo, > > On 10/2/07, Brandon S. Allbery KF8NH wrote: > > > > Sorry, just woke up and still not quite tracking right, so I modified > > the wrong snippet of code. The trick is to wrap parseLeftList in a > > try, so the parser retries the next alternative when it fails. > > > > Since "..." can only appear at the end of a list, I removed "..." > from the possible symbols and added a new function: > > parseThreeDottedList :: [SchDatum] -> Parser SchDatum > parseThreeDottedList ls = do > string "..." > many parseAtmosphere > char ')' > return $ SchList $ ls ++ [SchSymbol "..."] > > parseList :: Parser SchDatum > parseList = do > ls <- parseLeftList > try (parseThreeDottedList ls) <|> (parseDottedList ls) <|> > (parseProperList ls) > > Thanks for the help. > > Cheers, > -- > -alex > http://www.ventonegro.org/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jonathanccast at fastmail.fm Tue Oct 2 16:06:25 2007 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Oct 2 16:05:25 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <34CF03B8-5C31-40C5-B4A0-1CA28EB553D6@yandex.ru> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <1191339892.5435.3.camel@jcchost> <34CF03B8-5C31-40C5-B4A0-1CA28EB553D6@yandex.ru> Message-ID: <1191355585.5435.5.camel@jcchost> On Tue, 2007-10-02 at 22:05 +0400, Miguel Mitrofanov wrote: > > I would like to, again, strongly argue against sacrificing > > compatibility > > with Linux/BSD/etc. for the sake of compatibility with OS X or > > Windows. > > Ehm? I've used to think MacOS is a sort of BSD... Cocoa, then. jcc From stefanor at cox.net Tue Oct 2 16:53:15 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Oct 2 16:52:14 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> References: <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> Message-ID: <20071002205315.GA3046@localhost.localdomain> On Tue, Oct 02, 2007 at 08:02:30AM -0700, Deborah Goldsmith wrote: > UTF-16 is the type used in all the APIs. Everything else is considered an > encoding conversion. > > CoreFoundation uses UTF-16 internally except when the string fits entirely > in a single-byte legacy encoding like MacRoman or MacCyrillic. If any kind > of Unicode processing needs to be done to the string, it is first coerced > to UTF-16. If it weren't for backwards compatibility issues, I think we'd > use UTF-16 all the time as the machinery for switching encodings adds > complexity. I wouldn't advise it for a new library. I do not believe that anyone was seriously advocating multiple blessed encodings. The main question is *which* encoding to bless. 99+% of text I encounter is in US-ASCII, so I would favor UTF-8. Why is UTF-16 better for me? Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20071002/81a95a11/attachment-0001.bin From stefanor at cox.net Tue Oct 2 16:58:52 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Oct 2 16:57:49 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec In-Reply-To: <54e12800710020736s4c0c4ffcg4c046bbfff514441@mail.gmail.com> References: <54e12800710020652x383e5611i302b5e392ea545@mail.gmail.com> <1ED646C3-033D-4913-A716-C69B30D0BE82@ece.cmu.edu> <54e12800710020736s4c0c4ffcg4c046bbfff514441@mail.gmail.com> Message-ID: <20071002205852.GB3046@localhost.localdomain> On Tue, Oct 02, 2007 at 11:36:52AM -0300, Alex Queiroz wrote: > Hallo, > > On 10/2/07, Brandon S. Allbery KF8NH wrote: > > > > On Oct 2, 2007, at 9:52 , Alex Queiroz wrote: > > > > > (parseDottedList ls) <|> (parseProperList ls) > > > > > > I've factored out the common left sub-expression in > > > parseLeftList. The problem is that "..." is a valid identifier so when > > > inside the left of the list the parser sees a single dot, it tries to > > > match it with "...", which fails. Can anybody give advice on how to > > > rewrite these list parsing functions? > > > > try (parseDottedList ls) <|> parseProperList ls > > > > Overuse of try is a bad idea because it's slow, but sometimes it's > > the only way to go; it insures backtracking in cases like this. > > > > This does not work. The parser chokes in parseLeftList, because > it finds a single dot which is not the beginning of "...". I suggest left-factoring. parseThingyOrEOL = (space >> parseThingyOrEOL) <|> (fmap Left parseAtom) <|> (char '.' >> parseThingyOrEOL >>= \(Left x) -> Right x) <|> (char ')' >> return (Right nil)) <|> (char '(' >> fmap Left (fix (\ plist -> do obj <- parseThingyOrEOL case obj of Left x -> fmap (Cons x) plist Right x -> return x))) etc. Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20071002/87f4db55/attachment.bin From johan.tibell at gmail.com Tue Oct 2 17:05:38 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue Oct 2 17:04:35 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <20071002205315.GA3046@localhost.localdomain> References: <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <20071002205315.GA3046@localhost.localdomain> Message-ID: <90889fe70710021405i6549f618s8f695111cd7e452d@mail.gmail.com> > I do not believe that anyone was seriously advocating multiple blessed > encodings. The main question is *which* encoding to bless. 99+% of > text I encounter is in US-ASCII, so I would favor UTF-8. Why is UTF-16 > better for me? All software I write professional have to support 40 languages (including CJK ones) so I would prefer UTF-16 in case I could use Haskell at work some day in the future. I dunno that who uses what encoding the most is good grounds to pick encoding though. Ease of implementation and speed on some representative sample set of text may be. -- Johan From i.normann at iu-bremen.de Tue Oct 2 17:20:01 2007 From: i.normann at iu-bremen.de (Immanuel Normann) Date: Tue Oct 2 17:19:07 2007 Subject: [Haskell-cafe] Installation of GLFW package In-Reply-To: <856033f20710020818h7abe4863v63cd8dc6cb273391@mail.gmail.com> References: <1191278589.10169.17.camel@kant> <856033f20710020818h7abe4863v63cd8dc6cb273391@mail.gmail.com> Message-ID: <1191360001.6242.2.camel@kant> Am Dienstag, den 02.10.2007, 23:18 +0800 schrieb Paul L: > It seems like the GLFW C binaries wasn't included in your GLFW Haskell > module installed. Did you do the last step by running install.bat or > install.sh instead of "runhaskell Setup install"? now it works! ... although I am unfortunately not able to reconstruct what I did to make it running. Thank you, Immanuel > > Regards, > Paul Liu > > On 10/2/07, Immanuel Normann wrote: > > Hello, > > > > I have just read the thread about "installation of GLUT package" started > > at 9/3/2007 by Ronald Guida. Installation of the GLFW package is very > > much related to that. However, I haven't found the solution for > > installing the GLFW successsfully. > > > > I have downloaded > > > > http://www.cs.yale.edu/homes/hl293/download/GLFW-20070804.zip > > > > and followed the compile and installation instructions from the > > README.txt file. Actually I haven't noticed any error messages. > > > > Then I tried SimpleGraphics from SOE (downloaded from > > http://www.cs.yale.edu/homes/hl293/download/SOE-20070830.zip) > > with ghci-6.6. Again loading the file did not raise any error. > > > > But when I tried to start > > > > main > > = runGraphics ( > > do w <- openWindow > > "My First Graphics Program" (300,300) > > drawInWindow w (text (100,200) "Hello Graphics World") > > k <- getKey w > > closeWindow w > > ) > > > > I got this error message: > > > > "During interactive linking, GHCi couldn't find the following symbol: > > GLFWzm0zi1_GraphicsziUIziGLFW_initializze_closure > > This may be due to you not asking GHCi to load extra object files, > > archives or DLLs needed by your current session. Restart GHCi, > > specifying > > the missing library using the -L/path/to/object/dir and -lmissinglibname > > flags, or simply by naming the relevant files on the GHCi command line. > > Alternatively, this link failure might indicate a bug in GHCi." > > > > Here I am lost. What is the missing library? > > > > Regards, > > Immanuel > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From stefanor at cox.net Tue Oct 2 17:32:38 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Oct 2 17:31:35 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <90889fe70710021405i6549f618s8f695111cd7e452d@mail.gmail.com> References: <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <20071002205315.GA3046@localhost.localdomain> <90889fe70710021405i6549f618s8f695111cd7e452d@mail.gmail.com> Message-ID: <20071002213238.GA3302@localhost.localdomain> On Tue, Oct 02, 2007 at 11:05:38PM +0200, Johan Tibell wrote: > > I do not believe that anyone was seriously advocating multiple blessed > > encodings. The main question is *which* encoding to bless. 99+% of > > text I encounter is in US-ASCII, so I would favor UTF-8. Why is UTF-16 > > better for me? > > All software I write professional have to support 40 languages > (including CJK ones) so I would prefer UTF-16 in case I could use > Haskell at work some day in the future. I dunno that who uses what > encoding the most is good grounds to pick encoding though. Ease of > implementation and speed on some representative sample set of text may > be. UTF-8 supports CJK languages too. The only question is efficiency, and I believe CJK is still a relatively uncommon case compared to English and other Latin-alphabet languages. (That said, I live in a country all of whose dominant languages use the Latin alphabet) Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20071002/08c6b412/attachment.bin From twanvl at gmail.com Tue Oct 2 18:01:50 2007 From: twanvl at gmail.com (Twan van Laarhoven) Date: Tue Oct 2 18:00:16 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> Message-ID: <4702BFCE.7060503@gmail.com> Lots of people wrote: > I want a UTF-8 bikeshed! > No, I want a UTF-16 bikeshed! What the heck does it matter what encoding the library uses internally? I expect the interface to be something like (from my own CompactString library): > fromByteString :: Encoding -> ByteString -> UnicodeString > toByteString :: Encoding -> UnicodeString -> ByteString The only matter is efficiency for a particular encoding. I would suggest that we get a working library first. Either UTF-8 or UTF-16 will do, as long as it works. Even better would be to implement both (and perhaps more encodings), and then benchmark them to get a sensible default. Then the choice can be made available to the user as well, in case someone has specifix needs. But again: get it working first! Twan From dgoldsmith at mac.com Tue Oct 2 18:04:29 2007 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Tue Oct 2 18:03:27 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <1191339892.5435.3.camel@jcchost> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <1191339892.5435.3.camel@jcchost> Message-ID: On Oct 2, 2007, at 8:44 AM, Jonathan Cast wrote: > I would like to, again, strongly argue against sacrificing > compatibility > with Linux/BSD/etc. for the sake of compatibility with OS X or > Windows. > FFI bindings have to convert data formats in any case; Haskell > shouldn't > gratuitously break Linux support (or make life harder on Linux) just > to > support proprietary operating systems better. > > Now, if /independent of the details of MacOS X/, UTF-16 is better > (objectively), it can be converted to anything by the FFI. But > doing it > the way Java or MacOS X or Win32 or anyone else does it, at the > expense > of Linux, I am strongly opposed to. No one is advocating that. Any Unicode support library needs to support exporting text as UTF-8 since it's so widely used. It's used on Mac OS X, too, in exactly the same contexts it would be used on Linux. However, UTF-8 is a poor choice for internal representation. On Oct 2, 2007, at 2:32 PM, Stefan O'Rear wrote: > UTF-8 supports CJK languages too. The only question is efficiency, > and > I believe CJK is still a relatively uncommon case compared to English > and other Latin-alphabet languages. (That said, I live in a country > all > of whose dominant languages use the Latin alphabet) First of all, non-Latin countries already represent a large fraction of computer usage and the computer market. It is not at all "relatively uncommon." Japan alone is a huge market. China is a huge market. Second, it's not just CJK, but anything that's not mostly ASCII. Russian, Greek, Thai, Arabic, Hebrew, etc. etc. etc. UTF-8 is intended for compatibility with existing software that expects multibyte encodings. It doesn't work well as an internal representation. Again, no one is saying a Unicode library shouldn't have full support for input and output of UTF-8 (and other encodings). If you want to process ASCII text and squeeze out every last ounce of performance, use byte strings. Unicode strings should be optimized for representing and processing human language text, a large share of which is not in the Latin alphabet. Remember, speakers of English and other Latin-alphabet languages are a minority in the world, though not in the computer-using world. Yet. Deborah From dgoldsmith at mac.com Tue Oct 2 18:20:00 2007 From: dgoldsmith at mac.com (Deborah Goldsmith) Date: Tue Oct 2 18:19:00 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <4702BFCE.7060503@gmail.com> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702BFCE.7060503@gmail.com> Message-ID: On Oct 2, 2007, at 3:01 PM, Twan van Laarhoven wrote: > Lots of people wrote: > > I want a UTF-8 bikeshed! > > No, I want a UTF-16 bikeshed! > > What the heck does it matter what encoding the library uses > internally? I expect the interface to be something like (from my own > CompactString library): > > fromByteString :: Encoding -> ByteString -> UnicodeString > > toByteString :: Encoding -> UnicodeString -> ByteString I agree, from an API perspective the internal encoding doesn't matter. > > The only matter is efficiency for a particular encoding. This matters a lot. > > > I would suggest that we get a working library first. Either UTF-8 or > UTF-16 will do, as long as it works. > > Even better would be to implement both (and perhaps more encodings), > and then benchmark them to get a sensible default. Then the choice > can be made available to the user as well, in case someone has > specifix needs. But again: get it working first! The problem is that the internal encoding can have a big effect on the implementation of the library. It's better not to have to do it over again if the first choice is not optimal. I'm just trying to share the experience of the Unicode Consortium, the ICU library contributors, and Apple, with the Haskell community. They, and I personally, have many years of experience implementing support for Unicode. Anyway, I think we're starting to repeat ourselves... Deborah From clawsie at fastmail.fm Tue Oct 2 18:55:00 2007 From: clawsie at fastmail.fm (brad clawsie) Date: Tue Oct 2 18:53:59 2007 Subject: [Haskell-cafe] build problems with hscurses Message-ID: <20071002225500.GC70506@jobbicycle.corp.yahoo.com> hoping someone here can help me with a build problem when going through the hackage "build" stage, i get numerous errors like: HSCurses/Curses.hs:XXXX:0: invalid preprocessing directive #def where XXXX ranges in lines from 1597 to 1621. is there a special directive i need for runhaskell? any info appreciated. (on freebsd6.2, ghc6.6.1, ncurses-5.6_1) From aeyakovenko at gmail.com Tue Oct 2 19:08:01 2007 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Tue Oct 2 19:07:01 2007 Subject: [Haskell-cafe] bizarre memory usage with data.binary Message-ID: i am getting some weird memory usage out of this program: module Main where import Data.Binary import Data.List(foldl') main = do let sum' = foldl' (+) 0 let list::[Int] = decode $ encode $ ([1..] :: [Int]) print $ sum' list print "done" it goes up to 500M and down to 17M on windows. Its build with ghc 6.6.1 with the latest data.binary Any ideas what could be causing the memory usage to jump around so much? Thanks, Anatoly From jonathanccast at fastmail.fm Tue Oct 2 19:11:01 2007 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Oct 2 19:10:03 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <4702BFCE.7060503@gmail.com> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702BFCE.7060503@gmail.com> Message-ID: <1191366661.5435.28.camel@jcchost> On Wed, 2007-10-03 at 00:01 +0200, Twan van Laarhoven wrote: > Lots of people wrote: > > I want a UTF-8 bikeshed! > > No, I want a UTF-16 bikeshed! > > What the heck does it matter what encoding the library uses internally? +1 jcc From vandijk.roel at gmail.com Tue Oct 2 19:22:25 2007 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Tue Oct 2 19:21:21 2007 Subject: [Haskell-cafe] bizarre memory usage with data.binary In-Reply-To: References: Message-ID: Does it terminate? Looks like you are summing all the natural numbers. On a turing machine it should run forever, on a real computer it should run out of memory. Unless I am missing something obvious :-) From stefanor at cox.net Tue Oct 2 19:25:42 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Oct 2 19:24:40 2007 Subject: [Haskell-cafe] bizarre memory usage with data.binary In-Reply-To: References: Message-ID: <20071002232542.GA3648@localhost.localdomain> On Wed, Oct 03, 2007 at 01:22:25AM +0200, Roel van Dijk wrote: > Does it terminate? > > Looks like you are summing all the natural numbers. On a turing > machine it should run forever, on a real computer it should run out > of memory. Unless I am missing something obvious :-) There are only about 4 billion distinct values of type Int, 2 billion of which are positive. Integer is required for bigger values Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20071002/73e4a66a/attachment.bin From stefanor at cox.net Tue Oct 2 19:27:04 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Oct 2 19:26:01 2007 Subject: [Haskell-cafe] bizarre memory usage with data.binary In-Reply-To: References: Message-ID: <20071002232704.GB3648@localhost.localdomain> On Tue, Oct 02, 2007 at 04:08:01PM -0700, Anatoly Yakovenko wrote: > i am getting some weird memory usage out of this program: > > > module Main where > > import Data.Binary > import Data.List(foldl') > > > main = do > let sum' = foldl' (+) 0 > let list::[Int] = decode $ encode $ ([1..] :: [Int]) > print $ sum' list > print "done" > > it goes up to 500M and down to 17M on windows. Its build with ghc > 6.6.1 with the latest data.binary > > Any ideas what could be causing the memory usage to jump around so much? Only 500M? encode for lists is strict, I would have expected around 80GB usage... What does -ddump-simpl-stats say? Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20071002/91c71ac1/attachment.bin From aeyakovenko at gmail.com Tue Oct 2 20:01:31 2007 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Tue Oct 2 20:00:32 2007 Subject: [Haskell-cafe] Re: bizarre memory usage with data.binary In-Reply-To: References: Message-ID: Program1: module Main where import Data.Binary import Data.List(foldl') main = do let sum' = foldl' (+) 0 let list::[Int] = decode $ encode $ ([1..] :: [Int]) print $ sum' list print "done" vs Program2: module Main where import Data.Binary import Data.List(foldl') main = do let sum' = foldl' (+) 0 let list::[Int] = [1..] print $ sum' list print "done" neither program is expected to terminate. The point of these examples is to demonstrate that Data.Binary encode and decode have some strange memory allocation patters. If you run Program1, it will run forever, but its memory usage on my machine goes to 500M then back down to 17M then back up to 500M then back down to 17M... repeatedly. I don't think this has anything to do with running out of space in a 32 bit integer. Program2 on the other hand runs at constant memory at around 2M. Anatoly On 10/2/07, Anatoly Yakovenko wrote: > i am getting some weird memory usage out of this program: > > > module Main where > > import Data.Binary > import Data.List(foldl') > > > main = do > let sum' = foldl' (+) 0 > let list::[Int] = decode $ encode $ ([1..] :: [Int]) > print $ sum' list > print "done" > > it goes up to 500M and down to 17M on windows. Its build with ghc > 6.6.1 with the latest data.binary > > Any ideas what could be causing the memory usage to jump around so much? > > > Thanks, > Anatoly > From dons at galois.com Tue Oct 2 20:04:17 2007 From: dons at galois.com (Don Stewart) Date: Tue Oct 2 20:03:16 2007 Subject: [Haskell-cafe] Re: bizarre memory usage with data.binary In-Reply-To: References: Message-ID: <20071003000417.GC15300@scytale.galois.com> aeyakovenko: > Program1: > > module Main where > > import Data.Binary > import Data.List(foldl') > > > main = do > let sum' = foldl' (+) 0 > let list::[Int] = decode $ encode $ ([1..] :: [Int]) > print $ sum' list > print "done" > > vs > > Program2: > > module Main where > > import Data.Binary > import Data.List(foldl') > > > main = do > let sum' = foldl' (+) 0 > let list::[Int] = [1..] > print $ sum' list > print "done" > > neither program is expected to terminate. The point of these examples > is to demonstrate that Data.Binary encode and decode have some strange > memory allocation patters. The encode instance for lists is fairly strict: instance Binary a => Binary [a] where put l = put (length l) >> mapM_ put l get = do n <- get :: Get Int replicateM n get This is ok, since typically you aren't serialising infinite structures. Use a newtype, and a lazier instance, if you need to do this. -- Don From westondan at imageworks.com Tue Oct 2 20:11:50 2007 From: westondan at imageworks.com (Dan Weston) Date: Tue Oct 2 20:10:57 2007 Subject: [Haskell-cafe] Re: bizarre memory usage with data.binary In-Reply-To: References: Message-ID: <4702DE46.1030205@imageworks.com> Maybe what you are observing is that the operational semantics of undefined is undefined. The program can halt, run forever, use no memory, use all the memory. Although I doubt what GHC does with this code is a random process, I don't think it's too meaningful to ask what are the space usage patterns of a program returning bottom. Anatoly Yakovenko wrote: > Program1: > > module Main where > > import Data.Binary > import Data.List(foldl') > > > main = do > let sum' = foldl' (+) 0 > let list::[Int] = decode $ encode $ ([1..] :: [Int]) > print $ sum' list > print "done" > > vs > > Program2: > > module Main where > > import Data.Binary > import Data.List(foldl') > > > main = do > let sum' = foldl' (+) 0 > let list::[Int] = [1..] > print $ sum' list > print "done" > > neither program is expected to terminate. The point of these examples > is to demonstrate that Data.Binary encode and decode have some strange > memory allocation patters. > > If you run Program1, it will run forever, but its memory usage on my > machine goes to 500M then back down to 17M then back up to 500M then > back down to 17M... repeatedly. I don't think this has anything to do > with running out of space in a 32 bit integer. > > Program2 on the other hand runs at constant memory at around 2M. > > Anatoly > > On 10/2/07, Anatoly Yakovenko wrote: >> i am getting some weird memory usage out of this program: >> >> >> module Main where >> >> import Data.Binary >> import Data.List(foldl') >> >> >> main = do >> let sum' = foldl' (+) 0 >> let list::[Int] = decode $ encode $ ([1..] :: [Int]) >> print $ sum' list >> print "done" >> >> it goes up to 500M and down to 17M on windows. Its build with ghc >> 6.6.1 with the latest data.binary >> >> Any ideas what could be causing the memory usage to jump around so much? >> >> >> Thanks, >> Anatoly >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From aeyakovenko at gmail.com Tue Oct 2 20:32:05 2007 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Tue Oct 2 20:31:02 2007 Subject: [Haskell-cafe] Re: bizarre memory usage with data.binary In-Reply-To: <20071003000417.GC15300@scytale.galois.com> References: <20071003000417.GC15300@scytale.galois.com> Message-ID: On 10/2/07, Don Stewart wrote: > aeyakovenko: > > Program1: > > > > module Main where > > > > import Data.Binary > > import Data.List(foldl') > > > > > > main = do > > let sum' = foldl' (+) 0 > > let list::[Int] = decode $ encode $ ([1..] :: [Int]) > > print $ sum' list > > print "done" > The encode instance for lists is fairly strict: > > instance Binary a => Binary [a] where > put l = put (length l) >> mapM_ put l > get = do n <- get :: Get Int > replicateM n get > > This is ok, since typically you aren't serialising infinite structures. hmm, this doesn't make sense to me, it goes up to 500M then down then back up, then back down, so it doesn't just run out of memory because of (length l) forces you to evaluate the entire list. > Use a newtype, and a lazier instance, if you need to do this. Thanks for the tip. this runs at a constant 4M module Main where import Data.Binary import Data.List(foldl') data Foo = Foo Int Foo | Null instance Binary Foo where put (Foo i f) = do put (0 :: Word8) put i put f put (Null) = do put (1 :: Word8) get = do t <- get :: Get Word8 case t of 0 -> do i <- get f <- get return (Foo i f) 1 -> do return Null sumFoo zz (Null) = zz sumFoo zz (Foo ii ff) = sumFoo (zz + ii) ff fooBar i = Foo i (fooBar (i + 1)) main = do print $ sumFoo 0 $ decode $ encode $ fooBar 1 print "done" From aeyakovenko at gmail.com Tue Oct 2 20:35:59 2007 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Tue Oct 2 20:34:54 2007 Subject: [Haskell-cafe] Re: bizarre memory usage with data.binary In-Reply-To: <4702DE46.1030205@imageworks.com> References: <4702DE46.1030205@imageworks.com> Message-ID: servers never terminate, pretend that i have a server that reads a list encoded with data.binary from a socket, and sums it up and returns the current sum. i would expect it to run in constant memory, never terminate, and do useful work. which is basically the problem that I am facing right now. my program seems to grow randomly in memory use when marshaling large data types encoded using data.binary. On 10/2/07, Dan Weston wrote: > Maybe what you are observing is that the operational semantics of > undefined is undefined. The program can halt, run forever, use no > memory, use all the memory. > > Although I doubt what GHC does with this code is a random process, I > don't think it's too meaningful to ask what are the space usage patterns > of a program returning bottom. > > Anatoly Yakovenko wrote: > > Program1: > > > > module Main where > > > > import Data.Binary > > import Data.List(foldl') > > > > > > main = do > > let sum' = foldl' (+) 0 > > let list::[Int] = decode $ encode $ ([1..] :: [Int]) > > print $ sum' list > > print "done" > > > > vs > > > > Program2: > > > > module Main where > > > > import Data.Binary > > import Data.List(foldl') > > > > > > main = do > > let sum' = foldl' (+) 0 > > let list::[Int] = [1..] > > print $ sum' list > > print "done" > > > > neither program is expected to terminate. The point of these examples > > is to demonstrate that Data.Binary encode and decode have some strange > > memory allocation patters. > > > > If you run Program1, it will run forever, but its memory usage on my > > machine goes to 500M then back down to 17M then back up to 500M then > > back down to 17M... repeatedly. I don't think this has anything to do > > with running out of space in a 32 bit integer. > > > > Program2 on the other hand runs at constant memory at around 2M. > > > > Anatoly > > > > On 10/2/07, Anatoly Yakovenko wrote: > >> i am getting some weird memory usage out of this program: > >> > >> > >> module Main where > >> > >> import Data.Binary > >> import Data.List(foldl') > >> > >> > >> main = do > >> let sum' = foldl' (+) 0 > >> let list::[Int] = decode $ encode $ ([1..] :: [Int]) > >> print $ sum' list > >> print "done" > >> > >> it goes up to 500M and down to 17M on windows. Its build with ghc > >> 6.6.1 with the latest data.binary > >> > >> Any ideas what could be causing the memory usage to jump around so much? > >> > >> > >> Thanks, > >> Anatoly > >> > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > From felipe.lessa at gmail.com Tue Oct 2 20:37:53 2007 From: felipe.lessa at gmail.com (Felipe Almeida Lessa) Date: Tue Oct 2 20:36:49 2007 Subject: [Haskell-cafe] Re: bizarre memory usage with data.binary In-Reply-To: <20071003000417.GC15300@scytale.galois.com> References: <20071003000417.GC15300@scytale.galois.com> Message-ID: On 10/2/07, Don Stewart wrote: > The encode instance for lists is fairly strict: > > instance Binary a => Binary [a] where > put l = put (length l) >> mapM_ put l > get = do n <- get :: Get Int > replicateM n get > > This is ok, since typically you aren't serialising infinite structures. > > Use a newtype, and a lazier instance, if you need to do this. Maybe something like this (WARNING: ugly code, as in "not elegant", follows): newtype List a = List [a] split255 :: [a] -> (Word8, [a], [a]) split255 = s 0 where s 255 xs = (255, [], xs) s n (x:xs) = let (n', ys, zs) = s (n+1) xs in (n', x:ys, zs) s n [] = (n, [], []) instance Binary a => Binary (List a) where put (List l) = let (n, xs, ys) = split255 l in do putWord8 n mapM_ put xs when (n == 255) (put $ List ys) get = do n <- getWord8 xs <- replicateM (fromEnum n) get if n == 255 then get >>= \(List ys) -> return (List $ xs ++ ys) else return (List xs) It uses chunks of 255 elements and so doesn't traverse the whole list until starting to output something. OTOH, there's some data overhead (1 byte every 255 elements). Seems to run your example fine and in constant memory. HTH, -- Felipe. From dons at galois.com Tue Oct 2 20:38:01 2007 From: dons at galois.com (Don Stewart) Date: Tue Oct 2 20:37:03 2007 Subject: [Haskell-cafe] Re: bizarre memory usage with data.binary In-Reply-To: References: <4702DE46.1030205@imageworks.com> Message-ID: <20071003003801.GF15300@scytale.galois.com> aeyakovenko: > servers never terminate, pretend that i have a server that reads a > list encoded with data.binary from a socket, and sums it up and > returns the current sum. i would expect it to run in constant memory, > never terminate, and do useful work. > > which is basically the problem that I am facing right now. my program > seems to grow randomly in memory use when marshaling large data types > encoded using data.binary. If its specifically the list instance, where we currently trade laziness for efficiency of encoding (which may or may not be the right thing), I'd suggest a fully lazy encoding instance? -- Don From prstanley at ntlworld.com Tue Oct 2 20:42:41 2007 From: prstanley at ntlworld.com (PR Stanley) Date: Tue Oct 2 20:41:51 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <22fcbd520710011433k562a67f3q3a9c5259be1f0103@mail.gmail.co m> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> <20071001211849.705415c9@aligatoro.ret> <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> <22fcbd520710011433k562a67f3q3a9c5259be1f0103@mail.gmail.com> Message-ID: <7.0.1.0.0.20071003013146.01b6d8a8@ntlworld.com> > > > f x = x + x > > > Is the "x" use to create a pattern in the definition and when f is > > > called it's replaced by a value? > > > >Those equation-like definitions are syntactic sugar for lambda > >abstractions. f could as well be defined as f = \x -> x + x. > >Please elaborate > > >First, the > >f x = > >part says that f is a function which takes a single parameter, >called x. The other side of the = sign gives the function body: in >this case, x + x. This is exactly the same thing that is expressed >by the lambda expression > >\x -> x + x > >This expression defines a function that takes a single parameter >called x, and returns the value of x + x. The only difference is >that with the lambda expression, this function is not given a >name. But you can easily give the function a name (just as you can >give any Haskell expression a name) by writing > >f = \x -> x + x > >In general, writing > >g x y z = blah blah > >is just a shorthand for > >g = \x -> \y -> \z -> blah blah. > >That is, it simultaneously creates a function expression, and >assigns it a name. > >Does that help? Yes and thanks for the reply. When a function is declared in C the argument variable has an address somewhere in the memory: int f ( int x ) { return x * x; } any value passed to f() is assigned to x. x is the identifier for a real slot in the memory (the stack most likely) made available for f(). Is this also what happens in Haskell? Thanks, Paul From aeyakovenko at gmail.com Tue Oct 2 20:51:47 2007 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Tue Oct 2 20:50:42 2007 Subject: [Haskell-cafe] Re: bizarre memory usage with data.binary In-Reply-To: <20071003003801.GF15300@scytale.galois.com> References: <4702DE46.1030205@imageworks.com> <20071003003801.GF15300@scytale.galois.com> Message-ID: > If its specifically the list instance, where we currently trade laziness > for efficiency of encoding (which may or may not be the right thing), > I'd suggest a fully lazy encoding instance? Its not really a list, its more of a tree that has shared nodes, so something like this: A / \ B C \ / D / \ E F I suspect that maybe after encode/decode i end up with something like A / \ B C / \ D D / \ / \ E F E F From derek.a.elkins at gmail.com Tue Oct 2 21:02:31 2007 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Tue Oct 2 21:01:37 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <7.0.1.0.0.20071003013146.01b6d8a8@ntlworld.com> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> <20071001211849.705415c9@aligatoro.ret> <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> <22fcbd520710011433k562a67f3q3a9c5259be1f0103@mail.gmail.com> <7.0.1.0.0.20071003013146.01b6d8a8@ntlworld.com> Message-ID: <1191373351.5481.71.camel@derek-laptop> On Wed, 2007-10-03 at 01:42 +0100, PR Stanley wrote: > > > > f x = x + x > > > > Is the "x" use to create a pattern in the definition and when f is > > > > called it's replaced by a value? > > > > > >Those equation-like definitions are syntactic sugar for lambda > > >abstractions. f could as well be defined as f = \x -> x + x. > > > >Please elaborate > > > > > >First, the > > > >f x = > > > >part says that f is a function which takes a single parameter, > >called x. The other side of the = sign gives the function body: in > >this case, x + x. This is exactly the same thing that is expressed > >by the lambda expression > > > >\x -> x + x > > > >This expression defines a function that takes a single parameter > >called x, and returns the value of x + x. The only difference is > >that with the lambda expression, this function is not given a > >name. But you can easily give the function a name (just as you can > >give any Haskell expression a name) by writing > > > >f = \x -> x + x > > > >In general, writing > > > >g x y z = blah blah > > > >is just a shorthand for > > > >g = \x -> \y -> \z -> blah blah. > > > >That is, it simultaneously creates a function expression, and > >assigns it a name. > > > >Does that help? > > Yes and thanks for the reply. > When a function is declared in C the argument variable has an address > somewhere in the memory: > int f ( int x ) { > return x * x; > } > > any value passed to f() is assigned to x. x is the identifier for a > real slot in the memory (the stack most likely) made available for f(). > Is this also what happens in Haskell? How would you tell? From isaacdupree at charter.net Tue Oct 2 21:12:00 2007 From: isaacdupree at charter.net (Isaac Dupree) Date: Tue Oct 2 21:11:11 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <20071002213238.GA3302@localhost.localdomain> References: <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <20071002205315.GA3046@localhost.localdomain> <90889fe70710021405i6549f618s8f695111cd7e452d@mail.gmail.com> <20071002213238.GA3302@localhost.localdomain> Message-ID: <4702EC60.2010306@charter.net> Stefan O'Rear wrote: > On Tue, Oct 02, 2007 at 11:05:38PM +0200, Johan Tibell wrote: >>> I do not believe that anyone was seriously advocating multiple blessed >>> encodings. The main question is *which* encoding to bless. 99+% of >>> text I encounter is in US-ASCII, so I would favor UTF-8. Why is UTF-16 >>> better for me? >> All software I write professional have to support 40 languages >> (including CJK ones) so I would prefer UTF-16 in case I could use >> Haskell at work some day in the future. I dunno that who uses what >> encoding the most is good grounds to pick encoding though. Ease of >> implementation and speed on some representative sample set of text may >> be. > > UTF-8 supports CJK languages too. The only question is efficiency Due to the additional complexity of handling UTF-8 -- EVEN IF the actual text processed happens all to be US-ASCII -- will UTF-8 perhaps be less efficient than UTF-16, or only as fast? Isaac From allbery at ece.cmu.edu Tue Oct 2 21:45:59 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Oct 2 21:44:57 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <4702EC60.2010306@charter.net> References: <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <20071002205315.GA3046@localhost.localdomain> <90889fe70710021405i6549f618s8f695111cd7e452d@mail.gmail.com> <20071002213238.GA3302@localhost.localdomain> <4702EC60.2010306@charter.net> Message-ID: <93621F36-3B76-4095-8AF6-8D20C34D1D7E@ece.cmu.edu> On Oct 2, 2007, at 21:12 , Isaac Dupree wrote: > Stefan O'Rear wrote: >> On Tue, Oct 02, 2007 at 11:05:38PM +0200, Johan Tibell wrote: >>>> I do not believe that anyone was seriously advocating multiple >>>> blessed >>>> encodings. The main question is *which* encoding to bless. 99+ >>>> % of >>>> text I encounter is in US-ASCII, so I would favor UTF-8. Why is >>>> UTF-16 >>>> better for me? >>> All software I write professional have to support 40 languages >>> (including CJK ones) so I would prefer UTF-16 in case I could use >>> Haskell at work some day in the future. I dunno that who uses what >>> encoding the most is good grounds to pick encoding though. Ease of >>> implementation and speed on some representative sample set of >>> text may >>> be. >> UTF-8 supports CJK languages too. The only question is efficiency > > Due to the additional complexity of handling UTF-8 -- EVEN IF the > actual text processed happens all to be US-ASCII -- will UTF-8 > perhaps be less efficient than UTF-16, or only as fast? UTF8 will be very slightly faster in the all-ASCII case, but quickly blows chunks if you have *any* characters that require multibyte. Given the way UTF8 encoding works, this includes even Latin-1 non- ASCII, never mind CJK. (I think people have been missing that point. UTF8 is only cheap for 00-7f, *nothing else*.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From ok at cs.otago.ac.nz Tue Oct 2 22:27:42 2007 From: ok at cs.otago.ac.nz (ok) Date: Tue Oct 2 22:26:40 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <7.0.1.0.0.20071003013146.01b6d8a8@ntlworld.com> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> <20071001211849.705415c9@aligatoro.ret> <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> <22fcbd520710011433k562a67f3q3a9c5259be1f0103@mail.gmail.com> <7.0.1.0.0.20071003013146.01b6d8a8@ntlworld.com> Message-ID: <9EEAFC11-8449-46BC-A5D7-BFD4AA4A3A93@cs.otago.ac.nz> On 3 Oct 2007, at 1:42 pm, PR Stanley wrote: > When a function is declared in C the argument variable has an > address somewhere in the memory: > int f ( int x ) { > return x * x; > } Wrong. On the machines I use, x will be passed in registers and will never ever have an address in memory. In fact, unless I hold the Sun C compiler back by main force, it will probably open code f() so that there isn't any f any more, let alone any x. Here's the actual SPARC code generated for f: f: retl mulx %o0,%o0,%o0 No memory, no address. In C, a function call is rather like entering a new block, declaring some new variables (which might or might not ever go into memory) and initialising them to the values of the arguments. In Haskell, carrying out a function call is rather like creating some new names and *binding* them to promises to evaluate the arguments (if they are ever needed) and then returning a promise to evaluate the body (if it is ever needed). The key point is *binding* names to (deferred calculations of) values, rather than *initialising* mutable variables to (fully evaluated) values. How this is done is entirely up to the compiler. From clawsie at fastmail.fm Tue Oct 2 22:39:54 2007 From: clawsie at fastmail.fm (brad clawsie) Date: Tue Oct 2 22:38:50 2007 Subject: [Haskell-cafe] build problems with hscurses In-Reply-To: <20071002225500.GC70506@jobbicycle.corp.yahoo.com> References: <20071002225500.GC70506@jobbicycle.corp.yahoo.com> Message-ID: <20071003023954.GB1051@localhost.gateway.2wire.net> i solved this myself - for the sake of documenting the solution, i obtained the darcs version with darcs get --set-scripts-executable http://www.stefanwehr.de/darcs/hscurses/ and then a standard hackage install and i think the "--set-scripts-executable" in this case is significant On Tue, Oct 02, 2007 at 03:55:00PM -0700, brad clawsie wrote: > hoping someone here can help me with a build problem > > when going through the hackage "build" stage, i get numerous errors > like: > > HSCurses/Curses.hs:XXXX:0: invalid preprocessing directive #def > > where XXXX ranges in lines from 1597 to 1621. > > is there a special directive i need for runhaskell? any info > appreciated. > > (on freebsd6.2, ghc6.6.1, ncurses-5.6_1) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ketil at ii.uib.no Wed Oct 3 02:27:02 2007 From: ketil at ii.uib.no (Ketil Malde) Date: Wed Oct 3 02:25:57 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <20071002213238.GA3302@localhost.localdomain> References: <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <20071002205315.GA3046@localhost.localdomain> <90889fe70710021405i6549f618s8f695111cd7e452d@mail.gmail.com> <20071002213238.GA3302@localhost.localdomain> Message-ID: <1191392823.6149.81.camel@nmd9999> On Tue, 2007-10-02 at 14:32 -0700, Stefan O'Rear wrote: > UTF-8 supports CJK languages too. The only question is efficiency, and > I believe CJK is still a relatively uncommon case compared to English > and other Latin-alphabet languages. (That said, I live in a country all > of whose dominant languages use the Latin alphabet) As for space efficiency, I guess the argument could be made that since an ideogram typically conveys a whole word, it is reasonably to spend more bits for it. Anyway, I am unsure if I should take part in this discussion, as I'm not really dealing with text as such in multiple languages. Most of my data is in ASCII, and when they are not, I'm happy to treat it ("treat" here meaning "mostly ignore") as Latin1 bytes (current ByteString) or UTF-8. The only thing I miss is the ability to use String syntactic sugar -- but IIUC, that's coming? However, increased space usage is not acceptable, and I also don't want any conversion layer which could conceivably modify my data (e.g. by normalizing or error handling). -k From ketil at ii.uib.no Wed Oct 3 02:30:13 2007 From: ketil at ii.uib.no (Ketil Malde) Date: Wed Oct 3 02:29:07 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <93621F36-3B76-4095-8AF6-8D20C34D1D7E@ece.cmu.edu> References: <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702358A.8010003@list.mightyreason.com> <6D420F14-F898-4DB8-BEB0-B50BAE2882F4@mac.com> <20071002205315.GA3046@localhost.localdomain> <90889fe70710021405i6549f618s8f695111cd7e452d@mail.gmail.com> <20071002213238.GA3302@localhost.localdomain> <4702EC60.2010306@charter.net> <93621F36-3B76-4095-8AF6-8D20C34D1D7E@ece.cmu.edu> Message-ID: <1191393013.6149.86.camel@nmd9999> On Tue, 2007-10-02 at 21:45 -0400, Brandon S. Allbery KF8NH wrote: > > Due to the additional complexity of handling UTF-8 -- EVEN IF the > > actual text processed happens all to be US-ASCII -- will UTF-8 > > perhaps be less efficient than UTF-16, or only as fast? > UTF8 will be very slightly faster in the all-ASCII case, but quickly > blows chunks if you have *any* characters that require multibyte. What benchmarks are you basing this on? Doubling your data size is going to cost you if you are doing simple operations (searching, say), but I don't see UTF-8 being particularly expensive - somebody (forget who) implemented UTF-8 on top of ByteString, and IIRC, the benchmarks numbers didn't change all that much from the regular Char8. -k From tittoassini at gmail.com Wed Oct 3 04:42:42 2007 From: tittoassini at gmail.com (Pasqualino 'Titto' Assini) Date: Wed Oct 3 04:41:46 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec Message-ID: <200710030942.42563.tittoassini@gmail.com> Hi Alex, I hope not to spoil your fun but have you had a look at this: Write Yourself a Scheme in 48 Hours http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutorial/overview.html Regards, titto From jules at jellybean.co.uk Wed Oct 3 07:09:08 2007 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Oct 3 07:08:03 2007 Subject: [Haskell-cafe] Assignment, Substitution or what? In-Reply-To: <7.0.1.0.0.20071003013146.01b6d8a8@ntlworld.com> References: <7.0.1.0.0.20071001194932.01b6cde8@ntlworld.com> <20071001211849.705415c9@aligatoro.ret> <7.0.1.0.0.20071001214224.01b83c90@ntlworld.com> <22fcbd520710011433k562a67f3q3a9c5259be1f0103@mail.gmail.com> <7.0.1.0.0.20071003013146.01b6d8a8@ntlworld.com> Message-ID: <47037854.9000409@jellybean.co.uk> PR Stanley wrote: > Yes and thanks for the reply. > When a function is declared in C the argument variable has an address > somewhere in the memory: > int f ( int x ) { > return x * x; > } > > any value passed to f() is assigned to x. x is the identifier for a real > slot in the memory (the stack most likely) made available for f(). > Is this also what happens in Haskell? It is not, in my opinion, an unreasonable intuition. What's interesting to note is that because haskell values are immutable, there is no need for this to be a *new* memory location. In fact, in a typical simple haskell implementation what f is actually passed is a pointer to to the existing memory location. Procedure call in haskell doesn't normally involve argument copying, because with immutability there is no need for copying. Of course 'x*x' is a new value, so new memory is definitely allocated for that. The next epiphany of understanding is when you realise that what actually goes into that new memory is a code pointer, rather than a value. Instead of calculating 'x*x' the compiler simply chucks a pointer to the code which, when called, will calculate x*x. This code is only called if needed. Jules From bf3 at telenet.be Wed Oct 3 07:31:47 2007 From: bf3 at telenet.be (Peter Verswyvelen) Date: Wed Oct 3 07:30:39 2007 Subject: [Haskell-cafe] GLFW for WinHugs Message-ID: <000001c805b0$fbe5e630$f3b1b290$@be> The latest version of SOE comes with a wrapper for a nice GLFW library. This library comes with a demo of a 3D bouncing "Amiga" ball so it must be the best library in the world ;-) ;-) Since I'm letting my students play with WinHugs, I would prefer to have a WinHugs compatible version of that library. I tried to convert it, but I got stuck when ffihugs complained about not finding RTS.h, which seems to be a GHC-only include file. Would it be possible to convert this library to WinHugs? I guess similar work has been done for other libraries, so any hints are welcome. Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071003/463b9fd0/attachment.htm From prstanley at ntlworld.com Wed Oct 3 07:55:27 2007 From: prstanley at ntlworld.com (PR Stanley) Date: Wed Oct 3 07:54:17 2007 Subject: [Haskell-cafe] Curry and uncurry Message-ID: <7.0.1.0.0.20071003125457.01b1f020@ntlworld.com> Hi The following is from the Hutton book: Without looking at the standard prelude, define the higher-order library function curry that converts a function on pairs into a curried function, and conversely, the function uncurry that converts a curried function with two arguments into a function on pairs. Hint: first write down the types of the two functions. I didn't even know about the curry and uncurry functions. I'm not looking for the answer but some guidance would be much appreciated. Thanks, Paul From asandroq at gmail.com Wed Oct 3 08:12:32 2007 From: asandroq at gmail.com (Alex Queiroz) Date: Wed Oct 3 08:11:27 2007 Subject: [Haskell-cafe] Parsing R5RS Scheme with Parsec In-Reply-To: <200710030942.42563.tittoassini@gmail.com> References: <200710030942.42563.tittoassini@gmail.com> Message-ID: <54e12800710030512g6881e940x38fc176972c01271@mail.gmail.com> Hallo, On 10/3/07, Pasqualino 'Titto' Assini wrote: > Hi Alex, > > I hope not to spoil your fun but have you had a look at this: > > Write Yourself a Scheme in 48 Hours > http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutorial/overview.html > Yes, I'm actually using it as a basis. But it doesn't parse the whole R5RS grammar. Cheers, -- -alex http://www.ventonegro.org/ From bortzmeyer at nic.fr Wed Oct 3 08:15:31 2007 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed Oct 3 08:14:25 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <4702BFCE.7060503@gmail.com> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702BFCE.7060503@gmail.com> Message-ID: <20071003121531.GA20119@nic.fr> On Wed, Oct 03, 2007 at 12:01:50AM +0200, Twan van Laarhoven wrote a message of 24 lines which said: > Lots of people wrote: > > I want a UTF-8 bikeshed! > > No, I want a UTF-16 bikeshed! Personnally, I want an UTF-32 bikeshed. UTF-16 is as lousy as UTF-8 (for both of them, characters have different sizes, unlike what happens in UTF-32). > What the heck does it matter what encoding the library uses > internally? +1 It can even use a non-standard encoding scheme if it wants. From scook0 at gmail.com Wed Oct 3 08:31:48 2007 From: scook0 at gmail.com (Stuart Cook) Date: Wed Oct 3 08:30:43 2007 Subject: [Haskell-cafe] Curry and uncurry In-Reply-To: <7.0.1.0.0.20071003125457.01b1f020@ntlworld.com> References: <7.0.1.0.0.20071003125457.01b1f020@ntlworld.com> Message-ID: <49b351060710030531q66e63ae9qd2f1896382235a8c@mail.gmail.com> On 10/3/07, PR Stanley wrote: > Without looking at the standard prelude, define the > higher-order library function curry that converts a function > on pairs into a curried > function, and conversely, the function uncurry > that converts a curried > function with two arguments into a function on pairs. In other words, take a function like[1] add a b = a + b and make the following possible: (uncurry add) (2, 3) Conversely, take a function like sub' (a, b) = a - b and make the following possible: (curry sub') 4 1 > Hint: first write down the types of the two functions. This, I think, is the key part, and it's a useful technique for Haskell in general. First, write down the (general) type of a curried function, and the type of the corresponding uncurried function. Use those types to figure out what types curry and uncurry should have. Once you've done that, the implementation (which is pretty straightforward) should reveal itself. Stuart [1] I realise that add is just (+), and sub' is just (uncurry (-)), and some of my parens are unnecessary; I've written it this way to make the point of the exercise clearer. From johan.tibell at gmail.com Wed Oct 3 08:50:23 2007 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Oct 3 08:49:20 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <20071003121531.GA20119@nic.fr> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702BFCE.7060503@gmail.com> <20071003121531.GA20119@nic.fr> Message-ID: <90889fe70710030550j446337e7s6fef27dba597ca26@mail.gmail.com> > > What the heck does it matter what encoding the library uses > > internally? > > +1 It can even use a non-standard encoding scheme if it wants. Sounds good to me. I (think) one of my initial questions was if the encoding should be visible in the type of the UnicodeString type or not. My gut feeling is that having the type visible might make it hard to change the internal representation but I haven't yet got a good example to prove this. -- Johan From derek.a.elkins at gmail.com Wed Oct 3 08:56:18 2007 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Oct 3 08:55:24 2007 Subject: [Haskell-cafe] Curry and uncurry In-Reply-To: <49b351060710030531q66e63ae9qd2f1896382235a8c@mail.gmail.com> References: <7.0.1.0.0.20071003125457.01b1f020@ntlworld.com> <49b351060710030531q66e63ae9qd2f1896382235a8c@mail.gmail.com> Message-ID: <1191416178.5481.75.camel@derek-laptop> On Wed, 2007-10-03 at 22:31 +1000, Stuart Cook wrote: > On 10/3/07, PR Stanley wrote: > > Without looking at the standard prelude, define the > > higher-order library function curry that converts a function > > on pairs into a curried > > function, and conversely, the function uncurry > > that converts a curried > > function with two arguments into a function on pairs. > > In other words, take a function like[1] > > add a b = a + b > > and make the following possible: > > (uncurry add) (2, 3) > > Conversely, take a function like > > sub' (a, b) = a - b > > and make the following possible: > > (curry sub') 4 1 > > > > Hint: first write down the types of the two functions. > > This, I think, is the key part, and it's a useful technique for > Haskell in general. > > First, write down the (general) type of a curried function, and the > type of the corresponding uncurried function. Use those types to > figure out what types curry and uncurry should have. Once you've done > that, the implementation (which is pretty straightforward) should > reveal itself. Indeed, modulo bottom, the implementation of these functions is -completely- determined by the types. Djinn, for example, can automatically generate the implementations from the types. From jules at jellybean.co.uk Wed Oct 3 09:08:43 2007 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Oct 3 09:07:37 2007 Subject: [Haskell-cafe] "with" and "preserving" for local state Message-ID: <4703945B.4080403@jellybean.co.uk> Lots of external libraries contain state, but one that really contains a *lot* of state is the OpenGL libraries, since OpenGL is specified as a statemachine. This means that when you're writing structured code you quite often want to save and restore chunks of state 'automatically'. For the very most common case (coordinate transformations) Sven gives us 'preservingMatrix' which is extremely handy. Unless I've missed something there's no similar API for saving/restoring arbitrary state variables. It's not hard to write: > {-# OPTIONS -fglasgow-exts #-} > import Graphics.Rendering.OpenGL > import Graphics.UI.GLUT > > preserving :: (HasSetter g, HasGetter g) => g a -> IO t -> IO t > preserving var act = do old <- get var > ret <- act > var $= old > return ret This enables us to write preserving lighting $ do ..... Note that, since IORef is an instance of HasGetter and HasSetter, you can do 'preserving' on any old IORef, not just an openGL StateVar. Also note that the 'makeStateVar' interface that Graphics.Rendering.OpenGL.GL.StateVar exports allows you to make a statevar out of any appropriate action pair (not entirely unrelated to http://twan.home.fmf.nl/blog/haskell/overloading-functional-references.details) Sometimes you don't only want to preserve a value, but set a specific temporary value, so: > with :: (HasSetter g, HasGetter g) => g a -> a -> IO t -> IO t > with var val act = do old <- get var > var $= val > ret <- act > var $= old > return ret with lighting Enabled $ do .... (of course, with could be written as with var val act = preserving var $ var $= val >> act ) But this gets really clumsy if you have multiple variables to save/restore, which is really what lead me to write this message in the first place. A cute syntax for doing multiple save/restores at once is given by an existential: > data TemporaryValue = forall a g. > (HasGetter g,HasSetter g) => > g a := a > > with' :: [TemporaryValue] -> IO t -> IO t > with' tvs act = do olds <- mapM (\(a := b) -> do old <- get a > return (a := old)) > tvs > ret <- act > mapM_ (\(a := b) -> a $= b) tvs > return ret so we can then write: with' [lighting := Enabled, currentColor := Color4 1 0 1 0] $ do ... and have a type safe list of temporary assignments passed as an argument. And, amazingly, you get decent error messages too: *Main> :t with' [lighting := Enabled, currentColor := Color4 1 0 1 0] with' [lighting := Enabled, currentColor := Color4 1 0 1 0] :: IO t -> IO t *Main> :t with' [lighting := Enabled, currentColor := "Foo"] :1:44: Couldn't match expected type `Color4 GLfloat' against inferred type `[Char]' In the second argument of `(:=)', namely `"Foo"' In the expression: currentColor := "Foo" In the first argument of `with'', namely `[lighting := Enabled, currentColor := "Foo"]' Hope someone else finds that useful, Jules From bf3 at telenet.be Wed Oct 3 10:23:50 2007 From: bf3 at telenet.be (Peter Verswyvelen) Date: Wed Oct 3 10:22:57 2007 Subject: [Haskell-cafe] Hugs, dotnet, C#... Message-ID: <4703A5F6.3090509@telenet.be> In the (Win)Hugs documentation, I found "Only the ccall, stdcall and *dotnet *calling conventions are supported. All others are flagged as errors." However, I fail to find any more information on how to invoke dotnet methods. This might be really handy for me, as I'm very familiar with the dotnet framework. For example, yesterday I rewrote and extended a program that I wanted to develop in Haskell in just 3 hours using dotnet, while I spend weeks trying do this in Haskell. Of course, I'm a Haskell newbie and a dotnet expert, so this is not a fair comparison. However, I got a strange feeling, which I want to share with you :) First of all, it was a *horrible* experience to program C# again; I needed to type at least 3 times the amount of code, much of which was boilerplate code, and the code is not elegant. Haskell really changed my point of view on this; before I knew Haskell, I found C# (I'm talking C# 3.0 here) a really neat and nice language. On the other hand, the great Visual Studio IDE and Resharper addin made it at least 3 times faster to type, navigate, refactor, and debug the code... Somehow, I get things done really really really fast in C#, albeit in an "ugly" way. Once again, I just wish Haskell had such an IDE... And yes, I know of the existance of Visual Haskell, EclipseFP, Haskell Mode for Emacs (which I'm using), VIM, YI, but still, these do not compare with the experience I have when using Visual Studio/Resharper (or Eclipse or IntelliJ/IDEA for Java). But that might just be me of course... A slightly frustrated Peter ;-) BTW: I don't want to bring up the IDE discussion again, no really ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071003/4b3740d5/attachment.htm From jonathanccast at fastmail.fm Wed Oct 3 11:55:45 2007 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Oct 3 11:54:59 2007 Subject: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library. In-Reply-To: <20071003121531.GA20119@nic.fr> References: <90889fe70709241552tb726963he527bb63ea01d14@mail.gmail.com> <9D6C85E6-609A-4BC2-8144-A5A55812EBCD@mac.com> <113A8330-B792-47BF-AAF2-783FFC42D81C@mac.com> <4702BFCE.7060503@gmail.com> <20071003121531.GA20119@nic.fr> Message-ID: <1191426945.5435.30.camel@jcchost> On Wed, 2007-10-03 at 14:15 +0200, Stephane Bortzmeyer wrote: > On Wed, Oct 03, 2007 at 12:01:50AM +0200, > Twan van Laarhoven wrote > a message of 24 lines which said: > > > Lots of people wrote: > > > I want a UTF-8 bikeshed! > > > No, I want a UTF-16 bikeshed! > > Personnally, I want an UTF-32 bikeshed. UTF-16 is as lousy as UTF-8 > (for both of them, characters have different sizes, unlike what > happens in UTF-32). +1 > > What the heck does it matter what encoding the library uses > > internally? > > +1 It can even use a non-standard encoding scheme if it wants. +3 jcc From mux at FreeBSD.org Wed Oct 3 11:57:58 2007 From: mux at FreeBSD.org (Maxime Henrion) Date: Wed Oct 3 11:56:52 2007 Subject: [Haskell-cafe] Haskell FFI and finalizers Message-ID: <20071003155758.GA94069@elvis.mu.org> Hello all, I have recently developed a small set of bindings for a C library, and encountered a problem that I think could be interesting to others. My problem was that the C function I was writing bindings to expects to be passed a FILE *. So, I had basically two possibles routes to take: 1) Mimic the C API and have the haskell function take a Handle. Unfortunately, I can see no way to go from a Handle to a Ptr CFile, at least no portable way, so I discarded this option. 2) Deviate from the C API slightly and have the haskell function take a FilePath instead of a Handle. This is the option I chose, and this is where things get interesting. In order to pass a Ptr CFile (FILE *) to the C function, I had to call fopen() myself, using a usual FFI binding: foreign import ccall unsafe "fopen" fopen :: CString -> CString -> IO (Ptr CFile) That's the easy part. Now my problem was that I had to find a way to automatically close this FILE * when it isn't used anymore, in order not to leak FILE structures (and thus fds, etc). A finalizer is typically what I need, but unfortunately, a finalizer has a very strict shape: type FinalizerPtr a = FunPtr (Ptr a -> IO ()) That is, a finalizer can only be a pointer to a foreign function, and the foreign function itself needs a quite specific shape. And then I discovered Foreign.Concurrent, which allows one to associate a plain Haskell IO action to a pointer. The 'Foreign.Concurrent' name is a bit misleading to me; it seems this module is named so because it needs concurrency itself, rather than providing stuff for concurrency. So, in the end, I've got this code: import Foreign import Foreign.C import qualified Foreign.Concurrent as FC ... data PlayerStruct type Player = ForeignPtr PlayerStruct ... foreign import ccall unsafe "dd_newPlayer_file" dd_newPlayer_file :: Ptr CFile -> Ptr ImageStruct -> IO (Ptr PlayerStruct) foreign import ccall unsafe "&dd_destroyPlayer" destroyPlayerFinal :: FunPtr (Ptr PlayerStruct -> IO ()) foreign import ccall unsafe "fopen" fopen :: CString -> CString -> IO (Ptr CFile) foreign import ccall unsafe "fclose" fclose :: Ptr CFile -> IO CInt ... mkFinalizedPlayer :: Ptr PlayerStruct -> IO Player mkFinalizedPlayer = newForeignPtr destroyPlayerFinal newPlayerFile :: FilePath -> Image -> IO Player newPlayerFile path image = do withCString path $ \cpath -> do withCString "rb" $ \cmode -> do file <- throwErrnoIfNull "fopen: " (fopen cpath cmode) withForeignPtr image $ \ptr -> do player <- dd_newPlayer_file file ptr >>= mkFinalizedPlayer FC.addForeignPtrFinalizer player (fclose file >> return ()) return player So I'm adding the "usual" finalizer, and with the help of Foreign.Concurrent, I can add a second free-form one (fclose file >> return ()), in order to close the file I opened at an appropriate time. I'm looking forward hearing about other people's opinions, and wether this is a correct solution to the initial problem or not. I think there is another way to solve this, which is to provide the finalizer still in haskell code, but export the haskell code using FFI, so that I can use it as a plain, normal finalizer. I'm still unsure about this. Cheers, Maxime From jgbailey at gmail.com Wed Oct 3 12:03:07 2007 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Oct 3 12:02:01 2007 Subject: [Haskell-cafe] Curry and uncurry In-Reply-To: <7.0.1.0.0.20071003125457.01b1f020@ntlworld.com> References: <7.0.1.0.0.20071003125457.01b1f020@ntlworld.com> Message-ID: On 10/3/07, PR Stanley wrote: > > I didn't even know about the curry and uncurry functions. I'm not > looking for the answer but some guidance would be much appreciated. > Thanks, Paul You can look at the types without seeing the implementation, too. Just start up GHCI and type: :t curry or :t uncurry Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071003/9b56758f/attachment.htm From ryani.spam at gmail.com Wed Oct 3 13:12:57 2007 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Oct 3 13:11:54 2007 Subject: [Haskell-cafe] Haskell FFI and finalizers In-Reply-To: <20071003155758.GA94069@elvis.mu.org> References: <20071003155758.GA94069@elvis.mu.org> Message-ID: <2f9b2d30710031012w708d15b2gd24f7f8be7317e0d@mail.gmail.com> I think you want to use "wrapper" functions from the FFI: type HsPlayerFinalizer = Ptr PlayerStruct -> IO () foreign import ccall "wrapper" mkPlayerFinalizer :: HsPlayerFinalizer -> IO (FunPtr HsPlayerFinalizer) You can then make an arbitrary Haskell function (including a partially applied function with closure state) into a FunPtr. You call freeHaskellFunPtr when you are done with the function pointer. I believe it's safe to do this from the finalizer itself; you can use something like mkFinalizerPlayer ptr file = mdo finalizer <- mkPlayerFinalizer (createFinalizer finalizer file) newForeignPtr finalizer ptr where createFinalizer finalizer file player = do destroyPlayer player fclose file freeHaskellFunPtr finalizer -- ryan On 10/3/07, Maxime Henrion wrote: > Hello all, > > > > I have recently developed a small set of bindings for a C library, and > encountered a problem that I think could be interesting to others. > > My problem was that the C function I was writing bindings to expects to > be passed a FILE *. So, I had basically two possibles routes to take: > > 1) Mimic the C API and have the haskell function take a Handle. > > Unfortunately, I can see no way to go from a Handle to a Ptr CFile, at > least no portable way, so I discarded this option. > > 2) Deviate from the C API slightly and have the haskell function take a > FilePath instead of a Handle. > > This is the option I chose, and this is where things get interesting. > > In order to pass a Ptr CFile (FILE *) to the C function, I had to call > fopen() myself, using a usual FFI binding: > > foreign import ccall unsafe "fopen" > fopen :: CString -> CString -> IO (Ptr CFile) > > That's the easy par