From cgibbard at gmail.com Fri Feb 1 00:09:28 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Fri Feb 1 00:08:57 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad Message-ID: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> Hello, Today on #haskell, resiak was asking about a clean way to write the function which allocates an array of CStrings using withCString and withArray0 to produce a new with* style function. I came up with the following: nest :: [(r -> a) -> a] -> ([r] -> a) -> a nest xs = runCont (sequence (map Cont xs)) withCStringArray0 :: [String] -> (Ptr CString -> IO a) -> IO a withCStringArray0 strings act = nest (map withCString strings) (\rs -> withArray0 nullPtr rs act) Originally, I'd written nest without using the Cont monad, which was a bit of a mess by comparison, then noticed that its type was quite suggestive. Clearly, it would be more generally useful whenever you have a bunch of with-style functions for managing the allocation of resources, and would like to turn them into a single with-style function providing a list of the acquired resources. - Cale From lemming at henning-thielemann.de Fri Feb 1 05:12:28 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 1 05:11:43 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> Message-ID: On Fri, 1 Feb 2008, Cale Gibbard wrote: > Hello, > > Today on #haskell, resiak was asking about a clean way to write the > function which allocates an array of CStrings using withCString and > withArray0 to produce a new with* style function. I came up with the > following: > > nest :: [(r -> a) -> a] -> ([r] -> a) -> a > nest xs = runCont (sequence (map Cont xs)) > > withCStringArray0 :: [String] -> (Ptr CString -> IO a) -> IO a > withCStringArray0 strings act = nest (map withCString strings) > (\rs -> withArray0 nullPtr rs act) > > Originally, I'd written nest without using the Cont monad, which was a > bit of a mess by comparison, then noticed that its type was quite > suggestive. > > Clearly, it would be more generally useful whenever you have a bunch > of with-style functions for managing the allocation of resources, and > would like to turn them into a single with-style function providing a > list of the acquired resources. Nice idea. Could serve as an explanation what the Cont monad is good for. What about uploading it to the Wiki Category:Idioms ? From Christian.Maeder at dfki.de Fri Feb 1 05:32:35 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Feb 1 05:31:55 2008 Subject: [Haskell-cafe] Re: derive Pretty? In-Reply-To: <1f3dc80d0801311500t4107afabwafe370deb084870b@mail.gmail.com> References: <1f3dc80d0801311500t4107afabwafe370deb084870b@mail.gmail.com> Message-ID: <47A2F543.7040005@dfki.de> Greg Fitzgerald wrote: > Is it possible to automatically derive instances of Pretty > ? > If no, what do most do when it comes to pretty-printing large data types? We do it manually. Usually you have to decide anyway which bits to omit or add (only implicitly indicated by a data constructor) and if you compose things vertically or beside (or nested or whatever) to make it look pretty. HTH Christian see i.e an abstract syntax at: http://www.dfki.de/sks/hets/src-distribution/daily/Hets/docs/CASL-AS_Basic_CASL.html the pretty printer code is here http://www.dfki.de/sks/hets/src-distribution/daily/Hets/CASL/ToDoc.hs our pretty printer wrapper (for text and latex tailored for Hets) http://www.dfki.de/sks/hets/src-distribution/daily/Hets/docs/Common-Doc.html (try "versions" instead of "daily", if a "daily" went wrong) From dekudekuplex at yahoo.com Fri Feb 1 05:51:35 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Fri Feb 1 05:50:50 2008 Subject: [Haskell-cafe] anybody can tell me the pronuncation of "haskell"? In-Reply-To: Message-ID: <49382.7214.qm@web30204.mail.mud.yahoo.com> Here in Japan, it's pronounced in four syllables with no accent, as follows: Hah (as in "Hah, I see.") Sue (as in the name) Ke (as in the first syllable of "ketchup") Ru (as in the first syllable of "Lucas," since there is no difference between "l" and "r" sounds in Japanese) Put together, it sounds as follows: Hah-Sue-Ke-Ru Here's the URL of the Japanese Wikipedia page for Haskell Curry (for those who can read Japanese): http://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%B9%E3%82%B1%E3%83%AB%E3%83%BB%E3%82%AB%E3%83%AA%E3%83%BC Benjamin L. Russell --- Paulo Tanimoto wrote: > On Jan 29, 2008 11:19 AM, Jeremy Apthorp > wrote: > > Another Japanese word adopted from Portuguese is > their word for "bread": "pan". > > "tabako" too, I believe (it's not even written in > katakana). > > Now, how do the Japanese pronounce Haskell, I'd like > to know. > > Paulo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dan.doel at gmail.com Fri Feb 1 05:55:25 2008 From: dan.doel at gmail.com (Dan Doel) Date: Fri Feb 1 05:53:24 2008 Subject: [Haskell-cafe] Announce: CC-delcont 0.2 Message-ID: <200802010555.25810.dan.doel@gmail.com> Hello all, After much distraction and laziness on my part (my apologies), I have finally gotten around to putting together a new release of the delimited continuations library CC-delcont. It is now available on hackage. Relevant changes include: * Now builds in GHC-6.8.x * Builds with -Wall (and the code was cleaned up to make as little noise as possible) (Thanks to gwern for the above) Also included is a new module, Control.Monad.CC.Cursor, which provides some functions for reifying traversals into cursors that can be passed around and manipulated. It's still in its infancy, but I hope to eventually include generalized zippers and such. GHC 6.8 or greater is required to build, and haddock 2.0 or greater is required to generate the documentation. Links: * hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CC-delcont-0.2 * darcs: http://code.haskell.org/~dolio/CC-delcont/ * a brief tutorial: http://haskell.org/haskellwiki/Library/CC-delcont (I've not had too much feedback on this, so if anyone has trouble following some sections, or has ideas on how to better explain delimited continuations, changes are welcome.) Once again, if you discover any bugs, or have any suggestions, don't hesitate to let me know. -- Dan Doel From apfelmus at quantentunnel.de Fri Feb 1 06:13:04 2008 From: apfelmus at quantentunnel.de (apfelmus@quantentunnel.de) Date: Fri Feb 1 06:12:30 2008 Subject: [Haskell-cafe] Data.Ord and Heaps (Was: Why functional programming matters) Message-ID: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> Stephan Friedrichs wrote: > apfelmus wrote: >> [...] >> Feedback: I think the HeapPolicy thing is too non-standard. The =20 >> canonical way would be to use a MinHeap and let the Ord instance =20 >> handle everything. A MaxHeap can then be obtained via a different =20 >> Ord instance >> newtype Ord a =3D> Reverse a =3D Reverse { unReverse :: a } >> instance Ord a =3D> Ord (Reverse a) where >> compare =3D comparing unReverse >> This newtype should be in Data.Ord, of course. Being > > This solution should be used for all collections depending on Ord =20 > instances, including Data.Map, Data.Set and others. As long as I =20 > only include it in my tiny heap package, it is as 'non-standard' as =20= > my approach, isn't it? Yes. I mean "non-standard" in the software-reuse sense, i.e. Ord is =20 for user-defined orderings and should be the only such mechanism in =20 order to enable reuse. In fact, Data.Heap clearly shows that Data.Ord =20= is currently missing functionality. >> Simply setting >> type MaxHeap a =3D MinHeap (Reverse a) >> is inferior to a "native" MaxHeap since we'd have to pack/unpack =20 >> the Reverse all the time. But a type class for heaps - which =20 >> should be present anyway - can solve that problem: >> class Heap h where >> [...] >> instance Heap MinHeap where ... >> newtype MaxHeap a =3D M (MinHeap (Reverse a)) >> instance Heap MaxHeap where ... > > I've actually thought about this. Realising MinHeap and MaxHeap is =20 > no problem, but I decided against it, because implementing a custom =20= > order becomes quite complicated: You have to declare an > > newtype MyHeap a =3D ... > > instance Heap MyHeap where > -- about 10 functions > > instead of just > > data PriorityPolicy > > instance HeapPolicy PP MyPriorityType where > heapCompare =3D const (comparing priority) Note that the Heap class contains only three primitive operations =20 (empty, insert, viewHead), all the others have default =20 implementations in terms of those three. There is even an =20 underappreciated unfold among them :) toAscList =3D unfoldr viewHead The structure becomes especially clear by noting that any Heap is =20 defined by just two primitives inject :: Ord a =3D> Maybe (a, Heap a) -> Heap a view :: Ord a =3D> Heap a -> Maybe (a, Heap a) We have inject =3D maybe empty (uncurry insert) . This is just like =20= lists, except that view . inject =AD id since view returns the =20 smallest element. However, just that we managed to reduce the number of primitive =20 operations doesn't mean that the policy approach isn't preferable. It =20= needs 0 primitive operations, after all. But as foreshadowed in my =20 reply, it's possible to do policies within Ord. Don't stop thinking =20 about your good idea just because you can start coding :) Here's one way to do it: module Data.Ord where ... class (Ord p a) =3D> OrdPolicy p a where -- the policy p is a =20= type constructor to :: a -> p a from :: p a -> a instance OrdPolicy Identity a where ... newtype Reverse a =3D Reverse a instance Ord a =3D> Reverse a where compare =3D flip $ comparing from instance OrdPolicy Reverse a where to =3D Reverse; from (Reverse x) =3D x module Data.Heap where ... newtype Heap p a =3D Heap (MinHeap (p a)) type MaxHeap a =3D Heap Reverse a class Ord a =3D> Heap h a | h -> a where empty :: h insert :: a -> h -> h viewHead :: h -> Maybe (a, h) instance OrdPolicy p a =3D> Heap (Heap p a) a where ... What I don't like about this is that the policy is not polymorphic in =20= the element types, forcing the Heap class to be multi-parameter. I'd =20 really like to write class (forall a . Ord p a) =3D> OrdPolicy p where but I guess that's (currently) not possible. The original "phantom =20 policy" approach can't quite do this either: module Data.Ord where ... newtype OrdBy p a =3D OrdBy { unOrdBy :: a } data Reverse instance Ord a =3D> Ord (OrdBy Reverse a) where compare =3D flip $ comparing unOrdBy module Data.Heap where ... newtype Heap p a =3D Heap (MinHeap (OrdBy p a)) type MaxHeap a =3D Heap Reverse a class Heap h where empty :: Ord a =3D> h a insert :: Ord a =3D> a -> h a -> h a viewHead :: Ord a =3D> h a -> Maybe (a, h a) instance (Ord (OrdBy p a)) =3D> Heap (Heap p) where -- forall a? ... However, a distinct advantage of using OrdBy for all ordering =20 policies is that the from and to functions are no longer =20 necessary. All ordering policies use the same type OrdBy which =20 automatically guarantees that from and to are inverse to each =20 other. This would be an informal requirement otherwise, so I think =20 that phantom policies are clearly superior to type constructor =20 policies. Fortunately, this is orthogonal to making Heap a multi-=20 parameter type class and ensuring that OrdBy p a instances are =20 polymorphic in a . >> In conclusion: the ordering policy stuff should not be part of =20 >> Data.Heap, this is a job for Data.Ord. > As mentioned above: This sounds really useful. How about you =20 > propose this to the base-package maintainers? :) What, me? :D Regards, apfelmus From Malcolm.Wallace at cs.york.ac.uk Fri Feb 1 06:25:53 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Feb 1 06:27:26 2008 Subject: [Haskell-cafe] Re: hxt memory useage In-Reply-To: References: <200801241449.26827.matthew.pocock@ncl.ac.uk> <4798D33B.5010500@vex.net> <200801241917.33281.matthew.pocock@ncl.ac.uk> Message-ID: <20080201112553.7040b7d4.Malcolm.Wallace@cs.york.ac.uk> "Rene de Visser" wrote: > Even if you replace parsec, HXT is itself not > incremental. (It stores the whole XML document in memory as a tree, > and the tree is not memory effecient. If the usage pattern of the tree is search-and-discard, then only enough of the tree to satisfy the search needs to be stored in memory at once. Everything from the root to the first node of interest can easily be pruned by the garbage collector. A paper describing the lazy parsing technique, and using XML-parsing as its motivating example, is available at http://www.cs.york.ac.uk/~malcolm/partialparse.html > >> haxml offers the choice of non-incremental parsers and incremental > >> parsers. Indeed. This lazy incremental parser for XML is available in the development version of HaXml: http://www.cs.york.ac.uk/fp/HaXml-devel The source code for partial parsing is available in a separate package: http://www.cs.york.ac.uk/fp/polyparse These lazy parser combinators are roughly between 2x - 5x faster than Parsec on large inputs (although the strict variation is about 2x slower than Parsec). Regards, Malcolm From magnus at therning.org Fri Feb 1 06:42:14 2008 From: magnus at therning.org (Magnus Therning) Date: Fri Feb 1 06:41:40 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows Message-ID: <47A30596.6080209@therning.org> Is it possible to get Cabal to use 'cl' (Microsoft's C/C++ compiler shipped with Visual Studio Express)? I've found the Wiki page on using Visual Studio to create a DLL, then convert it to a .a file so that GHC can consume it. I'd rather skip using Visual Studio to build things and just ship a Cabalised package. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080201/8f5412be/signature.bin From dekudekuplex at yahoo.com Fri Feb 1 06:45:08 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Fri Feb 1 06:44:24 2008 Subject: [Haskell-cafe] Re: anybody can tell me the pronuncation of?"haskell"? In-Reply-To: Message-ID: <593130.51738.qm@web30208.mail.mud.yahoo.com> According to the "Gogen Yurai Jiten" (Etymology Derivation Dictionary") (http://gogen-allguide.com/a/arigatou.html), the etymology of "arigato" ("arigatou" when entered into a Japanese input method editor, such as Kotoeri) is as follows (at the risk of moji-bake (garbled text), I have included the Japanese text in Japanese characters before each translated portion): - translated text follows immediately after this line - ???????????????????A?`?e???u?L???????i???????????j?v???A?p?`?u?L???????i???????????j?v???E?????????A???????????????????B The etymology of "arigatou" is that the te-form [loosely translated as "conjunctive form"] "arigataku" of the adjective "arigatashi" changed in form to end in the "u" sound, and became "arigatou." ?u?L???????i???????????j?v???A?u?L???i?????j?????v???u?????i???????j?v?????????????A?{?????u???????????v???u?????????M?d???v?????????????\?????B "Arigatashi" has the meaning of "being" being "rare"/"difficult," and originally expressed the meaning of "rare" or "uncommon and precious." ?w?????q?x???u???????????????v?????A?u???????????????????????v???????????A???????A?u?????????????v?????????????????p?????????????B In [the scene] "Arigataki Mono" ["That Which is Uncommon/Precious] ] of "Makura no Soushi" [The Pillow Book] [see http://en.wikipedia.org/wiki/The_Pillow_Book], it is also used to mean "it is difficult to be in this world"; i.e., "difficult to spend [time in]." ???????????A?????????????M?d?????????????????????????????????????????????A?@???I?????????C?????????????????????A???????~?A?????????????????????????L???????B When medieval times arrived, from [the idea of] charity of the Buddha, etc., in obtaining that which is precious and difficult to obtain, it came to express a feeling of gratitude, and in recent times and later, it spread to general use as the meaning of gratitude. ?|???g?K???????u?I?u???K?[?h?iobrigado?j?v?????A?u???????????v?????????????????????????????????????A?|???g?K???l???K???????O?????g?????????????t???|???g?K???????R?????????????????A?u?I?u???K?[?h?v???u???????????v???????????????????????b???A???x?????????????????B There is a myth that from "obrigado" of Portuguese, people came to say "arigatou," but it cannot be the case that a word used before Portuguese people [first] visited Japan was derived from the Portuguese language; it just so happens to be the case that the sounds of "obrigado" and "arigatou" are similar, and this is a vulgar myth. - translated text ends immediately before this line - Yoroshiku onegai itashimasu. Arigatou gozaimasu. Benjamin L. Russell --- jerzy.karczmarczuk@info.unicaen.fr wrote: > Chung-chieh Shan corrects me: > > >> PS. If you think that "arigato" is a genuine > Japanese word, well, check > >> how the appropriately translated word is spelled > in Portuguese... > > > > I'm not sure what you mean by "genuine", but I > suspect that whether > > "arigato" is genuine does not depend on > Portuguese. > > http://linguistlist.org/issues/12/12-1871.html > > http://linguistlist.org/issues/12/12-1906.html > > > Yes, it seems that I have been one more victim of > this red herring. > In the cited issues of the linguistlist there is a > nice discussion of that > topic. It should be more widely known entre a gente > falando portugues. > Vou calar a boca... > > Gomen nasai. > > Jerzy Karczmarczuk > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From alfonso.acosta at gmail.com Fri Feb 1 07:00:05 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Feb 1 06:59:20 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200801312335.21615.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch wrote: > Am Donnerstag, 31. Januar 2008 18:30 schrieb Dominic Steinitz: > > Look at > > > > http://sneezy.cs.nott.ac.uk/fun/feb-07/jeremy-slides.pdf > > This is essentially what I had in mind. While Oleg's implementation needs > a "thrusted core", the GADT solution doesn't. True. However using GADTs doesn't allow to internally make use of Arrays, which (tell me if I'm wrong) are likely to be faster than the naive GADT implementation. Actually the GADT implementation you proposed fits nicely with the Vector definition already used in my EDSL (it is isomorphic actually), but efficiency could be an issue. > Some words on the representation of decimal numbers as types. While the > representation with types of the form D1 (D2 (D3 Sz)) has the advantage of > allowing numbers of arbitrary size, it has the disadvantage of a growing > number of parantheses. In my opinion, it would be nicer to have somethink > like D1 :- D2 :- D9 :- () with a right-associative operator :-. We could > even build the digit list the other way round?() :- D1 :- D2 :- D9?using a > left-associative :-. With the latter representation, we wouldn't need to > reverse digit sequences when adding numbers. Right, I agree. I think we should use the arbitrary-size implementation (actually, how arbitrary is it? what's the limit of GHC, if any?). To make it friendlier for the end user I thought about defining aliases for lets say the first 10000 numbers using Template Haskell. That could even make error reports friendlier (not sure to what point though). What do you think? So, we'll be making two separate libraries then. We should think about names. What about FixedVector for the vector library and DecTypArith (maybe too long) or DecTypes for the type-level decimal arithmetic library? I'll put my hands dirty once we agree on this. Cheers, Fons From alfonso.acosta at gmail.com Fri Feb 1 07:09:03 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Feb 1 07:08:17 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> Message-ID: <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> > What about FixedVector for the vector library and DecTypArith (maybe > too long) or DecTypes for the type-level decimal arithmetic library? Actually it would maybe be better to create common high-level interface that could include unary, binary and decimal arithmetic so that the library could be easily reused in other projects (people like Bjorn, seem to be using the unary implementation). I don't know if it would be feasible though. From jules at jellybean.co.uk Fri Feb 1 07:15:35 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Feb 1 07:14:51 2008 Subject: [Haskell-cafe] Simple network client In-Reply-To: <86506D5E-1C88-48F9-B8D2-606EA0030F43@fastmail.fm> References: <200801291212.02144.t.h@gmx.info><47A0678F.1070507@jellybean.co.uk> <002201c86348$911cad70$b3560850$@be> <125EACD0CAE4D24ABDB4D148C4593DA9049E926C@GBLONXMB02.corp.amvescap.net> <47A19382.9010006@phil.uu.nl> <86506D5E-1C88-48F9-B8D2-606EA0030F43@fastmail.fm> Message-ID: <47A30D67.9050604@jellybean.co.uk> Jonathan Cast wrote: > On 31 Jan 2008, at 1:23 AM, Reinier Lamers wrote: > >> Bayley, Alistair wrote: >>> More than one person has posted previously about the flaws and traps >>> of lazy IO. A common position seems to be "don't do lazy IO". >>> >> Still, when I was browsing the Haskell' wiki a few days ago, I >> couldn't find any proposal to remove lazy I/O or move it into some >> special System.IO.Lazy (or >> System.IO.UnsafeEvilFunctionsThatSacrificeBabies) ... > > Sacrificing babies is not a unique characteristic of lazy IO, of course; > it's true of any file IO on a non-versioning file system. However you can contain the pain if it's in the IO monad, and be in no worse situation than conventional languages. If the pain is unsafeInterleaved all over the place, then you actually *are* in a worse situation. ObHaskell' : lazy IO shouldn't be in any haskell standard, since it's not referentially transparent. It should be a powerful but dangerous feature enabled by certain implementations in an implementation specfic way. (unsafeInterleaveIO itself is not haskel98, I'm fairly sure) Jules From r.kelsall at millstream.com Fri Feb 1 08:15:54 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Fri Feb 1 08:15:13 2008 Subject: Cryptographic hash uniquness (was [Haskell-cafe] Simple network client) In-Reply-To: <151242831.20080131202417@gmail.com> References: <151242831.20080131202417@gmail.com> Message-ID: <47A31B8A.1000300@millstream.com> Bulat Ziganshin wrote: > Hello Peter, > > Thursday, January 31, 2008, 8:01:36 PM, you wrote: > >> files with different content generating the same hash)... My >> intuition told me that the odds of two cryptographic hashes (on >> meaningful content) colliding was much less than the earth being >> destroyed by an asteroid... But this is just intuition... What does >> computer science tell us about this? > > you may be interested to know that widely used rsync algorithms relies > on 128-bit hashes and its author speculated about its reliability: > > http://samba.org/~tridge/phd_thesis.pdf > Interesting paper. Thank you. I had a quick read of the bit relating to hashes and my understanding is this. He uses a weak, quick and simple hash to deal with 99.99% (I invented that percentage) of cases - if the hash is different we know the files are definitely different - if the hash collides he then does a strong, slow, secure hash and relies on this as the answer. But he's relying on the strong hash rather than doing a byte by byte comparison because there is a major cost (a network transmission of the file) to doing the proper byte by byte comparison. If you had both files accessible at a low cost it might be better to byte by byte compare them when you get a collision rather than use the strong hash. The right approach may be to assume that collisions will occur and cater for this properly in the program somehow. A good tip for testing this sort of thing is to have the length of the hash (maximum size of the array or whatever you want to test) as a parameter that you can turn down to a very low value to induce collisions (overflows etc) to see whether the program still works. And then turn it back up for live use. A cryptographic hash appears as a completely random function of the input so the likelihood of a collision is simply 2^(bits in hash). Richard. From loup.vaillant at gmail.com Fri Feb 1 09:03:05 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Fri Feb 1 09:02:22 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> Message-ID: <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> I have read quite a lot of Haskell papers, lately, and noticed that the number 42 appeared quite often, in informal tutorials as well as in very serious research papers. No wonder Haskell is the Answer to The Great Question of Life, The Universe, and Everything, but I would like to know who started this, and when. Google wasn't much help, and I can't believe it's coincidence --hence this email. I hope I didn't opened some Pandora box. :-) Cheers, Loup From dbueno at gmail.com Fri Feb 1 09:10:50 2008 From: dbueno at gmail.com (Denis Bueno) Date: Fri Feb 1 09:10:05 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> Message-ID: <6dbd4d000802010610v7744440bkad1182e9a69c985d@mail.gmail.com> On Fri, Feb 1, 2008 at 9:03 AM, Loup Vaillant wrote: > I have read quite a lot of Haskell papers, lately, and noticed that > the number 42 appeared quite often, in informal tutorials as well as > in very serious research papers. No wonder Haskell is the Answer to > The Great Question of Life, The Universe, and Everything, but I would > like to know who started this, and when. I believe it was Douglas Adams, author of the "trilogy" "Hitchhiker's Guide to the Galaxy". You may enjoy reading it, if you haven't. -- Denis From haskell at list.mightyreason.com Fri Feb 1 09:18:05 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Fri Feb 1 09:17:29 2008 Subject: [Haskell-cafe] Re: A handy little consequence of the Cont monad In-Reply-To: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> Message-ID: The "bit of a mess" that comes from avoiding monads is (my version): > import Foreign.Marshal.Array(withArray0) > import Foreign.Ptr(nullPtr,Ptr) > import Foreign.C.String(withCString,CString) This uses withCString in order of the supplied strings, and a difference list ([CString]->[CString]) initialized by "id" to assemble the [CString]. This is the laziest way to proceed. > acquireInOrder :: [String] -> (Ptr CString -> IO a) -> IO a > acquireInOrder strings act = > foldr (\s cs'io'a -> > (\cs -> > withCString s (\c -> cs'io'a (cs . (c:)) > ) > ) > ) > (\cs -> > withArray0 nullPtr (cs []) act > ) > strings > id This uses in withCString in reversed order of the supplied strings, and normal list ([CString]) initialized by "[]" to assemble the [CString]. This is not as lazy since it needs to go to the end of the supplied list for the first IO action. > acquireInRerverseOrder :: [String] -> (Ptr CString -> IO a) -> IO a > acquireInRerverseOrder strings act = > foldl (\cs'io'a s -> > (\cs -> > withCString s (\c -> cs'io'a (c:cs) > ) > ) > ) > (\cs -> > withArray0 nullPtr cs act > ) > strings > [] Cale Gibbard wrote: > Hello, > > Today on #haskell, resiak was asking about a clean way to write the > function which allocates an array of CStrings using withCString and > withArray0 to produce a new with* style function. I came up with the > following: > > nest :: [(r -> a) -> a] -> ([r] -> a) -> a > nest xs = runCont (sequence (map Cont xs)) > > withCStringArray0 :: [String] -> (Ptr CString -> IO a) -> IO a > withCStringArray0 strings act = nest (map withCString strings) > (\rs -> withArray0 nullPtr rs act) > > Originally, I'd written nest without using the Cont monad, which was a > bit of a mess by comparison, then noticed that its type was quite > suggestive. > > Clearly, it would be more generally useful whenever you have a bunch > of with-style functions for managing the allocation of resources, and > would like to turn them into a single with-style function providing a > list of the acquired resources. > > - Cale From cconway at cs.nyu.edu Fri Feb 1 09:18:50 2008 From: cconway at cs.nyu.edu (Christopher L Conway) Date: Fri Feb 1 09:18:09 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> Message-ID: <4a051d930802010618x614bef69na3a8e380bc3e1f98@mail.gmail.com> Loup, This is not unique to the Haskell community. I suspect the arbitrary constant 42 has been appearing unexplained in research papers for as long as there have been computer scientists who were sci-fi geeks (absolutely no offense intended to geeks ;-). It would be very difficult indeed to figure out who did this first, without some highly dedicated library research. Chris On Feb 1, 2008 9:03 AM, Loup Vaillant wrote: > I have read quite a lot of Haskell papers, lately, and noticed that > the number 42 appeared quite often, in informal tutorials as well as > in very serious research papers. No wonder Haskell is the Answer to > The Great Question of Life, The Universe, and Everything, but I would > like to know who started this, and when. > > Google wasn't much help, and I can't believe it's coincidence --hence > this email. I hope I didn't opened some Pandora box. :-) > > Cheers, > Loup > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From voigt at tcs.inf.tu-dresden.de Fri Feb 1 09:19:31 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Fri Feb 1 09:18:47 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <6dbd4d000802010610v7744440bkad1182e9a69c985d@mail.gmail.com> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> <6dbd4d000802010610v7744440bkad1182e9a69c985d@mail.gmail.com> Message-ID: <47A32A73.4@tcs.inf.tu-dresden.de> Denis Bueno wrote: > On Fri, Feb 1, 2008 at 9:03 AM, Loup Vaillant wrote: > >>I have read quite a lot of Haskell papers, lately, and noticed that >> the number 42 appeared quite often, in informal tutorials as well as >> in very serious research papers. No wonder Haskell is the Answer to >> The Great Question of Life, The Universe, and Everything, but I would >> like to know who started this, and when. > > > I believe it was Douglas Adams, author of the "trilogy" "Hitchhiker's > Guide to the Galaxy". You may enjoy reading it, if you haven't. I think Loup is aware of the hitchhiker books (see the reference to the Great Question of ... Everything). So unless Douglas Adams wrote some Haskell papers I am not aware of, the original question is still open ;-) Happy weekend... Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From loup.vaillant at gmail.com Fri Feb 1 09:27:45 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Fri Feb 1 09:26:59 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <4a051d930802010618x614bef69na3a8e380bc3e1f98@mail.gmail.com> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> <4a051d930802010618x614bef69na3a8e380bc3e1f98@mail.gmail.com> Message-ID: <6f9f8f4a0802010627q3ecaf2efia1a6f0ef0668b20e@mail.gmail.com> 2008/2/1, Christopher L Conway : > Loup, > > This is not unique to the Haskell community. I suspect the arbitrary > constant 42 has been appearing unexplained in research papers for as > long as there have been computer scientists who were sci-fi geeks > (absolutely no offense intended to geeks ;-). It would be very > difficult indeed to figure out who did this first, without some highly > dedicated library research. I suspected this. Just that I didn't noticed 42 but in Haskell papers. Maybe this is just a bias due to my recent interests. I should check some C/C++/Lisp/Ocaml papers. About the library search, Maybe it is possible to try a giant "grep" on all papers in ACM Portal, or CiteSeer? Loup From cconway at cs.nyu.edu Fri Feb 1 09:32:49 2008 From: cconway at cs.nyu.edu (Christopher L Conway) Date: Fri Feb 1 09:32:05 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <6f9f8f4a0802010627q3ecaf2efia1a6f0ef0668b20e@mail.gmail.com> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> <4a051d930802010618x614bef69na3a8e380bc3e1f98@mail.gmail.com> <6f9f8f4a0802010627q3ecaf2efia1a6f0ef0668b20e@mail.gmail.com> Message-ID: <4a051d930802010632n61c51b70wb67cb6821a60bec3@mail.gmail.com> On Feb 1, 2008 9:27 AM, Loup Vaillant wrote: > I suspected this. Just that I didn't noticed 42 but in Haskell papers. > Maybe this is just a bias due to my recent interests. I should check > some C/C++/Lisp/Ocaml papers. > > About the library search, Maybe it is possible to try a giant "grep" > on all papers in ACM Portal, or CiteSeer? I tried this briefly on the ACM. You need to be able to exclude citations, footnotes, volume numbers, etc., and their "Advanced Search" is not quite that advanced. :-) Chris From alfonso.acosta at gmail.com Fri Feb 1 09:41:10 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Feb 1 09:40:24 2008 Subject: [Haskell-cafe] fast graph algorithms without object identities In-Reply-To: <30150267-9896-4E99-BFE8-A7FCA587215C@alum.mit.edu> References: <30150267-9896-4E99-BFE8-A7FCA587215C@alum.mit.edu> Message-ID: <6a7c66fc0802010641u43c7f905l14f6dddbbd388111@mail.gmail.com> You'd probably be interested to read http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html On Jan 31, 2008 9:56 PM, Jan-Willem Maessen wrote: > > On Jan 31, 2008, at 5:39 AM, Henning Thielemann wrote: > > > > > It seems that algorithms on graphs can be implemented particularly > > efficient in low-level languages with pointers and in-place updates. > > E.g. > > topological sort needs only linear time, provided that dereferencing > > pointers requires constant time. I could simulate pointer > > dereferencings > > and pointer updates by Map yielding linear logarithmic time for > > topological sort. I wonder if it is possible to write a linear time > > topological sort using lazy evaluation, since the runtime system of > > Haskell implementations is a graph processor based on pointers. > > If so, I'd love to see this written up; I think it may be publishable > if it isn't published already. > > Note that even using ST techniques can take more than linear time, > given an arbitrary purely-functionally-defined graph as input. We > can't (eg) assume that each node contains a reference, or that they > are densely numbered, so we end up having to look them up in some > fashion (though using a hash table can be reasonably quick if we > uniquely number nodes). > > -Jan-Willem Maessen > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dbueno at gmail.com Fri Feb 1 09:41:15 2008 From: dbueno at gmail.com (Denis Bueno) Date: Fri Feb 1 09:40:32 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <47A32A73.4@tcs.inf.tu-dresden.de> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> <6dbd4d000802010610v7744440bkad1182e9a69c985d@mail.gmail.com> <47A32A73.4@tcs.inf.tu-dresden.de> Message-ID: <6dbd4d000802010641t686124c1l150f31c0c5b5ef06@mail.gmail.com> On Fri, Feb 1, 2008 at 9:19 AM, Janis Voigtlaender wrote: > I think Loup is aware of the hitchhiker books (see the reference to the > Great Question of ... Everything). Ah, I didn't read that correctly. I assumed that something he read something that had described Haskell as the answer to Life, the Universe, and Everything. Sorry about that. -- Denis From molyneux at kingston.ac.uk Fri Feb 1 10:24:02 2008 From: molyneux at kingston.ac.uk (Phil Molyneux) Date: Fri Feb 1 10:23:22 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> Message-ID: <40190312-5D60-48CE-A04D-6894DC984E57@kingston.ac.uk> Hi --- The arbitrary constant was made popular by Douglas Adams in the mid-1970s radio series ``A Hitchhikers Guide to the Galaxy'' (a trilogy in 4 parts) --- however it does have a basis in the standard model of physics --- a paper in Phys.Rev. of the early 1970s described the unification of the Electro-Weak and Strong nuclear forces --- the arbitrary constant (of nearly) 42 appears in the calculations. I forget the original paper but if you get hold of Frank Close ``The Cosmic Onion'' a graph reproduces the result. I met Douglas Adams once at a book signing and asked him how he got hold of the Phys.Rev. paper so early. Technically he should have written that ``42 is the answer to life, the universe and everything except for gravity and a few other arbitrary constants'' Adams was interested in computing --- I think his reaction to being told about functional programming was to wonder what non-functional programming might be. Phil On 1 Feb 2008, at 14:03, Loup Vaillant wrote: > I have read quite a lot of Haskell papers, lately, and noticed that > the number 42 appeared quite often, in informal tutorials as well as > in very serious research papers. No wonder Haskell is the Answer to > The Great Question of Life, The Universe, and Everything, but I would > like to know who started this, and when. > > Google wasn't much help, and I can't believe it's coincidence --hence > this email. I hope I didn't opened some Pandora box. :-) > > Cheers, > Loup > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > This email has been scanned for all viruses by the MessageLabs Email > Security System. This email has been scanned for all viruses by the MessageLabs Email Security System. From colin at colina.demon.co.uk Fri Feb 1 10:35:13 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Feb 1 10:34:29 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: <40190312-5D60-48CE-A04D-6894DC984E57@kingston.ac.uk> (Phil Molyneux's message of "Fri\, 1 Feb 2008 15\:24\:02 +0000") References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> <40190312-5D60-48CE-A04D-6894DC984E57@kingston.ac.uk> Message-ID: >>>>> "Phil" == Phil Molyneux writes: Phil> Adams was interested in computing --- I think his reaction Phil> to being told about functional programming was to wonder Phil> what non-functional programming might be. Curiously, that was my reaction too when i first heard of the term (from a university student who was complaining that it was too hard). -- Colin Adams Preston Lancashire From catamorphism at gmail.com Fri Feb 1 11:10:15 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Feb 1 11:09:31 2008 Subject: [Haskell-cafe] Who started 42, and when? In-Reply-To: References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> <40190312-5D60-48CE-A04D-6894DC984E57@kingston.ac.uk> Message-ID: <4683d9370802010810t44143df5p6bcd9b00efbb0936@mail.gmail.com> To pre-empt the next couple of questions, the numbers 17 and 23 are from _The Illuminatus! Trilogy_ by Robert Shea and Robert Anton Wilson, and the number 37 is from the Jersey Trilogy of movies by Kevin Smith. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I'm a nonbeliever, but I believe in your smile." -- Laura Nyro From bjorn.buckwalter at gmail.com Fri Feb 1 11:23:55 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Fri Feb 1 11:23:16 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> Message-ID: Alfonso Acosta gmail.com> writes: > Actually it would maybe be better to create common high-level > interface that could include unary, binary and decimal arithmetic so > that the library could be easily reused in other projects (people like > Bjorn, seem to be using the unary implementation). I don't know if it > would be feasible though. My reason for going with unary implementation was that it seemed to be the easiest and less tedious to implement. But is sure does make the error messages less friendly. It also limits the magnitude of the numbers quite severely unless one bumps up the type checker stack size. From the source code: "The practical size of the NumTypes is limited by the type checker stack. If the NumTypes grow too large (which can happen quickly with multiplication) an error message similar to the following will be emitted: Context reduction stack overflow; size = 20 Use -fcontext-stack=N to increase stack size to N This situation could concievably be mitigated significantly by using e.g. a binary representation of integers rather than Peano numbers." For my use (keeping track of physical dimensions) this hasn't been a problem. If Naturals had been sufficient for me I wouldn't have done my own implementation (I'm unaware of any other implementation of Integers). And there is certainly a lot of value to the clearer error messages from a decimal representation. Concerning whether or not there is any value in being able to change the representation of the type- level naturals in your library, my guess is that the value wouldn't be all that great. As I mentioned I use my implementation for tracking physical dimensions and HList's HNats for constraining vector dimensions but this isn't a problem since I cannot conceive of any reason why I would want to intermix the two. Of course, other usage scenarios exist where there would be a desire to intermix the vector dimensions with something else...? So sure, if you can abstract the representation away by all means do it. But I wouldn't go out of my way or impair the rest of the library to achieve this. Hope this helps, Bjorn From jmaessen at alum.mit.edu Fri Feb 1 11:28:12 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Fri Feb 1 11:27:32 2008 Subject: [Haskell-cafe] fast graph algorithms without object identities In-Reply-To: <6a7c66fc0802010641u43c7f905l14f6dddbbd388111@mail.gmail.com> References: <30150267-9896-4E99-BFE8-A7FCA587215C@alum.mit.edu> <6a7c66fc0802010641u43c7f905l14f6dddbbd388111@mail.gmail.com> Message-ID: <009AAE5D-A47A-45D0-AC5D-3C1269500D9E@alum.mit.edu> On Feb 1, 2008, at 9:41 AM, Alfonso Acosta wrote: > You'd probably be interested to read > http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html It is indeed an interesting paper (that I've read and referred to several times over the years). But it's tricky to get right in practice! And sadly, while it solves the problem of sharing (or object equivalence) it doesn't give us some sort of total order or hash key, so there's no way to efficiently associate transient mutable state uniquely with each reference we encounter. For that we need one of the other solutions discussed and rejected. This is why Data.Unique provides a pure hashUnique function. The best option I know of here to get the desired time bounds with a purely-functional abstraction is to use a splittable supply of unique labels (which can be encapsulated in a monad if we like), then use ST to associate a hash table of references with the graph nodes while traversing the graph. -Jan From wnoise at ofb.net Fri Feb 1 14:27:18 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Feb 1 14:26:49 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> Message-ID: On 2008-02-01, Bjorn Buckwalter wrote: > If Naturals had been sufficient for me I wouldn't have done my own > implementation (I'm unaware of any other implementation of Integers). > And there is certainly a lot of value to the clearer error messages > from a decimal representation. I did a balanced-base-three (digits are 0, and +- 1) representation to get negative "decimals". Again, for a proof-of-concept dimensional analysis arithmetic. No problem with the stack, but the error messages are still less than clear. -- Aaron Denney -><- From lgreg.meredith at biosimilarity.com Fri Feb 1 14:55:51 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Fri Feb 1 14:55:07 2008 Subject: [Haskell-cafe] NW Functional Programming Interest Group Message-ID: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> All, Apologies for multiple listings. A small cadre of us are organizing a Northwest Functional Programming Interest Group (hey... NWFPIG, that's kinda funny). Our first official meeting is at the The Seattle Public Library 1000 - 4th Ave. Seattle, WA 98104 from 17:00 - 18:00 on February 20th. On the first meeting's agenda we'll be - giving people who are interested in or actively using FP for work or play a chance to meet - seeking to build up a pipeline of presentations and guest speakers - trying to keep organizational mishigosh to a minimum Hope to see you there. Monadically yours, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080201/c54cf502/attachment.htm From jgbailey at gmail.com Fri Feb 1 15:36:44 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Feb 1 15:35:57 2008 Subject: [Haskell-cafe] Re: [Haskell] NW Functional Programming Interest Group In-Reply-To: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> References: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> Message-ID: If Seattle is too far away, Portland has its own recently formed FP group, PDXFP: http://groups.google.com/group/pdxfunc So far we're meeting every 2nd Monday of the month at CubeSpace on 6th & Grand. Justin From vigalchin at gmail.com Fri Feb 1 16:01:52 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Fri Feb 1 16:01:12 2008 Subject: [Haskell-cafe] reading from the cdrom drive on Red Hat Message-ID: <5ae4f2ba0802011301k6e6cda09ya13f6850c8f48078@mail.gmail.com> Hello, I wrote a simple program to read the contents of a cdrom: module Main where import Text.Printf import System.IO import System.Posix.Types import System.Posix.IO main = do fd <- openFd "/dev/cdrom" ReadOnly Nothing defaultFileFlags readCdRom fd 4096 closeFd fd readCdRom fd byteCount = do (buf, actualByteCount) = fdRead fd bytecount readCdRom fd byteCount When it executed it read thousands of 4096 blocks as I expected. It then got a "hardware error" which I suspect was the "end of the CD", i.e. the begininng of the "unlasered" part of the CD. Is there a better and more graceful way to detect and handle "end of data"? Thanks, ,Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080201/3a279362/attachment.htm From g9ks157k at acme.softbase.org Fri Feb 1 16:05:16 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Feb 1 16:04:42 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <47A29BDC.9010709@charter.net> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <47A29BDC.9010709@charter.net> Message-ID: <200802012205.16432.g9ks157k@acme.softbase.org> Am Freitag, 1. Februar 2008 05:11 schrieben Sie: > Wolfgang Jeltsch wrote: > > Well, the representation (D1,D2,D9) might be considered more readable. > > It has the disadvantage of a fixed maximum size for the numbers. Which > > takes me to a point I had already considered some time ago: Wouldn?t it > > be good if we had just a type > > > > data Pair val1 val2 = Pair val1 val2 > > > > and if then (val1,val2,?,valn) would just be syntactic sugar for this: > > > > val1 `Pair` (val2 `Pair` (?(valn `Pair` ())?)) > > I've thought of that too.. besides the asymmetry, the presence of > _|_/seq makes them actually not equivalent though, unfortunately > > ~Isaac With Ryan?s proposal (using strictness annotations) the new representation should be equivalent to the old one. Or am I missing something? Best wishes, Wolfgang From derek.a.elkins at gmail.com Fri Feb 1 16:27:06 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Feb 1 16:26:26 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> Message-ID: <1201901226.5496.79.camel@derek-laptop> On Fri, 2008-02-01 at 00:09 -0500, Cale Gibbard wrote: > Hello, > > Today on #haskell, resiak was asking about a clean way to write the > function which allocates an array of CStrings using withCString and > withArray0 to produce a new with* style function. I came up with the > following: > > nest :: [(r -> a) -> a] -> ([r] -> a) -> a > nest xs = runCont (sequence (map Cont xs)) This is what you write after all that time on #haskell? nest = runCont . sequence . map Cont From agl at imperialviolet.org Fri Feb 1 16:28:06 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Feb 1 16:27:20 2008 Subject: [Haskell-cafe] reading from the cdrom drive on Red Hat In-Reply-To: <5ae4f2ba0802011301k6e6cda09ya13f6850c8f48078@mail.gmail.com> References: <5ae4f2ba0802011301k6e6cda09ya13f6850c8f48078@mail.gmail.com> Message-ID: <396556a20802011328i61dd64fdp80e2fc3251a5490c@mail.gmail.com> 2008/2/1 Galchin Vasili : > I wrote a simple program to read the contents of a cdrom: (Note that this is a terribly inefficient way of reading large amounts of binary data. Of course, if this is just meant as an example, that's fine. Otherwise, see the struff about ByteStrings at http://www.haskell.org/haskellwiki/DealingWithBinaryData) The error you are seeing comes from the operating system. You could run the resulting Haskell program under strace to see the exact error, but what's happening is that the kernel is getting an error from the CD drive itself. This is pretty much unique to CDs I guess. If you were reading a hard drive, the kernel knows exactly how large the disk is (see /proc/partitions) and would return EOF (zero bytes). As an aside, hitting EOF in your code would result in an infinite loop, since you don't handle actualByteCount == 0. You can catch and handle the resulting exception with the functions in: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From g9ks157k at acme.softbase.org Fri Feb 1 16:32:16 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Feb 1 16:31:35 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> Message-ID: <200802012232.16922.g9ks157k@acme.softbase.org> Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta: > On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch wrote: > > Am Donnerstag, 31. Januar 2008 18:30 schrieb Dominic Steinitz: > > > Look at > > > > > > http://sneezy.cs.nott.ac.uk/fun/feb-07/jeremy-slides.pdf > > > > This is essentially what I had in mind. While Oleg's implementation > > needs a "thrusted core", the GADT solution doesn't. > > True. However using GADTs doesn't allow to internally make use of > Arrays, which (tell me if I'm wrong) are likely to be faster than the > naive GADT implementation. It depends. My first GADT implementation is equivalent to the [] type and often [] is better than arrays. For example, if you read the contents of a file and process it with maps, filters, etc., [] is likely to give you constant space usage which arrays don?t. If you want to lookup elements by index, then arrays are better, of course. For my purpose, it would be fine to use a []-like implementation, I think. > [?] > > Some words on the representation of decimal numbers as types. While the > > representation with types of the form D1 (D2 (D3 Sz)) has the advantage > > of allowing numbers of arbitrary size, it has the disadvantage of a > > growing number of parantheses. In my opinion, it would be nicer to have > > somethink like D1 :- D2 :- D9 :- () with a right-associative operator :-. > > We could even build the digit list the other way round?() :- D1 :- D2 :- > > D9?using a left-associative :-. With the latter representation, we > > wouldn't need to reverse digit sequences when adding numbers. > > Right, I agree. I think we should use the arbitrary-size implementation So let?s use the representation with the left-associative :- (or whatever operator we might choose). > (actually, how arbitrary is it? what's the limit of GHC, if any?). Arbitrary enough, I think. If we don?t need lists with billions of elements, our representations will have less than 8 digits. > To make it friendlier for the end user I thought about defining > aliases for lets say the first 10000 numbers using Template Haskell. > That could even make error reports friendlier (not sure to what point > though). What do you think? I have no clear opinion about that at the moment. Maybe it?s okay to use the representation directly. This way, we don?t introduce a dependeny on the Template Haskell language extension (which is only supported by GHC), and the actual representation will occur in error messages anyway whenever the message shows a computed number. > So, we'll be making two separate libraries then. We should think about > names. > > What about FixedVector for the vector library and DecTypArith (maybe > too long) or DecTypes for the type-level decimal arithmetic library? Alas, there is an inconsistency in naming packages already. Some prefer names which are entirely lowercase, some prefer camel case. I prefer lowercase, with hyphens separating parts of the name. And I also don?t like unusual abbreviations like ?typ? (not much shorter than ?type?). To mention arithmetics is not so important. So maybe something like ?type-level-decimals?? Maybe it?s better to put different type-level programming things into a single package. Then we could name this package ?type-level? or something similar. We could start with our decimals. Other type-level things could be added later. I already have some code about type-level booleans. It?s not very sensible to put these few lines into a separate package. It might be nice if we had a general type-level programming package where I could put this code into. As for the name of the fixed-size list package, I have to say that I don?t like the term ?vector? in this context. A vector is actually something with addition and scalar multiplication defined on it. Maybe we should make also this package?s scope wider. What about something like ?safe-data? or similar? > I'll put my hands dirty once we agree on this. Great!! > Cheers, > > Fons Best wishes, Wolfgang From g9ks157k at acme.softbase.org Fri Feb 1 16:33:28 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Feb 1 16:32:43 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> Message-ID: <200802012233.28126.g9ks157k@acme.softbase.org> Am Freitag, 1. Februar 2008 13:09 schrieben Sie: > > What about FixedVector for the vector library and DecTypArith (maybe > > too long) or DecTypes for the type-level decimal arithmetic library? > > Actually it would maybe be better to create common high-level > interface that could include unary, binary and decimal arithmetic so > that the library could be easily reused in other projects (people like > Bjorn, seem to be using the unary implementation). I don't know if it > would be feasible though. I?d say, let?s start with the decimal thing. We can extend our package later if there?s a need to do this, can?t we? Best wishes, Wolfgang From bos at serpentine.com Fri Feb 1 16:42:08 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri Feb 1 16:41:22 2008 Subject: [Haskell-cafe] reading from the cdrom drive on Red Hat In-Reply-To: <396556a20802011328i61dd64fdp80e2fc3251a5490c@mail.gmail.com> References: <5ae4f2ba0802011301k6e6cda09ya13f6850c8f48078@mail.gmail.com> <396556a20802011328i61dd64fdp80e2fc3251a5490c@mail.gmail.com> Message-ID: <47A39230.2090004@serpentine.com> Adam Langley wrote: > The error you are seeing comes from the operating system. No, it's the Haskell runtime turning a -1 return from read into an exception. You need to call hIsEOF to check whether you've hit EOF, then break out of the loop. References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> Message-ID: <20080201214858.GF31711@cs.cmu.edu> Not to start a flame war or religious debate, but I don't think that eta-expansions should be considered bad style. I realize that composition-style is good for certain types of reasoning, but fully eta-expanded code has an important legibility advantage: you can tell the shape of its type just by looking at it! Personally, I'd rather read the original version. -Dan On Feb01, Derek Elkins wrote: > On Fri, 2008-02-01 at 00:09 -0500, Cale Gibbard wrote: > > Hello, > > > > Today on #haskell, resiak was asking about a clean way to write the > > function which allocates an array of CStrings using withCString and > > withArray0 to produce a new with* style function. I came up with the > > following: > > > > nest :: [(r -> a) -> a] -> ([r] -> a) -> a > > nest xs = runCont (sequence (map Cont xs)) > > This is what you write after all that time on #haskell? > > nest = runCont . sequence . map Cont > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From agl at imperialviolet.org Fri Feb 1 16:49:43 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Feb 1 16:48:56 2008 Subject: [Haskell-cafe] reading from the cdrom drive on Red Hat In-Reply-To: <47A39230.2090004@serpentine.com> References: <5ae4f2ba0802011301k6e6cda09ya13f6850c8f48078@mail.gmail.com> <396556a20802011328i61dd64fdp80e2fc3251a5490c@mail.gmail.com> <47A39230.2090004@serpentine.com> Message-ID: <396556a20802011349x266303f7x66a099e186b59e4a@mail.gmail.com> On Feb 1, 2008 1:42 PM, Bryan O'Sullivan wrote: > No, it's the Haskell runtime turning a -1 return from read into an > exception. You need to call hIsEOF to check whether you've hit EOF, > then break out of the loop. (assuming you meant 0, not -1) My bad, I thought that the Posix.IO stuff was a closer wrapping than that. It does, indeed, throw an exception on 0. How unfortunate. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From vigalchin at gmail.com Fri Feb 1 16:54:54 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Fri Feb 1 16:54:08 2008 Subject: [Haskell-cafe] reading from the cdrom drive on Red Hat In-Reply-To: <396556a20802011349x266303f7x66a099e186b59e4a@mail.gmail.com> References: <5ae4f2ba0802011301k6e6cda09ya13f6850c8f48078@mail.gmail.com> <396556a20802011328i61dd64fdp80e2fc3251a5490c@mail.gmail.com> <47A39230.2090004@serpentine.com> <396556a20802011349x266303f7x66a099e186b59e4a@mail.gmail.com> Message-ID: <5ae4f2ba0802011354x3d72d384xd1fa5caf4770ae78@mail.gmail.com> Thank you Adam and Bradley. My program is my getting a feel of how to open a Linux and do "block" reads. Just conceptual Vasili On 2/1/08, Adam Langley wrote: > > On Feb 1, 2008 1:42 PM, Bryan O'Sullivan wrote: > > No, it's the Haskell runtime turning a -1 return from read into an > > exception. You need to call hIsEOF to check whether you've hit EOF, > > then break out of the loop. > > (assuming you meant 0, not -1) > > My bad, I thought that the Posix.IO stuff was a closer wrapping than > that. It does, indeed, throw an exception on 0. How unfortunate. > > > AGL > > > -- > Adam Langley agl@imperialviolet.org > http://www.imperialviolet.org 650-283-9641 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080201/3ed7117a/attachment.htm From answer at tnoo.net Fri Feb 1 10:56:08 2008 From: answer at tnoo.net (Martin =?iso-8859-1?Q?L=FCthi?=) Date: Fri Feb 1 17:04:19 2008 Subject: [Haskell-cafe] Re: Who started 42, and when? References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> <40190312-5D60-48CE-A04D-6894DC984E57@kingston.ac.uk> Message-ID: <871w7wacx3.fsf@tnoo.net> Hi Phil Molyneux writes: > Hi --- The arbitrary constant was made popular by Douglas Adams in the > mid-1970s radio series ``A Hitchhikers Guide to the Galaxy'' (a trilogy in 4 > parts) --- however it does have a basis in the standard model of physics --- > a paper in Phys.Rev. of the early 1970s described the unification of the > Electro-Weak and Strong nuclear forces --- the arbitrary constant (of nearly) > 42 appears in the calculations. I forget the original paper but if you get > hold of Frank Close ``The Cosmic Onion'' a graph reproduces the result. I met > Douglas Adams once at a book signing and asked him how he got hold of the > Phys.Rev. paper so early. Technically he should have written that ``42 is the > answer to life, the universe and everything except for gravity and a few > other arbitrary constants'' In the Japanese culture the number 42 has a very special meaning. I realized that while discussing cultural differences with a Japanese. Pronouncing 42 sounds like "death" or "to die". No hotel in Japan has a room 42. After knowing that it is hard to think that Doug Adams was not aware of that meaning. Best, Tinu From bbrown at botspiritcompany.com Fri Feb 1 17:05:07 2008 From: bbrown at botspiritcompany.com (bbrown) Date: Fri Feb 1 17:04:24 2008 Subject: [Haskell-cafe] Issues with hsql-sqllite build; errors from the hackage download Message-ID: <20080201220114.M74223@www.botspiritcompany.com> There seems to be an issue with the hsql-sqlite3. Anyone have a fix. Should I use what is from darcs? Index of /packages/archive/hsql-sqlite3/1.7/logs/failure The Glorious Glasgow Haskell Compilation System, version 6.8.1 $ runhaskell Setup.lhs configure Setup.lhs:7:33: Module `Distribution.Simple.Utils' does not export `rawSystemVerbose' -- Berlin Brown [berlin dot brown at gmail dot com] http://botspiritcompany.com/botlist/? From lennart at augustsson.net Fri Feb 1 17:19:17 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Feb 1 17:18:30 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: <20080201214858.GF31711@cs.cmu.edu> References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> <20080201214858.GF31711@cs.cmu.edu> Message-ID: It's a matter of taste. I prefer the function composition in this case. It reads nicely as a pipeline. -- Lennart On Fri, Feb 1, 2008 at 9:48 PM, Dan Licata wrote: > Not to start a flame war or religious debate, but I don't think that > eta-expansions should be considered bad style. I realize that > composition-style is good for certain types of reasoning, but fully > eta-expanded code has an important legibility advantage: you can tell > the shape of its type just by looking at it! Personally, I'd rather > read the original version. > > -Dan > > On Feb01, Derek Elkins wrote: > > On Fri, 2008-02-01 at 00:09 -0500, Cale Gibbard wrote: > > > Hello, > > > > > > Today on #haskell, resiak was asking about a clean way to write the > > > function which allocates an array of CStrings using withCString and > > > withArray0 to produce a new with* style function. I came up with the > > > following: > > > > > > nest :: [(r -> a) -> a] -> ([r] -> a) -> a > > > nest xs = runCont (sequence (map Cont xs)) > > > > This is what you write after all that time on #haskell? > > > > nest = runCont . sequence . map Cont > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080201/21ca5539/attachment.htm From derek.a.elkins at gmail.com Fri Feb 1 17:21:41 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Feb 1 17:21:05 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: <20080201214858.GF31711@cs.cmu.edu> References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> <20080201214858.GF31711@cs.cmu.edu> Message-ID: <1201904502.5496.81.camel@derek-laptop> On Fri, 2008-02-01 at 16:48 -0500, Dan Licata wrote: > Not to start a flame war or religious debate, but I don't think that > eta-expansions should be considered bad style. I realize that > composition-style is good for certain types of reasoning, but fully > eta-expanded code has an important legibility advantage: you can tell > the shape of its type just by looking at it! Personally, I'd rather > read the original version. Clearly you don't hang out on #haskell enough and have missed the humor. From conor at strictlypositive.org Fri Feb 1 17:29:02 2008 From: conor at strictlypositive.org (Conor McBride) Date: Fri Feb 1 17:28:00 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> <20080201214858.GF31711@cs.cmu.edu> Message-ID: Folks On 1 Feb 2008, at 22:19, Lennart Augustsson wrote: > It's a matter of taste. I prefer the function composition in this > case. > It reads nicely as a pipeline. > > -- Lennart > Dan L : > On Fri, Feb 1, 2008 at 9:48 PM, Dan Licata wrote: > Not to start a flame war or religious debate, but I don't think that > eta-expansions should be considered bad style. Cale: > > > nest :: [(r -> a) -> a] -> ([r] -> a) -> a > > > nest xs = runCont (sequence (map Cont xs)) > > Derek: > > This is what you write after all that time on #haskell? > > > > nest = runCont . sequence . map Cont Pardon my voodoo (apologies to libraries readers, but here we go again, slightly updated). With these useful general purpose goodies... > module Newtype where > import Data.Monoid > class Newtype p u | p -> u where > unpack :: p -> u > instance Newtype p u => Newtype (a -> p) (a -> u) where > unpack = (unpack .) > op :: Newtype p u => (u -> p) -> p -> u > op _ p = unpack p > wrap :: Newtype p u => (x -> y) ->(y -> p) -> x -> u > wrap pack f = unpack . f . pack > ala :: Newtype p' u' => (u -> p) -> > ((a -> p) -> b -> p') -> > (a -> u) -> b -> u' > ala pack hitWith = wrap (pack .) hitWith ...and the suitable Newtype instance for Cont, I get to write... nest = ala Cont traverse id ..separating the newtype encoding from what's really going on, fusing the map with the sequence, and generalizing to any old Traversable structure. Third-order: it's a whole other order. Conor From jerzy.karczmarczuk at info.unicaen.fr Fri Feb 1 17:43:33 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Fri Feb 1 17:42:46 2008 Subject: [Haskell-cafe] Re: Who started 42, and when? In-Reply-To: <871w7wacx3.fsf@tnoo.net> References: <6f9f8f4a0802010557g56c7457dx4227131fe63689a6@mail.gmail.com> <6f9f8f4a0802010603h4d091167p10e21a64c820b791@mail.gmail.com> <40190312-5D60-48CE-A04D-6894DC984E57@kingston.ac.uk> <871w7wacx3.fsf@tnoo.net> Message-ID: Martin L?thi: > In the Japanese culture the number 42 has a very special meaning. I > realized that while discussing cultural differences with a Japanese. > Pronouncing 42 sounds like "death" or "to die". No hotel in Japan has a > room 42. > > After knowing that it is hard to think that Doug Adams was not aware of > that meaning. Phil Molyneux: > ... it does have a basis in the standard model of physics --- > a paper in Phys.Rev. of the early 1970s described the unification of the > Electro-Weak and Strong nuclear forces --- the arbitrary constant > (of nearly) 42 appears in the calculations. I forget the original paper > but if you get hold of Frank Close ``The Cosmic Onion'' a graph > reproduces the result. I met Douglas Adams once at a book signing and > asked him how he got hold of the Phys.Rev. paper so early. Technically he > should have written that ``42 is the answer to life, the universe and > everything except for gravity and a few other arbitrary constants'' Bother...! You will discover the third (or the sixth?) moment of the Riemann zeta function which has this 42 in it, and without doubt, you will find something in Talmud and the Pyramides. And the mass of the Galaxy which is 3*10^42. And it takes light 10^(-42) sec. to cross the diameter of a proton, although if I were light, I wouldn'd do such silly thing. Fortunately I am heavy. And at least one of YOU is 42 years old, and I was once. (Yes, the number 1 which is even more magical). Perhaps before claiming before you know really something, because Adams told you so personally, you have a look here. http://groups.google.com/group/alt.fan.douglas-adams/msg/d1064f7b27808692?dm ode=source&hl=en ... And if you run a non-optimized Haskell program which computes the Fibonacci of 42, then you have to wait so long, that you must build a special Supercomputer for it. It has, BTW. been built, and it is called the "haskell-cafe mailing list". Jerzy Karczmarczuk From dons at galois.com Fri Feb 1 17:51:34 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 17:50:57 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: <1201904502.5496.81.camel@derek-laptop> References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> <20080201214858.GF31711@cs.cmu.edu> <1201904502.5496.81.camel@derek-laptop> Message-ID: <20080201225134.GH4029@scytale.galois.com> derek.a.elkins: > On Fri, 2008-02-01 at 16:48 -0500, Dan Licata wrote: > > Not to start a flame war or religious debate, but I don't think that > > eta-expansions should be considered bad style. I realize that > > composition-style is good for certain types of reasoning, but fully > > eta-expanded code has an important legibility advantage: you can tell > > the shape of its type just by looking at it! Personally, I'd rather > > read the original version. > > Clearly you don't hang out on #haskell enough and have missed the humor. For those not following, the last thing one does before comitting any Haskell code, once you've been on #haskell, is to feed it to lambdabot for "improvement" :) dons> @pl \f g (a,b) -> (f a, g b) lambdabot> flip flip snd . (ap .) . flip flip fst . ((.) .) . flip . (((.) . (,)) .) Ah, much better. We have a strange culture. -- Don From simonpj at microsoft.com Fri Feb 1 20:12:35 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 1 20:09:29 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <479F7BC9.9030406@iee.org> References: <404396ef0801280728s36dea93fn27733fc400f4e401@mail.gmail.com> <479E1415.2000908@gotadsl.co.uk> <404396ef0801281007y6a8acd90p434e6604bed15ce9@mail.gmail.com> <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> | Yes, using lots of stack is clearly bad with ghc, but this is a ghc | "bug". In fact the only reason these programs do use lots of stack | (vs. heap) is just a peculiarity of ghc rts implementation, so it | really should be ghc that fixes the problem, or at least admits | responsibility :-) I don't think there's anything fundamental here. GHC allocates the stack in the heap, and it can grow as big as you like. The size limit is simply to catch infinite recursion with a more helpful message than "heap overflow". I think. There is one peculiarity though: I don't think we ever shrink the stack, so once it gets big it stays big. This could be fixed, though. In short, feel free to set a very big max-stack size. If you are going to grow a stack of size N or a heap-allocated list of size N, the stack version will probably be more efficient -- with the caveat about deallocation that I mentioned. Simon From isaacdupree at charter.net Fri Feb 1 22:10:11 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Fri Feb 1 22:09:02 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802012205.16432.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <47A29BDC.9010709@charter.net> <200802012205.16432.g9ks157k@acme.softbase.org> Message-ID: <47A3DF13.2080106@charter.net> Wolfgang Jeltsch wrote: > Am Freitag, 1. Februar 2008 05:11 schrieben Sie: >> Wolfgang Jeltsch wrote: >>> Well, the representation (D1,D2,D9) might be considered more readable. >>> It has the disadvantage of a fixed maximum size for the numbers. Which >>> takes me to a point I had already considered some time ago: Wouldn?t it >>> be good if we had just a type >>> >>> data Pair val1 val2 = Pair val1 val2 >>> >>> and if then (val1,val2,?,valn) would just be syntactic sugar for this: >>> >>> val1 `Pair` (val2 `Pair` (?(valn `Pair` ())?)) >> I've thought of that too.. besides the asymmetry, the presence of >> _|_/seq makes them actually not equivalent though, unfortunately >> >> ~Isaac > > With Ryan?s proposal (using strictness annotations) the new representation > should be equivalent to the old one. Or am I missing something? adding the strictness annotation seems to make them equivalent, yes I agree (I hadn't seen that post when I wrote that reply) ~Isaac From derek.a.elkins at gmail.com Fri Feb 1 23:28:28 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Feb 1 23:27:45 2008 Subject: [Haskell-cafe] parsec3 pre-release Message-ID: <1201926508.5496.103.camel@derek-laptop> I'm currently getting Paolo Martini's Google Summer of Code project, an updated version of Parsec, into a releasable state, and I will be maintaining it for at least a while. Paolo's major additions are: * The Parser monad has been generalized into a Parser monad transformer * The parsers have been generalized to work over a stream of any type, in particular, with bytestrings. I have made a few minor additions as well: * There is Haddock documentation for almost all functions * The Parser monad now has Applicative/Alternative instances Currently, I am looking for people to give it a go reporting any bugs in the library or documentation, troubles building it, or changes/features they would like. I'm also interested in performance information. Most old Parsec code should be relatively easy but not trivial to port. There is a darcs repository on code.haskell.org. If nothing comes up, I'll put a package on Hackage in about a week or so. To get the code: darcs get http://code.haskell.org/ To build it, the standard cabal commands should work: http://haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package Alternatively, you can use the cabal-install application: http://hackage.haskell.org/trac/hackage/wiki/CabalInstall The documentation can be generated also via the normal cabal routine, or via cabal-install. From derek.a.elkins at gmail.com Fri Feb 1 23:53:59 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Feb 1 23:53:16 2008 Subject: [Haskell-cafe] parsec3 pre-release [important note] Message-ID: <1201928039.5496.107.camel@derek-laptop> I forgot to mention that the Text.Parsec modules should be preferred to the Text.ParserCombinators.Parsec modules as the Haddock documentation reveals. From derek.a.elkins at gmail.com Sat Feb 2 00:15:42 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Feb 2 00:15:00 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] Message-ID: <1201929342.5496.112.camel@derek-laptop> [Now with 100% more correct darcs get URLs.] I'm currently getting Paolo Martini's Google Summer of Code project, an updated version of Parsec, into a releasable state, and I will be maintaining it for at least a while. Paolo's major additions are: * The Parser monad has been generalized into a Parser monad transformer * The parsers have been generalized to work over a stream of any type, in particular, with bytestrings. I have made a few minor additions as well: * There is Haddock documentation for almost all functions * The Parser monad now has Applicative/Alternative instances Currently, I am looking for people to give it a go reporting any bugs in the library or documentation, troubles building it, or changes/features they would like. I'm also interested in performance information. Most old Parsec code should be relatively easy but not trivial to port. There is a darcs repository on code.haskell.org. If nothing comes up, I'll put a package on Hackage in about a week or so. To get the code: darcs get http://code.haskell.org/parsec3 To build it, the standard cabal commands should work: http://haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package Alternatively, you can use the cabal-install application: http://hackage.haskell.org/trac/hackage/wiki/CabalInstall The documentation can be generated also via the normal cabal routine, or via cabal-install. The Text.Parsec modules should be preferred to the Text.ParserCombinators.Parsec modules. From lpillay at webafrica.org.za Sat Feb 2 01:30:02 2008 From: lpillay at webafrica.org.za (Logesh Pillay) Date: Sat Feb 2 01:30:21 2008 Subject: [Haskell-cafe] newbie q about types Message-ID: <47A40DEA.2020107@webafrica.org.za> I have a list. Each component is a list with 2 whole numbers. I want to multiply the second number by the log of the first eg tail ([519432,525806]) * log (head [519432,525806]). I get the ffg error message: No instance for (Floating [t]) arising from a use of `log' at :1:25-50 Possible fix: add an instance declaration for (Floating [t]) In the second argument of `(*)', namely `log (head [519432, 525806])' In the expression: tail ([519432, 525806]) * log (head [519432, 525806]) In the definition of `it': it = tail ([519432, 525806]) * log (head [519432, 525806]) I've tried the only type signature I know "fromIntegral" but it does not help. How to fix? Thanks Logesh From jonathanccast at fastmail.fm Sat Feb 2 01:37:17 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sat Feb 2 01:36:36 2008 Subject: [Haskell-cafe] newbie q about types In-Reply-To: <47A40DEA.2020107@webafrica.org.za> References: <47A40DEA.2020107@webafrica.org.za> Message-ID: <2B638A2D-3398-4A25-AE1A-87E7A3D8A4E0@fastmail.fm> On 1 Feb 2008, at 10:30 PM, Logesh Pillay wrote: > I have a list. Each component is a list with 2 whole numbers. First off, why? In Haskell (unlike dynamically typed languages like Python or Perl), if you know you always have two elements, you want a pair (519432,525806), not a list [519432,525806]. > I want to multiply the second number by the log of the first > eg > tail ([519432,525806]) * log (head [519432,525806]). You mean [519432,525806] !! 1 * log ([519432,525806 !! 0) or fst (519432,525806) * log (snd (519432,525806) or (best of all) case (519432, 525806) of (x, y) -> x * log y or (if you must have a list) case [519432, 525806] of [x, y] -> x * log y > I get the ffg error message: > > No instance for (Floating [t]) This is because tail :: [t] -> [t] It doesn't give you a single element; it gives you the whole list! jcc From lrpalmer at gmail.com Sat Feb 2 01:41:03 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Feb 2 01:40:15 2008 Subject: [Haskell-cafe] newbie q about types In-Reply-To: <47A40DEA.2020107@webafrica.org.za> References: <47A40DEA.2020107@webafrica.org.za> Message-ID: <7ca3f0160802012241y2ba3028ftdca55713dd0dfa93@mail.gmail.com> Look at the type of tail: tail :: [a] -> [a] That is, tail is the list of all elements *except* the head. You want "last". (Barring style considerations. Usually in a situation like this you would use a list of tuples rather than a list of lists, since then you know at compile time that you have exactly two numbers in each element of the list). Luke On Feb 2, 2008 6:30 AM, Logesh Pillay wrote: > I have a list. Each component is a list with 2 whole numbers. I want > to multiply the second number by the log of the first > eg > tail ([519432,525806]) * log (head [519432,525806]). > > I get the ffg error message: > > No instance for (Floating [t]) > arising from a use of `log' at :1:25-50 > Possible fix: add an instance declaration for (Floating [t]) > In the second argument of `(*)', namely > `log (head [519432, 525806])' > In the expression: > tail ([519432, 525806]) * log (head [519432, 525806]) > In the definition of `it': > it = tail ([519432, 525806]) * log (head [519432, 525806]) > > > I've tried the only type signature I know "fromIntegral" but it does not > help. > > How to fix? > > Thanks > Logesh > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bulat.ziganshin at gmail.com Fri Feb 1 18:56:25 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Feb 2 02:20:31 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> <20080201214858.GF31711@cs.cmu.edu> Message-ID: <1493971874.20080202025625@gmail.com> Hello Conor, Saturday, February 2, 2008, 1:29:02 AM, you wrote: > nest = ala Cont traverse id > Third-order: it's a whole other order. oh! i remember faces of my friends when i showed them something like "sortOn snd . zip [0..]". probably i have the same face now :))) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jeff1.61803 at gmail.com Sat Feb 2 05:32:44 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Sat Feb 2 05:31:56 2008 Subject: [Haskell-cafe] Mutable arrays Message-ID: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> Hello, I'm trying to write code that will take a mutable 2D array and normalize it by dividing all elements by the largest element. I managed to write code to do this, but it seems overly complex. I could write something much simpler in Clean or C++. Most likely, my code is complex because I don't have any experience with mutable arrays in Haskell. I couldn't find any tutorials on the Internet. I'd be grateful for suggestions on simplifying the following code. Thanks. {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception #-} -- normalize_ary This takes a mutable array. Determines the largest -- element in the array (max_elem) and then divides every element by -- max_elem. normalize_ary :: (Num t1, Num t, Ix t, Ix t1, MArray a e t2, Ord e, Fractional e, Enum t, Enum t1) => a (t, t1) e -> t2 () normalize_ary ary = do -- The following two commented out lines of code show my first -- attempt at determining a value for max_elem. However, this -- produces a stack overflow. -- elem_ary <- getElems ary -- let max_elem = foldl1 max elem_ary max_elem <- calc_max_2d_elem ary max_elem `seq` map_in_place_2d_arr (\x -> x / max_elem) ary map_in_place_2d_arr :: (MArray a e t, Enum t2, Enum t1, Ix t1, Ix t2) => (e -> e) -> a (t1, t2) e -> t () map_in_place_2d_arr fn arr = ret where ret = do ((i1,j1),(i2,j2)) <- getBounds arr ( mapM_ (\i -> do v <- readArray arr i writeArray arr i (fn v) ) [(i,j) | i <- [i1..i2], j <- [j1..j2]]) calc_max_2d_elem :: (Ord t, MArray a t t1, Ix t2, Ix t3, Num t3, Num t2) => a (t3, t2) t -> t1 t calc_max_2d_elem arr = do m <- readArray arr (0,0) (_,(i_max, j_max)) <- getBounds arr let calc_max_loop arr m (i,j) | j == j_max = return m | otherwise = do e <- readArray arr (i,j) let m2 = max e m m2 `seq` calc_max_loop arr m2 nxt_idx where nxt_idx | i == i_max - 1 = (0,j+1) | otherwise = (i+1,j) calc_max_loop arr m (0,0) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080202/15382352/attachment.htm From lrpalmer at gmail.com Sat Feb 2 06:26:12 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sat Feb 2 06:25:24 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> Message-ID: <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> I prerequest your forgiveness if I sound patronizing, I'm just writing everything that comes to mind. 2008/2/2 Jeff ? : > {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception #-} > > -- normalize_ary This takes a mutable array. Determines the largest > -- element in the array (max_elem) and then divides every element by > -- max_elem. > normalize_ary :: (Num t1, > Num t, > Ix t, > Ix t1, > MArray a e t2, > Ord e, > Fractional e, > Enum t, > Enum t1) => > a (t, t1) e -> t2 () Yagh! Look at that type signature. That looks like it came from ghci. That type should raise a few alarms, such as the Num t, Num t1. Why should the indices be numbers? That indicates that your implementation is not as general as it should be, so maybe try another method. (Really it's calc_max_2d_elem which is losing that generality). I usually write my type signatures first, and then let that guide my implementation. But you will find differing valid opinions on this list on that issue. Anyway, without further ado, into the guts we go. > normalize_ary ary = > do > -- The following two commented out lines of code show my first > -- attempt at determining a value for max_elem. However, this > -- produces a stack overflow. > > -- elem_ary <- getElems ary > -- let max_elem = foldl1 max elem_ary Hmm, how big is the array? If it's pretty big, that's understandable. Frankly, it's because foldl sucks: I have never seen a reason to use it. You should be using the strict variant foldl' here. (I don't think there is a foldl1'). And that will get rid of your big function calc_max_2d_elem. > > max_elem <- calc_max_2d_elem ary > max_elem `seq` map_in_place_2d_arr (\x -> x / max_elem) ary I don't think that max_elem `seq` is doing anything useful here (but I could be missing something subtle). Oh and a really low level thing which may or may not make a difference: floating point division is expensive. You'd be better off precalculating 1 / max_elem and then multiplying by that instead. > map_in_place_2d_arr :: (MArray a e t, Enum t2, Enum t1, Ix t1, Ix t2) => > (e -> e) -> a (t1, t2) e -> t () Another conspicuous type signature. Enum t2, Enum t1 is the red flag here. It's because you're using [i1..i2] instead of range (i1,i2) from Data.Ix. > map_in_place_2d_arr fn arr = ret > where > ret = do ((i1,j1),(i2,j2)) <- getBounds arr > ( mapM_ (\i -> do v <- readArray arr i > writeArray arr i (fn v) ) > [(i,j) | i <- [i1..i2], j <- [j1..j2]]) This looks pretty good modulo the [i1..i2] I mentioned above. For this kind of stuff I prefer to use forM_, as it is a more imperative-looking construct for imperative-looking code (then you can lose the parentheses around (\i -> ...))... > calc_max_2d_elem :: (Ord t, MArray a t t1, Ix t2, Ix t3, Num t3, Num t2) => > a (t3, t2) t -> t1 t > calc_max_2d_elem arr = > do m <- readArray arr (0,0) > (_,(i_max, j_max)) <- getBounds arr > let calc_max_loop arr m (i,j) > | j == j_max = return m > | otherwise = do e <- readArray arr (i,j) > let m2 = max e m > m2 `seq` calc_max_loop arr m2 nxt_idx > where nxt_idx | i == i_max - 1 = (0,j+1) > | otherwise = (i+1,j) > calc_max_loop arr m (0,0) Hopefully we have done away with this thing given the foldl' thing. There are a lot of implicit assumptions hiding in this code, such as indices being zero-based integers. Writing your type signature first would have caught those assumptions, since you wouldn't have had (Num t3, Num t2) ;-). Luke From alfonso.acosta at gmail.com Sat Feb 2 07:46:10 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 2 07:45:22 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802012233.28126.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> <200802012233.28126.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802020446v6daaf9c2i25e2713ec268101f@mail.gmail.com> On Feb 1, 2008 10:33 PM, Wolfgang Jeltsch wrote: > > Actually it would maybe be better to create common high-level > > interface that could include unary, binary and decimal arithmetic so > > that the library could be easily reused in other projects (people like > > Bjorn, seem to be using the unary implementation). I don't know if it > > would be feasible though. > > I'd say, let's start with the decimal thing. We can extend our package later > if there's a need to do this, can't we? OK, let's do it like that. From overdrigzed at gmail.com Sat Feb 2 07:57:47 2008 From: overdrigzed at gmail.com (Rodrigo Queiro) Date: Sat Feb 2 07:56:58 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> Message-ID: <2eb8984a0802020457s68850ffg5d8dc8432a2aa3c4@mail.gmail.com> This is my attempt at some nicer code: maximum' (x:xs) = foldl' max x xs maximum' _ = undefined modifyArray :: (MArray a e m, Ix i) => (e -> e) -> a i e -> m () modifyArray fn arr = do bounds <- getBounds arr forM_ (range bounds) (modifyElement fn arr) modifyElement :: (MArray a e m, Ix i) => (e -> e) -> a i e -> i -> m () modifyElement fn arr i = do x <- readArray arr i writeArray arr i (fn x) normalizeArray :: (MArray a e m, Ix i, Fractional e, Ord e) => a i e -> m () normalizeArray arr = do arr_elems <- getElems arr let max_elem = maximum' arr_elems modifyArray (/max_elem) arr On 02/02/2008, Jeff ? wrote: > Hello, > > I'm trying to write code that will take a mutable 2D array and normalize it > by dividing all elements by the largest element. > > I managed to write code to do this, but it seems overly complex. I could > write something much simpler in Clean or C++. Most likely, my code is > complex because I don't have any experience with mutable arrays in Haskell. > I couldn't find any tutorials on the Internet. I'd be grateful for > suggestions on simplifying the following code. Thanks. > > > {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception #-} > > -- normalize_ary This takes a mutable array. Determines the largest > -- element in the array (max_elem) and then divides every element by > -- max_elem. > normalize_ary :: (Num t1, > Num t, > Ix t, > Ix t1, > MArray a e t2, > Ord e, > Fractional e, > Enum t, > Enum t1) => > a (t, t1) e -> t2 () > normalize_ary ary = > do > -- The following two commented out lines of code show my first > -- attempt at determining a value for max_elem. However, this > -- produces a stack overflow. > > -- elem_ary <- getElems ary > -- let max_elem = foldl1 max elem_ary > > max_elem <- calc_max_2d_elem ary > max_elem `seq` map_in_place_2d_arr (\x -> x / max_elem) ary > > > map_in_place_2d_arr :: (MArray a e t, Enum t2, Enum t1, Ix t1, Ix t2) => > (e -> e) -> a (t1, t2) e -> t () > map_in_place_2d_arr fn arr = ret > where > ret = do ((i1,j1),(i2,j2)) <- getBounds arr > ( mapM_ (\i -> do v <- readArray arr i > writeArray arr i (fn v) > ) > [(i,j) | i <- [i1..i2], j <- [j1..j2]]) > > > calc_max_2d_elem :: (Ord t, MArray a t t1, Ix t2, Ix t3, Num t3, Num t2) => > a (t3, t2) t -> t1 t > calc_max_2d_elem arr = > do m <- readArray arr (0,0) > (_,(i_max, j_max)) <- getBounds arr > let calc_max_loop arr m (i,j) > | j == j_max = return m > | otherwise = do e <- readArray arr (i,j) > let m2 = max e m > m2 `seq` calc_max_loop > arr m2 nxt_idx > where nxt_idx | i == i_max - 1 = (0,j+1) > | otherwise = (i+1,j) > calc_max_loop arr m (0,0) > > > _______________________________________________ > 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/20080202/0575fc32/attachment.htm From overdrigzed at gmail.com Sat Feb 2 08:11:58 2008 From: overdrigzed at gmail.com (Rodrigo Queiro) Date: Sat Feb 2 08:11:09 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <2eb8984a0802020457s68850ffg5d8dc8432a2aa3c4@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <2eb8984a0802020457s68850ffg5d8dc8432a2aa3c4@mail.gmail.com> Message-ID: <2eb8984a0802020511y3215cce2m698d2af2baa562d8@mail.gmail.com> Sorry, I was lazy. New maximum': maximum' = foldl1' max On 02/02/2008, Rodrigo Queiro wrote: > > This is my attempt at some nicer code: > > maximum' (x:xs) = foldl' max x xs > maximum' _ = undefined > > modifyArray :: (MArray a e m, Ix i) => (e -> e) -> a i e -> m () > modifyArray fn arr = do > bounds <- getBounds arr > forM_ (range bounds) (modifyElement fn arr) > > modifyElement :: (MArray a e m, Ix i) => (e -> e) -> a i e -> i -> m () > modifyElement fn arr i = do > x <- readArray arr i > writeArray arr i (fn x) > > normalizeArray :: (MArray a e m, Ix i, Fractional e, Ord e) => a i e -> m > () > normalizeArray arr = do > arr_elems <- getElems arr > let max_elem = maximum' arr_elems > modifyArray (/max_elem) arr > > On 02/02/2008, Jeff ? wrote: > > Hello, > > > > I'm trying to write code that will take a mutable 2D array and normalize > it > > by dividing all elements by the largest element. > > > > I managed to write code to do this, but it seems overly complex. I > could > > write something much simpler in Clean or C++. Most likely, my code is > > complex because I don't have any experience with mutable arrays in > Haskell. > > I couldn't find any tutorials on the Internet. I'd be grateful for > > suggestions on simplifying the following code. Thanks. > > > > > > {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception #-} > > > > -- normalize_ary This takes a mutable array. Determines the largest > > -- element in the array (max_elem) and then divides every element by > > -- max_elem. > > normalize_ary :: (Num t1, > > Num t, > > Ix t, > > Ix t1, > > MArray a e t2, > > Ord e, > > Fractional e, > > Enum t, > > Enum t1) => > > a (t, t1) e -> t2 () > > normalize_ary ary = > > do > > -- The following two commented out lines of code show my first > > -- attempt at determining a value for max_elem. However, this > > -- produces a stack overflow. > > > > -- elem_ary <- getElems ary > > -- let max_elem = foldl1 max elem_ary > > > > max_elem <- calc_max_2d_elem ary > > max_elem `seq` map_in_place_2d_arr (\x -> x / max_elem) ary > > > > > > map_in_place_2d_arr :: (MArray a e t, Enum t2, Enum t1, Ix t1, Ix t2) > => > > (e -> e) -> a (t1, t2) e -> t () > > map_in_place_2d_arr fn arr = ret > > where > > ret = do ((i1,j1),(i2,j2)) <- getBounds arr > > ( mapM_ (\i -> do v <- readArray arr i > > writeArray arr i (fn v) > > ) > > [(i,j) | i <- [i1..i2], j <- [j1..j2]]) > > > > > > calc_max_2d_elem :: (Ord t, MArray a t t1, Ix t2, Ix t3, Num t3, Num t2) > => > > a (t3, t2) t -> t1 t > > calc_max_2d_elem arr = > > do m <- readArray arr (0,0) > > (_,(i_max, j_max)) <- getBounds arr > > let calc_max_loop arr m (i,j) > > | j == j_max = return m > > | otherwise = do e <- readArray arr (i,j) > > let m2 = max e m > > m2 `seq` calc_max_loop > > arr m2 nxt_idx > > where nxt_idx | i == i_max - 1 = (0,j+1) > > | otherwise = (i+1,j) > > calc_max_loop arr m (0,0) > > > > > > _______________________________________________ > > 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/20080202/657476c9/attachment.htm From alfonso.acosta at gmail.com Sat Feb 2 08:54:59 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 2 08:54:10 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802012232.16922.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <200802012232.16922.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch wrote: > Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta: > > On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch > > > This is essentially what I had in mind. While Oleg's implementation > > > needs a "thrusted core", the GADT solution doesn't. > > > > True. However using GADTs doesn't allow to internally make use of > > Arrays, which (tell me if I'm wrong) are likely to be faster than the > > naive GADT implementation. > > It depends. My first GADT implementation is equivalent to the [] type and > often [] is better than arrays. For example, if you read the contents of a > file and process it with maps, filters, etc., [] is likely to give you > constant space usage which arrays don't. If you want to lookup elements by > index, then arrays are better, of course. For my purpose, it would be fine > to use a []-like implementation, I think. For mine it would be fine too. Let's implement our needs and then maybe extend it if someone rants about it. > > To make it friendlier for the end user I thought about defining > > aliases for lets say the first 10000 numbers using Template Haskell. > > That could even make error reports friendlier (not sure to what point > > though). What do you think? > > I have no clear opinion about that at the moment. Maybe it's okay to use the > representation directly. This way, we don't introduce a dependeny on the > Template Haskell language extension (which is only supported by GHC), and the > actual representation will occur in error messages anyway whenever the > message shows a computed number. Well, my EDSL already makes extensive use of TH. So, being selfish, it wouldn't be a problem for me (or any other GHC user) and I think it would make the library much more usable. Just compare f :: List (() :- D1 :- D0 :- D0 :- 1000) Int -> List (() :- D1 :- D0 :- D0 :- D0) Int with, let's say f :: List A1000 Int -> List A1000 Int Again, if someone complains about the TH dependency, the aliases could be generated by TH but saved statically in a module for each release. > > So, we'll be making two separate libraries then. We should think about > > names. > > > > What about FixedVector for the vector library and DecTypArith (maybe > > too long) or DecTypes for the type-level decimal arithmetic library? > > Alas, there is an inconsistency in naming packages already. Some prefer names > which are entirely lowercase, some prefer camel case. I prefer lowercase, > with hyphens separating parts of the name. And I also don't like unusual > abbreviations like "typ" (not much shorter than "type"). To mention > arithmetics is not so important. So maybe something > like "type-level-decimals"? > > Maybe it's better to put different type-level programming things into a single > package. Then we could name this package "type-level" or something similar. > We could start with our decimals. Other type-level things could be added > later. I already have some code about type-level booleans. It's not very > sensible to put these few lines into a separate package. It might be nice if > we had a general type-level programming package where I could put this code > into. Sounds sensible. However, I would rather prefer something like type-level-comp (from type level computations) or type-level-prog (from type level programming). Type level by itself doesn't describe the functionality of the package. > As for the name of the fixed-size list package, I have to say that I don't > like the term "vector" in this context. A vector is actually something with > addition and scalar multiplication defined on it. Maybe we should make also > this package's scope wider. What about something like "safe-data" or > similar? I think safe-data is a bit too general and might lead to confusion with other safe data packages (namely Mitchell's Safe library). Since the main particularity of the library is that safety properties are achieved via "emulating" dependent types I think that light-dependent-types (from lightweight dependent types), number-parameterized-data or simply parameterized-data (this is the name I like best) would be more appropiate. From alfonso.acosta at gmail.com Sat Feb 2 10:04:37 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 2 10:03:47 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <200802012232.16922.g9ks157k@acme.softbase.org> <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> Message-ID: <6a7c66fc0802020704j10ffd3a7m602d5d19e18602a9@mail.gmail.com> On Feb 2, 2008 2:54 PM, Alfonso Acosta wrote: > Just compare > > f :: List (() :- D1 :- D0 :- D0 :- 1000) Int -> List (() :- D1 :- D0 > :- D0 :- D0) Int I meant f :: List (() :- D1 :- D0 :- D0 :- D0) Int -> List (() :- D1 :- D0 :- D0 :- D0) Int sorry for the typo From duncan.coutts at worc.ox.ac.uk Sat Feb 2 10:08:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 10:07:30 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <47A30596.6080209@therning.org> References: <47A30596.6080209@therning.org> Message-ID: <1201964896.13130.132.camel@localhost> On Fri, 2008-02-01 at 11:42 +0000, Magnus Therning wrote: > Is it possible to get Cabal to use 'cl' (Microsoft's C/C++ compiler > shipped with Visual Studio Express)? The problem is to get GHC to use 'cl'. That's a longer term project that GHC HQ are interested in. There's something about it on the GHC dev wiki I think. Don't hold your breath. > I've found the Wiki page on using Visual Studio to create a DLL, then > convert it to a .a file so that GHC can consume it. I'd rather skip > using Visual Studio to build things and just ship a Cabalised package. You can create .dlls without using VS of course, if that's what you're trying to do. Duncan From duncan.coutts at worc.ox.ac.uk Sat Feb 2 10:16:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 10:15:19 2008 Subject: [Haskell-cafe] Issues with hsql-sqllite build; errors from the hackage download In-Reply-To: <20080201220114.M74223@www.botspiritcompany.com> References: <20080201220114.M74223@www.botspiritcompany.com> Message-ID: <1201965366.13130.140.camel@localhost> On Fri, 2008-02-01 at 17:05 -0500, bbrown wrote: > There seems to be an issue with the hsql-sqlite3. Anyone have a fix. Should > I use what is from darcs? HSQL is currently unmaintained. Frederik Eaton was considering taking it over: http://www.nabble.com/HSQL-defunct--td14978532.html Gentoo has a fix: http://haskell.org/~gentoo/gentoo-haskell/dev-haskell/hsql-sqlite/hsql-sqlite-1.7.ebuild The code in src_unpack() is replacing the Setup.hs with a default copy and then adding 'extra-libraries: sqlite3' to the .cabal file. Pretty straightforward. This does assume that you have sqlite3 installed in the default global location. You may also like to consider alternatives like HDBC-sqlite3. Duncan From s.clover at gmail.com Sat Feb 2 12:07:07 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sat Feb 2 12:06:23 2008 Subject: [Haskell-cafe] Issues with hsql-sqllite build; errors from the hackage download In-Reply-To: <1201965366.13130.140.camel@localhost> References: <20080201220114.M74223@www.botspiritcompany.com> <1201965366.13130.140.camel@localhost> Message-ID: <57BA8DFB-346D-422E-8F00-F2FE45F523B1@gmail.com> Just noticed, by the way, that haskelldb doesn't build correctly because it still hasn't updated the cabal for the base split. On the other hand, the development repo (which is 0.11 -- 0.10 is on hackage) builds fine. Are the maintainers planning to get an updated version on hackage? --S On Feb 2, 2008, at 10:16 AM, Duncan Coutts wrote: > > On Fri, 2008-02-01 at 17:05 -0500, bbrown wrote: >> There seems to be an issue with the hsql-sqlite3. Anyone have a >> fix. Should >> I use what is from darcs? > > HSQL is currently unmaintained. Frederik Eaton was considering > taking it > over: http://www.nabble.com/HSQL-defunct--td14978532.html > > Gentoo has a fix: > http://haskell.org/~gentoo/gentoo-haskell/dev-haskell/hsql-sqlite/ > hsql-sqlite-1.7.ebuild > The code in src_unpack() is replacing the Setup.hs with a default copy > and then adding 'extra-libraries: sqlite3' to the .cabal file. Pretty > straightforward. This does assume that you have sqlite3 installed > in the > default global location. > > You may also like to consider alternatives like HDBC-sqlite3. > > Duncan > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From chaddai.fouche at gmail.com Sat Feb 2 12:11:58 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Sat Feb 2 12:11:08 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <2eb8984a0802020511y3215cce2m698d2af2baa562d8@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <2eb8984a0802020457s68850ffg5d8dc8432a2aa3c4@mail.gmail.com> <2eb8984a0802020511y3215cce2m698d2af2baa562d8@mail.gmail.com> Message-ID: 2008/2/2, Rodrigo Queiro : > Sorry, I was lazy. New maximum': > maximum' = foldl1' max Sorry but none of those propositions change the heart of the problem : the list of elements is totally produced before she can be consumed due to the strict monadic (IO or ST) nature of getElems. Thus you get an extraordinary waste of memory as well as resources... To address this I propose this function : foldl1MArray' :: (MArray a e m, Ix i) => (e -> e -> e) -> a i e -> m e foldl1MArray' f a = do (l,u) <- getBounds a firstElem <- readArray a l foldM (\a mb -> a `seq` mb >>= return . f a) firstElem (map (readArray a) (range (l,u))) With this, we can rewrite the original program using the excellent modifyArray from Rodrigo : normalizeArray :: (MArray a e m, Ix i, Fractional e, Ord e) => a i e -> m () normalizeArray arr = do max_elem <- foldl1MArray' max arr modifyArray (* (1/max_elem)) arr -- Jeda? From fmartini at gmail.com Sat Feb 2 12:15:27 2008 From: fmartini at gmail.com (Felix Martini) Date: Sat Feb 2 12:14:38 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <1201964896.13130.132.camel@localhost> References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> Message-ID: <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> Magnus Therning wrote: > Is it possible to get Cabal to use 'cl' (Microsoft's C/C++ compiler > shipped with Visual Studio Express)? Duncan Coutts wrote: > The problem is to get GHC to use 'cl'. That's a longer term project that > GHC HQ are interested in. There's something about it on the GHC dev wiki > I think. Don't hold your breath. When using the native code generator only foreign C code must be compiled with a C compiler. Presently Cabal passes C sources that are listed in the 'c-sources' field of a cabal file to GHC. It would be nice to have a Cabal field to specify the compiler for C sources, say 'c-sources-compiler: msvc'. The default would still be gcc, but with a Cabal flag the user would be able to change that to e.g. Sun's C compiler. From dbueno at gmail.com Sat Feb 2 12:26:18 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Feb 2 12:25:29 2008 Subject: [Haskell-cafe] Re: HList error with hFoldr In-Reply-To: <20080128054545.D2E52A97B@Adric.metnet.fnmoc.navy.mil> References: <6dbd4d000801260803g7db6415co640dd78afcbe9f85@mail.gmail.com> <20080128054545.D2E52A97B@Adric.metnet.fnmoc.navy.mil> Message-ID: <6dbd4d000802020926y62715485kc0a5b0eaadb1caec@mail.gmail.com> On Jan 28, 2008 12:45 AM, wrote: > It seems strange that you need the types e and e' (perhaps this is a > quirk or a bug of GHC 6.8). With GHC 6.6, I have derived the following > > > instance (Floating f, MetricSpace e f, HFoldr ApplyDistSum Float l1 f, > HZip (HCons e l) (HCons e l) (HCons (e,e) l1)) > => MetricSpace (HCons e l) f where > c `dist` c' = sqrt $ hFoldr ApplyDistSum (0::Float) (hZip c c') > > which matches my intuitive understanding, and also sufficient to run > the given examples. This also works in GHC 6.8. Thanks! > When I wrote `I derived with GHC' I meant it literally. First I wrote > the instance without any constraints: > > instance () > => MetricSpace (HCons e l) f where > c `dist` c' = sqrt $ hFoldr ApplyDistSum (0::Float) (hZip c c') > > GHC of course complained about many missing constraints. I started > adding the constraints from the list of complaints, until GHC was > satisfied. This is basically a cut-and-paste job from the Emacs buffer > with GHC error messages to the buffer with the code. Wow. I will try this next time I post. Thanks very much. -- Denis From stefanor at cox.net Sat Feb 2 12:28:15 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Feb 2 12:27:26 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <2eb8984a0802020457s68850ffg5d8dc8432a2aa3c4@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <2eb8984a0802020457s68850ffg5d8dc8432a2aa3c4@mail.gmail.com> Message-ID: <20080202172815.GA3596@localhost.localdomain> On Sat, Feb 02, 2008 at 12:57:47PM +0000, Rodrigo Queiro wrote: > This is my attempt at some nicer code: > > maximum' (x:xs) = foldl' max x xs > maximum' _ = undefined > > modifyArray :: (MArray a e m, Ix i) => (e -> e) -> a i e -> m () > modifyArray fn arr = do > bounds <- getBounds arr > forM_ (range bounds) (modifyElement fn arr) > > modifyElement :: (MArray a e m, Ix i) => (e -> e) -> a i e -> i -> m () > modifyElement fn arr i = do > x <- readArray arr i > writeArray arr i (fn x) > > normalizeArray :: (MArray a e m, Ix i, Fractional e, Ord e) => a i e -> m () > normalizeArray arr = do > arr_elems <- getElems arr > let max_elem = maximum' arr_elems > modifyArray (/max_elem) arr Note that by using getElems, you are throwing away most of the advantages of arrays, since it is strict (it has to be, since it's effectively an IO function and lazy IO is unsound wrt Haskell's normal semantics) and converts the whole thing into a list. If I just had this one bit of code to do, I'd use explicit loop: normalizeArray arr = do b <- getBounds arr ; m <- findMax b forM_ (range b) (edit m) where findMax (i:is) = findMax' is =<< readArray arr i findMax' (i:is) !v = findMax' is . max v =<< readArray arr i findMax' [] !v = return v edit mx i = writeArray arr i . (/mx) =<< readArray arr i With a little more, I'd probably set the scene with a few array-modifying combinators, inspired by Oleg's left-fold idea: -- yes, I'm passing four arguments to foldr. this is not a mistake. foldA fn ac arr = getBounds arr >>= \b -> foldr (\ i ct acc -> ct =<< fn i ac =<< readArray arr i) (\_ -> return ac) (range b) ac foldAp fn = foldA (\i a b -> return (fn a b)) maxA = foldAp max minBound mapA fn ar = foldA (\i _ v -> writeArray ar i (fn v)) () ar normalize arr = maxA arr >>= \ m -> mapA (/m) arr 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/20080202/847dfb44/attachment.bin From dbueno at gmail.com Sat Feb 2 12:33:38 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Feb 2 12:32:47 2008 Subject: [Haskell-cafe] Refactoring from State monad to ST monad, for STUArray Message-ID: <6dbd4d000802020933s3eb42ce4ne8c0afcf305717ab@mail.gmail.com> Is it possible to use the ST monad as a (drop-in) replacement for the State monad in the following situation? If not, is there a "best practice" for refactoring? I have a bunch of functions that return state actions: type MyState = ... foo1 :: T1 -> State MyState a foo2 :: T2 -> State MyState a ... foon :: Tn -> State MyState a And I'd like to refactor this to use the ST monad, mechanically, if possible. All uses of the MyState inside State are single-threaded. In my application, MyState is a record with 5 or so fields. One of those fields uses a list to keep track of some information, and I'd like to change that to STUArray, because it changes my bottleneck operations from O(n) to O(1). This, of course, requires having the ST monad around, in order to achieve the proper time complexity. Is there an easy way to do this? In the future, should I *start out* with the ST monad if I suspect I'll need to use an imperative data structure for efficiency reasons? I started out with State because I'm modeling a transition system, so it seemed natural. Any advice is appreciated. -- Denis From duncan.coutts at worc.ox.ac.uk Sat Feb 2 12:45:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 12:44:15 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> Message-ID: <1201974303.13130.145.camel@localhost> On Sat, 2008-02-02 at 18:15 +0100, Felix Martini wrote: > Magnus Therning wrote: > > Is it possible to get Cabal to use 'cl' (Microsoft's C/C++ compiler > > shipped with Visual Studio Express)? > > Duncan Coutts wrote: > > The problem is to get GHC to use 'cl'. That's a longer term project that > > GHC HQ are interested in. There's something about it on the GHC dev wiki > > I think. Don't hold your breath. > > When using the native code generator only foreign C code must be > compiled with a C compiler. Presently Cabal passes C sources that are > listed in the 'c-sources' field of a cabal file to GHC. It would be > nice to have a Cabal field to specify the compiler for C sources, say > 'c-sources-compiler: msvc'. The default would still be gcc, but with a > Cabal flag the user would be able to change that to e.g. Sun's C > compiler. It would be reasonable to use the system C compiler rather than ghc, however we will have to do more work to find what extra include dirs get used and have Cabal pass those. Currently we pass the -package flags to ghc which ghc uses to look up what include dirs those packages add, and then it calls the C compiler with those extra include dirs. Cabal would have to do that itself. Duncan From derek.a.elkins at gmail.com Sat Feb 2 12:05:12 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Feb 2 13:05:10 2008 Subject: [Haskell-cafe] Refactoring from State monad to ST monad, for STUArray In-Reply-To: <6dbd4d000802020933s3eb42ce4ne8c0afcf305717ab@mail.gmail.com> References: <6dbd4d000802020933s3eb42ce4ne8c0afcf305717ab@mail.gmail.com> Message-ID: <1201971913.5496.117.camel@derek-laptop> On Sat, 2008-02-02 at 12:33 -0500, Denis Bueno wrote: > Is it possible to use the ST monad as a (drop-in) replacement for the > State monad in the following situation? If not, is there a "best > practice" for refactoring? > > I have a bunch of functions that return state actions: > > type MyState = ... > > foo1 :: T1 -> State MyState a > foo2 :: T2 -> State MyState a > ... > foon :: Tn -> State MyState a > > And I'd like to refactor this to use the ST monad, mechanically, if > possible. All uses of the MyState inside State are single-threaded. > > In my application, MyState is a record with 5 or so fields. One of > those fields uses a list to keep track of some information, and I'd > like to change that to STUArray, because it changes my bottleneck > operations from O(n) to O(1). This, of course, requires having the ST > monad around, in order to achieve the proper time complexity. > > Is there an easy way to do this? In the future, should I *start out* > with the ST monad if I suspect I'll need to use an imperative data > structure for efficiency reasons? I started out with State because > I'm modeling a transition system, so it seemed natural. > > Any advice is appreciated. %s/State MyState/MyMonad s/g type MyState s = ... s ... type MyMonad s = StateT (MyState s) (ST s) From magnus at therning.org Sat Feb 2 13:50:58 2008 From: magnus at therning.org (Magnus Therning) Date: Sat Feb 2 13:50:22 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <1201974303.13130.145.camel@localhost> References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> <1201974303.13130.145.camel@localhost> Message-ID: <47A4BB92.6030104@therning.org> Duncan Coutts wrote: [..] > It would be reasonable to use the system C compiler rather than ghc, > however we will have to do more work to find what extra include dirs get > used and have Cabal pass those. > > Currently we pass the -package flags to ghc which ghc uses to look up > what include dirs those packages add, and then it calls the C compiler > with those extra include dirs. Cabal would have to do that itself. Well it sounds like I'll have to settle for a two-step build procedure for the time being. Luckily I managed to recall the existence of CMake just today, so it seems I can make my Haskell-hacking-on-Windows experience somewhat bearable... /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080202/e0182c1d/signature.bin From duncan.coutts at worc.ox.ac.uk Sat Feb 2 14:06:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 14:05:54 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <47A4BB92.6030104@therning.org> References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> <1201974303.13130.145.camel@localhost> <47A4BB92.6030104@therning.org> Message-ID: <1201979201.13130.155.camel@localhost> On Sat, 2008-02-02 at 18:50 +0000, Magnus Therning wrote: > Duncan Coutts wrote: > [..] > > It would be reasonable to use the system C compiler rather than ghc, > > however we will have to do more work to find what extra include dirs get > > used and have Cabal pass those. > > > > Currently we pass the -package flags to ghc which ghc uses to look up > > what include dirs those packages add, and then it calls the C compiler > > with those extra include dirs. Cabal would have to do that itself. > > Well it sounds like I'll have to settle for a two-step build procedure > for the time being. Luckily I managed to recall the existence of CMake > just today, so it seems I can make my Haskell-hacking-on-Windows > experience somewhat bearable... Just so I'm sure I understand... So you're building a .dll using just C code and then you want to link that in with a Haskell prog that uses that .dll. And it is essential that the C code be built using MS's C compiler and not gcc. Is that right? And you'd like to have the .dll built using Cabal rather than having to hack an external C/Makefile. Or are you just trying to link some C code statically into a haskell program, but it just so happens that this C code relies on being built with MS's C compiler rather than gcc. Perhaps you could clarify what it is you're trying to do (the end goal, just just the minutia) so we can see what feature it is that Cabal is missing that would help your situation. When we figure that out we can file a feature request so it is not forgotten. Duncan From ryani.spam at gmail.com Sat Feb 2 14:57:57 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sat Feb 2 14:57:07 2008 Subject: [Haskell-cafe] Refactoring from State monad to ST monad, for STUArray In-Reply-To: <1201971913.5496.117.camel@derek-laptop> References: <6dbd4d000802020933s3eb42ce4ne8c0afcf305717ab@mail.gmail.com> <1201971913.5496.117.camel@derek-laptop> Message-ID: <2f9b2d30802021157q343304e4lff22b0927e3a32d@mail.gmail.com> You can also do something like the following: newtype StateST st s a = StateST { internalRunStateST :: ReaderT (STRef st s) (ST st) a } instance MonadState s (StateST s st) where get = ask >>= readSTRef put s = ask >>= \ref -> writeSTRef ref s runStateST :: StateST st s a -> s -> ST st a runStateST m s = do ref <- newSTRef s runReaderT (internalRunStateST m) ref -- ryan On Feb 2, 2008 9:05 AM, Derek Elkins wrote: > On Sat, 2008-02-02 at 12:33 -0500, Denis Bueno wrote: > > Is it possible to use the ST monad as a (drop-in) replacement for the > > State monad in the following situation? If not, is there a "best > > practice" for refactoring? > > > > I have a bunch of functions that return state actions: > > > > type MyState = ... > > > > foo1 :: T1 -> State MyState a > > foo2 :: T2 -> State MyState a > > ... > > foon :: Tn -> State MyState a > > > > And I'd like to refactor this to use the ST monad, mechanically, if > > possible. All uses of the MyState inside State are single-threaded. > > > > In my application, MyState is a record with 5 or so fields. One of > > those fields uses a list to keep track of some information, and I'd > > like to change that to STUArray, because it changes my bottleneck > > operations from O(n) to O(1). This, of course, requires having the ST > > monad around, in order to achieve the proper time complexity. > > > > Is there an easy way to do this? In the future, should I *start out* > > with the ST monad if I suspect I'll need to use an imperative data > > structure for efficiency reasons? I started out with State because > > I'm modeling a transition system, so it seemed natural. > > > > Any advice is appreciated. > > %s/State MyState/MyMonad s/g > > type MyState s = ... s ... > > type MyMonad s = StateT (MyState s) (ST s) > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From bjorn at bringert.net Sat Feb 2 15:19:47 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Sat Feb 2 15:18:57 2008 Subject: [Haskell-cafe] Issues with hsql-sqllite build; errors from the hackage download In-Reply-To: <57BA8DFB-346D-422E-8F00-F2FE45F523B1@gmail.com> References: <20080201220114.M74223@www.botspiritcompany.com> <1201965366.13130.140.camel@localhost> <57BA8DFB-346D-422E-8F00-F2FE45F523B1@gmail.com> Message-ID: Yes. It would be nice to have an updated HSQL release first though. /Bj?rn On Feb 2, 2008 6:07 PM, Sterling Clover wrote: > Just noticed, by the way, that haskelldb doesn't build correctly > because it still hasn't updated the cabal for the base split. On the > other hand, the development repo (which is 0.11 -- 0.10 is on > hackage) builds fine. Are the maintainers planning to get an updated > version on hackage? > > --S > > > On Feb 2, 2008, at 10:16 AM, Duncan Coutts wrote: > > > > > On Fri, 2008-02-01 at 17:05 -0500, bbrown wrote: > >> There seems to be an issue with the hsql-sqlite3. Anyone have a > >> fix. Should > >> I use what is from darcs? > > > > HSQL is currently unmaintained. Frederik Eaton was considering > > taking it > > over: http://www.nabble.com/HSQL-defunct--td14978532.html > > > > Gentoo has a fix: > > http://haskell.org/~gentoo/gentoo-haskell/dev-haskell/hsql-sqlite/ > > hsql-sqlite-1.7.ebuild > > The code in src_unpack() is replacing the Setup.hs with a default copy > > and then adding 'extra-libraries: sqlite3' to the .cabal file. Pretty > > straightforward. This does assume that you have sqlite3 installed > > in the > > default global location. > > > > You may also like to consider alternatives like HDBC-sqlite3. > > > > Duncan > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lemming at henning-thielemann.de Sat Feb 2 15:34:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Feb 2 15:34:14 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> Message-ID: On Sat, 2 Feb 2008, [ISO-8859-7] Jeff ? wrote: > Hello, > > I'm trying to write code that will take a mutable 2D array and normalize it > by dividing all elements by the largest element. Are you sure you need the arrays to be mutable? Maybe it's fast enough to do the copying - it's significantly easier anyway. If all operations run over the whole array, like the normalization, then it's not much a matter speed, but only a matter of memory. That is you need the double amount of memory, because the data can be processed and copied forth and back. You can even reduce this further, if you can come up with an optimizer fusion framework. With immutable arrays you can easily implement let xm = maximum (Array.elems arr) in fmap (/xm) arr Ok, better use the strict "maximum'" proposed by others in this thread. From jgm at berkeley.edu Sat Feb 2 16:42:36 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Sat Feb 2 16:38:29 2008 Subject: [Haskell-cafe] highlighting-kate - syntax highlighting library Message-ID: <20080202214236.GA12497@berkeley.edu> Hello all, I've been working on a source code syntax highlighting library. It is now somewhat usable, and help would be welcome in testing it further, so I'm making it publicly available: darcs get http://johnmacfarlane.net/repos/highlighting-kate Currently, the following languages are supported: Ada Asp Awk Bash Bibtex C Cmake Coldfusion Commonlisp Cpp Css D Diff Djangotemplate Doxygen Dtd Erlang Fortran Haskell Html Java Javadoc Javascript Json Latex Lex LiterateHaskell Lua Makefile Matlab Mediawiki Nasm Objectivec Objectivecpp Ocaml Pascal Perl Php Postscript Prolog Python Ruby Scala Scheme Sgml Sql SqlMysql SqlPostgresql Tcl Texinfo Xml Xslt Yacc The parsers for individual languages are automatically generated from Kate syntax definitions. The xml files have been included in the repository, together with the program that converts them to Haskell modules. There's also a standalone program, Highlight, that you can use to test the highlighting. (See README for instructions.) Bug reports and patches are welcome. Note that I don't want to make any manual modifications to the generated modules in Text/Highlighting/Kate/Syntax. Changes should be made either in the source xml files or in the program ParseSyntaxFiles.hs that generates these modules. John From newsham at lava.net Sat Feb 2 16:43:32 2008 From: newsham at lava.net (Tim Newsham) Date: Sat Feb 2 16:42:44 2008 Subject: [Haskell-cafe] weird behavior with FFI Message-ID: I am working on haskell bindings to C functions using FFI. I have a callback function that returns "IO ()". When I pass in the callback function: foo = printf "foo" it crashes (is there an easy way to debug this exception using ghc6.8.2?) bot: SilcClient_d1al: uncaught exception however, if I pass in the callback function: foo = do printf "foo" return () it does not crash. Is this a bug in my bindings? In ghc/ffi? Full code is at: http://www.thenewsh.com/%7Enewsham/silcbot.tgz Tim Newsham http://www.thenewsh.com/~newsham/ From dbueno at gmail.com Sat Feb 2 17:17:00 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Feb 2 17:16:10 2008 Subject: [Haskell-cafe] Refactoring from State monad to ST monad, for STUArray In-Reply-To: <2f9b2d30802021157q343304e4lff22b0927e3a32d@mail.gmail.com> References: <6dbd4d000802020933s3eb42ce4ne8c0afcf305717ab@mail.gmail.com> <1201971913.5496.117.camel@derek-laptop> <2f9b2d30802021157q343304e4lff22b0927e3a32d@mail.gmail.com> Message-ID: <6dbd4d000802021417n7516ef4fy578a4eedc8081f0a@mail.gmail.com> Thanks for all the responses. I have never used monad transformers before, but StateT is welcome and really cool. I didn't even think to look them up. I have a follow up question. I eventually get to a point where I have a value of type (ST s (Maybe (STUArray s Int Int))), and I need somehow to get rid of the Maybe, so I can call runSTUArray on it. The function containing this value returns a pure type: > data Solution = Sat (UArray Int Int) | Unsat deriving (Eq) I've included the function body below, along with a few comments that hopefully make my problem clear enough. Let me know if there's any more detail needed: > solve :: StdGen -> Cnf -> Solution > solve rnd cnf = > -- To solve, we simply take baby steps toward the solution using solveStep, > -- starting with the empty assignment. > Sat . runSTUArray $ > do solution <- -- this block, as you can see, > -- is the (ST s (STUArray s Int Int)) value > evalStateT (stepToSolution $ do > initialAssignment <- lift (newArray (1, numVars cnf) 0) > solveStep initialAssignment) > SC{cnf=cnf, dm=Map.empty, dl=[], bad=Set.empty, rnd=rnd} > case solution of -- `solution' is the (Maybe (STUArray s Int Int)) value > Nothing -> error "unsat" > Just m -> return m Using `error' in the Nothing case is exactly what I'd like to avoid. How should I improve this? On Feb 2, 2008 2:57 PM, Ryan Ingram wrote: > You can also do something like the following: > > newtype StateST st s a = StateST { internalRunStateST :: ReaderT > (STRef st s) (ST st) a } > > instance MonadState s (StateST s st) where > get = ask >>= readSTRef > put s = ask >>= \ref -> writeSTRef ref s > > runStateST :: StateST st s a -> s -> ST st a > runStateST m s = do > ref <- newSTRef s > runReaderT (internalRunStateST m) ref > > -- ryan > > > > On Feb 2, 2008 9:05 AM, Derek Elkins wrote: > > On Sat, 2008-02-02 at 12:33 -0500, Denis Bueno wrote: > > > Is it possible to use the ST monad as a (drop-in) replacement for the > > > State monad in the following situation? If not, is there a "best > > > practice" for refactoring? > > > > > > I have a bunch of functions that return state actions: > > > > > > type MyState = ... > > > > > > foo1 :: T1 -> State MyState a > > > foo2 :: T2 -> State MyState a > > > ... > > > foon :: Tn -> State MyState a > > > > > > And I'd like to refactor this to use the ST monad, mechanically, if > > > possible. All uses of the MyState inside State are single-threaded. > > > > > > In my application, MyState is a record with 5 or so fields. One of > > > those fields uses a list to keep track of some information, and I'd > > > like to change that to STUArray, because it changes my bottleneck > > > operations from O(n) to O(1). This, of course, requires having the ST > > > monad around, in order to achieve the proper time complexity. > > > > > > Is there an easy way to do this? In the future, should I *start out* > > > with the ST monad if I suspect I'll need to use an imperative data > > > structure for efficiency reasons? I started out with State because > > > I'm modeling a transition system, so it seemed natural. > > > > > > Any advice is appreciated. > > > > %s/State MyState/MyMonad s/g > > > > type MyState s = ... s ... > > > > type MyMonad s = StateT (MyState s) (ST s) > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -- Denis From magnus at therning.org Sat Feb 2 17:33:28 2008 From: magnus at therning.org (Magnus Therning) Date: Sat Feb 2 17:32:48 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <1201979201.13130.155.camel@localhost> References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> <1201974303.13130.145.camel@localhost> <47A4BB92.6030104@therning.org> <1201979201.13130.155.camel@localhost> Message-ID: <47A4EFB8.3040802@therning.org> Duncan Coutts wrote: [..] > Just so I'm sure I understand... Sure thing. > Or are you just trying to link some C code statically into a haskell > program, but it just so happens that this C code relies on being built > with MS's C compiler rather than gcc. Yes, this is exactly it. I mean, I could probably hack the incomplete mingw header files to add the functions I need, but I thought it'd be much easier to just use Microsoft's development environment. > Perhaps you could clarify what it is you're trying to do (the end goal, > just just the minutia) so we can see what feature it is that Cabal is > missing that would help your situation. When we figure that out we can > file a feature request so it is not forgotten. The end goal is to sneak Haskell into the work place ;-) What I'd really like to see is the ability to ?drive? development completely from Haskell. With that I mean to, just as on Linux, have a single cabal file that compiles the C code containing the wrappers while still having access to a complete development environment. On Windows that means compiling C/C++ with MS's tool set. I hope that clarifies what goes on in my muddy mind a bit... /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080202/e52c853c/signature.bin From l.mai at web.de Sat Feb 2 17:41:05 2008 From: l.mai at web.de (Lukas Mai) Date: Sat Feb 2 17:40:18 2008 Subject: [Haskell-cafe] weird behavior with FFI In-Reply-To: References: Message-ID: <200802022341.06332.l.mai@web.de> Am Samstag, 2. Februar 2008 schrieb Tim Newsham: > I am working on haskell bindings to C functions using FFI. I have > a callback function that returns "IO ()". When I pass in the callback > function: > foo = printf "foo" > > it crashes (is there an easy way to debug this exception using ghc6.8.2?) > bot: SilcClient_d1al: uncaught exception > > however, if I pass in the callback function: > foo = do > printf "foo" > return () > > it does not crash. I suspect this has to do with printf returning 'undefined' if you use it with an IO type. Something in the code looks at the result and crashes. Your second version is equivalent to printf "foo" >>= \_ -> return (), i.e. it never evaluates printf's result but returns () instead. Fixing the first version would require some changes to Text.Printf, restricting the 'a' in PrintfType (IO a). HTH, Lukas From newsham at lava.net Sat Feb 2 17:47:17 2008 From: newsham at lava.net (Tim Newsham) Date: Sat Feb 2 17:46:27 2008 Subject: [Haskell-cafe] weird behavior with FFI In-Reply-To: <200802022341.06332.l.mai@web.de> References: <200802022341.06332.l.mai@web.de> Message-ID: > Am Samstag, 2. Februar 2008 schrieb Tim Newsham: >> I am working on haskell bindings to C functions using FFI. I have >> a callback function that returns "IO ()". When I pass in the callback >> function: > I suspect this has to do with printf returning 'undefined' if you use it > with an IO type. Something in the code looks at the result and crashes. > Your second version is equivalent to printf "foo" >>= \_ -> return (), > i.e. it never evaluates printf's result but returns () instead. > Fixing the first version would require some changes to Text.Printf, > restricting the 'a' in PrintfType (IO a). But the callback function is already of type "IO ()" as mentioned above. > HTH, Lukas Tim Newsham http://www.thenewsh.com/~newsham/ From daniel.is.fischer at web.de Sat Feb 2 17:51:18 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Feb 2 17:48:58 2008 Subject: [Haskell-cafe] Refactoring from State monad to ST monad, for STUArray In-Reply-To: <6dbd4d000802021417n7516ef4fy578a4eedc8081f0a@mail.gmail.com> References: <6dbd4d000802020933s3eb42ce4ne8c0afcf305717ab@mail.gmail.com> <2f9b2d30802021157q343304e4lff22b0927e3a32d@mail.gmail.com> <6dbd4d000802021417n7516ef4fy578a4eedc8081f0a@mail.gmail.com> Message-ID: <200802022351.18371.daniel.is.fischer@web.de> Am Samstag, 2. Februar 2008 23:17 schrieb Denis Bueno: > Thanks for all the responses. I have never used monad transformers > before, but StateT is welcome and really cool. I didn't even think to > look them up. > > I have a follow up question. I eventually get to a point where I have > a value of type (ST s (Maybe (STUArray s Int Int))), and I need > somehow to get rid of the Maybe, so I can call runSTUArray on it. The > > function containing this value returns a pure type: > > data Solution = Sat (UArray Int Int) | Unsat deriving (Eq) > > I've included the function body below, along with a few comments that > hopefully make my problem clear enough. Let me know if there's any > > more detail needed: > > solve :: StdGen -> Cnf -> Solution > > solve rnd cnf = > > -- To solve, we simply take baby steps toward the solution using > > solveStep, -- starting with the empty assignment. > > Sat . runSTUArray $ > > do solution <- -- this block, as you can see, > > -- is the (ST s (STUArray s Int Int)) value > > evalStateT (stepToSolution $ do > > initialAssignment <- lift (newArray (1, numVars > > cnf) 0) solveStep initialAssignment) > > SC{cnf=cnf, dm=Map.empty, dl=[], bad=Set.empty, rnd=rnd} > > case solution of -- `solution' is the (Maybe (STUArray s Int Int)) > > value Nothing -> error "unsat" > > Just m -> return m > > Using `error' in the Nothing case is exactly what I'd like to avoid. > How should I improve this? Would solve rnd cnf = case evalStateT ... of Nothing -> Unsat Just st -> Sat $ runSTUArray st work? Might need some explicit 'forall s.' or not typecheck at all, didn't test. From daniel.is.fischer at web.de Sat Feb 2 17:58:02 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Feb 2 17:55:42 2008 Subject: [Haskell-cafe] Refactoring from State monad to ST monad, for STUArray In-Reply-To: <200802022351.18371.daniel.is.fischer@web.de> References: <6dbd4d000802020933s3eb42ce4ne8c0afcf305717ab@mail.gmail.com> <6dbd4d000802021417n7516ef4fy578a4eedc8081f0a@mail.gmail.com> <200802022351.18371.daniel.is.fischer@web.de> Message-ID: <200802022358.02645.daniel.is.fischer@web.de> Am Samstag, 2. Februar 2008 23:51 schrieb Daniel Fischer: > Am Samstag, 2. Februar 2008 23:17 schrieb Denis Bueno: > > Thanks for all the responses. I have never used monad transformers > > before, but StateT is welcome and really cool. I didn't even think to > > look them up. > > > > I have a follow up question. I eventually get to a point where I have > > a value of type (ST s (Maybe (STUArray s Int Int))), and I need > > somehow to get rid of the Maybe, so I can call runSTUArray on it. The > > > > function containing this value returns a pure type: > > > data Solution = Sat (UArray Int Int) | Unsat deriving (Eq) > > > > I've included the function body below, along with a few comments that > > hopefully make my problem clear enough. Let me know if there's any > > > > more detail needed: > > > solve :: StdGen -> Cnf -> Solution > > > solve rnd cnf = > > > -- To solve, we simply take baby steps toward the solution using > > > solveStep, -- starting with the empty assignment. > > > Sat . runSTUArray $ > > > do solution <- -- this block, as you can see, > > > -- is the (ST s (STUArray s Int Int)) value > > > evalStateT (stepToSolution $ do > > > initialAssignment <- lift (newArray (1, numVars > > > cnf) 0) solveStep initialAssignment) > > > SC{cnf=cnf, dm=Map.empty, dl=[], bad=Set.empty, rnd=rnd} > > > case solution of -- `solution' is the (Maybe (STUArray s Int > > > Int)) value Nothing -> error "unsat" > > > Just m -> return m > > > > Using `error' in the Nothing case is exactly what I'd like to avoid. > > How should I improve this? > > Would > > solve rnd cnf = > case evalStateT ... of > Nothing -> Unsat > Just st -> Sat $ runSTUArray st > > work? Might need some explicit 'forall s.' or not typecheck at all, didn't > test. > Obviously not. Try solve rnd cnf = runST $ do solution <- evalStateT ... case solution of Nothing -> return Unsat Just ar -> unsafeFreeze ar From aslatter at gmail.com Sat Feb 2 18:28:07 2008 From: aslatter at gmail.com (Antoine Latter) Date: Sat Feb 2 18:27:16 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <1201929342.5496.112.camel@derek-laptop> References: <1201929342.5496.112.camel@derek-laptop> Message-ID: <694519c50802021528l6269618bx860127aee2f2458e@mail.gmail.com> I'm not a fan of parameterizing the "Stream" class over the monad parameter `m': > class Stream s m t | s -> t where > uncons :: s -> m (Maybe (t,s)) which leads to instance declarations like so: > instance Monad m => Stream [tok] m tok where > uncons [] = return $ Nothing > uncons (t:ts) = return $ Just (t,ts) I looked through the sources and I didn't see anywhere where this parameterization gained anything. As a proof of this I did a mechanical re-write removing the class parameter, and the library still seems to work. -Antoine On Feb 1, 2008 11:15 PM, Derek Elkins wrote: > [Now with 100% more correct darcs get URLs.] > > I'm currently getting Paolo Martini's Google Summer of Code project, an > updated version of Parsec, into a releasable state, and I will be > maintaining it for at least a while. > > Paolo's major additions are: > * The Parser monad has been generalized into a Parser monad > transformer > * The parsers have been generalized to work over a stream of any > type, in particular, with bytestrings. > > I have made a few minor additions as well: > * There is Haddock documentation for almost all functions > * The Parser monad now has Applicative/Alternative instances > > Currently, I am looking for people to give it a go reporting any bugs in > the library or documentation, troubles building it, or changes/features > they would like. I'm also interested in performance information. > > Most old Parsec code should be relatively easy but not trivial to port. > There is a darcs repository on code.haskell.org. If nothing comes up, > I'll put a package on Hackage in about a week or so. > > To get the code: > darcs get http://code.haskell.org/parsec3 > > To build it, the standard cabal commands should work: > http://haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package > > Alternatively, you can use the cabal-install application: > http://hackage.haskell.org/trac/hackage/wiki/CabalInstall > > The documentation can be generated also via the normal cabal routine, or > via cabal-install. > > The Text.Parsec modules should be preferred to the > Text.ParserCombinators.Parsec modules. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ben at bridesmere.com Sat Feb 2 18:41:16 2008 From: ben at bridesmere.com (Ben Butler-Cole) Date: Sat Feb 2 18:40:28 2008 Subject: [Haskell-cafe] Circular enums Message-ID: <675097.37121.qm@web30801.mail.mud.yahoo.com> Hello I'm trying to define functions that allow you to traverse a bounded enumeration, "wrapping" at the start and the end. My implementation looks like this: next, prev :: (Enum a, Bounded a) => a -> a next = turn 1 prev = turn (-1) turn :: (Enum a, Bounded a) => Int -> a -> a turn n e = toEnum (add (fromEnum (maxBound::a) + 1) (fromEnum e) n) where add mod x y = (x + y + mod) `rem` mod Which fails to type check under GHC with this error: No instance for (Bounded a) arising from use of `maxBound' at Hbot.hs:6:34-41 Probable fix: add (Bounded a) to the expected type of an expression In the expression: maxBound :: a In the first argument of `fromEnum', namely `(maxBound :: a)' In the first argument of `(+)', namely `fromEnum (maxBound :: a)' My (clearly flawed) understanding of the signature I've specified for 'turn' means *exactly* that a is Bounded. Can anyone enlighten me as to where my understanding is going awry and how (whether) I can achieve what I'm trying to do. Thank you Ben From ben at bridesmere.com Sat Feb 2 18:45:47 2008 From: ben at bridesmere.com (Ben Butler-Cole) Date: Sat Feb 2 18:44:57 2008 Subject: [Haskell-cafe] Circular enums - resend Message-ID: <39004.24296.qm@web30803.mail.mud.yahoo.com> [Resending with formatting fixed.] Hello I'm trying to define functions that allow you to traverse a bounded enumeration, "wrapping" at the start and the end. My implementation looks like this: next, prev :: (Enum a, Bounded a) => a -> a next = turn 1 prev = turn (-1) turn :: (Enum a, Bounded a) => Int -> a -> a turn n e = toEnum (add (fromEnum (maxBound::a) + 1) (fromEnum e) n) where add mod x y = (x + y + mod) `rem` mod Which fails to type check under GHC with this error: No instance for (Bounded a) arising from use of `maxBound' at Hbot.hs:6:34-41 Probable fix: add (Bounded a) to the expected type of an expression In the expression: maxBound :: a In the first argument of `fromEnum', namely `(maxBound :: a)' In the first argument of `(+)', namely `fromEnum (maxBound :: a)' My (clearly flawed) understanding of the signature I've specified for 'turn' means *exactly* that a is Bounded. Can anyone enlighten me as to where my understanding is going awry and how (whether) I can achieve what I'm trying to do. Thank you Ben From allbery at ece.cmu.edu Sat Feb 2 18:47:17 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Feb 2 18:46:29 2008 Subject: [Haskell-cafe] Circular enums In-Reply-To: <675097.37121.qm@web30801.mail.mud.yahoo.com> References: <675097.37121.qm@web30801.mail.mud.yahoo.com> Message-ID: On Feb 2, 2008, at 18:41 , Ben Butler-Cole wrote: > No instance for (Bounded a) > arising from use of `maxBound' at Hbot.hs:6:34-41 > (...) > My (clearly flawed) understanding of the signature I've specified > for 'turn' means *exactly* that a is Bounded. The problem is that the scope of a is the type signature; it does *not* extend to the definition. You can try omitting the type on maxBound and minBound, or you can enable the scoped type variables extension ( http://www.haskell.org/ ghc/docs/latest/html/users_guide/other-type-extensions.html#scoped- type-variables ). -- 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 ben at bridesmere.com Sat Feb 2 18:47:39 2008 From: ben at bridesmere.com (Ben Butler-Cole) Date: Sat Feb 2 18:46:49 2008 Subject: [Haskell-cafe] Circular enums Message-ID: <887459.84442.qm@web30805.mail.mud.yahoo.com> [Resend with formatting maybe fixed.] Hello I'm trying to define functions that allow you to traverse a bounded enumeration, "wrapping" at the start and the end. My implementation looks like this: next, prev :: (Enum a, Bounded a) => a -> a next = turn 1 prev = turn (-1) turn :: (Enum a, Bounded a) => Int -> a -> a turn n e = toEnum (add (fromEnum (maxBound::a) + 1) (fromEnum e) n) where add mod x y = (x + y + mod) `rem` mod Which fails to type check under GHC with this error: No instance for (Bounded a) arising from use of `maxBound' at Hbot.hs:6:34-41 Probable fix: add (Bounded a) to the expected type of an expression In the expression: maxBound :: a In the first argument of `fromEnum', namely `(maxBound :: a)' In the first argument of `(+)', namely `fromEnum (maxBound :: a)' My (clearly flawed) understanding of the signature I've specified for 'turn' means *exactly* that a is Bounded. Can anyone enlighten me as to where my understanding is going awry and how (whether) I can achieve what I'm trying to do. Thank you Ben From ben at bridesmere.com Sat Feb 2 19:05:58 2008 From: ben at bridesmere.com (Ben Butler-Cole) Date: Sat Feb 2 19:05:07 2008 Subject: [Haskell-cafe] Circular enums Message-ID: <894573.13138.qm@web30808.mail.mud.yahoo.com> On Feb 2, 2008, at 18:41 , I wrote: > No instance for (Bounded a) > arising from use of `maxBound' at Hbot.hs:6:34-41 > (...) > My (clearly flawed) understanding of the signature I've specified > for 'turn' means *exactly* that a is Bounded. Brandon Allbery replied: > The problem is that the scope of a is the type signature; it does > *not* extend to the definition. > > You can try omitting the type on maxBound and minBound, or you > can enable the scoped type variables extension Thank you. This compiles fine with the Glasgow extensions turned on as long as the type in the function signature is universally quantified: turn :: forall a. (Enum a, Bounded a) => Int -> a -> a turn n e = toEnum (add (fromEnum (maxBound::a) + 1) (fromEnum e) n) where add mod x y = (x + y + mod) `rem` mod From newsham at lava.net Sat Feb 2 20:24:40 2008 From: newsham at lava.net (Tim Newsham) Date: Sat Feb 2 20:23:50 2008 Subject: [Haskell-cafe] strange GHC assembler failure Message-ID: I'm getting a weird build error: [ 9 of 95] Compiling Plugin.Pl.Common ( Plugin/Pl/Common.hs, dist/build/lambdabot/lambdabot-tmp/Plugin/Pl/Common.o ) /tmp/ghc52608_0/ghc52608_0.s: Assembler messages: /tmp/ghc52608_0/ghc52608_0.s:36:0: Error: unassigned file number 1 [... more of these ...] I narrowed this down -- this happens when I add my new library "silc-client" to the "Build-depends:" line in the cabal file even if none of its code is referenced. Removing the dependency makes the error go away. The module I'm referencing is a new one I'm still working on and it makes use of FFI and references external headers and libraries. (I put a copy at http://www.thenewsh.com/~newsham/silc-client.tgz if it helps anyone debug.. this is not release-quality code though). Any idea what is going on here? Tim Newsham http://www.thenewsh.com/~newsham/ From dbueno at gmail.com Sat Feb 2 20:37:14 2008 From: dbueno at gmail.com (Denis Bueno) Date: Sat Feb 2 20:36:23 2008 Subject: [Haskell-cafe] Refactoring from State monad to ST monad, for STUArray In-Reply-To: <200802022358.02645.daniel.is.fischer@web.de> References: <6dbd4d000802020933s3eb42ce4ne8c0afcf305717ab@mail.gmail.com> <6dbd4d000802021417n7516ef4fy578a4eedc8081f0a@mail.gmail.com> <200802022351.18371.daniel.is.fischer@web.de> <200802022358.02645.daniel.is.fischer@web.de> Message-ID: <6dbd4d000802021737w3b88c2f1s56ab1c68b591dc4@mail.gmail.com> On Feb 2, 2008 5:58 PM, Daniel Fischer wrote: > Obviously not. > Try > solve rnd cnf = runST $ do > solution <- evalStateT ... > case solution of > Nothing -> return Unsat > Just ar -> unsafeFreeze ar > Ah, right. Thanks. This worked. -- Denis From flippa at flippac.org Sat Feb 2 20:49:02 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Sat Feb 2 20:47:56 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <694519c50802021528l6269618bx860127aee2f2458e@mail.gmail.com> References: <1201929342.5496.112.camel@derek-laptop> <694519c50802021528l6269618bx860127aee2f2458e@mail.gmail.com> Message-ID: On Sat, 2 Feb 2008, Antoine Latter wrote: > I'm not a fan of parameterizing the "Stream" class over the monad > parameter `m': > I looked through the sources and I didn't see anywhere where this > parameterization gained anything. As a proof of this I did a > mechanical re-write removing the class parameter, and the library > still seems to work. > AngloHaskell attendees may remember the quickie I did on handling the layout rule via a parsing monad transformer - removing this would stop me from generating the input stream in a particular monad and break the trick behind it. The idea was to use a lexing monad which the parser would be stacked on top of, such that the parser could communicate with the lexer and delayout function. Then when the parser failed at a point where a closing brace would allow parsing to continue, it could backtrack in the stream, tell the lexer that it failed the first time and ask for the character again - and if the layout rule allows it at that point, the returned character would this time be a closing brace. -- flippa@flippac.org Performance anxiety leads to premature optimisation From duncan.coutts at worc.ox.ac.uk Sat Feb 2 21:24:22 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 2 21:23:33 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <47A4EFB8.3040802@therning.org> References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> <1201974303.13130.145.camel@localhost> <47A4BB92.6030104@therning.org> <1201979201.13130.155.camel@localhost> <47A4EFB8.3040802@therning.org> Message-ID: <1202005462.13130.224.camel@localhost> On Sat, 2008-02-02 at 22:33 +0000, Magnus Therning wrote: > Duncan Coutts wrote: > [..] > > Just so I'm sure I understand... > > Sure thing. > > > Or are you just trying to link some C code statically into a haskell > > program, but it just so happens that this C code relies on being built > > with MS's C compiler rather than gcc. > > Yes, this is exactly it. I mean, I could probably hack the incomplete > mingw header files to add the functions I need, but I thought it'd be > much easier to just use Microsoft's development environment. > > > Perhaps you could clarify what it is you're trying to do (the end goal, > > just just the minutia) so we can see what feature it is that Cabal is > > missing that would help your situation. When we figure that out we can > > file a feature request so it is not forgotten. > > The end goal is to sneak Haskell into the work place ;-) > > What I'd really like to see is the ability to ?drive? development > completely from Haskell. With that I mean to, just as on Linux, have a > single cabal file that compiles the C code containing the wrappers while > still having access to a complete development environment. On Windows > that means compiling C/C++ with MS's tool set. > > I hope that clarifies what goes on in my muddy mind a bit... Ok, so you could create a separate component to produce the .dll / .a from the C code but you'd prefer the convenience of being able to just: c-sources: blah.c and have them included in the project, but built using the MS C compiler. So I think we should file a feature request about building C sources using gcc/ms-c directly rather than going via ghc as that would give us the flexibility to use alternative C compilers. Perhaps you'd like to file it, otherwise I can. http://hackage.haskell.org/trac/hackage/ Duncan From aslatter at gmail.com Sat Feb 2 21:43:09 2008 From: aslatter at gmail.com (Antoine Latter) Date: Sat Feb 2 21:42:20 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <694519c50802021528l6269618bx860127aee2f2458e@mail.gmail.com> References: <1201929342.5496.112.camel@derek-laptop> <694519c50802021528l6269618bx860127aee2f2458e@mail.gmail.com> Message-ID: <694519c50802021843v1d7e64f4h815e267d5b1b75de@mail.gmail.com> On Feb 2, 2008 5:28 PM, Antoine Latter wrote: > I'm not a fan of parameterizing the "Stream" class over the monad parameter `m': > > > class Stream s m t | s -> t where > > uncons :: s -> m (Maybe (t,s)) > > which leads to instance declarations like so: > > > instance Monad m => Stream [tok] m tok where > > uncons [] = return $ Nothing > > uncons (t:ts) = return $ Just (t,ts) > To expand on this point, side-effect instances of Stream don't play nice with the backtracking in Text.Parsec.Prim.try: > import Text.Parsec > import Text.Parsec.Prim > import System.IO > import Control.Monad > type Parser a = (Stream s m Char) => ParsecT s u m a This particular instance was suggested by Derek. > instance Stream Handle IO Char where > uncons hdl = do > b <- hIsEOF hdl > if b then return Nothing > else liftM (\c -> Just (c,hdl)) getChar > testParser :: Parser String > testParser = try (string "hello1") <|> string "hello2" > test1 = runPT testParser () "stdin" stdin >>= print > test2 = hGetLine stdin >>= print . runP testParser () "stdin" "test1" uses the (Stream Handle IO Char) instance, "test2" uses the (Monad m => Stream [a] m a) instance. For input "hello2", test2 produces a valid parse while test1 does not. -Antoine From flippa at flippac.org Sat Feb 2 21:59:46 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Sat Feb 2 21:58:27 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <694519c50802021843v1d7e64f4h815e267d5b1b75de@mail.gmail.com> References: <1201929342.5496.112.camel@derek-laptop> <694519c50802021528l6269618bx860127aee2f2458e@mail.gmail.com> <694519c50802021843v1d7e64f4h815e267d5b1b75de@mail.gmail.com> Message-ID: On Sat, 2 Feb 2008, Antoine Latter wrote: > To expand on this point, side-effect instances of Stream don't play > nice with the backtracking in Text.Parsec.Prim.try: > > > import Text.Parsec > > import Text.Parsec.Prim > > import System.IO > > import Control.Monad > > > type Parser a = (Stream s m Char) => ParsecT s u m a > > This particular instance was suggested by Derek. > We've been kicking this around on IRC a little, it took me a moment to remember the problem. Basically the problem isn't parsec/try playing badly with the stream - it's the stream playing badly with parsec/try. You need to keep track of where in the file you are and either cache it in an IORef or use seek to jump about appropriately. At the moment, Derek's instance doesn't know where it is in the stream so Parsec's backtracking is invisible to the underlying monad. That caching is the source of the potential leak I mentioned to you, because Parsec doesn't currently tell the stream when it's committed up to a given point and anything preceding it can be dropped safely. We'll tell the list a nice story about this over the coming week. For now, it's nearly 3am here and I should get to bed! -- flippa@flippac.org The task of the academic is not to scale great intellectual mountains, but to flatten them. From derek.a.elkins at gmail.com Sat Feb 2 21:14:08 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Feb 2 22:14:36 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <694519c50802021843v1d7e64f4h815e267d5b1b75de@mail.gmail.com> References: <1201929342.5496.112.camel@derek-laptop> <694519c50802021528l6269618bx860127aee2f2458e@mail.gmail.com> <694519c50802021843v1d7e64f4h815e267d5b1b75de@mail.gmail.com> Message-ID: <1202004848.5537.25.camel@derek-laptop> On Sat, 2008-02-02 at 20:43 -0600, Antoine Latter wrote: > On Feb 2, 2008 5:28 PM, Antoine Latter wrote: > > I'm not a fan of parameterizing the "Stream" class over the monad parameter `m': > > > > > class Stream s m t | s -> t where > > > uncons :: s -> m (Maybe (t,s)) > > > > which leads to instance declarations like so: > > > > > instance Monad m => Stream [tok] m tok where > > > uncons [] = return $ Nothing > > > uncons (t:ts) = return $ Just (t,ts) > > > > To expand on this point, side-effect instances of Stream don't play > nice with the backtracking in Text.Parsec.Prim.try: > > > import Text.Parsec > > import Text.Parsec.Prim > > import System.IO > > import Control.Monad > > > type Parser a = (Stream s m Char) => ParsecT s u m a > > This particular instance was suggested by Derek. > > > instance Stream Handle IO Char where > > uncons hdl = do > > b <- hIsEOF hdl > > if b then return Nothing > > else liftM (\c -> Just (c,hdl)) getChar > > > testParser :: Parser String > > testParser = try (string "hello1") <|> string "hello2" > > > test1 = runPT testParser () "stdin" stdin >>= print > > test2 = hGetLine stdin >>= print . runP testParser () "stdin" > > "test1" uses the (Stream Handle IO Char) instance, "test2" uses the > (Monad m => Stream [a] m a) instance. > > For input "hello2", test2 produces a valid parse while test1 does not. Note that instance has a typo in it (which I fixed before testing this myself): getChar should be (hGetChar hdl) (though that makes no difference when you pass in stdin) From gwern0 at gmail.com Sat Feb 2 23:11:27 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Sat Feb 2 23:11:47 2008 Subject: [Haskell-cafe] ANN: Hlist 0.1 on Hackage Message-ID: <20080203041126.GA577630@localhost> Hey everyone: I'd like to make a short announcement that with the permission of its maintainer, I've uploaded HList v0.1 to Hackage. You can find the Hackage page here: . 'cabal install HList' should also work. HList for those who don't know is a sort of OO Haskell package which permits heterogeneous lists; you can find out more at . (The Darcs repository is at .) What changes have been made to the darcs repo? Well, they are mostly updates and cleanups - I've updated build-depends for GHC 6.8.x; largely moved from -fglasgow-exts to LANGUAGE pragmas; put the modules in a proper module namespace; fixed up Haddock generation; removed some unused files, and other things of that nature. -- gwern Covert data bank Armani Larson Missiles Dick CTP SO13 AUTODIN -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080202/25c5c145/attachment.bin From uhollerbach at gmail.com Sun Feb 3 03:04:48 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Sun Feb 3 03:03:56 2008 Subject: [Haskell-cafe] more haskeem: it's just scheme in haskell now, no more "almost" Message-ID: <65d7a7e0802030004k5d6d5ef3h15943695d702276b@mail.gmail.com> Hello, haskellers, my mud pies are getting bigger: I have added an exception-handling mechanism to haskeem (ie, for handling exceptions at the scheme level, not the haskell level; that was already working), and also hooked up the REPL to gnu readline: the example code for the readline command was practically tailor-made for me! :-) Also, I must apologize: I screwed up the URL earlier: I had said http://www.korgwal.com/software/haskeem/ and then promptly went and stuck it into http://www.korgwal.com/haskeem/ ... you may attribute that to rapidly-advancing senility, if you like, I won't contradict you. Anyway, I've fixed it by simply putting copies into both places. regards, Uwe Hollerbach From magnus at therning.org Sun Feb 3 06:31:14 2008 From: magnus at therning.org (Magnus Therning) Date: Sun Feb 3 06:30:27 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <1202005462.13130.224.camel@localhost> References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> <1201974303.13130.145.camel@localhost> <47A4BB92.6030104@therning.org> <1201979201.13130.155.camel@localhost> <47A4EFB8.3040802@therning.org> <1202005462.13130.224.camel@localhost> Message-ID: <47A5A602.5030806@therning.org> Duncan Coutts wrote: > On Sat, 2008-02-02 at 22:33 +0000, Magnus Therning wrote: >> Duncan Coutts wrote: >> [..] >>> Just so I'm sure I understand... >> Sure thing. >> >>> Or are you just trying to link some C code statically into a haskell >>> program, but it just so happens that this C code relies on being built >>> with MS's C compiler rather than gcc. >> Yes, this is exactly it. I mean, I could probably hack the incomplete >> mingw header files to add the functions I need, but I thought it'd be >> much easier to just use Microsoft's development environment. >> >>> Perhaps you could clarify what it is you're trying to do (the end goal, >>> just just the minutia) so we can see what feature it is that Cabal is >>> missing that would help your situation. When we figure that out we can >>> file a feature request so it is not forgotten. >> The end goal is to sneak Haskell into the work place ;-) >> >> What I'd really like to see is the ability to ?drive? development >> completely from Haskell. With that I mean to, just as on Linux, have a >> single cabal file that compiles the C code containing the wrappers while >> still having access to a complete development environment. On Windows >> that means compiling C/C++ with MS's tool set. >> >> I hope that clarifies what goes on in my muddy mind a bit... > > Ok, so you could create a separate component to produce the .dll / .a > from the C code but you'd prefer the convenience of being able to just: > c-sources: blah.c > and have them included in the project, but built using the MS C > compiler. > > So I think we should file a feature request about building C sources > using gcc/ms-c directly rather than going via ghc as that would give us > the flexibility to use alternative C compilers. > > Perhaps you'd like to file it, otherwise I can. > http://hackage.haskell.org/trac/hackage/ I raised ticket 229 for this issue. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080203/bbd2f785/signature.bin From bulat.ziganshin at gmail.com Sun Feb 3 09:17:03 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Feb 3 12:00:01 2008 Subject: [Haskell-cafe] Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: <1202005462.13130.224.camel@localhost> References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> <1201974303.13130.145.camel@localhost> <47A4BB92.6030104@therning.org> <1201979201.13130.155.camel@localhost> <47A4EFB8.3040802@therning.org> <1202005462.13130.224.camel@localhost> Message-ID: <647493922.20080203171703@gmail.com> Hello Duncan, Sunday, February 3, 2008, 5:24:22 AM, you wrote: > Ok, so you could create a separate component to produce the .dll / .a > from the C code but you'd prefer the convenience of being able to just: > c-sources: blah.c > and have them included in the project, but built using the MS C > compiler. > So I think we should file a feature request about building C sources > using gcc/ms-c directly rather than going via ghc as that would give us > the flexibility to use alternative C compilers. sorry, i think it's not whole story. gcc and msvc are probably incompatible in the meaning that you can't link together code produced by two compilers. exactly dll should be generated which allow to avoids this incompatibility -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From daniil.elovkov at googlemail.com Sun Feb 3 13:40:19 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Sun Feb 3 13:39:30 2008 Subject: [Haskell-cafe] SPJ on the radio (at .NET Rocks :) In-Reply-To: <20080124082743.GA4390@scytale.galois.com> References: <20080124082743.GA4390@scytale.galois.com> Message-ID: <47A60A93.3060408@gmail.com> It's great to see that Haskell and FP gains more and more visibility. One very little comment, continuing on the topic of mathematical schools and traditions: Sh?nfinkel was not a German mathematician, but a Soviet one (he was Jewish, of course). Taking into account the fact that he already worked before 1917, he can also be called Russian mathematician, probably. And also Ukrainian, since he seems to have been born in Ukraine. Don Stewart wrote: > Simon talks about laziness, purity and other FP concepts > to some .NET guys. Simon starts 7minutes 20seconds in. > > http://www.dotnetrocks.com/default.aspx?ShowNum=310 > > Good work Simon! > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jon.fairbairn at cl.cam.ac.uk Sun Feb 3 14:10:56 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sun Feb 3 14:10:14 2008 Subject: [Haskell-cafe] Yi, or Gtk2hs or fedora rpm problem? Message-ID: This was mentioned on the yi-devel list but didn't cause much excitement as it's not clear whose problem it is, so I'll ask here as well: I recently downloaded yi-0.3 and tried to build it, but get Loading package base ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. Loading package regex-base-0.72.0.1 ... linking ... done. Loading package regex-posix-0.72.0.2 ... linking ... done. Loading package regex-compat-0.71.0.1 ... linking ... done. Loading package fingertree-0.0 ... linking ... done. Loading package mtl-1.1.0.0 ... linking ... done. Loading package glib-0.9.12.1 ... linking ... done. Loading package cairo-0.9.12.1 ... linking ... done. yi: /usr/lib/ghc/6.8.2/gtk2hs/HSgtk.o: unknown symbol `containerszm0zi1zi0zi1_DataziSequence_length_info' Loading package gtk-0.9.12.1 ... linking ... yi: exception :: GhcException for any attempted invocation of yi. I don't know whether this problem is specific to yi, to gtk2hs or to the fedora 8 rpm of gtk2hs or something else (ghc 6.8.2). I tried to rpm --rebuild the gtk2hs source rpm, but the build failed, complaining of missing documentation files (the spec file can't be right, or I'd have seen an unsatisfied build-dependency message instead). What's the next step? -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From daniil.elovkov at googlemail.com Sun Feb 3 14:50:55 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Sun Feb 3 14:50:08 2008 Subject: [Haskell-cafe] hdbc, Oracle, and Solaris Message-ID: <47A61B1F.2090504@gmail.com> Hello folks. I don't understand whether hdbc has a specific Oracle backend or not (not via odbc). It is listed in the description of hdbc, but not really found elsewhere, it seems. I'd like to have a non-odbc support because it is very desirable to have it working on Solaris, and I'm not sure if it will be easy to set it up with odbc there. So, the question might go: has somebody had success with native Oracle support on Solaris with hdbc? Well, or hsql? From dons at galois.com Sun Feb 3 15:01:53 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 3 15:01:06 2008 Subject: [Haskell-cafe] more haskeem: it's just scheme in haskell now, no more "almost" In-Reply-To: <65d7a7e0802030004k5d6d5ef3h15943695d702276b@mail.gmail.com> References: <65d7a7e0802030004k5d6d5ef3h15943695d702276b@mail.gmail.com> Message-ID: <20080203200153.GC29420@scytale.galois.com> uhollerbach: > Hello, haskellers, my mud pies are getting bigger: I have added an > exception-handling mechanism to haskeem (ie, for handling exceptions > at the scheme level, not the haskell level; that was already working), > and also hooked up the REPL to gnu readline: the example code for the > readline command was practically tailor-made for me! :-) > > Also, I must apologize: I screwed up the URL earlier: I had said > http://www.korgwal.com/software/haskeem/ and then promptly went and > stuck it into http://www.korgwal.com/haskeem/ ... you may attribute > that to rapidly-advancing senility, if you like, I won't contradict > you. Anyway, I've fixed it by simply putting copies into both places. > > regards, > Uwe Hollerbach Lovely work. And excellent advice on your page for new Haskell programmers wanting to get their hands dirty. From mgsloan at gmail.com Sun Feb 3 15:42:47 2008 From: mgsloan at gmail.com (mgsloan) Date: Sun Feb 3 15:41:53 2008 Subject: [Haskell-cafe] RE: highlighting-kate - syntax highlighting library Message-ID: <438300e50802031242h454c15b2y79394c9ea5a44731@mail.gmail.com> Awesome! It looks quite nice, though it takes ages to compile. Would this be suitable for a text editor? One issue with text editors is you don't want to reprocess the entire file for each highlight. This, combined with multi-line syntactic elements, such as multiline strings or comments, makes for a rather awkward combination. It becomes a bit harder to predict the scope, highlighting wise, of editing actions. It may not really be necessary to do this very well. I for one find it annoying when you introduce an opening/closing symbol, it freezes for an instant, and the highlighting of the rest of the document alternates... So perhaps it could check if you're introducting a multiline element at the end when navigating off, re-evaluate highlighting of the rest of the document. Regardless of if the library can handle the requirements of text-editing in its current state, it looks like it wouldn't be too hard to add. Most of the work has been done :) Thanks! -Michael Sloan http://mgsloan.nfshost.com > Hello all, > > I've been working on a source code syntax highlighting library. It is > now somewhat usable, and help would be welcome in testing it further, so > I'm making it publicly available: > > darcs get http://johnmacfarlane.net/repos/highlighting-kate > > Currently, the following languages are supported: > > Ada Asp Awk Bash Bibtex > C Cmake Coldfusion Commonlisp Cpp > Css D Diff Djangotemplate Doxygen > Dtd Erlang Fortran Haskell Html > Java Javadoc Javascript Json Latex > Lex LiterateHaskell Lua Makefile Matlab > Mediawiki Nasm Objectivec Objectivecpp Ocaml > Pascal Perl Php Postscript Prolog > Python Ruby Scala Scheme Sgml > Sql SqlMysql SqlPostgresql Tcl Texinfo > Xml Xslt Yacc > > The parsers for individual languages are automatically generated > from Kate syntax definitions. The xml files have been included > in the repository, together with the program that converts them to > Haskell modules. There's also a standalone program, Highlight, that > you can use to test the highlighting. (See README for instructions.) > > Bug reports and patches are welcome. Note that I don't want to make > any manual modifications to the generated modules in > Text/Highlighting/Kate/Syntax. Changes should be made either in the > source xml files or in the program ParseSyntaxFiles.hs that generates > these modules. > > John From aslatter at gmail.com Sun Feb 3 15:53:15 2008 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 3 15:52:24 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <1201929342.5496.112.camel@derek-laptop> References: <1201929342.5496.112.camel@derek-laptop> Message-ID: <694519c50802031253x2b73b8fblf459a7726d2d2854@mail.gmail.com> Another picky nit: The monad transformer type is defined as such: > data ParsecT s u m a > = ParsecT { runParsecT :: State s u -> m (Consumed (m (Reply s u a))) } with the Consumed and reply types as: > data Consumed a = Consumed a > | Empty !a > data Reply s u a = Ok !a !(State s u) ParseError > | Error ParseError What's the advantage of having a double-wrapping of the base monad `m' over the simpler type: data ParsecT s u m a = ParsecT { runParsecT :: State s u -> m (Consumed (Reply s u a)) } -Antoine From colin at colina.demon.co.uk Sun Feb 3 16:01:39 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Feb 3 16:00:46 2008 Subject: [Haskell-cafe] RE: highlighting-kate - syntax highlighting library In-Reply-To: <438300e50802031242h454c15b2y79394c9ea5a44731@mail.gmail.com> (mgsloan@gmail.com's message of "Sun\, 3 Feb 2008 12\:42\:47 -0800") References: <438300e50802031242h454c15b2y79394c9ea5a44731@mail.gmail.com> Message-ID: >>>>> "Michael" == mgsloan writes: Michael> Awesome! >> I've been working on a source code syntax highlighting >> library. It is now somewhat usable, and help would be welcome >> in testing it further, so I'm making it publicly available: >> >> darcs get http://johnmacfarlane.net/repos/highlighting-kate >> >> Currently, the following languages are supported: >> >> Ada Asp Awk Bash Bibtex C Cmake Coldfusion Commonlisp Cpp Css D >> Diff Djangotemplate Doxygen Dtd Erlang Fortran Haskell Html >> Java Javadoc Javascript Json Latex Lex LiterateHaskell Lua >> Makefile Matlab Mediawiki Nasm Objectivec Objectivecpp Ocaml >> Pascal Perl Php Postscript Prolog Python Ruby Scala Scheme Sgml >> Sql SqlMysql SqlPostgresql Tcl Texinfo Xml Xslt Yacc Not to me. Where is Eiffel? -- Colin Adams Preston Lancashire From s.clover at gmail.com Sun Feb 3 16:29:57 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sun Feb 3 16:29:09 2008 Subject: [Haskell-cafe] ANN: strictify 0.1 Message-ID: Dear Friend, Have you ever stared at a maze of Haskell code and thought "Gosh, I'm just feeling lazy today. Everything works, and I mainly understand the strictness characteristics of my program. But I just can't decide where to put those last few bangs. Maybe I don't need to micro-optimize anyway." Sure you have. It's ok. You can let it out. You're among friends here. Why, I bet you've even gone and sprinkled some bangs randomly, hoping for the best. We've all been there. Maybe you even got those pesky strictness annotations right, but a new version of GHC with its ever improving strictness analyzer came along and rendered some obsolete. And yet there they still lie, consuming whole tens of picoseconds worth of your hard-earned processor cycles and troubling your dreams. Well, friend, your dreams need be troubled no more. The time has come for a new era! The era of strictifiericization version 0.1. An era where you can kiss those micro-optimization troubles over silly shootout entries goodbye! Instead of brute-forcing your way through permutations of strictness entries let your computer do the work for you. That's why we invented them after all! Rather than putting "!" in just the right places, put "{- ! -}" in every place you _might_ want a strictness annotation. Then sit back, pop open a cool refreshing brew, and wait (and wait and wait) as strictify does the rest!* Available now now now at hackage: http://hackage.haskell.org/cgi-bin/ hackage-scripts/package/strictify-0.1 Darcs repository at: http://code.haskell.org/~sclv/strictify/ *To prevent exponential running time, strictify only produces a local rather than global optimum of strictness patterns, which should be sufficient in 99% of all cases. Strictify only works on POSIX- compliant systems. Strictify is currently only suitable for "shootout"-style executables which are contained in a single main file, accepting input from argv, stdin, or both. Strictify will not fully execute until it recieves an EOF in stdin. If you cannot produce an EOF through ctrl-D and are not streaming an input file in, you may be forced to run "echo "" | strictify". No guarantee is made, express or implied, as to strictify improving the speed of your program or your mental acuity regarding strictness. Offer void where prohibited. As strictify contains small parts, it is not suitable for children under the age of five. Do not ingest strictify more than seventy five times in a one hour period. If symptoms persist, consult your physician. --S From felipe.lessa at gmail.com Sun Feb 3 16:38:35 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Feb 3 16:37:43 2008 Subject: [Haskell-cafe] RE: highlighting-kate - syntax highlighting library In-Reply-To: <438300e50802031242h454c15b2y79394c9ea5a44731@mail.gmail.com> References: <438300e50802031242h454c15b2y79394c9ea5a44731@mail.gmail.com> Message-ID: On Feb 3, 2008 6:42 PM, mgsloan wrote: > Would this be suitable for a text editor? Note that we already have a binding to GtkSourceView, see http://www.haskell.org/gtk2hs/docs/current/Graphics-UI-Gtk-SourceView.html . Cheers, -- Felipe. From ddvlad at anaconda.cs.pub.ro Sun Feb 3 16:39:01 2008 From: ddvlad at anaconda.cs.pub.ro (Vlad Dogaru) Date: Sun Feb 3 16:39:15 2008 Subject: [Haskell-cafe] IRC Statistics Message-ID: <47A63475.3010301@anaconda.cs.pub.ro> Hello, as part of an effort to learn Haskell, me and a few friends want to write an IRC statistcs generator. It would analyse logs and output HTML, text, or whatever other format. However, I have a few questions; we're all pretty new to this and it would be a shame to start off terribly wrong and get bored before we get to the fun parts. 1. Is there a similar effort in Haskell? I've seen a truly awesome IRCStats, but written in C (not that that's a bad thing). 2. I was thinking of the following structure: * a uniform Event format: joins, parts, actions, normal lines, and everything about them: the user, date and time, etc. * functions that parse logs to a list of events. Exotic log format? Just write a different function! (whatever `exotic' may mean) * functions that do various statistics on a list of events. The output will not be uniform. Examples are: who spoke most, what time people speak most, etc. * some way to make these into a common output form, maybe every above module having two functions, one for `internal' format, and one for converting that to proper output. Now, there will probably be a lot of opportunities to ask for feedback on possible statistics and log formats. My (main) question is whether you see anything conceptually wrong in this approach. With a bit of luck, we will be announcing hirst-0.1 in a few weeks or months (we're doing this while having schoool and other engagements). Thank you for your time, Vlad PS: This is my first post here, please point out any inadequacy. -- There is nothing more dangerous than an idea when it is the only one you have. From jgm at berkeley.edu Sun Feb 3 17:04:13 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Sun Feb 3 17:03:19 2008 Subject: [Haskell-cafe] Re: highlighting-kate - syntax highlighting library In-Reply-To: References: <438300e50802031242h454c15b2y79394c9ea5a44731@mail.gmail.com> Message-ID: <20080203220413.GA13126@berkeley.edu> > Not to me. Where is Eiffel? I've just added it. The library is so big already that I left out a bunch of languages for which there are Kate syntax definitions. But I'm happy to add them on request. John From ben.franksen at online.de Sun Feb 3 18:30:01 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Feb 3 18:32:06 2008 Subject: [Haskell-cafe] Re: Poor libraries documentation References: <404396ef0801300436l4a0f204dvdae578d94bcd80ac@mail.gmail.com> Message-ID: Neil Mitchell wrote: > I went looking for the the function in Haskell to calculate cos^{-1}, > inverse cosine. Unfortunately, the poor documentation in the libraries > hampered my attempts. The documentation for the trig functions in > Haskell is completely non-existent: Similar for mtl library. Some of the modules are documented, but many aren't at all. This has been a problem for me with the new Control.Monad.XYZ.Lazy vs. ...Strict stuff. I honestly don't have a clue what exactly is lazy or strict here. (I know there has been some discussion about this but I didn't understand most of it.) Another problem are the more obscure features of Control.Monad.Writer.Class, such as listen and pass methods. (For these I finally found an explanation in 'All About Monads'.) Cheers Ben From dekudekuplex at yahoo.com Sun Feb 3 22:14:20 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Sun Feb 3 22:13:26 2008 Subject: [Haskell-cafe] Re: Who started 42, and when? In-Reply-To: <871w7wacx3.fsf@tnoo.net> Message-ID: <196678.31270.qm@web30206.mail.mud.yahoo.com> That depends partly on how 42 it is pronounced. Normally, it is pronounced "yon-juu-ni," which has no relevance to "death." However, it is also possible to pronounce it "shi-ni," which also means "to die." Incidentally, it is the 4 part of 42 that is pronounced "shi," which alternatively means "death," and I have heard that there is also no hotel room in Japan with the number 4. (However, there are hotel rooms here with the number 13.) (Also, items in department stores are never sold (at least to my knowledge) in sets of 4.) In addition, the age 42 is considered a major climacteric age for men in Japan as well (for those who can read Japanese, see the Japanese Wikipedia entry for "yaku-doshi" (climacteric year)) (http://ja.wikipedia.org/wiki/%E5%8E%84%E5%B9%B4). (In general, the ages of 25, 42, and 61 are considered climacteric ages for men, and the ages of 19, 33, and 37 are considered climacteric for women, with 33 being the major climacteric age for women. Incidentally, 33 is pronounced "san-zan," which means "disastrous.") Does anybody else know of any culture where the number 42 holds special meaning; if so, what special meaning? Benjamin L. Russell --- Martin L?thi wrote: > [snip] > > In the Japanese culture the number 42 has a very > special meaning. I > realized that while discussing cultural differences > with a Japanese. > Pronouncing 42 sounds like "death" or "to die". No > hotel in Japan has a > room 42. From scook0 at gmail.com Sun Feb 3 22:40:51 2008 From: scook0 at gmail.com (Stuart Cook) Date: Sun Feb 3 22:39:57 2008 Subject: [Haskell-cafe] ANN: bimap 0.1 - a bidirectional map Message-ID: <49b351060802031940s32b1daa9h19675b024430142b@mail.gmail.com> Data.Bimap is a data structure that represents a bidirectional mapping between two key types. A bimap has two type parameters; each value in the bimap is associated with exactly one value of the opposite type. In other words, it's a bijection between (subsets of) its argument types. The API is loosely based on Data.Map; feedback and suggestions are most welcome. So far I've only tested it on GHC 6.6 on Linux/x86, with Cabal 1.2.3.0. Let me know if it works or breaks on other configurations. Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bimap-0.1 Haddocks: http://code.haskell.org/~scook0/haddock/bimap/ Darcs: darcs get http://code.haskell.org/bimap Stuart Cook From anthony_clayden at clear.net.nz Sun Feb 3 23:13:46 2008 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sun Feb 3 23:12:53 2008 Subject: [Haskell-cafe] Who started 42, and when? Message-ID: <47a690fa.26.7a2.7085@clear.net.nz> The earliest use of 42 in English humour I know of is Lewis Carroll's "Hunting of the Snark", written 1874 when the author was aged 42. Wikipedia says it all, and refers to Martin Gardner's "The Annotated Snark" (which is excellent). Lewis Carroll is the pen name of Charles Dodgson - a mathematician/logician. Gardner is of course a mathematician/science writer with an interest in puzzles and paradoxes. So although both rather pre-date functional programming, I think we might say there's a similar streak of humour. Sadly, Douglas Adams never revealed what language 'Deep Thought' was programmed in, but perhaps the machine it was 'unworthy to design' was to run Haskell natively? Anthony > The arbitrary constant was made popular by Douglas Adams in > the mid-1970s radio series ``A Hitchhikers Guide to the Galaxy'' (a > trilogy in 4 parts) --- however it does have a basis in the standard > model of physics --- a paper in Phys.Rev. of the early 1970s > described the unification of the Electro-Weak and Strong nuclear > forces --- the arbitrary constant (of nearly) 42 appears in the > calculations. I forget the original paper but if you get hold of > Frank Close ``The Cosmic Onion'' a graph reproduces the result. I met > Douglas Adams once at a book signing and asked him how he got hold of > the Phys.Rev. paper so early. Technically he should have written that > ``42 is the answer to life, the universe and everything except for > gravity and a few other arbitrary constants'' > > Adams was interested in computing --- I think his reaction to being > told about functional programming was to wonder what non-functional > programming might be. From mgsloan at gmail.com Mon Feb 4 00:40:28 2008 From: mgsloan at gmail.com (mgsloan) Date: Mon Feb 4 00:39:35 2008 Subject: [Haskell-cafe] RE: highlighting-kate - syntax highlighting library In-Reply-To: References: <438300e50802031242h454c15b2y79394c9ea5a44731@mail.gmail.com> Message-ID: <438300e50802032140j2accc557s2376b2fe4866dbe5@mail.gmail.com> Hmm, yeah, I may switch to that. Probably more practical than writing a raw editor ontop cairo. Won't be able to do a few things I was intending to, but if I want to replace it with custom stuff later I suppose I can. That pretty much takes care of 95% of a text editor. -Michael Sloan http://mgsloan.nfhost.com On Feb 3, 2008 1:38 PM, Felipe Lessa wrote: > On Feb 3, 2008 6:42 PM, mgsloan wrote: > > Would this be suitable for a text editor? > > Note that we already have a binding to GtkSourceView, see > http://www.haskell.org/gtk2hs/docs/current/Graphics-UI-Gtk-SourceView.html > . > > Cheers, > > -- > Felipe. > From wnoise at ofb.net Mon Feb 4 03:43:11 2008 From: wnoise at ofb.net (Aaron Denney) Date: Mon Feb 4 03:42:24 2008 Subject: [Haskell-cafe] Re: Re[2]: Cabal, GHC, FFI and Visual Studio on Windows References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> <1201974303.13130.145.camel@localhost> <47A4BB92.6030104@therning.org> <1201979201.13130.155.camel@localhost> <47A4EFB8.3040802@therning.org> <1202005462.13130.224.camel@localhost> <647493922.20080203171703@gmail.com> Message-ID: On 2008-02-03, Bulat Ziganshin wrote: > Hello Duncan, > > Sunday, February 3, 2008, 5:24:22 AM, you wrote: > >> Ok, so you could create a separate component to produce the .dll / .a >> from the C code but you'd prefer the convenience of being able to just: >> c-sources: blah.c >> and have them included in the project, but built using the MS C >> compiler. > >> So I think we should file a feature request about building C sources >> using gcc/ms-c directly rather than going via ghc as that would give us >> the flexibility to use alternative C compilers. > > sorry, i think it's not whole story. gcc and msvc are probably > incompatible in the meaning that you can't link together code > produced by two compilers. exactly dll should be generated which allow > to avoids this incompatibility Well, the whole purpose of the ABI is to allow linking code together from different compilers. This doesn't mean there won't be any problems, but I'd expect the ones that crop up won't *strictly* be because of the compilers being different, but because of the C libraries being different. DLL vs object files shouldn't change things all that much. -- Aaron Denney -><- From ndmitchell at gmail.com Mon Feb 4 03:56:28 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 4 03:55:33 2008 Subject: [Haskell-cafe] ANN: bimap 0.1 - a bidirectional map In-Reply-To: <49b351060802031940s32b1daa9h19675b024430142b@mail.gmail.com> References: <49b351060802031940s32b1daa9h19675b024430142b@mail.gmail.com> Message-ID: <404396ef0802040056v7e306356ice8925409dd83ad1@mail.gmail.com> Hi Stuart, > Data.Bimap is a data structure that represents a bidirectional mapping > between two key types. A bimap has two type parameters; each value in > the bimap is associated with exactly one value of the opposite type. > In other words, it's a bijection between (subsets of) its argument > types. Very handy, I actually wanted something similar myself a few days ago and came up with: http://www.cs.york.ac.uk/fp/darcs/firstify/Yhc/Core/Firstify/Mitchell/BiMap.hs A few design differences from your one: * I called my module BiMap" rather than "Bimap" - I debated this with a collegue, and we settled on the capital M, but it was a very close call. * I have no L/R and Either variants. I decided it was better to be a superset of Data.Map, and then have lookupRev/memberRev functions for the R versions. Do you think anyone is likely to use the Either variant, without a constant Left or Right in the code? Is this an artefact of how its easier to code, rather than to use? * I didn't push my Bimap to completion, because I am too lazy, and hoped others would. Only the methods I needed were implemented. Many thanks for doing this work! Thanks Neil From nominolo at googlemail.com Mon Feb 4 04:01:42 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Feb 4 04:00:47 2008 Subject: [Haskell-cafe] ANN: bimap 0.1 - a bidirectional map In-Reply-To: <49b351060802031940s32b1daa9h19675b024430142b@mail.gmail.com> References: <49b351060802031940s32b1daa9h19675b024430142b@mail.gmail.com> Message-ID: <916b84820802040101k767ffdb9y871ada325ce0d849@mail.gmail.com> +1 I needed this quite a lot in my own code but didn't take the time to generalize it into a releasable package. Thanks! On Feb 4, 2008 4:40 AM, Stuart Cook wrote: > Data.Bimap is a data structure that represents a bidirectional mapping > between two key types. A bimap has two type parameters; each value in > the bimap is associated with exactly one value of the opposite type. > In other words, it's a bijection between (subsets of) its argument > types. > > The API is loosely based on Data.Map; feedback and suggestions are most welcome. > > So far I've only tested it on GHC 6.6 on Linux/x86, with Cabal > 1.2.3.0. Let me know if it works or breaks on other configurations. > > > Hackage: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bimap-0.1 > > Haddocks: > http://code.haskell.org/~scook0/haddock/bimap/ > > Darcs: > darcs get http://code.haskell.org/bimap > > > Stuart Cook > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From magnus at therning.org Mon Feb 4 04:47:38 2008 From: magnus at therning.org (Magnus Therning) Date: Mon Feb 4 04:46:52 2008 Subject: [Haskell-cafe] Re: Re[2]: Cabal, GHC, FFI and Visual Studio on Windows In-Reply-To: References: <47A30596.6080209@therning.org> <1201964896.13130.132.camel@localhost> <6c0416190802020915u7a3878dbh9c3fe30f8106a3f0@mail.gmail.com> <1201974303.13130.145.camel@localhost> <47A4BB92.6030104@therning.org> <1201979201.13130.155.camel@localhost> <47A4EFB8.3040802@therning.org> <1202005462.13130.224.camel@localhost> <647493922.20080203171703@gmail.com> Message-ID: <47A6DF3A.9030001@therning.org> Aaron Denney wrote: > On 2008-02-03, Bulat Ziganshin wrote: >> Hello Duncan, >> >> Sunday, February 3, 2008, 5:24:22 AM, you wrote: >> >>> Ok, so you could create a separate component to produce the .dll / .a >>> from the C code but you'd prefer the convenience of being able to just: >>> c-sources: blah.c >>> and have them included in the project, but built using the MS C >>> compiler. >>> So I think we should file a feature request about building C sources >>> using gcc/ms-c directly rather than going via ghc as that would give us >>> the flexibility to use alternative C compilers. >> sorry, i think it's not whole story. gcc and msvc are probably >> incompatible in the meaning that you can't link together code >> produced by two compilers. exactly dll should be generated which allow >> to avoids this incompatibility > > Well, the whole purpose of the ABI is to allow linking code together > from different compilers. This doesn't mean there won't be any problems, > but I'd expect the ones that crop up won't *strictly* be because of > the compilers being different, but because of the C libraries being > different. DLL vs object files shouldn't change things all that much. Well, I can at least report that linking a library (.lib) produced using cl (via CMake) with object files created by GHC works well. I do get a warning: Warning: .drectve `/manifestdependency:"type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b'" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" ' unrecognized But it doesn't seem to have any impact on the resulting executable. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?gmail?com http://therning.org/magnus What if I don't want to obey the laws? Do they throw me in jail with the other bad monads? -- Daveman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/4f36e408/signature.bin From scook0 at gmail.com Mon Feb 4 05:12:32 2008 From: scook0 at gmail.com (Stuart Cook) Date: Mon Feb 4 05:11:37 2008 Subject: [Haskell-cafe] ANN: bimap 0.1 - a bidirectional map In-Reply-To: <404396ef0802040056v7e306356ice8925409dd83ad1@mail.gmail.com> References: <49b351060802031940s32b1daa9h19675b024430142b@mail.gmail.com> <404396ef0802040056v7e306356ice8925409dd83ad1@mail.gmail.com> Message-ID: <49b351060802040212p4c1d2a9dlb4d651247aff3a6d@mail.gmail.com> On Mon, Feb 4, 2008 at 7:56 PM, Neil Mitchell wrote: > A few design differences from your one: > > * I called my module BiMap" rather than "Bimap" - I debated this with > a collegue, and we settled on the capital M, but it was a very close > call. Mine was also originally BiMap, but I thought the capital M looked a little ugly, so I changed it. > * I have no L/R and Either variants. I decided it was better to be a > superset of Data.Map, and then have lookupRev/memberRev functions for > the R versions. Do you think anyone is likely to use the Either > variant, without a constant Left or Right in the code? Is this an > artefact of how its easier to code, rather than to use? I initially had only the Either variants, because that was easier to code, and I thought it would make the interface cleaner. Then when I started writing tests, I realised that this was a pain, and I went back and added the L/R variants. I never bothered to remove the Either variants, because the L/R versions are (currently) implemented in terms of them anyway. I was thinking of having another module, Data.Bimap.Asymmetric, that would expose an interface more like that of Data.Map (i.e. biased towards treating the left type as the key), but I decided it was better to get the first release out as soon as possible. Thanks for the feedback, Stuart From g9ks157k at acme.softbase.org Mon Feb 4 06:11:07 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 4 06:10:44 2008 Subject: module hierarchy (Re: [Haskell-cafe] parsec3 pre-release [important note]) In-Reply-To: <1201928039.5496.107.camel@derek-laptop> References: <1201928039.5496.107.camel@derek-laptop> Message-ID: <200802041211.08009.g9ks157k@acme.softbase.org> Am Samstag, 2. Februar 2008 05:53 schrieb Derek Elkins: > I forgot to mention that the Text.Parsec modules should be preferred to > the Text.ParserCombinators.Parsec modules as the Haddock documentation > reveals. I would have prefered to shorten ParserCombinators to Parsing and leave Parsec under the parsing category. However, I would prefer if Parsing would move out of Text since parsing is not just about parsing text. Parsec parses also streams other than character streams now. Recently, there was a discussion on the Yampa mailing list about where to put FRP-related modules into the module hierarchy. There was the suggestion of Control.FRP. It was noted, however, that Control seems to suggest imperative programming while many things under Control are not restricted to that paradigm (like monads, for example) and others (like FRP) have nothing to do with imperative programming. We finally chose to introduce a separate top-level module name FRP since the FRP stuff didn?t seem to really fit in any of the existing top-level categories. I concluded from this discussion that the current module hierarchy is too deep and that it might be good to remove the current top-level layer. So Parsing.Parsec, for example, or Monad.Reader. What do you and others think? Best wishes, Wolfgang From g9ks157k at acme.softbase.org Mon Feb 4 06:36:55 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 4 06:36:08 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802012232.16922.g9ks157k@acme.softbase.org> <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> Message-ID: <200802041236.55480.g9ks157k@acme.softbase.org> Am Samstag, 2. Februar 2008 14:54 schrieben Sie: > On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch wrote: > > Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta: > [?] > > > To make it friendlier for the end user I thought about defining > > > aliases for lets say the first 10000 numbers using Template Haskell. > > > That could even make error reports friendlier (not sure to what point > > > though). What do you think? > > > > I have no clear opinion about that at the moment. Maybe it's okay to use > > the representation directly. This way, we don't introduce a dependeny on > > the Template Haskell language extension (which is only supported by GHC), > > and the actual representation will occur in error messages anyway > > whenever the message shows a computed number. > > Well, my EDSL already makes extensive use of TH. So, being selfish, it > wouldn't be a problem for me (or any other GHC user) and I think it > would make the library much more usable. > > Just compare > > f :: List (() :- D1 :- D0 :- D0 :- 1000) Int -> List (() :- D1 :- D0 :- > D0 :- D0) Int > > with, let's say > > f :: List A1000 Int -> List A1000 Int > > Again, if someone complains about the TH dependency, the aliases could > be generated by TH but saved statically in a module for each release. Hmm, this could be a compromise although I?m not sure whether it is sensible to have a module with thousands of declarations. Another solution would be to put the Template Haskell convenience stuff into a separate package. The core package would probably be usable with Hugs too, while the convenience package would be usable only with GHC. At the moment, I?m not sure how often I?ll need to state type-level numbers explicitely. So currently I cannot know how important aliases for type-level numbers are. > > > So, we'll be making two separate libraries then. We should think about > > > names. > > > > > > What about FixedVector for the vector library and DecTypArith (maybe > > > too long) or DecTypes for the type-level decimal arithmetic library? > > > > Alas, there is an inconsistency in naming packages already. Some prefer > > names which are entirely lowercase, some prefer camel case. I prefer > > lowercase, with hyphens separating parts of the name. And I also don't > > like unusual abbreviations like "typ" (not much shorter than "type"). To > > mention arithmetics is not so important. So maybe something > > like "type-level-decimals"? > > > > Maybe it's better to put different type-level programming things into a > > single package. Then we could name this package "type-level" or > > something similar. We could start with our decimals. Other type-level > > things could be added later. I already have some code about type-level > > booleans. It's not very sensible to put these few lines into a separate > > package. It might be nice if we had a general type-level programming > > package where I could put this code into. > > Sounds sensible. However, I would rather prefer something like > type-level-comp (from type level computations) or type-level-prog > (from type level programming). Type level by itself doesn't describe > the functionality of the package. Hmm, package names don?t have to be descriptive. Short names tend to sound better and be easier to remember. My FRP GUI and graphics library is named Grapefruit. This name makes hardly any sense. It refers to the previous library Fruit and the fact that I like Grapefruits?nothing more. But it?s a name, people can remember more easily than FRGGLER (Functional Reactive GUI and Graphics Library with Extensible Records). ;-) In addition, abbreviations like ?comp? typically have the problem of being ambiguous: computation, composition, component, ? So I still prefer type-level. > > As for the name of the fixed-size list package, I have to say that I > > don't like the term "vector" in this context. A vector is actually > > something with addition and scalar multiplication defined on it. Maybe > > we should make also this package's scope wider. What about something > > like "safe-data" or similar? > > I think safe-data is a bit too general and might lead to confusion > with other safe data packages (namely Mitchell's Safe library). Since > the main particularity of the library is that safety properties are > achieved via "emulating" dependent types I think that > light-dependent-types (from lightweight dependent types), > number-parameterized-data or simply parameterized-data (this is the > name I like best) would be more appropiate. parametrized-data looks good. The others seem to be too long again. So type-level + parametrized-data is my vote. But don?t let?s spend too much time discussing the name. ;-) Best wishes, Wolfgang From stephan.friedrichs at tu-bs.de Mon Feb 4 07:09:00 2008 From: stephan.friedrichs at tu-bs.de (Stephan Friedrichs) Date: Mon Feb 4 07:08:21 2008 Subject: [Haskell-cafe] Re: Data.Ord and Heaps (Was: Why functional programming matters) In-Reply-To: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> References: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> Message-ID: <47A7005C.8030404@tu-bs.de> Hi, I'm sorry it took me so long to respond! apfelmus@quantentunnel.de wrote: > [newtype Ord a => Reverse a = Reverse { unReverse :: a }] > >> This solution should be used for all collections depending on Ord >> instances, including Data.Map, Data.Set and others. As long as I only >> include it in my tiny heap package, it is as 'non-standard' as my >> approach, isn't it? > > Yes. I mean "non-standard" in the software-reuse sense, i.e. Ord is for > user-defined orderings and should be the only such mechanism in order to > enable reuse. In fact, Data.Heap clearly shows that Data.Ord is > currently missing functionality. Ah, now I see. The entire ordering policy mechanism - no matter how it is going to be solved - belongs into Data.Ord and not in Data.Heap. As soon as Data.Ord provides a solution, I'll use it in Data.Heap. > > [...] > > Note that the Heap class contains only three primitive operations > (empty, insert, viewHead), all the others have default implementations > in terms of those three. There is even an underappreciated unfold among > them :) > > toAscList = unfoldr viewHead > > The structure becomes especially clear by noting that any Heap is > defined by just two primitives > > inject :: Ord a => Maybe (a, Heap a) -> Heap a > view :: Ord a => Heap a -> Maybe (a, Heap a) > > We have inject = maybe empty (uncurry insert) . This is just like > lists, except that view . inject ? id since view returns the > smallest element. I stumbled over the similarity of heaps and lists when implementing take, takeWhile, span, break, etc. (btw, they are included in heap-0.2 which I uploaded yesterday); so a heap is really nothing but a packed representation of a sorted list :) > > However, just that we managed to reduce the number of primitive > operations doesn't mean that the policy approach isn't preferable. It > needs 0 primitive operations, after all. But as foreshadowed in my > reply, it's possible to do policies within Ord. Don't stop thinking > about your good idea just because you can start coding :) > > Here's one way to do it: > > [...] > >>> In conclusion: the ordering policy stuff should not be part of >>> Data.Heap, this is a job for Data.Ord. >> As mentioned above: This sounds really useful. How about you propose >> this to the base-package maintainers? :) > > What, me? :D Where? :) Regards, Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/128cf147/signature.bin From johan.tibell at gmail.com Mon Feb 4 07:15:40 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Feb 4 07:14:45 2008 Subject: module hierarchy (Re: [Haskell-cafe] parsec3 pre-release [important note]) In-Reply-To: <200802041211.08009.g9ks157k@acme.softbase.org> References: <1201928039.5496.107.camel@derek-laptop> <200802041211.08009.g9ks157k@acme.softbase.org> Message-ID: <90889fe70802040415m9b3610dobedf603c4845b1d3@mail.gmail.com> On Feb 4, 2008 12:11 PM, Wolfgang Jeltsch wrote: > Am Samstag, 2. Februar 2008 05:53 schrieb Derek Elkins: > > I forgot to mention that the Text.Parsec modules should be preferred to > > the Text.ParserCombinators.Parsec modules as the Haddock documentation > > reveals. > > I would have prefered to shorten ParserCombinators to Parsing and leave Parsec > under the parsing category. However, I would prefer if Parsing would move > out of Text since parsing is not just about parsing text. Parsec parses also > streams other than character streams now. > > Recently, there was a discussion on the Yampa mailing list about where to put > FRP-related modules into the module hierarchy. There was the suggestion of > Control.FRP. It was noted, however, that Control seems to suggest imperative > programming while many things under Control are not restricted to that > paradigm (like monads, for example) and others (like FRP) have nothing to do > with imperative programming. We finally chose to introduce a separate > top-level module name FRP since the FRP stuff didn't seem to really fit in > any of the existing top-level categories. > > I concluded from this discussion that the current module hierarchy is too deep > and that it might be good to remove the current top-level layer. So > Parsing.Parsec, for example, or Monad.Reader. > > What do you and others think? I would recommend reading Ontology is Overrated [1] as it might be of relevant to this discussion. I've been asking myself lately if it would be beneficial for libraries that are not very core (e.g. Data.Map) to use a unique top-level name (e.g. Parsec.SubModule) and leave categorization to Hackage. Or should we just try to cram everything into the same module hierarchy (e.g. Parsing.Parsec, Parsing.Foo, etc?). Another question: If we continue with the current approach where should we put versions of a library specialized to a certain type? e.g. Parsing.ByteString.Parsec or Parsing.Parsec.ByteString? The current preference seems to be to use the latter but that makes it hard to find all parsing libraries that parses bytestrings as they would not be kept under Parsing.ByteString. 1. http://www.shirky.com/writings/ontology_overrated.html -- Johan From alfonso.acosta at gmail.com Mon Feb 4 07:22:36 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Feb 4 07:21:41 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802041236.55480.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802012232.16922.g9ks157k@acme.softbase.org> <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> <200802041236.55480.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> On Feb 4, 2008 12:36 PM, Wolfgang Jeltsch wrote: > Am Samstag, 2. Februar 2008 14:54 schrieben Sie: > > Again, if someone complains about the TH dependency, the aliases could > > be generated by TH but saved statically in a module for each release. > > Hmm, this could be a compromise although I'm not sure whether it is sensible > to have a module with thousands of declarations. As long as the module is automatically generated I don't see why it would be a problem. Bear in mind that using TH would, in practice, be equivalent to code such a module by hand anyway. > Another solution would be > to put the Template Haskell convenience stuff into a separate package. The > core package would probably be usable with Hugs too, while the convenience > package would be usable only with GHC. I'm not sure if it worths it to create a separate package and add another dependency for those who would like to use it. I don't still know how many people would be interested in using the type-level library so, again, I think it won't hurt to include the TH-generated aliases and then change it if some non-GHC user rants about it. > So type-level + parametrized-data is my vote. But don't let's spend too much > time discussing the name. ;-) Fair enough. type-level + parameterized-data it is then (unless someone else has a better suggestion). I'm going to begin coding now. I'll host the project in community.haskell.org, do you have an account there? PS: BTW, I asked Oleg for permission and, as expected, agreed to create the library under a BS-D license. From stephan.friedrichs at tu-bs.de Mon Feb 4 07:23:17 2008 From: stephan.friedrichs at tu-bs.de (Stephan Friedrichs) Date: Mon Feb 4 07:22:26 2008 Subject: [Haskell-cafe] ANN: heap-0.2 Message-ID: <47A703B5.6020709@tu-bs.de> A flexible heap implementation supporting min-, max- and custom-ordered heaps. New features since version 0.1: - Foldable and Read instance - filter, partition - subrange functions: take, drop, splitAt, takeWhile, span, break http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.2.1 //Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/0cfc942b/signature.bin From phil at kantaka.co.uk Mon Feb 4 07:59:43 2008 From: phil at kantaka.co.uk (Philip Armstrong) Date: Mon Feb 4 07:58:47 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> <20080201214858.GF31711@cs.cmu.edu> Message-ID: <20080204125943.GA10030@kantaka.co.uk> On Fri, Feb 01, 2008 at 10:19:17PM +0000, Lennart Augustsson wrote: > It's a matter of taste. I prefer the function composition in this case. > It reads nicely as a pipeline. (Hoping not to contribute to any flamage...) I've always liked $ for this kind of code, if you want to keep the arguments around: next xs = runCont $ sequence $ map Cont xs seems quite natural to me. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt From lemming at henning-thielemann.de Mon Feb 4 08:56:51 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Feb 4 08:55:56 2008 Subject: [Haskell-cafe] Circular enums In-Reply-To: <887459.84442.qm@web30805.mail.mud.yahoo.com> References: <887459.84442.qm@web30805.mail.mud.yahoo.com> Message-ID: On Sat, 2 Feb 2008, Ben Butler-Cole wrote: > [Resend with formatting maybe fixed.] > > Hello > > I'm trying to define functions that allow you to traverse a bounded enumeration, "wrapping" at the start and the end. > > My implementation looks like this: > > next, prev :: (Enum a, Bounded a) => a -> a > next = turn 1 > prev = turn (-1) > > turn :: (Enum a, Bounded a) => Int -> a -> a > turn n e = toEnum (add (fromEnum (maxBound::a) + 1) (fromEnum e) n) > where > add mod x y = (x + y + mod) `rem` mod ^^^ This should give warnings about a name clash with Prelude's 'mod' function. Actually, I think you want to use 'mod' here instead of 'rem': http://www.haskell.org/haskellwiki/Things_to_avoid#Forget_about_quot_and_rem To fix the type of 'maxBound' a GHC extension is certainly overkill. Better use `asTypeOf` instead. From ddssff at gmail.com Mon Feb 4 09:08:31 2008 From: ddssff at gmail.com (David Fox) Date: Mon Feb 4 09:07:37 2008 Subject: [Haskell-cafe] Bug in System.Environment - EOT inserted into argument string Message-ID: I'm seeing the character ^D inserted into argument strings that are about 256 characters long with GHC 6.8.2. Anyone else? Test.hs: module Main where import System.Environment import System.IO main = do args <- getArgs hPutStrLn stderr ("args: " ++ show args) Output: $ ghc6 --make Test.hs -o test [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking test ... $ ./test "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789" args: ["01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234\EOT5678901234567890123456789"] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/ae14bcee/attachment.htm From felipe.lessa at gmail.com Mon Feb 4 09:22:04 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Mon Feb 4 09:21:09 2008 Subject: [Haskell-cafe] fmap vs. liftM Message-ID: Hi there, Reading http://www.haskell.org/haskellwiki/Things_to_avoid I found an interesting saying: "By the way, in the case of IO monad the Functor class method fmap and the Monad based function liftM are the same." I always tought that prop :: (Functor m, Monad m, Eq (m b)) => (a -> b) -> m a -> Bool prop f x = fmap f x == liftM f x was True regardless of 'm'. Is there any exception? If so, why? I've even done s/fmap/liftM/g and s/liftM/fmap/g in the past for consistency =). Thanks! -- Felipe. From vigalchin at gmail.com Mon Feb 4 09:33:37 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Mon Feb 4 09:32:41 2008 Subject: [Haskell-cafe] building the unix package and cabal Message-ID: <5ae4f2ba0802040633l22b506c9id47bf2dfc73d9fd0@mail.gmail.com> Hello, I have been trying to build the unix package on RedHat RHEL 5. Over the weekend I read through the Cabal documentation. The unix-2.2.0.0 unix.cabal specifies the "build-type" attribute as "Configure". Based on Cabal doc, I should run ./configure. After this step then what? Bottom line is how do I build the unix-2.2.0.0 package on RHEL 5? Thank you, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/b0741e6e/attachment.htm From lemming at henning-thielemann.de Mon Feb 4 09:29:24 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Feb 4 09:35:17 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: Message-ID: On Mon, 4 Feb 2008, Felipe Lessa wrote: > Hi there, > > Reading http://www.haskell.org/haskellwiki/Things_to_avoid I found an > interesting saying: > > "By the way, in the case of IO monad the Functor class method fmap and > the Monad based function liftM are the same." > > I always tought that > > prop :: (Functor m, Monad m, Eq (m b)) => (a -> b) -> m a -> Bool > prop f x = fmap f x == liftM f x > > was True regardless of 'm'. Is there any exception? If so, why? I've > even done s/fmap/liftM/g and s/liftM/fmap/g in the past for > consistency =). Problem is that from the idea Functor is a superclass of Monad, with the property that "fmap == liftM". The first relation could have been expressed in Haskell 98 but was not done (forgotten?) in the standard libraries. The second relation can even not be expressed in Haskell 98. So it's only cosmetic, if you use 'liftM' instead of 'fmap' in order to avoid an explicit 'Functor' constraint in a function. From vigalchin at gmail.com Mon Feb 4 10:04:03 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Mon Feb 4 10:03:08 2008 Subject: [Haskell-cafe] modeling ANSI C structs in Haskell? Message-ID: <5ae4f2ba0802040704o6dafd4eawf2a452c65e1dc8fc@mail.gmail.com> Hello, I am reading through the FFI doc. Any suggestions on enabling Haskell programmers to model ANSI C structs that will be passed down to C run-time? Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/8753a6d6/attachment.htm From peteg42 at gmail.com Mon Feb 4 10:15:15 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Mon Feb 4 10:14:28 2008 Subject: [Haskell-cafe] modeling ANSI C structs in Haskell? In-Reply-To: <5ae4f2ba0802040704o6dafd4eawf2a452c65e1dc8fc@mail.gmail.com> References: <5ae4f2ba0802040704o6dafd4eawf2a452c65e1dc8fc@mail.gmail.com> Message-ID: Vasili, On 04/02/2008, at 10:04 PM, Galchin Vasili wrote: > I am reading through the FFI doc. Any suggestions on enabling > Haskell programmers to model ANSI C structs that will be passed down > to C run-time? The FFI spec is a wonderful document, but is of limited use in learning to use the FFI for practical tasks. I suggest you look into c2hs or some other tool that tries to help you with marshalling data structures (as compared to providing mechanisms sufficient for doing marshalling). I suggest you do this even if you don't end up using a tool, as the generated Haskell has some carefully designed idioms that will definitely help. cheers peter From nominolo at googlemail.com Mon Feb 4 10:53:09 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Feb 4 10:52:15 2008 Subject: [Haskell-cafe] building the unix package and cabal In-Reply-To: <5ae4f2ba0802040743n6e876829m4e4791262774176a@mail.gmail.com> References: <5ae4f2ba0802040633l22b506c9id47bf2dfc73d9fd0@mail.gmail.com> <916b84820802040705w59183b3an88872de0448f26d5@mail.gmail.com> <5ae4f2ba0802040743n6e876829m4e4791262774176a@mail.gmail.com> Message-ID: <916b84820802040753i6869afa3s43d4046c31fd83e7@mail.gmail.com> This is the GNU Multi-Precision library. You have to install that separately, Cabal can't do that for you. You should use the redhat package manager to install it. HTH On Feb 4, 2008 4:43 PM, Galchin Vasili wrote: > Hi Thomas, > > Have you tried to build this package yourself? I get a linker error .. > unresolved symbol "gmp". > > Vasili > > > > > On 2/4/08, Thomas Schilling wrote: > > Build-type: Configure means that *Cabal uses ./configure * to build > > the package. Nothing changes for you. Just use the usual: > > > > runhaskell Setup.hs configure --prefix=... [--user] > > runhaskell Setup.hs build > > runhaskell Setup.hs install > > > > or with cabal-install: > > > > cabal install unix > > > > 2008/2/4 Galchin Vasili : > > > Hello, > > > > > > I have been trying to build the unix package on RedHat RHEL 5. > Over > > > the weekend I read through the Cabal documentation. The unix-2.2.0.0 > > > unix.cabal specifies the "build-type" attribute as "Configure". Based on > > > Cabal doc, I should run ./configure. After this step then what? Bottom > line > > > is how do I build the unix-2.2.0.0 package on RHEL 5? > > > > > > Thank you, Vasili > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > > > From nominolo at googlemail.com Mon Feb 4 11:33:41 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Feb 4 11:32:49 2008 Subject: [Haskell-cafe] building the unix package and cabal In-Reply-To: <5ae4f2ba0802040822p62d4ac94p1d29f6562501ac2d@mail.gmail.com> References: <5ae4f2ba0802040633l22b506c9id47bf2dfc73d9fd0@mail.gmail.com> <916b84820802040705w59183b3an88872de0448f26d5@mail.gmail.com> <5ae4f2ba0802040743n6e876829m4e4791262774176a@mail.gmail.com> <916b84820802040753i6869afa3s43d4046c31fd83e7@mail.gmail.com> <5ae4f2ba0802040822p62d4ac94p1d29f6562501ac2d@mail.gmail.com> Message-ID: <916b84820802040833g72d34d91ifd834a667aebe86b@mail.gmail.com> I don't know. Maybe someone on @cafe can help. (I CC'd) On Feb 4, 2008 5:22 PM, Galchin Vasili wrote: > I have the gmp shared objects installed, i.e. .so's. Does ghc require static > linking with .a archive files? > > > > > On 2/4/08, Thomas Schilling wrote: > > This is the GNU Multi-Precision library. You have to install that > > separately, Cabal can't do that for you. You should use the redhat > > package manager to install it. HTH > > > > On Feb 4, 2008 4:43 PM, Galchin Vasili wrote: > > > Hi Thomas, > > > > > > Have you tried to build this package yourself? I get a linker error > .. > > > unresolved symbol "gmp". > > > > > > Vasili > > > > > > > > > > > > > > > On 2/4/08, Thomas Schilling wrote: > > > > Build-type: Configure means that *Cabal uses ./configure * to build > > > > the package. Nothing changes for you. Just use the usual: > > > > > > > > runhaskell Setup.hs configure --prefix=... [--user] > > > > runhaskell Setup.hs build > > > > runhaskell Setup.hs install > > > > > > > > or with cabal-install: > > > > > > > > cabal install unix > > > > > > > > 2008/2/4 Galchin Vasili : > > > > > Hello, > > > > > > > > > > I have been trying to build the unix package on RedHat RHEL 5. > > > Over > > > > > the weekend I read through the Cabal documentation. The unix-2.2.0.0 > > > > > unix.cabal specifies the "build-type" attribute as "Configure". > Based on > > > > > Cabal doc, I should run ./configure. After this step then what? > Bottom > > > line > > > > > is how do I build the unix-2.2.0.0 package on RHEL 5? > > > > > > > > > > Thank you, Vasili > > > > > _______________________________________________ > > > > > Haskell-Cafe mailing list > > > > > Haskell-Cafe@haskell.org > > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > > > > > > > > > > > > > > > > > > From vigalchin at gmail.com Mon Feb 4 11:50:13 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Mon Feb 4 11:49:18 2008 Subject: [Haskell-cafe] building the unix package and cabal In-Reply-To: <916b84820802040833g72d34d91ifd834a667aebe86b@mail.gmail.com> References: <5ae4f2ba0802040633l22b506c9id47bf2dfc73d9fd0@mail.gmail.com> <916b84820802040705w59183b3an88872de0448f26d5@mail.gmail.com> <5ae4f2ba0802040743n6e876829m4e4791262774176a@mail.gmail.com> <916b84820802040753i6869afa3s43d4046c31fd83e7@mail.gmail.com> <5ae4f2ba0802040822p62d4ac94p1d29f6562501ac2d@mail.gmail.com> <916b84820802040833g72d34d91ifd834a667aebe86b@mail.gmail.com> Message-ID: <5ae4f2ba0802040850v30c1a768n6f228f930843b87c@mail.gmail.com> more specifically the "gmp" unsatisfied ref shows up with the DynamicLinker. On 2/4/08, Thomas Schilling wrote: > > I don't know. Maybe someone on @cafe can help. (I CC'd) > > On Feb 4, 2008 5:22 PM, Galchin Vasili wrote: > > I have the gmp shared objects installed, i.e. .so's. Does ghc require > static > > linking with .a archive files? > > > > > > > > > > On 2/4/08, Thomas Schilling wrote: > > > This is the GNU Multi-Precision library. You have to install that > > > separately, Cabal can't do that for you. You should use the redhat > > > package manager to install it. HTH > > > > > > On Feb 4, 2008 4:43 PM, Galchin Vasili wrote: > > > > Hi Thomas, > > > > > > > > Have you tried to build this package yourself? I get a linker > error > > .. > > > > unresolved symbol "gmp". > > > > > > > > Vasili > > > > > > > > > > > > > > > > > > > > On 2/4/08, Thomas Schilling wrote: > > > > > Build-type: Configure means that *Cabal uses ./configure * to > build > > > > > the package. Nothing changes for you. Just use the usual: > > > > > > > > > > runhaskell Setup.hs configure --prefix=... [--user] > > > > > runhaskell Setup.hs build > > > > > runhaskell Setup.hs install > > > > > > > > > > or with cabal-install: > > > > > > > > > > cabal install unix > > > > > > > > > > 2008/2/4 Galchin Vasili : > > > > > > Hello, > > > > > > > > > > > > I have been trying to build the unix package on RedHat > RHEL 5. > > > > Over > > > > > > the weekend I read through the Cabal documentation. The > unix-2.2.0.0 > > > > > > unix.cabal specifies the "build-type" attribute as "Configure". > > Based on > > > > > > Cabal doc, I should run ./configure. After this step then what? > > Bottom > > > > line > > > > > > is how do I build the unix-2.2.0.0 package on RHEL 5? > > > > > > > > > > > > Thank you, Vasili > > > > > > _______________________________________________ > > > > > > 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/20080204/2f900afa/attachment.htm From ahey at iee.org Mon Feb 4 12:26:32 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Feb 4 12:25:46 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> References: <404396ef0801280728s36dea93fn27733fc400f4e401@mail.gmail.com> <479E1415.2000908@gotadsl.co.uk> <404396ef0801281007y6a8acd90p434e6604bed15ce9@mail.gmail.com> <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <47A74AC8.7030000@iee.org> Simon Peyton-Jones wrote: > | Yes, using lots of stack is clearly bad with ghc, but this is a ghc > | "bug". In fact the only reason these programs do use lots of stack > | (vs. heap) is just a peculiarity of ghc rts implementation, so it > | really should be ghc that fixes the problem, or at least admits > | responsibility :-) > > I don't think there's anything fundamental here. GHC allocates the stack in the heap, and it can grow as big as you like. The size limit is simply to catch infinite recursion with a more helpful message than "heap overflow". I think. There is one peculiarity though: I don't think we ever shrink the stack, so once it gets big it stays big. This could be fixed, though. Yikes! Sorry, but if what you say is true then things are even worse than I thought :-( This behaviour seems really bad to me, especially for concurrent programs. Also, I can't help thinking that the common justification for the current limit (that it helps find alleged bugs) is a little lame. It only helps find bugs if one expects ones program to use less than 8M of stack (hence if it's using more, it's a bug by ones *own* definition). But if a program or library is deliberately designed to make use of stack (in preference to heap) for efficiency reasons (or even just to avoid the awkwardness of using explict CPS style), then this is a source of bugs in otherwise perfectly correct and reasonable programs. If we want some way of investigating a programs stack use there must be a better way of doing it than deliberately inducing a crash in any program that exceeds 8M of stack. Thanks for the answer though. I think I'll write a ticket about this :-) Regards -- Adrian Hey From magnus at therning.org Mon Feb 4 12:28:09 2008 From: magnus at therning.org (Magnus Therning) Date: Mon Feb 4 12:27:16 2008 Subject: [Haskell-cafe] modeling ANSI C structs in Haskell? In-Reply-To: <5ae4f2ba0802040704o6dafd4eawf2a452c65e1dc8fc@mail.gmail.com> References: <5ae4f2ba0802040704o6dafd4eawf2a452c65e1dc8fc@mail.gmail.com> Message-ID: On 2/4/08, Galchin Vasili wrote: > > Hello, > > I am reading through the FFI doc. Any suggestions on enabling > Haskell programmers to model ANSI C structs that will be passed down to C > run-time? > Maybe this could offer some help http://therning.org/magnus/archives/315 /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/ce76651f/attachment.htm From clifford.beshers at gmail.com Mon Feb 4 12:30:48 2008 From: clifford.beshers at gmail.com (Clifford Beshers) Date: Mon Feb 4 12:29:52 2008 Subject: [Haskell-cafe] Bug in System.Environment - EOT inserted into argument string In-Reply-To: References: Message-ID: <6841b9520802040930y1c928d5ci1c601a7f2f6b01bb@mail.gmail.com> No, I cannot reproduce this. 2008/2/4 David Fox : > I'm seeing the character ^D inserted into argument strings that are about > 256 characters long with GHC 6.8.2. Anyone else? > > Test.hs: > > module Main where > > import System.Environment > import System.IO > > main = > do args <- getArgs > hPutStrLn stderr ("args: " ++ show args) > > > Output: > > $ ghc6 --make Test.hs -o test > [1 of 1] Compiling Main ( Test.hs, Test.o ) > Linking test ... > $ ./test > "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789" > args: > ["01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234\EOT5678901234567890123456789"] > > > _______________________________________________ > 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/20080204/0d318d34/attachment.htm From derek.a.elkins at gmail.com Mon Feb 4 11:32:08 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Feb 4 12:32:01 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: Message-ID: <1202142728.12961.4.camel@derek-laptop> On Mon, 2008-02-04 at 12:22 -0200, Felipe Lessa wrote: > Hi there, > > Reading http://www.haskell.org/haskellwiki/Things_to_avoid I found an > interesting saying: > > "By the way, in the case of IO monad the Functor class method fmap and > the Monad based function liftM are the same." > > I always tought that > > prop :: (Functor m, Monad m, Eq (m b)) => (a -> b) -> m a -> Bool > prop f x = fmap f x == liftM f x > > was True regardless of 'm'. Is there any exception? If there is, it's a bug in the library except you wouldn't normally use (==) but some meta-level equality*. From one perspective, liftM is the proof that every monad is a functor. * Usually observational equality, but one may want variants, e.g. observational equality with respect to some "observe" function From simonpj at microsoft.com Mon Feb 4 12:40:40 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 4 12:39:46 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A74AC8.7030000@iee.org> References: <404396ef0801280728s36dea93fn27733fc400f4e401@mail.gmail.com> <479E1415.2000908@gotadsl.co.uk> <404396ef0801281007y6a8acd90p434e6604bed15ce9@mail.gmail.com> <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> | Sorry, but if what you say is true then things are even worse than I | thought :-( This behaviour seems really bad to me, especially for | concurrent programs. Which behaviour precisely? Can you say what is wrong and what behaviour you expect? S From ddssff at gmail.com Mon Feb 4 12:45:57 2008 From: ddssff at gmail.com (David Fox) Date: Mon Feb 4 12:45:01 2008 Subject: [Haskell-cafe] Bug in System.Environment - EOT inserted into argument string In-Reply-To: <6841b9520802040930y1c928d5ci1c601a7f2f6b01bb@mail.gmail.com> References: <6841b9520802040930y1c928d5ci1c601a7f2f6b01bb@mail.gmail.com> Message-ID: I think it is a bug in the emacs shell mode. On Feb 4, 2008 9:30 AM, Clifford Beshers wrote: > No, I cannot reproduce this. > > 2008/2/4 David Fox : > > > I'm seeing the character ^D inserted into argument strings that are > > about 256 characters long with GHC 6.8.2. Anyone else? > > > > Test.hs: > > > > module Main where > > > > import System.Environment > > import System.IO > > > > main = > > do args <- getArgs > > hPutStrLn stderr ("args: " ++ show args) > > > > > > Output: > > > > $ ghc6 --make Test.hs -o test > > [1 of 1] Compiling Main ( Test.hs, Test.o ) > > Linking test ... > > $ ./test > > "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789" > > args: > > ["01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234\EOT5678901234567890123456789"] > > > > > > _______________________________________________ > > 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/20080204/5bfe7821/attachment.htm From miguelimo38 at yandex.ru Mon Feb 4 12:55:50 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Mon Feb 4 12:55:04 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: Message-ID: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> > Problem is that from the idea Functor is a superclass of Monad, with > the > property that "fmap == liftM". [cut] > The second relation can even not be expressed in Haskell 98. Erm... class Functor f where fmap :: (a -> b) -> f a -> f b class Functor m => Monad m where return :: a -> m a join :: m (m a) -> m a bind :: Monad m => m a -> (a -> m b) -> m b bind mx f = join $ fmap f mx Now liftM must be exactly equal to fmap. From briqueabraque at yahoo.com Mon Feb 4 13:11:55 2008 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Feb 4 13:11:22 2008 Subject: [Haskell-cafe] Is Haskore dead? Message-ID: Hi, I've just tried using Haskore (I use Ubuntu and GHC), with no success. Since Haskore was started a long time ago, but it's not yet cabalized, and the author's page can not be reached, I can't say for sure if it's still maintained. Does anybody know? Thanks, Maur?cio From gwern0 at gmail.com Mon Feb 4 13:32:20 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Mon Feb 4 13:32:01 2008 Subject: [Haskell-cafe] Is Haskore dead? In-Reply-To: References: Message-ID: <20080204183220.GA311608@localhost> On 2008.02.04 16:11:55 -0200, Maur??cio scribbled 0.3K characters: > Hi, > > I've just tried using Haskore (I use Ubuntu > and GHC), with no success. Since Haskore was > started a long time ago, but it's not yet > cabalized, and the author's page can not be > reached, I can't say for sure if it's still > maintained. Does anybody know? > > Thanks, > Maur?cio I think the homepage is more than a bit old. I googled a bit more, and found which links to a Darcs repo at . The most recent modification date is for src/, 04-Dec-2007. I'm trying it out right now, but the darcs get is taking a while. -- gwern ssa NMS encryption Finksburg Panama 1071 fraud import MDA South -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/e547aa1c/attachment-0001.bin From ndmitchell at gmail.com Mon Feb 4 13:35:23 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 4 13:34:27 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A74AC8.7030000@iee.org> References: <404396ef0801281007y6a8acd90p434e6604bed15ce9@mail.gmail.com> <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> Message-ID: <404396ef0802041035h4029c6e7u803cbfbc3301f6ad@mail.gmail.com> Hi > But if a program or library is deliberately designed to > make use of stack (in preference to heap) for efficiency reasons > then this is a source of bugs in otherwise perfectly correct and > reasonable programs. Can you give an example of a particular library or program, so everyone can be a bit more concrete about what you think should be allowed, but that isn't? Thanks Neil From matthew.pocock at ncl.ac.uk Mon Feb 4 12:33:36 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Mon Feb 4 13:38:54 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A74AC8.7030000@iee.org> References: <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> Message-ID: <200802041733.37370.matthew.pocock@ncl.ac.uk> On Monday 04 February 2008, Adrian Hey wrote: > Yikes! > > Also, I can't help thinking that the common justification for the > current limit (that it helps find alleged bugs) is a little lame. > It only helps find bugs if one expects ones program to use less than > 8M of stack (hence if it's using more, it's a bug by ones *own* > definition). My experience so far is that I've only triggered stack overflows when I've had an infinite recursion. Getting foldl and foldr wrong on long lists has usually lead to disasterous memory churn, not ever to an overflow. > Regards > -- > Adrian Hey From ahey at iee.org Mon Feb 4 14:23:09 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Feb 4 14:22:24 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> References: <404396ef0801280728s36dea93fn27733fc400f4e401@mail.gmail.com> <479E1415.2000908@gotadsl.co.uk> <404396ef0801281007y6a8acd90p434e6604bed15ce9@mail.gmail.com> <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <47A7661D.7090603@iee.org> Hello Simon, Simon Peyton-Jones wrote: > | Sorry, but if what you say is true then things are even worse than I > | thought :-( This behaviour seems really bad to me, especially for > | concurrent programs. > > Which behaviour precisely? Can you say what is wrong and what behaviour you expect? Roughly.. First bad thing: Stack size (memory consumed) doubles each time it overflows. Second bad thing: Arbitrary limit on stack size unrelated to overall (heap) memory available. Third bad thing (the really bad thing): If a stack has temporarily grown (to 64M say), it will never shrink back down again to something more typical (< 4K say). If I understand correctly, it will continue to take 64M from the heap regardless. What I would like is to be able to set an upper limit on total memory useage and allow the program to freely use this memory as either stack or heap. At least that should be the default behaviour, but maybe also allow +RTS restrictions for "debugging" (though I don't think this is a very good way of investigating a programs stack use). I would also like stack memory allocation to increase (and decrease :-) in some sane sized linear increment, not double each time. With the current scheme, as I understand it, if 65M is needed then 128M will be allocated. Stefan O'Rear suggested an alternative. I don't know how hard it would be to implement though (don't really know anything about ghc rts). http://haskell.org/pipermail/glasgow-haskell-users/2007-May/012472.html Regards -- Adrian Hey From g9ks157k at acme.softbase.org Mon Feb 4 14:27:59 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 4 14:27:19 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802041236.55480.g9ks157k@acme.softbase.org> <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> Message-ID: <200802042028.00034.g9ks157k@acme.softbase.org> Am Montag, 4. Februar 2008 13:22 schrieben Sie: > On Feb 4, 2008 12:36 PM, Wolfgang Jeltsch wrote: >[?] > I don't still know how many people would be interested in using the > type-level library so, again, I think it won't hurt to include the > TH-generated aliases and then change it if some non-GHC user rants > about it. Okay, let?s do so for now. > > So type-level + parametrized-data is my vote. But don't let's spend too > > much time discussing the name. ;-) > > Fair enough. type-level + parameterized-data it is then (unless > someone else has a better suggestion). I'm going to begin coding now. Yes, go ahead. :-) Thanks a lot. > I'll host the project in community.haskell.org, do you have an account > there? Now, I haven?t. :-( > PS: BTW, I asked Oleg for permission and, as expected, agreed to > create the library under a BS-D license. Great. So the packages you create now will be released under BSD3, right? Best wishes, Wolfgang From ndmitchell at gmail.com Mon Feb 4 14:44:00 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 4 14:43:06 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A7661D.7090603@iee.org> References: <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> Message-ID: <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> Hi > First bad thing: > Stack size (memory consumed) doubles each time it overflows. Bad thing? Assume that allocating memory takes some constant amount of time, such as invoking overflow behaviour etc. To get the size of the stack to n bytes with doubling takes O(log n), to get it there with a constant increase takes O(n). If you store the stack in a linear block, then allocation costs O(n) and you can even risk O(n^2) behaviour unless you double each time. I think its fairly well understood that things like hash tables should double in size when they overflow, rather than increasing by some small increment. Also remember that this behaviour never wastes more than 50% of the stack, which is a relatively small amount. > Third bad thing (the really bad thing): > If a stack has temporarily grown (to 64M say), it will never shrink > back down again to something more typical (< 4K say). If I understand > correctly, it will continue to take 64M from the heap regardless. That would be nice. But its only beneficial if there are programs which takes large amounts of stack at some point, but then shrink down to very little stack and continue for a reasonable amount of time. Console programs probably don't fit this pattern (since they tend to be batch style and exit quickly). GUI programs probably do, so perhaps stack reduction will be more important as the GUI toolkits mature and Haskell starts getting used for UI type things. That said, unless there is a real user with a real problem (rather than a theoretical concern), priority may go to other bugs. Thanks Neil From alfonso.acosta at gmail.com Mon Feb 4 14:44:04 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Feb 4 14:43:20 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802042028.00034.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802041236.55480.g9ks157k@acme.softbase.org> <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> <200802042028.00034.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802041144n6ea1ae65yf0f1fa16991c367d@mail.gmail.com> On Feb 4, 2008 8:27 PM, Wolfgang Jeltsch wrote: > Am Montag, 4. Februar 2008 13:22 schrieben Sie: > > I don't still know how many people would be interested in using the > > type-level library so, again, I think it won't hurt to include the > > TH-generated aliases and then change it if some non-GHC user rants > > about it. > > Okay, let's do so for now. Actually, I was considering to conditionally include the TH code or not depending on the compiler (using Cabal configurations). I thought "that should make everyone happy". Then, I realized we agreed to make use of infix type constructors anyway (which seems to be a GHC-only extension, tell me if I'm wrong), so the TH dependency is not that important anymore (unless we decide to avoid infix type constructors) > > I'll host the project in community.haskell.org, do you have an account > > there? > > Now, I haven't. :-( Well, you can request one at http://community.haskell.org/admin/account_request.html if you want Otherwise I'll take the maintainer role. > > PS: BTW, I asked Oleg for permission and, as expected, agreed to > > create the library under a BS-D license. > > Great. So the packages you create now will be released under BSD3, right? Yes, that's the intention. From g9ks157k at acme.softbase.org Mon Feb 4 14:56:20 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 4 14:55:29 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802041144n6ea1ae65yf0f1fa16991c367d@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802042028.00034.g9ks157k@acme.softbase.org> <6a7c66fc0802041144n6ea1ae65yf0f1fa16991c367d@mail.gmail.com> Message-ID: <200802042056.20108.g9ks157k@acme.softbase.org> Am Montag, 4. Februar 2008 20:44 schrieben Sie: > > > I'll host the project in community.haskell.org, do you have an account > > > there? > > > > Now, I haven't. :-( > > Well, you can request one at > http://community.haskell.org/admin/account_request.html if you want > > Otherwise I'll take the maintainer role. I?m fine with you having the maintainer role as long as you accept a patch from me from time to time. :-) Best wishes, Wolfgang From matthew.pocock at ncl.ac.uk Mon Feb 4 15:45:51 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Mon Feb 4 15:44:50 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> References: <47A7661D.7090603@iee.org> <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> Message-ID: <200802042045.51678.matthew.pocock@ncl.ac.uk> On Monday 04 February 2008, Neil Mitchell wrote: > Hi > That would be nice. But its only beneficial if there are programs > which takes large amounts of stack at some point, but then shrink down > to very little stack and continue for a reasonable amount of time. From the 'when I was a lad' department... Thinking back to when Java transitioned to a garbage collector that could give memory back to the OS, we got some unexpected benefits. Consider a machine that's running a load of programs, launched from some q system e.g. LSF/condor. If they keep memory, the box, q scheduler or admins get unhappy. If I had ?1 for each time our admins said "your 200 java apps are using 500m each!!!!" when I could see for sure that except for an initial memory burn during loading files in, only a few megs where resident. Magically, once Java could release heap, these grypes went away. Matthew > Thanks > > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From cgibbard at gmail.com Mon Feb 4 16:56:12 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Mon Feb 4 16:55:18 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: <20080204125943.GA10030@kantaka.co.uk> References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> <20080201214858.GF31711@cs.cmu.edu> <20080204125943.GA10030@kantaka.co.uk> Message-ID: <89ca3d1f0802041356x694d5bb6v39dc9639762dba2c@mail.gmail.com> On 04/02/2008, Philip Armstrong wrote: > > I've always liked $ for this kind of code, if you want to keep the > arguments around: > > next xs = runCont $ sequence $ map Cont xs > > seems quite natural to me. > I'd probably write that as nest xs = runCont . sequence . map Cont $ xs or else as: nest xs = runCont . sequence $ map Cont xs so as not to abuse the fact that ($) really has the wrong associativity. (I didn't really give that aspect of the code a moment's thought, or else I'd probably have made it either points-free or used the first form above. I've been bitten by the MR enough times that I'm wary of eta-reducing the last parameter out of functions -- of course, the explicit type signature means it doesn't matter.) It would be nice to flip the associativity of ($) someday. It loses little in the way of expressiveness, since one can generally replace the first (n-1) instances of ($) with (.) straightforwardly (the one exception to this being when there are other operator symbols like (***) acting on the functions involved, but these cases are fairly rare, and it's arguably clearer to leave those parens in). What it would buy us to make ($) left associative is that we could, for instance, remove the parens from an expression like: f (g x) (h y) (k z) getting: f $ g x $ h y $ k z Perhaps for Haskell 2. :) - Cale From ahey at iee.org Mon Feb 4 17:13:12 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Feb 4 17:12:25 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> References: <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> Message-ID: <47A78DF8.8000907@iee.org> Neil Mitchell wrote: > Hi > >> First bad thing: >> Stack size (memory consumed) doubles each time it overflows. > > Bad thing? Assume that allocating memory takes some constant amount of > time, such as invoking overflow behaviour etc. To get the size of the > stack to n bytes with doubling takes O(log n), to get it there with a > constant increase takes O(n). But whatever the program did to get given stack size must have been at least O(n) anyway, so overall it's still going to be O(n) even if the stack allocation part is O(log n). We're just talking about a very tiny increase in constant factors, at least if Stefan O'Rears hypothesis is correct :-). I'm inclined to agree with him. > If you store the stack in a linear > block, then allocation costs O(n) and you can even risk O(n^2) > behaviour unless you double each time. I think its fairly well > understood that things like hash tables should double in size when > they overflow, rather than increasing by some small increment. It is? Well obviously if the entire thing is copied each time this will be bad, but that's not what we're talking about. See Stefans proposal. > Also > remember that this behaviour never wastes more than 50% of the stack, > which is a relatively small amount. Only if the stack is relatively small. Would you say the same about heap, or about a stack that only needed 50% of heap space but ended up using all of it? Or money? Using twice as much as you need of anything is bad IMO. >> Third bad thing (the really bad thing): >> If a stack has temporarily grown (to 64M say), it will never shrink >> back down again to something more typical (< 4K say). If I understand >> correctly, it will continue to take 64M from the heap regardless. > > That would be nice. But its only beneficial if there are programs > which takes large amounts of stack at some point, but then shrink down > to very little stack and continue for a reasonable amount of time. > Console programs probably don't fit this pattern (since they tend to > be batch style and exit quickly). GUI programs probably do, so perhaps > stack reduction will be more important as the GUI toolkits mature and > Haskell starts getting used for UI type things. The nature of the app has nothing to do with it AFAICS, this problem can affect any program that evaluates expressions. > That said, unless > there is a real user with a real problem (rather than a theoretical > concern), priority may go to other bugs. The point is that writing a stack greedy function definition (rather than a heap greedy alternative) is almost always the simpler option, and would probably be more efficent too. It would also be perfectly OK in *most* situations. But being OK in most situations isn't good enough. You also (as far as is possible given finite amount of total memory) want it to be OK in "pathological" situations, or at least no worse than the heap greedy version. Why should the decision to use a stack greedy definition cause a crash at 8M whereas a heap greedy definition can happily use much more without crashing? I (like everyone else) tend to avoid knowingly writing stack greedy definitions because of this. But I do this as a workaround for ghc's currently (IMO) poor stack management, not because I consider code that uses the stack to be inherently buggy. Furthermore as I said earlier, "using a lot of stack" is purely a ghc rts implementation detail. Other possible Haskell implementations may not use a lot of stack for the same function (may not use a stack at all). So you can't say a program has bugs just because it happens to cause a "stack overflow" with ghc. You might reasonably argue that it has a bug if it uses a lot of memory with any plausible Haskell implementation (one way or another) *and* you can show that there is an alternative implementation which uses asymptotically less memory. Regards -- Adrian Hey From bbrown at botspiritcompany.com Mon Feb 4 17:18:22 2008 From: bbrown at botspiritcompany.com (bbrown) Date: Mon Feb 4 17:17:27 2008 Subject: [Haskell-cafe] Adding gcc type options with cabal (e.g. -mno-cygwin) Message-ID: <20080204221649.M41724@www.botspiritcompany.com> Is there a way to pass misc options to the cabal, ghc process. I tried the following: extra-libraries: sqlite3 extra-lib-dirs: C:\cygwin\lib include-dirs: C:\cygwin\usr\include ghc-options: -mno-cygwin runhaskell Setup.lhs build --ghc-options=-mno-cygwin -v No dice, doesn't show up. -- Berlin Brown email: berlin-dot-brown-AT-gmail-dot-com http://botspiritcompany.com/botlist/ From igloo at earth.li Mon Feb 4 17:20:47 2008 From: igloo at earth.li (Ian Lynagh) Date: Mon Feb 4 17:19:52 2008 Subject: [Haskell-cafe] building the unix package and cabal In-Reply-To: <5ae4f2ba0802040850v30c1a768n6f228f930843b87c@mail.gmail.com> References: <5ae4f2ba0802040633l22b506c9id47bf2dfc73d9fd0@mail.gmail.com> <916b84820802040705w59183b3an88872de0448f26d5@mail.gmail.com> <5ae4f2ba0802040743n6e876829m4e4791262774176a@mail.gmail.com> <916b84820802040753i6869afa3s43d4046c31fd83e7@mail.gmail.com> <5ae4f2ba0802040822p62d4ac94p1d29f6562501ac2d@mail.gmail.com> <916b84820802040833g72d34d91ifd834a667aebe86b@mail.gmail.com> <5ae4f2ba0802040850v30c1a768n6f228f930843b87c@mail.gmail.com> Message-ID: <20080204222047.GA18871@matrix.chaos.earth.li> On Mon, Feb 04, 2008 at 10:50:13AM -0600, Galchin Vasili wrote: > more specifically the "gmp" unsatisfied ref shows up with the DynamicLinker. This works for me, with GHC 6.8.2 and http://hackage.haskell.org/packages/archive/unix/2.2.0.0/unix-2.2.0.0.tar.gz $ ghc --make Setup $ ./Setup configure --user $ ./Setup build If it's not working for you then you might need a RHEL package called something like gmp-devel. If that doesn't fix it, please send us the exact commands you are running and the complete output. Note that you wouldn't normally compile the unix package yourself, however, as it is one of the packages that comes with GHC. Thanks Ian From prstanley at ntlworld.com Mon Feb 4 17:20:51 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Feb 4 17:20:05 2008 Subject: [Haskell-cafe] FP and Quality Message-ID: <7.0.1.0.0.20080204221330.01ced7e8@ntlworld.com> Hi folks I'm thinking of writing a little essay arguing the case for the advantages of FP for producing quality software. Can the list recommend any papers/articles which I can use as sources of my argument? I have access to the IEEE database too although earlier I couldn't find anything on the subject. Thanks, Paul From dons at galois.com Mon Feb 4 17:24:12 2008 From: dons at galois.com (Don Stewart) Date: Mon Feb 4 17:23:18 2008 Subject: [Haskell-cafe] Adding gcc type options with cabal (e.g. -mno-cygwin) In-Reply-To: <20080204221649.M41724@www.botspiritcompany.com> References: <20080204221649.M41724@www.botspiritcompany.com> Message-ID: <20080204222412.GF32486@scytale.galois.com> bbrown: > Is there a way to pass misc options to the cabal, ghc process. > > I tried the following: > > extra-libraries: sqlite3 > extra-lib-dirs: C:\cygwin\lib > include-dirs: C:\cygwin\usr\include > ghc-options: -mno-cygwin > > runhaskell Setup.lhs build --ghc-options=-mno-cygwin -v ghc-options: -optc-mno-cygwin cc-options: -mno-cygwin or ghc-options: -O2 -Wall cc-options: -Wall or via the foo.buildinfo file. Ghc-options: -optc@CPPFLAGS@ Cc-options: @CPPFLAGS@ Writing a binding to sqlite3? -- Don From bbrown at botspiritcompany.com Mon Feb 4 17:27:30 2008 From: bbrown at botspiritcompany.com (bbrown) Date: Mon Feb 4 17:26:52 2008 Subject: [Haskell-cafe] Adding gcc type options with cabal (e.g. -mno-cygwin) In-Reply-To: <20080204222412.GF32486@scytale.galois.com> References: <20080204221649.M41724@www.botspiritcompany.com> <20080204222412.GF32486@scytale.galois.com> Message-ID: <20080204222645.M84700@www.botspiritcompany.com> On Mon, 4 Feb 2008 14:24:12 -0800, Don Stewart wrote > bbrown: > > Is there a way to pass misc options to the cabal, ghc process. > > > > I tried the following: > > > > extra-libraries: sqlite3 > > extra-lib-dirs: C:\cygwin\lib > > include-dirs: C:\cygwin\usr\include > > ghc-options: -mno-cygwin > > > > runhaskell Setup.lhs build --ghc-options=-mno-cygwin -v > > ghc-options: -optc-mno-cygwin > cc-options: -mno-cygwin > > or > ghc-options: -O2 -Wall > cc-options: -Wall > > or via the foo.buildinfo file. > > Ghc-options: -optc@CPPFLAGS@ > Cc-options: @CPPFLAGS@ > > Writing a binding to sqlite3? > > -- Don > Writing a binding to sqlite3? No, one already exists. Trying to compile that one. My googling powers are crippled with haskell. I couldn't find how to add those options. Thanks for the quick response. -- Berlin Brown email: berlin-dot-brown-AT-gmail-dot-com http://botspiritcompany.com/botlist/ From bbrown at botspiritcompany.com Mon Feb 4 17:42:46 2008 From: bbrown at botspiritcompany.com (bbrown) Date: Mon Feb 4 17:41:49 2008 Subject: [Haskell-cafe] Adding gcc type options with cabal (e.g. -mno-cygwin) In-Reply-To: <20080204222645.M84700@www.botspiritcompany.com> References: <20080204221649.M41724@www.botspiritcompany.com> <20080204222412.GF32486@scytale.galois.com> <20080204222645.M84700@www.botspiritcompany.com> Message-ID: <20080204224031.M3882@www.botspiritcompany.com> On Mon, 4 Feb 2008 17:27:30 -0500, bbrown wrote > On Mon, 4 Feb 2008 14:24:12 -0800, Don Stewart wrote > > bbrown: > > > Is there a way to pass misc options to the cabal, ghc process. > > > > > > I tried the following: > > > > > > extra-libraries: sqlite3 > > > extra-lib-dirs: C:\cygwin\lib > > > include-dirs: C:\cygwin\usr\include > > > ghc-options: -mno-cygwin > > > > > > runhaskell Setup.lhs build --ghc-options=-mno-cygwin -v > > > > ghc-options: -optc-mno-cygwin > > cc-options: -mno-cygwin > > > > or > > ghc-options: -O2 -Wall > > cc-options: -Wall > > > > or via the foo.buildinfo file. > > > > Ghc-options: -optc@CPPFLAGS@ > > Cc-options: @CPPFLAGS@ > > > > Writing a binding to sqlite3? > > > > -- Don > > > Writing a binding to sqlite3? > > No, one already exists. Trying to compile that one. My googling > powers are crippled with haskell. I couldn't find how to add those options. > > Thanks for the quick response. > > -- > Berlin Brown > email: berlin-dot-brown-AT-gmail-dot-com > http://botspiritcompany.com/botlist/ I couldn't get hsql-sqlite (other unix libraries?) to compile on cygwin. I tried though. It looks like it is passing the option. The sqlite3 library is installed and setup. From googling, it looks there is an issue with compatibility between cygwin/ and whatever ghc was compiled with. But then again, I guess I could not try using cygwin? I built the library (sqlite3 under cygwin). Download ghc6.8.2 straight from the haskell.org. Creating dist\build (and its parents) Creating dist\build\autogen (and its parents) Preprocessing library hsql-sqlite3-1.7... Creating dist\build\Database\HSQL (and its parents) c:\projects\tools\home\projects\tmp3\ghc-6.8.2\bin\hsc2hs.exe --cc=c:\projects\t ools\home\projects\tmp3\ghc-6.8.2\bin\ghc.exe --ld=c:\projects\tools\home\projec ts\tmp3\ghc-6.8.2\bin\ghc.exe --cflag=-optc-mno-cygwin --cflag=-package --cflag= base-3.0.1.0 --cflag=-package --cflag=hsql-1.7 --cflag=-IC:\cygwin\usr\include - -lflag=-optl-LC:\cygwin\lib --lflag=-optl-lsqlite3 -o dist\build\Database\HSQL\S QLite3.hs Database\HSQL\SQLite3.hsc dist/build/Database/HSQL/SQLite3_hsc_make.o(.text+0x5d):SQLite3_hsc_make.c: unde fined reference to `_impure_ptr' dist/build/Database/HSQL/SQLite3_hsc_make.o(.text+0xa1):SQLite3_hsc_make.c: unde fined reference to `_impure_ptr' dist/build/Database/HSQL/SQLite3_hsc_make.o(.text+0xc9):SQLite3_hsc_make.c: unde fined reference to `_impure_ptr' dist/build/Database/HSQL/SQLite3_hsc_make.o(.text+0xfd):SQLite3_hsc_make.c: unde fined reference to `_impure_ptr' dist/build/Database/HSQL/SQLite3_hsc_make.o(.text+0x131):SQLite3_hsc_make.c: und efined reference to `_impure_ptr' dist/build/Database/HSQL/SQLite3_hsc_make.o(.text+0x16d):SQLite3_hsc_make.c: mor e undefined references to `_impure_ptr' follow collect2: ld returned 1 exit status linking dist\build\Database\HSQL\SQLite3_hsc_make.o failed command was: c:\projects\tools\home\projects\tmp3\ghc-6.8.2\bin\ghc.exe -optl-LC :\cygwin\lib -optl-lsqlite3 dist\build\Database\HSQL\SQLite3_hsc_make.o -o dist\ build\Database\HSQL\SQLite3_hsc_make.exe -- Berlin Brown email: berlin-dot-brown-AT-gmail-dot-com http://botspiritcompany.com/botlist/ From vigalchin at gmail.com Mon Feb 4 17:47:32 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Mon Feb 4 17:46:37 2008 Subject: [Haskell-cafe] building the unix package and cabal In-Reply-To: <20080204222047.GA18871@matrix.chaos.earth.li> References: <5ae4f2ba0802040633l22b506c9id47bf2dfc73d9fd0@mail.gmail.com> <916b84820802040705w59183b3an88872de0448f26d5@mail.gmail.com> <5ae4f2ba0802040743n6e876829m4e4791262774176a@mail.gmail.com> <916b84820802040753i6869afa3s43d4046c31fd83e7@mail.gmail.com> <5ae4f2ba0802040822p62d4ac94p1d29f6562501ac2d@mail.gmail.com> <916b84820802040833g72d34d91ifd834a667aebe86b@mail.gmail.com> <5ae4f2ba0802040850v30c1a768n6f228f930843b87c@mail.gmail.com> <20080204222047.GA18871@matrix.chaos.earth.li> Message-ID: <5ae4f2ba0802041447x77c9eec1hd2bf51428df9a6b6@mail.gmail.com> Hi Ian, I am trying to add new Posix functionality and it would be nice to be able to build unix myself. In any case, I will try your suggestion and see what happens. Regards, Vasili On 2/4/08, Ian Lynagh wrote: > > On Mon, Feb 04, 2008 at 10:50:13AM -0600, Galchin Vasili wrote: > > more specifically the "gmp" unsatisfied ref shows up with the > DynamicLinker. > > This works for me, with GHC 6.8.2 and > > http://hackage.haskell.org/packages/archive/unix/2.2.0.0/unix-2.2.0.0.tar.gz > > $ ghc --make Setup > $ ./Setup configure --user > $ ./Setup build > > If it's not working for you then you might need a RHEL package called > something like gmp-devel. If that doesn't fix it, please send us the > exact commands you are running and the complete output. > > Note that you wouldn't normally compile the unix package yourself, > however, as it is one of the packages that comes with GHC. > > > Thanks > Ian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080204/9dee4f57/attachment.htm From duncan.coutts at worc.ox.ac.uk Mon Feb 4 17:55:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 4 17:54:44 2008 Subject: [Haskell-cafe] Adding gcc type options with cabal (e.g. -mno-cygwin) In-Reply-To: <20080204221649.M41724@www.botspiritcompany.com> References: <20080204221649.M41724@www.botspiritcompany.com> Message-ID: <1202165735.13130.246.camel@localhost> On Mon, 2008-02-04 at 17:18 -0500, bbrown wrote: > Is there a way to pass misc options to the cabal, ghc process. > > I tried the following: > > extra-libraries: sqlite3 > extra-lib-dirs: C:\cygwin\lib > include-dirs: C:\cygwin\usr\include > ghc-options: -mno-cygwin > > runhaskell Setup.lhs build --ghc-options=-mno-cygwin -v > > No dice, doesn't show up. Really? That's odd, works for me: $ runhaskell Setup.lhs build --ghc-options=-mno-cygwin -v ... [snip] ... ghc-6.8.2: unrecognised flags: -mno-cygwin Usage: For basic information, try the `--help' option. Also works with runhaskell Setup.lhs configure --ghc-options=-mno-cygwin Works in the sense that it passes the flag through to ghc. Of course I'm on unix and ghc does not recognise that flag. What version of Cabal are you using? Duncan From duncan.coutts at worc.ox.ac.uk Mon Feb 4 18:18:19 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 4 18:17:25 2008 Subject: [Haskell-cafe] RE: highlighting-kate - syntax highlighting library In-Reply-To: References: <438300e50802031242h454c15b2y79394c9ea5a44731@mail.gmail.com> Message-ID: <1202167099.13130.249.camel@localhost> On Sun, 2008-02-03 at 19:38 -0200, Felipe Lessa wrote: > On Feb 3, 2008 6:42 PM, mgsloan wrote: > > Would this be suitable for a text editor? > > Note that we already have a binding to GtkSourceView, see > http://www.haskell.org/gtk2hs/docs/current/Graphics-UI-Gtk-SourceView.html BTW, if anyone wants to update this binding to the GtkSourceView 2.x api that'd be great. The api has not changed much so the changes should be pretty simple. The advantage is that the 2.x version has a much better highlighting engine which allows more accurate highlighters. Duncan From derek.a.elkins at gmail.com Mon Feb 4 17:26:39 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Feb 4 18:26:31 2008 Subject: [Haskell-cafe] A handy little consequence of the Cont monad In-Reply-To: <89ca3d1f0802041356x694d5bb6v39dc9639762dba2c@mail.gmail.com> References: <89ca3d1f0801312109k718f60a9maeef1c5e1025cc28@mail.gmail.com> <1201901226.5496.79.camel@derek-laptop> <20080201214858.GF31711@cs.cmu.edu> <20080204125943.GA10030@kantaka.co.uk> <89ca3d1f0802041356x694d5bb6v39dc9639762dba2c@mail.gmail.com> Message-ID: <1202164000.12961.6.camel@derek-laptop> On Mon, 2008-02-04 at 16:56 -0500, Cale Gibbard wrote: > On 04/02/2008, Philip Armstrong wrote: > > > > I've always liked $ for this kind of code, if you want to keep the > > arguments around: > > > > next xs = runCont $ sequence $ map Cont xs > > > > seems quite natural to me. > > > > I'd probably write that as > > nest xs = runCont . sequence . map Cont $ xs > > or else as: > > nest xs = runCont . sequence $ map Cont xs > > so as not to abuse the fact that ($) really has the wrong > associativity. (I didn't really give that aspect of the code a > moment's thought, or else I'd probably have made it either points-free > or used the first form above. I've been bitten by the MR enough times > that I'm wary of eta-reducing the last parameter out of functions -- > of course, the explicit type signature means it doesn't matter.) > > It would be nice to flip the associativity of ($) someday. It loses > little in the way of expressiveness, since one can generally replace > the first (n-1) instances of ($) with (.) straightforwardly (the one > exception to this being when there are other operator symbols like > (***) acting on the functions involved, but these cases are fairly > rare, and it's arguably clearer to leave those parens in). > > What it would buy us to make ($) left associative is that we could, > for instance, remove the parens from an expression like: > > f (g x) (h y) (k z) > > getting: > > f $ g x $ h y $ k z and also, pointedly, f $! g x $! h y $! k z or even just f $! x $! y > Perhaps for Haskell 2. :) We'll get rid of the monomorphism restriction then too and you won't have to be wary. From catamorphism at gmail.com Mon Feb 4 18:39:32 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Mon Feb 4 18:38:35 2008 Subject: [Haskell-cafe] FP and Quality In-Reply-To: <7.0.1.0.0.20080204221330.01ced7e8@ntlworld.com> References: <7.0.1.0.0.20080204221330.01ced7e8@ntlworld.com> Message-ID: <4683d9370802041539s6b156c0es48e95c3643904ef4@mail.gmail.com> On 2/4/08, PR Stanley wrote: > Hi folks > I'm thinking of writing a little essay arguing the case for the > advantages of FP for producing quality software. Can the list > recommend any papers/articles which I can use as sources of my > argument? I have access to the IEEE database too although earlier I > couldn't find anything on the subject. Try: Philip Wadler. An angry half dozen. SIGPLAN Notices 33(2):25--30, February 1998. [NB. http://citeseer.ist.psu.edu/article/wadler98angry.html ] Also look for the schedules for the 2007 and 2006 CUFP (Commercial Users of Functional Programming) workshops. The schedules have links to slides from talks by people using FP in industry. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Not only would I never want to belong to any club that would have me for a member -- if elected I would wear street shoes onto the squash court and set fire to the ballroom curtains."--Michael Chabon From prstanley at ntlworld.com Mon Feb 4 18:53:59 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Mon Feb 4 18:52:53 2008 Subject: [Haskell-cafe] FP and Quality In-Reply-To: <200802042333.56543.matthew.pocock@ncl.ac.uk> References: <7.0.1.0.0.20080204221330.01ced7e8@ntlworld.com> <200802042333.56543.matthew.pocock@ncl.ac.uk> Message-ID: <7.0.1.0.0.20080204235058.01d00a98@ntlworld.com> Thanks, keep the tips coming. I like the ones about the type safety and line counts. Cheers, Paul At 23:33 04/02/2008, you wrote: >Good luck with this - I'd love to see the outcome. > >My experience is that FP tends to result in a lot less code, so if >there are x >bugs per line of code, FP has less bugs per complete application. > >Talking about haskell, the typesystem dissalows whole classes of bugs. Things >simply do not compile if you stitch the innards together in the wrong order >(particuarly if you are agressive about using the most general types >possible). Since this accounts for perhaps 90% of where I do things wrong in >Java, I get a corresponding decrease in run-time bugs in haskell. However, >this is somewhat compensated for by the effort needed to get haskell programs >through the compiler in the first place - debug at compile or debug at >runtime is the tradeoff here. > >FP is easier to verify mechanically than imperative programming - more of the >logic is exposed directly. It's easier to do by-case proofs, even if they are >by-hand rather than mechanical. > >However, all of this is annecdotal. Good luck collecting real stats, or >peer-reviewed annecdotes. You may have luck looking at bug-fix times vs >number of developers for equivalent FP and Java apps/libs. Worth a shot, >given that the bug-trackers tend to be public. You could probably tie it back >to the size of the 'fix' patches. Get some nice graphs? > >Matthew > >On Monday 04 February 2008, you wrote: > > Hi folks > > I'm thinking of writing a little essay arguing the case for the > > advantages of FP for producing quality software. Can the list > > recommend any papers/articles which I can use as sources of my > > argument? I have access to the IEEE database too although earlier I > > couldn't find anything on the subject. > > Thanks, Paul > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe From jonathanccast at fastmail.fm Mon Feb 4 21:57:48 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Feb 4 21:57:01 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: Message-ID: <2CBD6487-994A-4774-AF6D-BCF0EBB8FBD7@fastmail.fm> On 4 Feb 2008, at 6:22 AM, Felipe Lessa wrote: > Hi there, > > Reading http://www.haskell.org/haskellwiki/Things_to_avoid I found an > interesting saying: > > "By the way, in the case of IO monad the Functor class method fmap and > the Monad based function liftM are the same." > > I always tought that > > prop :: (Functor m, Monad m, Eq (m b)) => (a -> b) -> m a -> Bool > prop f x = fmap f x == liftM f x Indeed, this is an equation from the equivalence of Haskell and category-theoretic monads. Furthermore, the same thing is explicitly asserted by the Haskell 98 Report: [1] Instances of both Monad and Functor should additionally satisfy the law: fmap f xs = xs >>= return . f > was True regardless of 'm'. Is there any exception? There is only one case I'm aware of: if the author of the type forgot to define a functor instance for his monad (I've been guilty of that before, at least). jcc (I fixed the wiki, btw.) [1] http://haskell.org/onlinereport/basic.html#sect6.3.6 From flippa at flippac.org Mon Feb 4 22:11:11 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Mon Feb 4 22:16:27 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <694519c50802031253x2b73b8fblf459a7726d2d2854@mail.gmail.com> References: <1201929342.5496.112.camel@derek-laptop> <694519c50802031253x2b73b8fblf459a7726d2d2854@mail.gmail.com> Message-ID: <2303.86.10.90.232.1202181071.squirrel@www.gradwell.com> On Sun, 3 Feb 2008, Antoine Latter wrote: > Another picky nit: > > The monad transformer type is defined as such: > > > data ParsecT s u m a > > = ParsecT { runParsecT :: State s u -> m (Consumed (m (Reply s u a))) } > > with the Consumed and reply types as: > > > data Consumed a = Consumed a > > | Empty !a > > > data Reply s u a = Ok !a !(State s u) ParseError > > | Error ParseError > > What's the advantage of having a double-wrapping of the base monad `m' > over the simpler type: > > data ParsecT s u m a > = ParsecT { runParsecT :: State s u -> m (Consumed (Reply s u a)) } > It's a necessary part of how Parsec works - both the Consumed and the Reply depend on the input stream, which is now generated from within the base monad. The Consumed result is evaluated in advance of the Reply, so keeping the computations separate preserves an important piece of laziness as m could be a strict monad. For now it's probably a good idea to look for issues that're visible to client code? Turning Parsec into a transformer was long considered an invitation to serious confusion, so it's not surprising that a few things look odd and a few others can be generalised in ways that aren't immediately obvious. -- flippa@flippac.org "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez From aslatter at gmail.com Mon Feb 4 22:26:23 2008 From: aslatter at gmail.com (Antoine Latter) Date: Mon Feb 4 22:25:27 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <2303.86.10.90.232.1202181071.squirrel@www.gradwell.com> References: <1201929342.5496.112.camel@derek-laptop> <694519c50802031253x2b73b8fblf459a7726d2d2854@mail.gmail.com> <2303.86.10.90.232.1202181071.squirrel@www.gradwell.com> Message-ID: <694519c50802041926y475782abufc19b8550b9e7a3d@mail.gmail.com> On Feb 4, 2008 9:11 PM, Philippa Cowderoy wrote: > It's a necessary part of how Parsec works - both the Consumed and the > Reply depend on the input stream, which is now generated from within the > base monad. The Consumed result is evaluated in advance of the Reply, so > keeping the computations separate preserves an important piece of > laziness as m could be a strict monad. > > For now it's probably a good idea to look for issues that're visible to > client code? Turning Parsec into a transformer was long considered an > invitation to serious confusion, so it's not surprising that a few things > look odd and a few others can be generalised in ways that aren't > immediately obvious. After I determined that the pre-release worked fine for the biggest set of parsers I have, I had to find other things to bring up :-) -Antoine From stefanor at cox.net Mon Feb 4 22:56:19 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Feb 4 22:55:23 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A78DF8.8000907@iee.org> References: <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> <47A78DF8.8000907@iee.org> Message-ID: <20080205035619.GA4446@localhost.localdomain> On Mon, Feb 04, 2008 at 10:13:12PM +0000, Adrian Hey wrote: >> Also >> remember that this behaviour never wastes more than 50% of the stack, >> which is a relatively small amount. > > Only if the stack is relatively small. Would you say the same about > heap, or about a stack that only needed 50% of heap space but ended > up using all of it? Or money? Using twice as much as you need of > anything is bad IMO. Apparently you don't realize that GHC normally uses twice as much heap as is needed, due to the decision to use a two-space copying collector by default for the oldest generation. :) 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/20080204/4bd3f9df/attachment.bin From scook0 at gmail.com Mon Feb 4 23:11:27 2008 From: scook0 at gmail.com (Stuart Cook) Date: Mon Feb 4 23:10:30 2008 Subject: [Haskell-cafe] bimap 0.2 Message-ID: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> I've updated the bimap package to version 0.2. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bimap-0.2 The main difference is a pretty comprehensive interface shakeup: the Either variants have been dropped, all L variants have had the L removed from their name, and a few functions have been curried. The end result is an interface much closer to that of Data.Map. (This also means that 0.2 isn't backwards-compatible.) In addition, the package now supports GHC 6.8, and has a few more tests in the test suite. Stuart From cgibbard at gmail.com Tue Feb 5 00:03:38 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Tue Feb 5 00:02:41 2008 Subject: [Haskell-cafe] Minor issue with mapAccumR Message-ID: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> I'm not sure whether this would be considered worth fixing right away, or if we should wait until some other major compatibility breaking language change to fix it, but it appears that somehow the parameters to the function passed to mapAccumR are flipped relative to their natural order. To show what I mean, here is some code: Prelude Data.List> mapAccumR (\x y -> (concat ["(f ",x," ",y,")"], concat ["(g ",x," ",y,")"])) "z" ["1","2","3"] ("(f (f (f z 3) 2) 1)",["(g (f (f z 3) 2) 1)","(g (f z 3) 2)","(g z 3)"]) You can see here that the list is flipped over in the process, even though the right fold structure is there, it ends up looking like a left fold over the reverse of the list. One would want the law: fst . mapAccumR f z = foldr (fst . f) z to be true, but instead we have: fst . mapAccumR (flip f) z = foldr (fst . f) z You can see that structurally if we flip the parameters in the above example: Prelude Data.List> mapAccumR (\y x -> (concat ["(f ",x," ",y,")"], concat ["(g ",x," ",y,")"])) "z" ["1","2","3"] ("(f 1 (f 2 (f 3 z)))",["(g 1 (f 2 (f 3 z)))","(g 2 (f 3 z))","(g 3 z)"]) I also have some diagrams on http://cale.yi.org/index.php/Fold_Diagrams (near the end) displaying the difference, and that's where I first noticed it. Are many people using mapAccumR? How much would it hurt to change it? - Cale From berlin.brown at gmail.com Tue Feb 5 00:10:08 2008 From: berlin.brown at gmail.com (Berlin Brown) Date: Tue Feb 5 00:09:10 2008 Subject: [Haskell-cafe] Adding gcc type options with cabal (e.g. -mno-cygwin) In-Reply-To: <1202165735.13130.246.camel@localhost> References: <20080204221649.M41724@www.botspiritcompany.com> <1202165735.13130.246.camel@localhost> Message-ID: On Feb 4, 2008 5:55 PM, Duncan Coutts wrote: > > On Mon, 2008-02-04 at 17:18 -0500, bbrown wrote: > > Is there a way to pass misc options to the cabal, ghc process. > > > > I tried the following: > > > > extra-libraries: sqlite3 > > extra-lib-dirs: C:\cygwin\lib > > include-dirs: C:\cygwin\usr\include > > ghc-options: -mno-cygwin > > > > runhaskell Setup.lhs build --ghc-options=-mno-cygwin -v > > > > No dice, doesn't show up. > > Really? That's odd, works for me: > > $ runhaskell Setup.lhs build --ghc-options=-mno-cygwin -v > ... > [snip] > ... > ghc-6.8.2: unrecognised flags: -mno-cygwin > Usage: For basic information, try the `--help' option. > > Also works with runhaskell Setup.lhs configure --ghc-options=-mno-cygwin > > Works in the sense that it passes the flag through to ghc. Of course I'm > on unix and ghc does not recognise that flag. > > What version of Cabal are you using? > > Duncan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > It looked like it passed the option, but didn't resolve the issue. Anyone seen that before? See error in previous post. -- Berlin Brown http://botspiritcompany.com/botlist/spring/help/about.html From ahey at iee.org Tue Feb 5 03:41:15 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Feb 5 03:40:26 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <20080205035619.GA4446@localhost.localdomain> References: <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> <47A78DF8.8000907@iee.org> <20080205035619.GA4446@localhost.localdomain> Message-ID: <47A8212B.6050608@iee.org> Stefan O'Rear wrote: > On Mon, Feb 04, 2008 at 10:13:12PM +0000, Adrian Hey wrote: >>> Also >>> remember that this behaviour never wastes more than 50% of the stack, >>> which is a relatively small amount. >> Only if the stack is relatively small. Would you say the same about >> heap, or about a stack that only needed 50% of heap space but ended >> up using all of it? Or money? Using twice as much as you need of >> anything is bad IMO. > > Apparently you don't realize that GHC normally uses twice as much heap > as is needed, due to the decision to use a two-space copying collector > by default for the oldest generation. :) Yikes again! It gets worse :-) Perhaps I should have said *live* heap. Regards -- Adrian Hey From simonpj at microsoft.com Tue Feb 5 03:42:23 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 5 03:41:27 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A7661D.7090603@iee.org> References: <404396ef0801280728s36dea93fn27733fc400f4e401@mail.gmail.com> <479E1415.2000908@gotadsl.co.uk> <404396ef0801281007y6a8acd90p434e6604bed15ce9@mail.gmail.com> <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> | First bad thing: | Stack size (memory consumed) doubles each time it overflows. | | Second bad thing: | Arbitrary limit on stack size unrelated to overall (heap) memory | available. | | Third bad thing (the really bad thing): | If a stack has temporarily grown (to 64M say), it will never shrink | back down again to something more typical (< 4K say). If I understand | correctly, it will continue to take 64M from the heap regardless. | | What I would like is to be able to set an upper limit on total memory | useage and allow the program to freely use this memory as either stack | or heap. At least that should be the default behaviour, but maybe | also allow +RTS restrictions for "debugging" (though I don't think this | is a very good way of investigating a programs stack use). | | I would also like stack memory allocation to increase (and decrease :-) | in some sane sized linear increment, not double each time. With the | current scheme, as I understand it, if 65M is needed then 128M will be | allocated. Would you like to create a ticket for this? I don't know how many people it bites, and how often, but it'd be good to have it recorded. Changing to a linear increment would be relatively straightforward, but would have quadratic copying cost as the stack grew big. Shrinking stacks would not be hard, I think, at the cost of perhaps copying them again if they grew big. | Stefan O'Rear suggested an alternative. I don't know how hard it would | be to implement though (don't really know anything about ghc rts). | | http://haskell.org/pipermail/glasgow-haskell-users/2007-May/012472.html Yes, this is the standard solution, and it's a good one because it has a robust cost model (no quadratic costs). However, it's tricky to get right; copying is simpler. If a significant fraction of runtime (for some interesting program(s)) turned out to be consumed by copying stacks then we could consider this. Simon From ahey at iee.org Tue Feb 5 04:50:09 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Feb 5 04:49:18 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <404396ef0801280728s36dea93fn27733fc400f4e401@mail.gmail.com> <479E1415.2000908@gotadsl.co.uk> <404396ef0801281007y6a8acd90p434e6604bed15ce9@mail.gmail.com> <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <47A83151.7020707@iee.org> Simon Peyton-Jones wrote: > | First bad thing: > | Stack size (memory consumed) doubles each time it overflows. > | > | Second bad thing: > | Arbitrary limit on stack size unrelated to overall (heap) memory > | available. > | > | Third bad thing (the really bad thing): > | If a stack has temporarily grown (to 64M say), it will never shrink > | back down again to something more typical (< 4K say). If I understand > | correctly, it will continue to take 64M from the heap regardless. > | > | What I would like is to be able to set an upper limit on total memory > | useage and allow the program to freely use this memory as either stack > | or heap. At least that should be the default behaviour, but maybe > | also allow +RTS restrictions for "debugging" (though I don't think this > | is a very good way of investigating a programs stack use). > | > | I would also like stack memory allocation to increase (and decrease :-) > | in some sane sized linear increment, not double each time. With the > | current scheme, as I understand it, if 65M is needed then 128M will be > | allocated. > > Would you like to create a ticket for this? OK > I don't know how many people it bites, and how often, The problem is that the fact that it *might* bite often affects your whole coding style (well mine actually :-) for some problems. It also seems to have given rise to the POV that ghc's current behaviour is good because stack use is bad. MHO is that it's only ghc's current behaviour that *makes* stack use bad. I think it bites a lot less often than it otherwise would because most people will deliberately chose to use heap in preference to stack (at least when writing "eager" code) just to avoid the problem. But it still bites pretty often anyway with "lazy" code for unexpected reasons. Arguably such situations are indeed a "bug" more often than not, but I still think terminating the program unnecessarily (at 8M stack) is bad default policy. > Yes, this is the standard solution, and it's a good one because it has a robust cost model (no quadratic costs). However, it's tricky to get right; copying is simpler. If a significant fraction of runtime (for some interesting program(s)) turned out to be consumed by copying stacks then we could consider this. Do you really need such evidence? If we agree that allowing stack to grow to arbitrary (limited only by memory availability) size is reasonable then surely we already know that there will be some stack size for which quadratic copying cost is going to get "stupid" :-) Of course there other possible more radical solutions that come to mind, like not using a (C style) "stack" at all. But I guess we'd be talking about a complete re-write of the pretty much all the rts and much of the compiler to do this :-( Regards -- Adrian Hey From simonpj at microsoft.com Tue Feb 5 04:54:10 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Feb 5 04:53:13 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A83151.7020707@iee.org> References: <404396ef0801280728s36dea93fn27733fc400f4e401@mail.gmail.com> <479E1415.2000908@gotadsl.co.uk> <404396ef0801281007y6a8acd90p434e6604bed15ce9@mail.gmail.com> <1201563268.5444.14.camel@derek-laptop> <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C318326874A5@EA-EXMSG-C334.europe.corp.microsoft.com> | > Yes, this is the standard solution, and it's a good one because it has a robust cost model (no quadratic | costs). However, it's tricky to get right; copying is simpler. If a significant fraction of runtime (for some | interesting program(s)) turned out to be consumed by copying stacks then we could consider this. | | Do you really need such evidence? If we agree that allowing stack to | grow to arbitrary (limited only by memory availability) size is | reasonable then surely we already know that there will be some stack | size for which quadratic copying cost is going to get "stupid" :-) Indeed, in principle. But there are only so many GHC-HQ cycles. Fixing stacks means not fixing something else, so it matters which issues bite most users. This isn't a fixed-sum game. The more people help fix and improve GHC, the more we can focus on the tricky bits that only we can do. Simon From ndmitchell at gmail.com Tue Feb 5 05:11:47 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Feb 5 05:10:48 2008 Subject: [Haskell-cafe] bimap 0.2 In-Reply-To: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> Message-ID: <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> Hi > The main difference is a pretty comprehensive interface shakeup: the > Either variants have been dropped, all L variants have had the L > removed from their name, and a few functions have been curried. The > end result is an interface much closer to that of Data.Map. (This also > means that 0.2 isn't backwards-compatible.) Good, this seems much nicer. A few comments: 1) You depend on MTL, but I can't obviously see why. Perhaps the test suite? 2) The code: {-| Insert a pair of values into the bimap, without checking for overlapping bindings. If either value is already in the bimap, and is not bound to the other value, the bimap will become inconsistent. -} unsafeInsert :: (Ord a, Ord b) => a -> b -> Bimap a b -> Bimap a b unsafeInsert x y (MkBimap left right) = MkBimap (M.insert x y left) (M.insert y x right) To my understanding, this is always safe, since insert will overwrite any existing element in a map. Hence you don't need to do the delete's first. In addition, since Bimap is not exported internally, the invariant will never be violated. 3) insert x y = delete x >>> deleteR y >>> unsafeInsert x y Why not: insert x y = unsafeInsert x y . delete x . delete y Now you don't end up using the arrow combinators, and it becomes more readable (at least to me). Of course, this function may disappear entirely if what I wrote in (2) is correct. I will probably start using the bimap package in my current project, so you already have at least one user :-) Thanks Neil From bulat.ziganshin at gmail.com Tue Feb 5 03:22:36 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 5 05:30:09 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <200802042045.51678.matthew.pocock@ncl.ac.uk> References: <47A7661D.7090603@iee.org> <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> <200802042045.51678.matthew.pocock@ncl.ac.uk> Message-ID: <1835906623.20080205112236@gmail.com> Hello Matthew, Monday, February 4, 2008, 11:45:51 PM, you wrote: >> That would be nice. But its only beneficial if there are programs >> which takes large amounts of stack at some point, but then shrink down >> to very little stack and continue for a reasonable amount of time. > From the 'when I was a lad' department... > Thinking back to when Java transitioned to a garbage collector that could give > memory back to the OS, we got some unexpected benefits. Consider a machine i would be also happy if ghc will return unused *heap* memory back to OS - it's immediately required for my GUI program where users may open huge files and then close them. but i personally don't have the same need for *stack* -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From loup.vaillant at gmail.com Tue Feb 5 05:50:08 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Tue Feb 5 05:49:12 2008 Subject: [Haskell-cafe] bimap 0.2 In-Reply-To: <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> Message-ID: <6f9f8f4a0802050250u348f229frccd850cb5e8d29ee@mail.gmail.com> 2008/2/5, Neil Mitchell : > 3) > insert x y = delete x > >>> deleteR y > >>> unsafeInsert x y > > Why not: > > insert x y = unsafeInsert x y . delete x . delete y > > Now you don't end up using the arrow combinators, and it becomes more > readable (at least to me). Of course, this function may disappear > entirely if what I wrote in (2) is correct. I'd rather prefer the arrow combinator: it let me read the composition in natural order. Sure, ">>>" is more verbose than ".", and less idiomatic, but I tend to think it scale a bit more (in the case of bigger compositions). Well, maybe just a matter of taste... Loup From scook0 at gmail.com Tue Feb 5 06:01:18 2008 From: scook0 at gmail.com (Stuart Cook) Date: Tue Feb 5 06:00:20 2008 Subject: [Haskell-cafe] bimap 0.2 In-Reply-To: <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> Message-ID: <49b351060802050301xd8d19edv2955696680606e3c@mail.gmail.com> On Tue, Feb 5, 2008 at 9:11 PM, Neil Mitchell wrote: > Hi > > > > The main difference is a pretty comprehensive interface shakeup: the > > Either variants have been dropped, all L variants have had the L > > removed from their name, and a few functions have been curried. The > > end result is an interface much closer to that of Data.Map. (This also > > means that 0.2 isn't backwards-compatible.) > > Good, this seems much nicer. A few comments: > > 1) You depend on MTL, but I can't obviously see why. Perhaps the test suite? The current implementation of (!) relies on the Monad instance for Either exported by Control.Monad.Error. There's no fundamental reason for this; it was just easier to code. Perhaps I'll get rid of it in a later version, but I haven't bothered yet because I don't think an MTL dependency is a big deal. > 2) The code: > > {-| Insert a pair of values into the bimap, without checking for > overlapping bindings. If either value is already in the bimap, and > is not bound to the other value, the bimap will become inconsistent. > -} > unsafeInsert :: (Ord a, Ord b) > => a -> b -> Bimap a b -> Bimap a b > unsafeInsert x y (MkBimap left right) = > MkBimap (M.insert x y left) (M.insert y x right) > > To my understanding, this is always safe, since insert will overwrite > any existing element in a map. Hence you don't need to do the delete's > first. In addition, since Bimap is not exported internally, the > invariant will never be violated. Consider the Bimap { (1, "alfa") }. If I do (unsafeInsert 1 "bravo"), the left-hand map will contain: { (1 => "bravo") } and the right-hand map will contain: { ("alfa" => 1), ("bravo" => 1) } If I then do (lookupR "alfa"), I'll incorrectly get (Just 1) instead of (Nothing). Heck, let me prove it to you -- here's what happens if I define (insert = unsafeInsert): prop_clobberR : Falsifiable, after 0 tests: fromList [(-1,1)] 0 prop_valid : Falsifiable, after 12 tests: fromList [(1,-5),(5,-5)] It is true that at least one of the deletes will always be unnecessary, but since a failed delete does nothing we might as well leave both of them in. The export of (valid) is mostly a debugging aid, so that users can check whether their problems are caused by my code. > 3) > insert x y = delete x > >>> deleteR y > >>> unsafeInsert x y > > Why not: > > insert x y = unsafeInsert x y . delete x . delete y > > Now you don't end up using the arrow combinators, and it becomes more > readable (at least to me). Of course, this function may disappear > entirely if what I wrote in (2) is correct. This is a matter of taste, I guess. In this case I felt that the "backwards" order of (.) was a little misleading, and I'm personally quite comfortable with using (>>>) for forward composition. > I will probably start using the bimap package in my current project, > so you already have at least one user :-) Glad to hear it, and thanks for your feedback. Stuart From duncan.coutts at worc.ox.ac.uk Tue Feb 5 06:01:46 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 5 06:03:00 2008 Subject: [Haskell-cafe] Adding gcc type options with cabal (e.g. -mno-cygwin) In-Reply-To: References: <20080204221649.M41724@www.botspiritcompany.com> <1202165735.13130.246.camel@localhost> Message-ID: <1202209306.13130.271.camel@localhost> On Tue, 2008-02-05 at 00:10 -0500, Berlin Brown wrote: > It looked like it passed the option, but didn't resolve the issue. > Anyone seen that before? See error in previous post. GHC is not a cygwin program. It does not use the cygwin gcc, it always uses its own gcc anyway (which happens to be a mingwin binary) so -mno-cygwin should not make any difference to the mingwin gcc. I'd advice using mingw + msys with ghc under windows rather than cygwin. Or use neither and just use a console. Duncan From ndmitchell at gmail.com Tue Feb 5 06:25:25 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Feb 5 06:24:26 2008 Subject: [Haskell-cafe] bimap 0.2 In-Reply-To: <49b351060802050301xd8d19edv2955696680606e3c@mail.gmail.com> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> <49b351060802050301xd8d19edv2955696680606e3c@mail.gmail.com> Message-ID: <404396ef0802050325tf978540s38880146217809a8@mail.gmail.com> Hi > > 1) You depend on MTL, but I can't obviously see why. Perhaps the test suite? > > The current implementation of (!) relies on the Monad instance for > Either exported by Control.Monad.Error. There's no fundamental reason > for this; it was just easier to code. Perhaps I'll get rid of it in a > later version, but I haven't bothered yet because I don't think an MTL > dependency is a big deal. Yes, an MTL dependency is nothing to worry about at all, and isn't worth even thinking about removing given its actually used. > Heck, let me prove it to you -- here's what happens if I define > (insert = unsafeInsert): Ah, I see now. You are of course correct. > > 3) > > insert x y = delete x > > >>> deleteR y > > >>> unsafeInsert x y > > > > Why not: > > > > insert x y = unsafeInsert x y . delete x . delete y > > > > Now you don't end up using the arrow combinators, and it becomes more > > readable (at least to me). Of course, this function may disappear > > entirely if what I wrote in (2) is correct. > > This is a matter of taste, I guess. In this case I felt that the > "backwards" order of (.) was a little misleading, and I'm personally > quite comfortable with using (>>>) for forward composition. Fair enough. You've obviously thought about the issues in this package a great deal, which gives me a nice happy feeling when using the package! Thanks Neil From Christian.Maeder at dfki.de Tue Feb 5 07:33:05 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Feb 5 07:32:07 2008 Subject: [Haskell-cafe] Re: bimap 0.2 In-Reply-To: <404396ef0802050325tf978540s38880146217809a8@mail.gmail.com> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> <49b351060802050301xd8d19edv2955696680606e3c@mail.gmail.com> <404396ef0802050325tf978540s38880146217809a8@mail.gmail.com> Message-ID: <47A85781.1030202@dfki.de> Neil Mitchell wrote: > Yes, an MTL dependency is nothing to worry about at all, and isn't > worth even thinking about removing given its actually used. I would appreciate haskell98 portability! We have a similar module, too, and would switch to a standard (if bimap becomes it). We've called it "injective maps". Does surjectivity make sense a all? Our other names are bad, but maybe "transpose" or "inverse" is better than "twist" (viewing maps as finite functions). Our delete function takes both values as input, possibly deleting two entries, but your two delete functions make more sense. http://www.dfki.de/sks/hets/src-distribution/daily/Hets/docs/Common-InjMap.html or http://www.dfki.de/sks/hets/src-distribution/versions/Hets/docs/Common-InjMap.html Cheers Christian From lemming at henning-thielemann.de Tue Feb 5 07:56:06 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 5 07:55:26 2008 Subject: [Haskell-cafe] Is Haskore dead? - By no means! In-Reply-To: <20080204183220.GA311608@localhost> References: <20080204183220.GA311608@localhost> Message-ID: On Mon, 4 Feb 2008 gwern0@gmail.com wrote: > On 2008.02.04 16:11:55 -0200, Maur??cio scribbled 0.3K characters: > > Hi, > > > > I've just tried using Haskore (I use Ubuntu > > and GHC), with no success. Since Haskore was > > started a long time ago, but it's not yet > > cabalized, and the author's page can not be > > reached, I can't say for sure if it's still > > maintained. Does anybody know? > > > > Thanks, > > Maur?cio > > I think the homepage is more than a bit old. I googled a bit more, and found which links to a Darcs repo at . The most recent modification date is for src/, 04-Dec-2007. I'm trying it out right now, but the darcs get is taking a while. I've setup and maintain the Darcs repository. I've extended and corrected the original package by Paul Hudak a lot. It's also cabalized, but much of a building site, with (too) much package dependencies. Discussion has shifted to: http://lists.lurk.org/mailman/listinfo/haskell-art From lemming at henning-thielemann.de Tue Feb 5 08:31:57 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 5 08:30:59 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> References: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> Message-ID: On Mon, 4 Feb 2008, Miguel Mitrofanov wrote: > > Problem is that from the idea Functor is a superclass of Monad, with > > the > > property that "fmap == liftM". > > [cut] > > > The second relation can even not be expressed in Haskell 98. > > Erm... > > class Functor f where > fmap :: (a -> b) -> f a -> f b > class Functor m => Monad m where > return :: a -> m a > join :: m (m a) -> m a > > bind :: Monad m => m a -> (a -> m b) -> m b > bind mx f = join $ fmap f mx nice > Now liftM must be exactly equal to fmap. How do you convince the compiler that 'join (fmap return x) == x' ? From bulat.ziganshin at gmail.com Tue Feb 5 05:41:14 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 5 08:33:54 2008 Subject: [Haskell-cafe] bimap 0.2 In-Reply-To: <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> Message-ID: <1519494426.20080205134114@gmail.com> Hello Neil, Tuesday, February 5, 2008, 1:11:47 PM, you wrote: > insert x y = delete x > >>> deleteR y > >>> unsafeInsert x y i use the following trick: (.$) = flip ($) insert x y it = it.$ delete x .$ deleteR y .$ unsafeInsert x y -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From allbery at ece.cmu.edu Tue Feb 5 08:57:33 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Feb 5 08:56:36 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> Message-ID: On Feb 5, 2008, at 8:31 , Henning Thielemann wrote: > How do you convince the compiler that > 'join (fmap return x) == x' ? How do you convince it that the current formulation of Monad obeys the monad laws? (rhetorical) -- 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 lrpalmer at gmail.com Tue Feb 5 09:07:09 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Feb 5 09:06:10 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A83151.7020707@iee.org> References: <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> Message-ID: <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> On Feb 5, 2008 2:50 AM, Adrian Hey wrote: > I think it bites a lot less often than it otherwise would because most > people will deliberately chose to use heap in preference to stack (at > least when writing "eager" code) just to avoid the problem. But it still > bites pretty often anyway with "lazy" code for unexpected reasons. > Arguably such situations are indeed a "bug" more often than not, but > I still think terminating the program unnecessarily (at 8M stack) is > bad default policy. Please, after all this, do give an example. Luke From lemming at henning-thielemann.de Tue Feb 5 09:20:36 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 5 09:19:37 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> Message-ID: On Tue, 5 Feb 2008, Brandon S. Allbery KF8NH wrote: > On Feb 5, 2008, at 8:31 , Henning Thielemann wrote: > > > How do you convince the compiler that > > 'join (fmap return x) == x' ? > > How do you convince it that the current formulation of Monad obeys > the monad laws? (rhetorical) My point was that the constraint 'liftM == fmap' cannot be expressed in Haskell 98, and the answer by Miguel suggested that it would be possible by a different design of class Monad. The above was my objection to this suggestion. From lemming at henning-thielemann.de Tue Feb 5 09:25:12 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 5 09:24:15 2008 Subject: [Haskell-cafe] Re: Minor issue with mapAccumR In-Reply-To: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> References: <89ca3d1f0802042103m3e72f6f7y3ad5f5552093ef5e@mail.gmail.com> Message-ID: On Tue, 5 Feb 2008, Cale Gibbard wrote: > Are many people using mapAccumR? How much would it hurt to change it? I cannot remember having ever used mapAccumR, but I used mapAccumL where I used mapM on State monad before, in order to avoid dependency on MTL (and thus non-Haskell-98 features). From matthew at wellquite.org Tue Feb 5 09:48:14 2008 From: matthew at wellquite.org (Matthew Sackman) Date: Tue Feb 5 09:47:23 2008 Subject: [Haskell-cafe] Parameterisations of Monads Message-ID: <20080205144814.GC25563@arkansas.doc.ic.ac.uk> So I was thinking how dull and uninspiring the current definiton of Monad really is and came up with some more interesting parameterisations. The only problem with this one is I'm a) not sure if it still is a Monad and b) very unsure if it's of any use. There's the possibility that chucking Cont in there or using newtype to simultate multiple arrows / type lambdas may lead to more interesting instances, but can anyone think of exciting use cases for this stuff? Feel free to fill in the instances! It's also not a parameterisation I've seen before. Matthew > class SuperMonad (m1 :: * -> * -> *) (m2 :: * -> *) where > (>>~) :: m1 (m2 a) (m1 (m2 b) (m2 b)) > (>>=~) :: m1 (m2 a) (m1 (m1 a (m2 b)) (m2 b)) > returns :: m1 a (m2 a) > > instance (Monad m) => SuperMonad ((->)) m where > (>>~) :: m a -> m b -> m b > (>>~) = (>>) > (>>=~) :: m a -> (a -> m b) -> m b > (>>=~) = (>>=) > returns :: a -> m a > returns = return > > instance (Monad m) => SuperMonad ((,)) m where > (>>~) :: (m a, (m b, m b)) > (>>=~) :: (m a, ((a, m b), m b)) > returns :: (a, m a) > > instance (Monad m) => SuperMonad Either m where > (>>~) :: Either (m a) (Either (m a) (m b)) > (>>=~) :: Either (m a) (Either (Either a (m b)) (m b)) > returns :: Either a (m a) > > instance (Monad m) => SuperMonad State m where > (>>~) :: State (m a) (State (m a) (m b)) > (>>=~) :: State (m a) (State (State a (m b)) (m b)) > returns :: State a (m a) From lemming at henning-thielemann.de Tue Feb 5 10:01:27 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 5 10:00:27 2008 Subject: [Haskell-cafe] Signature for non-empty filter Message-ID: Is Haskell's type system including extensions strong enough for describing a function, that does not always return a trivial value? E.g. (filter (\x -> x==1 && x==2)) will always compute an empty list. Using an appropriate signature for the function it shall be rejected at compile time, because it is probably a mistake - probably (filter (\x -> x==1 || x==2) xs) was meant. I assume that the type must contain somehow an example input for which the function value is non-trivial. If Haskell's type system is not strong enough, what about dependently typed languages like Cayenne or Epigram? (I know, theorem provers have no problem with such types.) From zunino at di.unipi.it Tue Feb 5 10:07:40 2008 From: zunino at di.unipi.it (Roberto Zunino) Date: Tue Feb 5 10:02:47 2008 Subject: [Haskell-cafe] Data.Ord and Heaps (Was: Why functional programming matters) In-Reply-To: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> References: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> Message-ID: <47A87BBC.1030909@di.unipi.it> (Sorry for the late reply.) apfelmus@quantentunnel.de wrote: > I'd really like to write > > class (forall a . Ord p a) => OrdPolicy p where > > but I guess that's (currently) not possible. Actually, it seems that something like this can be achieved, at some price. First, I change the statement ;-) to class (forall a . Ord a => Ord p a) => OrdPolicy p since I guess this is what you really want. Then, we reify the Ord class with a GADT: data O a where O :: Ord a => O a Then, we reify the forall, using GADT+impredicativity: data O1 p where O1:: (forall a . Ord a => O (p a)) -> O1 p We can express the constraint with a class OrdAll, providing the GADT proof: class OrdAll p where ordAll :: O1 p Instances are easy to define, I think: instance OrdAll [] where ordAll = O1 O Your class becomes then: class OrdAll p => OrdPolicy p where ... Actually, using this is not exactly nice, since you have to 'instantiate' the forall on your own. For example, fooSort :: forall p a . (OrdPolicy p, Ord a) => [p a] -> [p a] fooSort = case ordAll of O1 o -> case o of (O :: O (p a)) -> sort * * * Actually, a simpler (untested) approach could be: class OrdAll p where ordAll :: Ord a => O (p a) This would make the O1 hack useless. Regards, Zun. From lemming at henning-thielemann.de Tue Feb 5 10:10:11 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 5 10:09:13 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> Message-ID: On Fri, 1 Feb 2008, Aaron Denney wrote: > On 2008-02-01, Bjorn Buckwalter wrote: > > If Naturals had been sufficient for me I wouldn't have done my own > > implementation (I'm unaware of any other implementation of Integers). > > And there is certainly a lot of value to the clearer error messages > > from a decimal representation. > > I did a balanced-base-three (digits are 0, and +- 1) representation to > get negative "decimals". Nice. In German the digit values are sometimes called "eins, keins, meins". :-) From lrpalmer at gmail.com Tue Feb 5 10:38:08 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Feb 5 10:37:08 2008 Subject: [Haskell-cafe] Parameterisations of Monads In-Reply-To: <20080205144814.GC25563@arkansas.doc.ic.ac.uk> References: <20080205144814.GC25563@arkansas.doc.ic.ac.uk> Message-ID: <7ca3f0160802050738y5e147a96qd9f6afe2a559885@mail.gmail.com> On Feb 5, 2008 7:48 AM, Matthew Sackman wrote: > So I was thinking how dull and uninspiring the current definiton of > Monad really is and came up with some more interesting > parameterisations. The only problem with this one is I'm a) not sure if > it still is a Monad and b) very unsure if it's of any use. There's the > possibility that chucking Cont in there or using newtype to simultate > multiple arrows / type lambdas may lead to more interesting instances, > but can anyone think of exciting use cases for this stuff? > > Feel free to fill in the instances! It's also not a parameterisation > I've seen before. I can't! That's because all the instances except for (->) have free type variables in a covariant position, so I'd be forced to used undefined all over the place. And the State instance just confuses me... :-) However, I think most Arrows would work as the first parameter, it's just not clear they would be useful. Luke From drl at cs.cmu.edu Tue Feb 5 10:44:33 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Tue Feb 5 10:43:37 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: Message-ID: <20080205154433.GA1566@cs.cmu.edu> [CC'ed to the agda mailing list as well] On Feb05, Henning Thielemann wrote: > > Is Haskell's type system including extensions strong enough for describing > a function, that does not always return a trivial value? E.g. > (filter (\x -> x==1 && x==2)) > will always compute an empty list. Using an appropriate signature for > the function it shall be rejected at compile time, because it is probably > a mistake - probably (filter (\x -> x==1 || x==2) xs) was meant. I assume > that the type must contain somehow an example input for which the function > value is non-trivial. If Haskell's type system is not strong enough, what > about dependently typed languages like Cayenne or Epigram? (I know, > theorem provers have no problem with such types.) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > You can definitely do this with dependent types. Here's a way to do it in Agda 2: -- booleans, just like in Haskell: data Bool : Set where True : Bool False : Bool _||_ : Bool -> Bool -> Bool False || False = False _ || _ = True _&&_ : Bool -> Bool -> Bool True && True = True _ && _ = False not : Bool -> Bool not True = False not False = True -- Now our first use of dependency: we need to turn a boolean value -- into the proposition that it's true. We do this with a type -- Check b where only Check True is inhabited; Check False is not data Check : Bool -> Set where OK : Check True -- a function f is satisfiable if there is some input on which it returns true data Sat {A : Set} : (A -> Bool) -> Set where Witness : {f : A -> Bool} -> (a : A) -> Check (f a) -> Sat f -- here's an easy one: example : Sat (\x -> x || not x) example = Witness True OK -- there's no way to prove this one, as each case you'd need -- a term of type Check False in the empty context example2 : Sat (\x -> x && not x) example2 = Witness True {! need a term of type Check False !} example2 = Witness False {! need a term of type Check False !} -- Now you can use Sat f as a precondition to filter: data List (A : Set) : Set where [] : List A _::_ : A -> List A -> List A filter : {A : Set} (f : A -> Bool) -> Sat f -> List A -> List A filter f sat [] = [] filter f sat (x :: xs) with f x ... | True = x :: (filter f sat xs) ... | False = filter f sat xs -- Note that the code doesn't use sat at all, so we might as well have -- written: stdfilter : {A : Set} -> (A -> Bool) -> List A -> List A stdfilter f [] = [] stdfilter f (x :: xs) with f x ... | True = x :: (stdfilter f xs) ... | False = stdfilter f xs fancyfilter : {A : Set} (f : A -> Bool) -> Sat f -> List A -> List A fancyfilter f _ l = stdfilter f l That is, the Sat f argument is used only to impose the precondition that you wanted, and it has no bearing on how filter actually computes. Of course, the trade-off here is that to call filter you have to cough up an argument on which the function is satisfiable. I don't know a way to get the compiler to construct this proof for you, but maybe someone who has done more dependent programming that I have knows a trick. You may be able to mimic this using GADTs, but it likely won't be as direct, because the 'Check (f a)' argument to Sat talks about the very code that you're passing to filter. -Dan From jeff1.61803 at gmail.com Tue Feb 5 11:36:27 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Tue Feb 5 11:35:31 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> Message-ID: <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> I want to say thanks to everyone who responded to my mutable array post. I'm going to work through and experiment with all the comments people posted. It might take me a while. Luke Palmer wrote: > > Hmm, how big is the array? If it's pretty big, that's > understandable. Frankly, it's because foldl sucks: I have never seen > a reason to use it. You should be using the strict variant foldl' > here. (I don't think there is a foldl1'). And that will get rid of > your big function calc_max_2d_elem. > > I should have mentioned that I'm working with a 2D array that is 1024 x 1024. Eventually, this code will have to work with arrays that are much larger. (For fun I write image processing and fractal "art" programs.) I replaced the foldl1 with foldl1'. Unfortunately, I still get a stack overflow. Chadda? Fouch? wrote: > Sorry but none of those propositions change the heart of the problem : > the list of elements is totally produced before she can be consumed > due to the strict monadic (IO or ST) nature of getElems. Thus you get > an extraordinary waste of memory as well as resources... > This is interesting. I've been programming in Concurrent Clean for a while. Instead of monads, Clean supports unique types for mutable arrays and IO. In Clean, I can write code that iterates through a mutable array by converting it to a lazy list. This is convenient because I can use all the nice list processing functions that are available. Changing the subject slightly, I once wrote code in Concurrent Clean that filtered a file that was larger than the available memory on my PC. I did this by creating a function that returned the contents of the original file as a lazy list. Then, I created functions to process the list and write the processed list to a results file. The code was not imperative at all. The function that wrote the results file forced the evaluation of the lazy list. As the lazy list was consumed, the contents of the original file were read. Is this possible with Monads in Haskell? Based on your comments, I suspect that in Haskell, one would have to explicitly code a loop that reads a portion of the original file, processed it, and writes a portion of the results file, over and over. By the way, if anyone wants to see it, I can post some Clean code that demonstrates the file processing I described. Clean's syntax is very similar to Haskell's. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080205/71c3c85c/attachment.htm From kalman.noel at bluebottle.com Tue Feb 5 12:14:00 2008 From: kalman.noel at bluebottle.com (Kalman Noel) Date: Tue Feb 5 12:13:03 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> Message-ID: <200802051717.m15HHnBf008328@mi0.bluebottle.com> Jeff ? wrote: > Changing the subject slightly, I once wrote code in Concurrent Clean that > filtered a file that was larger than the available memory on my PC. I did > this by creating a function that returned the contents of the original file > as a lazy list. Doing this is idiomatic in Haskell, although its usage is commonly discouraged in more complex UI settings because you cannot ever close the file handle until the end of the program. The relevant functions are to be found in the Prelude (or in Data.ByteString.Lazy, for that matter). ---------------------------------------------------------------------- Get a free email account with anti spam protection. http://www.bluebottle.com/tag/2 From lrpalmer at gmail.com Tue Feb 5 12:17:57 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Feb 5 12:17:02 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> Message-ID: <7ca3f0160802050917n3db0dc58r9fd9d0852366e84f@mail.gmail.com> On Feb 5, 2008 4:36 PM, Jeff ? wrote: > > I want to say thanks to everyone who responded to my mutable array post. > I'm going to work through and experiment with all the comments people > posted. It might take me a while. > > Luke Palmer wrote: > > Hmm, how big is the array? If it's pretty big, that's > > understandable. Frankly, it's because foldl sucks: I have never seen > > a reason to use it. You should be using the strict variant foldl' > > here. (I don't think there is a foldl1'). And that will get rid of > > your big function calc_max_2d_elem. > > > > I should have mentioned that I'm working with a 2D array that is 1024 x > 1024. Eventually, this code will have to work with arrays that are much > larger. (For fun I write image processing and fractal "art" programs.) I > replaced the foldl1 with foldl1'. Unfortunately, I still get a stack > overflow. Right, that was my mistake. The reason is right here: > Chadda? Fouch? wrote: > > > > > Sorry but none of those propositions change the heart of the problem : > > the list of elements is totally produced before she can be consumed > > due to the strict monadic (IO or ST) nature of getElems. Thus you get > > an extraordinary waste of memory as well as resources... > > > > This is interesting. I've been programming in Concurrent Clean for a while. > Instead of monads, Clean supports unique types for mutable arrays and IO. > In Clean, I can write code that iterates through a mutable array by > converting it to a lazy list. This is convenient because I can use all the > nice list processing functions that are available. > > Changing the subject slightly, I once wrote code in Concurrent Clean that > filtered a file that was larger than the available memory on my PC. I did > this by creating a function that returned the contents of the original file > as a lazy list. Then, I created functions to process the list and write the > processed list to a results file. The code was not imperative at all. The > function that wrote the results file forced the evaluation of the lazy list. > As the lazy list was consumed, the contents of the original file were read. > Is this possible with Monads in Haskell? Yes, using hGetContents, which is considered bad practice by many people here. The problem is that hGetContents breaks referential transparency, and I suspect that whatever Clean does to lazily read files also does (though I can't be sure, I haven't looked in any detail at uniqueness types). That is, the contents of the returned list depend on when you read it, which is not allowed in a referentially transparent language. The same applies to your problem. getElems cannot return a lazy list of elements*, because what if the array were changed between the point that you did the getElems and the point you required the element. So it seems that actually specifying the order of evaluation using an imperative-style loop is the only pure way to do this. * Well, it could, but it would require some cleverness like copy-on-write logic under the hood. Luke From bulat.ziganshin at gmail.com Tue Feb 5 10:25:43 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 5 13:00:33 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: Message-ID: <1542297371.20080205182543@gmail.com> Hello Henning, Tuesday, February 5, 2008, 6:01:27 PM, you wrote: > Is Haskell's type system including extensions strong enough for describing > a function, that does not always return a trivial value? E.g. > (filter (\x -> x==1 && x==2)) such things may be detected by (too) smart compiler, but in general it's undecidable: filter (if LifeHasMeaning then const True else odd) ;) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Tue Feb 5 13:06:28 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 5 13:06:14 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> Message-ID: <262262496.20080205210628@gmail.com> Hello Jeff, Tuesday, February 5, 2008, 7:36:27 PM, you wrote: > Changing the subject slightly, I once wrote code in Concurrent > Clean that filtered a file that was larger than the available memory > on my PC.? > Is this possible with Monads in Haskell?? google for "simple unix tools" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jefferson.r.heard at gmail.com Tue Feb 5 13:07:29 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Tue Feb 5 13:06:30 2008 Subject: [Haskell-cafe] Why is this so inefficient? Message-ID: <4165d3a70802051007l2aa4c44ex2032b08fd05f2323@mail.gmail.com> I thought this was fairly straightforward, but where the marked line finishes in 0.31 seconds on my machine, the actual transpose takes more than 5 minutes. I know it must be possible to read data in haskell faster than this. I'm trying to read a 100MB comma delimited file. I've tried both CSV modules, and these take even longer to read the file. Is there some general best-practice for reading and parsing large amounts of data that I'm not aware of? I have tried, by the way, a couple of things, including putting a bang (!) before row in transposeRow and using foldr instead of foldl', but that didn't change anything other than force me to increase the stack size to 100M on the command line. I'm running in the profiler now, and I'll update this, but I thought I would check and see if my head was on remotely straight to begin with. -- Jeff --- module ColumnMajorCSV where import qualified Data.ByteString.Char8 as S import qualified Data.Map as M import qualified Data.List as L transposeRow cols row = zipWith (:) row cols transposeCSV :: [[S.ByteString]] -> M.Map String [S.ByteString] transposeCSV (header:rows) = M.fromList (zip (map S.unpack header) spreadsheet) where spreadsheet = L.foldl' transposeRow emptySheet rows emptySheet = take (length header) $ repeat [] dataFromFile :: String -> IO (M.Map String [S.ByteString]) dataFromFile filename = do f <- S.readFile filename print . length . map (S.split ',' $!) . S.lines $ f -- finishes in 0.31 seconds return . transposeCSV . map (S.split ',' $!) . S.lines $ f -- this takes 5 minutes and 6 seconds From dons at galois.com Tue Feb 5 13:15:22 2008 From: dons at galois.com (Don Stewart) Date: Tue Feb 5 13:14:36 2008 Subject: [Haskell-cafe] Why is this so inefficient? In-Reply-To: <4165d3a70802051007l2aa4c44ex2032b08fd05f2323@mail.gmail.com> References: <4165d3a70802051007l2aa4c44ex2032b08fd05f2323@mail.gmail.com> Message-ID: <20080205181522.GA4229@scytale.galois.com> If the strings are relatively short, there can be a bottleneck in the current Ord instance for Bytestrings. When lots of them are in a map, the ffi calls to memcmp dominate. I've a fix for this (do it all in Haskell for small strings), and can push it if someone complains some more. jefferson.r.heard: > I thought this was fairly straightforward, but where the marked line > finishes in 0.31 seconds on my machine, the actual transpose takes > more than 5 minutes. I know it must be possible to read data in > haskell faster than this. I'm trying to read a 100MB comma delimited > file. I've tried both CSV modules, and these take even longer to read > the file. Is there some general best-practice for reading and parsing > large amounts of data that I'm not aware of? > > I have tried, by the way, a couple of things, including putting a bang > (!) before row in transposeRow and using foldr instead of foldl', but > that didn't change anything other than force me to increase the stack > size to 100M on the command line. > > I'm running in the profiler now, and I'll update this, but I thought I > would check and see if my head was on remotely straight to begin with. > > -- Jeff > > --- > module ColumnMajorCSV where > > import qualified Data.ByteString.Char8 as S > import qualified Data.Map as M > import qualified Data.List as L > > transposeRow cols row = zipWith (:) row cols > > transposeCSV :: [[S.ByteString]] -> M.Map String [S.ByteString] > transposeCSV (header:rows) = M.fromList (zip (map S.unpack header) spreadsheet) > where spreadsheet = L.foldl' transposeRow emptySheet rows > emptySheet = take (length header) $ repeat [] > > dataFromFile :: String -> IO (M.Map String [S.ByteString]) > dataFromFile filename = do > f <- S.readFile filename > print . length . map (S.split ',' $!) . S.lines $ f > -- finishes in 0.31 seconds > return . transposeCSV . map (S.split ',' $!) . S.lines $ f -- > this takes 5 minutes and 6 seconds > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jefferson.r.heard at gmail.com Tue Feb 5 13:20:54 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Tue Feb 5 13:19:56 2008 Subject: [Haskell-cafe] Why is this so inefficient? In-Reply-To: <20080205181522.GA4229@scytale.galois.com> References: <4165d3a70802051007l2aa4c44ex2032b08fd05f2323@mail.gmail.com> <20080205181522.GA4229@scytale.galois.com> Message-ID: <4165d3a70802051020k1b6f21caoc0b913179fe3a723@mail.gmail.com> I've switched to this, which gets rid of the ByteString instances fairly quickly. None of them make it into the final map. I'm still not getting any faster response out of it, and it also complains that my stack size is too small for anything about 128K records or more. import qualified Data.ByteString.Char8 as S import qualified Data.Map as M import qualified Data.List as L transposeRow cols row = zipWith (:) (map (read . S.unpack) $ row) cols transposeCSV :: [[S.ByteString]] -> M.Map String [Float] transposeCSV (header:rows) = M.fromList (zip (map S.unpack header) spreadsheet) where spreadsheet = L.foldl' transposeRow emptySheet rows emptySheet = take (length header) $ repeat [] dataFromFile :: String -> IO (M.Map String [Float]) dataFromFile filename = do f <- S.readFile filename return . transposeCSV . map (S.split ',' $!) . S.lines $ f On Tue, Feb 5, 2008 at 1:15 PM, Don Stewart wrote: > If the strings are relatively short, there can be a bottleneck > in the current Ord instance for Bytestrings. When lots of them > are in a map, the ffi calls to memcmp dominate. > > I've a fix for this (do it all in Haskell for small strings), and > can push it if someone complains some more. > > jefferson.r.heard: > > > > I thought this was fairly straightforward, but where the marked line > > finishes in 0.31 seconds on my machine, the actual transpose takes > > more than 5 minutes. I know it must be possible to read data in > > haskell faster than this. I'm trying to read a 100MB comma delimited > > file. I've tried both CSV modules, and these take even longer to read > > the file. Is there some general best-practice for reading and parsing > > large amounts of data that I'm not aware of? > > > > I have tried, by the way, a couple of things, including putting a bang > > (!) before row in transposeRow and using foldr instead of foldl', but > > that didn't change anything other than force me to increase the stack > > size to 100M on the command line. > > > > I'm running in the profiler now, and I'll update this, but I thought I > > would check and see if my head was on remotely straight to begin with. > > > > -- Jeff > > > > --- > > module ColumnMajorCSV where > > > > import qualified Data.ByteString.Char8 as S > > import qualified Data.Map as M > > import qualified Data.List as L > > > > transposeRow cols row = zipWith (:) row cols > > > > transposeCSV :: [[S.ByteString]] -> M.Map String [S.ByteString] > > transposeCSV (header:rows) = M.fromList (zip (map S.unpack header) spreadsheet) > > where spreadsheet = L.foldl' transposeRow emptySheet rows > > emptySheet = take (length header) $ repeat [] > > > > dataFromFile :: String -> IO (M.Map String [S.ByteString]) > > dataFromFile filename = do > > f <- S.readFile filename > > print . length . map (S.split ',' $!) . S.lines $ f > > -- finishes in 0.31 seconds > > return . transposeCSV . map (S.split ',' $!) . S.lines $ f -- > > this takes 5 minutes and 6 seconds > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From ahey at iee.org Tue Feb 5 13:50:44 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Feb 5 13:49:52 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> References: <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> Message-ID: <47A8B004.6000001@iee.org> Luke Palmer wrote: > On Feb 5, 2008 2:50 AM, Adrian Hey wrote: >> I think it bites a lot less often than it otherwise would because most >> people will deliberately chose to use heap in preference to stack (at >> least when writing "eager" code) just to avoid the problem. But it still >> bites pretty often anyway with "lazy" code for unexpected reasons. >> Arguably such situations are indeed a "bug" more often than not, but >> I still think terminating the program unnecessarily (at 8M stack) is >> bad default policy. > > Please, after all this, do give an example. If you mean an example of coding style and choice of stack vs. heap, I already have.. http://www.haskell.org/pipermail/haskell-cafe/2008-January/038832.html If you mean an example of it biting with lazy code, this is discussed so often you'd be spoiled for choice if you search the mailing list archives. Here's a good one.. http://www.haskell.org/pipermail/haskell-cafe/2005-December/013521.html This example actually shows the problem twice. In one case it's solvable by using foldl' instead of foldl. In the other case there's nothing that can reasonably be done by the user short of editing the source code of Data.Map to provide a stricter insertWith function (which has now been added IIRC). The problem is repeated applying of a strict function lazily. When the result is eventually demanded the stack "blows up". In the mean time you sometimes have an unnecessary space (heap) leak too (with counters for example). Regards -- Adrian Hey From lrpalmer at gmail.com Tue Feb 5 13:57:18 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Feb 5 13:56:18 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A8B004.6000001@iee.org> References: <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> Message-ID: <7ca3f0160802051057h551dba72r97f14681f202f2a8@mail.gmail.com> On Feb 5, 2008 6:50 PM, Adrian Hey wrote: > > Luke Palmer wrote: > > On Feb 5, 2008 2:50 AM, Adrian Hey wrote: > >> I think it bites a lot less often than it otherwise would because most > >> people will deliberately chose to use heap in preference to stack (at > >> least when writing "eager" code) just to avoid the problem. But it still > >> bites pretty often anyway with "lazy" code for unexpected reasons. > >> Arguably such situations are indeed a "bug" more often than not, but > >> I still think terminating the program unnecessarily (at 8M stack) is > >> bad default policy. > > > > Please, after all this, do give an example. > > If you mean an example of coding style and choice of stack vs. heap, > I already have.. > > http://www.haskell.org/pipermail/haskell-cafe/2008-January/038832.html Ah, sorry, I must have missed that message. Luke From ndmitchell at gmail.com Tue Feb 5 14:05:45 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Feb 5 14:04:46 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A8B004.6000001@iee.org> References: <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> Message-ID: <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> Hi > If you mean an example of coding style and choice of stack vs. heap, > I already have.. > > http://www.haskell.org/pipermail/haskell-cafe/2008-January/038832.html I'm at a loss as why you want a strict version of take. It's clearly not for performance, as it performs slower. I'd say both the gobbler programs have a bug, namely that they are not sufficiently lazy. As an aside, my version of this function would be: neilGobbler :: Int -> [x] -> [x] neilGobbler n xs = length res `seq` res where res = take n xs I have no idea if it takes the heap or the stack, or if it performs faster or slower. If you still have whatever test you used on the gobbler, perhaps you could tell us. > If you mean an example of it biting with lazy code, this is discussed > so often you'd be spoiled for choice if you search the mailing list > archives. Here's a good one.. > > http://www.haskell.org/pipermail/haskell-cafe/2005-December/013521.html > > This example actually shows the problem twice. In one case it's solvable > by using foldl' instead of foldl. Which reduces the memory from O(n) to O(1). Surely thats a good thing, and the code before had a space leak. Space leak is bad, therefore telling people about it is good. I think its sensible to let people set their own stack bound (which is possible), but that clearly just from taking an informal poll of respondants to this thread, the current default should indeed be the default. You seem to be the only person clamouring for an unlimited stack, and thanks to +RTS, you already have it. Thanks Neil From vigalchin at gmail.com Tue Feb 5 14:06:25 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Tue Feb 5 14:05:27 2008 Subject: [Haskell-cafe] building the unix package and cabal In-Reply-To: <20080204222047.GA18871@matrix.chaos.earth.li> References: <5ae4f2ba0802040633l22b506c9id47bf2dfc73d9fd0@mail.gmail.com> <916b84820802040705w59183b3an88872de0448f26d5@mail.gmail.com> <5ae4f2ba0802040743n6e876829m4e4791262774176a@mail.gmail.com> <916b84820802040753i6869afa3s43d4046c31fd83e7@mail.gmail.com> <5ae4f2ba0802040822p62d4ac94p1d29f6562501ac2d@mail.gmail.com> <916b84820802040833g72d34d91ifd834a667aebe86b@mail.gmail.com> <5ae4f2ba0802040850v30c1a768n6f228f930843b87c@mail.gmail.com> <20080204222047.GA18871@matrix.chaos.earth.li> Message-ID: <5ae4f2ba0802051106j7cc9459dv40ac056ec7ecfd17@mail.gmail.com> Hi Ian, Should gmp-devel be an archive (.a) or a shared object (.so)? If an .a, don't I have to have an environemmt var to point at it's directory? I tried your sequence below on unix-2.2.0.0 and still cannot resolve "gmp". I did find one gmp .rpm on one of the RHEL cds but without "-devel". Regards, Vasili On 2/4/08, Ian Lynagh wrote: > > On Mon, Feb 04, 2008 at 10:50:13AM -0600, Galchin Vasili wrote: > > more specifically the "gmp" unsatisfied ref shows up with the > DynamicLinker. > > This works for me, with GHC 6.8.2 and > > http://hackage.haskell.org/packages/archive/unix/2.2.0.0/unix-2.2.0.0.tar.gz > > $ ghc --make Setup > $ ./Setup configure --user > $ ./Setup build > > If it's not working for you then you might need a RHEL package called > something like gmp-devel. If that doesn't fix it, please send us the > exact commands you are running and the complete output. > > Note that you wouldn't normally compile the unix package yourself, > however, as it is one of the packages that comes with GHC. > > > Thanks > Ian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080205/d980822c/attachment.htm From ahey at iee.org Tue Feb 5 14:15:59 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Feb 5 14:15:07 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <1835906623.20080205112236@gmail.com> References: <47A7661D.7090603@iee.org> <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> <200802042045.51678.matthew.pocock@ncl.ac.uk> <1835906623.20080205112236@gmail.com> Message-ID: <47A8B5EF.1080202@iee.org> Bulat Ziganshin wrote: > Hello Matthew, > > Monday, February 4, 2008, 11:45:51 PM, you wrote: > >>> That would be nice. But its only beneficial if there are programs >>> which takes large amounts of stack at some point, but then shrink down >>> to very little stack and continue for a reasonable amount of time. > >> From the 'when I was a lad' department... > >> Thinking back to when Java transitioned to a garbage collector that could give >> memory back to the OS, we got some unexpected benefits. Consider a machine > > i would be also happy if ghc will return unused *heap* memory back to > OS - it's immediately required for my GUI program where users may open > huge files and then close them. but i personally don't have the same > need for *stack* How do you know you don't or won't have the same need for stack? Given that most most real programs are going to pull in library code written by all sorts of people, don't you want your program to be robust and memory efficient even if it makes use of libraries whose authors chose stack gobbling in preference to heap gobbling, or who used a (currently non-existant AFAIK) CPS based implementation for development? I just don't get this idea that the current implementation (8M limit IIRC in the absence of +RTS options) is good. 8M is still a pretty big stack and (8M - 4K) per thread seems like an awful lot of memory to waste to me. If we're all so sure that big stacks are a "bug" then why bother allowing them to grow at all. Why not just limit them to 4K? Actually I think the latter option above might be good way to discover how many "bug" free Haskell progs there really are out there. Precious few I suspect :-( Regards -- Adrian Hey From alfonso.acosta at gmail.com Tue Feb 5 14:16:53 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Feb 5 14:16:03 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> Message-ID: <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> On Feb 5, 2008 4:10 PM, Henning Thielemann wrote: > > On Fri, 1 Feb 2008, Aaron Denney wrote: > > > On 2008-02-01, Bjorn Buckwalter wrote: > > > If Naturals had been sufficient for me I wouldn't have done my own > > > implementation (I'm unaware of any other implementation of Integers). > > > And there is certainly a lot of value to the clearer error messages > > > from a decimal representation. > > > > I did a balanced-base-three (digits are 0, and +- 1) representation to > > get negative "decimals". > > Nice. In German the digit values are sometimes called "eins, keins, meins". :-) I'm almost done with the decimal library but it would be nice to check some Integer implementations for future inclusion. So, Aaron, Bj?rn, are your implementations available somewhere? From bjorn.buckwalter at gmail.com Tue Feb 5 14:29:31 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Tue Feb 5 14:28:32 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> Message-ID: <8b2a1a960802051129y2a666898mc842780411627516@mail.gmail.com> On Feb 5, 2008 2:16 PM, Alfonso Acosta wrote: > On Feb 5, 2008 4:10 PM, Henning Thielemann > wrote: > > > > On Fri, 1 Feb 2008, Aaron Denney wrote: > > > > > On 2008-02-01, Bjorn Buckwalter wrote: > > > > If Naturals had been sufficient for me I wouldn't have done my own > > > > implementation (I'm unaware of any other implementation of Integers). > > > > And there is certainly a lot of value to the clearer error messages > > > > from a decimal representation. > > > > > > I did a balanced-base-three (digits are 0, and +- 1) representation to > > > get negative "decimals". > > > > Nice. In German the digit values are sometimes called "eins, keins, meins". :-) > > I'm almost done with the decimal library but it would be nice to check > some Integer implementations for future inclusion. So, Aaron, Bj?rn, > are your implementations available somewhere? As noted elsewhere in the thread my implementation is available at: http://www.buckwalter.se/~bjorn/darcs/dimensional/Numeric/NumType.lhs It is my intent to extract this (self-contained) module to its own package and put on hackage. It's been a low priority for me but I'm rather incentivized by this thread. Thanks, Bjorn From alfonso.acosta at gmail.com Tue Feb 5 15:03:30 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Feb 5 15:02:34 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <8b2a1a960802051129y2a666898mc842780411627516@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> <8b2a1a960802051129y2a666898mc842780411627516@mail.gmail.com> Message-ID: <6a7c66fc0802051203p22276101ledf4f87353a7bddc@mail.gmail.com> On Feb 5, 2008 8:29 PM, Bjorn Buckwalter wrote: > > On Feb 5, 2008 2:16 PM, Alfonso Acosta wrote: > > On Feb 5, 2008 4:10 PM, Henning Thielemann > > wrote: > > > > > > On Fri, 1 Feb 2008, Aaron Denney wrote: > > > > > > > On 2008-02-01, Bjorn Buckwalter wrote: > > > > > If Naturals had been sufficient for me I wouldn't have done my own > > > > > implementation (I'm unaware of any other implementation of Integers). > > > > > And there is certainly a lot of value to the clearer error messages > > > > > from a decimal representation. > > > > > > > > I did a balanced-base-three (digits are 0, and +- 1) representation to > > > > get negative "decimals". > > > > > > Nice. In German the digit values are sometimes called "eins, keins, meins". :-) > > > > I'm almost done with the decimal library but it would be nice to check > > some Integer implementations for future inclusion. So, Aaron, Bj?rn, > > are your implementations available somewhere? > > As noted elsewhere in the thread my implementation is available at: > > http://www.buckwalter.se/~bjorn/darcs/dimensional/Numeric/NumType.lhs Thanks! > It is my intent to extract this (self-contained) module to its own > package and put on hackage. It's been a low priority for me but I'm > rather incentivized by this thread. Great! How about joining efforts? As I said I almost have a preliminary version of the decimal library which I'll realease for reviewing purpouses soon (It won't include Integer computations though) From westondan at imageworks.com Tue Feb 5 15:06:42 2008 From: westondan at imageworks.com (Dan Weston) Date: Tue Feb 5 15:11:26 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> Message-ID: <47A8C1D2.3080300@imageworks.com> Can you do this with a GHC rule? Something like: {-# RULES "join_dot_fmap_return/id" forall x . join (fmap return x) = x #-} Dan Henning Thielemann wrote: > On Tue, 5 Feb 2008, Brandon S. Allbery KF8NH wrote: > >> On Feb 5, 2008, at 8:31 , Henning Thielemann wrote: >> >>> How do you convince the compiler that >>> 'join (fmap return x) == x' ? >> How do you convince it that the current formulation of Monad obeys >> the monad laws? (rhetorical) > > My point was that the constraint 'liftM == fmap' cannot be expressed in > Haskell 98, and the answer by Miguel suggested that it would be possible > by a different design of class Monad. The above was my objection to this > suggestion. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From bos at serpentine.com Tue Feb 5 15:21:03 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Feb 5 15:20:03 2008 Subject: [Haskell-cafe] Why is this so inefficient? In-Reply-To: <4165d3a70802051007l2aa4c44ex2032b08fd05f2323@mail.gmail.com> References: <4165d3a70802051007l2aa4c44ex2032b08fd05f2323@mail.gmail.com> Message-ID: <47A8C52F.5070406@serpentine.com> Jefferson Heard wrote: > I thought this was fairly straightforward, but where the marked line > finishes in 0.31 seconds on my machine, the actual transpose takes > more than 5 minutes. I know it must be possible to read data in > haskell faster than this. I took a look into this, writing a similar, but simpler, program. Half of the runtime, and 2/3 of the allocation, is spent in ByteString's split function. The remaining portions are spent in transposing the list. COST CENTRE %time %alloc ticks bytes split 66.7 65.1 56 120130000 xpose 31.0 32.8 26 60618031 read 1.2 2.0 1 3640229 lines 1.2 0.1 1 260002 I've attached two programs to demonstrate the problem. One creates a sample speadsheet; the other transposes it. I spent a little time trying to find a faster replacement for ByteString.split, but no luck before I had to return to other things. References: <20080205144814.GC25563@arkansas.doc.ic.ac.uk> Message-ID: <47A8C6A3.4020103@imageworks.com> Matthew, Your SuperMonad seems remarkably similar to Gabor Greif's Thrist datatype [1,2] reported only six days ago on this list [3]. Can you compare/contrast your class approach with his polymorphic type approach? Or have I completely confused the two because of the similar kind of their arguments? data Thrist :: (* -> * -> *) -> * -> * -> * where Nil :: Thrist p a a Cons :: p a b -> Thrist p b c -> Thrist p a c data Arrow' :: (* -> * -> *) -> * -> * -> * where Arr :: Arrow a => a b c -> Arrow' a b c First :: Arrow a => Arrow' a b c -> Arrow' a (b, d) (c, d) [1] http://heisenbug.blogspot.com/2007/11/trendy-topics.html [2] http://heisenbug.blogspot.com/2008/01/embeddings-part-one-arrow-thrist.html [3] http://thread.gmane.org/gmane.comp.lang.haskell.cafe/35907/focus=35957 Dan Matthew Sackman wrote: > So I was thinking how dull and uninspiring the current definiton of > Monad really is and came up with some more interesting > parameterisations. The only problem with this one is I'm a) not sure if > it still is a Monad and b) very unsure if it's of any use. There's the > possibility that chucking Cont in there or using newtype to simultate > multiple arrows / type lambdas may lead to more interesting instances, > but can anyone think of exciting use cases for this stuff? > > Feel free to fill in the instances! It's also not a parameterisation > I've seen before. > > Matthew > >> class SuperMonad (m1 :: * -> * -> *) (m2 :: * -> *) where >> (>>~) :: m1 (m2 a) (m1 (m2 b) (m2 b)) >> (>>=~) :: m1 (m2 a) (m1 (m1 a (m2 b)) (m2 b)) >> returns :: m1 a (m2 a) >> >> instance (Monad m) => SuperMonad ((->)) m where >> (>>~) :: m a -> m b -> m b >> (>>~) = (>>) >> (>>=~) :: m a -> (a -> m b) -> m b >> (>>=~) = (>>=) >> returns :: a -> m a >> returns = return >> >> instance (Monad m) => SuperMonad ((,)) m where >> (>>~) :: (m a, (m b, m b)) >> (>>=~) :: (m a, ((a, m b), m b)) >> returns :: (a, m a) >> >> instance (Monad m) => SuperMonad Either m where >> (>>~) :: Either (m a) (Either (m a) (m b)) >> (>>=~) :: Either (m a) (Either (Either a (m b)) (m b)) >> returns :: Either a (m a) >> >> instance (Monad m) => SuperMonad State m where >> (>>~) :: State (m a) (State (m a) (m b)) >> (>>=~) :: State (m a) (State (State a (m b)) (m b)) >> returns :: State a (m a) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From felipe.lessa at gmail.com Tue Feb 5 16:51:18 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Tue Feb 5 16:50:19 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: <47A8C1D2.3080300@imageworks.com> References: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> <47A8C1D2.3080300@imageworks.com> Message-ID: On Feb 5, 2008 6:06 PM, Dan Weston wrote: > Can you do this with a GHC rule? Something like: > > {-# RULES > "join_dot_fmap_return/id" forall x . join (fmap return x) = x > #-} > > Dan I guess this would make use of the rule (otherwise the transformation would change the code's semantic) but would not enforce that the rule itself is valid (which is undecidable). Cheers, -- Felipe. From bulat.ziganshin at gmail.com Tue Feb 5 16:17:00 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 5 17:32:22 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A8B5EF.1080202@iee.org> References: <47A7661D.7090603@iee.org> <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> <200802042045.51678.matthew.pocock@ncl.ac.uk> <1835906623.20080205112236@gmail.com> <47A8B5EF.1080202@iee.org> Message-ID: <8010605868.20080206001700@gmail.com> Hello Adrian, Tuesday, February 5, 2008, 10:15:59 PM, you wrote: >> i would be also happy if ghc will return unused *heap* memory back to >> OS - it's immediately required for my GUI program where users may open >> huge files and then close them. but i personally don't have the same >> need for *stack* > How do you know you don't or won't have the same need for stack? i run my program with rather large datasets - it's happy with current 8m stack. i had problems with filterM function, though, and replaced it with my own, tail-recursive but probably less efficient implementation i know that real problems for my programs will be solved by adding "heap releasing" or, say, x64 support. are you have real problems with stack management? if not, isn't it better to allow ghc developers to solve real problems for me and other people? things will never be ideal from my own POV the only serious argument may be that current situation limits usability of some programming techniques (CPS?) which is able to increase programmer's productivity -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jwlato at gmail.com Tue Feb 5 19:00:38 2008 From: jwlato at gmail.com (John Lato) Date: Tue Feb 5 18:59:40 2008 Subject: [Haskell-cafe] Mutable arrays Message-ID: <9979e72e0802051600v210b3f03k55a7c0001d9e8950@mail.gmail.com> At least for file processing, I don't think the lazy solution is as bad as some people on this list indicate. My solution was to define a function processAudioFile :: (Handle, Handle) -> (ASig -> ASig) -> IO (), similar to interact. The function reads from the first handle and writes to the second (the problem domain requires two separate files). Contents of the first are read into a lazy bytestring with hGetContents (from Data.ByteString.Lazy), decoded into an ASig (which in the current version is actually a tuple of a list and an Int of the total length, but I'm reworking this into a monad), and processed. The processed list is then encoded back into a bytestring and written with hPut. I then stick the whole thing in a bracket to open and close the filehandles, and call the bracketed function when I'm ready to do processing. I'm pretty happy with this solution, for several reasons: 1. The actual processing code remains purely functional. 2. I didn't have to write imperative-style looping constructs. 3. Handles get closed after use (even with exceptions, thanks to bracket). 4. Because all IO, processing, and writing is encapsulated in one function, everything happens sequentially as it's supposed to, so I don't get exceptions about lazy filehandles being closed. 5. Performance has been good. Memory usage is lower than expected, and it's fairly fast (at least when I remember to use a non-profiled version). I've tested this approach with wave files into the 100's of MB so far. Perhaps not quite as fast as optimized C, but good enough for me. I'm not quite sure how to get around the problem of getElems being strict, though. I do have one idea, but I don't know how it would work in practice: -- let ary_max = foldl1' max $ elems $ unsafeFreeze myArray If you use a boxed array type (IOArray or STArray) for myArray, and compiled with GHC, no copying is necessary (you may need to use type annotations to guarantee this). Then use the foldl' function to get array_max, and map it onto the original mutable array. I think it would be safe provided that you calculate ary_max before you start to modify the array, which is true for normalization. It's worth a try, anyway. John Lato > > Changing the subject slightly, I once wrote code in Concurrent Clean that > > filtered a file that was larger than the available memory on my PC. I did > > this by creating a function that returned the contents of the original file > > as a lazy list. Then, I created functions to process the list and write the > > processed list to a results file. The code was not imperative at all. The > > function that wrote the results file forced the evaluation of the lazy list. > > As the lazy list was consumed, the contents of the original file were read. > > Is this possible with Monads in Haskell? > > Yes, using hGetContents, which is considered bad practice by many > people here. The problem is that hGetContents breaks referential > transparency, and I suspect that whatever Clean does to lazily read > files also does (though I can't be sure, I haven't looked in any > detail at uniqueness types). That is, the contents of the returned > list depend on when you read it, which is not allowed in a > referentially transparent language. > > The same applies to your problem. getElems cannot return a lazy list > of elements*, because what if the array were changed between the point > that you did the getElems and the point you required the element. So > it seems that actually specifying the order of evaluation using an > imperative-style loop is the only pure way to do this. > > * Well, it could, but it would require some cleverness like > copy-on-write logic under the hood. From scook0 at gmail.com Tue Feb 5 19:43:06 2008 From: scook0 at gmail.com (Stuart Cook) Date: Tue Feb 5 19:42:06 2008 Subject: [Haskell-cafe] Re: bimap 0.2 In-Reply-To: <47A85781.1030202@dfki.de> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> <49b351060802050301xd8d19edv2955696680606e3c@mail.gmail.com> <404396ef0802050325tf978540s38880146217809a8@mail.gmail.com> <47A85781.1030202@dfki.de> Message-ID: <49b351060802051643q5baf143bn20a5bc3a175ae6a8@mail.gmail.com> On Tue, Feb 5, 2008 at 11:33 PM, Christian Maeder wrote: > Neil Mitchell wrote: > > Yes, an MTL dependency is nothing to worry about at all, and isn't > > worth even thinking about removing given its actually used. > > I would appreciate haskell98 portability! My development version has removed the need for Control.Monad.Exception and Control.Arrow. The only remaining H98 incompatibility I can think of is the use of foldl' in fromList. > We've called it "injective maps". Does surjectivity make sense a all? > Our other names are bad, but maybe "transpose" or "inverse" is better > than "twist" (viewing maps as finite functions). In my mind, surjectivity is the property that each key in the right-hand map is a value in the left-hand map (and vice-versa). This is related to the unsafeInsert problem I mentioned earlier. I'm open to suggesions for alternatives to "twist". I think it's cute, because it suggests transposing something without fundamentally changing it, but a less fanciful name could be a good idea. > Our delete function takes both values as input, possibly deleting two > entries, but your two delete functions make more sense. Incidentally, someone might find it useful to have a two-argument delete defined as deletePair :: (Ord a, Ord b) => a -> b -> Bimap a b -> Bimap a b deletePair x y bi | (x, y) `pairMember` bi = delete x bi | otherwise = bi but it's easy enough to define that I probably don't need to provide it myself. > http://www.dfki.de/sks/hets/src-distribution/daily/Hets/docs/Common-InjMap.html > or > http://www.dfki.de/sks/hets/src-distribution/versions/Hets/docs/Common-InjMap.html The getAToB and getBToA functions are interesting. I'm thinking of adding them as toMap and toMapR. Stuart From gabor at mac.com Tue Feb 5 20:15:51 2008 From: gabor at mac.com (Gabor Greif) Date: Tue Feb 5 20:15:06 2008 Subject: [Haskell-cafe] Parameterisations of Monads In-Reply-To: <47A8C6A3.4020103@imageworks.com> References: <20080205144814.GC25563@arkansas.doc.ic.ac.uk> <47A8C6A3.4020103@imageworks.com> Message-ID: <321D7A19-E2B9-4C14-A71A-9F54DC442119@mac.com> Am 05.02.2008 um 21:27 schrieb Dan Weston: > Matthew, > > Your SuperMonad seems remarkably similar to Gabor Greif's Thrist > datatype [1,2] reported only six days ago on this list [3]. > > Can you compare/contrast your class approach with his polymorphic > type approach? Or have I completely confused the two because of the > similar kind of their arguments? > > data Thrist :: (* -> * -> *) -> * -> * -> * where > Nil :: Thrist p a a > Cons :: p a b -> Thrist p b c -> Thrist p a c > > data Arrow' :: (* -> * -> *) -> * -> * -> * where > Arr :: Arrow a => a b c -> Arrow' a b c > First :: Arrow a => Arrow' a b c -> Arrow' a (b, d) (c, d) For the record, I have done the monad into thrist embedding now: http://heisenbug.blogspot.com/2008/02/embeddings-part-two-monad- thrist.html Will start pondering about mfix and restricted monads now. Cheers, Gabor From stefanor at cox.net Tue Feb 5 20:26:43 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Tue Feb 5 20:25:45 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <9979e72e0802051600v210b3f03k55a7c0001d9e8950@mail.gmail.com> References: <9979e72e0802051600v210b3f03k55a7c0001d9e8950@mail.gmail.com> Message-ID: <20080206012643.GA4048@localhost.localdomain> On Tue, Feb 05, 2008 at 06:00:38PM -0600, John Lato wrote: > -- let ary_max = foldl1' max $ elems $ unsafeFreeze myArray > > If you use a boxed array type (IOArray or STArray) for myArray, and > compiled with GHC, no copying is necessary (you may need to use type > annotations to guarantee this). Then use the foldl' function to get > array_max, and map it onto the original mutable array. I think it > would be safe provided that you calculate ary_max before you start to > modify the array, which is true for normalization. Eek! unsafeFreeze isn't a type cast, it actually modifies flags in the heap object which are used by the generational garbage collector. It's quite concievable that you could get segfaults by modifying a boxed array after passing it to unsafeFreeze. This, I believe, would work: let ary_max = foldl1' max [ inlinePerformIO (readArray myArray ix) | ix <- range (inlinePerformIO (getBounds myArray)) ] But it's equally untested. 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/20080205/6a07d40d/attachment.bin From jwlato at gmail.com Tue Feb 5 21:15:48 2008 From: jwlato at gmail.com (John Lato) Date: Tue Feb 5 21:54:47 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <20080206012643.GA4048@localhost.localdomain> References: <9979e72e0802051600v210b3f03k55a7c0001d9e8950@mail.gmail.com> <20080206012643.GA4048@localhost.localdomain> Message-ID: <9979e72e0802051815i5468ac47oe20618aeaf53baaa@mail.gmail.com> Hmm. It looks like I forgot a step, and it probably would segfault as given. That's what I get for mucking about with unsafe* functions. How about this? let frozen_ary = unsafeFreeze myArray let ary_max = foldl1' max $ elems frozen_ary in ary_max `seq` map (1/ary_max) $ unsafeThaw frozen_ary This sequence doesn't modify the array object after freezing, except to call unsafeThaw on it, and there is no need to access the frozen array after unsafeThaw. Even so, piling another unsafe function on to clean up the mess from the first unsafe function strikes me as an anti-pattern (even though the docs seem to indicate that "unsafeThaw write unsafeFreeze" could work). Furthermore, I can't say what would happen to any of the original references to myArray, other than that it's better not to use them. I'm still mostly a noob, but assuming it works, your version with inlinePerformIO looks better to me, even with the caveats of inlinePerformIO. John On Feb 5, 2008 7:26 PM, Stefan O'Rear wrote: > On Tue, Feb 05, 2008 at 06:00:38PM -0600, John Lato wrote: > > -- let ary_max = foldl1' max $ elems $ unsafeFreeze myArray > > > > If you use a boxed array type (IOArray or STArray) for myArray, and > > compiled with GHC, no copying is necessary (you may need to use type > > annotations to guarantee this). Then use the foldl' function to get > > array_max, and map it onto the original mutable array. I think it > > would be safe provided that you calculate ary_max before you start to > > modify the array, which is true for normalization. > > Eek! unsafeFreeze isn't a type cast, it actually modifies flags in the > heap object which are used by the generational garbage collector. It's > quite concievable that you could get segfaults by modifying a boxed > array after passing it to unsafeFreeze. > > This, I believe, would work: > > let ary_max = foldl1' max [ inlinePerformIO (readArray myArray ix) > | ix <- range (inlinePerformIO (getBounds myArray)) ] > > But it's equally untested. > > Stefan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHqQzTFBz7OZ2P+dIRAujzAJ49RDMKtgzrMZ9TxRyXge0hSFZHgwCdGAXM > 8rQy4Fufodehcj5cxoSOoVM= > =wHxm > -----END PGP SIGNATURE----- > > From scook0 at gmail.com Tue Feb 5 21:53:33 2008 From: scook0 at gmail.com (Stuart Cook) Date: Tue Feb 5 21:55:00 2008 Subject: [Haskell-cafe] Re: bimap 0.2 In-Reply-To: <49b351060802051643q5baf143bn20a5bc3a175ae6a8@mail.gmail.com> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> <49b351060802050301xd8d19edv2955696680606e3c@mail.gmail.com> <404396ef0802050325tf978540s38880146217809a8@mail.gmail.com> <47A85781.1030202@dfki.de> <49b351060802051643q5baf143bn20a5bc3a175ae6a8@mail.gmail.com> Message-ID: <49b351060802051853k2cb78ae8q2b129dfb8810eae9@mail.gmail.com> On Wed, Feb 6, 2008 at 11:43 AM, Stuart Cook wrote: > My development version has removed the need for > Control.Monad.Exception and Control.Arrow. The only remaining H98 > incompatibility I can think of is the use of foldl' in fromList. Version 0.2.1 features: * almost-H98 compatibility (foldl' and hierarchical modules) * toMap/toMapR * big-O in function comments * version info in function comments Stuart From bjorn.buckwalter at gmail.com Tue Feb 5 22:32:09 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Tue Feb 5 22:42:00 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802051203p22276101ledf4f87353a7bddc@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> <8b2a1a960802051129y2a666898mc842780411627516@mail.gmail.com> <6a7c66fc0802051203p22276101ledf4f87353a7bddc@mail.gmail.com> Message-ID: <8b2a1a960802051932s17965fcapf7f53274e170b15d@mail.gmail.com> > > > I'm almost done with the decimal library but it would be nice to check > > > some Integer implementations for future inclusion. So, Aaron, Bj?rn, > > > are your implementations available somewhere? > > > > As noted elsewhere in the thread my implementation is available at: > > > > http://www.buckwalter.se/~bjorn/darcs/dimensional/Numeric/NumType.lhs > > Thanks! > > > It is my intent to extract this (self-contained) module to its own > > package and put on hackage. It's been a low priority for me but I'm > > rather incentivized by this thread. > > Great! > > How about joining efforts? As I said I almost have a preliminary > version of the decimal library which I'll realease for reviewing > purpouses soon (It won't include Integer computations though) Well, could you elaborate a little on joining efforts? The effort I was planning to invest in my package consists mainly of creating a .cabal file plus some logistics to get tarballs to where they have to be. I understand that you (and Wolfgang) are creating a library of type level decimals for the purpose of constraining vector (list?) lengths. After that I haven't been paying attention fully to the thread. Is the goal to create a general-purpose library for type-level programming and my module would fit into that grander scheme? Or did you have something else in mind with joining efforts? E.g. help reviewing your code or writing new code? From uhollerbach at gmail.com Tue Feb 5 23:44:27 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Tue Feb 5 23:43:26 2008 Subject: [Haskell-cafe] background question about IO monad Message-ID: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> Hello, haskellers, I have a question for you about the IO monad. On one level, I seem to be "getting" it, at least I seem to be writing code that does what I want, but on another level I am almost certainly not at all clear on some concepts. In various tutorials around the web, I keep finding this notion that the IO monad is "one-way", that you can put stuff into it, but you can't take it out. (And, damn, some of the contortions I went through while trying to figure out how to do exceptions in my little scheme interpreter certainly bear that out! I was sure beating my head against liftIO et al for a fair while...) But let me post some code snippets here: > lispUTCTime [] = doIOAction (getClockTime) toS allErrs > where toS val = String (calendarTimeToString (toUTCTime val)) > lispUTCTime [IntNumber n] = > return (String (calendarTimeToString (toUTCTime (TOD n 0)))) This is a little function I added to the interpreter a couple of days ago: if you enter (UTCtime) with no arguments, it gets the current time and formats it as UTC: like so; this came from the first alternative above: lisp> (UTCtime) "Wed Feb 6 03:57:45 UTC 2008" and if you give an argument, you get that interpreted as a number of seconds since epoch, and that gets formatted as UTC; this is from the second alternative above: lisp> (UTCtime 1.203e9) "Thu Feb 14 14:40:00 UTC 2008" And here's the doIOAction routine: I wrote this, it's not some system-level routine. > doIOAction action ctor epred = > do ret <- liftIO (try action) > case ret of > Left err -> if epred err > then throwError (Default (show err)) > else return (Bool False) > Right val -> return (ctor val) OK, with all that as background, on one level I understand why I need the doIOAction routine in the first version of lispUTCTime: I'm calling getClockTime, that's an IO action, so I enter the IO monad, get the time, and return: all is cool. In the second version, all I'm doing is taking a number and interpreting it as a time, and writing that in a particular format; again, no problem. But after that, it sure seems to me as if I've taken data out of the IO monad... haven't I? Given that the second alternative never entered doIOAction and that after both are done I have a string of characters, prettily formatted to indicate a time, that's what it feels like to this unwashed C programmer. So, what's going on there? What's the difference between the two alternatives? I would appreciate any enlightenment you can send my way! regards, Uwe From flippa at flippac.org Tue Feb 5 23:49:18 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue Feb 5 23:47:54 2008 Subject: [Haskell-cafe] Parsec3 stream properties Message-ID: I'm having a little difficulty finding full properties for Parsec3's Stream class, largely because I don't want to overspecify it with regard to side-effects. Here's the class: > class Stream s m t | s -> t where > uncons :: s -> m (Maybe (t,s)) The idea is that: * unfoldM uncons gives the [t] corresponding to the stream * Assuming no relevant side-effects, unconsing the same value twice will yield the same result What's a relevant side-effect? Well, that's up to the stream and the monad it's built in - but unconsing once shouldn't affect the result of unconsing a second time unless you've found something fiendishly clever that I haven't thought of. Using stream mutability to implement a programming language from within the parsing monad is not a good idea, though no doubt someone'll do it anyway! -- flippa@flippac.org Society does not owe people jobs. Society owes it to itself to find people jobs. From lrpalmer at gmail.com Wed Feb 6 01:12:08 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Feb 6 01:11:08 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> Message-ID: <7ca3f0160802052212l796fd669sb0fc37f1d1cafdf0@mail.gmail.com> On Feb 5, 2008 9:44 PM, Uwe Hollerbach wrote: > lisp> (UTCtime) > "Wed Feb 6 03:57:45 UTC 2008" > --- > lisp> (UTCtime 1.203e9) > "Thu Feb 14 14:40:00 UTC 2008" > -- > But after that, it sure seems to me as if I've taken data out of the > IO monad... haven't I? Given that the second alternative never entered > doIOAction and that after both are done I have a string of characters, > prettily formatted to indicate a time, that's what it feels like to > this unwashed C programmer. Formatting a time is a completely pure operation. If you give the time formatting function the same timestamp, you always get the same string back. It is getting the *current* time which is in the IO monad, since it "returns" different results depending on at what time it is called. Luke From jeff1.61803 at gmail.com Wed Feb 6 01:14:22 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Wed Feb 6 01:13:22 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> Message-ID: <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> On Feb 5, 2008 4:58 PM, Chadda? Fouch? wrote: > 2008/2/5, Jeff ? : > > This is interesting. I've been programming in Concurrent Clean for a > while. > > Instead of monads, Clean supports unique types for mutable arrays and > IO. > > In Clean, I can write code that iterates through a mutable array by > > converting it to a lazy list. This is convenient because I can use all > the > > nice list processing functions that are available. > > > > You could absolutely write something like that in Haskell, but as some > have pointed out, this is probably _not a Good Idea_, even though it > works in your particular case, the array could be modified between the > time you get the lazy list and the time you actually read it... And > there's no way to insure it's not happening in Haskell, and I strongly > doubt there is in Concurrent Clean, could you confirm ? > Concurrent Clean can handle this in a safe way. Here's a code snippet for normalize_2D_ary from ArrayTest.icl: uToList_2D :: *(a u:(b c)) -> (.[c],*(a u:(b c))) | Array a (b c) & Array b c map_in_place_2d_arr :: (a -> a) *(b *(c a)) -> *(b *(c a)) | Array b (c a) & Array c a normalize_2D_ary :: *(a *(b c)) -> *(a *(b c)) | Array a (b c) & Array b c & / c & Ord c normalize_2D_ary ary = let (lst,ary2) = uToList_2D ary max_elem = foldl1 max lst in map_in_place_2d_arr (\ x -> x / max_elem) ary2 uToList_2D takes a unique array, ary, and returns a tuple containing a list of the array elements and a "new" array, ary2. uToList_2D does not modify ary, but Clean's type system forces any function that accesses a unique array to thread the array through and return a "new" array. Under the hood the "new" array actually uses the same memory storage as the original array. So, it is effecient. Threading the array serializes access insuring the array won't be modified until the list is complete. The type system will generate an error if I wrote code that breaks referential transparency. Array and IO Monads can be implemented in Clean on top of the uniqueness type system. The do-notation could be added to the language. However, the comments I've read so far lead me to believe the code I've shown cannot be implemented in Haskell using a lazy list without resorting to unsafe functions. I'm beginning to suspect the uniqueness type system of Clean is more general and flexible than Haskell's monads. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080206/ac8fdb76/attachment.htm From jeff1.61803 at gmail.com Wed Feb 6 01:15:48 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Wed Feb 6 01:14:48 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> Message-ID: <7665bf90802052215v78917300n6ac42877ce00eec9@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: ArrayTest.icl Type: application/octet-stream Size: 2059 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080206/b69e44e0/ArrayTest.obj From jonathanccast at fastmail.fm Wed Feb 6 01:18:48 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 6 01:17:57 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> Message-ID: On 5 Feb 2008, at 10:14 PM, Jeff ? wrote: > > > On Feb 5, 2008 4:58 PM, Chadda? Fouch? > wrote: > 2008/2/5, Jeff ? : > > This is interesting. I've been programming in Concurrent Clean > for a while. > > Instead of monads, Clean supports unique types for mutable > arrays and IO. > > In Clean, I can write code that iterates through a mutable array by > > converting it to a lazy list. This is convenient because I can > use all the > > nice list processing functions that are available. > > > > You could absolutely write something like that in Haskell, but as some > have pointed out, this is probably _not a Good Idea_, even though it > works in your particular case, the array could be modified between the > time you get the lazy list and the time you actually read it... And > there's no way to insure it's not happening in Haskell, and I strongly > doubt there is in Concurrent Clean, could you confirm ? > Concurrent Clean can handle this in a safe way. Here's a code > snippet for normalize_2D_ary from ArrayTest.icl: > > uToList_2D :: *(a u:(b c)) -> (.[c],*(a u:(b c))) | Array a (b c) & > Array b c > map_in_place_2d_arr :: (a -> a) *(b *(c a)) -> *(b *(c a)) | Array > b (c a) & Array c a > normalize_2D_ary :: *(a *(b c)) -> *(a *(b c)) | Array a (b c) & > Array b c & / c & Ord c > normalize_2D_ary ary = > let (lst,ary2) = uToList_2D ary > max_elem = foldl1 max lst > in map_in_place_2d_arr (\ x -> x / max_elem) ary2 > uToList_2D takes a unique array, ary, and returns a tuple > containing a list of the array elements and a "new" array, ary2. > uToList_2D does not modify ary, but Clean's type system forces any > function that accesses a unique array to thread the array through > and return a "new" array. Under the hood the "new" array actually > uses the same memory storage as the original array. So, it is > effecient. Threading the array serializes access insuring the > array won't be modified until the list is complete. I'm confused --- does uToList_2D return the head of the list before or after it finishes reading the array? If before, then I don't see how the type system prevents me from modifying the array before I finish examining the list, as you claim. If after, then the list isn't truly lazy. > The type system will generate an error if I wrote code that breaks > referential transparency. > > Array and IO Monads can be implemented in Clean on top of the > uniqueness type system. The do-notation could be added to the > language. > However, the comments I've read so far lead me to believe the code > I've shown cannot be implemented in Haskell using a lazy list > without resorting to unsafe functions. I'm beginning to suspect > the uniqueness type system of Clean is more general and flexible > than Haskell's monads. You mean this particular monad, of course. jcc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080205/3aaae38c/attachment.htm From chris.casinghino at gmail.com Wed Feb 6 01:21:38 2008 From: chris.casinghino at gmail.com (Chris Casinghino) Date: Wed Feb 6 01:20:38 2008 Subject: [Haskell-cafe] weird ghci behavior with gadts and existentials Message-ID: Hi all, I've been playing a bit with gadts and existentials lately, and I have an example where I don't quite understand the behavior of ghc. The expression in question typechecks sometimes in some versions of ghc, depending on where you write it, and not in other versions. Some other people I've asked report not getting any errors, even when using apparently one of the same versions of ghc I checked. If I create a file which contains: > data TypeGADT t where > TyInt :: TypeGADT Int > > data ExpGADT t where > ExpInt :: Int -> ExpGADT Int > > data HiddenTypeExp = forall t . Hidden (TypeGADT t, ExpGADT t) > > weird = case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e I am able to :load it into ghci just fine (with -fglasgow-exts) with version 6.8.2. However, if I then copy the line: let weird2 = case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e into ghci, I get a type error. In the HEAD version 6.9, I get a type error on the definition of "weird" right away when I :load the file. The type error goes away if I add the line > weird :: ExpGADT Int before the definition of weird. The type error in question is this: :1:46: Inferred type is less polymorphic than expected Quantified type variable `t' escapes When checking an existential match that binds e :: ExpGADT t The pattern(s) have type(s): HiddenTypeExp The body has type: ExpGADT t In a case alternative: Hidden (TyInt, e) -> e In the expression: case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e So, several questions. 1) Why the discrepancy in behavior between ":load"ing the file and copying in the definition in 6.8.2. It seems like, one way or the other, this should be consistent. 2) Several other people report not getting any errors at all, even people with ghc 6.8.2, one of the versions I tested. What's the "right" behavior? My guess would be that this should cause no type error, even without the type annotation. The GADT pattern match against "TyInt" in the case statement should refine the existential type variable t to Int, so no existential type variables are escaping. Is that right? 3) Is there a bug here? Are there two bugs (one, the typing error, two, the difference between ghc and ghci)? Or, do I just not understand what is going on? Sorry for the length of this email! --Chris Casinghino From ahey at iee.org Wed Feb 6 03:20:18 2008 From: ahey at iee.org (Adrian Hey) Date: Wed Feb 6 03:19:26 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> References: <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> Message-ID: <47A96DC2.9030805@iee.org> Neil Mitchell wrote: > Hi > >> If you mean an example of coding style and choice of stack vs. heap, >> I already have.. >> >> http://www.haskell.org/pipermail/haskell-cafe/2008-January/038832.html > > I'm at a loss as why you want a strict version of take. It's clearly > not for performance, as it performs slower. I'd say both the gobbler > programs have a bug, namely that they are not sufficiently lazy. I have already partially scanned the list looking for the first element that satisfies some condition, using a tail recursive search. If such an element is found I want to split the list at that point. If such an element is not found the entire list has been scanned without using any "extra" stack or heap (other than that used by the list itself and the condition test). I could build the reversed list accumulator on the heap as I did the search, but I don't because this will be completely wasted effort in the case where such an element is not found. So instead I just use an unboxed Int to count how far I get and have the search return this and the unsearched suffix (in the case where a matching element is found). But the lifetimes of the list prefix and suffix from this point on are completely unrelated so I don't want the prefix thunk to be hanging on to the unknown sized suffix. As I already know that the list has been evaluated at least up to the point that it gets "chopped off", I choose to use a strict (eager) take. > As an aside, my version of this function would be: > > neilGobbler :: Int -> [x] -> [x] > neilGobbler n xs = length res `seq` res > where res = take n xs > > I have no idea if it takes the heap or the stack, or if it performs > faster or slower. If you still have whatever test you used on the > gobbler, perhaps you could tell us. My guess is it will use O(1) stack and burn O(n) heap (in addition that actually used by the result), so assymptotic complexity wise same as heapGobbler, but probably higher constant factors with ghc due to lazy building of take thunks and subsequent reduction and indirection costs. >> If you mean an example of it biting with lazy code, this is discussed >> so often you'd be spoiled for choice if you search the mailing list >> archives. Here's a good one.. >> >> http://www.haskell.org/pipermail/haskell-cafe/2005-December/013521.html >> >> This example actually shows the problem twice. In one case it's solvable >> by using foldl' instead of foldl. > > Which reduces the memory from O(n) to O(1). Are you sure about that? Using foldl' here eliminates one of the two possible sources of stack overflow, but it doesn't eliminate a space leak. It's O(n) either way. Using strict Map insertion will eliminate a space leak (in this case) and also a possible source stack overflow. > Surely thats a good thing, Would be if it was true :-) > and the code before had a space leak. Space leak is bad, therefore > telling people about it is good. There are plenty of space leaks that won't cause stack overflows, and plenty of stack overflows that aren't caused by space leaks (see above for one example). Again I have to say that even if true, I think this is a pretty lame justification for the current implementation. The *default* behaviour of any useful program should surely be to make best effort to carry on working (and in due course deliver an answer or whatever), even if there is unexpectedly high stack use for some reason (that may or may not be a "bug"). > I think its sensible to let people set their own stack bound (which is > possible), I have no objection to people bounding their stack if that's their choice. I can't imagine why anybody who stopped to think about this would actually want this feature, but it's free world. What I object to is it being bounded by default to something other than overall program memory limit. I know that I could probably achieve this effect myself with +RTS options, but I also want to be able to write libraries that other people are going to use safely without having to add a appropriate warning in the documentation to the effect that some parts use O(n) stack space deliberately, by design. But of course this all assumes that underlying implementation is sufficiently robust to make "unbounded" stacks safe (at least as safe as any other "unbounded" data structure). Unfortunately it seems this isn't the case at present if what various folk have told me is true. > but that clearly just from taking an informal poll of > respondants to this thread, the current default should indeed be the > default. You seem to be the only person clamouring for an unlimited > stack, Yes, this is strange. Same thing happened in the "global variables" debate despite it being obvious to any thinking person that I was correct. Denial of the reality of some very simple examples of the problem was typical of that debate too. :-) Regards -- Adrian Hey From Christian.Maeder at dfki.de Wed Feb 6 04:33:53 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 6 04:32:55 2008 Subject: [Haskell-cafe] Re: bimap 0.2 In-Reply-To: <49b351060802051643q5baf143bn20a5bc3a175ae6a8@mail.gmail.com> References: <49b351060802042011k594e1a2drdedd57671dc9d413@mail.gmail.com> <404396ef0802050211x2faac9b4sde3de93bd4f15486@mail.gmail.com> <49b351060802050301xd8d19edv2955696680606e3c@mail.gmail.com> <404396ef0802050325tf978540s38880146217809a8@mail.gmail.com> <47A85781.1030202@dfki.de> <49b351060802051643q5baf143bn20a5bc3a175ae6a8@mail.gmail.com> Message-ID: <47A97F01.2040308@dfki.de> Stuart Cook wrote: > wrote: >> We've called it "injective maps". Does surjectivity make sense a all? > > In my mind, surjectivity is the property that each key in the > right-hand map is a value in the left-hand map (and vice-versa). This Still, injectivity ("one-to-one") is the only interesting property. The inverse (on the range) is then injective, too. Christian From rendel at rbg.informatik.tu-darmstadt.de Wed Feb 6 05:23:01 2008 From: rendel at rbg.informatik.tu-darmstadt.de (Tillmann Rendel) Date: Wed Feb 6 05:22:12 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> Message-ID: <47A98A85.30607@rbg.informatik.tu-darmstadt.de> Uwe Hollerbach wrote: >> lispUTCTime [] = doIOAction (getClockTime) toS allErrs >> where toS val = String (calendarTimeToString (toUTCTime val)) here you use liftIO (hidden in doIOAction) to use an IO action (getClockTime) inside of a different monad wich contains IO at it's base. so your custom SchemeInterpreterMonad (however it's called) is basically just an extended IO monad. >> lispUTCTime [IntNumber n] = >> return (String (calendarTimeToString (toUTCTime (TOD n 0)))) here you use a pure computation to produce the result string, but then you use return to put it in the monad, too. since IO lives at the base of your custom monad, return will put the String into IO, too. you can't take the IO String out of the IO monad, but you can put the pure String in the IO monad using return. > But after that, it sure seems to me as if I've taken data out of the > IO monad... haven't I? Given that the second alternative never entered > doIOAction and that after both are done I have a string of characters, > prettily formatted to indicate a time, that's what it feels like to > this unwashed C programmer. As explained above, the second alternative uses return instead of doIOAction to "enter" the monad. From a Haskell programmers point of view, you don't have a pure string of characters, but you have a monadic action producing such a string in both cases. That is fine, since your program is inside a REPL anyway, and the very next thing you want to do is to print the computed value, wich is another IO action. but from the point of view of the Scheme programmer using your interpreter, there is no special IO monad around, since the whole Scheme interpreter lives in IO and IO is available to him everywhere. Tillmann From ndmitchell at gmail.com Wed Feb 6 05:48:17 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Feb 6 05:47:14 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47A96DC2.9030805@iee.org> References: <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> Message-ID: <404396ef0802060248q7c8bb272t62525b2451be9600@mail.gmail.com> Hi > I have already partially scanned the list looking for the first > element that satisfies some condition, using a tail recursive search. > > If such an element is found I want to split the list at that point. span/break? I really can't believe the memory overhead of span is that terrible, you are only duplicating the (:)'s and its only one traversal. > > As an aside, my version of this function would be: > > > > neilGobbler :: Int -> [x] -> [x] > > neilGobbler n xs = length res `seq` res > > where res = take n xs > > > My guess is it will use O(1) stack and burn O(n) heap (in addition that > actually used by the result), so assymptotic complexity wise same as > heapGobbler, but probably higher constant factors with ghc due to lazy > building of take thunks and subsequent reduction and indirection costs. Sure? Guessing constant factors related to strictness and laziness is incredibly hard! My guess based on "gut feeling" is that the program will take less time, and use half the memory. But given my initial comment, that guess is not very reliable. > Yes, this is strange. Same thing happened in the "global variables" > debate despite it being obvious to any thinking person that I was > correct. Denial of the reality of some very simple examples of the > problem was typical of that debate too. The particular world I live in is special, but I like it :-) Thanks Neil From bulat.ziganshin at gmail.com Wed Feb 6 04:30:08 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 6 06:08:15 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> Message-ID: <1495211458.20080206123008@gmail.com> Hello Uwe, Wednesday, February 6, 2008, 7:44:27 AM, you wrote: > But after that, it sure seems to me as if I've taken data out of the > IO monad... this means that you can't use results of IO actions in pure functions. your code works in some transformed version of IO monad, so you don't escaped it if we call pure functions as "functions" and non-pure ones as "procedures", the rule is "functions can't call procedures", but all other activity is possible. in your do_action you calls procedure (to format current time) and call a function (to format given time). do_action is procedure (because it works in transformed IO monad), so you don't break any rules -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From v.dijk.bas at gmail.com Wed Feb 6 06:32:40 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Feb 6 06:31:38 2008 Subject: [Haskell-cafe] Inverting a Monad Message-ID: Hello, Is there a way to 'invert' an arbitrary Monad? By 'inverting' I mean to turn success into failure and failure into success. Here are some specific inversions of the Maybe and List Monad: invM :: Maybe a -> Maybe () invM Nothing = Just () invM (Just _) = Nothing invL :: [] a -> [] () invL [] = [()] invL (_:_) = [] How can I define this for an arbitrary Monad m? More specifically, I would like to define: inv :: (Monad m, M.MonadPlus m, ???) => m a -> m () inv m = if m fails then return () if m succeeds then fail The following obviously doesn't work: inv m = (m >> mzero) `mplus` return () because it will always return (). There's also a 'inversion' for natural numbers: invN :: Int -> Int invN 0 = 1 invN n = 0 but how can I define that without pattern matching, so only using arithmetic operations, +, -, *, ^, ...? The reason I ask this is that I'm writing a parser combinator library to understand parser a bit better. And I would like to define the combinator: notFollowedBy :: P t m a -> P t m () 'notFollowedBy p' fails when p succeeds and returns () when p fails. I will share the code when it's a bit more polished. Thanks, Bas From miguelimo38 at yandex.ru Wed Feb 6 06:39:16 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed Feb 6 06:38:23 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: Message-ID: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> > invM :: Maybe a -> Maybe () > invM Nothing = Just () > invM (Just _) = Nothing > > invL :: [] a -> [] () > invL [] = [()] > invL (_:_) = [] > > > How can I define this for an arbitrary Monad m? Such as Identity? From felipe.lessa at gmail.com Wed Feb 6 06:45:02 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed Feb 6 06:44:03 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> Message-ID: On Feb 6, 2008 9:39 AM, Miguel Mitrofanov wrote: > > How can I define this for an arbitrary Monad m? > > Such as Identity? An arbirtrary monad can't be inverted, however there's Error and ErrorT that provide throwing and catching abilities. I guess your parser is a monad transformer, so *maybe* the solution is to require MonadError from the inner monad. Cheers, -- Felipe. From v.dijk.bas at gmail.com Wed Feb 6 06:46:06 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Feb 6 06:45:04 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> Message-ID: On Feb 6, 2008 12:39 PM, Miguel Mitrofanov wrote: > > invM :: Maybe a -> Maybe () > > invM Nothing = Just () > > invM (Just _) = Nothing > > > > invL :: [] a -> [] () > > invL [] = [()] > > invL (_:_) = [] > > > > > > How can I define this for an arbitrary Monad m? > > Such as Identity? > Well in: inv :: (Monad m, ...) => m a -> m () inv m = ... I don't mind that there are more constraints on 'm' than just Monad maybe a MonadPlus constraint or others are needed. (I was even thinking about a MonadTimes class as in: class MonadPlus m => MonadTimes m where mone :: m () mtimes :: m a -> m a -> m a ) Thanks, Bas From miguelimo38 at yandex.ru Wed Feb 6 06:50:46 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed Feb 6 06:49:55 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> Message-ID: <1D3B08E0-DCDC-4897-BCA1-5E53F5D04248@yandex.ru> >> Such as Identity? >> > > Well in: > > inv :: (Monad m, ...) => m a -> m () > inv m = ... > > I don't mind that there are more constraints on 'm' than just Monad class Monad m => MonadInv m where inv :: m a -> m () With this constraint you certainly can have your "inv". From v.dijk.bas at gmail.com Wed Feb 6 06:51:16 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Feb 6 06:50:14 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> Message-ID: On Feb 6, 2008 12:45 PM, Felipe Lessa wrote: > I guess your parser is a monad transformer, so *maybe* the solution is to require > MonadError from the inner monad. Indeed my parser 'P t m a' is a monad transformer. I will try out requiring 'm' to have a 'MonadError' constraint and see how far I come with that. I'll let you know. Thanks, Bas From v.dijk.bas at gmail.com Wed Feb 6 06:54:51 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Feb 6 06:53:48 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: <1D3B08E0-DCDC-4897-BCA1-5E53F5D04248@yandex.ru> References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> <1D3B08E0-DCDC-4897-BCA1-5E53F5D04248@yandex.ru> Message-ID: On Feb 6, 2008 12:50 PM, Miguel Mitrofanov wrote: > class Monad m => MonadInv m where inv :: m a -> m () > > With this constraint you certainly can have your "inv". Yes indeed. But I was kind of hoping that I could use standard Haskell classes without adding my own. (BTW I would like to know of other possible applications of 'inv' besides my parser. So yell if you find one please) Thanks, Bas From matthew.pocock at ncl.ac.uk Wed Feb 6 06:58:02 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Wed Feb 6 06:56:58 2008 Subject: [Haskell-cafe] classes for data structures Message-ID: <200802061158.02285.matthew.pocock@ncl.ac.uk> Hi, I've been working a lot with maps, sets and lists. While the process of getting things out of them is abstracted by foldable, traversable and friends, the process of building one up is not. Would it be possible to have something like: class Buildable b where empty :: b a --makes an empty b with elements of type a insert :: a -> b a -> b a --inserts the new element into the buildable I'm not particularly wedded to the names. It's just that it would be very convenient sometimes to collect data items into e.g. a list or a set, without pushing in some klunky foralled insert function. I see that this is realted to MonadPlus, but the space of possible container classes is wider than that of monads e.g. set. Matthew From lrpalmer at gmail.com Wed Feb 6 07:04:13 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Feb 6 07:03:41 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: Message-ID: <7ca3f0160802060404t7c9a789y6a4dc4510fff4187@mail.gmail.com> On Feb 6, 2008 11:32 AM, Bas van Dijk wrote: > The following obviously doesn't work: > > inv m = (m >> mzero) `mplus` return () > > because it will always return (). How about: inv m = do success <- (m >> return True) `mplus` return False if success then mzero else return () Luke From felipe.lessa at gmail.com Wed Feb 6 07:16:06 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed Feb 6 07:15:36 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: <7ca3f0160802060404t7c9a789y6a4dc4510fff4187@mail.gmail.com> References: <7ca3f0160802060404t7c9a789y6a4dc4510fff4187@mail.gmail.com> Message-ID: On Feb 6, 2008 10:04 AM, Luke Palmer wrote: > How about: > > inv m = do > success <- (m >> return True) `mplus` return False > if success then mzero else return () Prelude Control.Monad> inv [] [()] Prelude Control.Monad> inv [10] [()] -- Felipe. From haskell at list.mightyreason.com Wed Feb 6 07:24:13 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Wed Feb 6 07:23:18 2008 Subject: [Haskell-cafe] Re: weird ghci behavior with gadts and existentials In-Reply-To: References: Message-ID: <47A9A6ED.9060904@list.mightyreason.com> Let me add: > data ExpGADT t where > ExpInt :: Int -> ExpGADT Int > ExpChar :: Char -> ExpGADT Char Which type do you think 'unHide' and 'wierd' should have: > unHide h = case h of > Hidden (_,e) -> e > > wierd = unHide (Hidden (TyInt,ExpInt 3)) either: > unHide :: HiddenTypeExp -> ExpGADT t -- Choice 1: Polymorphic t > unHide :: HiddenTypeExp -> ExpGADT Int -- Choice 2: Monomorphic Int Note that TypeGADT/TyInt are irrelevant to unHide and wierd. Clearly the first choice to unHide violates the encapsulation of 't'. Clearly I cannot choose the 2nd choice, since it might be an ExpChar. So unHide is impossible to write. Chris Casinghino wrote: > Hi all, > > I've been playing a bit with gadts and existentials lately, and I > have an example where I don't quite understand the behavior of > ghc. The expression in question typechecks sometimes in some > versions of ghc, depending on where you write it, and not in > other versions. Some other people I've asked report not getting > any errors, even when using apparently one of the same versions > of ghc I checked. > > If I create a file which contains: > >> data TypeGADT t where >> TyInt :: TypeGADT Int >> >> data ExpGADT t where >> ExpInt :: Int -> ExpGADT Int >> >> data HiddenTypeExp = forall t . Hidden (TypeGADT t, ExpGADT t) >> >> weird = case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e > > I am able to :load it into ghci just fine (with -fglasgow-exts) > with version 6.8.2. However, if I then copy the line: > > let weird2 = case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e > > into ghci, I get a type error. In the HEAD version 6.9, I get a > type error on the definition of "weird" right away when I :load > the file. The type error goes away if I add the line > >> weird :: ExpGADT Int > > before the definition of weird. > > The type error in question is this: > > :1:46: > Inferred type is less polymorphic than expected > Quantified type variable `t' escapes > When checking an existential match that binds > e :: ExpGADT t > The pattern(s) have type(s): HiddenTypeExp > The body has type: ExpGADT t > In a case alternative: Hidden (TyInt, e) -> e > In the expression: > case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e > > So, several questions. > > 1) Why the discrepancy in behavior between ":load"ing the file and > copying in the definition in 6.8.2. It seems like, one way or the > other, this should be consistent. > > 2) Several other people report not getting any errors at all, even > people with ghc 6.8.2, one of the versions I tested. What's the > "right" behavior? My guess would be that this should cause no > type error, even without the type annotation. The GADT pattern > match against "TyInt" in the case statement should refine the > existential type variable t to Int, so no existential type > variables are escaping. Is that right? > > 3) Is there a bug here? Are there two bugs (one, the typing error, > two, the difference between ghc and ghci)? Or, do I just not > understand what is going on? > > Sorry for the length of this email! > > --Chris Casinghino From lutz at iks-jena.de Wed Feb 6 07:49:30 2008 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed Feb 6 07:48:30 2008 Subject: [Haskell-cafe] Inverting a Monad References: Message-ID: * Felipe Lessa wrote: > Prelude Control.Monad> inv [] > [()] > Prelude Control.Monad> inv [10] > [()] inv m = if m == mzero then return () else mzero `asTypeOf` m Yes, unfair. From lemming at henning-thielemann.de Wed Feb 6 08:00:51 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 07:59:50 2008 Subject: [Haskell-cafe] Linear algebra In-Reply-To: <6dbd4d000801311711y6f0eb025o66a09e3cc7c92356@mail.gmail.com> References: <200802010011.21341.jon@ffconsultancy.com> <6dbd4d000801311711y6f0eb025o66a09e3cc7c92356@mail.gmail.com> Message-ID: On Thu, 31 Jan 2008, Denis Bueno wrote: > On Thu, Jan 31, 2008 at 7:11 PM, Jon Harrop wrote: > > > > Has anyone written anything on the use of FP (e.g. point free style) in linear > > algebra problems? > > I'm not sure how relevant this is to you, but John Backus wrote > foundationally on it and related topics. > > http://www.stanford.edu/class/cs242/readings/backus.pdf > > "Can Programming Be Liberated from the von Neumann Style?" > > It's an excellent read, regardless. http://www.haskell.org/haskellwiki/Linear_algebra http://darcs.haskell.org/numeric-quest/Orthogonals.html From v.dijk.bas at gmail.com Wed Feb 6 08:07:27 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Feb 6 08:06:25 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: Message-ID: On Feb 6, 2008 1:49 PM, Lutz Donnerhacke wrote: > inv m = if m == mzero then return () else mzero `asTypeOf` m Interesting! > :t inv inv :: (MonadPlus m, Eq (m ())) => m () -> m () The 'Eq' constraint on 'm ()' is a bit problemetic I think in case 'm' is a function like a 'State'. Thanks, Bas From peter.padawitz at udo.edu Wed Feb 6 08:32:08 2008 From: peter.padawitz at udo.edu (Peter Padawitz) Date: Wed Feb 6 08:31:08 2008 Subject: [Haskell-cafe] lazy evaluation Message-ID: <47A9B6D8.3010306@udo.edu> Can anybody give me a simple explanation why the second definition of a palindrome checker does not terminate, although the first one does? pal :: Eq a => [a] -> Bool pal s = b where (b,r) = eqrev s r [] eqrev :: Eq a => [a] -> [a] -> [a] -> (Bool,[a]) eqrev (x:s1) ~(y:s2) acc = (x==y&&b,r) where (b,r) = eqrev s1 s2 (x:acc) eqrev _ _ acc = (True,acc) pal :: Eq a => [a] -> Bool pal s = b where (b,r) = eqrev' s r eqrev' :: Eq a => [a] -> [a] -> (Bool,[a]) eqrev' (x:s1) ~(y:s2) = (x==y&&b,r++[y]) where (b,r) = eqrev' s1 s2 eqrev' _ _ = (True,[]) Peter From lemming at henning-thielemann.de Wed Feb 6 08:43:46 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 08:47:46 2008 Subject: [Haskell-cafe] lazy evaluation In-Reply-To: <47A9B6D8.3010306@udo.edu> References: <47A9B6D8.3010306@udo.edu> Message-ID: On Wed, 6 Feb 2008, Peter Padawitz wrote: > Can anybody give me a simple explanation why the second definition of a > palindrome checker does not terminate, although the first one does? Just another question, what about x == reverse x ? - You can still optimize for avoiding duplicate equality tests. From lemming at henning-thielemann.de Wed Feb 6 09:00:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 08:59:01 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: <200802061158.02285.matthew.pocock@ncl.ac.uk> References: <200802061158.02285.matthew.pocock@ncl.ac.uk> Message-ID: On Wed, 6 Feb 2008, Matthew Pocock wrote: > Hi, > > I've been working a lot with maps, sets and lists. While the process of > getting things out of them is abstracted by foldable, traversable and > friends, the process of building one up is not. Would it be possible to have > something like: > > class Buildable b where > empty :: b a --makes an empty b with elements of type a > insert :: a -> b a -> b a --inserts the new element into the buildable How can this interface be used both for lists and maps? I'm afraid it is difficult to find an interface that fits the needs of many different data structures. Maybe at least a generalized 'unfoldr' is possible. From miguelimo38 at yandex.ru Wed Feb 6 09:06:09 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Wed Feb 6 09:05:15 2008 Subject: [Haskell-cafe] lazy evaluation In-Reply-To: <47A9B6D8.3010306@udo.edu> References: <47A9B6D8.3010306@udo.edu> Message-ID: On 6 Feb 2008, at 16:32, Peter Padawitz wrote: > Can anybody give me a simple explanation why the second definition > of a palindrome checker does not terminate, although the first one > does? > > pal :: Eq a => [a] -> Bool > pal s = b where (b,r) = eqrev s r [] > > eqrev :: Eq a => [a] -> [a] -> [a] -> (Bool,[a]) > eqrev (x:s1) ~(y:s2) acc = (x==y&&b,r) where (b,r) = eqrev s1 s2 > (x:acc) > eqrev _ _ acc = (True,acc) I. eqrev "" (_|_) acc = (True, acc) II.a. eqrev "1" (_|_) "" = ('1' == (_|_) && b, r) where (b,r) = eqrev "" (_|_) "1" By (I), (b,r) = (True, "1"), so eqrev "1" (_|_) "" = ((_|_),"1") II.b. eqrev "1" "1" "" = ('1' == '1' && b, r) where (b,r) = eqrev "" "" "1" (b,r) = (True,"1"), so eqrev "1" "1" "" = (True,"1") Therefore, the least fixed point of \r -> eqrev "1" r "" is "1" and the answer is True. > pal :: Eq a => [a] -> Bool > pal s = b where (b,r) = eqrev' s r > > eqrev' :: Eq a => [a] -> [a] -> (Bool,[a]) > eqrev' (x:s1) ~(y:s2) = (x==y&&b,r++[y]) where (b,r) = eqrev' s1 s2 > eqrev' _ _ = (True,[]) I. eqrev' "" (_|_) = (True,[]) II.a. eqrev' "1" (_|_) = ('1' == (_|_) && b, r ++ [(_|_)]) where (b,r) = eqrev' "" (_|_) By (I), (b,r) = (True,[]), so eqrev' "1" (_|_) = ((_|_),[(_|_)]) II.b. eqrev' "1" [(_|_)] = ('1' == (_|_) && b, r ++ [(_|_)]) where (b,r) = eqrev' "" [] (b,r) = (True,[]), so eqrev' "1" [(_|_)] = ((_|_),[(_|_)]) Therefore, the least fixed point of \r -> eqrev' "1" r is [(_|_)] and the answer is (_|_). No wonder it hangs. From lemming at henning-thielemann.de Wed Feb 6 08:50:11 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 09:08:10 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> <47A8C1D2.3080300@imageworks.com> Message-ID: On Tue, 5 Feb 2008, Felipe Lessa wrote: > On Feb 5, 2008 6:06 PM, Dan Weston wrote: > > Can you do this with a GHC rule? Something like: > > > > {-# RULES > > "join_dot_fmap_return/id" forall x . join (fmap return x) = x > > #-} > > > > Dan > > I guess this would make use of the rule (otherwise the transformation > would change the code's semantic) but would not enforce that the rule > itself is valid (which is undecidable). I have already thought about (ab)using GHC rules for forcing programmers to take care. :-) That is, if the rule would be stated as above, then programmers _have_ to ensure that the law is satisfied, and the optimizer will penalize violations of the rules with non-working code. From lemming at henning-thielemann.de Wed Feb 6 09:09:56 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 09:08:53 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <1542297371.20080205182543@gmail.com> References: <1542297371.20080205182543@gmail.com> Message-ID: On Tue, 5 Feb 2008, Bulat Ziganshin wrote: > Hello Henning, > > Tuesday, February 5, 2008, 6:01:27 PM, you wrote: > > > Is Haskell's type system including extensions strong enough for describing > > a function, that does not always return a trivial value? E.g. > > (filter (\x -> x==1 && x==2)) > > such things may be detected by (too) smart compiler, but in general > it's undecidable: filter (if LifeHasMeaning then const True else odd) ;) As I said, if the programmer could specify an input on the type level for which the output is non-trivial, then this would solve the problem. From dbueno at gmail.com Wed Feb 6 09:11:55 2008 From: dbueno at gmail.com (Denis Bueno) Date: Wed Feb 6 09:10:53 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: References: <200802061158.02285.matthew.pocock@ncl.ac.uk> Message-ID: <6dbd4d000802060611r7d54329fx978843c8897ede52@mail.gmail.com> On Feb 6, 2008 9:00 AM, Henning Thielemann wrote: > On Wed, 6 Feb 2008, Matthew Pocock wrote: > > class Buildable b where > > empty :: b a --makes an empty b with elements of type a > > insert :: a -> b a -> b a --inserts the new element into the buildable > > How can this interface be used both for lists and maps? [...] One solution is to change the class slightly: class Buildable t x where empty :: t insert :: x -> t -> t instance Buildable (Map k a) (k, a) where empty = Map.empty insert = uncurry Map.insert -- Denis From felipe.lessa at gmail.com Wed Feb 6 09:13:55 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed Feb 6 09:12:53 2008 Subject: [Haskell-cafe] fmap vs. liftM In-Reply-To: References: <50E16135-5D67-490E-94EC-D7E8C0E17EE1@yandex.ru> <47A8C1D2.3080300@imageworks.com> Message-ID: On Feb 6, 2008 11:50 AM, Henning Thielemann wrote: > That is, if the rule would be stated as above, then > programmers _have_ to ensure that the law is satisfied, and the optimizer > will penalize violations of the rules with non-working code. Be careful. For much less (blowing up when stack > 8MiB) we already had 42 messages =). -- Felipe. From v.dijk.bas at gmail.com Wed Feb 6 09:21:26 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Feb 6 09:20:23 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> Message-ID: On Feb 6, 2008 12:51 PM, Bas van Dijk wrote: > I will try out requiring 'm' to have a 'MonadError' constraint and see how far I come > with that. I'm now trying to define 'inv' using 'catchError` but I can't get it to work. The following obviously doesn't work: import Control.Monad.Error inv :: MonadError e m => m a -> m () inv m = (m >> fail "") `catchError` \_ -> (return ()) Bas From bulat.ziganshin at gmail.com Wed Feb 6 09:22:14 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 6 09:21:25 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: <1542297371.20080205182543@gmail.com> Message-ID: <38610660.20080206172214@gmail.com> Hello Henning, Wednesday, February 6, 2008, 5:09:56 PM, you wrote: >> > Is Haskell's type system including extensions strong enough for describing >> > a function, that does not always return a trivial value? E.g. >> > (filter (\x -> x==1 && x==2)) >> >> such things may be detected by (too) smart compiler, but in general >> it's undecidable: filter (if LifeHasMeaning then const True else odd) ;) > As I said, if the programmer could specify an input on the type level for > which the output is non-trivial, then this would solve the problem. it's another question: you can describe trivial values using type system, but can't prohibit them using it - it's impossible because you can't check for arbitrary algorithm whether it will be finally stopped -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Wed Feb 6 09:40:36 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 09:39:39 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: <6dbd4d000802060611r7d54329fx978843c8897ede52@mail.gmail.com> References: <200802061158.02285.matthew.pocock@ncl.ac.uk> <6dbd4d000802060611r7d54329fx978843c8897ede52@mail.gmail.com> Message-ID: On Wed, 6 Feb 2008, Denis Bueno wrote: > On Feb 6, 2008 9:00 AM, Henning Thielemann > wrote: > > On Wed, 6 Feb 2008, Matthew Pocock wrote: > > > class Buildable b where > > > empty :: b a --makes an empty b with elements of type a > > > insert :: a -> b a -> b a --inserts the new element into the buildable > > > > How can this interface be used both for lists and maps? [...] > > One solution is to change the class slightly: > > class Buildable t x where > empty :: t > insert :: x -> t -> t > > instance Buildable (Map k a) (k, a) where > empty = Map.empty > insert = uncurry Map.insert ok, maybe with functional dependency t -> x From josef.svenningsson at gmail.com Wed Feb 6 09:51:27 2008 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Wed Feb 6 09:50:26 2008 Subject: [Haskell-cafe] lazy evaluation In-Reply-To: References: <47A9B6D8.3010306@udo.edu> Message-ID: <8dde104f0802060651x59f6f461qe973ccfc7e69fe32@mail.gmail.com> On Feb 6, 2008 3:06 PM, Miguel Mitrofanov wrote: > > On 6 Feb 2008, at 16:32, Peter Padawitz wrote: > > > Can anybody give me a simple explanation why the second definition > > of a palindrome checker does not terminate, although the first one > > does? > > > > pal :: Eq a => [a] -> Bool > > pal s = b where (b,r) = eqrev s r [] > > > > eqrev :: Eq a => [a] -> [a] -> [a] -> (Bool,[a]) > > eqrev (x:s1) ~(y:s2) acc = (x==y&&b,r) where (b,r) = eqrev s1 s2 > > (x:acc) > > eqrev _ _ acc = (True,acc) > > I. eqrev "" (_|_) acc = (True, acc) > II.a. eqrev "1" (_|_) "" = ('1' == (_|_) && b, r) where (b,r) = eqrev > "" (_|_) "1" > By (I), (b,r) = (True, "1"), so eqrev "1" (_|_) "" = ((_|_),"1") > II.b. eqrev "1" "1" "" = ('1' == '1' && b, r) where (b,r) = eqrev "" > "" "1" > (b,r) = (True,"1"), so eqrev "1" "1" "" = (True,"1") > > Therefore, the least fixed point of \r -> eqrev "1" r "" is "1" and > the answer is True. > > > pal :: Eq a => [a] -> Bool > > pal s = b where (b,r) = eqrev' s r > > > > eqrev' :: Eq a => [a] -> [a] -> (Bool,[a]) > > eqrev' (x:s1) ~(y:s2) = (x==y&&b,r++[y]) where (b,r) = eqrev' s1 s2 > > eqrev' _ _ = (True,[]) > > I. eqrev' "" (_|_) = (True,[]) > II.a. eqrev' "1" (_|_) = ('1' == (_|_) && b, r ++ [(_|_)]) where (b,r) > = eqrev' "" (_|_) > By (I), (b,r) = (True,[]), so eqrev' "1" (_|_) = ((_|_),[(_|_)]) > II.b. eqrev' "1" [(_|_)] = ('1' == (_|_) && b, r ++ [(_|_)]) where > (b,r) = eqrev' "" [] > (b,r) = (True,[]), so eqrev' "1" [(_|_)] = ((_|_),[(_|_)]) > Therefore, the least fixed point of \r -> eqrev' "1" r is [(_|_)] and > the answer is (_|_). No wonder it hangs. > This proof also shows us where the problem lies and how to fix it. It turns out to be really easy: change 'r++[y]' to 'r++[x]' and the program works. Cheers, Josef From apfelmus at quantentunnel.de Wed Feb 6 09:58:23 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Feb 6 09:57:43 2008 Subject: [Haskell-cafe] Re: Data.Ord and Heaps In-Reply-To: <47A87BBC.1030909@di.unipi.it> References: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> <47A87BBC.1030909@di.unipi.it> Message-ID: Roberto Zunino wrote: >> I'd really like to write >> >> class (forall a . Ord p a) => OrdPolicy p where >> >> but I guess that's (currently) not possible. > > Actually, it seems that something like this can be achieved, at some price. > > data O a where O :: Ord a => O a > > data O1 p where O1:: (forall a . Ord a => O (p a)) -> O1 p Ah, very nice :) > First, I change the statement ;-) to > > class (forall a . Ord a => Ord p a) => OrdPolicy p > > since I guess this is what you really want. Right, modulo the fact that I also forgot the parenthesis class (forall a . Ord a => Ord (p a)) => OrdPolicy p So, the intention is to automatically have the instance instance (OrdPolicy p, Ord a) => Ord (p a) where which can be obtained from your GADT proof compare = case ordAll of O1 o -> case o of (O :: O (p a)) -> compare This instance declaration is a bit problematic because it contains only type variables. Fortunately, the phantom type approach doesn't have this problem: data OrdBy p a = OrdBy { unOrdBy :: a } data O a where O :: Ord a => O a class OrdPolicy p where -- simplified O1 ordAll :: Ord a => O (OrdBy p a) instance (Ord a, OrdPolicy p) => Ord (OrdBy p a) where compare = case ordAll of { (O :: O (OrdBy p a)) -> compare } By making the dictionary in O explicit, we can even make this Haskell98! class OrdPolicy p where compare' :: Ord a => OrdBy p a -> OrdBy p a -> Ordering instance (Ord a, OrdPolicy p) => Ord (OrdBy p a) where compare = compare' On second thought, being polymorphic in a is probably too restrictive: the only usable OrdPolicy besides the identity is Reverse :) After all, there aren't so many useful functions with type compare' :: forall a. (a -> a -> Ordering) -> (a -> a -> Ordering) So, other custom orderings usually depend on the type a . Did you have any specific examples in mind, Stephan? At the moment, I can only think of ordering Maybe a such that Nothing is either the largest or the smallest element on f g x y = g x `f` g y data Up instance Ord a => Ord (OrdBy Up (Maybe a)) where compare = f `on` unOrdBy where f Nothing Nothing = EQ f x Nothing = LT f Nothing y = GT f (Just x) (Just y) = compare x y data Down instance Ord a => Ord (OrdBy Down (Maybe a)) where compare = f `on` unOrdBy where f Nothing Nothing = EQ f x Nothing = GT f Nothing y = LT f (Just x) (Just y) = compare x y But I think that those two orderings merit special data types like data Raised a = Bottom | Raise a deriving (Eq, Ord) data Lowered a = Lower a | Top deriving (Eq, Ord) instead of type Raised a = OrdBy Down (Maybe a) type Lowered a = OrdBy Up (Maybe a) Regards, apfelmus From lemming at henning-thielemann.de Wed Feb 6 10:09:28 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 10:08:31 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <38610660.20080206172214@gmail.com> References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> Message-ID: On Wed, 6 Feb 2008, Bulat Ziganshin wrote: > Hello Henning, > > Wednesday, February 6, 2008, 5:09:56 PM, you wrote: > > >> > Is Haskell's type system including extensions strong enough for describing > >> > a function, that does not always return a trivial value? E.g. > >> > (filter (\x -> x==1 && x==2)) > >> > >> such things may be detected by (too) smart compiler, but in general > >> it's undecidable: filter (if LifeHasMeaning then const True else odd) ;) > > > As I said, if the programmer could specify an input on the type level for > > which the output is non-trivial, then this would solve the problem. > > it's another question: you can describe trivial values using type > system, but can't prohibit them using it - it's impossible because you > can't check for arbitrary algorithm whether it will be finally stopped I could consider the function buggy, if it does not terminate on the given example. From jules at jellybean.co.uk Wed Feb 6 10:12:48 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Feb 6 10:11:50 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: <200802061158.02285.matthew.pocock@ncl.ac.uk> References: <200802061158.02285.matthew.pocock@ncl.ac.uk> Message-ID: <47A9CE70.4060206@jellybean.co.uk> Matthew Pocock wrote: > Hi, > > I've been working a lot with maps, sets and lists. While the process of > getting things out of them is abstracted by foldable, traversable and > friends, the process of building one up is not. Would it be possible to have > something like: > > class Buildable b where > empty :: b a --makes an empty b with elements of type a > insert :: a -> b a -> b a --inserts the new element into the buildable Another approach uses : singleton :: a -> b a and then just mappend :: b a -> b a -> b a i.e. make b a into a Monoid. singleton = pure = return, if there happens to be a Monad/Applicative instance around. And indeed there *will* be a Monad, if there is a sensible way of defining concat :: b (b a) -> b a, which there probably is. Jules From peter.padawitz at udo.edu Wed Feb 6 10:19:41 2008 From: peter.padawitz at udo.edu (Peter Padawitz) Date: Wed Feb 6 10:18:40 2008 Subject: [Haskell-cafe] lazy evaluation In-Reply-To: <47A9B6D8.3010306@udo.edu> References: <47A9B6D8.3010306@udo.edu> Message-ID: <47A9D00D.2090900@udo.edu> @ Miguel: Thanks for carrying out the fixpoint computation I was too lazy to do! I see: lazy evaluation programmers must not be lazy ;-) @ Josef: Oh yes, I mixed up x and y! In fact, I was confused about the semantical difference between eqrev and eqrev', although eqrev is just an iterative version of eqrev' -- if x and y were not mixed up. Peter Peter Padawitz wrote: > Can anybody give me a simple explanation why the second definition of > a palindrome checker does not terminate, although the first one does? > > pal :: Eq a => [a] -> Bool > pal s = b where (b,r) = eqrev s r [] > > eqrev :: Eq a => [a] -> [a] -> [a] -> (Bool,[a]) > eqrev (x:s1) ~(y:s2) acc = (x==y&&b,r) where (b,r) = eqrev s1 s2 (x:acc) > eqrev _ _ acc = (True,acc) > > pal :: Eq a => [a] -> Bool > pal s = b where (b,r) = eqrev' s r > > eqrev' :: Eq a => [a] -> [a] -> (Bool,[a]) > eqrev' (x:s1) ~(y:s2) = (x==y&&b,r++[y]) where (b,r) = eqrev' s1 s2 > eqrev' _ _ = (True,[]) From dbueno at gmail.com Wed Feb 6 10:32:14 2008 From: dbueno at gmail.com (Denis Bueno) Date: Wed Feb 6 10:31:16 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: References: <200802061158.02285.matthew.pocock@ncl.ac.uk> <6dbd4d000802060611r7d54329fx978843c8897ede52@mail.gmail.com> Message-ID: <6dbd4d000802060732j46ca6420g465bf767e17eb08a@mail.gmail.com> On Feb 6, 2008 9:40 AM, Henning Thielemann wrote: > > > On Wed, 6 Feb 2008, Denis Bueno wrote: > > > On Feb 6, 2008 9:00 AM, Henning Thielemann > > wrote: > > > On Wed, 6 Feb 2008, Matthew Pocock wrote: > > > > class Buildable b where > > > > empty :: b a --makes an empty b with elements of type a > > > > insert :: a -> b a -> b a --inserts the new element into the buildable > > > > > > How can this interface be used both for lists and maps? [...] > > > > One solution is to change the class slightly: > > > > class Buildable t x where > > empty :: t > > insert :: x -> t -> t > > > > instance Buildable (Map k a) (k, a) where > > empty = Map.empty > > insert = uncurry Map.insert > > ok, maybe with functional dependency t -> x > I'm not sure about that. It's often convenient to have two instances, one like the one I gave above, and others involving something that embeds a key-value pair: type SomethingWithKV k a = KV {getKV :: (k, a)} instance Buildable (Map k a) (SomethingWithKV k a) where empty = Map.empty insert s m = uncurry Map.insert (getKV s) m I have done this before -- it's very convenient, and I think makes the code that uses empty and insert more robust, and easier to read. -- Denis From lemming at henning-thielemann.de Wed Feb 6 10:36:02 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 10:35:03 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: <6dbd4d000802060732j46ca6420g465bf767e17eb08a@mail.gmail.com> References: <200802061158.02285.matthew.pocock@ncl.ac.uk> <6dbd4d000802060611r7d54329fx978843c8897ede52@mail.gmail.com> <6dbd4d000802060732j46ca6420g465bf767e17eb08a@mail.gmail.com> Message-ID: On Wed, 6 Feb 2008, Denis Bueno wrote: > On Feb 6, 2008 9:40 AM, Henning Thielemann > > > ok, maybe with functional dependency t -> x > > I'm not sure about that. It's often convenient to have two instances, > one like the one I gave above, and others involving something that > embeds a key-value pair: > > type SomethingWithKV k a = KV {getKV :: (k, a)} > instance Buildable (Map k a) (SomethingWithKV k a) where > empty = Map.empty > insert s m = uncurry Map.insert (getKV s) m > > I have done this before -- it's very convenient, and I think makes the > code that uses empty and insert more robust, and easier to read. But why do you want to have the special type SomethingWithKV, but not MapSomething ? From dbueno at gmail.com Wed Feb 6 10:39:29 2008 From: dbueno at gmail.com (Denis Bueno) Date: Wed Feb 6 10:38:28 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: References: <200802061158.02285.matthew.pocock@ncl.ac.uk> <6dbd4d000802060611r7d54329fx978843c8897ede52@mail.gmail.com> <6dbd4d000802060732j46ca6420g465bf767e17eb08a@mail.gmail.com> Message-ID: <6dbd4d000802060739v7fa03b9epbf347e300c652869@mail.gmail.com> On Feb 6, 2008 10:36 AM, Henning Thielemann wrote: > > type SomethingWithKV k a = KV {getKV :: (k, a)} > > instance Buildable (Map k a) (SomethingWithKV k a) where > > empty = Map.empty > > insert s m = uncurry Map.insert (getKV s) m > > > > I have done this before -- it's very convenient, and I think makes the > > code that uses empty and insert more robust, and easier to read. > > But why do you want to have the special type SomethingWithKV, but not > MapSomething ? Do you mean a map that maps SomethingWithKV to whatever, instead of k to v? My point is that if you add the functional dependency, you can't write instances for types which wrap what you're really interested in. You have to manually unwrap those types everywhere they interact with a map. This is tedious and error-prone. Being able to write such instances is useful, I think, though not always clearer in all cases. -- Denis From apfelmus at quantentunnel.de Wed Feb 6 10:51:27 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Wed Feb 6 10:50:33 2008 Subject: [Haskell-cafe] Re: Data.Ord and Heaps (Was: Why functional programming matters) In-Reply-To: <47A7005C.8030404@tu-bs.de> References: <288B9431-ADC3-46D3-97F4-6A219388E015@quantentunnel.de> <47A7005C.8030404@tu-bs.de> Message-ID: Stephan Friedrichs wrote: > I'm sorry it took me so long to respond! No worries :) >>>> In conclusion: the ordering policy stuff should not be part of >>>> Data.Heap, this is a job for Data.Ord. >>> This sounds really useful. How about you propose >>> this to the base-package maintainers? :) >> >> What, me? :D > > Where? :) Proposals for the base package go to libraries@haskell.org . A proposal is a darcs patch + a deadline. Unfortunately, ghc 6.8.* isn't yet available on Macports, I'd have to install 6.6.1 again on my wiped disk to get a haskell compiler and darcs. I'm currently leaning towards code like data OrdBy p a = OrdBy { unOrdBy :: a } instance Eq a => Eq (OrdBy p a) where (==) = (==) `on` unOrdBy data Reverse type Reversed a = OrdBy Reverse a instance Ord a => Ord (OrdBy Reverse a) where compare = flip $ comparing unOrdBy and probably another example for custom orderings. Do you now a good one? I'm not so happy about the names. In particular, I don't like unOrdBy , too much cAmelCase. Any other ideas? Maybe data Rearrange p a = Rearrange { unRearrange :: a } data ReOrd p a = ReOrd { unReOrd :: a } But I guess it can't be helped and it's not too bad either. The class constraint Ord (OrdBy p a) => will be common in user code, but it's a bit bulky for my taste. However, its main problem is that it's not Haskell98 :( A multi-parameter class (just like in the original heap-0.1) class OrdPolicy p a where ... instance OrdPolicy p a => Ord (OrdBy p a) where ... is shorter but not H98 either. The name could be a mot juste, too. class Rearranged p a where ... class Ord' p a where ... class OrdBy p a where ... -- clashes with the name of the type Regards, apfelmus From lemming at henning-thielemann.de Wed Feb 6 11:07:02 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 11:05:58 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: <6dbd4d000802060739v7fa03b9epbf347e300c652869@mail.gmail.com> References: <200802061158.02285.matthew.pocock@ncl.ac.uk> <6dbd4d000802060611r7d54329fx978843c8897ede52@mail.gmail.com> <6dbd4d000802060732j46ca6420g465bf767e17eb08a@mail.gmail.com> <6dbd4d000802060739v7fa03b9epbf347e300c652869@mail.gmail.com> Message-ID: On Wed, 6 Feb 2008, Denis Bueno wrote: > On Feb 6, 2008 10:36 AM, Henning Thielemann > wrote: > > > type SomethingWithKV k a = KV {getKV :: (k, a)} > > > instance Buildable (Map k a) (SomethingWithKV k a) where > > > empty = Map.empty > > > insert s m = uncurry Map.insert (getKV s) m > > > > > > I have done this before -- it's very convenient, and I think makes the > > > code that uses empty and insert more robust, and easier to read. > > > > But why do you want to have the special type SomethingWithKV, but not > > MapSomething ? > > Do you mean a map that maps SomethingWithKV to whatever, instead of k to v? I mean a Map that is specialised for storing SomethingWithKV instead of plain pairs. (If I imagine a Map as a list of pairs that is optimized for efficiency.) From jeff1.61803 at gmail.com Wed Feb 6 11:24:25 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Wed Feb 6 11:23:27 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> Message-ID: <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> On Feb 6, 2008 1:18 AM, Jonathan Cast wrote: > On 5 Feb 2008, at 10:14 PM, Jeff ? wrote: > > > > On Feb 5, 2008 4:58 PM, Chadda? Fouch? wrote: > > > 2008/2/5, Jeff ? : > > > This is interesting. I've been programming in Concurrent Clean for a > > while. > > > Instead of monads, Clean supports unique types for mutable arrays and > > IO. > > > In Clean, I can write code that iterates through a mutable array by > > > converting it to a lazy list. This is convenient because I can use > > all the > > > nice list processing functions that are available. > > > > > > > You could absolutely write something like that in Haskell, but as some > > have pointed out, this is probably _not a Good Idea_, even though it > > works in your particular case, the array could be modified between the > > time you get the lazy list and the time you actually read it... And > > there's no way to insure it's not happening in Haskell, and I strongly > > doubt there is in Concurrent Clean, could you confirm ? > > > Concurrent Clean can handle this in a safe way. Here's a code snippet > for normalize_2D_ary from ArrayTest.icl: > > uToList_2D :: *(a u:(b c)) -> (.[c],*(a u:(b c))) | Array a (b c) & Array > b c > map_in_place_2d_arr :: (a -> a) *(b *(c a)) -> *(b *(c a)) | Array b (c a) > & Array c a > normalize_2D_ary :: *(a *(b c)) -> *(a *(b c)) | Array a (b c) & Array b c > & / c & Ord c > normalize_2D_ary ary = > let (lst,ary2) = uToList_2D ary > max_elem = foldl1 max lst > in map_in_place_2d_arr (\ x -> x / max_elem) ary2 > uToList_2D takes a unique array, ary, and returns a tuple containing a > list of the array elements and a "new" array, ary2. uToList_2D does not > modify ary, but Clean's type system forces any function that accesses a > unique array to thread the array through and return a "new" array. Under > the hood the "new" array actually uses the same memory storage as the > original array. So, it is effecient. Threading the array serializes access > insuring the array won't be modified until the list is complete. > > > I'm confused --- does uToList_2D return the head of the list before or > after it finishes reading the array? If before, then I don't see how the > type system prevents me from modifying the array before I finish examining > the list, as you claim. If after, then the list isn't truly lazy. > uToList_2D can return the head of the list before it finishes reading the array. I could modify the code so that it is ambiguous whether the array is modified before the list processing is finished. normalize_2D_ary ary = let (lst,ary2) = uToList_2D ary max_elem = foldl1 max lst in map_in_place_2d_arr (\ x -> x / max_elem) ary // I changed ary2 to ary However, the type system will generate an error with this code because ary is no longer unique because it is referenced in two expressions. Clean produces this error message: Uniqueness error [ArrayTest.icl,55,normalize_2D_ary]: "ary" demanded attribute cannot be offered by shared object I should mention that a problem with the code I've shown is that it is very sensitive to the order in which the expression graph is evaluated. Simple changes can cause lst to become strict and the program to run out of heap. By the way, Clean has it's share of rough edges. The reason I'm hanging out on Haskell-Cafe is because I'm trying to get away from those rough edges. But, I am missing Clean's uniqueness types. I'm starting to see Haskell's unsafe functions as a blunt work around that could be fixed elegantly and safely by implementing uniqueness types. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080206/e66ca3eb/attachment.htm From dons at galois.com Wed Feb 6 11:33:59 2008 From: dons at galois.com (Don Stewart) Date: Wed Feb 6 11:33:05 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> Message-ID: <20080206163359.GA29074@scytale.galois.com> jeff1.61803: > On Feb 6, 2008 1:18 AM, Jonathan Cast <[1]jonathanccast@fastmail.fm> > wrote: > > On 5 Feb 2008, at 10:14 PM, Jeff I* wrote: > > On Feb 5, 2008 4:58 PM, ChaddaA- FouchA(c) > <[2]chaddai.fouche@gmail.com> wrote: > > 2008/2/5, Jeff I* <[3]jeff1.61803@gmail.com>: > > This is interesting. I've been programming in Concurrent Clean > for a while. > > Instead of monads, Clean supports unique types for mutable arrays > and IO. > > In Clean, I can write code that iterates through a mutable array > by > > converting it to a lazy list. This is convenient because I can > use all the > > nice list processing functions that are available. > > > > You could absolutely write something like that in Haskell, but as > some > have pointed out, this is probably _not a Good Idea_, even though it > works in your particular case, the array could be modified between > the > time you get the lazy list and the time you actually read it... And > there's no way to insure it's not happening in Haskell, and I > strongly > doubt there is in Concurrent Clean, could you confirm ? > > Concurrent Clean can handle this in a safe way. Here's a code snippet > for normalize_2D_ary from ArrayTest.icl: > > uToList_2D :: *(a u:(b c)) -> (.[c],*(a u:(b c))) | Array a (b c) & > Array b c > map_in_place_2d_arr :: (a -> a) *(b *(c a)) -> *(b *(c a)) | Array b > (c a) & Array c a > normalize_2D_ary :: *(a *(b c)) -> *(a *(b c)) | Array a (b c) & Array > b c & / c & Ord c > normalize_2D_ary ary = > let (lst,ary2) = uToList_2D ary > max_elem = foldl1 max lst > in map_in_place_2d_arr (\ x -> x / max_elem) ary2 > uToList_2D takes a unique array, ary, and returns a tuple containing a > list of the array elements and a "new" array, ary2. uToList_2D does > not modify ary, but Clean's type system forces any function that > accesses a unique array to thread the array through and return a "new" > array. Under the hood the "new" array actually uses the same memory > storage as the original array. So, it is effecient. Threading the > array serializes access insuring the array won't be modified until > the list is complete. > > I'm confused --- does uToList_2D return the head of the list before or > after it finishes reading the array? If before, then I don't see how > the type system prevents me from modifying the array before I finish > examining the list, as you claim. If after, then the list isn't truly > lazy. > > > uToList_2D can return the head of the list before it finishes reading the > array. I could modify the code so that it is ambiguous whether the array > is modified before the list processing is finished. > > normalize_2D_ary ary = > let (lst,ary2) = uToList_2D ary > max_elem = foldl1 max lst > in map_in_place_2d_arr (\ x -> x / max_elem) ary // I changed ary2 > to ary > > However, the type system will generate an error with this code because > ary is no longer unique because it is referenced in two expressions. > Clean produces this error message: > > Uniqueness error [ArrayTest.icl,55,normalize_2D_ary]: "ary" demanded > attribute cannot be offered by shared object > > I should mention that a problem with the code I've shown is that it is > very sensitive to the order in which the expression graph is evaluated. > Simple changes can cause lst to become strict and the program to run out > of heap. > By the way, Clean has it's share of rough edges. The reason I'm hanging > out on Haskell-Cafe is because I'm trying to get away from those rough > edges. But, I am missing Clean's uniqueness types. I'm starting to > see Haskell's unsafe functions as a blunt work around that could be fixed > elegantly and safely by implementing uniqueness types. That's a reasonable critique : its hard to enforce uniqueness, in the type system in Haskell, -- I'd be interesting to see approaches that avoid extending the compiler. -- Don From bf3 at telenet.be Wed Feb 6 12:12:57 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Wed Feb 6 12:11:54 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <20080206163359.GA29074@scytale.galois.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> Message-ID: <00b801c868e3$8550d070$8ff27150$@be> > That's a reasonable critique : its hard to enforce uniqueness, in the > type system in Haskell, -- I'd be interesting to see approaches that > avoid extending the compiler. Isn't the compiler already "modified" in a way to deal with the RealWorld type that is used in the IO monad? Surely the RealWorld is unique... Regards, Peter Verswyvelen From allbery at ece.cmu.edu Wed Feb 6 12:23:02 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Feb 6 12:22:02 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <00b801c868e3$8550d070$8ff27150$@be> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> Message-ID: On Feb 6, 2008, at 12:12 , Peter Verswyvelen wrote: >> That's a reasonable critique : its hard to enforce uniqueness, in the >> type system in Haskell, -- I'd be interesting to see approaches that >> avoid extending the compiler. > > Isn't the compiler already "modified" in a way to deal with the > RealWorld > type that is used in the IO monad? Surely the RealWorld is unique... You might want to look at the definition of unsafePerformIO before asserting that. -- 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 allbery at ece.cmu.edu Wed Feb 6 12:25:11 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed Feb 6 12:24:12 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> Message-ID: On Feb 6, 2008, at 12:23 , Brandon S. Allbery KF8NH wrote: > You might want to look at the definition of unsafePerformIO before > asserting that. On second thought I think I haven't had enough sleep to claim anything of the sort with any confidence. -- 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 ndmitchell at gmail.com Wed Feb 6 12:25:18 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Feb 6 12:24:19 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <00b801c868e3$8550d070$8ff27150$@be> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> Message-ID: <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> Hi > Isn't the compiler already "modified" in a way to deal with the RealWorld > type that is used in the IO monad? Surely the RealWorld is unique... No. The monad and the primitive operations ensure it is unique, the IO monad is abstracted away properly, and it all works neatly so you can't violate the uniqueness. However, the realWorld thing is not actually unique, for example unsafeInterleaveIO and unsafePerformIO violate this. Thanks Neil From bf3 at telenet.be Wed Feb 6 12:45:16 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Wed Feb 6 12:44:13 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> Message-ID: <00ba01c868e8$08eb5140$1ac1f3c0$@be> Yeah, I also believed that, but then I'm confused: Don Stewart wrote: > That's a reasonable critique : its hard to enforce uniqueness, in the type system in Haskell, -- I'd be interesting to see approaches that avoid extending the compiler. Neil Mitchell wrote: > No. The monad and the primitive operations ensure it is unique, the IO > monad is abstracted away properly, and it all works neatly so you > can't violate the uniqueness. So monads *do* enforce uniqueness... So what is the difference between Haskell's monad approach and Clean's uniqueness typing? I always thought these were just two different ways to tackle the same problem, and I had the feeling Haskell's approach was actually more general. Thanks, Peter > -----Original Message----- > From: Neil Mitchell [mailto:ndmitchell@gmail.com] > Sent: Wednesday, February 06, 2008 6:25 PM > To: Peter Verswyvelen > Cc: Don Stewart; Jeff ?; haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Mutable arrays > > Hi > > > Isn't the compiler already "modified" in a way to deal with the > RealWorld > > type that is used in the IO monad? Surely the RealWorld is unique... > > No. The monad and the primitive operations ensure it is unique, the IO > monad is abstracted away properly, and it all works neatly so you > can't violate the uniqueness. However, the realWorld thing is not > actually unique, for example unsafeInterleaveIO and unsafePerformIO > violate this. > > Thanks > > Neil > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.20/1261 - Release Date: > 2/5/2008 8:57 PM From chris.casinghino at gmail.com Wed Feb 6 12:59:25 2008 From: chris.casinghino at gmail.com (Chris Casinghino) Date: Wed Feb 6 12:58:26 2008 Subject: [Haskell-cafe] Re: weird ghci behavior with gadts and existentials In-Reply-To: <47A9A6ED.9060904@list.mightyreason.com> References: <47A9A6ED.9060904@list.mightyreason.com> Message-ID: On Feb 6, 2008 7:24 AM, ChrisK wrote: > Let me add: > > > data ExpGADT t where > > ExpInt :: Int -> ExpGADT Int > > ExpChar :: Char -> ExpGADT Char > > Which type do you think 'unHide' and 'wierd' should have: > > > unHide h = case h of > > Hidden (_,e) -> e > > > > wierd = unHide (Hidden (TyInt,ExpInt 3)) I agree that unHide, as written, can't be typechecked, because the existential variable escapes - without the GADT pattern match on TyInt, t never gets refined. The addition of ExpChar has nothing to do with this, though - if we replace the underscore with TyInt as before, the function should still typecheck as: HiddenTypeExp -> ExpGADT Int At least, assuming my reasoning was right in the first message. Now, with the addition of ExpChar we may have a runtime error when using this function, but it doesn't change the type of these things, and I'm still stuck trying to figure out if my example before is a bug of if I misunderstand something. Haskell doesn't have good coverage checking for GADT cases, and even if it did adding ExpChar would probably only cause a warning. It's certainly an interesting case to think about though, in terms of how existentials and gadts interact. --Chris > Chris Casinghino wrote: > > Hi all, > > > > I've been playing a bit with gadts and existentials lately, and I > > have an example where I don't quite understand the behavior of > > ghc. The expression in question typechecks sometimes in some > > versions of ghc, depending on where you write it, and not in > > other versions. Some other people I've asked report not getting > > any errors, even when using apparently one of the same versions > > of ghc I checked. > > > > If I create a file which contains: > > > >> data TypeGADT t where > >> TyInt :: TypeGADT Int > >> > >> data ExpGADT t where > >> ExpInt :: Int -> ExpGADT Int > >> > >> data HiddenTypeExp = forall t . Hidden (TypeGADT t, ExpGADT t) > >> > >> weird = case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e > > > > I am able to :load it into ghci just fine (with -fglasgow-exts) > > with version 6.8.2. However, if I then copy the line: > > > > let weird2 = case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e > > > > into ghci, I get a type error. In the HEAD version 6.9, I get a > > type error on the definition of "weird" right away when I :load > > the file. The type error goes away if I add the line > > > >> weird :: ExpGADT Int > > > > before the definition of weird. > > > > The type error in question is this: > > > > :1:46: > > Inferred type is less polymorphic than expected > > Quantified type variable `t' escapes > > When checking an existential match that binds > > e :: ExpGADT t > > The pattern(s) have type(s): HiddenTypeExp > > The body has type: ExpGADT t > > In a case alternative: Hidden (TyInt, e) -> e > > In the expression: > > case Hidden (TyInt, ExpInt 3) of Hidden (TyInt, e) -> e > > > > So, several questions. > > > > 1) Why the discrepancy in behavior between ":load"ing the file and > > copying in the definition in 6.8.2. It seems like, one way or the > > other, this should be consistent. > > > > 2) Several other people report not getting any errors at all, even > > people with ghc 6.8.2, one of the versions I tested. What's the > > "right" behavior? My guess would be that this should cause no > > type error, even without the type annotation. The GADT pattern > > match against "TyInt" in the case statement should refine the > > existential type variable t to Int, so no existential type > > variables are escaping. Is that right? > > > > 3) Is there a bug here? Are there two bugs (one, the typing error, > > two, the difference between ghc and ghci)? Or, do I just not > > understand what is going on? > > > > Sorry for the length of this email! > > > > --Chris Casinghino > > From alfonso.acosta at gmail.com Wed Feb 6 13:03:55 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Feb 6 13:02:57 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <8b2a1a960802051932s17965fcapf7f53274e170b15d@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> <8b2a1a960802051129y2a666898mc842780411627516@mail.gmail.com> <6a7c66fc0802051203p22276101ledf4f87353a7bddc@mail.gmail.com> <8b2a1a960802051932s17965fcapf7f53274e170b15d@mail.gmail.com> Message-ID: <6a7c66fc0802061003q511bb8e0v13a35ab1f9c601a1@mail.gmail.com> On Feb 6, 2008 4:32 AM, Bjorn Buckwalter wrote: > Well, could you elaborate a little on joining efforts? The effort I > was planning to invest in my package consists mainly of creating a > .cabal file plus some logistics to get tarballs to where they have to > be. > > I understand that you (and Wolfgang) are creating a library of type > level decimals for the purpose of constraining vector (list?) lengths. > After that I haven't been paying attention fully to the thread. Is the > goal to create a general-purpose library for type-level programming > and my module would fit into that grander scheme? Yes,the idea is to create a Cabal-ready wide-scope type-level programming library, joining the operations implemented in the different type-level libraries which are around. The goal (or at least mine) is to provide a common reusable type-level library which saves constantly reinventing the wheel. I'll provide an initial implementation (just including naturals in decimal representation) soon. Wolfgang suggested adding booleans at a later point too if I recall properly. Any useful type-level operation should have a place in the library. > Or did you have something else in mind with joining efforts? E.g. help > reviewing your code or writing new code? > This would certainly help too. From dons at galois.com Wed Feb 6 13:15:05 2008 From: dons at galois.com (Don Stewart) Date: Wed Feb 6 13:14:09 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <00b801c868e3$8550d070$8ff27150$@be> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> Message-ID: <20080206181505.GA2091@scytale.galois.com> bf3: > > That's a reasonable critique : its hard to enforce uniqueness, in the > > type system in Haskell, -- I'd be interesting to see approaches that > > avoid extending the compiler. > > Isn't the compiler already "modified" in a way to deal with the RealWorld > type that is used in the IO monad? Surely the RealWorld is unique... Yep, its an unforgable, strict kinded value. Sometimes I find it would be nice to have user defined versions of these guys. -- Don From catamorphism at gmail.com Wed Feb 6 13:27:36 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Wed Feb 6 13:26:38 2008 Subject: [Haskell-cafe] Re: [Haskell] Extensible records: Static duck typing In-Reply-To: <705A37EC-3F77-4210-A73D-FAC40AE5278E@ntlworld.com> References: <965491992.20080205132858@gmail.com> <8087A09F-3DA5-449A-A6DE-FEE67B177B10@ntlworld.com> <3d96ac180802050421x2795f633o48b4bbe2f336a851@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3183270FCF6@EA-EXMSG-C334.europe.corp.microsoft.com> <705A37EC-3F77-4210-A73D-FAC40AE5278E@ntlworld.com> Message-ID: <4683d9370802061027g111c6292q675b79901afd95f4@mail.gmail.com> [redirecting to haskell-cafe] On 2/6/08, Barney Hilken wrote: > This is what I was trying to do with the wiki page. I stopped because > the only other contributor decided he could no longer contribute, and > I felt I was talking to myself. If we want to be rational about the > design, we need real examples to demonstrate what is genuinely useful, > and I don't have that many of them. It's obvious that records are a language feature that people besides just you care about. And so everybody would benefit from your effort if you chose to continue adding more examples to the wiki page. Records clearly seem to be an important issue if so many people have replied to your thread, and your comment expressing frustration at "arbitrary decisions" getting made about design seems to suggest you have some passion about the issue. On the other hand, if you can't think of real examples offhand, and no one else can either, maybe it's not that important... (Examples don't have to be very complicated to be useful, by the way. Simpler is better.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "If pots couldn't call kettles black, there'd be a lot less talking going on." -- Larissa Ranbom From jeff1.61803 at gmail.com Wed Feb 6 14:20:42 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Wed Feb 6 14:19:42 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <00ba01c868e8$08eb5140$1ac1f3c0$@be> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> Message-ID: <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> On 2/6/08, Peter Verswyvelen wrote: > Yeah, I also believed that, but then I'm confused: > > So monads *do* enforce uniqueness... So what is the difference between > Haskell's monad approach and Clean's uniqueness typing? I always thought > these were just two different ways to tackle the same problem, and I had > the > feeling Haskell's approach was actually more general. IO and mutable array monads could be implemented on top of Clean's unique arrays and world objects. So, I'd argue that Clean is at least as general as Haskell. On the other hand, I've posted two similar problems to this list. In Haskell I want to . . . 1) turn a mutable array into a lazy list 2) turn the contents of a file into a lazy list The responses I've received are typically: 1) Use unsafeFreeze / unsafeThaw 2) Use hGetContents. (which uses unsafePeformIO under the hood.) 3) Don't use a lazy list. Rewrite the code to break the data up into smaller chunks and process the chunks in a loop. I have solved both of these problems in Clean using a lazy list without resorting to unsafe operations. So, it seems to me that uniqueness types are more general than monads. By the way, I'm not good enough to use unsafe functions. My code would crash for sure. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080206/063a27d3/attachment.htm From rendel at rbg.informatik.tu-darmstadt.de Wed Feb 6 14:27:03 2008 From: rendel at rbg.informatik.tu-darmstadt.de (Tillmann Rendel) Date: Wed Feb 6 14:26:16 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> Message-ID: <47AA0A07.7030606@rbg.informatik.tu-darmstadt.de> Bas van Dijk wrote: > The following obviously doesn't work: > > import Control.Monad.Error > > inv :: MonadError e m => m a -> m () > inv m = (m >> fail "") `catchError` \_ -> (return ()) What about this? inv :: MonadError e m => m a -> m () inv m = join $ (m >> return mzero) `catchError` \_ -> return (return ()) Tillmann From g9ks157k at acme.softbase.org Wed Feb 6 14:37:52 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Feb 6 14:36:58 2008 Subject: [Haskell-cafe] classes for data structures In-Reply-To: <47A9CE70.4060206@jellybean.co.uk> References: <200802061158.02285.matthew.pocock@ncl.ac.uk> <47A9CE70.4060206@jellybean.co.uk> Message-ID: <200802062037.52374.g9ks157k@acme.softbase.org> Am Mittwoch, 6. Februar 2008 16:12 schrieb Jules Bean: > And indeed there *will* be a Monad, if there is a sensible way of > defining concat :: b (b a) -> b a, which there probably is. Not with sets. ?concat? on Set would have type Ord a => Set (Set a) -> Set a instead of Set (Set a) -> Set a. Best wishes, Wolfgang From dons at galois.com Wed Feb 6 14:55:35 2008 From: dons at galois.com (Don Stewart) Date: Wed Feb 6 14:54:38 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> References: <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> Message-ID: <20080206195535.GA8444@scytale.galois.com> jeff1.61803: > On 2/6/08, Peter Verswyvelen <[1]bf3@telenet.be> wrote: > > Yeah, I also believed that, but then I'm confused: > > So monads *do* enforce uniqueness... So what is the difference between > Haskell's monad approach and Clean's uniqueness typing? I always thought > these were just two different ways to tackle the same problem, and I had > the > feeling Haskell's approach was actually more general. > > > IO and mutable array monads could be implemented on top of Clean's unique > arrays and world objects. So, I'd argue that Clean is at least as general > as Haskell. > > On the other hand, I've posted two similar problems to this list. In > Haskell I want to . . . > > 1) turn a mutable array into a lazy list > 2) turn the contents of a file into a lazy list > > The responses I've received are typically: > > 1) Use unsafeFreeze / unsafeThaw > 2) Use hGetContents. (which uses unsafePeformIO under the hood.) > 3) Don't use a lazy list. Rewrite the code to break the data up into > smaller chunks and process the chunks in a loop. > > I have solved both of these problems in Clean using a lazy list without > resorting to unsafe operations. So, it seems to me that uniqueness types > are more general than monads. They solve a specific issue in the type system that goes statically unchecked. Monads are a separate issue (and kind of a non-sequitor here). Uniquness doesn't give you more than the IO monad. From chaddai.fouche at gmail.com Wed Feb 6 14:56:00 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Wed Feb 6 14:55:01 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> Message-ID: 2008/2/6, Jeff ? : > I have solved both of these problems in Clean using a lazy list without > resorting to unsafe operations. So, it seems to me that uniqueness types > are more general than monads. Are you aware that your code in Clean has some issues, like the lst not being so lazy if you operate on ary2 before you operate on lst (it is completely put in memory in this case) ? You've effectively created a big uncertainty on the space taken by your function. Is this ok with you ? The monadic fold (like I and some others proposed) guarantee you a constant amount of memory consumed and is perfectly safe too, is the Clean solution really so much better ? Jonathan Cast : > I'm confused --- does uToList_2D return the head of the list before or after it finishes reading > the array? If before, then I don't see how the type system prevents me from modifying the > array before I finish examining the list, as you claim. If after, then the list isn't truly lazy. What happens here is that the array can't be modified without evaluating ary2 and ary2 can't be evaluated without completely evaluating the list before, so you effectively get the list lazily as long as you don't touch ary2 before touching the list, and you can't damage the list by modifying the array (because in this case, lst would be completely evaluated in the first place). You can do the same in Haskell in fact, but you'll need to discipline yourself to evaluate the "witness" before modifying the array. So uniqueness here seems to have an advantage over monads, still, the monads look much cleaner (sic) than Clean code with all those unique value passing around... -- Jeda? From bf3 at telenet.be Wed Feb 6 15:45:43 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Wed Feb 6 15:44:42 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> Message-ID: <000001c86901$3e25fd60$ba71f820$@be> I see. Unfortunately I did not spent enough time playing with Clean, and I'm still learning Haskell, so I can't give any feedback on your questions J Now from the little time I've spent in the company of Clean, I must say there's another advantage of uniqueness typing: it is very easy to understand. While monads are a tiny bit more demanding! But monads give such a mental satisfaction once you see the light ;-) So you say uniqueness typing might be more general. Can one make list monads and all the other funky Haskell monads with Clean's uniqueness typing then? Peter From: Jeff ? [mailto:jeff1.61803@gmail.com] Sent: woensdag 6 februari 2008 20:21 To: Peter Verswyvelen; Neil Mitchell; Don Stewart Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Mutable arrays On 2/6/08, Peter Verswyvelen wrote: Yeah, I also believed that, but then I'm confused: So monads *do* enforce uniqueness... So what is the difference between Haskell's monad approach and Clean's uniqueness typing? I always thought these were just two different ways to tackle the same problem, and I had the feeling Haskell's approach was actually more general. IO and mutable array monads could be implemented on top of Clean's unique arrays and world objects. So, I'd argue that Clean is at least as general as Haskell. On the other hand, I've posted two similar problems to this list. In Haskell I want to . . . 1) turn a mutable array into a lazy list 2) turn the contents of a file into a lazy list The responses I've received are typically: 1) Use unsafeFreeze / unsafeThaw 2) Use hGetContents. (which uses unsafePeformIO under the hood.) 3) Don't use a lazy list. Rewrite the code to break the data up into smaller chunks and process the chunks in a loop. I have solved both of these problems in Clean using a lazy list without resorting to unsafe operations. So, it seems to me that uniqueness types are more general than monads. By the way, I'm not good enough to use unsafe functions. My code would crash for sure. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080206/b4156ccd/attachment.htm From Andrew.Butterfield at cs.tcd.ie Wed Feb 6 15:57:43 2008 From: Andrew.Butterfield at cs.tcd.ie (Andrew Butterfield) Date: Wed Feb 6 15:56:47 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <00ba01c868e8$08eb5140$1ac1f3c0$@be> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7ca3f0160802020326p62bff99eg2b3c8abd0b033857@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> Message-ID: <47AA1F47.7050501@cs.tcd.ie> Peter Verswyvelen wrote: > So monads *do* enforce uniqueness... So what is the difference between > Haskell's monad approach and Clean's uniqueness typing? I always thought > these were just two different ways to tackle the same problem, and I had the > feeling Haskell's approach was actually more general. Yes (1), and no (2). ! Long pedantic post follows (1) They are two different ways to tackle the same problem: how to have I/O in a pure functional language when I/O neccessarily requires the "world state" to be destructively updated (e.g. we can't copy the entire filesystem, or the (truly) global internet state). The solution is based on the following observation: imagine we a have a large datastructure (e.g. big tree) and a function that updates it, then, *in general*, pure functional semantics requires the implementation to return a copy of its argument with the update applied, leaving the original argumment intact. However, if in a given program, we know that the old value of the big structure is never referenced once the function is applied, then we can *implement* the function application "under the hood" as a true destructive update, without breaking the pure referential semantics of the language. Such a use of a structure in a program is said to "single-threaded". For example, the program f (g (h bigThing)) makes single-threaded use of bigThing, so *in this program*, we could implement f, g and h using destructive update without altering the outcome as predicted by a copy semantics. However, the program (bigThing,h bigThing) does not have a single-threaded use of bigThing, so h *must* be implemented using copying, because we have access to both values. The upshot of all of this is that a program that restricts itself to single-threaded use of a (large) structure can use a desctructive implementation, so if we can ensure that our patterns of I/O access are single-threaded, then we can: - implement I/O as we must, i.e with destructive update - yet still maintain the "illusion" that our program is pure (copying). What's the catch? Well, in general, the question of wether or not a given structure's use is single-threaded, is undecidable. So what we have are two (partial) solutions: Clean's uniqueness types, and Haskell's monads. Let us assume that the entire I/O state is captured by a variable world :: World "Invent-and-Verify": Clean allows you to write a program that explicity mentions world, and the uses the type-system to check that accesses to world are single-threaded. Essentially the destructive functions have type annotations that insist their World arguments and results are singly-threaded (a.k.a. "unique"). So program writefile "a.dat" "Text A" (writefile "b.dat" "Text B" world) typechecks, but program (world,writefile "b.dat" "Text B" world) doesn't. Because of undecidability, the type-checker is not totally accurate, but behaves conservatively, so may report a program as ill-typed, even if it is actually single-threaded, but will always spot a program that is truly bad - not single-threaded. "Correctness-by-Construction": Haskell approaches the problem by hiding the world inside an abstract data-type called a monad. Haskell programs do not mention the world explicitly at all. The monad, with its return, bind and basic monadic I/O operations is setup so that the hidden world state is always accessed in a single-threaded fashion,so the underlying implementation is free to use desctructive update. So we can write a monadic form of the first program above, as do writefile "b.dat" "Text B" writefile "a.dat" "Text A" We cannot begin to express the second (ill-typed) program at all ! (2) Leaving aside the fact that the monad concept is more general than just I/O (Maybe monad, List monad, etc..), we can state categorically that as far as I/O is concerned, that Clean's uniqueness type approach is more general than Haskell's monads, i.e.: - any Haskell monad-IO program can be re-written as a correctly typed Clean IO program (simply "implement" the IO monad as a state monad over a state world :: World). - not all Clean IO programs can be directly written in monadic style. The issue has to do with the fact that the IO monad "over-sequences" IO actions, because the monad encapsulates the entire world in one lump. (see slides 37/38 of http://research.microsoft.com/~simonpj/papers/haskell-retrospective/HaskellRetrospective.pdf). So if we have two functions, one, f1 :: IO (), reading from file "f1.in" and writing to "f1.out", and the other, f2 :: IO () reading from "f2.in" and writing to "f2.out", we must decide as programmers what order to use - either do{ f1 ; f2 } or do { f2; f1 }. If we generalise to f1 .. fn, we have to sequence these, which is why the function in Haskell of type [IO a] -> IO [a], is called "sequence". In Clean, we not only have explicit access to the world, but we can partition it. Simplifying somewhat, we could open up pairs of file-handle (f1.in,f1.out), (f2.in,f2,out) ... (fn.in,fn.out), which does have to be done sequentially, since each file opening modifies the (global) filesystem. However, once this is done, we could, in principle, execute the fn in any order, and indeed in such a way that the implementation could choose to do them in parallel - this potential for (admittedly limited) deterministic parallel execution of I/O actions is possible with uniqueness types, but not epxressible in the monadic world as currently formulated. (3) Shameless plug : a semantics for I/O that covers both Clean and Haskell and which scopes out the "deterministic parallelism" alluded to above was described in Malcolm Dowse, Andrew Butterfield: Modelling deterministic concurrent I/O. ICFP 2006: 148-159 http://doi.acm.org/10.1145/1159803.1159823 -- -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. Department of Computer Science, Room F.13, O'Reilly Institute, Trinity College, University of Dublin, Ireland. http://www.cs.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- From bulat.ziganshin at gmail.com Wed Feb 6 12:39:31 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 6 16:02:53 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> Message-ID: <1252070813.20080206203931@gmail.com> Hello Henning, Wednesday, February 6, 2008, 6:09:28 PM, you wrote: >> it's another question: you can describe trivial values using type >> system, but can't prohibit them using it - it's impossible because you >> can't check for arbitrary algorithm whether it will be finally stopped > I could consider the function buggy, if it does not terminate on the given > example. it's impossible to check for *arbitrary* function call whether it will be terminated. seems that you don't have formal CS education? :) so one can develop set of functions that are guaranteed to be terminated or guaranteed to be non-trivial. but it's impossible to check for arbitrary function whether it's trivial and even whether it will terminate for particular data this means that answer to original question - one can ensure that argument for filter is non-terminating function only if these functions are written using some special notation which doesn't allow to write arbitrary turing-complete algorithms -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From Andrew.Butterfield at cs.tcd.ie Wed Feb 6 16:06:14 2008 From: Andrew.Butterfield at cs.tcd.ie (Andrew Butterfield) Date: Wed Feb 6 16:05:16 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <000001c86901$3e25fd60$ba71f820$@be> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> <000001c86901$3e25fd60$ba71f820$@be> Message-ID: <47AA2146.2010407@cs.tcd.ie> Peter Verswyvelen wrote: > So you say uniqueness typing might be more general? Can one make list > monads and all the other funky Haskell monads with Clean?s uniqueness > typing then? As my long post pointed out - as far IO is concerned, Clean is more general than Haskell (less over-sequencing). However in a general setting, monads are very general, much more so than Clean's I/O uniqueness types. Monads capture a fundamental pattern of sequential side-effecting computation in a pure referentially transparent way - IO is just a specific instance of this. Having said that, it's worth noting that list and maybe monads can be introduced in Clean, but these would have nothing to do with the I/O infrastructure in that language. -- -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. Department of Computer Science, Room F.13, O'Reilly Institute, Trinity College, University of Dublin, Ireland. http://www.cs.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- From bertram.felgenhauer at googlemail.com Wed Feb 6 16:23:43 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Wed Feb 6 16:22:48 2008 Subject: [Haskell-cafe] Why is this so inefficient? In-Reply-To: <4165d3a70802051007l2aa4c44ex2032b08fd05f2323@mail.gmail.com> References: <4165d3a70802051007l2aa4c44ex2032b08fd05f2323@mail.gmail.com> Message-ID: <20080206212343.GA4278@zombie.inf.tu-dresden.de> Jefferson Heard wrote: > I thought this was fairly straightforward, but where the marked line > finishes in 0.31 seconds on my machine, the actual transpose takes > more than 5 minutes. I know it must be possible to read data in [snip] > dataFromFile :: String -> IO (M.Map String [S.ByteString]) > dataFromFile filename = do > f <- S.readFile filename > print . length . map (S.split ',' $!) . S.lines $ f > -- finishes in 0.31 seconds The S.split applications will never be evaluated - the list that you produce is full of thunks of the form (S.split ',' $! ) The $! will only take effect if those thunks are forced, and length doesn't do that. Try print . sum . map (length . S.split ',') . S.lines $ f instead, to force S.split to produce a result. (In fact, S.split is strict in its second argument, so the $! shouldn't have any effect on the running time at all. I didn't measure that though.) > return . transposeCSV . map (S.split ',' $!) . S.lines $ f -- > this takes 5 minutes and 6 seconds HTH, Bertram From lemming at henning-thielemann.de Wed Feb 6 16:29:02 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 16:27:59 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <1252070813.20080206203931@gmail.com> References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> <1252070813.20080206203931@gmail.com> Message-ID: On Wed, 6 Feb 2008, Bulat Ziganshin wrote: > Hello Henning, > > Wednesday, February 6, 2008, 6:09:28 PM, you wrote: > > >> it's another question: you can describe trivial values using type > >> system, but can't prohibit them using it - it's impossible because you > >> can't check for arbitrary algorithm whether it will be finally stopped > > > I could consider the function buggy, if it does not terminate on the given > > example. > > it's impossible to check for *arbitrary* function call whether it will be > terminated. seems that you don't have formal CS education? :) > > so one can develop set of functions that are guaranteed to be > terminated or guaranteed to be non-trivial. but it's impossible to > check for arbitrary function whether it's trivial and even whether it > will terminate for particular data If the type checker does not terminate because the checked function does not terminate on the example input, then the function does not pass the type check and as a compromise this would be ok. From lemming at henning-thielemann.de Wed Feb 6 16:45:42 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 6 16:44:38 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <20080205154433.GA1566@cs.cmu.edu> References: <20080205154433.GA1566@cs.cmu.edu> Message-ID: On Tue, 5 Feb 2008, Dan Licata wrote: > [CC'ed to the agda mailing list as well] > > On Feb05, Henning Thielemann wrote: > > > > Is Haskell's type system including extensions strong enough for describing > > a function, that does not always return a trivial value? E.g. > > (filter (\x -> x==1 && x==2)) > > will always compute an empty list. Using an appropriate signature for > > the function it shall be rejected at compile time, because it is probably > > a mistake - probably (filter (\x -> x==1 || x==2) xs) was meant. I assume > > that the type must contain somehow an example input for which the function > > value is non-trivial. If Haskell's type system is not strong enough, what > > about dependently typed languages like Cayenne or Epigram? (I know, > > theorem provers have no problem with such types.) > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > You can definitely do this with dependent types. Here's a way to do it > in Agda 2: Thanks for your detailed answer! I don't fully understand the Agda code, but I record that there is another system which allows such kind of types. Now, 'filter' was a particular example where the type constraint can be reformulated as constraint on the element test 'f'. However there might be a composed function like stupidFilter = filter odd . map (2*) I assume that Agda lets me forbid such functions by properly designed types, too. From v.dijk.bas at gmail.com Wed Feb 6 16:47:33 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Feb 6 16:46:30 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: <47AA0A07.7030606@rbg.informatik.tu-darmstadt.de> References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> <47AA0A07.7030606@rbg.informatik.tu-darmstadt.de> Message-ID: On Feb 6, 2008 8:27 PM, Tillmann Rendel wrote: > What about this? > > inv :: MonadError e m => m a -> m () > inv m = join $ (m >> return mzero) `catchError` \_ -> return (return ()) Beautiful! That's the one I'm looking for! I was already defining a 'MonadInvert' class and a bunch of instances like below but this is a much more flexible solution. ------------------------------------------------------------------------------------------------- -- | A Monad that supports inversion. -- Turning success into failure and failure into success. class Monad m => MonadInvert m where -- | @invert m@ fails when @m@ is successfull (returns a value) -- and returns @()@ when @m@ fails . invert :: m a -> m () instance MonadInvert Maybe where invert Nothing = Just () invert (Just _) = Nothing instance MonadInvert [] where invert [] = [()] invert (_:_) = [] instance E.Error e => MonadInvert (Either e) where invert (Left _) = Right () invert (Right _) = Left E.noMsg instance (E.Error e, MonadInvert m) => MonadInvert (E.ErrorT e m) where invert = T.lift . invert . E.runErrorT instance MonadInvert m => MonadInvert (S.StateT st m) where invert m = S.StateT $ \s -> (invert $ S.runStateT m s) >>= \u -> return (u, s) ... ------------------------------------------------------------------------------------------------- Thanks very much. Bas From matthew.pocock at ncl.ac.uk Wed Feb 6 16:54:11 2008 From: matthew.pocock at ncl.ac.uk (Matthew Pocock) Date: Wed Feb 6 16:53:05 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: <1252070813.20080206203931@gmail.com> Message-ID: <200802062154.11609.matthew.pocock@ncl.ac.uk> On Wednesday 06 February 2008, Henning Thielemann wrote: > If the type checker does not terminate because the checked function does > not terminate on the example input, then the function does not pass the > type check and as a compromise this would be ok. Can't fault this logic. The problem is that you may have to wait quite a long time to discover this non-termination. Matthew From stefanor at cox.net Wed Feb 6 17:11:23 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Feb 6 17:10:23 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <47AA1F47.7050501@cs.tcd.ie> References: <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <47AA1F47.7050501@cs.tcd.ie> Message-ID: <20080206221123.GA4083@localhost.localdomain> On Wed, Feb 06, 2008 at 08:57:43PM +0000, Andrew Butterfield wrote: > In Clean, we not only have explicit access to the world, but > we can partition it. Simplifying somewhat, we could open up > pairs of file-handle (f1.in,f1.out), (f2.in,f2,out) ... (fn.in,fn.out), > which does have to be done sequentially, since each file opening modifies > the (global) filesystem. However, once this is done, > we could, in principle, execute the fn in any order, > and indeed in such a way that the implementation could choose to > do them in parallel - this potential for (admittedly limited) > deterministic parallel execution of I/O actions is possible with > uniqueness types, but not epxressible in the monadic world as > currently formulated. What if f1.out is a symlink to f2.out? I don't think Clean satisfies the evaluation order independance that is so treasured here. 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/20080206/e8322060/attachment.bin From jeff1.61803 at gmail.com Wed Feb 6 17:31:59 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Wed Feb 6 17:30:56 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> Message-ID: <7665bf90802061431g13512fe1o7eee72bf5a793f53@mail.gmail.com> On 2/6/08, Chadda? Fouch? wrote: > > 2008/2/6, Jeff ? : > > I have solved both of these problems in Clean using a lazy list without > > resorting to unsafe operations. So, it seems to me that uniqueness > types > > are more general than monads. > > Are you aware that your code in Clean has some issues, like the lst > not being so lazy if you operate on ary2 before you operate on lst (it > is completely put in memory in this case) ? You've effectively created > a big uncertainty on the space taken by your function. Is this ok with > you ? Yes, I'm aware of this. In a previous post, I wrote, "I should mention that a problem with the code I've shown is that it is very sensitive to the order in which the expression graph is evaluated. Simple changes can cause lst to become strict and the program to run out of heap." However, I think your description of this issue is much more succinct than mine. I'm not sure, but I _think_ this problem can be solved using Clean's strict let-before notation. normalize_2D_ary ary = # (lst,ary) = uToList_2D ary #! max_elem = foldl1 max lst // max_elem is strict -- lst is consumed. = map_in_place_2d_arr (\ x -> x / max_elem) ary > The monadic fold (like I and some others proposed) guarantee you > a constant amount of memory consumed and is perfectly safe too, is the > Clean solution really so much better ? > I'm looking forward to spending a few free hours this weekend playing with the monadic fold code. I've written a lot of image processing code in Clean that treats images as lists of RGBA tuples. It's a very useful abstraction. But, I've spent more time than I care to admit fixing unexpected stack and heap overflows that were caused by seemingly unrelated code change. I hope to find other abstractions that aren't so fragile. Peter Verswyvelen wrote: > Now from the little time I've spent in the company of Clean, I must say > there's another advantage of uniqueness typing: it is very easy to > understand. While monads are a tiny bit more demanding! But monads give such > a mental satisfaction once you see the light ;-) > For me, the light is a faint distant flicker. I hope to see it clearer someday. At the risk of starting a flame war, being labeled a troll, having Godwin's law invoked, and suffering a life time ban from Haskell-Cafe, I'd like to broach another subject. I noticed that GHC implements mutable arrays in the IO monad. This seems odd to me. Arrays aren't related to IO. Are there obstacles to mixing code that uses IO monads and array monads that are most easily worked around by sticking mutable arrays into the IO monad? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080206/8adbdfc4/attachment.htm From g9ks157k at acme.softbase.org Wed Feb 6 18:01:48 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Feb 6 18:00:55 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <1252070813.20080206203931@gmail.com> References: <1252070813.20080206203931@gmail.com> Message-ID: <200802070001.48662.g9ks157k@acme.softbase.org> Am Mittwoch, 6. Februar 2008 18:39 schrieb Bulat Ziganshin: > [?] > this means that answer to original question - one can ensure that > argument for filter is non-terminating function only if these > functions are written using some special notation which doesn't allow > to write arbitrary turing-complete algorithms And this is exactly what Agda, Epigram, Coq, etc. do. Note however that those systems are not very restrictive. It?s possible, for example, to define Ackermann?s function in Agda: > module Ackermann where > > data Nat : Set where > > O : Nat > > ?_ : Nat -> Nat > > ackermann : Nat -> Nat -> Nat > ackermann O m = ? m > ackermann (? n) O = ackermann n (? O) > ackermann (? n) (? m) = ackermann n (ackermann (? n) m) Best wishes, Wolfgang From ajb at spamcop.net Wed Feb 6 18:20:13 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Feb 6 18:19:10 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: <2E9274F5-A1C2-4921-8F3B-1B3793D21847@yandex.ru> Message-ID: <20080206182013.6mlw6kc44c0o0488@webmail.spamcop.net> G'day all. On Feb 6, 2008 12:45 PM, Felipe Lessa wrote: >> I guess your parser is a monad transformer, so *maybe* the solution >> is to require MonadError from the inner monad. Quoting Bas van Dijk : > Indeed my parser 'P t m a' is a monad transformer. I will try out > requiring 'm' to have a 'MonadError' constraint and see how far I come > with that. I've occasionally found this useful: class (Monad m) => MonadNegate m where mtrue :: m () mfalse :: m () mnot :: m a -> m () mtrue = return () mfalse = fail "False" Cheers, Andrew Bromage From daniel.is.fischer at web.de Wed Feb 6 18:37:15 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Wed Feb 6 18:34:42 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802061431g13512fe1o7eee72bf5a793f53@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802061431g13512fe1o7eee72bf5a793f53@mail.gmail.com> Message-ID: <200802070037.15755.daniel.is.fischer@web.de> Am Mittwoch, 6. Februar 2008 23:31 schrieb Jeff ?: > > At the risk of starting a flame war, being labeled a troll, having Godwin's > law invoked, and suffering a life time ban from Haskell-Cafe, I'd like to > broach another subject. I noticed that GHC implements mutable arrays in > the IO monad. This seems odd to me. Arrays aren't related to IO. Are > there obstacles to mixing code that uses IO monads and array monads that > are most easily worked around by sticking mutable arrays into the IO monad? IO(U)Arrays are only one variant of mutable Array, there are also ST(U)Arrays, which are often preferred. From drl at cs.cmu.edu Wed Feb 6 19:25:45 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Wed Feb 6 19:24:47 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: <20080205154433.GA1566@cs.cmu.edu> Message-ID: <20080207002545.GB10247@cs.cmu.edu> On Feb06, Henning Thielemann wrote: > > On Tue, 5 Feb 2008, Dan Licata wrote: > > On Feb05, Henning Thielemann wrote: > > > > > > Is Haskell's type system including extensions strong enough for describing > > > a function, that does not always return a trivial value? E.g. > > > (filter (\x -> x==1 && x==2)) > > > will always compute an empty list. Using an appropriate signature for > > > the function it shall be rejected at compile time, because it is probably > > > a mistake - probably (filter (\x -> x==1 || x==2) xs) was meant. I assume > > > that the type must contain somehow an example input for which the function > > > value is non-trivial. If Haskell's type system is not strong enough, what > > > about dependently typed languages like Cayenne or Epigram? (I know, > > > theorem provers have no problem with such types.) > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > You can definitely do this with dependent types. Here's a way to do it > > in Agda 2: > > Thanks for your detailed answer! I don't fully understand the Agda code, > but I record that there is another system which allows such kind of types. > Now, 'filter' was a particular example where the type constraint can be > reformulated as constraint on the element test 'f'. However there might > be a composed function like > stupidFilter = filter odd . map (2*) > I assume that Agda lets me forbid such functions by properly designed > types, too. > I think what you want to say now is not just (filter f l) is type correct when there is some argument on which f returns true but (filter f l) is type correct when there is some *element of l* on which f returns true Here is one way to say this with dependent types: data SatBy {A : Set} : (A -> Bool) -> List A -> Set where Here : {f : A -> Bool} {x : A} {xs : List A} -> Check (f x) -> SatBy f (x :: xs) There : {f : A -> Bool} {x : A} {xs : List A} -> SatBy f xs -> SatBy f (x :: xs) fancyfilter2 : {A : Set} (f : A -> Bool) (l : List A) -> SatBy f l -> List A fancyfilter2 f l _ = stdfilter f l The idea is that SatBy f l proves that there is some element of l on which (f x) is true. 'Here' says that this is true if (f x) is true on the head of the list; 'There' says that this is true of (x :: xs) if it's true of xs. Of course, now to call fancyfilter2, you need to prove this property of your f and your l. You won't be able to do this for 'odd' and 'map (2*) x', but you would be able to do this for, e.g., 'even' and 'map (2*) xs where xs is non-nil'. -Dan From ndmitchell at gmail.com Wed Feb 6 19:35:53 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Feb 6 19:34:50 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <20080207002545.GB10247@cs.cmu.edu> References: <20080205154433.GA1566@cs.cmu.edu> <20080207002545.GB10247@cs.cmu.edu> Message-ID: <404396ef0802061635l6d846239j7ff1011a269eb81@mail.gmail.com> Hi > I think what you want to say now is not just > > (filter f l) is type correct when there is some argument on which f > returns true > > but > > (filter f l) is type correct when there is some *element of l* on > which f returns true or in Haskell: filterNonEmpty f x = assert (not $ null res) res where res = filter f x If you give that definition to the Catch tool (http://www-users.cs.york.ac.uk/~ndm/catch/) it will try and prove each call is safe. For certain examples, Catch will do the job very well - for example if your filter is something structural like isJust or null. Thanks Neil From v.dijk.bas at gmail.com Wed Feb 6 19:44:42 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed Feb 6 19:43:37 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <1201929342.5496.112.camel@derek-laptop> References: <1201929342.5496.112.camel@derek-laptop> Message-ID: Probably a weird idea but could this be useful? class (Monad m) => Stream s m t | s -> t where uncons :: s -> m (m (t,s)) for example: instance (Monad m) => Stream [t] m t where uncons [] = return $ fail "uncons []" uncons (t:ts) = return $ return (t,ts) One small advantage is that Streams can have custom error messages when there's no input. Also, using 'uncons' could be as simple as: 'join . uncons'. Bas On Feb 2, 2008 6:15 AM, Derek Elkins wrote: > [Now with 100% more correct darcs get URLs.] > > I'm currently getting Paolo Martini's Google Summer of Code project, an > updated version of Parsec, into a releasable state, and I will be > maintaining it for at least a while. > > Paolo's major additions are: > * The Parser monad has been generalized into a Parser monad > transformer > * The parsers have been generalized to work over a stream of any > type, in particular, with bytestrings. > > I have made a few minor additions as well: > * There is Haddock documentation for almost all functions > * The Parser monad now has Applicative/Alternative instances > > Currently, I am looking for people to give it a go reporting any bugs in > the library or documentation, troubles building it, or changes/features > they would like. I'm also interested in performance information. > > Most old Parsec code should be relatively easy but not trivial to port. > There is a darcs repository on code.haskell.org. If nothing comes up, > I'll put a package on Hackage in about a week or so. > > To get the code: > darcs get http://code.haskell.org/parsec3 > > To build it, the standard cabal commands should work: > http://haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package > > Alternatively, you can use the cabal-install application: > http://hackage.haskell.org/trac/hackage/wiki/CabalInstall > > The documentation can be generated also via the normal cabal routine, or > via cabal-install. > > The Text.Parsec modules should be preferred to the > Text.ParserCombinators.Parsec modules. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From drl at cs.cmu.edu Wed Feb 6 20:04:03 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Wed Feb 6 20:03:02 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <1252070813.20080206203931@gmail.com> References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> <1252070813.20080206203931@gmail.com> Message-ID: <20080207010403.GC10247@cs.cmu.edu> Let's be careful here: decidability is only relevant if you want to *automatically* prove calls to filter correct. It is certainly possible to give a type system/specification logic for reasoning about all functions written in a Turing-complete language (e.g., all Haskell functions). In such a type system/logic, you will be able to prove that particular functions have particular results (e.g., "that function f over there maps 4 to true"). If you give filter the type/specification that Henning wants, you may not be able to get a computer to automatically validate all "correct" calls to filter, where "correct" means that I can prove, in the specification logic, that the predicate is satisfiable. However, you can get a computer to validate some calls to filter, and a human may be able to validate others by hand. I.e., it's not necessary to restrict the class of functions you consider if you're willing to give up on full automation. So I disagree with the "only if" below. -Dan On Feb06, Bulat Ziganshin wrote: > Hello Henning, > > Wednesday, February 6, 2008, 6:09:28 PM, you wrote: > > >> it's another question: you can describe trivial values using type > >> system, but can't prohibit them using it - it's impossible because you > >> can't check for arbitrary algorithm whether it will be finally stopped > > > I could consider the function buggy, if it does not terminate on the given > > example. > > it's impossible to check for *arbitrary* function call whether it will be > terminated. seems that you don't have formal CS education? :) > > so one can develop set of functions that are guaranteed to be > terminated or guaranteed to be non-trivial. but it's impossible to > check for arbitrary function whether it's trivial and even whether it > will terminate for particular data > > this means that answer to original question - one can ensure that > argument for filter is non-terminating function only if these > functions are written using some special notation which doesn't allow > to write arbitrary turing-complete algorithms > From jeff1.61803 at gmail.com Wed Feb 6 20:17:27 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Wed Feb 6 20:16:23 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <200802070037.15755.daniel.is.fischer@web.de> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802061431g13512fe1o7eee72bf5a793f53@mail.gmail.com> <200802070037.15755.daniel.is.fischer@web.de> Message-ID: <7665bf90802061717y50b3d557oe7c91615b26fb8c6@mail.gmail.com> > > IO(U)Arrays are only one variant of mutable Array, there are also > ST(U)Arrays, > which are often preferred. > I should have worded my question better. The MArray interface is implemented in both the ST and IO monad. A state monad seems like a logical place for mutable arrays. However, I don't understand the motivation for implementing it in IO. Were mutable arrays added to IO because it would be difficult to write code that does both IO and manipulates arrays otherwise? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080206/89fd69c1/attachment.htm From bjorn.buckwalter at gmail.com Wed Feb 6 20:30:32 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Wed Feb 6 20:29:28 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802061003q511bb8e0v13a35ab1f9c601a1@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> <8b2a1a960802051129y2a666898mc842780411627516@mail.gmail.com> <6a7c66fc0802051203p22276101ledf4f87353a7bddc@mail.gmail.com> <8b2a1a960802051932s17965fcapf7f53274e170b15d@mail.gmail.com> <6a7c66fc0802061003q511bb8e0v13a35ab1f9c601a1@mail.gmail.com> Message-ID: <8b2a1a960802061730m558f9a77te4c9647ff06c1b4@mail.gmail.com> On Feb 6, 2008 1:03 PM, Alfonso Acosta wrote: > On Feb 6, 2008 4:32 AM, Bjorn Buckwalter wrote: > > I understand that you (and Wolfgang) are creating a library of type > > level decimals for the purpose of constraining vector (list?) lengths. > > After that I haven't been paying attention fully to the thread. Is the > > goal to create a general-purpose library for type-level programming > > and my module would fit into that grander scheme? > > Yes,the idea is to create a Cabal-ready wide-scope type-level > programming library, joining the operations implemented in the > different type-level libraries which are around. The goal (or at least > mine) is to provide a common reusable type-level library which saves > constantly reinventing the wheel. Ok. Is this what people want -- one big hold-all library with everything, as opposed to smaller more specialized packages? I guess I can see advantages (real or perceived) to both approaches. The other library I use for type-level programming is HList. It has type-level booleans already so you might what to take a look at it if you're not already familiar with it. In fact, if you are serious about creating the de facto(?) type-level programming library trying to get Oleg involved would be very beneficial both in terms of innovation and credibility. > > Or did you have something else in mind with joining efforts? E.g. help > > reviewing your code or writing new code? > > > > This would certainly help too. I'm sure it would. ;) I didn't mean to imply that I have plenty of spare time to invest in this but I'll certainly be paying attention when you start releasing code. Thanks, Bjorn From alfonso.acosta at gmail.com Wed Feb 6 20:47:39 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Feb 6 20:46:35 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <8b2a1a960802061730m558f9a77te4c9647ff06c1b4@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> <8b2a1a960802051129y2a666898mc842780411627516@mail.gmail.com> <6a7c66fc0802051203p22276101ledf4f87353a7bddc@mail.gmail.com> <8b2a1a960802051932s17965fcapf7f53274e170b15d@mail.gmail.com> <6a7c66fc0802061003q511bb8e0v13a35ab1f9c601a1@mail.gmail.com> <8b2a1a960802061730m558f9a77te4c9647ff06c1b4@mail.gmail.com> Message-ID: <6a7c66fc0802061747s1713da91v9083396f381a657c@mail.gmail.com> On Feb 7, 2008 2:30 AM, Bjorn Buckwalter wrote: > Ok. Is this what people want -- one big hold-all library with > everything, as opposed to smaller more specialized packages? I guess I > can see advantages (real or perceived) to both approaches. Apart from Dockins' typenats library there are no other user-friendly specific type-level libraries that know, so I cannot really tell if people would prefer a hold-all library or a couple of more granular specialized ones. Right now is not hold-all at all (it is still vaporware actually :)), so I think there's no reason to discuss that at this point. Let's see what people think. > The other library I use for type-level programming is HList. It has > type-level booleans already so you might what to take a look at it if > you're not already familiar with it. Thanks I'll have a look at it. > In fact, if you are serious about > creating the de facto(?) type-level programming library trying to get > Oleg involved would be very beneficial both in terms of innovation and > credibility. Sure. I've actually been exchanging mail with Oleg. He has given me some useful suggestions and contributed with some code. He didn't mention to what point he wanted to get involved though, but I'm sure he will try to help. From jonathanccast at fastmail.fm Wed Feb 6 20:50:12 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 6 20:49:17 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <200802062154.11609.matthew.pocock@ncl.ac.uk> References: <1252070813.20080206203931@gmail.com> <200802062154.11609.matthew.pocock@ncl.ac.uk> Message-ID: <252F2727-29F0-4D8D-8AD6-BFE4793A117D@fastmail.fm> On 6 Feb 2008, at 1:54 PM, Matthew Pocock wrote: > On Wednesday 06 February 2008, Henning Thielemann wrote: > >> If the type checker does not terminate because the checked >> function does >> not terminate on the example input, then the function does not >> pass the >> type check and as a compromise this would be ok. > > Can't fault this logic. The problem is that you may have to wait > quite a long > time to discover this non-termination. I would second this --- letting the compiler go only to discover that it's been running for the last 3 hours because it's diverging seems like a wasted 3 hours. jcc From jonathanccast at fastmail.fm Wed Feb 6 21:05:23 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 6 21:04:28 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> Message-ID: <8BA6F54F-9C25-49BE-8DD4-0F54812D9B63@fastmail.fm> On 6 Feb 2008, at 11:56 AM, Chadda? Fouch? wrote: > 2008/2/6, Jeff ? : >> I have solved both of these problems in Clean using a lazy list >> without >> resorting to unsafe operations. So, it seems to me that >> uniqueness types >> are more general than monads. > > Are you aware that your code in Clean has some issues, like the lst > not being so lazy if you operate on ary2 before you operate on lst (it > is completely put in memory in this case) ? You've effectively created > a big uncertainty on the space taken by your function. Is this ok with > you ? The monadic fold (like I and some others proposed) guarantee you > a constant amount of memory consumed and is perfectly safe too, is the > Clean solution really so much better ? > > Jonathan Cast : >> I'm confused --- does uToList_2D return the head of the list >> before or after it finishes reading >> the array? If before, then I don't see how the type system >> prevents me from modifying the >> array before I finish examining the list, as you claim. If after, >> then the list isn't truly lazy. > > What happens here is that the array can't be modified without > evaluating ary2 and ary2 can't be evaluated without completely > evaluating the list before, I see. I would agree that Clean's system is more powerful (and concomitantly more dangerous) in this case. > so you effectively get the list lazily as > long as you don't touch ary2 before touching the list, and you can't > damage the list by modifying the array (because in this case, lst > would be completely evaluated in the first place). You can do the same > in Haskell in fact, but you'll need to discipline yourself to evaluate > the "witness" before modifying the array. > > > So uniqueness here seems to have an advantage over monads, True. > still, the > monads look much cleaner (sic) Some might argue this. > than Clean code with all those unique > value passing around... The same thing could be implemented in Haskell, of course: data MySafeArray a i e = MSA{ touchThisFirst :: IORef (), realArray :: a i e } instance MArray a e IO => MArray (MySafeArray a) e IO where unsafeRead a i = do x <- readIORef $ touchThisFirst a eval x touchThisFirst a `writeIORef` () unsafeRead $ realArray a Then your getContents looks like this: getArrayElems a = do x <- readIORef $ touchThisFirst a eval x ls <- touchThisFirst a `writeIORef` deepSeq ls return ls Ugly, but it can be encapsulated in a library somewhere. jcc From jonathanccast at fastmail.fm Wed Feb 6 21:16:24 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 6 21:15:30 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802061717y50b3d557oe7c91615b26fb8c6@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802061431g13512fe1o7eee72bf5a793f53@mail.gmail.com> <200802070037.15755.daniel.is.fischer@web.de> <7665bf90802061717y50b3d557oe7c91615b26fb8c6@mail.gmail.com> Message-ID: <66E934F6-AF7D-4F3D-87A0-0C81DBFED5FB@fastmail.fm> On 6 Feb 2008, at 5:17 PM, Jeff ? wrote: > IO(U)Arrays are only one variant of mutable Array, there are also ST > (U)Arrays, > which are often preferred. > > I should have worded my question better. The MArray interface is > implemented in both the ST and IO monad. A state monad seems like > a logical place for mutable arrays. However, I don't understand > the motivation for implementing it in IO. Were mutable arrays > added to IO because it would be difficult to write code that does > both IO and manipulates arrays otherwise? Yes. As I understand it, the reasons are roughly as follows: (a) The ST monad is a fairly clever hack, and is some years (4 or 5?) younger than IO. (b) You can't have an ST-mutable array as a global variable, but you can do this with IO. It's ugly, but some libraries are rumored to require it (see the discussion in http://haskell.org/haskellwiki/ Top_level_mutable_state). (c) In particular, libraries that need to do I/O and/or FFI are rumored to be particularly in need of top-level mutable state, so it's natural to combine the two (or three). (d) It's very difficult to combine monads. Clean's uniqueness types / can/ be combined (as could arbitrary state monads). In general, IMHO what you normally want when combining monads is their coproduct. A general coproduct is quite ugly, but it simplifies nicely in particular cases. Clean, by restricting the problem to combining uniqueness-type-based state monads, can combine monads more easily than Haskell can in the general case. 15 years ago, when these decisions were made, it seemed easier to have a single monad. (e) To a certain extent, IO is the monad in Haskell for `everything other languages can do that we can't'. That's just the nature of the beast; the name IO is simply taken from the most prominent example. So IO's mandate is to do everything C can do better. (f) Some of use consider the IO monad (and mutable arrays in general) deprecated for precisely this reason; the rest seem to want C with a nicer syntax. They use IO, we try to avoid it entirely. jcc From uhollerbach at gmail.com Wed Feb 6 22:30:12 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Wed Feb 6 22:29:09 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <1495211458.20080206123008@gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> <1495211458.20080206123008@gmail.com> Message-ID: <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> Hi, all, thanks for the responses. I understand the distinction between pure functions and impure functions/procedures/IO actions, it just felt to me in the samples that I quoted that I was in fact starting from basically the starting point, eventually getting to the same endpoint (or at least a pair of endpoints that are not easily distinguished from each other by looking just at code), and inbetween one path was going through liftIO and the other not. But I guess it comes down to the fact that, since I'm in a REPL, I'm wallowing in impurity all the time (or something like that :-) ) regards, Uwe On 2/6/08, Bulat Ziganshin wrote: > Hello Uwe, > > Wednesday, February 6, 2008, 7:44:27 AM, you wrote: > > > But after that, it sure seems to me as if I've taken data out of the > > IO monad... > > this means that you can't use results of IO actions in pure functions. > your code works in some transformed version of IO monad, so you don't > escaped it > > if we call pure functions as "functions" and non-pure ones as > "procedures", the rule is "functions can't call procedures", but all > other activity is possible. in your do_action you calls procedure (to > format current time) and call a function (to format given time). > do_action is procedure (because it works in transformed IO monad), so > you don't break any rules > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > From jonathanccast at fastmail.fm Wed Feb 6 22:42:18 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 6 22:41:24 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> <1495211458.20080206123008@gmail.com> <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> Message-ID: <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> On 6 Feb 2008, at 7:30 PM, Uwe Hollerbach wrote: > Hi, all, thanks for the responses. I understand the distinction > between pure functions and impure functions/procedures/IO actions, Um, I'm not sure of that, given what you go on to say. > it > just felt to me in the samples that I quoted that I was in fact > starting from basically the starting point, Not really. The key difference to understand is that between difference between getCurrentTime and toUTCTime 42. These are your `starting points' --- the rest is just pure code. > eventually getting to the > same endpoint (or at least a pair of endpoints that are not easily > distinguished from each other by looking just at code), and inbetween Well, the in-between paths are pure (or can be) either way. It's the starting point that needs liftIO or not. > one path was going through liftIO and the other not. But I guess it > comes down to the fact that, since I'm in a REPL, I'm wallowing in > impurity all the time (or something like that :-) ) jcc From dave at zednenem.com Wed Feb 6 22:58:52 2008 From: dave at zednenem.com (David Menendez) Date: Wed Feb 6 22:57:49 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: References: Message-ID: <49a77b7a0802061958q3b1c9bat783c1e3815585b50@mail.gmail.com> On Feb 6, 2008 6:32 AM, Bas van Dijk wrote: > Is there a way to 'invert' an arbitrary Monad? > > By 'inverting' I mean to turn success into failure and failure into > success. Here are some specific inversions of the Maybe and List > Monad: > > invM :: Maybe a -> Maybe () > invM Nothing = Just () > invM (Just _) = Nothing > > invL :: [] a -> [] () > invL [] = [()] > invL (_:_) = [] > > > How can I define this for an arbitrary Monad m? If you're doing any kind of backtracking or non-determinism, you might consider the msplit operation defined in "Backtracking, Interleaving, and Terminating Monad Transformers" . Essentially, this defines a class of monads with zero, plus, and a split operation: class (MonadPlus m) => MonadSplit m where msplit :: m a -> m (Maybe (a, m a)) Essentially, if 'm' returns no results, then 'msplit m' returns Nothing, otherwise it returns Just (a, m'), where a is the first result, and m' is a computation which produces the remaining results (if any). There is an obvious implementation for the list monad, but msplit can also be defined for a monad transformer. There are a bunch of useful operations using msplit, such as the "soft cut", ifte :: (MonadSplit m) => m a -> (a -> m b) -> m b -> m b ifte p th el = msplit p >>= maybe el (\(a,m) -> th a `mplus` (m >>= th)) 'ifte p th el' is equivalent to 'p >>= th' if p returns any results, and 'el' otherwise. Note that it is *not* the same as (p >>= th) `mplus` el. Here's your inverse operation: mnot :: (MonadSplit m) => m a -> m () mnot m = msplit m >>= maybe (return ()) mzero -- Dave Menendez From uhollerbach at gmail.com Wed Feb 6 23:13:02 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Wed Feb 6 23:11:59 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> <1495211458.20080206123008@gmail.com> <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> Message-ID: <65d7a7e0802062013v6e5bb434tba68c1cd30f524ae@mail.gmail.com> Well, you may well be right! Just think of me as a planarian at the opera... :-) On 2/6/08, Jonathan Cast wrote: > On 6 Feb 2008, at 7:30 PM, Uwe Hollerbach wrote: > > > Hi, all, thanks for the responses. I understand the distinction > > between pure functions and impure functions/procedures/IO actions, > > Um, I'm not sure of that, given what you go on to say. > > > it > > just felt to me in the samples that I quoted that I was in fact > > starting from basically the starting point, > > Not really. The key difference to understand is that between > difference between getCurrentTime and toUTCTime 42. These are your > `starting points' --- the rest is just pure code. > > > eventually getting to the > > same endpoint (or at least a pair of endpoints that are not easily > > distinguished from each other by looking just at code), and inbetween > > Well, the in-between paths are pure (or can be) either way. It's the > starting point that needs liftIO or not. > > > one path was going through liftIO and the other not. But I guess it > > comes down to the fact that, since I'm in a REPL, I'm wallowing in > > impurity all the time (or something like that :-) ) > > jcc > > From bayer at cpw.math.columbia.edu Wed Feb 6 23:29:38 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Wed Feb 6 23:28:34 2008 Subject: [Haskell-cafe] Best practice for embedding files in a GHC-compiled tool? Message-ID: <9FA3427A-DC2B-4D81-9A7D-7D2765F86990@math.columbia.edu> What is the best way to embed an arbitrary file in a Haskell program? I would like to use GHC to compile command-line tools to be used with OS X. I want the tool to be a single file, not a package or a directory, that makes no assumptions about what else is present. For example, it should be able to run as part of an OS X install disk. I want this tool to be "self reproducing" in the sense that one of its options causes it to output its own documentation and source code. I want this data to be stored as a compressed file within the tool binary itself. The distribution model I'm imagining here is where one writes a program anonymously, that isn't hosted anywhere but is passed from user to user because it is useful, and eventually reaches another user who wants to modify the code. Assume that intermediate users will care less about this, and will try to delete anything that they can. That rules out storing the data in a separate file. Think of the M.I.T. game "Core Wars" from the dawn of the computer age. I'm looking for a strategy here that will be evolutionarily successful in a fairly hostile environment. In other words, I want to be able to write in Haskell, without losing the automatic distribution of source code enjoyed by interpreted languages. No one deletes the source code for a Perl script, because by doing so they're killing the program. There must be some library I'm overlooking that would make this very easy. All I can think of is to use Template Haskell to read a compressed tar file into a Haskell variable. Is that what one does, or is there a better way? Thanks in advance, Dave From dekudekuplex at yahoo.com Thu Feb 7 00:36:23 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Thu Feb 7 00:35:19 2008 Subject: [Haskell-cafe] FP and Quality In-Reply-To: <7.0.1.0.0.20080204235058.01d00a98@ntlworld.com> Message-ID: <792941.88805.qm@web30208.mail.mud.yahoo.com> How about the following papers on real-world Haskell programming results: ----- text follows immediately after this line ----- Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity (1994), by Paul Hudak and Mark P. Jones: http://citeseer.ist.psu.edu/41732.html Why Functional Programming Matters (1984), by John Hughes: http://www.md.chalmers.se/~rjmh/Papers/whyfp.html Why Haskell matters (date unknown) (Web page), originally by Sebastian Sylvan: http://www.haskell.org/haskellwiki/Why_Haskell_matters ----- text ends immediately before this line ----- The following resource page may also be useful: Haskell in industry: http://www.haskell.org/haskellwiki/Haskell_in_industry The following site may also be useful: Commercial Users of Functional Programming: Functional Programming As a Means, Not an End: http://cufp.galois.com/ Barring time constraints, I may post additional findings later. Benjamin L. Russell --- PR Stanley wrote: > Thanks, keep the tips coming. I like the ones about > the type safety > and line counts. > Cheers, > Paul > At 23:33 04/02/2008, you wrote: > >Good luck with this - I'd love to see the outcome. > > > >My experience is that FP tends to result in a lot > less code, so if > >there are x > >bugs per line of code, FP has less bugs per > complete application. > > > >Talking about haskell, the typesystem dissalows > whole classes of bugs. Things > >simply do not compile if you stitch the innards > together in the wrong order > >(particuarly if you are agressive about using the > most general types > >possible). Since this accounts for perhaps 90% of > where I do things wrong in > >Java, I get a corresponding decrease in run-time > bugs in haskell. However, > >this is somewhat compensated for by the effort > needed to get haskell programs > >through the compiler in the first place - debug at > compile or debug at > >runtime is the tradeoff here. > > > >FP is easier to verify mechanically than imperative > programming - more of the > >logic is exposed directly. It's easier to do > by-case proofs, even if they are > >by-hand rather than mechanical. > > > >However, all of this is annecdotal. Good luck > collecting real stats, or > >peer-reviewed annecdotes. You may have luck looking > at bug-fix times vs > >number of developers for equivalent FP and Java > apps/libs. Worth a shot, > >given that the bug-trackers tend to be public. You > could probably tie it back > >to the size of the 'fix' patches. Get some nice > graphs? > > > >Matthew > > > >On Monday 04 February 2008, you wrote: > > > Hi folks > > > I'm thinking of writing a little essay arguing > the case for the > > > advantages of FP for producing quality software. > Can the list > > > recommend any papers/articles which I can use as > sources of my > > > argument? I have access to the IEEE database too > although earlier I > > > couldn't find anything on the subject. > > > Thanks, Paul > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe@haskell.org > > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From trebla at vex.net Thu Feb 7 01:14:39 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu Feb 7 01:13:39 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <1201929342.5496.112.camel@derek-laptop> References: <1201929342.5496.112.camel@derek-laptop> Message-ID: <47AAA1CF.5040106@vex.net> Is it good or bad to add: instance (MonadIO m) => MonadIO (ParsecT s u m) From uhollerbach at gmail.com Thu Feb 7 02:32:17 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Thu Feb 7 02:31:12 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> <1495211458.20080206123008@gmail.com> <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> Message-ID: <65d7a7e0802062332q4131363ey6503bf75b996e54f@mail.gmail.com> All right, after a bit of dinner and some time to mess about, here's another attempt to check my understanding: here is a simplified version of the lisp-time example: > module Main where > import System.Time > > pure_fn :: Integer -> String > pure_fn n = calendarTimeToString (toUTCTime (TOD n 0)) > > wicked_fn :: IO String > wicked_fn = getClockTime >>= return . pure_fn . toI > where toI (TOD n _) = n > > make_wicked :: String -> IO String > make_wicked str = return str > > -- use of pure_fn > -- main = putStrLn (pure_fn 1230000000) > > -- use of wicked_fn > -- main = wicked_fn >>= putStrLn > > -- use of make_wicked > main = (make_wicked (pure_fn 1234567890)) >>= putStrLn If I use the first of the three "main" alternatives, I'm calling a pure function directly: it takes an integer, 123..., and produces a string. If I pass the same integer to the pure function, I'll get the same value, every time. This string is passed to putStrLn, an IO action, in order that I may gaze upon it, but the string itself is not thereby stuck in the IO monad. If I use the second of the three "main" alternatives, I'm calling an IO action: wicked_fn, which returns the current time formatted as UTC. In principle, every time I call wicked_fn, I could get a different answer. Because it's an IO action, I can't just pass it to putStrLn in the same way I passed in the previous pure_fn value, but instead I have to use the bind operator >>=. If I use the third of the "main" alternatives, I am starting with a pure function: it's that number formatted as UTC (it happens to come to Fri Feb 13 of next year), but then I pass it through the make_wicked function, which transmogrifies it into the IO monad. Therefore, as in the above, I have to use >>= in order to get it to work; "putStrLn (make_wicked (pure_fn 123...))" doesn't work. OK, after all that, my original question, in terms of this example: "the IO monad is one-way" is equivalent to saying there is no haskell function that I could write that would take > (make_wicked (pure_fn 123456)) and make it into something that could be used in the same way and the same places as just plain > (pure_fn 123456) ? And, coming back to my scheme interpreter, this is at least somewhat irrelevant, because, since I am in a REPL of my own devising, I'm firmly in IO-monad-land, now and forever. Right? thanks, Uwe From lrpalmer at gmail.com Thu Feb 7 02:38:56 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Feb 7 02:37:55 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <65d7a7e0802062332q4131363ey6503bf75b996e54f@mail.gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> <1495211458.20080206123008@gmail.com> <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> <65d7a7e0802062332q4131363ey6503bf75b996e54f@mail.gmail.com> Message-ID: <7ca3f0160802062338x13edd3bagd36199903293ff98@mail.gmail.com> On Feb 7, 2008 7:32 AM, Uwe Hollerbach wrote: > > pure_fn :: Integer -> String > > pure_fn n = calendarTimeToString (toUTCTime (TOD n 0)) > > > > make_wicked :: String -> IO String > > make_wicked str = return str > > > > -- use of make_wicked > > main = (make_wicked (pure_fn 1234567890)) >>= putStrLn > > OK, after all that, my original question, in terms of this example: > "the IO monad is one-way" is equivalent to saying there is no haskell > function that I could write that would take > > > (make_wicked (pure_fn 123456)) > > and make it into something that could be used in the same way and the > same places as just plain > > > (pure_fn 123456) > > ? Spot on! Luke From leandrodemarco at gmail.com Thu Feb 7 02:58:10 2008 From: leandrodemarco at gmail.com (Leandro Demarco Vedelago) Date: Thu Feb 7 02:57:11 2008 Subject: [Haskell-cafe] problem with collection (container) class Message-ID: <15c02dff0802062358g632cea57ifc7eeaee3aa1f587@mail.gmail.com> Hi! I'm pretty (not to say very) new to haskell and i've to create a new class named container that includes types that hold other values, more specific, i have "created" this two types: data Abb a b = Branch a b (Abb a b) (Abb a b) | Leaf and data ListAssoc a b = Node a b (ListAssoc a b) | Empty and implemented some common functions (add, search, delete, empty,etc). So when I was asked to create this new class I crashed against a big problem, or at least for me. My first attempt was: class Container c where empty :: c but when I had to implement "add" I tried add :: c -> a -> b -> c although I was almost sure that it wouldn't work, so I realized that I had to give Container not one but three parameters, the container and the types of values that the container saved so I started searching and I found similar cases, but the difference iis that in this cases the class was defined as follows: class Container c e | c->e where empty :: c insert :: c -> e -> c member :: c -> e -> Bool but my particular problem here is that the types I designed hold two values of different type and these holds just one value. Besides I knew nothing about functional dependency used in here and I keep knowing almost nothing about them, but I tried something like this: class Container c a b |c -> a, c -> b where empty :: c add :: c -> a -> c search :: c -> a -> Maybe b del :: c -> a -> c toListPair :: c -> [(a,b)] instance Container Abb a b where empty = Leaf add Leaf x y = Branch x y Leaf Leaf add arb@(Branch ni nd ri rd) x y |x == ni = arb |x > ni = Branch ni nd ri (add rd x y) |otherwise = Branch ni nd (add ri x y) rd search Leaf x = Nothing search (Branch ni nd ri rd) x |x == ni = Just nd |x > ni = search rd x |x < ni = search ri x but when I try to load it in WinHugs I get the following error message: - Instance is more general than a dependency allows *** Instance : Container Abb a b *** For class : Container a b c *** Under dependency : a -> b and as I have stated above my knowledge about dependencies is almost null, not to say null, so I don?t even have an idea where the error is. A suggestion that I've received was to change the type of Abb for data Abb (a,b) = Branch a b (Abb (a,b)) (Abb (a,b)) | Leaf and declare container class with just two parameters like I found in all pages I visited. I have not tried this yet, as I still have hope that what I intend to do is possible. Well if you have any suggestions I'd appreciate you send it to me and sorry for bothering you and my english, but i'm "spanish-speaker". -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080207/6f756dd2/attachment.htm From lemming at henning-thielemann.de Thu Feb 7 03:07:45 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 7 03:06:42 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <252F2727-29F0-4D8D-8AD6-BFE4793A117D@fastmail.fm> References: <1252070813.20080206203931@gmail.com> <200802062154.11609.matthew.pocock@ncl.ac.uk> <252F2727-29F0-4D8D-8AD6-BFE4793A117D@fastmail.fm> Message-ID: On Wed, 6 Feb 2008, Jonathan Cast wrote: > On 6 Feb 2008, at 1:54 PM, Matthew Pocock wrote: > > > On Wednesday 06 February 2008, Henning Thielemann wrote: > > > >> If the type checker does not terminate because the checked > >> function does > >> not terminate on the example input, then the function does not > >> pass the > >> type check and as a compromise this would be ok. > > > > Can't fault this logic. The problem is that you may have to wait > > quite a long time to discover this non-termination. > > I would second this --- letting the compiler go only to discover that > it's been running for the last 3 hours because it's diverging seems > like a wasted 3 hours. There is the same problem with unit testing: Tests that eat too much time have to be rewritten. Same here: If the automatic proof takes too long - choose a simpler example input (if possible). But Dan's point definitely applies here - there is no need to automatically prove every instance, if there is a possibility to do a proof manually. From lemming at henning-thielemann.de Thu Feb 7 03:12:35 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 7 03:11:31 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <404396ef0802061635l6d846239j7ff1011a269eb81@mail.gmail.com> References: <20080205154433.GA1566@cs.cmu.edu> <20080207002545.GB10247@cs.cmu.edu> <404396ef0802061635l6d846239j7ff1011a269eb81@mail.gmail.com> Message-ID: On Thu, 7 Feb 2008, Neil Mitchell wrote: > Hi > > > I think what you want to say now is not just > > > > (filter f l) is type correct when there is some argument on which f > > returns true > > > > but > > > > (filter f l) is type correct when there is some *element of l* on > > which f returns true > > or in Haskell: > > filterNonEmpty f x = assert (not $ null res) res > where res = filter f x > > If you give that definition to the Catch tool > (http://www-users.cs.york.ac.uk/~ndm/catch/) it will try and prove > each call is safe. For certain examples, Catch will do the job very > well - for example if your filter is something structural like isJust > or null. Indeed, if Catch or ESC or similar tools can handle such specifications it would be great. However I suspect that the translation you gave is different from what I wanted. I consider a function buggy, if it implements 'const' considerably more complicated than just saying 'const'. :-) That is, I only want to reject a function if it _always_ returns the empty list. Your 'filterNonEmpty' is rejected whenever _some_ arguments yield the empty list. From bulat.ziganshin at gmail.com Wed Feb 6 18:29:32 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 7 04:32:00 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> <1252070813.20080206203931@gmail.com> Message-ID: <1537238467.20080207022932@gmail.com> Hello Henning, Thursday, February 7, 2008, 12:29:02 AM, you wrote: >> it's impossible to check for *arbitrary* function call whether it will be >> terminated. seems that you don't have formal CS education? :) >> >> so one can develop set of functions that are guaranteed to be >> terminated or guaranteed to be non-trivial. but it's impossible to >> check for arbitrary function whether it's trivial and even whether it >> will terminate for particular data > If the type checker does not terminate because the checked function does > not terminate on the example input, then the function does not pass the > type check and as a compromise this would be ok. how you can check that some code doesn't terminate? ;) it may be just a bit too slow. we again return to my original point - we can check for *some* representations of trivial functions values, but we can't *ensure* that some computation is non-trivial -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Feb 6 18:34:14 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 7 04:32:19 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802061431g13512fe1o7eee72bf5a793f53@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <7665bf90802061120k353dacbv5a692b5208240452@mail.gmail.com> <7665bf90802061431g13512fe1o7eee72bf5a793f53@mail.gmail.com> Message-ID: <653325272.20080207023414@gmail.com> Hello Jeff, Thursday, February 7, 2008, 1:31:59 AM, you wrote: > I noticed that > GHC implements mutable arrays in the IO monad.??This seems odd to > me.??Arrays aren't related to IO.? IO monad isn't only about I/O but about imperative stuff in general. there is also special monad limited to mutable vars and arrays, namely ST. read also this: http://haskell.org/haskellwiki/Modern_array_libraries http://haskell.org/haskellwiki/IO_inside -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ndmitchell at gmail.com Thu Feb 7 04:35:38 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 7 04:34:32 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: <20080205154433.GA1566@cs.cmu.edu> <20080207002545.GB10247@cs.cmu.edu> <404396ef0802061635l6d846239j7ff1011a269eb81@mail.gmail.com> Message-ID: <404396ef0802070135h787cf448h2f25b91d94029742@mail.gmail.com> Hi > Indeed, if Catch or ESC or similar tools can handle such specifications it > would be great. However I suspect that the translation you gave is > different from what I wanted. I consider a function buggy, if it > implements 'const' considerably more complicated than just saying 'const'. > :-) That is, I only want to reject a function if it _always_ returns the > empty list. Your 'filterNonEmpty' is rejected whenever _some_ arguments > yield the empty list. Yes, but someone redefined your problem as the above one, which I can solve :-) For your original problem, Catch is entirely unsuitable. ESC/Haskell would be my preferred method of solving this within Haskell, but I'm not sure if it has existentials or not. I could imagine writing something like: filter :: {f: exists x. f x == True} -> {True} -> {True} filter :: (a -> Bool) -> [a] -> [a] Thanks Neil From g9ks157k at acme.softbase.org Thu Feb 7 05:17:48 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 7 05:16:54 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802061747s1713da91v9083396f381a657c@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <8b2a1a960802061730m558f9a77te4c9647ff06c1b4@mail.gmail.com> <6a7c66fc0802061747s1713da91v9083396f381a657c@mail.gmail.com> Message-ID: <200802071117.48786.g9ks157k@acme.softbase.org> Am Donnerstag, 7. Februar 2008 02:47 schrieb Alfonso Acosta: > > The other library I use for type-level programming is HList. It has > > type-level booleans already so you might what to take a look at it if > > you're not already familiar with it. > > Thanks I'll have a look at it. I have to admit that I don?t like the names HBool, HTrue and HFalse. What do they mean? Heterogenous booleans? Heterogenous truth? Why it?s ?Bool? instead of ?Boolean? and therefore not conforming to the Prelude convention? Heterogenous lists are not directly about type level computation. A HList type is usually inhabited. On the other hand, types which denote type level naturals or type-level booleans are empty data types. So type level booleans should go into some type level programming library like the one Alfonso and I want to create. HList should then use these booleans. This is at least my opinion. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Feb 7 06:25:24 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 7 06:24:38 2008 Subject: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available In-Reply-To: <47991E00.8050208@telenet.be> References: <4794F854.1050008@serpentine.com> <200801241256.46959.g9ks157k@acme.softbase.org> <47991E00.8050208@telenet.be> Message-ID: <200802071225.24114.g9ks157k@acme.softbase.org> Hello Peter, an answer to an ?old? e-mail (from January 25). Sorry for not answering earlier. Am Freitag, 25. Januar 2008 00:23 schrieben Sie: > Wolfgang Jeltsch wrote: > > Indeed. A functional approach to GUIs is nice but at the moment we don?t > > have anything that is suitable for solving real world problems (although > > this is being worked on). > > Could you elaborate a bit on that? What are the current obstacles to be > solved? Performance problems and lack of widgets are the two things that come to my mind immediately. Maybe also lack of a good way of doing dynamic user interfaces (user interfaces with a changing set/order of widgets). > When I looked at Yampa, I didn't really see a problem with making a GUI > or interactive application based on it (besides maybe performance and > space/time leaks, the latter IMO being a general problem in Haskell that > just occurs quicker in reactive programming). I think, performance is a big problem. To me it seems that Yampa-based GUIs maybe have a performance penalty of more than just a constant factor. Please have a look at the sections ?Implementation and efficiency? and ?Signals? under . > [?] > The main problem I could see is that Yampa is not really event driven in > the imperative sense; I mean in an ideal event based system, the > hardware triggers an interrupt when some sensor changes, and this then > triggers other software events; only the code that is related to > handling the event that occurred is executed. But the event that is > handled could potentially not be needed for the current output (which > could be considered as a programming bug...) Not necessarily a bug. There are events which don?t result in changes of the GUI, for example, mouse clicks into empty areas. > [?] Best wishes, Wolfgang From daniel.is.fischer at web.de Thu Feb 7 07:26:14 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Feb 7 07:23:40 2008 Subject: [Haskell-cafe] problem with collection (container) class In-Reply-To: <15c02dff0802062358g632cea57ifc7eeaee3aa1f587@mail.gmail.com> References: <15c02dff0802062358g632cea57ifc7eeaee3aa1f587@mail.gmail.com> Message-ID: <200802071326.14078.daniel.is.fischer@web.de> Am Donnerstag, 7. Februar 2008 08:58 schrieb Leandro Demarco Vedelago: > but when I try to load it in WinHugs I get the following error message: > > - Instance is more general than a dependency allows > *** Instance : Container Abb a b > *** For class : Container a b c > *** Under dependency : a -> b > > and as I have stated above my knowledge about dependencies is almost null, > not to say null, so I don?t even have an idea where the error is. Maybe ghci's error message is more helpful: dafis@linux:~/Documents/haskell/move> ghci Leandro GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Leandro ( Leandro.hs, interpreted ) Leandro.hs:16:19: `Abb' is not applied to enough type arguments Expected kind `*', but `Abb' has kind `* -> * -> *' In the instance declaration for `Container Abb a b' Failed, modules loaded: none. There are a couple of other things, mainly that you have the wrong type for 'add' and you need an Ord constraint for 'search'. This works: {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {- # LANGUAGE FlexibleInstances # -} module Leandro where data Abb a b = Branch a b (Abb a b) (Abb a b) | Leaf data ListAssoc a b = Node a b (ListAssoc a b) | Empty class Container c a b |c -> a, c -> b where empty :: c add :: c -> a -> b -> c search :: c -> a -> Maybe b del :: c -> a -> c toListPair :: c -> [(a,b)] instance (Ord a) => Container (Abb a b) a b where empty = Leaf add Leaf x y = Branch x y Leaf Leaf add arb@(Branch ni nd ri rd) x y |x == ni = arb |x > ni = Branch ni nd ri (add rd x y) |otherwise = Branch ni nd (add ri x y) rd search Leaf x = Nothing search (Branch ni nd ri rd) x |x == ni = Just nd |x > ni = search rd x |x < ni = search ri x Note: The FlexibleInstances Language pragma is required by GHC 6.8.1 and 6.8.2, but not by GHC 6.6.1 or hugs, I think that's a bug in 6.8.* > A suggestion that I've received was to change the type of Abb for > > data Abb (a,b) = Branch a b (Abb (a,b)) (Abb (a,b)) | Leaf > > and declare container class with just two parameters like I found in all > pages I visited. I have not tried this yet, as I still have hope that what > I intend to do is possible. > > Well if you have any suggestions I'd appreciate you send it to me and sorry > for bothering you and my english, but i'm "spanish-speaker". Cheers, Daniel From bayer at cpw.math.columbia.edu Thu Feb 7 07:53:15 2008 From: bayer at cpw.math.columbia.edu (Dave Bayer) Date: Thu Feb 7 07:52:10 2008 Subject: [Haskell-cafe] Best practice for embedding files in a GHC-compiled tool? In-Reply-To: <20080207052714.GB432795@localhost> References: <9FA3427A-DC2B-4D81-9A7D-7D2765F86990@math.columbia.edu> <20080207052714.GB432795@localhost> Message-ID: <48513191-0A26-44FD-8674-C0F3985CD7E2@math.columbia.edu> On Feb 7, 2008, at 12:27 AM, gwern0@gmail.com wrote: > Are you assuming that the various users have GHC/Hugs installed? You > know about scripting through the 'runhaskell' binary, right? I do, and I've used this. I don't want to do that here. Let me say this again: I am making no assumptions whatsoever about various users, other than platform. Haskell is not a niche language, with the right compile options, it CAN be used in this way. Here's the extreme case: When one is installing Mac OS X, one has access to a command line via a terminal application, but the operating system is otherwise very stripped down. Nevertheless, if one customizes an install DVD by adding a single command-line tool, one can execute that tool in this environment. I'd rather use Haskell than C for such applications. With C, we can introduce one file to an alien environment, and it will run. I've linked GHC Haskell programs that can be used in this way. Such programs can be used by anyone on a given platform. Assuming that GHC/Hugs is installed divides the potential audience by a large factor. Under this extreme hypothesis, how do I embed a compressed tar file into a single file command line tool written in Haskell and compiled by GHC? Thanks, Dave From bulat.ziganshin at gmail.com Thu Feb 7 05:23:20 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 7 08:02:16 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <20080207010403.GC10247@cs.cmu.edu> References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> <1252070813.20080206203931@gmail.com> <20080207010403.GC10247@cs.cmu.edu> Message-ID: <1675514121.20080207132320@gmail.com> Hello Dan, Thursday, February 7, 2008, 4:04:03 AM, you wrote: > I.e., it's not necessary to restrict the class of functions you consider > if you're willing to give up on full automation. So I disagree with the > "only if" below. ok, read this as "computer can ensure...", because it was exactly the original question - "can computer check that any given function in turing-complete language is non-trivial?" >> this means that answer to original question - one can ensure that >> argument for filter is non-terminating function only if these >> functions are written using some special notation which doesn't allow >> to write arbitrary turing-complete algorithms >> -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu Feb 7 05:29:48 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 7 08:02:44 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802061717y50b3d557oe7c91615b26fb8c6@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <7665bf90802061431g13512fe1o7eee72bf5a793f53@mail.gmail.com> <200802070037.15755.daniel.is.fischer@web.de> <7665bf90802061717y50b3d557oe7c91615b26fb8c6@mail.gmail.com> Message-ID: <858244868.20080207132948@gmail.com> Hello Jeff, Thursday, February 7, 2008, 4:17:27 AM, you wrote: > logical place for mutable arrays.? However, I don't understand the > motivation for implementing it in IO.? Were mutable arrays added to > IO because it would be difficult to write code that does both IO and manipulates arrays otherwise? yes. you can't perform separate ST actions in IO monad, you may call only entire computations with pure results - the same as you can do from pure code IO monad implements idea of sequencing actions and it is used ro "import" any actions written in other languages (C/C++ in most cases). ST monad is just the same internally but it was directive limited to only two types of actions - with variables and mutable arrays. this, together with some type tricks ensures that its results are referentially-transparent and therefore may be called from pure code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Thu Feb 7 08:27:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 7 08:26:25 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <1675514121.20080207132320@gmail.com> References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> <1252070813.20080206203931@gmail.com> <20080207010403.GC10247@cs.cmu.edu> <1675514121.20080207132320@gmail.com> Message-ID: On Thu, 7 Feb 2008, Bulat Ziganshin wrote: > Thursday, February 7, 2008, 4:04:03 AM, you wrote: > > > I.e., it's not necessary to restrict the class of functions you consider > > if you're willing to give up on full automation. So I disagree with the > > "only if" below. > > ok, read this as "computer can ensure...", because it was exactly the > original question - "can computer check that any given function in > turing-complete language is non-trivial?" My original question according to http://www.haskell.org/pipermail/haskell-cafe/2008-February/039161.html was "Is Haskell's type system including extensions strong enough for describing a function, that does not always return a trivial value?" From alfonso.acosta at gmail.com Thu Feb 7 09:56:36 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Feb 7 09:55:36 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802071117.48786.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <8b2a1a960802061730m558f9a77te4c9647ff06c1b4@mail.gmail.com> <6a7c66fc0802061747s1713da91v9083396f381a657c@mail.gmail.com> <200802071117.48786.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> Don't expect anything astonishing yet, but an initial version of the library can be found at http:/code.haskell.org/type-level To make reviewing easier I have put the haddock-generated documentation at http://code.haskell.org/~fons/type-level/doc/ Some remarks: * Only Positive and Natural numerals in decimal representation are supported. It would be cool to add support for Integers though. * The code is based on Oleg's implimentation of type-level binaries http://okmij.org/ftp/Computation/resource-aware-prog/BinaryNumber.hs * exponentiation/log and GCD is not implemented yet * multiplication is not relational and thus division is broken. I tried porting Oleg's multiplication algorithm without success. * Aliases (in binary, octal decimal and hexadecimal form) for type-level values and their value-level reflection functions are generated with TH. That implies: * Long compilation time depending on your system * Although errors will always be reported in decimal form, the end user can input values using other bases (only for values in the range of generated aliases of course) * It would be cool to have "real" support for other bases apart from decimals * It would imply having unlimited size of input for other bases (right now if we want to input a value out of the alises limit, decimal reprentation is mandatory) * However, is it feasible? How could it be done without needing to implement the operations for each base? WOuld it be possible to "overload" the type-level operators so that they worked with different representations and mixed representation arguments? * Booleans are not implemented (Wolfgang?) I would be happy to hear any suggestions, get code reviews and/or contributions. Cheers, Fons On Feb 7, 2008 11:17 AM, Wolfgang Jeltsch wrote: > Am Donnerstag, 7. Februar 2008 02:47 schrieb Alfonso Acosta: > > > The other library I use for type-level programming is HList. It has > > > type-level booleans already so you might what to take a look at it if > > > you're not already familiar with it. > > > > Thanks I'll have a look at it. > > I have to admit that I don't like the names HBool, HTrue and HFalse. What do > they mean? Heterogenous booleans? Heterogenous truth? Why it's "Bool" > instead of "Boolean" and therefore not conforming to the Prelude convention? > > Heterogenous lists are not directly about type level computation. A HList > type is usually inhabited. On the other hand, types which denote type level > naturals or type-level booleans are empty data types. So type level booleans > should go into some type level programming library like the one Alfonso and I > want to create. HList should then use these booleans. This is at least my > opinion. > > Best wishes, > Wolfgang > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jonathanccast at fastmail.fm Thu Feb 7 10:13:30 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 7 10:12:31 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <65d7a7e0802062332q4131363ey6503bf75b996e54f@mail.gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> <1495211458.20080206123008@gmail.com> <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> <65d7a7e0802062332q4131363ey6503bf75b996e54f@mail.gmail.com> Message-ID: <9F3A8102-53FC-4220-B465-9103FDAB72D4@fastmail.fm> On 6 Feb 2008, at 11:32 PM, Uwe Hollerbach wrote: > All right, after a bit of dinner and some time to mess about, here's > another attempt to check my understanding: here is a simplified > version of the lisp-time example: > >> module Main where >> import System.Time >> >> pure_fn :: Integer -> String >> pure_fn n = calendarTimeToString (toUTCTime (TOD n 0)) >> >> wicked_fn :: IO String >> wicked_fn = getClockTime >>= return . pure_fn . toI >> where toI (TOD n _) = n >> >> make_wicked :: String -> IO String >> make_wicked str = return str >> >> -- use of pure_fn >> -- main = putStrLn (pure_fn 1230000000) >> >> -- use of wicked_fn >> -- main = wicked_fn >>= putStrLn >> >> -- use of make_wicked >> main = (make_wicked (pure_fn 1234567890)) >>= putStrLn > > If I use the first of the three "main" alternatives, I'm calling a > pure function directly: it takes an integer, 123..., and produces a > string. If I pass the same integer to the pure function, I'll get the > same value, every time. This string is passed to putStrLn, an IO > action, in order that I may gaze upon it, but the string itself is not > thereby stuck in the IO monad. > > If I use the second of the three "main" alternatives, I'm calling an > IO action: wicked_fn, which returns the current time formatted as UTC. > In principle, every time I call wicked_fn, I could get a different > answer. Because it's an IO action, I can't just pass it to putStrLn in > the same way I passed in the previous pure_fn value, but instead I > have to use the bind operator >>=. > > If I use the third of the "main" alternatives, I am starting with a > pure function: it's that number formatted as UTC (it happens to come > to Fri Feb 13 of next year), but then I pass it through the > make_wicked function, which transmogrifies it into the IO monad. > Therefore, as in the above, I have to use >>= in order to get it to > work; "putStrLn (make_wicked (pure_fn 123...))" doesn't work. > > > > OK, after all that, my original question, in terms of this example: > "the IO monad is one-way" is equivalent to saying there is no haskell > function that I could write that would take > >> (make_wicked (pure_fn 123456)) > > and make it into something that could be used in the same way and the > same places as just plain > >> (pure_fn 123456) > > ? > > And, coming back to my scheme interpreter, this is at least somewhat > irrelevant, because, since I am in a REPL of my own devising, I'm > firmly in IO-monad-land, now and forever. Right. jcc From g9ks157k at acme.softbase.org Thu Feb 7 10:16:05 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 7 10:15:19 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071117.48786.g9ks157k@acme.softbase.org> <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> Message-ID: <200802071616.06220.g9ks157k@acme.softbase.org> Am Donnerstag, 7. Februar 2008 15:56 schrieben Sie: > Don't expect anything astonishing yet, but an initial version of the > library can be found at > > http:/code.haskell.org/type-level > > To make reviewing easier I have put the haddock-generated documentation at > > http://code.haskell.org/~fons/type-level/doc/ Thanks for your effort. From a quick look at the Haddock documentation, some questions/remarks arised. Nat means ?all natural numbers except zero? while Nat0 means ?all natural numbers (including zero)?. Since in computer science, natural numbers usually cover zero, we should use Pos instead of Nat and Nat instead of Nat0. You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, the latter representation should probably be prefered. With it, :+ always has a number as its left argument and a digit as its right. Without the () :+ we get ugly exceptional cases. You can see this, for example, in the instance declarations for Compare. With the second representation, we could reduce the number of instances dramatically. We would define a comparison of digits (verbose) and than a comparison of numbers based on the digit comparison (not verbose). :+ is already used as the constructor for complex numbers. We should probably use some different operator. Again, thanks for your work. > [?] Best wishes, Wolfgang From jonathanccast at fastmail.fm Thu Feb 7 10:30:29 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 7 10:29:25 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: <1252070813.20080206203931@gmail.com> <200802062154.11609.matthew.pocock@ncl.ac.uk> <252F2727-29F0-4D8D-8AD6-BFE4793A117D@fastmail.fm> Message-ID: <2104FCCD-2B16-40BB-A385-7E9BF8733E9D@fastmail.fm> On 7 Feb 2008, at 12:07 AM, Henning Thielemann wrote: > > On Wed, 6 Feb 2008, Jonathan Cast wrote: > >> On 6 Feb 2008, at 1:54 PM, Matthew Pocock wrote: >> >>> On Wednesday 06 February 2008, Henning Thielemann wrote: >>> >>>> If the type checker does not terminate because the checked >>>> function does >>>> not terminate on the example input, then the function does not >>>> pass the >>>> type check and as a compromise this would be ok. >>> >>> Can't fault this logic. The problem is that you may have to wait >>> quite a long time to discover this non-termination. >> >> I would second this --- letting the compiler go only to discover that >> it's been running for the last 3 hours because it's diverging seems >> like a wasted 3 hours. > > There is the same problem with unit testing: Tests that eat too > much time > have to be rewritten. Tell that to my co-workers... > Same here: If the automatic proof takes too long - > choose a simpler example input (if possible). 3 hours wasn't chosen arbitrarily --- I've had suites of unit tests take that long, and that's realistically about when I'd check for divergence. And in a large program I'd hate to recompile only to discover that it's taking so long because *I* introduced an infinite loop into the compiler. > But Dan's point definitely > applies here - there is no need to automatically prove every > instance, if > there is a possibility to do a proof manually. jcc From alfonso.acosta at gmail.com Thu Feb 7 10:31:36 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Feb 7 10:30:31 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802071616.06220.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071117.48786.g9ks157k@acme.softbase.org> <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> On Feb 7, 2008 4:16 PM, Wolfgang Jeltsch wrote: > Nat means "all natural numbers except zero" while Nat0 means "all natural > numbers (including zero)". Since in computer science, natural numbers > usually cover zero, we should use Pos instead of Nat and Nat instead of Nat0. Sounds sensible, actually Nat and Nat0 is confusing. However I would rather use Pos and Nat0 to make explicit that naturals include zero . Depending on the definition of naturals they might or might not include zero. http://en.wikipedia.org/wiki/Natural_number > You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, the > latter representation should probably be prefered. With it, :+ always has a > number as its left argument and a digit as its right. Without the () :+ we > get ugly exceptional cases. > You can see this, for example, in the instance > declarations for Compare. With the second representation, we could reduce > the number of instances dramatically. We would define a comparison of digits > (verbose) and than a comparison of numbers based on the digit comparison (not > verbose). Even if () would be preferred from the programmers point of view (I'm not sure how much we could reduce the number of instances though), it makes the representation less attractive on the user-side. Anyone using the library would find it annoying and would wonder why is it neccessary. Unless we find a way to use () only internally (we should use a one-character type to make it shorter to type) I think we should stick to current representation. > :+ is already used as the constructor for complex numbers. We should probably > use some different operator. Right. I didn't think about that, thanks. From ahey at iee.org Thu Feb 7 11:34:25 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Feb 7 11:33:33 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <404396ef0802060248q7c8bb272t62525b2451be9600@mail.gmail.com> References: <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> <404396ef0802060248q7c8bb272t62525b2451be9600@mail.gmail.com> Message-ID: <47AB3311.7000804@iee.org> Neil Mitchell wrote: > Hi > >> I have already partially scanned the list looking for the first >> element that satisfies some condition, using a tail recursive search. >> >> If such an element is found I want to split the list at that point. > > span/break? I really can't believe the memory overhead of span is that > terrible, you are only duplicating the (:)'s and its only one > traversal. > >>> As an aside, my version of this function would be: >>> >>> neilGobbler :: Int -> [x] -> [x] >>> neilGobbler n xs = length res `seq` res >>> where res = take n xs >>> >> My guess is it will use O(1) stack and burn O(n) heap (in addition that >> actually used by the result), so assymptotic complexity wise same as >> heapGobbler, but probably higher constant factors with ghc due to lazy >> building of take thunks and subsequent reduction and indirection costs. > > Sure? Guessing constant factors related to strictness and laziness is > incredibly hard! My guess based on "gut feeling" is that the program > will take less time, and use half the memory. But given my initial > comment, that guess is not very reliable. But the point is that *both* heapGobbler and neilGobbler are likely to be slower and chew through at least twice as much heap as stackGobbler, which would be the implementation of choice for both simplicity and performance if it wasn't for this stack management problem. Regards -- Adrian Hey From jeff1.61803 at gmail.com Thu Feb 7 11:34:58 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Thu Feb 7 11:33:54 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <2eb8984a0802020457s68850ffg5d8dc8432a2aa3c4@mail.gmail.com> <2eb8984a0802020511y3215cce2m698d2af2baa562d8@mail.gmail.com> Message-ID: <7665bf90802070834g6944b089l39198a7dfb11ee1f@mail.gmail.com> On Feb 2, 2008 12:11 PM, Chadda? Fouch? wrote: > To address this I propose this function : > foldl1MArray' :: (MArray a e m, Ix i) => (e -> e -> e) -> a i e -> m e > foldl1MArray' f a = do > (l,u) <- getBounds a > firstElem <- readArray a l > foldM (\a mb -> a `seq` mb >>= return . f a) > firstElem (map (readArray a) (range (l,u))) > I played with your foldl1MArray' last night. I noticed it can be reduced to . . . foldl1MArray' :: (MArray a e m, Ix i) => (e -> e -> e) -> a i e -> m e foldl1MArray' f a = do (l,u) <- getBounds a foldl1' (liftM2 f) (map (readArray a) (range (l,u))) Unfortunately, my new version consumes a lot of stack and heap space. Why is this so inefficient? Is there a simple change that will make it efficient? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080207/86340c41/attachment.htm From ndmitchell at gmail.com Thu Feb 7 11:56:22 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 7 11:55:16 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47AB3311.7000804@iee.org> References: <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> <404396ef0802060248q7c8bb272t62525b2451be9600@mail.gmail.com> <47AB3311.7000804@iee.org> Message-ID: <404396ef0802070856w6836370bjf0f616e55ac3aca@mail.gmail.com> Hi > But the point is that *both* heapGobbler and neilGobbler are likely to > be slower and chew through at least twice as much heap as stackGobbler, > which would be the implementation of choice for both simplicity and > performance if it wasn't for this stack management problem. Sure? That sounds like the thing that people can conjecture, but benchmarks can prove. And I'd claim that neilGobbler is the simplest function by a large margin. Thanks Neil From bf3 at telenet.be Thu Feb 7 12:33:06 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Thu Feb 7 12:32:00 2008 Subject: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available In-Reply-To: <200802071225.24114.g9ks157k@acme.softbase.org> References: <4794F854.1050008@serpentine.com> <200801241256.46959.g9ks157k@acme.softbase.org> <47991E00.8050208@telenet.be> <200802071225.24114.g9ks157k@acme.softbase.org> Message-ID: <000601c869af$814a1b90$83de52b0$@be> Interesting. Thanks for the reply. It might be nice to have some performance benchmarks for all these experimental systems, so we can compare them. I could understand that performance might be an issue for games, but for GUIs? I mean many imperative GUI systems use rather slow message dispatching systems, and we use those every day. Look at the new Windows Presentation Foundation system found in VISTA. Here events are broadcasted and routed through the whole element tree. This is also rather slow I guess. > -----Original Message----- > From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- > bounces@haskell.org] On Behalf Of Wolfgang Jeltsch > Sent: Thursday, February 07, 2008 12:25 PM > To: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now > publicly available > > Hello Peter, > > an answer to an ?old? e-mail (from January 25). Sorry for not > answering > earlier. > > Am Freitag, 25. Januar 2008 00:23 schrieben Sie: > > Wolfgang Jeltsch wrote: > > > Indeed. A functional approach to GUIs is nice but at the moment we > don?t > > > have anything that is suitable for solving real world problems > (although > > > this is being worked on). > > > > Could you elaborate a bit on that? What are the current obstacles to > be > > solved? > > Performance problems and lack of widgets are the two things that come > to my > mind immediately. Maybe also lack of a good way of doing dynamic user > interfaces (user interfaces with a changing set/order of widgets). > > > When I looked at Yampa, I didn't really see a problem with making a > GUI > > or interactive application based on it (besides maybe performance and > > space/time leaks, the latter IMO being a general problem in Haskell > that > > just occurs quicker in reactive programming). > > I think, performance is a big problem. To me it seems that Yampa-based > GUIs > maybe have a performance penalty of more than just a constant factor. > Please > have a look at the sections ?Implementation and efficiency? and > ?Signals? > under . > > > [?] > > > The main problem I could see is that Yampa is not really event driven > in > > the imperative sense; I mean in an ideal event based system, the > > hardware triggers an interrupt when some sensor changes, and this > then > > triggers other software events; only the code that is related to > > handling the event that occurred is executed. But the event that is > > handled could potentially not be needed for the current output (which > > could be considered as a programming bug...) > > Not necessarily a bug. There are events which don?t result in changes > of the > GUI, for example, mouse clicks into empty areas. > > > [?] > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.19.21/1263 - Release Date: > 2/6/2008 8:14 PM From ahey at iee.org Thu Feb 7 12:43:43 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Feb 7 12:42:45 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <404396ef0802070856w6836370bjf0f616e55ac3aca@mail.gmail.com> References: <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> <404396ef0802060248q7c8bb272t62525b2451be9600@mail.gmail.com> <47AB3311.7000804@iee.org> <404396ef0802070856w6836370bjf0f616e55ac3aca@mail.gmail.com> Message-ID: <47AB434F.10603@iee.org> Neil Mitchell wrote: > Hi > >> But the point is that *both* heapGobbler and neilGobbler are likely to >> be slower and chew through at least twice as much heap as stackGobbler, >> which would be the implementation of choice for both simplicity and >> performance if it wasn't for this stack management problem. > > Sure? Yes, though testing stackGobbler with a large enough data set could be problematic for the very reason we've been discsussing. But let's say your hypothesis was correct. If so then presumably *all* Haskell programs could give better performance than they currently do if we nuked the stack completely and have ghc generate CPS style code. This too would be fine with me. The problem with the current situation is that we have perfectly sound and correct programs that "crash" quite unnecessarily (and even if they don't get quite that far, can still cause considerable per thread memory wastage if what SPJ says is true). Why their authors choose to use a "stack greedy" implementation and whether that was by design or a mistake really *isn't* the point. As I said before (this is the third time I think), the fact that these programs use a lot of "stack" at all is just a peculiarity of *ghc* implementation, so it really is a ghc responsibility to do a decent job of stack management IMO. It's not a programmer responsibility to code in such a way that minimal "stack" is used (with ghc). > That sounds like the thing that people can conjecture, but > benchmarks can prove. And I'd claim that neilGobbler is the simplest > function by a large margin. AFAICT neilGobbler isn't even entirely safe as an implementation of an eager take. There's nothing the Haskell standard to stop it being transformed into.. neilGobbler :: Int -> [x] -> [x] neilGobbler n xs = length (take n xs) `seq` take n xs Regards -- Adrian Hey From ahey at iee.org Thu Feb 7 12:53:30 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Feb 7 12:52:34 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47AB434F.10603@iee.org> References: <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> <404396ef0802060248q7c8bb272t62525b2451be9600@mail.gmail.com> <47AB3311.7000804@iee.org> <404396ef0802070856w6836370bjf0f616e55ac3aca@mail.gmail.com> <47AB434F.10603@iee.org> Message-ID: <47AB459A.3070608@iee.org> Adrian Hey wrote: > AFAICT neilGobbler isn't even entirely safe as an implementation of > an eager take. There's nothing the Haskell standard to stop it being > transformed into.. > > neilGobbler :: Int -> [x] -> [x] > neilGobbler n xs = length (take n xs) `seq` take n xs Whoops, I see stackGobbler has the same problem.. -- Strict version of take stackGobbler :: Int -> [x] -> [x] stackGobbler 0 _ = [] stackGobbler _ [] = [] stackGobbler n (x:xs) = let xs' = stackGobbler (n-1) xs in xs' `seq` (x:xs') I guess this is an example of the Haskell standard needing to be tightened up a bit, but that is another story.. Regards -- Adrian Hey From chad.scherrer at gmail.com Thu Feb 7 13:40:47 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Thu Feb 7 14:34:25 2008 Subject: [Haskell-cafe] :i and :t give different types Message-ID: Hello haskell-cafe, In ghci, I tried to get info for Data.Stream.Stream: $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m Data.Stream Prelude Data.Stream> :i Stream data Stream a where Stream :: forall a s. (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a -- Defined in Data.Stream instance Functor Stream -- Defined in Data.Stream This didn't seem right to me, so I asked tried this: Prelude Data.Stream> :t Stream Stream :: (Data.Stream.Unlifted s) => (s -> Step a s) -> s -> Stream a What's going on here? forall a s. (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a and (Data.Stream.Unlifted s) => (s -> Step a s) -> s -> Stream a are completely different, right? And really, neither one makes much sense to me. I would have expected forall s. (Data.Stream.Unlifted s) => (s -> Step a s) -> s -> Stream a -- Chad From dons at galois.com Thu Feb 7 14:47:18 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 7 14:46:13 2008 Subject: [Haskell-cafe] :i and :t give different types In-Reply-To: References: Message-ID: <20080207194718.GD19014@scytale.galois.com> chad.scherrer: > Hello haskell-cafe, > > In ghci, I tried to get info for Data.Stream.Stream: > > $ ghci > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> :m Data.Stream > Prelude Data.Stream> :i Stream > data Stream a where > Stream :: forall a s. > (Data.Stream.Unlifted s) => > !s -> Step a s -> !s -> Stream a > -- Defined in Data.Stream That's fine, and is the correct type. data Stream a = forall s. Unlifted s => Stream !(s -> Step a s) -- ^ a stepper function !s -- ^ an initial state > instance Functor Stream -- Defined in Data.Stream > > This didn't seem right to me, so I asked tried this: > > Prelude Data.Stream> :t Stream > Stream :: (Data.Stream.Unlifted s) => (s -> Step a s) -> s -> Stream a So that's the type of the Stream constructor, which introduces a new existentially typed Stream (the 'a'). > What's going on here? > > forall a s. (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a > and > (Data.Stream.Unlifted s) => (s -> Step a s) -> s -> Stream a One is the type, one is the constructor for the type. > are completely different, right? And really, neither one makes much > sense to me. I would have expected > > forall s. (Data.Stream.Unlifted s) => (s -> Step a s) -> s -> Stream a For the constructor? This all looks right, as far as I can tell: $ ghci -fglasgow-exts Prelude> :m + Data.Stream Info about the data type: Prelude Data.Stream> :info Stream data Stream a where Stream :: forall a s. (Data.Stream.Unlifted s) => !s -> Step a s -> !s -> Stream a -- Defined in Data.Stream instance Functor Stream -- Defined in Data.Stream The type of the constructor Prelude Data.Stream> :t Stream Stream :: forall s a. (Data.Stream.Unlifted s) => (s -> Step a s) -> s -> Stream a The kind of the type: Prelude Data.Stream> :k Stream Stream :: * -> * -- Don From vigalchin at gmail.com Thu Feb 7 13:14:51 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Thu Feb 7 14:49:52 2008 Subject: [Haskell-cafe] question concerning ANSI "void *" Message-ID: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> Hello, Ok .. I am writing a Haskell function that will call down into the ANSI C library .. blah :: .... -> Ptr Word8 ....-> .... The underlying C function that "blah" is calling has a "void *" so I am using "Ptr Word 8" to model the "void *". I propose to have the callers of function "blah" to populate a data structure something like "Ptr Buz" where "data Buz = { ........} and then do a "recast :: Ptr Word 8 -> Ptr Buz" when invoking function "blah". Does this seem reasonable? Is there a better way? Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080207/a66a92a2/attachment.htm From jwlato at gmail.com Thu Feb 7 13:55:54 2008 From: jwlato at gmail.com (John Lato) Date: Thu Feb 7 14:50:16 2008 Subject: [Haskell-cafe] Mutable arrays Message-ID: <9979e72e0802071055v4b447441oc069b1d537769de6@mail.gmail.com> Ok, I've done some testing on different array accessing strategies, and at this point I believe that, as Stefan previously suggested, using an Oleg-inspired fold for access offers the best performance. My first non-unsafe idea was to try: > import Data.Array.MArray > import Data.Array.IO > import Data.Int (Int32) > import Data.List (foldl') > > -- |Create an array. Change the type signature to experiment with different array types. > makeAry :: IO (IOUArray Integer Float) > makeAry = newListArray (1,1000000) [1..] > getElemsLazy :: (MArray a e m, Ix i) => a i e -> m [e] > getElemsLazy myAry = getBounds myAry >>= > mapM (readArray myAry) . range this works on a 1 million element Int32 array (IOArray or IOUArray): > myElems <-getElemsLazy myAry > let myMax = foldl' max 0 myElems But with a 10-million element array, I get a stack overflow. I next tried the foldA functions Stefan posted, but had some problems with them. I think that the array elements need to be instances of Bounded and Fractional, and I don't know of a suitable type. Anyway, his code is a little too compact for me to understand without further study, so I moved on. Next I created my own fold operators. These are fairly directly copied from an email Oleg posted to the haskell mailing list: > leftFoldA' myArray self iteratee seed = do > elem <- readArray myArray $ fst seed > case iteratee seed elem of > Left seed -> return seed > Right seed -> self iteratee seed > > leftFoldA :: (MArray a e m, Ix a1) => a a1 e -> ((a1, b) -> e -> Either t (a1, b)) -> a1, b) -> m t > leftFoldA array iteratee seed = > let g = (leftFoldA' array) g in > g iteratee seed > > leftFoldModA' myArray self iteratee seed = do > elem <- readArray myArray $ fst seed > result <- iteratee seed elem > case result of > Left seed -> return seed > Right seed -> self iteratee seed > > leftFoldMA :: (MArray a e m, Ix a1) => a a1 e -> ((a1, b) -> e -> m (Either t (a1, b))) -> a1, b) -> m t > leftFoldMA array iteratee seed = > let g = (leftFoldModA' array) g in > g iteratee seed the two functions to use are leftFoldA and leftFoldMA. The difference, show in the type signature, is that the iteratee in leftFoldA is pure while the iteratee in leftFoldMA operates in the monad. So if you're going to modify the array, for example, you need to use the leftFoldMA version. These folds let me define: > findMax myAry = do > (lowB, highB) <- getBounds myAry > let maxReader (ix, acc) c = > let > ix' = ix + 1 > acc' = max c acc > in acc' `seq` (if ix' > highB then Left else Right) (ix', acc') > (_, myMax) <- leftFoldA myAry maxReader (lowB, 0) > return myMax > > normalizeArray myAry = do > myMax <- findMax myAry > (lowB, highB) <- getBounds myAry > let normMod = 1/myMax > let normalizer (ix, _) c = do > let ix' = ix + 1 > curVal <- readArray myAry ix > writeArray myAry ix (curVal * normMod) > return $ (if ix' > highB then Left else Right) (ix', ()) > leftFoldMA myAry normalizer (lowB, ()) > > -- |show all elements from lowB to highB > -- this only works with IO arrays, since the readArray and print happen in the same monad. > -- you could possibly make it work with ST arrays if you use a monad transformer, but you'd have > -- to change leftFoldMA as well. > showElems myAry lowB highB = do > let showFunc (ix, _) c = do > let ix' = ix + 1 > readArray myAry ix >>= print > return $ (if ix' > highB then Left else Right) (ix', ()) > leftFoldMA myAry showFunc (lowB, ()) There are probably better ways to define the folds, but I hope these are pretty easy to follow. If I was doing a lot of different operations, I'd probably define functions like > makeIteratee highB func = (\(ix, acc) c -> > let > ix' = ix + 1 > acc' = func c acc > in acc' `seq` (if ix' > highB then Left else Right) (ix', acc')) so that findMax becomes: > findMax2 myAry = do > (lowB, highB) <- getBounds myAry > (_, myMax) <- leftFoldA myAry (makeIteratee highB max) (lowB, 0) > return myMax instead of having to define a bunch of iteratees in let clauses. Now, running the program > main :: IO () > main = do > myAry <- makeAry > (lowB, highB) <- getBounds myAry > normalizeArray myAry > showElems myAry 1 10 > showElems myAry 999990 1000000 > return () takes about 5 seconds, with no optimizations. It takes less than a second with -O2. Much better. It does take longer with boxed arrays, but that's to be expected. No unsafe functions, either. The only sketchy bit is using seq in the iteratees (e.g. maxReader in findMax) to force the accumulator. I say sketchy not because it's unsafe or unreliable, but it would be nice if it was unnecessary. Notes: I used GHC 6.8.1 on WinXP, 3.2GHZ P4, 1.5GB RAM. All of my original tests were done without any optimizations, which is why I didn't include timing information for the earlier stuff. The getElemsLazy function is fast, but the stack overflow is annoying. Using the leftFold functions is both faster and avoids the space leak. I was also using the Data.List.Stream and Control.Monad.Stream versions of foldl' and mapM, although I don't think those made much difference. Anyway, this was a good exercise for me. I learned a lot, especially about the power of left-fold enumerators. Cheers, John From ryani.spam at gmail.com Thu Feb 7 14:55:37 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Feb 7 14:54:31 2008 Subject: [Haskell-cafe] :i and :t give different types In-Reply-To: <20080207194718.GD19014@scytale.galois.com> References: <20080207194718.GD19014@scytale.galois.com> Message-ID: <2f9b2d30802071155m2fa88eearaf6d368c61ed2b3a@mail.gmail.com> It looks like there is a bug with unparsing of bang-constructors in ghci: On 2/7/08, Don Stewart wrote: > data Stream a = forall s. Unlifted s => > Stream !(s -> Step a s) -- ^ a stepper function > !s -- ^ an initial state > Prelude Data.Stream> :info Stream > data Stream a where > Stream :: forall a s. > (Data.Stream.Unlifted s) => > !s -> Step a s -> !s -> Stream a This last line should start with !(s -> Step a s) instead of !s -> Step a s. If that was fixed, everything looks correct. -- ryan From dons at galois.com Thu Feb 7 14:57:31 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 7 14:56:26 2008 Subject: [Haskell-cafe] :i and :t give different types In-Reply-To: <2f9b2d30802071155m2fa88eearaf6d368c61ed2b3a@mail.gmail.com> References: <20080207194718.GD19014@scytale.galois.com> <2f9b2d30802071155m2fa88eearaf6d368c61ed2b3a@mail.gmail.com> Message-ID: <20080207195731.GE19014@scytale.galois.com> ryani.spam: > It looks like there is a bug with unparsing of bang-constructors in ghci: > > On 2/7/08, Don Stewart wrote: > > data Stream a = forall s. Unlifted s => > > Stream !(s -> Step a s) -- ^ a stepper function > > !s -- ^ an initial state > > > Prelude Data.Stream> :info Stream > > data Stream a where > > Stream :: forall a s. > > (Data.Stream.Unlifted s) => > > !s -> Step a s -> !s -> Stream a > > This last line should start with !(s -> Step a s) instead of !s -> Step a s. > > If that was fixed, everything looks correct. Ah, yes, missing parens! Well spotted. So a pretty printer wibble in GHC? -- Don From westondan at imageworks.com Thu Feb 7 14:38:48 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Feb 7 14:59:50 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071117.48786.g9ks157k@acme.softbase.org> <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> Message-ID: <47AB5E48.9000400@imageworks.com> I know that naming is arbitrary, but... Digits in types seems ugly to me. In this case, it is also redundant. Everyone but FORTRAN programmers counts from 0, not 1. Nat and Pos seem clear. Nat0 could even mean Nat \ {0}, the opposite of what is proposed, so confusion is even increased with Nat0. Dan Alfonso Acosta wrote: > On Feb 7, 2008 4:16 PM, Wolfgang Jeltsch wrote: >> Nat means "all natural numbers except zero" while Nat0 means "all natural >> numbers (including zero)". Since in computer science, natural numbers >> usually cover zero, we should use Pos instead of Nat and Nat instead of Nat0. > > Sounds sensible, actually Nat and Nat0 is confusing. However I would > rather use Pos and Nat0 to make explicit that naturals include zero . > > Depending on the definition of naturals they might or might not > include zero. http://en.wikipedia.org/wiki/Natural_number > >> You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, the >> latter representation should probably be prefered. With it, :+ always has a >> number as its left argument and a digit as its right. Without the () :+ we >> get ugly exceptional cases. >> You can see this, for example, in the instance >> declarations for Compare. With the second representation, we could reduce >> the number of instances dramatically. We would define a comparison of digits >> (verbose) and than a comparison of numbers based on the digit comparison (not >> verbose). > > Even if () would be preferred from the programmers point of view (I'm > not sure how much we could reduce the number of instances though), it > makes the representation less attractive on the user-side. Anyone > using the library would find it annoying and would wonder why is it > neccessary. > > Unless we find a way to use () only internally (we should use a > one-character type to make it shorter to type) I think we should stick > to current representation. > >> :+ is already used as the constructor for complex numbers. We should probably >> use some different operator. > > Right. I didn't think about that, thanks. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From clifford.beshers at gmail.com Thu Feb 7 13:24:40 2008 From: clifford.beshers at gmail.com (Clifford Beshers) Date: Thu Feb 7 15:01:36 2008 Subject: [Haskell-cafe] FP and Quality In-Reply-To: <7.0.1.0.0.20080204221330.01ced7e8@ntlworld.com> References: <7.0.1.0.0.20080204221330.01ced7e8@ntlworld.com> Message-ID: <6841b9520802071024k7d9a664w86aaf75646a2a4da@mail.gmail.com> ICFP 2007 introduced a new category of paper called an "Experience Report", which is not required to add to the body of research knowledge, but rather report on the effectiveness of functional tools and methods in full-scale projects. You can read the official description in the call for papers: http://www.icfpconference.org/icfp2008/cfp/cfp.html The ICFP 2007 schedule lists all the experience reports here: http://www.informatik.uni-bonn.de/~ralf/schedule.html You can get the PDFs for the experience report (and talk slides) we wrote describing our use of FP at Linspire here: http://seereason.com/publications/ Cliff On Feb 4, 2008 2:20 PM, PR Stanley wrote: > Hi folks > I'm thinking of writing a little essay arguing the case for the > advantages of FP for producing quality software. Can the list > recommend any papers/articles which I can use as sources of my > argument? I have access to the IEEE database too although earlier I > couldn't find anything on the subject. > Thanks, Paul > > _______________________________________________ > 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/20080207/b5e26a47/attachment.htm From gmh at Cs.Nott.AC.UK Thu Feb 7 15:03:06 2008 From: gmh at Cs.Nott.AC.UK (Graham Hutton) Date: Thu Feb 7 15:04:01 2008 Subject: [Haskell-cafe] Two Lectureships in Nottingham Message-ID: <24982.1202414586@cs.nott.ac.uk> Dear all, We are advertising two new Lectureships (Assistant Professorships) in Computer Science at the University of Nottingham in England. Applications in the area of functional programming are particularly welcome. Further details are available from: http://jobs.nottingham.ac.uk/vacancies.aspx?cat=160#j2797 The closing date for applications is 22nd Feburary 2008 Best wishes, Graham Hutton +-----------------------------------------------------------------+ | Dr Graham Hutton Email : gmh@cs.nott.ac.uk | | School of Computer Science | | University of Nottingham Web : www.cs.nott.ac.uk/~gmh | | Jubilee Campus, Wollaton Road | | Nottingham NG8 1BB, UK Phone : +44 (0)115 951 4220 | +-----------------------------------------------------------------+ This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From westondan at imageworks.com Thu Feb 7 15:01:17 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Feb 7 15:08:19 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <8b2a1a960802061730m558f9a77te4c9647ff06c1b4@mail.gmail.com> <6a7c66fc0802061747s1713da91v9083396f381a657c@mail.gmail.com> <200802071117.48786.g9ks157k@acme.softbase.org> <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> Message-ID: <47AB638D.602@imageworks.com> This may be a GHC bug, but even though in the module Data.TypeLevel.Num.Reps has the header {-# LANGUAGE EmptyDataDecls, TypeOperators #-} I still get an error with both ghc and ghci version 6.8.2 unless I throw in the -XTypeOperators flag. > cat Go.hs import Data.TypeLevel.Num.Reps main = return (undefined :: D2 :+ D1) >> print "Done" > ghc --make Go.hs [1 of 1] Compiling Main ( Go.hs, Go.o ) Go.hs:3:31: Illegal operator `:+' in type `D2 :+ D1' (Use -XTypeOperators to allow operators in types) > ghc --make -XTypeOperators Go.hs [1 of 1] Compiling Main ( Go.hs, Go.o ) Linking Go ... > ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Dan Alfonso Acosta wrote: > Don't expect anything astonishing yet, but an initial version of the > library can be found at > > http:/code.haskell.org/type-level > > To make reviewing easier I have put the haddock-generated documentation at > > http://code.haskell.org/~fons/type-level/doc/ > > Some remarks: > > * Only Positive and Natural numerals in decimal representation are > supported. It would be cool to add support for Integers though. > > * The code is based on Oleg's implimentation of type-level binaries > http://okmij.org/ftp/Computation/resource-aware-prog/BinaryNumber.hs > > * exponentiation/log and GCD is not implemented yet > > * multiplication is not relational and thus division is broken. I > tried porting Oleg's multiplication algorithm without success. > > * Aliases (in binary, octal decimal and hexadecimal form) for > type-level values and their value-level reflection functions are > generated with TH. > That implies: > * Long compilation time depending on your system > * Although errors will always be reported in decimal form, the end > user can input values using other bases (only for values in the range > of generated aliases of course) > > * It would be cool to have "real" support for other bases apart from decimals > * It would imply having unlimited size of input for other bases > (right now if we want to input a value out of the alises limit, > decimal reprentation is mandatory) > * However, is it feasible? How could it be done without needing to > implement the operations for each base? WOuld it be possible to > "overload" the type-level operators so that they worked with different > representations and mixed representation arguments? > > * Booleans are not implemented (Wolfgang?) > > I would be happy to hear any suggestions, get code reviews and/or contributions. > > Cheers, > > Fons > > > > > > > > > On Feb 7, 2008 11:17 AM, Wolfgang Jeltsch wrote: >> Am Donnerstag, 7. Februar 2008 02:47 schrieb Alfonso Acosta: >>>> The other library I use for type-level programming is HList. It has >>>> type-level booleans already so you might what to take a look at it if >>>> you're not already familiar with it. >>> Thanks I'll have a look at it. >> I have to admit that I don't like the names HBool, HTrue and HFalse. What do >> they mean? Heterogenous booleans? Heterogenous truth? Why it's "Bool" >> instead of "Boolean" and therefore not conforming to the Prelude convention? >> >> Heterogenous lists are not directly about type level computation. A HList >> type is usually inhabited. On the other hand, types which denote type level >> naturals or type-level booleans are empty data types. So type level booleans >> should go into some type level programming library like the one Alfonso and I >> want to create. HList should then use these booleans. This is at least my >> opinion. >> >> Best wishes, >> Wolfgang >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From chaddai.fouche at gmail.com Thu Feb 7 13:21:32 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Thu Feb 7 15:12:34 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <7665bf90802070834g6944b089l39198a7dfb11ee1f@mail.gmail.com> References: <7665bf90802020232w3ede6fb4ibf12d9d1d99fff61@mail.gmail.com> <2eb8984a0802020457s68850ffg5d8dc8432a2aa3c4@mail.gmail.com> <2eb8984a0802020511y3215cce2m698d2af2baa562d8@mail.gmail.com> <7665bf90802070834g6944b089l39198a7dfb11ee1f@mail.gmail.com> Message-ID: 2008/2/7, Jeff ? : > I played with your foldl1MArray' last night. I noticed it can be reduced to > . . . > > foldl1MArray' :: (MArray a e m, Ix i) => (e -> e -> e) -> a i e -> m e > foldl1MArray' f a = do > (l,u) <- getBounds a > foldl1' (liftM2 f) (map (readArray a) (range (l,u))) > > Unfortunately, my new version consumes a lot of stack and heap space. Why > is this so inefficient? Is there a simple change that will make it > efficient? This code don't compute the results incrementally, it can't because foldl1' is not aware of the monad, it only construct a huge action in m which is then run. foldM advantage is that it can run incrementally. Which is not to say my code was the best possible (far from it), already the following would have been better : > foldlA f a arr = getBounds arr >>= > foldM (\a->a `seq` liftM $ f a) a > . map (readArray arr) . range > foldl1A f arr = getBounds arr >>= readArray arr . fst >>= > flip (foldlA f) arr -- Jeda? From alfonso.acosta at gmail.com Thu Feb 7 15:25:03 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Feb 7 15:23:58 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <47AB638D.602@imageworks.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <8b2a1a960802061730m558f9a77te4c9647ff06c1b4@mail.gmail.com> <6a7c66fc0802061747s1713da91v9083396f381a657c@mail.gmail.com> <200802071117.48786.g9ks157k@acme.softbase.org> <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> <47AB638D.602@imageworks.com> Message-ID: <6a7c66fc0802071225t4f777a6as993afbd892cab2cf@mail.gmail.com> On Feb 7, 2008 9:01 PM, Dan Weston wrote: > This may be a GHC bug, but even though in the module > Data.TypeLevel.Num.Reps has the header > > {-# LANGUAGE EmptyDataDecls, TypeOperators #-} > > I still get an error with both ghc and ghci version 6.8.2 unless I throw > in the -XTypeOperators flag. If you are using type operators in a module you have to supply the flag, independently of what flags are supplied in other modules. The same applies for other extensions which modify the _syntax_ of the language (e.g. Template Haskell etc ...) So, it's not a bug. As a side note, even if the TypeOperators flag is supplied GHC 6.8.2 fires an error with the following declaration: instance (Compare x y CEQ) => x :==: y -- GHC fires a "Malformed instance header" error whereas using an equivalent prefix definition works just fine instance (Compare x y CEQ) => (:==:) x y From chad.scherrer at gmail.com Thu Feb 7 15:30:53 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Thu Feb 7 15:29:54 2008 Subject: [Haskell-cafe] :i and :t give different types In-Reply-To: <20080207195731.GE19014@scytale.galois.com> References: <20080207194718.GD19014@scytale.galois.com> <2f9b2d30802071155m2fa88eearaf6d368c61ed2b3a@mail.gmail.com> <20080207195731.GE19014@scytale.galois.com> Message-ID: On Feb 7, 2008 11:57 AM, Don Stewart wrote: > Ah, yes, missing parens! Well spotted. > > So a pretty printer wibble in GHC? > > -- Don Yeah, that was my first concern, but then I noticed the quantification was different, so I'm still working through that one. It was confusing, since I assumed the implementations of :i and :t shared a lot of code. -- Chad From agl at imperialviolet.org Thu Feb 7 16:30:34 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Feb 7 16:29:28 2008 Subject: [Haskell-cafe] question concerning ANSI "void *" In-Reply-To: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> References: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> Message-ID: <396556a20802071330y7c788fbet2b1d57f72f4f0271@mail.gmail.com> 2008/2/7 Galchin Vasili : > Ok .. I am writing a Haskell function that will call down into the ANSI > C library .. blah :: .... -> Ptr Word8 ....-> .... The underlying C function > that "blah" is calling has a "void *" so I am using "Ptr Word 8" to model > the "void *". Depending on the context, "void *" is generally either taken as a Ptr () (for an opaque pointer) or Ptr Word8 (for calls like memcpy). > I propose to have the callers of function "blah" to populate a > data structure something like "Ptr Buz" where "data Buz = { ........} and > then do a "recast :: Ptr Word 8 -> Ptr Buz" when invoking function "blah". > Does this seem reasonable? Is there a better way? Generally, Ptr x is only used where x is either a shadow type or a Bits type. Having a Ptr Baz where Baz is an ADT seems a little odd. If you need to translate a structure from Haskell to C code, probably you are better off having callers pass in a Baz then, internal to the wrapping, fill out the C structure and call the FFI function with a Ptr CBaz (where CBaz is a shadow type). AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From dons at galois.com Thu Feb 7 18:11:47 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 7 18:10:47 2008 Subject: [Haskell-cafe] User groups meeting all over the world Message-ID: <20080207231147.GI19014@scytale.galois.com> The community might be interested to know that there are (at least) 7 Haskell/FP user groups meeting across the world in the next two weeks! FringeDC Washington DC/USA February 9 PDXFunc Portland/USA February 11 Fun in the afternoon London/UK February 12 BayFP San Francisco/USA February 13 Saint-Petersburg Haskell User Group Saint-Petersburg/Russia. February 16 NYFP Network New York/USA February 19 NWFPIG: Seattle FP Group Seattle/USA February 20 The Austin (Texas) group met a couple of weeks ago. This is a great development -- a year ago I don't think we had *any* groups meeting regularly. Consider dropping in to one, if there's a meetting near you, or starting your own group! All groups we know about are listed here: http://www.haskell.org/haskellwiki/User_groups -- Don From bulat.ziganshin at gmail.com Thu Feb 7 09:49:43 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 7 18:12:05 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> <1252070813.20080206203931@gmail.com> <20080207010403.GC10247@cs.cmu.edu> <1675514121.20080207132320@gmail.com> Message-ID: <937662766.20080207174943@gmail.com> Hello Henning, Thursday, February 7, 2008, 4:27:30 PM, you wrote: >> ok, read this as "computer can ensure...", because it was exactly the >> original question - "can computer check that any given function in >> turing-complete language is non-trivial?" > My original question according to > > http://www.haskell.org/pipermail/haskell-cafe/2008-February/039161.html > was "Is Haskell's type system including extensions strong enough for > describing a function, that does not always return a trivial value?" where Haskell is *turing-complete* *computer* language this allows to answer to your question that you need to use special, non-turing language if you want to check arbitrary functions for non-trivialness. one example of such language: data Func = ConstTrue | ConstFalse and dependent-typed languages provides you (afaiu) much richer facilities to describe functions for which you still may prove something useful so, if you term "function" includes the Func type, the answer is "yes", but if you mean usual haskell functions, the answer is no -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ryani.spam at gmail.com Thu Feb 7 18:14:54 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Feb 7 18:13:50 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <65d7a7e0802062332q4131363ey6503bf75b996e54f@mail.gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> <1495211458.20080206123008@gmail.com> <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> <65d7a7e0802062332q4131363ey6503bf75b996e54f@mail.gmail.com> Message-ID: <2f9b2d30802071514i7cf5baaenfcc85ef6e388c06b@mail.gmail.com> On 2/6/08, Uwe Hollerbach wrote: > And, coming back to my scheme interpreter, this is at least somewhat > irrelevant, because, since I am in a REPL of my own devising, I'm > firmly in IO-monad-land, now and forever. This is not entirely true; a REPL can be pure. Consider the following simple stack-based-calculator; all the IO happens within "interact", the REPL itself is pure: import System.IO main = hSetBuffering stdout NoBuffering >> interact replMain replMain s = "Stack calculator\n> " ++ repl [] s repl :: [Int] -> String -> String repl _ [] = "" repl _ ('q':_) = "" repl s ('\n':xs) = show s ++ "\n> " ++ repl s xs repl s xs@(x:_) | x >= '0' && x <= '9' = let (v, xs') = head $ reads xs in repl (v:s) xs' repl s (c:xs) | c `elem` validCommands = case command c s of Just s' -> repl s' xs Nothing -> "\n" ++ repl s xs repl s (_:xs) = repl s xs -- ignore unrecognized characters validCommands = ".d+c" command :: Char -> [Int] -> Maybe [Int] command '.' (x:xs) = Just xs command 'd' (x:xs) = Just $ x:x:xs command '+' (x:y:xs) = Just $ (x+y):xs command 'c' _ = Just [] command _ _ = Nothing You can go further than "interact" if you want to abstract away the impurity in your system and take input from some outside process which has a limited set of impure operations. Take a look here for an example using "Prompt" (which has seen some discussion here on haskell-cafe): http://paste.lisp.org/display/53766 In that example, "guess n" is an action in the pure Prompt monad; different interpretation functions allow this monad to interact with an AI (in a semi-pure setting; it outputs strings), or with a real player via the full IO interface. A similar mechanism could be used for the scheme REPL to make it as "pure" as possible, with "getClockTime" being replaced by "prompt GetClockTime" to interact with the outside world. From prstanley at ntlworld.com Thu Feb 7 18:21:18 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Thu Feb 7 18:20:27 2008 Subject: [Haskell-cafe] User groups meeting all over the world In-Reply-To: <20080207231147.GI19014@scytale.galois.com> References: <20080207231147.GI19014@scytale.galois.com> Message-ID: <7.0.1.0.0.20080207231310.01d14eb0@ntlworld.com> I will only consider events where they serve free tea and sandwiches, plus if there's a landing pad for the chopper nearby. :-) At 23:11 07/02/2008, you wrote: >The community might be interested to know that there are (at least) >7 Haskell/FP user groups meeting across the world in the next two >weeks! > > FringeDC Washington DC/USA February 9 > PDXFunc Portland/USA February 11 > Fun in the afternoon London/UK February 12 > BayFP San Francisco/USA February 13 > Saint-Petersburg Haskell User Group Saint-Petersburg/Russia. February 16 > NYFP Network New York/USA February 19 > NWFPIG: Seattle FP Group Seattle/USA February 20 > >The Austin (Texas) group met a couple of weeks ago. > >This is a great development -- a year ago I don't think we had *any* >groups meeting regularly. > >Consider dropping in to one, if there's a meetting near you, or >starting your own group! > >All groups we know about are listed here: > > http://www.haskell.org/haskellwiki/User_groups > >-- Don >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe@haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe From drl at cs.cmu.edu Thu Feb 7 18:46:54 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Thu Feb 7 18:45:51 2008 Subject: [Haskell-cafe] Signature for non-empty filter In-Reply-To: <937662766.20080207174943@gmail.com> References: <1542297371.20080205182543@gmail.com> <38610660.20080206172214@gmail.com> <1252070813.20080206203931@gmail.com> <20080207010403.GC10247@cs.cmu.edu> <1675514121.20080207132320@gmail.com> <937662766.20080207174943@gmail.com> Message-ID: <20080207234654.GB17779@cs.cmu.edu> Hi Bulat, Once again, let's be careful about what "check arbitrary functions for termination/non-trivialness" means. If you mean, "decide via an algorithm whether a function is terminating on all inputs", then yes, you need to restrict the class of functions. If you mean "prove in some logic that a function is terminating on all inputs", then there is no reason to restrict the class of functions. (Think of it this way: the truth of propositions in that logic may not be decidable, so the existence of a proof of termination in that logic does not imply an algorithm for deciding termination.) ACL2 and Twelf are practical systems built around this second kind of reasoning. In these systems, you write down partial functions (in a functional notation in ACL2, in a logic programming notation in Twelf) and then prove that they are terminating, and therefore total. Both systems permit the definition of all computable functions on the natural numbers (worst comes to worst, you can write an interpreter for the untyped lambda-calculus). So in neither system is it *decidable* whether a function is terminating. However, both provide helpful tools for proving that individual functions are terminating, and in both systems you can help these tools along yourself when the automated reasoning doesn't do the job. Many dependently typed programming languages have this flavor, in that you can prove propositions that are not decidable. Propositions are represented by types, and proofs by programs, so the truth of a proposition comes down to the existence of a term of a particular type. There is no reason that type inhabitation (and therefore all propositions) needs to be decidable. So it is perfeclty possible to have a dependent type system where you give filter the type "for all satisfiable f" where f ranges over all computable functions of the appropriate type, even though this proposition is not decidable. -Dan On Feb07, Bulat Ziganshin wrote: > Hello Henning, > > Thursday, February 7, 2008, 4:27:30 PM, you wrote: > > >> ok, read this as "computer can ensure...", because it was exactly the > >> original question - "can computer check that any given function in > >> turing-complete language is non-trivial?" > > > My original question according to > > > > http://www.haskell.org/pipermail/haskell-cafe/2008-February/039161.html > > was "Is Haskell's type system including extensions strong enough for > > describing a function, that does not always return a trivial value?" > > where Haskell is *turing-complete* *computer* language > > this allows to answer to your question that you need to use special, > non-turing language if you want to check arbitrary functions for > non-trivialness. one example of such language: > > data Func = ConstTrue | ConstFalse > > and dependent-typed languages provides you (afaiu) much richer > facilities to describe functions for which you still may prove > something useful > > so, if you term "function" includes the Func type, the answer is > "yes", but if you mean usual haskell functions, the answer is no > > From alfonso.acosta at gmail.com Thu Feb 7 19:15:00 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Feb 7 19:13:53 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <47AB5E48.9000400@imageworks.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071117.48786.g9ks157k@acme.softbase.org> <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <47AB5E48.9000400@imageworks.com> Message-ID: <6a7c66fc0802071615y72617686pf9b157f69cd0ecb9@mail.gmail.com> On Feb 7, 2008 8:38 PM, Dan Weston wrote: > I know that naming is arbitrary, but... > > Digits in types seems ugly to me. In this case, it is also redundant. > Everyone but FORTRAN programmers counts from 0, not 1. Nat and Pos seem > clear. Nat0 could even mean Nat \ {0}, the opposite of what is proposed, > so confusion is even increased with Nat0. Ok, fair enough. I changed the names of Positives and Naturals (which do include 0) for Pos and Nat. The change (together with a connective rename from :+ to :* ) is already pushed in the darcs repository. From ok at cs.otago.ac.nz Thu Feb 7 19:22:51 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Feb 7 19:21:47 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <47AB5E48.9000400@imageworks.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071117.48786.g9ks157k@acme.softbase.org> <6a7c66fc0802070656q30e58c25r9b9c445b35cc4510@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <47AB5E48.9000400@imageworks.com> Message-ID: On 8 Feb 2008, at 8:38 am, Dan Weston wrote: > I know that naming is arbitrary, but... > > Digits in types seems ugly to me. In this case, it is also > redundant. Everyone but FORTRAN programmers counts from 0, not 1. > Nat and Pos seem clear. Nat0 could even mean Nat \ {0}, the > opposite of what is proposed, so confusion is even increased with > Nat0. For what it's worth, the Ada names for the types {x in Z | x >= 0} and {x in Z | x > 0} are "Natural" and "Positive" respectively. Natural is useful for counting stuff; Positive is useful mainly because Ada practice is to index from 1. In Z, |N is used for natural numbers, which are defined to include 0. In modern set theory, both the cardinal and the ordinal numbers start with 0, not with 1. All things considered, I would be very upset indeed if a type called "Nat" or "Natural" or something like that did not include 0. From keith at oreilly.com Thu Feb 7 19:46:46 2008 From: keith at oreilly.com (Keith Fahlgren) Date: Thu Feb 7 19:45:46 2008 Subject: [Haskell-cafe] User groups meeting all over the world In-Reply-To: <7.0.1.0.0.20080207231310.01d14eb0@ntlworld.com> References: <20080207231147.GI19014@scytale.galois.com> <7.0.1.0.0.20080207231310.01d14eb0@ntlworld.com> Message-ID: <47ABA676.7010401@oreilly.com> On 2/7/08 3:21 PM, PR Stanley wrote: > I will only consider events where they serve free tea and sandwiches, > plus if there's a landing pad for the chopper nearby. :-) BayFP's next one _might_ be at a place rhyming with "Loogle"[1], so that'd be organic tea and I'm certain there's a landing pad.... HTH, Keith 1. We're still working on the location From ben.franksen at online.de Thu Feb 7 20:07:43 2008 From: ben.franksen at online.de (Ben Franksen) Date: Thu Feb 7 20:09:45 2008 Subject: [Haskell-cafe] Re: modeling ANSI C structs in Haskell? References: <5ae4f2ba0802040704o6dafd4eawf2a452c65e1dc8fc@mail.gmail.com> Message-ID: Galchin Vasili wrote: > I am reading through the FFI doc. Any suggestions on enabling > Haskell > programmers to model ANSI C structs that will be passed down to C > run-time? If you have a C function that needs to be passed a struct, then there are three scenarios: (a) A common situation is that your C struct is opaque (or at least meant to be used opaquely). You'll have explicit allocate+construct functions as well as deallocate+destruct functions in your C library. This means that you don't care at all how to marshall the struct, you don't even (need to) know how it looks like. All you work with is pointers (i.e. Ptr a, or Ptr X where X is an empty data type). You can use ForeignPtr to automatically call the Library provided destructor when the GC finds that the pointer is no longer accessible in your program (from the Haskell side). (b) In case the C function expects a pointer to a user allocated struct, your type X will probably be a Haskell record, and you want to make X an instance of class Storable. You can allocate and deallocate the C struct by using one of the functions provided by Foreign.Marshal.Alloc. (c) Most uncommon (though not not unheard of): the function gets the struct passed by value. This means you can't write the FFI code completely in Haskell because Haskell FFI can only work with C primitive types (numbers, pointers, etc). You need to write a little C wrapper to convert pass-by-value to pass-by-reference. Then see case (b). HTH Ben From jonathanccast at fastmail.fm Thu Feb 7 21:44:20 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 7 21:43:14 2008 Subject: [Haskell-cafe] :i and :t give different types In-Reply-To: References: <20080207194718.GD19014@scytale.galois.com> <2f9b2d30802071155m2fa88eearaf6d368c61ed2b3a@mail.gmail.com> <20080207195731.GE19014@scytale.galois.com> Message-ID: On 7 Feb 2008, at 12:30 PM, Chad Scherrer wrote: > On Feb 7, 2008 11:57 AM, Don Stewart wrote: >> Ah, yes, missing parens! Well spotted. >> >> So a pretty printer wibble in GHC? >> >> -- Don > > Yeah, that was my first concern, but then I noticed the quantification > was different, so I'm still working through that one. The quantification isn't different, just differently presented. In Haskell 98, there are never explicit foralls and any type is implicitly quantified over its free variables at the top level. So, in GHC a type without explicit foralls is quantified over its free variables at the top level. So the two types are in fact equal. > It was confusing, since I assumed the implementations of :i and :t > shared a lot of code. Apparently not :) jcc From uhollerbach at gmail.com Fri Feb 8 01:03:20 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Fri Feb 8 01:02:13 2008 Subject: [Haskell-cafe] background question about IO monad In-Reply-To: <2f9b2d30802071514i7cf5baaenfcc85ef6e388c06b@mail.gmail.com> References: <65d7a7e0802052044y6a09554ci306114a503815ea9@mail.gmail.com> <1495211458.20080206123008@gmail.com> <65d7a7e0802061930j1c00e560j801a3a2225adc32d@mail.gmail.com> <3EB6DEEF-0D0B-4847-8A68-7C94A0C10531@fastmail.fm> <65d7a7e0802062332q4131363ey6503bf75b996e54f@mail.gmail.com> <2f9b2d30802071514i7cf5baaenfcc85ef6e388c06b@mail.gmail.com> Message-ID: <65d7a7e0802072203m14670d1kc84390f138acde28@mail.gmail.com> Thanks, I'm going to have to study this a bit... Uwe On 2/7/08, Ryan Ingram wrote: > On 2/6/08, Uwe Hollerbach wrote: > > And, coming back to my scheme interpreter, this is at least somewhat > > irrelevant, because, since I am in a REPL of my own devising, I'm > > firmly in IO-monad-land, now and forever. > > This is not entirely true; a REPL can be pure. > > Consider the following simple stack-based-calculator; all the IO > happens within "interact", the REPL itself is pure: > > import System.IO > > main = hSetBuffering stdout NoBuffering >> interact replMain > > replMain s = "Stack calculator\n> " ++ repl [] s > > repl :: [Int] -> String -> String > repl _ [] = "" > repl _ ('q':_) = "" > repl s ('\n':xs) = show s ++ "\n> " ++ repl s xs > repl s xs@(x:_) | x >= '0' && x <= '9' = > let (v, xs') = head $ reads xs in repl (v:s) xs' > repl s (c:xs) | c `elem` validCommands = case command c s of > Just s' -> repl s' xs > Nothing -> "\n" ++ repl s xs > repl s (_:xs) = repl s xs -- ignore unrecognized characters > > validCommands = ".d+c" > command :: Char -> [Int] -> Maybe [Int] > command '.' (x:xs) = Just xs > command 'd' (x:xs) = Just $ x:x:xs > command '+' (x:y:xs) = Just $ (x+y):xs > command 'c' _ = Just [] > command _ _ = Nothing > > You can go further than "interact" if you want to abstract away the > impurity in your system and take input from some outside process which > has a limited set of impure operations. Take a look here for an > example using "Prompt" (which has seen some discussion here on > haskell-cafe): http://paste.lisp.org/display/53766 > > In that example, "guess n" is an action in the pure Prompt monad; > different interpretation functions allow this monad to interact with > an AI (in a semi-pure setting; it outputs strings), or with a real > player via the full IO interface. A similar mechanism could be used > for the scheme REPL to make it as "pure" as possible, with > "getClockTime" being replaced by "prompt GetClockTime" to interact > with the outside world. > From tomahawkins at gmail.com Fri Feb 8 01:33:35 2008 From: tomahawkins at gmail.com (Tom Hawkins) Date: Fri Feb 8 01:32:27 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. Message-ID: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> I've been programming with Haskell for a few years and love it. One of my favorite applications of Haskell is using for domain specific languages. However, after designing a handful of DSLs, I continue to hit what appears to be a fundamental hurdle -- or at least I have yet to find an adequate solution. My DSLs invariably define a datatype to capture expressions; something like this: data Expression = Add Expression Expression | Sub Expression Expression | Variable String | Constant Int deriving Eq Using the datatype Expression, it is easy to mass a collections of functions to help assemble complex expressions, which leads to very concise programs in the DSL. The problem comes when I want to generate efficient code from an Expression (ie. to C or some other target language). The method I use invovles converting the tree of subexpressions into an acyclic graphic to eliminate common subexpressions. The nodes are then topologically ordered and assigned an instruction, or statement for each node. For example: let a = Add (Constant 10) (Variable "i1") b = Sub (Variable "i2") (Constant 2) c = Add a b would compile to a C program that may look like this: a = 10 + i1; b = i2 - 2; c = a + b; The process of converting an expression tree to a graph uses either Eq or Ord (either derived or a custom instance) to search and build a set of unique nodes to be ordered for execution. In this case "a", then "b", then "c". The problem is expressions often have shared, equivalent subnodes, which dramatically grows the size of the tree. For example: let d = Add c c e = Add d d -- "e" now as 16 leaf nodes. As these trees grow in size, the equality comparison in graph construction quickly becomes the bottleneck for DSL compilation. What's worse, the phase transition from tractable to intractable is very sharp. In one of my DSL programs, I made a seemingly small change, and compilation time went from milliseconds to not-in-a-million-years. Prior to Haskell, I wrote a few DSLs in OCaml. I didn't have this problem in OCaml because each "let" expression was mutable, and I could use the physical equality operator to perform fast comparisons. Unfortunately, I have grown to love Haskell's type system and its lack of side effects, and could never go back. Is there anything that can be done to dramatically speed up comparisons, or is there a better approach I can take to extract common subexpressions? I should point out I have an opportunity to get Haskell on a real industrial application. But if I can't solve this problem, I may have to resort to far less eloquent languages. :-( Thanks for any and all help. -Tom From alfonso.acosta at gmail.com Fri Feb 8 01:57:41 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Feb 8 01:56:33 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> Message-ID: <6a7c66fc0802072257x2cf475bvbafd19990b4146ba@mail.gmail.com> As I pointed out a few days ago in another thread, you can benefit from using Observable sharing [1] Be warned that Observable sharing is a non-conservative extension of Haskell and it breaks referential transparency. [1] http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html On Feb 8, 2008 7:33 AM, Tom Hawkins wrote: > I've been programming with Haskell for a few years and love it. One > of my favorite applications of Haskell is using for domain specific > languages. However, after designing a handful of DSLs, I continue to > hit what appears to be a fundamental hurdle -- or at least I have yet > to find an adequate solution. > > My DSLs invariably define a datatype to capture expressions; something > like this: > > data Expression > = Add Expression Expression > | Sub Expression Expression > | Variable String > | Constant Int > deriving Eq > > Using the datatype Expression, it is easy to mass a collections of > functions to help assemble complex expressions, which leads to very > concise programs in the DSL. > > The problem comes when I want to generate efficient code from an > Expression (ie. to C or some other target language). The method I use > invovles converting the tree of subexpressions into an acyclic graphic > to eliminate common subexpressions. The nodes are then topologically > ordered and assigned an instruction, or statement for each node. For > example: > > let a = Add (Constant 10) (Variable "i1") > b = Sub (Variable "i2") (Constant 2) > c = Add a b > > would compile to a C program that may look like this: > > a = 10 + i1; > b = i2 - 2; > c = a + b; > > The process of converting an expression tree to a graph uses either Eq > or Ord (either derived or a custom instance) to search and build a set > of unique nodes to be ordered for execution. In this case "a", then > "b", then "c". The problem is expressions often have shared, > equivalent subnodes, which dramatically grows the size of the tree. > For example: > > let d = Add c c > e = Add d d -- "e" now as 16 leaf nodes. > > As these trees grow in size, the equality comparison in graph > construction quickly becomes the bottleneck for DSL compilation. > What's worse, the phase transition from tractable to intractable is > very sharp. In one of my DSL programs, I made a seemingly small > change, and compilation time went from milliseconds to > not-in-a-million-years. > > Prior to Haskell, I wrote a few DSLs in OCaml. I didn't have this > problem in OCaml because each "let" expression was mutable, and I > could use the physical equality operator to perform fast comparisons. > Unfortunately, I have grown to love Haskell's type system and its lack > of side effects, and could never go back. > > Is there anything that can be done to dramatically speed up > comparisons, or is there a better approach I can take to extract > common subexpressions? I should point out I have an opportunity to > get Haskell on a real industrial application. But if I can't solve > this problem, I may have to resort to far less eloquent languages. > :-( > > Thanks for any and all help. > > -Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From emax at cs.chalmers.se Fri Feb 8 02:00:08 2008 From: emax at cs.chalmers.se (Emil Axelsson) Date: Fri Feb 8 01:58:20 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> Message-ID: <47ABFDF8.9040800@cs.chalmers.se> I know of a few of ways to express sharing in a pure language: 1) "Observable sharing", which, in general, is unsafe. http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html 2) Using Template Haskell http://www.dcs.gla.ac.uk/publications/PAPERS/7524/EmbedHDLinTH.ps 3) Matthew Naylor has done some work on "expressible sharing", which has advantages over both methods above. I don't have any reference though... 4) Use a monad (but I'm sure this is what you're trying to avoid). / Emil On 2008-02-08 07:33, Tom Hawkins wrote: > I've been programming with Haskell for a few years and love it. One > of my favorite applications of Haskell is using for domain specific > languages. However, after designing a handful of DSLs, I continue to > hit what appears to be a fundamental hurdle -- or at least I have yet > to find an adequate solution. > > My DSLs invariably define a datatype to capture expressions; something > like this: > > data Expression > = Add Expression Expression > | Sub Expression Expression > | Variable String > | Constant Int > deriving Eq > > Using the datatype Expression, it is easy to mass a collections of > functions to help assemble complex expressions, which leads to very > concise programs in the DSL. > > The problem comes when I want to generate efficient code from an > Expression (ie. to C or some other target language). The method I use > invovles converting the tree of subexpressions into an acyclic graphic > to eliminate common subexpressions. The nodes are then topologically > ordered and assigned an instruction, or statement for each node. For > example: > > let a = Add (Constant 10) (Variable "i1") > b = Sub (Variable "i2") (Constant 2) > c = Add a b > > would compile to a C program that may look like this: > > a = 10 + i1; > b = i2 - 2; > c = a + b; > > The process of converting an expression tree to a graph uses either Eq > or Ord (either derived or a custom instance) to search and build a set > of unique nodes to be ordered for execution. In this case "a", then > "b", then "c". The problem is expressions often have shared, > equivalent subnodes, which dramatically grows the size of the tree. > For example: > > let d = Add c c > e = Add d d -- "e" now as 16 leaf nodes. > > As these trees grow in size, the equality comparison in graph > construction quickly becomes the bottleneck for DSL compilation. > What's worse, the phase transition from tractable to intractable is > very sharp. In one of my DSL programs, I made a seemingly small > change, and compilation time went from milliseconds to > not-in-a-million-years. > > Prior to Haskell, I wrote a few DSLs in OCaml. I didn't have this > problem in OCaml because each "let" expression was mutable, and I > could use the physical equality operator to perform fast comparisons. > Unfortunately, I have grown to love Haskell's type system and its lack > of side effects, and could never go back. > > Is there anything that can be done to dramatically speed up > comparisons, or is there a better approach I can take to extract > common subexpressions? I should point out I have an opportunity to > get Haskell on a real industrial application. But if I can't solve > this problem, I may have to resort to far less eloquent languages. > :-( > > Thanks for any and all help. > > -Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From bulat.ziganshin at gmail.com Fri Feb 8 02:09:16 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 8 03:08:59 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> Message-ID: <1331901839.20080208100916@gmail.com> Hello Tom, Friday, February 8, 2008, 9:33:35 AM, you wrote: > The process of converting an expression tree to a graph uses either Eq > or Ord (either derived or a custom instance) to search and build a set > of unique nodes to be ordered for execution. in similar situation, i've added hash field to each node, initialized by smart constructor: data Expression = Add Hash Expression Expression | ... type Hash=Int add x y = Add (x*y+1234567) x y ... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Fri Feb 8 03:16:31 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 8 03:15:24 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> Message-ID: On Fri, 8 Feb 2008, Tom Hawkins wrote: > I've been programming with Haskell for a few years and love it. One > of my favorite applications of Haskell is using for domain specific > languages. However, after designing a handful of DSLs, I continue to > hit what appears to be a fundamental hurdle -- or at least I have yet > to find an adequate solution. It seems to become a FAQ. I think all DSLs suffer from the same problems: sharing and recursion. I've used wrappers for CSound, SuperCollider, MetaPost, they all have these problems. From ithika at gmail.com Fri Feb 8 04:12:23 2008 From: ithika at gmail.com (Dougal Stanton) Date: Fri Feb 8 04:11:15 2008 Subject: [Haskell-cafe] FP and Quality In-Reply-To: <792941.88805.qm@web30208.mail.mud.yahoo.com> References: <7.0.1.0.0.20080204235058.01d00a98@ntlworld.com> <792941.88805.qm@web30208.mail.mud.yahoo.com> Message-ID: <2d3641330802080112h1f110b72v83fa84f1cd22f29e@mail.gmail.com> On 07/02/2008, Benjamin L. Russell wrote: > ----- text follows immediately after this line ----- > Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment > in Software Prototyping Productivity (1994), > by Paul Hudak and Mark P. Jones: > http://citeseer.ist.psu.edu/41732.html This one's quite interesting but refers to the much longer report. In the bibliography it is listed as unpublished, but during the text the authors suggest you read it anyway. Does anyone have a source for this document. (A quick search has only produced further citations in other places.) J.A.N. Lee, B. Blum, P. Kanellakis, H. Crisp, and J.A. Caruso. ProtoTech HiPer-D Joint Prototyping Demonstration Project, February 1994. Unpublished; 400 pages. Cheers, D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From g9ks157k at acme.softbase.org Fri Feb 8 04:57:44 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Feb 8 04:56:58 2008 Subject: [Haskell-cafe] Draft chapters of "Real World Haskell" =?utf-8?q?now=09publicly?= available In-Reply-To: <000601c869af$814a1b90$83de52b0$@be> References: <4794F854.1050008@serpentine.com> <200802071225.24114.g9ks157k@acme.softbase.org> <000601c869af$814a1b90$83de52b0$@be> Message-ID: <200802081057.44710.g9ks157k@acme.softbase.org> Am Donnerstag, 7. Februar 2008 18:33 schrieben Sie: > Interesting. Thanks for the reply. > > It might be nice to have some performance benchmarks for all these > experimental systems, so we can compare them. I think, the most important thing is the asymptotical time behavior, e.g., whether the time of a certain task is linear, logarithmic or constant in the number of widgets. Constant factors can always be improved. So performance benchmarks don?t seem so important to me in the current early state of FRP GUI libraries. > I could understand that performance might be an issue for games, but for > GUIs? I mean many imperative GUI systems use rather slow message > dispatching systems, and we use those every day. Look at the new Windows > Presentation Foundation system found in VISTA. Here events are broadcasted > and routed through the whole element tree. This is also rather slow I > guess. Are they rooted through every node of the tree (linear time) or are they routed down the tree to a leaf (not more than logarithmic time, probably). The latter would be acceptable, the former not. The problem I noted on the Grapefruit talk page might result in a Yampa-based GUI taking linear time for handling a single event (but I?m not completely sure about that). Does Vista?s event handling really have linear behavior as your statement seems to suggest? Best wishes, Wolfgang From simonmarhaskell at gmail.com Fri Feb 8 05:46:25 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 8 05:45:21 2008 Subject: [Haskell-cafe] Re: threads + IORefs = Segmentation fault? In-Reply-To: <20080118232255.GF6197@darcs.net> References: <20080118232255.GF6197@darcs.net> Message-ID: <47AC3301.8040500@microsoft.com> David Roundy wrote: > I'm working on some new progress-reporting code for darcs, and am getting > segmentation faults! :( The code uses threads + an IORef global variable > to do this (with lots of unsafePerformIO). So my question for the gurus > who know more about this than I do: is this safe? I thought it would be, > because only one thread ever modifies the IORef, and the others only read > it. I don't really care if they read a correct value, as long as they > don't segfault. > > The code (to summarize) looks like: > > {-# NOINLINE _progressData #-} > _progressData :: IORef (Map String ProgressData) > _progressData = unsafePerformIO $ newIORef empty > > updateProgressData :: String -> (ProgressData -> ProgressData) -> IO () > updateProgressData k f = when (progressMode) $ modifyIORef _progressData (adjust f k) > > setProgressData :: String -> ProgressData -> IO () > setProgressData k p = when (progressMode) $ modifyIORef _progressData (insert k p) > > getProgressData :: String -> IO (Maybe ProgressData) > getProgressData k = if progressMode then lookup k `fmap` readIORef _progressData > else return Nothing (I'm a bit behind with haskell-cafe, sorry for not seeing this sooner...) Yes, that should all be fine, because the IORef is only modified from one thread, and read from the other(s). If you were modifying the IORef from more than one thread you would need to use atomicallyModifyIORef, or MVars. Cheers, Simon From mfn-haskell-cafe at cs.york.ac.uk Fri Feb 8 05:56:12 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Fri Feb 8 05:57:21 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <47ABFDF8.9040800@cs.chalmers.se> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> Message-ID: <20080208105612.GA19796@venice.staff.cs.york.ac.uk> Hi, (Warning: longish message!) There is some concern, and rightly so, that observable sharing is dangerous, and that your Haskell program will explode if you use it, and perhaps even that anyone who uses it is "dirty" and should be sent to matron's for a good scrubbing! However, when used "safely", it is not a hack, nor even dirty, but a nice, simple solution to an otherwise nasty problem. Below I define what I mean by "safely". First consider the circumstances under which obserevable sharing is useful. Typically we have some Haskell function "f" that produces a symbolic representation of an expression. For whatever reason, we'd like to *generate a program* that computes the value of this expression, rather that computing it in Haskell. For example, in Lava, we want to generate a VHDL program so that the expression can be computed on, say, an FPGA. In Tom's case, he wants to generate a C program to compute the expression. All perfectly reasonable, and in my opinion, a very powerfull way to use Haskell. Now recall that referential transparency lets you replace equals with equals without changing the *value produced* by a program. Note that it says nothing about preserving *runtime behaviour*. Sharing, for example, may be lost. So if you do equational reasoning on function "f" (above), and loose some sharing, then you can only expect that the same sharing will also be also lost in the generated program. As long as the generated program computes the same result as it did before, referential transparency will be, overall, preserved; it would only be lost intermediately. This is what I mean by "safe". Now, there remains the concern that Haskell's semantics does not enforce sharing. A Haskell compiler is free to change the sharing a program at a whim, unknowingly to the programmer who may be relying on it in for an efficient program. However, to my knowledge, it is an unwritten rule of Haskell compilers that sharing *is* preserved, and that they do perform *graph* reduction. Clean, a similar language to Haskell, indeed has a semantics based on graphs. So I don't believe Haskell being non-strict (not necessarily lazy) is a good reason for not using observable sharing. Though I do feel better when I compile without -O. :-) Finally, when I say "observable sharing", I don't necessarily mean it as defined by Koen Claessen and David Sands. I simply mean the use of unsafePerformIO to detect sharing, whether or not this is done by an "eq" predicate on Refs. (I say this because I think there are simpler ways to detect sharing, though these will probably not have the nice semantic properties of observable sharing.) Sorry for the somewhat long exposition. :-) Matt. From news at lyra.net Fri Feb 8 07:12:07 2008 From: news at lyra.net (news@lyra.net) Date: Fri Feb 8 07:11:17 2008 Subject: [Haskell-cafe] Create a list without duplicates from a list with duplicates Message-ID: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> Hallo! Let's suppose I have a list [a,b,c,d,c,d]. I'd like to write a function that returns a new list without duplicates (in the example [a,b,c,d]). How can I do that? What is the most general way? I'd like to use the same function for a list of Int or String or some other user defined data type. Thank for your attention! From jed at 59A2.org Fri Feb 8 07:21:01 2008 From: jed at 59A2.org (Jed Brown) Date: Fri Feb 8 07:19:24 2008 Subject: [Haskell-cafe] Create a list without duplicates from a list with duplicates In-Reply-To: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> (news@lyra.net's message of "Fri, 08 Feb 2008 13:12:07 +0100") References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> Message-ID: <87d4r71vwy.fsf@59A2.org> On 8 Feb 2008, news@lyra.net wrote: > Hallo! > > Let's suppose I have a list [a,b,c,d,c,d]. I'd like to write > a function that returns a new list without duplicates (in > the example [a,b,c,d]). How can I do that? What is the most > general way? I'd like to use the same function for a list of > Int or String or some other user defined data type. Look at Data.List: nub :: (Eq a) => [a] -> [a] nub = nubBy (==) nubBy :: (a -> a -> Bool) -> [a] -> [a] nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\ y -> not (eq x y)) xs) Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080208/5bd1e2ff/attachment.bin From ndmitchell at gmail.com Fri Feb 8 07:23:12 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 8 07:22:03 2008 Subject: [Haskell-cafe] Haskell maximum stack depth In-Reply-To: <47AB434F.10603@iee.org> References: <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> <404396ef0802060248q7c8bb272t62525b2451be9600@mail.gmail.com> <47AB3311.7000804@iee.org> <404396ef0802070856w6836370bjf0f616e55ac3aca@mail.gmail.com> <47AB434F.10603@iee.org> Message-ID: <404396ef0802080423jb9e92efwdad9e87bb8969683@mail.gmail.com> Hi > Yes, though testing stackGobbler with a large enough data set could > be problematic for the very reason we've been discsussing. Yes you are sure, or yes you tested and the results show than neilGobbler is x% slower and consume y% more memory on specific test n? > But let's say your hypothesis was correct. My hypothesis isn't that the stack is slow. > AFAICT neilGobbler isn't even entirely safe as an implementation of > an eager take. There's nothing the Haskell standard to stop it being > transformed into.. > > neilGobbler :: Int -> [x] -> [x] > neilGobbler n xs = length (take n xs) `seq` take n xs Yes, but so much in the Haskell standard is also missing. I think in this case you could reasonably argue that any compiler violating this _is_ violating the Haskell standard as it was intended (albeit not as it was written). You'll also find that the space behaviour of CAF's isn't documented in Haskell, but if people changed it you'd break quite a bit of the nofib suite. Thanks Neil From felipe.lessa at gmail.com Fri Feb 8 07:25:19 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri Feb 8 07:24:10 2008 Subject: [Haskell-cafe] Create a list without duplicates from a list with duplicates In-Reply-To: <87d4r71vwy.fsf@59A2.org> References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> <87d4r71vwy.fsf@59A2.org> Message-ID: 2008/2/8 Jed Brown : > Look at Data.List: > > nub :: (Eq a) => [a] -> [a] > nub = nubBy (==) > > nubBy :: (a -> a -> Bool) -> [a] -> [a] > nubBy eq [] = [] > nubBy eq (x:xs) = x : nubBy eq (filter (\ y -> not (eq x y)) xs) And then there's also sort :: (Ord a) => [a] -> [a] which should have better performance, O(n log n) against O(n?) I guess, but of course will change the order of the elements. If you really don't mind the order at all, you could also use Data.Set in the first place. Cheers, -- Felipe. From ndmitchell at gmail.com Fri Feb 8 07:26:06 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 8 07:24:57 2008 Subject: [Haskell-cafe] User groups meeting all over the world In-Reply-To: <20080207231147.GI19014@scytale.galois.com> References: <20080207231147.GI19014@scytale.galois.com> Message-ID: <404396ef0802080426s828f2efx5498be035ba6638c@mail.gmail.com> Hi > Fun in the afternoon London/UK February 12 Fun in the afternoon is great, but its not really a user group - it is still primarily an academic event, although is open to everyone. There is LUG, which is the London Haskell Users Group, which should definately be on this list. Thanks Neil From tux_rocker at reinier.de Fri Feb 8 08:20:06 2008 From: tux_rocker at reinier.de (Reinier Lamers) Date: Fri Feb 8 08:19:07 2008 Subject: [Haskell-cafe] Best practice for embedding files in a GHC-compiled tool? In-Reply-To: <48513191-0A26-44FD-8674-C0F3985CD7E2@math.columbia.edu> References: <9FA3427A-DC2B-4D81-9A7D-7D2765F86990@math.columbia.edu> <20080207052714.GB432795@localhost> <48513191-0A26-44FD-8674-C0F3985CD7E2@math.columbia.edu> Message-ID: <467D6DFC-10C4-444D-A830-E47CA9F65B2A@reinier.de> Op 7-feb-2008, om 13:53 heeft Dave Bayer het volgende geschreven: > > Under this extreme hypothesis, how do I embed a compressed tar file > into a single file command line tool written in Haskell and > compiled by GHC? Hack up a shell script or a small Haskell program to automatically generate a Haskell file of the form: > module TarFile where > > import Data.ByteString as B > > myTarFile = B.pack [] You could also do that using Template Haskell, as you already hinted, but this sounds less like rocket science :-) Reinier From chaddai.fouche at gmail.com Fri Feb 8 09:10:00 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Fri Feb 8 09:08:59 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <9979e72e0802071055v4b447441oc069b1d537769de6@mail.gmail.com> References: <9979e72e0802071055v4b447441oc069b1d537769de6@mail.gmail.com> Message-ID: Apr?s avoir un peu manipul? la solution de John pour qu'elle fasse la m?me chose que la mienne, je peux affirmer qu'elle est l?g?rement moins rapide (c'est infime et normal vu que ses leftFold passent plus d'informations), mais que les deux solutions ont au moins cet avantage d'?tre rapides (2s sur 10M de Double) et en m?moire parfaitement constante : ---- import Data.Array.MArray import Control.Monad import Data.Array.IO import System maxArr a = liftM (foldl1' max) (getElems a) foldlA :: (MArray a e m, Ix i) => (r -> e -> r) -> r -> a i e -> m r foldlA f a arr = getBounds arr >>= foldM (\a->a `seq` liftM $ f a) a . map (readArray arr) . range foldl1A :: (MArray a e m, Ix i) => (e -> e -> e) -> a i e -> m e foldl1A f arr = flip (foldlA f) arr =<< readArray arr . fst =<< getBounds arr foldMA :: (MArray a e m, Ix i) => (r -> e -> m r) -> r -> a i e -> m r foldMA f a arr = getBounds arr >>= foldM (\a->a `seq` (>>= f a)) a . map (readArray arr) . range modifyArray :: (MArray a e m, Ix i) => (e -> e) -> a i e -> m () modifyArray f arr = mapM_ (modifyElement f arr) . range =<< getBounds arr modifyElement :: (MArray a e m, Ix i) => (e -> e) -> a i e -> i -> m () modifyElement f arr i = writeArray arr i . f =<< readArray arr i main = do [n] <- getArgs a <- (newListArray (0, 10 ^ read n) [1..] :: IO (IOUArray Int Double)) maxE <- foldl1A max a modifyArray (* (1/maxE)) a print =<< readArray a (10 ^ read n) ---- En tout cas il serait agr?able d'avoir quelques unes de ces fonctions dans les librairies standards, vu qu'elles sont g?n?ralement utiles et tr?s efficace. Je n'utilise pas les langages fonctionnels pour avoir ? ?crire des boucles explicites sur mes structures de donn?es !! ;-) (et comme on l'a vu, pour un d?butant, l'?criture d'une g?n?ralisation efficace de ces boucles n'est pas si triviale qu'il y para?t). -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080208/4f576221/attachment.htm From chaddai.fouche at gmail.com Fri Feb 8 09:18:55 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Fri Feb 8 09:17:47 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: References: <9979e72e0802071055v4b447441oc069b1d537769de6@mail.gmail.com> Message-ID: Sorry for the french, I was a little bit confused... On 08/02/08, Chadda? Fouch? wrote : After I changed John's code so that it worked on the same dataset as mine, I could benchmark both of them : My solution is a bit faster (but that's a very tiny difference and to be expected since John's fold are more general than mine), but in any case, both solution are reasonably fast (2s on a 10M Double array (unboxed)) and don't eat any more memory than necessary : Anyway it would be nice to have some version of those function in the standard library (MArray) since they are pretty useful and efficient. I don't use functional language in order to have to code explicit loops on my data structures !! ;-) (And as we saw, to write an efficient generalisation of those loops isn't as easy as it might seems) -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080208/4b67917f/attachment.htm From catamorphism at gmail.com Fri Feb 8 10:02:57 2008 From: catamorphism at gmail.com (Tim Chevalier) Date: Fri Feb 8 10:01:51 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <20080208105612.GA19796@venice.staff.cs.york.ac.uk> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <20080208105612.GA19796@venice.staff.cs.york.ac.uk> Message-ID: <4683d9370802080702l35f0b5e3t847721cf28ba1ba8@mail.gmail.com> On 2/8/08, Matthew Naylor wrote: > it in for an efficient program. However, to my knowledge, it is an > unwritten rule of Haskell compilers that sharing *is* preserved, and > that they do perform *graph* reduction. Clean, a similar language to I'm not sure that programmers ought to be relying on this rule. Sure, all Haskell compilers I know of preserve sharing and do graph reduction. But conventional wisdom is not the same thing as an unwritten rule. Someday, someone might come along and write a Haskell compiler that isn't based on graph reduction and doesn't preserve sharing at the implementation level (while still preserving the informal semantics of Haskell). A programmer who had written code that failed to compile correctly under this hypothetical compiler would be a very naughty Haskell programmer indeed. > Haskell, indeed has a semantics based on graphs. So I don't believe Haskell doesn't have a semantics, graph-based or not... or at least not a formal one, and if not a formal one, I don't know what you mean :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "There are no sexist decisions to be made. There are antisexist decisions to be made. And they require tremendous energy and self-scrutiny, as well as moral stamina..." -- Samuel R. Delany From g9ks157k at acme.softbase.org Fri Feb 8 10:10:59 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Feb 8 10:10:04 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> Message-ID: <200802081610.59914.g9ks157k@acme.softbase.org> Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie: > On Feb 7, 2008 4:16 PM, Wolfgang Jeltsch wrote: > [?] > > You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, the > > latter representation should probably be prefered. With it, :+ always > > has a number as its left argument and a digit as its right. Without the > > () :+ we get ugly exceptional cases. > > You can see this, for example, in the instance > > declarations for Compare. With the second representation, we could > > reduce the number of instances dramatically. We would define a > > comparison of digits (verbose) and than a comparison of numbers based on > > the digit comparison (not verbose). > > Even if () would be preferred from the programmers point of view (I'm > not sure how much we could reduce the number of instances though), it > makes the representation less attractive on the user-side. Anyone > using the library would find it annoying and would wonder why is it > neccessary. I wouldn?t wonder. Leaving out the () :* part just works because our type-level ?values? are not typed, i.e., there aren?t different kinds Digit and Number but only kind *. If :+ would be a data constructor (on the value level), it would take a number and a digit argument which would forbid using a digit as its left argument. So I consider using a digit on the left as ?unclean?. It?s similar to using a number as the second part of a cons cell in LISP. > [?] Best wishes, Wolfgang From njbartlett at gmail.com Fri Feb 8 10:41:22 2008 From: njbartlett at gmail.com (njbartlett@gmail.com) Date: Fri Feb 8 10:40:14 2008 Subject: [Haskell-cafe] User groups meeting all over the world In-Reply-To: <404396ef0802080426s828f2efx5498be035ba6638c@mail.gmail.com> References: <20080207231147.GI19014@scytale.galois.com> <404396ef0802080426s828f2efx5498be035ba6638c@mail.gmail.com> Message-ID: Hi Neil, London HUG is not on the list because we're not meeting in the next two weeks. Rest assured we are on the wiki page though. On that note, I am looking again for topics and speaker for the next full meeting at City University. It will likely be in the middle of March. If anybody has ideas for talks, please let me know. Also talk to me if there is something in particular you would like to *hear* about... then we'll do our best to find somebody who can talk about it. Thanks, Another Neil On 2/8/08, Neil Mitchell wrote: > Hi > > > Fun in the afternoon London/UK February 12 > > Fun in the afternoon is great, but its not really a user group - it is > still primarily an academic event, although is open to everyone. There > is LUG, which is the London Haskell Users Group, which should > definately be on this list. > > Thanks > > Neil > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From monnier at iro.umontreal.ca Fri Feb 8 11:14:55 2008 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Fri Feb 8 11:14:03 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> Message-ID: >> > You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, the >> > latter representation should probably be prefered. With it, :+ always >> > has a number as its left argument and a digit as its right. Without the >> > () :+ we get ugly exceptional cases. >> > You can see this, for example, in the instance >> > declarations for Compare. With the second representation, we could >> > reduce the number of instances dramatically. We would define a >> > comparison of digits (verbose) and than a comparison of numbers based on >> > the digit comparison (not verbose). >> >> Even if () would be preferred from the programmers point of view (I'm >> not sure how much we could reduce the number of instances though), it >> makes the representation less attractive on the user-side. Anyone >> using the library would find it annoying and would wonder why is it >> neccessary. > I wouldn?t wonder. Leaving out the () :* part just works because our > type-level ?values? are not typed, i.e., there aren?t different kinds Digit > and Number but only kind *. If :+ would be a data constructor (on the value > level), it would take a number and a digit argument which would forbid using > a digit as its left argument. So I consider using a digit on the left > as ?unclean?. It?s similar to using a number as the second part of a cons > cell in LISP. How 'bout treating :+ as similar to `append' rather than similar to `cons'? Basically treat :+ as taking 2 numbers (rather than a number and a digit). Stefan From allbery at ece.cmu.edu Fri Feb 8 11:23:57 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Feb 8 11:22:50 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> Message-ID: <85BABA82-5700-4EE2-ACEB-D806A817EB8B@ece.cmu.edu> On Feb 8, 2008, at 11:14 , Stefan Monnier wrote: >>>> You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I >>>> think, the >>>> latter representation should probably be prefered. >>>> (...) > How 'bout treating :+ as similar to `append' rather than similar to > `cons'? > Basically treat :+ as taking 2 numbers (rather than a number and > a digit). Dumb questions department: why not define e.g. D'0 .. D'9 as () :* 0 .. () :* 9? Programmers then get D'1 :* 2, but the library sees () :* 1 :* 2. -- 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 vigalchin at gmail.com Fri Feb 8 12:13:46 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Fri Feb 8 12:12:38 2008 Subject: [Haskell-cafe] question concerning ANSI "void *" In-Reply-To: <396556a20802071330y7c788fbet2b1d57f72f4f0271@mail.gmail.com> References: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> <396556a20802071330y7c788fbet2b1d57f72f4f0271@mail.gmail.com> Message-ID: <5ae4f2ba0802080913h316adb17gaa9b2f0ba7fae881@mail.gmail.com> Let's take a concrete but "made up" case .. suppose we want to call through to pthread_create and pass the (void *) argument to pthread_create which in turn gets interpreted by the pthread that is launched. How would one populate the C struct that is passed to the launched pthread keeping in mind that this C struct is variable in length? From the FFI how would one model this C struct? Thanks, Vasili On 2/7/08, Adam Langley wrote: > > 2008/2/7 Galchin Vasili : > > Ok .. I am writing a Haskell function that will call down into the > ANSI > > C library .. blah :: .... -> Ptr Word8 ....-> .... The underlying C > function > > that "blah" is calling has a "void *" so I am using "Ptr Word 8" to > model > > the "void *". > > Depending on the context, "void *" is generally either taken as a Ptr > () (for an opaque pointer) or Ptr Word8 (for calls like memcpy). > > > I propose to have the callers of function "blah" to populate a > > data structure something like "Ptr Buz" where "data Buz = { ........} > and > > then do a "recast :: Ptr Word 8 -> Ptr Buz" when invoking function > "blah". > > Does this seem reasonable? Is there a better way? > > Generally, Ptr x is only used where x is either a shadow type or a > Bits type. Having a Ptr Baz where Baz is an ADT seems a little odd. If > you need to translate a structure from Haskell to C code, probably you > are better off having callers pass in a Baz then, internal to the > wrapping, fill out the C structure and call the FFI function with a > Ptr CBaz (where CBaz is a shadow type). > > > AGL > > -- > Adam Langley agl@imperialviolet.org > http://www.imperialviolet.org 650-283-9641 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080208/e4775ae7/attachment.htm From agl at imperialviolet.org Fri Feb 8 12:23:18 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Feb 8 12:22:11 2008 Subject: [Haskell-cafe] question concerning ANSI "void *" In-Reply-To: <5ae4f2ba0802080913h316adb17gaa9b2f0ba7fae881@mail.gmail.com> References: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> <396556a20802071330y7c788fbet2b1d57f72f4f0271@mail.gmail.com> <5ae4f2ba0802080913h316adb17gaa9b2f0ba7fae881@mail.gmail.com> Message-ID: <396556a20802080923n2322c601u85becab0f34f0314@mail.gmail.com> On Feb 8, 2008 9:13 AM, Galchin Vasili wrote: > Let's take a concrete but "made up" case .. suppose we want to call through > to pthread_create and pass the (void *) argument to pthread_create which in > turn gets interpreted by the pthread that is launched. How would one > populate the C struct that is passed to the launched pthread keeping in mind > that this C struct is variable in length? From the FFI how would one model > this C struct? It tough to be helpful with such a generic request. Here are some options that you can consider: 1) Write a wrapper function in C which has a nicer FFI interface to call from Haskell. Using cabal this is pretty painless and, if the interface suits it, it probably the easiest solution. 2) Call pthread_create directly with the FFI. You can give the FFI function a Haskell type with 'Ptr ()' or 'Ptr X', it doesn't really matter. However the type system serves you best, do it that way. This means that you need to populate the struct yourself in Haskell. The issue with this is that the local system defines lots of things like padding and alignment which mean that the layout of the structure in memory is complex and platform specific. Tools like hsc2hs[1] or c2hs will be very helpful here. Dealing with the variable length probably isn't an issue. Usually variable length structures have a fixed header and a variable tail, where the tail is an array of primitives. You can malloc the correct sized region, use one of the previous tools to fill in the fixed header and then use poke to complete the tail. I might be able to be more helpful if you give the actual struct and function prototype that you're trying to wrap. Cheers [1] http://therning.org/magnus/archives/tag/hsc2hs [2] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From simonpj at microsoft.com Fri Feb 8 12:55:53 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 8 12:54:46 2008 Subject: [Haskell-cafe] :i and :t give different types In-Reply-To: <20080207195731.GE19014@scytale.galois.com> References: <20080207194718.GD19014@scytale.galois.com> <2f9b2d30802071155m2fa88eearaf6d368c61ed2b3a@mail.gmail.com> <20080207195731.GE19014@scytale.galois.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3183278F46B@EA-EXMSG-C334.europe.corp.microsoft.com> I have not been following closely but if Don thinks there's a bug there probably is. Can someone submit a bug report pls? Better still a patch! :-) Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Don Stewart | Sent: 07 February 2008 19:58 | To: Ryan Ingram | Cc: haskell-cafe@haskell.org; Chad Scherrer | Subject: Re: [Haskell-cafe] :i and :t give different types | | ryani.spam: | > It looks like there is a bug with unparsing of bang-constructors in ghci: | > | > On 2/7/08, Don Stewart wrote: | > > data Stream a = forall s. Unlifted s => | > > Stream !(s -> Step a s) -- ^ a stepper function | > > !s -- ^ an initial state | > | > > Prelude Data.Stream> :info Stream | > > data Stream a where | > > Stream :: forall a s. | > > (Data.Stream.Unlifted s) => | > > !s -> Step a s -> !s -> Stream a | > | > This last line should start with !(s -> Step a s) instead of !s -> Step a s. | > | > If that was fixed, everything looks correct. | | Ah, yes, missing parens! Well spotted. | | So a pretty printer wibble in GHC? | | -- Don | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From chad.scherrer at gmail.com Fri Feb 8 13:28:38 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Fri Feb 8 13:27:37 2008 Subject: [Haskell-cafe] :i and :t give different types In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3183278F46B@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20080207194718.GD19014@scytale.galois.com> <2f9b2d30802071155m2fa88eearaf6d368c61ed2b3a@mail.gmail.com> <20080207195731.GE19014@scytale.galois.com> <638ABD0A29C8884A91BC5FB5C349B1C3183278F46B@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: On Feb 8, 2008 9:55 AM, Simon Peyton-Jones wrote: > I have not been following closely but if Don thinks there's a bug there probably is. Can someone submit a bug report pls? Better still a patch! :-) > > Simon Ok, I filed a bug report. From vigalchin at gmail.com Fri Feb 8 13:55:22 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Fri Feb 8 13:54:13 2008 Subject: [Haskell-cafe] question concerning ANSI "void *" In-Reply-To: <396556a20802080923n2322c601u85becab0f34f0314@mail.gmail.com> References: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> <396556a20802071330y7c788fbet2b1d57f72f4f0271@mail.gmail.com> <5ae4f2ba0802080913h316adb17gaa9b2f0ba7fae881@mail.gmail.com> <396556a20802080923n2322c601u85becab0f34f0314@mail.gmail.com> Message-ID: <5ae4f2ba0802081055g6fc196c5j170f6b0fcde9e78c@mail.gmail.com> a couple of concrete examples: typedef struct {char a; int b; char str[8]} type1; typedef struct {long c; char d} type2; So to pthread_create (just an example function) we could be passing a struct of type1 or a struct of type2 .. i.e. arbitrary length and content ... I am trying to better understand this. I see some of the poke functions mentioned in the FFI. Which one are you alluding to? Regards, Vasili On 2/8/08, Adam Langley wrote: > > On Feb 8, 2008 9:13 AM, Galchin Vasili wrote: > > Let's take a concrete but "made up" case .. suppose we want to call > through > > to pthread_create and pass the (void *) argument to pthread_create which > in > > turn gets interpreted by the pthread that is launched. How would one > > populate the C struct that is passed to the launched pthread keeping in > mind > > that this C struct is variable in length? From the FFI how would one > model > > this C struct? > > It tough to be helpful with such a generic request. Here are some > options that you can consider: > > 1) Write a wrapper function in C which has a nicer FFI interface to > call from Haskell. Using cabal this is pretty painless and, if the > interface suits it, it probably the easiest solution. > 2) Call pthread_create directly with the FFI. You can give the FFI > function a Haskell type with 'Ptr ()' or 'Ptr X', it doesn't really > matter. However the type system serves you best, do it that way. This > means that you need to populate the struct yourself in Haskell. The > issue with this is that the local system defines lots of things like > padding and alignment which mean that the layout of the structure in > memory is complex and platform specific. Tools like hsc2hs[1] or c2hs > will be very helpful here. Dealing with the variable length probably > isn't an issue. Usually variable length structures have a fixed header > and a variable tail, where the tail is an array of primitives. You can > malloc the correct sized region, use one of the previous tools to fill > in the fixed header and then use poke to complete the tail. > > I might be able to be more helpful if you give the actual struct and > function prototype that you're trying to wrap. > > Cheers > > > > [1] http://therning.org/magnus/archives/tag/hsc2hs > [2] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ > > -- > Adam Langley agl@imperialviolet.org > http://www.imperialviolet.org 650-283-9641 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080208/deb63180/attachment.htm From vigalchin at gmail.com Fri Feb 8 13:57:58 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Fri Feb 8 13:56:51 2008 Subject: [Haskell-cafe] question concerning ANSI "void *" In-Reply-To: <5ae4f2ba0802081055g6fc196c5j170f6b0fcde9e78c@mail.gmail.com> References: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> <396556a20802071330y7c788fbet2b1d57f72f4f0271@mail.gmail.com> <5ae4f2ba0802080913h316adb17gaa9b2f0ba7fae881@mail.gmail.com> <396556a20802080923n2322c601u85becab0f34f0314@mail.gmail.com> <5ae4f2ba0802081055g6fc196c5j170f6b0fcde9e78c@mail.gmail.com> Message-ID: <5ae4f2ba0802081057n95e89bsc170f5323408e20d@mail.gmail.com> basically I am trying to implement ioctl for the Posix library .. so a possible signtaure would be: fdIoctl :: Fd -> Int -> Ptr Word 8 -> IO( Ptr Word8) ???? Vasili On 2/8/08, Galchin Vasili wrote: > > a couple of concrete examples: > > typedef struct {char a; int b; char str[8]} type1; > > typedef struct {long c; char d} type2; > > So to pthread_create (just an example function) we could be passing a > struct of type1 or a struct of type2 .. i.e. arbitrary length and content > ... I am trying to better understand this. I see some of the poke functions > mentioned in the FFI. Which one are you alluding to? > > Regards, Vasili > > > On 2/8/08, Adam Langley wrote: > > > > On Feb 8, 2008 9:13 AM, Galchin Vasili wrote: > > > Let's take a concrete but "made up" case .. suppose we want to call > > through > > > to pthread_create and pass the (void *) argument to pthread_create > > which in > > > turn gets interpreted by the pthread that is launched. How would one > > > populate the C struct that is passed to the launched pthread keeping > > in mind > > > that this C struct is variable in length? From the FFI how would one > > model > > > this C struct? > > > > It tough to be helpful with such a generic request. Here are some > > options that you can consider: > > > > 1) Write a wrapper function in C which has a nicer FFI interface to > > call from Haskell. Using cabal this is pretty painless and, if the > > interface suits it, it probably the easiest solution. > > 2) Call pthread_create directly with the FFI. You can give the FFI > > function a Haskell type with 'Ptr ()' or 'Ptr X', it doesn't really > > matter. However the type system serves you best, do it that way. This > > means that you need to populate the struct yourself in Haskell. The > > issue with this is that the local system defines lots of things like > > padding and alignment which mean that the layout of the structure in > > memory is complex and platform specific. Tools like hsc2hs[1] or c2hs > > will be very helpful here. Dealing with the variable length probably > > isn't an issue. Usually variable length structures have a fixed header > > and a variable tail, where the tail is an array of primitives. You can > > malloc the correct sized region, use one of the previous tools to fill > > in the fixed header and then use poke to complete the tail. > > > > I might be able to be more helpful if you give the actual struct and > > function prototype that you're trying to wrap. > > > > Cheers > > > > > > > > [1] http://therning.org/magnus/archives/tag/hsc2hs > > [2] http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ > > > > -- > > Adam Langley agl@imperialviolet.org > > http://www.imperialviolet.org 650-283-9641 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080208/1c1c5895/attachment.htm From westondan at imageworks.com Fri Feb 8 15:36:25 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Feb 8 15:35:23 2008 Subject: [Haskell-cafe] Create a list without duplicates from a list with duplicates In-Reply-To: References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> <87d4r71vwy.fsf@59A2.org> Message-ID: <47ACBD49.6050606@imageworks.com> As noted, (Data.Set.toList . Data.Set.fromList) is the best traditional solution if you don't care about order (or Data.Set.toAscList for a sorted result). If order is important, the new bijective Data.Bimap class http://code.haskell.org/~scook0/haddock/bimap/Data-Bimap.html may be your best bet (I haven't yet tried it myself). Meanwhile, here is a hand-rolled solution to order-preserving nubbing: > import Data.List(groupBy,sortBy,sort) > import Data.Maybe(listToMaybe) > > efficientNub :: (Ord a) => [a] -> [a] > efficientNub = flip zip [0..] -- carry along index > >>> sort -- sort by value, then index > >>> groupBy equalFsts -- group adjacent equal values > >>> map head -- keep only primus inter pares > >>> sortBy compareSnds -- sort by index > >>> map fst -- discard index > > where equalFsts (x1,y1) (x2,y2) = x1 == x2 > compareSnds (x1,y1) (x2,y2) = compare y1 y2 > x >>> y = y . x There is a hidden proof obligation here: Exercise: Prove that (groupBy equalFsts >>> map head) is a total function, using the defintion of groupBy from Data.List: groupBy :: (a -> a -> Bool) -> [a] -> [[a]] groupBy _ [] = [] groupBy eq (x:xs) = (x:ys) : groupBy eq zs where (ys,zs) = span (eq x) xs Felipe Lessa wrote: > 2008/2/8 Jed Brown : >> Look at Data.List: >> >> nub :: (Eq a) => [a] -> [a] >> nub = nubBy (==) >> >> nubBy :: (a -> a -> Bool) -> [a] -> [a] >> nubBy eq [] = [] >> nubBy eq (x:xs) = x : nubBy eq (filter (\ y -> not (eq x y)) xs) > > And then there's also > > sort :: (Ord a) => [a] -> [a] > > which should have better performance, O(n log n) against O(n?) I > guess, but of course will change the order of the elements. If you > really don't mind the order at all, you could also use Data.Set in the > first place. > > Cheers, > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From agl at imperialviolet.org Fri Feb 8 15:38:44 2008 From: agl at imperialviolet.org (Adam Langley) Date: Fri Feb 8 15:37:36 2008 Subject: [Haskell-cafe] question concerning ANSI "void *" In-Reply-To: <5ae4f2ba0802081057n95e89bsc170f5323408e20d@mail.gmail.com> References: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> <396556a20802071330y7c788fbet2b1d57f72f4f0271@mail.gmail.com> <5ae4f2ba0802080913h316adb17gaa9b2f0ba7fae881@mail.gmail.com> <396556a20802080923n2322c601u85becab0f34f0314@mail.gmail.com> <5ae4f2ba0802081055g6fc196c5j170f6b0fcde9e78c@mail.gmail.com> <5ae4f2ba0802081057n95e89bsc170f5323408e20d@mail.gmail.com> Message-ID: <396556a20802081238k2f951899lb6e9249a12a0946f@mail.gmail.com> On Feb 8, 2008 10:57 AM, Galchin Vasili wrote: > basically I am trying to implement ioctl for the Posix library .. so a > possible signtaure would be: > > fdIoctl :: Fd -> Int -> Ptr Word 8 -> IO( Ptr Word8) ???? Ah, ok. You could cover many of the ioctls (the ones which only take a single primitive) by using the Storable class and the types CInt etc. Define the FFI call to ioctl with a type of CInt -> Int -> Ptr () -> IO CInt and then ioctlCInt :: CInt -> CInt -> CInt -> IO CInt ioctlCInt fd call arg = do allocaBytes $ \ptr -> do poke ptr arg result <- ioctl fd call (cast ptr) when (result < 0) $ fail "ioctl error" peek ptr (untested, might work ;) ... and likewise for the other C types. However, for those ioctls which take a complex structure (e.g. many of the networking ones), you'll need to marshal yourself: data SomeIOCtlStruct = CInt CInt CInt ioctlSomeIOCtlStruct :: CInt -> CInt -> SomeIOCtlStruct -> IO () ioctlSomeIOCtlStruct = do ... (see the above linked to pointers to hsc2hs and c2hs about how to write this function) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From westondan at imageworks.com Fri Feb 8 15:52:39 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Feb 8 15:51:39 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <47ACC09A.4070408@imageworks.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> <85BABA82-5700-4EE2-ACEB-D806A817EB8B@ece.cmu.edu> <47ACC09A.4070408@imageworks.com> Message-ID: <47ACC117.1020606@imageworks.com> Dan Weston wrote: > Brandon S. Allbery KF8NH wrote: >> >> On Feb 8, 2008, at 11:14 , Stefan Monnier wrote: >> >>>>>> You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I >>>>>> think, the >>>>>> latter representation should probably be prefered. >>>>>> (...) >>> How 'bout treating :+ as similar to `append' rather than similar to >>> `cons'? >>> Basically treat :+ as taking 2 numbers (rather than a number and >>> a digit). >> >> Dumb questions department: why not define e.g. D'0 .. D'9 as () :* 0 >> .. () :* 9? Programmers then get D'1 :* 2, but the library sees () :* >> 1 :* 2. >> > > No, D'0 should be (), not () :* D0. If you allow () :* D0, then you > introduce redundant types for the same number: > > In the first case, D'0 :* D'3 == D'3, and D'0 :* D'0 has no instance. In > your example, D'3 and D'0 :* D'3 are equivalent, but no longer unify. > > Dan On second thought, how would you write D'3 :* D0 ? I think maybe using the () makes it fundamentally difficult to restrict multiple types for the same number. From westondan at imageworks.com Fri Feb 8 15:50:34 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Feb 8 15:51:47 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <85BABA82-5700-4EE2-ACEB-D806A817EB8B@ece.cmu.edu> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> <85BABA82-5700-4EE2-ACEB-D806A817EB8B@ece.cmu.edu> Message-ID: <47ACC09A.4070408@imageworks.com> Brandon S. Allbery KF8NH wrote: > > On Feb 8, 2008, at 11:14 , Stefan Monnier wrote: > >>>>> You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I >>>>> think, the >>>>> latter representation should probably be prefered. >>>>> (...) >> How 'bout treating :+ as similar to `append' rather than similar to >> `cons'? >> Basically treat :+ as taking 2 numbers (rather than a number and >> a digit). > > Dumb questions department: why not define e.g. D'0 .. D'9 as () :* 0 .. > () :* 9? Programmers then get D'1 :* 2, but the library sees () :* 1 :* 2. > No, D'0 should be (), not () :* D0. If you allow () :* D0, then you introduce redundant types for the same number: In the first case, D'0 :* D'3 == D'3, and D'0 :* D'0 has no instance. In your example, D'3 and D'0 :* D'3 are equivalent, but no longer unify. Dan From droundy at darcs.net Fri Feb 8 15:55:09 2008 From: droundy at darcs.net (David Roundy) Date: Fri Feb 8 15:54:01 2008 Subject: [Haskell-cafe] Re: threads + IORefs = Segmentation fault? In-Reply-To: <47AC3301.8040500@microsoft.com> References: <20080118232255.GF6197@darcs.net> <47AC3301.8040500@microsoft.com> Message-ID: <20080208205507.GA17316@darcs.net> On Fri, Feb 08, 2008 at 10:46:25AM +0000, Simon Marlow wrote: > (I'm a bit behind with haskell-cafe, sorry for not seeing this sooner...) No problem! > Yes, that should all be fine, because the IORef is only modified from one > thread, and read from the other(s). If you were modifying the IORef from > more than one thread you would need to use atomicallyModifyIORef, or MVars. If I did modify the IORef from more than one thread (e.g. if a bug were introduced), would this cause any trouble other than occasional missed updates or reads of wrong data? -- David Roundy Department of Physics Oregon State University From rendel at rbg.informatik.tu-darmstadt.de Fri Feb 8 16:07:39 2008 From: rendel at rbg.informatik.tu-darmstadt.de (Tillmann Rendel) Date: Fri Feb 8 16:06:50 2008 Subject: [Haskell-cafe] Create a list without duplicates from a list with duplicates In-Reply-To: <47ACBD49.6050606@imageworks.com> References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> <87d4r71vwy.fsf@59A2.org> <47ACBD49.6050606@imageworks.com> Message-ID: <47ACC49B.50707@rbg.informatik.tu-darmstadt.de> Dan Weston wrote: > Meanwhile, here is a hand-rolled solution to order-preserving nubbing: > > > import Data.List(groupBy,sortBy,sort) > > import Data.Maybe(listToMaybe) > > > > efficientNub :: (Ord a) => [a] -> [a] > > efficientNub = flip zip [0..] -- carry along index > > >>> sort -- sort by value, then index > > >>> groupBy equalFsts -- group adjacent equal values > > >>> map head -- keep only primus inter pares > > >>> sortBy compareSnds -- sort by index > > >>> map fst -- discard index > > > > where equalFsts (x1,y1) (x2,y2) = x1 == x2 > > compareSnds (x1,y1) (x2,y2) = compare y1 y2 > > x >>> y = y . x I would try something like efficientNub = catMaybes . snd . mapAccumR f empty where f s x | member x s = (s, Nothing) | otherwise = (insert x s, x) that is, threading the Set of already given results through. Tillmann From jgbailey at gmail.com Fri Feb 8 16:17:42 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Fri Feb 8 16:16:34 2008 Subject: [Haskell-cafe] Fwd: [pdxfunc] pdxfunc meeting: Monday, February 11, 7pm, CubeSpace (Portland, OR) Message-ID: ---------- Forwarded message ---------- From: Igal Koshevoy Date: Feb 8, 2008 12:01 PM Subject: [pdxfunc] pdxfunc meeting: Monday, February 11, 7pm, CubeSpace To: Igal Koshevoy Join us at the next meeting of pdxfunc, the Portland Functional Programming Study Group. We'll have presentations, demos and discussions. We welcome programmers interested in all functional languages and our meetings have content for coders of all skill levels. If interested, please also subscribe to our mailing list at http://groups.google.com/group/pdxfunc PRESENTATIONS (1) Kevin Scaldeferri: Effortless Concurrent Programming with Erlang Abstract: Erlang is a dynamic functional programming language designed for concurrent programming. After a quick introduction to the syntax and primitives, we'll dive into some code to see example of how you can easily write programs that take advantage of multiple CPUs, and that even scale effortlessly to clusters of machines. (You are highly encouraged to download and install Erlang from http://erlang.org/download.html before the meeting.) Speaker: Kevin Scaldeferri has spent the last 6 years building high-volume, high-reliability systems at Yahoo. His interests include programming languages, the interaction between online and real-life communities, and techniques for making the development process more reliable, more successful, and more fun. (2) Tim Chevalier: Towards a GraphicsMagick Binding for Haskell Abstract: I will discuss my work in progress on implementing a Haskell Foreign Function Interface (FFI) binding for the C-based GraphicsMagick image manipulation library. I will introduce portions of the FFI through examples, as well as tools for simplifying FFI use. I will also explain how I have begun to use Haskell's type system to develop a simplified yet equally powerful interface (as compared to the C version) to the GraphicsMagick library. Given the ongoing nature of my work, I will conclude by soliciting comments on what *you* would like to see in a Haskell image manipulation library. Speaker: Tim Chevalier is a PhD student at Portland State University, where he thinks about alternative back-ends for Haskell and languages like it. He has been programming in Haskell for seven years, the first six of which he spent trying to understand monads. From ben.franksen at online.de Fri Feb 8 16:14:45 2008 From: ben.franksen at online.de (Ben Franksen) Date: Fri Feb 8 16:16:53 2008 Subject: [Haskell-cafe] Re: problem with collection (container) class References: <15c02dff0802062358g632cea57ifc7eeaee3aa1f587@mail.gmail.com> <200802071326.14078.daniel.is.fischer@web.de> Message-ID: Daniel Fischer wrote: > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FunctionalDependencies #-} > {- # LANGUAGE FlexibleInstances # -} > module Leandro where > > data Abb a b = Branch a b (Abb a b) (Abb a b) | Leaf > > data ListAssoc a b = Node a b (ListAssoc a b) | Empty > > class Container c a b |c -> a, c -> b where > [...] > > instance (Ord a) => Container (Abb a b) a b where > [...] > > Note: The FlexibleInstances Language pragma is required by GHC 6.8.1 and > 6.8.2, but not by GHC 6.6.1 or hugs, I think that's a bug in 6.8.* If it's a bug then it is probably in 6.6.1 too, it just gets hidden by the fact that in 6.6.1 the -fglasgow-exts extensions cannot be activated separately. If you enable one of them, you get them all. Cheers Ben From ben.franksen at online.de Fri Feb 8 16:23:20 2008 From: ben.franksen at online.de (Ben Franksen) Date: Fri Feb 8 16:25:22 2008 Subject: [Haskell-cafe] Re: question concerning ANSI "void *" References: <5ae4f2ba0802071014s98739b0uf2067d534f85c047@mail.gmail.com> <396556a20802071330y7c788fbet2b1d57f72f4f0271@mail.gmail.com> <5ae4f2ba0802080913h316adb17gaa9b2f0ba7fae881@mail.gmail.com> Message-ID: Galchin Vasili wrote: > Let's take a concrete but "made up" case .. suppose we want to call > through to pthread_create and pass the (void *) argument to pthread_create > which in turn gets interpreted by the pthread that is launched. How would > one populate the C struct that is passed to the launched pthread keeping > in mind that this C struct is variable in length? From the FFI how would > one model this C struct? In this case I'd use Storable a => Ptr a and provide an instance Storable for the actual type you want to marshal. You can allocate the struct with Foreign.Marshal.Alloc.malloc and marshall it from Haskell to C with Foreign.Storable.poke. Cheers Ben From daniel.is.fischer at web.de Fri Feb 8 17:23:39 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri Feb 8 17:21:58 2008 Subject: [Haskell-cafe] Re: problem with collection (container) class In-Reply-To: References: <15c02dff0802062358g632cea57ifc7eeaee3aa1f587@mail.gmail.com> <200802071326.14078.daniel.is.fischer@web.de> Message-ID: <200802082323.39726.daniel.is.fischer@web.de> Am Freitag, 8. Februar 2008 22:14 schrieb Ben Franksen: > If it's a bug then it is probably in 6.6.1 too, it just gets hidden by the > fact that in 6.6.1 the -fglasgow-exts extensions cannot be activated > separately. If you enable one of them, you get them all. > Thanks for the info, didn't know that. The problem was the error message, which didn't mention that each type variable may appear only once in an instance head, which I had temporarily forgotten. Then the message Leandro.hs:32:0: Illegal instance declaration for `Container (Abb a b) a b' (All instance types must be of the form (T a1 ... an) where a1 ... an are distinct type *variables* Use -XFlexibleInstances if you want to disable this.) In the instance declaration for `Container (Abb a b) a b' looks rather confusing :) > Cheers > Ben > Cheers, Daniel From wnoise at ofb.net Fri Feb 8 18:05:12 2008 From: wnoise at ofb.net (Aaron Denney) Date: Fri Feb 8 18:04:14 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200801312335.21615.g9ks157k@acme.softbase.org> <6a7c66fc0802010400g71094d4fy66cc40483de699dc@mail.gmail.com> <6a7c66fc0802010409i635c47e2xe7c34e69007dd436@mail.gmail.com> <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> Message-ID: On 2008-02-05, Alfonso Acosta wrote: > On Feb 5, 2008 4:10 PM, Henning Thielemann > wrote: >> >> On Fri, 1 Feb 2008, Aaron Denney wrote: >> >> > On 2008-02-01, Bjorn Buckwalter wrote: >> > > If Naturals had been sufficient for me I wouldn't have done my own >> > > implementation (I'm unaware of any other implementation of Integers). >> > > And there is certainly a lot of value to the clearer error messages >> > > from a decimal representation. >> > >> > I did a balanced-base-three (digits are 0, and +- 1) representation to >> > get negative "decimals". >> >> Nice. In German the digit values are sometimes called "eins, keins, meins". :-) > > I'm almost done with the decimal library but it would be nice to check > some Integer implementations for future inclusion. So, Aaron, Bj?rn, > are your implementations available somewhere? http://ofb.net/~wnoise/repos/dimensional/ -- Aaron Denney -><- From tomahawkins at gmail.com Fri Feb 8 18:28:50 2008 From: tomahawkins at gmail.com (Tom Hawkins) Date: Fri Feb 8 18:27:41 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <47ABFDF8.9040800@cs.chalmers.se> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> Message-ID: <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> On 2/8/08, Emil Axelsson wrote: > I know of a few of ways to express sharing in a pure language: > > 1) "Observable sharing", which, in general, is unsafe. > 2) Using Template Haskell > 3) Matthew Naylor has done some work on "expressible sharing", which has > 4) Use a monad (but I'm sure this is what you're trying to avoid). Or... 5) Forget embedding the DSL, and write a direct compiler. In addition to the sharing problem, another shortcoming of Haskell DSLs is they can not fully exploit the benefits of algebraic datatypes. Specifically, pattern matching ADTs can only be used to control the compile-time configuration of the target, it can't be used to describe the target's behavior -- at least for DSLs that generate code that executes outside of Haskell's runtime. Writing a real compiler would solve both of these problems. Is there any Haskell implementation that has a clean cut-point, from which I can start from a fully type-checked, type-annotated intermediate representation? And thanks for the link to John's paper describing Hydra's use of Template Haskell. I will definiately consider TH. -Tom From jonathanccast at fastmail.fm Fri Feb 8 19:14:17 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 8 19:13:10 2008 Subject: [Haskell-cafe] GHC + interactive input/output Message-ID: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> $ cat > foo.c #include int main() { char s[1024]; printf("gsi> "); gets(s); printf("%s\n", s); return 0; } $ make foo cc gsi.c -o gsi $ ./foo warning: this program uses gets(), which is unsafe. gsi> hello hello $ cat > foo.hs main = do putStr "gsi> " s <- getLine putStrLn s $ ghc foo.hs -o foo $ ./foo hello gsi> hello (This is on MacOS X). It strikes me that GHC is being extraordinarily unhelpful here. Is there anyone on the planet who ever actually wants this behavior? jcc From philip.weaver at gmail.com Fri Feb 8 19:41:37 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Fri Feb 8 19:40:26 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> Message-ID: Your "gsi> " is buffered because there's no newline at the end. To flush the buffer and force it to be printed immediately, use 'hFlush' from the System.IO library, or use 'hSetBuffering' from that same library: http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html I believe you can observe the same behavior in C. - Phil On Feb 8, 2008 4:14 PM, Jonathan Cast wrote: > $ cat > foo.c > #include > > int > main() > { > char s[1024]; > printf("gsi> "); > gets(s); > printf("%s\n", s); > return 0; > } > $ make foo > cc gsi.c -o gsi > $ ./foo > warning: this program uses gets(), which is unsafe. > gsi> hello > hello > $ cat > foo.hs > main = do > putStr "gsi> " > s <- getLine > putStrLn s > $ ghc foo.hs -o foo > $ ./foo > hello > gsi> hello > > (This is on MacOS X). It strikes me that GHC is being > extraordinarily unhelpful here. Is there anyone on the planet who > ever actually wants this behavior? > > jcc > > _______________________________________________ > 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/20080208/17a9b850/attachment.htm From dons at galois.com Fri Feb 8 19:47:39 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 8 19:46:34 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> Message-ID: <20080209004739.GA11554@scytale.galois.com> tomahawkins: > On 2/8/08, Emil Axelsson wrote: > > I know of a few of ways to express sharing in a pure language: > > > > 1) "Observable sharing", which, in general, is unsafe. > > 2) Using Template Haskell > > 3) Matthew Naylor has done some work on "expressible sharing", which has > > 4) Use a monad (but I'm sure this is what you're trying to avoid). > > Or... > > 5) Forget embedding the DSL, and write a direct compiler. > > In addition to the sharing problem, another shortcoming of Haskell > DSLs is they can not fully exploit the benefits of algebraic > datatypes. Specifically, pattern matching ADTs can only be used to > control the compile-time configuration of the target, it can't be used > to describe the target's behavior -- at least for DSLs that generate > code that executes outside of Haskell's runtime. > > Writing a real compiler would solve both of these problems. Is there > any Haskell implementation that has a clean cut-point, from which I > can start from a fully type-checked, type-annotated intermediate > representation? Taking the output of GHC's intermediate phase, after optimising leaves you with type checked, optimised, 'Core' -- basically lambda calculus with extras. It's a good start if you then want to hand-compile that down. Extract it with -fext-core -- Don From allbery at ece.cmu.edu Fri Feb 8 19:50:15 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Feb 8 19:49:06 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> Message-ID: <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> On Feb 8, 2008, at 19:41 , Philip Weaver wrote: > Your "gsi> " is buffered because there's no newline at the end. To > flush the buffer and force it to be printed immediately, use > 'hFlush' from the System.IO library, or use 'hSetBuffering' from > that same library: http://haskell.org/ghc/docs/latest/html/ > libraries/base/System-IO.html > > I believe you can observe the same behavior in C. Most C stdio libraries in my experience have extra code in the functions that read stdin to flush stdout first, specifically because of lazy people who don't pay attention to buffering. -- 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 jonathanccast at fastmail.fm Fri Feb 8 20:07:10 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 8 20:06:01 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> Message-ID: On 8 Feb 2008, at 4:50 PM, Brandon S. Allbery KF8NH wrote: > > On Feb 8, 2008, at 19:41 , Philip Weaver wrote: > >> Your "gsi> " is buffered because there's no newline at the end. >> To flush the buffer and force it to be printed immediately, use >> 'hFlush' from the System.IO library, or use 'hSetBuffering' from >> that same library: http://haskell.org/ghc/docs/latest/html/ >> libraries/base/System-IO.html >> >> I believe you can observe the same behavior in C. > > Most C stdio libraries in my experience have extra code in the > functions that read stdin to flush stdout first, specifically > because of lazy people who don't pay attention to buffering. Why can't GHC implement the same thing? jcc From philip.weaver at gmail.com Fri Feb 8 20:29:22 2008 From: philip.weaver at gmail.com (Philip Weaver) Date: Fri Feb 8 20:28:15 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> Message-ID: GHC certain *could* do this, but it's arguably not the right thing to do. For performance, the operating system buffers writes until it is ready to write large chunks at a time. If you do not want this behavior, change the buffering mode from its default. - Phil On Feb 8, 2008 5:07 PM, Jonathan Cast wrote: > On 8 Feb 2008, at 4:50 PM, Brandon S. Allbery KF8NH wrote: > > > > > On Feb 8, 2008, at 19:41 , Philip Weaver wrote: > > > >> Your "gsi> " is buffered because there's no newline at the end. > >> To flush the buffer and force it to be printed immediately, use > >> 'hFlush' from the System.IO library, or use 'hSetBuffering' from > >> that same library: http://haskell.org/ghc/docs/latest/html/ > >> libraries/base/System-IO.html > >> > >> I believe you can observe the same behavior in C. > > > > Most C stdio libraries in my experience have extra code in the > > functions that read stdin to flush stdout first, specifically > > because of lazy people who don't pay attention to buffering. > > Why can't GHC implement the same thing? > > jcc > > _______________________________________________ > 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/20080208/00c4c236/attachment.htm From jonathanccast at fastmail.fm Fri Feb 8 20:45:57 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 8 20:44:51 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> Message-ID: <00F31CE3-BA30-46CE-BAC9-59CEC5F789F4@fastmail.fm> On 8 Feb 2008, at 5:29 PM, Philip Weaver wrote: > GHC certain *could* do this, but it's arguably not the right thing > to do. For performance, the operating system buffers writes until > it is ready to write large chunks at a time. If you do not want > this behavior, change the buffering mode from its default. To what? BlockBuffering is worse, not better, and the docs *explicitly* say that switching to NoBuffering will break ^D (if it wasn't broken already...) My specification for a working program is `one that works exactly like every other program on my machine'. I don't see how to produce such a program with GHC.(1) jcc (1) Using readline might work (although I'm kind of sceptical given what's preceded it), but I haven't gotten it to link thus far... From bjorn.buckwalter at gmail.com Fri Feb 8 20:59:41 2008 From: bjorn.buckwalter at gmail.com (Bjorn Buckwalter) Date: Fri Feb 8 20:58:34 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802061747s1713da91v9083396f381a657c@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802051116q653268bcld3340433da1a7bee@mail.gmail.com> <8b2a1a960802051129y2a666898mc842780411627516@mail.gmail.com> <6a7c66fc0802051203p22276101ledf4f87353a7bddc@mail.gmail.com> <8b2a1a960802051932s17965fcapf7f53274e170b15d@mail.gmail.com> <6a7c66fc0802061003q511bb8e0v13a35ab1f9c601a1@mail.gmail.com> <8b2a1a960802061730m558f9a77te4c9647ff06c1b4@mail.gmail.com> <6a7c66fc0802061747s1713da91v9083396f381a657c@mail.gmail.com> Message-ID: <8b2a1a960802081759l1950c620h8a2eb4575e4091d7@mail.gmail.com> On Feb 6, 2008 8:47 PM, Alfonso Acosta wrote: > On Feb 7, 2008 2:30 AM, Bjorn Buckwalter wrote: > > Ok. Is this what people want -- one big hold-all library with > > everything, as opposed to smaller more specialized packages? I guess I > > can see advantages (real or perceived) to both approaches. > > Apart from Dockins' typenats library there are no other user-friendly > specific type-level libraries that know, so I cannot really tell if > people would prefer a hold-all library or a couple of more granular > specialized ones. > > Right now is not hold-all at all (it is still vaporware actually :)), > so I think there's no reason to discuss that at this point. Let's see > what people think. Right, of course. I'll be taking a look at your no-longer-vaporware! ;) From prstanley at ntlworld.com Fri Feb 8 21:25:29 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri Feb 8 21:24:29 2008 Subject: [Haskell-cafe] Slightly Offtopic in Part Message-ID: <7.0.1.0.0.20080209000534.01d22ec0@ntlworld.com> Hi folks The disjunction elimination rule: I've been trying to make sense of it and I think I have had some success; however, it's far from adequate. I wonder, is there a way of demonstrating it in Haskell? A code frag with a jargon-free explanation would be mucho appreciated. Cheers, Paul From ryani.spam at gmail.com Fri Feb 8 21:34:37 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Feb 8 21:33:27 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: <00F31CE3-BA30-46CE-BAC9-59CEC5F789F4@fastmail.fm> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <00F31CE3-BA30-46CE-BAC9-59CEC5F789F4@fastmail.fm> Message-ID: <2f9b2d30802081834t38f1d2fdw15a44ae9f37e6c1@mail.gmail.com> import System.IO myGetLine = hFlush stdout >> getLine -- ryan On 2/8/08, Jonathan Cast wrote: > On 8 Feb 2008, at 5:29 PM, Philip Weaver wrote: > > > GHC certain *could* do this, but it's arguably not the right thing > > to do. For performance, the operating system buffers writes until > > it is ready to write large chunks at a time. If you do not want > > this behavior, change the buffering mode from its default. > > To what? > > BlockBuffering is worse, not better, and the docs *explicitly* say > that switching to NoBuffering will break ^D (if it wasn't broken > already...) My specification for a working program is `one that > works exactly like every other program on my machine'. I don't see > how to produce such a program with GHC.(1) > > jcc > > (1) Using readline might work (although I'm kind of sceptical given > what's preceded it), but I haven't gotten it to link thus far... > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ryani.spam at gmail.com Fri Feb 8 21:47:51 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Feb 8 21:46:42 2008 Subject: [Haskell-cafe] Slightly Offtopic in Part In-Reply-To: <7.0.1.0.0.20080209000534.01d22ec0@ntlworld.com> References: <7.0.1.0.0.20080209000534.01d22ec0@ntlworld.com> Message-ID: <2f9b2d30802081847k2f093dfaj2d630c683630a1db@mail.gmail.com> I'm assuming you mean the rule described in http://en.wikibooks.org/wiki/Formal_Logic/Sentential_Logic/Inference_Rules > type Disj a b = Either a b > disj_elim :: Disj a b -> (a -> c) -> (b -> c) -> c > disj_elim (Left a) a2c b2c = a2c a > disj_elim (Right b) a2c b2c = b2c b If you know "either a is true, or b is true" and you know "from a, I can prove c", and you know "from b, I can prove c", then you can prove c. -- ryan On 2/8/08, PR Stanley wrote: > Hi folks > The disjunction elimination rule: > I've been trying to make sense of it and I think I have had some > success; however, it's far from adequate. I wonder, is there a way of > demonstrating it in Haskell? A code frag with a jargon-free > explanation would be mucho appreciated. > Cheers, Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jonathanccast at fastmail.fm Fri Feb 8 21:50:13 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 8 21:49:04 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: <2f9b2d30802081834t38f1d2fdw15a44ae9f37e6c1@mail.gmail.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <00F31CE3-BA30-46CE-BAC9-59CEC5F789F4@fastmail.fm> <2f9b2d30802081834t38f1d2fdw15a44ae9f37e6c1@mail.gmail.com> Message-ID: <975278FA-FE47-4BE9-A770-FA24D43EB6BE@fastmail.fm> On 8 Feb 2008, at 6:34 PM, Ryan Ingram wrote: > import System.IO > > myGetLine = hFlush stdout >> getLine That fixes this issue, certainly (although it's superfluous; my program really does contain only a single call to getLine)... Nevertheless, it would be nice to at least have it in the standard library; it's much more useful than any of the input functions that already exist. jcc From drl at cs.cmu.edu Fri Feb 8 21:59:21 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Fri Feb 8 21:58:12 2008 Subject: [Haskell-cafe] Slightly Offtopic in Part In-Reply-To: <7.0.1.0.0.20080209000534.01d22ec0@ntlworld.com> References: <7.0.1.0.0.20080209000534.01d22ec0@ntlworld.com> Message-ID: <20080209025921.GA28389@cs.cmu.edu> Out of context (am I missing some earlier part of this thread?) I'm not entirely sure what you mean. Are you're talking about the disjunction elim rule in intuitionistic natural deduction: Gamma |- A + B Gamma, A |- C Gamma, B |- C ---------------------------------------------- Gamma |- C If so, this is just 'case'. If you annotate the rule with proof terms (programs in the simply-typed lambda-calculus), you get the typing rule for case: Gamma |- e : A + B Gamma, x1 : A |- e1 : C Gamma, x2 : B |- e2 : C ------------------------------------------------------ Gamma |- case e of { Inl x1 -> e1 ; Inr x2 -> e2 } : C I.e., when pattern matching on the following type data Or a b = Inl a | Inr b (this type is isomorphic to Either in the Prelude) you have two cases to consider, one where you have an 'a' and the other where you have a 'b'. E.g., let's prove a simple theorem: comm :: Or a b -> Or b a comm x = case x of Inl x1 -> Inr x1 Inr x2 -> Inl x2 Does that help? -Dan On Feb09, PR Stanley wrote: > Hi folks > The disjunction elimination rule: > I've been trying to make sense of it and I think I have had some > success; however, it's far from adequate. I wonder, is there a way of > demonstrating it in Haskell? A code frag with a jargon-free > explanation would be mucho appreciated. > Cheers, Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From stefanor at cox.net Fri Feb 8 21:59:54 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Fri Feb 8 21:58:46 2008 Subject: [Haskell-cafe] Slightly Offtopic in Part In-Reply-To: <2f9b2d30802081847k2f093dfaj2d630c683630a1db@mail.gmail.com> References: <7.0.1.0.0.20080209000534.01d22ec0@ntlworld.com> <2f9b2d30802081847k2f093dfaj2d630c683630a1db@mail.gmail.com> Message-ID: <20080209025954.GA4422@localhost.localdomain> On Fri, Feb 08, 2008 at 06:47:51PM -0800, Ryan Ingram wrote: > I'm assuming you mean the rule described in > http://en.wikibooks.org/wiki/Formal_Logic/Sentential_Logic/Inference_Rules > > > type Disj a b = Either a b > > > disj_elim :: Disj a b -> (a -> c) -> (b -> c) -> c > > disj_elim (Left a) a2c b2c = a2c a > > disj_elim (Right b) a2c b2c = b2c b > > If you know "either a is true, or b is true" > and you know "from a, I can prove c", > and you know "from b, I can prove c", > then you can prove c. aka: import Data.Either type Disj = Either disj_elim = either 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/20080208/c46c0d62/attachment.bin From jonathanccast at fastmail.fm Fri Feb 8 22:02:24 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 8 22:01:15 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: <975278FA-FE47-4BE9-A770-FA24D43EB6BE@fastmail.fm> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <00F31CE3-BA30-46CE-BAC9-59CEC5F789F4@fastmail.fm> <2f9b2d30802081834t38f1d2fdw15a44ae9f37e6c1@mail.gmail.com> <975278FA-FE47-4BE9-A770-FA24D43EB6BE@fastmail.fm> Message-ID: On 8 Feb 2008, at 6:50 PM, Jonathan Cast wrote: > On 8 Feb 2008, at 6:34 PM, Ryan Ingram wrote: > >> import System.IO >> >> myGetLine = hFlush stdout >> getLine > > That fixes this issue, certainly (although it's superfluous; my > program really does contain only a single call to getLine)... > > Nevertheless, it would be nice to at least have it in the standard > library; it's much more useful than any of the input functions that > already exist. Also, for some reason, this doesn't seem to be necessary inside an Emacs buffer... Do we not care about performance in that case? jcc From westondan at imageworks.com Fri Feb 8 22:22:46 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Feb 8 22:21:38 2008 Subject: [Haskell-cafe] Slightly Offtopic in Part In-Reply-To: <2f9b2d30802081847k2f093dfaj2d630c683630a1db@mail.gmail.com> References: <7.0.1.0.0.20080209000534.01d22ec0@ntlworld.com> <2f9b2d30802081847k2f093dfaj2d630c683630a1db@mail.gmail.com> Message-ID: <47AD1C86.9040501@imageworks.com> For more details, look for a function called "orElim" in the write-up http://www.thenewsh.com/~newsham/formal/curryhoward/ Dan Ryan Ingram wrote: > I'm assuming you mean the rule described in > http://en.wikibooks.org/wiki/Formal_Logic/Sentential_Logic/Inference_Rules > >> type Disj a b = Either a b > >> disj_elim :: Disj a b -> (a -> c) -> (b -> c) -> c >> disj_elim (Left a) a2c b2c = a2c a >> disj_elim (Right b) a2c b2c = b2c b From westondan at imageworks.com Fri Feb 8 22:32:41 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Feb 8 22:31:35 2008 Subject: [Haskell-cafe] Slightly Offtopic in Part In-Reply-To: <47AD1C86.9040501@imageworks.com> References: <7.0.1.0.0.20080209000534.01d22ec0@ntlworld.com> <2f9b2d30802081847k2f093dfaj2d630c683630a1db@mail.gmail.com> <47AD1C86.9040501@imageworks.com> Message-ID: <47AD1ED9.3000600@imageworks.com> It should be emphasized that a type needs to be inhabited by (at least one) *total* function to prove a theorem. Otherwise, you could have the following partial function purporting to prove the phony theorem that "A or B implies A": phony :: Either a b -> a phony (Left a) = a Dan Dan Weston wrote: > For more details, look for a function called "orElim" in the write-up > > http://www.thenewsh.com/~newsham/formal/curryhoward/ > > Dan > > Ryan Ingram wrote: >> I'm assuming you mean the rule described in >> http://en.wikibooks.org/wiki/Formal_Logic/Sentential_Logic/Inference_Rules >> >> >>> type Disj a b = Either a b >> >>> disj_elim :: Disj a b -> (a -> c) -> (b -> c) -> c >>> disj_elim (Left a) a2c b2c = a2c a >>> disj_elim (Right b) a2c b2c = b2c b > > From scook0 at gmail.com Fri Feb 8 22:35:14 2008 From: scook0 at gmail.com (Stuart Cook) Date: Fri Feb 8 22:34:03 2008 Subject: [Haskell-cafe] Create a list without duplicates from a list with duplicates In-Reply-To: <47ACBD49.6050606@imageworks.com> References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> <87d4r71vwy.fsf@59A2.org> <47ACBD49.6050606@imageworks.com> Message-ID: <49b351060802081935t59908bf7h631addf56d7cdcb@mail.gmail.com> On Sat, Feb 9, 2008 at 7:36 AM, Dan Weston wrote: > If order is important, the new bijective Data.Bimap class > http://code.haskell.org/~scook0/haddock/bimap/Data-Bimap.html > may be your best bet (I haven't yet tried it myself). Let me try: nub :: (Ord a) => [a] -> [a] nub = map snd . Data.Bimap.toAscList . Data.Bimap.fromList . reverse . zip [1..] > nub "hello, world!" "helo, wrd!" Without the call to (reverse), this would still be an order-preserving nub, except that it would preserve the relative order of the *last* occurrence of each element. Actually, this makes me wonder whether fromList's behaviour should be changed, and whether I should add a "non-clobbering" variant of insert. Stuart From clawsie at fastmail.fm Sat Feb 9 02:08:33 2008 From: clawsie at fastmail.fm (brad clawsie) Date: Sat Feb 9 02:07:26 2008 Subject: [Haskell-cafe] ANN: Finance-Quote-Yahoo 0.5.0 Message-ID: <867iheli8e.fsf@laptop.gateway.2wire.net> a new version of Finance-Quote-Yahoo has been uploaded to hackage that breaks an api of the previous version for getting bulk historical quote information. specifically, notice this updated type signature: getHistoricalQuote :: QuoteSymbol -> Day -> Day -> QuoteFrequency -> IO (Maybe [HistoricalQuote]) the QuoteFrequency can be one of Daily, Weekly, Monthly or Dividend old code using this function will break, which is why i am notifying the list explicitly of this upload. since the versioning is still 0.* and the library is listed as experimental, users should expect changes until a 1.* version is released. brad From news at lyra.net Sat Feb 9 05:12:25 2008 From: news at lyra.net (news@lyra.net) Date: Sat Feb 9 05:11:17 2008 Subject: [Haskell-cafe] Compulsory relation 1 to many from entity A to entity A Message-ID: <47ad7c89.23a.1d18.804875462@webmailh2.aruba.it> Hallo! I'd like to build a database model with winHugs that allows a "recursive relation". For example a single instance of entity "components" is related with at least another row of the entity "components" (1 to many relationship). How can I do that? Thank you for your attention! From haskell at list.mightyreason.com Sat Feb 9 08:19:22 2008 From: haskell at list.mightyreason.com (ChrisK) Date: Sat Feb 9 08:18:26 2008 Subject: [Haskell-cafe] Re: Create a list without duplicates from a list with duplicates In-Reply-To: <49b351060802081935t59908bf7h631addf56d7cdcb@mail.gmail.com> References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> <87d4r71vwy.fsf@59A2.org> <47ACBD49.6050606@imageworks.com> <49b351060802081935t59908bf7h631addf56d7cdcb@mail.gmail.com> Message-ID: <47ADA85A.2020600@list.mightyreason.com> For Bimap is there anything like Data.Map.insertWithKey ? Stuart Cook wrote: > On Sat, Feb 9, 2008 at 7:36 AM, Dan Weston wrote: >> If order is important, the new bijective Data.Bimap class >> http://code.haskell.org/~scook0/haddock/bimap/Data-Bimap.html >> may be your best bet (I haven't yet tried it myself). > > Let me try: > > nub :: (Ord a) => [a] -> [a] > nub = map snd . Data.Bimap.toAscList . Data.Bimap.fromList . reverse > . zip [1..] > > > nub "hello, world!" > "helo, wrd!" > > Without the call to (reverse), this would still be an order-preserving > nub, except that it would preserve the relative order of the *last* > occurrence of each element. Actually, this makes me wonder whether > fromList's behaviour should be changed, and whether I should add a > "non-clobbering" variant of insert. > > > Stuart From bertram.felgenhauer at googlemail.com Sat Feb 9 09:34:34 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Feb 9 09:33:28 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <20080208105612.GA19796@venice.staff.cs.york.ac.uk> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <20080208105612.GA19796@venice.staff.cs.york.ac.uk> Message-ID: <20080209143433.GA4284@zombie.inf.tu-dresden.de> Matthew Naylor wrote: [snip] > Finally, when I say "observable sharing", I don't necessarily mean it > as defined by Koen Claessen and David Sands. I simply mean the use of > unsafePerformIO to detect sharing, whether or not this is done by an > "eq" predicate on Refs. (I say this because I think there are simpler > ways to detect sharing, though these will probably not have the nice > semantic properties of observable sharing.) ghc actually provides a primop for this: reallyUnsafePtrEquality# :: a -> a -> Int# Use at your own risk. Note that you can only check for equality uing that primop. To detect cycles in data structures efficiently, a total order would be better, but in the presence of copying garbage collection that's asking too much. Bertram From felipe.lessa at gmail.com Sat Feb 9 09:46:58 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sat Feb 9 09:45:47 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <20080209143433.GA4284@zombie.inf.tu-dresden.de> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <20080208105612.GA19796@venice.staff.cs.york.ac.uk> <20080209143433.GA4284@zombie.inf.tu-dresden.de> Message-ID: On Feb 9, 2008 12:34 PM, Bertram Felgenhauer wrote: > ghc actually provides a primop for this: > > reallyUnsafePtrEquality# :: a -> a -> Int# > > Use at your own risk. Why is it more than unsafe? 'unsafePerformIO' seems to me a lot unsafer than 'reallyUnsafePtrEquality#'. Also, is anybody using 'reallyUnsafePtrEquality#' on a working project? Cheers, -- Felipe. From bertram.felgenhauer at googlemail.com Sat Feb 9 09:49:08 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Feb 9 09:47:59 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <20080208105612.GA19796@venice.staff.cs.york.ac.uk> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <20080208105612.GA19796@venice.staff.cs.york.ac.uk> Message-ID: <20080209144908.GB4284@zombie.inf.tu-dresden.de> Matthew Naylor wrote: (snip) > Now, there remains the concern that Haskell's semantics does not > enforce sharing. A Haskell compiler is free to change the sharing a > program at a whim, unknowingly to the programmer who may be relying on > it in for an efficient program. However, to my knowledge, it is an > unwritten rule of Haskell compilers that sharing *is* preserved, and > that they do perform *graph* reduction. That is not true anymore for the threaded runtime of ghc. If two threads demand the same thunk, one of them will usually block, but there is a small window where both threads can start evaluting the expression. To prevent this, you'd have to take a lock or otherwise synchronize the threads upon entering each thunk, which is prohibitively expensive. See "Haskell on a Shared-Memory Multiprocessor", http://www.haskell.org/~simonmar/papers/multiproc.pdf for details, section 3.1 in particular. Bertram From flippa at flippac.org Sat Feb 9 09:54:03 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Sat Feb 9 09:52:55 2008 Subject: [Haskell-cafe] parsec3 pre-release [attempt 2] In-Reply-To: <47AAA1CF.5040106@vex.net> References: <1201929342.5496.112.camel@derek-laptop> <47AAA1CF.5040106@vex.net> Message-ID: On Thu, 7 Feb 2008, Albert Y. C. Lai wrote: > Is it good or bad to add: > > instance (MonadIO m) => MonadIO (ParsecT s u m) > I don't see any reason not to add it - it's not as if we can prevent people lifting to IO! Good catch. -- flippa@flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage. From scook0 at gmail.com Sat Feb 9 09:57:47 2008 From: scook0 at gmail.com (Stuart Cook) Date: Sat Feb 9 09:56:36 2008 Subject: [Haskell-cafe] Re: Create a list without duplicates from a list with duplicates In-Reply-To: <47ADA85A.2020600@list.mightyreason.com> References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> <87d4r71vwy.fsf@59A2.org> <47ACBD49.6050606@imageworks.com> <49b351060802081935t59908bf7h631addf56d7cdcb@mail.gmail.com> <47ADA85A.2020600@list.mightyreason.com> Message-ID: <49b351060802090657l1b738de2oc83cb0fdb88b587@mail.gmail.com> On Sun, Feb 10, 2008 at 12:19 AM, ChrisK wrote: > For Bimap is there anything like Data.Map.insertWithKey ? No. I wanted to implement the insertWith family, but it wasn't clear to me what should happen if the value produced by the user's function already exists, bound to something else. One possibility might be to do nothing (or error) if that happens, making it the user's responsibility to not do such things. Whatever the case may be, it should be possible for client code to define such an operation, with no more than a constant-factor overhead. Perhaps I should wait and see if people find themselves doing this before guessing at an implementation. (Incidentally, almost everything in Map that's missing from Bimap is missing either because it doesn't make sense, or because of corner cases like this one.) Stuart From g9ks157k at acme.softbase.org Sat Feb 9 10:08:53 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sat Feb 9 10:07:55 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> Message-ID: <200802091608.53295.g9ks157k@acme.softbase.org> Am Freitag, 8. Februar 2008 17:14 schrieb Stefan Monnier: > >> > You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, > >> > the latter representation should probably be prefered. With it, :+ > >> > always has a number as its left argument and a digit as its right. > >> > Without the () :+ we get ugly exceptional cases. > >> > You can see this, for example, in the instance > >> > declarations for Compare. With the second representation, we could > >> > reduce the number of instances dramatically. We would define a > >> > comparison of digits (verbose) and than a comparison of numbers based > >> > on the digit comparison (not verbose). > >> > >> Even if () would be preferred from the programmers point of view (I'm > >> not sure how much we could reduce the number of instances though), it > >> makes the representation less attractive on the user-side. Anyone > >> using the library would find it annoying and would wonder why is it > >> neccessary. > > > > I wouldn?t wonder. Leaving out the () :* part just works because our > > type-level ?values? are not typed, i.e., there aren?t different kinds > > Digit and Number but only kind *. If :+ would be a data constructor (on > > the value level), it would take a number and a digit argument which would > > forbid using a digit as its left argument. So I consider using a digit > > on the left as ?unclean?. It?s similar to using a number as the second > > part of a cons cell in LISP. > > How 'bout treating :+ as similar to `append' rather than similar to `cons'? > Basically treat :+ as taking 2 numbers (rather than a number and > a digit). So what would (D1 :* D1) :* (D2 :* D2) mean then? > Stefan Best wishes, Wolfgang From pocm at soton.ac.uk Sat Feb 9 10:33:40 2008 From: pocm at soton.ac.uk (Paulo J. Matos) Date: Sat Feb 9 10:32:28 2008 Subject: [Haskell-cafe] Re: Internships at GHC HQ In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C316EC9CDEAC@EA-EXMSG-C334.europe.corp.microsoft.com> References: <638ABD0A29C8884A91BC5FB5C349B1C316EC9CDEAC@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <11b141710802090733t1e26cf18gb0f05e1ddf16d2ca@mail.gmail.com> On Jan 25, 2008 11:40 AM, Simon Peyton-Jones wrote: > Would you be interested in working at Microsoft Research for three months? If so, you might want to think about applying for an internship. > > Simon and I are looking for interns, starting in summer 2008. Lots of background info here: > http://hackage.haskell.org/trac/ghc/wiki/Internships > including a bunch of possible projects, although you may also have ideas of your own. > Hello Simon, I wonder if there is any interest by the part of Microsoft and the Haskell community in a software model checker using SAT-based techniques for Haskell. There's have been in the last few year a couple of approaches on this for C by several people, including some Microsoft people. Cheers, Paulo Matos > But the bottom line is > - apply by end Feb 2008 for this round > - tell one of us that you have done so > > (None of this is restricted to Haskell stuff. You can apply to work at any Microsoft Research lab, on any topic. But there are a lot of applicants, so you are more likely to be successful if you are fairly specific about who at MSR you'd like to work with and why, and contact that person to say that you've applied.) > > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK From v.dijk.bas at gmail.com Sat Feb 9 10:48:59 2008 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Sat Feb 9 10:47:47 2008 Subject: [Haskell-cafe] Inverting a Monad In-Reply-To: <49a77b7a0802061958q3b1c9bat783c1e3815585b50@mail.gmail.com> References: <49a77b7a0802061958q3b1c9bat783c1e3815585b50@mail.gmail.com> Message-ID: On Feb 7, 2008 4:58 AM, David Menendez wrote: > If you're doing any kind of backtracking or non-determinism, you might > consider the msplit operation defined in "Backtracking, Interleaving, > and Terminating Monad Transformers" > . Thanks for pointing me to this very interesting paper! Bas From bertram.felgenhauer at googlemail.com Sat Feb 9 11:03:25 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat Feb 9 11:02:17 2008 Subject: [Haskell-cafe] Best practice for embedding files in a GHC-compiled tool? In-Reply-To: <9FA3427A-DC2B-4D81-9A7D-7D2765F86990@math.columbia.edu> References: <9FA3427A-DC2B-4D81-9A7D-7D2765F86990@math.columbia.edu> Message-ID: <20080209160325.GC4284@zombie.inf.tu-dresden.de> Dave Bayer wrote: > What is the best way to embed an arbitrary file in a Haskell program? I don't know the best way. I'd probably use FFI. main.hs: {-# LANGUAGE ForeignFunctionInterface #-} module Main where import Foreign import Foreign.ForeignPtr import qualified Data.ByteString as B import qualified Data.ByteString.Internal as BI foreign import ccall "& hello" hello :: Ptr Word8 foreign import ccall "& hello_size" helloSize :: Ptr Int main = do helloSize' <- peek helloSize hello' <- newForeignPtr_ hello let helloBS = BI.PS hello' 0 helloSize' B.putStr helloBS hello.c: char hello[] = "Hello, world!\n"; int hello_size = sizeof(hello); Test: # ghc -O -o main main.hs hello.c -package bytestring # ./main Hello, world! The idea is then to use some existing tool that embeds binary data in C programs. Bertram From bf3 at telenet.be Sat Feb 9 11:33:21 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sat Feb 9 11:32:08 2008 Subject: [Haskell-cafe] Newbie question: mutually exclusive strict / lazy Message-ID: Consider the function cond x y z = if x then y else z I guess we can certainly say cond is strict in x. But what about y and z? If x is true, then cond is strict in y If x is false, then cond is strict in z So we can't really say cond is lazy nor strict in its second or third argument. Of course, this is the case for many more functions, but in the case of the if-then-else primitive, does the strictness analyzer make use of this "mutually exclusive strictness" fact? Cheers, Peter From atomb at galois.com Sat Feb 9 11:52:34 2008 From: atomb at galois.com (Aaron Tomb) Date: Sat Feb 9 11:51:34 2008 Subject: [Haskell-cafe] Best practice for embedding files in a GHC-compiled tool? In-Reply-To: <20080209160325.GC4284@zombie.inf.tu-dresden.de> References: <9FA3427A-DC2B-4D81-9A7D-7D2765F86990@math.columbia.edu> <20080209160325.GC4284@zombie.inf.tu-dresden.de> Message-ID: On Feb 9, 2008, at 8:03 AM, Bertram Felgenhauer wrote: > Dave Bayer wrote: >> What is the best way to embed an arbitrary file in a Haskell program? > > I don't know the best way. I'd probably use FFI. > The idea is then to use some existing tool that embeds binary > data in C programs. Since you're specifically interested in OS X, I'd follow this advice, and then look at /usr/include/mach-o/getsect.h. This header declares a function extern char *getsectdata( const char *segname, const char *sectname, unsigned long *size); which seems like it'll give you all of the data in one of the sections of the executable file for the currently running program. I haven't used it, though, so I'm not positive about how it works. I think it's then fairly straightforward to tell the linker to just include an arbitrary file into a section with a name of your choice. Aaron From daniel.is.fischer at web.de Sat Feb 9 11:56:34 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Feb 9 11:53:54 2008 Subject: [Haskell-cafe] Newbie question: mutually exclusive strict / lazy In-Reply-To: References: Message-ID: <200802091756.34159.daniel.is.fischer@web.de> Am Samstag, 9. Februar 2008 17:33 schrieb Peter Verswyvelen: > Consider the function > > cond x y z = if x then y else z > > I guess we can certainly say cond is strict in x. > > But what about y and z? > > If x is true, then cond is strict in y > If x is false, then cond is strict in z > > So we can't really say cond is lazy nor strict in its second or third > argument. > > Of course, this is the case for many more functions, but in the case of > the if-then-else primitive, does the strictness analyzer make use of this > "mutually exclusive strictness" fact? > > Cheers, > Peter Hope I remember correctly... A function is strict in an argument, if whenever that argument is _|_, the result is _|_, regardless of possible other arguments. Since if True then 0 else _|_ == 0, if-then-else is nonstrict in the third argument, similarly if False then _|_ else 0 == 0, so if-then-else is nonstrict in the second argument. Cheers, Daniel From mfn-haskell-cafe at cs.york.ac.uk Sat Feb 9 14:07:08 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Sat Feb 9 14:07:26 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> Message-ID: <20080209190708.GA19255@venice.staff.cs.york.ac.uk> Hi Tom, > In addition to the sharing problem, another shortcoming of Haskell > DSLs is they can not fully exploit the benefits of algebraic > datatypes. Specifically, pattern matching ADTs can only be used to > control the compile-time configuration of the target, it can't be used > to describe the target's behavior -- at least for DSLs that generate > code that executes outside of Haskell's runtime. you can embed algebraic data types and pattern matching in Haskell with your own semantics, and retain type inference. It goes something like this: (nil, (|>)) = datatype (cons0 [] \/ cons2 (:)) map f xs = match xs rules where rules (x, xs) = [ nil --> nil , x |> xs --> f x |> map f xs ] here, map :: (Term a -> Term b) -> Term [a] -> Term [b]. The main issue is that you have to quantify the free variables in patterns, hence the "rules" function. I don't know if this helps you. > Writing a real compiler would solve both of these problems. Is there > any Haskell implementation that has a clean cut-point, from which I > can start from a fully type-checked, type-annotated intermediate > representation? The Yhc.Core library is very simple to use and fairly mature (Neil's been tweeking it for about 3 years now), but it doesn't meet your type-annotated requirement. (Untyped core is still pretty useful, though.) If you go the real compiler route, would it not make sense to take the DSL as the source language rather than Haskell? Or are the DSL and Haskell quite similar? Or perhaps you are thinking of a two language system, where some code is evaluated at compile time by Haskell, and some is compiled to the target language? If so, maybe you just want domain specific syntax inside a Haskell program, in which case the paper "Why it's nice to be quoted: quasiquoting for haskell" might be relevant (it's actually supported in GHC I think). Anyway, all very thought provoking! Matt. P.S. Tom Hawkins wrote: > Emil Axelsson wrote: > > I know of a few of ways to express sharing in a pure language: > > > > 1) "Observable sharing", which, in general, is unsafe. > > 2) Using Template Haskell > > 3) Matthew Naylor has done some work on "expressible sharing", which has > > 4) Use a monad (but I'm sure this is what you're trying to avoid). > > Or... > > 5) Forget embedding the DSL, and write a direct compiler. Taking options 2 or 5 just to solve the sharing problem sounds to me like a lot of hard work for little reward. But don't worry, I won't repeat my observable sharing speech. :-) From lemming at henning-thielemann.de Sat Feb 9 00:20:39 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Feb 9 15:26:45 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> Message-ID: On Fri, 8 Feb 2008, Tom Hawkins wrote: > 5) Forget embedding the DSL, and write a direct compiler. > > In addition to the sharing problem, another shortcoming of Haskell > DSLs is they can not fully exploit the benefits of algebraic > datatypes. Specifically, pattern matching ADTs can only be used to > control the compile-time configuration of the target, it can't be used > to describe the target's behavior -- at least for DSLs that generate > code that executes outside of Haskell's runtime. Also in a pure Haskell library you will try to avoid direct access to constructors, because the internal data structures might change. Better are functions that access the internal data of a type, like 'maybe' and 'either' for 'Maybe' and 'Either', respectively. From lemming at henning-thielemann.de Fri Feb 8 10:25:19 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Feb 9 16:42:35 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802081610.59914.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> Message-ID: On Fri, 8 Feb 2008, Wolfgang Jeltsch wrote: > Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie: > > > > Even if () would be preferred from the programmers point of view (I'm > > not sure how much we could reduce the number of instances though), it > > makes the representation less attractive on the user-side. Anyone > > using the library would find it annoying and would wonder why is it > > neccessary. > > I wouldn?t wonder. Leaving out the () :* part just works because our > type-level ?values? are not typed, i.e., there aren?t different kinds Digit > and Number but only kind *. If :+ would be a data constructor (on the value > level), it would take a number and a digit argument which would forbid using > a digit as its left argument. So I consider using a digit on the left > as ?unclean?. It?s similar to using a number as the second part of a cons > cell in LISP. seconded From alfonso.acosta at gmail.com Sat Feb 9 17:33:16 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 9 17:32:03 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802081610.59914.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802091433m301637a3qd275fefdf934cdc1@mail.gmail.com> On Feb 8, 2008 4:10 PM, Wolfgang Jeltsch wrote: > Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie: > > Even if () would be preferred from the programmers point of view (I'm > > not sure how much we could reduce the number of instances though), it > > makes the representation less attractive on the user-side. Anyone > > using the library would find it annoying and would wonder why is it > > neccessary. > > I wouldn't wonder. Leaving out the () :* part just works because our > type-level "values" are not typed, i.e., there aren't different kinds Digit > and Number but only kind *. If :+ would be a data constructor (on the value > level), it would take a number and a digit argument which would forbid using > a digit as its left argument. Well, the fact is that :+ (or :* as it is called now) is not a value constructor but a type constructor as you said, so I don't think your example really applies here. Besides, you should be regarded :* as (,) and not as a constructor which "would take a number and a digit argument which would forbid using a digit as its left argument." Indeed, :* exists as a value-level constructor too and works exactly like that. Furthermore, you probably consider using () as natural and logical because you are still thinking from the implementation side. If you forget the implementation details and think as a user who barely wants to write type-level numerical literals, :* is simply an ugly syntactic requirement which we cannot get rid of (I would be happy to find another representation closer to a literal, but I couldn't until now). That is not the case for (), since, as shown in the initial implementation, can be avoided. So, for me, it's just a matter of usability and syntax, the closer the representation can be to literals, the better. I don't see the semantic implications of :* as a valid argument. For me, :* is just an unavoidable ugly syntactical token without meaning. Imagine that for some reason, adding () as a prefix in every numerical literal made the implementation of a compiler slightly easier/faster. I bet users would rant about it till exhaustion :) If the argument was that, for some reason, () was proven to speed up the implementation or make a big maintainability difference (I still have my doubts) it would maybe make more sense (I still wouldn't be sure if it pays off though). Maybe it would be a good idea to create a patch and see what happens :) As a side note, I think that type-value digits actually are "typed" (metatyped maybe is a nicer term?). Class constraints take the role of types in this case. After all (sorry if the definition is imprecise), a type establishes a set of valid values. "Nat n => n" does exactly that. For example, it forces type-level naturals to be normalized (i.e. numerals with leading zeros don't satisfy the Nat constraint) > So I consider using a digit on the left > as "unclean". It's similar to using a number as the second part of a cons > cell in LISP. Again, the comparisson is based on semantical implications of the implementation which shouldn't be visible for, or at least not taken into consideration by, the final user. From alfonso.acosta at gmail.com Sat Feb 9 17:37:28 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 9 17:36:15 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802091437xe1ed637q96bad3a76f49dbb4@mail.gmail.com> On Feb 8, 2008 5:14 PM, Stefan Monnier wrote: > How 'bout treating :+ as similar to `append' rather than similar to `cons'? > Basically treat :+ as taking 2 numbers (rather than a number and > a digit). Interpreting it like that would certainly make make more sense. But again, I think that :* should be interpreted just as an unavoidable syntactical annoyance without meaning or interpretation. From alfonso.acosta at gmail.com Sat Feb 9 17:46:54 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 9 17:45:43 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802091608.53295.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> <200802091608.53295.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802091446t65d0bb79hc0479f1390d19199@mail.gmail.com> On Feb 9, 2008 4:08 PM, Wolfgang Jeltsch wrote: > So what would (D1 :* D1) :* (D2 :* D2) mean then? Nothing. That value doesn't satisfy the Nat or Post class constraints and should be taken into consideration. Why should :* be provided a meaning? it is an unavoidable syntactical connective for all that I care. The meaning is provided by class constraints and that's all that matter from the semantical point of view. From alfonso.acosta at gmail.com Sat Feb 9 17:52:18 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 9 17:51:04 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802091433m301637a3qd275fefdf934cdc1@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> <6a7c66fc0802091433m301637a3qd275fefdf934cdc1@mail.gmail.com> Message-ID: <6a7c66fc0802091452l2b700e9bpa9d3a0666b9c78a7@mail.gmail.com> On Feb 9, 2008 11:33 PM, Alfonso Acosta wrote: > On Feb 8, 2008 4:10 PM, Wolfgang Jeltsch wrote: > example really applies here. Besides, you should be regarded :* as (,) > and not as a constructor which "would take a number and a digit Sorry for my lousy English, I meant "you should regard" not "you should be regarded". From alfonso.acosta at gmail.com Sat Feb 9 18:55:19 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 9 18:54:06 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> Message-ID: <6a7c66fc0802091555h519e87ddnacd9bcc2bc09c8c7@mail.gmail.com> On Feb 9, 2008 12:28 AM, Tom Hawkins wrote: > 5) Forget embedding the DSL, and write a direct compiler. > > In addition to the sharing problem, another shortcoming of Haskell > DSLs is they can not fully exploit the benefits of algebraic > datatypes. Specifically, pattern matching ADTs can only be used to > control the compile-time configuration of the target, it can't be used > to describe the target's behavior -- at least for DSLs that generate > code that executes outside of Haskell's runtime. Only partly true. Probably you are not aware of them (I myself learned about its existence a few days ago) but pattern quasiquoting (available in GHC's HEAD) can be used for that. http://www.haskell.org/ghc/dist/current/docs/users_guide/template-haskell.html#th-quasiquotation > > Writing a real compiler would solve both of these problems. Is there > any Haskell implementation that has a clean cut-point, from which I > can start from a fully type-checked, type-annotated intermediate > representation? If you have to write a compiler why not define a language which fits better with the semantics of the embedded language instead of using plain Haskell? The approach you propose has the disadvantages of both the embedded and the standalone languages. On one hand you have to stick with the syntax of the host language which may not fit with your exact semantical requirements and, on the other hand, you cannot take advantage of all the existing machinery around the host language (you have to code your own compiler). Furthermore, the first citizen status of functions make it impossible (or really difficult at least) to compile EDSL descriptions avoiding runtime and simply applying a static analysis approach (using Core or plain Haskell as input). > And thanks for the link to John's paper describing Hydra's use of > Template Haskell. I will definiately consider TH. Well, TH would be one of those static analysis approaches. Actually, O'Donell's implementation (which uses an outdated version of Template Haskell) only works with a small Haskell subset. So using TH you'd probably be changing the host language anyhow. Furthermore, the TH approach consists in adding node labels by preprocessing the EDSL description, making sharing observable. That makes the original EDSL description inpure. The only difference is that side effects are added by preprocessing instead of using runtime unsafe functions. ---- Some pointers covering the topic: [1] and [2] summarize what are the alternatives to observe sharing in Haskell whereas [3] compares the embedded approach vs standalone approach and advocates the last one. 1) http://www.imit.kth.se/~ingo/MasterThesis/ThesisAlfonsoAcosta2007.pdf (section 2.4.1 and 3.1) 2) http://www.cs.um.edu.mt/svrg/Papers/csaw2006-01.pdf (section 3) 3) http://web.cecs.pdx.edu/~sheard/papers/secondLook.ps From lemming at henning-thielemann.de Fri Feb 8 08:16:27 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Feb 9 18:54:21 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <20080208105612.GA19796@venice.staff.cs.york.ac.uk> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <20080208105612.GA19796@venice.staff.cs.york.ac.uk> Message-ID: On Fri, 8 Feb 2008, Matthew Naylor wrote: > Now recall that referential transparency lets you replace equals with > equals without changing the *value produced* by a program. Note that > it says nothing about preserving *runtime behaviour*. Sharing, for > example, may be lost. So if you do equational reasoning on function > "f" (above), and loose some sharing, then you can only expect that the > same sharing will also be also lost in the generated program. As long > as the generated program computes the same result as it did before, > referential transparency will be, overall, preserved; it would only be > lost intermediately. This is what I mean by "safe". I think there are degrees of observability. If a Haskell library immediately talks to a C library and shares resources generated by the library, then this sharing can be hardly observed and the method is somehow safe. If you generate a C program with Haskell and write it to a disk it can be easily observed and people might rely on a particular resulting C program. If the C program is piped to a C compiler which is immediately run, then sharing can be hardly observed. Even within Haskell sharing is somehow observable, the Haskell program could observe the free memory of the machine and thus it can see a difference between sharing and duplicated objects. From lemming at henning-thielemann.de Fri Feb 8 11:28:44 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Feb 9 19:06:23 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <85BABA82-5700-4EE2-ACEB-D806A817EB8B@ece.cmu.edu> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> <85BABA82-5700-4EE2-ACEB-D806A817EB8B@ece.cmu.edu> Message-ID: On Fri, 8 Feb 2008, Brandon S. Allbery KF8NH wrote: > On Feb 8, 2008, at 11:14 , Stefan Monnier wrote: > > >>>> You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I > >>>> think, the > >>>> latter representation should probably be prefered. > >>>> (...) > > How 'bout treating :+ as similar to `append' rather than similar to > > `cons'? > > Basically treat :+ as taking 2 numbers (rather than a number and > > a digit). > > Dumb questions department: why not define e.g. D'0 .. D'9 as () :* > 0 .. () :* 9? Programmers then get D'1 :* 2, but the library sees > () :* 1 :* 2. Do you remember that they talk about types D0, D1, and so on? From lemming at henning-thielemann.de Fri Feb 8 08:23:02 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Feb 9 19:07:53 2008 Subject: [Haskell-cafe] Create a list without duplicates from a list with duplicates In-Reply-To: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> Message-ID: On Fri, 8 Feb 2008, news@lyra.net wrote: > Hallo! > > Let's suppose I have a list [a,b,c,d,c,d]. I'd like to write > a function that returns a new list without duplicates (in > the example [a,b,c,d]). How can I do that? What is the most > general way? I'd like to use the same function for a list of > Int or String or some other user defined data type. List.nub I assume you couldn't find this function due its cryptic name. Don't worry, many others failed before. From simeon.mattes at gmail.com Sat Feb 9 19:09:20 2008 From: simeon.mattes at gmail.com (Mattes Simeon) Date: Sat Feb 9 19:23:49 2008 Subject: [Haskell-cafe] Datatypes - Haskell Message-ID: Hello to everybody I am an new user of Haskel and generally in functional programming and I could say that I am very impressed from this Language. Though I can't understand the use of datatypes. Let's take a firly simple situtation e.g. data Pair a b = Pair a b i.e. an new type with name Pair parameterized over the types a,b with one Constructor named Paid which take two values of type a,b a more complex one would be data Either a b = Left a | Right b i.e a new type named Either parameterized over the types a, b and two Constructors 1. Left which take one value of type a and 2. Right which takes one value of type b I consider that the definitions above are well formulated. Nevertheless I can't understand them quite well. I have read that datatypes are used to define new structures. So, is there any corresponding example in C, sinch I am quite familiar with structures in it? I hope the word C here is allowed here :o) Thanks From allbery at ece.cmu.edu Sat Feb 9 19:28:54 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Feb 9 19:27:43 2008 Subject: [Haskell-cafe] Datatypes - Haskell In-Reply-To: References: Message-ID: On Feb 9, 2008, at 19:09 , Mattes Simeon wrote: > e.g. data Pair a b = Pair a b struct Pair { a pair_a; b pair_b; }; > data Either a b = Left a | Right b union Either { enum { Left, Right } _tag; a either_left; b either_right; }; (except that Haskell makes sure you use it properly, while C will let you access foo.either_right when foo._tag == Left). -- 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 sebastian.sylvan at gmail.com Sat Feb 9 19:52:10 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat Feb 9 19:50:57 2008 Subject: [Haskell-cafe] Datatypes - Haskell In-Reply-To: References: Message-ID: <3d96ac180802091652s1da0ae5as345fa3ec8afbc000@mail.gmail.com> On Feb 10, 2008 12:09 AM, Mattes Simeon wrote: > Hello to everybody > > I am an new user of Haskel and generally in functional programming and I > could > say that I am very impressed from this Language. Though I can't understand > the > use of datatypes. > > Let's take a firly simple situtation > > e.g. data Pair a b = Pair a b > > i.e. an new type with name Pair parameterized over the types a,b with one > Constructor named Paid which take two values of type a,b > > a more complex one would be > data Either a b = Left a | Right b > > i.e a new type named Either parameterized over the types a, b and two > Constructors 1. Left which take one value of type a and 2. Right which > takes one > value of type b > > I consider that the definitions above are well formulated. Nevertheless I > can't > understand them quite well. > > I have read that datatypes are used to define new structures. So, is there > any > corresponding example in C, sinch I am quite familiar with structures in > it? I > hope the word C here is allowed here :o) > I guess C++ would be closer... template< class A, class B> struct Pair { A fst; B snd; } template< class A, class B> struct Either { enum {Left, Right} tag; union{ A left; B right; }; } In the second example the tag would be used to figure out which of the two alternatives the structure actually is. In Haskell you can just pattern match on the constructor. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080210/c3fc18eb/attachment.htm From stevelihn at gmail.com Sat Feb 9 21:59:19 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Sat Feb 9 21:58:06 2008 Subject: [Haskell-cafe] ANN: Finance-Treasury 0.1.1 Message-ID: A new experimental package, Finance-Treasury, has been uploaded to hackage. It automates the fetching of Treasury's daily yield curve data (XML) and translates the data into Data.Map representation. The collection of historical data can go back to 1992. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Treasury The APIs are largely working. But the internal code still needs improvement. Welcome suggestions and fixes. Recommendation on proper error handling design will be particularly appreciated. steve From alfonso.acosta at gmail.com Sat Feb 9 23:14:06 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Feb 9 23:12:52 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802071616.06220.g9ks157k@acme.softbase.org> <6a7c66fc0802070731u50c27d9bk7114f8735df131d2@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> <85BABA82-5700-4EE2-ACEB-D806A817EB8B@ece.cmu.edu> Message-ID: <6a7c66fc0802092014t66e01ea3uc18c451a6fef1f8d@mail.gmail.com> Moving on to the implementation of fixed-sized vectors themselves ... I have been trying to implement them as a GADT but I have run into quite few problems. As a result, I'm considering to implement them using the more-traditional phantom type-parameter approach. Anyhow, I'd like to share those problems with the list, just in case someone comes with a solution. Here are some examples of what I was able to define without problems (although, for some cases, I was forced to "break" the safety layer of the GADT by using the toInt reflection function). Save this email as FSVec.lhs to test them. > {-# LANGUAGE GADTs, Rank2Types, ScopedTypeVariables, KindSignatures #-} > module Data.Param.FSVec where > > import Data.TypeLevel.Num The Fixed Sized Vector data type. I know Wolfgang would prefer something more closely named to LiSt to, but let's avoid getting into that discussion now. > data FSVec :: * -> * -> * where > NullV :: FSVec D0 a > (:>) :: Succ s s' => a -> FSVec s a -> FSVec s' a > infixr :> Some successful examples > headV :: Pos s => FSVec s a -> a > headV (x :> xs) = x > lastV :: Pos s => FSVec s a -> a > lastV = lastV' > -- trusted function without the Pos constraint, otherwise the compiler would complain about > -- the Succ constraint of :> not being met. > where lastV' :: FSVec s a -> a > lastV' (x :> NullV) = x > lastV' (x :> xs) = lastV' xs > atV :: (Pos s, Nat n, n :<: s) => FSVec s a -> n -> a > atV v n = atV' v (toInt n) > -- Reflecting the index breaks checking that the recursive call > -- verifies the atV constraints, however I couldn't find another way. > -- atV' is to be trusted regarding the recursive call > where atV' :: FSVec s a -> Int -> a > atV' (x :> xs) n > | n == 0 = x > | otherwise = atV' xs (n-1) > -- this defition is nicer but doesn't typecheck > -- atV (x :> xs) n > -- | toInt n == 0 = x > -- | otherwise = atV xs (predRef n) Now some functions which I wasn't able to define Concat function. This would be the naive implementation, but it fails to compile. (<+>) :: Add s1 s2 s3 => FSVec s1 a -> FSVec s2 a -> FSVec s3 a NullV <+> ys = ys (x:>xs) <+> ys = x :> (xs <+> ys) Tail function, which is also incorrect. tailV :: Succ s' s => FSVec s a -> FSVec s' a tailV (x :> xs) = xs And finally, vector, which is supposed to build a fixed-sized vector out of a list. The ideal type for the function would be: vector :: [a] -> FSVec s a But there is no apparent way in which to obtain s based on the length of the input list. [1] shows a way in which to create vector using CPS style and a reification function: reifyInt :: Int -> (forall s . Nat s => FSVect s a -> w) -> w The result would be a function with the following type: vector :: [a] -> (forall s . Nat s => FSVec s a -> w) -> w Nevertheless, I'm not fully satisfied by it. Another alternative would be forcing the user to provide the size explicitly (which is ugly as well) vector' :: Nat s => s -> [a] -> FSVec s a The Succ constraint in the definition of :> doesn't allow me to do such a thing. The following implementation does not typecheck: vector' :: Nat s => s -> [a] -> FSVec s a vector' s l | toInt s == length l = vector' l | otherwise = error "dynamic/static size mismatch" where vector'' :: [a] -> FSVec s a vector'' [] = NullV vector'' (x : xs) = x :> vector' xs The problem is that I don't know a way in which to "bypass" the Succ constraint of :> . Using a traditional phantom type-parameter to express the size is the only solution I can think of (which would also solve the problems of init and tail). However, that would mean losing the ability of pattern matching with (:>). Any comments/suggestions would be very much appreciated. Cheers, Fons [1] http://ofb.net/~frederik/vectro/draft-r2.pdf From tomahawkins at gmail.com Sun Feb 10 01:45:49 2008 From: tomahawkins at gmail.com (Tom Hawkins) Date: Sun Feb 10 01:44:35 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <20080209190708.GA19255@venice.staff.cs.york.ac.uk> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> <20080209190708.GA19255@venice.staff.cs.york.ac.uk> Message-ID: <594c1e830802092245w5ddcf79cp60dde0f098321ee6@mail.gmail.com> Hi Matt, On Feb 9, 2008 1:07 PM, Matthew Naylor wrote: > If you go the real compiler route, would it not make sense to take the > DSL as the source language rather than Haskell? Or are the DSL and > Haskell quite similar? The two are nearly identical. In fact the only significant difference between the languages is the semantics of top level monad; it wouldn't be IO, but something else. With the syntax the same, it could leverage much of Haskell's standard library. > Or perhaps you are thinking of a two language > system, where some code is evaluated at compile time by Haskell, and > some is compiled to the target language? Not necessarily in the same compilation flow, but I can think of several scenarios where it would be advantageous for code written in this other language to be pulled into a conventional Haskell program. > Taking options 2 or 5 just to solve the sharing problem sounds to me > like a lot of hard work for little reward. But don't worry, I won't > repeat my observable sharing speech. :-) So is the general strategy with observable sharing to use unsafePerformIO with Data.Unique to label expressions at construction? Ahh...clever! I did not think of this. Of course, now that you have me reading up on Yhc.Core, option #5 is looking considerably more fun. -Tom From simeon.mattes at gmail.com Sun Feb 10 07:40:59 2008 From: simeon.mattes at gmail.com (Mattes Simeon) Date: Sun Feb 10 07:39:57 2008 Subject: [Haskell-cafe] Re: Datatypes - Haskell References: <3d96ac180802091652s1da0ae5as345fa3ec8afbc000@mail.gmail.com> Message-ID: Thanks for your help. It was very useful. Though in comparison with C or C++ I can't figure out so clear the syntax. Maybe it has to do with the syntactic Sugar of each Language. I 'll give you a similar example I saw in a book for Haskel The following program just returns the value of the position of a datatype Tuple which can hold one or two elements. data Tuple a b = One a | Two a b tuple1 (One a)= Just a tuple1 (Two a b) = Just a tuple2 (One a) = Nothing tuple2 (Two a b) = Just b The corresponding Version in C++, which seems to be more appropriate, would be template struct Tuple { enum (One, Two) tag; union { A either_one; struct nOne { A either_two B two; }; }; } Am I wrong. If not, how can I use it in the corresponding function in C++? I seems realy strange, and I'm confused. Surely a solution to this would be to use the standard types of Haskel for tuples and check out each time if I have just a number or a tuple. But this is how somebody thinks in imperative languages. Functional programming is something more, isn't it? Sorry for beeing so naive, but although unions, enum, structure are just some tools in C, surely something more in C++, in Haskell they are seem to be a standard. From asviraspossible at gmail.com Sun Feb 10 08:12:10 2008 From: asviraspossible at gmail.com (Victor Nazarov) Date: Sun Feb 10 08:10:55 2008 Subject: [Haskell-cafe] Re: Datatypes - Haskell In-Reply-To: References: <3d96ac180802091652s1da0ae5as345fa3ec8afbc000@mail.gmail.com> Message-ID: On Feb 10, 2008 3:40 PM, Mattes Simeon wrote: > Thanks for your help. It was very useful. > > Though in comparison with C or C++ I can't figure out so clear the syntax. > Maybe it has to do with the syntactic Sugar of each Language. I 'll give you a > similar example I saw in a book for Haskel > > The following program just returns the value of the position of a datatype Tuple > which can hold one or two elements. > > data Tuple a b = One a | Two a b > tuple1 (One a)= Just a > tuple1 (Two a b) = Just a > > tuple2 (One a) = Nothing > tuple2 (Two a b) = Just b > > The corresponding Version in C++, which seems to be more appropriate, would be I think this is the most native way to do it in C++: template class Tuple { public: static Tuple *One (A *a) { return new One (a); } static Tuple *Two (A *a, B *b) { return new Two (a, b); } virtual A *tuple1 () = 0; virtual B *tuple2 () = 0; }; template class One : Tuple { public: One (A *a) { this->a = a; } A *tuple1 () { return a; } B *tuple2 () { return NULL; } private: A *a; } template class Two: Tuple { public: Two (A *a, B *b) { this->a = a; this->b = b} A *tuple1 () { return a; } B *tuple2 () { return b; } private: A *a; B *b; } -- vir http://vir.comtv.ru/ From mfeathers at mindspring.com Sun Feb 10 08:34:01 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Sun Feb 10 08:33:10 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> Message-ID: <47AEFD49.3070106@mindspring.com> On a lark, I loaded this into Hugs this morning, and it didn't complain: data Thing = Thing (Integer -> Integer) But, I've never seen that sort of construct in an example. Do people ever embed functions in ADTs? Michael From chaddai.fouche at gmail.com Sun Feb 10 08:42:36 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Sun Feb 10 08:41:24 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: <47AEFD49.3070106@mindspring.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> Message-ID: 2008/2/10, Michael Feathers : > On a lark, I loaded this into Hugs this morning, and it didn't complain: > > > data Thing = Thing (Integer -> Integer) > > > > But, I've never seen that sort of construct in an example. Do people > ever embed functions in ADTs? Yes, anyway you can embed function in Maybe a or Either a b for example, since they're polymorphic. Embedding functions in ADT purposefully happens quite often too, just look at the State Monad, the functionnal references proposal and so on... Recently I embedded functions into a denotational semantic ADT for a tiny DSL, there's plenty of use cases. -- Jeda? From sebastian.sylvan at gmail.com Sun Feb 10 08:42:50 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sun Feb 10 08:41:37 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: <47AEFD49.3070106@mindspring.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> Message-ID: <3d96ac180802100542y1ddba9e2r96b391f40bb36894@mail.gmail.com> On Feb 10, 2008 1:34 PM, Michael Feathers wrote: > On a lark, I loaded this into Hugs this morning, and it didn't complain: > > > data Thing = Thing (Integer -> Integer) > > > > But, I've never seen that sort of construct in an example. Do people > ever embed functions in ADTs? Yes, this is quite common. Here's a quick example (untested): data MyMap key value = M (key -> Maybe value) lookup (M m) key = m key insert (M m) key value = M (\key' -> if key' == key then Just value else m key') This is a naive data structure for storing a map as a function from the key to the value. Not very efficient, perhaps, but you use similar concepts in more useful scenarios (e.g. the State monad). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080210/66318ab6/attachment.htm From sebastian.sylvan at gmail.com Sun Feb 10 08:44:29 2008 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sun Feb 10 08:43:15 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: <3d96ac180802100542y1ddba9e2r96b391f40bb36894@mail.gmail.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <3d96ac180802100542y1ddba9e2r96b391f40bb36894@mail.gmail.com> Message-ID: <3d96ac180802100544o7e2326apa6a8243f76679117@mail.gmail.com> On Feb 10, 2008 1:42 PM, Sebastian Sylvan wrote: > > > On Feb 10, 2008 1:34 PM, Michael Feathers > wrote: > > > On a lark, I loaded this into Hugs this morning, and it didn't complain: > > > > > > data Thing = Thing (Integer -> Integer) > > > > > > > > But, I've never seen that sort of construct in an example. Do people > > ever embed functions in ADTs? > > > Yes, this is quite common. Here's a quick example (untested): > > data MyMap key value = M (key -> Maybe value) > > lookup (M m) key = m key > insert (M m) key value = M (\key' -> if key' == key then Just value else m > key') > > This is a naive data structure for storing a map as a function from the > key to the value. Not very efficient, perhaps, but you use similar concepts > in more useful scenarios (e.g. the State monad). > Perhaps I should add an empty MyMap too: empty = M (\_-> Nothing ) -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080210/aae62474/attachment.htm From lrpalmer at gmail.com Sun Feb 10 08:54:51 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Feb 10 08:53:36 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: <47AEFD49.3070106@mindspring.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> Message-ID: <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> Quite frequently. Here are a few examples from my own code: For "functional references" (representing a bidirectional function from a data type to a part of itself (for example the first element of a pair)). > data Accessor s a > = Accessor { get :: s -> a > , set :: a -> s -> s > } My quantum computation arrow (really in the realm of "concrete, useful things", huh? :-) > data Operator b c > = Op (forall d. QStateVec (b,d) -> IO (QStateVec (c,d))) > | ... The ubiquitous FRP Behavior, comprising a current value and a function which takes a timestep and returns the next value. > data Behavior a > = Behavior a (Double -> Behavior a) The "suspend" monad, representing a computation which can either finish now with a value of type a, or suspends to request a value of type v before continuing. > data Suspend v a > = Return a > | Suspend (v -> Suspend v a) It seems that most frequently, functions in ADTs are used when implementing monads or arrows, but that doens't need to be the case. A lot of times a function is the best way to represent a particular part of a data structure :-) Luke On Feb 10, 2008 1:34 PM, Michael Feathers wrote: > On a lark, I loaded this into Hugs this morning, and it didn't complain: > > > data Thing = Thing (Integer -> Integer) > > > > But, I've never seen that sort of construct in an example. Do people > ever embed functions in ADTs? > > > Michael > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mfeathers at mindspring.com Sun Feb 10 09:32:54 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Sun Feb 10 09:32:08 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> Message-ID: <47AF0B16.5060500@mindspring.com> Great. Thanks to everyone! Michael Luke Palmer wrote: > Quite frequently. > > Here are a few examples from my own code: > > For "functional references" (representing a bidirectional function > from a data type to a part of itself (for example the first element of > a pair)). > > >> data Accessor s a >> = Accessor { get :: s -> a >> , set :: a -> s -> s >> } >> > > My quantum computation arrow (really in the realm of "concrete, useful > things", huh? :-) > > >> data Operator b c >> = Op (forall d. QStateVec (b,d) -> IO (QStateVec (c,d))) >> | ... >> > > The ubiquitous FRP Behavior, comprising a current value and a function > which takes a timestep and returns the next value. > > >> data Behavior a >> = Behavior a (Double -> Behavior a) >> > > The "suspend" monad, representing a computation which can either > finish now with a value of type a, or suspends to request a value of > type v before continuing. > > >> data Suspend v a >> = Return a >> | Suspend (v -> Suspend v a) >> > > It seems that most frequently, functions in ADTs are used when > implementing monads or arrows, but that doens't need to be the case. > A lot of times a function is the best way to represent a particular > part of a data structure :-) > > Luke > > On Feb 10, 2008 1:34 PM, Michael Feathers wrote: > >> On a lark, I loaded this into Hugs this morning, and it didn't complain: >> >> >> data Thing = Thing (Integer -> Integer) >> >> >> >> But, I've never seen that sort of construct in an example. Do people >> ever embed functions in ADTs? >> >> >> Michael >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > From mfeathers at mindspring.com Sun Feb 10 10:07:01 2008 From: mfeathers at mindspring.com (Michael Feathers) Date: Sun Feb 10 10:06:12 2008 Subject: [Haskell-cafe] nub vs. find + (:) Is this abysmal code? In-Reply-To: <47AF0B16.5060500@mindspring.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> <47AF0B16.5060500@mindspring.com> Message-ID: <47AF1315.1000406@mindspring.com> How bad is this: addProduct :: [Product] -> Product -> [Product] addProduct inventory product = nub (product : inventory) compared to this: addProduct :: [Product] -> Product -> [Product] addProduct inventory p | isNothing (find (==p) inventory) = p : inventory | otherwise = inventory My guess is that the latter is more efficient, but then when I think about laziness, I wonder whether the first is a fair trade. Michael From felipe.lessa at gmail.com Sun Feb 10 10:11:46 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Feb 10 10:10:31 2008 Subject: [Haskell-cafe] nub vs. find + (:) Is this abysmal code? In-Reply-To: <47AF1315.1000406@mindspring.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> <47AF0B16.5060500@mindspring.com> <47AF1315.1000406@mindspring.com> Message-ID: On Feb 10, 2008 1:07 PM, Michael Feathers wrote: > How bad is this: > > addProduct :: [Product] -> Product -> [Product] > addProduct inventory product = nub (product : inventory) > O(n?) as is nub. > compared to this: > > addProduct :: [Product] -> Product -> [Product] > addProduct inventory p > | isNothing (find (==p) inventory) = p : inventory > | otherwise = inventory O(n) as is find. > My guess is that the latter is more efficient, but then when I think > about laziness, I wonder whether the first is a fair trade. I don't think so =). Still, you should be using Data.Set which will take you to O(log n). -- Felipe. From chaddai.fouche at gmail.com Sun Feb 10 10:14:12 2008 From: chaddai.fouche at gmail.com (=?ISO-8859-1?Q?Chadda=EF_Fouch=E9?=) Date: Sun Feb 10 10:12:58 2008 Subject: [Haskell-cafe] nub vs. find + (:) Is this abysmal code? In-Reply-To: <47AF1315.1000406@mindspring.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> <47AF0B16.5060500@mindspring.com> <47AF1315.1000406@mindspring.com> Message-ID: 2008/2/10, Michael Feathers : > > How bad is this: > > addProduct :: [Product] -> Product -> [Product] > addProduct inventory product = nub (product : inventory) > This is pretty terrible, if the list is consumed afterward (which we assume it will be) we should have something like a O(n^3) complexity... Since nub is O(n^2). > > compared to this: > > addProduct :: [Product] -> Product -> [Product] > addProduct inventory p > | isNothing (find (==p) inventory) = p : inventory > | otherwise = inventory > This is much better, though probably better writed : > addProduct :: [Product] -> Product -> [Product] > addProduct inventory p > | elem p inventory = p : inventory > | otherwise = inventory and probably even better with a Set instead of a List... -- Jeda? From felipe.lessa at gmail.com Sun Feb 10 10:20:59 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Feb 10 10:19:44 2008 Subject: [Haskell-cafe] nub vs. find + (:) Is this abysmal code? In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> <47AF0B16.5060500@mindspring.com> <47AF1315.1000406@mindspring.com> Message-ID: On Feb 10, 2008 1:14 PM, Chadda? Fouch? wrote: > This is much better, though probably better writed : > > addProduct :: [Product] -> Product -> [Product] > > addProduct inventory p > > | elem p inventory = p : inventory > > | otherwise = inventory Maybe addProduct :: [Product] -> Product -> [Product] addProduct inventory p = p : delete p inventory > and probably even better with a Set instead of a List... import qualified Data.Set as S addProduct :: S.Set Product -> Product -> S.Set Product addProduct = flip S.insert -- Felipe. From felipe.lessa at gmail.com Sun Feb 10 10:22:35 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Feb 10 10:21:20 2008 Subject: [Haskell-cafe] nub vs. find + (:) Is this abysmal code? In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> <47AF0B16.5060500@mindspring.com> <47AF1315.1000406@mindspring.com> Message-ID: On Feb 10, 2008 1:20 PM, Felipe Lessa wrote: > Maybe > > addProduct :: [Product] -> Product -> [Product] > addProduct inventory p = p : delete p inventory Oh, forget this, it will keep rewriting the tail of the list, which is a Bad Thing (TM). -- Felipe. From lemming at henning-thielemann.de Sun Feb 10 10:59:51 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Feb 10 10:58:47 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> Message-ID: On Sun, 10 Feb 2008, Henning Thielemann wrote: > On Sun, 10 Feb 2008, Luke Palmer wrote: > > > Quite frequently. > > > > Here are a few examples from my own code: > > > > For "functional references" (representing a bidirectional function > > from a data type to a part of itself (for example the first element of > > a pair)). > > > > > data Accessor s a > > > = Accessor { get :: s -> a > > > , set :: a -> s -> s > > > } > > > > My quantum computation arrow (really in the realm of "concrete, useful > > things", huh? :-) > > The pattern seems to be common enough to be turned into a package. > > http://www.haskell.org/haskellwiki/?title=Record_access&action=history I meant http://www.haskell.org/haskellwiki/Record_access From lemming at henning-thielemann.de Sun Feb 10 10:59:09 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Feb 10 10:58:57 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> Message-ID: On Sun, 10 Feb 2008, Luke Palmer wrote: > Quite frequently. > > Here are a few examples from my own code: > > For "functional references" (representing a bidirectional function > from a data type to a part of itself (for example the first element of > a pair)). > > > data Accessor s a > > = Accessor { get :: s -> a > > , set :: a -> s -> s > > } > > My quantum computation arrow (really in the realm of "concrete, useful > things", huh? :-) The pattern seems to be common enough to be turned into a package. http://www.haskell.org/haskellwiki/?title=Record_access&action=history From lemming at henning-thielemann.de Sun Feb 10 11:02:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun Feb 10 11:01:14 2008 Subject: [Haskell-cafe] nub vs. find + (:) Is this abysmal code? In-Reply-To: <47AF1315.1000406@mindspring.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> <7ca3f0160802100554g578ee083v902d46fd4600b47b@mail.gmail.com> <47AF0B16.5060500@mindspring.com> <47AF1315.1000406@mindspring.com> Message-ID: On Sun, 10 Feb 2008, Michael Feathers wrote: > How bad is this: > > addProduct :: [Product] -> Product -> [Product] > addProduct inventory product = nub (product : inventory) > > > compared to this: > > addProduct :: [Product] -> Product -> [Product] > addProduct inventory p > | isNothing (find (==p) inventory) = p : inventory > | otherwise = inventory Data.Set is first choice, 'elem' is second choice, but still better than 'isNothing (find ...)'. From g9ks157k at acme.softbase.org Sun Feb 10 11:43:40 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sun Feb 10 11:42:42 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802092014t66e01ea3uc18c451a6fef1f8d@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802092014t66e01ea3uc18c451a6fef1f8d@mail.gmail.com> Message-ID: <200802101743.41443.g9ks157k@acme.softbase.org> Am Sonntag, 10. Februar 2008 05:14 schrieben Sie: > [?] > Now some functions which I wasn't able to define > > Concat function. This would be the naive implementation, but it fails > to compile. > > (<+>) :: Add s1 s2 s3 => FSVec s1 a -> FSVec s2 a -> FSVec s3 a > NullV <+> ys = ys > (x:>xs) <+> ys = x :> (xs <+> ys) Hmm, we would have to find a way to implement lemmas. In this case, the lemma that succ (x + y) = succ x + y. At the moment, I?ve no good idea how to do that. > Tail function, which is also incorrect. > > tailV :: Succ s' s => FSVec s a -> FSVec s' a > tailV (x :> xs) = xs Maybe this problem is similar to the one I came across earlier. See my mail on and the replies to it. > And finally, vector, which is supposed to build a fixed-sized vector > out of a list. > > The ideal type for the function would be: > > vector :: [a] -> FSVec s a > > But there is no apparent way in which to obtain s based on the length > of the input list. > > [1] shows a way in which to create vector using CPS style and a > reification function: > > reifyInt :: Int -> (forall s . Nat s => FSVect s a -> w) -> w > > The result would be a function with the following type: > > vector :: [a] -> (forall s . Nat s => FSVec s a -> w) -> w > > Nevertheless, I'm not fully satisfied by it. I suppose, it?s the best we can get without having dependent types. Others might correct me. > [?] Some remark concerning spelling: Would it be possible to drop the V at the end of the function names? I think the fact that those functions are about ?vectors? is better expressed by qualification: import Data.List as List import Data.TypeLevel.Vector as Vector -- Usage: Vector.last, List.last, ? Compare this to the functions in Data.Map, Data.Set, etc. They also use insert, etc. instead of insertM, insertS, etc. Note that the latter would quickly lead to ambiguities because insertM would stand for map insertion as well as for multiset insertion. Similar with sets and sequences. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Sun Feb 10 11:45:16 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sun Feb 10 11:44:16 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802091446t65d0bb79hc0479f1390d19199@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802091608.53295.g9ks157k@acme.softbase.org> <6a7c66fc0802091446t65d0bb79hc0479f1390d19199@mail.gmail.com> Message-ID: <200802101745.17022.g9ks157k@acme.softbase.org> Am Samstag, 9. Februar 2008 23:46 schrieben Sie: > On Feb 9, 2008 4:08 PM, Wolfgang Jeltsch wrote: > > So what would (D1 :* D1) :* (D2 :* D2) mean then? > > Nothing. That value doesn't satisfy the Nat or Post class constraints > and should be taken into consideration. > > Why should :* be provided a meaning? it is an unavoidable syntactical > connective for all that I care. The meaning is provided by class > constraints and that's all that matter from the semantical point of > view. I was just refering to Stefan?s argument that :* should be treated as a form of concatenation. From your point of view, it?s clear, of course. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Sun Feb 10 11:51:49 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sun Feb 10 11:50:49 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802091433m301637a3qd275fefdf934cdc1@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802081610.59914.g9ks157k@acme.softbase.org> <6a7c66fc0802091433m301637a3qd275fefdf934cdc1@mail.gmail.com> Message-ID: <200802101751.49456.g9ks157k@acme.softbase.org> Am Samstag, 9. Februar 2008 23:33 schrieben Sie: > On Feb 8, 2008 4:10 PM, Wolfgang Jeltsch wrote: > > Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie: > > > Even if () would be preferred from the programmers point of view (I'm > > > not sure how much we could reduce the number of instances though), it > > > makes the representation less attractive on the user-side. Anyone > > > using the library would find it annoying and would wonder why is it > > > neccessary. > > > > I wouldn't wonder. Leaving out the () :* part just works because our > > type-level "values" are not typed, i.e., there aren't different kinds > > Digit and Number but only kind *. If :+ would be a data constructor (on > > the value level), it would take a number and a digit argument which would > > forbid using a digit as its left argument. > > Well, the fact is that :+ (or :* as it is called now) is not a value > constructor but a type constructor as you said, so I don't think your > example really applies here. Besides, you should be regarded :* as (,) > and not as a constructor which "would take a number and a digit > argument which would forbid using a digit as its left argument." > Indeed, :* exists as a value-level constructor too and works exactly > like that. > > Furthermore, you probably consider using () as natural and logical > because you are still thinking from the implementation side. If you > forget the implementation details and think as a user who barely wants > to write type-level numerical literals, :* is simply an ugly syntactic > requirement which we cannot get rid of (I would be happy to find > another representation closer to a literal, but I couldn't until now). > That is not the case for (), since, as shown in the initial > implementation, can be avoided. > > So, for me, it's just a matter of usability and syntax, the closer the > representation can be to literals, the better. I don't see the > semantic implications of :* as a valid argument. For me, :* is just an > unavoidable ugly syntactical token without meaning. Imagine that for > some reason, adding () as a prefix in every numerical literal made the > implementation of a compiler slightly easier/faster. I bet users would > rant about it till exhaustion :) > > If the argument was that, for some reason, () was proven to speed up > the implementation or make a big maintainability difference (I still > have my doubts) it would maybe make more sense (I still wouldn't be > sure if it pays off though). Maybe it would be a good idea to create a > patch and see what happens :) > > As a side note, I think that type-value digits actually are "typed" > (metatyped maybe is a nicer term?). Class constraints take the role of > types in this case. > > After all (sorry if the definition is imprecise), a type establishes a > set of valid values. "Nat n => n" does exactly that. For example, it > forces type-level naturals to be normalized (i.e. numerals with > leading zeros don't satisfy the Nat constraint) > > > So I consider using a digit on the left > > as "unclean". It's similar to using a number as the second part of a > > cons cell in LISP. > > Again, the comparisson is based on semantical implications of the > implementation which shouldn't be visible for, or at least not taken > into consideration by, the final user. My arguments were not so much about implementation, I think. I?d see a type-level number as a list of digits, and a list has the form x1 : (x2 : (? : (xn : [])?)) or ((?([] `Snoc` x1) `Snoc` ?) `Snoc` x(n-1)) `Snoc` xn. From this point of view, it?s reasonable to have the extra () :*. On the other hand, it might be sensible to give the user the illusion that :* is part of a special syntax while it?s actually an operator. I?m not really sure what the better approach is. Best wishes, Wolfgang From drl at cs.cmu.edu Sun Feb 10 12:08:41 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Sun Feb 10 12:07:31 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802101743.41443.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802092014t66e01ea3uc18c451a6fef1f8d@mail.gmail.com> <200802101743.41443.g9ks157k@acme.softbase.org> Message-ID: <20080210170841.GB14463@cs.cmu.edu> > > And finally, vector, which is supposed to build a fixed-sized vector > > out of a list. > > > > The ideal type for the function would be: > > > > vector :: [a] -> FSVec s a > > > > But there is no apparent way in which to obtain s based on the length > > of the input list. > > > > [1] shows a way in which to create vector using CPS style and a > > reification function: > > > > reifyInt :: Int -> (forall s . Nat s => FSVect s a -> w) -> w > > > > The result would be a function with the following type: > > > > vector :: [a] -> (forall s . Nat s => FSVec s a -> w) -> w > > > > Nevertheless, I'm not fully satisfied by it. > > I suppose, it?s the best we can get without having dependent types. Others > might correct me. The type vector :: [a] -> FSVec s a doesn't make sense here: because s is universally quantified at the outside, this says "for all lengths s, given a list, I can produce a vector of length s". And indeed, in the second version, it looks like you're using the continuation to curry an existential: vector :: [a] -> (forall s . Nat s => FSVec s a -> w) -> w is the same as vector :: [a] -> ((exists s . Nat s and FSVec s a) -> w) -> w So why not just do vector :: [a] -> (exists s . Nat s and FSVec s a) I.e. data UnknownLengthVec a where U :: Nat s => FsVec s a -> UnknownLengthVec a vector :: [a] -> UnknownLengthVec a I haven't tried, but I'd be surprised if you couldn't write this function by recuring on the list. Of course, this type does not relate the size of the vector to the output of the length function on lists; it just says you get a vector some size. But maybe that's good enough for many uses? -Dan From mfn-haskell-cafe at cs.york.ac.uk Sun Feb 10 13:52:37 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Sun Feb 10 13:52:06 2008 Subject: [Haskell-cafe] I love purity, but it's killing me. In-Reply-To: <594c1e830802092245w5ddcf79cp60dde0f098321ee6@mail.gmail.com> References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> <47ABFDF8.9040800@cs.chalmers.se> <594c1e830802081528i396f10bcg99cf20dfba43f963@mail.gmail.com> <20080209190708.GA19255@venice.staff.cs.york.ac.uk> <594c1e830802092245w5ddcf79cp60dde0f098321ee6@mail.gmail.com> Message-ID: <20080210185237.GA21358@venice.staff.cs.york.ac.uk> Hi Tom, > So is the general strategy with observable sharing to use > unsafePerformIO with Data.Unique to label expressions at > construction? something like that, yes. Basically, you just need: {-# NOINLINE ref #-} ref x = unsafePerformIO (newIORef x) and you can write expressions like ref False == ref False and let x = ref False in x == x However, while referential equality is enough for sharing detection, I *suspect* it's simpler to use the fact that refs are IORefs and you can read and write them (in the IO monad). So a very simple Lava might look like module Lava (Bit,Netlist,low,high,nand2,netlist) where import Data.IORef import System.IO.Unsafe {-# NOINLINE ref #-} ref x = unsafePerformIO (newIORef x) type Ref = IORef (Maybe Int) data Bit = Gate String Ref [Bit] type Netlist = [(String, Int, [Int])] -- gate, output, inputs low = Gate "low" (ref Nothing) [] high = Gate "high" (ref Nothing) [] nand2 (a, b) = Gate "nand2" (ref Nothing) [a, b] netlist :: Bit -> IO Netlist netlist x = do i <- newIORef (0 :: Int) ; f i x where f i (Gate str r xs) = do val <- readIORef r num <- readIORef i case val of Nothing -> do writeIORef r (Just num) writeIORef i (num+1) rest <- mapM (f i) xs let is = map ((\(g,o,is) -> o) . head) rest return ((str,num,is):concat rest) Just j -> return [("indirection",j,[])] -- explicit sharing! Indirections can be filtered out at the end, they don't actually give the netlist any information. > Of course, now that you have me reading up on Yhc.Core, option #5 is > looking considerably more fun. Yeah, I think Yhc.Core is pretty nifty too. Thank Neil! Matt. From jgm at berkeley.edu Sun Feb 10 14:16:58 2008 From: jgm at berkeley.edu (John MacFarlane) Date: Sun Feb 10 14:15:15 2008 Subject: [Haskell-cafe] ANN: highlighting-kate-0.2 Message-ID: <20080210191657.GA13711@berkeley.edu> I've just uploaded highlighting-kate-0.2 to HackageDB. highlighting-kate is a source code syntax highlighting library, based on syntax description files from the Kate editor (http://kate-editor.org/). Currently, the following languages are supported: Ada Alert Asp Awk Bash Bibtex C Cmake Coldfusion Commonlisp Cpp Css D Djangotemplate Doxygen Dtd Eiffel Erlang Fortran Haskell Html Java Javadoc Javascript Json Latex Lex LiterateHaskell Lua Makefile Matlab Mediawiki Modula3 Nasm Objectivec Ocaml Pascal Perl Php Postscript Prolog Python Rhtml Ruby Scala Scheme Sgml Sql SqlMysql SqlPostgresql Tcl Texinfo Xml Xslt Yacc The tarball includes a utility for generating new syntax highlighting modules from XML syntax descriptions. It also includes the source code for a command-line syntax highlighting program, Highlight. Please send bug reports and suggestions my way. John From thomas.dubuisson at gmail.com Sun Feb 10 14:49:39 2008 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sun Feb 10 14:43:29 2008 Subject: [Haskell-cafe] Proper exception handling Message-ID: <1202672979.3336.11.camel@localhost> Cafe, Fact 1: ghc{,i} does not crash when executing this code. Fact 2: I do not want this to crash. Question: Is there some theoretical window between the 'catchDyn' exception handling and the recursive call to 'catchThatDamnError' that could result in an unhandled exception? (of type 'DynError', of coarse) I suppose I am looking for an answer to this question from a language standpoint as well as a compiler pov. As an aside: I see at least one way to be certain of the safty by wrapping the call to forkIO in 'catchDyn', reforking if an exception is caught, and passing the new ThreadId to throwConstantly via shared mutable state - I'd like to avoid all this if my current example is safe. Thomas > import Control.Exception (catchDyn, throwDynTo) > import Control.Concurrent (forkIO, threadDelay) > import Control.Monad (forever) > import Data.Dynamic > > main = do > tid <- forkIO catchThatDamnError > forever $ throwConstantly tid > > catchThatDamnError = catchDyn start (\DynError -> catchThatDamnError) > > start = do > threadDelay 5000 > start > > throwConstantly tid = do > throwDynTo tid DynError > > data DynError = DynError deriving (Eq, Ord, Show, Typeable) From dons at galois.com Sun Feb 10 14:49:53 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 10 14:48:38 2008 Subject: [Haskell-cafe] Embedded Functions in Algebraic Data Types? In-Reply-To: <47AEFD49.3070106@mindspring.com> References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> <47AEFD49.3070106@mindspring.com> Message-ID: <20080210194953.GA28106@scytale.galois.com> mfeathers: > On a lark, I loaded this into Hugs this morning, and it didn't complain: > > > data Thing = Thing (Integer -> Integer) > > > > But, I've never seen that sort of construct in an example. Do people > ever embed functions in ADTs? > > > Michael What's the use of a functional language if you can't treat functions as first class values :) -- Don From ben.franksen at online.de Sun Feb 10 15:02:36 2008 From: ben.franksen at online.de (Ben Franksen) Date: Sun Feb 10 15:05:55 2008 Subject: [Haskell-cafe] Re: RE: Extensible records: Static duck typing References: <965491992.20080205132858@gmail.com> <8087A09F-3DA5-449A-A6DE-FEE67B177B10@ntlworld.com> <3d96ac180802050421x2795f633o48b4bbe2f336a851@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3183270FCF6@EA-EXMSG-C334.europe.corp.microsoft.com> <9CFEEB19-FCA9-46D2-B26A-15F4581697E2@ntlworld.com> Message-ID: [redirecting discussion from @haskell to @cafe] Barney Hilken wrote: >> What about just implementing the cheapest solution that still gets >> us most >> of the way? > >> (3) If it is as cheap (to implement) as advertised then there is no >> great >> risk involved. If it turns out the missing features are a great >> show-stopper for some people (which I don't believe) then let them >> present >> their case afterwards, with good examples at hand. We can still >> decide to >> aim for a higher goal in the long term. > >> If in doubt, chose the solution that is easier to implement. > > Since this paper, there have been several proposals which can be 90% > implemented as libraries, using either functional dependencies or > associated types. These all have much more expressive type systems > than the SPJ paper, yet need very little compiler support. The > question is, which one (if any) should get this small but necessary > support? Which proposals exactly do you refer to? Where can I read about the amount of compiler support these proposals need to make them practically usable? I know about HList/OOHaskell papers+library. This is very interesting stuff but it is not something that comes even close to being usable in day-to-day programming. It is too hard to understand, the (type) error messages are completely uncomprehensible, it is completely unclear how to to make it efficient and how much compiler support would be needed to overcome all these problems. Besides, the question of "functional dependencies or associated types" is still open, right? I think it would be a very bad idea to wait until all those issues have been resolved. So, unless there are other library based proposals on the table that I am not aware of and which don't share these problems, I still think the proposal I was referring to (http://research.microsoft.com/~simonpj/Haskell/records.html) comes closest to what people want and need, while still requiring minimal implementation effort. Cheers Ben From stefanor at cox.net Sun Feb 10 15:28:01 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sun Feb 10 15:26:47 2008 Subject: [Haskell-cafe] Proper exception handling In-Reply-To: <1202672979.3336.11.camel@localhost> References: <1202672979.3336.11.camel@localhost> Message-ID: <20080210202801.GA3753@localhost.localdomain> On Sun, Feb 10, 2008 at 02:49:39PM -0500, Thomas DuBuisson wrote: > Cafe, > Fact 1: ghc{,i} does not crash when executing this code. > Fact 2: I do not want this to crash. > Question: Is there some theoretical window between the 'catchDyn' exception handling and the recursive call to 'catchThatDamnError' that could result in an unhandled exception? (of type 'DynError', of coarse) > > I suppose I am looking for an answer to this question from a language standpoint as well as a compiler pov. > > As an aside: I see at least one way to be certain of the safty by wrapping the call to forkIO in 'catchDyn', reforking if an exception is caught, and passing the new ThreadId to throwConstantly via shared mutable state - I'd like to avoid all this if my current example is safe. > > Thomas Asynchronous exceptions are blocked in handlers, so there is no window - infact all exceptions after the first won't be delivered at all. However, you could be unlucky enough to throw the first error before the first catchDyn, so more synchronisation might be needed. Stefan > > > import Control.Exception (catchDyn, throwDynTo) > > import Control.Concurrent (forkIO, threadDelay) > > import Control.Monad (forever) > > import Data.Dynamic > > > > main = do > > tid <- forkIO catchThatDamnError > > forever $ throwConstantly tid > > > > catchThatDamnError = catchDyn start (\DynError -> catchThatDamnError) > > > > start = do > > threadDelay 5000 > > start > > > > throwConstantly tid = do > > throwDynTo tid DynError > > > > data DynError = DynError deriving (Eq, Ord, Show, Typeable) -------------- 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/20080210/1aa18a5f/attachment.bin From ajb at spamcop.net Sun Feb 10 17:45:22 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Sun Feb 10 17:44:07 2008 Subject: [Haskell-cafe] Re: Datatypes - Haskell In-Reply-To: References: <3d96ac180802091652s1da0ae5as345fa3ec8afbc000@mail.gmail.com> Message-ID: <20080210174522.gj8jk0pv8gcco8sc@webmail.spamcop.net> G'day all. On Feb 10, 2008 3:40 PM, Mattes Simeon wrote: >> Though in comparison with C or C++ I can't figure out so clear the syntax. Quoting Victor Nazarov : > I think this is the most native way to do it in C++: Herb Sutter and Andrei Alexandrescu will find you and beat you up if you write this. This is considered more appropriate. (Warning: untested code follows.) #include template class Tuple : public boost::variant > { private: typedef std::pair pair_type; typedef boost::variant base_type; struct visitor_A : public boost::static_visitor { const A* operator()(const A& a) { return &a; } const A* operator()(const pair_type& p) { return &p.first; } }; public: Tuple(const A& a) : base_type(a) { } Tuple(const A& a, const B& b) : base_type(pair_type(a,b)) { } const A* tuple1() const { return boost::apply_visitor(visitor_A(), *this); } const B* tuple2() const { const pair_type* p = boost::get(*this); return p ? &p->second : 0; } }; But in this specific case, this might be more appropriate: template class Tuple { A m_a; boost::optional m_b; // etc }; Cheers, Andrew Bromage From lennart at augustsson.net Sun Feb 10 18:28:16 2008 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Feb 10 18:27:06 2008 Subject: [Haskell-cafe] Newbie question: mutually exclusive strict / lazy In-Reply-To: References: Message-ID: I'm not sure what you mean by "the strictness analyzer". GHC's strictness analyzer? I don't know, but I would hope so since it was done already in 1980 by Alan Mycroft. -- Lennart On Sat, Feb 9, 2008 at 4:33 PM, Peter Verswyvelen wrote: > Consider the function > > cond x y z = if x then y else z > > I guess we can certainly say cond is strict in x. > > But what about y and z? > > If x is true, then cond is strict in y > If x is false, then cond is strict in z > > So we can't really say cond is lazy nor strict in its second or third > argument. > > Of course, this is the case for many more functions, but in the case of > the if-then-else primitive, does the strictness analyzer make use of this > "mutually exclusive strictness" fact? > > Cheers, > Peter > > > > > > > > > > _______________________________________________ > 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/20080210/80e53552/attachment.htm From tphyahoo at gmail.com Sun Feb 10 18:33:41 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sun Feb 10 18:32:26 2008 Subject: [Haskell-cafe] using the writer monad to better understand foldl and foldr, and haskell debugging techniques in general Message-ID: <910ddf450802101533k2335c864sf21fc370e58df11d@mail.gmail.com> The following is a simple introduction to debugging techniques in haskell, illustrated with a canonical use of foldr and foldl. Comments welcome. import Control.Monad.Writer import Debug.Trace -- We use the writer monad to better understand foldl and foldr -- and show a debugging technique in haskell -- you could get similar output using Debug.Trace, but this relies on unsafePerformIO -- ... http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Debug-Trace.html -- which is Ugly. -- Though ugly, trace isn't really unsafe as far as my understanding goes. But still, I find it nice -- that there's a way to accomplish the exact same thing by using the writer or "debugger" monad -- which is pure as pure can get -- In this particular example, it doesn't matter if you use Debug.Trace or the writer monad. -- However, I am fidding around in another scenario (debugging a series of graphs using Data.Graph.Inductive) -- which seems not to lend itself well to trace. If I can find a nice way to explain what I am doing and why -- I may do a follow-up to this post describing that. -- same as prelude, I think myfoldr f z [] = z myfoldr f z (x:xs) = x `f` r where r = (myfoldr f z xs) myfoldl f z [] = z myfoldl f z (x:xs) = myfoldl f l xs where l = z `f` x -- canonical uses of fold, no debug output tfr = myfoldr (:) [] [1..10] -- copy a list tfl = myfoldl (flip (:)) [] [1..10] -- reverse a list -- debugging output using Debug.Trace (unsafePerfomIO) -- (Not really unsafe, but unsafePerformIO (which is used in the trace function) sounds kind of scary) myfoldrD f z [] = z myfoldrD f z (x:xs) | trace ("x,r: " ++ (show (x,r))) True = x `f` r where r = (myfoldrD f z xs) myfoldlD f z [] = z myfoldlD f z (x:xs) | trace (("z,x") ++ (show (z,x))) True= myfoldlD f l xs where l = z `f` x -- run these to see the functions with debug output from trace tfrD = myfoldrD (:) [] [1..10] -- copy a list tflD = myfoldlD (flip (:)) [] [1..10] -- reverse a list -- using writer monad -- Nothing unsafe here, pure referrentially transparent goodness myfoldrW f z [] = return z myfoldrW f z (x:xs) = do r <- (myfoldrW f z xs) tell ("x,r: " ++ (show (x,r)) ++ "\n" ) return $ x `f` r myfoldlW f z [] = return z myfoldlW f z (x:xs) = do tell ("z,x): " ++ (show (z,x)) ++ "\n") l <- return $ (z `f` x) myfoldlW f l xs -- display the debug output from the writer monad tfrW = putStrLn $ snd $ runWriter $ myfoldrW (:) [] [1..10] tflW = putStrLn $ snd $ runWriter $ myfoldlW (flip (:)) [] [1..10] From ok at cs.otago.ac.nz Sun Feb 10 18:37:27 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Sun Feb 10 18:36:13 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> Message-ID: On 9 Feb 2008, at 2:29 pm, Philip Weaver wrote: > GHC certain *could* do this, but it's arguably not the right thing > to do. I have reminded the GHC maintainers before that the Haskell specification *REQUIRES* a Haskell system to support this; there is an example that makes no sense whatever without it. (And the other Haskell systems I use get it right.) I note that David Bacon's SETL implementation has explicit support for tying an input stream and an output stream together so that any time input is done on the input stream the output stream is flushed; this is done automatically for sockets and is *seriously* useful in avoiding mistakes. Note that this should make essentially no difference to performance because (a) the flushing is only needed when the input buffer is exhausted, which happens once per line, (b) the kinds of streams where you want it (terminals, STREAMs, sockets, serial ports, &c) generally have other costs so high you won't be able to measure this one, (c) it *only* applies to bidirectional streams or to explicitly coupled streams, so I/O to disc files or memory sticks or other high speed block devices should never be affected at all (unless someone chooses to do it explicitly, in which case it's still going to be faster than anything they could have done by hand). From felipe.lessa at gmail.com Sun Feb 10 18:44:36 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Sun Feb 10 18:43:20 2008 Subject: [Haskell-cafe] using the writer monad to better understand foldl and foldr, and haskell debugging techniques in general In-Reply-To: <910ddf450802101533k2335c864sf21fc370e58df11d@mail.gmail.com> References: <910ddf450802101533k2335c864sf21fc370e58df11d@mail.gmail.com> Message-ID: On Feb 10, 2008 9:33 PM, Thomas Hartman wrote: > -- using writer monad > -- Nothing unsafe here, pure referrentially transparent goodness > myfoldrW f z [] = return z > myfoldrW f z (x:xs) = do > r <- (myfoldrW f z xs) > tell ("x,r: " ++ (show (x,r)) ++ "\n" ) > return $ x `f` r *Main> foldr const 0 [1..] 1 *Main> putStrLn $ snd $ runWriter $ myfoldrW const 0 [1..] Interrupted. One of the good things from foldr is the possibility of "short-circuiting", so to speak. However I don't know if it is possible to show this using the writer monad, as is would involve observing if the function is strict or not in its second argument. Cheers, -- Felipe. From tphyahoo at gmail.com Sun Feb 10 18:52:55 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Sun Feb 10 18:51:39 2008 Subject: [Haskell-cafe] using the writer monad to better understand foldl and foldr, and haskell debugging techniques in general In-Reply-To: <910ddf450802101551s3ea00662w406b014d240f302c@mail.gmail.com> References: <910ddf450802101533k2335c864sf21fc370e58df11d@mail.gmail.com> <910ddf450802101551s3ea00662w406b014d240f302c@mail.gmail.com> Message-ID: <910ddf450802101552s1c9bce82o2884002c5a2582b3@mail.gmail.com> same behavior with myfoldrD (:) [] [1..] -- uses Debug.Trace.trace So, I would say this proves my main point, which was that you could accomplish the same thing using the writer monad that you could do using the more "ad hoc" trace function from Debug.Trace. It's good that you point this out though, because understanding that foldr can take an infinite list and foldl not is a very key point. > 2008/2/10, Felipe Lessa : > > On Feb 10, 2008 9:33 PM, Thomas Hartman wrote: > > > -- using writer monad > > > -- Nothing unsafe here, pure referrentially transparent goodness > > > myfoldrW f z [] = return z > > > myfoldrW f z (x:xs) = do > > > r <- (myfoldrW f z xs) > > > tell ("x,r: " ++ (show (x,r)) ++ "\n" ) > > > return $ x `f` r > > > > *Main> foldr const 0 [1..] > > 1 > > *Main> putStrLn $ snd $ runWriter $ myfoldrW const 0 [1..] > > Interrupted. > > > > One of the good things from foldr is the possibility of > > "short-circuiting", so to speak. However I don't know if it is > > possible to show this using the writer monad, as is would involve > > observing if the function is strict or not in its second argument. > > > > Cheers, > > > > -- > > Felipe. > > > From dons at galois.com Sun Feb 10 20:09:39 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 10 20:08:33 2008 Subject: [Haskell-cafe] Haskell Weekly News - February 10, 2008 Message-ID: <20080211010939.GB28106@scytale.galois.com> --------------------------------------------------------------------------- Haskell Weekly News Issue 69 - February 10, 2008 --------------------------------------------------------------------------- Welcome to issue 69 of HWN, a newsletter covering developments in the [1]Haskell community. A quick update HWN this week, with a gazillion new libraries on Hackage. (> 150 new and updated libs!) 1. http://haskell.org/ Hackage New and updated libraries in [2]the Hackage library database. 2. http://hackage.haskell.org/ * WordNet 0.1.1. Uploaded by Max Rabkin. [3]WordNet: Haskell interface to the WordNet database. * lazysmallcheck 0.1. Uploaded by Gwern Branwen. [4]lazysmallcheck: A library for demand-driven testing of Haskell programs. * DrIFT 2.2.3. Uploaded by Gwern Branwen. [5]DrIFT: Program to derive type class instances. * highlighting-kate 0.2. Uploaded by John MacFarlane. [6]highlighting-kate: Syntax highlighting. * leksah 0.1. Uploaded by Juergen NicklischFranken. [7]leksah: Genuine Haskell Face. * frag 1.1. Uploaded by Gwern Branwen. [8]frag: 3-D First Person Shooter (FPS). * GoogleChart 0.2. Uploaded by Evan Martin. [9]GoogleChart: Generate web-based charts using the Google Chart API. * HFuse 0.1. Uploaded by Gwern Branwen. [10]HFuse: HFuse is a binding for the Linux FUSE library. * GoogleChart 0.1. Uploaded by Evan Martin. [11]GoogleChart: Generate web-based charts using the Google Chart API. * Finance-Quote-Yahoo 0.5.0. Uploaded by Brad Clawsie. [12]Finance-Quote-Yahoo: Obtain quote data from finance.yahoo.com. 3. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/WordNet-0.1.1 4. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lazysmallcheck-0.1 5. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/DrIFT-2.2.3 6. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/highlighting-kate-0.2 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/leksah-0.1 8. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/frag-1.1 9. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GoogleChart-0.2 10. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse-0.1 11. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GoogleChart-0.1 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Quote-Yahoo-0.5.0 * binary-strict 0.3.0. Uploaded by Adam Langley. [13]binary-strict: Binary deserialisation using strict ByteStrings. * Stream 0.2.3. Uploaded by Wouter Swierstra. [14]Stream: A library for manipulating infinite lists.. * Finance-Treasury 0.1.1. Uploaded by Stephen Lihn. [15]Finance-Treasury: Obtain Treasury yield curve data. * Hedi 0.1. Uploaded by Paolo Veronelli. [16]Hedi: Line oriented editor. * newports 1.1. Uploaded by Brad Clawsie. [17]newports: List ports newer than N days on a FreeBSD system. * Finance-Treasury 0.1. Uploaded by Stephen Lihn. [18]Finance-Treasury: Obtain Treasury yield curve data. * GPLib 0.0. Uploaded by Gwern Branwen. [19]GPLib: Generic library for genetic programming. * nano-hmac 0.1.1. Uploaded by Hitesh Jasani. [20]nano-hmac: Bindings to OpenSSL HMAC.. * multiset 0.1. Uploaded by Twan VanLaarhoven. [21]multiset: The Data.MultiSet container type. * hpodder 1.1.0. Uploaded by John Goerzen. [22]hpodder: Podcast Aggregator (downloader). 13. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict-0.3.0 14. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.2.3 15. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Treasury-0.1.1 16. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Hedi-0.1 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/newports-1.1 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Finance-Treasury-0.1 19. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GPLib-0.0 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nano-hmac-0.1.1 21. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/multiset-0.1 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hpodder-1.1.0 * bimap 0.2.1. Uploaded by Stuart Cook. [23]bimap: Bidirectional mapping between two key types. * monadLib 3.4.4. Uploaded by Iavor Diatchki. [24]monadLib: A collection of monad transformers.. * IOSpec 0.2. Uploaded by Wouter Swierstra. [25]IOSpec: A pure specification of the IO monad.. * bimap 0.2. Uploaded by Stuart Cook. [26]bimap: Bidirectional mapping between two key types. * strictify 0.1. Uploaded by Sterling Clover. [27]strictify: Find a local optimum of strictness annotations.. * heap 0.2.2. Uploaded by Stephan Friedrichs. [28]heap: Heaps in Haskell. * LDAP 0.6.4. Uploaded by John Goerzen. [29]LDAP: Haskell binding for C LDAP API. * HStringTemplate 0.2. Uploaded by Sterling Clover. [30]HStringTemplate: StringTemplate implementation in Haskell.. * RJson 0.3.2. Uploaded by Alex Drummond. [31]RJson: A reflective JSON serializer/parser.. * network-dns 0.1.1. Uploaded by Adam Langley. [32]network-dns: A pure Haskell, asyncronous DNS client library. 23. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bimap-0.2.1 24. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/monadLib-3.4.4 25. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/IOSpec-0.2 26. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bimap-0.2 27. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/strictify-0.1 28. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.2.2 29. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/LDAP-0.6.4 30. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HStringTemplate-0.2 31. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/RJson-0.3.2 32. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-dns-0.1.1 * lcs 0.2. Uploaded by Ian Lynagh. [33]lcs: Find longest common sublist of two lists. * tracker 0.1. Uploaded by Will Thompson. [34]tracker: Client library for Tracker metadata database, indexer and search tool. * CC-delcont 0.2. Uploaded by Dan Doel. [35]CC-delcont: Delimited continuations and dynamically scoped variables. * control-timeout 0.1.2. Uploaded by Adam Langley. [36]control-timeout: Timeout handling. * network-dns 0.1. Uploaded by Adam Langley. [37]network-dns: A pure Haskell, asyncronous DNS client library. * binary-strict 0.2.4. Uploaded by Adam Langley. [38]binary-strict: Binary deserialisation using strict ByteStrings. * heap 0.1.1. Uploaded by Stephan Friedrichs. [39]heap: Heaps in Haskell. * HCL 1.3. Uploaded by Justin Bailey. [40]HCL: High-level library for building command line interfaces.. * yi 0.3. Uploaded by Jean PhilippeBernardy. [41]yi: The Haskell-Scriptable Editor. * binary-strict 0.2.3. Uploaded by Adam Langley. [42]binary-strict: Binary deserialisation using strict ByteStrings. 33. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/lcs-0.2 34. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/tracker-0.1 35. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CC-delcont-0.2 36. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-timeout-0.1.2 37. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-dns-0.1 38. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict-0.2.4 39. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.1.1 40. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HCL-1.3 41. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/yi-0.3 42. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict-0.2.3 * heap 0.1. Uploaded by Stephan Friedrichs. [43]heap: Heaps in Haskell. * pureMD5 0.1.2. Uploaded by Thomas DuBuisson. [44]pureMD5: MD5 implementations that should become part of a ByteString Crypto package.. * RJson 0.3.1. Uploaded by Alex Drummond. [45]RJson: A reflective JSON serializer/parser.. * template 0.1.1.1. Uploaded by Johan Tibell. [46]template: Simple string substitution. * network-bytestring 0.1.1.1. Uploaded by Johan Tibell. [47]network-bytestring: Fast and memory efficient low-level networking. * ftphs 1.0.4. Uploaded by John Goerzen. [48]ftphs: FTP Client and Server Library. * mersenne-random-pure64 0.1.1. Uploaded by Donald Stewart. [49]mersenne-random-pure64: Generate high quality pseudorandom numbers purely using a Mersenne Twister. * Diff 0.1. Uploaded by Sterling Clover. [50]Diff: O(ND) diff algorithm in haskell.. * crack 0.1. Uploaded by Trevor Elliott. [51]crack: A haskell binding to cracklib. * miniplex 0.3.3. Uploaded by Lukas Mai. [52]miniplex: simple 1-to-N interprocess communication. 43. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/heap-0.1 44. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pureMD5-0.1.2 45. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/RJson-0.3.1 46. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/template-0.1.1.1 47. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-bytestring-0.1.1.1 48. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ftphs-1.0.4 49. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mersenne-random-pure64-0.1.1 50. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Diff-0.1 51. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/crack-0.1 52. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/miniplex-0.3.3 * colock 0.2.2. Uploaded by Lukas Mai. [53]colock: thread-friendly file locks that don't block the entire program. * mersenne-random-pure64 0.1. Uploaded by Donald Stewart. [54]mersenne-random-pure64: Generate high quality pseudorandom numbers purely using a Mersenne Twister. * network-rpca 0.0.1. Uploaded by Adam Langley. [55]network-rpca: A cross-platform RPC library. * xmonad-contrib 0.6. Uploaded by Spencer Janssen. [56]xmonad-contrib: Third party extensions for xmonad. * xmonad 0.6. Uploaded by Spencer Janssen. [57]xmonad: A tiling window manager. * codec-libevent 0.1.2. Uploaded by Adam Langley. [58]codec-libevent: Cross-platform structure serialisation. * bytestringparser 0.3. Uploaded by Bryan OSullivan. [59]bytestringparser: Combinator parsing with Data.ByteString.Lazy. * HStringTemplate 0.2. Uploaded by Sterling Clover. [60]HStringTemplate: StringTemplate implementation in Haskell.. * value-supply 0.1. Uploaded by Iavor Diatchki. [61]value-supply: A library for generating values without having to thread state.. * derive 0.1.1. Uploaded by Neil Mitchell. [62]derive: A program and library to derive instances for data types. 53. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colock-0.2.2 54. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mersenne-random-pure64-0.1 55. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-rpca-0.0.1 56. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad-contrib-0.6 57. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad-0.6 58. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/codec-libevent-0.1.2 59. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestringparser-0.3 60. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HStringTemplate-0.2 61. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/value-supply-0.1 62. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/derive-0.1.1 * control-timeout 0.1.1. Uploaded by Adam Langley. [63]control-timeout: Timeout handling. * mkcabal 0.4.1. Uploaded by Donald Stewart. [64]mkcabal: Generate cabal files for a Haskell project. * regexpr 0.2.9. Uploaded by Yoshikuni Jujo. [65]regexpr: regular expression like Perl/Ruby in Haskell. * mtlparse 0.0.0.5. Uploaded by Yoshikuni Jujo. [66]mtlparse: parse library use mtl package. * cgi 3001.1.5.2. Uploaded by Bjorn Bringert. [67]cgi: A library for writing CGI programs. * xhtml 3000.0.2.2. Uploaded by Bjorn Bringert. [68]xhtml: An XHTML combinator library. * harpy 0.4. Uploaded by Martin Grabmueller. [69]harpy: Runtime code generation for x86 machine code. * editline 0.2. Uploaded by Judah Jacobson. [70]editline: Bindings to the editline library (libedit).. * hmatrix 0.2.0.0. Uploaded by Alberto Ruiz. [71]hmatrix: Linear algebra and numerical computations. * regexpr 0.2.8. Uploaded by Yoshikuni Jujo. [72]regexpr: regular expression like Perl/Ruby in Haskell. 63. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-timeout-0.1.1 64. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mkcabal-0.4.1 65. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.2.9 66. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mtlparse-0.0.0.5 67. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cgi-3001.1.5.2 68. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhtml-3000.0.2.2 69. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy-0.4 70. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.2 71. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hmatrix-0.2.0.0 72. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.2.8 * pcre-light 0.3. Uploaded by Donald Stewart. [73]pcre-light: A small, efficient and portable regex library for Perl 5 compatible regular expressions. * mersenne-random 0.1. Uploaded by Donald Stewart. [74]mersenne-random: Generate high quality pseudorandom numbers using a SIMD Fast Mersenne Twister. * AvlTree 2.4. Uploaded by Adrian Hey. [75]AvlTree: Balanced binary trees using AVL algorithm.. * fec 0.1.1. Uploaded by Adam Langley. [76]fec: Forward error correction of ByteStrings. * COrdering 2.1. Uploaded by Adrian Hey. [77]COrdering: An algebraic data type similar to Prelude Ordering.. * i18n 0.3. Uploaded by Eugene Grigoriev. [78]i18n: Internationalization for Haskell. * binary-strict 0.2.2. Uploaded by Adam Langley. [79]binary-strict: Binary deserialisation using strict ByteStrings. * regexpr 0.2.6. Uploaded by Yoshikuni Jujo. [80]regexpr: regular expression like Perl/Ruby in Haskell. * RJson 0.2. Uploaded by Alex Drummond. [81]RJson: A reflective JSON serializer/parser.. * regexpr 0.2.5. Uploaded by Yoshikuni Jujo. [82]regexpr: regular expression like Perl/Ruby in Haskell. 73. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light-0.3 74. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mersenne-random-0.1 75. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/AvlTree-2.4 76. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fec-0.1.1 77. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/COrdering-2.1 78. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/i18n-0.3 79. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict-0.2.2 80. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.2.6 81. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/RJson-0.2 82. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.2.5 * fec 0.1. Uploaded by Adam Langley. [83]fec: Forward error correction of ByteStrings. * dataenc 0.10.2. Uploaded by Magnus Therning. [84]dataenc: Data encoding library. * regexpr 0.2.3. Uploaded by Yoshikuni Jujo. [85]regexpr: regular expression like Perl/Ruby in Haskell. * regexpr 0.2.2. Uploaded by Yoshikuni Jujo. [86]regexpr: regular expression like Perl/Ruby in Haskell. * reactive 0.3. Uploaded by Conal Elliott. [87]reactive: Simple foundation for functional reactive programming. * regexpr 0.2.1. Uploaded by Yoshikuni Jujo. [88]regexpr: regular expression like Perl/Ruby in Haskell. * djinn 2008.1.18. Uploaded by Lennart Augustsson. [89]djinn: Generate Haskell code from a type. * Etherbunny 0.3. Uploaded by Nicholas Burlett. [90]Etherbunny: A network analysis toolkit for Haskell. * regexpr 0.2.0. Uploaded by Yoshikuni Jujo. [91]regexpr: regular expression like Perl/Ruby in Haskell. * RJson 0.1. Uploaded by Alex Drummond. [92]RJson: A reflective JSON serializer/parser.. 83. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fec-0.1 84. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dataenc-0.10.2 85. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.2.3 86. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.2.2 87. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/reactive-0.3 88. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.2.1 89. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/djinn-2008.1.18 90. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Etherbunny-0.3 91. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.2.0 92. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/RJson-0.1 * regexpr 0.1.7. Uploaded by Yoshikuni Jujo. [94]regexpr: regular expression like Perl/Ruby in Haskell. * reactive 0.2. Uploaded by Conal Elliott. [95]reactive: Simple foundation for functional reactive programming. * srcinst 0.8.10. Uploaded by John Goerzen. [96]srcinst: Build and install Debian packages completely from source. * dfsbuild 1.0.2. Uploaded by John Goerzen. [97]dfsbuild: Build Debian From Scratch CD/DVD images. * darcs-buildpackage 0.5.12. Uploaded by John Goerzen. [98]darcs-buildpackage: Tools to help manage Debian packages with Darcs. * anydbm 1.0.5. Uploaded by John Goerzen. [99]anydbm: Interface for DBM-like database systems. * HDBC-sqlite3 1.1.4.0. Uploaded by John Goerzen. [100]HDBC-sqlite3: Sqlite v3 driver for HDBC. * HDBC-postgresql 1.1.4.0. Uploaded by John Goerzen. [101]HDBC-postgresql: PostgreSQL driver for HDBC. * HDBC-odbc 1.1.4.0. Uploaded by John Goerzen. [102]HDBC-odbc: ODBC driver for HDBC. 94. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regexpr-0.1.7 95. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/reactive-0.2 96. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/srcinst-0.8.10 97. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dfsbuild-1.0.2 98. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/darcs-buildpackage-0.5.12 99. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/anydbm-1.0.5 100. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-sqlite3-1.1.4.0 101. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-postgresql-1.1.4.0 102. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-odbc-1.1.4.0 * magic 1.0.7. Uploaded by John Goerzen. [103]magic: Interface to C file/magic library. * ListLike 1.0.1. Uploaded by John Goerzen. [104]ListLike: Generic support for list-like structures. * LDAP 0.6.3. Uploaded by John Goerzen. [105]LDAP: Haskell binding for C LDAP API. * hg-buildpackage 1.0.4. Uploaded by John Goerzen. [106]hg-buildpackage: Tools to help manage Debian packages with Mercurial. * HDBC 1.1.4. Uploaded by John Goerzen. [107]HDBC: Haskell Database Connectivity. * HSH 1.2.5. Uploaded by John Goerzen. [108]HSH: Library to mix shell scripting with Haskell programs. * editline 0.1. Uploaded by Judah Jacobson. [109]editline: Bindings to the editline library (libedit).. * pureMD5 0.1.1. Uploaded by Thomas DuBuisson. [110]pureMD5: MD5 implementations that should become part of a ByteString Crypto package.. * hmp3 1.4. Uploaded by Donald Stewart. [111]hmp3: An ncurses mp3 player written in Haskell. * binary-strict 0.2.1. Uploaded by Adam Langley. [112]binary-strict: Binary deserialisation using strict ByteStrings. 103. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/magic-1.0.7 104. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListLike-1.0.1 105. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/LDAP-0.6.3 106. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hg-buildpackage-1.0.4 107. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-1.1.4 108. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HSH-1.2.5 109. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 110. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pureMD5-0.1.1 111. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hmp3-1.4 112. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict-0.2.1 * GLFW 0.3. Uploaded by Paul Liu. [113]GLFW: A binding for GLFW, An OpenGL Framework. * hbeat 0.1.1. Uploaded by Tim Docker. [114]hbeat: A simple step sequencer GUI.. * hackage2hwn 0.2.1. Uploaded by Donald Stewart. [115]hackage2hwn: Convert hackage = Hackage RSS feeds to Haskell Weekly News format. * tagsoup 0.4. Uploaded by Neil Mitchell. [116]tagsoup: Parsing and extracting information from (possibly malformed) HTML documents. * HaXml 1.19.2. Uploaded by Malcolm Wallace. [117]HaXml: Utilities for manipulating XML documents. * Emping 0.3.1. Uploaded by Hans VanThiel. [118]Emping: derives heuristic rules from nominal data. * hbeat 0.1. Uploaded by Tim Docker. [119]hbeat: A simple step sequencer GUI.. * Imlib 0.1.1. Uploaded by Cale Gibbard. [120]Imlib: Added by CaleGibbard, Sun Jan 13 22:26:59 PST 2008.. * pcre-light 0.2. Uploaded by Donald Stewart. [121]pcre-light: A small, efficient and portable regex library for Perl 5 compatible regular expressions. * YamlReference 0.8. Uploaded by Oren BenKiki. [122]YamlReference: YAML reference implementation. 113. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/GLFW-0.3 114. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hbeat-0.1.1 115. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hackage2hwn-0.2.1 116. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/tagsoup-0.4 117. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml-1.19.2 118. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Emping-0.3.1 119. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hbeat-0.1 120. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Imlib-0.1.1 121. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light-0.2 122. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/YamlReference-0.8 * ContArrow 0.0.4. Uploaded by Evgeny Jukov. [123]ContArrow: Control.Arrow.Transformer.Cont. * ContArrow 0.0.3. Uploaded by Evgeny Jukov. [124]ContArrow: Control.Arrow.Transformer.Cont. * mkcabal 0.4. Uploaded by Donald Stewart. [125]mkcabal: Generate cabal files for a Haskell project. * pcre-light 0.1. Uploaded by Donald Stewart. [126]pcre-light: A lightweight binding to PCRE. * YamlReference 0.7. Uploaded by Oren BenKiki. [127]YamlReference: YAML reference implementation. * Crypto 4.1.0. Uploaded by Dominic Steinitz. [128]Crypto: DES, Blowfish, AES, TEA, SHA1, MD5, RSA, BubbleBabble, Hexdump, Support for Word128, Word192 and Word256 and Beyond, PKCS5 Padding, Various Encryption Modes e.g. Cipher Block Chaining all in one package.. * containers 0.1.0.1. Uploaded by Ross Paterson. [129]containers: Assorted concrete container types. * ConfigFile 1.0.4. Uploaded by John Goerzen. [130]ConfigFile: Configuration file reading & writing. * MissingH 1.0.0. Uploaded by John Goerzen. [131]MissingH: Large utility library. * hslogger 1.0.4. Uploaded by John Goerzen. [132]hslogger: Versatile logging framework. 123. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ContArrow-0.0.4 124. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ContArrow-0.0.3 125. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mkcabal-0.4 126. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light-0.1 127. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/YamlReference-0.7 128. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Crypto-4.1.0 129. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/containers-0.1.0.1 130. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ConfigFile-1.0.4 131. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MissingH-1.0.0 132. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hslogger-1.0.4 * hslogger 1.0.2. Uploaded by John Goerzen. [133]hslogger: Versatile logging framework. * BerkeleyDB 0.3. Uploaded by John McCall. [134]BerkeleyDB: Bindings for Berkeley DB v1.x. * BitSyntax 0.3.2. Uploaded by Adam Langley. [135]BitSyntax: A module to aid in the (de)serialisation of binary data. * Hashell 0.15. Uploaded by Gwern Branwen. [136]Hashell: Simple shell written in Haskell. * binary-strict 0.2. Uploaded by Adam Langley. [137]binary-strict: Binary deserialisation using strict ByteStrings. * Shu-thing 1.1. Uploaded by Gwern Branwen. [138]Shu-thing: A vector shooter game. * zlib 0.4.0.2. Uploaded by Duncan Coutts. [139]zlib: Compression and decompression in the gzip and zlib formats. * i18n 0.2. Uploaded by Eugene Grigoriev. [140]i18n: Internationalization for Haskell. * pandoc 0.46. Uploaded by John MacFarlane. [141]pandoc: Conversion between markup formats. * hscolour 1.9. Uploaded by Malcolm Wallace. [142]hscolour: Colourise Haskell code.. 133. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hslogger-1.0.2 134. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/BerkeleyDB-0.3 135. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/BitSyntax-0.3.2 136. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Hashell-0.15 137. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict-0.2 138. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shu-thing-1.1 139. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.4.0.2 140. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/i18n-0.2 141. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pandoc-0.46 142. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hscolour-1.9 * regex-pcre 0.94.1. Uploaded by ChrisKuklewicz. [143]regex-pcre: Replaces/Enhances Text.Regex. * regex-posix 0.93.1. Uploaded by Chris Kuklewicz. [144]regex-posix: Replaces/Enhances Text.Regex. * regex-base 0.93.1. Uploaded by Chris Kuklewicz. [145]regex-base: Replaces/Enhances Text.Regex. * regex-compat 0.91. Uploaded by Chris Kuklewicz. [146]regex-compat: Replaces/Enhances Text.Regex. * haddock 2.0.0.0. Uploaded by David Waern. [147]haddock: Added by DavidWaern 143. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-pcre-0.94.1 144. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-posix-0.93.1 145. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-base-0.93.1 146. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-compat-0.91 147. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.0.0.0 Blog noise [148]Haskell news from the [149]blogosphere. 148. http://planet.haskell.org/ * [150]Scala Buzzzzings * [151]Taxicab Numbers * [152]Tuppence Tour of Haskell Concurrency Constructs * [153]Power of Functional Programming, its Features and its Future * [154]Monads in Python (with nice syntax!) * [155]Monads in Ruby (with nice syntax!) * [156]The Marvels of Monads (in C#) * [157]Pointfree programming in OCaml * [158]HSOE Chapter 3 * [159]Extra type safety using polymorphic types as first-level refinements * [160]Why you should use Haskell for your next domain specific language 149. http://haskell.org/haskellwiki/Blog_articles 150. http://patricklogan.blogspot.com/2008/01/scala-buzzzzings.html 151. http://python-tips-gw.blogspot.com/2008/01/taxicab-numbers.html 152. http://mult.ifario.us/p/tuppence-tour-of-haskell-concurrency-constructs 153. http://www.canerten.com/power-of-functional-programming-its-features-and-its-future/ 154. http://www.valuedlessons.com/2008/01/monads-in-python-with-nice-syntax.html 155. http://www.valuedlessons.com/2008/01/monads-in-ruby-with-nice-syntax.html 156. http://blogs.msdn.com/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx? 157. http://alaska-kamtchatka.blogspot.com/2008/01/pointless-polymorphism.html 158. http://apocalisp.wordpress.com/2008/01/08/hsoe-chapter-3/ 159. http://blog.jbapple.com/2008/01/extra-type-safety-using-polymorphic.html 160. http://paulspontifications.blogspot.com/2008/01/why-haskell-is-good-for-embedded-domain.html * [161]Record system headaches * [162]Programming Erlang * [163]Haskell syntax is not Java syntax; good or bad? * [164]Judging programming languages by the results * [165]One line binary reader in Haskell * [166]On the utility of functional programming * [167]The Rise Of Functional Programming: F#/Scala/Haskell and the failing of Lisp * [168]Seeqsuq: A Seeqpod URL Ripper (in Haskell) * [169]2008 predictions * [170]The Haskell Program Coverage Toolkit (part 1) 161. http://jpmoresmau.blogspot.com/2008/01/nested-records-headaches-in-haskell.html 162. http://www.oxtremists.co.uk/?p=68 163. http://jpmoresmau.blogspot.com/2008/01/haskell-syntax-is-not-java-syntax-good.html 164. http://www.pvv.org/~alexanro/2008/01/11/judging-programming-languages-by-the-results/ 165. http://tehgeekmeister.wordpress.com/2008/01/11/one-line-binary-reader-in-haskell/ 166. http://geekrant.wordpress.com/2008/01/12/on-the-utility-of-functional-programming/ 167. http://www.brandonwerner.com/2008/01/13/the-rise-of-functional-programming-fscalahaskell-and-the-failing-of-lisp/ 168. http://cmars232.blogspot.com/2008/01/seeqsuq-seeqpod-url-ripper-in-haskell.html 169. http://lambda-the-ultimate.org/node/2600#comment-39191 170. http://blog.unsafeperformio.com/?p=18 * [171]Haskell Code Coverage tool available * [172]A Little Lesson on Laziness and Unsafety * [173]Haskell's do syntax for python and ruby * [174]Error handling in Python: monads are too much for me * [175]Simple POSIX regular expression example * [176]Read the content of a file into a list of string * [177]How not to explain Haskell monads * [178]HStringTemplate: An Elegant, Functional, Nifty Templating Engine for Haskell. * [179]A (hopefully) painless introduction to monads * [180]Simple Type Inference in Haskell 171. http://leibnizdream.wordpress.com/2008/01/15/haskell-code-coverage-tool-available/ 172. http://mult.ifario.us/p/a-little-lesson-on-laziness-and-unsafety 173. http://www.valuedlessons.com/2008/01/recently-i-wrote-about-ways-to-add.html 174. http://ndanger.org/blog/2008/01/16/error-handling-in-python-monads-are-too-much-for-me/ 175. http://athashdollarpercent.blogspot.com/2008/01/simple-posix-regular-expression-example.html 176. http://athashdollarpercent.blogspot.com/2008/01/read-content-of-file-into-list-of.html 177. http://mvanier.livejournal.com/1205.html 178. http://fmapfixreturn.wordpress.com/2008/01/14/hstringtemplate-an-elegant-functional-nifty-templating-engine-for-haskell/ 179. http://www.prairienet.org/~dsb/monads.htm 180. http://notvincenz.blogspot.com/2008/01/simple-type-inference-in-haskell.html * [181]Quality assurance for Haskell code via code coverage * [182]Getting started with Yi, the haskell editor * [183]Haskell Impressions, Part I * [184]Software Transactional Memory for F# * [185]One or so word summary of the programming languages I work with * [186]HStringTemplate: Turtles all the way * [187]Scraping my boilerplate: Generics instead of Records * [188]Functional Programming is Hard * [189]Erik Meijer: Evaluating Functional Programming Language Purity :: Video * [190]Solving XKCD's Ghost problem in Haskell: First player wins 181. http://blog.unsafeperformio.com/?p=18 182. http://nobugs.org/developer/yi/index.html 183. http://blog.safira.com/2008/01/haskell-impressions-part-i.html 184. http://cs.hubfs.net/blogs/hell_is_other_languages/archive/2008/01/16/4565.aspx 185. http://berlinbrowndev.blogspot.com/2008/01/one-or-so-word-summary-of-programming.html 186. http://fmapfixreturn.wordpress.com/2008/01/18/turtles-all-the-way/ 187. http://jpmoresmau.blogspot.com/2008/01/scraping-my-boilerplate-generics.html 188. http://blog.magenic.com/blogs/aarone/archive/2008/01/18/Functional-Programming-is-Hard.aspx 189. http://channel9.msdn.com/ShowPost.aspx?PostID=374141 190. http://squing.blogspot.com/2008/01/first-player-wins-superghost.html * [191]Haskell Function calls and Parentheses * [192]an elementary proof of the undecidability of the halting problem * [193]Invasion of the multi-core machines * [194]Monads for Imperative Peeps * [195]Haskell Shuffling * [196]Notes on Haskell * [197]Functional Programming Languages * [198]Case Study: Using Haskell and HAppS for Openomy API v2.0 * [199]A Haskell Hackathon (in Japanese) * [200]Control.Parallel.Strategies introduction 191. http://berlinbrowndev.blogspot.com/2008/01/haskell-function-calls-and-parentheses.html 192. http://www.bemuzed.com/lucasd/halting-poem.html 193. http://blog.susheelspace.com/?p=126 194. http://climbing-the-hill.blogspot.com/2008/01/haskell-monads-for-imperative-peeps.html 195. http://brett-hall.blogspot.com/2008/01/haskell-shuffling.html 196. http://penberg.blogspot.com/2008/01/its-not-dead-yet.html 197. http://blog.inquirylabs.com/2008/01/20/functional-programming-languages/ 198. http://blog.openomy.com/2008/01/case-study-using-haskell-and-happs-for.html 199. http://d.hatena.ne.jp/yukoba/20080121/p1 200. http://thoughtpolice.stringsandints.com/index.cgi/code/haskell#parallel_strategies_intro * [201]'I asked the manager if they were considering using such languages. He replied that they had actually considered using Haskell for some smaller projects' * [202]Solving IO Sequencing in Haskell with a Monad * [203]Haskell Music * [204]Matching checklists using Haskell * [205]State monads * [206]Haskell is a very expressive language * [207]Counting Infinity * [208]Haskell, del.icio.us, and JSON * [209]It's time for Haskell in the web browser * [210]OpenGL programming with Haskell 201. http://pinderkent.blogsavy.com/archives/150 202. http://wry-observer.blogspot.com/2008/01/solving-io-sequencing-in-haskell-with.html 203. http://samdanielson.com/2008/1/23/haskell-music 204. http://porg.es/blog/matching-checklists-using-haskell 205. http://mvanier.livejournal.com/1901.html 206. http://berlinbrowndev.blogspot.com/2008/01/haskell-is-very-expressive-language.html 207. http://muaddibspace.blogspot.com/2008/01/counting-infinity.html 208. http://mult.ifario.us/p/haskell-del-icio-us-and-json 209. http://pinderkent.blogsavy.com/archives/151 210. http://metavar.blogspot.com/2008/01/opengl-programming-with-haskell.html * [211]unfolds in scala * [212]Haskell Snippet: looking at foldl (also a java version) * [213]MatLab: Why OCaml and Haskell are not ready for general scientists -- missing libraries * [214]Problems in Lisp: Historical relics, poor FFI, libraries, forks * [215]On blub * [216]Refining Pipelines * [217]Purely functional recursive types in Haskell and Python * [218]Counting matches in a list * [219]SPJ on .NET Rocks * [220]Hackage, cabal and the google charts api * [221]Haskell Rocks! * [222]How many functions are there from () to ()? 211. http://scala-blogs.org/2008/01/roman-numerals-in-scala.html 212. http://berlinbrowndev.blogspot.com/2008/01/haskell-snippet-looking-at-foldl-also.html 213. http://alexandermikhalev.blogspot.com/2008/01/why-ocaml-and-haskell-is-not-for.html 214. http://nightschool.near-time.net/news/2008/1/31/some-improvements-are-distracting 215. http://etalog.blogspot.com/2008/01/on-blub.html 216. http://alaska-kamtchatka.blogspot.com/2008/02/refining-pipelines.html 217. http://sigfpe.blogspot.com/2008/02/purely-functional-recursive-types-in.html 218. http://haskell101.wordpress.com/2008/02/03/counting-matches-in-a-list/ 219. http://weblogs.asp.net/gbarnett/archive/2008/02/06/something-that-when-unnoticed-in-the-functional-world.aspx 220. http://community.livejournal.com/evan_tech/241080.html 221. http://l33tminion.livejournal.com/189554.html 222. http://sigfpe.blogspot.com/2008/02/how-many-functions-are-there-from-to.html Quotes of the Week * Peter: I hardly know Haskell, but I can already write some code much faster and easier than I could do in C/C++ (and I've been programming 2 decades in that language) * Miguel Mitrofanov: Since NaN /= NaN, I think, we should decipher 'NaN' as 'Not a NaN' * Achim Schneider: The essence of non-strictness, though, is another kind of story. Like a golem plowing half of the country until you remember that you placed him a bit absent-mindedly into your backyard and said 'plow', that still won't plow mountains. The essence of strictness is easy, though: get stuck on a stone, fall over and continue moving until you break. * monochrom: OCaml tells you 'map f xs is bad because it takes O(n) space'. Haskell tells you 'map f xs' is good because it takes O(1) space * ddarius: It says *right on the box* that it it's intended for *both* research and applications. * Clifford Beshers: Why Haskell? Medical researchers announced today that MRI studies reveal that the structure of the human brain is significantly different in adolescence than adulthood. * Larry O'Brien: I really had a hard time refactoring my Ruby into a packrat parser. This was due, in no small part, because of the difficulty in understanding the types being built-up in the data structure. The paper, in explicitly-typed Haskell: clear as a bell. My code's behavior on unit tests: virtually indistinguishable from random. * SuperGrade: Haskell kind of herds you into functional programming. There are advantages to this manner of coding, and I'm getting to thinking you should attempt code this way almost all of the time, regardless of language. * Berlin Brown: Haskell is readable, fast, and expressive. I like it. * Yaakov Nemoy: Changing the type of a function in Python will lead to strange runtime errors that take some work to debug, whereas, when I tinker with a program in Haskell, I already know it will work once it compiles. * Michael Reid: Learning Haskell has completely reversed my feeling that static typing is an old outdated idea. The power of Haskell's type system makes it feel like you are programming in a dynamic language to some degree, yet all of it is type-checked, and that is just *really* cool. * weavejester: I've come across many parser generators that are a dream to work with in comparison to lex and yacc. The best one I've found so far is Haskell's Parsec. * David Roundy: What's the good of having a haskell-programming computational linguist on board if we can't get static compile-time guarantees of grammatical correctness? * Bulat Ziganshin: When FP just pass all the functions and data required for specialization of generic algorithm, OOP provides interfaces, virtual functions, anonymous classes, delegates and lots of other interesting ways to hide the fact of lack of first-class functions :) * [Douglas] Adams: was interested in computing --- I think his reaction to being told about functional programming was to wonder what non-functional programming might be. * ezekiel: I find Haskell to be like Lisp and APL and Python all put together in a way that leads me quickly to a solid result. Other languages work, but the road to the result is bumpier. * AlanYx: I've found that Haskell's uber-strong, static type system does help me be productive, because it increases the class of bugs that can be found at compile time, forces thinking at a higher level, and can help avoid edits to existing code breaking things elsewhere in the code * anonymous: Closures in today's world are a 'language geek' feature. Unless done extremely carefully and in a way that supports the various skill levels of developers, they end up being unusable and unsupportable by anything less than computer language savants. In their inherent obscurity and complexity, 'language geek' style closures are about as anti-Java as you can get. * anonymous: I work in a Smalltalk shop, where we extend and maintain an application that has been around over a decade. During the maintenance part of our job, it would be really nice to have type declarations on variables. For maintenance, the more dependable information we have, the better! The fewer things that can escape as runtime exceptions, the better! * consultant barbie: Languages are hard. Let's write web frameworks and go shopping! About the Haskell Weekly News New editions are posted to [223]the Haskell mailing list as well as to [224]the Haskell Sequence and [225]Planet Haskell. [226]RSS is also available, and headlines appear on [227]haskell.org. Headlines are available as [228]PDF. To help create new editions of this newsletter, please see the [229]contributing information. Send stories to dons at galois.com. The darcs repository is available at darcs get [230]http://code.haskell.org/~dons/code/hwn/ 223. http://www.haskell.org/mailman/listinfo/haskell 224. http://sequence.complete.org/ 225. http://planet.haskell.org/ 226. http://sequence.complete.org/node/feed 227. http://haskell.org/ 228. http://code.haskell.org/~dons/code/hwn/archives/20080210.pdf 229. http://haskell.org/haskellwiki/HWN 230. http://code.haskell.org/~dons/code/hwn/ From ryani.spam at gmail.com Sun Feb 10 21:26:31 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Feb 10 21:25:14 2008 Subject: [Haskell-cafe] Proper exception handling In-Reply-To: <1202672979.3336.11.camel@localhost> References: <1202672979.3336.11.camel@localhost> Message-ID: <2f9b2d30802101826ybef9010gab92501f4013f2e7@mail.gmail.com> If you want to guarantee safety, you can use an MVar () to force serialization; put something in the MVar inside of catchDyn, and take from it immediately after starting the thread & after throwing each exception. -- ryan On Feb 10, 2008 11:49 AM, Thomas DuBuisson wrote: > Cafe, > Fact 1: ghc{,i} does not crash when executing this code. > Fact 2: I do not want this to crash. > Question: Is there some theoretical window between the 'catchDyn' exception handling and the recursive call to 'catchThatDamnError' that could result in an unhandled exception? (of type 'DynError', of coarse) > > I suppose I am looking for an answer to this question from a language standpoint as well as a compiler pov. > > As an aside: I see at least one way to be certain of the safty by wrapping the call to forkIO in 'catchDyn', reforking if an exception is caught, and passing the new ThreadId to throwConstantly via shared mutable state - I'd like to avoid all this if my current example is safe. > > Thomas > > > import Control.Exception (catchDyn, throwDynTo) > > import Control.Concurrent (forkIO, threadDelay) > > import Control.Monad (forever) > > import Data.Dynamic > > > > main = do > > tid <- forkIO catchThatDamnError > > forever $ throwConstantly tid > > > > catchThatDamnError = catchDyn start (\DynError -> catchThatDamnError) > > > > start = do > > threadDelay 5000 > > start > > > > throwConstantly tid = do > > throwDynTo tid DynError > > > > data DynError = DynError deriving (Eq, Ord, Show, Typeable) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jsnx at lolcatbible.com Sun Feb 10 23:17:33 2008 From: jsnx at lolcatbible.com (Jason Dusek) Date: Sun Feb 10 23:16:17 2008 Subject: [Haskell-cafe] Re: Datatypes - Haskell In-Reply-To: References: <3d96ac180802091652s1da0ae5as345fa3ec8afbc000@mail.gmail.com> Message-ID: <42784f260802102017p34e97d41i89ad3e60fe37d385@mail.gmail.com> Mattes Simeon wrote: > Though in comparison with C or C++ I can't figure out so clear > the syntax...I seems realy strange, and I'm confused. > > Surely a solution to this would be to use the standard types > of Haskel for tuples and check out each time if I have just a > number or a tuple. But this is how somebody thinks in > imperative languages. Functional programming is something > more... The data declarations in Haskell are well-suited to pattern matching -- you have a compact way to express each alternative, so you can match on that alternative. The C++ way offers a *uniform* interface to every alternative, so you can do if-tests that will type check. The "do an if test at runtime" way is very general, but basically unoptimizable; whereas pattern matching is very specific, and can be optimized (see page 5 of Luca Cardelli's [Compiling ML]). > Sorry for beeing so naive, but although unions, enum, > structure are just some tools in C, surely something more in > C++, in Haskell they are seem to be a standard. It's certainly true that Haskell elevates certain common data structures to the level of 'native citizens', providing short cut syntax and so forth. Personally, I think C's approach is an example of neglect in this domain, not sparseness; however, at the time C was introduced, I would not have said the same thing at all. -- _jsn [Compiling ML]: http://lucacardelli.name/Papers/CompilingML.pdf From uhollerbach at gmail.com Mon Feb 11 01:15:58 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Mon Feb 11 01:14:42 2008 Subject: [Haskell-cafe] fast integer base-2 log function? Message-ID: <65d7a7e0802102215m42e5b228xacfa4047a3a54075@mail.gmail.com> Hello, haskellers, Is there a fast integer base-2 log function anywhere in the standard libraries? I wandered through the index, but didn't find anything that looked right. I need something that's more robust than logBase, it needs to handle numbers with a few to many thousands of digits. I found a thread from a couple of years ago that suggested there was no such routine, and that simply doing "length (show n)" might be the best. That seems kind of... less than elegant. I've come up with a routine, shown below, that seems reasonably fast (a few seconds of CPU time for a million-bit number, likely adequate for my purposes), but it seems that something with privileged access to the innards of an Integer ought to be even much faster -- it's just a simple walk along a list (array?) after all. Any pointers? Thanks! Uwe > powi :: Integer -> Integer -> Integer > powi b e | e == 0 = 1 > | e < 0 = error "negative exponent in powi" > | even e = powi (b*b) (e `quot` 2) > | otherwise = b * (powi b (e - 1)) > ilog2 :: Integer -> Integer > ilog2 n | n < 0 = ilog2 (- n) > | n < 2 = 1 > | otherwise = up n (1 :: Integer) > where up n a = if n < (powi 2 a) > then bin (quot a 2) a > else up n (2*a) > bin lo hi = if (hi - lo) <= 1 > then hi > else let av = quot (lo + hi) 2 > in if n < (powi 2 av) > then bin lo av > else bin av hi (This was all properly aligned when I cut'n'pasted; proportional fonts might be messing it up here.) From naur at post11.tele.dk Mon Feb 11 01:44:03 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Mon Feb 11 01:45:31 2008 Subject: [Haskell-cafe] fast integer base-2 log function? In-Reply-To: <20080211061619.IPFX5833.fep27.mail.dk@www.haskell.org> References: <20080211061619.IPFX5833.fep27.mail.dk@www.haskell.org> Message-ID: <200802110744.10469.naur@post11.tele.dk> Hello, If the standard libraries provide such a function, I haven't found it. I must admit that I haven't studied your code in detail. I usually do as follows for integer logarithms, shamelessly stolen from the Haskell report: > -- Integer log base (c.f. Haskell report 14.4): > > imLog :: Integer->Integer->Integer > imLog b x > = if x < b then > 0 > else > let > l = 2 * imLog (b*b) x > doDiv x l = if x < b then l else doDiv (x`div`b) (l+1) > in > doDiv (x`div`(b^l)) l Best regards Thorkil On Monday 11 February 2008 07:15, Uwe Hollerbach wrote: > Hello, haskellers, > > Is there a fast integer base-2 log function anywhere in the standard > libraries? I wandered through the index, but didn't find anything that > looked right. I need something that's more robust than logBase, it > needs to handle numbers with a few to many thousands of digits. I > found a thread from a couple of years ago that suggested there was no > such routine, and that simply doing "length (show n)" might be the > best. That seems kind of... less than elegant. I've come up with a > routine, shown below, that seems reasonably fast (a few seconds of CPU > time for a million-bit number, likely adequate for my purposes), but > it seems that something with privileged access to the innards of an > Integer ought to be even much faster -- it's just a simple walk along > a list (array?) after all. Any pointers? Thanks! > > Uwe > > > powi :: Integer -> Integer -> Integer > > powi b e | e == 0 = 1 > > | e < 0 = error "negative exponent in powi" > > | even e = powi (b*b) (e `quot` 2) > > | otherwise = b * (powi b (e - 1)) > > > ilog2 :: Integer -> Integer > > ilog2 n | n < 0 = ilog2 (- n) > > | n < 2 = 1 > > | otherwise = up n (1 :: Integer) > > where up n a = if n < (powi 2 a) > > then bin (quot a 2) a > > else up n (2*a) > > bin lo hi = if (hi - lo) <= 1 > > then hi > > else let av = quot (lo + hi) 2 > > in if n < (powi 2 av) > > then bin lo av > > else bin av hi > > (This was all properly aligned when I cut'n'pasted; proportional fonts > might be messing it up here.) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From stefanor at cox.net Mon Feb 11 02:21:07 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Feb 11 02:19:54 2008 Subject: [Haskell-cafe] fast integer base-2 log function? In-Reply-To: <65d7a7e0802102215m42e5b228xacfa4047a3a54075@mail.gmail.com> References: <65d7a7e0802102215m42e5b228xacfa4047a3a54075@mail.gmail.com> Message-ID: <20080211072107.GA5038@localhost.localdomain> On Sun, Feb 10, 2008 at 10:15:58PM -0800, Uwe Hollerbach wrote: > Hello, haskellers, > > Is there a fast integer base-2 log function anywhere in the standard > libraries? I wandered through the index, but didn't find anything that > looked right. I need something that's more robust than logBase, it > needs to handle numbers with a few to many thousands of digits. I > found a thread from a couple of years ago that suggested there was no > such routine, and that simply doing "length (show n)" might be the > best. That seems kind of... less than elegant. I've come up with a > routine, shown below, that seems reasonably fast (a few seconds of CPU > time for a million-bit number, likely adequate for my purposes), but > it seems that something with privileged access to the innards of an > Integer ought to be even much faster -- it's just a simple walk along > a list (array?) after all. Any pointers? Thanks! Even easier. {-# LANGUAGE MagicHash #-} import GHC.Exts import Data.Bits -- experiment with using a LUT here (hint: FFI + static arrays in C) ilog2i0, ilog2i1, ilog2i2, ilog2i3, ilog2i4 :: Int -> Int -> Int ilog2i0 k x | x .&. 0xFFFF0000 /= 0 = ilog2i1 (k + 16) (x `shiftR` 16) | otherwise = ilog2i1 k x ilog2i1 k x | x .&. 0xFF00 /= 0 = ilog2i2 (k + 8) (x `shiftR` 8) | otherwise = ilog2i2 k x ilog2i2 k x | x .&. 0xF0 /= 0 = ilog2i3 (k + 4) (x `shiftR` 4) | otherwise = ilog2i3 k x ilog2i3 k x | x .&. 0xC /= 0 = ilog2i4 (k + 2) (x `shiftR` 2) | otherwise = ilog2i4 k x ilog2i4 k x | x .&. 0x2 /= 0 = k + 1 + (x `shiftR` 1) | otherwise = k + x log2i :: Integer -> Int -- actually returns bit length, and returns garbage on negatives, but do you care? log2i (J# len adr) = ilog2i0 0 (I# (indexIntArray# adr (len -# 1#))) + I# (32# *# (len -# 1#)) log2i (S# sml) = ilog2i0 0 (I# sml) > > powi :: Integer -> Integer -> Integer > > powi b e | e == 0 = 1 > > | e < 0 = error "negative exponent in powi" > > | even e = powi (b*b) (e `quot` 2) > > | otherwise = b * (powi b (e - 1)) > > > ilog2 :: Integer -> Integer > > ilog2 n | n < 0 = ilog2 (- n) > > | n < 2 = 1 > > | otherwise = up n (1 :: Integer) > > where up n a = if n < (powi 2 a) > > then bin (quot a 2) a > > else up n (2*a) > > bin lo hi = if (hi - lo) <= 1 > > then hi > > else let av = quot (lo + hi) 2 > > in if n < (powi 2 av) > > then bin lo av > > else bin av hi > > (This was all properly aligned when I cut'n'pasted; proportional fonts > might be messing it up here.) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- 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/20080210/19b63cfc/attachment.bin From bf3 at telenet.be Mon Feb 11 03:06:59 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Mon Feb 11 03:05:39 2008 Subject: [Haskell-cafe] Newbie question: mutually exclusive strict / lazy In-Reply-To: References: Message-ID: <001801c86c85$13b81360$3b283a20$@be> Yes, sorry, GHC's strictness analyzer. What I meant with this email is that I guess that for a strictness analyzer, the information that a function is strict in an argument *independent from the other arguments* would not be good enough in itself for optimization, it would be better to also use the dependencies between the arguments (as in the case of the if.then.else). It seems one can indicate in GHC that an argument is strict using annotiations, but I don't see a way of specifying these dependencies (maybe this does not make sense, and this is all newbie nonsense). Of course, with whole program optimization this would not be necessary, but if the compiler just sees the function signature, he must assume that a lazy argument is always lazy, independent of the value of other strict arguments no? Cheers, Peter From: lennart.augustsson@gmail.com [mailto:lennart.augustsson@gmail.com] On Behalf Of Lennart Augustsson Sent: maandag 11 februari 2008 0:28 To: Peter Verswyvelen Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Newbie question: mutually exclusive strict / lazy I'm not sure what you mean by "the strictness analyzer". GHC's strictness analyzer? I don't know, but I would hope so since it was done already in 1980 by Alan Mycroft. -- Lennart On Sat, Feb 9, 2008 at 4:33 PM, Peter Verswyvelen wrote: Consider the function cond x y z = if x then y else z I guess we can certainly say cond is strict in x. But what about y and z? If x is true, then cond is strict in y If x is false, then cond is strict in z So we can't really say cond is lazy nor strict in its second or third argument. Of course, this is the case for many more functions, but in the case of the if-then-else primitive, does the strictness analyzer make use of this "mutually exclusive strictness" fact? Cheers, Peter _______________________________________________ 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/20080211/a68fa087/attachment.htm From hitesh.jasani at gmail.com Mon Feb 11 03:54:12 2008 From: hitesh.jasani at gmail.com (Hitesh Jasani) Date: Mon Feb 11 03:53:03 2008 Subject: [Haskell-cafe] ANN: nano-hmac 0.2.0 Message-ID: nano-hmac provides bindings to OpenSSL's HMAC interface. With this release the set of hashing functions supported is: MD5, SHA, SHA1, SHA224, SHA256, SHA384, SHA512. If you're unfamiliar with HMAC's then you may want to check out the second link below where I explain a little bit about them in a blog entry. The hackage pages mentioned that they're not running haddock 2.0, so I don't know if the docs will generate. If not, you can see the docs online at the third link below. * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nano-hmac-0.2.0 * http://www.jasani.org/2008/02/nano-hmac-020-released.html * http://docs.jasani.org/nano-hmac/0.2.0/ Any and all comments/suggestions/criticisms/fortune-cookie-proverbs are welcome. Thanks, Hitesh From loup.vaillant at gmail.com Mon Feb 11 04:51:34 2008 From: loup.vaillant at gmail.com (Loup Vaillant) Date: Mon Feb 11 04:50:18 2008 Subject: [Haskell-cafe] Newbie question: mutually exclusive strict / lazy In-Reply-To: <001801c86c85$13b81360$3b283a20$@be> References: <001801c86c85$13b81360$3b283a20$@be> Message-ID: <6f9f8f4a0802110151i31ced3a4u8c65011f2c5125ea@mail.gmail.com> 2008/2/11, Peter Verswyvelen : > > Yes, sorry, GHC's strictness analyzer. > > What I meant with this email is that I guess that for a strictness analyzer, > the information that a function is strict in an argument *independent from > the other arguments* would not be good enough in itself for optimization, it > would be better to also use the dependencies between the arguments (as in > the case of the if?then?else). > > It seems one can indicate in GHC that an argument is strict using > annotiations, but I don't see a way of specifying these dependencies (maybe > this does not make sense, and this is all newbie nonsense). Of course, with > whole program optimization this would not be necessary, but if the compiler > just sees the function signature, he must assume that a lazy argument is > always lazy, independent of the value of other strict arguments no? It may not always be the case, but, here, for your particular example, what you need is an inline followed by a reduction (dunno which). Reminder: > cond x y z = if x then y else z The translation in core, is this: cond x y z = case x of True -> y False -> z So, suppose we know at some call site that x is True. So, the call cond x e1 e2 -- e1 and e2 are arbitrary expressions is equivalent to: cond True e1 e2 An inline replaces the call by this: cond x e1 e2 = case True of True -> e1 False -> e2 In this case, the compiler can easily determine at compile time the selected branch. Therefore, this "case" expression is replaced by the correct branch: e1 I would be surprised if GHC doesn't already perform this kind of optimization [1,2]. So, no need for a fancy strictness analyser for this code. About more complicated cases, I'm clueless, thought. Cheers, Loup [1] http://research.microsoft.com/~simonpj/Papers/inlining/ [2] http://citeseer.ist.psu.edu/jones91unboxed.html From felipe.lessa at gmail.com Mon Feb 11 04:53:13 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Mon Feb 11 04:51:56 2008 Subject: [Haskell-cafe] using the writer monad to better understand foldl and foldr, and haskell debugging techniques in general In-Reply-To: <910ddf450802101552s1c9bce82o2884002c5a2582b3@mail.gmail.com> References: <910ddf450802101533k2335c864sf21fc370e58df11d@mail.gmail.com> <910ddf450802101551s3ea00662w406b014d240f302c@mail.gmail.com> <910ddf450802101552s1c9bce82o2884002c5a2582b3@mail.gmail.com> Message-ID: On Feb 10, 2008 9:52 PM, Thomas Hartman wrote: > So, I would say this proves my main point, which was that you could > accomplish the same thing using the writer monad that you could do > using the more "ad hoc" trace function from Debug.Trace. Not really. That only happens with your implementation of myfoldrD. If you write it as myfoldrD' f z [] = z myfoldrD' f z (x:xs) = x `f` trace ("x,r: " ++ (show (x,r))) r where r = myfoldrD' f z xs then we have the expected behavior *Main> myfoldrD (:) [] [1..5] x,r: (5,[]) x,r: (4,[5]) x,r: (3,[4,5]) x,r: (2,[3,4,5]) x,r: (1,[2,3,4,5]) [1,2,3,4,5] *Main> myfoldrD' (:) [] [1..5] [1x,r: (5,[]) x,r: (4,[5]) x,r: (3,[4,5]) x,r: (2,[3,4,5]) x,r: (1,[2,3,4,5]) ,2,3,4,5] *Main> myfoldrD const 0 [1..] Interrupted. *Main> myfoldrD' const 0 [1..] 1 *Main> myfoldrD (\x xs -> if x < 0 then [] else x:xs) [] ([1,2,3,-1] ++ repeat 0) *** Exception: stack overflow *Main> myfoldrD' (\x xs -> if x < 0 then [] else x:xs) [] ([1,2,3,-1] ++ repeat 0) [1x,r: (3,[]) x,r: (2,[3]) x,r: (1,[2,3]) ,2,3] As Debug.Trace hides the IO monad in a pure computation (i.e. unsafePerformIO) we can use it from the inside of the [pure] function that is passed to foldr. Note that we could also implement a Writer monad on top of unsafePerformIO, you basically just change Debug.Trace to an IO action that does the mappend as Writer would but in an IORef. In the end you read that IORef and do a big tell to the outside Writer monad. I'd say that this is a safe use of unsafePerformIO as it shouldn't break referential transparency. But without this hack I don't think we could do the same thing. Good news is that the hack is 'hideable' as are the hacks from ByteString, for example. Cheers, -- Felipe. From felipe.lessa at gmail.com Mon Feb 11 04:55:01 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Mon Feb 11 04:53:44 2008 Subject: [Haskell-cafe] using the writer monad to better understand foldl and foldr, and haskell debugging techniques in general In-Reply-To: References: <910ddf450802101533k2335c864sf21fc370e58df11d@mail.gmail.com> <910ddf450802101551s3ea00662w406b014d240f302c@mail.gmail.com> <910ddf450802101552s1c9bce82o2884002c5a2582b3@mail.gmail.com> Message-ID: On Feb 11, 2008 7:53 AM, Felipe Lessa wrote: > read that IORef and do a big tell to the outside Writer monad. I'd say > that this is a safe use of unsafePerformIO as it shouldn't break > referential transparency. But without this hack I don't think we could Well, not really as well. The IO action from unsafePerformIO may be executed several times, I guess. =) -- Felipe. From g9ks157k at acme.softbase.org Mon Feb 11 08:24:19 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 11 08:23:28 2008 Subject: [Haskell-cafe] Haskell Weekly News - February 10, 2008 In-Reply-To: <20080211010939.GB28106@scytale.galois.com> References: <20080211010939.GB28106@scytale.galois.com> Message-ID: <200802111424.19285.g9ks157k@acme.softbase.org> Am Montag, 11. Februar 2008 02:09 schrieb Don Stewart: > [?] > * Imlib 0.1.1. Uploaded by Cale Gibbard. [120]Imlib: Added by > CaleGibbard, Sun Jan 13 22:26:59 PST 2008.. > [?] > * haddock 2.0.0.0. Uploaded by David Waern. [147]haddock: Added by > DavidWaern > [?] What's the reason for these entries not having a sensible synopsis? > [?] Best wishes, Wolfgang From asitdepends2 at gmail.com Mon Feb 11 08:33:23 2008 From: asitdepends2 at gmail.com (Deokjae Lee) Date: Mon Feb 11 08:32:05 2008 Subject: [Haskell-cafe] A question about "monad laws" Message-ID: Tutorials about monad mention the "monad axioms" or "monad laws". The tutorial "All About Monads" says that "It is up to the programmer to ensure that any Monad instance he creates satisfies the monad laws". The following is one of the laws. (x >>= f) >>= g == x >>= (\v -> f v >>= g) However, this seems to me a kind of mathematical identity. If it is mathematical identity, a programmer need not care about this law to implement a monad. Can anyone give me an example implementation of monad that violate this law ? From ndmitchell at gmail.com Mon Feb 11 08:38:57 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 11 08:37:38 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: Message-ID: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> Hi > The following is one of the laws. > > (x >>= f) >>= g == x >>= (\v -> f v >>= g) Or stated another way: (x >>= f) >>= g == x >>= (f >>= g) Now it should be easier to see that this is simply associativity. It's easy enough to violate, if you want to - but I don't have any nice simple examples to hand. Thanks Neil From ross at soi.city.ac.uk Mon Feb 11 08:44:01 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 11 08:43:07 2008 Subject: [Haskell-cafe] Haskell Weekly News - February 10, 2008 In-Reply-To: <200802111424.19285.g9ks157k@acme.softbase.org> References: <20080211010939.GB28106@scytale.galois.com> <200802111424.19285.g9ks157k@acme.softbase.org> Message-ID: <20080211134401.GA18919@soi.city.ac.uk> On Mon, Feb 11, 2008 at 02:24:19PM +0100, Wolfgang Jeltsch wrote: > Am Montag, 11. Februar 2008 02:09 schrieb Don Stewart: > > [???] > > > * Imlib 0.1.1. Uploaded by Cale Gibbard. [120]Imlib: Added by > > CaleGibbard, Sun Jan 13 22:26:59 PST 2008.. > > > [???] > > > * haddock 2.0.0.0. Uploaded by David Waern. [147]haddock: Added by > > DavidWaern > > > [???] > > What's the reason for these entries not having a sensible synopsis? Because the hackageDB RSS feed he's using doesn't include a synopsis, for no particular reason. From kid.meier at gmail.com Mon Feb 11 08:57:23 2008 From: kid.meier at gmail.com (Michael Reid) Date: Mon Feb 11 08:56:07 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> Message-ID: > Now it should be easier to see that this is simply associativity. It's > easy enough to violate, if you want to - but I don't have any nice > simple examples to hand. > > I have recently been reading a tutorial or paper where a Monad that violated this law was presented. The authors shrugged it off as not important, that the notation gained by implementing the operation as a Monad was worth it, but what is not clear is what the consequences of violating such associativity are. Does violating this law introduce the potential that your program will not do what you think it should? /mike. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080211/45028f96/attachment.htm From ndmitchell at gmail.com Mon Feb 11 08:59:09 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 11 08:57:51 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> Message-ID: <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> Hi > > (x >>= f) >>= g == x >>= (\v -> f v >>= g) > > Or stated another way: > > (x >>= f) >>= g == x >>= (f >>= g) Which is totally wrong, woops. See this page for lots of details about the Monad Laws and quite a nice explanation of where you use them: http://www.haskell.org/haskellwiki/Monad_Laws Thanks Neil From jerzy.karczmarczuk at info.unicaen.fr Mon Feb 11 09:15:51 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Mon Feb 11 09:14:32 2008 Subject: [Haskell-cafe] A question about =?utf-8?B?Im1vbmFkIGxhd3Mi?= In-Reply-To: References: Message-ID: Deokjae Lee cites: > The tutorial "All About Monads" says that "It is up to the programmer to > ensure that any Monad instance he creates satisfies the monad laws". > > The following is one of the laws. > > (x >>= f) >>= g == x >>= (\v -> f v >>= g) > > However, this seems to me a kind of mathematical identity. If it is > mathematical identity, a programmer need not care about this law to > implement a monad. Can anyone give me an example implementation of > monad that violate this law ? After three or five reactions to this posting, I think it it is time to generalize. Haskell is not math. Or rather, there is no way to be sure that the *implementation* of some mathematical domains and operations thereupon are fool-proof. Sometimes you break "en passant" some sacred laws. For example the transitivity of ordering. 5>2, right? and 8>5 as well. But, imagine a - little esoteric example of cyclic arithmetic modulo 10, where the shortest distance gives you the order, so 2>8. A mathematician will shrug, saying that calling +that+ an order relation is nonsense, and he/she will be absolutely right. But people do that... There is a small obscure religious sect of people who want to implement several mathematical entities as functional operators, where multiplication is f. composition. You do it too generically, too optimistically, and then some octonions come and break your teeth. So, people *should care*. Jerzy Karczmarczuk From news at lyra.net Mon Feb 11 09:27:40 2008 From: news at lyra.net (news@lyra.net) Date: Mon Feb 11 09:26:25 2008 Subject: [Haskell-cafe] f(g(x), h(y)) - Correct syntax Message-ID: <47b05b5c.38e.3a3d.1988458869@webmailh4.aruba.it> Hallo! I have this code: ---------------------------------------- q1 :: EName -> [ApprenticeInfo] q1 c = [apprenticeInfo n | n <- allApprentices, member ((sq4 c) (firstOf5(n))) == True] sq4 :: ESurname -> [IDB] sq4 c = (sq3 (sq1 (c))) firstOf5 :: (a,b,c,d,e) -> a firstOf5 (n,_,_,_,_) = n member :: [IDB] -> IDB -> Bool member [] y = False member(x:xs) y = (x==y) || member xs y ---------------------------------------- sq4 works correctly and returns [IDB] Unfortunately member ((sq4 c) (firstOf5(n))) gives this error: Type error in application *** Expression : sq4 c (firstOf5 n) *** Term : sq4 *** Type : ESurname -> [IDB] *** Does not match : a -> b -> c As far as I see it I'm not writing the correct syntax for a function of 2 functions. I have g(x): Esurname->[IDB] h(y): (IDB,_,_,_,_) -> IDB f(x,y): ([IDB], IDB) -> Bool I want to obtain f(g(x), h(y)) and I obtain something else. Where am I wrong? Thanks From lrpalmer at gmail.com Mon Feb 11 09:34:03 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 11 09:32:44 2008 Subject: [Haskell-cafe] f(g(x), h(y)) - Correct syntax In-Reply-To: <47b05b5c.38e.3a3d.1988458869@webmailh4.aruba.it> References: <47b05b5c.38e.3a3d.1988458869@webmailh4.aruba.it> Message-ID: <7ca3f0160802110634k2caffd9cu3b6aa9582285b463@mail.gmail.com> On Feb 11, 2008 2:27 PM, news@lyra.net wrote: > Hallo! > > I have this code: > ---------------------------------------- > q1 :: EName -> [ApprenticeInfo] > q1 c = [apprenticeInfo n | n <- allApprentices, member ((sq4 > c) (firstOf5(n))) == True] > > sq4 :: ESurname -> [IDB] > sq4 c = (sq3 (sq1 (c))) > > firstOf5 :: (a,b,c,d,e) -> a > firstOf5 (n,_,_,_,_) = n > > member :: [IDB] -> IDB -> Bool > member [] y = False > member(x:xs) y = (x==y) || member xs y > ---------------------------------------- > sq4 works correctly and returns [IDB] > Unfortunately member ((sq4 c) (firstOf5(n))) gives this > error: > > Type error in application > *** Expression : sq4 c (firstOf5 n) > *** Term : sq4 > *** Type : ESurname -> [IDB] > *** Does not match : a -> b -> c > > As far as I see it I'm not writing the correct syntax for a > function of 2 functions. I assume you meant arguments. And you're right. In Haskell the whole argument list is not enclosed in parentheses like it is in many other languages. "f (x y)" means what C would call "f(x(y))", whereas "f x y" means what C would call "f(x,y)" (modulo currying stuff). Drop the set of parentheses starting just after member and you should be fine. Luke From lemming at henning-thielemann.de Mon Feb 11 09:42:18 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Feb 11 09:41:02 2008 Subject: [Haskell-cafe] f(g(x), h(y)) - Correct syntax In-Reply-To: <47b05b5c.38e.3a3d.1988458869@webmailh4.aruba.it> References: <47b05b5c.38e.3a3d.1988458869@webmailh4.aruba.it> Message-ID: On Mon, 11 Feb 2008, news@lyra.net wrote: > Hallo! > > I have this code: > ---------------------------------------- > q1 :: EName -> [ApprenticeInfo] > q1 c = [apprenticeInfo n | n <- allApprentices, member ((sq4 > c) (firstOf5(n))) == True] > > sq4 :: ESurname -> [IDB] > sq4 c = (sq3 (sq1 (c))) > > firstOf5 :: (a,b,c,d,e) -> a > firstOf5 (n,_,_,_,_) = n > > member :: [IDB] -> IDB -> Bool > member [] y = False > member(x:xs) y = (x==y) || member xs y cf. List.elem From apfelmus at quantentunnel.de Mon Feb 11 10:14:34 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Mon Feb 11 10:13:27 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: Message-ID: Deokjae Lee wrote: > Tutorials about monad mention the "monad axioms" or "monad laws". The > tutorial "All About Monads" says that "It is up to the programmer to > ensure that any Monad instance he creates satisfies the monad laws". > > The following is one of the laws. > > (x >>= f) >>= g == x >>= (\v -> f v >>= g) > > However, this seems to me a kind of mathematical identity. If it is > mathematical identity, a programmer need not care about this law to > implement a monad. Can anyone give me an example implementation of > monad that violate this law ? I will be mean by asking the following counter question: x + (y + z) = (x + y) + z is a mathematical identity. If it is a mathematical identity, a programmer need not care about this law to implement addition + . Can anyone give me an example implementation of addition that violates this law? The only difference here is that the associative law for addition is "obvious" to you, whereas the associative law for monads is not "obvious" to you (yet). As Neil mentioned, maybe http://www.haskell.org/haskellwiki/Monad_Laws can help to convince yourself that the associative law monads should be obvious, too. In short, the reason for its obviousness is the interpretation of >>= in terms of sequencing actions with side effects. The law is probably best demonstration with its special case x >> (y >> z) = (x >> y) >> z In other words, it signifies that it's only the sequence of x,y,z and not the nesting that matters. Regards, apfelmus From jonathanccast at fastmail.fm Mon Feb 11 10:34:36 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Feb 11 10:33:20 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: Message-ID: <1B8EE28B-2F75-4A45-8B49-BE4409B59B2A@fastmail.fm> On 11 Feb 2008, at 5:33 AM, Deokjae Lee wrote: > Tutorials about monad mention the "monad axioms" or "monad laws". The > tutorial "All About Monads" says that "It is up to the programmer to > ensure that any Monad instance he creates satisfies the monad laws". > > The following is one of the laws. > > (x >>= f) >>= g == x >>= (\v -> f v >>= g) > > However, this seems to me a kind of mathematical identity. What do you mean by identity? It's easy enough to violate: newtype Gen a = Gen (StdGen -> a) runGen :: Gen a -> StdGen -> a runGen (Gen f) = f instance Monad Gen where return x = Gen (const x) a >>= f = Gen (\ r -> let (r1, r2) = split r in runGen (f (runGen a r1)) r2) [1] split returns two generators independent of each other and of its argument; thus, this `monad' violates all *three* of the monad laws, in the sense of equality. So, for example, the program do x <- a return x denotes a random variable independent of (and hence distinct from) a. In general, you want some kind of backstop `equality' (e.g., that the monad laws hold in the sense of identical distribution) when you violate them; otherwise, you will violate the expectations your users have from the syntax of the do notation. jcc [1] Test.QuickCheck From Andrew.Butterfield at cs.tcd.ie Mon Feb 11 10:35:23 2008 From: Andrew.Butterfield at cs.tcd.ie (Andrew Butterfield) Date: Mon Feb 11 10:34:00 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: Message-ID: <47B06B3B.2070504@cs.tcd.ie> apfelmus wrote: > Deokjae Lee wrote: >> Tutorials about monad mention the "monad axioms" or "monad laws". The >> tutorial "All About Monads" says that "It is up to the programmer to >> ensure that any Monad instance he creates satisfies the monad laws". >> >> The following is one of the laws. >> >> (x >>= f) >>= g == x >>= (\v -> f v >>= g) >> >> However, this seems to me a kind of mathematical identity. If it is >> mathematical identity, a programmer need not care about this law to >> implement a monad. Can anyone give me an example implementation of >> monad that violate this law ? > > I will be mean by asking the following counter question: > > x + (y + z) = (x + y) + z > > is a mathematical identity. If it is a mathematical identity, a > programmer need not care about this law to implement addition + . Can > anyone give me an example implementation of addition that violates > this law? Hugs> 1.0 + (2.5e-15 + 2.5e-15) 1.00000000000001 :: Double Hugs> (1.0 + 2.5e-15) + 2.5e-15 1.0 :: Double Hugs, on Pentium 4 machine running Windows XP SP2 (all of which is largely irrelevant!) This is precisely Jerzy's point - you can have many mathematical laws as you like but there is no guarantee that a programming languages implementation will satisfy them. The above example is due to rounding errors and arises because the Double type in Haskell (or C, C++, whatever) is a finite (rational) approximation to real numbers which are infinite (platonic) entities. Associativity of addition applies for platonic reals, but not their widely used IEEE-standard approximate implementation on standard hardware. For monads, the situation is slightly different. Haskell describes the signature of the monadic operators return :: x -> m x (>>=) :: m a -> (a -> m b) -> m b but cannot restrict how you actually instantiate these. It admonishes you by stating that you should obey the relevant laws, but cannot enforce this. (of course, technically if you implement a dodgy monad, its not really a monad at all, but something different with operators with the same name and types - also technically values of type Double are not real numbers, (or true rationals either !) let m denote the "list monad" (hypothetically). Let's instantiate: return :: x -> [x] return x = [x,x] (>>=) :: [x] -> (x -> [y]) -> [y] xs >>= f = concat ((map f) xs) Let g n = [show n] Here (return 1 >>= g ) [1,2,3] = ["1","1","1","1","1","1"] but g[1,2,3] = ["1","2","3"], thus violating the first monad law | return a >>= f = f a | -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. Course Director, B.A. (Mod.) in CS and ICT degrees, Year 4. Department of Computer Science, Room F.13, O'Reilly Institute, Trinity College, University of Dublin, Ireland. http://www.cs.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- From felipe.lessa at gmail.com Mon Feb 11 10:50:59 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Mon Feb 11 10:49:42 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B06B3B.2070504@cs.tcd.ie> References: <47B06B3B.2070504@cs.tcd.ie> Message-ID: On Feb 11, 2008 1:35 PM, Andrew Butterfield wrote: > Hugs> 1.0 + (2.5e-15 + 2.5e-15) > 1.00000000000001 :: Double > Hugs> (1.0 + 2.5e-15) + 2.5e-15 > 1.0 :: Double Prelude> (1e30 + (-1e30)) + 1 1.0 Prelude> 1e30 + ((-1e30) + 1) 0.0 I love this example from David Goldberg (http://docs.sun.com/source/806-3568/ncg_goldberg.html). -- Felipe. From arnarbi at gmail.com Mon Feb 11 10:52:01 2008 From: arnarbi at gmail.com (Arnar Birgisson) Date: Mon Feb 11 10:50:45 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: Message-ID: <28012bc60802110752j1ce1770ck6be1ec7406b0c422@mail.gmail.com> Hi all, On Feb 11, 2008 3:14 PM, apfelmus wrote: > I will be mean by asking the following counter question: > > x + (y + z) = (x + y) + z > > is a mathematical identity. If it is a mathematical identity, a > programmer need not care about this law to implement addition + . Can > anyone give me an example implementation of addition that violates this law? Depends on what you mean by "addition". In general, algebraists call any associative and commutative operation on a set "addition", and nothing else. From that POV, there is by definition no "addition" that violates this law. Arnar From Andrew.Butterfield at cs.tcd.ie Mon Feb 11 10:59:46 2008 From: Andrew.Butterfield at cs.tcd.ie (Andrew Butterfield) Date: Mon Feb 11 10:58:21 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B06B3B.2070504@cs.tcd.ie> References: <47B06B3B.2070504@cs.tcd.ie> Message-ID: <47B070F2.1070102@cs.tcd.ie> Andrew Butterfield wrote: > let m denote the "list monad" (hypothetically). Let's instantiate: > > return :: x -> [x] > return x = [x,x] > > (>>=) :: [x] -> (x -> [y]) -> [y] > xs >>= f = concat ((map f) xs) > > Let g n = [show n] > > Here (return 1 >>= g ) [1,2,3] = ["1","1","1","1","1","1"] > but g[1,2,3] = ["1","2","3"], > thus violating the first monad law | return > > a >>= > > f = f a > I messed this up - I was trying for the simplest example I could get ! Apologies. Start over: Program ---------------------------------------------------- module BadMonad where import Monad newtype MyList t = MyList [t] instance Show t => Show (MyList t) where show (MyList xs) = show xs unmylist (MyList xs) = xs myconcat xs = MyList (concat (map unmylist xs)) instance Monad MyList where return x = MyList [x,x] (MyList xs) >>= f = myconcat ((map f) xs) i2s :: Int -> MyList Char i2s x = MyList (show x) m = i2s 9 Hugs transcript ---------------------------------------- BadMonad> m "9" :: MyList Char BadMonad> m >>= return "99" :: MyList Char We violate the second law (Right Identity, m = m >>= return ) -- -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. Course Director, B.A. (Mod.) in CS and ICT degrees, Year 4. Department of Computer Science, Room F.13, O'Reilly Institute, Trinity College, University of Dublin, Ireland. http://www.cs.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- From jonathanccast at fastmail.fm Mon Feb 11 11:00:04 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Feb 11 10:58:49 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <28012bc60802110752j1ce1770ck6be1ec7406b0c422@mail.gmail.com> References: <28012bc60802110752j1ce1770ck6be1ec7406b0c422@mail.gmail.com> Message-ID: <5EECE1AC-1359-4394-A77B-5D9CABF932D0@fastmail.fm> On 11 Feb 2008, at 7:52 AM, Arnar Birgisson wrote: > Hi all, > > On Feb 11, 2008 3:14 PM, apfelmus wrote: >> I will be mean by asking the following counter question: >> >> x + (y + z) = (x + y) + z >> >> is a mathematical identity. If it is a mathematical identity, a >> programmer need not care about this law to implement addition + . Can >> anyone give me an example implementation of addition that violates >> this law? > > Depends on what you mean by "addition". In general, algebraists call > any associative and commutative operation on a set "addition", and > nothing else. From that POV, there is by definition no "addition" that > violates this law. I agree. The Num Double instance should be expelled from the Prelude immediately. jcc (What? Haskell has a Float type?) From alfonso.acosta at gmail.com Mon Feb 11 12:17:33 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Feb 11 12:16:19 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802101743.41443.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802092014t66e01ea3uc18c451a6fef1f8d@mail.gmail.com> <200802101743.41443.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802110917v4b34649dl62d843c925bfa16@mail.gmail.com> Hi Wolfgang, On Feb 10, 2008 5:43 PM, Wolfgang Jeltsch wrote: I added some line annotations to the code below so that errors can be more easily understood > > (<+>) :: Add s1 s2 s3 => FSVec s1 a -> FSVec s2 a -> FSVec s3 a -- line 78 > > NullV <+> ys = ys -- line 79 > > (x:>xs) <+> ys = x :> (xs <+> ys) -- line 80 > > Hmm, we would have to find a way to implement lemmas. In this case, the lemma > that succ (x + y) = succ x + y. At the moment, I've no good idea how to do > that. I'm not sure if that is the only problem. I already mentioned I'm a noob with GADTs so I might be wrong but it seems that emulating dependent types with multiparameter type classes or type synonym families (more on this below) and GADT pattern matching does not work nicely. In the case of <+>, three errors are generated: 1) Couldn't match expected type `s3' against inferred type `s2' `s3' is a rigid type variable bound by the type signature for `<+>' at Data/Param/FSVec.hs:78:19 `s2' is a rigid type variable bound by the type signature for `<+>' at Data/Param/FSVec.hs:78:16 Expected type: FSVec s3 a Inferred type: FSVec s2 a 2) Could not deduce (Data.TypeLevel.Num.Sets.PosI s3, Data.TypeLevel.Num.Ops.NClassify s3 yc, Data.TypeLevel.Num.Ops.DivMod10 yh yl s3) from the context (Succ s11 s1) 3) Could not deduce (Data.TypeLevel.Num.Ops.Add' s11 s2 s, Data.TypeLevel.Num.Ops.Add' s2 s11 s) from the context (Succ s11 s1) arising from a use of `<+>' So defining the lema you mentioned (succ (x + y) = succ x + y) wouldn't solve the whole problem. Actually (2) wouldn't happen if the context of the function was taken into account (i.e. "from the context (Succ s11 s1)" should be "from the context (Succ s11 s1, Add s1 s2 s3)". Can someone explain why GHC does not behave like that? I don't know if type synonym families would help for <+> but certainly they don't for tailV: > > tailV :: Succ s' s => FSVec s a -> FSVec s' a > > tailV (x :> xs) = xs > > Maybe this problem is similar to the one I came across earlier. See my mail > on and > the replies to it. As suggested by the pointer you provided, I redefined FSVec and tailV using a transformating of Succ into a type synonym family (see the end of this mail for its full definition) but it didn't help. data FSVec :: * -> * -> * where NullV :: FSVec D0 a (:>) :: FSVec s a -> FSVec (Succ s) a tailV :: FSVec s a -> FSVec (Succ s) a tailV (x :> xs) = xs tailV leads to this error (which I don't really understand :S) GADT pattern match in non-rigid context for `:>' Tell GHC HQ if you'd like this to unify the context In the pattern: x :> xs In the definition of `tailV': tailV (x :> xs) = xs My first impressions about using type synonym families (as opposed to multiparameter type classes) to fake dependent types are: * Positive part: - Operations on types can really be expressed as functions on types which is more natural than using MTPC-constraints. Infox operands are particularly expressive. For example: -- Add type family type family (:+:) x y :: * - According to http://www.haskell.org/pipermail/haskell/2007-September/019759.html They fit in a nicer way with the Haskell standard. * Negative part: - They don't allow defining relational type operations, which is _really_ important to dramatically reduce the number of necessary instances. i.e Pred cannot be defined out of Succ, this declaration is ilegal type family Pred x :: * type instance Pred (Succ x) = x whereas it is perfecty possible using MTPCs class (Pos x, Nat y) => Pred x y | x -> y, y -> x instance Succ x y => Pred y x - I'm maybe missing something, but it seems that type synonym families don't work nicely with typeclass constraints. this is ilegal (syntax error): type family Nat x => Succ x :: * this is ilegal too (another syntax error): type instance Nat x => Succ (x :* D0) = x :* D1 and finally I was really surprised to know that, using the type synonym family this is illegal too! toInt (succRef d0) the expression above leads to the following error: No instance for (Data.TypeLevel.Num.Sets.NatI (Succ D0)) But .... Succ D0 = D1, and D1 and D1 _is_ an instance of NatI ! ---- Conclusion ---- So, it seems that with or without type synonym families GADTs don't work so nicely to emulate dependent types (or at least numer-parameterized data structures), so I'll move on to traditional phantom types unless someone provides a solution. I'd like to be proven wrong (we'll lose pattern matching without GADTs which is a pity) but I cannot come up with a better solution. On the other hand, using phantom type parameters allows to encapsulate whichever vector representation we want "under the hood". And that's actually the approach followed by Fredrik Eaton's Vectro library: http://ofb.net/~frederik/vectro/ So unless someone provides a solution for the GADT problem, I think the best option would be simply adapting Vectro to work with the type-level library. > > The result would be a function with the following type: > > > > vector :: [a] -> (forall s . Nat s => FSVec s a -> w) -> w > > > > Nevertheless, I'm not fully satisfied by it. > > I suppose, it's the best we can get without having dependent types. Others > might correct me. Well, if that's all it can be done (and that's what it seems from your answers), satisfied or not, there's no better option. > > Some remark concerning spelling: Would it be possible to drop the V at the end > of the function names? I think the fact that those functions are > about "vectors" is better expressed by qualification: Right, do you think the same should be done for Data.TypeLeve.Num.Ops ? (succRef, predRef, addRef, subRef and friends ...) Best Regards, A really frustrated Fons PS: Implemnetaion of Succ using a type synonym family. -- | Successor type-level relation type family Succ x :: * type instance Succ D0 = D1 type instance Succ D1 = D2 type instance Succ D2 = D3 type instance Succ D3 = D4 type instance Succ D4 = D5 type instance Succ D5 = D6 type instance Succ D6 = D7 type instance Succ D7 = D8 type instance Succ D9 = (D1 :* D0) type instance Succ (x :* D0) = x :* D1 type instance Succ (x :* D1) = x :* D2 type instance Succ (x :* D2) = x :* D3 type instance Succ (x :* D3) = x :* D4 type instance Succ (x :* D4) = x :* D5 type instance Succ (x :* D5) = x :* D6 type instance Succ (x :* D6) = x :* D7 type instance Succ (x :* D7) = x :* D8 type instance Succ (x :* D8) = x :* D9 type instance Succ (x :* D9) = (Succ x) :* D0 -- | value-level reflection function for the succesor type-level relation -- (named succRef to avoid a clash with 'Prelude.succ') succRef :: Nat x => x -> Succ x succRef = undefined From agl at imperialviolet.org Mon Feb 11 12:42:44 2008 From: agl at imperialviolet.org (Adam Langley) Date: Mon Feb 11 12:41:26 2008 Subject: [Haskell-cafe] ANN: nano-hmac 0.2.0 In-Reply-To: References: Message-ID: <396556a20802110942g7e917b61o3f9a8a0d27823800@mail.gmail.com> On Feb 11, 2008 12:54 AM, Hitesh Jasani wrote: > nano-hmac provides bindings to OpenSSL's HMAC interface. With this release the > set of hashing functions supported is: MD5, SHA, SHA1, SHA224, SHA256, SHA384, > SHA512. Just a heads up; PHO has written nice bindings to much of OpenSSL: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsOpenSSL-0.3.1 AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From jgbailey at gmail.com Mon Feb 11 12:46:32 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Mon Feb 11 12:45:14 2008 Subject: [Haskell-cafe] Compulsory relation 1 to many from entity A to entity A In-Reply-To: <47ad7c89.23a.1d18.804875462@webmailh2.aruba.it> References: <47ad7c89.23a.1d18.804875462@webmailh2.aruba.it> Message-ID: On Feb 9, 2008 2:12 AM, news@lyra.net wrote: > I'd like to build a database model with winHugs that allows > a "recursive relation". For example a single instance of > entity "components" is related with at least another row of > the entity "components" (1 to many relationship). How can I > do that? A very simple approach is to use a recursive data type: data Relation = Relate Component [Component] If components store their relations, then data Component = Component { related :: Maybe [Component] } There are much more complicated but type-safe approaches too. What are you looking to do? Justin From miguelimo38 at yandex.ru Mon Feb 11 12:46:25 2008 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Mon Feb 11 12:45:23 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: Message-ID: > (x >>= f) >>= g == x >>= (\v -> f v >>= g) > > However, this seems to me a kind of mathematical identity. If it is > mathematical identity, a programmer need not care about this law to > implement a monad. Can anyone give me an example implementation of > monad that violate this law ? It's well known that "ListT m" monad violates this law in general (though it satisfies it for some particular monads m). For example, Prelude Control.Monad.List> runListT ((ListT [[(),()]] >> ListT [[()], [()]]) >> ListT [[1],[2]]) [[1,1],[1,2],[2,1],[2,2],[1,1],[1,2],[2,1],[2,2],[1,1],[1,2],[2,1], [2,2],[1,1],[1,2],[2,1],[2,2]] Prelude Control.Monad.List> runListT (ListT [[(),()]] >> (ListT [[()], [()]] >> ListT [[1],[2]])) [[1,1],[1,2],[1,1],[1,2],[2,1],[2,2],[2,1],[2,2],[1,1],[1,2],[1,1], [1,2],[2,1],[2,2],[2,1],[2,2]] From uhollerbach at gmail.com Mon Feb 11 12:55:06 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Mon Feb 11 12:53:48 2008 Subject: [Haskell-cafe] fast integer base-2 log function? In-Reply-To: <200802110744.10469.naur@post11.tele.dk> References: <20080211061619.IPFX5833.fep27.mail.dk@www.haskell.org> <200802110744.10469.naur@post11.tele.dk> Message-ID: <65d7a7e0802110955v7c2e9d74ibf02385712fab119@mail.gmail.com> Thanks, guys! It looks at first glance as if the code Thorkil posted is similar to mine (grow comparison number in steps of 2 in the exponent, then binary-search to get the exact exponent), while Stefan's version is more similar to the walk-the-list idea I had in mind. I'll play with both of these when I get a chance... Uwe On Feb 10, 2008 10:44 PM, Thorkil Naur wrote: > Hello, > > If the standard libraries provide such a function, I haven't found it. I > must > admit that I haven't studied your code in detail. I usually do as follows > for > integer logarithms, shamelessly stolen from the Haskell report: > > > -- Integer log base (c.f. Haskell report 14.4): > > > > imLog :: Integer->Integer->Integer > > imLog b x > > = if x < b then > > 0 > > else > > let > > l = 2 * imLog (b*b) x > > doDiv x l = if x < b then l else doDiv (x`div`b) (l+1) > > in > > doDiv (x`div`(b^l)) l > > Best regards > Thorkil > > > On Monday 11 February 2008 07:15, Uwe Hollerbach wrote: > > Hello, haskellers, > > > > Is there a fast integer base-2 log function anywhere in the standard > > libraries? I wandered through the index, but didn't find anything that > > looked right. I need something that's more robust than logBase, it > > needs to handle numbers with a few to many thousands of digits. I > > found a thread from a couple of years ago that suggested there was no > > such routine, and that simply doing "length (show n)" might be the > > best. That seems kind of... less than elegant. I've come up with a > > routine, shown below, that seems reasonably fast (a few seconds of CPU > > time for a million-bit number, likely adequate for my purposes), but > > it seems that something with privileged access to the innards of an > > Integer ought to be even much faster -- it's just a simple walk along > > a list (array?) after all. Any pointers? Thanks! > > > > Uwe > > > > > powi :: Integer -> Integer -> Integer > > > powi b e | e == 0 = 1 > > > | e < 0 = error "negative exponent in powi" > > > | even e = powi (b*b) (e `quot` 2) > > > | otherwise = b * (powi b (e - 1)) > > > > > ilog2 :: Integer -> Integer > > > ilog2 n | n < 0 = ilog2 (- n) > > > | n < 2 = 1 > > > | otherwise = up n (1 :: Integer) > > > where up n a = if n < (powi 2 a) > > > then bin (quot a 2) a > > > else up n (2*a) > > > bin lo hi = if (hi - lo) <= 1 > > > then hi > > > else let av = quot (lo + hi) 2 > > > in if n < (powi 2 av) > > > then bin lo av > > > else bin av hi > > > > (This was all properly aligned when I cut'n'pasted; proportional fonts > > might be messing it up here.) > > _______________________________________________ > > 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/20080211/90e9a04b/attachment.htm From gwern0 at gmail.com Mon Feb 11 12:55:04 2008 From: gwern0 at gmail.com (gwern0@gmail.com) Date: Mon Feb 11 12:54:13 2008 Subject: [Haskell-cafe] ANN: nano-hmac 0.2.0 In-Reply-To: <396556a20802110942g7e917b61o3f9a8a0d27823800@mail.gmail.com> References: <396556a20802110942g7e917b61o3f9a8a0d27823800@mail.gmail.com> Message-ID: <20080211175504.GA828831@localhost> On 2008.02.11 09:42:44 -0800, Adam Langley scribbled 0.5K characters: > On Feb 11, 2008 12:54 AM, Hitesh Jasani wrote: > > nano-hmac provides bindings to OpenSSL's HMAC interface. With this release the > > set of hashing functions supported is: MD5, SHA, SHA1, SHA224, SHA256, SHA384, > > SHA512. > > Just a heads up; PHO has written nice bindings to much of OpenSSL: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsOpenSSL-0.3.1 > > AGL > > -- > Adam Langley agl@imperialviolet.org Also, I recently uploaded hopenssl at . I don't know how it stacks up, but it was necessary to be able to 'cabal install postmaster' (which now works very nicely). -- gwern JD Yongyue SITOR t bemd Magdeyev 1911 ISS Gorizont Juiliett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080211/5fb56e2d/attachment.bin From dpiponi at gmail.com Mon Feb 11 13:09:39 2008 From: dpiponi at gmail.com (Dan Piponi) Date: Mon Feb 11 13:08:22 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: Message-ID: <625b74080802111009t26da64edt4fb70340f806a11c@mail.gmail.com> IOn Feb 11, 2008 9:46 AM, Miguel Mitrofanov wrote: > It's well known that "ListT m" monad violates this law in general > (though it satisfies it for some particular monads m). For example, I went through this example in quite a bit of detail a while ago and wrote it up here: http://sigfpe.blogspot.com/2006/11/why-isnt-listt-monad.html . I tried to show not just why the monad laws fails to hold for ListT [], but also show how it almost holds. -- Dan From alfonso.acosta at gmail.com Mon Feb 11 13:43:13 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Feb 11 13:41:59 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <20080210170841.GB14463@cs.cmu.edu> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802092014t66e01ea3uc18c451a6fef1f8d@mail.gmail.com> <200802101743.41443.g9ks157k@acme.softbase.org> <20080210170841.GB14463@cs.cmu.edu> Message-ID: <6a7c66fc0802111043i47c21f13lb2af1a61d2719fe1@mail.gmail.com> Hi Dan, On Feb 10, 2008 6:08 PM, Dan Licata wrote: > > > The ideal type for the function would be: > > > > > > vector :: [a] -> FSVec s a Well, I probably didn't express myself properly when writing "The ideal type", "the first type which comes to mind" would have been more accurate. Thanks for your explanation, which is actually much better than mine and, in fact, almost identical to the one included in http://ofb.net/~frederik/vectro/draft-r2.pdf From g9ks157k at acme.softbase.org Mon Feb 11 14:14:30 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 11 14:13:42 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802110917v4b34649dl62d843c925bfa16@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802101743.41443.g9ks157k@acme.softbase.org> <6a7c66fc0802110917v4b34649dl62d843c925bfa16@mail.gmail.com> Message-ID: <200802112014.31024.g9ks157k@acme.softbase.org> Am Montag, 11. Februar 2008 18:17 schrieben Sie: > [?] > As suggested by the pointer you provided, I redefined FSVec and tailV > using a transformating of Succ into a type synonym family (see the end > of this mail for its full definition) but it didn't help. Be careful! Type family support is still broken in GHC 6.8. And the whole type system machinery seemed to be rather broken when I last checked a then current development version (6.9). > data FSVec :: * -> * -> * where > NullV :: FSVec D0 a > (:>) :: FSVec s a -> FSVec (Succ s) a > > tailV :: FSVec s a -> FSVec (Succ s) a > tailV (x :> xs) = xs > > tailV leads to this error (which I don't really understand :S) > > GADT pattern match in non-rigid context for `:>' > Tell GHC HQ if you'd like this to unify the context > In the pattern: x :> xs > In the definition of `tailV': tailV (x :> xs) = xs I think, this can be solved with a type declaration. At least I heard about something like this. Probably googling for this error message will help. > My first impressions about using type synonym families (as opposed to > multiparameter type classes) to fake dependent types are: > > [?] I think, type synonym families are not a replacement for multiparameter classes but for functional dependencies. So you will still need multiparameter classes in certain places but you?ll be able to get rid of functional dependencies (except for certain cases where fundeps are combined with overlapping instances, at least). > - I'm maybe missing something, but it seems that type synonym > families don't work nicely with typeclass constraints. > > this is ilegal (syntax error): > > type family Nat x => Succ x :: * > > this is ilegal too (another syntax error): > > type instance Nat x => Succ (x :* D0) = x :* D1 Maybe you should put your type family synonym into a class where it becomes an associated type synonym: class Nat x where type Succ x :: * [?] > and finally I was really surprised to know that, using the type > synonym family this is illegal too! > > toInt (succRef d0) > > the expression above leads to the following error: > > No instance for (Data.TypeLevel.Num.Sets.NatI (Succ D0)) > > But .... Succ D0 = D1, and D1 and D1 _is_ an instance of NatI ! Maybe a bug. As I said, you cannot expect type families to work reliably at the moment. > [?] > > Some remark concerning spelling: Would it be possible to drop the V at > > the end of the function names? I think the fact that those functions are > > about "vectors" is better expressed by qualification: > > Right, do you think the same should be done for Data.TypeLeve.Num.Ops > ? (succRef, predRef, addRef, subRef and friends ...) Yes, I think so. > Best Regards, > > A really frustrated Fons :-( Best wishes, Wolfgang > [?] From g9ks157k at acme.softbase.org Mon Feb 11 14:24:29 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 11 14:23:32 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> Message-ID: <200802112024.29703.g9ks157k@acme.softbase.org> Am Montag, 11. Februar 2008 14:57 schrieb Michael Reid: > > Now it should be easier to see that this is simply associativity. It's > > easy enough to violate, if you want to - but I don't have any nice > > simple examples to hand. > > I have recently been reading a tutorial or paper where a Monad that > violated this law was presented. The authors shrugged it off as not > important, that the notation gained by implementing the operation as a > Monad was worth it, but what is not clear is what the consequences of > violating such > associativity are. > > Does violating this law introduce the potential that your program will not > do what you think it should? > > /mike. Other libraries might (and probably will) expect Monad instances to satisfy the monad laws and will not work as intended or even make sense if the monad laws aren?t satisfied. Sometimes it looks as if people think that monads are special in that they have to satisfy certain laws. But this isn?t the case. Practically every Haskell type class has some laws (informally) attached to it which instances should satisfy. For example, the following should hold for instances of the Ord class: a < b = compare a b = LT a == b = compare a b = EQ a > b = compare a b = GT a <= b = a < b || a == b a >= b = a > b || a == b a < b = b > a a < b && b < c => a < c If an Ord instances doesn?t obey these laws than it?s likely to make Set and Map behave strangely. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Mon Feb 11 14:30:59 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 11 14:30:08 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B06B3B.2070504@cs.tcd.ie> References: <47B06B3B.2070504@cs.tcd.ie> Message-ID: <200802112030.59581.g9ks157k@acme.softbase.org> Am Montag, 11. Februar 2008 16:35 schrieb Andrew Butterfield: > This is precisely Jerzy's point - you can have many mathematical laws as > you like but there is no guarantee that a programming languages > implementation will satisfy them. But people writing instances of type classes should take care of satisfying the laws since other libraries will most likely expect this. Best wishes, Wolfgang From westondan at imageworks.com Mon Feb 11 15:32:53 2008 From: westondan at imageworks.com (Dan Weston) Date: Mon Feb 11 15:32:33 2008 Subject: [Haskell-cafe] Create a list without duplicates from a list with duplicates In-Reply-To: References: <47ac4717.1dd.45e0.323007547@webmailh4.aruba.it> Message-ID: <47B0B0F5.9000500@imageworks.com> Of course the most *general* way requires an Eq constraint: > List.nub :: Eq a => [a] -> [a] But there are better functions (already mentioned) with the less general Ord constraint. Int and String are instances of Ord. "some other user defined data type" probably is too, but if you mean "any other user defined data type", even Eq may not be satisfied, e.g. > data NotEvenEq a = FuncsNotEq (a->a) The hammer you use depends on what you're hammering on. Dan Henning Thielemann wrote: > On Fri, 8 Feb 2008, news@lyra.net wrote: > >> Hallo! >> >> Let's suppose I have a list [a,b,c,d,c,d]. I'd like to write >> a function that returns a new list without duplicates (in >> the example [a,b,c,d]). How can I do that? What is the most >> general way? I'd like to use the same function for a list of >> Int or String or some other user defined data type. > > List.nub From isaacdupree at charter.net Mon Feb 11 15:44:46 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Feb 11 15:43:13 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802012232.16922.g9ks157k@acme.softbase.org> <6a7c66fc0802020554i5e96eb84n296e2df8bfec9f46@mail.gmail.com> <200802041236.55480.g9ks157k@acme.softbase.org> <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> Message-ID: <47B0B3BE.4010601@charter.net> Alfonso Acosta wrote: >> So type-level + parametrized-data is my vote. But don't let's spend too much >> time discussing the name. ;-) > > Fair enough. type-level + parameterized-data it is then (unless > someone else has a better suggestion). I'm going to begin coding now. hang on, "parametrized" or "parameterized"? -- both seem like plausible spellings, but there's an "e" different between what you two said! From vigalchin at gmail.com Mon Feb 11 16:28:18 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Mon Feb 11 16:27:00 2008 Subject: [Haskell-cafe] example packages that use Storable in Hackage ?? Message-ID: <5ae4f2ba0802111328i46753684w5086cfd5cbe2b982@mail.gmail.com> Hello, http://hackage.haskell.org/packages/archive/pkg-list.html .. what are some packages that use Storable? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080211/5c25c419/attachment.htm From dons at galois.com Mon Feb 11 16:29:24 2008 From: dons at galois.com (Don Stewart) Date: Mon Feb 11 16:28:08 2008 Subject: [Haskell-cafe] ANN: nano-hmac 0.2.0 In-Reply-To: References: Message-ID: <20080211212924.GB10466@scytale.galois.com> hitesh.jasani: > nano-hmac provides bindings to OpenSSL's HMAC interface. With this release the > set of hashing functions supported is: MD5, SHA, SHA1, SHA224, SHA256, SHA384, > SHA512. > > If you're unfamiliar with HMAC's then you may want to check out the second link > below where I explain a little bit about them in a blog entry. > > The hackage pages mentioned that they're not running haddock 2.0, so I don't > know if the docs will generate. If not, you can see the docs online at the > third link below. > > * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nano-hmac-0.2.0 > * http://www.jasani.org/2008/02/nano-hmac-020-released.html > * http://docs.jasani.org/nano-hmac/0.2.0/ > > Any and all comments/suggestions/criticisms/fortune-cookie-proverbs are welcome. > Shall we merge nano-md5 into this lib, and deprecate nano-md5 itself? Seems like a good time to consolidate, and produce a single openssl binding. -- Don From stefanor at cox.net Mon Feb 11 16:34:54 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Mon Feb 11 16:33:35 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> Message-ID: <20080211213454.GA3783@localhost.localdomain> On Mon, Feb 11, 2008 at 01:59:09PM +0000, Neil Mitchell wrote: > Hi > > > > (x >>= f) >>= g == x >>= (\v -> f v >>= g) > > > > Or stated another way: > > > > (x >>= f) >>= g == x >>= (f >>= g) > > Which is totally wrong, woops. > > See this page for lots of details about the Monad Laws and quite a > nice explanation of where you use them: > http://www.haskell.org/haskellwiki/Monad_Laws My favorite presentation of the monad laws is associativity of Kliesli composition: (a1 >=> a2) x = a1 x >>= a2 -- predefined in 6.8 control.monad -- The laws return >=> a = a a >=> return = a a >=> (b >=> c) = (a >=> b) >=> c 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/20080211/c7e25e76/attachment.bin From dbenbenn at gmail.com Mon Feb 11 16:35:34 2008 From: dbenbenn at gmail.com (David Benbennick) Date: Mon Feb 11 16:34:16 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <200802112024.29703.g9ks157k@acme.softbase.org> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <200802112024.29703.g9ks157k@acme.softbase.org> Message-ID: On Feb 11, 2008 11:24 AM, Wolfgang Jeltsch wrote: > a < b && b < c => a < c > > If an Ord instances doesn't obey these laws than it's likely to make Set and > Map behave strangely. Some months ago I pointed out that Ratio Int (which is an Ord instance) doesn't satisfy this property. I provided a patch to fix the problem, but my bug report was closed as wontfix: http://hackage.haskell.org/trac/ghc/ticket/1517. -- I'm doing Science and I'm still alive. From maciej.podgurski at googlemail.com Mon Feb 11 16:50:01 2008 From: maciej.podgurski at googlemail.com (Maciej Podgurski) Date: Mon Feb 11 16:46:42 2008 Subject: [Haskell-cafe] Parsec: Transforming between parsers with different token streams Message-ID: <47B0C309.4050807@googlemail.com> Hi, I'm writing a simple parser for a line-oriented language using Parsec. A group of lines is parsed by a parser that tokens are of type String. Each token is again parsed by a parser that tokens are of type Char (i.e. this parser has the Parsec type Parser a). Now I wrote a transforming function that converts a char parser to a line parser by running the char parser on the current token of the line parser and accepting the token, if the char parser did not fail: type LineParser = GenParser String () a toLineParser :: Parser a -> LineParser a toLineParser p = tokenPrim showLine nextPos testLine "how to get the inner error message???" where showLine l = "\": " ++ l ++ "\"" nextPos pos t rest = incSourceLine pos 1 testLine l = case parse p "" l of Left msg -> Nothing Right res -> Just res My problem is to extract the possible error message of the inner char parser (msg) and pass it to the outer line parser. Maybe using tokenPrim is no the best approach here. Someone how can help me with that problem? Besh wishes, Maciej From dbueno at gmail.com Mon Feb 11 17:03:55 2008 From: dbueno at gmail.com (Denis Bueno) Date: Mon Feb 11 17:02:38 2008 Subject: [Haskell-cafe] RFC: SAT solver using Cont/callCC for backtracking search Message-ID: <6dbd4d000802111403v6915791ale99851ffccab2b7c@mail.gmail.com> Hi all, I've recently done a small Haskell port of some OCaml code from a paper entitled "SAT-MICRO: petit mais costaud!" It's a tiny (one emacs buffer for the algorithm, ~160 lines overall) DPLL SAT solver with non-chronological backtracking, implemented using the Cont monad and callCC. If anyone has time and interest, I'm requesting comments on how the code could be improved in any way: style, efficiency, etc. The code in the paper is OCaml which uses exceptions as the main control-flow mechanism for backtracking. If you can read French, you may be interested in the paper, which is available here: http://hal.inria.fr/inria-00202831/en/ Of course, you will likely understand the OCaml code even if you don't understand French. Thanks in advance to anyone who comments. -- Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: ParseCnf.hs Type: application/octet-stream Size: 2268 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080211/6a18ee3c/ParseCnf.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: MicroSat.hs Type: application/octet-stream Size: 6674 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080211/6a18ee3c/MicroSat.obj From dons at galois.com Mon Feb 11 17:05:51 2008 From: dons at galois.com (Don Stewart) Date: Mon Feb 11 17:04:34 2008 Subject: [Haskell-cafe] RFC: SAT solver using Cont/callCC for backtracking search In-Reply-To: <6dbd4d000802111403v6915791ale99851ffccab2b7c@mail.gmail.com> References: <6dbd4d000802111403v6915791ale99851ffccab2b7c@mail.gmail.com> Message-ID: <20080211220551.GA10632@scytale.galois.com> dbueno: > Hi all, > > I've recently done a small Haskell port of some OCaml code from a > paper entitled "SAT-MICRO: petit mais costaud!" It's a tiny (one > emacs buffer for the algorithm, ~160 lines overall) DPLL SAT solver > with non-chronological backtracking, implemented using the Cont monad > and callCC. If anyone has time and interest, I'm requesting comments > on how the code could be improved in any way: style, efficiency, etc. > The code in the paper is OCaml which uses exceptions as the main > control-flow mechanism for backtracking. > > If you can read French, you may be interested in the paper, which is > available here: http://hal.inria.fr/inria-00202831/en/ > > Of course, you will likely understand the OCaml code even if you don't > understand French. > > Thanks in advance to anyone who comments. Have you thought about uploading it to hackage.haskell.org? We've got some similar stuff up there already, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sat-1.1.1 so feel free to upload this code! -- Don From dbueno at gmail.com Mon Feb 11 17:14:47 2008 From: dbueno at gmail.com (Denis Bueno) Date: Mon Feb 11 17:13:34 2008 Subject: [Haskell-cafe] RFC: SAT solver using Cont/callCC for backtracking search In-Reply-To: <20080211220551.GA10632@scytale.galois.com> References: <6dbd4d000802111403v6915791ale99851ffccab2b7c@mail.gmail.com> <20080211220551.GA10632@scytale.galois.com> Message-ID: <6dbd4d000802111414k5b4189ddhd8e8ee0c57f27c4f@mail.gmail.com> On Mon, Feb 11, 2008 at 5:05 PM, Don Stewart wrote: > Have you thought about uploading it to hackage.haskell.org? > We've got some similar stuff up there already, > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sat-1.1.1 > > so feel free to upload this code! Thanks. There's one more optimisation (clause learning) described in the paper that I intend to implement first. Then I'd like to upload it to hackage. If, after all that, I still feel adventurous, I may implement 2-watched literals. At that point it might actually be a competitive solver. But we'll see. -- Denis From nominolo at googlemail.com Mon Feb 11 17:44:10 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Mon Feb 11 17:42:57 2008 Subject: [Haskell-cafe] example packages that use Storable in Hackage ?? In-Reply-To: <5ae4f2ba0802111328i46753684w5086cfd5cbe2b982@mail.gmail.com> References: <5ae4f2ba0802111328i46753684w5086cfd5cbe2b982@mail.gmail.com> Message-ID: Hm, there used to be an experimental search tool that could find packages by which packages they depended on. I can't find it, though, so I assume it has been removed in the meantime. On 11 feb 2008, at 22.28, Galchin Vasili wrote: > Hello, > > http://hackage.haskell.org/packages/archive/pkg-list.html .. > what are some packages that use Storable? > > Regards, Vasili > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ben.franksen at online.de Mon Feb 11 18:38:02 2008 From: ben.franksen at online.de (Ben Franksen) Date: Mon Feb 11 18:39:58 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" References: <625b74080802111009t26da64edt4fb70340f806a11c@mail.gmail.com> Message-ID: Dan Piponi wrote: > IOn Feb 11, 2008 9:46 AM, Miguel Mitrofanov wrote: >> It's well known that "ListT m" monad violates this law in general >> (though it satisfies it for some particular monads m). For example, > > I went through this example in quite a bit of detail a while ago and > wrote it up here: > http://sigfpe.blogspot.com/2006/11/why-isnt-listt-monad.html . I tried > to show not just why the monad laws fails to hold for ListT [], but > also show how it almost holds. ...and the Unimo paper[1] explains how to easily write a 'correct' ListT. BTW, Unimo is an extreme case of the monad laws holding only w.r.t. the 'right' equality, i.e. in the laws m == m' is to be understood as observe_monad m == observe_monad m' (and even this '==' is of course /not/ the Eq class method but a semantic equality.) [1] http://web.cecs.pdx.edu/~cklin/papers/unimo-143.pdf Cheers Ben From ok at cs.otago.ac.nz Mon Feb 11 19:23:07 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon Feb 11 19:21:51 2008 Subject: [Haskell-cafe] Re: Datatypes - Haskell In-Reply-To: <42784f260802102017p34e97d41i89ad3e60fe37d385@mail.gmail.com> References: <3d96ac180802091652s1da0ae5as345fa3ec8afbc000@mail.gmail.com> <42784f260802102017p34e97d41i89ad3e60fe37d385@mail.gmail.com> Message-ID: On the subject of data types, I've recently seen Haskell code using data Foo ... = Foo { ... } where I would have used newtype instead of data. When is it a good idea to avoid newtype? From dons at galois.com Mon Feb 11 19:26:38 2008 From: dons at galois.com (Don Stewart) Date: Mon Feb 11 19:25:29 2008 Subject: [Haskell-cafe] Re: Datatypes - Haskell In-Reply-To: References: <3d96ac180802091652s1da0ae5as345fa3ec8afbc000@mail.gmail.com> <42784f260802102017p34e97d41i89ad3e60fe37d385@mail.gmail.com> Message-ID: <20080212002638.GE10632@scytale.galois.com> ok: > On the subject of data types, I've recently seen Haskell code using > data Foo ... = Foo { ... } > where I would have used newtype instead of data. When is it a good > idea to avoid newtype? It depends what's in the ... If its just something with the same representation as an existing type, using a newtype makes sense. If it builds a more complicated single-contructor type, such as many record types, then data is required. -- Don From ok at cs.otago.ac.nz Mon Feb 11 20:02:20 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon Feb 11 20:01:08 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B06B3B.2070504@cs.tcd.ie> References: <47B06B3B.2070504@cs.tcd.ie> Message-ID: <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> On 12 Feb 2008, at 4:35 am, Andrew Butterfield wrote: [floating point addition is not associative] And this is an excellent example of why violating expected laws is BAD. The failure of floating point addition to be associative means that there are umpteen ways of computing polynomials, for example, and doing it different ways will give you different answers. This is *not* a good way to write reliable software. I did enough Numerical Analysis papers in my pre- PhD years to get quite scared sometimes. Oh, here's a good one: dot1 [] [] = 0 dot1 (x:xs) (y:ys) = x*y + dots1 xs ys Obvious naive code for dot product. Switch over to tail recursion dot2 xs ys = aux xs ys 0 where aux [] [] s = s aux (x:xs) (y:ys) s = aux xs ys (s + x*y) The problem is that (a) in floating point arithmetic these two functions give DIFFERENT answers, and (b) NEITHER of them is wrong (arguably, neither of them is right either). For integers, of course, they must agree (if I haven't made any silly mistakes). This kind of thing makes it incredibly hard to think about numerical calculations. Basically, laws are stated so that implementors will make stuff that clients don't have to think about until their brains melt. From ok at cs.otago.ac.nz Mon Feb 11 20:21:05 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon Feb 11 20:19:47 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <200802112024.29703.g9ks157k@acme.softbase.org> Message-ID: On 12 Feb 2008, at 10:35 am, David Benbennick wrote: > Some months ago I pointed out that Ratio Int (which is an Ord > instance) doesn't satisfy this property. I provided a patch to fix > the problem, but my bug report was closed as wontfix: > http://hackage.haskell.org/trac/ghc/ticket/1517. I'm not happy about that response. Basically, if the inputs to a mathematical operation are representable, and the mathematically correct result is representable, I expect a system to deliver it or die trying. What the intermediate calculations get up to is the implementor's problem, not the user's. On the other hand, if I knew in advance whether a particular + or * was going to overflow, I probably wouldn't need the computer to actually do it. But if I give the computer some numbers that are clearly representable and just ask it to *sort* them, it had better d--- well get that RIGHT. I am extremely grateful for this report, because now I know "NEVER USE Ratio Int, it's too broken". Sad aside: back in the 70s I had my own Ratio Int written in Burroughs Algol. I was not smart enough to use double precision numbers for anything, but because of one hardware feature, it didn't matter a lot. That hardware feature was that integer overflows were TRAPPED and REPORTED. I have since used precisely one C compiler on precisely one Unix system that took advantage of the fact that the C standard (both C89 and C99) was very carefully written to ALLOW TRAPPING of signed integer overflows. (Contrary to mythology, C only requires wrapping for unsigned integers.) I found that a surprisingly valuable debugging aid. This all supports the general point, of course: data types whose operations are so implemented as to break sensible laws can and WILL land you in great piles of fresh steaming hot fertiliser. From agl at imperialviolet.org Mon Feb 11 21:27:47 2008 From: agl at imperialviolet.org (Adam Langley) Date: Mon Feb 11 21:26:28 2008 Subject: [Haskell-cafe] example packages that use Storable in Hackage ?? In-Reply-To: <5ae4f2ba0802111328i46753684w5086cfd5cbe2b982@mail.gmail.com> References: <5ae4f2ba0802111328i46753684w5086cfd5cbe2b982@mail.gmail.com> Message-ID: <396556a20802111827p64ac913fk7088d25a2167e4c3@mail.gmail.com> 2008/2/11 Galchin Vasili : > http://hackage.haskell.org/packages/archive/pkg-list.html .. what are > some packages that use Storable? binary and binary-strict at least. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From jerzy.karczmarczuk at info.unicaen.fr Mon Feb 11 23:14:37 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Mon Feb 11 23:13:18 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> Message-ID: Richard A. O'Keefe comments: > [floating point addition is not associative]] > > And this is an excellent example of why violating expected laws is BAD. > The failure of floating point addition to be associative means that there > are umpteen ways of computing polynomials, for example, and doing it > different ways will give you different answers. This is *not* a good > way to write reliable software. [Then we see the scalar product whose value *may* depend on the ev. order] I wonder... Would you say that *no* typical floating-point software is reliable? Jerzy Karczmarczuk From derek.a.elkins at gmail.com Mon Feb 11 22:38:15 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Feb 11 23:37:51 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <20080211213454.GA3783@localhost.localdomain> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <404396ef0802110559gea267b8q61646b85295ecfa9@mail.gmail.com> <20080211213454.GA3783@localhost.localdomain> Message-ID: <1202787495.5604.12.camel@derek-laptop> On Mon, 2008-02-11 at 13:34 -0800, Stefan O'Rear wrote: > On Mon, Feb 11, 2008 at 01:59:09PM +0000, Neil Mitchell wrote: > > Hi > > > > > > (x >>= f) >>= g == x >>= (\v -> f v >>= g) > > > > > > Or stated another way: > > > > > > (x >>= f) >>= g == x >>= (f >>= g) > > > > Which is totally wrong, woops. > > > > See this page for lots of details about the Monad Laws and quite a > > nice explanation of where you use them: > > http://www.haskell.org/haskellwiki/Monad_Laws > > My favorite presentation of the monad laws is associativity of Kliesli > composition: > > (a1 >=> a2) x = a1 x >>= a2 -- predefined in 6.8 control.monad > > -- The laws > > return >=> a = a > a >=> return = a > a >=> (b >=> c) = (a >=> b) >=> c Indeed. The monad laws are just that the Kleisli category is actually a category. From bjpop at csse.unimelb.edu.au Tue Feb 12 00:14:02 2008 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Tue Feb 12 00:06:57 2008 Subject: [Haskell-cafe] Announce: Melbourne Functional Programming Union Message-ID: <0AD13F6E-FED0-42DF-94A6-FFB9AAAABBF9@csse.unimelb.edu.au> Hello Haskellers, After a few years hiatus, I'm pleased to announce that the Melbourne Functional Programming Union (FPU) is back. What is the FPU? It is a group of people who are interested in all things functional programming. We hold regular informal talks, and have friendly discussions afterwards. We are situated at the University of Melbourne (Australia), but the Union is open to all comers. Obviously it helps if you live near this part of the World. To give you an idea of the kinds of things we talk about, here is a list of our most recent topics: - the GHCi debugger - Arrows for parser combinators - a curious stack overflow in Haskell - a demonstration of Coq - deriving monads from vague ideas in several easy steps (this coming Friday) Here is our old outdated web page for historical reference: http://www.cs.mu.oz.au/fpu/ A new page is under construction. At the moment, talks are held on Fridays, 1-2pm, in the ICT Building at Melbourne Uni. Contact Bernie Pope if you are interested in participating in the FPU. From uhollerbach at gmail.com Tue Feb 12 01:18:45 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Tue Feb 12 01:17:25 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <200802112024.29703.g9ks157k@acme.softbase.org> Message-ID: <65d7a7e0802112218s25d7b9ddpf6a262f62c2a2bd0@mail.gmail.com> Ratio Integer may possibly have the same trouble, or maybe something related. I was messing around with various operators on Rationals and found that positive and negative infinity don't compare right. Here's a small program which shows this; if I'm doing something wrong, I'd most appreciate it being pointed out to me. If I fire up ghci, import Data.Ratio and GHC.Real, and then ask about the type of "infinity", it tells me Rational, which as far as I can tell is Ratio Integer...? So far I have only found these wrong results when I compare the two infinities. Uwe > module Main where > import Prelude > import Data.Ratio > import GHC.Real > > pinf = infinity > ninf = -infinity > zero = 0 > > main = > do putStrLn ("pinf = " ++ (show pinf)) > putStrLn ("ninf = " ++ (show ninf)) > putStrLn ("zero = " ++ (show zero)) > putStrLn ("min pinf zero =\t" ++ (show (min pinf zero))) > putStrLn ("min ninf zero =\t" ++ (show (min ninf zero))) > putStrLn ("min ninf pinf =\t" ++ (show (min ninf pinf))) > putStrLn ("min pinf ninf =\t" ++ (show (min pinf ninf)) ++ "\twrong") > putStrLn ("max pinf zero =\t" ++ (show (max pinf zero))) > putStrLn ("max ninf zero =\t" ++ (show (max ninf zero))) > putStrLn ("max ninf pinf =\t" ++ (show (max ninf pinf))) > putStrLn ("max pinf ninf =\t" ++ (show (max pinf ninf)) ++ "\twrong") > putStrLn ("(<) pinf zero =\t" ++ (show ((<) pinf zero))) > putStrLn ("(<) ninf zero =\t" ++ (show ((<) ninf zero))) > putStrLn ("(<) ninf pinf =\t" ++ (show ((<) ninf pinf)) ++ "\twrong") > putStrLn ("(<) pinf ninf =\t" ++ (show ((<) pinf ninf))) > putStrLn ("(>) pinf zero =\t" ++ (show ((>) pinf zero))) > putStrLn ("(>) ninf zero =\t" ++ (show ((>) ninf zero))) > putStrLn ("(>) ninf pinf =\t" ++ (show ((>) ninf pinf))) > putStrLn ("(>) pinf ninf =\t" ++ (show ((>) pinf ninf)) ++ "\twrong") > putStrLn ("(<=) pinf zero =\t" ++ (show ((<=) pinf zero))) > putStrLn ("(<=) ninf zero =\t" ++ (show ((<=) ninf zero))) > putStrLn ("(<=) ninf pinf =\t" ++ (show ((<=) ninf pinf))) > putStrLn ("(<=) pinf ninf =\t" ++ (show ((<=) pinf ninf)) ++ "\twrong") > putStrLn ("(>=) pinf zero =\t" ++ (show ((>=) pinf zero))) > putStrLn ("(>=) ninf zero =\t" ++ (show ((>=) ninf zero))) > putStrLn ("(>=) ninf pinf =\t" ++ (show ((>=) ninf pinf))) > putStrLn ("(>=) pinf ninf =\t" ++ (show ((>=) pinf ninf)) ++ "\twrong") From dbenbenn at gmail.com Tue Feb 12 01:50:44 2008 From: dbenbenn at gmail.com (David Benbennick) Date: Tue Feb 12 01:49:24 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <65d7a7e0802112218s25d7b9ddpf6a262f62c2a2bd0@mail.gmail.com> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <200802112024.29703.g9ks157k@acme.softbase.org> <65d7a7e0802112218s25d7b9ddpf6a262f62c2a2bd0@mail.gmail.com> Message-ID: On Feb 11, 2008 10:18 PM, Uwe Hollerbach wrote: > If I fire up ghci, import > Data.Ratio and GHC.Real, and then ask about the type of "infinity", it > tells me Rational, which as far as I can tell is Ratio Integer...? Yes, Rational is Ratio Integer. It might not be a good idea to import GHC.Real, since it doesn't seem to be documented at http://www.haskell.org/ghc/docs/latest/html/libraries/. If you just import Data.Ratio, and define > pinf :: Integer > pinf = 1 % 0 > ninf :: Integer > ninf = (-1) % 0 Then things fail the way you expect (basically, Data.Ratio isn't written to support infinity). But it's really odd the way the infinity from GHC.Real works. Anyone have an explanation? -- I'm doing Science and I'm still alive. From hitesh.jasani at gmail.com Tue Feb 12 03:07:43 2008 From: hitesh.jasani at gmail.com (Hitesh Jasani) Date: Tue Feb 12 03:06:33 2008 Subject: [Haskell-cafe] Re: ANN: nano-hmac 0.2.0 References: <396556a20802110942g7e917b61o3f9a8a0d27823800@mail.gmail.com> Message-ID: Adam Langley imperialviolet.org> writes: > Just a heads up; PHO has written nice bindings to much of OpenSSL: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsOpenSSL-0.3.1 Thanks for pointing it out. It looks like PHO has done some good work there. - Hitesh From hitesh.jasani at gmail.com Tue Feb 12 03:10:59 2008 From: hitesh.jasani at gmail.com (Hitesh Jasani) Date: Tue Feb 12 03:13:45 2008 Subject: [Haskell-cafe] Re: ANN: nano-hmac 0.2.0 References: <20080211212924.GB10466@scytale.galois.com> Message-ID: Don Stewart galois.com> writes: > > Shall we merge nano-md5 into this lib, and deprecate nano-md5 itself? > Seems like a good time to consolidate, and produce a single openssl > binding. > It's tempting, but I would really hate to lose nano-md5 as it is today. I thought your concept was a great idea to inspire people to start small to get a feel for developing Haskell libraries. The current nano-md5 serves as a really good example. In the Ruby community there are many small libraries that do one, simple focused task. There are times when this is a virtue over libraries that try to be all encompassing. It's weird but I would have thought the Haskell community would have more embraced small libraries also since they may be more composable. - Hitesh From g9ks157k at acme.softbase.org Tue Feb 12 05:21:23 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 12 05:20:33 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (=?iso-8859-1?q?using=09datatype?= algebra?) In-Reply-To: <47B0B3BE.4010601@charter.net> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> <47B0B3BE.4010601@charter.net> Message-ID: <200802121121.23809.g9ks157k@acme.softbase.org> Am Montag, 11. Februar 2008 21:44 schrieben Sie: > Alfonso Acosta wrote: > >> So type-level + parametrized-data is my vote. But don't let's spend too > >> much time discussing the name. ;-) > > > > Fair enough. type-level + parameterized-data it is then (unless > > someone else has a better suggestion). I'm going to begin coding now. > > hang on, "parametrized" or "parameterized"? -- both seem like plausible > spellings, but there's an "e" different between what you two said! What spelling is more common? Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 12 05:22:38 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 12 05:21:33 2008 Subject: [Haskell-cafe] Haskell Weekly News - February 10, 2008 In-Reply-To: <20080211134401.GA18919@soi.city.ac.uk> References: <20080211010939.GB28106@scytale.galois.com> <200802111424.19285.g9ks157k@acme.softbase.org> <20080211134401.GA18919@soi.city.ac.uk> Message-ID: <200802121122.38745.g9ks157k@acme.softbase.org> Am Montag, 11. Februar 2008 14:44 schrieb Ross Paterson: > On Mon, Feb 11, 2008 at 02:24:19PM +0100, Wolfgang Jeltsch wrote: > > Am Montag, 11. Februar 2008 02:09 schrieb Don Stewart: > > > [?] > > > > > > * Imlib 0.1.1. Uploaded by Cale Gibbard. [120]Imlib: Added by > > > CaleGibbard, Sun Jan 13 22:26:59 PST 2008.. > > > > > > [?] > > > > > > * haddock 2.0.0.0. Uploaded by David Waern. [147]haddock: Added by > > > DavidWaern > > > > > > [?] > > > > What's the reason for these entries not having a sensible synopsis? > > Because the hackageDB RSS feed he's using doesn't include a synopsis, > for no particular reason. I don?t really understand this. I works with the other packages. Why not with the above ones? Best wishes, Wolfgang From gale at sefer.org Tue Feb 12 06:20:50 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Feb 12 06:19:29 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <200802112024.29703.g9ks157k@acme.softbase.org> Message-ID: <2608b8a80802120320q6b6a69ecjf433432ca9ddc841@mail.gmail.com> David Benbennick wrote: >> Some months ago I pointed out that Ratio Int (which is an Ord >> instance) doesn't satisfy this property. I provided a patch to fix >> the problem, but my bug report was closed as wontfix: >> http://hackage.haskell.org/trac/ghc/ticket/1517. Richard A. O'Keefe wrote: > I'm not happy about that response... > I am extremely grateful for this report, because now I know > "NEVER USE Ratio Int, it's too broken". Ian wrote, in the Trac ticket: > Thanks for the patch, but I see a couple of problems: > ...If you still think that this change should be made then > I think that it should go through the library submissions process: > http://www.haskell.org/haskellwiki/Library_submissions The "wontfix" resolution does not mean that the patch was rejected. It just means that there are reasons for and against it, so GHC HQ is not unilaterally implementing it without giving the community a chance to discuss the issues. I think that is an admirable attitude. If you feel that this issue is important, why not go ahead and start the process to get it adopted? Regards, Yitz From gale at sefer.org Tue Feb 12 06:32:32 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Feb 12 06:31:12 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> Message-ID: <2608b8a80802120332r5c0fe11bk3c6ab7d60a59641e@mail.gmail.com> Jerzy Karczmarczuk wrote: > Would you say that *no* typical floating-point software is reliable? It depends on how you define "reliable". Floating point intentionally trades accuracy for speed, leaving it to the user to worry about round-off errors. It is usually not too hard to get the probability of failure somewhat low in practice, if you don't require a proof. It used to be true - and may still be - that the engineers who implement floating point in the hardware of our CPUs would never fly on commercial airliners. Would you? Would you entrust your country's nuclear arsenal to an automated system that depends on floating point arithmetic? Regards, Yitz From gale at sefer.org Tue Feb 12 06:47:36 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Feb 12 06:46:16 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <625b74080802111009t26da64edt4fb70340f806a11c@mail.gmail.com> Message-ID: <2608b8a80802120347n3d777158x5cc16ea22515035b@mail.gmail.com> Ben Franksen wrote: > ...and the Unimo paper[1] explains how to easily write a 'correct' ListT. > BTW, Unimo is an extreme case of the monad laws holding only w.r.t. > the 'right' equality, i.e. in the laws m == m' is to be understood as > observe_monad m == observe_monad m' > (and even this '==' is of course /not/ the Eq class method but a semantic > equality.) > [1] http://web.cecs.pdx.edu/~cklin/papers/unimo-143.pdf Are you sure? Maybe I am missing something, but I don't see any claim that the Unimo ListT satisfies the laws any more than the old mtl ListT. It looks to me like Unimo is just an attempt to provide an easier way to create, use, and understand monads, not a change in their semantics. ListT-Done-Right could also be defined via the Unimo framework, and then it would satisfy the monad laws. Thanks, Yitz From jerzy.karczmarczuk at info.unicaen.fr Tue Feb 12 06:58:02 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Tue Feb 12 06:56:41 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <2608b8a80802120332r5c0fe11bk3c6ab7d60a59641e@mail.gmail.com> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <2608b8a80802120332r5c0fe11bk3c6ab7d60a59641e@mail.gmail.com> Message-ID: Yitzchak Gale writes: > Jerzy Karczmarczuk wrote: >> Would you say that *no* typical floating-point software is reliable? > > It depends on how you define "reliable". > > Floating point intentionally trades accuracy for speed, ... > It used to be true - and may still be - that the engineers > who implement floating point in the hardware of our > CPUs would never fly on commercial airliners. Would you? > > Would you entrust your country's nuclear arsenal to an > automated system that depends on floating point arithmetic? 1. This is not a possible "trade-off" or not. In scientific/engineering computation there is really no choice, since you have to compute logarithms, trigonometric functions, etc., and some inaccuracy is unavoidable. Of course, one may use intervals, and other extremely costly stuff, but if the stability of the algorithms is well controlled, and in normal case it is (especially if the basic arithmetics has some extra control bits to do the rounding), th issue is far from being mortal. 2. The story about engineering not flying commercial planes is largely anecdotical, and you know that. Repeating it here doesn't change much. 3. Nuclear arsenal is never really "entrusted to an automated system", because of reasons much beyond the fl.point inaccuracies. On the other hand, in all those software one has to deal with probabilities, and with imprecise experimental data, so even if for God knows which purpose everything used exact algebraic numbers, or controlled transcendental extensions, the input imprecision would kill all the sense of infinitely precise computations thereupon. 4. The non-reliability of engineering software has many more important reasons, sometimes incredibly stupid, such as the confusion between metric and English units in the Mars Climate Orbiter crash... The Ariane 5 crash was the result not of the floating-point computation but of the conversion to signed 16-bit numers (from a 64bit double). 5. Of course, in the original posting case, the underlying math/logic is discrete, and has no similar inaccuracies, so the two worlds should not be confounded... Here, if some laws get broken, it is the result of bad conventions, which usually can be easily avoided. Jerzy Karczmarczuk From gale at sefer.org Tue Feb 12 07:33:35 2008 From: gale at sefer.org (Yitzchak Gale) Date: Tue Feb 12 07:32:16 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <2608b8a80802120332r5c0fe11bk3c6ab7d60a59641e@mail.gmail.com> Message-ID: <2608b8a80802120433g348f1b98ub1101764c7557c1f@mail.gmail.com> I wrote: >> Floating point intentionally trades accuracy for speed, Jerzy Karczmarczuk wrote: > 1. This is not a possible "trade-off" or not. In scientific/engineering > computation there is really no choice, since you have to compute > logarithms, trigonometric functions, etc., and some inaccuracy is > unavoidable. Of course, one may use intervals, and other extremely > costly stuff, but if the stability of the algorithms is well controlled, > and in normal case it is (especially if the basic arithmetics has some > extra control bits to do the rounding), th issue is far from being > mortal. Agreed. That is what I meant by "trade-off". And I am not trying to say at all that it is wrong to use it. Life is full of trade-offs. >> It used to be true - and may still be - that the engineers >> who implement floating point in the hardware of our >> CPUs would never fly on commercial airliners. Would you? > 2. The story about engineering not flying commercial planes is largely > anecdotical, and you know that. Repeating it here doesn't change much. I heard it from someone who personally worked with one such team of engineers about ten years ago. >> Would you entrust your country's nuclear arsenal to an >> automated system that depends on floating point arithmetic? > 3. Nuclear arsenal is never really "entrusted to an automated system", > because of reasons much beyond the fl.point inaccuracies. Yes, of course, no one is really that stupid. Are they? > On the other hand, in all those software one has to deal with > probabilities, and with imprecise experimental data, so even if for God > knows which purpose everything used exact algebraic numbers, or > controlled transcendental extensions, the input imprecision would kill > all the sense of infinitely precise computations thereupon. > 4. The non-reliability of engineering software has many more important > reasons, sometimes incredibly stupid, such as the confusion between > metric and English units in the Mars Climate Orbiter crash... > The Ariane 5 crash was the result not of the floating-point computation > but of the conversion to signed 16-bit numers (from a 64bit double). Yes, high reliability is very hard. There are many factors that make it hard; floating point is undeniably one of them. Again - that doesn't mean that floating point should not be used. It is a powerful and important tool, as you say. I was once part of a software project in which people's lives might depend on there not being any bugs in my code. It was an experience that changed my life forever, and that is probably one of the factors that contributes to my interest in Haskell. Regards, Yitz From jmaessen at alum.mit.edu Tue Feb 12 09:12:40 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Tue Feb 12 09:11:30 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <200802112024.29703.g9ks157k@acme.softbase.org> <65d7a7e0802112218s25d7b9ddpf6a262f62c2a2bd0@mail.gmail.com> Message-ID: On Feb 12, 2008, at 1:50 AM, David Benbennick wrote: > On Feb 11, 2008 10:18 PM, Uwe Hollerbach > wrote: >> If I fire up ghci, import >> Data.Ratio and GHC.Real, and then ask about the type of "infinity", >> it >> tells me Rational, which as far as I can tell is Ratio Integer...? > > Yes, Rational is Ratio Integer. It might not be a good idea to import > GHC.Real, since it doesn't seem to be documented at > http://www.haskell.org/ghc/docs/latest/html/libraries/. If you just > import Data.Ratio, and define > >> pinf :: Integer >> pinf = 1 % 0 > >> ninf :: Integer >> ninf = (-1) % 0 > > Then things fail the way you expect (basically, Data.Ratio isn't > written to support infinity). But it's really odd the way the > infinity from GHC.Real works. Anyone have an explanation? An educated guess here: the value in GHC.Real is designed to permit fromRational to yield the appropriate high-precision floating value for infinity (exploiting IEEE arithmetic in a simple, easily- understood way). If I'm right, it probably wasn't intended to be used as a Rational at all, nor to be exploited by user code. -Jan-Willem Maessen From apfelmus at quantentunnel.de Tue Feb 12 09:56:53 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Tue Feb 12 09:55:49 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <2608b8a80802120347n3d777158x5cc16ea22515035b@mail.gmail.com> References: <625b74080802111009t26da64edt4fb70340f806a11c@mail.gmail.com> <2608b8a80802120347n3d777158x5cc16ea22515035b@mail.gmail.com> Message-ID: Yitzchak Gale wrote: > Ben Franksen wrote: >> ...and the Unimo paper[1] explains how to easily write a 'correct' ListT. > > Are you sure? Maybe I am missing something, but I don't > see any claim that the Unimo ListT satisfies the laws any > more than the old mtl ListT. > ListT-Done-Right could also be defined via the Unimo > framework, and then it would satisfy the monad laws. The list monad transformer implemented with Unimo (figure 13) is different from ListT m a = m [a] (figure 11 for reference). Note that I say "the list monad transformer". I don't understand what's so special about "ListT m does not fulfill the monad laws", it just shows that na?vely using m [a] to implement the list monad transformer is incorrect for general m . In other words, there is a big bug in Control.Monad.List and that's all there is to it. Regards, apfelmus From jon.fairbairn at cl.cam.ac.uk Tue Feb 12 10:15:07 2008 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Feb 12 10:13:55 2008 Subject: [Haskell-cafe] Re: Datatypes - Haskell References: <3d96ac180802091652s1da0ae5as345fa3ec8afbc000@mail.gmail.com> <42784f260802102017p34e97d41i89ad3e60fe37d385@mail.gmail.com> Message-ID: "Richard A. O'Keefe" writes: > On the subject of data types, I've recently seen Haskell code using > data Foo ... = Foo { ... } > where I would have used newtype instead of data. When is it a good > idea to avoid newtype? When the code was written before newtype was introduced into the language? Also when { ... } is not a single type. -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From magnus at therning.org Tue Feb 12 11:41:07 2008 From: magnus at therning.org (Magnus Therning) Date: Tue Feb 12 11:39:47 2008 Subject: [Haskell-cafe] Windows, or GHC? Message-ID: The following code will on Linux print three strings each followed by a NULL byte: module Main where putStr0 = putStr $ s ++ "\0" main = do putStr0 "Hello" putStr0 "Hello" putStr0 "Hello" On Windows however it will print nothing! In order to trigger printing I have to change the definition of putStr0 to putStr0 = putStr (s ++ "\0") >> hFlush stdout Is this difference in behaviour due to a bug in GHC on Windows or just a quirkiness of the platform? /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080212/9f601b70/attachment.htm From jwlato at gmail.com Tue Feb 12 13:28:22 2008 From: jwlato at gmail.com (John Lato) Date: Tue Feb 12 13:27:01 2008 Subject: [Haskell-cafe] question about STM and IO Message-ID: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> Hello, I was recently looking at the STM library, and I have a question about the function "unsafeIOToSTM". Can anyone explain to me what is unsafe about it, and what sort of use would be considered "safe"? Thanks, John From lrpalmer at gmail.com Tue Feb 12 13:33:45 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Feb 12 13:32:23 2008 Subject: [Haskell-cafe] question about STM and IO In-Reply-To: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> References: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> Message-ID: <7ca3f0160802121033m65899521xfd6efbef0c261a45@mail.gmail.com> On Feb 12, 2008 6:28 PM, John Lato wrote: > Hello, > > I was recently looking at the STM library, and I have a question about > the function "unsafeIOToSTM". Can anyone explain to me what is unsafe > about it, and what sort of use would be considered "safe"? A few things. First, this will crash: > atomically $ unsafeIOToStm $ atomically $ return () The implementation requires that transactions must not be nested, and this function allows you to nest transactions. Also, it's unclear what "retry" means in the context of arbitrary IO actions. A memory transaction is really only defined for exactly that: memory stuff. When you start talking about user I/O, network, etc. the transactional idea breaks down. So mostly the way I think of it is that it's semantically nonsense. Luke From stephan.friedrichs at tu-bs.de Tue Feb 12 13:41:45 2008 From: stephan.friedrichs at tu-bs.de (Stephan Friedrichs) Date: Tue Feb 12 13:40:37 2008 Subject: [Haskell-cafe] question about STM and IO In-Reply-To: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> References: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> Message-ID: <47B1E869.2040806@tu-bs.de> Hello, John Lato wrote: > I was recently looking at the STM library, and I have a question about > the function "unsafeIOToSTM". Can anyone explain to me what is unsafe > about it, and what sort of use would be considered "safe"? it's unsafe to perform IO inside of a transaction as it can't be undone, when rolling it back. I guess, unsafeIOToSTM has been designed in order to allow us to inject debugging output into a transaction, but you really shouldn't use it to perform "real" IO (like writing files, etc.). HTH - Stephan -- Fr?her hie? es ja: Ich denke, also bin ich. Heute wei? man: Es geht auch so. - Dieter Nuhr -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080212/4f4c403e/signature.bin From uhollerbach at gmail.com Tue Feb 12 13:43:19 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Tue Feb 12 13:41:58 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <200802112024.29703.g9ks157k@acme.softbase.org> <65d7a7e0802112218s25d7b9ddpf6a262f62c2a2bd0@mail.gmail.com> Message-ID: <65d7a7e0802121043k4768e606r5a169d039436fcaf@mail.gmail.com> On Feb 12, 2008 6:12 AM, Jan-Willem Maessen wrote: > > On Feb 12, 2008, at 1:50 AM, David Benbennick wrote: > > > On Feb 11, 2008 10:18 PM, Uwe Hollerbach > > wrote: > >> If I fire up ghci, import > >> Data.Ratio and GHC.Real, and then ask about the type of "infinity", > >> it > >> tells me Rational, which as far as I can tell is Ratio Integer...? > > > > Yes, Rational is Ratio Integer. It might not be a good idea to import > > GHC.Real, since it doesn't seem to be documented at > > http://www.haskell.org/ghc/docs/latest/html/libraries/. If you just > > import Data.Ratio, and define > > > >> pinf :: Integer > >> pinf = 1 % 0 > > > >> ninf :: Integer > >> ninf = (-1) % 0 > > > > Then things fail the way you expect (basically, Data.Ratio isn't > > written to support infinity). But it's really odd the way the > > infinity from GHC.Real works. Anyone have an explanation? > > An educated guess here: the value in GHC.Real is designed to permit > fromRational to yield the appropriate high-precision floating value > for infinity (exploiting IEEE arithmetic in a simple, easily- > understood way). If I'm right, it probably wasn't intended to be used > as a Rational at all, nor to be exploited by user code. > > -Jan-Willem Maessen > > Well... I dunno. Looking at the source to GHC.Real, I see infinity, notANumber :: Rationalinfinity = 1 :% 0notANumber = 0 :% 0 This is actually the reason I imported GHC.Real, because just plain % normalizes the rational number it creates, and that barfs very quickly when the denominator is 0. But the values themselves look perfectly reasonable... no? Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080212/24c6d037/attachment.htm From lrpalmer at gmail.com Tue Feb 12 13:49:53 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Feb 12 13:48:35 2008 Subject: [Haskell-cafe] A question about "monad laws" In-Reply-To: <65d7a7e0802121043k4768e606r5a169d039436fcaf@mail.gmail.com> References: <404396ef0802110538q15db024cj2291edc87b873249@mail.gmail.com> <200802112024.29703.g9ks157k@acme.softbase.org> <65d7a7e0802112218s25d7b9ddpf6a262f62c2a2bd0@mail.gmail.com> <65d7a7e0802121043k4768e606r5a169d039436fcaf@mail.gmail.com> Message-ID: <7ca3f0160802121049u125028fdqc94bbd14eadf79f4@mail.gmail.com> 2008/2/12 Uwe Hollerbach : > Well... I dunno. Looking at the source to GHC.Real, I see > > infinity, notANumber :: Rational > infinity = 1 :% 0 > notANumber = 0 :% 0 > > This is actually the reason I imported GHC.Real, because just plain % > normalizes the rational number it creates, and that barfs very quickly when > the denominator is 0. But the values themselves look perfectly reasonable... > no? Ummm... I'm going to have to go with no. In particular we can't have signed infinity represented like this and maintain reasonable numeric laws: 1/0 = 1/(-0) = (-1)/0 Rationals are defined not to have a zero denomiator, so I'll bet in more than one place in Data.Ratio that assumption is made. Luke From jwlato at gmail.com Tue Feb 12 13:55:15 2008 From: jwlato at gmail.com (John Lato) Date: Tue Feb 12 13:53:55 2008 Subject: [Haskell-cafe] question about STM and IO In-Reply-To: <47B1E869.2040806@tu-bs.de> References: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> <47B1E869.2040806@tu-bs.de> Message-ID: <9979e72e0802121055r7443d284ib2acf8e0bd570d3b@mail.gmail.com> Thanks. Both this answer and Luke's make perfect sense. John On Feb 12, 2008 12:41 PM, Stephan Friedrichs wrote: > Hello, > > > John Lato wrote: > > I was recently looking at the STM library, and I have a question about > > the function "unsafeIOToSTM". Can anyone explain to me what is unsafe > > about it, and what sort of use would be considered "safe"? > > it's unsafe to perform IO inside of a transaction as it can't be undone, > when rolling it back. I guess, unsafeIOToSTM has been designed in order > to allow us to inject debugging output into a transaction, but you > really shouldn't use it to perform "real" IO (like writing files, etc.). > > HTH - Stephan > > -- > > Fr?her hie? es ja: Ich denke, also bin ich. > Heute wei? man: Es geht auch so. > > - Dieter Nuhr > > From dons at galois.com Tue Feb 12 14:03:42 2008 From: dons at galois.com (Don Stewart) Date: Tue Feb 12 14:02:31 2008 Subject: [Haskell-cafe] ANN: nano-hmac 0.2.0 In-Reply-To: <88a582380802120002u55866b98h20892808aa5e7af4@mail.gmail.com> References: <20080211212924.GB10466@scytale.galois.com> <88a582380802120002u55866b98h20892808aa5e7af4@mail.gmail.com> Message-ID: <20080212190342.GA26504@scytale.galois.com> Ok, I'll leave it up there as a separate package then. :) -- Don hitesh.jasani: > Don, > > It's tempting, but I would really hate to lose nano-md5 as it is > today. I thought your concept was a great idea to inspire people to > start small to get a feel for developing Haskell libraries. The > current nano-md5 serves as a really good example. > > In the Ruby community there are many small libraries that do one, > simple focused task. There are times when this is a virtue over > libraries that try to be all encompassing. It's weird but I would > have thought the Haskell community would have more embraced small > libraries also since they may be more composable. > > - Hitesh > > > On Feb 11, 2008 4:29 PM, Don Stewart wrote: > > hitesh.jasani: > > > nano-hmac provides bindings to OpenSSL's HMAC interface. With this release the > > > set of hashing functions supported is: MD5, SHA, SHA1, SHA224, SHA256, SHA384, > > > SHA512. > > > > > > If you're unfamiliar with HMAC's then you may want to check out the second link > > > below where I explain a little bit about them in a blog entry. > > > > > > The hackage pages mentioned that they're not running haddock 2.0, so I don't > > > know if the docs will generate. If not, you can see the docs online at the > > > third link below. > > > > > > * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nano-hmac-0.2.0 > > > * http://www.jasani.org/2008/02/nano-hmac-020-released.html > > > * http://docs.jasani.org/nano-hmac/0.2.0/ > > > > > > Any and all comments/suggestions/criticisms/fortune-cookie-proverbs are welcome. > > > > > > > Shall we merge nano-md5 into this lib, and deprecate nano-md5 itself? > > Seems like a good time to consolidate, and produce a single openssl > > binding. > > > > -- Don > > From svein.ove at aas.no Tue Feb 12 14:11:24 2008 From: svein.ove at aas.no (Svein Ove Aas) Date: Tue Feb 12 14:10:02 2008 Subject: [Haskell-cafe] Windows, or GHC? In-Reply-To: References: Message-ID: <221b53ab0802121111y71028558gf8e512be3a7ab31a@mail.gmail.com> 2008/2/12 Magnus Therning : > The following code will on Linux print three strings each followed by a NULL > byte: > > module Main where > > putStr0 = putStr $ s ++ "\0" > > main = do > putStr0 "Hello" > putStr0 "Hello" > putStr0 "Hello" > > On Windows however it will print nothing! In order to trigger printing I > have to change the definition of putStr0 to > > putStr0 = putStr (s ++ "\0") >> hFlush stdout > > Is this difference in behaviour due to a bug in GHC on Windows or just a > quirkiness of the platform? > I can't directly answer, but a way to find out would be to try the same thing in C. It seems to me that, while Linux implicitly flushes streams on exit, Windows is failing to do so. So try the same output in C, with and without fflush, and.. you'll see. A program to do this follows for your convenience. ---- #include int main() { int i; for (int i=0; i<3; i++) puts("Hello\0"); //fflush(stdout); return 0; } From vigalchin at gmail.com Tue Feb 12 14:24:41 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Tue Feb 12 14:23:20 2008 Subject: [Haskell-cafe] Foreign.C.Types question ... Message-ID: <5ae4f2ba0802121124maf7540se47451eeb8ec8a45@mail.gmail.com> Hello, http://cvs.haskell.org/Hugs/pages/libraries/base/Foreign-C-Types.html .. I want to look at the actual code for these C types so that I can see how the instances of Storable for each type are coded so e.g. I can see how sizeOf/allignment are coded. Thanks, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080212/44078de6/attachment.htm From allbery at ece.cmu.edu Tue Feb 12 15:06:34 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue Feb 12 15:05:13 2008 Subject: [Haskell-cafe] Foreign.C.Types question ... In-Reply-To: <5ae4f2ba0802121124maf7540se47451eeb8ec8a45@mail.gmail.com> References: <5ae4f2ba0802121124maf7540se47451eeb8ec8a45@mail.gmail.com> Message-ID: <223B481B-942E-4A22-B7D3-6119317FCFB3@ece.cmu.edu> On Feb 12, 2008, at 14:24 , Galchin Vasili wrote: > http://cvs.haskell.org/Hugs/pages/libraries/base/Foreign-C- > Types.html .. I want to look at the actual code for these C types > so that I can see how the instances of Storable for each type are > coded so e.g. I can see how sizeOf/allignment are coded. I followed links from http://haskell.org to find the Hugs development wiki ( http://hackage.haskell.org/trac/hugs ) and found a "browse source code" link: http://darcs.haskell.org/darcsweb/darcsweb.cgi? r=hugs98;a=summary The bad news is that this returns a (very pretty...) Python error. Eep? -- 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 alfonso.acosta at gmail.com Tue Feb 12 15:32:20 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Feb 12 15:31:02 2008 Subject: [Haskell-cafe] Haddock documentation of Data.Array.* is confusing Message-ID: <6a7c66fc0802121232x1f114055g3db24c95c27dc4c5@mail.gmail.com> Hi, Excuse me for the subject, but IMHO is absolutely true. Anyhow, the purpose of this message is not merely to rant about it (which I know doesn't help) but to illustrate the possible impression of a Haskell newcomers. It's been a long long time since I last used arrays in Haskell (lists are normally just fine for me) so I checked the docs to refresh my memory. This is the result of my experience: The first thing I checked was Data.Array which ... just shows function names without signatures! OK, I followed the advice shown in "Data.Array" and tried to understand the more generic interface of Data.IArray. Fine, the documentation is much better, however it mentions Data.Array.Base, whose documentation link is missing :S I was suprised to see that even if all the functions of Data.IArray (i.e. array, listArray ... ) are perfectly sensible and generic (which is nice), they are not part of ot the IArray multiparameter class. So I wondered .. how can someone add its own implementation of inmutable arrays to the IArray interface? It was obvious that "bounds" (the only method of the IArray typeclass) was not going to enough, but I tried anyway with a naive example. {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses #-} data Ix i => LArray i e = LArray [e] (i,i) instance IArray LArray e where -- bounds :: (Ix i, IArray LArray e) => LArray i e -> (i,i) bounds (LArray _ b) = b GHC warned me about missing definitions for some"unsafe" methods of ArrayI which .... as expected, belong to the "phantom" Data.Array.Base module. The sources of Data.Array.Base revealed that the purpose of hiding them was to protect the user. Someone who wants add an array implementation to the IArray interface should use Data.Array.Base but why would it hurt to add a note in IArray mentioning it? and Why is Data.Array.Base hidden for Haddock (especially when there are some broken links pointing to it)? Cheers, Fons From joseph.bruce at pnl.gov Tue Feb 12 17:16:43 2008 From: joseph.bruce at pnl.gov (Joe) Date: Tue Feb 12 17:18:43 2008 Subject: [Haskell-cafe] Re: Export Haskell Libraries References: <9972866.post@talk.nabble.com> <1176443837.7971.29.camel@localhost> <9973642.post@talk.nabble.com> Message-ID: SevenThunders wrote: > ... Really > all that's needed though is a tool that can automagically wrap a homegrown > static or even dynamic library that contains the needed components of the > GHC run time library along with the additional user code. I know all the > object files are available as are of course the libraries themselves, so > such a script is not impossible. It seems that ghc itself is doing some > kind of dependency analysis to determine the final call to gcc. To which Duncan replied: > Yes, ghc knows which packages are required and the description for each > package lists the packages it depends on and any C libs and other linker > flags and search paths it needs. Automated sounds great. Has anything been done in this regard? I'm new to Haskell and to GHC in particular; how difficult is this? Where would I start in coding it myself (it seems as though I would need some inside knowledge into the workings of GHC)? Otherwise I'll try to make SevenThunders' approach work. Did you have success with the HS*.o files? Many thanks, Joe From zunino at di.unipi.it Tue Feb 12 19:10:11 2008 From: zunino at di.unipi.it (Roberto Zunino) Date: Tue Feb 12 19:29:36 2008 Subject: [Haskell-cafe] Windows, or GHC? In-Reply-To: <221b53ab0802121111y71028558gf8e512be3a7ab31a@mail.gmail.com> References: <221b53ab0802121111y71028558gf8e512be3a7ab31a@mail.gmail.com> Message-ID: <47B23563.5060506@di.unipi.it> Svein Ove Aas wrote: > A program to do this follows for your convenience. > > ---- > #include > > int main() { > int i; > for (int i=0; i<3; i++) > puts("Hello\0"); This will have the same effect as puts("Hello"). Maybe putchar(0) will actually output the NUL. Zun. From ndmitchell at gmail.com Tue Feb 12 20:34:11 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Feb 12 20:32:47 2008 Subject: [Haskell-cafe] Windows, or GHC? In-Reply-To: References: Message-ID: <404396ef0802121734r3387a101g4abac65e84c338a2@mail.gmail.com> Hi > The following code will on Linux print three strings each followed by a NULL > byte: > > module Main where > > putStr0 = putStr $ s ++ "\0" > > main = do > putStr0 "Hello" > putStr0 "Hello" > putStr0 "Hello" > > On Windows however it will print nothing! You missed out an s in putStr0, which causes it not to compile. When I add the s, and try on Windows XP with GHC 6.8.1 it works perfectly and prints 3 strings with null bytes. Can you still replicate this? If so, what specific details. Thanks Neil From jeremy.shaw at linspireinc.com Tue Feb 12 23:38:22 2008 From: jeremy.shaw at linspireinc.com (Jeremy Shaw) Date: Tue Feb 12 23:37:57 2008 Subject: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems Message-ID: <63wta2td.wl%jeremy.shaw@linspireinc.com> Hello, I get funny results when I call getSymbolicLinkStatus in ghc 6.8.2 on Ubuntu 7.10. This happens on several systems and has been confirmed by other people. Though, some people on almost the exact same system claimed to not see it at all. Here is an interactive example with ghci, note how the result changes from run to run. (Although not shown below, the values do sometimes repeat, so it is not completely random): Prelude> System.Posix.Files.getSymbolicLinkStatus "/etc/motd" >>= print . System.Posix.Files.fileID 13165085651657739420 Prelude> System.Posix.Files.getSymbolicLinkStatus "/etc/motd" >>= print . System.Posix.Files.fileID 13165312309966851228 Prelude> System.Posix.Files.getSymbolicLinkStatus "/etc/motd" >>= print . System.Posix.Files.fileID 623410571888290073 Prelude> System.Posix.Files.getSymbolicLinkStatus "/etc/motd" >>= print . System.Posix.Files.fileID 12892261005034 If I *compile* the following (with or without optimization): module Main where import System.Posix.Files main = do getSymbolicLinkStatus "/etc/motd" >>= print . fileID getSymbolicLinkStatus "/etc/motd" >>= print . fileID getSymbolicLinkStatus "/etc/motd" >>= print . fileID getSymbolicLinkStatus "/etc/motd" >>= print . fileID Then I get all 0: /tmp # ./test 0 0 0 0 I have tested the same code under GHC 6.6 and 6.4 and it works fine. Additionally, getFileStatus, seems to work fine everytime. (Unfortunately, I really need getSymbolicLinkStatus). If anyone has a work-around or fix that I can use in the next 15 hours, that would be extremely useful ;) Thanks in advance! j. From agl at imperialviolet.org Wed Feb 13 01:44:17 2008 From: agl at imperialviolet.org (Adam Langley) Date: Wed Feb 13 01:42:53 2008 Subject: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems In-Reply-To: <63wta2td.wl%jeremy.shaw@linspireinc.com> References: <63wta2td.wl%jeremy.shaw@linspireinc.com> Message-ID: <396556a20802122244l731dd84eob8e4781dddabfef9@mail.gmail.com> On Feb 12, 2008 8:38 PM, Jeremy Shaw wrote: > I get funny results when I call getSymbolicLinkStatus in ghc 6.8.2 on > Ubuntu 7.10. This happens on several systems and has been confirmed by > other people. Currently I'm looking at hsc2hs for this bug. On a 32 bit box here: int main() { struct stat st; printf("size of structure is %d\n", sizeof(st)); printf("inode is at offset %d\n", __builtin_offsetof(struct stat, st_ino)); } Gives: size of structure is 88 inode is at offset 12 However, building Files.hsc gives: fileID (FileStatus stat) = unsafePerformIO $ withForeignPtr stat $ ((\hsc_ptr -> peekByteOff hsc_ptr 88)) {-# LINE 315 "Files.hsc" #-} e.g. it's reading random memory at the end of the structure. Looking at the code from the documentation: http://haskell.org/ghc/docs/latest/html/libraries/unix/src/System-Posix-Files.html#fileID fileID (FileStatus stat) = unsafePerformIO $ withForeignPtr stat $ ((\hsc_ptr -> peekByteOff hsc_ptr 8)) {-# LINE 315 "System/Posix/Files.hsc" #-} Seems like it might work, but that offset is too small. It appears that it might be a 64-bit build (because the size of the stat structure which when it gets malloced is 144), but a 64-bit build should have larger offsets, not smaller. You can't write your own fileID function, because FileStatus isn't exported from Posix.Files. You can, however, write getSymbolicLinkInode a c function (which does both the lstat and extraction from the structure) and FFI it. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From agl at imperialviolet.org Wed Feb 13 02:04:40 2008 From: agl at imperialviolet.org (Adam Langley) Date: Wed Feb 13 02:03:16 2008 Subject: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems In-Reply-To: <396556a20802122244l731dd84eob8e4781dddabfef9@mail.gmail.com> References: <63wta2td.wl%jeremy.shaw@linspireinc.com> <396556a20802122244l731dd84eob8e4781dddabfef9@mail.gmail.com> Message-ID: <396556a20802122304k62966ff3kcbb0ff0fd1ca6daf@mail.gmail.com> On Feb 12, 2008 10:44 PM, Adam Langley wrote: > Currently I'm looking at hsc2hs for this bug. On a 32 bit box here: hsc2hs is forgiven; if you build with #define _FILE_OFFSET_BITS 32 then the structure is 96 bytes and the 64-bit offset is, indeed, at offset 88. However, if you end up calling the wrong libc lstat (and it's tough to tell, because both lstat and lstat64 in libc call the system call lstat64, so strace can't tell you) you'll only get an 88 byte structure filled in. HsUnix.h has a wrapper around lstat for exactly this reason, however ltrace shows it calling the wrong one. -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From agl at imperialviolet.org Wed Feb 13 02:45:41 2008 From: agl at imperialviolet.org (Adam Langley) Date: Wed Feb 13 02:44:17 2008 Subject: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems In-Reply-To: <396556a20802122304k62966ff3kcbb0ff0fd1ca6daf@mail.gmail.com> References: <63wta2td.wl%jeremy.shaw@linspireinc.com> <396556a20802122244l731dd84eob8e4781dddabfef9@mail.gmail.com> <396556a20802122304k62966ff3kcbb0ff0fd1ca6daf@mail.gmail.com> Message-ID: <396556a20802122345y741504f0s9769734a9e041e6e@mail.gmail.com> On Feb 12, 2008 11:04 PM, Adam Langley wrote: > structure filled in. HsUnix.h has a wrapper around lstat for exactly > this reason, however ltrace shows it calling the wrong one. So (finally!) the real issue: hsc2hs has a C preprocessor prelude (utils/hsc2hs/template-hsc.h) which includes some GHC header files. As a result, hsc processes files in 64-bit mode: % cpp -I../../includes -dM template-hsc.h | grep FILE_OFFSET_BITS #define _FILE_OFFSET_BITS 64 However, when building HsUnix.c (or any c file with cabal), the environment is different and it's built in 32-bit mode. Thus the lstat wrapper called the 32-bit glibc function, but the structure sizes and offsets in Files.hs (from Files.hsc) are all for 64-bit mode. The fix is not quite obvious. Probably hsc2hs should try harder not to change the environment so much. I'm not quite sure why the hsc2hs template pulls in the HsFFI header - it doesn't seem to need it. Although you can remove the #include and rebuild the unix package, I can safely say that you'll be reinstalling ghc if you do. What might work is changing hsc2hs and then rebuilding all of GHC. However, that's an overnight build so I don't know yet. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From jnf at arcor.de Wed Feb 13 02:46:31 2008 From: jnf at arcor.de (=?ISO-8859-1?Q?J=FCrgen?= Nicklisch-Franken) Date: Wed Feb 13 02:45:08 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell Message-ID: <1202888791.5962.1.camel@jutaro-laptop> I'm pleased to announce the first release of Leksah, an IDE for Haskell written in Haskell. Leksah is intended as a practical tool to support the Haskell development process. This is an unfinished pre-release with bugs and open ends. However, I decided to make a first announcement, hoping that Leksah may already be interesting and useful. Leksah uses GTK+ as GUI Toolkit with the gtk2hs binding. It is platform independent and should run on any platform where GTK+, gtk2hs and GHC can be installed. I have tested it on Windows and Linux. It only supports GHC. Features: * jumping to code every and anywhere * integration of cabal build * source candy * keymaps * configurable window * ... Some rudimentary documentation can be found in the doc/ subdirectory. Author and availability: Leksah is written by me and published under a GPL-2 license. Leksah can be optained via Hackage: http://hackage.haskell.org/ Darcs development repository: http://code.haskell.org/leksah Juergen From ccshan at post.harvard.edu Wed Feb 13 02:55:16 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Wed Feb 13 02:59:20 2008 Subject: [Haskell-cafe] Re: I love purity, but it's killing me. References: <594c1e830802072233n2b36ca82wd3c778f22edd4564@mail.gmail.com> Message-ID: <4cka85-223.ln1@mantle.rutgers.edu> Henning Thielemann wrote in article in gmane.comp.lang.haskell.cafe: > It seems to become a FAQ. I think all DSLs suffer from the same problems: > sharing and recursion. I've used wrappers for CSound, SuperCollider, > MetaPost, they all have these problems. What do you mean by the "recursion" problem? Sometimes (or perhaps even often), sharing in an EDSL can be expressed in two ways. First, to reuse a -value- in the embedded language, you could introduce a "let" construct in the embedded language. let_ expr body = body expr Second, to reuse an -expression- in the embedded language, if your interpreter is compositional (here by "interpreter" I include a compiler, and by "compositional" I mean a fold), then you can represent an embedded expression simply as its interpretation. add x y = x + y let expr = add x y in add expr expr Jacques Carette, Oleg Kiselyov, and I have been exploring this "final" representation. http://okmij.org/ftp/Computation/tagless-typed.html -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig I am a signature virus. Put me in your signature. From gour at mail.inet.hr Wed Feb 13 03:45:48 2008 From: gour at mail.inet.hr (Gour) Date: Wed Feb 13 03:44:41 2008 Subject: [Haskell-cafe] hoogle & gtk2hs Message-ID: <87zlu5s0qr.fsf@nitai.hr> Hi! Emacs haskell-mode has haskell-hoogle function to search Haskell API, but it, unfortunately, does not work with gtk2hs API which can be accessed via web at http://haskell.org/hoogle/?package=gtk Any plan to integrate Gtk2Hs so it becomes accessible via haskell-hoogle function? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ---------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080213/346bd688/attachment.bin From oleg at okmij.org Wed Feb 13 04:33:19 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Wed Feb 13 04:34:37 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] Message-ID: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> Tom Hawkins wrote: ] My DSLs invariably define a datatype to capture expressions; something ] like this: ] ] data Expression ] = Add Expression Expression ] | Sub Expression Expression ] | Variable String ] | Constant Int ] deriving Eq ] The problem comes when I want to generate efficient code from an ] Expression (ie. to C or some other target language). The method I use ] invovles converting the tree of subexpressions into an acyclic graphic ] to eliminate common subexpressions. The nodes are then topologically ] ordered and assigned an instruction, or statement for each node. For ] example: ] ] let a = Add (Constant 10) (Variable "i1") ] b = Sub (Variable "i2") (Constant 2) ] c = Add a b ] The process of converting an expression tree to a graph uses either Eq ] or Ord (either derived or a custom instance) to search and build a set ] of unique nodes to be ordered for execution. In this case "a", then ] "b", then "c". The problem is expressions often have shared, ] equivalent subnodes, which dramatically grows the size of the tree. ] For example: ] ] let d = Add c c ] e = Add d d -- "e" now as 16 leaf nodes. ] ] As these trees grow in size, the equality comparison in graph ] construction quickly becomes the bottleneck for DSL compilation. We show the design of the same sort of DSL that explicitly maintains sharing information and where node comparisons are quick, because we are comparing hashes rather than trees themselves. Our approach is assuredly safe, pure, and Haskell98 (save for disabling of the monomorphism restriction, which is done solely to avoid writing signatures). No GHC-specific behavior is relied upon. > {-# OPTIONS_GHC -fno-monomorphism-restriction #-} > > module DSL where > > import Data.IntMap as IM > import Control.Monad.State The approach is based on the final tagless representation. Here is our DSL: > class Exp repr where > constant :: Int -> repr Int > variable :: String -> repr Int > add :: repr Int -> repr Int -> repr Int > sub :: repr Int -> repr Int -> repr Int Tom Hawkins' test expressions now look as follows > a = add (constant 10) (variable "i1") > b = sub (variable "i2") (constant 2) > c = add a b > d = add c c > e = add d d which is the same as before modulo the case of the identifiers: everything is in lower case. We can show the expressions as before: showing is one way of evaluating things > newtype S t = S{unS :: String} > > instance Exp S where > constant x = S $ show x > variable x = S x > add e1 e2 = S( unS e1 ++ " + " ++ unS e2) > sub e1 e2 = S( unS e1 ++ " - " ++ unS e2) > > test_showe = unS e *DSL> test_showe "10 + i1 + i2 - 2 + 10 + i1 + i2 - 2 + 10 + i1 + i2 - 2 + 10 + i1 + i2 - 2" We can write an evaluator for the expressions > type REnv = [(String,Int)] > newtype R t = R{unR :: REnv -> t} -- A reader Monad, actually > > instance Exp R where > constant x = R $ const x > variable x = R ( \env -> maybe (error $ "no var: " ++ x) id $ > Prelude.lookup x env) > add e1 e2 = R(\env -> unR e1 env + unR e2 env) > sub e1 e2 = R(\env -> unR e1 env - unR e2 env) > test_vale = unR e [("i1",5),("i2",10)] -- 92 We stress: we are using exactly the same expression e as before. We are only evaluating it differently. The gist of the final tagless approach is to write an expression once and evaluate it many times. Now, we chose a different representation: to make sharing explicit We chose not to rely on GHC; we don't care if in (add c c), the two c are shared or copied. It is not observable in pure Haskell, and we don't care. We build our acyclic graph nevertheless. > type ExpHash = Int We stress: ACode is NOT a recursive data structure, so the comparison of ACode values takes constant time! > data ACode = AConst ExpHash | > AVar ExpHash | > AAdd ExpHash | > ASub ExpHash > deriving (Eq,Show) > data ExpMaps = ExpMaps{ hashcnt :: ExpHash, -- to generate new Hash > ctmap :: IntMap Int, > vrmap :: IntMap String, > admap :: IntMap (ACode,ACode), > sumap :: IntMap (ACode,ACode)} > deriving Show > exmap0 = ExpMaps 0 IM.empty IM.empty IM.empty IM.empty > > > newtype A t = A{unA :: State ExpMaps ACode} Granted, the following could be done far more efficiently: we need bimaps. > loookupv :: Eq v => v -> IntMap v -> Maybe Int > loookupv v = IM.foldWithKey > (\k e z -> maybe (if e == v then Just k else Nothing) (const z) z) > Nothing > > record con prj upd x = do > s <- get > maybe (do let s' = upd (s{hashcnt = succ (hashcnt s)}) > (IM.insert (hashcnt s) x (prj s)) > put s' > return (con $ hashcnt s)) > (return . con) $ loookupv x (prj s) > instance Exp A where > constant x = A(record AConst ctmap (\s e -> s{ctmap = e}) x) > variable x = A(record AVar vrmap (\s e -> s{vrmap = e}) x) > add e1 e2 = A(do > h1 <- unA e1 > h2 <- unA e2 > record AAdd admap (\s e -> s{admap = e}) (h1,h2)) > sub e1 e2 = A(do > h1 <- unA e1 > h2 <- unA e2 > record ASub sumap (\s e -> s{sumap = e}) (h1,h2)) Again, we are using the very same expression e we wrote at the very beginning: > test_sme = runState (unA e) exmap0 *DSL> test_sme (AAdd 8, ExpMaps {hashcnt = 9, ctmap = fromList [(0,10),(4,2)], vrmap = fromList [(1,"i1"),(3,"i2")], admap = fromList [(2,(AConst 0,AVar 1)),(6,(AAdd 2,ASub 5)), (7,(AAdd 6,AAdd 6)),(8,(AAdd 7,AAdd 7))], sumap = fromList [(5,(AVar 3,AConst 4))]}) We retain all the information about expression 'e'. In addition, all sharing is fully explicit. As we can see, the evaluation process finds common subexpressions automatically. From hc-erikd at mega-nerd.com Wed Feb 13 04:46:15 2008 From: hc-erikd at mega-nerd.com (Erik de Castro Lopo) Date: Wed Feb 13 04:44:55 2008 Subject: [Haskell-cafe] Announce : Sydney (Australia) Functional Programming Group Message-ID: <20080213204615.f7838749.hc-erikd@mega-nerd.com> Hi all, I'd like to announce the FP-SYD, the Sydney (Australia) Functional Programming group. The intro page is here: http://groups.google.com/group/fp-syd To subscribe to the mailing list (mainly for meeting organisation, meeting announcements, and Sydney job offers) either go to the URL above of send mail to: fp-syd-subscribe at googlegroups dot com Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Hey, I've re-dorkulated." -- Prof. Frink (The Simpsons) From magnus at therning.org Wed Feb 13 05:26:56 2008 From: magnus at therning.org (Magnus Therning) Date: Wed Feb 13 05:25:33 2008 Subject: [Haskell-cafe] Foreign.C.Types question ... In-Reply-To: <5ae4f2ba0802121124maf7540se47451eeb8ec8a45@mail.gmail.com> References: <5ae4f2ba0802121124maf7540se47451eeb8ec8a45@mail.gmail.com> Message-ID: On 2/12/08, Galchin Vasili wrote: > > Hello, > > http://cvs.haskell.org/Hugs/pages/libraries/base/Foreign-C-Types.html .. > I want to look at the actual code for these C types so that I can see how > the instances of Storable for each type are coded so e.g. I can see how > sizeOf/allignment are coded. > I've written a small example that might be of help: http://therning.org/magnus/archives/315 /M -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080213/30bc93fa/attachment.htm From lrpalmer at gmail.com Wed Feb 13 05:36:32 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Wed Feb 13 05:35:07 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] In-Reply-To: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> References: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> Message-ID: <7ca3f0160802130236r3b478deasaa55fea87326a8f5@mail.gmail.com> On Feb 13, 2008 9:33 AM, wrote: > The approach is based on the final tagless representation. Here is our > DSL: > > > class Exp repr where > > constant :: Int -> repr Int > > variable :: String -> repr Int > > add :: repr Int -> repr Int -> repr Int > > sub :: repr Int -> repr Int -> repr Int This is very nice. May I ask, though, what is the purpose of all the Ints appearing as arguments to repr here? Looking over this code, it seems that it would work just as well if they were all omitted. Thanks, Luke From simeon.mattes at gmail.com Wed Feb 13 06:57:58 2008 From: simeon.mattes at gmail.com (Simeon Mattes) Date: Wed Feb 13 06:56:41 2008 Subject: [Haskell-cafe] existential types Message-ID: I have found that ghc has adopted the existential data constructors. Because it was first time I have heard this term I have found some articles about it. The less complex for me was the following explanation data Worker x y = Worker {buffer :: b, input :: x, output :: y} This is wrong in Haskell98 because we can 't just hide buffer :: b. We should write instead data Worker b x y = Worker {buffer :: b, input :: x, output :: y} Let suppose that b has an indefinite type. Then with existential types we could write data Worker x y = forall b. Buffer b => Worker {buffer :: b, input :: x, output :: y} The example above is similar to the example that Paul Hudak, John Hughes, Simon Peyton Jones and Philip Wadler mention in an article "a history of Haskell". Though I can't figure out how exactly could utilize such a type. To be honest haskell is my first functional language and I 'm not so familiar with. So, an example would be very helpful From lemming at henning-thielemann.de Wed Feb 13 07:51:20 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 13 07:49:56 2008 Subject: [Haskell-cafe] existential types In-Reply-To: References: Message-ID: On Wed, 13 Feb 2008, Simeon Mattes wrote: > I have found that ghc has adopted the existential data constructors. Because it > was first time I have heard this term I have found some articles about it. The > less complex for me was the following explanation > > data Worker x y = Worker {buffer :: b, input :: x, output :: y} Seems to be the example which is also presented here: http://www.haskell.org/haskellwiki/Existential_type From scook0 at gmail.com Wed Feb 13 08:08:34 2008 From: scook0 at gmail.com (Stuart Cook) Date: Wed Feb 13 08:07:09 2008 Subject: [Haskell-cafe] ANN: unix-pty-light 0.1 Message-ID: <49b351060802130508v5871b550o2b51b1b6d738aec9@mail.gmail.com> A little while ago, I needed bindings for creating and accessing a pseudo-terminal device. Since I couldn't find any in the unix package, I wrote my own. Later, I found out that unix-2.2.0.0 does indeed contain pseudo-terminal bindings, but unfortunately it seems to be incompatible with my version of GHC (6.6). Therefore, I have created a package that provides pseudo-terminal support, and should work with both 6.6 and 6.8 (though I have only tested 6.6). As always, comments and feedback are most welcome. Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-pty-light-0.1 Darcs: http://code.haskell.org/~scook0/unix-pty-light/ Haddock: http://code.haskell.org/~scook0/haddock/unix-pty-light/ Stuart Cook From daniil.elovkov at googlemail.com Wed Feb 13 08:19:09 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Wed Feb 13 08:17:50 2008 Subject: [Haskell-cafe] existential types In-Reply-To: References: Message-ID: <47B2EE4D.10103@gmail.com> Simeon Mattes wrote: > I have found that ghc has adopted the existential data constructors. Because it > was first time I have heard this term I have found some articles about it. The > less complex for me was the following explanation > > data Worker x y = Worker {buffer :: b, input :: x, output :: y} > > This is wrong in Haskell98 because we can 't just hide buffer :: b. We should > write instead data Worker b x y = Worker {buffer :: b, input :: x, output :: y} > > Let suppose that b has an indefinite type. Then with existential types we could > write data Worker x y = forall b. Buffer b => Worker {buffer :: b, input :: x, > output > :: y} > > The example above is similar to the example that Paul Hudak, John Hughes, Simon > Peyton Jones and Philip Wadler mention in an article "a history of Haskell". > > Though I can't figure out how exactly could utilize such a type. To be honest > haskell is my first functional language and I 'm not so familiar with. So, an > example would be very helpful I would say I don't see why this particular datatype is useful. I mean with no regard to existentials. Having output as a field in the data constructor seems strange to me. From daniil.elovkov at googlemail.com Wed Feb 13 08:30:53 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Wed Feb 13 08:29:32 2008 Subject: [Haskell-cafe] Haskell wiki is searched by google. Message-ID: <47B2F10D.7000200@gmail.com> Hello I remember there was a problem with haskell wiki pages not being indexed and searched. Now it seems to work perfectly. Actually typing 'monomorphism restriction' in google I see the appropriate wiki page as the first result. I must have missed the moment when it was fixed. Just sharing my observations. Thanks. From r.kelsall at millstream.com Wed Feb 13 09:14:39 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Wed Feb 13 09:13:23 2008 Subject: [Haskell-cafe] Haskell wiki is searched by google. In-Reply-To: <47B2F10D.7000200@gmail.com> References: <47B2F10D.7000200@gmail.com> Message-ID: <47B2FB4F.3040506@millstream.com> Daniil Elovkov wrote: > Hello > > I remember there was a problem with haskell wiki pages not being indexed > and searched. > > Now it seems to work perfectly. Actually typing 'monomorphism > restriction' in google I see the appropriate wiki page as the first result. > > I must have missed the moment when it was fixed. Just sharing my > observations. Thanks. Hello Daniil, I think I may have started that discussion here : http://www.haskell.org/pipermail/haskell-cafe/2007-November/035127.html but sadly a search for mdo in the Search box at the top of this page http://haskell.org/haskellwiki/Haskell still gives no results. I suspect something needs adjusting in the configuration of MediaWiki for the haskellwiki. Richard. From mfn-haskell-cafe at cs.york.ac.uk Wed Feb 13 09:27:30 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Wed Feb 13 09:27:22 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] In-Reply-To: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> References: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> Message-ID: <20080213142730.GA13391@pc149.staff.cs.york.ac.uk> Hi Oleg, it's not immediately clear (to me at least) how efficient your method will be in "practice". Any method based on common sub-expression elimination surely must inspect every node in the flattened graph. In the worst case, an acyclic graph containing n nodes could have 2^n nodes when flattened to a tree: tricky 0 = constant 0 tricky d = add g g where g = tricky (d-1) Of course, in "practice" the worst case may not occur. Also, my mental model is big circuits, which may be different to yours and Tom's. (Sorry if I'm just pointing out the obvious.) Matt. From daniil.elovkov at googlemail.com Wed Feb 13 09:33:14 2008 From: daniil.elovkov at googlemail.com (Daniil Elovkov) Date: Wed Feb 13 09:31:53 2008 Subject: [Haskell-cafe] Haskell wiki is searched by google. In-Reply-To: <47B2FB4F.3040506@millstream.com> References: <47B2F10D.7000200@gmail.com> <47B2FB4F.3040506@millstream.com> Message-ID: <47B2FFAA.9020807@gmail.com> Richard Kelsall wrote: > Daniil Elovkov wrote: >> Hello >> >> I remember there was a problem with haskell wiki pages not being >> indexed and searched. >> >> Now it seems to work perfectly. Actually typing 'monomorphism >> restriction' in google I see the appropriate wiki page as the first >> result. >> >> I must have missed the moment when it was fixed. Just sharing my >> observations. Thanks. > > Hello Daniil, I think I may have started that discussion here : > > http://www.haskell.org/pipermail/haskell-cafe/2007-November/035127.html > > but sadly a search for mdo in the Search box at the top of this page > > http://haskell.org/haskellwiki/Haskell > > still gives no results. I suspect something needs adjusting in the > configuration of MediaWiki for the haskellwiki. > Indeed. But searching with google mdo site:haskell.org/haskellwiki does a pretty good job - 6 results :) From r.kelsall at millstream.com Wed Feb 13 10:15:30 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Wed Feb 13 10:14:09 2008 Subject: [Haskell-cafe] Haskell wiki is searched by google. In-Reply-To: <47B2FFAA.9020807@gmail.com> References: <47B2F10D.7000200@gmail.com> <47B2FB4F.3040506@millstream.com> <47B2FFAA.9020807@gmail.com> Message-ID: <47B30992.8010207@millstream.com> Daniil Elovkov wrote: > Richard Kelsall wrote: >> Daniil Elovkov wrote: >>> Hello >>> >>> I remember there was a problem with haskell wiki pages not being >>> indexed and searched. >>> >>> Now it seems to work perfectly. Actually typing 'monomorphism >>> restriction' in google I see the appropriate wiki page as the first >>> result. >>> >>> I must have missed the moment when it was fixed. Just sharing my >>> observations. Thanks. >> >> Hello Daniil, I think I may have started that discussion here : >> >> http://www.haskell.org/pipermail/haskell-cafe/2007-November/035127.html >> >> but sadly a search for mdo in the Search box at the top of this page >> >> http://haskell.org/haskellwiki/Haskell >> >> still gives no results. I suspect something needs adjusting in the >> configuration of MediaWiki for the haskellwiki. >> > Indeed. > > But searching with google > > mdo site:haskell.org/haskellwiki > > does a pretty good job - 6 results :) > I have to admit I haven't yet discovered how all the documentation fits together. I set the "Search haskell.org" link on left on the front page to search Google like this mdo site:haskell.org for "mdo" which gives 577 results including the relevant page of the GHC documentation at the top. But I'm not really sure it should search everything on haskell.org. I can easily change this if anybody suggests a better search criteria. I looked all over the wiki for some way to warn users that the search results might be incomplete. All the relevant bits - like the search results messages - appeared to be locked against me changing them. I'm happy to Google for things, but I don't think it's good to have a misleading search box on the front page. Richard. From jake.mcarthur at gmail.com Wed Feb 13 11:41:03 2008 From: jake.mcarthur at gmail.com (Jake McArthur) Date: Wed Feb 13 11:39:52 2008 Subject: [Haskell-cafe] existential types In-Reply-To: References: Message-ID: <6B58F195-D4EB-4B25-BC7F-4E12EF404403@gmail.com> Let's try a different example. Let's start with a list designed to hold numbers: data NumericList a = Num a => [a] Normally this would be fine. We can hold things like [1, 2, 3, 4, 5] and [1.7, 5.3, 2.0, 99.1]. But what if we wanted to be able to hold numbers with _different types_ in the list? That is, we won't know anything about them except that they are instances of Num. That is where existential types come in: data NumericList = forall a . Num a => [a] Now we can have NumericLists like [1 :: Int, 5.7 :: Double, 4%5 :: Rational]. The only useful thing you can do with the values, in this case, is apply functions of the Num type class, but there are times when this is useful. (There are actually ways to cast these values back to their original types elsewhere, but I'll ignore that because it is far out of the scope of your question). Does this help? - Jake From jake.mcarthur at gmail.com Wed Feb 13 11:42:26 2008 From: jake.mcarthur at gmail.com (Jake McArthur) Date: Wed Feb 13 11:41:07 2008 Subject: [Haskell-cafe] existential types In-Reply-To: References: Message-ID: <78F57B49-1B08-4107-A83C-311CA72C345B@gmail.com> Oops, I was hasty in typing those data definitions. They will not work because they have no constructors. Sorry about that. - Jake From felipe.lessa at gmail.com Wed Feb 13 12:15:40 2008 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed Feb 13 12:14:14 2008 Subject: [Haskell-cafe] existential types In-Reply-To: <6B58F195-D4EB-4B25-BC7F-4E12EF404403@gmail.com> References: <6B58F195-D4EB-4B25-BC7F-4E12EF404403@gmail.com> Message-ID: On Feb 13, 2008 2:41 PM, Jake McArthur wrote: > Now we can have NumericLists like [1 :: Int, 5.7 :: Double, 4%5 :: > Rational]. No, we can't =). Using data NumericList = forall a . Num a => N [a] *Main> let a = N [1::Int,2,3,4] *Main> let b = N [1::Double,2,3,4] *Main> let c = N [1::Int,2::Double] :1:18: Couldn't match expected type `Int' against inferred type `Double' In the expression: 2 :: Double In the first argument of `N', namely `[1 :: Int, 2 :: Double]' In the expression: N [1 :: Int, 2 :: Double] *Main> let d = [a, b, N [1::Rational,2,3,4]] The lists inside N will be homogeneous, but you can have a (homogeneous) list of N's such that each N has a diferrent list type. If you want a list of different types of numbers, you should do something like data Number = forall a. Num a => Number a type NumberList = [Number] x :: NumberList x = [Number (1::Int), Number (2::Double), Number (3::Rational)] or maybe data NumberList2 = forall a . Num a => Cons a NumberList2 | Nil x2 :: NumberList2 x2 = Cons (1::Int) $ Cons (2::Double) $ Cons (3::Rational) Nil Cheers, -- Felipe. From simeon.mattes at gmail.com Wed Feb 13 12:24:27 2008 From: simeon.mattes at gmail.com (Simeon Mattes) Date: Wed Feb 13 12:23:11 2008 Subject: [Haskell-cafe] Re: existential types References: <6B58F195-D4EB-4B25-BC7F-4E12EF404403@gmail.com> Message-ID: The help of all was very useful. But since Jake gave me an example I prefer to follow this up. Although I 'm not so familiar generally with datatypes I have understood you. It seems in this example that with existential types we can put in the same list different types although generally this is not allowed. I have tried to write this example with the ghc compiler 6.8.2 but there was an error pare error in data/newtype declaration. I have also tried to find the etymology of the word existential, since some times somebody can easily find a better answer, but I can't figure out why this is so. (really why "existential" types?). Maybe a completed example would be more helpful. existence Look up existence at Dictionary.com c.1384, from O.Fr. existence, from L.L. existentem "existent," prp. of L. existere "stand forth, appear," and, as a secondary meaning, "exist;" from ex- "forth" + sistere "cause to stand" (see assist). Existential as a term in logic is from 1819. Existentialism is 1941 from Ger. Existentialismus (1919), ult. from Dan. writer S?ren Kierkegaard (1813-55), who wrote (1846) of Existents-Forhold "condition of existence," existentielle Pathos, etc. (I hope this way of questioning is not so strange) From jgbailey at gmail.com Wed Feb 13 12:52:52 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Wed Feb 13 12:51:28 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: <1202888791.5962.1.camel@jutaro-laptop> References: <1202888791.5962.1.camel@jutaro-laptop> Message-ID: That looks really cool and I'd like to try it out. Can you provide links to these packages? gtk >=0.9.12, glib >=0.9.12, sourceview >=0.9.12, binary >=0.4.1 I just don't have time to track them down myself ... Justin From aslatter at gmail.com Wed Feb 13 13:32:03 2008 From: aslatter at gmail.com (Antoine Latter) Date: Wed Feb 13 13:30:38 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: References: <1202888791.5962.1.camel@jutaro-laptop> Message-ID: <694519c50802131032o54a6eb64gc0b1bd14ce121608@mail.gmail.com> The package `binary' should be on hackage.haskell.org. The others can be found in gtk2hs, I think: http://www.haskell.org/gtk2hs/ Antoine On Feb 13, 2008 11:52 AM, Justin Bailey wrote: > That looks really cool and I'd like to try it out. Can you provide > links to these packages? > > gtk >=0.9.12, > glib >=0.9.12, > sourceview >=0.9.12, > binary >=0.4.1 > > I just don't have time to track them down myself ... > > Justin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mfn-haskell-cafe at cs.york.ac.uk Wed Feb 13 15:24:38 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Wed Feb 13 15:26:57 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] In-Reply-To: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> References: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> Message-ID: <20080213202437.GA21729@venice.staff.cs.york.ac.uk> Hello again, since Oleg presented an approach to the sharing problem that works on acyclic graphs, I may as well mention an alternative, pure, standard Haskell solution which is to express the fork points in the circuit (or expression), i.e. the points at which an expression is duplicated. You need to introduce a fork primitive: fork :: Bit -> (Bit, Bit) or fork :: Exp -> (Exp, Exp) This fits quite naturally in the context of circuit description, and I called it "expressible sharing". Under some mild restrictions, it even works on cyclic graphs. In particular, it works nicely for regular circuits. The "tricky" example I mentioned earlier would be written: tricky 0 = constant 0 tricky d = add e0 e1 where (e0, e1) = fork (tricky (d-1)) However, in the end I admitted defeat and decided I preferred observable sharing! Matt. From ryani.spam at gmail.com Wed Feb 13 15:43:14 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Feb 13 15:41:49 2008 Subject: [Haskell-cafe] Re: existential types In-Reply-To: References: <6B58F195-D4EB-4B25-BC7F-4E12EF404403@gmail.com> Message-ID: <2f9b2d30802131243p5f57cbdcvdf6ba75e262d26f9@mail.gmail.com> The name "existential types" comes from the logical connective "exists", which is the dual of "for all". For example, given some property P of objects of type T, you can say forall x : T. P(x) -- means that P holds for all things of type x or exists x : T. P(x) -- means that there is some x for which P holds. For example, take P(x) to be "x is an integer". Then: forall x : Int, P(x) -- valid, all objects of type Int are integers forall x : Float, P(x) -- not valid exists x : Float, P(x) -- valid, for example, 1.0 :: Float is an integer In Haskell, forall is only used for kinds, such as *, the type of types, and * -> *, the kind of type constructor used for monads & lists (among other things). A couple of examples: (+) :: forall a. Num a => a -> a -> a means forall a : *, Num a implies (+) has type (a -> a -> a) return False :: forall a. Monad m => m Bool means forall m : * -> *, Monad m implies that (return False) has type (m Bool). Similarily, you might want to say (note: this is not valid haskell) [0 :: Int, 2 :: Double] :: [ t such that there exists a Num instance for t ], However, you can express "exists" in terms of "forall": exists x, P(x) is equivalent to (not (forall x, not P(x))) that is, if it is not true for all x that P(x) does not hold, then there must be some x for which it does hold. The existential types extension to haskell uses this dual: data Number = forall a. Num a => N a means that the constructor N has type N :: forall a. Num a => a -> Number Consider this function: isZero (N n) = (n == 0) You have a Number and you are pattern matching on N, so what do you know about the type of n? Well, you know that N was called with an object of some type a, and that Num a holds. That is: exists a : *, Num a & type(n) == a You can now express that list: [ N (0 :: Int), N (2 :: Double) ] :: [ Number ] and use it like any other list: map isZero [ N (0 :: Int), N (2 :: Double) ] :: [Bool] -- ryan On 2/13/08, Simeon Mattes wrote: > The help of all was very useful. But since Jake gave me an example I prefer to > follow this up. > > Although I 'm not so familiar generally with datatypes I have understood you. It > seems in this example that with existential types we can put in the same list > different types although generally this is not allowed. I have tried to write > this example with the ghc compiler 6.8.2 but there was an error > > pare error in data/newtype declaration. > > > I have also tried to find the etymology of the word existential, since some > times somebody can easily find a better answer, but I can't figure out why this > is so. (really why "existential" types?). Maybe a completed example would be > more helpful. > > existence Look up existence at Dictionary.com c.1384, from O.Fr. existence, from > L.L. existentem "existent," prp. of L. existere "stand forth, appear," and, as a > secondary meaning, "exist;" from ex- "forth" + sistere "cause to stand" (see > assist). Existential as a term in logic is from 1819. Existentialism is 1941 > from Ger. Existentialismus (1919), ult. from Dan. writer S?ren Kierkegaard > (1813-55), who wrote (1846) of Existents-Forhold "condition of existence," > existentielle Pathos, etc. > > (I hope this way of questioning is not so strange) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From mfn-haskell-cafe at cs.york.ac.uk Wed Feb 13 15:41:29 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Wed Feb 13 15:42:03 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] In-Reply-To: <20080213202437.GA21729@venice.staff.cs.york.ac.uk> References: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> <20080213202437.GA21729@venice.staff.cs.york.ac.uk> Message-ID: <20080213204129.GA21849@venice.staff.cs.york.ac.uk> > tricky 0 = constant 0 > tricky d = add e0 e1 > where > (e0, e1) = fork (tricky (d-1)) Oops, I just realised that this isn't a very good example of expressible sharing! The problem is that it doesn't take any inputs, and expressible sharing just collapses (partially evaluates) operators when they are applied to constants. A better example would be something that takes an input, such as distrib a [] = [] distrib a (x:xs) = (a0, x) : distrib a1 xs where (a0, a1) = fork a Matt. From drl at cs.cmu.edu Wed Feb 13 16:31:10 2008 From: drl at cs.cmu.edu (Dan Licata) Date: Wed Feb 13 16:29:55 2008 Subject: [Haskell-cafe] Re: existential types In-Reply-To: <2f9b2d30802131243p5f57cbdcvdf6ba75e262d26f9@mail.gmail.com> References: <6B58F195-D4EB-4B25-BC7F-4E12EF404403@gmail.com> <2f9b2d30802131243p5f57cbdcvdf6ba75e262d26f9@mail.gmail.com> Message-ID: <20080213213110.GA28680@cs.cmu.edu> Hi Ryan, On Feb13, Ryan Ingram wrote: > However, you can express "exists" in terms of "forall": > exists x, P(x) is equivalent to (not (forall x, not P(x))) > that is, if it is not true for all x that P(x) does not hold, then > there must be some x for which it does hold. > > The existential types extension to haskell uses this dual: > data Number = forall a. Num a => N a > > means that the constructor N has type > N :: forall a. Num a => a -> Number Actually, the encoding of existential types doesn't use the negation trick, which doesn't even work in intuitionistic logic. The encoding of existentials is just currying: Given a function of type (A , B) -> C we can produce a function A -> B -> C "exists" is a lot like pairing, and "forall" is a lot like ->. So if all we want is existentials to the left of an -> we can just curry them away: (exists a.B) -> C becomes forall a. B -> C The existential type extension allows forall's to the left of the -> in the signature of a datatype constructor, so constructors can have existentially bound variables. I.e. data AnyNum where N : forall a. Num a => a -> AnyNum could just as well be written data AnyNum = N (exists a. Num a and a) but Haskell doesn't allow the latter syntax. -Dan From mads_lindstroem at yahoo.dk Wed Feb 13 14:49:33 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Wed Feb 13 16:30:14 2008 Subject: [Haskell-cafe] Haskell wiki is searched by google. In-Reply-To: <47B2FB4F.3040506@millstream.com> References: <47B2F10D.7000200@gmail.com> <47B2FB4F.3040506@millstream.com> Message-ID: <1202932173.4167.4.camel@localhost.localdomain> Richard Kelsall wrote: > Daniil Elovkov wrote: > > Hello > > > > I remember there was a problem with haskell wiki pages not being indexed > > and searched. > > > > Now it seems to work perfectly. Actually typing 'monomorphism > > restriction' in google I see the appropriate wiki page as the first result. > > > > I must have missed the moment when it was fixed. Just sharing my > > observations. Thanks. > > Hello Daniil, I think I may have started that discussion here : > > http://www.haskell.org/pipermail/haskell-cafe/2007-November/035127.html > > but sadly a search for mdo in the Search box at the top of this page > > http://haskell.org/haskellwiki/Haskell > > still gives no results. I suspect something needs adjusting in the > configuration of MediaWiki for the haskellwiki. Not MediaWiki, but the underlying database. If HaskellWiki uses MySql ft_min_word_len needs to be set to something smaller than four. See http://dev.mysql.com/doc/refman/5.0/en/fulltext-fine-tuning.html . After doing this the indexes needs to be rebuild. Greetings, Mads Lindstr?m > > > Richard. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From derek.a.elkins at gmail.com Wed Feb 13 16:32:20 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Feb 13 17:31:54 2008 Subject: [Haskell-cafe] Re: existential types In-Reply-To: <20080213213110.GA28680@cs.cmu.edu> References: <6B58F195-D4EB-4B25-BC7F-4E12EF404403@gmail.com> <2f9b2d30802131243p5f57cbdcvdf6ba75e262d26f9@mail.gmail.com> <20080213213110.GA28680@cs.cmu.edu> Message-ID: <1202938341.5604.39.camel@derek-laptop> On Wed, 2008-02-13 at 16:31 -0500, Dan Licata wrote: > Hi Ryan, > > On Feb13, Ryan Ingram wrote: > > However, you can express "exists" in terms of "forall": > > exists x, P(x) is equivalent to (not (forall x, not P(x))) > > that is, if it is not true for all x that P(x) does not hold, then > > there must be some x for which it does hold. > > > > The existential types extension to haskell uses this dual: > > data Number = forall a. Num a => N a > > > > means that the constructor N has type > > N :: forall a. Num a => a -> Number > > Actually, the encoding of existential types doesn't use the negation > trick, which doesn't even work in intuitionistic logic. > > The encoding of existentials is just currying: > > Given a function of type > > (A , B) -> C > > we can produce a function > > A -> B -> C > > "exists" is a lot like pairing, and "forall" is a lot like ->. So if > all we want is existentials to the left of an -> we can just curry them > away: > > (exists a.B) -> C > > becomes > > forall a. B -> C Or categorically: Existentials are left adjoints. Universals are the dual of existentials. (->) is continuous in its first argument (because it's a right adjoint [to itself no less]) so it takes limits to limits, but it's also contravariant so it takes limits in the opposite category to limits or, effectively, it takes colimits to limits. Since we know the relevant universals exist, we have the above by continuity of right adjoints. From stevelihn at gmail.com Wed Feb 13 19:34:57 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Wed Feb 13 19:43:56 2008 Subject: [Haskell-cafe] ANN: nano-hmac 0.2.0 In-Reply-To: <20080212190342.GA26504@scytale.galois.com> References: <20080211212924.GB10466@scytale.galois.com> <88a582380802120002u55866b98h20892808aa5e7af4@mail.gmail.com> <20080212190342.GA26504@scytale.galois.com> Message-ID: And in perl CPAN world, there are "bundles" that put together related packages in one big install... Maybe there can be "Cabal bundles". Just an idea! On Feb 12, 2008 2:03 PM, Don Stewart wrote: > Ok, I'll leave it up there as a separate package then. :) > > -- Don > > hitesh.jasani: > > Don, > > > > It's tempting, but I would really hate to lose nano-md5 as it is > > today. I thought your concept was a great idea to inspire people to > > start small to get a feel for developing Haskell libraries. The > > current nano-md5 serves as a really good example. > > > > In the Ruby community there are many small libraries that do one, > > simple focused task. There are times when this is a virtue over > > libraries that try to be all encompassing. It's weird but I would > > have thought the Haskell community would have more embraced small > > libraries also since they may be more composable. > > > > - Hitesh > > > > > > > On Feb 11, 2008 4:29 PM, Don Stewart wrote: > > > hitesh.jasani: > > > > nano-hmac provides bindings to OpenSSL's HMAC interface. With this release the > > > > set of hashing functions supported is: MD5, SHA, SHA1, SHA224, SHA256, SHA384, > > > > SHA512. > > > > > > > > If you're unfamiliar with HMAC's then you may want to check out the second link > > > > below where I explain a little bit about them in a blog entry. > > > > > > > > The hackage pages mentioned that they're not running haddock 2.0, so I don't > > > > know if the docs will generate. If not, you can see the docs online at the > > > > third link below. > > > > > > > > * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nano-hmac-0.2.0 > > > > * http://www.jasani.org/2008/02/nano-hmac-020-released.html > > > > * http://docs.jasani.org/nano-hmac/0.2.0/ > > > > > > > > Any and all comments/suggestions/criticisms/fortune-cookie-proverbs are welcome. > > > > > > > > > > Shall we merge nano-md5 into this lib, and deprecate nano-md5 itself? > > > Seems like a good time to consolidate, and produce a single openssl > > > binding. > > > > > > -- Don > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ok at cs.otago.ac.nz Wed Feb 13 19:46:17 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Feb 13 19:44:54 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> Message-ID: On 12 Feb 2008, at 5:14 pm, jerzy.karczmarczuk@info.unicaen.fr wrote: > Would you say that *no* typical floating-point software is reliable? With lots of hedging and clutching of protective amulets around the word "reliable", of course not. What I *am* saying is that (a) it's exceptionally HARD to make reliable because although the operations are well defined and arguably reasonable they do NOT obey the laws that school and university mathematics teach us to expect them to obey (b) "reliable" in each case needs to be defined with some care; it will almost never mean "gives answers accurate to machine precision for any legal input" and probably won't mean "gives sensible answers for any legal input" either. With luck, it will mean "gives answers accurate to a specified tolerance for an input that differs from the input you actually provided by no more than a specified tolerance for inputs that are neither too big nor too small, a stated range". (Note that the problem that gets almost solved may only be almost your problem.) (c) practical advice is to use reputable packaged software whenever you possibly can rather than writing your own, and always check that the answers make physical sense before putting any trust with them; if (or should I say when) things go weird, seek the help of an expert. (d) if you trust the output of a certain popular spreadsheet program, I have a bridge you might be interested in buying... This is leaving aside all sorts of machine strangeness, like the student whose neural net program started running hundreds of times slower than he expected. I advised him to replace s = 0; for (i = 0; i < n; i++) s += x[i]*x[i]; by s = 0; for (i = 0; i < n; i++) if (fabs(x[i]) > 1e-19) s += x[i]*x[i]; and the problem went away. Dear reader: do you know why I expected this problem, what it was, and why this is NOT a general solution? From stevelihn at gmail.com Wed Feb 13 19:50:55 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Wed Feb 13 19:49:30 2008 Subject: [Haskell-cafe] a general question on Arrows Message-ID: In John Hughes' paper [1], Programming with Arrows, p. 20, "The truly interesting arrow types are those which do not correspond to a monad, because it is here that arrows give us real extra generality. Since we know that stream functions cannot be represented as a monad, then they are one of these "interesting" arrow types. So are the arrows used for functional reactive programming, for building GUIs, and the arrows for discrete event simulation we present in Section 5. And since these arrows cannot be represented by a monad, we know that they cannot support a sensible definition of app either." He described a few things that "cannot" be represented as a monad, they are: 1. Stream 2. FRP 3. GUI (request/response?) 4. Event Driven System (like circuits, robots?) My first question is: Are they "absolutely" outside of the realm of function + monad, therefore, arrows are indispensable? Or it is simply because the haskell program would be very cumbersome without arrows in these areas? (I mean without utilizing FFI to rescue.) The second question is: Other than the 4 areas above, are there more? Just want to get a sense of how useful arrows are. Not really a theoretical question. Thanks, Steve [1] http://www.cs.chalmers.se/~rjmh/afp-arrows.pdf From ok at cs.otago.ac.nz Wed Feb 13 19:56:11 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Feb 13 19:54:48 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802121121.23809.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> <47B0B3BE.4010601@charter.net> <200802121121.23809.g9ks157k@acme.softbase.org> Message-ID: <05B7D634-41DC-4618-8A0A-DF05123A4528@cs.otago.ac.nz> Concerning "parametrized" vs "parameterized" On 12 Feb 2008, at 11:21 pm, Wolfgang Jeltsch asked: > What spelling is more common? Strictly speaking, there is no such word in English as "parametrized". There is no general morphological rule "Xer => Xrized" in English. The only spelling accepted by the OED is "parameterized", which annoys me because I prefer the -ise- spelling. Amusingly, one of the quotations in the www.oed.com entry for "parameterized" actually spells it "parametrized"; I don't know whether the source had it that way or whether the data entry error was at the OED. From jake.mcarthur at gmail.com Wed Feb 13 20:06:58 2008 From: jake.mcarthur at gmail.com (Jake McArthur) Date: Wed Feb 13 20:05:35 2008 Subject: [Haskell-cafe] existential types References: <8321D3BB-0DB1-46AD-850C-AAF2AE092992@gmail.com> Message-ID: <308E07AA-86AE-4977-844F-F02A20EA6997@gmail.com> From: Jake McArthur Date: February 13, 2008 7:04:49 PM CST To: Felipe Lessa Subject: Re: [Haskell-cafe] existential types On Feb 13, 2008, at 11:15 AM, Felipe Lessa wrote: > On Feb 13, 2008 2:41 PM, Jake McArthur > wrote: >> Now we can have NumericLists like [1 :: Int, 5.7 :: Double, 4%5 :: >> Rational]. > > No, we can't =). Using > > data NumericList = forall a . Num a => N [a] > [etc.etc.etc.] Oops again. Maybe I just shouldn't say anything to anybody on the Internet within an hour of waking up in the morning! ;) - Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080213/ec16c277/attachment.htm From thomas.dubuisson at gmail.com Wed Feb 13 20:16:55 2008 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed Feb 13 20:10:22 2008 Subject: [Haskell-cafe] ANN: nano-hmac 0.2.0 In-Reply-To: References: <20080211212924.GB10466@scytale.galois.com> <88a582380802120002u55866b98h20892808aa5e7af4@mail.gmail.com> <20080212190342.GA26504@scytale.galois.com> Message-ID: <1202951815.25623.7.camel@localhost> Hopefully this bundle would be a module that re-exports all the submodules packages. I'm kind of annoyed by some of my code that imports ten different modules for one function from each. So in this case: import nanoCrypto (md5, sha, hmac) where nanoCrypto is a bundle (just another hackage package, really) that depends on nano-{md5,sha,hmac} and exports. Sound good? Or perhaps this is already how things work in CPAN and I am just stating what everyone already knows. Thomas On Wed, 2008-02-13 at 19:34 -0500, Steve Lihn wrote: > And in perl CPAN world, there are "bundles" that put together related > packages in one big install... Maybe there can be "Cabal bundles". > Just an idea! > > On Feb 12, 2008 2:03 PM, Don Stewart wrote: > > Ok, I'll leave it up there as a separate package then. :) > > > > -- Don > > > > hitesh.jasani: > > > Don, > > > > > > It's tempting, but I would really hate to lose nano-md5 as it is > > > today. I thought your concept was a great idea to inspire people to > > > start small to get a feel for developing Haskell libraries. The > > > current nano-md5 serves as a really good example. > > > > > > In the Ruby community there are many small libraries that do one, > > > simple focused task. There are times when this is a virtue over > > > libraries that try to be all encompassing. It's weird but I would > > > have thought the Haskell community would have more embraced small > > > libraries also since they may be more composable. > > > > > > - Hitesh > > > > > > > > > > > On Feb 11, 2008 4:29 PM, Don Stewart wrote: > > > > hitesh.jasani: > > > > > nano-hmac provides bindings to OpenSSL's HMAC interface. With this release the > > > > > set of hashing functions supported is: MD5, SHA, SHA1, SHA224, SHA256, SHA384, > > > > > SHA512. > > > > > > > > > > If you're unfamiliar with HMAC's then you may want to check out the second link > > > > > below where I explain a little bit about them in a blog entry. > > > > > > > > > > The hackage pages mentioned that they're not running haddock 2.0, so I don't > > > > > know if the docs will generate. If not, you can see the docs online at the > > > > > third link below. > > > > > > > > > > * http://hackage.haskell.org/cgi-bin/hackage-scripts/package/nano-hmac-0.2.0 > > > > > * http://www.jasani.org/2008/02/nano-hmac-020-released.html > > > > > * http://docs.jasani.org/nano-hmac/0.2.0/ > > > > > > > > > > Any and all comments/suggestions/criticisms/fortune-cookie-proverbs are welcome. > > > > > > > > > > > > > Shall we merge nano-md5 into this lib, and deprecate nano-md5 itself? > > > > Seems like a good time to consolidate, and produce a single openssl > > > > binding. > > > > > > > > -- Don > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From rl at cse.unsw.edu.au Wed Feb 13 20:28:22 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Feb 13 20:27:08 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> Message-ID: <47B39936.10509@cse.unsw.edu.au> Richard A. O'Keefe wrote: > > On 12 Feb 2008, at 5:14 pm, jerzy.karczmarczuk@info.unicaen.fr wrote: >> Would you say that *no* typical floating-point software is reliable? > > With lots of hedging and clutching of protective amulets around the > word "reliable", of course not. What I *am* saying is that > (a) it's exceptionally HARD to make reliable because although the > operations > are well defined and arguably reasonable they do NOT obey the laws that > school and university mathematics teach us to expect them to obey Ints do not obey those laws, either. It is not exceptionally hard to write reliable software using ints. You just have to check for exceptional conditions. That's also the case for floating point. That said, I suspect that 90% of programs that use float and double would be much better off using something else. The only reason to use floating point is performance. > This is leaving aside all sorts of machine strangeness, like the student > whose neural net program started running hundreds of times slower than > he expected. I advised him to replace > s = 0; > for (i = 0; i < n; i++) s += x[i]*x[i]; > by > s = 0; > for (i = 0; i < n; i++) > if (fabs(x[i]) > 1e-19) > s += x[i]*x[i]; > and the problem went away. Dear reader: do you know why I expected this > problem, what it was, and why this is NOT a general solution? I guess it trapped on creating denormals. But again, presumably the reason the student used doubles here was because he wanted his program to be fast. Had he read just a little bit about floating point, he would have known that it is *not* fast under certain conditions. As it were, he seems to have applied what he though was an optimisation (using floating point) without knowing anything about it. A professional programmer would get (almost) no sympathy in such a situation. Roman From westondan at imageworks.com Wed Feb 13 21:23:07 2008 From: westondan at imageworks.com (Dan Weston) Date: Wed Feb 13 21:21:52 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <05B7D634-41DC-4618-8A0A-DF05123A4528@cs.otago.ac.nz> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <6a7c66fc0802040422t12d24746u62ee0b4a39706fba@mail.gmail.com> <47B0B3BE.4010601@charter.net> <200802121121.23809.g9ks157k@acme.softbase.org> <05B7D634-41DC-4618-8A0A-DF05123A4528@cs Message-ID: <47B3A60B.2020809@imageworks.com> Richard A. O'Keefe wrote: > Concerning "parametrized" vs "parameterized" > On 12 Feb 2008, at 11:21 pm, Wolfgang Jeltsch asked: >> What spelling is more common? > > Strictly speaking, there is no such word in English as "parametrized". Except that, strictly speaking, there *is* a word "parametrized" in English. I have read and heard it from many (at least 10) independent uses by educated native writers of English. I use it myself. Merriam-Webster agrees with me [1]. The OED editorial board is no Acad?mie Anglaise: its criterion is descriptive, not prescriptive, by its own admission [2]. Whether a spelling is accepted by the OED has nothing to do with morphological rules (or "proper" usage) and everything to do with established usage. That is why we say "impulse" but not "compulse", the antonym of "increment" is not "excrement", we have "electrify/liquify" but "electrification/liquefaction", "duh" and "no duh" are near-synonyms, etc. To directly answer Wolfgang's question: "parameterized" is the more common. It is "more correct" only insofar as it is the more common. [1] http://www.merriam-webster.com/dictionary/parametrized Main Entry: pa?ram?e?ter?ize Pronunciation: \p?-?ra-m?-t?-?ri-z, -m?-?tri-z\ Variant(s): or pa?ram?e?trize \-?ra-m?-?tri-z\ Function: transitive verb Inflected Form(s): pa?ram?e?ter?ized or pa?ram?e?trized; pa?ram?e?ter?iz?ing or pa?ram?e?triz?ing Date: 1940 : to express in terms of parameters [2] http://www.oed.com/about/writing/choosing.html "...a new word is not included in the OED unless it has "caught on" and become established in the language. Words that are only used for a short period of time, or by a very small number of people, are not included." Dan Richard A. O'Keefe wrote: > Concerning "parametrized" vs "parameterized" > On 12 Feb 2008, at 11:21 pm, Wolfgang Jeltsch asked: >> What spelling is more common? > > Strictly speaking, there is no such word in English as "parametrized". > There is no general morphological rule "Xer => Xrized" in English. > The only spelling accepted by the OED is "parameterized", > which annoys me because I prefer the -ise- spelling. > > Amusingly, one of the quotations in the www.oed.com entry for > "parameterized" actually spells it "parametrized"; I don't know whether > the source had it that way or whether the data entry error was at the OED. From jerzy.karczmarczuk at info.unicaen.fr Wed Feb 13 22:31:00 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Wed Feb 13 22:29:34 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B39936.10509@cse.unsw.edu.au> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> Message-ID: Trialog: Roman Leshchinskiy writes: > Richard A. O'Keefe wrote: >> jerzy.karczmarczuk@info.unicaen.fr wrote: >>> Would you say that *no* typical floating-point software is reliable? >> >> With lots of hedging and clutching of protective amulets around the >> word "reliable", of course not. What I *am* saying is that >> (a) it's exceptionally HARD to make reliable because although the >> operations >> are well defined and arguably reasonable they do NOT obey the laws that >> school and university mathematics teach us to expect them to obey > > Ints do not obey those laws, either. It is not exceptionally hard to write > reliable software using ints. You just have to check for exceptional > conditions. That's also the case for floating point. > > That said, I suspect that 90% of programs that use float and double would > be much better off using something else. The only reason to use floating > point is performance. I have a bit different perspective... First, when I see the advice "use something else", I always ask "what", and I get an answer very, very rarely... Well? What do you propose? Then, the problem is not always pathological, in the sense of "exceptional conditions". There are touchy points related to the stability of the algorithms for the solution of differential equations. There are doubtful random number generators in Monte-Carlo business. There are ill-conditioned matrices and screwed-up iterative definitions. Algorithms work, work, and ultimately explode or produce rubbish. The "laws" which get broken are "almost" respected for a long time, and then we have the Bald Man (Sorites) paradox... RAO'K very wisely says that people should avoid reinventing wheels, and they should use established packages, written by people who know. The problem *here* is that we would like to have something fabulous in Haskell - for example... And there aren't too many experts, who would convert to the Functional Religion just for fun. What is *much worse*, some potential users who could encourage building such packages in the numerical domain, typically don't believe that FP gives anything interesting. At least, this is the opinion of physicists I spoke to recently. Never mind. We shall dance over their cadavers, unless they dance over ours. In both cases we shall be happy. Jerzy Karczmarczuk From ok at cs.otago.ac.nz Wed Feb 13 22:36:49 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed Feb 13 22:35:25 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B39936.10509@cse.unsw.edu.au> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> Message-ID: <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> On 14 Feb 2008, at 2:28 pm, Roman Leshchinskiy wrote: > Richard A. O'Keefe wrote: >> On 12 Feb 2008, at 5:14 pm, jerzy.karczmarczuk@info.unicaen.fr wrote: >>> Would you say that *no* typical floating-point software is reliable? >> With lots of hedging and clutching of protective amulets around the >> word "reliable", of course not. What I *am* saying is that >> (a) it's exceptionally HARD to make reliable because although the >> operations >> are well defined and arguably reasonable they do NOT obey the >> laws that >> school and university mathematics teach us to expect them to obey > > Ints do not obey those laws, either. They obey a heck of a lot more of them. Any combination of Ints using (+), (-), (*), and negate is going to be congruent to the mathematically correct answer modulo 2**n for some n. In particular, (+) is associative for Ints. > It is not exceptionally hard to write reliable software using ints. I did my BSc and MSc computing on a B6700, where the hardware *always* notified you in case of an integer overflow. In that case, it was perfectly easy to write reliable software. You just pretended that the type 'INTEGER' in your program meant 'mathematical integer', and if that got you into trouble, the machine was certain to tell you about it. Using languages that do not check for integer overflow, even on hardware (like, as it happens, both the different machines on my desk) that makes it cheap to do so, I *have* had trouble with multiplying two positive integers and getting a negative rules and also with a program that went into an infinite loop because it happened to multiply two positive numbers and get another positive number that was smaller than the one it started with. There's also the problem dividing two negative integers can give you a negative result. And one problem I definitely ran into was a Pascal 'for' loop with positive bounds that ran forever. When I contrast the amount of manual checking I have to do when writing C (or, for that matter, Haskell) with the amount of manual checking I have to do when using Smalltalk or SETL or Lisp, and when I remember how life was *better* for me in this respect back in the 70s, well, it doesn't make me happy. This would be my top priority request for Haskell': require that the default Int type check for overflow on all operations where overflow is possible, provide Int32, Int64 for people who actually *want* wraparound. I've been told that there was a day when there was serious trouble in the US financial markets because the volume of trade exceeded the 32-bit signed integer limit, and many programs started giving nonsense results. But the Smalltalk programs just kept powering on... > You just have to check for exceptional conditions. Why should it be *MY* job to check for exceptional conditions? That's the *MACHINE*'s job. When you bought your computer, you paid for hardware that will do this job for you! > That's also the case for floating point. If you think that, you do not understand floating point. x+(y+z) == (x+y)+z fails even though there is nothing exceptional about any of the operands or any of the results. I have known a *commercial* program blithely invert a singular matrix because of this kind of thing, on hardware where every kind of arithmetic exception was reported. There were no "exceptional conditions", the answer was just 100% wrong. > I guess it trapped on creating denormals. But again, presumably the > reason the student used doubles here was because he wanted his > program to be fast. Had he read just a little bit about floating > point, he would have known that it is *not* fast under certain > conditions. Well, no. Close, but no cigar. (a) It wasn't denormals, it was underflow. (b) The fact underflow was handled by trapping to the operating system, which then completed the operating by writing a 0.0 to the appropriate register, is *NOT* a universal property of floating point, and is *NOT* a universal property of IEEE floating point. It's a fact about that particular architecture, and I happened to have the manual and he didn't. (c) x*x => 0 when x is small enough *is* fast on a lot of machines. > As it were, he seems to have applied what he though was an > optimisation (using floating point) without knowing anything about > it. A professional programmer would get (almost) no sympathy in > such a situation. You must be joking. Almost everybody working with neural nets uses floating point. (One exception I came across was some people using special vector processor hardware that didn't *have* floating point. These days, you could probably use a programmable GPU to good effect.) For neural net calculations, you have to do lots of dot products. When this example happened, machines were commonly 32 bit, not 64 bit. So doing the calculations in integers would (a) have limited him to 16 bits for the coefficients, instead of double's 53. This might just have been enough of a limit to prevent learning the kinds of things he wanted his net to learn. Actually, if you want to do a dot product on n-vectors, you need enough bits for n as well. Suppose you have 100 inputs, then you'll need 7 bits for that, so you are limited to (31-7)/2 = 12 bits, which is dangerously low. (doubles can do precise sums of up to 128 products of coefficients with up to 23 bits). (b) integer multiplication was very slow on that machine. On most modern machines, integer multiplication is quite slow compared with add, because architects look at C benchmarks and conclude that multiplication isn't important. So programmers learn to do multiply-heavy calculations in floating point, so the benchmarks show less integer multiplication, so the architects let integer multiply get relatively slower, and .... (c) the sigmoid function *has* to be done in floating point arithmetic. In fact I *wanted* him to use integer operations so that he could exploit the new-at-the-time graphics instructions (think MMX), but the project foundered on this step. He couldn't get a workable approximation of the sigmoid function using integers that didn't kill performance. (d) Much of the calculation needed for neural nets can be done using the Basic Linear Algebra Subroutines, which are available in seriously tuned form for most modern machines. If a programmer *didn't* use these (floating-point-only) libraries, I would be asking why not. If you are aware of any neural net software for general purpose hardware done by programmers you consider competent that *doesn't* use floating point, I would be interested to hear about it. From rl at cse.unsw.edu.au Wed Feb 13 23:00:15 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Feb 13 22:58:55 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> Message-ID: <47B3BCCF.7080306@cse.unsw.edu.au> jerzy.karczmarczuk@info.unicaen.fr wrote: > Trialog: > Roman Leshchinskiy writes: >> Richard A. O'Keefe wrote: > >>> jerzy.karczmarczuk@info.unicaen.fr wrote: >>>> Would you say that *no* typical floating-point software is reliable? >>> >>> With lots of hedging and clutching of protective amulets around the >>> word "reliable", of course not. What I *am* saying is that >>> (a) it's exceptionally HARD to make reliable because although the >>> operations >>> are well defined and arguably reasonable they do NOT obey the laws that >>> school and university mathematics teach us to expect them to obey >> >> Ints do not obey those laws, either. It is not exceptionally hard to >> write reliable software using ints. You just have to check for >> exceptional conditions. That's also the case for floating point. >> That said, I suspect that 90% of programs that use float and double >> would be much better off using something else. The only reason to use >> floating point is performance. > > I have a bit different perspective... > First, when I see the advice "use something else", I always ask "what", > and I get an answer very, very rarely... Well? What do you propose? For Haskell, Rational seems like a good choice. The fact that the standard requires defaulting to Double is quite unfortunate and inconsistent, IMO; the default should be Rational. Float and Double shouldn't even be in scope without an explicit import. There really is no good reason to use them unless you are writing a binding to existing libraries or really need the performance. > Then, the problem is not always pathological, in the sense of "exceptional > conditions". There are touchy points related to the stability of the > algorithms for the solution of differential equations. There are doubtful > random number generators in Monte-Carlo business. There are ill-conditioned > matrices and screwed-up iterative definitions. Algorithms work, work, and > ultimately explode or produce rubbish. The "laws" which get broken are > "almost" respected for a long time, and then we have the Bald Man (Sorites) > paradox... > RAO'K very wisely says that people should avoid reinventing wheels, and > they should use established packages, written by people who know. Yes, I completely agree with that (even though my original email probably didn't sound as if I did). My point was that (a) most people don't need floating point and (b) those who do need it should learn how to use it. > The problem *here* is that we would like to have something fabulous in > Haskell - for example... I think we mostly have it already. Roman From rl at cse.unsw.edu.au Thu Feb 14 00:01:17 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Feb 13 23:59:55 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> Message-ID: <47B3CB1D.6040404@cse.unsw.edu.au> Richard A. O'Keefe wrote: > > On 14 Feb 2008, at 2:28 pm, Roman Leshchinskiy wrote: > >> Richard A. O'Keefe wrote: >>> On 12 Feb 2008, at 5:14 pm, jerzy.karczmarczuk@info.unicaen.fr wrote: >>>> Would you say that *no* typical floating-point software is reliable? >>> With lots of hedging and clutching of protective amulets around the >>> word "reliable", of course not. What I *am* saying is that >>> (a) it's exceptionally HARD to make reliable because although the >>> operations >>> are well defined and arguably reasonable they do NOT obey the >>> laws that >>> school and university mathematics teach us to expect them to obey >> >> Ints do not obey those laws, either. > > They obey a heck of a lot more of them. > Any combination of Ints using (+), (-), (*), and negate > is going to be congruent to the mathematically correct answer modulo 2**n > for some n. In particular, (+) is associative for Ints. Yes, but neither school nor, for the most part, university mathematics teach us to expect modulo arithmetic. Good programmers learn about it at some point in their carreer, though, and write their programs accordingly. If they intend to use floating point, they should learn about it, too. I do agree that most programmers don't know how to use floats properly and aren't even aware that they can be used improperly. But that's an educational problem, not a problem with floating point. > This would be my top priority request for Haskell': > require that the default Int type check for overflow on all > operations where overflow is possible, > provide Int32, Int64 for people who actually *want* wraparound. I don't understand this. Why use a type which can overflow in the first place? Why not use Integer? >> You just have to check for exceptional conditions. > > Why should it be *MY* job to check for exceptional conditions? It shouldn't unless you use a type whose contract specifies that it's your job to check for them. Which is the case for Int, Float and Double. It's not the case for Integer and Rational. > If you think that, you do not understand floating point. > x+(y+z) == (x+y)+z fails even though there is nothing exceptional about > any of the operands or any of the results. For all practical purposes, the semantics of (==) is not well defined for floating point numbers. That's one of the first things I used to teach my students about floats: *never* compare them for equality. So in my view, your example doesn't fail, it's undefined. That Haskell provides (==) for floats is unfortunate. > I have known a *commercial* program blithely invert a singular matrix > because of this kind of thing, on hardware where every kind of arithmetic > exception was reported. There were no "exceptional conditions", the > answer was just 100% wrong. If they used (==) for floats, then they simply didn't know what they were doing. The fact that a program is commercial doesn't mean it's any good. >> I guess it trapped on creating denormals. But again, presumably the >> reason the student used doubles here was because he wanted his program >> to be fast. Had he read just a little bit about floating point, he >> would have known that it is *not* fast under certain conditions. > > Well, no. Close, but no cigar. > (a) It wasn't denormals, it was underflow. "Creating denormals" and underflow are equivalent. Denormals are created as a result of underflow. A denormalised number is smaller than any representable normal number. When the result of an operation is too small to be represented by a normal number, IEEE arithmetic will either trap or return a denormal, depending on whether underflow is masked or not. > (b) The fact underflow was handled by trapping to the operating system, > which then completed the operating by writing a 0.0 to the appropriate > register, is *NOT* a universal property of floating point, and is *NOT* > a universal property of IEEE floating point. It's a fact about that > particular architecture, and I happened to have the manual and he > didn't. IIRC, underflow is a standard IEEE exception. > (c) x*x => 0 when x is small enough *is* fast on a lot of machines. Only if underflow is masked (which it probably is by default). Although I vaguely recall that denormals were/are slower on some architectures. >> As it were, he seems to have applied what he though was an >> optimisation (using floating point) without knowing anything about it. >> A professional programmer would get (almost) no sympathy in such a >> situation. > > You must be joking. Almost everybody working with neural nets uses > floating point. > > [...] > > If you are aware of any neural net software for general purpose hardware > done > by programmers you consider competent that *doesn't* use floating point, I > would be interested to hear about it. I'm not. But progammers I consider competent for this particular task know how to use floating point. Your student didn't but that's ok for a student. He had someone he could ask so hopefully, he'll know next time. To be clear, I do not mean to imply that programmers who do not know about floating point are incompetent. I'm only somewhat sceptical of programmers who do not know about it but still write software that relies on it. Roman From mad.one at gmail.com Thu Feb 14 00:11:25 2008 From: mad.one at gmail.com (Austin Seipp) Date: Thu Feb 14 00:10:03 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: References: <1202888791.5962.1.camel@jutaro-laptop> Message-ID: <1202965604-sup-3495@continuum> > gtk >=0.9.12, > glib >=0.9.12, > sourceview >=0.9.12, These are all apart of gtk2hs: http://haskell.org/gtk2hs/ For my build on Linux I had to pass a --enable-sourceview option to ./configure so that the sourceview package was picked up and built, but I figure it's probably picked up automatically if installed. On windows, I have no idea if the installer carries these things with it. > binary >=0.4.1 Binary can be found on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary -- "It was in the days of the rains that their prayers went up, not from the fingering of knotted prayer cords or the spinning of prayer wheels, but from the great pray-machine in the monastery of Ratri, goddess of the Night." Roger Zelazny From dave at zednenem.com Thu Feb 14 01:04:17 2008 From: dave at zednenem.com (David Menendez) Date: Thu Feb 14 01:02:56 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] In-Reply-To: <7ca3f0160802130236r3b478deasaa55fea87326a8f5@mail.gmail.com> References: <20080213093319.DF381A9B2@Adric.metnet.fnmoc.navy.mil> <7ca3f0160802130236r3b478deasaa55fea87326a8f5@mail.gmail.com> Message-ID: <49a77b7a0802132204q6f993c59g16bd27d1f6c7f1a4@mail.gmail.com> On Feb 13, 2008 5:36 AM, Luke Palmer wrote: > On Feb 13, 2008 9:33 AM, wrote: > > The approach is based on the final tagless representation. Here is our > > DSL: > > > > > class Exp repr where > > > constant :: Int -> repr Int > > > variable :: String -> repr Int > > > add :: repr Int -> repr Int -> repr Int > > > sub :: repr Int -> repr Int -> repr Int > > This is very nice. May I ask, though, what is the purpose of all the > Ints appearing as arguments to repr here? Looking over this code, it > seems that it would work just as well if they were all omitted. In this example, they could be omitted. But let's say you had a language more than one type: class Exp repr where constant :: Int -> repr Int variable :: String -> repr Int add :: repr Int -> repr Int -> repr Int sub :: repr Int -> repr Int -> repr Int true :: repr Bool false :: repr Bool and :: repr Bool -> repr Bool -> repr Bool less_than :: repr Int -> repr Int -> repr Bool if_ :: repr Bool -> repr a -> repr a -> repr a The argument to repr prevents you from writing ill-typed code like "if_ (variable "x") (constant 0) false". -- Dave Menendez From ok at cs.otago.ac.nz Thu Feb 14 01:05:32 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Feb 14 01:04:09 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B3CB1D.6040404@cse.unsw.edu.au> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> Message-ID: On 14 Feb 2008, at 6:01 pm, Roman Leshchinskiy wrote: > I don't understand this. Why use a type which can overflow in the > first place? Why not use Integer? Why is this hard to understand? Dijkstra's classic "A Discipline of Programming" distinguishes several kinds of machine. I'm quoting from memory here. A Sufficiently Large Machine is one which can run your program to completion giving correct answers all the way. An Insufficiently Large Machine is one which can't do that and silently goes crazy instead. A Hopefully Sufficiently Large Machine is one which *either* does what a Sufficiently Large Machine would have *or* reports that it couldn't. The good thing about an SLM is that it always gives you right answers (assuming your program is correct). The bad thing is that you can't afford it. The good thing about an ILM is that you can afford it. The bad thing is that you can't trust it. The great thing about a HSLM is that you can both trust and afford it. Presumably the reason for having Int in the language at all is speed. As people have pointed out several times on this list to my knowledge, Integer performance is not as good as Int performance, not hardly, and it is silly to pay that price if I don't actually need it. The thing about using SafeInt is that I should get the *same* space and speed from SafeInt as I do from Int, or at the very least the same space and far better speed than Integer, while at the same time EITHER the results are the results I would have got using Integer *OR* the system promises to tell me about it, so that I *know* there is a problem. SafeInt is what you should use when you *THINK* your results should all fit in a machine int but aren't perfectly sure. (And this is nearly all the time.) Int is what you should use when you don't give a damn what the results are as long as you get them fast. (But in that case, why not use C or assembler?) > >>> You just have to check for exceptional conditions. >> Why should it be *MY* job to check for exceptional conditions? > > It shouldn't unless you use a type whose contract specifies that > it's your job to check for them. Which is the case for Int, Float > and Double. Wrong. You're confusing two things here. One is Float and Double, where we get in serious trouble WITHOUT ANY EXCEPTIONAL CONDITIONS IN SIGHT. The other is Int overflow. There may also be an equivocation on 'checking'. When was the last time you proved that a large program would not incur an integer overflow? When was the last time you proved that a library package would not incur integer overflow provided it was called in accord with its contract. When was the last time you even *found* a sufficiently informative contract in someone else's Haskell code? The checking I am talking about is done by the hardware at machine speeds and provides *certainty* that overflow did not occur. > It's not the case for Integer and Rational. > >> If you think that, you do not understand floating point. >> x+(y+z) == (x+y)+z fails even though there is nothing exceptional >> about >> any of the operands or any of the results. > > For all practical purposes, the semantics of (==) is not well > defined for floating point numbers. With respect to IEEE arithmetic, wrong. > That's one of the first things I used to teach my students about > floats: *never* compare them for equality. That's one of the warning signs I watch out for. "Never compare floats for equality" is a sure sign of someone who thinks they know about floats but don't. > So in my view, your example doesn't fail, it's undefined. That > Haskell provides (==) for floats is unfortunate. The operation is well defined and required by the IEEE standard. > > If they used (==) for floats, then they simply didn't know what > they were doing. The fact that a program is commercial doesn't mean > it's any good. Er, we weren't talking about (==) for floats; I don't know where you got that. I never said it was any good; quite the opposite. My point is that bad software escaped into the commercial market because floating point doesn't follow the laws people expect it to. > >>> I guess it trapped on creating denormals. But again, presumably >>> the reason the student used doubles here was because he wanted >>> his program to be fast. Had he read just a little bit about >>> floating point, he would have known that it is *not* fast under >>> certain conditions. >> Well, no. Close, but no cigar. >> (a) It wasn't denormals, it was underflow. > > "Creating denormals" and underflow are equivalent. No they are not. Underflow in this sense occurs when the result is too small to be even a denormal. (The IEEE exceptions Underflow and Inexact are not the same. Creating denormals is likely to trigger Inexact but should not trigger Underflow. I am talking only about a condition that triggered Underflow.) > Denormals are created as a result of underflow. A denormalised > number is smaller than any representable normal number. When the > result of an operation is too small to be represented by a normal > number, IEEE arithmetic will either trap or return a denormal, > depending on whether underflow is masked or not. No, we're talking about a situation where returning a denormal is not an option because there is no suitable denormal. This is underflow. > >> (b) The fact underflow was handled by trapping to the operating >> system, >> which then completed the operating by writing a 0.0 to the >> appropriate >> register, is *NOT* a universal property of floating point, and >> is *NOT* >> a universal property of IEEE floating point. It's a fact >> about that >> particular architecture, and I happened to have the manual and >> he didn't. > > IIRC, underflow is a standard IEEE exception. Underflow is indeed a standard IEEE exception. Like other standard IEEE exceptions, it is *disabled by default*. In this case, the hardware delivered the exception *to the operating system*, but the operating system did not deliver it to the *user code*. It is the *combination* of hardware and operating system that conforms to the IEEE standard (or not). So we are talking about a situation where the only legal IEEE outcomes are "return 0.0" or "raise the Underflow exception" and where raising an exception *in the user code* wasn't allowed and didn't happen. The hardware is allowed to trap to the operating system any time it feels like, for any reason (like 'this model doesn't support the SQRTD instruction') or none (hey, it's a Friday, I think I'll generate traps). The knowledge I had, and the student lacked, was *not* knowledge about an interface (the IEEE specification) but about an implementation. There's a lot of Haskell code out there with no performance guides in the documentation... > I'm not. But progammers I consider competent for this particular > task know how to use floating point. Your student didn't but that's > ok for a student. Wrong. He *did* know "how to use floating point", and his code would have run at the expected speed on other hardware. It gave pretty good answers. What he didn't know was how one particular machine struck the balance between hardware and software. I wonder just how many programmers these days think Double.(*) is _always_ a cheap hardware instruction? Returning to our theme: the programmer expectation here is "a simple cost model." Violating that expectation led to a program with a huge unexpected cost problem. In the same way, violating other programmer expectations is likely to lead to unexpected correctness problems. From lrpalmer at gmail.com Thu Feb 14 03:47:13 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Feb 14 03:45:46 2008 Subject: [Haskell-cafe] a general question on Arrows In-Reply-To: References: Message-ID: <7ca3f0160802140047x796e75b3x5783a0ee43ac94c3@mail.gmail.com> On Thu, Feb 14, 2008 at 12:50 AM, Steve Lihn wrote: > He described a few things that "cannot" be represented as a monad, they are: > 1. Stream This is actually a comonad. > 2. FRP Depends on which FRP you're talking about. This could be the stream comonoad + the event monad. Here's another fun arrow: http://luqui.org/blog/archives/2007/09/06/quantum-entanglement-in-haskell/ Luke From jed at 59A2.org Thu Feb 14 04:04:05 2008 From: jed at 59A2.org (Jed Brown) Date: Thu Feb 14 04:01:50 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B3BCCF.7080306@cse.unsw.edu.au> (Roman Leshchinskiy's message of "Thu, 14 Feb 2008 15:00:15 +1100") References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <47B3BCCF.7080306@cse.unsw.edu.au> Message-ID: <87pruzzz7e.fsf@59A2.org> On 14 Feb 2008, rl@cse.unsw.edu.au wrote: > > jerzy.karczmarczuk@info.unicaen.fr wrote: > > Trialog: > > Roman Leshchinskiy writes: > >> Richard A. O'Keefe wrote: > > > >>> jerzy.karczmarczuk@info.unicaen.fr wrote: > >>>> Would you say that *no* typical floating-point software is reliable? > >>> > >>> With lots of hedging and clutching of protective amulets around the > >>> word "reliable", of course not. What I *am* saying is that > >>> (a) it's exceptionally HARD to make reliable because although the operations > >>> are well defined and arguably reasonable they do NOT obey the laws that > >>> school and university mathematics teach us to expect them to obey > >> > >> Ints do not obey those laws, either. It is not exceptionally hard to write > >> reliable software using ints. You just have to check for exceptional > >> conditions. That's also the case for floating point. > >> That said, I suspect that 90% of programs that use float and double would be > >> much better off using something else. The only reason to use floating point > >> is performance. > > > > I have a bit different perspective... > > First, when I see the advice "use something else", I always ask "what", > > and I get an answer very, very rarely... Well? What do you propose? > > For Haskell, Rational seems like a good choice. The fact that the standard > requires defaulting to Double is quite unfortunate and inconsistent, IMO; the > default should be Rational. Float and Double shouldn't even be in scope without > an explicit import. There really is no good reason to use them unless you are > writing a binding to existing libraries or really need the performance. Until you need to evaluate a transcendental function. Floating point numbers are remarkably well-behaved in the following sense. Fundamental Axiom of Floating Point Arithmetic (Trefethen & Bau, 1997) For all x,y in F, there exists e with |e| <= e_machine such that x <*> y = (x * y) (1 + e) where F is the set of real numbers in a particular floating point representation, <*> represents any hardware arithmetic operation and * is the corresponding exact operation. This is satisfied by nearly all floating point implementations, with somewhat stronger conditions for IEEE. It is easily extended to complex arithmetic, perhaps after scaling e_machine by a small factor. This single axiom is sufficient for all stability (with regard to rounding error) results of numerical algorithms. Double precision has 15 significant digits. It is a very rare physical quantity that can be measured to 10 significant digits and this is unlikely to change in the next 100 years. It is a rare algorithm for which floating point arithmetic is a problem. Occasionally we must make decisions, such as choosing which way to project during Householder QR, so that rounding error is not a problem. Unfortunately, Gaussian Elimination is an important (only because it happens to be fast) algorithm which suffers From rounding error. Since there are well conditioned matrices for which Gaussian Elimination fails spectacularly despite pivoting, many people believe that rounding error is a major part of numerical analysis. This is absolutely not the case; it is less than 10% of the field. Of course, if you are not trying to represent arbitrary real numbers, using floating point may be a mistake. Converting between integer or rational representations and floating point requires careful attention. As long as you stay in floating point, it is almost never a problem. Remember that it is not possible to implement exact real arithmetic so that equality is decidable. We should take this as a sign that equality for floating point arithmetic is dangerous to rely upon. Floating point is extremely useful and I think it would be a mistake to remove it from the Prelude. One thing I would like to see is the Enum instances removed. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080214/10836754/attachment.bin From rl at cse.unsw.edu.au Thu Feb 14 04:24:02 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Feb 14 04:22:44 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> Message-ID: <47B408B2.3090900@cse.unsw.edu.au> Richard A. O'Keefe wrote: > On 14 Feb 2008, at 6:01 pm, Roman Leshchinskiy wrote: >> I don't understand this. Why use a type which can overflow in the >> first place? Why not use Integer? > > [...] > > Presumably the reason for having Int in the language at all is speed. > As people have pointed out several times on this list to my knowledge, > Integer performance is not as good as Int performance, not hardly, > and it is silly to pay that price if I don't actually need it. Do I understand correctly that you advocate using overflowing ints (even if they signal overflow) even if Integers are fast enough for a particular program? I strongly disagree with this. It's premature optimisation of the worst kind - trading correctness for unneeded performance. > SafeInt is what you should use when you *THINK* your results should all fit > in a machine int but aren't perfectly sure. (And this is nearly all the > time.) Again, I strongly disagree. You should use Integer unless your program is too slow and profiling shows that Integer is the culprit. If and only if that is the case should you think about alternatives. That said, I doubt that your SafeInt would be significantly faster than Integer. >>>> You just have to check for exceptional conditions. >>> Why should it be *MY* job to check for exceptional conditions? >> >> It shouldn't unless you use a type whose contract specifies that it's >> your job to check for them. Which is the case for Int, Float and Double. > > Wrong. You're confusing two things here. One is Float and Double, > where we get in serious trouble WITHOUT ANY EXCEPTIONAL CONDITIONS IN > SIGHT. The other is Int overflow. I'm not sure what I'm confusing here, my comment referred specifically to exceptional conditions which floats provide plenty of. As to getting in trouble, I don't need floats for that, I manage to do it perfectly well with any data type including (). Seriously, though, I think we agree that using floating point numbers correctly isn't trivial, people who do that should know what they are doing and should best use existing libraries. I just don't see how floats are special in this regard. > The checking I am talking about is done by the hardware at machine speeds > and provides *certainty* that overflow did not occur. So you advocate using different hardware? >>> If you think that, you do not understand floating point. >>> x+(y+z) == (x+y)+z fails even though there is nothing exceptional about >>> any of the operands or any of the results. >> >> For all practical purposes, the semantics of (==) is not well defined >> for floating point numbers. > > With respect to IEEE arithmetic, wrong. Yes, IEEE does define an operation which is (wrongly, IMO) called "equality". It's not a particularly useful operation (and it is not equality), but it does have a defined semantics. However, the semantics of (==) on floats isn't really defined in Haskell or C, for that matter, even if you know that the hardware is strictly IEEE conformant. In general, floating point numbers do not really have a useful notion of equality. They are approximations, after all, and independently derived approximations can only be usefully tested for approximate equality. And yes, x+(y+z) is approximately equal to (x+y)+z for floats. How approximate depends on the particular values, of course. >> That's one of the first things I used to teach my students about >> floats: *never* compare them for equality. > > That's one of the warning signs I watch out for. "Never compare floats for > equality" is a sure sign of someone who thinks they know about floats > but don't. Hmm. Personally, I've never seen an algorithm where comparing for exact equality was algorithmically necessary. Sometimes (rarely) it is acceptable but necessary? Do you know of one? On the other hand, there are a lot of cases where comparing for exact equality is algorithmically wrong. As an aside, you might want to try googling for "Never compare floats for equality". I'm positive some of those people *do* know about floats. >> "Creating denormals" and underflow are equivalent. > > No they are not. Underflow in this sense occurs when the result is too > small to be even a denormal. I'm fairly sure that IEEE underflow occurs when the result cannot be represented by a *normal* number but I don't have a copy of the standard. Anyway, it's not important for this discussion, I guess. > Underflow is indeed a standard IEEE exception. Like other standard IEEE > exceptions, it is *disabled by default*. In this case, the hardware > delivered the exception *to the operating system*, but the operating > system did not deliver it to the *user code*. It is the *combination* > of hardware and operating system that conforms to the IEEE standard (or > not). > So we are talking about a situation where the only legal IEEE outcomes are > "return 0.0" or "raise the Underflow exception" and where raising an > exception > *in the user code* wasn't allowed and didn't happen. Now I'm curious. I would have guessed that it was an Alpha but that would behave differently (it would trap on underflow, but only in strict IEEE mode and only because it actually implemented flush to zero instead of gradual underflow). >> I'm not. But progammers I consider competent for this particular task >> know how to use floating point. Your student didn't but that's ok for >> a student. > > Wrong. He *did* know "how to use floating point", and his code would have > run at the expected speed on other hardware. It gave pretty good answers. Wrt speed - not necessarily. For instance, x86 is really bad when it comes to denormals. Have a look at http://www.cygnus-software.com/papers/x86andinfinity.html for instance. So while he knew how to get good results with floating point, he didn't know how to get good performance. Which, as you say, is not part of the IEEE standard but which you still have to know if you use floats. Roman From g9ks157k at acme.softbase.org Thu Feb 14 04:40:25 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 14 04:39:31 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized =?utf-8?q?vectors=09?=(=?utf-8?q?using=09datatype?= algebra?) In-Reply-To: <47B3A60B.2020809@imageworks.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <05B7D634-41DC-4618-8A0A-DF05123A4528@cs <47B3A60B.2020809@imageworks.com> Message-ID: <200802141040.25292.g9ks157k@acme.softbase.org> Am Donnerstag, 14. Februar 2008 03:23 schrieben Sie: > To directly answer Wolfgang's question: "parameterized" is the more > common. It is "more correct" only insofar as it is the more common. So we should ?parameterized? for the package name. Best wishes, Wolfgang From ajb at spamcop.net Thu Feb 14 05:20:11 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Feb 14 05:18:43 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B408B2.3090900@cse.unsw.edu.au> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> Message-ID: <20080214052011.vdcelmp6yo8c84c4@webmail.spamcop.net> G'day all. Richard A. O'Keefe wrote: >> That's one of the warning signs I watch out for. "Never compare floats for >> equality" is a sure sign of someone who thinks they know about >> floats but don't. Quoting Roman Leshchinskiy : > Hmm. Personally, I've never seen an algorithm where comparing for exact > equality was algorithmically necessary. One trick I've occasionally used is to avoid the need for a discriminated union of floating point and integer types by just using a floating point number. If you ignore bitwise operations and division/remainder, any integer operation that doesn't cause overflow on 32-bit integers will work just the same if you use IEEE-754 64-bit floating point numbers instead. That includes equality. Moreover, you even get a few more significant bits of precision. In these days of fast 64 and 128 bit words, it might not be entirely moral, but it works. Cheers, Andrew Bromage From alistair at abayley.org Thu Feb 14 06:14:52 2008 From: alistair at abayley.org (Alistair Bayley) Date: Thu Feb 14 06:13:27 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: <1202888791.5962.1.camel@jutaro-laptop> References: <1202888791.5962.1.camel@jutaro-laptop> Message-ID: <79d7c4980802140314r53258529s96a43b774f0d2621@mail.gmail.com> > Leksah is written by me and published under a GPL-2 license. > Leksah can be optained via Hackage: http://hackage.haskell.org/ > Darcs development repository: http://code.haskell.org/leksah I just downloaded this from hackage and went through the usual Cabal ritual. The build fails with [16 of 41] Compiling IDE.Utils.File ( src/IDE/Utils/File.hs, dist\build\leksah\leksah-tmp/IDE/Utils/File.o ) src/IDE/Utils/File.hs:161:33: Couldn't match expected type `Either String String' against inferred type `String' In the expression: if takeExtension fp == ".lhs" then unlit fp str else str In the definition of `str'': str' = if takeExtension fp == ".lhs" then unlit fp str else str In the expression: if exists then do str <- readFile fp let str' = ... let parseRes = ... .... else return Nothing Would I be better off getting straight from the darcs repo? Alistair From alistair at abayley.org Thu Feb 14 06:17:06 2008 From: alistair at abayley.org (Alistair Bayley) Date: Thu Feb 14 06:15:39 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: <79d7c4980802140314r53258529s96a43b774f0d2621@mail.gmail.com> References: <1202888791.5962.1.camel@jutaro-laptop> <79d7c4980802140314r53258529s96a43b774f0d2621@mail.gmail.com> Message-ID: <79d7c4980802140317v32b8233cwda1f62baf533ceab@mail.gmail.com> On 14/02/2008, Alistair Bayley wrote: > > src/IDE/Utils/File.hs:161:33: > Couldn't match expected type `Either String String' > against inferred type `String' Never mind; I've just realised this is because I have the latest dev version of Cabal installed. Alistair From ithika at gmail.com Thu Feb 14 06:18:17 2008 From: ithika at gmail.com (Dougal Stanton) Date: Thu Feb 14 06:16:56 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: <79d7c4980802140314r53258529s96a43b774f0d2621@mail.gmail.com> References: <1202888791.5962.1.camel@jutaro-laptop> <79d7c4980802140314r53258529s96a43b774f0d2621@mail.gmail.com> Message-ID: <2d3641330802140318n651e5207p508a722998fe9d22@mail.gmail.com> On 14/02/2008, Alistair Bayley wrote: > I just downloaded this from hackage and went through the usual Cabal > ritual. The build fails with > .... > Would I be better off getting straight from the darcs repo? I compiled from the darcs repo last night, which worked fine. -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From alfonso.acosta at gmail.com Thu Feb 14 07:27:13 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Feb 14 07:25:49 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802112014.31024.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802101743.41443.g9ks157k@acme.softbase.org> <6a7c66fc0802110917v4b34649dl62d843c925bfa16@mail.gmail.com> <200802112014.31024.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802140427x142b5448k42b4b23cb323fb9c@mail.gmail.com> I asked Oleg regarding the use of GADTs to emulate dependent types. My conclusion is that I should forget about them. Here is the full answer: ---------- Forwarded message ---------- From: Date: Feb 12, 2008 8:49 AM Subject: Re: GADTs to emulate dependent types? To: alfonso.acosta@gmail.com Hello! > The main question is whether it is feasible to use GADTs to define > fixed-sized vectors or not. The motivation behind it is to avoid > needing to code your own trusted core and use the compiler typechecker > for that purpose instead. That is a false proposition. In Haskell, any code that uses GADT *MUST* use a run-time test (run-time pattern match). Otherwise, the code is unsound and provides no guarantees. The particular value of a GADT data type is a witness of a proposition expressed in the type of GADT (e.g., type equality). Since it is possible in Haskell to fake this witness (just write undefined), if you don't check the witness at run-time, that is, test that the witness is a real value rather than undefined, you don't get any guarantees. That is why the irrefutable pattern-match does not work with GADT. Incidentally, the first implementation of GADT in GHC did permit irrefutable pattern-match, which did let one write unsound code (that is, code that gave segmentation fault): http://okmij.org/ftp/Haskell/GADT-problem.hs The issue is not present in Coq, for example, whose core calculus is sound and you cannot fake the evidence. Thus, the unsoundness of Haskell (the presence of undefined) mandates the run-time test for any code that uses GADT. So, GADTs are fundamentally less efficient than the typeclasses; the latter can provide assurances that can be checked at compile-time only, with no run-time artifacts. > data FSVec :: * -> * -> * where > NullV :: FSVec D0 a > (:>) :: Succ s s' => a -> FSVec s a -> FSVec s' a That is an old problem, and a difficult problem. In Singapore I was talking to Zhaohui Luo (you can look him up on Google), who said that the problem of asserting two types being equal (that is, Succ D0 being equal to D1) is a very tough one. Conor McBride have written a paper on observational equality -- but this is not Haskell. So, I don't think this approach works. Cheers, Oleg From jerzy.karczmarczuk at info.unicaen.fr Thu Feb 14 07:42:07 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Thu Feb 14 07:40:40 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <87pruzzz7e.fsf@59A2.org> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <47B3BCCF.7080306@cse.unsw.edu.au> <87pruzzz7e.fsf@59A2.org> Message-ID: Jed Brown comments the answer of - -- Roman Leshchinskiy who answers my question concerning the replacement of floating-point numbers: >> > First, when I see the advice "use something else", I always ask "what", >> > and I get an answer very, very rarely... Well? What do you propose? >> For Haskell, Rational seems like a good choice. The fact that the >> standard requires defaulting to Double is quite unfortunate and >> inconsistent, IMO; the default should be Rational. Float and Double >> shouldn't even be in scope without an explicit import. There really >> is no good reason to use them unless you are >> writing a binding to existing libraries or really need the performance. Here Jed Brown says: > Until you need to evaluate a transcendental function. ... It would be killing, wouldn't it?... I would say more. It is known that in randomly taken, usual formulae in physics, engineering, etc., if you start with rationals, *typically* the GCD between numerator and denominator will be small, the reductions of fractions are not very effective. Your rationals explode very fast! If after some reasonable number of operations you get rationals whose num/den have millions of digits, the program becomes *completely useless*, this is not "just" the questions of performance. Richard O'Keefe said that people speculate about floating-point numbers without knowing them. Well, nobody is perfect... I am a bit disturbed by people, who speculate without ever *needing* fl.p's, and who haven't thus the sensibility. For them this is a kind of game. Well, it isn't. R.L. says: > For all practical purposes, the semantics of (==) is not well defined > for floating point numbers. That's one of the first things I used to > teach my students about floats: *never* compare them for equality. > So in my view, your example doesn't fail, it's undefined. > That Haskell provides (==) for floats is unfortunate. I disagree, on practical basis. Floating-point numbers are very well defined, we know how the mantissa is represented. If the numbers are normalized, as they should, plenty of low-level iterative algorithms may use the equality - after some operation - to check that the machine- precision convergence has been obtained. On the contrary, the verification that the absolute value between two terms is less than some threshold, may be arbitrary or dubious. Jerzy Karczmarczuk From grzegorz.chrupala at computing.dcu.ie Thu Feb 14 07:56:39 2008 From: grzegorz.chrupala at computing.dcu.ie (Grzegorz Chrupala) Date: Thu Feb 14 07:55:10 2008 Subject: [Haskell-cafe] Stack overflow Message-ID: <15479718.post@talk.nabble.com> Hi all, I have a very simple program which reads a Data.Map from a file using Data.Binary and Data.ByteString.Lazy, which gives stack overflow with files over a certain size. Any ideas of what might be causing it? You can try it with the small file (11M) at: http://computing.dcu.ie/~gchrupala/map.bin import System import Data.Map import qualified Data.ByteString.Lazy as BS import Data.Binary main = do [path] <- getArgs m <- fmap decode (BS.readFile path)::IO (Map (Int,Maybe String) Int) putStrLn . show . findMax $ m -- Grzegorz -- View this message in context: http://www.nabble.com/Stack-overflow-tp15479718p15479718.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From wb at arb-phys.uni-dortmund.de Thu Feb 14 08:03:04 2008 From: wb at arb-phys.uni-dortmund.de (Wilhelm B. Kloke) Date: Thu Feb 14 08:01:46 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> <20080214052011.vdcelmp6yo8c84c4@webmail.spamcop.net> Message-ID: ajb@spamcop.net schrieb: > G'day all. > > Richard A. O'Keefe wrote: > >> Hmm. Personally, I've never seen an algorithm where comparing for exact >> equality was algorithmically necessary. > > One trick I've occasionally used is to avoid the need for a discriminated > union of floating point and integer types by just using a floating point > number. IMHO it is a perfectly good idea to use the FP processor for integer computations. You can use the Inexact Trap as Overflow Exception, a service you don't get from i386 (and most other) hardware for int operations. Of course your integers are limited to 24bit+sign in single precision and 54bit+sign in double. In i387 extended precision you get 64bit+sign. I would consider a good idea if ghc would provide language support to this sort of integers. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From simonmarhaskell at gmail.com Thu Feb 14 08:03:25 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 14 08:02:03 2008 Subject: [Haskell-cafe] Re: threads + IORefs = Segmentation fault? In-Reply-To: <20080208205507.GA17316@darcs.net> References: <20080118232255.GF6197@darcs.net> <47AC3301.8040500@microsoft.com> <20080208205507.GA17316@darcs.net> Message-ID: <47B43C1D.5090302@microsoft.com> David Roundy wrote: >> Yes, that should all be fine, because the IORef is only modified from one >> thread, and read from the other(s). If you were modifying the IORef from >> more than one thread you would need to use atomicallyModifyIORef, or MVars. > > If I did modify the IORef from more than one thread (e.g. if a bug were > introduced), would this cause any trouble other than occasional missed > updates or reads of wrong data? It shouldn't, no. Cheers, Simon From rl at cse.unsw.edu.au Thu Feb 14 09:15:41 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Feb 14 09:14:26 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <47B3BCCF.7080306@cse.unsw.edu.au> <87pruzzz7e.fsf@59A2.org> Message-ID: <47B44D0D.2070008@cse.unsw.edu.au> jerzy.karczmarczuk@info.unicaen.fr wrote: > Jed Brown comments the answer of - > -- Roman Leshchinskiy who answers my question concerning the replacement > of floating-point numbers: >>> > First, when I see the advice "use something else", I always ask >>> "what", >>> > and I get an answer very, very rarely... Well? What do you propose? > >>> For Haskell, Rational seems like a good choice. The fact that the >>> standard requires defaulting to Double is quite unfortunate and >>> inconsistent, IMO; the default should be Rational. Float and Double >>> shouldn't even be in scope without an explicit import. There really >>> is no good reason to use them unless you are >>> writing a binding to existing libraries or really need the performance. > > Here Jed Brown says: >> Until you need to evaluate a transcendental function. > ... > It would be killing, wouldn't it?... Yes, it would. I was talking about average programs, though, which (I suspect) don't do numerics and really only need fractions. If you do numerics, by all means use a data type that supports numerics well. But even here, and especially in a functional language, IEEE floating point usually isn't the best choice unless you really need the performance. You seem to be after a type that can be used to represent non-integer numbers in next to all problem domains. I don't think such a type exists. So, as usual, one has to choose a data structure suited to the problem at hand. IMO, standard floating point is not a good choice for most problem domains so Float and Double shouldn't be used by default. Whether Rational is a good default is certainly debatable. >> For all practical purposes, the semantics of (==) is not well defined >> for floating point numbers. That's one of the first things I used to >> teach my students about floats: *never* compare them for equality. So >> in my view, your example doesn't fail, it's undefined. That Haskell >> provides (==) for floats is unfortunate. > > I disagree, on practical basis. Floating-point numbers are very well > defined, we know how the mantissa is represented. If the numbers are > normalized, as they should, plenty of low-level iterative algorithms > may use the equality - after some operation - to check that the machine- > precision convergence has been obtained. If you are absolutely sure that for every possible precision and for every sequence of operations that compilers will generate from your code your algorithm will actually converge to a particular binary representation and not flip-flop on the last bit of the mantissa, for instance, and if you do not care about the actual precision of your algorithm (i.e., you want as much as possible of it) then yes, you might get away with using exact equality. Of course, you'll have to protect that part of your code by a sufficient number of warnings since you are using a highly unsafe operation in a very carefully controlled context. I'm not sure the trouble is really worth it. Anyway, in my view, such an unsafe operation shouldn't be in scope by default and definitely shouldn't be called (==). It's really quite like unsafePerformIO. > On the contrary, the verification that the absolute value between two > terms is less than some threshold, may be arbitrary or dubious. Only if you use an inappropriate theshold. Choosing thresholds and precision is an important part of numeric programming and should be done with great care. Roman From simonmarhaskell at gmail.com Thu Feb 14 09:15:07 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 14 09:14:40 2008 Subject: [Haskell-cafe] Re: Haskell maximum stack depth In-Reply-To: <20080205035619.GA4446@localhost.localdomain> References: <479EE139.5090706@iee.org> <404396ef0801290128x2518d723g69be9e3c9bf7c0c4@mail.gmail.com> <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <404396ef0802041144yab70486p621944daf7fbc9a9@mail.gmail.com> <47A78DF8.8000907@iee.org> <20080205035619.GA4446@localhost.localdomain> Message-ID: <47B44CEB.5070503@microsoft.com> Stefan O'Rear wrote: > On Mon, Feb 04, 2008 at 10:13:12PM +0000, Adrian Hey wrote: >>> Also >>> remember that this behaviour never wastes more than 50% of the stack, >>> which is a relatively small amount. >> Only if the stack is relatively small. Would you say the same about >> heap, or about a stack that only needed 50% of heap space but ended >> up using all of it? Or money? Using twice as much as you need of >> anything is bad IMO. > > Apparently you don't realize that GHC normally uses twice as much heap > as is needed, due to the decision to use a two-space copying collector > by default for the oldest generation. :) Three times in fact, on average. If the old generation contained L live data at the last collection, it is allowed to grow to 2L before being collected again. If it still has L live data at the next collection, L is copied, giving you a total requirement of 3L for a major collection. Compacting GC reduces this to 2L, because the live data is not copied. The factor of 2 is tunable using +RTS -F. Cheers, Simon From r.kelsall at millstream.com Thu Feb 14 09:27:40 2008 From: r.kelsall at millstream.com (Richard Kelsall) Date: Thu Feb 14 09:26:18 2008 Subject: [Haskell-cafe] Haskell wiki is searched by google. In-Reply-To: <1202932173.4167.4.camel@localhost.localdomain> References: <47B2F10D.7000200@gmail.com> <47B2FB4F.3040506@millstream.com> <1202932173.4167.4.camel@localhost.localdomain> Message-ID: <47B44FDC.6010809@millstream.com> Mads Lindstr?m wrote: > Richard Kelsall wrote: >> Daniil Elovkov wrote: >>> Hello >>> >>> I remember there was a problem with haskell wiki pages not being indexed >>> and searched. >>> >>> Now it seems to work perfectly. Actually typing 'monomorphism >>> restriction' in google I see the appropriate wiki page as the first result. >>> >>> I must have missed the moment when it was fixed. Just sharing my >>> observations. Thanks. >> Hello Daniil, I think I may have started that discussion here : >> >> http://www.haskell.org/pipermail/haskell-cafe/2007-November/035127.html >> >> but sadly a search for mdo in the Search box at the top of this page >> >> http://haskell.org/haskellwiki/Haskell >> >> still gives no results. I suspect something needs adjusting in the >> configuration of MediaWiki for the haskellwiki. > > Not MediaWiki, but the underlying database. If HaskellWiki uses MySql > ft_min_word_len needs to be set to something smaller than four. See > http://dev.mysql.com/doc/refman/5.0/en/fulltext-fine-tuning.html . After > doing this the indexes needs to be rebuild. Testing using this page http://www.haskell.org/haskellwiki/Extending_Phooey by searching for words which I can see are on the page I get Not found Found --------- ----- mdo Phooey map wire way play let persistence So three character words don't get indexed but four character words do. I mentioned in the previous thread that some longer words weren't getting indexed. It looks like this has been fixed. All the long words I just tried worked properly. And, better than Google, the words get indexed as soon as they are changed. I tried searches for words added this afternoon and they returned up-to-date results. Excellent! Whoever it was thank you for fixing the search. Richard. From anton at appsolutions.com Thu Feb 14 09:36:43 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Thu Feb 14 09:31:58 2008 Subject: [Haskell-cafe] Haskell wiki is searched by google. In-Reply-To: <47B44FDC.6010809@millstream.com> References: <47B2F10D.7000200@gmail.com> <47B2FB4F.3040506@millstream.com> <1202932173.4167.4.camel@localhost.localdomain> <47B44FDC.6010809@millstream.com> Message-ID: <47B451FB.5030605@appsolutions.com> Richard Kelsall wrote: > I mentioned in the previous thread that some longer words weren't > getting indexed. It looks like this has been fixed. All the long words > I just tried worked properly. And, better than Google, the words get > indexed as soon as they are changed. I tried searches for words added > this afternoon and they returned up-to-date results. Excellent! Whoever > it was thank you for fixing the search. Haskelves? From simonmarhaskell at gmail.com Thu Feb 14 10:31:37 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Feb 14 10:30:13 2008 Subject: [Haskell-cafe] Re: Haskell maximum stack depth In-Reply-To: <47A96DC2.9030805@iee.org> References: <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> Message-ID: <47B45ED9.3050302@microsoft.com> Adrian Hey wrote: > I have no objection to people bounding their stack if that's their > choice. I can't imagine why anybody who stopped to think about this > would actually want this feature, but it's free world. > > What I object to is it being bounded by default to something other > than overall program memory limit. (i'm a few days behind haskell-cafe, as usual...) There *are* some good reasons to want a stack limit, but they are only practical concerns. The point is, GHC has no such thing as the "overall program memory limit" unless by that you mean the total amount of memory + swap in your machine. You can set a limit with +RTS -M, but there isn't one by default. So what happens when you write a program with a space leak is that it gobbles up all the memory, and turns on the hard disk light for a few minutes until the OS gives up and kills it. Or at least, you hope it kills your program and not something else important you were doing at the time. We used to have a default heap limit, for the reason above, but I was persuaded to remove it because it was too much of a pain to keep having to say +RTS -M when your program ran out of memory. So we could do the same with the stack limit - the only concern is whether it will be highly inconvenient when we accidentally write programs with infinite loops, which in my experience seem to occur more than space-leaky programs. We could also set the limit a lot higher than it currently is. Or, we could try to figure out how much memory is in the machine and set it based on that. Basically, I don't care that much, unless it means I have to do a lot of work to implement it :) Cheers, Simon From byorgey at gmail.com Thu Feb 14 10:44:57 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Thu Feb 14 10:43:30 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: <1202888791.5962.1.camel@jutaro-laptop> References: <1202888791.5962.1.camel@jutaro-laptop> Message-ID: <22fcbd520802140744y3ba29055rce2dd78ee96d6ccc@mail.gmail.com> On Wed, Feb 13, 2008 at 2:46 AM, J?rgen Nicklisch-Franken wrote: > I'm pleased to announce the first release of Leksah, an IDE for > Haskell written in Haskell. Leksah is intended as a practical tool > to support the Haskell development process. > Is there a development listserv for leksah? And what about a bug tracker? -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080214/1d332f11/attachment.htm From rherrmann at gmail.com Thu Feb 14 11:59:08 2008 From: rherrmann at gmail.com (Ricardo Herrmann) Date: Thu Feb 14 11:57:42 2008 Subject: [Haskell-cafe] question about STM and IO In-Reply-To: <47B1E869.2040806@tu-bs.de> References: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> <47B1E869.2040806@tu-bs.de> Message-ID: <15481669.post@talk.nabble.com> Stephan Friedrichs-2 wrote: > > > it's unsafe to perform IO inside of a transaction as it can't be undone, > when rolling it back. I guess, unsafeIOToSTM has been designed in order > to allow us to inject debugging output into a transaction, but you > really shouldn't use it to perform "real" IO (like writing files, etc.). > > Simon Peyton Jones provides a good example of this in http://research.microsoft.com/~simonpj/papers/stm/beautiful.pdf > atomically (do { x <- readTVar xv > ; y <- readTVar yv > ; if x>y then launchMissiles > else return () }) > > where launchMissiles :: IO () causes serious international side-effects. > ;-) -- Ricardo Guimar?es Herrmann "There are only two industries that refer to their customers as 'users'" -- Edward Tufte -- View this message in context: http://www.nabble.com/question-about-STM-and-IO-tp15439579p15481669.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From wnoise at ofb.net Thu Feb 14 13:04:01 2008 From: wnoise at ofb.net (Aaron Denney) Date: Thu Feb 14 13:02:38 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> Message-ID: On 2008-02-14, Roman Leshchinskiy wrote: > Richard A. O'Keefe wrote: >> Presumably the reason for having Int in the language at all is speed. >> As people have pointed out several times on this list to my knowledge, >> Integer performance is not as good as Int performance, not hardly, >> and it is silly to pay that price if I don't actually need it. > > Do I understand correctly that you advocate using overflowing ints (even > if they signal overflow) even if Integers are fast enough for a > particular program? I strongly disagree with this. It's premature > optimisation of the worst kind - trading correctness for unneeded > performance. "Fast enough" is not absolute. It's not trading correctness, it's trading /completion/. And if you expect everything to fit in [-2^31..2^31-1] or [0..2^32-1], finding out it doesn't might be valuable information about your problem domain. For "exploratory" coding, speed and knowing when something breaks can be more important than knowing that all possible corner case are covered, even ones you don't expect to hit. >> SafeInt is what you should use when you *THINK* your results should all fit >> in a machine int but aren't perfectly sure. (And this is nearly all the >> time.) > > Again, I strongly disagree. You should use Integer unless your program > is too slow and profiling shows that Integer is the culprit. If and only > if that is the case should you think about alternatives. That said, I > doubt that your SafeInt would be significantly faster than Integer. Why? GMP is pretty good, but it's not going to be anywhere near hardware speeds. >> The checking I am talking about is done by the hardware at machine speeds >> and provides *certainty* that overflow did not occur. > > So you advocate using different hardware? At a minimum, any usable hardware sets flags on overflow. Testing on those is pretty cheap. Much cheaper than calling a GMP routine to compare with 2^32, for instance. -- Aaron Denney -><- From jnf at arcor.de Thu Feb 14 13:24:23 2008 From: jnf at arcor.de (=?ISO-8859-1?Q?J=FCrgen?= Nicklisch-Franken) Date: Thu Feb 14 13:22:56 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: <22fcbd520802140744y3ba29055rce2dd78ee96d6ccc@mail.gmail.com> References: <1202888791.5962.1.camel@jutaro-laptop> <22fcbd520802140744y3ba29055rce2dd78ee96d6ccc@mail.gmail.com> Message-ID: <1203013463.5970.17.camel@jutaro-laptop> Currently their is no mailing list and no bug tracker. Until yesterday it was a "one person - I do it inbetween" project. If others like to contribute, which would be great, I think about writing a short "one page" developers intro. J?rgen Am Donnerstag, den 14.02.2008, 10:44 -0500 schrieb Brent Yorgey: > > On Wed, Feb 13, 2008 at 2:46 AM, J?rgen Nicklisch-Franken > wrote: > I'm pleased to announce the first release of Leksah, an IDE > for > Haskell written in Haskell. Leksah is intended as a practical > tool > to support the Haskell development process. > > Is there a development listserv for leksah? And what about a bug > tracker? > > -Brent > > From ben.franksen at online.de Thu Feb 14 13:32:55 2008 From: ben.franksen at online.de (Ben Franksen) Date: Thu Feb 14 13:34:54 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> <20080214052011.vdcelmp6yo8c84c4@webmail.spamcop.net> Message-ID: Wilhelm B. Kloke wrote: > ajb@spamcop.net schrieb: >> G'day all. >> >> Richard A. O'Keefe wrote: >> >>> Hmm. Personally, I've never seen an algorithm where comparing for exact >>> equality was algorithmically necessary. >> >> One trick I've occasionally used is to avoid the need for a discriminated >> union of floating point and integer types by just using a floating point >> number. > > IMHO it is a perfectly good idea to use the FP processor for integer > computations. You can use the Inexact Trap as Overflow Exception, > a service you don't get from i386 (and most other) hardware for int > operations. Of course your integers are limited to 24bit+sign in > single precision and 54bit+sign in double. In i387 extended precision > you get 64bit+sign. > > I would consider a good idea if ghc would provide language support to > this sort of integers. No need, you can do that for yourself: {-# LANGUAGE GeneralizedNewtypeDeriving #-} newtype DInt = DInt Double deriving (Eq, Ord, Enum, Num) instance Show DInt where show (DInt x) = show (truncate x :: Integer) You can even make it H98 by defining the instances manually... Cheers Ben From agl at imperialviolet.org Thu Feb 14 13:46:22 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Feb 14 13:44:54 2008 Subject: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems In-Reply-To: <396556a20802122345y741504f0s9769734a9e041e6e@mail.gmail.com> References: <63wta2td.wl%jeremy.shaw@linspireinc.com> <396556a20802122244l731dd84eob8e4781dddabfef9@mail.gmail.com> <396556a20802122304k62966ff3kcbb0ff0fd1ca6daf@mail.gmail.com> <396556a20802122345y741504f0s9769734a9e041e6e@mail.gmail.com> Message-ID: <396556a20802141046y132ed976s4581b5754a1cdd1b@mail.gmail.com> Filed as: http://hackage.haskell.org/trac/ghc/ticket/2096 -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From saynte at gmail.com Thu Feb 14 14:36:07 2008 From: saynte at gmail.com (Scott West) Date: Thu Feb 14 14:34:39 2008 Subject: [Haskell-cafe] Best way to find an "undefined" error? Message-ID: <92bb28850802141136k335f905esb6ac6b3ecc0dd7f8@mail.gmail.com> Hello all, Does anyone favourite technique to track down an "undefined" call? I'm 99% sure that my code is not the offender (I've grepped for undefined occurrences and turned them all into "error" calls). Supposing that this is happening in some other package or library that I'm using, what is the best way to find out where it is? I have profiling enabled on all libraries that I use, so I'm ok there I think. Any magic combination of +RTS .. -RTS? Scott From dons at galois.com Thu Feb 14 14:55:43 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 14 14:54:29 2008 Subject: [Haskell-cafe] Best way to find an "undefined" error? In-Reply-To: <92bb28850802141136k335f905esb6ac6b3ecc0dd7f8@mail.gmail.com> References: <92bb28850802141136k335f905esb6ac6b3ecc0dd7f8@mail.gmail.com> Message-ID: <20080214195543.GC7180@scytale.galois.com> saynte: > Hello all, > > Does anyone favourite technique to track down an "undefined" call? I'm > 99% sure that my code is not the offender (I've grepped for undefined > occurrences and turned them all into "error" calls). Supposing that > this is happening in some other package or library that I'm using, > what is the best way to find out where it is? I have profiling enabled > on all libraries that I use, so I'm ok there I think. Any magic > combination of +RTS .. -RTS? > You can use the profiler to get a stack trace, or use the new GHCi debugger to step backwards from the exception to the source. I wrote a bit of a tutorial for this here: http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14#no-exceptions -- Don From dbueno at gmail.com Thu Feb 14 15:02:41 2008 From: dbueno at gmail.com (Denis Bueno) Date: Thu Feb 14 15:01:13 2008 Subject: [Haskell-cafe] Best way to find an "undefined" error? In-Reply-To: <20080214195543.GC7180@scytale.galois.com> References: <92bb28850802141136k335f905esb6ac6b3ecc0dd7f8@mail.gmail.com> <20080214195543.GC7180@scytale.galois.com> Message-ID: <6dbd4d000802141202o341934a8n91f9e65570d772d7@mail.gmail.com> On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart wrote: > You can use the profiler to get a stack trace, or use the new > GHCi debugger to step backwards from the exception to the source. > > I wrote a bit of a tutorial for this here: > > http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14#no-exceptions Section 6.3 of http://haskell.org/haskellwiki/Debugging also is relevant for using ghcu to step backward ... perhaps the section label is misleading, though. Feel free to modify as needed if you find the ghci stepper lets you find the problem -- Denis From saynte at gmail.com Thu Feb 14 16:12:34 2008 From: saynte at gmail.com (Scott West) Date: Thu Feb 14 16:11:06 2008 Subject: [Haskell-cafe] Best way to find an "undefined" error? In-Reply-To: <6dbd4d000802141202o341934a8n91f9e65570d772d7@mail.gmail.com> References: <92bb28850802141136k335f905esb6ac6b3ecc0dd7f8@mail.gmail.com> <20080214195543.GC7180@scytale.galois.com> <6dbd4d000802141202o341934a8n91f9e65570d772d7@mail.gmail.com> Message-ID: <92bb28850802141312v3bd5eb6fk6f17799da1862ac1@mail.gmail.com> On Thu, Feb 14, 2008 at 3:02 PM, Denis Bueno wrote: > On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart wrote: > > You can use the profiler to get a stack trace, or use the new > > GHCi debugger to step backwards from the exception to the source. > > > > I wrote a bit of a tutorial for this here: > > > > http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14#no-exceptions > > Section 6.3 of http://haskell.org/haskellwiki/Debugging also is > relevant for using ghcu to step backward ... perhaps the section label > is misleading, though. Feel free to modify as needed if you find the > ghci stepper lets you find the problem Well, when using +RTS -xc, I get: Prelude.undefined I'm not really sure what to do with this, not really the stacktrace I was hoping for. The ghci debugger I found was really quite nice, up until it his some portion of code that it isn't interpreting. By not "interpreting" i mean things that have been already been compiled and it's just calling (even if it has been compiled with profiling). I have a feeling that my problem is somewhere in something that has already been compiled. Knowing that, should +RTS -xc be giving me more information? Is there a way for it to do so? Regards, Scott From jed at 59A2.org Thu Feb 14 16:22:58 2008 From: jed at 59A2.org (Jed Brown) Date: Thu Feb 14 16:20:39 2008 Subject: [Haskell-cafe] ANN: two new packages: carray, fft Message-ID: <87d4qzz0zx.fsf@59A2.org> Hopefully these are mature enough to be generally useful. I would appreciate any comments regarding the interface. The FFTW API is not particularly nice for building a pure interface on. Some of the transforms could be made slightly faster at the expense of a much nastier interface, but unless someone needs the extra few percent, or is pushing the memory limits on their machine, I'm not inclined to expose the underlying nastiness. * carray A C-compatible array library. Provides both an immutable and mutable (in the IO monad) interface. Includes utilities for multi-dimensional arrays, slicing and norms. Memory is 16-byte aligned by default to enable use of SIMD instructions. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/carray * fft Bindings to the FFTW library. Provides high performance discrete fourier transforms in arbitrary dimensions. Include transforms of complex data, real data, and real to real transforms. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fft Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080214/6b0b79c9/attachment.bin From dons at galois.com Thu Feb 14 16:33:11 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 14 16:32:05 2008 Subject: [Haskell-cafe] ANN: two new packages: carray, fft In-Reply-To: <87d4qzz0zx.fsf@59A2.org> References: <87d4qzz0zx.fsf@59A2.org> Message-ID: <20080214213311.GA10952@scytale.galois.com> jed: > Hopefully these are mature enough to be generally useful. I would > appreciate any comments regarding the interface. The FFTW API is not > particularly nice for building a pure interface on. Some of the > transforms could be made slightly faster at the expense of a much > nastier interface, but unless someone needs the extra few percent, or is > pushing the memory limits on their machine, I'm not inclined to expose > the underlying nastiness. > > > * carray A C-compatible array library. > Provides both an immutable and mutable (in the IO monad) interface. > Includes utilities for multi-dimensional arrays, slicing and norms. > Memory is 16-byte aligned by default to enable use of SIMD > instructions. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/carray > > > * fft Bindings to the FFTW library. > Provides high performance discrete fourier transforms in arbitrary > dimensions. Include transforms of complex data, real data, and real > to real transforms. > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fft > > > Jed Excellent work! These fill a key niche. Thanks for contributing! -- Don From dons at galois.com Thu Feb 14 16:43:13 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 14 16:41:54 2008 Subject: [Haskell-cafe] Best way to find an "undefined" error? In-Reply-To: <92bb28850802141312v3bd5eb6fk6f17799da1862ac1@mail.gmail.com> References: <92bb28850802141136k335f905esb6ac6b3ecc0dd7f8@mail.gmail.com> <20080214195543.GC7180@scytale.galois.com> <6dbd4d000802141202o341934a8n91f9e65570d772d7@mail.gmail.com> <92bb28850802141312v3bd5eb6fk6f17799da1862ac1@mail.gmail.com> Message-ID: <20080214214313.GB10952@scytale.galois.com> saynte: > On Thu, Feb 14, 2008 at 3:02 PM, Denis Bueno wrote: > > On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart wrote: > > > You can use the profiler to get a stack trace, or use the new > > > GHCi debugger to step backwards from the exception to the source. > > > > > > I wrote a bit of a tutorial for this here: > > > > > > http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14#no-exceptions > > > > Section 6.3 of http://haskell.org/haskellwiki/Debugging also is > > relevant for using ghcu to step backward ... perhaps the section label > > is misleading, though. Feel free to modify as needed if you find the > > ghci stepper lets you find the problem > > Well, when using +RTS -xc, I get: > > Prelude.undefined > > I'm not really sure what to do with this, not really the stacktrace I > was hoping for. The ghci debugger I found was really quite nice, up > until it his some portion of code that it isn't interpreting. By not > "interpreting" i mean things that have been already been compiled and > it's just calling (even if it has been compiled with profiling). I > have a feeling that my problem is somewhere in something that has > already been compiled. Is it possible to just load all the code interpreted? Or is the problem in a dependent library? If you profile and let the program terminate, there should be a stack trace in the .prof as well. -- Don From naur at post11.tele.dk Thu Feb 14 16:44:42 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Thu Feb 14 16:44:26 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <20080214092430.MABX1539.fep24.mail.dk@www.haskell.org> References: <20080214092430.MABX1539.fep24.mail.dk@www.haskell.org> Message-ID: <200802142244.43095.naur@post11.tele.dk> Hello, On a tangent, probably: On Thursday 14 February 2008 10:24, Roman Leshchinskiy wrote: > ... > Hmm. Personally, I've never seen an algorithm where comparing for exact > equality was algorithmically necessary. Sometimes (rarely) it is > acceptable but necessary? Do you know of one? Finding the "machine epsilon", perhaps, that is, the smallest (floating point, surely) number for which 1.0+machine_eps==1.0 would be a candidate? > ... Best regards Thorkil From saynte at gmail.com Thu Feb 14 17:12:41 2008 From: saynte at gmail.com (Scott West) Date: Thu Feb 14 17:11:12 2008 Subject: [Haskell-cafe] Best way to find an "undefined" error? In-Reply-To: <20080214214313.GB10952@scytale.galois.com> References: <92bb28850802141136k335f905esb6ac6b3ecc0dd7f8@mail.gmail.com> <20080214195543.GC7180@scytale.galois.com> <6dbd4d000802141202o341934a8n91f9e65570d772d7@mail.gmail.com> <92bb28850802141312v3bd5eb6fk6f17799da1862ac1@mail.gmail.com> <20080214214313.GB10952@scytale.galois.com> Message-ID: <92bb28850802141412t42a501f6sc57a74d62ae86fe1@mail.gmail.com> On Thu, Feb 14, 2008 at 4:43 PM, Don Stewart wrote: > saynte: > > > > On Thu, Feb 14, 2008 at 3:02 PM, Denis Bueno wrote: > > > On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart wrote: > > > > You can use the profiler to get a stack trace, or use the new > > > > GHCi debugger to step backwards from the exception to the source. > > > > > > > > I wrote a bit of a tutorial for this here: > > > > > > > > http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14#no-exceptions > > > > > > Section 6.3 of http://haskell.org/haskellwiki/Debugging also is > > > relevant for using ghcu to step backward ... perhaps the section label > > > is misleading, though. Feel free to modify as needed if you find the > > > ghci stepper lets you find the problem > > > > Well, when using +RTS -xc, I get: > > > > Prelude.undefined > > > > I'm not really sure what to do with this, not really the stacktrace I > > was hoping for. The ghci debugger I found was really quite nice, up > > until it his some portion of code that it isn't interpreting. By not > > "interpreting" i mean things that have been already been compiled and > > it's just calling (even if it has been compiled with profiling). I > > have a feeling that my problem is somewhere in something that has > > already been compiled. > > Is it possible to just load all the code interpreted? Or is the problem > in a dependent library? > > If you profile and let the program terminate, there should be a stack > trace in the .prof as well. > > -- Don > Well, I can load a bunch of it interpreted. I've already done this as far as I think I can. The only pieces laying outside the interpreter are the GHC libraries and Gtk2Hs. The really funny thing, is that (essentially) I believe the error results from a call to "fromDynamic" out of Data.Dynamic. This sort of leads me to believe that someone's "Typeable" instance is being funny. Again though, all the Typeable's in the immediate area of my code seem to be fine. (the .prof didn't seem to reveal anything yet... I'll look it over a little more closely though) Regards, Scott From rl at cse.unsw.edu.au Thu Feb 14 17:41:02 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Thu Feb 14 17:39:39 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> Message-ID: <47B4C37E.4070708@cse.unsw.edu.au> Aaron Denney wrote: > On 2008-02-14, Roman Leshchinskiy wrote: >> Richard A. O'Keefe wrote: > >>> SafeInt is what you should use when you *THINK* your results should all fit >>> in a machine int but aren't perfectly sure. (And this is nearly all the >>> time.) >> Again, I strongly disagree. You should use Integer unless your program >> is too slow and profiling shows that Integer is the culprit. If and only >> if that is the case should you think about alternatives. That said, I >> doubt that your SafeInt would be significantly faster than Integer. > > Why? GMP is pretty good, but it's not going to be anywhere near > hardware speeds. This how Integer is defined in the libraries: data Integer = S# Int# -- small integers | J# Int# ByteArray# -- large integers As long as the Int# doesn't overflow, you don't call any GMP routines. Roman From jeremy.shaw at linspireinc.com Wed Feb 13 18:03:53 2008 From: jeremy.shaw at linspireinc.com (Jeremy Shaw) Date: Thu Feb 14 18:03:06 2008 Subject: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems In-Reply-To: <396556a20802122345y741504f0s9769734a9e041e6e@mail.gmail.com> References: <63wta2td.wl%jeremy.shaw@linspireinc.com> <396556a20802122244l731dd84eob8e4781dddabfef9@mail.gmail.com> <396556a20802122304k62966ff3kcbb0ff0fd1ca6daf@mail.gmail.com> <396556a20802122345y741504f0s9769734a9e041e6e@mail.gmail.com> Message-ID: <4pcctq5i.wl%jeremy.shaw@linspireinc.com> Created a ticket with a patch: http://hackage.haskell.org/trac/ghc/ticket/2093 From jeremy.shaw at linspireinc.com Wed Feb 13 17:55:50 2008 From: jeremy.shaw at linspireinc.com (Jeremy Shaw) Date: Thu Feb 14 18:03:24 2008 Subject: [Haskell-cafe] getSymbolicLinkStatus completely broken on some 6.8.2 systems In-Reply-To: <396556a20802122345y741504f0s9769734a9e041e6e@mail.gmail.com> References: <63wta2td.wl%jeremy.shaw@linspireinc.com> <396556a20802122244l731dd84eob8e4781dddabfef9@mail.gmail.com> <396556a20802122304k62966ff3kcbb0ff0fd1ca6daf@mail.gmail.com> <396556a20802122345y741504f0s9769734a9e041e6e@mail.gmail.com> Message-ID: <63wstqix.wl%jeremy.shaw@linspireinc.com> Hello, You rule! Here is where I am at now. It seems that when I build ghc from source, the top level configure script detects that my system has large file support, and enables it. As you discovered, this gets dumped into: /usr/lib/ghc-6.8.2/include/ghcautoconf.h which gets included when hsc2hs calculates the offsets. However, it seems that that header file does not get included when the unix library builds -- so it builds the library with out large file support. If I run ltrace on this program: > import System.Posix.Files > > main = > do getSymbolicLinkStatus "/etc/passwd" >>= print . fileID > getFileStatus "/etc/passwd" >>= print . fileID I see that __xstat64 is called, but plain old __xlstat is called. As a fix(??) I added the copied the following from ghc's configure.ac into unix's configure.ac and ran autoreconf: dnl ** Enable large file support. NB. do this before testing the type of dnl off_t, because it will affect the result of that test. AC_SYS_LARGEFILE This seemed to fix my problem -- ltrace shows that __lxstat64 is called and the results are normal. thanks a ton! j. At Tue, 12 Feb 2008 23:45:41 -0800, Adam Langley wrote: > > On Feb 12, 2008 11:04 PM, Adam Langley wrote: > > structure filled in. HsUnix.h has a wrapper around lstat for exactly > > this reason, however ltrace shows it calling the wrong one. > > So (finally!) the real issue: > > hsc2hs has a C preprocessor prelude (utils/hsc2hs/template-hsc.h) > which includes some GHC header files. As a result, hsc processes files > in 64-bit mode: > % cpp -I../../includes -dM template-hsc.h | grep FILE_OFFSET_BITS > #define _FILE_OFFSET_BITS 64 > > However, when building HsUnix.c (or any c file with cabal), the > environment is different and it's built in 32-bit mode. Thus the lstat > wrapper called the 32-bit glibc function, but the structure sizes and > offsets in Files.hs (from Files.hsc) are all for 64-bit mode. > > The fix is not quite obvious. Probably hsc2hs should try harder not to > change the environment so much. I'm not quite sure why the hsc2hs > template pulls in the HsFFI header - it doesn't seem to need it. > > Although you can remove the #include and rebuild the unix package, I > can safely say that you'll be reinstalling ghc if you do. What might > work is changing hsc2hs and then rebuilding all of GHC. However, > that's an overnight build so I don't know yet. > > > AGL > > -- > Adam Langley agl@imperialviolet.org > http://www.imperialviolet.org 650-283-9641 From ajb at spamcop.net Thu Feb 14 18:06:33 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Feb 14 18:05:03 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <200802142244.43095.naur@post11.tele.dk> References: <20080214092430.MABX1539.fep24.mail.dk@www.haskell.org> <200802142244.43095.naur@post11.tele.dk> Message-ID: <20080214180633.9x8jhlsd0c4ssgo8@webmail.spamcop.net> G'day all. Quoting Thorkil Naur : > Finding the "machine epsilon", perhaps, that is, the smallest > (floating point, > surely) number for which 1.0+machine_eps==1.0 would be a candidate? The machine epsilon is the smallest relative separation between two adjacent normalised floating point numbers. (The largest is the machine epsilon multiplied by the radix, more or less.) So as I understand it, if you're thinking relative error, this test: (fabs(x1-x2) < machine_eps * fabs(x1)) should be true if and only if x1 == x2, assuming that x1 and x2 are nonzero and normalised. I've always had the impression that using the machine epsilon for pseudo-equality testing is fairly useless, especially if you can work out a meaningful problem-specific tolerance. What seems to be more useful is using the machine epsilon to compute an estimate of how much relative error your algorithm accumulates. I've seen this in a lot of Serious Numeric Code(tm), and I've done it myself (probably inexpertly) a few times. I haven't tried this, but I imagine that a computed relative error estimate could be useful for assisting your approximate-equality tests under some circumstances. Richard might know of some circumstances where this sort of thing would be useful. Cheers, Andrew Bromage From agl at imperialviolet.org Thu Feb 14 19:44:48 2008 From: agl at imperialviolet.org (Adam Langley) Date: Thu Feb 14 19:43:20 2008 Subject: [Haskell-cafe] ANN: ctemplate, SSL server support in HsOpenSSL, network-minihttp, binary parsing, network-dns Message-ID: <396556a20802141644h12ae9db9ud16f41ffee463e5d@mail.gmail.com> Binary parsing: binary-strict now has support for combinator parsing[1] with <|> and friends. This works both for the strict Get and the IncrementalGet. (The latter was more complex than I expected) binary-strict also gained a very fast byte set module[2] (used for scanning ranges of valid bytes) and a surprisingly useful hexDump[3] function (because I kept having to write it in lots of places) [1] http://hackage.haskell.org/packages/archive/binary-strict/0.3.0/doc/html/Data-Binary-Strict-Class.html [2] http://hackage.haskell.org/packages/archive/binary-strict/0.3.0/doc/html/Data-Binary-Strict-ByteSet.html [3] http://hackage.haskell.org/packages/archive/binary-strict/0.3.0/doc/html/Data-Binary-Strict-Util.html DNS: network-dns contains a DNS client library[4] in pure Haskell. The ADNS library (for which a wrapper already exists) is GPL, not BSD. This code is also halfway to being a DNS server should anyone so wish. This is very similar to the DNS client library in libevent (because I wrote them both). HTTP: ctemplate is a wrapping of the template library which Google uses for most of their sites. There are several template systems already in Hackage, but I like ctemplate because escaping is so easy and well supported. Generally the power of a template system doesn't interest me (in fact, it can be a bad thing), but stopping XSS attacks is a big deal. HsOpenSSL now has rudimentary support for writing SSL servers[5] (clients coming soon). In terms of blocking IO, this /should/ work the way you would hope (i.e. like a Haskell function w.r.t. forkIO). network-minihttp is a small HTTP server. Currently it serves files from the disk (with caching and range support), but it's most of the way to being a HTTP client also. Don't do anything too serious with it yet, however. It needs a few limits to stop DoS attackers from, for example, sending an infinite header and using up all the memory :) [4] http://hackage.haskell.org/packages/archive/network-dns/0.1.1/doc/html/Network-DNS-Client.html -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641 From dons at galois.com Thu Feb 14 20:06:25 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 14 20:05:01 2008 Subject: [Haskell-cafe] ANN: Leksah 0.1 - Haskell IDE written in Haskell In-Reply-To: <22fcbd520802140744y3ba29055rce2dd78ee96d6ccc@mail.gmail.com> References: <1202888791.5962.1.camel@jutaro-laptop> <22fcbd520802140744y3ba29055rce2dd78ee96d6ccc@mail.gmail.com> Message-ID: <20080215010625.GB11142@scytale.galois.com> byorgey: > On Wed, Feb 13, 2008 at 2:46 AM, Juergen Nicklisch-Franken > <[1]jnf@arcor.de> wrote: > > I'm pleased to announce the first release of Leksah, an IDE for > Haskell written in Haskell. Leksah is intended as a practical tool > to support the Haskell development process. > > Is there a development listserv for leksah? And what about a bug tracker? > Should be pretty cheap to create a bug tracker on google's bug tracker site, as xmonad does. then link to it from the wiki page. From saynte at gmail.com Thu Feb 14 21:25:07 2008 From: saynte at gmail.com (Scott West) Date: Thu Feb 14 21:23:38 2008 Subject: [Haskell-cafe] Best way to find an "undefined" error? In-Reply-To: <92bb28850802141412t42a501f6sc57a74d62ae86fe1@mail.gmail.com> References: <92bb28850802141136k335f905esb6ac6b3ecc0dd7f8@mail.gmail.com> <20080214195543.GC7180@scytale.galois.com> <6dbd4d000802141202o341934a8n91f9e65570d772d7@mail.gmail.com> <92bb28850802141312v3bd5eb6fk6f17799da1862ac1@mail.gmail.com> <20080214214313.GB10952@scytale.galois.com> <92bb28850802141412t42a501f6sc57a74d62ae86fe1@mail.gmail.com> Message-ID: <92bb28850802141825i64aba55dh5b12b2485b31f132@mail.gmail.com> On Thu, Feb 14, 2008 at 5:12 PM, Scott West wrote: > > On Thu, Feb 14, 2008 at 4:43 PM, Don Stewart wrote: > > saynte: > > > > > > > On Thu, Feb 14, 2008 at 3:02 PM, Denis Bueno wrote: > > > > On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart wrote: > > > > > You can use the profiler to get a stack trace, or use the new > > > > > GHCi debugger to step backwards from the exception to the source. > > > > > > > > > > I wrote a bit of a tutorial for this here: > > > > > > > > > > http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14#no-exceptions > > > > > > > > Section 6.3 of http://haskell.org/haskellwiki/Debugging also is > > > > relevant for using ghcu to step backward ... perhaps the section label > > > > is misleading, though. Feel free to modify as needed if you find the > > > > ghci stepper lets you find the problem > > > > > > Well, when using +RTS -xc, I get: > > > > > > Prelude.undefined > > > > > > I'm not really sure what to do with this, not really the stacktrace I > > > was hoping for. The ghci debugger I found was really quite nice, up > > > until it his some portion of code that it isn't interpreting. By not > > > "interpreting" i mean things that have been already been compiled and > > > it's just calling (even if it has been compiled with profiling). I > > > have a feeling that my problem is somewhere in something that has > > > already been compiled. > > > > Is it possible to just load all the code interpreted? Or is the problem > > in a dependent library? > > > > If you profile and let the program terminate, there should be a stack > > trace in the .prof as well. > > > > -- Don > > > > Well, I can load a bunch of it interpreted. I've already done this as > far as I think I can. The only pieces laying outside the interpreter > are the GHC libraries and Gtk2Hs. The really funny thing, is that > (essentially) I believe the error results from a call to "fromDynamic" > out of Data.Dynamic. This sort of leads me to believe that someone's > "Typeable" instance is being funny. Again though, all the Typeable's > in the immediate area of my code seem to be fine. > > (the .prof didn't seem to reveal anything yet... I'll look it over a > little more closely though) > > Regards, > Scott > I did finally find the error (in one of the pieces of code not written by myself). A few instances of Typeable were trying to pattern match their arguments. *bomb* In either case, it was an interesting experience! Thanks for the help all! Regards, Scott From stevelihn at gmail.com Thu Feb 14 21:34:53 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Thu Feb 14 21:33:23 2008 Subject: [Haskell-cafe] a general question on Arrows In-Reply-To: <7ca3f0160802140047x796e75b3x5783a0ee43ac94c3@mail.gmail.com> References: <7ca3f0160802140047x796e75b3x5783a0ee43ac94c3@mail.gmail.com> Message-ID: > > 1. Stream > This is actually a comonad. Something more to learn everyday. > Here's another fun arrow: > > http://luqui.org/blog/archives/2007/09/06/quantum-entanglement-in-haskell/ > > Luke > Luke, I managed to get your quantum entanglement examples working. But honestly, I can't quite figure out your Quantum module yet. My head is exploding after reading the code :-) It is amazing to know it takes several layers of arrows to simulate the quantum mechanics. I have a small question on the simulation technique. In both John Hughes and your code, you wrap the "print" inside the runXYZ (...) to print out the state of simulation. It is like: runArrow ( ... simulation ...then print ...) -< input Why don't you structure it like y <- runArrow ( ... simulation ... then return observation ... ) -< input reuse y or print y In the former, the result is printed on the screen. I can not collect the result and do more analysis. For example, for a quantum state |0> + i |1>, the probability is half half. If I can repeat the simulation 10000 times and collect the "observations" (y) , then I can "prove" the correctness of experiment by observing ~5000 of |0> and ~5000 of |1>. Or even plot the probability distribution of the experiment. Steve From ok at cs.otago.ac.nz Thu Feb 14 22:19:20 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Feb 14 22:17:55 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: <47B408B2.3090900@cse.unsw.edu.au> References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> Message-ID: On 14 Feb 2008, at 10:24 pm, Roman Leshchinskiy wrote: > Do I understand correctly that you advocate using overflowing ints > (even if they signal overflow) even if Integers are fast enough for > a particular program? No you most certainly do NOT. There is no way to soundly, and I would have thought no way to plausibly, infer that from anything I wrote. > > Again, I strongly disagree. You should use Integer unless your > program is too slow and profiling shows that Integer is the > culprit. If and only if that is the case should you think about > alternatives. That said, I doubt that your SafeInt would be > significantly faster than Integer. SafeInt should be as fast as Int, or very nearly. The representation of SafeInt is identical to the representation of Int, so the space overheads are definitely lower. >> The checking I am talking about is done by the hardware at machine >> speeds >> and provides *certainty* that overflow did not occur. > > So you advocate using different hardware? Again, this is the opposite of what I wrote. On my desk there are a Pentium machine and an UltraSPARC and a G4. They *all* support cheap integer overflow checks. I am saying that we should use the hardware we have already paid for! > It's not a particularly useful operation (and it is not equality), > but it does have a defined semantics. However, the semantics of > (==) on floats isn't really defined in Haskell or C, for that > matter, even if you know that the hardware is strictly IEEE > conformant. The semantics of == on floats in C99 is, under certain circumstances, and on the machines I use with the compilers I use, defined to be those of the IEEE (or, as the C99 standard puts it, IEC) operation. > > In general, floating point numbers do not really have a useful > notion of equality. They are approximations. The *numbers* are not approximations, the *operations* are approximate. In particular, floating point +, -, *, <, ==, abs, sign, and other related operations (but not /) are *exact* on integral values, if the results fit. AWK programs would be in terrible trouble if this were not so From ok at cs.otago.ac.nz Thu Feb 14 22:30:37 2008 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu Feb 14 22:29:18 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" In-Reply-To: References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> <20080214052011.vdcelmp6yo8c84c4@webmail.spamcop.net> Message-ID: <82C4E5C8-F3E7-492A-9A35-1BCA5F1A309D@cs.otago.ac.nz> On 15 Feb 2008, at 2:03 am, Wilhelm B. Kloke wrote: IMHO it is a perfectly good idea to use the FP processor for integer > computations. You can use the Inexact Trap as Overflow Exception, > a service you don't get from i386 (and most other) hardware for int > operations. A neat idea. However, the i386 has the INTO instruction, the SPARC family has the TRAPV instruction, and other processors have analogues. Some machines have two sets of add/subtract instructions, one trapping, one not. From oleg at okmij.org Thu Feb 14 22:51:24 2008 From: oleg at okmij.org (oleg@okmij.org) Date: Thu Feb 14 22:52:38 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] Message-ID: <20080215035124.4C509A99B@Adric.metnet.fnmoc.navy.mil> Matthew Naylor wrote: > it's not immediately clear (to me at least) how efficient your method > will be in "practice". Any method based on common sub-expression > elimination surely must inspect every node in the flattened graph. In > the worst case, an acyclic graph containing n nodes could have 2^n > nodes when flattened to a tree: > > tricky 0 = constant 0 > tricky d = add g g > where > g = tricky (d-1) It should work quite well in practice, as demonstrated below. Once our DSL is extended with a let form (so the user can declare the intention to share results of computations rather than computations themselves), tricky code becomes trivial. The code remains declarative, safe and pure, and, save for the (cosmetic) lack of the monomorphism restriction, Haskell98. The well-commented code is available at http://okmij.org/ftp/Haskell/DSLSharing.hs First a few comments on the tricky code. It is true that (absent programmer's proclamations and code structuring forms) a complete method of common sub-expression elimination must inspect every sub-expression in the program. That inspection must include at least one comparison of a node with some other nodes. As I understand the original problem had less to do with the number of comparison but more to do with the cost of a single comparison. In an impure language, we can use constant-time physical equality. It is usually provided natively as pointer comparison, and can be trivially emulated via mutation. The original poster used pure Haskell and the following representation for the program graph: data Expression = Add Expression Expression | Sub Expression Expression | Variable String | Constant Int deriving Eq Here, the derived equality operation, albeit pure, no longer takes constant time. Comparing nodes near the root of a deep tree really takes a while. As the previous message on DSL with sharing showed, one can do common sub-expression elimination and the conversion of the program tree to a DAG using a constant-time node equality operation, without sacrificing purity. The tricky function is a metaprogram that builds a large DSL program: (tricky 12) yields a single DSL expression with 8191 nodes. Such humongous expressions with thousands of components are unlikely to be written by human programmers (although can be easily generated). Many compilers will choke if we submit a program with one large expression. (Incidentally, the previously posted code converts the tree (tricky 12) to a 12-node DAG in 0.25 secs on 1GHz Pentium). The reason we can compile much larger projects is because we structure them, into compilation units, functions, let-blocks. The structure gives the common sub-expression eliminator and other optimizer phases much needed hints and so significantly limits the search space. For example, hardly any compiler searches for common sub-expressions across compilation units. More importantly for us here, forms like let-expressions let the programmer declare that the results of certain computations be shared. Although the tricky code also contains a let-expression (masqueraded as 'where'), the sharing there occurs at the meta-level and benefits the generator rather than the generated program. We share code generators rather than the generated code. The importance of placing 'let' in the right phase has been extensively discussed in http://www.cs.rice.edu/~taha/publications/conference/pepm06.pdf also in the context of a DSL (for dynamic programming). In our case, we need to give our DSL programmer a way to state their intention on sharing results of DSL computations. The programmer declares certain expressions common, and thus greatly helps the compiler as well as human readers of the code. As Chung-chieh Shan has pointed out, we need to introduce a "let" construct in the _embedded_ language. Since our DSL already has (concrete) variables with string names, we can extend our language thusly: let_ "v1" (add (constant 1) (variable "x)) (add (variable v1") (variable "v1")) We chose a different way: higher-order abstract syntax. We use variables of the metalanguage (that is, Haskell) as let-bound variables. Our language is now defined as > class Exp repr where > constant :: Int -> repr Int > variable :: String -> repr Int > add :: repr Int -> repr Int -> repr Int > sub :: repr Int -> repr Int -> repr Int > let_ :: repr a -> (repr a -> repr b) -> repr b -- like flip ($) Here are simple programs in our language > a = add (constant 10) (variable "i1") > b = sub (variable "i2") (constant 2) > c = add a b > d = add c c > e = add d d -- "e" now as 16 leaf nodes. > e' = let_ d (\x -> add x x) The programs (e) and (e') evaluate to the same integer given the same environment for "i1" and "i2". The two programs differ in how sharing is declared. The program (e) uses the identifier (d) twice; even if GHC shares the corresponding expressions rather than copies them (a Haskell system is not obliged to share anything: sharing is not observable in Haskell98), what GHC shares are metalanguage computations. Although the metalanguage (Haskell) is pure, the object language does not have to be. Indeed, the common-subexpression elimination, when considered as an evaluation of an object expression, is an impure evaluation. The same object expression may give, in different contexts, different results (that is, compile to different assembly code). In the case of (e'), we explicitly stated that "d" is a common sub-expression. It must be executed once, with the results shared. The difference is easy to see if we print e and e': *DSLSharing> test_showe "10 + i1 + i2 - 2 + 10 + i1 + i2 - 2 + 10 + i1 + i2 - 2 + 10 + i1 + i2 - 2" *DSLSharing> test_showe' "let v0 = 10 + i1 + i2 - 2 + 10 + i1 + i2 - 2 in v0 + v0" Higher-order syntax for let_ (see e') seems better than that based on concrete variable names. As test-showe' demonstrates, we can easily convert from higher-order abstract to the concrete syntax. The converse is much more cumbersome. We easily extend the previously written common sub-expression eliminator by adding the clause for let_ > instance Exp A where > ... > let_ e f = A(do > x <- unA e > unA $ f (A (return x))) And that is it. We can write the tricky function with the explicit sharing: > tricky' 0 = constant 0 > tricky' d = let_ (tricky' (d-1)) (\g -> add g g) > > test_tricky' n = runState (unA (tricky' n)) exmap0 *DSLSharing> test_tricky' 12 (AAdd 12, ExpMaps {hashcnt = 13, ctmap = fromList [(0,0)], vrmap = fromList [], admap = fromList [(1,(AConst 0,AConst 0)),(2,(AAdd 1,AAdd 1)), (3,(AAdd 2,AAdd 2)),(4,(AAdd 3,AAdd 3)),(5,(AAdd 4,AAdd 4)), (6,(AAdd 5,AAdd 5)),(7,(AAdd 6,AAdd 6)),(8,(AAdd 7,AAdd 7)), (9,(AAdd 8,AAdd 8)),(10,(AAdd 9,AAdd 9)),(11,(AAdd 10,AAdd 10)), (12,(AAdd 11,AAdd 11))], sumap = fromList []}) (0.01 secs, 0 bytes) Indeed it takes negligible time. In fact, test_tricky' 12 takes (0.01 secs, 561860 bytes) test_tricky' 100 takes (0.03 secs, 1444888 bytes) If the DAG corresponding to (test_tricky' 100) were converted to a tree, it would have had 2^101 -1 nodes (which is more than 10^31). From uhollerbach at gmail.com Thu Feb 14 23:23:29 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Thu Feb 14 23:21:59 2008 Subject: [Haskell-cafe] fast integer base-2 log function? In-Reply-To: <65d7a7e0802110955v7c2e9d74ibf02385712fab119@mail.gmail.com> References: <20080211061619.IPFX5833.fep27.mail.dk@www.haskell.org> <200802110744.10469.naur@post11.tele.dk> <65d7a7e0802110955v7c2e9d74ibf02385712fab119@mail.gmail.com> Message-ID: <65d7a7e0802142023k6303042fke1b76122cfaa7c6d@mail.gmail.com> Hi, all, a few days ago I had asked about fast integer log-2 routines, and got a couple of answers. I've now had a chance to play with the routines, and here's what I found. Initially, Thorkil's routine taken from the Haskell report was about 30% or so faster than mine. When I replaced the calls to my routine "powi" with native calls to ^, my routine became about 10% faster than Thorkil's routine. (I undoubtedly had some reason for using my own version of powi, but I have no idea anymore what that reason was... :-/ ) I initially thought that that speed difference might be due to the fact that my routine had base 2 hard-wired, whereas his routine is for general bases, but that seems not to be the case: when I modified my version to also do general bases, it stayed pretty much the same. I didn't do enough statistics-gathering to really be absolutely positively certain that my routine is indeed 10.000% faster, but there did seem to be a slight edge in speed there. Here's the latest version, in case anyone's interested. I had previously had effectively a bit-length version; since I made it general base-b I changed it to a log function. > ilogb :: Integer -> Integer -> Integer > ilogb b n | n < 0 = ilogb b (- n) > | n < b = 0 > | otherwise = (up b n 1) - 1 > where up b n a = if n < (b ^ a) > then bin b (quot a 2) a > else up b n (2*a) > bin b lo hi = if (hi - lo) <= 1 > then hi > else let av = quot (lo + hi) 2 > in if n < (b ^ av) > then bin b lo av > else bin b av hi Stefan's routine is, as expected, much much faster still: I tested the first two routines on numbers with 5 million or so bits and they took ~20 seconds of CPU time, whereas I tested Stefan's routine with numbers with 50 million bits, and it took ~11 seconds of CPU time. The limitation of Stefan's routine is of course that it's limited to base 2 -- it is truly a bit-length routine -- and I guess another potential limitation is that it uses GHC extensions, not pure Haskell (at least I had to compile it with -fglasgow-exts). But it's the speed king if those limitations aren't a problem! Uwe From stefanor at cox.net Thu Feb 14 23:29:05 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Thu Feb 14 23:27:38 2008 Subject: [Haskell-cafe] fast integer base-2 log function? In-Reply-To: <65d7a7e0802142023k6303042fke1b76122cfaa7c6d@mail.gmail.com> References: <20080211061619.IPFX5833.fep27.mail.dk@www.haskell.org> <200802110744.10469.naur@post11.tele.dk> <65d7a7e0802110955v7c2e9d74ibf02385712fab119@mail.gmail.com> <65d7a7e0802142023k6303042fke1b76122cfaa7c6d@mail.gmail.com> Message-ID: <20080215042905.GA4526@localhost.localdomain> On Thu, Feb 14, 2008 at 08:23:29PM -0800, Uwe Hollerbach wrote: > Stefan's routine is, as expected, much much faster still: I tested the > first two routines on numbers with 5 million or so bits and they took > ~20 seconds of CPU time, whereas I tested Stefan's routine with > numbers with 50 million bits, and it took ~11 seconds of CPU time. The > limitation of Stefan's routine is of course that it's limited to base > 2 -- it is truly a bit-length routine -- and I guess another potential > limitation is that it uses GHC extensions, not pure Haskell (at least > I had to compile it with -fglasgow-exts). But it's the speed king if > those limitations aren't a problem! At the risk of stating the obvious, it also hard-codes 32 bit words and certain configurable (but nobody bothers) details of the GMP data representation (big endian, 0 nails). 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/20080214/2126afcc/attachment.bin From lrpalmer at gmail.com Fri Feb 15 00:13:33 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Feb 15 00:12:03 2008 Subject: [Haskell-cafe] a general question on Arrows In-Reply-To: References: <7ca3f0160802140047x796e75b3x5783a0ee43ac94c3@mail.gmail.com> Message-ID: <7ca3f0160802142113x683b09aawdbf7f79591a3f993@mail.gmail.com> On Thu, Feb 14, 2008 at 7:34 PM, Steve Lihn wrote: > I have a small question on the simulation technique. In both John > Hughes and your code, you wrap the "print" inside the runXYZ (...) to > print out the state of simulation. It is like: > > runArrow ( ... simulation ...then print ...) -< input > > Why don't you structure it like > > y <- runArrow ( ... simulation ... then return observation ... ) -< input > reuse y or print y After attempting to reply to this several times, I think I finally know what you're asking. Well, "observe" and "observeWith" are exported, so you could do that if you wanted. As far as why I didn't do that in my example code, uh, I dunno. Really the purpose of this was to port the Quantum::Entanglement Perl module, for no other reason than that module made me go "Woah! That's awesome!". So I wanted to transliterate the Perl examples which collapsed and printed in one go, because those were what made me feel like I was inside some freaky quantum computer, not just running a simulation module. :-) Luke From donn at drizzle.com Fri Feb 15 01:01:32 2008 From: donn at drizzle.com (Donn Cave) Date: Fri Feb 15 01:00:04 2008 Subject: [Haskell-cafe] ANN: ctemplate, SSL server support in HsOpenSSL, network-minihttp, binary parsing, network-dns In-Reply-To: <93EC276E-1960-4D91-9151-63C1B8BF2FBD@avvanta.com> References: <396556a20802141644h12ae9db9ud16f41ffee463e5d@mail.gmail.com> <93EC276E-1960-4D91-9151-63C1B8BF2FBD@avvanta.com> Message-ID: <6A19DB5B-55E7-49FC-9847-FBB22BE0B453@drizzle.com> On Feb 14, 2008, at 4:44 PM, Adam Langley wrote: > HsOpenSSL now has rudimentary support for writing SSL servers[5] > (clients coming soon). In terms of blocking IO, this /should/ work the > way you would hope (i.e. like a Haskell function w.r.t. forkIO). Coincidentally, night before last I downloaded the openssl source and started trying to think about an SSL library. The thing is, I have always wished for an SSL library that doesn't do I/O, but just transforms data and leaves the I/O to you. I guess that's going to be a good deal more complicated, and in many cases not worth it at all - so there would need to be an SSLIO layer above it - but clinging to some vague reactive-object ideals I imagine that this `pure' SSL core could fit into some kinds of dispatching frameworks where the usual thing would be awkward. Anyway, I'll write again in a few years if I get around to doing anything about it. Donn Cave, donn@avvanta.com From voigt at tcs.inf.tu-dresden.de Fri Feb 15 02:13:24 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Fri Feb 15 02:11:56 2008 Subject: [Haskell-cafe] Re: [Haskell] Mailing List Archive: Search Broken? In-Reply-To: <20080214163312.GA28430@scytale.galois.com> References: <47B3FE2D.1000305@tcs.inf.tu-dresden.de> <20080214163312.GA28430@scytale.galois.com> Message-ID: <47B53B94.3020801@tcs.inf.tu-dresden.de> Don Stewart wrote: > voigt: > >>Hi, >> >>it seems that something is wrong with the search on >> >> http://www.mail-archive.com/haskell@haskell.org/ >> >>Only messages from Nov and Dec 2007 are found, no matter what search >>phrases and date ranges are given. >> >>Worked yesterday and delivered search results over the whole history of >>the archive. >> >>Same for haskell-cafe. >> >>Anyone knows what is going on? > > > I always use gmane, via: > > http://news.gmane.org/search.php?match=haskell The problem with this is that when searching through gmane, and selecting a single message with a hit, one gets only to see that message without its context thread. At least I could not find out a way to switch from the found message to the thread in which it occurred. The search facility on www.mail-archive.com is much nicer in that respect, but as mentioned, as of yesterday seems to have forgotten about all messages prior to November 2007, and from 2008. Too bad... Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From cs-haskell at protempore.net Fri Feb 15 02:33:24 2008 From: cs-haskell at protempore.net (Calvin Smith) Date: Fri Feb 15 02:27:40 2008 Subject: [Haskell-cafe] Re: [Haskell] Mailing List Archive: Search Broken? In-Reply-To: <47B53B94.3020801@tcs.inf.tu-dresden.de> References: <47B3FE2D.1000305@tcs.inf.tu-dresden.de> <20080214163312.GA28430@scytale.galois.com> <47B53B94.3020801@tcs.inf.tu-dresden.de> Message-ID: <47B54044.3050200@protempore.net> On 02/14/2008 11:13 PM, Janis Voigtlaender wrote: > Don Stewart wrote: >> voigt: >> >> I always use gmane, via: >> >> http://news.gmane.org/search.php?match=haskell > > The problem with this is that when searching through gmane, and > selecting a single message with a hit, one gets only to see that message > without its context thread. At least I could not find out a way to > switch from the found message to the thread in which it occurred. > > The search facility on www.mail-archive.com is much nicer in that > respect, but as mentioned, as of yesterday seems to have forgotten about > all messages prior to November 2007, and from 2008. > > Too bad... > > Ciao, > Janis. > I removed haskell@haskell from the recipients. It is possible to get to the thread-view of a message from just the bare message page. For example, if I turn up in a google search, which takes me to the article without context, I then click on the linked subject of the message, which redirects me to , which is the threaded view. It still doesn't seem to allow you to get to other threads before and after the given thread, but at least you can view the entire thread of the message you found. It's definitely not very intuitive. Cheers, Calvin From wb at arb-phys.uni-dortmund.de Fri Feb 15 02:37:05 2008 From: wb at arb-phys.uni-dortmund.de (Wilhelm B. Kloke) Date: Fri Feb 15 02:35:50 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> <20080214052011.vdcelmp6yo8c84c4@webmail.spamcop.net> Message-ID: Ben Franksen schrieb: > Wilhelm B. Kloke wrote: >> ajb@spamcop.net schrieb: >>> >> I would consider a good idea if ghc would provide language support to >> this sort of integers. > > No need, you can do that for yourself: > > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > newtype DInt = DInt Double deriving (Eq, Ord, Enum, Num) > > instance Show DInt where show (DInt x) = show (truncate x :: Integer) Probably you missed the point I wanted to make. This works only properly, if you can catch the Inexact Trap which indicates the overflow. The problem whith normal Ints is that the hardware does not support overflow detection. You get silent wrong results if you use an Int type which maps to C int, but not if it maps to C float or double with Inexact trap enabled. Therefore you need add runtime checks to be sure that you notice a possible overflow condition. -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key From voigt at tcs.inf.tu-dresden.de Fri Feb 15 02:39:18 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Fri Feb 15 02:37:48 2008 Subject: [Haskell-cafe] Re: [Haskell] Mailing List Archive: Search Broken? In-Reply-To: <47B54044.3050200@protempore.net> References: <47B3FE2D.1000305@tcs.inf.tu-dresden.de> <20080214163312.GA28430@scytale.galois.com> <47B53B94.3020801@tcs.inf.tu-dresden.de> <47B54044.3050200@protempore.net> Message-ID: <47B541A6.7090704@tcs.inf.tu-dresden.de> Calvin Smith wrote: > On 02/14/2008 11:13 PM, Janis Voigtlaender wrote: > >>Don Stewart wrote: >> >>>voigt: >>> >>>I always use gmane, via: >>> >>> http://news.gmane.org/search.php?match=haskell >> >>The problem with this is that when searching through gmane, and >>selecting a single message with a hit, one gets only to see that message >>without its context thread. At least I could not find out a way to >>switch from the found message to the thread in which it occurred. >> >>The search facility on www.mail-archive.com is much nicer in that >>respect, but as mentioned, as of yesterday seems to have forgotten about >>all messages prior to November 2007, and from 2008. >> >>Too bad... >> >>Ciao, >>Janis. >> > > > I removed haskell@haskell from the recipients. > > It is possible to get to the thread-view of a message from just the bare > message page. For example, if I turn up > in a google > search, which takes me to the article without context, I then click on > the linked subject of the message, which redirects me to > , > which is the threaded view. It still doesn't seem to allow you to get to > other threads before and after the given thread, but at least you can > view the entire thread of the message you found. > > It's definitely not very intuitive. And the funny thing is that I tried just that yesterday, to no avail. Now I found that it does work for haskell.cafe, but not for haskell.general, which I tried yesterday. Strange. (The problem on mail-archive affects both lists haskell-cafe and haskell proper.) Thanks for the solution at least for haskell-cafe! Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From apfelmus at quantentunnel.de Fri Feb 15 05:13:59 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Feb 15 05:12:40 2008 Subject: [Haskell-cafe] Re: [Haskell] Mailing List Archive: Search Broken? In-Reply-To: <47B53B94.3020801@tcs.inf.tu-dresden.de> References: <47B3FE2D.1000305@tcs.inf.tu-dresden.de> <20080214163312.GA28430@scytale.galois.com> <47B53B94.3020801@tcs.inf.tu-dresden.de> Message-ID: Janis Voigtlaender wrote: > when searching through gmane, and > selecting a single message with a hit, one gets only to see that message > without its context thread. At least I could not find out a way to > switch from the found message to the thread in which it occurred. The subject line is a hyperlink that points to the context thread of the message (which is displayed with frames). Regards, apfelmus From voigt at tcs.inf.tu-dresden.de Fri Feb 15 05:19:41 2008 From: voigt at tcs.inf.tu-dresden.de (Janis Voigtlaender) Date: Fri Feb 15 05:18:11 2008 Subject: [Haskell-cafe] Re: [Haskell] Mailing List Archive: Search Broken? In-Reply-To: References: <47B3FE2D.1000305@tcs.inf.tu-dresden.de> <20080214163312.GA28430@scytale.galois.com> <47B53B94.3020801@tcs.inf.tu-dresden.de> Message-ID: <47B5673D.8070101@tcs.inf.tu-dresden.de> apfelmus wrote: > Janis Voigtlaender wrote: > >> when searching through gmane, and selecting a single message with a >> hit, one gets only to see that message without its context thread. At >> least I could not find out a way to switch from the found message to >> the thread in which it occurred. > > > The subject line is a hyperlink that points to the context thread of the > message (which is displayed with frames). ... only in the case of haskell.cafe, but not for haskell.general. (see my response to Calvin Smith on the cafe list) Actually, in the case of haskell.general, it seems to work if and only if the current message is the first one in a thread. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de From prstanley at ntlworld.com Fri Feb 15 05:41:15 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Fri Feb 15 05:39:46 2008 Subject: [Haskell-cafe] set terminology Message-ID: <7.0.1.0.0.20080215103804.01cff7c8@ntlworld.com> Hi domain, source --- are the two different things? I'm sure I read somewhere that the source \subseteq domain in mappings. The same was said about range and target -- target \subseteq range. Any ideas? Thanks, Paul From apfelmus at quantentunnel.de Fri Feb 15 05:42:32 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Feb 15 05:41:10 2008 Subject: [Haskell-cafe] Re: [Haskell] Mailing List Archive: Search Broken? In-Reply-To: <47B5673D.8070101@tcs.inf.tu-dresden.de> References: <47B3FE2D.1000305@tcs.inf.tu-dresden.de> <20080214163312.GA28430@scytale.galois.com> <47B53B94.3020801@tcs.inf.tu-dresden.de> <47B5673D.8070101@tcs.inf.tu-dresden.de> Message-ID: Janis Voigtlaender wrote: > apfelmus wrote: >> The subject line is a hyperlink that points to the context thread of >> the message (which is displayed with frames). > > .... only in the case of haskell.cafe, but not for haskell.general. (see > my response to Calvin Smith on the cafe list) > > Actually, in the case of haskell.general, it seems to work if and only > if the current message is the first one in a thread. Oh! That used to work in haskell.general, too. Hm, it does seem to work for messages after August 2007. Looks like the search homunculus is on strike... Regards, apfelmus From Andrew.Butterfield at cs.tcd.ie Fri Feb 15 06:05:11 2008 From: Andrew.Butterfield at cs.tcd.ie (Andrew Butterfield) Date: Fri Feb 15 06:03:18 2008 Subject: [Haskell-cafe] Mutable arrays In-Reply-To: <20080206221123.GA4083@localhost.localdomain> References: <7665bf90802050836s4d782b25j6a87584c87007c2d@mail.gmail.com> <7665bf90802052214l2c2a0638w90f8bff1a74bf978@mail.gmail.com> <7665bf90802060824s5c7004edx9c221d2375700d46@mail.gmail.com> <20080206163359.GA29074@scytale.galois.com> <00b801c868e3$8550d070$8ff27150$@be> <404396ef0802060925l2ce6fe6fw8dfea1a8e0469514@mail.gmail.com> <00ba01c868e8$08eb5140$1ac1f3c0$@be> <47AA1F47.7050501@cs.tcd.ie> <20080206221123.GA4083@localhost.localdomain> Message-ID: <47B571E7.1080205@cs.tcd.ie> Stefan O'Rear wrote: > On Wed, Feb 06, 2008 at 08:57:43PM +0000, Andrew Butterfield wrote: > >> In Clean, we not only have explicit access to the world, but >> we can partition it. Simplifying somewhat, we could open up >> pairs of file-handle (f1.in,f1.out), (f2.in,f2,out) ... (fn.in,fn.out), >> which does have to be done sequentially, since each file opening modifies >> the (global) filesystem. However, once this is done, >> we could, in principle, execute the fn in any order, >> and indeed in such a way that the implementation could choose to >> do them in parallel - this potential for (admittedly limited) >> deterministic parallel execution of I/O actions is possible with >> uniqueness types, but not epxressible in the monadic world as >> currently formulated. >> > > What if f1.out is a symlink to f2.out? I don't think Clean satisfies > the evaluation order independance that is so treasured here. > Sorry for lateness in getting back - it's been one of those fortnights.. The case you mention won't arise simply because during the process of opening these file-handles (which cannot be done in parallel, because they all modify the filesystem), the write conflict will be detected, and the opening of the second one will fail. Once the file-handle pairs are all opened we have a guarantee that all writes are to distinct files. -- -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. Course Director, B.A. (Mod.) in CS and ICT degrees, Year 4. Department of Computer Science, Room F.13, O'Reilly Institute, Trinity College, University of Dublin, Ireland. http://www.cs.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- From lemming at henning-thielemann.de Fri Feb 15 07:47:45 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 15 07:46:17 2008 Subject: [Haskell-cafe] ANN: two new packages: carray, fft In-Reply-To: <87d4qzz0zx.fsf@59A2.org> References: <87d4qzz0zx.fsf@59A2.org> Message-ID: On Thu, 14 Feb 2008, Jed Brown wrote: > Hopefully these are mature enough to be generally useful. I would > appreciate any comments regarding the interface. The FFTW API is not > particularly nice for building a pure interface on. because FFTW stores global data (called 'plan's) > Some of the transforms could be made slightly faster at the expense of > a much nastier interface, but unless someone needs the extra few > percent, or is pushing the memory limits on their machine, I'm not > inclined to expose the underlying nastiness. I want to mention once again that there is already a Fast Fourier transform for arbitrary length that is coded entirely in Haskell. http://hackage.haskell.org/packages/archive/dsp/0.2/doc/html/Numeric-Transform-Fourier-FFT.html From simonmarhaskell at gmail.com Fri Feb 15 10:21:30 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 15 10:20:02 2008 Subject: [Haskell-cafe] Re: Proper exception handling In-Reply-To: <20080210202801.GA3753@localhost.localdomain> References: <1202672979.3336.11.camel@localhost> <20080210202801.GA3753@localhost.localdomain> Message-ID: <47B5ADFA.1050601@microsoft.com> Stefan O'Rear wrote: > On Sun, Feb 10, 2008 at 02:49:39PM -0500, Thomas DuBuisson wrote: >> Cafe, >> Fact 1: ghc{,i} does not crash when executing this code. >> Fact 2: I do not want this to crash. >> Question: Is there some theoretical window between the 'catchDyn' exception handling and the recursive call to 'catchThatDamnError' that could result in an unhandled exception? (of type 'DynError', of coarse) >> >> I suppose I am looking for an answer to this question from a language standpoint as well as a compiler pov. >> >> As an aside: I see at least one way to be certain of the safty by wrapping the call to forkIO in 'catchDyn', reforking if an exception is caught, and passing the new ThreadId to throwConstantly via shared mutable state - I'd like to avoid all this if my current example is safe. >> >> Thomas > > Asynchronous exceptions are blocked in handlers, so there is no window - > infact all exceptions after the first won't be delivered at all. > However, you could be unlucky enough to throw the first error before the > first catchDyn, so more synchronisation might be needed. In 6.8.2, forkIO inherits the blocked status from the parent, so you can say block $ forkIO ... to avoid this race. Cheers, Simon From simonmarhaskell at gmail.com Fri Feb 15 10:24:29 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Fri Feb 15 10:23:03 2008 Subject: [Haskell-cafe] Re: fast integer base-2 log function? In-Reply-To: <20080211072107.GA5038@localhost.localdomain> References: <65d7a7e0802102215m42e5b228xacfa4047a3a54075@mail.gmail.com> <20080211072107.GA5038@localhost.localdomain> Message-ID: <47B5AEAD.3050409@microsoft.com> Stefan O'Rear wrote: > On Sun, Feb 10, 2008 at 10:15:58PM -0800, Uwe Hollerbach wrote: >> Hello, haskellers, >> >> Is there a fast integer base-2 log function anywhere in the standard >> libraries? I wandered through the index, but didn't find anything that >> looked right. I need something that's more robust than logBase, it >> needs to handle numbers with a few to many thousands of digits. I >> found a thread from a couple of years ago that suggested there was no >> such routine, and that simply doing "length (show n)" might be the >> best. That seems kind of... less than elegant. I've come up with a >> routine, shown below, that seems reasonably fast (a few seconds of CPU >> time for a million-bit number, likely adequate for my purposes), but >> it seems that something with privileged access to the innards of an >> Integer ought to be even much faster -- it's just a simple walk along >> a list (array?) after all. Any pointers? Thanks! > > Even easier. > > > {-# LANGUAGE MagicHash #-} > import GHC.Exts > import Data.Bits > > -- experiment with using a LUT here (hint: FFI + static arrays in C) > ilog2i0, ilog2i1, ilog2i2, ilog2i3, ilog2i4 :: Int -> Int -> Int > ilog2i0 k x | x .&. 0xFFFF0000 /= 0 = ilog2i1 (k + 16) (x `shiftR` 16) > | otherwise = ilog2i1 k x > ilog2i1 k x | x .&. 0xFF00 /= 0 = ilog2i2 (k + 8) (x `shiftR` 8) > | otherwise = ilog2i2 k x > ilog2i2 k x | x .&. 0xF0 /= 0 = ilog2i3 (k + 4) (x `shiftR` 4) > | otherwise = ilog2i3 k x > ilog2i3 k x | x .&. 0xC /= 0 = ilog2i4 (k + 2) (x `shiftR` 2) > | otherwise = ilog2i4 k x > ilog2i4 k x | x .&. 0x2 /= 0 = k + 1 + (x `shiftR` 1) > | otherwise = k + x > > log2i :: Integer -> Int -- actually returns bit length, and returns garbage on negatives, but do you care? > log2i (J# len adr) = ilog2i0 0 (I# (indexIntArray# adr (len -# 1#))) + I# (32# *# (len -# 1#)) > log2i (S# sml) = ilog2i0 0 (I# sml) I don't know if this would be any faster in practice, but it avoids those comparisons: http://aggregate.org/MAGIC/#Log2%20of%20an%20Integer Cheers, Simon From bf3 at telenet.be Fri Feb 15 11:14:43 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Fri Feb 15 11:13:06 2008 Subject: [Haskell-cafe] *** JOB OFFER *** related to realtime 3D graphics, animation and reactive content Message-ID: <000901c86fed$dff421b0$9fdc6510$@be> Anygma is a startup company focusing on generating easy-to-use tools for creating audio-visual 2D/3D content, in the area of entertainment, media, corporate communication and the internet. Anygma has recently raised new capital in order to fund the development of a new platform targeted towards artists and designers for generating procedural and reactive geometry, animations and games. We are looking for talented and passionate computer scientists and software engineers to help us design and implement a prototype of this platform. If you are interested in applying Haskell, OpenGL, and some C/C++, to create such a platform, feel free to apply for the job by sending an email to peter AT nazooka DOT com. More information about the job offer can be found here. Thank you, Peter Verswyvelen, Software Architect, www.anygma.com PS: This job offer was already placed in the Haskell Caf? a while ago, but apparently many Haskellers did not notice it, so here?s take#2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080215/2dc98ee8/attachment.htm From jed at 59A2.org Fri Feb 15 12:07:51 2008 From: jed at 59A2.org (Jed Brown) Date: Fri Feb 15 12:05:24 2008 Subject: [Haskell-cafe] ANN: two new packages: carray, fft In-Reply-To: (Henning Thielemann's message of "Fri, 15 Feb 2008 13:47:45 +0100 (MET)") References: <87d4qzz0zx.fsf@59A2.org> Message-ID: <87tzkaxi54.fsf@59A2.org> On 15 Feb 2008, lemming@henning-thielemann.de wrote: On Thu, 14 Feb 2008, Jed Brown wrote: >> Hopefully these are mature enough to be generally useful. I would >> appreciate any comments regarding the interface. The FFTW API is not >> particularly nice for building a pure interface on. > > because FFTW stores global data (called 'plan's) Yes. In the Haskell interface, the existence of these plans is hidden From the user. In the advanced interface, you can influence the quality of the plan which may effect how long a transform takes to compute, but it will not effect the result. If FFTW added the ability to query the plan cache, or if we kept a mirror Haskell-side, then we could make better use of memory which would improve performance. Fortunately, we have a really fast malloc. >> Some of the transforms could be made slightly faster at the expense of >> a much nastier interface, but unless someone needs the extra few >> percent, or is pushing the memory limits on their machine, I'm not >> inclined to expose the underlying nastiness. > > I want to mention once again that there is already a Fast Fourier > transform for arbitrary length that is coded entirely in Haskell. > http://hackage.haskell.org/packages/archive/dsp/0.2/doc/html/Numeric-Transform-Fourier-FFT.html Indeed, this package does exist, but it is lacking compared to FFTW with regard to multi-dimensional transforms, real to real transforms, and performance (particularly for large sizes). The transforms in the dsp package are only a few times slower than FFTW for small sizes, but it quickly becomes orders of magnitude slower, especially when the size is not a power of two. It also uses several times more memory, due in part to always using boxed arrays. Modifying dsp to allow use of unboxed arrays would be nice. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080215/d4eed40f/attachment.bin From ryani.spam at gmail.com Fri Feb 15 12:21:52 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Feb 15 12:20:21 2008 Subject: [Haskell-cafe] fast integer base-2 log function? In-Reply-To: <65d7a7e0802142023k6303042fke1b76122cfaa7c6d@mail.gmail.com> References: <20080211061619.IPFX5833.fep27.mail.dk@www.haskell.org> <200802110744.10469.naur@post11.tele.dk> <65d7a7e0802110955v7c2e9d74ibf02385712fab119@mail.gmail.com> <65d7a7e0802142023k6303042fke1b76122cfaa7c6d@mail.gmail.com> Message-ID: <2f9b2d30802150921qf3b649amb227551256fa3fe3@mail.gmail.com> On Thu, Feb 14, 2008 at 8:23 PM, Uwe Hollerbach wrote: > Stefan's routine is, as expected, much much faster still: I tested the > first two routines on numbers with 5 million or so bits and they took > ~20 seconds of CPU time, whereas I tested Stefan's routine with > numbers with 50 million bits, and it took ~11 seconds of CPU time. This seems wrong to me; that routine should take a small constant amount of time. I suspect you are measuring the time to construct the 50-million bit numbers as well. If you constructed a single number and called this routine on it several times I am sure you would get far different results, with the first routines taking ~7-11s each and Stefan's GHC/GMP-magic taking almost nothing. -- ryan From uhollerbach at gmail.com Fri Feb 15 12:55:21 2008 From: uhollerbach at gmail.com (Uwe Hollerbach) Date: Fri Feb 15 12:53:50 2008 Subject: [Haskell-cafe] fast integer base-2 log function? In-Reply-To: <2f9b2d30802150921qf3b649amb227551256fa3fe3@mail.gmail.com> References: <20080211061619.IPFX5833.fep27.mail.dk@www.haskell.org> <200802110744.10469.naur@post11.tele.dk> <65d7a7e0802110955v7c2e9d74ibf02385712fab119@mail.gmail.com> <65d7a7e0802142023k6303042fke1b76122cfaa7c6d@mail.gmail.com> <2f9b2d30802150921qf3b649amb227551256fa3fe3@mail.gmail.com> Message-ID: <65d7a7e0802150955m3b05ffeby1561818bdc87a444@mail.gmail.com> Yes, I suspect you are right. I didn't look into that in much detail, although I did try exchanging "(2 ^ 50000000)" with "(1 `shiftL` 50000000)"; but that didn't make any difference. Uwe On Fri, Feb 15, 2008 at 9:21 AM, Ryan Ingram wrote: > On Thu, Feb 14, 2008 at 8:23 PM, Uwe Hollerbach > wrote: > > Stefan's routine is, as expected, much much faster still: I tested the > > first two routines on numbers with 5 million or so bits and they took > > ~20 seconds of CPU time, whereas I tested Stefan's routine with > > numbers with 50 million bits, and it took ~11 seconds of CPU time. > > This seems wrong to me; that routine should take a small constant > amount of time. I suspect you are measuring the time to construct the > 50-million bit numbers as well. If you constructed a single number > and called this routine on it several times I am sure you would get > far different results, with the first routines taking ~7-11s each and > Stefan's GHC/GMP-magic taking almost nothing. > > -- ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080215/50bb1177/attachment.htm From dot at dotat.at Fri Feb 15 13:15:15 2008 From: dot at dotat.at (Tony Finch) Date: Fri Feb 15 13:13:51 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] In-Reply-To: <20080215035124.4C509A99B@Adric.metnet.fnmoc.navy.mil> References: <20080215035124.4C509A99B@Adric.metnet.fnmoc.navy.mil> Message-ID: On Thu, 14 Feb 2008, oleg@okmij.org wrote: > > As I understand the original problem had less to do with the number of > comparison but more to do with the cost of a single comparison. In an > impure language, we can use constant-time physical equality. It is > usually provided natively as pointer comparison, and can be trivially > emulated via mutation. In Haskell you can (with care) use System.Mem.StableName. http://research.microsoft.com/~simonpj/Papers/weak.htm Tony. -- f.a.n.finch http://dotat.at/ VIKING NORTH UTSIRE: SOUTHERLY 5 OR 6, OCCASIONALLY 7 LATER IN NORTH. MODERATE OR ROUGH. FAIR. GOOD. From jmaessen at alum.mit.edu Fri Feb 15 14:12:39 2008 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Fri Feb 15 14:11:13 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] In-Reply-To: References: <20080215035124.4C509A99B@Adric.metnet.fnmoc.navy.mil> Message-ID: On Feb 15, 2008, at 1:15 PM, Tony Finch wrote: > On Thu, 14 Feb 2008, oleg@okmij.org wrote: >> >> As I understand the original problem had less to do with the number >> of >> comparison but more to do with the cost of a single comparison. In an >> impure language, we can use constant-time physical equality. It is >> usually provided natively as pointer comparison, and can be trivially >> emulated via mutation. > > In Haskell you can (with care) use System.Mem.StableName. > http://research.microsoft.com/~simonpj/Papers/weak.htm Extra points to anyone who can demonstrate this actually in use for caching. -Jan-Willem Maessen From lemming at henning-thielemann.de Fri Feb 15 16:11:16 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 15 16:30:57 2008 Subject: [Haskell-cafe] ANN: two new packages: carray, fft In-Reply-To: <87tzkaxi54.fsf@59A2.org> References: <87d4qzz0zx.fsf@59A2.org> <87tzkaxi54.fsf@59A2.org> Message-ID: On Fri, 15 Feb 2008, Jed Brown wrote: > On 15 Feb 2008, lemming@henning-thielemann.de wrote: > > On Thu, 14 Feb 2008, Jed Brown wrote: > > >> Hopefully these are mature enough to be generally useful. I would > >> appreciate any comments regarding the interface. The FFTW API is not > >> particularly nice for building a pure interface on. > > > > because FFTW stores global data (called 'plan's) > > Yes. In the Haskell interface, the existence of these plans is hidden > From the user. With locks for threaded use? From jed at 59A2.org Fri Feb 15 17:21:44 2008 From: jed at 59A2.org (Jed Brown) Date: Fri Feb 15 17:19:17 2008 Subject: [Haskell-cafe] ANN: two new packages: carray, fft In-Reply-To: (Henning Thielemann's message of "Fri, 15 Feb 2008 22:11:16 +0100 (MET)") References: <87d4qzz0zx.fsf@59A2.org> <87tzkaxi54.fsf@59A2.org> Message-ID: <878x1lyi6f.fsf@59A2.org> On 15 Feb 2008, lemming@henning-thielemann.de wrote: > On Fri, 15 Feb 2008, Jed Brown wrote: > > > On 15 Feb 2008, lemming@henning-thielemann.de wrote: > > > > On Thu, 14 Feb 2008, Jed Brown wrote: > > > > >> Hopefully these are mature enough to be generally useful. I would > > >> appreciate any comments regarding the interface. The FFTW API is not > > >> particularly nice for building a pure interface on. > > > > > > because FFTW stores global data (called 'plan's) > > > > Yes. In the Haskell interface, the existence of these plans is hidden > > From the user. > > With locks for threaded use? In FFTW, planning is not thread-safe, but execution of plans is. The Haskell library takes a lock during planning, but releases it before execution. Planning can be time-consuming if you want a high quality plan, and unfortunately this phase is single threaded. It would be nice if FFTW would expose slightly more of its internal interface, or take its own lock when modifying it's cache so that planning would be thread-safe. Once a plan for your transform size is created (or imported through the wisdom interface) the call to the planner will return immediately and everything else can run in parallel. In the Haskell interface, the default planner is 'estimate' which just employs heuristics rather than actually computing some transforms. If you have imported the correct wisdom, this will still do an optimized transform. If not, it will be less than optimal, but there will be no time-consuming planning phase. If you are concerned about getting the absolute best performance, you can use the advanced interface (which still hides locking, memory allocation, and internals of multi-dimensional transforms) for more control over planning. Jed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080215/9c28a047/attachment.bin From westondan at imageworks.com Fri Feb 15 17:25:02 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Feb 15 17:23:35 2008 Subject: [Haskell-cafe] set terminology In-Reply-To: <7.0.1.0.0.20080215103804.01cff7c8@ntlworld.com> References: <7.0.1.0.0.20080215103804.01cff7c8@ntlworld.com> Message-ID: <47B6113E.4030800@imageworks.com> Since no one else has replied, I will take a stab. This is the terminology I have seen/heard: A mapping in a category is typed. It can map only from a "source" object to a "target" object. There may be zero, one, or multiple such mappings (functions) from a given source to a given target (but at least one if source and target are the same, namely the identity map). For a particular source and target, where the source and target happen not just to be opaque objects but have internal structure (with subset operations), mappings are called functions, the source is called the domain, and the target is called the codomain. Elements X in the domain are mapped to some element Y in the codomain. The set of all such Y is the range, and the set of all such X is the corange. (Wikipedia [1] suggests that there is ambiguity with the word "domain", but I have never heard that elsewhere). Any given subset S of the corange (called a preimage) maps to the corresponding image of S, which is a subset of the range. Preimage and image apply to singleton sets as well, so (by trivial isomorphism) these words apply to mapped elements themselves. In this case, the usual arrow symbol gets a little vertical cap on the left end. In any case, I would not get too hung up on the terminology. It is much more important to understand what is meant in any given setting. [1] http://en.wikipedia.org/wiki/Function_%28mathematics%29 Dan PR Stanley wrote: > Hi > domain, source --- are the two different things? I'm sure I read > somewhere that the source \subseteq domain in mappings. The same was > said about range and target -- target \subseteq range. > Any ideas? > Thanks, Paul > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From westondan at imageworks.com Fri Feb 15 17:59:52 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Feb 15 17:59:21 2008 Subject: [Haskell-cafe] set terminology In-Reply-To: <47B6113E.4030800@imageworks.com> References: <7.0.1.0.0.20080215103804.01cff7c8@ntlworld.com> <47B6113E.4030800@imageworks.com> Message-ID: <47B61968.6090101@imageworks.com> To clarify the distinction between domain/corange as I understand common usage: For a total function, the domain and corange are equal. In the category of sets, all functions are total (by definition of a function). If we generalize to the category of CPOs by associating with every set an extra value called "bottom" (as well as appropriate sums and products containing bottom), and by expanding the concept of function to make use of these bottoms for otherwise undefined mappings, then the domain refers to the thing with the bottoms in it and the corange refers to the largest set (i.e. no bottoms) in the domain whose image contains no bottoms in it. So the corange may not be equal to the domain. So, domain and codomain in Haskell are types (i.e. that include bottom). Range, corange, preimage, and image are only sets that don't include a bottom. Also, a minor correction (after consulting Wikipedia [1]): For any given subset of the range (called an image), there may be multiple subsets of the corange that have this image (the corresponding inverse image). The "preimage" (or complete inverse image) is the exactly one largest such subset of the corange to have the given image. [1] http://en.wikipedia.org/wiki/Function_%28mathematics%29 Dan Dan Weston wrote: > Since no one else has replied, I will take a stab. This is the > terminology I have seen/heard: > > A mapping in a category is typed. It can map only from a "source" object > to a "target" object. There may be zero, one, or multiple such mappings > (functions) from a given source to a given target (but at least one if > source and target are the same, namely the identity map). > > For a particular source and target, where the source and target happen > not just to be opaque objects but have internal structure (with subset > operations), mappings are called functions, the source is called the > domain, and the target is called the codomain. > > Elements X in the domain are mapped to some element Y in the codomain. > The set of all such Y is the range, and the set of all such X is the > corange. (Wikipedia [1] suggests that there is ambiguity with the word > "domain", but I have never heard that elsewhere). > > Any given subset S of the corange (called a preimage) maps to the > corresponding image of S, which is a subset of the range. Preimage and > image apply to singleton sets as well, so (by trivial isomorphism) these > words apply to mapped elements themselves. In this case, the usual arrow > symbol gets a little vertical cap on the left end. > > In any case, I would not get too hung up on the terminology. It is much > more important to understand what is meant in any given setting. > > [1] http://en.wikipedia.org/wiki/Function_%28mathematics%29 > > Dan > > PR Stanley wrote: >> Hi >> domain, source --- are the two different things? I'm sure I read >> somewhere that the source \subseteq domain in mappings. The same was >> said about range and target -- target \subseteq range. >> Any ideas? >> Thanks, Paul >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > From ryani.spam at gmail.com Fri Feb 15 19:50:08 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Feb 15 19:48:35 2008 Subject: [Haskell-cafe] Re: [Haskell] Lemmas about type functions In-Reply-To: <2f9b2d30802151505s54c99da2w55e37ad5238e2ad4@mail.gmail.com> References: <47B5F7AB.3060505@iro.umontreal.ca> <2f9b2d30802151505s54c99da2w55e37ad5238e2ad4@mail.gmail.com> Message-ID: <2f9b2d30802151650h2e55645cwcf584f293da9b482@mail.gmail.com> [moved to haskell-cafe] Hmm, there's a problem here. Since type functions are open, it's not actually true that (forall ts. Cat ts () = ts), because someone could add, for example type instance Cat [a] () = [(a,a)] which makes the lemma no longer true. What you are doing in cat_nil is not proving that Cat ts () = ts, but rather that the form of ts is a particular form which makes that theorem hold, in particular, for all types ts of the form ts = (t1, (t2, ..., (tN, ()) ... )) Cat ts () = ts So for your lemma to hold, you need a new judgement "Valid ts": class Valid ts where cat_nil :: Equiv (Cat ts ()) ts -- other lemmas here instance Valid () where cat_nil = Equiv instance Valid x => Valid (a, x) where cat_nil = case (cat_nil :: Equiv (Cat x ()) x) of Equiv -> Equiv coerce :: forall f ts. Valid ts => f (Cat ts ()) -> f ts coerce x = case (cat_nil :: Equiv (Cat ts ()) ts) of Equiv -> x Also, I'm not sure if GHC can currently optimize away cat_nil; it's clear by construction that cat_nil is total, but if the compiler can't detect that it needs to run and make sure it returns Equiv and not _|_. Otherwise you get an unsound result: (given the type instance above) instance Valid [a] where cat_nil = cat_nil Oleg has pointed out this problem with GADTs as type witnesses here: http://okmij.org/ftp/Haskell/GADT-problem.hs -- ryan On 2/15/08, Ryan Ingram wrote: > I am pretty sure that this doesn't exist, but it's quite interesting. > I've submitted a feature request here: > > http://hackage.haskell.org/trac/ghc/ticket/2101 > > On 2/15/08, Louis-Julien Guillemette wrote: > > Hi all, > > > > I've been using GHC's type families somewhat extensively in my > > type-preserving compiler (BTW, they work great), and quite often I > > come across the need to prove lemmas about those functions. As far as > > I understand there's currently no way to handle such lemmas purely at > > the type level, and I have to encode them as term-level functions. > > > > I wonder if I'm missing something, or otherwise if there are plans to > > provide some way to do this kind of type-level reasoning. > > > > Here's a simple example. > > > > I encode (de Bruijn) type contexts as lists of types of this form: > > > > (t0, (t1, (... , ()...))) > > > > I sometimes concatenate type contexts, and need a lemma stating that > > appending an empty context leaves it unchanged (ts ++ [] == ts). > > > > type family Cat ts0 ts > > type instance Cat () ts' = ts' > > type instance Cat (s, ts) ts' = (s, Cat ts ts') > > > > That is, I need to coerce: > > > > Exp (Cat ts ()) > > > > into: > > > > Exp ts > > > > The way I presently do it is through a term-level function that > > produces a witness that the two types are equivalent, like this: > > > > data Equiv s t where > > Equiv :: (s ~ t) => Equiv s t > > > > cat_nil :: EnvRep ts -> Equiv (Cat ts ()) ts > > cat_nil R0 = Equiv > > cat_nil (Rs _ ts_r) = case cat_nil ts_r of Equiv -> Equiv > > > > coerce :: EnvRep ts -> Exp (Cat ts ()) -> Exp ts > > coerce ts_r e = case cat_nil ts_r of Equiv -> e > > > > > > Louis > > > > _______________________________________________ > > Haskell mailing list > > Haskell@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell > > > From sciolizer at gmail.com Fri Feb 15 21:00:50 2008 From: sciolizer at gmail.com (Joshua Ball) Date: Fri Feb 15 20:59:20 2008 Subject: [Haskell-cafe] *** JOB OFFER *** related to realtime 3D graphics, animation and reactive content In-Reply-To: <000901c86fed$dff421b0$9fdc6510$@be> References: <000901c86fed$dff421b0$9fdc6510$@be> Message-ID: <92fdc3450802151800t4a4f75efwd730258ff2fc6fe@mail.gmail.com> How unfortunate that I didn't see your announcement before, as I have just accepted a job with another company. However, I have added your company to the Haskell in Industry page on the Haskell wiki. http://haskell.org/haskellwiki/Haskell_in_industry Please add a paragraph describing your company. I have also added this announcement to the Haskell jobs page http://haskell.org/haskellwiki/Jobs which is the #1 Google result for a search of "haskell jobs". 2008/2/15 Peter Verswyvelen : > > > > > Anygma is a startup company focusing on generating easy-to-use tools for > creating audio-visual 2D/3D content, in the area of entertainment, media, > corporate communication and the internet. > > Anygma has recently raised new capital in order to fund the development of > a new platform targeted towards artists and designers for generating > procedural and reactive geometry, animations and games. > > We are looking for talented and passionate computer scientists and software > engineers to help us design and implement a prototype of this platform. > > If you are interested in applying Haskell, OpenGL, and some C/C++, to > create such a platform, feel free to apply for the job by sending an email > to peter AT nazooka DOT com. > > More information about the job offer can be found here. > > Thank you, > Peter Verswyvelen, > Software Architect, > www.anygma.com > > > > PS: This job offer was already placed in the Haskell Caf? a while ago, but > apparently many Haskellers did not notice it, so here's take#2 > > > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From jeff1.61803 at gmail.com Fri Feb 15 21:47:23 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Fri Feb 15 21:45:50 2008 Subject: [Haskell-cafe] Help with error Message-ID: <7665bf90802151847g7c572c21n5058d18973475ac@mail.gmail.com> Hello, I get an error message on the code below with GHC. I can't figure out how to get rid of the error. I'd appreciate suggestions on how to fix this. (BTW, the code may look overly combersome because I stripped out anything unnecessary to demonstrate the error.) {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception -fallow-undecidable-instances #-} import qualified Prelude import Prelude import Data.Array.IArray class Sequence seq where slength :: (seq e) -> Int snull :: (seq e) -> Bool shead :: (seq e) -> e stail :: (seq e) -> (seq e) instance Sequence [] where slength = length snull = null shead = head stail = tail class From_seq t where from_seq :: (Sequence seq) => (seq e) -> (t e) instance From_seq [] where from_seq seq | snull seq = [] | otherwise = (shead seq) : (from_seq (stail seq)) from_seq' seq | snull seq = (listArray (0,-1) []) | otherwise = listArray (0,fromIntegral (slength seq) -1) (from_seq seq) {- When I uncomment this out, I get the error messages: Error.hs:41:19: Could not deduce (IArray a e) from the context (From_seq (a i), Ix i, Num i, IArray a e1, Sequence seq) arising from a use of `from_seq'' at Error.hs:41:19-31 instance (Ix i, Num i, IArray a e) => From_seq (a i) where from_seq seq = from_seq' seq -} When I load the module above, I can evaluate the folloing in GHCI *Main> from_seq' [0..5] :: Array Int Double array (0,5) [(0,0.0),(1,1.0),(2,2.0),(3,3.0),(4,4.0),(5,5.0)] But, I'd like to do this with the From_seq class. If anyone has suggestions, I'd be grateful. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080215/4ac486e6/attachment.htm From aslatter at gmail.com Fri Feb 15 22:15:37 2008 From: aslatter at gmail.com (Antoine Latter) Date: Fri Feb 15 22:14:03 2008 Subject: [Haskell-cafe] Help with error In-Reply-To: <7665bf90802151847g7c572c21n5058d18973475ac@mail.gmail.com> References: <7665bf90802151847g7c572c21n5058d18973475ac@mail.gmail.com> Message-ID: <694519c50802151915o33b1f825h8725955ae9b8e799@mail.gmail.com> (sent to the list this time) The problem is in the type-signature for from_seq: from_seq :: (Sequence seq) => (seq e) -> (t e) Neither the From_seq class or the type signature of the from_seq function place any restrictions on the type of e, so the type can be rewritten as: from_seq :: forall e seq . Sequence seq => (seq e) -> (t e) That is, the class explicitly defines from_seq has having norestrictions on e. Your from_seq' function requires the type e (in the error, e1) to inhabit IArray a e. The IArray constraint isn't compatible with the From_seq class definition. You may need to explore multi-parameter type classes: http://en.wikibooks.org/wiki/Haskell/Advanced_type_classes Does this help? -Antoine 2008/2/15 Jeff ? : > Hello, > > I get an error message on the code below with GHC. I can't figure out how > to get rid of the error. I'd appreciate suggestions on how to fix this. > (BTW, the code may look overly combersome because I stripped out anything > unnecessary to demonstrate the error.) > > {-# OPTIONS_GHC > -fglasgow-exts > -fbreak-on-exception > -fallow-undecidable-instances > #-} > > import qualified Prelude > import Prelude > import Data.Array.IArray > > class Sequence seq where > slength :: (seq e) -> Int > snull :: (seq e) -> Bool > shead :: (seq e) -> e > stail :: (seq e) -> (seq e) > > instance Sequence [] where > slength = length > snull = null > shead = head > stail = tail > > class From_seq t where > from_seq :: (Sequence seq) => (seq e) -> (t e) > > instance From_seq [] where > from_seq seq > | snull seq = [] > | otherwise = (shead seq) : (from_seq (stail seq)) > > from_seq' seq > | snull seq = (listArray (0,-1) []) > | otherwise = listArray (0,fromIntegral (slength seq) -1) (from_seq > seq) > > {- > When I uncomment this out, I get the error messages: > > Error.hs:41:19: > Could not deduce (IArray a e) > from the context (From_seq (a i), > Ix i, > Num i, > IArray a e1, > Sequence seq) > arising from a use of `from_seq'' at Error.hs:41:19-31 > > > instance (Ix i, Num i, IArray a e) => From_seq (a i) where > from_seq seq = from_seq' seq > -} > > > When I load the module above, I can evaluate the folloing in GHCI > > *Main> from_seq' [0..5] :: Array Int Double > array (0,5) [(0,0.0),(1,1.0),(2,2.0),(3,3.0),(4,4.0),(5,5.0)] > > But, I'd like to do this with the From_seq class. If anyone has > suggestions, I'd be grateful. > > Thanks, > > Jeff > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From jeff1.61803 at gmail.com Sat Feb 16 04:06:48 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Sat Feb 16 04:05:16 2008 Subject: [Haskell-cafe] Help with error In-Reply-To: <694519c50802151915o33b1f825h8725955ae9b8e799@mail.gmail.com> References: <7665bf90802151847g7c572c21n5058d18973475ac@mail.gmail.com> <694519c50802151915o33b1f825h8725955ae9b8e799@mail.gmail.com> Message-ID: <7665bf90802160106l651f8848s6804b7e49016b27@mail.gmail.com> 2008/2/15 Antoine Latter : > (sent to the list this time) > > The problem is in the type-signature for from_seq: > > from_seq :: (Sequence seq) => (seq e) -> (t e) > > Neither the From_seq class or the type signature of the from_seq > function place any restrictions on the type of e, so the type can be > rewritten as: > > from_seq :: forall e seq . Sequence seq => (seq e) -> (t e) > > That is, the class explicitly defines from_seq has having norestrictions > on e. > > Your from_seq' function requires the type e (in the error, e1) to > inhabit IArray a e. > > The IArray constraint isn't compatible with the From_seq class > definition. You may need to explore multi-parameter type classes: > http://en.wikibooks.org/wiki/Haskell/Advanced_type_classes > > Does this help? > Yes, this helped. I added the type variable, e, to my From_seq class and it worked. Thank you for the explanation. Here are the changes I made: class From_seq t e where from_seq :: (Sequence seq) => (seq e) -> (t e) instance From_seq [] e where from_seq seq | snull seq = [] | otherwise = (shead seq) : (from_seq (stail seq)) instance (Ix i, Num i, IArray a e) => From_seq (a i) e where from_seq seq = from_seq' seq -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080216/440b9d4d/attachment.htm From mfn-haskell-cafe at cs.york.ac.uk Sat Feb 16 05:59:38 2008 From: mfn-haskell-cafe at cs.york.ac.uk (Matthew Naylor) Date: Sat Feb 16 06:01:51 2008 Subject: [Haskell-cafe] Designing DSL with explicit sharing [was: I love purity, but it's killing me] In-Reply-To: <20080215035124.4C509A99B@Adric.metnet.fnmoc.navy.mil> References: <20080215035124.4C509A99B@Adric.metnet.fnmoc.navy.mil> Message-ID: <20080216105938.GA4052@pc149.staff.cs.york.ac.uk> Hi Oleg, at the possible risk of straying from Tom's original problem, consider the following generator that could conceivably occur in practice: > sklansky f [] = [] > sklansky f [x] = [x] > sklansky f xs = left' ++ [ f (last left') r | r <- right' ] > where > (left, right) = splitAt (length xs `div` 2) xs > left' = sklansky f left > right' = sklansky f right > > test_sklansky n = runState sk exmap0 > where > sk = sequence (Prelude.map unA (sklansky add xs)) > xs = Prelude.map (variable . show) [1..n] (Example due to Chalmers folk, Mary Sheeran and Emil Axelsson; sklanksy is similar to scanl1, but contains more parallelism.) If a 128-bit processor were being developed, sklansky could reasonably be passed 128 elements, *Main> test_sklansky 128 -- on an AMD64 2200 (3.71 secs, 296129440 bytes) and could form part of a larger expression, and be called several times. So I think this is close to a real situation where CSE is not practical. But like you say, a human would not write such a humungous expression by hand; hand-written expressions may therefore be ideal for crunching by your CSE method. Still, we might like to write generators like sklansky. Hope is offered by the new "let_" construct, but it's not clear how to use it in this case. The problem is that sklansky is a function over lists of expressions rather than single expressions, and the "let_" construct can only bind single expressions and return single expressions. To write sklansky using your approach, it seems (to me) that the DSL's expression type needs to be extended to support lists. Will this not be complicated and introduce notational inconvenience? (In an earlier post, I outlined a method for embedding algebraic data types in Haskell, and it does have some notational burden.) Matt. From dons at galois.com Sat Feb 16 14:50:55 2008 From: dons at galois.com (Don Stewart) Date: Sat Feb 16 14:49:32 2008 Subject: [Haskell-cafe] Haskell project support and analysis on ohloh Message-ID: <20080216195055.GB31581@scytale.galois.com> Recently ohloh.net added support for analysing haskell code. You can see a range of Haskell projects analysed on ohloh here: http://www.ohloh.net/projects/search?q=haskell Including: http://www.ohloh.net/projects/11789?p=nhc98 http://www.ohloh.net/projects/6869?p=xmonad http://www.ohloh.net/projects/4078?p=HUGS http://www.ohloh.net/projects/6949?p=yi http://www.ohloh.net/projects/10496?p=bytestring http://www.ohloh.net/projects/11766?p=parsec http://www.ohloh.net/projects/11779?p=mtl http://www.ohloh.net/projects/11729?p=binary http://www.ohloh.net/projects/11769?p=X11 http://www.ohloh.net/projects/11790?p=array Which gives rise to some fun 'reports' (and also helps non-Haskell people notice that there are lots of Haskell projects, and developers with experience): xmonad: " Over the past twelve months, 34 developers contributed new code to xmonad. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Ohloh. " nhc98: "nhc has a mature, well established code base. The first lines of source code were added to nhc98 in 1999. This is a relatively long time for an open source project to stay active, and can be a very good sign. A long source control history like this one shows that the project has enough merit to hold contributors's interest for a long time. It might indicate a mature and relatively bug-free code base, and can be a sign of an organized, dedicated development team. " Now, they don't support analysing darcs repos, but the do support git, and with darcs-to-git and darcs2git I've been able to (slowly) get a bunch of repos into git form. You can find the git conversions here, if you're interested: http://www.cse.unsw.edu.au/~dons/git/ (git clone http://www.cse.unsw.edu.au/~dons/git/parsec for example). GHC, base and lambdabot are still in the process of conversion. If you want to do your own conversions, I suggest trying darcs2git first, which is very fast. If that doesn't suceed, try darcs-to-git, which is *much* slower (damn ruby), but seems to be more robust. You can then register the resulting git repo for analysis. The global language statistics, and individual Haskell statistics will update in the next few hours, I suspect. http://www.ohloh.net/languages/38 Though at the time of writing they appear out of date. Happy hacking. -- Don From alangcarter at gmail.com Sat Feb 16 17:05:47 2008 From: alangcarter at gmail.com (Alan Carter) Date: Sat Feb 16 17:04:12 2008 Subject: [Haskell-cafe] Doubting Haskell Message-ID: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Greetings Haskellers, I'm a Haskell newbie, and this post began as a scream for help. Having slept on it I find myself thinking of Simon Peyton-Jones' recent request for good use cases. Perhaps a frustrated - and doubting - newbie can also provide a data point. If my worries are unfounded (and I hope they are), I think it's significant that to me, today, they seem real enough. Please understand that I'm not being negative for the sake of it - rather I'm describing what Haskell looks like from the outside. Let me put it this way. Imagine that two weeks ago my forward-thinking and risk-embracing boss asked me to evaluate Haskell for the upcoming Project X. Further imagine that she ensured I was able to sit in the corner emitting curses for the whole two weeks, and on Monday I have to provide my report. At this point, two weeks in, I would be forced to say that I have no reason to believe that Haskell is useful for real world tasks. ghc is an industrial strength compiler for a toy language. While remarkable claims are made for it, in practice even the experts are often unable to implement the most basic behaviours, and where they are able to implement, they find that their program has become so complex that they are unable to describe or discuss the result. Likely this is a deep problem, not a shallow one. The Haskell community is in denial over this, leading to phenomenal time wasting as one goes round and round in circles playing word games with documentation. This risks a return of the chronic embuggerance that we thought we'd escaped when Vista appeared and the set of people who would have to write Windows device drivers reduced to Hewlett Packard employees, Joanna Rutkowska and criminals. When people enthuse about Haskell, we should run a program called Cat.hs from the haskell.org website, throw fruit at them and laugh. Strong words, but in all honesty I *want* to believe, and if I would make such a report I imagine hundreds if not thousands would say the same thing. I'm hoping I'm wrong about this, and what's actually needed is some work on communication (perhaps from a production programming point of view, which I'd be keen to help with). What got me started with Haskell was the video of an Intel employee holding a Teraflops in his hand. I still remember the very silly September 1991 edition of Scientific American, which asked if a Teraflops would *ever* be built. What a stupid question! Stack up enough VIC20s and eventually you'll get a Teraflops. The question should have been "when". Now it's the size of a CD, and only 80 cores are needed. Unfortunately keeping 80 cores running is tricky. I know this from writing some heavy parallel stuff in the mid-90s. It was all quite clever in it's day. Chuck bloated and unguessable CORBA, do something light with TCP/IP (Beuwolf took that to extremes). Neat linkage like rpcgen gave C, so that I could run fast on an SMP Sequent with 30 cores or on a floorfull of about 70 Sun pizza boxen at night. Unfortunately despite having a nice framework, tracing rays is still hard (the rays and medium were... interesting). Making a problem parallel required a sneaky and dedicated person's sincere skull-sweat. Worse, the solutions so produced had a horrible structural instability about them. Just a small change to the requirement could require a computed value where it wasn't needed before, so that it resulted in big changes to the implementation. The skull-sweating would be needed all over again. (Remember that the big point about objects, which e.g. Booch always emphasized, was that a well chosen set of classes maps well to the domain and so reduces such structural instability.) Even then, it was devilish hard to keep 70 "cores" busy. So watching the Intel guy got my klaxons going. We now need to be able to do parallel with ease. Functional programming just got really important. It's years since I last played with Scheme, but I quickly moved on because I could see the "which Scheme" problem becoming a millstone round everyone's necks outside of research contexts. Ditto Lisp. So Haskell. Grown-up compiler, one standard and (apparently) a decent corpus of example code and tutorials. I might be an imperative programmer, but I do lapse - for example I find it very easy to generate swathes of cross referenced documentation using m4. My head goes kind of weird after a few hours, such that m4 seems sane and it's the rest of the world that's ungainly, so maybe it should be banned like DMT, but I like it. I felt able to enter the functional world. I'll omit the first week of suffering, which I see is a well documented rite of passage. (Although most evaluators will have left the building by the end of week one so it's not helping popularity. Perhaps there could be Squires of the Lambda Calculus who haven't done the vigil, mortification of flesh and so on?) Eventually a 3 page introduction on the O'Reilly website together with a good document called "Haskell for C Programmers" got me to the point where I could access "Yet Another Haskell Tutorial", and I was away... for a bit. After a while I'd written some malformed horrors as answers to exercises, and was telling myself that it's probably just an edge effect - deep within a real Haskell program the ugliness would be invisible, tucked away in Ugly.hs. Then I discovered wxHaskell and got very excited. I really like wxWidgets, and I know it well. If I could play with some Haskell which manipulates wxWidgets I'd progress very quickly! I even have a recent C++ wxWidgets program which was annoying me as I wrote it because of the boilerplate. Great! I can play with type inference and mutter "about bloody time" with a smile on my face. Eventually I got a mix of wxWidgets 2.6.3, wxHaskell from darcs, ghc 6.6 running on my Mac, almost exactly as that permutation was described on the website, and I was off. Within a few hours I had a nice frame, with 10 text controls and legends populating it. It already took less lines than C++, and then I discovered how to bundle all the text controls into a tuple to pass them around, and define some "getters" to access the tuple. My line count shrunk to what it "should" be - that is, something Kolmogorov wouldn't laugh at but is unattainable in C++. I had an onOpen which popped up a dialog and got a filename from the user, with all the properties filled in right. I proved that I could update the values in the text controls from the onOpen. Great. Next, translate the bit that says (pseudocode): if(attempt_file_open) if(attempt_file_read) process That's it. No fancy, complex error messages. Just check the error returns and only proceed if I have something to proceed with. Like grown-ups do. I *will* check my error returns. I have tormented too many newbies to *ever* consider doing anything else. If I cannot check my error returns I will not write the program. This is production programming 101, and I suspect that there's a real issue with priorities between the traditional Haskell community and production programmers. So the time of madness began. I could find examples which did: if(attempt_file_open) attempt_file_read process Which is useless. Other examples did: attempt_file_open if(attempt_file_read) process Which is also useless. So I'm looking through the wxHaskell examples. They're all contrived, using very high level functions to (for example) read a complete image structure from a named file, which as one function had one possible source of errors. I go back to scanning and Googling like crazy. Eventually I notice a bit in "Yet Another Haskell Tutorial" - page 65 - which introduces "bracket", immediately explains that it is useless for my (very common) need, and refers the reader to Section 10 - "Advanced Techniques". The author of this excellent document hasn't yet written Section 10. I wonder why. I pause to examine bracket some more. I really can't tell if the "always" clause gets called if the initialization fails. From the use with file opening it looks like it isn't (or the handle to be closed would be invalid) but that wouldn't help if the initializer had two steps, e.g. called socket(2) and bind(2). This is the kind of thing good production programmers get really het up about. I'm still grovelling through reams of stuff, trying to find out how to open *and* read a file in a grown up way, and I find various programs on haskell.org. There's an implementation of cat(1)! That's the thing! A file concatenator must be able to open *and* read it's file. Eagerly I download it. Curiously there doesn't seem to be any error handling. I compile it and point it at a non-existent file. The program crashes. Horribly. So much for Cat.hs. I feel glad I hadn't been able to cope with the video of Simon Peyton-Jones OSCON talk, because the camera operator kept filming his face while he's gesturing at the specific line of code he's talking about with a pointer! After seeing Cat.hs do essence of FAIL just opening a file, claims that Haskell could serve as a scripting language suitable for the crew of the Black Pearl in yonder corner to use would pain me. Now I'm getting cross and turned off the whole business. I've been here before, grovelling through reams of stuff, trying to find something out while each example is contrived to side-step the problem, half-baked and useless, evasive or referencing non-existent documentation. All I need to make the experience complete is a certain firm's trademarks gratuitously embedded in the text at least once on every line. Then I'd be nauseous by now too. Finally I found an uncommented example with no discussion called Hedi. This seems to be doing exception handling, but what it is doing, how, why, what can raise them, so on and so forth would presumably be covered in the "too complex to describe" bit of "Yet Another Haskell Tutorial". I tried to understand it from first principles, looking at the Type theology for the exceptions and various calls, but while I have the cup of tea I lack the necessary Total Perspective Vortex. I felt no confidence trying to even cut and paste it. So question number one: Please - how do I do this? Somehow I doubt that wrapping the complexity of opening a file *and* reading it in a grown up way and then documenting idioms that use the wrapper would help. If it would, the wrapper and doco would already exist. That implies that the complexity doesn't stack. If I get to the point where I can open a file *and* read it in a grown up way, and then I need to (say) verify a version number from the file: if(attempt_file_open) if(attempt_file_read) if(version_ok) process Would I need to completely restructure my program? I suspect so. But it's worth bringing it up. Question number two: Might wrapping the indescribable complexity of the most basic operations make it possible to publish and discuss some idioms which accomplish them? I'd be quite happy with a voodoo idiom for now. I know someone who (20 years on) still doesn't understand pointers to functions. She still uses qsort(3) by rote, and it works for her. That will do for beginners. My biggest worry is that there's a really bad trade-off going on here. Sure, the structural instability of imperative parallel algorithms can be reduced, but at the cost of adding structural instability to everything else! TANSTAAFL and the lump in the carpet always goes somewhere. I read one chap who complained that in order to add one single line of debug he had to completely restructure his entire program, and then the line count was as big as an imperative language would be. Plus a world more complex I bet. It's this TANSTAAFL that's making me a non-believer. So question number three (rhetorical): What would have happened if Codd and Date had tried to make SQL a general purpose programming language? Sequential file handling would have been impossible for all practical purposes, so no-one would have got the benefits of set theory (oh sorry relational calculus) and our most successful intentional language would have been stillborn. We'd still be using CODASYL. Which leads to question number four: Why not do one job well? Limit parallelism to a single SMP machine where there are no comms to fail and failures which do occur will justify the OS chucking the whole process. Make an interface so that Haskell can be called from C++ or Java, with a simple IDL that can marshall nested structs, list<>s, map<>s and vector<>s in and out. Then we can get on with writing ambitious pure computations with names like sortOutRawCatScanData, tersely and in easily parallelizable ways, like we embed SQL to get certain specialist jobs done. Then when all this was going on, question number five appeared: What the hell are these "lightweight Haskell threads"? Are they some kind of green threads running non-preemptively inside a single OS thread? Are they OS threads that could run concurrently on multi-core hardware? If they are green threads (and it sounds like they are) then this is all an academic exercise which has no production application yet. I'm still hoping that this is solvable. That the instinctive priorities of production programmers are just different to those of researchers, and in fact it *is* possible to open a file *and* read it, checking *both* error returns, without being driven insane. If so, I sincerely suggest an example or two, like the small but well formed programs in K&R, Stroustrup or Gosling saying things like: if((fp = fopen(...)) != NULL) { if(fgets(...) != NULL) { printf(...); } fclose(...) } Best wishes - and still hoping I'm wrong after all Alan Carter -- ... the PA system was moaning unctuously, like a lady hippopotamus reading A. E. Housman ..." -- James Blish, "They Shall Have Stars" From cgibbard at gmail.com Sat Feb 16 17:53:50 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat Feb 16 17:52:17 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> On 16/02/2008, Alan Carter wrote: > Greetings Haskellers, > > I'm still hoping that this is solvable. That the instinctive > priorities of production programmers are just different to those of > researchers, and in fact it *is* possible to open a file *and* read > it, checking *both* error returns, without being driven insane. If so, > I sincerely suggest an example or two, like the small but well formed > programs in K&R, Stroustrup or Gosling saying things like: > > if((fp = fopen(...)) != NULL) > { > if(fgets(...) != NULL) > { > printf(...); > } > > fclose(...) > } > > Best wishes - and still hoping I'm wrong after all > > Alan Carter Well, first of all, have you read the documentation for System.IO? http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html That has all the corresponding functions you need. I'm not sure I understand completely how you managed to spend two weeks struggling with this before asking. Two minutes on #haskell, or a quick question about how to open and read a file should have got you a useful response. :) First, I'll write the program in a straightforward, but extremely explicit manner, handling possible errors and managing clean up explicitly. This code is rather verbose, so I'll then show some other less verbose ways to handle things while still maintaining safety. So, the first version: import System.IO import Control.Exception (try) main = do mfh <- try (openFile "myFile" ReadMode) case mfh of Left err -> do putStr "Error opening file for reading: " print err Right fh -> do mline <- try (hGetLine fh) case mline of Left err -> do putStr "Error reading line: " print err hClose fh Right line -> putStrLn ("Read: " ++ line) Okay, so this is hopefully fairly self-explanatory to a C-programmer. The only potentially-confusing part is the function 'try', imported from Control.Exception. What it does is to catch all possible exceptions, and reflect them through the return value of the action. If an exception is thrown, 'try' will catch it, and give us a value of the form (Left e), for e being the exception. If instead, the operation succeeds without an exception, we get a value (Right x), where x is the normal return value of the action. The successive 'case' expressions are used to pattern match on this, and handle the errors by printing out an explanatory message. Some example runs of this program: cale@zaphod:~$ rm myFile cale@zaphod:~$ ./read Error opening file for reading: myFile: openFile: does not exist (No such file or directory) cale@zaphod:~$ touch myFile cale@zaphod:~$ ./read Error reading line: myFile: hGetLine: end of file cale@zaphod:~$ echo "hello" >> myFile cale@zaphod:~$ ./read Read: hello This program actually does more error handling than your example C program, so let's tone it down a bit, and make use of some nice IO operations provided to handle errors and clean things up safely in the event of a failure. import System.IO main = withFile "myFile" ReadMode $ \fh -> do line <- hGetLine fh putStrLn ("Read: " ++ line) The function 'withFile' takes a filename, a mode in which to open the file, and a function, taking a filehandle, and giving an action to be performed with that handle, and wraps that action up inside an exception handler, which ensures that the file handle is safely closed if an exception is thrown. (This doesn't matter much in our small example, but I'm sure you'll appreciate how that's an important thing.) We don't handle the exceptions explicitly in this program, but we still could. There are a host of exception-handling mechanisms in Control.Exception, ranging from simple value-oriented things like try, to more explicit operations for wrapping things in exception handlers, like catch: catch :: IO a -> (Exception -> IO a) -> IO a Or to get more selective: catchJust :: (Exception -> Maybe b) -> IO a -> (b -> IO a) -> IO a Which takes a function that gets to decide whether to handle the exception, and at the same time, transform the exception in some way before passing it on to the exception handler. For more information about exceptions, check out the documentation for Control.Exception here: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html I assure you that Haskell is a very reasonable programming language in which to write safe and correct programs. There are whole companies founded on writing high-assurance software in Haskell. If you have more questions, I would be happy to answer them, either here, or perhaps more comfortably, on IRC, #haskell on irc.freenode.net. It's a very beginner friendly channel, and asking questions there is a great way to learn the language quickly, and find the resources you need. Hope this helps! - Cale From trebla at vex.net Sat Feb 16 18:01:42 2008 From: trebla at vex.net (Albert Y. C. Lai) Date: Sat Feb 16 18:00:10 2008 Subject: [Haskell-cafe] Response to unexpected doubt in haskell-cafe (was: Doubting Haskell) In-Reply-To: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <47B76B56.7020308@vex.net> Alan Carter wrote: > if((fp = fopen(...)) != NULL) > { > if(fgets(...) != NULL) > { > printf(...); > } > > fclose(...) > } This reminds me of a 1976 article written by David Parnas and Harald W?rges: Response to undesired events in software systems. Since it's old, it is harder to find, but here are a few things to try: If you have download privilege on ACM Digital Library, http://portal.acm.org/citation.cfm?id=800253.807717 (If not, you can still see the full citation, the abstract, etc.) The paper is also collected in this book full of Parnas's papers: Software Fundamentals: collected papers by David L. Parnas. Edited by Daniel M. Hoffman and David M. Weiss. Someone else made slides to present this paper: http://www.cs.virginia.edu/~wh5a/personal/Quals/misc/ParnasPaper%20on%20stanley/ResponseToUndesiredEvents.ppt From ruslan.evdokimov at gmail.com Sat Feb 16 18:06:17 2008 From: ruslan.evdokimov at gmail.com (Ruslan Evdokimov) Date: Sat Feb 16 18:04:42 2008 Subject: [Haskell-cafe] GHC strange behavior Message-ID: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> Hi, all! I have strange GHC behavior. Consider the code: import Control.Parallel main = print (o `par` (fromInteger e) / (fromInteger o)) where [e,o] = map sum $ map (`filter` numbers) [even, odd] numbers = [1..10000000] When it compiled without threaded it has 19068 ms to run, 396 Mb total memory in use and %GC time 88.2%, the same with -threaded and +RTS -N1, but with +RTS -N2 it takes only 3806 ms to run, 3 Mb total memory in use and %GC time 8.1%. Why it so? It's a bug or I missed something? I test it on dual-core Athlon X2 4200+ 2Gb running 64bit Gentoo system. gcc 4.2.2 and ghc 6.8.2. -- Ruslan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080217/a74764ab/attachment.htm From robdockins at fastmail.fm Sat Feb 16 18:40:58 2008 From: robdockins at fastmail.fm (Robert Dockins) Date: Sat Feb 16 18:06:26 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <200802161840.58577.robdockins@fastmail.fm> I'm going to try to respond the the main practical question in this message; perhaps others will feel up to addressing the more philosophical aspects. (I see now that Cale has beaten me to the punch, but I guess I'll post this anyways...) > Greetings Haskellers, [snip quite a bit of discussion] > Great. Next, translate the bit that > says (pseudocode): > > if(attempt_file_open) > if(attempt_file_read) > process > > That's it. No fancy, complex error messages. Just check the error > returns and only proceed if I have something to proceed with. Like > grown-ups do. I *will* check my error returns. I have tormented too > many newbies to *ever* consider doing anything else. If I cannot check > my error returns I will not write the program. You'll find in Haskell that the normal way of handling things like I/O errors is to use the exception handling mechanism. There aren't usually "error returns" to check. Instead you usually place error handlers at the positions where you want to be notified of errors using the "catch" or "handle" functions. If you want to you can convert any IO action into one with an error return by using the "try" function. The Control.Exception module is probably the one you want to check out. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html [snip more discussion] > If so, > I sincerely suggest an example or two, like the small but well formed > programs in K&R, Stroustrup or Gosling saying things like: > > if((fp = fopen(...)) != NULL) > { > if(fgets(...) != NULL) > { > printf(...); > } > > fclose(...) > } Here is a quick example I whipped up. It includes both a pretty direct translation of the above code, and another version which is a little more idiomatic. Rob Dockins ----------- code follows ---------------- import Control.Exception import System.IO main = direct_translation direct_translation = do tryh <- try (openFile "test.txt" ReadMode) case tryh of Left err -> print err Right h -> do tryl <- try (hGetLine h) case tryl of Left err -> do print err; hClose h Right l -> do putStrLn l hClose h the_way_I_would_do_it = handle (\err -> print err) $ bracket (openFile "test.txt" ReadMode) hClose $ \h -> do l <- hGetLine h putStrLn l From beakerchu at googlemail.com Sat Feb 16 18:13:59 2008 From: beakerchu at googlemail.com (Dave Hinton) Date: Sat Feb 16 18:12:23 2008 Subject: [Haskell-cafe] Working with multiple time zones Message-ID: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> (This is a toy program to demonstrate only the part of my real program that I'm having trouble with.) Suppose I'm writing a program to print the current time in various time zones. The time zones are to be given symbolically on the command line in the form "Europe/London" or "America/New_York". The idea is that either the operating system or the runtime library keeps track of what time zones different places are in, and when they are on summer time, so that my code doesn't have to worry about it. Haskell has a TimeZone type in Data.Time.LocalTime, but it only represents constant offsets from UTC ? doesn't encode rules for when the clocks change. And there doesn't seem to be any way of looking up the time zone for a locality. Data.Time.LocalTime has the getTimeZone function, which returns the time zone for a given UTC time on the local machine ? this takes care of summer time, but by itself only works for the local machine's locality. If I was writing this program in C, I'd get round this by setting the TZ environment variable to the locality I was interested in before doing time conversions. $ cat cnow.c #include #include #include #include void outTime (time_t utc, char *tzName) { char env[100] = "TZ="; strcat (env, tzName); putenv (env); printf ("%s\t%s", tzName, asctime (localtime (&utc))); } int main (int argc, char **argv) { int i; time_t utc = time (NULL); for (i = 1; i < argc; ++i) outTime (utc, argv[i]); return 0; } $ gcc cnow.c -o cnow $ ./cnow Europe/Paris Europe/Moscow Europe/London Europe/Paris Sat Feb 16 23:57:22 2008 Europe/Moscow Sun Feb 17 01:57:22 2008 Europe/London Sat Feb 16 22:57:22 2008 So far, so good. Here's the equivalent in Haskell: $ cat hsnow.hs import Data.Time import Data.Time.LocalTime import System.Environment import System.Posix.Env outTime utc env = do putEnv ("TZ=" ++ env) tz <- getTimeZone utc putStrLn (env ++ "\t" ++ show (utcToLocalTime tz utc)) main = do utc <- getCurrentTime mapM_ (outTime utc) =<< getArgs $ ghc --make hsnow.hs -o hsnow [1 of 1] Compiling Main ( hsnow.hs, hsnow.o ) Linking hsnow ... $ ./hsnow Europe/Paris Europe/Moscow Europe/London Europe/Paris 2008-02-16 23:59:11.776151 Europe/Moscow 2008-02-16 23:59:11.776151 Europe/London 2008-02-16 23:59:11.776151 $ ./hsnow Europe/Moscow Europe/London Europe/Paris Europe/Moscow 2008-02-17 01:59:28.617711 Europe/London 2008-02-17 01:59:28.617711 Europe/Paris 2008-02-17 01:59:28.617711 Not good. GHC's runtime library seems to be taking the value of TZ the first time it is called as gospel, and ignoring subsequent changes to TZ. So: 1. Is this a bug in GHC's Data.Time.LocalTime.getTimeZone? 2. If GHC's implementation is working as designed, how do I translate the C program above into Haskell? I'm running on Debian stable, with GHC 6.6. Thanks. From jonathanccast at fastmail.fm Sat Feb 16 18:19:05 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sat Feb 16 18:17:33 2008 Subject: [Haskell-cafe] GHC strange behavior In-Reply-To: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> References: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> Message-ID: <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> On 16 Feb 2008, at 3:06 PM, Ruslan Evdokimov wrote: > Hi, all! > > I have strange GHC behavior. Consider the code: > > import Control.Parallel > > main = print (o `par` (fromInteger e) / (fromInteger o)) > where > [e,o] = map sum $ map (`filter` numbers) [even, odd] > numbers = [1..10000000] > > > When it compiled without threaded it has 19068 ms to run, 396 Mb > total memory in use and %GC time 88.2%, the same with - > threaded and +RTS -N1, but with +RTS -N2 it takes only 3806 ms to > run, 3 Mb total memory in use and %GC time 8.1%. Why it so? > It's a bug or I missed something? Wild guess? If you leave o as a thunk, to be evaluated once the program has e, then it has numbers, so you keep the entire 10-million entry list in memory. Evaluating e and o in parallel allows the system to start garbage collecting cons cells from numbers much earlier, which reduces residency (I'd've been unsuprised at more than two orders of magnitude). Managing the smaller heap (and especially not having to copy numbers on each GC) then makes the garbage collector go much faster, so you get a smaller run time. > > I test it on dual-core Athlon X2 4200+ 2Gb running 64bit Gentoo > system. gcc 4.2.2 and ghc 6.8.2. jcc From flippa at flippac.org Sat Feb 16 18:46:48 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Sat Feb 16 18:44:48 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: On Sat, 16 Feb 2008, Alan Carter wrote: > I'm a Haskell newbie, and this post began as a scream for help. Extremely understandable - to be blunt, I don't really feel that Haskell is ready as a general-purpose production environment unless users are willing to invest considerably more than usual. Not only is it not as "batteries included" as one might like, sometimes it's necessary to build your own batteries! It's also sometimes hard to tell who the experts are, especially as many of us mostly work in fairly restricted areas - often way away from any IO, which is often a source of woe but whose avoidance leaves something of a hole in some coders' expertise. The current state of error-handling is something of a mess, and there are at least two good reasons for this: * Errors originating in the IO monad have a significantly different nature to those generated by pure code * We don't have[1] extensible variants, leading to the kinds of problem you complain about with scalability as the number of potential errors increases It's been a while since I was in the tutorial market, but I don't think many tutorials address the first point properly and it's a biggie. Most IO functions are written to throw exceptions in the IO monad if they fail, which forces you to handle them as such. So, here's an example: import System.IO fileName = "foo.bar" main = (do h <- openFile fileName ReadMode catch (hGetContents h >>= putStr) (\e -> do putStrLn "Error reading file" hClose h ) ) `catch` (\e -> putStrLn "Error opening file") On my machine, putting this through runhaskell results in a line "Error opening file", as unsurprisingly there's no foo.bar. Producing an error opening is harder work, whereas if I change filename to the program's source I get the appropriate output. It may say something about me that I didn't get this to compile first time - the culprit being a layout error, followed by having got the parms to openFile in the wrong order. Caveats so far: there are such things as non-IO exceptions in the IO monad, and catching them requires Control.Error.catch, which thankfully also catches the IO exceptions. If putStr were to throw an exception, I'd need yet another catch statement to distinguish it (though it'd be handled as-is). The sensible thing though is probably to use Control.Error.bracket (which is written in terms of catch) thusly: import System.IO import Control.Error filename = "foo.bar" main = bracket (openFile filename ReadMode) (\h -> hGetContents h >>= putStr) (\h -> hClose h) So from here, we have two remaining problems: 1) What about pure errors? 2) What about new exception types? I'll attack the second first, as there's a standard solution for IO and a similar approach can be adopted in pure code. It's a fairly simple, if arguably unprincipled, solution - use dynamic typing! Control.Error offers us throwDyn and catchDyn, which take advantage of facilities in Data.Dynamic. Pure code can make use of Data.Dynamic in a similar manner if needed. Personally I'm not too happy with this as a solution in most cases, but it's no worse than almost every other language ever - I guess Haskell's capabilities elsewhere have spoiled me. As for pure errors, there're essentially two steps: 1) Find a type that'll encode both the errors and the success cases (Maybe and Either are in common use) 2) Write the appropriate logic I'll not go into step 1 much, most of the time you want to stick with Maybe or Either (there's a punning mnemonic that "if it's Left it can't have gone right" - it's usual to use Right for success and Left for failure). The second point is where you get to adopt any approach from writing out all the case analysis longhand to using a monad or monad transformer based around your error type. It's worth being aware of Control.Monad.Error at this point, though personally I find it a little irritating to work with. By the time you're building customised monads, you're into architecture land - you're constructing an environment for code to run in and defining how that code interfaces with the rest of the world, it's perhaps the closest thing Haskellers have to layers in OO design. If you find you're using multiple monads (I ended up with three in a 300 line lambda calculus interpreter, for example - Parsec, IO and a custom-built evaluation monad) then getting things right at the boundaries is important - if you've got that right and the monad's been well chosen then everything else should come easily. Thankfully, with a little practice it becomes possible to keep your code factored in such a manner that it's easy to refactor your way around the occasional snarl-ups that happen when a new change warrants re-architecting. That or someone just won buzzword bingo, anyway. Anyway, I hope this's been helpful. [1] There are ways of implementing them in GHC, but in practice they're not used enough for anyone to be comfortable building an error-handling library around them -- flippa@flippac.org Society does not owe people jobs. Society owes it to itself to find people jobs. From cgibbard at gmail.com Sat Feb 16 18:50:03 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat Feb 16 18:48:30 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <89ca3d1f0802161550g398263a6w209f9a7596537cff@mail.gmail.com> On 16/02/2008, Alan Carter wrote: > Then when all this was going on, question number five appeared: What > the hell are these "lightweight Haskell threads"? Are they some kind > of green threads running non-preemptively inside a single OS thread? > Are they OS threads that could run concurrently on multi-core > hardware? If they are green threads (and it sounds like they are) then > this is all an academic exercise which has no production application > yet. > > Best wishes - and still hoping I'm wrong after all > > Alan Carter Sorry for missing this question in my first response. The answer of course depends on the Haskell implementation in question, but of course, we're talking about GHC here. Haskell threads, in the sense of Control.Concurrent.forkIO, are essentially a sort of green thread which is scheduled by the Haskell runtime system. Threads can either be bound to a particular OS thread, or (as is default), not be bound to a particular OS thread, allowing the scheduler to manage n Haskell threads with m OS threads, where usually you want to set m to something like the number of processors in your machine. I'm a little hazy on the details, and perhaps someone more familiar with the GHC runtime can fill in some more details for you if you'd like. Aside from Concurrent Haskell (which was originally designed for single-processor concurrency and later extended to allow for scheduling threads to execute in multiple OS threads), there is Parallel Haskell, which is used to annotate pure computations for parallelism (but since they're pure, there is no concurrency). At its core, Parallel Haskell has an extremely simple programmer interface: par :: a -> b -> b Evaluation of an expression of the form (par x y) will cause x to be put in a queue of expressions to be evaluated by a worker on some OS thread, if there is free time, before resulting in y. If there is no time to evaluate x on some processor before it is eventually needed, then evaluation just proceeds normally, but if there is, then it won't need evaluation later, due to the usual sharing from lazy evaluation. >From this extremely simple form of parallel annotation, it's possible to build lots of interesting mechanisms for carrying out evaluation in parallel. You can read more about that in a paper titled "Algorithm + Strategy = Parallelism" by PW Trinder, K Hammond, H-W Loidl and Simon Peyton Jones, or check out the documentation for Control.Parallel.Strategies. - Cale From ruslan.evdokimov at gmail.com Sat Feb 16 19:07:15 2008 From: ruslan.evdokimov at gmail.com (Ruslan Evdokimov) Date: Sat Feb 16 19:05:39 2008 Subject: [Haskell-cafe] GHC strange behavior In-Reply-To: <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> References: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> Message-ID: <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> 2008/2/17, Jonathan Cast : > > Wild guess? If you leave o as a thunk, to be evaluated once the > program has e, then it has numbers, so you keep the entire 10-million > entry list in memory. Evaluating e and o in parallel allows the > system to start garbage collecting cons cells from numbers much > earlier, which reduces residency (I'd've been unsuprised at more than > two orders of magnitude). Managing the smaller heap (and especially > not having to copy numbers on each GC) then makes the garbage > collector go much faster, so you get a smaller run time. > But I also tested it on P-IV 3.0 with HT and 1GB (single core) running Windows-XP (ghc 6.8.2), and it works fine (fast & low GC) in all three cases without significant difference. Sure it didn't runs faster with -N2 'cause it's not dual-core. From dons at galois.com Sat Feb 16 19:09:12 2008 From: dons at galois.com (Don Stewart) Date: Sat Feb 16 19:07:41 2008 Subject: [Haskell-cafe] GHC strange behavior In-Reply-To: <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> References: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> Message-ID: <20080217000912.GD31581@scytale.galois.com> ruslan.evdokimov: > 2008/2/17, Jonathan Cast : > > > > Wild guess? If you leave o as a thunk, to be evaluated once the > > program has e, then it has numbers, so you keep the entire 10-million > > entry list in memory. Evaluating e and o in parallel allows the > > system to start garbage collecting cons cells from numbers much > > earlier, which reduces residency (I'd've been unsuprised at more than > > two orders of magnitude). Managing the smaller heap (and especially > > not having to copy numbers on each GC) then makes the garbage > > collector go much faster, so you get a smaller run time. > > > But I also tested it on P-IV 3.0 with HT and 1GB (single core) running > Windows-XP (ghc 6.8.2), and it works fine (fast & low GC) in all three > cases without significant difference. Sure it didn't runs faster with > -N2 'cause it's not dual-core. What flags did you compile the code with? From ruslan.evdokimov at gmail.com Sat Feb 16 19:14:08 2008 From: ruslan.evdokimov at gmail.com (Ruslan Evdokimov) Date: Sat Feb 16 19:12:38 2008 Subject: [Haskell-cafe] GHC strange behavior In-Reply-To: <20080217000912.GD31581@scytale.galois.com> References: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> <20080217000912.GD31581@scytale.galois.com> Message-ID: <412322860802161614q204ca02y878c8992b31dcaa3@mail.gmail.com> 2008/2/17, Don Stewart : > > What flags did you compile the code with? > 1st case: ghc -O2 --make 2nd and 3rd cases: ghc -O2 --make -threaded From stefanor at cox.net Sat Feb 16 19:21:12 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Feb 16 19:19:39 2008 Subject: [Haskell-cafe] GHC strange behavior In-Reply-To: <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> References: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> Message-ID: <20080217002112.GA4573@localhost.localdomain> On Sun, Feb 17, 2008 at 03:07:15AM +0300, Ruslan Evdokimov wrote: > 2008/2/17, Jonathan Cast : > > > > Wild guess? If you leave o as a thunk, to be evaluated once the > > program has e, then it has numbers, so you keep the entire 10-million > > entry list in memory. Evaluating e and o in parallel allows the > > system to start garbage collecting cons cells from numbers much > > earlier, which reduces residency (I'd've been unsuprised at more than > > two orders of magnitude). Managing the smaller heap (and especially > > not having to copy numbers on each GC) then makes the garbage > > collector go much faster, so you get a smaller run time. > > > But I also tested it on P-IV 3.0 with HT and 1GB (single core) running > Windows-XP (ghc 6.8.2), and it works fine (fast & low GC) in all three > cases without significant difference. Sure it didn't runs faster with > -N2 'cause it's not dual-core. This makes perfect sense - -N2 tells GHC to use two threads, and if you run two threads on a single-processor system it's implemented by running the threads alternatingly (around 100/s for modern Linux, probably similar for other systems). Thus, the two evaluations never get more than a hundreth of a second out of step, and memory usage is still low. 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/20080216/9cff7386/attachment-0001.bin From stefanor at cox.net Sat Feb 16 19:26:02 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Feb 16 19:24:29 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <89ca3d1f0802161550g398263a6w209f9a7596537cff@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161550g398263a6w209f9a7596537cff@mail.gmail.com> Message-ID: <20080217002602.GB4573@localhost.localdomain> On Sat, Feb 16, 2008 at 06:50:03PM -0500, Cale Gibbard wrote: > On 16/02/2008, Alan Carter wrote: > > Then when all this was going on, question number five appeared: What > > the hell are these "lightweight Haskell threads"? Are they some kind > > of green threads running non-preemptively inside a single OS thread? > > Are they OS threads that could run concurrently on multi-core > > hardware? If they are green threads (and it sounds like they are) then > > this is all an academic exercise which has no production application > > yet. > > > > Best wishes - and still hoping I'm wrong after all > > > > Alan Carter Yes, they are green threads. But not the stupid kind you are used to. Consider an operating system. You are running hundreds of threads in a typical system. You don't have hundreds of processors - let's be generous and say you have 8. Obviously these threads are in some sense 'green'. But they are still being run with (limited) parallelism! There is no reason to expect anything less of user-level 'green threads', and if all the systems you have been using are incapable of running threads in paralell, then all the systems you have been using are toys or broken. GHC is not a toy (in this regard), and contains a mini-operating system that schedules how ever many millions of threads you have onto a number of OS threads specified with the +RTS -N option. 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/20080216/3a3a8c36/attachment.bin From jefferson.r.heard at gmail.com Sat Feb 16 19:27:49 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Sat Feb 16 19:26:14 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <4165d3a70802161627q4142d3d3jb232389d8ca78f1e@mail.gmail.com> Since everyone's been focusing on the IO so far, I wanted to take a quick stab at his mention of "green" vs. OS threads... I like the term "green", actually, as it's what my grandmother calls decaffeinated coffee, owing to the fact that decaf taster's choice has a big green plastic lid. Distrust all coffee that comes in a plastic lid, folks. Life is better that way... However, Haskell very much has real, caffeinated parallelism mechanisms. There is explicit concurrency, which says that things can happen at the same time (see Control.Concurrent) and there is the whole question of Glasgow Parallel Haskell and Data Parallel Haskell, which I won't really begin to cover, as Manuel Chakravarty and Simon Peyton Jones will do TONS better at explaining these than I can. I will however mention Control.Parallel and Control.Parallel.Strategies, because they're my personal favorite way of being parallel. The Haskell thread is semantically much like the Java thread, it's green, in other words, but you can control the number of real OS threads that Haskell threads are executed on at the command line. Thus you might call them "half caffeinated" But, at least with Control.Parallel.Strategies, they're SO much easier to use. There are a couple of caveats, but I'll give an example first. Let's say you're doing some heavy computer graphics, but you're doing it all in spherical coordinates (I do this all the time, which is why I'm using it as an example) and before you go to OpenGL, you need to transform everything into Carteisan coordinates. vertices :: [GL.Vertex3] -- a list of oh, say, 150,000 vertices or so in spherical coordinates sphericalToCart :: GL.Vertex3 -> GL.Vertex3 sphericalToCart (GL.Vertex3 r a z) = (GL.Vertex3 (r * cos a * sin z) (r * sin a * sin z) (r * cos a)) Now to convert them all, you'd just do a map sphericalToCart vertices and that would do a lazy conversion of everything, but since you know you're going to use all the vertices, strictness is just as well, and you can do strict things in parallel this way: parMap rwhnf sphericalToCart vertices or even more efficiently, map rwhnf sphericalToCart vertices `using` parListChunk 1024 That'll execute on all cores of your processor and do the same operation much faster, if you were going to have to do the entire operation anyway. -- Jeff On Sat, Feb 16, 2008 at 5:05 PM, Alan Carter wrote: > Greetings Haskellers, > > I'm a Haskell newbie, and this post began as a scream for help. Having > slept on it I find myself thinking of Simon Peyton-Jones' recent > request for good use cases. Perhaps a frustrated - and doubting - > newbie can also provide a data point. If my worries are unfounded (and > I hope they are), I think it's significant that to me, today, they > seem real enough. Please understand that I'm not being negative for > the sake of it - rather I'm describing what Haskell looks like from > the outside. > > Let me put it this way. Imagine that two weeks ago my forward-thinking > and risk-embracing boss asked me to evaluate Haskell for the upcoming > Project X. Further imagine that she ensured I was able to sit in the > corner emitting curses for the whole two weeks, and on Monday I have > to provide my report. > > At this point, two weeks in, I would be forced to say that I have no > reason to believe that Haskell is useful for real world tasks. ghc is > an industrial strength compiler for a toy language. While remarkable > claims are made for it, in practice even the experts are often unable > to implement the most basic behaviours, and where they are able to > implement, they find that their program has become so complex that > they are unable to describe or discuss the result. Likely this is a > deep problem, not a shallow one. The Haskell community is in denial > over this, leading to phenomenal time wasting as one goes round and > round in circles playing word games with documentation. This risks a > return of the chronic embuggerance that we thought we'd escaped when > Vista appeared and the set of people who would have to write Windows > device drivers reduced to Hewlett Packard employees, Joanna Rutkowska > and criminals. When people enthuse about Haskell, we should run a > program called Cat.hs from the haskell.org website, throw fruit at > them and laugh. > > Strong words, but in all honesty I *want* to believe, and if I would > make such a report I imagine hundreds if not thousands would say the > same thing. I'm hoping I'm wrong about this, and what's actually > needed is some work on communication (perhaps from a production > programming point of view, which I'd be keen to help with). > > What got me started with Haskell was the video of an Intel employee > holding a Teraflops in his hand. I still remember the very silly > September 1991 edition of Scientific American, which asked if a > Teraflops would *ever* be built. What a stupid question! Stack up > enough VIC20s and eventually you'll get a Teraflops. The question > should have been "when". Now it's the size of a CD, and only 80 cores > are needed. Unfortunately keeping 80 cores running is tricky. I know > this from writing some heavy parallel stuff in the mid-90s. It was all > quite clever in it's day. Chuck bloated and unguessable CORBA, do > something light with TCP/IP (Beuwolf took that to extremes). Neat > linkage like rpcgen gave C, so that I could run fast on an SMP Sequent > with 30 cores or on a floorfull of about 70 Sun pizza boxen at night. > > Unfortunately despite having a nice framework, tracing rays is still > hard (the rays and medium were... interesting). Making a problem > parallel required a sneaky and dedicated person's sincere skull-sweat. > Worse, the solutions so produced had a horrible structural instability > about them. Just a small change to the requirement could require a > computed value where it wasn't needed before, so that it resulted in > big changes to the implementation. The skull-sweating would be needed > all over again. (Remember that the big point about objects, which e.g. > Booch always emphasized, was that a well chosen set of classes maps > well to the domain and so reduces such structural instability.) Even > then, it was devilish hard to keep 70 "cores" busy. > > So watching the Intel guy got my klaxons going. We now need to be able > to do parallel with ease. Functional programming just got really > important. It's years since I last played with Scheme, but I quickly > moved on because I could see the "which Scheme" problem becoming a > millstone round everyone's necks outside of research contexts. Ditto > Lisp. So Haskell. Grown-up compiler, one standard and (apparently) a > decent corpus of example code and tutorials. I might be an imperative > programmer, but I do lapse - for example I find it very easy to > generate swathes of cross referenced documentation using m4. My head > goes kind of weird after a few hours, such that m4 seems sane and it's > the rest of the world that's ungainly, so maybe it should be banned > like DMT, but I like it. I felt able to enter the functional world. > > I'll omit the first week of suffering, which I see is a well > documented rite of passage. (Although most evaluators will have left > the building by the end of week one so it's not helping popularity. > Perhaps there could be Squires of the Lambda Calculus who haven't done > the vigil, mortification of flesh and so on?) Eventually a 3 page > introduction on the O'Reilly website together with a good document > called "Haskell for C Programmers" got me to the point where I could > access "Yet Another Haskell Tutorial", and I was away... for a bit. > > After a while I'd written some malformed horrors as answers to > exercises, and was telling myself that it's probably just an edge > effect - deep within a real Haskell program the ugliness would be > invisible, tucked away in Ugly.hs. Then I discovered wxHaskell and got > very excited. I really like wxWidgets, and I know it well. If I could > play with some Haskell which manipulates wxWidgets I'd progress very > quickly! I even have a recent C++ wxWidgets program which was > annoying me as I wrote it because of the boilerplate. Great! I can > play with type inference and mutter "about bloody time" with a smile > on my face. Eventually I got a mix of wxWidgets 2.6.3, wxHaskell from > darcs, ghc 6.6 running on my Mac, almost exactly as that permutation > was described on the website, and I was off. > > Within a few hours I had a nice frame, with 10 text controls and > legends populating it. It already took less lines than C++, and then I > discovered how to bundle all the text controls into a tuple to pass > them around, and define some "getters" to access the tuple. My line > count shrunk to what it "should" be - that is, something Kolmogorov > wouldn't laugh at but is unattainable in C++. I had an onOpen which > popped up a dialog and got a filename from the user, with all the > properties filled in right. I proved that I could update the values in > the text controls from the onOpen. Great. Next, translate the bit that > says (pseudocode): > > if(attempt_file_open) > if(attempt_file_read) > process > > That's it. No fancy, complex error messages. Just check the error > returns and only proceed if I have something to proceed with. Like > grown-ups do. I *will* check my error returns. I have tormented too > many newbies to *ever* consider doing anything else. If I cannot check > my error returns I will not write the program. This is production > programming 101, and I suspect that there's a real issue with > priorities between the traditional Haskell community and production > programmers. > > So the time of madness began. I could find examples which did: > > if(attempt_file_open) > attempt_file_read > process > > Which is useless. Other examples did: > > attempt_file_open > if(attempt_file_read) > process > > Which is also useless. So I'm looking through the wxHaskell examples. > They're all contrived, using very high level functions to (for > example) read a complete image structure from a named file, which as > one function had one possible source of errors. I go back to scanning > and Googling like crazy. Eventually I notice a bit in "Yet Another > Haskell Tutorial" - page 65 - which introduces "bracket", immediately > explains that it is useless for my (very common) need, and refers the > reader to Section 10 - "Advanced Techniques". The author of this > excellent document hasn't yet written Section 10. I wonder why. I > pause to examine bracket some more. I really can't tell if the > "always" clause gets called if the initialization fails. From the use > with file opening it looks like it isn't (or the handle to be closed > would be invalid) but that wouldn't help if the initializer had two > steps, e.g. called socket(2) and bind(2). This is the kind of thing > good production programmers get really het up about. > > I'm still grovelling through reams of stuff, trying to find out how to > open *and* read a file in a grown up way, and I find various programs > on haskell.org. There's an implementation of cat(1)! That's the thing! > A file concatenator must be able to open *and* read it's file. Eagerly > I download it. Curiously there doesn't seem to be any error handling. > I compile it and point it at a non-existent file. The program crashes. > Horribly. So much for Cat.hs. I feel glad I hadn't been able to cope > with the video of Simon Peyton-Jones OSCON talk, because the camera > operator kept filming his face while he's gesturing at the specific > line of code he's talking about with a pointer! After seeing Cat.hs do > essence of FAIL just opening a file, claims that Haskell could serve > as a scripting language suitable for the crew of the Black Pearl in > yonder corner to use would pain me. > > Now I'm getting cross and turned off the whole business. I've been > here before, grovelling through reams of stuff, trying to find > something out while each example is contrived to side-step the > problem, half-baked and useless, evasive or referencing non-existent > documentation. All I need to make the experience complete is a certain > firm's trademarks gratuitously embedded in the text at least once on > every line. Then I'd be nauseous by now too. > > Finally I found an uncommented example with no discussion called Hedi. > This seems to be doing exception handling, but what it is doing, how, > why, what can raise them, so on and so forth would presumably be > covered in the "too complex to describe" bit of "Yet Another Haskell > Tutorial". I tried to understand it from first principles, looking at > the Type theology for the exceptions and various calls, but while I > have the cup of tea I lack the necessary Total Perspective Vortex. I > felt no confidence trying to even cut and paste it. > > So question number one: Please - how do I do this? > > Somehow I doubt that wrapping the complexity of opening a file *and* > reading it in a grown up way and then documenting idioms that use the > wrapper would help. If it would, the wrapper and doco would already > exist. That implies that the complexity doesn't stack. If I get to the > point where I can open a file *and* read it in a grown up way, and > then I need to (say) verify a version number from the file: > > if(attempt_file_open) > if(attempt_file_read) > if(version_ok) > process > > Would I need to completely restructure my program? I suspect so. But > it's worth bringing it up. Question number two: Might wrapping the > indescribable complexity of the most basic operations make it possible > to publish and discuss some idioms which accomplish them? I'd be quite > happy with a voodoo idiom for now. I know someone who (20 years on) > still doesn't understand pointers to functions. She still uses > qsort(3) by rote, and it works for her. That will do for beginners. > > My biggest worry is that there's a really bad trade-off going on here. > Sure, the structural instability of imperative parallel algorithms can > be reduced, but at the cost of adding structural instability to > everything else! TANSTAAFL and the lump in the carpet always goes > somewhere. I read one chap who complained that in order to add one > single line of debug he had to completely restructure his entire > program, and then the line count was as big as an imperative language > would be. Plus a world more complex I bet. It's this TANSTAAFL that's > making me a non-believer. > > So question number three (rhetorical): What would have happened if > Codd and Date had tried to make SQL a general purpose programming > language? Sequential file handling would have been impossible for all > practical purposes, so no-one would have got the benefits of set > theory (oh sorry relational calculus) and our most successful > intentional language would have been stillborn. We'd still be using > CODASYL. > > Which leads to question number four: Why not do one job well? Limit > parallelism to a single SMP machine where there are no comms to fail > and failures which do occur will justify the OS chucking the whole > process. Make an interface so that Haskell can be called from C++ or > Java, with a simple IDL that can marshall nested structs, list<>s, > map<>s and vector<>s in and out. Then we can get on with writing > ambitious pure computations with names like sortOutRawCatScanData, > tersely and in easily parallelizable ways, like we embed SQL to get > certain specialist jobs done. > > Then when all this was going on, question number five appeared: What > the hell are these "lightweight Haskell threads"? Are they some kind > of green threads running non-preemptively inside a single OS thread? > Are they OS threads that could run concurrently on multi-core > hardware? If they are green threads (and it sounds like they are) then > this is all an academic exercise which has no production application > yet. > > I'm still hoping that this is solvable. That the instinctive > priorities of production programmers are just different to those of > researchers, and in fact it *is* possible to open a file *and* read > it, checking *both* error returns, without being driven insane. If so, > I sincerely suggest an example or two, like the small but well formed > programs in K&R, Stroustrup or Gosling saying things like: > > if((fp = fopen(...)) != NULL) > { > if(fgets(...) != NULL) > { > printf(...); > } > > fclose(...) > } > > Best wishes - and still hoping I'm wrong after all > > Alan Carter > > > -- > ... the PA system was moaning unctuously, like a lady hippopotamus > reading A. E. Housman ..." > -- James Blish, "They Shall Have Stars" > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From ruslan.evdokimov at gmail.com Sat Feb 16 19:41:52 2008 From: ruslan.evdokimov at gmail.com (Ruslan Evdokimov) Date: Sat Feb 16 19:40:16 2008 Subject: [Haskell-cafe] GHC strange behavior In-Reply-To: <20080217002112.GA4573@localhost.localdomain> References: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> <20080217002112.GA4573@localhost.localdomain> Message-ID: <412322860802161641s75f1a40bkc919fc5e78d4f83d@mail.gmail.com> 2008/2/17, Stefan O'Rear : > This makes perfect sense - -N2 tells GHC to use two threads, and if you > run two threads on a single-processor system it's implemented by running > the threads alternatingly (around 100/s for modern Linux, probably > similar for other systems). Thus, the two evaluations never get more > than a hundreth of a second out of step, and memory usage is still low. > > Stefan Test on windows XP AthlonX2 4200+ 2Gb: C:\imp>test 1 12328 ms C:\imp>test +RTS -N2 1 5234 ms C:\imp>test +RTS -N2 1 3515 ms 1st - 1 thread 2nd - 2 threads on single core (one core disabled through Task Manager) 3rd - 2 threads on different cores From stefanor at cox.net Sat Feb 16 19:55:52 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Feb 16 19:54:19 2008 Subject: [Haskell-cafe] GHC strange behavior In-Reply-To: <412322860802161641s75f1a40bkc919fc5e78d4f83d@mail.gmail.com> References: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> <20080217002112.GA4573@localhost.localdomain> <412322860802161641s75f1a40bkc919fc5e78d4f83d@mail.gmail.com> Message-ID: <20080217005552.GA4684@localhost.localdomain> On Sun, Feb 17, 2008 at 03:41:52AM +0300, Ruslan Evdokimov wrote: > 2008/2/17, Stefan O'Rear : > > > This makes perfect sense - -N2 tells GHC to use two threads, and if you > > run two threads on a single-processor system it's implemented by running > > the threads alternatingly (around 100/s for modern Linux, probably > > similar for other systems). Thus, the two evaluations never get more > > than a hundreth of a second out of step, and memory usage is still low. > > > > Stefan > > Test on windows XP AthlonX2 4200+ 2Gb: > > C:\imp>test > 1 > 12328 ms > > C:\imp>test +RTS -N2 > 1 > 5234 ms > > C:\imp>test +RTS -N2 > 1 > 3515 ms > > 1st - 1 thread > 2nd - 2 threads on single core (one core disabled through Task Manager) > 3rd - 2 threads on different cores As far as I can tell, that confirms my explanation. If you see it differently - say how. 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/20080216/f2d3dad6/attachment.bin From donn at avvanta.com Sat Feb 16 20:04:53 2008 From: donn at avvanta.com (Donn Cave) Date: Sat Feb 16 20:03:19 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: On Feb 16, 2008, at 3:46 PM, Philippa Cowderoy wrote: > On Sat, 16 Feb 2008, Alan Carter wrote: > >> I'm a Haskell newbie, and this post began as a scream for help. > > Extremely understandable - to be blunt, I don't really feel that > Haskell > is ready as a general-purpose production environment unless users are > willing to invest considerably more than usual. Not only is it not as > "batteries included" as one might like, sometimes it's necessary to > build > your own batteries! Ironically, the simple task of reading a file is more work than I expect precisely because I don't want to bother to handle exceptions. I mean, in some applications it's perfectly OK to let an exception go to the top. But in Haskell, you cannot read a file line by line without writing an exception handler, because end of file is an exception! as if a file does not normally have an end where the authors of these library functions came from? For the author of the original post ... can't make out what you actually found and tried, so you should know about "catch" in the Prelude, the basic exception handler. Donn Cave, donn@avvanta.com From bos at serpentine.com Sat Feb 16 20:11:59 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Feb 16 20:10:23 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <47B789DF.5010604@serpentine.com> Donn Cave wrote: > But in Haskell, you cannot read a file line by line without writing an > exception handler, because end of file is an exception! Ah, yet another person who has never found System.IO.hIsEOF :-) Whereas in C or Python you would check the return value of read against zero or an empty string, in Haskell you call hIsEOF *before* a read. References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> Message-ID: <2f9b2d30802161725w78d9232dy108e86f034278e85@mail.gmail.com> I don't have anything to answer for the "interesting" part of your question, but if you're just interested in getting something working... On Feb 16, 2008 3:13 PM, Dave Hinton wrote: > 2. If GHC's implementation is working as designed, how do I translate > the C program above into Haskell? You can use the FFI to call localtime() directly; see http://www.haskell.org/haskellwiki/FFI_Introduction There's information on the types to use here: http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign-C.html http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign.html Something along the lines of: {-# LANGUAGE FFI #-} {-# INCLUDE #-} import Foreign import Foreign.C data CStructTm = ... -- implement struct tm here instance Storable CStructTm where ... foreign import ccall unsafe "localtime" c_localtime :: Ptr CTime -> IO (Ptr CStructTm) localtime :: CTime -> IO CStructTm localtime = do ... -- marshal time into a pointer, call c_localtime, marshal structure back into a CStructTm and return it. From stefanor at cox.net Sat Feb 16 20:36:02 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Sat Feb 16 20:34:29 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <47B789DF.5010604@serpentine.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <47B789DF.5010604@serpentine.com> Message-ID: <20080217013602.GA4786@localhost.localdomain> On Sat, Feb 16, 2008 at 05:11:59PM -0800, Bryan O'Sullivan wrote: > Donn Cave wrote: > > > But in Haskell, you cannot read a file line by line without writing an > > exception handler, because end of file is an exception! > > Ah, yet another person who has never found System.IO.hIsEOF :-) > > Whereas in C or Python you would check the return value of read against > zero or an empty string, in Haskell you call hIsEOF *before* a read. I'll bet that breaks horribly in the not-so-corner case of /dev/tty. 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/20080216/2433c02a/attachment.bin From ruslan.evdokimov at gmail.com Sat Feb 16 20:37:00 2008 From: ruslan.evdokimov at gmail.com (Ruslan Evdokimov) Date: Sat Feb 16 20:35:24 2008 Subject: [Haskell-cafe] GHC strange behavior In-Reply-To: <20080217005552.GA4684@localhost.localdomain> References: <412322860802161506p55c4e55bk90fe135725b7db3f@mail.gmail.com> <6A7C8A77-C328-4560-A85A-C811373DF4A8@fastmail.fm> <412322860802161607j42b911baq77c5f28c12f25dc9@mail.gmail.com> <20080217002112.GA4573@localhost.localdomain> <412322860802161641s75f1a40bkc919fc5e78d4f83d@mail.gmail.com> <20080217005552.GA4684@localhost.localdomain> Message-ID: <412322860802161737y505fd5e8h9c0a1b524442d489@mail.gmail.com> 2008/2/17, Stefan O'Rear : > > As far as I can tell, that confirms my explanation. If you see it > differently - say how. > > Stefan > Seems you're right, I changed it to: [e,o] = map sum $ [filter even numbers, (filter odd) $ reverse numbers] It prevents numbers from being collected and here is results: >test.exe 1 12812 ms >test.exe +RTS -N2 1 16671 ms From bos at serpentine.com Sat Feb 16 21:23:54 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Feb 16 21:22:17 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <20080217013602.GA4786@localhost.localdomain> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <47B789DF.5010604@serpentine.com> <20080217013602.GA4786@localhost.localdomain> Message-ID: <47B79ABA.1040705@serpentine.com> Stefan O'Rear wrote: > I'll bet that breaks horribly in the not-so-corner case of /dev/tty. Actually, it doesn't. It seems to do a read behind the scenes if the buffer is empty, so it blocks until you type something. References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <47B789DF.5010604@serpentine.com> <20080217013602.GA4786@localhost.localdomain> <47B79ABA.1040705@serpentine.com> Message-ID: <20080217023441.GA4878@localhost.localdomain> On Sat, Feb 16, 2008 at 06:23:54PM -0800, Bryan O'Sullivan wrote: > Stefan O'Rear wrote: > > > I'll bet that breaks horribly in the not-so-corner case of /dev/tty. > > Actually, it doesn't. It seems to do a read behind the scenes if the > buffer is empty, so it blocks until you type something. Well... that's what I meant by break horribly. 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/20080216/5d6098fb/attachment.bin From bos at serpentine.com Sat Feb 16 21:36:17 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sat Feb 16 21:34:39 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <20080217023441.GA4878@localhost.localdomain> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <47B789DF.5010604@serpentine.com> <20080217013602.GA4786@localhost.localdomain> <47B79ABA.1040705@serpentine.com> <20080217023441.GA4878@localhost.localdomain> Message-ID: <47B79DA1.9080803@serpentine.com> Stefan O'Rear wrote: > Well... that's what I meant by break horribly. Buh? That behaviour makes perfect sense to me. References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <2C5810F3-DF1E-4F8E-AFC1-D3BE49B6162C@fastmail.fm> On 16 Feb 2008, at 5:04 PM, Donn Cave wrote: > > On Feb 16, 2008, at 3:46 PM, Philippa Cowderoy wrote: > >> On Sat, 16 Feb 2008, Alan Carter wrote: >> >>> I'm a Haskell newbie, and this post began as a scream for help. >> >> Extremely understandable - to be blunt, I don't really feel that >> Haskell >> is ready as a general-purpose production environment unless users are >> willing to invest considerably more than usual. Not only is it not as >> "batteries included" as one might like, sometimes it's necessary >> to build >> your own batteries! > > Ironically, the simple task of reading a file is more work than I > expect > precisely because I don't want to bother to handle exceptions. I > mean, > in some applications it's perfectly OK to let an exception go to > the top. > > But in Haskell, you cannot read a file line by line without writing an > exception handler, because end of file is an exception! as if a > file does > not normally have an end where the authors of these library functions > came from? I agree 100%; to make life tolerable around Haskell I/O, I usually end up binding the moral equivalent of tryJust (\ exc -> case exc of IOException e | isEOFError e -> return () _ -> Nothing) $ getLine somewhere at top level and then calling that where it's needed. > For the author of the original post ... can't make out what you > actually > found and tried, so you should know about "catch" in the Prelude, the > basic exception handler. Also, you might need to know that bracket nests in various ways: bracket openFile hClose $ bracket readLine cleanUpLine $ proceed There's also finally, for when the first argument to bracket is ommitted, and (>>) for when the second argument is :) jcc From stevelihn at gmail.com Sun Feb 17 00:00:05 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Sat Feb 16 23:58:31 2008 Subject: [Haskell-cafe] Where does ~> come from? Message-ID: While I am reading TypeCompose module, I am having trouble finding where ~> comes from? (And its son ~~> and grandson ~~~>, etc.) This is my immediate question. Help is appreciated. A bigger (higher-order?) issue I encountered and I think other people could also have is to look up all these special "symbols" during the learning curve. As things are getting higher and higher order in Haskell, more inventive symbols are appearing. It becomes harder to remember the exact definitions are. The difficulties are: 1) I used to see a page on haskell.org that lists many symbols, but I could not find that page any more. 2) You would hope there is a quick way to search those symbols. But most search engines do not treate symbols friendly, often just ignore them. I typed ~> in Hoogle, it also returned nothing. 3) If the module defining the symbol is not in standard library, it is not possible to look up the symbol in the core library index. The only way to find the symbol seems to go to the source code, check every module being imported and if I am lucky I will find it in the same package. If I am not lucky, I will have to search that module on the Internet, and hunt it down recursively. I wonder if anybody has the same problem. If enough crowd have the same problem, maybe there could be a better way to handle this kind of documentation/learning issue! Thanks, Steve From prstanley at ntlworld.com Sun Feb 17 01:20:01 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sun Feb 17 01:18:21 2008 Subject: [Haskell-cafe] Designing a Parser Message-ID: <7.0.1.0.0.20080217061839.01d001f0@ntlworld.com> Hi friends I'm in the process of designing a series of functions which you might collectively call a parser. The idea is to evaluate an input string for a proof software. So a typical input string would be something like "(P & Q) -> q". There are a number of things to consider here, for example, does the string belong to the domain which is a subset of the 7-bit ASCII table, starting from 32 and ending at 126. Then you need to remove all space characters to make things a bit simpler. Next we find out if the logical sentnece is bracketted. I start this by looking for a bracket in the string. If true then I isolate the brackets into a new set in order to spot any odd ones. Here is what I've done so far: domain :: [Char] domain = [x | x <- ascii7, x >= ' ' && x <= '~'] where ascii7 = ['\0'..'\127'] -- a legal input character is a member of domain. isInDomain :: Char -> Bool isInDomain x = any (==x) domain -- a legal input string is a subset of domain. isSubset :: [Char] -> Bool isSubset input = all isInDomain input -- delete spaces for easier parsing. noSpace :: [Char] -> [Char] noSpace input = [x | x <- input, x /= space] where space = ' ' -- set of brackets brackets = ['(', ')', '[', ']', '{', '}'] -- Are there any brackets in input? hasBrackets :: [Char] -> Bool hasBrackets input = or [True | x <- input, any (==x) brackets] -- filter all brackets into a subset. getBrackets :: [Char] -> [Char] getBrackets input = [x | x <- input, any (==x) brackets] -- What are matching brackets? areMatched :: Char -> Char -> Bool areMatched '(' ')' = True areMatched '[' ']' = True areMatched '{' '}' = True areMatched _ _ = False -- Can all the brackets in input be paired up? allMatched :: [Char] -> Bool I can't think of an elegant pattern for the last function. I've already tried set comprehension. However, something tells me that the answer may lie in a complex recursive pattern. I'm not afraid of complex solutions but I naturally see them as an easy way out. It's those clear simple patterns that separate men from mice. :-) I'd be grateful for any advice on this and indeed my approach as a whole. If you think I'm on the wrong path from the start feel free to let me know. I'm not asking for the answer. I'd like to work that out by myself although some guidance would be most appreciated. Thanks, Paul From cgibbard at gmail.com Sun Feb 17 01:21:14 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Sun Feb 17 01:20:00 2008 Subject: [Haskell-cafe] Where does ~> come from? In-Reply-To: References: Message-ID: <89ca3d1f0802162221i1aaf81a6tb0292db61f50c526@mail.gmail.com> On 17/02/2008, Steve Lihn wrote: > While I am reading TypeCompose module, I am having trouble finding > where ~> comes from? (And its son ~~> and grandson ~~~>, etc.) This > is my immediate question. Help is appreciated. (~>) is typically an infix type variable. If it were a constructor, it would have to start with a colon. So it doesn't have a definition as such, you can think of it as any type constructor with at least two type parameters. I think that would explain why you were having such trouble searching for it! Generally, though, if you want to know where something is defined, you can use ghci's :info command, and it should tell you the file and line in which it's defined, as well as its type (if it's a value) and its fixity (if it's an infix operator). You can then load up whatever documentation or source code is available for that module. Of course, in this case, it would report (correctly) that (~>) is not in scope. Usually, packages on Hackage have whatever documentation is available linked directly from their pages on Hackage. hope this helps! - Cale From colin at colina.demon.co.uk Sun Feb 17 01:47:25 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Feb 17 01:45:50 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> (Cale Gibbard's message of "Sat\, 16 Feb 2008 17\:53\:50 -0500") References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> Message-ID: >>>>> "Cale" == Cale Gibbard writes: Cale> So, the first version: Cale> import System.IO import Control.Exception (try) Cale> main = do mfh <- try (openFile "myFile" ReadMode) case mfh Cale> of Left err -> do putStr "Error opening file for reading: " Cale> print err Right fh -> do mline <- try (hGetLine fh) case Cale> mline of Left err -> do putStr "Error reading line: " print Cale> err hClose fh Right line -> putStrLn ("Read: " ++ line) Left? Right? Hardly descriptive terms. Sounds like a sinister language to me. -- Colin Adams Preston Lancashire From lrpalmer at gmail.com Sun Feb 17 02:03:01 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Feb 17 02:01:24 2008 Subject: [Haskell-cafe] Designing a Parser In-Reply-To: <7.0.1.0.0.20080217061839.01d001f0@ntlworld.com> References: <7.0.1.0.0.20080217061839.01d001f0@ntlworld.com> Message-ID: <7ca3f0160802162303g6a08d90fga84fb4a3c3549feb@mail.gmail.com> On Feb 17, 2008 6:20 AM, PR Stanley wrote: > I can't think of an elegant pattern for the last function. I've > already tried set comprehension. However, something tells me that the > answer may lie in a complex recursive pattern. I'm not afraid of > complex solutions but I naturally see them as an easy way out. It's > those clear simple patterns that separate men from mice. :-) I'd be > grateful for any advice on this and indeed my approach as a whole. If > you think I'm on the wrong path from the start feel free to let me > know. I'm not asking for the answer. I'd like to work that out by > myself although some guidance would be most appreciated. Yes, I definitely think you're on the wrong path from the start. In high school when I was learning C++ I wrote an arithmetic expression parser in something like this fashion. I scanned the input for the first opening bracket, then I walked forward to the matching closing bracket and extracted the subexpression and evaluated it. The approach turned out to be both complicated and inefficient. I think the biggest problem was that it didn't scale well with implementation complexity; eg. to add support for prefix functions like sin() was almost impossible. Think about how you would go about doing such things using your approach. I think I've seen you ask questions relating to this on the list before, and at the risk of repeating others, I suggest the ReadS in the Haskell Prelude. You get the benefit of it being a clean, top-down solution as well as the benefit of having a lot of primitive Haskell types already implemented for you (such as Integers). I'll describe the approach again, describing the combinators, and then afterward showing how you might use them to accomplish this problem. I'll leave the details up to you, since you can learn a lot by implementing combinator libraries like this. First, you build a bunch of functions which are "parsers". A "parser" is just a function of type String -> [(a,String)] for some type 'a'; that is, it takes a string and returns a list of "parses", where a parse is the value parsed paired with the remainder of the string. So if you have a function: parseInt :: String -> [(Int,String)] Then you can expect this result: parseInt "123 hello world" = [(123, " hello world")] Or maybe even: parseInt "123 hello world" = [(123, " hello world"), (12, "3 hello world"), (1, "23 hello world")] But that latter behavior is not recommended in this case (i.e. it is advisable force int parsing to be greedy). Then to combine parsers you can use some combination operations: sequenceParsers :: (String -> [(a,String)]) -> (a -> String -> [(b, String)]) -> String -> [(b,String)] That one may be easier to see if you use the built-in type synonym ReadS a = String -> [(a, String)]: sequenceParsers :: ReadS a -> (a -> ReadS b) -> ReadsB The second argument here is a function, because we have already parsed the first argument and know its value, so the second argument ought to be able to use it. We can also write: alternateParsers :: ReadS a -> ReadS a -> ReadS a Which gives all valid parses that the first one recognizes concatenated with all valid parsers that the second one recognizes. Implementation of these combinators is left to you. Since the types of these functions are quite general, you can use a type-directed approach (i.e. if your implementation uses all available data and it typechecks, it's probably correct). Now that you have these, how do you use them to actually parse something? Let's parse simple logical expressions. First we need a data structure to parse into: data Exp = Variable String | AndExp Exp Exp | OrExp Exp Exp Let's do it with a top down coding strategy: write a function to parse an expression using whatever helper functions we need but haven't written yet :-) parseExp :: ReadS Exp parseExp = parseAnyOf [ parseVariable, parseAndExp, parseOrExp ] Where we haven't written parseAnyOf yet. Write that inductively on the list: parseAnyOf :: [ReadS a] -> ReadS a parseAnyOf [] = \input -> [] parseAnyOf (p:ps) = alternateParsers p (parseAnyOf ps) And jump in to the next thing we haven't written, parseVariable: parseVariable :: ReadS Exp parseVariable = mapParser Variable parseString mapParser doesn't actually parse anything, it just parses whatever its argument does and applies a function to the result: mapParser :: (a -> b) -> ReadS a -> ReadS b mapParser :: (a -> b) -> (String -> [(a,String)]) -> String -> [(b,String)] I rewrote the type signature to help guide your implementation. That should get you started, and show you how the approach usually goes. You seem to already get the idea of writing many small functions and composing them together. This is the same idea, except the functions are abstracting the problem more. Luke From prstanley at ntlworld.com Sun Feb 17 02:33:04 2008 From: prstanley at ntlworld.com (PR Stanley) Date: Sun Feb 17 02:31:23 2008 Subject: [Haskell-cafe] Designing a Parser In-Reply-To: <7ca3f0160802162303g6a08d90fga84fb4a3c3549feb@mail.gmail.co m> References: <7.0.1.0.0.20080217061839.01d001f0@ntlworld.com> <7ca3f0160802162303g6a08d90fga84fb4a3c3549feb@mail.gmail.com> Message-ID: <7.0.1.0.0.20080217073059.01cff1d8@ntlworld.com> Actually, I haven't sent this question to the list before. So you're in no danger of repeating yourself. Thanks for your kind reply anyway Paul At 07:03 17/02/2008, you wrote: >On Feb 17, 2008 6:20 AM, PR Stanley wrote: > > I can't think of an elegant pattern for the last function. I've > > already tried set comprehension. However, something tells me that the > > answer may lie in a complex recursive pattern. I'm not afraid of > > complex solutions but I naturally see them as an easy way out. It's > > those clear simple patterns that separate men from mice. :-) I'd be > > grateful for any advice on this and indeed my approach as a whole. If > > you think I'm on the wrong path from the start feel free to let me > > know. I'm not asking for the answer. I'd like to work that out by > > myself although some guidance would be most appreciated. > >Yes, I definitely think you're on the wrong path from the start. In >high school when I was learning C++ I wrote an arithmetic expression >parser in something like this fashion. I scanned the input for the >first opening bracket, then I walked forward to the matching closing >bracket and extracted the subexpression and evaluated it. > >The approach turned out to be both complicated and inefficient. I >think the biggest problem was that it didn't scale well with >implementation complexity; eg. to add support for prefix functions >like sin() was almost impossible. Think about how you would go about >doing such things using your approach. > >I think I've seen you ask questions relating to this on the list >before, and at the risk of repeating others, I suggest the ReadS in >the Haskell Prelude. You get the benefit of it being a clean, >top-down solution as well as the benefit of having a lot of primitive >Haskell types already implemented for you (such as Integers). > >I'll describe the approach again, describing the combinators, and then >afterward showing how you might use them to accomplish this problem. >I'll leave the details up to you, since you can learn a lot by >implementing combinator libraries like this. > >First, you build a bunch of functions which are "parsers". A "parser" >is just a function of type String -> [(a,String)] for some type 'a'; >that is, it takes a string and returns a list of "parses", where a >parse is the value parsed paired with the remainder of the string. So >if you have a function: > > parseInt :: String -> [(Int,String)] > >Then you can expect this result: > > parseInt "123 hello world" = [(123, " hello world")] > >Or maybe even: > > parseInt "123 hello world" = [(123, " hello world"), (12, "3 hello >world"), (1, "23 hello world")] > >But that latter behavior is not recommended in this case (i.e. it is >advisable force int parsing to be greedy). > >Then to combine parsers you can use some combination operations: > > sequenceParsers :: (String -> [(a,String)]) -> (a -> String -> >[(b, String)]) -> String -> [(b,String)] > >That one may be easier to see if you use the built-in type synonym >ReadS a = String -> [(a, String)]: > > sequenceParsers :: ReadS a -> (a -> ReadS b) -> ReadsB > >The second argument here is a function, because we have already parsed >the first argument and know its value, so the second argument ought to >be able to use it. We can also write: > > alternateParsers :: ReadS a -> ReadS a -> ReadS a > >Which gives all valid parses that the first one recognizes >concatenated with all valid parsers that the second one recognizes. > >Implementation of these combinators is left to you. Since the types >of these functions are quite general, you can use a type-directed >approach (i.e. if your implementation uses all available data and it >typechecks, it's probably correct). > >Now that you have these, how do you use them to actually parse >something? Let's parse simple logical expressions. First we need a >data structure to parse into: > > data Exp > = Variable String > | AndExp Exp Exp > | OrExp Exp Exp > >Let's do it with a top down coding strategy: write a function to >parse an expression using whatever helper functions we need but >haven't written yet :-) > > parseExp :: ReadS Exp > parseExp = parseAnyOf [ parseVariable, parseAndExp, parseOrExp ] > >Where we haven't written parseAnyOf yet. Write that inductively on the list: > > parseAnyOf :: [ReadS a] -> ReadS a > parseAnyOf [] = \input -> [] > parseAnyOf (p:ps) = alternateParsers p (parseAnyOf ps) > >And jump in to the next thing we haven't written, parseVariable: > > parseVariable :: ReadS Exp > parseVariable = mapParser Variable parseString > >mapParser doesn't actually parse anything, it just parses whatever its >argument does and applies a function to the result: > > mapParser :: (a -> b) -> ReadS a -> ReadS b > mapParser :: (a -> b) -> (String -> [(a,String)]) -> String -> > [(b,String)] > >I rewrote the type signature to help guide your implementation. > >That should get you started, and show you how the approach usually >goes. You seem to already get the idea of writing many small >functions and composing them together. This is the same idea, except >the functions are abstracting the problem more. > >Luke From bf3 at telenet.be Sun Feb 17 02:40:17 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sun Feb 17 02:38:47 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr Message-ID: <47B7E4E1.6040506@telenet.be> After having played with some packages that use arrows, and after having read the very nice "programming with arrows" paper I wanted to build some of my own. Strangely my code did not work, even the simplest function got stuck in an infinite loop or gave a stack overflow. I quickly noticed I made a really stupid mistake, I forget to implement "arr"! However, the compiler did not give a warning on this. So I wandered how it was possible that the Arrow package had a default implementation for something so specific as arr? The code revealed the following: -- | Lift a function to an arrow: you must define either this -- or 'pure'. arr :: (b -> c) -> a b c arr = pure -- | A synonym for 'arr': you must define one or other of them. pure :: (b -> c) -> a b c pure = arr Ah, so the default implementation of arr is pure... and vice versa... This feels like rather incorrect to me, but my feelings are based on imperative background knowledge, so this might be totally correct design in Haskell. Why not force people to implement arr and leave just pure as the synonym? And if pure is really a synonym for arr, what does it do inside the Arrow type class? Does it ever make sense to have a different implementation for arr and pure? Thanks for any help, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080217/1f5051b8/attachment.htm From anton at appsolutions.com Sun Feb 17 02:46:10 2008 From: anton at appsolutions.com (Anton van Straaten) Date: Sun Feb 17 02:40:44 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> Message-ID: <47B7E642.4050309@appsolutions.com> Colin Paul Adams wrote: >>>>>> "Cale" == Cale Gibbard writes: > > Cale> So, the first version: > > Cale> import System.IO import Control.Exception (try) > > Cale> main = do mfh <- try (openFile "myFile" ReadMode) case mfh > Cale> of Left err -> do putStr "Error opening file for reading: " > Cale> print err Right fh -> do mline <- try (hGetLine fh) case > Cale> mline of Left err -> do putStr "Error reading line: " print > Cale> err hClose fh Right line -> putStrLn ("Read: " ++ line) > > Left? Right? > > Hardly descriptive terms. Sounds like a sinister language to me. I was thinking along the same lines. Politically-sensitive left-handed people everywhere ought to be offended that "Left" is the alternative used to represent errors, mnemonic value notwithstanding. Is there a benefit to reusing a generic Either type for this sort of thing? For code comprehensibility, wouldn't it be better to use more specific names? If I want car and cdr, I know where to find it. Anton From jonathanccast at fastmail.fm Sun Feb 17 02:50:47 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sun Feb 17 02:49:16 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <47B7E642.4050309@appsolutions.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> <47B7E642.4050309@appsolutions.com> Message-ID: On 16 Feb 2008, at 11:46 PM, Anton van Straaten wrote: > Colin Paul Adams wrote: >>>>>>> "Cale" == Cale Gibbard writes: >> Cale> So, the first version: >> Cale> import System.IO import Control.Exception (try) >> Cale> main = do mfh <- try (openFile "myFile" ReadMode) case mfh >> Cale> of Left err -> do putStr "Error opening file for reading: " >> Cale> print err Right fh -> do mline <- try (hGetLine fh) case >> Cale> mline of Left err -> do putStr "Error reading line: " print >> Cale> err hClose fh Right line -> putStrLn ("Read: " ++ line) >> Left? Right? >> Hardly descriptive terms. Sounds like a sinister language to me. > > I was thinking along the same lines. Politically-sensitive left- > handed people everywhere ought to be offended that "Left" is the > alternative used to represent errors, mnemonic value notwithstanding. > > Is there a benefit to reusing a generic Either type for this sort > of thing? Standardization. It's already a standard, we need a standard sum type anyway, and it'd be kind of silly to have two isomorphic types with the same signature in the Prelude. jcc From jonathanccast at fastmail.fm Sun Feb 17 03:00:43 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sun Feb 17 02:59:12 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: <47B7E4E1.6040506@telenet.be> References: <47B7E4E1.6040506@telenet.be> Message-ID: On 16 Feb 2008, at 11:40 PM, Peter Verswyvelen wrote: > After having played with some packages that use arrows, and after > having read the very nice "programming with arrows" paper I wanted > to build some of my own. > > Strangely my code did not work, even the simplest function got > stuck in an infinite loop or gave a stack overflow. > > I quickly noticed I made a really stupid mistake, I forget to > implement "arr"! However, the compiler did not give a warning on > this. So I wandered how it was possible that the Arrow package had > a default implementation for something so specific as arr? > > The code revealed the following: > > -- | Lift a function to an arrow: you must define either this > -- or 'pure'. > arr :: (b -> c) -> a b c > arr = pure > > -- | A synonym for 'arr': you must define one or other of them. > pure :: (b -> c) -> a b c > pure = arr > Ah, so the default implementation of arr is pure... and vice versa... > > This feels like rather incorrect to me, but my feelings are based > on imperative background knowledge, so this might be totally > correct design in Haskell. > > Why not force people to implement arr and leave just pure as the > synonym? And if pure is really a synonym for arr, what does it do > inside the Arrow type class? Does it ever make sense to have a > different implementation for arr and pure? No; the equations arr = pure and pure = arr are laws for the class. (This is true in general for default methods). Note that this situation --- where leaving the default methods in place gives rise to an infinite loop --- is quite common; it occurs for the classes Eq and Ord, as well, for example. This example is admittedly kind of silly, but I'm sure someone has a passionate attachment to one or both names, so requiring definitions to use one or the other would be controversial. jcc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080217/137a10cd/attachment-0001.htm From derek.a.elkins at gmail.com Sun Feb 17 02:38:30 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Feb 17 03:37:52 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <47B7E642.4050309@appsolutions.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> <47B7E642.4050309@appsolutions.com> Message-ID: <1203233910.5610.9.camel@derek-laptop> On Sun, 2008-02-17 at 02:46 -0500, Anton van Straaten wrote: > Colin Paul Adams wrote: > >>>>>> "Cale" == Cale Gibbard writes: > > > > Cale> So, the first version: > > > > Cale> import System.IO import Control.Exception (try) > > > > Cale> main = do mfh <- try (openFile "myFile" ReadMode) case mfh > > Cale> of Left err -> do putStr "Error opening file for reading: " > > Cale> print err Right fh -> do mline <- try (hGetLine fh) case > > Cale> mline of Left err -> do putStr "Error reading line: " print > > Cale> err hClose fh Right line -> putStrLn ("Read: " ++ line) > > > > Left? Right? > > > > Hardly descriptive terms. Sounds like a sinister language to me. > > I was thinking along the same lines. Politically-sensitive left-handed > people everywhere ought to be offended that "Left" is the alternative > used to represent errors, mnemonic value notwithstanding. > > Is there a benefit to reusing a generic Either type for this sort of > thing? For code comprehensibility, wouldn't it be better to use more > specific names? If I want car and cdr, I know where to find it. Actually, it's either intentional or ironic that Colin uses the word "sinister" in his response as "Left" is etymologically related to it. See http://en.wikipedia.org/wiki/Left-handed#Negative_associations_of_left-handedness_in_language (to the extent wikipedia can be trusted) Indeed, also as wikipedia mentions, there are entire connotations with both words along the lines of how Haskell libraries use them. The benefit of reusing Either is that a) it -is- already mnemonic, b) there are several functions that operate on Eithers in the standard, there's little point in rewriting all of them just so you can say Ok or Error. That said, you often don't see too many explicit uses of the constructors of Either (as functions or patterns) in Haskell code as it is usually more convenient to use combinators (e.g. either or the monad methods) rather than explicit cases. From apfelmus at quantentunnel.de Sun Feb 17 03:55:18 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun Feb 17 03:53:50 2008 Subject: [Haskell-cafe] Re: Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> Message-ID: Colin Paul Adams wrote: > Left? Right? > > Hardly descriptive terms. Sounds like a sinister language to me. The mnemonics is that Right x is "right" in the sense of correct. So, the error case has to be Left err . Regards, apfelmus From colin at colina.demon.co.uk Sun Feb 17 04:12:57 2008 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Sun Feb 17 04:11:21 2008 Subject: [Haskell-cafe] Re: Doubting Haskell In-Reply-To: (apfelmus@quantentunnel.de's message of "Sun\, 17 Feb 2008 09\:55\:18 +0100") References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> Message-ID: >>>>> "apfelmus" == apfelmus writes: apfelmus> Colin Paul Adams wrote: >> Left? Right? >> >> Hardly descriptive terms. Sounds like a sinister language to >> me. apfelmus> The mnemonics is that Right x is "right" in the sense of apfelmus> correct. So, the error case has to be Left err . As I said, this is sinister (i.e. regarding left-handed people as evil). And left is not the opposite of correct. That would be incorrect. Also, it is not clear to me that a failure to read a file (for instance) is incorrect behaviour. If the file doesn't exist, then I think it ought to be considered correct behaviour to fail to read the file. So Success and Failure seem to be much better. Certainly they make the program far more readable to my eyes. -- Colin Adams Preston Lancashire From jonathanccast at fastmail.fm Sun Feb 17 04:20:40 2008 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Sun Feb 17 04:19:07 2008 Subject: [Haskell-cafe] Re: Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> Message-ID: On 17 Feb 2008, at 1:12 AM, Colin Paul Adams wrote: >>>>>> "apfelmus" == apfelmus writes: > > apfelmus> Colin Paul Adams wrote: >>> Left? Right? >>> >>> Hardly descriptive terms. Sounds like a sinister language to >>> me. > > apfelmus> The mnemonics is that Right x is "right" in the sense of > apfelmus> correct. So, the error case has to be Left err . > > As I said, this is sinister You do know what `sinister' means, no? > (i.e. regarding left-handed people as > evil). Sheesh, it's just a mnemonic... > > And left is not the opposite of correct. That would be incorrect. No, Left is the opposite of Right. Right is the constructor modified by fmap (due to the design of Haskell type classes); therefore return = Right. Therefore any computation in Either that is not the result of a return is an application of Left. > Also, it is not clear to me that a failure to read a file (for > instance) is incorrect behaviour. Then don't think of Left as `incorrect behavior'. Left isn't incorrect, or Parsec's parse function wouldn't return it on parse errors. > If the file doesn't exist, then I > think it ought to be considered correct behaviour to fail to read the > file. > > So Success and Failure seem to be much better. Certainly they make the > program far more readable to my eyes. But the program succeeded in doing what I expected it to do when if failed... jcc Besides, these decisions were made 15 years ago, they're not going to change now... From apfelmus at quantentunnel.de Sun Feb 17 04:30:01 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Sun Feb 17 04:28:41 2008 Subject: [Haskell-cafe] Re: Doubting Haskell In-Reply-To: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: Alan Carter wrote: > We now need to be able to do parallel with ease. Functional > programming just got really important. While this is a reason to have a look at Haskell, I think it's not the best one. In fact, I think it's probably harmful to have parallelism as single goal for learning Haskell: the language is very different from imperative languages and if you "just want to do parallelism" but otherwise stick to what you know, you'll have a really hard time. > Eventually a 3 page > introduction on the O'Reilly website together with a good document > called "Haskell for C Programmers" got me to the point where I could > access "Yet Another Haskell Tutorial", and I was away... for a bit. IMHO, the easiest way to learn Haskell and to appreciate functional programming is to learn it from a textbook :) The online tutorials are nice but you'll have a much harder time with them. I'd recommend Hutton's "Programming in Haskell" for the basics and Bird's "Introduction to Functional Programming using Haskell" for the functional style. See also http://haskell.org/haskellwiki/Books#Textbooks Of course, the textbooks (except "Real World Haskll" which is not done yet) most likely don't cover the System.IO stuff, but you've got the #haskell irc channel and the mailing list for that. So, the textbook remark is in anticipation of the questions that you are going to have :) (if you decide to pursue Haskell further, that is). Regards, apfelmus From nominolo at googlemail.com Sun Feb 17 05:15:25 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Feb 17 05:13:53 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <47B7E642.4050309@appsolutions.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> <47B7E642.4050309@appsolutions.com> Message-ID: On 17 feb 2008, at 08.46, Anton van Straaten wrote: > Colin Paul Adams wrote: >>>>>>> "Cale" == Cale Gibbard writes: >> Cale> So, the first version: >> Cale> import System.IO import Control.Exception (try) >> Cale> main = do mfh <- try (openFile "myFile" ReadMode) case mfh >> Cale> of Left err -> do putStr "Error opening file for reading: " >> Cale> print err Right fh -> do mline <- try (hGetLine fh) case >> Cale> mline of Left err -> do putStr "Error reading line: " print >> Cale> err hClose fh Right line -> putStrLn ("Read: " ++ line) >> Left? Right? >> Hardly descriptive terms. Sounds like a sinister language to me. > > I was thinking along the same lines. Politically-sensitive left- > handed people everywhere ought to be offended that "Left" is the > alternative used to represent errors, mnemonic value notwithstanding. > > Is there a benefit to reusing a generic Either type for this sort > of thing? For code comprehensibility, wouldn't it be better to use > more specific names? If I want car and cdr, I know where to find it. Haskell doesn't have constructor aliases and keeping around dozens of isomorphic types would be stupid. (Views could help, though.) Also, "Right" is naturally used when the everything was alright. It might be arbitrary, but it's not hard to remember - once you're past the newbie phase no-one confuses car and cdr anyways... From ross at soi.city.ac.uk Sun Feb 17 06:33:18 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sun Feb 17 06:31:48 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: References: <47B7E4E1.6040506@telenet.be> Message-ID: <20080217113318.GA2994@soi.city.ac.uk> On Sun, Feb 17, 2008 at 12:00:43AM -0800, Jonathan Cast wrote: > arr = pure > pure = arr > [...] > This example is admittedly kind of silly, but I'm sure someone has a > passionate attachment to one or both names, so requiring definitions > to use one or the other would be controversial. Perhaps not. I used the name pure for arr in the Fun of Programming paper, because Richard Bird preferred that name, but it hasn't caught on, and now the same name is used in the Applicative class. So perhaps it should be removed from Arrow. From fmartini at gmail.com Sun Feb 17 07:14:25 2008 From: fmartini at gmail.com (Felix Martini) Date: Sun Feb 17 07:12:49 2008 Subject: [Haskell-cafe] ANN: winerror-0.1 Message-ID: <6c0416190802170414q29251201uadffd116c3e8ab63@mail.gmail.com> This is a small package for error handling when making foreign calls to the Windows API. The functions are similar to those in Foreign.C.Error, e.g. throwWinErrorIf corresponds to throwErrnoIf. Dynamic io errors are thrown with GHC so the catchWinError function can catch specific Windows error codes and handle them. Regards, Felix From phil at kantaka.co.uk Sun Feb 17 07:31:41 2008 From: phil at kantaka.co.uk (Philip Armstrong) Date: Sun Feb 17 07:30:05 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <15479718.post@talk.nabble.com> References: <15479718.post@talk.nabble.com> Message-ID: <20080217123141.GA5229@kantaka.co.uk> On Thu, Feb 14, 2008 at 04:56:39AM -0800, Grzegorz Chrupala wrote: >I have a very simple program which reads a Data.Map from a file using >Data.Binary and Data.ByteString.Lazy, which gives stack overflow with files >over a certain size. Any ideas of what might be causing it? > >You can try it with the small file (11M) at: >http://computing.dcu.ie/~gchrupala/map.bin > >import System >import Data.Map >import qualified Data.ByteString.Lazy as BS >import Data.Binary >main = do > [path] <- getArgs > m <- fmap decode (BS.readFile path)::IO (Map (Int,Maybe String) Int) > putStrLn . show . findMax $ m Since no-one else has answered, I'll take a stab. Obiously, you have a stack leak due to laziness somewhere -- now Data.Map is strict in it's keys, but lazy in it's values, and Data.Binary is lazy so my suspicion would be that you're building up lazy decode thunks for the value elements on the stack as the map is being constructed. If either decode or the Map construction were strict, you'd probably be OK, but the combination is blowing the stack. (Data.Binary serialises Maps by writing them out to a list of key, value pairs in ascending key order. The Map can be reconstructed from this list in O(N) time.) In your specific example, you can replace the type for the result of the decoding with IO [(Int,Maybe String),Int)] and evaluate the right hand sides (with seq if necessary) before constructing the map from the list, which will avoid the stack blowout. In fact, a little experimentation has revealed that this: do [path] <- getArgs m <- liftM decode (BS.readFile path)::IO [((Int, Maybe String), Int)] putStrLn . show . findMax . fromAscList $ m will work just fine. No extra evaluation needed at all! I'll leave it to the Haskell gurus to explain what's going on... cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt From flippa at flippac.org Sun Feb 17 08:32:50 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Sun Feb 17 08:30:46 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <47B7E642.4050309@appsolutions.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> <47B7E642.4050309@appsolutions.com> Message-ID: On Sun, 17 Feb 2008, Anton van Straaten wrote: > Is there a benefit to reusing a generic Either type for this sort of thing? > For code comprehensibility, wouldn't it be better to use more specific > names? If I want car and cdr, I know where to find it. > It's Haskell's standard sum type, with a pile of instances already written. There's an instance of MonadError such that you only need to see an Either when you run the computation for example (and then you get an Either whatever the actual error monad was!). If we had appropriate language extensions to map an isomorphic Success/Failure type onto it then I'd probably use them - as it is, the level of inertia around Either is great enough to mean that's only worth doing if I'm expecting to roll a third constructor in at some point. That said, generally I'll wrap it up pretty fast if I have to handle Either directly. Not that that's necessarily any different to cons, car and cdr of course, but there's plenty of library support for doing so. -- flippa@flippac.org "I think you mean Philippa. I believe Phillipa is the one from an alternate universe, who has a beard and programs in BASIC, using only gotos for control flow." -- Anton van Straaten on Lambda the Ultimate From bf3 at telenet.be Sun Feb 17 08:32:27 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Sun Feb 17 08:30:57 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: <20080217113318.GA2994@soi.city.ac.uk> References: <47B7E4E1.6040506@telenet.be> <20080217113318.GA2994@soi.city.ac.uk> Message-ID: <47B8376B.1010108@telenet.be> I don't get why the name isn't "arrow" instead of "arr"... Arr reminds me of pirates, "arrrrrrrhh" ;-) I guess "first" was chosen because "fst" was already taken, but then it would be logical to choose "arrow" instead of "arr" ;-) Ross Paterson wrote: > On Sun, Feb 17, 2008 at 12:00:43AM -0800, Jonathan Cast wrote: > >> arr = pure >> pure = arr >> [...] >> This example is admittedly kind of silly, but I'm sure someone has a >> passionate attachment to one or both names, so requiring definitions >> to use one or the other would be controversial. >> > > Perhaps not. I used the name pure for arr in the Fun of Programming > paper, because Richard Bird preferred that name, but it hasn't caught on, > and now the same name is used in the Applicative class. So perhaps it > should be removed from Arrow. > _______________________________________________ > 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/20080217/7a2a8605/attachment.htm From ndmitchell at gmail.com Sun Feb 17 08:41:38 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun Feb 17 08:39:59 2008 Subject: [Haskell-cafe] Where does ~> come from? In-Reply-To: References: Message-ID: <404396ef0802170541o70a37be0x82123be1b95aa52a@mail.gmail.com> Hi > 2) You would hope there is a quick way to search those symbols. But > most search engines do not treate symbols friendly, often just ignore > them. I typed ~> in Hoogle, it also returned nothing. > 3) If the module defining the symbol is not in standard library, it is > not possible to look up the symbol in the core library index. The next version of Hoogle will allow you to search all the modules on Hackage, i.e. it will find ~>. A month after I have written my thesis this will all be done :-) Thanks Neil From igloo at earth.li Sun Feb 17 09:42:32 2008 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 17 09:40:54 2008 Subject: [Haskell-cafe] GHC + interactive input/output In-Reply-To: References: <9898D516-17A7-4069-9F19-8424521F0C48@fastmail.fm> <088C3D96-B91F-44ED-A267-AF5CADFCD60F@ece.cmu.edu> Message-ID: <20080217144231.GA17307@matrix.chaos.earth.li> Hi Richard, On Mon, Feb 11, 2008 at 12:37:27PM +1300, Richard A. O'Keefe wrote: > > On 9 Feb 2008, at 2:29 pm, Philip Weaver wrote: > > >GHC certain *could* do this, but it's arguably not the right thing > >to do. > > I have reminded the GHC maintainers before that the Haskell > specification > *REQUIRES* a Haskell system to support this; ["this" is flushing stdout when we read from stdin, if I have followed correctly] Can you please say where the report says this? I've just skimmed http://haskell.org/onlinereport/io.html and didn't see it mentioned. Also, if there's a GHC bug about this, can you please point me to it? A quick search didn't find anything. > there is an example that > makes > no sense whatever without it. I'm not sure which example you're referring to, but the first example on the above page 21.10.1 Summing Two Numbers starts off by doing hSetBuffering stdout NoBuffering which implies to me that implementations are not expected to do the flushing hack. Thanks Ian From bjorn at bringert.net Sun Feb 17 10:09:10 2008 From: bjorn at bringert.net (Bjorn Bringert) Date: Sun Feb 17 10:07:33 2008 Subject: [Haskell-cafe] Working with multiple time zones In-Reply-To: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> Message-ID: On Feb 17, 2008 12:13 AM, Dave Hinton wrote: > (This is a toy program to demonstrate only the part of my real program > that I'm having trouble with.) > > Suppose I'm writing a program to print the current time in various > time zones. The time zones are to be given symbolically on the command > line in the form "Europe/London" or "America/New_York". The idea is > that either the operating system or the runtime library keeps track of > what time zones different places are in, and when they are on summer > time, so that my code doesn't have to worry about it. > > Haskell has a TimeZone type in Data.Time.LocalTime, but it only > represents constant offsets from UTC ? doesn't encode rules for when > the clocks change. And there doesn't seem to be any way of looking up > the time zone for a locality. > > Data.Time.LocalTime has the getTimeZone function, which returns the > time zone for a given UTC time on the local machine ? this takes care > of summer time, but by itself only works for the local machine's > locality. > > If I was writing this program in C, I'd get round this by setting the > TZ environment variable to the locality I was interested in before > doing time conversions. > > $ cat cnow.c > #include > #include > #include > #include > void outTime (time_t utc, char *tzName) > { > char env[100] = "TZ="; > strcat (env, tzName); > putenv (env); > printf ("%s\t%s", tzName, asctime (localtime (&utc))); > } > int main (int argc, char **argv) > { > int i; > time_t utc = time (NULL); > for (i = 1; i < argc; ++i) outTime (utc, argv[i]); > return 0; > } > $ gcc cnow.c -o cnow > $ ./cnow Europe/Paris Europe/Moscow Europe/London > Europe/Paris Sat Feb 16 23:57:22 2008 > Europe/Moscow Sun Feb 17 01:57:22 2008 > Europe/London Sat Feb 16 22:57:22 2008 > > So far, so good. Here's the equivalent in Haskell: > > $ cat hsnow.hs > import Data.Time > import Data.Time.LocalTime > import System.Environment > import System.Posix.Env > outTime utc env > = do putEnv ("TZ=" ++ env) > tz <- getTimeZone utc > putStrLn (env ++ "\t" ++ show (utcToLocalTime tz utc)) > main > = do utc <- getCurrentTime > mapM_ (outTime utc) =<< getArgs > $ ghc --make hsnow.hs -o hsnow > [1 of 1] Compiling Main ( hsnow.hs, hsnow.o ) > Linking hsnow ... > $ ./hsnow Europe/Paris Europe/Moscow Europe/London > Europe/Paris 2008-02-16 23:59:11.776151 > Europe/Moscow 2008-02-16 23:59:11.776151 > Europe/London 2008-02-16 23:59:11.776151 > $ ./hsnow Europe/Moscow Europe/London Europe/Paris > Europe/Moscow 2008-02-17 01:59:28.617711 > Europe/London 2008-02-17 01:59:28.617711 > Europe/Paris 2008-02-17 01:59:28.617711 > > Not good. GHC's runtime library seems to be taking the value of TZ the > first time it is called as gospel, and ignoring subsequent changes to > TZ. > > So: > > 1. Is this a bug in GHC's Data.Time.LocalTime.getTimeZone? > 2. If GHC's implementation is working as designed, how do I translate > the C program above into Haskell? > > I'm running on Debian stable, with GHC 6.6. Interesting, it works for me: $ ghc --make hsnow.hs -o hsnow [1 of 1] Compiling Main ( hsnow.hs, hsnow.o ) Linking hsnow ... $ ./hsnow Europe/Paris Europe/Moscow Europe/London Europe/Paris 2008-02-17 16:07:43.009057 Europe/Moscow 2008-02-17 18:07:43.009057 Europe/London 2008-02-17 15:07:43.009057 $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 $ uname -srv Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 -- /Bj?rn From daniel.is.fischer at web.de Sun Feb 17 11:26:23 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Feb 17 11:23:15 2008 Subject: [Haskell-cafe] Working with multiple time zones In-Reply-To: References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> Message-ID: <200802171726.23468.daniel.is.fischer@web.de> Am Sonntag, 17. Februar 2008 16:09 schrieb Bjorn Bringert: > > Interesting, it works for me: > > $ ghc --make hsnow.hs -o hsnow > [1 of 1] Compiling Main ( hsnow.hs, hsnow.o ) > Linking hsnow ... > > $ ./hsnow Europe/Paris Europe/Moscow Europe/London > Europe/Paris 2008-02-17 16:07:43.009057 > Europe/Moscow 2008-02-17 18:07:43.009057 > Europe/London 2008-02-17 15:07:43.009057 > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.8.2 > > $ uname -srv > Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT > 2007; root:xnu-792.25.20~1/RELEASE_I386 Doesn't work for me: dafis@linux:~> ghc --make hsnow.hs -o hsnw [1 of 1] Compiling Main ( hsnow.hs, hsnow.o ) Linking hsnw ... dafis@linux:~> ./hsnw Europe/Moscow Europe/Paris Europe/London Europe/Moscow 2008-02-17 18:37:24.107667 Europe/Paris 2008-02-17 18:37:24.107667 Europe/London 2008-02-17 18:37:24.107667 dafis@linux:~> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Adding some debug-code, we see that the TZ evironment variable is properly set, but the TimeZone returned by getTimeZone is always that of the first argument: dafis@linux:~> ./hsnow Europe/Moscow Europe/Paris Europe/London Just "Europe/Moscow" 2008-02-17 16:01:56.061005 UTC MSK Europe/Moscow 2008-02-17 19:01:56.061005 Just "Europe/Paris" 2008-02-17 16:01:56.061005 UTC MSK Europe/Paris 2008-02-17 19:01:56.061005 Just "Europe/London" 2008-02-17 16:01:56.061005 UTC MSK Europe/London 2008-02-17 19:01:56.061005 Looking at the code in HsTime.c, it might be a difference between localtime and localtime_r. From donn at avvanta.com Sun Feb 17 12:56:21 2008 From: donn at avvanta.com (Donn Cave) Date: Sun Feb 17 12:54:46 2008 Subject: [Haskell-cafe] Re: Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> Message-ID: <43BC324B-F62B-40D3-8982-9E8DB115D8CC@avvanta.com> On Feb 17, 2008, at 1:12 AM, Colin Paul Adams wrote: > > And left is not the opposite of correct. That would be incorrect. > > Also, it is not clear to me that a failure to read a file (for > instance) is incorrect behaviour. If the file doesn't exist, then I > think it ought to be considered correct behaviour to fail to read the > file. Well, of course correct behavior is to cope with both cases in the most appropriate way. If it's any consolation to those of the left handed persuasion, I guessed it wrong - I have used Either in this way, but Left was Success and Right was Failure. I don't enjoy puns, and mapped to an A/B form it seemed obvious that Success is A. Donn Cave, donn@avvanta.com From daniel.is.fischer at web.de Sun Feb 17 13:22:49 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sun Feb 17 13:19:41 2008 Subject: [Haskell-cafe] Working with multiple time zones In-Reply-To: <200802171726.23468.daniel.is.fischer@web.de> References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> <200802171726.23468.daniel.is.fischer@web.de> Message-ID: <200802171922.49686.daniel.is.fischer@web.de> Am Sonntag, 17. Februar 2008 17:26 schrieb Daniel Fischer: > > Looking at the code in HsTime.c, it might be a difference between localtime > and localtime_r. > Indeed, mucking about a bit with HsTime.c, so that either a) localtime is called instead of localtime_r or b) tzset() is done before localtime_r, it works as it should (on my box at least). Cheers, Daniel From jerzy.karczmarczuk at info.unicaen.fr Sun Feb 17 13:28:07 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Sun Feb 17 13:26:30 2008 Subject: [Haskell-cafe] Re: Doubting Haskell In-Reply-To: <43BC324B-F62B-40D3-8982-9E8DB115D8CC@avvanta.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802161453t28205203vecbcfabe9c04bd91@mail.gmail.com> <43BC324B-F62B-40D3-8982-9E8DB115D8CC@avvanta.com> Message-ID: Donn Cave writes: > On Feb 17, 2008, at 1:12 AM, Colin Paul Adams wrote: >> And left is not the opposite of correct. That would be incorrect. ... > If it's any consolation to those of the left handed persuasion, I guessed > it wrong - I have used Either in this way, but Left was Success and > Right was Failure. I don't enjoy puns, and mapped to an A/B form > it seemed obvious that Success is A. Weellll, for those who don't enjoy puns, but feel that the life and everything is one enormous pun, a political reminder. For many years, the world is composed of Leftists and Rightists (let's for the moment forget the normal people). Those from the Left always felt that they were right, and that those from the Right should not be left unpunished, while those from the Right thought that those from the Left should be left to die. Even if it seems right to consider that these deviations should be left to historians, we should not forget that at the beginning of the glorious Soviet country there was a proposal to change the meaning of traffic lights. Red would mean "Forward!!". On the other hand, in France nowadays the difference between Right and Left is more or less the same as between "Immediate failure" and "Delayed failure". Choose yourselves which is which. Jerzy Karczmarczuk From allbery at ece.cmu.edu Sun Feb 17 13:43:48 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Feb 17 13:42:12 2008 Subject: [Haskell-cafe] Working with multiple time zones In-Reply-To: <200802171922.49686.daniel.is.fischer@web.de> References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> <200802171726.23468.daniel.is.fischer@web.de> <200802171922.49686.daniel.is.fischer@web.de> Message-ID: <35B7D015-EAE1-4A19-955B-5E77E5B3970F@ece.cmu.edu> On Feb 17, 2008, at 13:22 , Daniel Fischer wrote: > Am Sonntag, 17. Februar 2008 17:26 schrieb Daniel Fischer: >> Looking at the code in HsTime.c, it might be a difference between >> localtime >> and localtime_r. > > Indeed, mucking about a bit with HsTime.c, so that either > a) localtime is called instead of localtime_r > or > b) tzset() is done before localtime_r, > it works as it should (on my box at least). Yes, some platforms require tzset() to recognize timezone changes. -- 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 ryani.spam at gmail.com Sun Feb 17 13:59:00 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Sun Feb 17 13:57:22 2008 Subject: [Haskell-cafe] Designing a Parser In-Reply-To: <7.0.1.0.0.20080217073059.01cff1d8@ntlworld.com> References: <7.0.1.0.0.20080217061839.01d001f0@ntlworld.com> <7ca3f0160802162303g6a08d90fga84fb4a3c3549feb@mail.gmail.com> <7.0.1.0.0.20080217073059.01cff1d8@ntlworld.com> Message-ID: <2f9b2d30802171059q51ecf405y3e66ccecd7fa233f@mail.gmail.com> Writing a parsing library like this is a great learning experience; Graham Hutton wrote a paper you can follow along with entitled "Monadic Parsing in Haskell" at http://www.cs.nott.ac.uk/~gmh/bib.html#pearl But if you're just interested in writing a parser, and not in writing a parser generator, I recommend Parsec; it's included with GHC as Text.ParserCombinators.Parsec, and there is a tutorial in the second part of this page: http://legacy.cs.uu.nl/daan/download/parsec/parsec.html -- ryan From beakerchu at googlemail.com Sun Feb 17 14:10:47 2008 From: beakerchu at googlemail.com (Dave Hinton) Date: Sun Feb 17 14:09:09 2008 Subject: [Haskell-cafe] Re: Working with multiple time zones In-Reply-To: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> Message-ID: <61d3022d0802171110l6a90c92fwace7bd5c6fe9afe6@mail.gmail.com> Hurrah, I am now calling the C function tzset() from my Haskell code via FFI, and I'm getting the results I want. $ cat hsc2now.hs {-# LANGUAGE ForeignFunctionInterface #-} import Data.Time import Data.Time.LocalTime import System.Environment import System.Posix.Env foreign import ccall "time.h tzset" tzset :: IO () outTime utc tzName = do putEnv ("TZ=" ++ tzName) tzset tz <- getTimeZone utc putStrLn (tzName ++ "\t" ++ show (utcToLocalTime tz utc)) main = do utc <- getCurrentTime mapM_ (outTime utc) =<< getArgs $ ghc --make hsc2now.hs -o hsc2now [1 of 1] Compiling Main ( hsc2now.hs, hsc2now.o ) Linking hsc2now ... $ ./hsc2now Europe/Moscow Europe/Paris Europe/London Europe/Moscow 2008-02-17 22:06:44.770153 Europe/Paris 2008-02-17 20:06:44.770153 Europe/London 2008-02-17 19:06:44.770153 Thank you everyone for your help :-) From dons at galois.com Sun Feb 17 14:37:17 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 17 14:36:44 2008 Subject: [Haskell-cafe] Re: Working with multiple time zones In-Reply-To: <61d3022d0802171110l6a90c92fwace7bd5c6fe9afe6@mail.gmail.com> References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> <61d3022d0802171110l6a90c92fwace7bd5c6fe9afe6@mail.gmail.com> Message-ID: <20080217193717.GA3376@scytale.galois.com> beakerchu: > Hurrah, I am now calling the C function tzset() from my Haskell code > via FFI, and I'm getting the results I want. > > $ cat hsc2now.hs > {-# LANGUAGE ForeignFunctionInterface #-} > import Data.Time > import Data.Time.LocalTime > import System.Environment > import System.Posix.Env > foreign import ccall "time.h tzset" tzset :: IO () > outTime utc tzName > = do putEnv ("TZ=" ++ tzName) > tzset > tz <- getTimeZone utc > putStrLn (tzName ++ "\t" ++ show (utcToLocalTime tz utc)) > main > = do utc <- getCurrentTime > mapM_ (outTime utc) =<< getArgs > $ ghc --make hsc2now.hs -o hsc2now > [1 of 1] Compiling Main ( hsc2now.hs, hsc2now.o ) > Linking hsc2now ... > $ ./hsc2now Europe/Moscow Europe/Paris Europe/London > Europe/Moscow 2008-02-17 22:06:44.770153 > Europe/Paris 2008-02-17 20:06:44.770153 > Europe/London 2008-02-17 19:06:44.770153 > > Thank you everyone for your help :-) Perhaps we should get a binding to tzset in the unix library? From ahey at iee.org Sun Feb 17 17:01:14 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Feb 17 16:59:37 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <20080217123141.GA5229@kantaka.co.uk> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> Message-ID: <47B8AEAA.3050005@iee.org> Philip Armstrong wrote: > Since no-one else has answered, I'll take a stab. > Obiously, you have a stack leak due to laziness somewhere I wouldn't say that was obvious, though it is certainly a possibility. I'm never exactly clear what people mean by a "stack leak". It seems some folk regard any algorithm that makes use of O(n) or worse stack space as a "stack leak". My opinion is that using O(n) or worse working memory when the job could be done in O(log n) or O(1) memory is certainly bad, but using O(n) stack is no worse in principle than using O(n) heap. But at the moment it is worse in practice with ghc, regretably :-( > In fact, a little experimentation has revealed that this: > > do > [path] <- getArgs > m <- liftM decode (BS.readFile path)::IO [((Int, Maybe String), Int)] > putStrLn . show . findMax . fromAscList $ m > > will work just fine. No extra evaluation needed at all! I'll leave it > to the Haskell gurus to explain what's going on... That's very interesting. Strangely if you use fromDistinctAscList instead (as used by the Binary instance get method) the problem re-appears. This is despite fromAscList making use of fromDistinctAscList. BTW, I find this especially ironic as fromDistinctAscList is the perfect example what I was talking about in another thread (continuation passing madness caused by an irrational fear of stack use). As to what's really going on here, I haven't figured it out and I'm not really inclined to try :-) Regards -- Adrian Hey From bertram.felgenhauer at googlemail.com Sun Feb 17 17:44:23 2008 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun Feb 17 17:42:57 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <47B8AEAA.3050005@iee.org> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> <47B8AEAA.3050005@iee.org> Message-ID: <20080217224423.GA4787@zombie.inf.tu-dresden.de> Adrian Hey wrote: > Philip Armstrong wrote: >> In fact, a little experimentation has revealed that this: >> do >> [path] <- getArgs >> m <- liftM decode (BS.readFile path)::IO [((Int, Maybe String), Int)] >> putStrLn . show . findMax . fromAscList $ m >> will work just fine. No extra evaluation needed at all! I'll leave it >> to the Haskell gurus to explain what's going on... > > That's very interesting. Strangely if you use fromDistinctAscList > instead (as used by the Binary instance get method) the problem > re-appears. This is despite fromAscList making use of fromDistinctAscList. > BTW, I find this especially ironic as fromDistinctAscList is the perfect > example what I was talking about in another thread (continuation passing > madness caused by an irrational fear of stack use). I'm fairly certain that the stack overflow is (indirectly) caused by Data.Binary, not Data.Map. The result of 'decode' is a list of known length with unevaluated elements (because the Get monad is lazy) [*], where each element depends on the previous one (because reading is sequential, and the elements of the list may have nonuniform size). Now when you evaluate the last element, that will demand the last but one element, which in turn will demand the previous element, and so on. If the list is long enough, you'll get a stack overflow. Using fromAscList instead of fromDistinctAscList cures the problem, because it inspects every key in the list, starting from the beginning, in order to eliminate duplicates. fromDistinctAscList, on the other hand, does not inspect the keys at all. do [path] <- getArgs m <- liftM decode (BS.readFile path)::IO [((Int, Maybe String), Int)] putStrLn . show . last $ m should also exhibit the same stack overflow. HTH, Bertram [*] For example, consider this: Prelude Data.Binary> length (decode (encode (42 :: Int)) :: [Int]) 42 Prelude Data.Binary> decode (encode (42 :: Int)) :: [Int] [*** Exception: too few bytes. Failed reading at byte position 16 From flippa at flippac.org Sun Feb 17 18:00:18 2008 From: flippa at flippac.org (Philippa Cowderoy) Date: Sun Feb 17 17:58:04 2008 Subject: [Haskell-cafe] More powerful error handling Message-ID: For a while I've been meaning to propose something along the lines of this class: class (MonadError m e, MonadError m' e') => MonadErrorRelated m e m' e' | m -> e, m' -> e', m e' -> m' where catch' :: m a -> (e -> m' a) -> m' a rethrow :: m a -> (e -> e') -> m' a with an example instance being: instance (Error e, Error e') => MonadErrorRelated (Either e) e (Either e') e' where catch' (Right v) _ = Right v catch' (Left e) h = h e rethrow c ef = catch' c (throw . ef) (yep, that definition of rethrow would make a sensible default and there's a default catch' in terms of rethrow too) The nicest use would be for converting between a more specific error type and a more general one that handles a wider range of errors - enabling us to keep tighter track of which errors are possible in a given piece of code. Bonus points for using it together with polymorphic variants where rethrow becomes rather trivial. The following two functions or close variants might also be useful: catchMaybe :: (MonadError m ()) => Maybe a -> m a catchMaybe Nothing = throwError () catchMaybe (Just a) = return a catchEither :: (MonadError m e) => Either e a -> m a catchEither (Left err) = throwError err catchEither (Right a) = return a No doubt there are some names that could use tweaking. As far as I'm concerned you can count me in the camp of people that resent the existing MonadError instances all requiring an Error instance too, it makes things messier when you have access to something like this. But I guess that's because fail is begging for the following definition: fail = fail -- fail is made of fail -- flippa@flippac.org There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances. From ahey at iee.org Sun Feb 17 18:45:26 2008 From: ahey at iee.org (Adrian Hey) Date: Sun Feb 17 18:43:48 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <20080217224423.GA4787@zombie.inf.tu-dresden.de> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> <47B8AEAA.3050005@iee.org> <20080217224423.GA4787@zombie.inf.tu-dresden.de> Message-ID: <47B8C716.8020302@iee.org> Bertram Felgenhauer wrote: > I'm fairly certain that the stack overflow is (indirectly) caused by > Data.Binary, not Data.Map. Yes, I think you are right. At least it seems clear that the stack overflow is not directly caused by fromDistinctAscList. > The result of 'decode' is a list of known length with unevaluated > elements (because the Get monad is lazy) [*], where each element depends > on the previous one (because reading is sequential, and the elements of > the list may have nonuniform size). Now when you evaluate the last > element, that will demand the last but one element, which in turn will > demand the previous element, and so on. If the list is long enough, > you'll get a stack overflow. > > Using fromAscList instead of fromDistinctAscList cures the problem, > because it inspects every key in the list, starting from the beginning, > in order to eliminate duplicates. fromDistinctAscList, on the other > hand, does not inspect the keys at all. > > do > [path] <- getArgs > m <- liftM decode (BS.readFile path)::IO [((Int, Maybe String), Int)] > putStrLn . show . last $ m > > should also exhibit the same stack overflow. Indeed it does. So it seems if I understand correctly, this is yet another example what I would call the lazy applied strict thunk chain problem (I'm sure you understand what I mean by that). The standard "party line" advice in such circumstances is to prevent their formation by evaluating eagerly as they are applied. However, this is often not possible for users of libraries they don't "own", if the API does not provide the necessary strictness control. I would argue that even if it possible is sometimes undesirable too (if evaluation is expensive, saves nothing in heap use and the final value may never be needed). So I still think the stack management system should be designed so that as far as is practical (given finite memory), any expression that can be built on the heap can also be evaluated without causing a "stack overflow". But I guess this rant is not much help to the OP :-) Regards -- Adrian Hey From mads_lindstroem at yahoo.dk Sun Feb 17 14:12:25 2008 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Sun Feb 17 18:49:38 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <1203275545.10676.7.camel@localhost.localdomain> Hi Alan I can help but feeling curious. Did some of the answers actually help you? Are you still as doubtful about Haskell as when you wrote your email? Greetings, Mads Lindstr?m From chad.scherrer at gmail.com Sun Feb 17 18:53:18 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Sun Feb 17 18:51:41 2008 Subject: [Haskell-cafe] stream/bytestring questions Message-ID: ByteStrings have given a real performance boost to a lot of Haskell applications, and I'm curious why some of the techniques aren't more abstracted and widely available. If it's "because it's a big job", that's certainly understandable, but maybe there's something I'm overlooking that some of the abstractions aren't really desirable. My first question is about the stream fusion. This seems (based on the ByteString paper) to speed things up quite a lot, but for some reason this isn't necessarily the case for lists. Is this just a matter of the existing fusion for lists doing such a good job in many cases that it's hard to beat? The streams paper suggests that some contructors aren't optimized away during fusion, but wouldn't this also be a problem for fusion in the bytestring context? Are there many cases where it helps performance to program to streams directly, rather than letting the rules go back and forth between them and lists? I tried to do this, but kept getting hung up on the Unlifted stuff; it's not exposed (pardon the pun) in the API, and I don't understand why the types are different than the usual (), Either a b, (a,b), etc. Second, the idea of representing a sequence as a lazy list of strict arrays is very appealing. But why represent it so concretely? Wouldn't it make sense to do something like data ArrayList a i e = Empty | Chunk !(a i e) (ArrayList a i e) ? Then array fusion could be written for IArray types in general, and the ByteString library would become a set of instances with some specialization pragmas. Presumably a more general StorableVector could be represented as an IArray, and the NDP stuff seems a good fit too, so this would make it easy to leverage future work. Seems to separate the various concerns a little better, too, but again maybe there's a performance issue I'm missing. Sorry for the barrage of questions; I guess there's just a lot I'm trying to understand better. Thanks, Chad From ccshan at post.harvard.edu Sun Feb 17 18:08:22 2008 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Sun Feb 17 18:58:58 2008 Subject: [Haskell-cafe] Re: Designing DSL with explicit sharing [was: I love?purity, but it's killing me] References: <20080215035124.4C509A99B@Adric.metnet.fnmoc.navy.mil> <20080216105938.GA4052@pc149.staff.cs.york.ac.uk> Message-ID: <6crm85-9tv.ln1@mantle.rutgers.edu> Matthew Naylor wrote in article <20080216105938.GA4052@pc149.staff.cs.york.ac.uk> in gmane.comp.lang.haskell.cafe: > > sklansky f [] = [] > > sklansky f [x] = [x] > > sklansky f xs = left' ++ [ f (last left') r | r <- right' ] > > where > > (left, right) = splitAt (length xs `div` 2) xs > > left' = sklansky f left > > right' = sklansky f right > ... > To write sklansky using your approach, it seems (to me) that the DSL's > expression type needs to be extended to support lists. It's actually enough for the -metalanguage- to support lists. You may not be surprised that the key is to program using continuations (again, functions just at the metalanguage level, not the object-language level): "sklansky" should have the (metalanguage) type Exp repr => (repr a -> repr a -> repr a) -> [repr a] -> ([repr a] -> repr b) -> repr b but it would be more convenient to use the continuation monad (from Control.Monad.Cont) and regard the creation of a name in the object language as a side effect in the metalanguage. import DSLSharing (Exp(..), unS) import Control.Monad.Cont (Cont(Cont), runCont) sklansky :: Exp repr => (repr a -> repr a -> repr a) -> [repr a] -> Cont (repr b) [repr a] sklansky f [] = return [] sklansky f [x] = return [x] sklansky f xs = do let (left, right) = splitAt (length xs `div` 2) xs left' <- sklansky f left right' <- sklansky f right fmap (left' ++) (mapM (Cont . let_ . f (last left')) right') Here's a quick test (I added some whitespace): *Sklansky> flip unS 0 $ flip runCont id $ fmap (foldl sub (constant 0)) $ sklansky add $ map (variable.('x':).show) [0..9] "let v0 = x0 + x1 in let v1 = x3 + x4 in let v2 = x2 + x3 in let v3 = x2 + v1 in let v4 = v0 + x2 in let v5 = v0 + v2 in let v6 = v0 + v3 in let v7 = x5 + x6 in let v8 = x8 + x9 in let v9 = x7 + x8 in let v10 = x7 + v8 in let v11 = v7 + x7 in let v12 = v7 + v9 in let v13 = v7 + v10 in let v14 = v6 + x5 in let v15 = v6 + v7 in let v16 = v6 + v11 in let v17 = v6 + v12 in let v18 = v6 + v13 in 0 - x0 - v0 - v4 - v5 - v6 - v14 - v15 - v16 - v17 - v18" -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig I am a signature virus. Put me in your signature. From allbery at ece.cmu.edu Sun Feb 17 19:13:07 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Feb 17 19:11:32 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: References: Message-ID: <9A94E4D2-63CA-45E0-A61C-2011A87E708F@ece.cmu.edu> On Feb 17, 2008, at 18:53 , Chad Scherrer wrote: > ByteStrings have given a real performance boost to a lot of Haskell > applications, and I'm curious why some of the techniques aren't more > abstracted and widely available. If it's "because it's a big job", > that's certainly understandable, but maybe there's something I'm > overlooking that some of the abstractions aren't really desirable. Have you looked at the stream-fusion package on Hackage? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream- fusion-0.1.1 -- 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 jefferson.r.heard at gmail.com Sun Feb 17 19:13:28 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Sun Feb 17 19:11:49 2008 Subject: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL Message-ID: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com> In C and in Java, I can use truetype fonts in Haskell using select libraries, and I'd like to be able to do the same in Haskell. Are there any portable libraries out there for loading fonts into OpenGL geometry for Haskell? I can use the vector fonts from GLUT is absolutely neccessary, but I'd like something that looks a little more professional. Are there any suggestions? -- Jeff -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From allbery at ece.cmu.edu Sun Feb 17 19:20:40 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Feb 17 19:19:02 2008 Subject: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL In-Reply-To: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com> References: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com> Message-ID: On Feb 17, 2008, at 19:13 , Jefferson Heard wrote: > In C and in Java, I can use truetype fonts in Haskell using select > libraries, and I'd like to be able to do the same in Haskell. Are > there any portable libraries out there for loading fonts into OpenGL > geometry for Haskell? I can use the vector fonts from GLUT is > absolutely neccessary, but I'd like something that looks a little more > professional. Are there any suggestions? Can't speak to OpenGL per se, but have a look at: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-ttf-0.4.0 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-xft-0.2 -- 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 chad.scherrer at gmail.com Sun Feb 17 19:23:25 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Sun Feb 17 19:21:50 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: <9A94E4D2-63CA-45E0-A61C-2011A87E708F@ece.cmu.edu> References: <9A94E4D2-63CA-45E0-A61C-2011A87E708F@ece.cmu.edu> Message-ID: On Feb 17, 2008 4:13 PM, Brandon S. Allbery KF8NH wrote: > Have you looked at the stream-fusion package on Hackage? > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream- > fusion-0.1.1 Yeah, I've seen this. It's nice that this is separated, but a little unsatisfying that the bytestring library reimplements it rather than just requiring it as a dependency. This, and the fact that bytestrings are way fast, while the stream-fusion stuff is sometimes slower than just using lists, make me think that either (1) there's sometimes an advantage in programming directly to streams, or (2) maybe more of the stream functions need to be exposed in the API. Or maybe there's another reason... that's part of my question. Chad From allbery at ece.cmu.edu Sun Feb 17 19:36:29 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Feb 17 19:34:52 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: References: <9A94E4D2-63CA-45E0-A61C-2011A87E708F@ece.cmu.edu> Message-ID: <80583CA1-F2A7-4DE6-A007-0916475D31E2@ece.cmu.edu> On Feb 17, 2008, at 19:23 , Chad Scherrer wrote: > On Feb 17, 2008 4:13 PM, Brandon S. Allbery KF8NH > wrote: >> Have you looked at the stream-fusion package on Hackage? >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream- >> fusion-0.1.1 > > Yeah, I've seen this. It's nice that this is separated, but a little > unsatisfying that the bytestring library reimplements it rather than > just requiring it as a dependency. This, and the fact that bytestrings > are way fast, while the stream-fusion stuff is sometimes slower than > just using lists, make me think that either (1) there's sometimes an > advantage in programming directly to streams, or (2) maybe more of the > stream functions need to be exposed in the API. Or maybe there's > another reason... that's part of my question. You should be able to find discussion of this here if you search for "stream fusion". The short version, IIRC, is that (a) this is still an area of active research, with the above lagging behind the current work which is usually in current bytestrings; (b) the spinoff library at times conflicts badly with the existing ghc RULEs for lists, and I think some changes to the way ghc applies RULEs are going to happen at some point in order to ameliorate this. (ghc's current handling of RULEs, inlining, and build/foldr etc. is a bit ad hoc and needs to be given structure so that it is possible to accurately control when and how they are applied. This also has been discussed, either here or on haskell@.) Don Stewart, Duncan Coutts (streams), and Simon Peyton-Jones (ghc) should be able to give details on this stuff, and hopefully one or more of them will jump in to correct any misrecollections or errors I've made. -- 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 dons at galois.com Sun Feb 17 20:01:23 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 17 19:59:48 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: References: Message-ID: <20080218010123.GA3817@scytale.galois.com> chad.scherrer: > ByteStrings have given a real performance boost to a lot of Haskell > applications, and I'm curious why some of the techniques aren't more > abstracted and widely available. If it's "because it's a big job", > that's certainly understandable, but maybe there's something I'm > overlooking that some of the abstractions aren't really desirable. > > My first question is about the stream fusion. This seems (based on the > ByteString paper) to speed things up quite a lot, but for some reason > this isn't necessarily the case for lists. Is this just a matter of yeah, with lists, as compared to bytestrings, there are: * more complex operations to fuse * allocation is much cheaper (lazy list cons nodes) * built in desugaring for build/foldr fusion interferes (enumerations, comprehensions) so the benefits of fusing lists are less obvious than bytestrings, where every fusion point knocks out a big array allocation, and they're a bit more complex to get the full api going. > the existing fusion for lists doing such a good job in many cases that > it's hard to beat? The streams paper suggests that some contructors > aren't optimized away during fusion, but wouldn't this also be a > problem for fusion in the bytestring context? Are there many cases probably not, as the issues are mostly to do with deeply nested comprehensions, which simply aren't done with bytestrings. > where it helps performance to program to streams directly, rather than no, using the rules should be fine. you're not supposed to program in the stream abstraction. > letting the rules go back and forth between them and lists? I tried to > do this, but kept getting hung up on the Unlifted stuff; it's not > exposed (pardon the pun) in the API, and I don't understand why the > types are different than the usual (), Either a b, (a,b), etc. > > Second, the idea of representing a sequence as a lazy list of strict > arrays is very appealing. But why represent it so concretely? Wouldn't > it make sense to do something like > > data ArrayList a i e = Empty | Chunk !(a i e) (ArrayList a i e) > ? someone could do that. we chose to go with the monomorphic case, since its easier to get the api right, and the performance right. > Then array fusion could be written for IArray types in general, and > the ByteString library would become a set of instances with some > specialization pragmas. Presumably a more general StorableVector could > be represented as an IArray, and the NDP stuff seems a good fit too, > so this would make it easy to leverage future work. Seems to separate > the various concerns a little better, too, but again maybe there's a > performance issue I'm missing. > > Sorry for the barrage of questions; I guess there's just a lot I'm > trying to understand better. Sure. Hope that clears things up. From dons at galois.com Sun Feb 17 20:04:41 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 17 20:03:06 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: References: <9A94E4D2-63CA-45E0-A61C-2011A87E708F@ece.cmu.edu> Message-ID: <20080218010441.GA3887@scytale.galois.com> chad.scherrer: > On Feb 17, 2008 4:13 PM, Brandon S. Allbery KF8NH wrote: > > > Have you looked at the stream-fusion package on Hackage? > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream- > > fusion-0.1.1 > > Yeah, I've seen this. It's nice that this is separated, but a little > unsatisfying that the bytestring library reimplements it rather than > just requiring it as a dependency. This, and the fact that bytestrings they currently use two different fusion systems. bytestring uses an older version of what is now stream fusion. at some point we'll switch bytestrings over to using the new stuff in the stream-fusion package, since its a lot better. > are way fast, while the stream-fusion stuff is sometimes slower than > just using lists, make me think that either (1) there's sometimes an > advantage in programming directly to streams, or (2) maybe more of the > stream functions need to be exposed in the API. Or maybe there's > another reason... that's part of my question. ah, you assume stream-fusion lists are slower. for list stuff, since 6.8, i've only seen things the same speed or better. but if you have a program doing the wrong thing, it would be worth looking at. -- Don From john at repetae.net Sun Feb 17 20:09:20 2008 From: john at repetae.net (John Meacham) Date: Sun Feb 17 20:07:41 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <20080218010920.GB22804@sliver.repetae.net> On Sat, Feb 16, 2008 at 05:04:53PM -0800, Donn Cave wrote: > But in Haskell, you cannot read a file line by line without writing an > exception handler, because end of file is an exception! as if a file does > not normally have an end where the authors of these library functions > came from? Part of it is that using 'getLine' is not idiomatic haskell when you don't want to worry about exceptions. Generally you do something like doMyThing xs = print (length xs) main = do contents <- readFile "my.file" mapM_ doMyThing (lines contents) which will call 'doMyThing' on each line of the file, in this case printing the length of each line. or more succinctly: main = readFile "my.file" >>= mapM_ doMyThing . lines John -- John Meacham - ?repetae.net?john? From chad.scherrer at gmail.com Sun Feb 17 20:25:26 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Sun Feb 17 20:24:01 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: <20080218010441.GA3887@scytale.galois.com> References: <9A94E4D2-63CA-45E0-A61C-2011A87E708F@ece.cmu.edu> <20080218010441.GA3887@scytale.galois.com> Message-ID: > they currently use two different fusion systems. bytestring uses an > older version of what is now stream fusion. at some point we'll switch > bytestrings over to using the new stuff in the stream-fusion package, > since its a lot better. Oh, that's pretty interesting. I had assumed bytestring had the latest fusion stuff. > ah, you assume stream-fusion lists are slower. for list stuff, since > 6.8, i've only seen things the same speed or better. but if you have a > program doing the wrong thing, it would be worth looking at. I was just going by the "Lists to Streams to Nothing At All" paper. That's great that it's gotten faster! Does that mean the path for replacing Data.List with this is any clearer? From lrpalmer at gmail.com Sun Feb 17 20:26:17 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Sun Feb 17 20:24:38 2008 Subject: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL In-Reply-To: References: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com> Message-ID: <7ca3f0160802171726o789f61a1u2af22f270fd64127@mail.gmail.com> On Feb 18, 2008 12:20 AM, Brandon S. Allbery KF8NH wrote: > > On Feb 17, 2008, at 19:13 , Jefferson Heard wrote: > > > In C and in Java, I can use truetype fonts in Haskell using select > > libraries, and I'd like to be able to do the same in Haskell. Are > > there any portable libraries out there for loading fonts into OpenGL > > geometry for Haskell? I can use the vector fonts from GLUT is > > absolutely neccessary, but I'd like something that looks a little more > > professional. Are there any suggestions? > > Can't speak to OpenGL per se, but have a look at: > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-ttf-0.4.0 > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-xft-0.2 I have an immature, but precise and picky implementation that renders text in a ttf font to an OpenGL texture (using SDL-ttf) here: http://svn.luqui.org/svn/misc/luke/work/code/haskell/frp/Fregl/Draw.hs (It may have some dependencies in the same directory). Text support is way at the bottom. Good Luck, Luke From dons at galois.com Sun Feb 17 20:27:25 2008 From: dons at galois.com (Don Stewart) Date: Sun Feb 17 20:25:48 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: References: <9A94E4D2-63CA-45E0-A61C-2011A87E708F@ece.cmu.edu> <20080218010441.GA3887@scytale.galois.com> Message-ID: <20080218012725.GA3959@scytale.galois.com> chad.scherrer: > > they currently use two different fusion systems. bytestring uses an > > older version of what is now stream fusion. at some point we'll switch > > bytestrings over to using the new stuff in the stream-fusion package, > > since its a lot better. > > Oh, that's pretty interesting. I had assumed bytestring had the latest > fusion stuff. > > > ah, you assume stream-fusion lists are slower. for list stuff, since > > 6.8, i've only seen things the same speed or better. but if you have a > > program doing the wrong thing, it would be worth looking at. > > I was just going by the "Lists to Streams to Nothing At All" paper. > That's great that it's gotten faster! Does that mean the path for > replacing Data.List with this is any clearer? Not yet. We still don't have a good system for fusing nested concatMaps, that GHC likes, which come up when you desugar list comprehensions. If you can live without too many comprehensions, then the stream-fusion package is entirely viable. -- Don From jefferson.r.heard at gmail.com Sun Feb 17 20:28:59 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Sun Feb 17 20:27:21 2008 Subject: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL In-Reply-To: <7ca3f0160802171726o789f61a1u2af22f270fd64127@mail.gmail.com> References: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com> <7ca3f0160802171726o789f61a1u2af22f270fd64127@mail.gmail.com> Message-ID: <4165d3a70802171728g1aa433e2o78517035f1b16d77@mail.gmail.com> Thanks. that's certainly a thought... doesn't make the text 3d, though, does it? I'd ideally like to have something that turns the text into geometry, but this'll do in a pinch... On Sun, Feb 17, 2008 at 8:26 PM, Luke Palmer wrote: > On Feb 18, 2008 12:20 AM, Brandon S. Allbery KF8NH wrote: > > > > On Feb 17, 2008, at 19:13 , Jefferson Heard wrote: > > > > > In C and in Java, I can use truetype fonts in Haskell using select > > > libraries, and I'd like to be able to do the same in Haskell. Are > > > there any portable libraries out there for loading fonts into OpenGL > > > geometry for Haskell? I can use the vector fonts from GLUT is > > > absolutely neccessary, but I'd like something that looks a little more > > > professional. Are there any suggestions? > > > > Can't speak to OpenGL per se, but have a look at: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-ttf-0.4.0 > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/X11-xft-0.2 > > I have an immature, but precise and picky implementation that renders text in > a ttf font to an OpenGL texture (using SDL-ttf) here: > http://svn.luqui.org/svn/misc/luke/work/code/haskell/frp/Fregl/Draw.hs > (It may have some dependencies in the same directory). Text support is > way at the bottom. > > Good Luck, > > Luke > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From chad.scherrer at gmail.com Sun Feb 17 21:02:47 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Sun Feb 17 21:01:10 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: <20080218010123.GA3817@scytale.galois.com> References: <20080218010123.GA3817@scytale.galois.com> Message-ID: On Feb 17, 2008 5:01 PM, Don Stewart wrote: > yeah, with lists, as compared to bytestrings, there are: > > * more complex operations to fuse > * allocation is much cheaper (lazy list cons nodes) > * built in desugaring for build/foldr fusion interferes (enumerations, comprehensions) > > so the benefits of fusing lists are less obvious than bytestrings, where > every fusion point knocks out a big array allocation, and they're a bit > more complex to get the full api going. Ok, that makes sense. > no, using the rules should be fine. you're not supposed to program in > the stream abstraction. I was working on some run-length encoding stuff and found it most natural to do a lot of it using unfoldr, and I had a state in the unfold that was naturally represented as a tuple. I got a little worried about all the packing and unpacking tuples not being optimized out, and this got me wondering about just using Streams directly. At the time, the Skip constructor for a Step felt natural to use in some places, which I thought could be really convenient. I dunno, maybe it's not an issue. Hmm, if it would help I can try to post some of the code... > > Wouldn't > > it make sense to do something like > > > > data ArrayList a i e = Empty | Chunk !(a i e) (ArrayList a i e) > > ? > > someone could do that. we chose to go with the monomorphic case, since > its easier to get the api right, and the performance right. Unless I'm overlooking something, this would involve something like... (1) make the fusion stuff apply to an IArray (pretty handy anyway) (2) make (strict) ByteString an instance of IArray (or maybe via StorableArray) (3) write an ArrayList module, similar to Data.ByteString.Lazy >From this, it would be pretty short again, in theory, to write an alternate ByteString library using the abstractions. The point of this would be to leverage future code improvements and reduce code duplication. Does this seem reasonable? Or is it too soon to consider this kind of extension? Chad From jeremy at n-heptane.com Sun Feb 17 22:07:08 2008 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Sun Feb 17 22:05:25 2008 Subject: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL In-Reply-To: <7ca3f0160802171726o789f61a1u2af22f270fd64127@mail.gmail.com> References: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com> <7ca3f0160802171726o789f61a1u2af22f270fd64127@mail.gmail.com> Message-ID: <87wsp3x8rn.wl%jeremy.shaw@linspireinc.com> At Mon, 18 Feb 2008 01:26:17 +0000, Luke Palmer wrote: > I have an immature, but precise and picky implementation that renders text in > a ttf font to an OpenGL texture (using SDL-ttf) here: > http://svn.luqui.org/svn/misc/luke/work/code/haskell/frp/Fregl/Draw.hs > (It may have some dependencies in the same directory). Text support is > way at the bottom. Along the same lines, I have an imcomplete, but direct binding to freetype and an incomplete binding to GLX which can be used to draw text to opengl textures: http://n-heptane.com/nhlab/repos/haskell-freetype/ http://n-heptane.com/nhlab/repos/haskell-glx/ This file contains an example of drawing text using GLX+FreeType: http://n-heptane.com/nhlab/repos/haskell-freetype/FreeTypeTest.hs This code has not been touched in a few years, so it probably needs some updates to work with ghc 6.8. Also, I believe the X11 package now has builtin support for ClientMessage, so that module can go away. j. From derek.a.elkins at gmail.com Sun Feb 17 21:06:56 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Feb 17 22:06:15 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: References: <20080218010123.GA3817@scytale.galois.com> Message-ID: <1203300416.5522.5.camel@derek-laptop> On Sun, 2008-02-17 at 18:02 -0800, Chad Scherrer wrote: > On Feb 17, 2008 5:01 PM, Don Stewart wrote: > > yeah, with lists, as compared to bytestrings, there are: > > > > * more complex operations to fuse > > * allocation is much cheaper (lazy list cons nodes) > > * built in desugaring for build/foldr fusion interferes (enumerations, comprehensions) > > > > so the benefits of fusing lists are less obvious than bytestrings, where > > every fusion point knocks out a big array allocation, and they're a bit > > more complex to get the full api going. > > Ok, that makes sense. > > > no, using the rules should be fine. you're not supposed to program in > > the stream abstraction. > > I was working on some run-length encoding stuff and found it most > natural to do a lot of it using unfoldr, and I had a state in the > unfold that was naturally represented as a tuple. I got a little > worried about all the packing and unpacking tuples not being optimized > out, and this got me wondering about just using Streams directly. At > the time, the Skip constructor for a Step felt natural to use in some > places, which I thought could be really convenient. I dunno, maybe > it's not an issue. Hmm, if it would help I can try to post some of the > code... It's -quite- possible that a coalgebraic perspective is much more natural for your code/problem. If that's the case, use it (the coalgebraic perspective that is). Obviously depending on the internals of the stream library is not a good idea and using Streams directly was not their intent, but it is your code. Do what you will. From tgdavies at gmail.com Sun Feb 17 22:37:07 2008 From: tgdavies at gmail.com (Tom Davies) Date: Sun Feb 17 22:35:42 2008 Subject: [Haskell-cafe] Arrow combinator names Message-ID: Are there generally accepted English language names for the arrow combinators? >>> compose? &&& pair? etc... From derek.a.elkins at gmail.com Sun Feb 17 21:45:12 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sun Feb 17 22:44:31 2008 Subject: [Haskell-cafe] Arrow combinator names In-Reply-To: References: Message-ID: <1203302712.5522.8.camel@derek-laptop> On Mon, 2008-02-18 at 03:37 +0000, Tom Davies wrote: > Are there generally accepted English language names for the arrow combinators? > > >>> compose? That's fine though ambiguous. > &&& pair? > > etc... The rest don't generally accepted readings. There are some examples of wordier names used (e.g. fork for (&&&)), but nothing generally accepted. From scook0 at gmail.com Mon Feb 18 00:11:44 2008 From: scook0 at gmail.com (Stuart Cook) Date: Mon Feb 18 00:10:09 2008 Subject: [Haskell-cafe] naming a data structure for weighted random selection without replacement Message-ID: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> A while ago I wrote a little data structure that allows weighted random selection-without-replacement from a collection of values in O(log n) time.[1] I'm now in the process of packaging it up for Hackage, but I'm looking for good names for both the type and its operations. The name I have at the moment is "Pool", which I'm reasonably happy with, but I wanted to see if I could find anything better. Asking on #haskell got me a few responses: * Hat (cute, but conflicts with the program tracer) * Bag (already way too overloaded) * Bucket (not as suggestive as Pool) I have three main operations: * "pull" selects a random element, returning it and the remainder, but fails if the pool is empty * "pullN" selects /n/ distinct elements, returning them and the remainder, but fails if the pool has too few elements * "takeN" selects up to /n/ distinct elements, returning them and the remainder, but returns no more elements than could be found in the pool (analogous to Data.List.take) Any suggestions? Stuart [1] Actually I delegated most of the work to the data-structure-in-a-can that is Data.FingerTree, but that's another story. From simonpj at microsoft.com Mon Feb 18 03:48:35 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Feb 18 03:47:06 2008 Subject: [Haskell-cafe] Re: problem with collection (container) class In-Reply-To: <200802082323.39726.daniel.is.fischer@web.de> References: <15c02dff0802062358g632cea57ifc7eeaee3aa1f587@mail.gmail.com> <200802071326.14078.daniel.is.fischer@web.de> <200802082323.39726.daniel.is.fischer@web.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C318352FA1BC@EA-EXMSG-C334.europe.corp.microsoft.com> Good point. Happily I improved the error message a couple of weeks ago, so it'll be better in the next release Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Daniel Fischer | Sent: 08 February 2008 22:24 | To: Ben Franksen; haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] Re: problem with collection (container) class | | Am Freitag, 8. Februar 2008 22:14 schrieb Ben Franksen: | > If it's a bug then it is probably in 6.6.1 too, it just gets hidden by the | > fact that in 6.6.1 the -fglasgow-exts extensions cannot be activated | > separately. If you enable one of them, you get them all. | > | Thanks for the info, didn't know that. | | The problem was the error message, which didn't mention that each type | variable may appear only once in an instance head, which I had temporarily | forgotten. Then the message | | Leandro.hs:32:0: | Illegal instance declaration for `Container (Abb a b) a b' | (All instance types must be of the form (T a1 ... an) | where a1 ... an are distinct type *variables* | Use -XFlexibleInstances if you want to disable this.) | In the instance declaration for `Container (Abb a b) a b' | | looks rather confusing :) | | > Cheers | > Ben | > | Cheers, | Daniel | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From phil at kantaka.co.uk Mon Feb 18 04:20:56 2008 From: phil at kantaka.co.uk (Philip Armstrong) Date: Mon Feb 18 04:19:16 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <47B8AEAA.3050005@iee.org> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> <47B8AEAA.3050005@iee.org> Message-ID: <20080218092056.GA6426@kantaka.co.uk> On Sun, Feb 17, 2008 at 10:01:14PM +0000, Adrian Hey wrote: > Philip Armstrong wrote: >> Since no-one else has answered, I'll take a stab. >> Obiously, you have a stack leak due to laziness somewhere > > I wouldn't say that was obvious, though it is certainly a > possibility. > > I'm never exactly clear what people mean by a "stack leak". > It seems some folk regard any algorithm that makes use of > O(n) or worse stack space as a "stack leak". In my personal lexicon, a stack leak is one where you accumulate unevaluated thunks on the stack. In this case, the combination of Data.Map not evaluating it's values and Data.Binary being lazy is (I think) resulting in decode thunks accumulating on the stack. > My opinion is that using O(n) or worse working memory when > the job could be done in O(log n) or O(1) memory is certainly > bad, but using O(n) stack is no worse in principle than using > O(n) heap. But at the moment it is worse in practice with ghc, > regretably :-( I'd agree with this entirely. >> In fact, a little experimentation has revealed that this: >> >> do >> [path] <- getArgs >> m <- liftM decode (BS.readFile path)::IO [((Int, Maybe String), Int)] >> putStrLn . show . findMax . fromAscList $ m >> >> will work just fine. No extra evaluation needed at all! I'll leave it >> to the Haskell gurus to explain what's going on... > > That's very interesting. Strangely if you use fromDistinctAscList > instead (as used by the Binary instance get method) the problem > re-appears. This is despite fromAscList making use of fromDistinctAscList. Yup. It's because (I've just realised) fromAscList is evaluating the values returned by decode in order to build the Distinct Ascending List to pass to fromDistinctAscList. A previous version I was going to put up simply ran another function over the list before passing it to the map constructor, which was not particularly elegant but also worked. Data.Binary calls fromDistinctAscList to build the map, which is why it gets into this mess. > BTW, I find this especially ironic as fromDistinctAscList is the perfect > example what I was talking about in another thread (continuation passing > madness caused by an irrational fear of stack use). In *some* cases, continuation passing can be quite a bit faster than other approaches IIRC. I haven't looked at this bit of code though. > As to what's really going on here, I haven't figured it out and I'm not > really inclined to try :-) I did try and do some profiling, but gave up when I realised that I'd have to go sprinking SCCs around the core libraries, which would mean recompiling Data.Map and friends... Heap profile graphs which assign everything to "CAF" are not very helpful :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt LocalWords: fromDistinctAscList IIRC sprinking From phil at kantaka.co.uk Mon Feb 18 04:23:38 2008 From: phil at kantaka.co.uk (Philip Armstrong) Date: Mon Feb 18 04:21:57 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <47B8C716.8020302@iee.org> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> <47B8AEAA.3050005@iee.org> <20080217224423.GA4787@zombie.inf.tu-dresden.de> <47B8C716.8020302@iee.org> Message-ID: <20080218092338.GB6426@kantaka.co.uk> On Sun, Feb 17, 2008 at 11:45:26PM +0000, Adrian Hey wrote: > But I guess this rant is not much help to the OP :-) Can the Get Monad from Data.Binary be replaced by the one in Data.Binary.Strict.Get? Would probably require some hacking on the library I guess. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt From ashley at semantic.org Mon Feb 18 04:25:47 2008 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Feb 18 04:24:09 2008 Subject: [Haskell-cafe] Re: Working with multiple time zones In-Reply-To: <20080217193717.GA3376@scytale.galois.com> References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> <61d3022d0802171110l6a90c92fwace7bd5c6fe9afe6@mail.gmail.com> <20080217193717.GA3376@scytale.galois.com> Message-ID: <47B94F1B.6060908@semantic.org> Don Stewart wrote: > Perhaps we should get a binding to tzset in the unix library? That's probably preferable to calling tzset() before every localtime_r. But perhaps we want a call that combines the putenv and the tzset, just so it exposes fewer implementation details. This is essentially an interface to the zoneinfo database rather than time functionality as such. Ideally there would be a better C interface to zoneinfo that wouldn't involve mucking around with (global) environment variables. -- Ashley Yakeley Seattle, WA From lemming at henning-thielemann.de Mon Feb 18 05:53:24 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Feb 18 05:51:43 2008 Subject: [Haskell-cafe] naming a data structure for weighted random selection without replacement In-Reply-To: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> References: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> Message-ID: On Mon, 18 Feb 2008, Stuart Cook wrote: > A while ago I wrote a little data structure that allows weighted > random selection-without-replacement from a collection of values in > O(log n) time.[1] I'm now in the process of packaging it up for > Hackage, but I'm looking for good names for both the type and its > operations. Some ours ago I uploaded a package which would allow this: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/probability-0.2 You would stack a State transformer with a distribution as state and the inner monad is a Probability.Random.T. A similar example is here: http://darcs.haskell.org/probability/src/Numeric/Probability/Example/Collection.hs But maybe your concern is efficiency, and thus you need the special data structure. From lemming at henning-thielemann.de Mon Feb 18 05:58:39 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Feb 18 05:57:30 2008 Subject: [Haskell-cafe] More powerful error handling In-Reply-To: References: Message-ID: On Sun, 17 Feb 2008, Philippa Cowderoy wrote: > The nicest use would be for converting between a more specific error type > and a more general one that handles a wider range of errors - enabling us > to keep tighter track of which errors are possible in a given piece of > code. Bonus points for using it together with polymorphic variants where > rethrow becomes rather trivial. I guess it's about exception handling, not error handling, right? I thought that must be possible by plugging various exception types together, say data CustomException = IOExc IOError | NetworkExc NetworkException | ThreadExc ThreadingException Now you can turn any IOError to CustomException by wrapping it with IOExc. From lrpalmer at gmail.com Mon Feb 18 06:37:11 2008 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 18 06:35:30 2008 Subject: [Haskell-cafe] naming a data structure for weighted random selection without replacement In-Reply-To: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> References: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> Message-ID: <7ca3f0160802180337y695c5a3xbe2384b366d68543@mail.gmail.com> On Feb 18, 2008 5:11 AM, Stuart Cook wrote: > A while ago I wrote a little data structure that allows weighted > random selection-without-replacement from a collection of values in > O(log n) time.[1] I'm now in the process of packaging it up for > Hackage, but I'm looking for good names for both the type and its > operations. I'm pretty sure it should have Random in the name whatever it is called. Luke > The name I have at the moment is "Pool", which I'm reasonably happy > with, but I wanted to see if I could find anything better. Asking on > #haskell got me a few responses: > > * Hat (cute, but conflicts with the program tracer) > * Bag (already way too overloaded) > * Bucket (not as suggestive as Pool) > > I have three main operations: > > * "pull" selects a random element, returning it and the remainder, but > fails if the pool is empty > * "pullN" selects /n/ distinct elements, returning them and the > remainder, but fails if the pool has too few elements > * "takeN" selects up to /n/ distinct elements, returning them and the > remainder, but returns no more elements than could be found in the > pool (analogous to Data.List.take) > > Any suggestions? > > > Stuart > > [1] Actually I delegated most of the work to the > data-structure-in-a-can that is Data.FingerTree, but that's another > story. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From michal.palka at poczta.fm Mon Feb 18 06:54:17 2008 From: michal.palka at poczta.fm (=?UTF-8?Q?Micha=C5=82_Pa=C5=82ka?=) Date: Mon Feb 18 06:52:41 2008 Subject: [Haskell-cafe] naming a data structure for weighted random selection without replacement In-Reply-To: <7ca3f0160802180337y695c5a3xbe2384b366d68543@mail.gmail.com> References: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> <7ca3f0160802180337y695c5a3xbe2384b366d68543@mail.gmail.com> Message-ID: <1203335657.4676.8.camel@localhost> On Mon, 2008-02-18 at 11:37 +0000, Luke Palmer wrote: > On Feb 18, 2008 5:11 AM, Stuart Cook wrote: > > A while ago I wrote a little data structure that allows weighted > > random selection-without-replacement from a collection of values in > > O(log n) time.[1] I'm now in the process of packaging it up for > > Hackage, but I'm looking for good names for both the type and its > > operations. > > I'm pretty sure it should have Random in the name whatever it is > called. Obvious idea: How about WeightedRandom? Micha? From grzegorz.chrupala at computing.dcu.ie Mon Feb 18 06:56:32 2008 From: grzegorz.chrupala at computing.dcu.ie (Grzegorz Chrupala) Date: Mon Feb 18 06:54:50 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <20080218092056.GA6426@kantaka.co.uk> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> <47B8AEAA.3050005@iee.org> <20080218092056.GA6426@kantaka.co.uk> Message-ID: <15543838.post@talk.nabble.com> Philip Armstrong wrote: > > On Sun, Feb 17, 2008 at 10:01:14PM +0000, Adrian Hey wrote: >> Philip Armstrong wrote: >>> Since no-one else has answered, I'll take a stab. >>> Obiously, you have a stack leak due to laziness somewhere >> >> I wouldn't say that was obvious, though it is certainly a >> possibility. >> >> I'm never exactly clear what people mean by a "stack leak". >> It seems some folk regard any algorithm that makes use of >> O(n) or worse stack space as a "stack leak". > > In my personal lexicon, a stack leak is one where you accumulate > unevaluated thunks on the stack. > > In this case, the combination of Data.Map not evaluating it's values > and Data.Binary being lazy is (I think) resulting in decode thunks > accumulating on the stack. > >> My opinion is that using O(n) or worse working memory when >> the job could be done in O(log n) or O(1) memory is certainly >> bad, but using O(n) stack is no worse in principle than using >> O(n) heap. But at the moment it is worse in practice with ghc, >> regretably :-( > > I'd agree with this entirely. > >>> In fact, a little experimentation has revealed that this: >>> >>> do >>> [path] <- getArgs >>> m <- liftM decode (BS.readFile path)::IO [((Int, Maybe String), Int)] >>> putStrLn . show . findMax . fromAscList $ m >>> >>> will work just fine. No extra evaluation needed at all! I'll leave it >>> to the Haskell gurus to explain what's going on... >> >> That's very interesting. Strangely if you use fromDistinctAscList >> instead (as used by the Binary instance get method) the problem >> re-appears. This is despite fromAscList making use of >> fromDistinctAscList. > > Yup. It's because (I've just realised) fromAscList is evaluating the > values returned by decode in order to build the Distinct Ascending > List to pass to fromDistinctAscList. A previous version I was going to > put up simply ran another function over the list before passing it to > the map constructor, which was not particularly elegant but also > worked. > > Data.Binary calls fromDistinctAscList to build the map, which is why > it gets into this mess. > >> BTW, I find this especially ironic as fromDistinctAscList is the perfect >> example what I was talking about in another thread (continuation passing >> madness caused by an irrational fear of stack use). > > In *some* cases, continuation passing can be quite a bit faster than > other approaches IIRC. I haven't looked at this bit of code though. > >> As to what's really going on here, I haven't figured it out and I'm not >> really inclined to try :-) > > I did try and do some profiling, but gave up when I realised that I'd > have to go sprinking SCCs around the core libraries, which would mean > recompiling Data.Map and friends... > > Heap profile graphs which assign everything to "CAF" are not very > helpful :) > > Phil > > Thanks to everyone who answered, this fixes my particular problem, and I think thanks to the comments I sort of vaguely understand what going on now. I run into this kind of esoteric laziness leaks from time to time and it's very frustrating -- I think that's about the only thing I don't like about Haskell. -- Grzegorz -- View this message in context: http://www.nabble.com/Stack-overflow-tp15479718p15543838.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From simonmarhaskell at gmail.com Mon Feb 18 08:26:17 2008 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 18 08:24:42 2008 Subject: [Haskell-cafe] Re: Doubting Haskell In-Reply-To: <47B79ABA.1040705@serpentine.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <47B789DF.5010604@serpentine.com> <20080217013602.GA4786@localhost.localdomain> <47B79ABA.1040705@serpentine.com> Message-ID: <47B98779.9020601@microsoft.com> Bryan O'Sullivan wrote: > Stefan O'Rear wrote: > >> I'll bet that breaks horribly in the not-so-corner case of /dev/tty. > > Actually, it doesn't. It seems to do a read behind the scenes if the > buffer is empty, so it blocks until you type something. Indeed, and this is why even an unbuffered Handle needs to have a 1-character buffer, an interesting fact I discovered when implementing the I/O library. Cheers, Simon From dave.a.tapley at gmail.com Mon Feb 18 12:47:52 2008 From: dave.a.tapley at gmail.com (Dave Tapley) Date: Mon Feb 18 12:46:11 2008 Subject: [Haskell-cafe] Haskell Thrift bindings Message-ID: Hi everyone, This is regarding Thrift, "a software framework for scalable cross-language services development"(1) Present in the release tarball there is some source for Haskell but no sign of a tutorial or any sample code. I'm just picking through but as a long shot does anyone have examples they could send me? I'm also looking to put together a page on haskellwiki once I'm up and running. The project seems like a fine way to sneak Haskell into existing project ;) Cheers, Dave (1) http://developers.facebook.com/thrift/ From ahey at iee.org Mon Feb 18 12:56:41 2008 From: ahey at iee.org (Adrian Hey) Date: Mon Feb 18 12:55:01 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <20080218092056.GA6426@kantaka.co.uk> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> <47B8AEAA.3050005@iee.org> <20080218092056.GA6426@kantaka.co.uk> Message-ID: <47B9C6D9.8070907@iee.org> Philip Armstrong wrote: > On Sun, Feb 17, 2008 at 10:01:14PM +0000, Adrian Hey wrote: >> BTW, I find this especially ironic as fromDistinctAscList is the perfect >> example what I was talking about in another thread (continuation passing >> madness caused by an irrational fear of stack use). > > In *some* cases, continuation passing can be quite a bit faster than > other approaches IIRC. I haven't looked at this bit of code though. Can you or anyone else give an example? Thanks -- Adrian Hey From phil at kantaka.co.uk Mon Feb 18 13:37:49 2008 From: phil at kantaka.co.uk (Philip Armstrong) Date: Mon Feb 18 13:36:06 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <47B9C6D9.8070907@iee.org> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> <47B8AEAA.3050005@iee.org> <20080218092056.GA6426@kantaka.co.uk> <47B9C6D9.8070907@iee.org> Message-ID: <20080218183749.GA8008@kantaka.co.uk> On Mon, Feb 18, 2008 at 05:56:41PM +0000, Adrian Hey wrote: > Philip Armstrong wrote: >> On Sun, Feb 17, 2008 at 10:01:14PM +0000, Adrian Hey wrote: >>> BTW, I find this especially ironic as fromDistinctAscList is the perfect >>> example what I was talking about in another thread (continuation passing >>> madness caused by an irrational fear of stack use). >> >> In *some* cases, continuation passing can be quite a bit faster than >> other approaches IIRC. I haven't looked at this bit of code though. > > Can you or anyone else give an example? I think I was thinking of this: http://r6.ca/blog/20071028T162529Z.html but can't be entirely sure. Sorry! Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt From ben.franksen at online.de Mon Feb 18 13:41:57 2008 From: ben.franksen at online.de (Ben Franksen) Date: Mon Feb 18 13:43:44 2008 Subject: [Haskell-cafe] Re: A question about "monad laws" References: <47B06B3B.2070504@cs.tcd.ie> <90533B63-96C0-4982-A695-8A217A61BBC2@cs.otago.ac.nz> <47B39936.10509@cse.unsw.edu.au> <6A400340-AA2D-47F9-9552-EAAED17F6403@cs.otago.ac.nz> <47B3CB1D.6040404@cse.unsw.edu.au> <47B408B2.3090900@cse.unsw.edu.au> <20080214052011.vdcelmp6yo8c84c4@webmail.spamcop.net> Message-ID: Wilhelm B. Kloke wrote: > Ben Franksen schrieb: >> Wilhelm B. Kloke wrote: >>> ajb@spamcop.net schrieb: >>>> >>> I would consider a good idea if ghc would provide language support to >>> this sort of integers. >> >> No need, you can do that for yourself: >> >> {-# LANGUAGE GeneralizedNewtypeDeriving #-} >> newtype DInt = DInt Double deriving (Eq, Ord, Enum, Num) >> >> instance Show DInt where show (DInt x) = show (truncate x :: Integer) > > Probably you missed the point I wanted to make. Obviously ;) > This works only properly, > if you can catch the Inexact Trap which indicates the overflow. The > problem whith normal Ints is that the hardware does not support overflow > detection. You get silent wrong results if you use an Int type which maps > to C int, but not if it maps to C float or double with Inexact trap > enabled. Therefore you need add runtime checks to be sure that you notice > a possible overflow condition. I agree completely. Cheers Ben From byorgey at gmail.com Mon Feb 18 14:01:20 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Mon Feb 18 13:59:41 2008 Subject: [Haskell-cafe] Arrow combinator names In-Reply-To: References: Message-ID: <22fcbd520802181101r5afe7f22l54995972fa309325@mail.gmail.com> On Sun, Feb 17, 2008 at 10:37 PM, Tom Davies wrote: > Are there generally accepted English language names for the arrow > combinators? > > >>> compose? Well, compose usually means something with type (a c d -> a b c -> a b d), but (>>>) has the dual type (a b c -> a c d -> a b d). So it's really "cocompose", which, of course, can be shortened to "mpose". -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080218/ca21e815/attachment.htm From brett.gibson at talk21.com Mon Feb 18 15:20:25 2008 From: brett.gibson at talk21.com (Brett Gibson) Date: Mon Feb 18 15:23:27 2008 Subject: [Haskell-cafe] Re: naming a data structure for weighted random selection without replacement References: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> Message-ID: Stuart Cook gmail.com> writes: > The name I have at the moment is "Pool", which I'm reasonably happy > with, but I wanted to see if I could find anything better. Asking on > #haskell got me a few responses: > > ... > > Any suggestions? How about Tombola? Brett From gale at sefer.org Mon Feb 18 18:07:43 2008 From: gale at sefer.org (Yitzchak Gale) Date: Mon Feb 18 18:06:01 2008 Subject: [Haskell-cafe] Re: Working with multiple time zones In-Reply-To: <20080217193717.GA3376@scytale.galois.com> References: <61d3022d0802161513v776274c3p4c3f185b8ed61535@mail.gmail.com> <61d3022d0802171110l6a90c92fwace7bd5c6fe9afe6@mail.gmail.com> <20080217193717.GA3376@scytale.galois.com> Message-ID: <2608b8a80802181507s783213a0q6d0a8a6a4c27ba5@mail.gmail.com> Brandon S. Allbery KF8NH wrote: >> some platforms require tzset() to recognize timezone changes. I think it is something like - POSIX requires the tzset() call, but in ANSI C 98 there is no tzset() and localtime() always rechecks TZ automatically. Right? In the man page on Mac OS X Tiger (Darwin 8.11.1), it says that localtime() calls tzset() automatically if the current process has not called it yet. Which implies that it would only be called once, so I don't understand Bjorn's successful result on that platform. Don Stewart wrote: > Perhaps we should get a binding to tzset in the unix library? I agree - but to make it worthwhile, we should either: a) make things work the same on all platforms, or b) faithfully expose the underlying local platform, but make it easy (and well documented) for a program to discover what needs to be done to make things work. (Even if the information provided by System.Info is sufficient, how easy is it to use it for this?) In any case, full information or a clear pointer to it should appear in the Haddocks for Data.Time.LocalTime, System.Time, and wherever else appropriate. For comparison, Python does (a) - the behavior of localtime() and tzset() are always like POSIX, even on a platform that does otherwise. And also on Windows. This behavior is clearly described in the documentation for the time module. Regards, Yitz From aslatter at gmail.com Mon Feb 18 21:05:39 2008 From: aslatter at gmail.com (Antoine Latter) Date: Mon Feb 18 21:03:57 2008 Subject: [Haskell-cafe] build-depends contraints in a .cabal file Message-ID: <694519c50802181805n2f3f2d9cke13eb758f95b290b@mail.gmail.com> Can I specify an equality constraint in the build-depends field of a .cabal file? This would say that I want one specific version (because all the rest of my packages are compiled against that version and I'm getting type-checking errors trying to install the new package). neither > build-depends: foobar = 3.0.1 or > build-depends: foobar-3.0.1 seem to work. Do I have any choices other than re-compiling everything? Thanks, Antoine From isaacdupree at charter.net Mon Feb 18 21:27:04 2008 From: isaacdupree at charter.net (Isaac Dupree) Date: Mon Feb 18 21:25:07 2008 Subject: [Haskell-cafe] naming a data structure for weighted random selection without replacement In-Reply-To: <1203335657.4676.8.camel@localhost> References: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> <7ca3f0160802180337y695c5a3xbe2384b366d68543@mail.gmail.com> <1203335657.4676.8.camel@localhost> Message-ID: <47BA3E78.7040803@charter.net> Micha? Pa?ka wrote: > On Mon, 2008-02-18 at 11:37 +0000, Luke Palmer wrote: >> On Feb 18, 2008 5:11 AM, Stuart Cook wrote: >>> A while ago I wrote a little data structure that allows weighted >>> random selection-without-replacement from a collection of values in >>> O(log n) time.[1] I'm now in the process of packaging it up for >>> Hackage, but I'm looking for good names for both the type and its >>> operations. >> I'm pretty sure it should have Random in the name whatever it is >> called. > > Obvious idea: How about WeightedRandom? the "without replacement" thing is more specific. Although maybe the design could accomodate selection-with-replacement in the same package too or RandomPool? RandomHat? OutOfAHat? :-) -Isaac From scook0 at gmail.com Mon Feb 18 22:31:21 2008 From: scook0 at gmail.com (Stuart Cook) Date: Mon Feb 18 22:29:44 2008 Subject: [Haskell-cafe] naming a data structure for weighted random selection without replacement In-Reply-To: <47BA3E78.7040803@charter.net> References: <49b351060802172111g1de2258cu35226488fd23cf02@mail.gmail.com> <7ca3f0160802180337y695c5a3xbe2384b366d68543@mail.gmail.com> <1203335657.4676.8.camel@localhost> <47BA3E78.7040803@charter.net> Message-ID: <49b351060802181931t9b3051cv979c337d11fbb105@mail.gmail.com> On Tue, Feb 19, 2008 at 1:27 PM, Isaac Dupree wrote: > the "without replacement" thing is more specific. Although maybe the > design could accomodate selection-with-replacement in the same package too Once you have without-replacement, with-replacement is easy: just re-use the old structure instead of the new one. Laziness means that you don't even pay the cost of deletion. (Multiple-with-replacement takes a little more work, because you can't just re-use the multiple-without-replacement function if you want each draw to be independent.) > or RandomPool? RandomHat? OutOfAHat? :-) I'm currently leaning towards something like "Data.Random.WeightedPool". (I really love Hat and Urn, but I now think they're a little *too* cute.) Stuart From g9ks157k at acme.softbase.org Tue Feb 19 05:31:34 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 05:30:29 2008 Subject: [Haskell-cafe] Arrow combinator names In-Reply-To: References: Message-ID: <200802191131.35135.g9ks157k@acme.softbase.org> Am Montag, 18. Februar 2008 04:37 schrieb Tom Davies: > Are there generally accepted English language names for the arrow > combinators? > > >>> compose? > > &&& pair? > > etc... I call >>> ?sequence?. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 19 05:05:01 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 05:31:36 2008 Subject: [Haskell-cafe] Re: Doubting Haskell In-Reply-To: References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> Message-ID: <200802191105.01512.g9ks157k@acme.softbase.org> Am Sonntag, 17. Februar 2008 10:12 schrieb Colin Paul Adams: > The mnemonics is that Right x is "right" in the sense of > correct. So, the error case has to be Left err . > > As I said, this is sinister (i.e. regarding left-handed people as > evil). I hardly can believe that you mean this seriously. Do you really think that the Haskell architects wanted to offend left-handed people? What does assure you that the names of the Either constructors are about handedness? Are you really so sensitive that you want to make people think about all kinds of misinterpretations the usage of an everyday word may cause before they use it? I?d propose that people don?t search for non-existent defamation so that productivity doesn?t get buried under the search for ?politically correct? words. Actually, I wouldn?t have dreamed of Left being related to left-handedness. To me, it has long been very clear that Left and Right were assigned its meaning this way round because otherwise you wouldn?t get Functor and Monad instances. A pure technical reason, having nothing to do with hands, politics and whatever you might think of. > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 19 05:33:07 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 05:31:59 2008 Subject: [Haskell-cafe] build-depends contraints in a .cabal file In-Reply-To: <694519c50802181805n2f3f2d9cke13eb758f95b290b@mail.gmail.com> References: <694519c50802181805n2f3f2d9cke13eb758f95b290b@mail.gmail.com> Message-ID: <200802191133.07963.g9ks157k@acme.softbase.org> Am Dienstag, 19. Februar 2008 03:05 schrieb Antoine Latter: > Can I specify an equality constraint in the build-depends field of a > .cabal file? This would say that I want one specific version (because > all the rest of my packages are compiled against that version and I'm > getting type-checking errors trying to install the new package). > > neither > > > build-depends: foobar = 3.0.1 > > or > > > build-depends: foobar-3.0.1 > > seem to work. > > Do I have any choices other than re-compiling everything? > > Thanks, > Antoine I think, you should use == instead of =. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 19 05:28:40 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 05:33:37 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: <47B8376B.1010108@telenet.be> References: <47B7E4E1.6040506@telenet.be> <20080217113318.GA2994@soi.city.ac.uk> <47B8376B.1010108@telenet.be> Message-ID: <200802191128.40946.g9ks157k@acme.softbase.org> Am Sonntag, 17. Februar 2008 14:32 schrieb Peter Verswyvelen: > I don't get why the name isn't "arrow" instead of "arr"... Arr reminds > me of pirates, "arrrrrrrhh" ;-) > I guess "first" was chosen because "fst" was already taken, but then it > would be logical to choose "arrow" instead of "arr" ;-) arr has two problems in my opinion. First, it is an unneccessarily truncated name. Is it really so difficult to type two letters more? Second, it doesn?t describe its purpose very well. Okay, it constructs an arrow. But (>>>) and first do this as well. pure makes much more sense to me, since it says that it constructs *pure* arrows. If you look at Grapfruit?s source code, you probably won?t find any occurences of arr (but you?ll find Arrow.pure rather often). Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 19 05:36:13 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 05:34:59 2008 Subject: [Haskell-cafe] Re: a help for install In-Reply-To: <864256.86995.qm@web55508.mail.re4.yahoo.com> References: <864256.86995.qm@web55508.mail.re4.yahoo.com> Message-ID: <200802191136.13871.g9ks157k@acme.softbase.org> Am Montag, 18. Februar 2008 19:46 schrieb Carlos Gomez A.: > hi, my name is carlos > > I need information for correct install or > > what are dependencies on ghc ? > > I have a Debian System. Always use your distribution?s packages until they aren?t any or there is good reason not to do so. Try ?aptitude install ghc6?. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 19 05:22:22 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 05:35:50 2008 Subject: [Haskell-cafe] Where does ~> come from? In-Reply-To: <404396ef0802170541o70a37be0x82123be1b95aa52a@mail.gmail.com> References: <404396ef0802170541o70a37be0x82123be1b95aa52a@mail.gmail.com> Message-ID: <200802191122.23121.g9ks157k@acme.softbase.org> Am Sonntag, 17. Februar 2008 14:41 schrieb Neil Mitchell: > Hi > > > 2) You would hope there is a quick way to search those symbols. But > > most search engines do not treate symbols friendly, often just ignore > > them. I typed ~> in Hoogle, it also returned nothing. > > 3) If the module defining the symbol is not in standard library, it is > > not possible to look up the symbol in the core library index. > > The next version of Hoogle will allow you to search all the modules on > Hackage, i.e. it will find ~>. A month after I have written my thesis > this will all be done :-) > > Thanks > > Neil I think, it won?t find it. As Cale said, it?s a type variable. It?s like the ?a? in the following definition: data T a = T a a I think, Conal Elliott used an operator type variable in order to make his code more readable. The (~>) is a type parameter which stands for an arrow type. Best wishes, Wolfgang From duncan.coutts at worc.ox.ac.uk Tue Feb 19 06:07:53 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 19 06:15:59 2008 Subject: [Haskell-cafe] build-depends contraints in a .cabal file In-Reply-To: <694519c50802181805n2f3f2d9cke13eb758f95b290b@mail.gmail.com> References: <694519c50802181805n2f3f2d9cke13eb758f95b290b@mail.gmail.com> Message-ID: <1203419273.2102.35.camel@localhost> On Mon, 2008-02-18 at 20:05 -0600, Antoine Latter wrote: > Can I specify an equality constraint in the build-depends field of a > .cabal file? This would say that I want one specific version (because > all the rest of my packages are compiled against that version and I'm > getting type-checking errors trying to install the new package). > > neither > > build-depends: foobar = 3.0.1 > > or > > build-depends: foobar-3.0.1 > > seem to work. > Do I have any choices other than re-compiling everything? As Wolfgang says, use ==. I should note that I'm also just about to add detection for this kind of problem where we end up getting inconsistent versions of installed packages. In future you'll get a warning like: Configuring Foo-1.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package rss-3000.0.1 requires HaXml-1.13.3 package Foo-1.0 requires HaXml-1.19.2 http://hackage.haskell.org/trac/hackage/ticket/220 Separately we're also trying to add a: cabal configure --constraint "HaXml < 1.19" construct to let users add additional constraints on the configure command line. http://hackage.haskell.org/trac/hackage/ticket/224 This should be useful in the above situation until we have something more automatic, though the real purpose is to make it easier for people to test with various versions of deps and to allow cabal-install to specify exact dependencies after it has constructed its install plan. BTW, if you have a suggestion for a better command line flag name then do say. Duncan From ahey at iee.org Tue Feb 19 07:22:11 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Feb 19 07:20:31 2008 Subject: [Haskell-cafe] Re: Haskell maximum stack depth In-Reply-To: <47B45ED9.3050302@microsoft.com> References: <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> <47B45ED9.3050302@microsoft.com> Message-ID: <47BAC9F3.5070200@iee.org> Simon Marlow wrote: > The point is, GHC has no such thing as the "overall program memory > limit" unless by that you mean the total amount of memory + swap in your > machine. You can set a limit with +RTS -M, but there isn't one by > default. So what happens when you write a program with a space leak is > that it gobbles up all the memory, and turns on the hard disk light for > a few minutes until the OS gives up and kills it. Or at least, you hope > it kills your program and not something else important you were doing at > the time. Well if having "unbounded" (by default) memory use in the form of heap is OK with most users then I can't see why the same should not be OK for stack. An errant program is just as likely to explode the heap as it is the stack AFAICS. > We used to have a default heap limit, for the reason above, but I was > persuaded to remove it because it was too much of a pain to keep having > to say +RTS -M when your program ran out of memory. So we > could do the same with the stack limit - the only concern is whether it > will be highly inconvenient when we accidentally write programs with > infinite loops, which in my experience seem to occur more than > space-leaky programs. To be honest, in all my years of Haskelling I can't think of a single occasion where I've had a program get stuck in an infinite loop. I've had plenty of stack overflows, and they're reported on the mailing lists pretty regularly, but on all such occasions it's been caused by deep but very definitely finite recursion. > We could also set the limit a lot higher than it currently is. Or, we > could try to figure out how much memory is in the machine and set it > based on that. Basically, I don't care that much, unless it means I > have to do a lot of work to implement it :) I don't think just keeping the implementation as it is and just changing (or removing) the limit is really an option. Unfortunately, as things are at present, using a lot of stack with a program compiled by ghc really is a "bug" and the limit does provide users with some protection against this. But IMO the bug is in the ghc rts, not the users source code most of the time :-( I think at the minimum, the stack shrinking mod you suggested should be implemented before the limit is removed. Regards -- Adrian Hey From ahey at iee.org Tue Feb 19 07:41:47 2008 From: ahey at iee.org (Adrian Hey) Date: Tue Feb 19 07:40:04 2008 Subject: [Haskell-cafe] Stack overflow In-Reply-To: <20080218183749.GA8008@kantaka.co.uk> References: <15479718.post@talk.nabble.com> <20080217123141.GA5229@kantaka.co.uk> <47B8AEAA.3050005@iee.org> <20080218092056.GA6426@kantaka.co.uk> <47B9C6D9.8070907@iee.org> <20080218183749.GA8008@kantaka.co.uk> Message-ID: <47BACE8B.7010802@iee.org> Philip Armstrong wrote: > On Mon, Feb 18, 2008 at 05:56:41PM +0000, Adrian Hey wrote: >> Philip Armstrong wrote: >>> On Sun, Feb 17, 2008 at 10:01:14PM +0000, Adrian Hey wrote: >>>> BTW, I find this especially ironic as fromDistinctAscList is the >>>> perfect >>>> example what I was talking about in another thread (continuation >>>> passing >>>> madness caused by an irrational fear of stack use). >>> >>> In *some* cases, continuation passing can be quite a bit faster than >>> other approaches IIRC. I haven't looked at this bit of code though. >> >> Can you or anyone else give an example? > > I think I was thinking of this: > > http://r6.ca/blog/20071028T162529Z.html > > but can't be entirely sure. Sorry! Perhaps I should say can someone provide an example and explain why they believe it is faster. That isn't to say I doubt the measurements taken with that particular code, but I must say that if transforming code that uses the "hardware accelerated" continuation passing (by that I mean the machine stack of course) to explicit continuations on the heap is generally faster, there must be something very wrong in stack land. But perhaps there is? Interestingly, if you allow sufficient stack space for Grzegorz version (+64M) it does terminate, but it's still much slower than the version you provided (about 30 times slower). I don't know if this slow down is due only to the stack use, or whether both the stack use and the slow down are just different artefacts of the problem Bertram mentioned. Regards -- Adrian Hey From jeff1.61803 at gmail.com Tue Feb 19 10:49:03 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Tue Feb 19 10:47:20 2008 Subject: [Haskell-cafe] Selecting Array type Message-ID: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> I'm trying to create a type called SmartArray. It is a type synonym for an array. If the element type can be unboxed, then SmartArray is an unboxed array. Otherwise, it is a boxed array. For instance, (SmartArray Int Double) is the same as (UArray Int Double) (SmartArray Int String) is the same as (Array Int String) However, my implementation of SmartArray requires me to create an instance of a selector class to tell the compiler wheither the type is boxed or unboxed. I'm hoping to avoid creating instances of the selector class for every possible type. I'd be grateful for any suggestions. Please see my code: {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception -XOverlappingInstances #-} import Data.Ix import Data.Array.Unboxed import Data.Complex type SmartArray i e = (Ix i, SmartArraySelector a e) => (a i e) -- smartArray is similar to array function from Data.Array. But, it -- will return a UArray if e can be unboxed. Otherwise, it returns an Array. smartArray :: (i, i) -> [(i, e)] -> SmartArray i e smartArray bnd eLst = array bnd eLst class (IArray a e) => SmartArraySelector a e | e -> a where arrayType :: Ix i => a i e -> a i e arrayType = id -- SmartArraySelector selects UArray for all types that can be -- unboxed. An instance has to be created for each unboxed type. I'd -- like to avoid listing all unboxed types here. However, since there -- are only a few unboxed types, it's not too burdensome to list them -- all. (For brevity, I didn't create all possible instances.) instance SmartArraySelector UArray Bool where instance SmartArraySelector UArray Char where instance SmartArraySelector UArray Double where instance SmartArraySelector UArray Float where instance SmartArraySelector UArray Int where -- SmartArraySelector selects Array for all types that can't be -- unboxed. An instance has to be created for EVERY possible unboxed -- type that might be used with SmartArray. Since, the list of -- possible types is unlimited, this is pretty annoying. instance SmartArraySelector Array String where instance SmartArraySelector Array (Complex e) where -- I'd like to replace all the boxed instances above with one instance -- like . . . -- -- instance SmartArraySelector Array e where -- -- However, this generates an error even though, -- -XOverlappingInstances turned on. test e = smartArray (0,10) [ (i,e) | i <- [0..10]] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080219/34508bbc/attachment.htm From bf3 at telenet.be Tue Feb 19 11:04:39 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Tue Feb 19 11:02:42 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: <200802191128.40946.g9ks157k@acme.softbase.org> References: <47B7E4E1.6040506@telenet.be> <20080217113318.GA2994@soi.city.ac.uk> <47B8376B.1010108@telenet.be> <200802191128.40946.g9ks157k@acme.softbase.org> Message-ID: <00e701c87311$21daba00$65902e00$@be> Ah, "pure" stands for "pure arrow". I found this confusing since I consider all functions in Haskell (except unsafeXXX and maybe IO) to be "pure". So pureArrow would be good but is so loooong ;-) Actually, if you look at the way OO programmers design code, they usually choose long descriptive names, like "FindElementByName". Most Haskell people seem more math oriented and use very short names, like "fst" and "snd" (which are a bit better than the old "car" and "cdr"). Now in the end, once you get used to a name, it doesn't matter does it? But when I show typical Haskell code to object-oriented friends of mine, they get scared because it looks like math, with all the symbols and short names. But if I show code like render $ solid (rectangle (position 100 100) (size 400 50)) `inColor` red `over` line (position 50 50) (position 150 150) `withLineSize` 4 `inColor` blue and compare that to what this would like when using C++ (or C# with WPF...), they go... wow... The only question they tend to ask is "what does the $ and `` do?". And if I tell them I designed this mini-language myself in Haskell in a few lines of code without lexing and yaccing, they can hardly believe it. Mmm, maybe this is a good one for "Why functional programming matters", but for the experienced Haskellers, the above DSL stuff is probably too obvious. So even if I don't know much of Haskell yet, the ability to write these small DSLs so compactly and elegantly is what one of things I really like about the language. E.g. for my students, I wrote a little "3D vector math" exercise generator in a couple of hours. This tool generates algebraic exercises and shows the solutions step by step by performing simplification, using indented pretty printing. I would never have been able to do that in C++ or C# in such a short time and so compactly, even though I have +15 years more experience with the latter language. But in Haskell, even though I hardly know the language, it was "easy". I now want to use GTK2HS to generate PDFs from these exercises that also shows step-by-step geometrical solutions (but that's work in progress ;) PS: Wolfgang also seems to use nice names in Grapefruit for his types, e.g. act :: PlainCircuit (IO output) output createPlainCircuit :: PlainCircuit input output -> input -> IO (output, IO ()) instead of act :: PlainCircuit (IO a) a mkPlainCircuit :: PlainCircuit a b -> a -> IO (b, IO ()) What is the general "style guide" regarding this? > -----Original Message----- > From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- > bounces@haskell.org] On Behalf Of Wolfgang Jeltsch > Sent: Tuesday, February 19, 2008 11:29 AM > To: haskell-cafe@haskell.org > Subject: Re: [Haskell-cafe] Arrows: definition of pure & arr > > Am Sonntag, 17. Februar 2008 14:32 schrieb Peter Verswyvelen: > > I don't get why the name isn't "arrow" instead of "arr"... Arr > reminds > > me of pirates, "arrrrrrrhh" ;-) > > I guess "first" was chosen because "fst" was already taken, but then > it > > would be logical to choose "arrow" instead of "arr" ;-) > > arr has two problems in my opinion. First, it is an unneccessarily > truncated > name. Is it really so difficult to type two letters more? Second, it > doesn?t describe its purpose very well. Okay, it constructs an arrow. > But > (>>>) and first do this as well. pure makes much more sense to me, > since it > says that it constructs *pure* arrows. > > If you look at Grapfruit?s source code, you probably won?t find any > occurences > of arr (but you?ll find Arrow.pure rather often). > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.7/1286 - Release Date: > 2/18/2008 6:49 PM From lemming at henning-thielemann.de Tue Feb 19 11:09:24 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 19 11:07:39 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: <00e701c87311$21daba00$65902e00$@be> References: <47B7E4E1.6040506@telenet.be> <20080217113318.GA2994@soi.city.ac.uk> <47B8376B.1010108@telenet.be> <200802191128.40946.g9ks157k@acme.softbase.org> <00e701c87311$21daba00$65902e00$@be> Message-ID: On Tue, 19 Feb 2008, Peter Verswyvelen wrote: > But when I show typical Haskell code to object-oriented friends of mine, > they get scared because it looks like math, with all the symbols and > short names. They will feel like a C programmer looking at C++ code, wondering how the heck an output stream can be left shifted by a number using << . :-) From bf3 at telenet.be Tue Feb 19 13:37:18 2008 From: bf3 at telenet.be (Peter Verswyvelen) Date: Tue Feb 19 13:35:42 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: References: <47B7E4E1.6040506@telenet.be> <20080217113318.GA2994@soi.city.ac.uk> <47B8376B.1010108@telenet.be> <200802191128.40946.g9ks157k@acme.softbase.org> <00e701c87311$21daba00$65902e00$@be> Message-ID: <47BB21DE.6040009@telenet.be> Exactly. And that must be one of the reasons the Java designers said "no" to operator overloading? That kind of programmers just don't like operators I guess. But we do :-) Although I would prefer nice math symbols and layout instead of the :~> ASCII art. Thielemann wrote: > On Tue, 19 Feb 2008, Peter Verswyvelen wrote: > > >> But when I show typical Haskell code to object-oriented friends of mine, >> they get scared because it looks like math, with all the symbols and >> short names. >> > > They will feel like a C programmer looking at C++ code, wondering how the > heck an output stream can be left shifted by a number using << . :-) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080219/1417ce72/attachment.htm From jgbailey at gmail.com Tue Feb 19 14:13:44 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Tue Feb 19 14:12:00 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: <00e701c87311$21daba00$65902e00$@be> References: <47B7E4E1.6040506@telenet.be> <20080217113318.GA2994@soi.city.ac.uk> <47B8376B.1010108@telenet.be> <200802191128.40946.g9ks157k@acme.softbase.org> <00e701c87311$21daba00$65902e00$@be> Message-ID: On Feb 19, 2008 8:04 AM, Peter Verswyvelen wrote: > Actually, if you look at the way OO programmers design code, they usually choose long descriptive names, like "FindElementByName". Most Haskell people seem more math oriented and use very short names, like "fst" and "snd" (which are a bit better than the old "car" and "cdr"). Now in the end, once you get used to a name, it doesn't matter does it? I also think this comes from better IDE support. When I'm coding in C#, I choose longer method, class, and property names because Visual Studio frees me from having to type the entire thing - Intellisense does most of the work. When I am coding in PHP or Haskell, with poor IDE support, I tend for shorter. I think a secondary influence comes from the need to typeset code in journals and books. Even if you don't actually publish your code, the people who have written the existing papers and tutorials did, and that influence the style you learn. Justin From jeff1.61803 at gmail.com Tue Feb 19 14:48:09 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Tue Feb 19 14:46:28 2008 Subject: [Haskell-cafe] Re: Selecting Array type In-Reply-To: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> Message-ID: <7665bf90802191148n5e19876co8a69bad102417f58@mail.gmail.com> I apologize if this has already been posted. I sent the following message several hours ago and I haven't seen it post. So, I'm resending. I'm trying to create a type called SmartArray. It is a type synonym for an array. If the element type can be unboxed, then SmartArray is an unboxed array. Otherwise, it is a boxed array. For instance, (SmartArray Int Double) is the same as (UArray Int Double) (SmartArray Int String) is the same as (Array Int String) However, my implementation of SmartArray requires me to create an instance of a selector class to tell the compiler whether the type is boxed or unboxed. I'm hoping to avoid creating instances of the selector class for every possible type. I'd be grateful for any suggestions. Please see my code: {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception -XOverlappingInstances #-} import Data.Ix import Data.Array.Unboxed import Data.Complex type SmartArray i e = (Ix i, SmartArraySelector a e) => (a i e) -- smartArray is similar to array function from Data.Array. But, it -- will return a UArray if e can be unboxed. Otherwise, it returns an Array. smartArray :: (i, i) -> [(i, e)] -> SmartArray i e smartArray bnd eLst = array bnd eLst class (IArray a e) => SmartArraySelector a e | e -> a where arrayType :: Ix i => a i e -> a i e arrayType = id -- SmartArraySelector selects UArray for all types that can be -- unboxed. An instance has to be created for each unboxed type. I'd -- like to avoid listing all unboxed types here. However, since there -- are only a few unboxed types, it's not too burdensome to list them -- all. (For brevity, I didn't create all possible instances.) instance SmartArraySelector UArray Bool where instance SmartArraySelector UArray Char where instance SmartArraySelector UArray Double where instance SmartArraySelector UArray Float where instance SmartArraySelector UArray Int where -- SmartArraySelector selects Array for all types that can't be -- unboxed. An instance has to be created for EVERY possible unboxed -- type that might be used with SmartArray. Since, the list of -- possible types is unlimited, this is pretty annoying. instance SmartArraySelector Array String where instance SmartArraySelector Array (Complex e) where -- I'd like to replace all the boxed instances above with one instance -- like . . . -- -- instance SmartArraySelector Array e where -- -- However, this generates an error even though, -- -XOverlappingInstances turned on. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080219/041b0a32/attachment.htm From alfonso.acosta at gmail.com Tue Feb 19 15:44:46 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Feb 19 15:43:03 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802141040.25292.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <47B3A60B.2020809@imageworks.com> <200802141040.25292.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802191244s58587137o83d0b4b019f46c84@mail.gmail.com> On Feb 14, 2008 10:40 AM, Wolfgang Jeltsch wrote: > So we should "parameterized" for the package name. That's the packagename I've been using. I'm done with a basic implementation but I'd like to test some other things before showing the code. On the other hand, I think that the type-level library is almost ready for it's initial release. Before uploading it to Hackage and making an announcement I would be pleased to receive some comments/suggestions. Here is the darcs repository: http://code.haskell.org/type-level/ Here is the haddock-generated documentation: http://code.haskell.org/~fons/type-level/doc/ There are still some things missing which would be cool to have: * Native support of representations in different bases (I don't know if it's feasible) * Support of negative integers (Bj?rn?) * Support of type-level Booleans (Wolfgang?) From joseph.bruce at pnl.gov Tue Feb 19 15:59:00 2008 From: joseph.bruce at pnl.gov (Bruce, Joseph R (Joe)) Date: Tue Feb 19 15:57:29 2008 Subject: [Haskell-cafe] Exporting Haskell Libraries to C Programmers Message-ID: Hi, I have a Haskell library that I want to make available via FFI to C programmers on my project team. I read this thread (http://thread.gmane.org/gmane.comp.lang.haskell.cafe/21447) which had some interesting ideas, but they seemed unresolved. Or maybe it answers my question but I don't understand it. Is there a way I can package (ghc-)compiled Haskell code into a statically-linked library and not force the C programmers to include headers and libraries that they have no knowledge of and undefine a seemingly endless list of preprocessor symbols (run ghc with the verbose flag and look at the calls to gcc)? Can this process be automated? Thanks, Joe From g9ks157k at acme.softbase.org Tue Feb 19 16:15:57 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 16:14:55 2008 Subject: [Haskell-cafe] Where does ~> come from? In-Reply-To: <6BD267D89E66B9499514F119920E583C0220E86F@usctmx1110.merck.com> References: <200802191122.23121.g9ks157k@acme.softbase.org> <6BD267D89E66B9499514F119920E583C0220E86F@usctmx1110.merck.com> Message-ID: <200802192215.57372.g9ks157k@acme.softbase.org> Am Dienstag, 19. Februar 2008 18:26 schrieben Sie: > [?] > However, I was told this: ~> a b is a ~> b, but if I write c a b and > wish the effect of a `c` b. This would not work. ~> as an infix operator > has a special place in GHC. It is not "just a type variable". Sorry, but I don?t understand fully what you mean. :-( But nevertheless, a ~> b is not the same as ~> a b but as (~>) a b. It?s just like with ordinary operators where a + b is the same as (+) a b. ~> is not special in GHC. You could use, for example, ### instead of ~> and get the same results. However, GHC accepts type operators only if you tell it to do so. Give GHC the option -XTypeOperators or insert {-# LANGUAGE TypeOperators #-} at the beginning of your source file. > [?] Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 19 16:23:46 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 16:22:37 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: <00e701c87311$21daba00$65902e00$@be> References: <47B7E4E1.6040506@telenet.be> <200802191128.40946.g9ks157k@acme.softbase.org> <00e701c87311$21daba00$65902e00$@be> Message-ID: <200802192223.47061.g9ks157k@acme.softbase.org> Am Dienstag, 19. Februar 2008 17:04 schrieben Sie: > PS: Wolfgang also seems to use nice names in Grapefruit for his types, e.g. > > act :: PlainCircuit (IO output) output >?createPlainCircuit?::?PlainCircuit?input?output?->?input?->?IO?(output,IO?()) > > instead of > > act :: PlainCircuit (IO a) a > mkPlainCircuit :: PlainCircuit a b -> a -> IO (b, IO ()) Whereby I have to add that I use create now instead of createPlainCircuit since in case of ambiguity you can use qualification like in PlainCircuit.create. I think, this is nicer because PlainCircuit.create is ?more structured? than createPlainCircuit where everything is put into a single parameter. I?m also in the process of shortening the names for type variables since in conference papers you cannot use names that long (because otherwise you quickly overrun the available width) and I don?t want to have too many differences between papers and actual source code. However, I still don?t like single-letter names like a and b. > [?] Best wishes, Wolfgang From duncan.coutts at worc.ox.ac.uk Tue Feb 19 16:13:47 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 19 16:25:18 2008 Subject: [Haskell-cafe] Re: Haskell maximum stack depth In-Reply-To: <47BAC9F3.5070200@iee.org> References: <479F7BC9.9030406@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318325D6F0F@EA-EXMSG-C334.europe.corp.microsoft.com> <47A74AC8.7030000@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326872AF@EA-EXMSG-C334.europe.corp.microsoft.com> <47A7661D.7090603@iee.org> <638ABD0A29C8884A91BC5FB5C349B1C318326873FC@EA-EXMSG-C334.europe.corp.microsoft.com> <47A83151.7020707@iee.org> <7ca3f0160802050607j479ecd5egbea5cd5d2d5dec2d@mail.gmail.com> <47A8B004.6000001@iee.org> <404396ef0802051105j5f3de4a4jbe9425be90737eb2@mail.gmail.com> <47A96DC2.9030805@iee.org> <47B45ED9.3050302@microsoft.com> <47BAC9F3.5070200@iee.org> Message-ID: <1203455627.2102.65.camel@localhost> On Tue, 2008-02-19 at 12:22 +0000, Adrian Hey wrote: > To be honest, in all my years of Haskelling I can't think of a single > occasion where I've had a program get stuck in an infinite loop. I've > had plenty of stack overflows, and they're reported on the mailing > lists pretty regularly, but on all such occasions it's been caused > by deep but very definitely finite recursion. It's really pretty easy. I've occasionally done it by accident, it just requires changing names about in a let that was not recursive and suddenly it is recursive in a way that was not intended. Duncan From g9ks157k at acme.softbase.org Tue Feb 19 16:27:50 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 16:26:29 2008 Subject: [Haskell-cafe] Arrows: definition of pure & arr In-Reply-To: <47BB21DE.6040009@telenet.be> References: <47B7E4E1.6040506@telenet.be> <47BB21DE.6040009@telenet.be> Message-ID: <200802192227.50328.g9ks157k@acme.softbase.org> Am Dienstag, 19. Februar 2008 19:37 schrieb Peter Verswyvelen: > Exactly. And that must be one of the reasons the Java designers said > "no" to operator overloading? That kind of programmers just don't like > operators I guess. But we do :-) Although I would prefer nice math > symbols and layout instead of the :~> ASCII art. lhs2TeX at least gives you nice math symbols when typesetting source code. Do you know this tool already? It?s brilliant, IMO. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 19 16:52:30 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 16:51:10 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802191244s58587137o83d0b4b019f46c84@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802141040.25292.g9ks157k@acme.softbase.org> <6a7c66fc0802191244s58587137o83d0b4b019f46c84@mail.gmail.com> Message-ID: <200802192252.30233.g9ks157k@acme.softbase.org> Am Dienstag, 19. Februar 2008 21:44 schrieben Sie: > * Support of type-level Booleans (Wolfgang?) Attached is just a quickly hacked Boolean module. Nothing very special. I?d be happy if you could prettify this (choose better names, add documentation, etc.). Thanks for any effort. Best wishes, Wolfgang -------------- next part -------------- A non-text attachment was scrubbed... Name: Boolean.hs Type: text/x-java Size: 3349 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20080219/ab2e9eb0/Boolean.bin From alfonso.acosta at gmail.com Tue Feb 19 18:39:43 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Feb 19 18:37:58 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802192252.30233.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802141040.25292.g9ks157k@acme.softbase.org> <6a7c66fc0802191244s58587137o83d0b4b019f46c84@mail.gmail.com> <200802192252.30233.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802191539v2f2c8c3dhbd79dddb9da4f910@mail.gmail.com> 2008/2/19 Wolfgang Jeltsch : > Attached is just a quickly hacked Boolean module. Nothing very special. I'd > be happy if you could prettify this (choose better names, add documentation, > etc.). Thanks for any effort. Thanks to you for the module. I have a few questions though. Why are the value-level reflecting functionsimplemented as type-class methods? It makes the code more verbose and I don't see any advantage compared to simply defining a function per class. Let me show you an example: This is your implementation of Not: class (Boolean boolean, Boolean boolean') => Not boolean boolean' | boolean -> boolean', boolean' -> boolean where not :: boolean -> boolean' instance Not False True where not _ = true instance Not True False where not _ = false This is how I would do it: class (Boolean boolean, Boolean boolean') => Not boolean boolean' | boolean -> boolean', boolean' -> boolean where instance Not False True instance Not True False not :: Not a b => a -> b not = undefined Furthermore, why did you choose to use Boolean instead of simply Bool? Cheers, Fons From g9ks157k at acme.softbase.org Tue Feb 19 20:26:41 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 19 20:25:20 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802191539v2f2c8c3dhbd79dddb9da4f910@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802192252.30233.g9ks157k@acme.softbase.org> <6a7c66fc0802191539v2f2c8c3dhbd79dddb9da4f910@mail.gmail.com> Message-ID: <200802200226.41438.g9ks157k@acme.softbase.org> Am Mittwoch, 20. Februar 2008 00:39 schrieben Sie: > Why are the value-level reflecting functionsimplemented as type-class > methods? It makes the code more verbose and I don't see any advantage > compared to simply defining a function per class. Let me show you an > example: > > This is your implementation of Not: > > class (Boolean boolean, Boolean boolean') => > Not boolean boolean' | boolean -> boolean', boolean' -> boolean > where not :: boolean -> boolean' > > instance Not False True where > not _ = true > > instance Not True False where > not _ = false > > This is how I would do it: > > class (Boolean boolean, Boolean boolean') => > Not boolean boolean' | boolean -> boolean', boolean' -> boolean > where > > instance Not False True > instance Not True False > > not :: Not a b => a -> b > not = undefined Your definition of the not function uses the implementation detail that false and true are actually undefined. My implementation of the not function also works if false and true are defined to be something different. Of course, false and true are in the same library, so we know this implementation detail and could make use of it. > Furthermore, why did you choose to use Boolean instead of simply Bool? To avoid a name clash. Feel free to change this. Note that False and True don?t cause a name clash since they live in a namespace different from the one Prelude?s False and True live in. > Cheers, > > Fons Best wishes, Wolfgang From dave at zednenem.com Wed Feb 20 00:34:24 2008 From: dave at zednenem.com (David Menendez) Date: Wed Feb 20 00:32:39 2008 Subject: [Haskell-cafe] Where does ~> come from? In-Reply-To: <200802192215.57372.g9ks157k@acme.softbase.org> References: <200802191122.23121.g9ks157k@acme.softbase.org> <6BD267D89E66B9499514F119920E583C0220E86F@usctmx1110.merck.com> <200802192215.57372.g9ks157k@acme.softbase.org> Message-ID: <49a77b7a0802192134p8f26225v559e8110f7d223f2@mail.gmail.com> On Feb 19, 2008 4:15 PM, Wolfgang Jeltsch wrote: > Am Dienstag, 19. Februar 2008 18:26 schrieben Sie: > > [?] > > > However, I was told this: ~> a b is a ~> b, but if I write c a b and > > wish the effect of a `c` b. This would not work. ~> as an infix operator > > has a special place in GHC. It is not "just a type variable". > > Sorry, but I don't understand fully what you mean. :-( But nevertheless, > a ~> b is not the same as ~> a b but as (~>) a b. It's just like with > ordinary operators where a + b is the same as (+) a b. Note that some (all?) versions of GHC will incorrectly print "a ~> b" as "~> a b". Prelude> :t undefined :: a + b undefined :: a + b :: forall (+ :: * -> * -> *) a b. + a b It mostly gets infix type constructors right, although there are apparently problems with precedence and associativity. -- Dave Menendez From alfonso.acosta at gmail.com Wed Feb 20 03:20:19 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Feb 20 03:18:34 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802200226.41438.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802192252.30233.g9ks157k@acme.softbase.org> <6a7c66fc0802191539v2f2c8c3dhbd79dddb9da4f910@mail.gmail.com> <200802200226.41438.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802200020pf1aebb1vbafafdcd8ebf7ada@mail.gmail.com> OK I'll include the module after I change the things mentioned. BTW, I finally have an initial version of the parameterized-data package: Darcs repository: http://code.haskell.org/parameterized-data Haddock documentation: http://code.haskell.org/~fons/parameterized-data/doc/ Any comments/suggestions would be appreciated. To fix the problem of the "vector" constructor I included a Template Haskell variant. It is quite simple to use: $ ghci -XTemplateHaskell Prelude> :m +Data.Param Prelude Data.Param> $(vectorTH [1 :: Int, 2, 3, 4]) Prelude Data.Param> :t $(vectorTH [1 :: Int, 2, 3, 4]) (vectorTH [1 :: Int, 2, 3, 4]) :: (Num t) => FSVec Data.TypeLevel.Num.Reps.D4 t Note that the size parameter (type-level decimal numeral) is correct. It would be nice to be able to use a Quasiquoter [1] (available in GHC HEAD) to enable pattern matching and custom syntax to Vector literals. However, I was bitten by a polymorphism problem when implementing it: see [2] for details [1] http://www.haskell.org/ghc/dist/current/docs/users_guide/template-haskell.html#th-quasiquotation [2] http://www.haskell.org/pipermail/template-haskell/2008-February/000655.html On Wed, Feb 20, 2008 at 2:26 AM, Wolfgang Jeltsch wrote: > Am Mittwoch, 20. Februar 2008 00:39 schrieben Sie: > > > Why are the value-level reflecting functionsimplemented as type-class > > methods? It makes the code more verbose and I don't see any advantage > > compared to simply defining a function per class. Let me show you an > > example: > > > > This is your implementation of Not: > > > > class (Boolean boolean, Boolean boolean') => > > Not boolean boolean' | boolean -> boolean', boolean' -> boolean > > where not :: boolean -> boolean' > > > > instance Not False True where > > not _ = true > > > > instance Not True False where > > not _ = false > > > > This is how I would do it: > > > > class (Boolean boolean, Boolean boolean') => > > Not boolean boolean' | boolean -> boolean', boolean' -> boolean > > where > > > > instance Not False True > > instance Not True False > > > > not :: Not a b => a -> b > > not = undefined > > Your definition of the not function uses the implementation detail that false > and true are actually undefined. My implementation of the not function also > works if false and true are defined to be something different. Of course, > false and true are in the same library, so we know this implementation detail > and could make use of it. > > > > Furthermore, why did you choose to use Boolean instead of simply Bool? > > To avoid a name clash. Feel free to change this. > > Note that False and True don't cause a name clash since they live in a > namespace different from the one Prelude's False and True live in. > > > Cheers, > > > > Fons > > > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From cgibbard at gmail.com Wed Feb 20 04:58:08 2008 From: cgibbard at gmail.com (Cale Gibbard) Date: Wed Feb 20 04:56:22 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> Message-ID: <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> (I'm copying the list on this, since my reply contains a tutorial which might be of use to other beginners.) On 19/02/2008, Alan Carter wrote: > Hi Cale, > > On Feb 19, 2008 3:48 PM, Cale Gibbard wrote: > > Just checking up, since you haven't replied on the list. Was my > > information useful? Did I miss any questions you might have had? If > > you'd like, I posted some examples of using catch here: > > Thanks for your enquiry! My experiment continues. I did put a progress > report on the list - your examples together with a similar long an > short pair got me over the file opening problem, and taught me some > things about active whitespace :-) I couldn't get withFile working > (says out of scope, maybe 'cos I'm ghc 6.6 on my Mac) Make sure to put: import System.IO at the top of your source file, if you haven't been. This should import everything documented here: http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html > but it turned out the line I was looking for (collapsed from the examples) > was: > > text <- readFile "data.txt" `catch` \_ -> return "" > > This ensures the program never loses control, crashing or becoming > unpredictable by attempting to use an invalid resource, by yielding an > empty String if for any reason the file read fails. Then an empty > String makes it very quickly through parsing. I guess that's quite > "functiony" :-) > > Amazing how easy once I knew how. Even stranger that I couldn't find a > "bread and butter" example of it. > > Then I was going very quickly for a while. My file is dumped from a > WordPress MySql table. Well formed lines have 4 tab separated fields > (I'm using pipes for tabs here): > > line id | record id | property | value > > Line IDs are unique and don't matter. All lines with the same record > ID give a value to a property in the same record, similar to this: > > 1|1|name|arthur > 2|1|quest|seek holy grail > 3|1|colour|blue > 4|2|name|robin > 5|2|quest|run away > 6|2|colour|yellow > > Organizing that was a joy. It took minutes: let cutUp = tail (filter (\fields -> (length fields) == 4) (map (\x -> split x '\t') (lines text))) This should almost certainly be a function of text: cutUp text = tail (filter (\fields -> (length fields) == 4) (map (\x -> split x '\t') (lines text))) > I found a split on someone's blog (looking for a library tokenizer), > but I can understand it just fine. I even get to chuck out ill-formed > lines and remove the very first (which contains MySql column names) on > the way through! Sadly, there's no general library function for doing this. We have words and lines (and words would work here, if your fields never have spaces), but nobody's bothered to put anything more general for simple splitting into the base libraries (though I'm sure there's plenty on hackage -- MissingH has a Data.String.Utils module which contains split and a bunch of others, for example). However, for anything more complicated, there are also libraries like Parsec, which are generally really effective, so I highly recommend looking at that at some point. > I then made a record to put things in, and wrote some lines to play > with it (these are the real property names): > > data Entry = Entry > { occupation :: String > , iEnjoyMyJob :: Int > , myJobIsWellDefined :: Int > , myCoworkersAreCooperative :: Int > , myWorkplaceIsStressful :: Int > , myJobIsStressful :: Int > , moraleIsGoodWhereIWork :: Int > , iGetFrustratedAtWork :: Int > } > ... > let e = Entry{occupation = "", iEnjoyMyJob = 0} > let f = e {occupation = "alan"} > let g = f {iEnjoyMyJob = 47} > putStrLn ((occupation g) ++ " " ++ (show (iEnjoyMyJob g))) > > Then I ran into another quagmire. I think I have to use Data.Map to > build a collection of records keyed by record id, and fill them in by > working through the list of 4 item lists called cutUp. As with the > file opening problem I can find a few examples that convert a list of > tuples to a Data.Map, one to one. I found a very complex example that > convinced me a map from Int to a record is possible, but gave me no > understanding of how to do it. I spent a while trying to use foldl > before I decided it can't be appropriate (I need to pass more values). > So I tried a couple of recursive functions, something like: > > type Entries = M.Map Int Entry > ... > let entries = loadEntries cutUp > ... > loadEntries :: [[String]] -> Entries > loadEntries [] = M.empty Entries > loadEntries [x : xs] = loadEntry (loadEntries xs) x -- Possible common beginner error here: [x:xs] means the list with one element which is a list whose first element is x and whose tail is xs. Your type signature and the type of cutUp seems to confirm that this is the right type, but you don't seem to have a case to handle a longer list of lists. If you want just a list with first entry x, and with tail xs, that's just (x:xs). If you want to handle lists of lists recursively, you'll generally need two cases: ([]:xss) and ((x:xs):xss). We'll end up doing something different instead of recursion in a moment. > > loadEntry entries _ rid fld val = entries > > Trying to create an empty map at the bottom of the recursion so later > I can try to fiddle about checking if the key is present and crating a > new record otherwise, then updating the record with a changed one (a > big case would be needed deep in to do each property update). If I'm > on the right track it's not good enough to get better, so now I'm just > throwing bits of forest animals into the pot at random again :-( > > So I certainly would be grateful for a clue! The bits I can do (I got > a non-trivial wxHaskell frame sorted out quite easily, the tokenizing > and record bit were OK) I think show I'm not *totally* stupid at this, > I'm putting loads of time investment in (it's an experiement in > itself) but there do seem to be certain specific things that would be > ubiquitous patterns in any production or scripting environment, which > are not discussed at all and far from obvious. The more I see of > Haskell the more I suspect this issue is the gating one for popular > uptake. > > I couldn't help thinking of this bit, from the Wikipedia entry on the > Cocteau Twins: > > "The band's seventh LP, Four-Calendar Caf?, was released in late 1993. > It was a departure from the heavily-processed, complex and layered > sounds of Blue Bell Knoll and Heaven or Las Vegas, featuring clearer > and more minimalistic arrangements. This, along with the record's > unusually comprehensible lyrics, led to mixed reviews for the album: > Some critics accused the group of selling out and producing an > 'accessible album,' while others praised the new direction as a > felicitous development worthy of comparison with Heaven or Las Vegas." > > Best wishes, > > Alan I woke up rather early, and haven't much to do, so I'll turn this into a tutorial. :) Okay. The most common ways to build a map are by using the fromList, fromListWith, or fromListWithKey functions. You can see them in the documentation here: http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.html#v%3AfromList The types are: fromList :: (Ord k) => [(k,a)] -> Map k a fromListWith :: (Ord k) => (a -> a -> a) -> [(k,a)] -> Map k a fromListWithKey :: (Ord k) => (k -> a -> a -> a) -> [(k,a)] -> Map k a They take a list of (key,value) pairs, and build a map from it. Additionally, the fromListWith function takes a function which specifies how the values should be combined if their keys collide. There is also a fromListWithKey function which allows the means of combination to depend on the key as well. At this point we realise something interesting about the way the data is being represented: if there is a field in someone's record with no row in the database, what should the resulting field contain? In C, they often use some integer which is out of range, like -1 for this. How about for a missing occupation field? Well, that's a String, you could use some generic failure string, or an empty string, but I'll show you another possibility that just might be convenient. If t is any type, then the type (Maybe t) consists of the values Nothing, and Just x, whenever x is a value of type t. This is another convenient way to represent the idea that a computation might fail. Let's start by changing your record type so that each field is a Maybe value, that is, either the value Nothing, or the value Just x, where x is the value it would have been. data Entry = Entry { occupation :: Maybe String , iEnjoyMyJob :: Maybe Int , myJobIsWellDefined :: Maybe Int , myCoworkersAreCooperative :: Maybe Int , myWorkplaceIsStressful :: Maybe Int , myJobIsStressful :: Maybe Int , moraleIsGoodWhereIWork :: Maybe Int , iGetFrustratedAtWork :: Maybe Int } There's a very general function in the module Control.Monad which I'd like to use just for the Maybe type here. It's called mplus, and for Maybe, it works like this: mplus (Just x) _ = Just x mplus Nothing y = y So if the first parameter isn't Nothing, that's what you get, otherwise, you get the second parameter. Of course, this operation has an identity element which is Nothing. So this lets you combine partial information expressed by Maybe types, in a left-biased way. It's about to become obvious that record types are less convenient than perhaps they could be in Haskell, and this is absolutely true -- I'd actually probably use a somewhat different representation myself (possibly something involving a Map from Strings (field names) to Int values), but I can't really be sure what you intend with this data, and how much type safety you want. I'll elide the field names just because I can here. It's not necessarily good style. combine :: Entry -> Entry -> Entry combine (Entry a1 a2 a3 a4 a5 a6 a7 a8) (Entry b1 b2 b3 b4 b5 b6 b7 b8) = Entry (a1 `mplus` b1) (a2 `mplus` b2) (a3 `mplus` b3) (a4 `mplus` b4) (a5 `mplus` b5) (a6 `mplus` b6) (a7 `mplus` b7) (a8 `mplus` b8) Even with all the shorthand, this is pretty ugly (and I'll show how I'd represent the data in a moment), but what this does is to combine two partial entries, favouring the information in the first, but filling the holes in the first with data from the second. This operation has an identity element, which is: emptyEntry = Entry Nothing Nothing Nothing Nothing Nothing Nothing Nothing Nothing Let's try a different representation, which is a little more flexible, but expresses less in the type system. data Entry = Entry { occupation :: Maybe String, survey :: M.Map String Int } deriving (Eq, Ord, Show) So now, instead of a bunch of separate Maybe Int fields, we have just one Map from String to Int. If we don't have information for a field, we simply won't have that key in the Map. Of course, this means we'll have to use strings for field labels. If that seems unhappy, you could always define a type like: data SurveyQuestion = IEnjoyMyJob | MyJobIsWellDefined | MyCoworkersAreCooperative | MyWorkplaceIsStressful | MyJobIsStressful | MoraleIsGoodWhereIWork | IGetFrustratedAtWork deriving (Eq, Ord, Show) to be used in place of the String type. Let's see how combine will look now: combine :: Entry -> Entry -> Entry combine (Entry o1 s1) (Entry o2 s2) = Entry (o1 `mplus` o2) (s1 `M.union` s2) Or, using the record syntax more: combine :: Entry -> Entry -> Entry combine e1 e2 = Entry { occupation = (occupation e1 `mplus` occupation e2), survey = (survey e1 `M.union` survey e2) } Again, this new version has an identity with respect to combine, which is: emptyEntry = Entry {occupation = Nothing, survey = (M.empty)} Now, we just need a way to take one of your rows, and turn it into a (key,value) pair, where the value is a partial entry. readRow :: [String] -> (Int, Entry) readRow [n, k, "occupation", v] = (read k, emptyEntry { occupation = Just v }) readRow [n, k, f, v] = (read k, emptyEntry { survey = M.singleton f (read v) }) readRow xs = error "failure case, should never happen!" There is actually a failure case that I'm not handling here, which is what happens when the value or key fails to parse as an Int. For that we'd use reads instead of read, but let's ignore it for now. We can then map this function over our cut up rows, something along the lines of: map readRow (cutUp text) at which point we'll have a list of (Int, Entry) pairs. We then want to fill up our Entries Map with those, and we want to combine them as we go using the combine function: entryMap text = M.fromListWith combine (map readRow (cutUp text)) Some final changes we could consider would be putting more of the error handling into readRow itself: if it was to return a singleton Map rather than an (Int, Entry) pair, then it could return the empty Map on failure, and the results would then be combined using the function M.unionsWith combine. We could move the length 4 test out of cutUp then, and just make it the fall-through case in readRow. I'll also use reads, which returns a list of (parse,rest-of-string) pairs, to handle the failure cases where the numbers don't parse, by just treating those rows as nonexistent: readRow :: [String] -> M.Map Int Entry readRow [n, k, f, v] = case reads k of [] -> M.empty -- the key didn't parse (k',_):_ -> if f == "occupation" then M.singleton k' (emptyEntry { occupation = Just v }) else case reads v of [] -> M.empty -- the value didn't parse (v',_):_ -> M.singleton k' (emptyEntry { survey = M.singleton f v' }) readRow xs = M.empty -- this handles the case when the list is any length but 4 cutUp text = tail (map (\x -> split x '\t') (lines text)) -- which allows cutUp to be simpler entryMap text = M.unionsWith combine (map readRow (cutUp text)) Anyway, I hope this tutorial gives some idea of how things progress, and what sort of thinking is generally involved. Note that the focus here was more on finding the right combining operations, and then using pre-existing higher-order functions to collapse the structure, than it was on recursion. Indeed, the final program there doesn't contain any explicit recursion at all! This is generally something to aim for. Using explicit recursion is generally a means of last resort. Higher order functions on data structures are our control structures. - Cale From g9ks157k at acme.softbase.org Wed Feb 20 05:26:17 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Feb 20 05:25:19 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <6a7c66fc0802200020pf1aebb1vbafafdcd8ebf7ada@mail.gmail.com> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802200226.41438.g9ks157k@acme.softbase.org> <6a7c66fc0802200020pf1aebb1vbafafdcd8ebf7ada@mail.gmail.com> Message-ID: <200802201126.17982.g9ks157k@acme.softbase.org> Am Mittwoch, 20. Februar 2008 09:20 schrieben Sie: > OK I'll include the module after I change the things mentioned. > > BTW, I finally have an initial version of the parameterized-data package: > > Darcs repository: > > http://code.haskell.org/parameterized-data > > Haddock documentation: > > http://code.haskell.org/~fons/parameterized-data/doc/ > > Any comments/suggestions would be appreciated. Hello Fons, why do you use the term vector? I?d say that this term is more or less wrong for what this type is about. The distinguishing property of vectors compared to lists is that there is addition and scalar multiplication for vectors. Being a list of fixed size is not so important for vectors, in fact, it?s completely unnecessary. Real numbers are vectors, functions from real numbers to real numbers are vectors, matrixes are vectors?you just have to provide them with proper addition and scalar multiplication. The data type you defined is a fixed size list. > [?] Best wishes, Wolfgang From jgoerzen at complete.org Wed Feb 20 09:39:13 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Feb 20 10:01:21 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types Message-ID: Hi folks, Before I started using Haskell, I used OCaml for a spell. One of my biggest annoyances with OCaml was that it had two list types: the default list (strict), and a lazy list (known as a stream). This led to all sorts of annoyances. Libraries were always written to work with one list or the other. If you wanted to use two libraries, one that assumed one list and the other that assumed another, you had a difficult task ahead of you. I am concerned that the same thing is happening in Haskell. We know have three common list-like types: the regular list, strict ByteString, and lazy ByteString. This has created some annoying situations. For instance, a ByteString is great for reading data fast, but Parsec doesn't work on ByteStrings. I am glad that someone wrote a Parsec equivolent that does[1], which answers a real need. But this means that all the combinators in the hsemail library that implement standard RFC conventions won't be usable in my ByteString code, for instance. Similarly, we have another annoying situation relating to character encodings: * The iconv library works only on lazy ByteStrings, and does not handle Strings or strict ByteStrings * The utf8-string library doesn't support UTF-16, doesn't require an external library, and works only on Strings -- no support for ByteStrings. * Data.Encoding.* is native haskell, supports UTF-*, but works only on ByteSting.Lazy again. Now, to help solve this problem, I wrote ListLike[2], providing a set of typeclasses that make list operations generic. I also provided default instances of ListLike for: ListLike Data.ByteString.ByteString Word8 ListLike Data.ByteString.Lazy.ByteString Word8 ListLike [a] a (Integral i, Ix i) => ListLike (Array i e) e (Ord key, Eq val) => ListLike (Map key val) (key, val) These instances use the native underlying calls where appropriate (for instance, ByteString and Data.List both provide a 'head'). The typeclass also contains large numbers of default implementations, such that only four functions must be implemented to make a type a member of ListLike. API ref is at http://software.complete.org/listlike/static/doc/ListLike/Data-ListLike.html#intro Now, the questions: 1) Does everyone agree with me that we have a problem here? 2) Would it make sense to make ListLike, or something like it, part of the Haskell core? 3) Would it make sense to base as much code as possible in the Haskell core areound ListLike definitions? Here I think of functions such as lines and words, which make sense both on [Char] as well as ByteStrings. 4) We are missing one final useful type: a Word32-based ByteString. When working in the Unicode character set, a 32-bit character can indeed be useful, and I could see situations in which the performance benefit of a ByteString-like implementation could be useful combared to [Char]. [1] Yes, I have read about Parsec 3 being imminent, which is also great [2] http://software.complete.org/listlike From lemming at henning-thielemann.de Wed Feb 20 10:17:55 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 20 10:15:25 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: Message-ID: > Now, to help solve this problem, I wrote ListLike[2], providing a > set of typeclasses that make list operations generic. I also provided > default instances of ListLike for: > > ListLike Data.ByteString.ByteString Word8 > ListLike Data.ByteString.Lazy.ByteString Word8 > ListLike [a] a > (Integral i, Ix i) => ListLike (Array i e) e > (Ord key, Eq val) => ListLike (Map key val) (key, val) It's a multi-parameter type class, right? So it's difficult to push it to the core. > Now, the questions: > > 1) Does everyone agree with me that we have a problem here? I agree. > 2) Would it make sense to make ListLike, or something like it, > part of the Haskell core? Somehow yes. However since the 'base' package is constantly split into smaller parts, there is maybe no need to merge it somewhere, but introduce simply new package dependencies. > 3) Would it make sense to base as much code as possible in the Haskell > core areound ListLike definitions? Here I think of functions such > as lines and words, which make sense both on [Char] as well as > ByteStrings. > > 4) We are missing one final useful type: a Word32-based ByteString. > When working in the Unicode character set, a 32-bit character > can indeed be useful, and I could see situations in which the > performance benefit of a ByteString-like implementation could > be useful combared to [Char]. StorableVector should fill this gap. http://code.haskell.org/~sjanssen/storablevector/ From ross at soi.city.ac.uk Wed Feb 20 10:44:37 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Feb 20 10:42:55 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: Message-ID: <20080220154437.GA22454@soi.city.ac.uk> On Wed, Feb 20, 2008 at 08:39:13AM -0600, John Goerzen wrote: > I am concerned that the same thing is happening in Haskell. We now > have three common list-like types: the regular list, strict > ByteString, and lazy ByteString. > > This has created some annoying situations. For instance, a ByteString > is great for reading data fast, but Parsec doesn't work on > ByteStrings. I am glad that someone wrote a Parsec equivalent that > does[1], which answers a real need. But this means that all the > combinators in the hsemail library that implement standard RFC > conventions won't be usable in my ByteString code, for instance. > [...] > http://software.complete.org/listlike/static/doc/ListLike/Data-ListLike.html As Henning pointed out, multiple parameter type classes are problematic for core libraries at present. An alternative might be explicit dictionaries. For example, a partial solution would be to provide coinductive views, i.e. for all these types to provide functions of a type like full -> Maybe (item, full) (Data.Map, Data.Set and Data.Sequence would each have two such functions), and to have a library of generalized functions taking such functions as parameters, like splitAt :: (full -> Maybe (item, full)) -> Int -> full -> ([item], full) Parsing libraries could include a similar parameter within their monad. That only covers the elimination side, of course. From byorgey at gmail.com Wed Feb 20 10:49:53 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Wed Feb 20 10:48:07 2008 Subject: [Haskell-cafe] Selecting Array type In-Reply-To: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> Message-ID: <22fcbd520802200749x5e3976ecyc29528faaaf0df44@mail.gmail.com> 2008/2/19 Jeff ? : > > instance SmartArraySelector UArray Bool where > instance SmartArraySelector UArray Char where > instance SmartArraySelector UArray Double where > instance SmartArraySelector UArray Float where > instance SmartArraySelector UArray Int where > Well, I'm not sure of the answer to your question, so I'll just make a frivolous observation instead: I think you can leave off the "where" on instances without any method definitions. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080220/0ea05483/attachment.htm From pasalic at cs.rice.edu Wed Feb 20 10:52:45 2008 From: pasalic at cs.rice.edu (Emir Pasalic) Date: Wed Feb 20 10:50:59 2008 Subject: [Haskell-cafe] First Call for Papers -- GPCE'08 Message-ID: <2E98E75B-6FFC-4670-BE4D-6038AC50621B@cs.rice.edu> Call for Papers Seventh International Conference on Generative Programming and Component Engineering (GPCE 2008) October 19-23, 2008 Nashville, Tennessee (co-located with OOPSLA 2008) http://www.gpce.org Important Dates: * Submission of abstracts: May 12, 2008 * Submission: May 19, 2008 * Notification: June 30, 2008 * Tutorial and workshop proposals: March 30, 2008 * Tutorial and workshop notification: April 5, 2008 Scope Generative and component approaches are revolutionizing software development similar to how automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (DSLs) (elevating program specifications to compact domain-specific notations that are easier to write, maintain, and analyze) are key technologies for automating program development. The International Conference on Generative Programming and Component Engineering provides a venue for researchers and practitioners interested in techniques for enhancing the productivity, quality, and time-to-market in software development that stems from deploying components and automating program generation. In addition to exploring cutting-edge techniques for developing generative and component-based software, our goal is to foster further cross-fertilization between the software engineering research community and the programming languages community. Submissions Research papers: 10 pages in SIGPLAN proceedings style (sigplanconf.cls) reporting original research results that contribute to scientific knowledge in the areas listed below (the PC chair can advise on appropriateness). Experience reports: 2 to 4 pages in length in SIGPLAN proceedings style (sigplanconf.cls). We encourage experience reports that provide concrete evidence with regards to the efficacy of generative technologies in industrial applications. Topics GPCE seeks contributions in software engineering and in programming languages related (but not limited) to: * Generative programming o Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, step-wise refinement, and generic programming o Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, and program transformation o Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, and reflection * Generative techniques for o Product-line architectures o Distributed, real-time and embedded systems o Model-driven development and architecture o Resource bounded/safety critical systems. * Component-based software engineering o Reuse, distributed platforms and middleware, distributed systems, evolution, patterns, development methods, deployment and configuration techniques, and formal methods * Integration of generative and component-based approaches * Domain engineering and domain analysis o Domain-specific languages including visual and UML-based DSLs * Separation of concerns o Aspect-oriented and feature-oriented programming, o Intentional programming and multi-dimensional separation of concerns * Industrial applications of the above Experience reports on applications of these techniques to real-world problems are especially encouraged, as are research papers that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. The program chair is happy to advise on the appropriateness of a particular subject. Submissions must adhere to SIGPLAN's republication policy. Please contact the program chair if you have any questions about how this policy applies to your paper (gpce2008 at gpce.org). Organizers General Chair: Yannis Smaragdakis (University of Oregon) Program Chair: Jeremy Siek (University of Colorado at Boulder) Satellite Chair: Ralf Lammel (Univ. Koblenz-Landau) Publicity Chair: Emir Pasalic (LogicBlox, Inc.) Program Committee David Abrahams (Boost Consulting) Uwe Assmann (Technische Universitat, Dresden) Ira Baxter (Semantic Designs, USA) Martin Bravenboer (Delft Univ. of Tech., The Netherlands) Jacques Carette (McMaster University, Canada) Shigeru Chiba (Tokyo Institute of Technology, Japan) William R. Cook (University of Texas at Austin, USA) Lidia Fuentes (University of Malaga, Spain) Yossi Gil (The Technion, Israel) Aniruddha Gokhale (Vanderbilt University, USA) Mark Grechanik (Accenture Technology Labs, USA) Stanislaw Jarzabek (National University of Singapore) Jaakko Jarvi (Texas A&M Unviersity, USA) Julie Lawall (DIKU, University of Copenhagen, Denmark) Christian Lengauer (University of Passau, Germany) Matthew Marcus (Adobe Systems Inc., USA) Anne-Francoise Le Meur (University of Lille 1, France) Sibylle Schupp (Chalmers University of Technology, Sweden) Peter Sestoft (IT University of Copenhagen, Denmark) Chung-chieh Shan (Rutgers University, USA) Eric Van Wyk (University of Minnesota, USA) From lemming at henning-thielemann.de Wed Feb 20 10:59:52 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 20 10:57:35 2008 Subject: [Haskell-cafe] Selecting Array type In-Reply-To: <22fcbd520802200749x5e3976ecyc29528faaaf0df44@mail.gmail.com> References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> <22fcbd520802200749x5e3976ecyc29528faaaf0df44@mail.gmail.com> Message-ID: On Wed, 20 Feb 2008, Brent Yorgey wrote: > 2008/2/19 Jeff ? : > > instance SmartArraySelector UArray Bool where > > instance SmartArraySelector UArray Char where > > instance SmartArraySelector UArray Double where > > instance SmartArraySelector UArray Float where > > instance SmartArraySelector UArray Int where > Well, I'm not sure of the answer to your question, so I'll just make a > frivolous observation instead: I think you can leave off the "where" on > instances without any method definitions. Haddock 0.* makes a difference at this point. From jgoerzen at complete.org Wed Feb 20 11:23:16 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Feb 20 11:23:23 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types References: <20080220154437.GA22454@soi.city.ac.uk> Message-ID: On 2008-02-20, Ross Paterson wrote: >> conventions won't be usable in my ByteString code, for instance. >> [...] >> http://software.complete.org/listlike/static/doc/ListLike/Data-ListLike.html > > As Henning pointed out, multiple parameter type classes are problematic > for core libraries at present. > > An alternative might be explicit dictionaries. For example, a partial > solution would be to provide coinductive views, i.e. for all these types > to provide functions of a type like > > full -> Maybe (item, full) Hrm, what exactly is the return data here? Is is the head and the tail if the list has >= 1 item, or Nothing otherwise? Or...? The problem with this approach, if my guess is correct, is that you can't achieve native speed because you will have to be re-implementing everything in terms of these functions. For instance, I'd be using a re-implementation of length instead of a native ByteString length, which may be much faster. I notice that Data.Foldable does some similar things but does not use multi-parameter type classes. I seem to recall that I attempted to do this in the same manner, but got tripped up somewhere. I can't remember now exactly what the problem was, but I can go back and look if nobody knows off-hand. What is the problem with MPTC in base? From jgoerzen at complete.org Wed Feb 20 11:28:16 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Feb 20 11:28:18 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types References: <20080220154437.GA22454@soi.city.ac.uk> Message-ID: On 2008-02-20, John Goerzen wrote: > I notice that Data.Foldable does some similar things but does not use > multi-parameter type classes. I seem to recall that I attempted to do > this in the same manner, but got tripped up somewhere. I can't > remember now exactly what the problem was, but I can go back and look > if nobody knows off-hand. I went back and looked. The problem is that ByteString doesn't work as a member of Foldable, or of ListLike without it being MPTC. Trying to do so yields: ListLike.hs:217:20: Kind mis-match Expected kind `* -> *', but `BS.ByteString' has kind `*' In the instance declaration for `F.Foldable BS.ByteString' Is there any way around that, other than MPTC? -- John From ndmitchell at gmail.com Wed Feb 20 11:31:48 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Feb 20 11:30:00 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: References: <20080220154437.GA22454@soi.city.ac.uk> Message-ID: <404396ef0802200831r533a4f31gcfbb96e9bcc15611@mail.gmail.com> Hi > > full -> Maybe (item, full) > > Hrm, what exactly is the return data here? Is is the head and the > tail if the list has >= 1 item, or Nothing otherwise? Or...? Yes, its the projection onto another type: [] = Nothing (x:xs) = Just (x, xs) > What is the problem with MPTC in base? MPTC is not a part of any Haskell standard. The rules surrounding MPTC are not clear. People want to remove MPTC's/functional dependencies, or modify them with associated types. Compilers such as nhc and yhc can't implement them. Once they are in Haskell', with an associated set of restrictions/overlap rules etc, then they can be freely used with the base library. Thanks Neil From vandijk.roel at gmail.com Wed Feb 20 11:12:20 2008 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Wed Feb 20 11:37:01 2008 Subject: [Haskell-cafe] Problem with Python AST Message-ID: Hello everyone, I am trying to create an AST for Python. My approach is to create a data type for each syntactic construct. But I am stuck trying to statically enforce some constraints over my statements. A very short example to illustrate my problem: newtype Ident = Id String data BinOp = Add | Sub data Exp = IntLit Integer | BinOpExp BinOp Exp Exp data NormalCtx data LoopCtx data Statement ctx where Compound :: Compound -> Statement ctx Pass :: Statement ctx Break :: Statement LoopCtx newtype Global = Global [Ident] data Suite ctx = Suite [Global] [Statement ctx] type Else = Suite NormalCtx data Compound = If [(Exp, Suite NormalCtx)] (Maybe Else) | While Exp (Suite LoopCtx) (Maybe Else) newtype Program = Program [Statement NormalCtx] The "global" statement makes an identifier visible in the local scope. It holds for the entire current code block. So it also works backwards, which is why I didn't make it a statement but part of a suite (= block of statements). Some statements may occur in any context, such as the "pass" statement. But others are only allowed in certain situations, such as the "break" statement. This is why I defined the Statement as a GADT. I just supply the context in which the statement may be used and the typechecker magically does the rest. Feeling very content with this solution I tried a slightly more complex program and discovered that my AST can not represent this Python program: for i in range(10): if i == 6: break The compound if statement is perfectly valid nested in the loop because the Compound constructor of Statement allows any context. But the suites inside the clauses of the if statement only allow normal contexts. Since Break has a LoopCtx the typechecker complains. Is there some other way to statically enforce that break statements can only occur _nested_ inside a loop? There is a similar problem with return statements that may only occur in functions. These nested statements should somehow 'inherit' a context, if that makes any sense :-) I know I can simply create separate data types statements that can occur inside loops and function bodies. But that would make the AST a lot more complex, something I try to avoid. Python's syntax is already complex enough! Most of these constraints are not in the EBNF grammar which can be found in the language reference, but they are specified in the accompanying text. The cpython interpreter will generate SyntaxError's when you violate these constraints. See also Python's language reference: http://docs.python.org/ref/ref.html (see sections 6 and 7) From alfonso.acosta at gmail.com Wed Feb 20 12:07:13 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Feb 20 12:12:19 2008 Subject: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?) In-Reply-To: <200802201126.17982.g9ks157k@acme.softbase.org> References: <6a7c66fc0801310302p6bdee4adm6cf6a2778772ecbf@mail.gmail.com> <200802200226.41438.g9ks157k@acme.softbase.org> <6a7c66fc0802200020pf1aebb1vbafafdcd8ebf7ada@mail.gmail.com> <200802201126.17982.g9ks157k@acme.softbase.org> Message-ID: <6a7c66fc0802200907r1b688dbet63d221b90f1a0cd1@mail.gmail.com> On Wed, Feb 20, 2008 at 11:26 AM, Wolfgang Jeltsch wrote: > Hello Fons, > > why do you use the term vector? I'd say that this term is more or less wrong > for what this type is about. The distinguishing property of vectors compared > to lists is that there is addition and scalar multiplication for vectors. That depends on how you interpret the word vector, which is polysemous: http://en.wikipedia.org/wiki/Vector You are interpreting it as "An element in a vector space, often represented as a coordinate vector" whereas in this case I try to mean "A one-dimensional array". > The data type you defined is a fixed size list. The fact that FSVec is internally implemented using lists doesn't imply that FSVec should be interpreted as a list. FSVec is an ADT and I could as well have used something else to implement it (inmutable arrays for instance). From dgorin at dc.uba.ar Wed Feb 20 12:53:34 2008 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Wed Feb 20 12:52:54 2008 Subject: [Haskell-cafe] Problem with Python AST In-Reply-To: References: Message-ID: Hi Something like this would do? if_ = Compound $ If [(IntLit 6, Suite [] [Break])] Nothing while_ = Compound $ While (IntLit 6) (Suite [] [if_]) Nothing f = Program [while_] -- this one fails -- f2 = Program [if_] newtype Ident = Id String data BinOp = Add | Sub data Exp = IntLit Integer | BinOpExp BinOp Exp Exp data NormalCtx data LoopCtx data Statement ctx where Compound :: Compound ctx -> Statement ctx Pass :: Statement ctx Break :: Statement LoopCtx newtype Global = Global [Ident] data Suite ctx = Suite [Global] [Statement ctx] type Else ctx = Suite ctx data Compound ctx where If :: [(Exp, Suite ctx)] -> Maybe (Else ctx) -> Compound ctx While :: Exp -> (Suite LoopCtx) -> Maybe (Else LoopCtx) -> Compound ctx newtype Program = Program [Statement NormalCtx] Daniel On Feb 20, 2008, at 5:12 PM, Roel van Dijk wrote: > Hello everyone, > > I am trying to create an AST for Python. My approach is to create a > data type for each syntactic construct. But I am stuck trying to > statically enforce some constraints over my statements. A very short > example to illustrate my problem: > > > newtype Ident = Id String > > data BinOp = Add > | Sub > > data Exp = IntLit Integer > | BinOpExp BinOp Exp Exp > > data NormalCtx > data LoopCtx > > data Statement ctx where > Compound :: Compound -> Statement ctx > Pass :: Statement ctx > Break :: Statement LoopCtx > > newtype Global = Global [Ident] > > data Suite ctx = Suite [Global] [Statement ctx] > > type Else = Suite NormalCtx > > data Compound = If [(Exp, Suite NormalCtx)] (Maybe Else) > | While Exp (Suite LoopCtx) (Maybe Else) > > newtype Program = Program [Statement NormalCtx] > > > The "global" statement makes an identifier visible in the local scope. > It holds for the entire current code block. So it also works > backwards, which is why I didn't make it a statement but part of a > suite (= block of statements). > > Some statements may occur in any context, such as the "pass" > statement. But others are only allowed in certain situations, such as > the "break" statement. This is why I defined the Statement as a GADT. > I just supply the context in which the statement may be used and the > typechecker magically does the rest. > > Feeling very content with this solution I tried a slightly more > complex program and discovered that my AST can not represent this > Python program: > > for i in range(10): > if i == 6: > break > > The compound if statement is perfectly valid nested in the loop > because the Compound constructor of Statement allows any context. But > the suites inside the clauses of the if statement only allow normal > contexts. Since Break has a LoopCtx the typechecker complains. > > Is there some other way to statically enforce that break statements > can only occur _nested_ inside a loop? There is a similar problem with > return statements that may only occur in functions. These nested > statements should somehow 'inherit' a context, if that makes any sense > :-) > > I know I can simply create separate data types statements that can > occur inside loops and function bodies. But that would make the AST a > lot more complex, something I try to avoid. Python's syntax is already > complex enough! > > Most of these constraints are not in the EBNF grammar which can be > found in the language reference, but they are specified in the > accompanying text. The cpython interpreter will generate SyntaxError's > when you violate these constraints. > > See also Python's language reference: > http://docs.python.org/ref/ref.html (see sections 6 and 7) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jules at jellybean.co.uk Wed Feb 20 12:55:54 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Wed Feb 20 12:54:06 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: References: <20080220154437.GA22454@soi.city.ac.uk> Message-ID: <47BC69AA.4000000@jellybean.co.uk> John Goerzen wrote: > On 2008-02-20, John Goerzen wrote: >> I notice that Data.Foldable does some similar things but does not use >> multi-parameter type classes. I seem to recall that I attempted to do >> this in the same manner, but got tripped up somewhere. I can't >> remember now exactly what the problem was, but I can go back and look >> if nobody knows off-hand. > > I went back and looked. > > The problem is that ByteString doesn't work as a member of Foldable, > or of ListLike without it being MPTC. Trying to do so yields: > > ListLike.hs:217:20: > Kind mis-match > Expected kind `* -> *', but `BS.ByteString' has kind `*' > In the instance declaration for `F.Foldable BS.ByteString' > > Is there any way around that, other than MPTC? Not directly, no. The point about Foldable, Functor, and Monad, is that they enforce the connection between container and contents. If the contents is of type "a", the container is of type "f a" for a fixed type constructor 'f'. This works for [], Seq, and so on, but fails for ByteString. To go to the next level, for ByteString you either need type-level functions (to generalise 'f' from "type constructor" to "arbitrary function :: * -> *"), or MPTCs (to make the association between container and contents explicit). However, passing around dictionaries is certainly a solution which works in haskell98. I haven't thought it through enough to see if it would be unpleasantly verbose in practice. Jules From chad.scherrer at gmail.com Wed Feb 20 13:31:55 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Wed Feb 20 13:30:09 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: <1203300416.5522.5.camel@derek-laptop> References: <20080218010123.GA3817@scytale.galois.com> <1203300416.5522.5.camel@derek-laptop> Message-ID: On Feb 17, 2008 6:06 PM, Derek Elkins wrote: > It's -quite- possible that a coalgebraic perspective is much more > natural for your code/problem. If that's the case, use it (the > coalgebraic perspective that is). Obviously depending on the internals > of the stream library is not a good idea and using Streams directly was > not their intent, but it is your code. Do what you will. Here's an example of the problem. Start with a function extract :: [Int] -> [a] -> [a] extract = f 0 where f !k nss@(n:ns) (x:xs) | n == k = x : f (k+1) ns xs | otherwise = f (k+1) nss xs f _ _ _ = [] which is just a more efficient way of getting extract ns xs == [xs !! n | n <- ns] There should be a way to write this that will be friendly for stream fusion. The best option I can see is unfoldr. But if you try to write it this way, you get something like extract' ns xs = unfoldr f (0,ns,xs) where f (!k, nss@(n:ns), x:xs) | n == k = Just (x, (k + 1, ns, xs)) | otherwise = f (k+1, nss, xs) f _ = Nothing This is fine, except that the second-to-last line means this is still recursive. If I understand correctly, fusion requires that the recursion be encapsulated within the unfoldr or other functions that are expressed internally as stream functions. We could encapsulate the recursion with a function stepUnfoldr :: (s -> Step a s) -> s -> [a] stepUnfoldr f s = unfoldr g s where g s = case f s of Done -> Nothing Yield x s' -> Just (x,s') Skip s' -> g s' Using this, we could just write extract'' ns xs = stepUnfoldr f (0,ns,xs) where f (!k, nss@(n:ns), x:xs) | n == k = Yield x (k + 1, ns, xs) | otherwise = Skip (k+1, nss, xs) f _ = Done This is a pretty natural way to write the algorithm, and the recursion is nicely tucked away. The only remaining question is whether we can get things to fuse. The type of stepUnfoldr looks familiar... *Main> :t stepUnfoldr stepUnfoldr :: (s -> Step a s) -> s -> [a] *Main> :t \f s -> unstream $ Stream f s \f s -> unstream $ Stream f s :: (Data.Stream.Unlifted s) => (s -> Step a s) -> s -> [a] If we could somehow swap out our state type for an unlifted one, we could write a rule stepUnfoldr f = unstream . Stream f It seems like there might be some subtleties there to watch out for, but I'm not sure yet. Anyway, this is the kind of thing I had in mind when I asked about using the internals of Data.Stream more directly. Chad From chad.scherrer at gmail.com Wed Feb 20 13:48:21 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Wed Feb 20 13:46:42 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types References: Message-ID: Henning Thielemann henning-thielemann.de> writes: > > 4) We are missing one final useful type: a Word32-based ByteString. > > When working in the Unicode character set, a 32-bit character > > can indeed be useful, and I could see situations in which the > > performance benefit of a ByteString-like implementation could > > be useful combared to [Char]. > > StorableVector should fill this gap. > http://code.haskell.org/~sjanssen/storablevector/ > Yes, it could, but (1) it's way behind ByteString in terms of optimizations (== "fusion") (2) there's (as far as I know) not a StorableVector.Lazy, which is very much needed To catch up on both fronts, we're looking at a lot of duplicate code. Chad From aslatter at gmail.com Wed Feb 20 13:57:14 2008 From: aslatter at gmail.com (Antoine Latter) Date: Wed Feb 20 13:55:28 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: References: Message-ID: <694519c50802201057s298ec17rdbb26de12836eb35@mail.gmail.com> On Feb 20, 2008 12:48 PM, Chad Scherrer wrote: > > StorableVector should fill this gap. > > http://code.haskell.org/~sjanssen/storablevector/ > > > > Yes, it could, but > (1) it's way behind ByteString in terms of optimizations (== "fusion") > (2) there's (as far as I know) not a StorableVector.Lazy, which is very much > needed > > To catch up on both fronts, we're looking at a lot of duplicate code. For anyone looking into it - the StorableVector fusion would have to be quite different from the current ByteString fusion framework. Maybe it would be enough to lay down a Stream fusion framework for StorableVectors. -Antoine From chad.scherrer at gmail.com Wed Feb 20 13:59:29 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Wed Feb 20 13:57:48 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: <694519c50802201057s298ec17rdbb26de12836eb35@mail.gmail.com> References: <694519c50802201057s298ec17rdbb26de12836eb35@mail.gmail.com> Message-ID: On Feb 20, 2008 10:57 AM, Antoine Latter wrote: > For anyone looking into it - the StorableVector fusion would have to > be quite different from the current ByteString fusion framework. > Maybe it would be enough to lay down a Stream fusion framework for > StorableVectors. I must be missing something. Why would it have to be so different? Chad From jgoerzen at complete.org Wed Feb 20 13:43:48 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Feb 20 14:06:29 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types References: <20080220154437.GA22454@soi.city.ac.uk> <47BC69AA.4000000@jellybean.co.uk> Message-ID: On 2008-02-20, Jules Bean wrote: > Not directly, no. > > The point about Foldable, Functor, and Monad, is that they enforce the > connection between container and contents. If the contents is of type > "a", the container is of type "f a" for a fixed type constructor 'f'. > This works for [], Seq, and so on, but fails for ByteString. Right. In a pure abstract sense, we humans know there is a relationship between container and contents: a ByteString always contains a Word8 (or a Char8 if we choose the alternative implementation). But that is not expressed in the type of ByteString. > However, passing around dictionaries is certainly a solution which works > in haskell98. I haven't thought it through enough to see if it would be > unpleasantly verbose in practice. I'm not sure precisely what you mean here. If you mean to use dictionaries instead of typeclasses entirely, yes of course that would work, but it would mean that the functions could not operate on the underlying types unmodified, and once again compatibility issues may arise. On the other hand, if you mean using a dictionary to "wrap" just the ByteString types (or other similar ones), I am currently thinking of something along those lines. I'll post here if I come up with something clever (or not). From aslatter at gmail.com Wed Feb 20 14:20:30 2008 From: aslatter at gmail.com (Antoine Latter) Date: Wed Feb 20 14:18:43 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: References: <694519c50802201057s298ec17rdbb26de12836eb35@mail.gmail.com> Message-ID: <694519c50802201120r5f8fb6deua048e99bfea89887@mail.gmail.com> On Feb 20, 2008 12:59 PM, Chad Scherrer wrote: > On Feb 20, 2008 10:57 AM, Antoine Latter wrote: > > For anyone looking into it - the StorableVector fusion would have to > > be quite different from the current ByteString fusion framework. > > Maybe it would be enough to lay down a Stream fusion framework for > > StorableVectors. > > I must be missing something. Why would it have to be so different? > >From what I saw of Data.ByteString.Fusion, it relies on the assumption that the elements of the output array are of the same size and alignment as the elements of all of the arrays in the fused intermediate steps. That way, all of the intermediate stages can mutate the output array in place. This works because all of the fusable bytestring functions have types along the lines of: map :: (Word8 -> Word8) -> ByteString -> ByteString With StorableVector, it'd be nice to support the fusion of: map :: (a -> b) -> Vector a -> Vector b All of this just comes from me reading the code, so I could be miss-interpreting something. The NDP papers probably have something interesting to say about this, but I haven't taken the time to try and understand/simplify what they do. -Antoine From alangcarter at gmail.com Wed Feb 20 14:34:14 2008 From: alangcarter at gmail.com (Alan Carter) Date: Wed Feb 20 14:32:30 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> Message-ID: <56a54d4d0802201134r670c433duaec37a62e802ae32@mail.gmail.com> Cale, On Feb 20, 2008 10:58 AM, Cale Gibbard wrote: > (I'm copying the list on this, since my reply contains a tutorial > which might be of use to other beginners.) Thank you so much for this - I've just started playing with it so few intelligent responses yet. I'm sure it will be of *huge* use to others, right in the middle of the "gap" I fell into. The experiment continues - I'll be back :-) Many thanks, Alan -- ... the PA system was moaning unctuously, like a lady hippopotamus reading A. E. Housman ..." -- James Blish, "They Shall Have Stars" From dominic.steinitz at blueyonder.co.uk Wed Feb 20 14:28:54 2008 From: dominic.steinitz at blueyonder.co.uk (Dominic Steinitz) Date: Wed Feb 20 14:40:33 2008 Subject: [Haskell-cafe] Broken http://darcs.haskell.org/darcsweb/? Message-ID: <47BC7F76.20801@blueyonder.co.uk> I'm getting errors when I click on any of the links. I'm not sure who administers the site. IOError Python 2.4.4: /usr/bin/python Wed Feb 20 11:41:13 2008 A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /srv/darcsweb/darcsweb.cgi 2248 url_request.sort() 2249 cache = Cache(config.cachedir, url_request) 2250 if cache.open(): 2251 # we have a hit, dump and run 2252 cache.dump() cache = <__main__.Cache instance>, cache.open = > /srv/darcsweb/darcsweb.cgi in open(self=<__main__.Cache instance>) 466 pid = str(os.getpid()) 467 fname = self.basedir + '/.' + self.fname + '-' + pid 468 self.file = open(fname, 'w') 469 self.mode = 'w' 470 self = <__main__.Cache instance>, self.file = None, builtin open = , fname = '/tmp/darcsweb-cache/.3647210cedbbeff551e4ffe8dac1328a00518335-30974' IOError: [Errno 2] No such file or directory: '/tmp/darcsweb-cache/.3647210cedbbeff551e4ffe8dac1328a00518335-30974' args = (2, 'No such file or directory') errno = 2 filename = '/tmp/darcsweb-cache/.3647210cedbbeff551e4ffe8dac1328a00518335-30974' strerror = 'No such file or directory' From chad.scherrer at gmail.com Wed Feb 20 15:11:20 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Wed Feb 20 15:09:33 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: <694519c50802201120r5f8fb6deua048e99bfea89887@mail.gmail.com> References: <694519c50802201057s298ec17rdbb26de12836eb35@mail.gmail.com> <694519c50802201120r5f8fb6deua048e99bfea89887@mail.gmail.com> Message-ID: Antoine Latter wrote: > From what I saw of Data.ByteString.Fusion, it relies on the assumption > that the elements of the output array are of the same size and > alignment as the elements of all of the arrays in the fused > intermediate steps. That way, all of the intermediate stages can > mutate the output array in place. I see a lot in there involving the elimination of intermediate data structures, but nothing about destructive updates. The API is purely functional, and what you're talking about would need to be done in the IO monad to be sure you don't throw away stuff you might need to use again. Chad From ben.franksen at online.de Wed Feb 20 16:08:28 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Feb 20 16:10:15 2008 Subject: [Haskell-cafe] Re: Arrows: definition of pure & arr References: <47B7E4E1.6040506@telenet.be> <200802191128.40946.g9ks157k@acme.softbase.org> <00e701c87311$21daba00$65902e00$@be> <200802192223.47061.g9ks157k@acme.softbase.org> Message-ID: Wolfgang Jeltsch wrote: > I?m also in the process of shortening the names for type variables since > in conference papers you cannot use names that long (because otherwise you > quickly overrun the available width) and I don?t want to have too many > differences between papers and actual source code. However, I still don?t > like single-letter names like a and b. I like them if the type variables are really completely arbitrary types, like in map :: (a->b) -> [a] -> [b]. Using longer and more descriptive names here would (IMHO) be a mistake, as there is nothing specific about them. Similar on the value level, a definition like map f (x:xs) = f x : map f xs is (IMO) rather /easier/ to understand than anything using longer and more descriptive names, as, again, what x stands for is completely irrelevant here. I'd like to mention in passing that according to Dijkstra, when we develop an abstraction, it is important to (at least temporarily) forget what the symbols originally stood for, that is, before we abstracted them out of the context in which they originally appeared. The advantage is that without 'intuition' (about what the symbols 'mean') we have nothing left to follow but logic, which (supposedly) leads to a clearer understanding of the abstraction in itself, which in turn leads to shorter and more concise proofs, i.e. programs. That said, there are many situations where the type variables are linked by constraints and additional type (e.g. class method) signatures. In this case, mnemonic names can be a great help to understanding. In the example given, I'd use one-letter abbreviations of teh longer names, i.e. create :: PlainCircuit i o -> i -> IO (o, IO ()) Cheers Ben From stevelihn at gmail.com Wed Feb 20 16:22:58 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Wed Feb 20 16:21:12 2008 Subject: [Haskell-cafe] A little toy of Haskell Trivia Message-ID: I proudly announce a little toy that lists the frequency of modules being imported by other modules. Do you know Control.Monad is the most frequently imported module? I did not! Currently it only includes GHC 6.8 core library. If you have any idea how to parse through HackageDB code, please let me know. http://haskell.ecoin.net/cgi-bin/modules.pl Disclaimer: This is entirely for fun. It is by no means accurate or complete. I only spent a couple hours on a little perl script and a mysql table... From cetin.sert at gmail.com Wed Feb 20 16:29:19 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Wed Feb 20 16:27:33 2008 Subject: [Haskell-cafe] what is the fastest way to extract variables from a proposition? Message-ID: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> -- proposition data Prp a = Var a | Not (Prp a) | Or (Prp a) (Prp a) | And (Prp a) (Prp a) | Imp (Prp a) (Prp a) | Xor (Prp a) (Prp a) | Eqv (Prp a) (Prp a) | Cns Bool deriving (Show, Eq) -- Here are to variable extraction methods -- variable extraction reference imp. -- Graham Hutton: Programming in Haskell, 107 vars_ :: Prp a ? [a] vars_ (Cns _) = [] vars_ (Var x) = [x] vars_ (Not p) = vars_ p vars_ (Or p q) = vars_ p ++ vars_ q vars_ (And p q) = vars_ p ++ vars_ q vars_ (Imp p q) = vars_ p ++ vars_ q vars_ (Xor p q) = vars_ p ++ vars_ q vars_ (Eqv p q) = vars_ p ++ vars_ q -- variable extraction new * this is faster vars :: Prp a ? [a] vars p = evs [p] where evs [] = [] evs (Cns _ :ps) = [] evs (Var x :ps) = x:evs ps evs (Not p :ps) = evs (p:ps) evs (Or p q:ps) = evs (p:q:ps) evs (And p q:ps) = evs (p:q:ps) evs (Imp p q:ps) = evs (p:q:ps) evs (Xor p q:ps) = evs (p:q:ps) evs (Eqv p q:ps) = evs (p:q:ps) -- for : Not (Imp (Or (Var 'p') (Var 'q')) (Var p)) -- vars_: ['p','q','p'] -- vars : ['p','q','p'] -- order and the fact that 'p' appears twice being irrelevant: -- is there an even faster way to do this? -- -- Cetin Sert -- www.corsis.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080220/acaf6d5c/attachment.htm From ben.franksen at online.de Wed Feb 20 16:32:01 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Feb 20 16:33:53 2008 Subject: [Haskell-cafe] Re: a help for install References: <864256.86995.qm@web55508.mail.re4.yahoo.com> <200802191136.13871.g9ks157k@acme.softbase.org> Message-ID: Wolfgang Jeltsch wrote: > Am Montag, 18. Februar 2008 19:46 schrieb Carlos Gomez A.: >> hi, my name is carlos >> >> I need information for correct install or >> >> what are dependencies on ghc ? >> >> I have a Debian System. > > Always use your distribution?s packages until they aren?t any or there is > good > reason not to do so. Try ?aptitude install ghc6?. For my system (kubuntu 7.10) ghc-6.8.2 is not available as a package, only 6.6.1. And there are programs and libraries that can't be used with 6.6.1. Furthermore, in kubuntu 7.10 the libghc6 packages are broken w.r.t the documentation path. To illustrate (I have both libghc6-mtl-dev and libghc6-mtl-doc installed): ben@sarun[1]: ~ > ghc-pkg describe mtl | grep haddock haddock-interfaces: /usr/share/mtl-1.0.1/doc/html/mtl.haddock haddock-html: /usr/share/mtl-1.0.1/doc/html ben@sarun[1]: ~ > ls /usr/share/mtl-1.0.1/doc/html ls: /usr/share/mtl-1.0.1/doc/html: No such file or directory ben@sarun[1]: ~ > locate mtl.haddock /usr/share/doc/ghc6-doc/html/libraries/mtl/mtl.haddock ben@sarun[1]: ~ > ls /usr/share/doc/ghc6-doc/html/libraries/mtl/mtl.haddock /usr/share/doc/ghc6-doc/html/libraries/mtl/mtl.haddock This leads to errors when haddock tries to link to the mtl documentation. It took me quite a while to figure out what the source of this problem was. IME, it is better to install ghc and all the libraries from source. Of course you need to install ghc from the distro package for bootstrapping ghc, but you can delete it after the self-compiled ghc is installed. Cheers Ben PS: Yes, I reported this bug to the package maintainer but I received no response. From dons at galois.com Wed Feb 20 16:45:39 2008 From: dons at galois.com (Don Stewart) Date: Wed Feb 20 16:44:04 2008 Subject: [Haskell-cafe] Exporting Haskell Libraries to C Programmers In-Reply-To: References: Message-ID: <20080220214539.GB8658@scytale.galois.com> joseph.bruce: > Hi, > > I have a Haskell library that I want to make available via FFI to C > programmers on my project team. I read this thread > (http://thread.gmane.org/gmane.comp.lang.haskell.cafe/21447) which had > some interesting ideas, but they seemed unresolved. Or maybe it answers > my question but I don't understand it. > > Is there a way I can package (ghc-)compiled Haskell code into a > statically-linked library and not force the C programmers to include > headers and libraries that they have no knowledge of and undefine a > seemingly endless list of preprocessor symbols (run ghc with the verbose > flag and look at the calls to gcc)? Can this process be automated? Yes, check the FFI documentation for the main story. In short, build the Haskell code with cabal, with your foreign export Haskell functions in the cbits. That bundle can then be linked against C code. You do need to link your app against libHSrts.a and libHSbase.a (and other libs you use), but assuming you foreign export, the code to call will look just like normal C stuff. -- Don From igloo at earth.li Wed Feb 20 16:57:54 2008 From: igloo at earth.li (Ian Lynagh) Date: Wed Feb 20 16:56:07 2008 Subject: [Haskell-cafe] Broken http://darcs.haskell.org/darcsweb/? In-Reply-To: <47BC7F76.20801@blueyonder.co.uk> References: <47BC7F76.20801@blueyonder.co.uk> Message-ID: <20080220215754.GA6882@matrix.chaos.earth.li> On Wed, Feb 20, 2008 at 07:28:54PM +0000, Dominic Steinitz wrote: > I'm getting errors when I click on any of the links. I've created /tmp/darcsweb-cache and made it writable, which seems to have made it work again. > I'm not sure who administers the site. Neither am I, but it needs some tweaking or it will break whenever monk is rebooted. It would be useful if an admin address could be put on the pages, too. Thanks Ian From ben.franksen at online.de Wed Feb 20 16:56:05 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Feb 20 16:57:45 2008 Subject: [Haskell-cafe] Re: Selecting Array type References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> <7665bf90802191148n5e19876co8a69bad102417f58@mail.gmail.com> Message-ID: Jeff ? wrote: > However, my implementation of SmartArray requires me to create an instance > of a selector class to tell the compiler whether the type is boxed or > unboxed. I'm hoping to avoid creating instances of the selector class for > every possible type. I'd be grateful for any suggestions. Using ghc-6.8.2 I get test.hs:30:0: Functional dependencies conflict between instance declarations: instance [overlap ok] SmartArraySelector UArray Bool -- Defined at test.hs:30:0-46 instance [overlap ok] SmartArraySelector Array e -- Defined at test.hs:49:0-40 [more of the same for the other classes omitted] The offending lines are instance SmartArraySelector UArray Bool where vs. instance SmartArraySelector Array e where Note that it explicitly says 'overlap ok' but the functional dependencies cannot be fulfilled. You defined class (IArray a e) => SmartArraySelector a e | e -> a Your generic instance says that it determines the 'a' type for /all/ types 'e' as 'Array'. This conflicts with the other instance which says it determines the 'a' for the specific type 'Bool' as 'UArray'. That leaves the question how to achieve what you want, for which unfortunately I have no answer. Cheers Ben From lgreg.meredith at biosimilarity.com Wed Feb 20 17:14:49 2008 From: lgreg.meredith at biosimilarity.com (Greg Meredith) Date: Wed Feb 20 17:13:03 2008 Subject: [Haskell-cafe] Fwd: NW Functional Programming Interest Group In-Reply-To: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> References: <5de3f5ca0802011155l771cc649wa0e671bbe3abe364@mail.gmail.com> Message-ID: <5de3f5ca0802201414v2c241df0r6684151f8d2d9719@mail.gmail.com> All, Apologies for multiple listings. This is just a friendly reminder that a small cadre of us are organizing a Northwest Functional Programming Interest Group. Our first official meeting is today at the The Seattle Public Library 1000 - 4th Ave. Seattle, WA 98104 Spiral 6 Conference Room from 17:00 - 18:00 on February 20th. On the first meeting's agenda we'll be - giving people who are interested in or actively using FP for work or play a chance to meet - seeking to build up a pipeline of presentations and guest speakers - trying to keep organizational mishigosh to a minimum Hope to see you there. Monadically yours, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080220/a7f3b136/attachment.htm From ben.franksen at online.de Wed Feb 20 17:18:51 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Feb 20 17:20:37 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types References: <20080220154437.GA22454@soi.city.ac.uk> <47BC69AA.4000000@jellybean.co.uk> Message-ID: John Goerzen wrote: > On 2008-02-20, Jules Bean wrote: >> Not directly, no. >> >> The point about Foldable, Functor, and Monad, is that they enforce the >> connection between container and contents. If the contents is of type >> "a", the container is of type "f a" for a fixed type constructor 'f'. >> This works for [], Seq, and so on, but fails for ByteString. > > Right. In a pure abstract sense, we humans know there is a > relationship between container and contents: a ByteString always > contains a Word8 (or a Char8 if we choose the alternative > implementation). > > But that is not expressed in the type of ByteString. Hm, making a function out of a constant is easy on the value level, just use (const x) instead of (x). So, what about wrapping ByteString in a GADT, like this data ByteString' a where BS' :: Word8 -> ByteString' Word8 ? I probably overlooked something important here... Cheers Ben From droundy at darcs.net Wed Feb 20 17:28:19 2008 From: droundy at darcs.net (David Roundy) Date: Wed Feb 20 17:26:33 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: References: <20080220154437.GA22454@soi.city.ac.uk> <47BC69AA.4000000@jellybean.co.uk> Message-ID: <20080220222818.GO17316@darcs.net> On Wed, Feb 20, 2008 at 11:18:51PM +0100, Ben Franksen wrote: > John Goerzen wrote: > > > On 2008-02-20, Jules Bean wrote: > >> Not directly, no. > >> > >> The point about Foldable, Functor, and Monad, is that they enforce the > >> connection between container and contents. If the contents is of type > >> "a", the container is of type "f a" for a fixed type constructor 'f'. > >> This works for [], Seq, and so on, but fails for ByteString. > > > > Right. In a pure abstract sense, we humans know there is a > > relationship between container and contents: a ByteString always > > contains a Word8 (or a Char8 if we choose the alternative > > implementation). > > > > But that is not expressed in the type of ByteString. > > Hm, making a function out of a constant is easy on the value level, just use > (const x) instead of (x). So, what about wrapping ByteString in a GADT, > like this > > data ByteString' a where > BS' :: Word8 -> ByteString' Word8 > > ? I probably overlooked something important here... The problem is that while this would change the kind of ByteString to the same as the kind expected by Functor, you still couldn't define a proper Functor instance, since only ByteString' Word8 can ever actually be created. i.e. how could you implement fmapBS :: (a -> b) -> ByteString' a -> ByteString' b -- David Roundy Department of Physics Oregon State University From ben.franksen at online.de Wed Feb 20 17:40:50 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Feb 20 17:42:31 2008 Subject: [Haskell-cafe] Re: Re: The Proliferation of List-Like Types References: <20080220154437.GA22454@soi.city.ac.uk> <47BC69AA.4000000@jellybean.co.uk> <20080220222818.GO17316@darcs.net> Message-ID: David Roundy wrote: > On Wed, Feb 20, 2008 at 11:18:51PM +0100, Ben Franksen wrote: >> John Goerzen wrote: >> > On 2008-02-20, Jules Bean wrote: >> >> Not directly, no. >> >> >> >> The point about Foldable, Functor, and Monad, is that they enforce the >> >> connection between container and contents. If the contents is of type >> >> "a", the container is of type "f a" for a fixed type constructor 'f'. >> >> This works for [], Seq, and so on, but fails for ByteString. >> > >> > Right. In a pure abstract sense, we humans know there is a >> > relationship between container and contents: a ByteString always >> > contains a Word8 (or a Char8 if we choose the alternative >> > implementation). >> > >> > But that is not expressed in the type of ByteString. >> >> Hm, making a function out of a constant is easy on the value level, just >> use (const x) instead of (x). So, what about wrapping ByteString in a >> GADT, like this >> >> data ByteString' a where >> BS' :: Word8 -> ByteString' Word8 >> >> ? I probably overlooked something important here... > > The problem is that while this would change the kind of ByteString to the > same as the kind expected by Functor, you still couldn't define a proper > Functor instance, since only ByteString' Word8 can ever actually be > created. i.e. how could you implement > > fmapBS :: (a -> b) -> ByteString' a -> ByteString' b Oh yes, indeed. I knew there would be a catch, somewhere... Cheers Ben From jgoerzen at complete.org Wed Feb 20 17:45:38 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Feb 20 18:06:31 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types References: <20080220154437.GA22454@soi.city.ac.uk> <47BC69AA.4000000@jellybean.co.uk> Message-ID: On 2008-02-20, John Goerzen wrote: > > On the other hand, if you mean using a dictionary to "wrap" just the > ByteString types (or other similar ones), I am currently thinking of > something along those lines. I'll post here if I come up with > something clever (or not). Can't come up with anything particularly clever here. I think if we go that route, our only option is to add some wrapping/dewrapping function to encapsulate a ByteString into some sort of BSWrapper that does this sort of thing. Not exceptionally convenient. -- John From duncan.coutts at worc.ox.ac.uk Wed Feb 20 18:13:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 20 18:11:46 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: Message-ID: <1203549214.3076.4.camel@localhost> On Wed, 2008-02-20 at 08:39 -0600, John Goerzen wrote: > * The iconv library works only on lazy ByteStrings, and does not > handle Strings or strict ByteStrings There is a very good reason for this. The right solution in this particular example is not to overload every internal string operation in the iconv lib (which would be far far too slow) but to convert to/from your favourite representation on the edge. So in this case those conversions would be pack/unpack or the similar equivalents for strict <-> lazy bytestrings. If we want it to be generic then we want a class of string like things that provides conversions only, not operations. For example we could export iconv as: iconv :: StringLike string => Encoding -> Encoding -> string -> string iconv to from = (convertStringRep :: Lazy.ByteString -> string) . theRealIconv . (convertStringRep :: string -> Lazy.ByteString) class StringLike string where ... convertStringRep :: (StringLike s1, StringLike s2) => s1 -> s2 -- analogous to fromIntegral Duncan From bulat.ziganshin at gmail.com Wed Feb 20 16:14:44 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 20 18:13:48 2008 Subject: [Haskell-cafe] question about STM and IO In-Reply-To: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> References: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> Message-ID: <346903926.20080221001444@gmail.com> Hello John, Tuesday, February 12, 2008, 9:28:22 PM, you wrote: > I was recently looking at the STM library, and I have a question about > the function "unsafeIOToSTM". Can anyone explain to me what is unsafe > about it, and what sort of use would be considered "safe"? STM operations can be repeated if first transaction was unsuccessful. so, you may se here only operations that may be safely repeated - say, reading/writing memory areas, or reading/writing files, or even sending network message as long as its duplication is ok -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Feb 20 16:17:52 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 20 18:14:15 2008 Subject: [Haskell-cafe] Haddock documentation of Data.Array.* is confusing In-Reply-To: <6a7c66fc0802121232x1f114055g3db24c95c27dc4c5@mail.gmail.com> References: <6a7c66fc0802121232x1f114055g3db24c95c27dc4c5@mail.gmail.com> Message-ID: <702624326.20080221001752@gmail.com> Hello Alfonso, Tuesday, February 12, 2008, 11:32:20 PM, you wrote: > Excuse me for the subject, but IMHO is absolutely true. Anyhow, the of course, you are right, but for practical goals i may suggest just to read module sources instead of reading [had]docs. seeing the implementation is much more interesting, after all. especially when you are so cool that you are going to add your own instance -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From g9ks157k at acme.softbase.org Wed Feb 20 18:45:43 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Feb 20 18:44:27 2008 Subject: [Haskell-cafe] A little toy of Haskell Trivia In-Reply-To: References: Message-ID: <200802210045.43570.g9ks157k@acme.softbase.org> Am Mittwoch, 20. Februar 2008 22:22 schrieb Steve Lihn: > I proudly announce a little toy that lists the frequency of modules > being imported by other modules. Do you know Control.Monad is the most > frequently imported module? I did not! This doesn?t surprise me very much. What surprises me more is that OpenGL stuff is that popular. :-) > [?] Best wishes, Wolfgang From ross at soi.city.ac.uk Wed Feb 20 18:59:34 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Feb 20 18:57:47 2008 Subject: [Haskell-cafe] A little toy of Haskell Trivia In-Reply-To: References: Message-ID: <20080220235934.GA24386@soi.city.ac.uk> On Wed, Feb 20, 2008 at 09:22:58PM +0000, Steve Lihn wrote: > I proudly announce a little toy that lists the frequency of modules > being imported by other modules. Do you know Control.Monad is the most > frequently imported module? I did not! > > Currently it only includes GHC 6.8 core library. If you have any idea > how to parse through HackageDB code, please let me know. The layout is pretty simple. The index file http://hackage.haskell.org/packages/archive/00-index.tar.gz contains all the .cabal files. From their names you can figure out the locations of the source bundles, e.g. AGI/1.1/AGI.cabal -> http://hackage.haskell.org/packages/archive/AGI/1.1/AGI-1.1.tar.gz You can easily slurp the lot. The HackageDB wiki page has more details: http://hackage.haskell.org/trac/hackage/wiki/HackageDB From stevelihn at gmail.com Wed Feb 20 19:18:42 2008 From: stevelihn at gmail.com (Steve Lihn) Date: Wed Feb 20 19:16:54 2008 Subject: [Haskell-cafe] Where does ~> come from? In-Reply-To: <49a77b7a0802192134p8f26225v559e8110f7d223f2@mail.gmail.com> References: <200802191122.23121.g9ks157k@acme.softbase.org> <6BD267D89E66B9499514F119920E583C0220E86F@usctmx1110.merck.com> <200802192215.57372.g9ks157k@acme.softbase.org> <49a77b7a0802192134p8f26225v559e8110f7d223f2@mail.gmail.com> Message-ID: If ~> does not have any special meaning and it could be ### or xyz, then how does GHC know to print a ~> b, but not ~> a b a ### b, but not ### a b xyz a b, but not a `xyz` b Simply because xyz is alphanumeric? On Wed, Feb 20, 2008 at 12:34 AM, David Menendez wrote: > On Feb 19, 2008 4:15 PM, Wolfgang Jeltsch wrote: > > Am Dienstag, 19. Februar 2008 18:26 schrieben Sie: > > > [?] > > > > > However, I was told this: ~> a b is a ~> b, but if I write c a b and > > > wish the effect of a `c` b. This would not work. ~> as an infix operator > > > has a special place in GHC. It is not "just a type variable". > > > > Sorry, but I don't understand fully what you mean. :-( But nevertheless, > > a ~> b is not the same as ~> a b but as (~>) a b. It's just like with > > ordinary operators where a + b is the same as (+) a b. > > Note that some (all?) versions of GHC will incorrectly print "a ~> b" > as "~> a b". > > > > Prelude> :t undefined :: a + b > undefined :: a + b :: forall (+ :: * -> * -> *) a b. + a b > > It mostly gets infix type constructors right, although there are > apparently problems with precedence and associativity. > > -- > Dave Menendez > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From stefanor at cox.net Wed Feb 20 19:26:58 2008 From: stefanor at cox.net (Stefan O'Rear) Date: Wed Feb 20 19:25:11 2008 Subject: [Haskell-cafe] Where does ~> come from? In-Reply-To: References: <200802191122.23121.g9ks157k@acme.softbase.org> <6BD267D89E66B9499514F119920E583C0220E86F@usctmx1110.merck.com> <200802192215.57372.g9ks157k@acme.softbase.org> <49a77b7a0802192134p8f26225v559e8110f7d223f2@mail.gmail.com> Message-ID: <20080221002658.GA4566@localhost.localdomain> On Wed, Feb 20, 2008 at 07:18:42PM -0500, Steve Lihn wrote: > If ~> does not have any special meaning and it could be ### or xyz, > then how does GHC know to print > a ~> b, but not ~> a b > a ### b, but not ### a b > xyz a b, but not a `xyz` b > > Simply because xyz is alphanumeric? Yes. 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/20080220/a50ff44d/attachment.bin From alfonso.acosta at gmail.com Wed Feb 20 19:34:54 2008 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Feb 20 19:33:05 2008 Subject: [Haskell-cafe] Haddock documentation of Data.Array.* is confusing In-Reply-To: <702624326.20080221001752@gmail.com> References: <6a7c66fc0802121232x1f114055g3db24c95c27dc4c5@mail.gmail.com> <702624326.20080221001752@gmail.com> Message-ID: <6a7c66fc0802201634n61dffd9cnfd6669252e383ae1@mail.gmail.com> On Wed, Feb 20, 2008 at 10:17 PM, Bulat Ziganshin wrote: > Hello Alfonso, > > > Tuesday, February 12, 2008, 11:32:20 PM, you wrote: > > > Excuse me for the subject, but IMHO is absolutely true. Anyhow, the > > of course, you are right, but for practical goals i may suggest just > to read module sources instead of reading [had]docs. Well, that's what I was forced to do in the end, but I still think that the haddock documentation should be clear enough for most of the cases, and, when it comes to Data.Array* it could certainly be improved. > seeing the > implementation is much more interesting, after all. especially when you > are so cool that you are going to add your own instance I don't think that "being cool" had anything to do with it. My only purpose was to understand the desing of the interface for inmutable arrays. From conal at conal.net Wed Feb 20 19:43:08 2008 From: conal at conal.net (Conal Elliott) Date: Wed Feb 20 19:41:20 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor Message-ID: There was a chat today on #haskell (15:08 to 16:10) about evolving haddock. I'd like to get comments. The goal is to get the full functionality of a general purpose, programmer-friendly markup language like markdown. One example is image embedding. Another is friendly links (no visible URL). The idea is to make a future haddock be a *preprocessor* that generates pandoc's extended markdown (or some such). Documentation would be mostly markdown, with very few extensions for code documentation ('foo' and " Foo.Bar", maybe a bit more). Most of the doc would simply be passed through untouched. The code-doc extensions would get rewritten into standard markdown and mixed in with the rest. Pandoc could then take the generated markdown and produce HTML, LaTeX, DocBoook XML, etc. Perhaps there will be ways in which markdown falls short in expressiveness. If so, I'm guessing the shortcomings wouldn't be specific to the task of code documentation, and so could be approached as improvements to markdown/pandoc (which is written in Haskell). Since the old and new doc languages would be quite incompatible, we might want to specify in a .cabal file which language to use. Reactions? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080220/bac7e70d/attachment.htm From ben.franksen at online.de Wed Feb 20 19:53:20 2008 From: ben.franksen at online.de (Ben Franksen) Date: Wed Feb 20 19:55:09 2008 Subject: [Haskell-cafe] Re: Where does ~> come from? References: <200802191122.23121.g9ks157k@acme.softbase.org> <6BD267D89E66B9499514F119920E583C0220E86F@usctmx1110.merck.com> <200802192215.57372.g9ks157k@acme.softbase.org> <49a77b7a0802192134p8f26225v559e8110f7d223f2@mail.gmail.com> <20080221002658.GA4566@localhost.localdomain> Message-ID: Stefan O'Rear wrote: > On Wed, Feb 20, 2008 at 07:18:42PM -0500, Steve Lihn wrote: >> If ~> does not have any special meaning and it could be ### or xyz, >> then how does GHC know to print >> a ~> b, but not ~> a b >> a ### b, but not ### a b >> xyz a b, but not a `xyz` b >> >> Simply because xyz is alphanumeric? > > Yes. To slightly elaborate this: In Haskell, normal (prefix) functions and operators (infix) functions are syntactically distinguished by the characters they may contain: the former must contain only alphanumerics plus ' and _, the latter only operator symbols such as !#$%&*+./<=>?@\^|-~ for details see the Haskell98 Report (http://www.haskell.org/onlinelibrary/lexemes.html). Cheers Ben From jgoerzen at complete.org Wed Feb 20 20:01:46 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Feb 20 20:00:08 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <1203549214.3076.4.camel@localhost> References: <1203549214.3076.4.camel@localhost> Message-ID: <200802201901.46890.jgoerzen@complete.org> On Wednesday 20 February 2008 5:13:34 pm Duncan Coutts wrote: > On Wed, 2008-02-20 at 08:39 -0600, John Goerzen wrote: > > * The iconv library works only on lazy ByteStrings, and does not > > handle Strings or strict ByteStrings > > There is a very good reason for this. The right solution in this > particular example is not to overload every internal string operation in > the iconv lib (which would be far far too slow) but to convert to/from I guess the first question here is: in general, why? Let's say you were using something like ListLike (or StringLike, see below). If a library used these operations exclusively, you could make it work on most any type of list by simply changing your imports. (Hide the regular functions from Prelude, and import ListLike). For types such as ByteStrings or lists, that already have a very rich native implementation of these functions, the native implementation is used. You should be getting greater compatibility essentially for free. ListLike is an exhaustive mapping over these native functions. This would be great for anything from sort algorithms to parsers, etc. I even have a ListLikeIO typeclass[2] to facilitate this. [2] Now in your iconv case, you have a special case because you are doing manipulation specifically upon 8-bit binary data. It may not make sense for you to support a [Char] or even a Char8 ByteString because it does not lend itself to those very well. You could, perhaps, support a [Word8] as well as a ByteString when using ListLike. That is, you may have a function like this: head :: ListLike full Word8 => full -> Word8 You could still use this with a ByteString at native speeds, and a [Word8] at its native speed. But this doesn't buy us the ability to use this library interchangably with a Word8-based ByteString and a [Char]. That is a scenario ListLike is not designed to help with. ListLike is designed to make the container interchangable, but does not address making the contents interchangable. I think this is what you are pointing out? > your favourite representation on the edge. So in this case those > conversions would be pack/unpack or the similar equivalents for strict > <-> lazy bytestrings. > > If we want it to be generic then we want a class of string like things > that provides conversions only, not operations. > > For example we could export iconv as: > > iconv :: StringLike string => Encoding -> Encoding -> string -> string > iconv to from = (convertStringRep :: Lazy.ByteString -> string) > . theRealIconv > . (convertStringRep :: string -> Lazy.ByteString) > > class StringLike string where > ... > > convertStringRep :: (StringLike s1, StringLike s2) => s1 -> s2 > -- analogous to fromIntegral ListLike has something along these lines, too: [1] class StringLike s where toString :: s -> String fromString :: String -> s lines :: ListLike full s => s -> full words :: ListLike full s => s -> full unlines :: ListLike full s => full -> s unwords :: ListLike full s => full -> s The last four functions are there as a way to provide a universal interface to optimized native functions, where available. The minimal complete definition is just toString and fromString. Technically, you could make every function look like: iconv data = fromString . toString $ realIConv (fromString . toString $ data) That can be made simpler for the programmer with a helper function, but is not necessarily very efficient. With an MPTC, we could do: class StringConvertable s1 s2 where convertString :: s1 -> s2 withString :: s1 -> (s2 -> a) -> a withString x func = func (convertString x) interactString :: s1 -> (s2 -> s2) -> s1 interactString x func = convertString (func (convertString x) which ought to make easy conversions (String to ByteString, for instance) easily doable for a library such as iconv. What do you think? [1] http://software.complete.org/listlike/static/doc/ListLike/Data-ListLike-String.html#t%3AStringLike [2] http://software.complete.org/listlike/static/doc/ListLike/Data-ListLike-IO.html > > > Duncan From ryani.spam at gmail.com Wed Feb 20 20:40:55 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Feb 20 20:39:08 2008 Subject: [Haskell-cafe] Selecting Array type In-Reply-To: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> Message-ID: <2f9b2d30802201740leba997btfb2b927f7cbd14d3@mail.gmail.com> Oleg's done a lot of work here; there's a bunch of magic that can be done with TypeCast. I took my inspiration from here: http://okmij.org/ftp/Haskell/typecast.html#ambiguity-resolution Here are some tests in ghci (note that I specialized the index type in "test" to Int to make this shorter; doing so isn't technically required): Prelude SmartArray> :t test (1::Int) test (1::Int) :: Data.Array.Base.UArray Int Int Prelude SmartArray> :t test (1::Int, 2::Int) test (1::Int, 2::Int) :: GHC.Arr.Array Int (Int, Int) Prelude SmartArray> :t test "Foo" test "Foo" :: GHC.Arr.Array Int [Char] Prelude SmartArray> :t test False test False :: Data.Array.Base.UArray Int Bool Prelude SmartArray> The trick is to represent whether a type is boxed or not via a type-level boolean, which you can then use to affect the instance selecton. Here is the source: {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception -fallow-undecidable-instances -fallow-overlapping-instances #-} module SmartArray where import Data.Ix import Data.Array.Unboxed import Data.Complex type SmartArray i e = (Ix i, SmartArraySelector a e) => (a i e) -- smartArray is similar to array function from Data.Array. But, it -- will return a UArray if e can be unboxed. Otherwise, it returns an Array. smartArray :: (i, i) -> [(i, e)] -> SmartArray i e smartArray bnd eLst = array bnd eLst class (IArray a e) => SmartArraySelector a e | e -> a -- SmartArraySelector selects UArray for all types that can be -- unboxed. An instance has to be created for each unboxed type. I'd -- like to avoid listing all unboxed types here. However, since there -- are only a few unboxed types, it's not too burdensome to list them -- all. (For brevity, I didn't create all possible instances.) class IsUnboxed t b | t -> b instance TypeCast b HTrue => IsUnboxed Bool b instance TypeCast b HTrue => IsUnboxed Char b instance TypeCast b HTrue => IsUnboxed Double b instance TypeCast b HTrue => IsUnboxed Float b instance TypeCast b HTrue => IsUnboxed Int b instance TypeCast b HFalse => IsUnboxed a b -- overlap here class IArray a t => ArraySelector b t a | b t -> a -- where array' :: Ix i => b -> (i,i) -> [(i,t)] -> a i t instance IArray UArray a => ArraySelector HTrue a UArray -- where array' _ = array instance ArraySelector HFalse a Array -- where array' _ = array instance (IsUnboxed t b, ArraySelector b t a) => SmartArraySelector a t test :: SmartArraySelector a e => e -> a Int e test e = smartArray (0,10) [ (i,e) | i <- [0..10]] -- Magic toolbox that solves everything! Thanks Oleg! data HTrue data HFalse class TypeCast a b | a -> b, b->a where typeCast :: a -> b class TypeCast' t a b | t a -> b, t b -> a where typeCast' :: t->a->b class TypeCast'' t a b | t a -> b, t b -> a where typeCast'' :: t->a->b instance TypeCast' () a b => TypeCast a b where typeCast x = typeCast' () x instance TypeCast'' t a b => TypeCast' t a b where typeCast' = typeCast'' instance TypeCast'' () a a where typeCast'' _ x = x From rl at cse.unsw.edu.au Wed Feb 20 20:53:08 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Feb 20 20:51:25 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: References: <20080218010123.GA3817@scytale.galois.com> <1203300416.5522.5.camel@derek-laptop> Message-ID: <47BCD984.1040703@cse.unsw.edu.au> Chad Scherrer wrote: > > Here's an example of the problem. Start with a function > > extract :: [Int] -> [a] -> [a] > extract = f 0 > where > f !k nss@(n:ns) (x:xs) > | n == k = x : f (k+1) ns xs > | otherwise = f (k+1) nss xs > f _ _ _ = [] If you want this to play nicely with stream fusion, you have to define a version of extract which works on streams instead of lists: extractS :: Stream Int -> Stream a -> Stream a Now, you can easily define a fusible list version: extract ns xs = unstream (extractS (stream ns) (stream xs)) In general, I don't see why programming directly with streams is something that should be avoided. You do have to be quite careful, though, if you want to get good performance (but GHC's simplifier is becoming increasingly robust in this respect). > extract ns xs == [xs !! n | n <- ns] Note that in contrast to your function, this doesn't assume that ns is sorted and hence, there is no way to implement this without producing an intermediate list. Roman From ryani.spam at gmail.com Wed Feb 20 21:02:52 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Feb 20 21:01:03 2008 Subject: [Haskell-cafe] question about STM and IO In-Reply-To: <346903926.20080221001444@gmail.com> References: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> <346903926.20080221001444@gmail.com> Message-ID: <2f9b2d30802201802s6a602d4bu3de92a8d4c58e1fe@mail.gmail.com> On 2/20/08, Bulat Ziganshin wrote: > STM operations can be repeated if first transaction was unsuccessful. > so, you may se here only operations that may be safely repeated - say, > reading/writing memory areas, or reading/writing files, or even > sending network message as long as its duplication is ok Actually, you have to be even more careful than that; you may only include not just operations that may be safely repeated, but operations that may be erroneously executed. Consider the following snippet: badNews:: TVar Int -> TVar Int -> IO () badNews xRef yRef = atomically $ do x <- xRef y <- yRef if (x < y) then unsafeIOToSTM launchMissiles else return () (where launchMissiles has serious side effects, but can be called repeatedly without problem; the missiles will already have been launched in the second call). Even if (x < y) is never "atomically" true, launchMissiles could get executed during the evaluation of this STM action if it was run concurrently with another action that wrote new values to x and y in some order, such as the following snippet safe :: TVar Int -> TVar Int -> IO () safe xRef yRef = do atomically $ do writeTVar xRef 15 writeTVar yRef 13 main :: IO () main = do xRef <- newTVar 10 yRef <- newTVar 8 forkIO safe forkIO badNews If "badNews" runs to the point of reading from xRef, then "safe" runs in its entirety and commits successfully, then badNews resumes, launchMissiles will get called and then badNews will fail to commit and be restarted. The second runthrough of badNews will read the values, determine that x >= y, and just return (), but it's too late, the missiles have already been launched. -- ryan From rl at cse.unsw.edu.au Wed Feb 20 21:42:56 2008 From: rl at cse.unsw.edu.au (Roman Leshchinskiy) Date: Wed Feb 20 21:41:18 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: Message-ID: <47BCE530.2030607@cse.unsw.edu.au> John Goerzen wrote: > > I am concerned that the same thing is happening in Haskell. We know > have three common list-like types: the regular list, strict > ByteString, and lazy ByteString. Why do you consider ByteString to be list-like but not arrays? > 1) Does everyone agree with me that we have a problem here? Yes, definitely. Haskell simply lacks a standard container library. > 2) Would it make sense to make ListLike, or something like it, > part of the Haskell core? I don't think ListLike is the right approach. It's basically a fairly arbitrary collection of functions. It would be preferable, IMO, to identify a small set of combinators which would allow most list/sequence functions to be implemented generically and efficiently. Personally, I'd go with something like streams (the stream fusion ones) but I'm biased, of course. > 3) Would it make sense to base as much code as possible in the Haskell > core areound ListLike definitions? Here I think of functions such > as lines and words, which make sense both on [Char] as well as > ByteStrings. Yes, as long as there are only very few core combinators. The more methods your ListLike class has, the harder it is to justify why a new function should be implemented in terms of those and not included in the class. > 4) We are missing one final useful type: a Word32-based ByteString. > When working in the Unicode character set, a 32-bit character > can indeed be useful, and I could see situations in which the > performance benefit of a ByteString-like implementation could > be useful combared to [Char]. I have to disagree somewhat. What we are missing is a nice, efficient array library. There is nothing magical about ByteStrings, they are just unboxed arrays. In fact, there is no good reason for ByteString to be a separate type at all. Roman From ryani.spam at gmail.com Wed Feb 20 21:51:30 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Feb 20 21:49:42 2008 Subject: [Haskell-cafe] what is the fastest way to extract variables from a proposition? In-Reply-To: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> References: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> Message-ID: <2f9b2d30802201851g6aa6c031u56e1fc4cbcd1063b@mail.gmail.com> It depends what you mean by "faster"; more efficient (runtime) or less typing (programmer time!) For the former, you have basically the best implementation there is; you are basically encoding the continuation of (++) into the accumulating list of arguments to evs. You might want to consider difference lists to simplify the definition, however; the performance should be comparable: newtype DList a = DL ([a] -> [a]) dlToList :: DList a -> [a] dlToList (DL l) = l [] dlSingleton :: a -> DList a dlSingleton = DL . (:) dlConcat :: DList a -> DList a -> DList a dlConcat (DL l1) (DL l2) = DL (l1 . l2) varsDL :: Prp a -> DList a varsDL (Var a) = dlSingleton a varsDL (Not a) = varsDL a varsDL (Or a b) = varsDL a `dlConcat` varsDL b -- etc. If you want less typing, consider some form of generics programming such as using "Scrap your Boilerplate"; see http://www.cs.vu.nl/boilerplate/ data Prp a = ... deriving (Eq, Show, Data, Typeable) -- note that this gives the wrong result for Prp Bool because of Cns. -- this is fixable, see http://www.cs.vu.nl/boilerplate/testsuite/foldTree.hs varsGeneric :: forall a. Typeable a => Prp a -> [a] varsGeneric = listify (\x -> case (x :: a) of _ -> True) -- ryan On 2/20/08, Cetin Sert wrote: > -- proposition > data Prp a = Var a > | Not (Prp a) > | Or (Prp a) (Prp a) > | And (Prp a) (Prp a) > | Imp (Prp a) (Prp a) > | Xor (Prp a) (Prp a) > | Eqv (Prp a) (Prp a) > | Cns Bool > deriving (Show, Eq) > > -- Here are to variable extraction methods > > -- variable extraction reference imp. > -- Graham Hutton: Programming in Haskell, 107 > vars_ :: Prp a ? [a] > vars_ (Cns _) = [] > vars_ (Var x) = [x] > vars_ (Not p) = vars_ p > vars_ (Or p q) = vars_ p ++ vars_ q > vars_ (And p q) = vars_ p ++ vars_ q > vars_ (Imp p q) = vars_ p ++ vars_ q > vars_ (Xor p q) = vars_ p ++ vars_ q > vars_ (Eqv p q) = vars_ p ++ vars_ q > > -- variable extraction new * this is faster > vars :: Prp a ? [a] > vars p = evs [p] > where > evs [] = [] > evs (Cns _ :ps) = [] > evs (Var x :ps) = x:evs ps > evs (Not p :ps) = evs (p:ps) > evs (Or p q:ps) = evs (p:q:ps) > evs (And p q:ps) = evs (p:q:ps) > evs (Imp p q:ps) = evs (p:q:ps) > evs (Xor p q:ps) = evs (p:q:ps) > evs (Eqv p q:ps) = evs (p:q:ps) > > -- for : Not (Imp (Or (Var 'p') (Var 'q')) (Var p)) > -- vars_: ['p','q','p'] > -- vars : ['p','q','p'] > > -- order and the fact that 'p' appears twice being irrelevant: > -- is there an even faster way to do this? > -- > -- Cetin Sert > -- www.corsis.de > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dekudekuplex at yahoo.com Wed Feb 20 21:52:27 2008 From: dekudekuplex at yahoo.com (Benjamin L. Russell) Date: Wed Feb 20 21:50:39 2008 Subject: [Haskell-cafe] A little toy of Haskell Trivia In-Reply-To: Message-ID: <525779.5740.qm@web30208.mail.mud.yahoo.com> Rewriting that script in Haskell could be an interesting exercise. Do you have the source code? Benjamin L. Russell --- Steve Lihn wrote: > I proudly announce a little toy that lists the > frequency of modules > being imported by other modules. Do you know > Control.Monad is the most > frequently imported module? I did not! > > Currently it only includes GHC 6.8 core library. If > you have any idea > how to parse through HackageDB code, please let me > know. > > http://haskell.ecoin.net/cgi-bin/modules.pl > > Disclaimer: This is entirely for fun. It is by no > means accurate or > complete. I only spent a couple hours on a little > perl script and a > mysql table... > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ajb at spamcop.net Wed Feb 20 21:59:40 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Feb 20 21:57:51 2008 Subject: [Haskell-cafe] what is the fastest way to extract variables from a proposition? In-Reply-To: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> References: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> Message-ID: <20080220215940.3iwaftoovcokcg04@webmail.spamcop.net> G'day all. Quoting Cetin Sert : > -- proposition > data Prp a = Var a > | Not (Prp a) > | Or (Prp a) (Prp a) > | And (Prp a) (Prp a) > | Imp (Prp a) (Prp a) > | Xor (Prp a) (Prp a) > | Eqv (Prp a) (Prp a) > | Cns Bool > deriving (Show, Eq) This is probably the fastest: vars :: Prp a -> [a] vars p = vars' p [] where vars' (Var a) = (a:) vars' (Not p) = vars' p vars' (Or l r) = vars' l . vars' r {- etc -} vars' (Cns _) = id Cheers, Andrew Bromage From ajb at spamcop.net Wed Feb 20 22:46:55 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Feb 20 22:45:05 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: <404396ef0802200831r533a4f31gcfbb96e9bcc15611@mail.gmail.com> References: <20080220154437.GA22454@soi.city.ac.uk> <404396ef0802200831r533a4f31gcfbb96e9bcc15611@mail.gmail.com> Message-ID: <20080220224655.hh0duqpts0cgo8ss@webmail.spamcop.net> G'day all. Quoting Neil Mitchell : > Yes, its the projection onto another type: > > [] = Nothing > (x:xs) = Just (x, xs) Also known as msplit: http://www.haskell.org/haskellwiki/New_monads/MonadSplit Cheers, Andrew Bromage From lemming at henning-thielemann.de Wed Feb 20 22:57:30 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 20 22:55:41 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: References: <694519c50802201057s298ec17rdbb26de12836eb35@mail.gmail.com> Message-ID: On Wed, 20 Feb 2008, Chad Scherrer wrote: > On Feb 20, 2008 10:57 AM, Antoine Latter wrote: > > For anyone looking into it - the StorableVector fusion would have to > > be quite different from the current ByteString fusion framework. > > Maybe it would be enough to lay down a Stream fusion framework for > > StorableVectors. > > I must be missing something. Why would it have to be so different? I think there can also be problems simply because the element type is no longer fixed to Word8 but also not entirely free, but restricted to Storable. E.g. you cannot simply replace SV.fromList . List.map f by SV.map f . SV.fromList because in the second form not only the result type of 'f' must be Storable, but the input type of 'f' must be Storable, too. From lemming at henning-thielemann.de Wed Feb 20 23:07:46 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 20 23:05:58 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <47BCE530.2030607@cse.unsw.edu.au> References: <47BCE530.2030607@cse.unsw.edu.au> Message-ID: On Thu, 21 Feb 2008, Roman Leshchinskiy wrote: > John Goerzen wrote: > > > 2) Would it make sense to make ListLike, or something like it, > > part of the Haskell core? > > I don't think ListLike is the right approach. It's basically a fairly > arbitrary collection of functions. It would be preferable, IMO, to > identify a small set of combinators which would allow most list/sequence > functions to be implemented generically and efficiently. Personally, I'd > go with something like streams (the stream fusion ones) but I'm biased, > of course. As long as it is only about speeding up list processing, one might also consider this as optimization problem. This could be handled without adapting much List based code in applications to a generic sequence class. That is, if I convert the result of a composition of list functions to a lazy ByteString, I tell the compiler that I don't need full laziness and the compiler can optimize, say ByteString.fromList . List.func1 . List.func2 . List.build to ByteString.func1 . ByteString.func2 . ByteString.build or even better ByteString.fusedFunc1Func2Build by some clever fusion framework. I think that a type class is easier to justify if it unifies data structures that are more different than just providing the same API with different efficiency. From cetin.sert at gmail.com Wed Feb 20 23:10:14 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Wed Feb 20 23:08:26 2008 Subject: [Haskell-cafe] what is the fastest way to extract variables from a proposition? In-Reply-To: <20080220215940.3iwaftoovcokcg04@webmail.spamcop.net> References: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> <20080220215940.3iwaftoovcokcg04@webmail.spamcop.net> Message-ID: <1ff5dedc0802202010o2c39bb16od24c0153ecd110b1@mail.gmail.com> plong 0 = Var 0 plong n | even n = Or (Var n) (plong (n-1)) | otherwise = And (Var n) (plong (n-1)) main = do print ((length ? vars) (plong 10000000)) real 0m3.290s user 0m3.152s sys 0m0.020s main = do print ((length ? vars_) (plong 10000000)) real 0m3.732s user 0m3.680s sys 0m0.024s -- vrsn=varsBromage main = do print ((length ? vrsn) (plong 10000000)) real 0m4.164s user 0m4.128s sys 0m0.008s ghc -fglasgow-exts -O2 ghc 6.8.2 @Andrew: It is astonishing to see that your version actually performs the worst (at least on my machine). By looking at your code I had also thought that yours would be the fastest in terms of runtime performance, it was also exactly what I tried but failed to get to here on my own. Maybe future ghc versions will change this in favour of your version. I would like to have someone test it on another machine though: fetch: svn co https://okitsune.svn.sourceforge.net/svnroot/okitsune . build: ghc -fglasgow-exts -O2 Common.hs Propositions.hs Test.hs testS: time ./a.out sert testH: time ./a.out hutton testB: time ./a.out bromage Best regards, Cetin Sert. On 21/02/2008, ajb@spamcop.net wrote: > > G'day all. > > > Quoting Cetin Sert : > > > -- proposition > > data Prp a = Var a > > | Not (Prp a) > > | Or (Prp a) (Prp a) > > | And (Prp a) (Prp a) > > | Imp (Prp a) (Prp a) > > | Xor (Prp a) (Prp a) > > | Eqv (Prp a) (Prp a) > > | Cns Bool > > deriving (Show, Eq) > > > This is probably the fastest: > > vars :: Prp a -> [a] > vars p = vars' p [] > where > vars' (Var a) = (a:) > > vars' (Not p) = vars' p > > vars' (Or l r) = vars' l . vars' r > {- etc -} > vars' (Cns _) = id > > Cheers, > Andrew Bromage > > _______________________________________________ > 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/20080221/bc99625a/attachment.htm From jwlato at gmail.com Wed Feb 20 23:10:15 2008 From: jwlato at gmail.com (John Lato) Date: Wed Feb 20 23:08:35 2008 Subject: [Haskell-cafe] question about STM and IO In-Reply-To: <2f9b2d30802201802s6a602d4bu3de92a8d4c58e1fe@mail.gmail.com> References: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> <346903926.20080221001444@gmail.com> <2f9b2d30802201802s6a602d4bu3de92a8d4c58e1fe@mail.gmail.com> Message-ID: <9979e72e0802202010w4ffde6feg4fc4070d868cfb2d@mail.gmail.com> I take it that this follows from the lack of any mechanism to rollback IO? If so, I think that the following guidelines suffice for when it's acceptable to use unsafeIOtoSTM: 1. The IO action must be able to be safely repeated. 2. The IO action must be able to be safely performed with possibly-incorrect arguments, even if it isn't supposed to be performed. 3. Don't try to nest transactions. If I understand it correctly, I think that covers it. Thanks to everyone who answered; I really appreciate it. John On Wed, Feb 20, 2008 at 8:02 PM, Ryan Ingram wrote: > On 2/20/08, Bulat Ziganshin wrote: > > STM operations can be repeated if first transaction was unsuccessful. > > so, you may se here only operations that may be safely repeated - say, > > reading/writing memory areas, or reading/writing files, or even > > sending network message as long as its duplication is ok > > Actually, you have to be even more careful than that; you may only > include not just operations that may be safely repeated, but > operations that may be erroneously executed. Consider the following > snippet: From lemming at henning-thielemann.de Wed Feb 20 23:17:04 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 20 23:15:15 2008 Subject: [Haskell-cafe] A little toy of Haskell Trivia In-Reply-To: <200802210045.43570.g9ks157k@acme.softbase.org> References: <200802210045.43570.g9ks157k@acme.softbase.org> Message-ID: On Thu, 21 Feb 2008, Wolfgang Jeltsch wrote: > Am Mittwoch, 20. Februar 2008 22:22 schrieb Steve Lihn: > > I proudly announce a little toy that lists the frequency of modules > > being imported by other modules. Do you know Control.Monad is the most > > frequently imported module? I did not! > > This doesn?t surprise me very much. What surprises me more is that OpenGL > stuff is that popular. :-) Maybe some kind of self-citation ... From derek.a.elkins at gmail.com Wed Feb 20 23:30:41 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Feb 20 23:28:58 2008 Subject: [Haskell-cafe] what is the fastest way to extract variables from a proposition? In-Reply-To: <1ff5dedc0802202010o2c39bb16od24c0153ecd110b1@mail.gmail.com> References: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> <20080220215940.3iwaftoovcokcg04@webmail.spamcop.net> <1ff5dedc0802202010o2c39bb16od24c0153ecd110b1@mail.gmail.com> Message-ID: <1203568241.5522.10.camel@derek-laptop> On Thu, 2008-02-21 at 05:10 +0100, Cetin Sert wrote: > plong 0 = Var 0 > plong n | even n = Or (Var n) (plong (n-1)) > | otherwise = And (Var n) (plong (n-1)) compare the times again but with plong as follows: plong 0 = Var 0 plong n | even n = Or (plong (n-1)) (Var n) | otherwise = And (plong (n-1)) (Var n) > > > main = do print ((length ? vars) (plong 10000000)) > real 0m3.290s > user 0m3.152s > sys 0m0.020s > > main = do print ((length ? vars_) (plong 10000000)) > real 0m3.732s > user 0m3.680s > sys 0m0.024s > > -- vrsn=varsBromage > main = do print ((length ? vrsn) (plong 10000000)) > real 0m4.164s > user 0m4.128s > sys 0m0.008s > > ghc -fglasgow-exts -O2 > ghc 6.8.2 > > @Andrew: > It is astonishing to see that your version actually performs the worst > (at least on my machine). By looking at your code I had also thought > that yours would be the fastest in terms of runtime performance, it > was also exactly what I tried but failed to get to here on my own. > Maybe future ghc versions will change this in favour of your version. > > I would like to have someone test it on another machine though: > > fetch: svn co https://okitsune.svn.sourceforge.net/svnroot/okitsune . > build: ghc -fglasgow-exts -O2 Common.hs Propositions.hs Test.hs > testS: time ./a.out sert > testH: time ./a.out hutton > testB: time ./a.out bromage > > > Best regards, > Cetin Sert. > > On 21/02/2008, ajb@spamcop.net wrote: > G'day all. > > > Quoting Cetin Sert : > > > -- proposition > > data Prp a = Var a > > | Not (Prp a) > > | Or (Prp a) (Prp a) > > | And (Prp a) (Prp a) > > | Imp (Prp a) (Prp a) > > | Xor (Prp a) (Prp a) > > | Eqv (Prp a) (Prp a) > > | Cns Bool > > deriving (Show, Eq) > > > This is probably the fastest: > > vars :: Prp a -> [a] > vars p = vars' p [] > where > vars' (Var a) = (a:) > > vars' (Not p) = vars' p > > vars' (Or l r) = vars' l . vars' r > {- etc -} > vars' (Cns _) = id > > Cheers, > Andrew Bromage > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jgoerzen at complete.org Wed Feb 20 23:35:32 2008 From: jgoerzen at complete.org (John Goerzen) Date: Wed Feb 20 23:33:49 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <47BCE530.2030607@cse.unsw.edu.au> References: <47BCE530.2030607@cse.unsw.edu.au> Message-ID: <200802202235.32613.jgoerzen@complete.org> On Wednesday 20 February 2008 8:42:56 pm Roman Leshchinskiy wrote: > John Goerzen wrote: > > I am concerned that the same thing is happening in Haskell. We know > > have three common list-like types: the regular list, strict > > ByteString, and lazy ByteString. > > Why do you consider ByteString to be list-like but not arrays? > > > 1) Does everyone agree with me that we have a problem here? > > Yes, definitely. Haskell simply lacks a standard container library. > > > 2) Would it make sense to make ListLike, or something like it, > > part of the Haskell core? > > I don't think ListLike is the right approach. It's basically a fairly > arbitrary collection of functions. It would be preferable, IMO, to > identify a small set of combinators which would allow most list/sequence > functions to be implemented generically and efficiently. Personally, I'd > go with something like streams (the stream fusion ones) but I'm biased, > of course. From what I've heard of streams in this discussion, that does sound quite interesting. Unless streams are used internally for the [] implementation, though, we'd still need something to resolve the library compatibility question. -- John From ajb at spamcop.net Wed Feb 20 23:53:13 2008 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed Feb 20 23:51:24 2008 Subject: [Haskell-cafe] what is the fastest way to extract variables from a proposition? In-Reply-To: <1ff5dedc0802202010o2c39bb16od24c0153ecd110b1@mail.gmail.com> References: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> <20080220215940.3iwaftoovcokcg04@webmail.spamcop.net> <1ff5dedc0802202010o2c39bb16od24c0153ecd110b1@mail.gmail.com> Message-ID: <20080220235313.uzeatopc00k4cw00@webmail.spamcop.net> G'day all. Quoting Cetin Sert : > It is astonishing to see that your version actually performs the worst (at > least on my machine). On your example, I'm not surprised: > plong 0 = Var 0 > plong n | even n = Or (Var n) (plong (n-1)) > | otherwise = And (Var n) (plong (n-1)) This is effectively a singly linked list. I would expect my (well, I didn't invent it) to work better on something that didn't have this unique structure, such as: test 0 = Var 0 test n | even n = Or (Var n) (test (n-1)) | otherwise = And (test (n-1)) (Var n) Cheers, Andrew Bromage From cetin.sert at gmail.com Wed Feb 20 23:54:01 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Wed Feb 20 23:52:17 2008 Subject: [Haskell-cafe] what is the fastest way to extract variables from a proposition? In-Reply-To: <1203568241.5522.10.camel@derek-laptop> References: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> <20080220215940.3iwaftoovcokcg04@webmail.spamcop.net> <1ff5dedc0802202010o2c39bb16od24c0153ecd110b1@mail.gmail.com> <1203568241.5522.10.camel@derek-laptop> Message-ID: <1ff5dedc0802202054g6bb0550as7aa61ac1ddde35e5@mail.gmail.com> sert@elite:~/workspace/Haskell-1/bin$ time ./theResult sert 1000001 real 0m1.384s user 0m1.148s sys 0m0.112s sert@elite:~/workspace/Haskell-1/bin$ time ./theResult bromage 1000001 real 0m2.240s user 0m1.972s sys 0m0.176s sert@elite:~/workspace/Haskell-1/bin$ time ./theResult bromage 10000001 real 0m59.875s user 0m58.080s sys 0m1.656s sert@elite:~/workspace/Haskell-1/bin$ time ./theResult sert 10000001 real 0m32.043s user 0m30.930s sys 0m0.992s Hutton seems to fail miserably in both lengths here o_O I was not aware of the effect of structures on performance. Thanks for reminding me! Best Regards, Cetin Sert On 21/02/2008, Derek Elkins wrote: > > On Thu, 2008-02-21 at 05:10 +0100, Cetin Sert wrote: > > plong 0 = Var 0 > > plong n | even n = Or (Var n) (plong (n-1)) > > | otherwise = And (Var n) (plong (n-1)) > > > compare the times again but with plong as follows: > plong 0 = Var 0 > plong n | even n = Or (plong (n-1)) (Var n) > | otherwise = And (plong (n-1)) (Var n) > > > > > > > > main = do print ((length ? vars) (plong 10000000)) > > real 0m3.290s > > user 0m3.152s > > sys 0m0.020s > > > > main = do print ((length ? vars_) (plong 10000000)) > > real 0m3.732s > > user 0m3.680s > > sys 0m0.024s > > > > -- vrsn=varsBromage > > main = do print ((length ? vrsn) (plong 10000000)) > > real 0m4.164s > > user 0m4.128s > > sys 0m0.008s > > > > ghc -fglasgow-exts -O2 > > ghc 6.8.2 > > > > @Andrew: > > It is astonishing to see that your version actually performs the worst > > (at least on my machine). By looking at your code I had also thought > > that yours would be the fastest in terms of runtime performance, it > > was also exactly what I tried but failed to get to here on my own. > > Maybe future ghc versions will change this in favour of your version. > > > > I would like to have someone test it on another machine though: > > > > fetch: svn co https://okitsune.svn.sourceforge.net/svnroot/okitsune . > > build: ghc -fglasgow-exts -O2 Common.hs Propositions.hs Test.hs > > testS: time ./a.out sert > > testH: time ./a.out hutton > > testB: time ./a.out bromage > > > > > > Best regards, > > Cetin Sert. > > > > On 21/02/2008, ajb@spamcop.net wrote: > > G'day all. > > > > > > Quoting Cetin Sert : > > > > > -- proposition > > > data Prp a = Var a > > > | Not (Prp a) > > > | Or (Prp a) (Prp a) > > > | And (Prp a) (Prp a) > > > | Imp (Prp a) (Prp a) > > > | Xor (Prp a) (Prp a) > > > | Eqv (Prp a) (Prp a) > > > | Cns Bool > > > deriving (Show, Eq) > > > > > > This is probably the fastest: > > > > vars :: Prp a -> [a] > > vars p = vars' p [] > > where > > vars' (Var a) = (a:) > > > > vars' (Not p) = vars' p > > > > vars' (Or l r) = vars' l . vars' r > > {- etc -} > > vars' (Cns _) = id > > > > Cheers, > > Andrew Bromage > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080221/0dcfe428/attachment-0001.htm From cetin.sert at gmail.com Thu Feb 21 00:13:57 2008 From: cetin.sert at gmail.com (Cetin Sert) Date: Thu Feb 21 00:12:09 2008 Subject: [Haskell-cafe] what is the fastest way to extract variables from a proposition? In-Reply-To: <20080220235313.uzeatopc00k4cw00@webmail.spamcop.net> References: <1ff5dedc0802201329j7e6c1549ne8e7a759f0ee293e@mail.gmail.com> <20080220215940.3iwaftoovcokcg04@webmail.spamcop.net> <1ff5dedc0802202010o2c39bb16od24c0153ecd110b1@mail.gmail.com> <20080220235313.uzeatopc00k4cw00@webmail.spamcop.net> Message-ID: <1ff5dedc0802202113y5de86965od550b0279562a8b1@mail.gmail.com> > I would expect my (well, I didn't invent it) to work better on something that didn't have this unique structure, such as: > test 0 = Var 0 > test n | even n = Or (Var n) (test (n-1)) > | otherwise = And (test (n-1)) (Var n) for some reason this still does not perform as well as it should o__O I think function composition might somehow be the bottleneck behind this. --with plong 0 = Var 0 plong n | even n = Or (Var n) (plong (n-1)) | otherwise = And (plong (n-1)) (Var n) --and n = 1000000 sert@elite:~/workspace/Haskell-1/bin$ time ./theResult sert 1000001 real 0m0.692s user 0m0.624s sys 0m0.040s sert@elite:~/workspace/Haskell-1/bin$ time ./theResult sert 1000001 real 0m0.696s user 0m0.644s sys 0m0.036s sert@elite:~/workspace/Haskell-1/bin$ time ./theResult sert 1000001 real 0m0.840s user 0m0.744s sys 0m0.052s sert@elite:~/workspace/Haskell-1/bin$ time ./theResult bromage 1000001 real 0m1.561s user 0m1.360s sys 0m0.100s sert@elite:~/workspace/Haskell-1/bin$ time ./theResult bromage 1000001 real 0m1.692s user 0m1.392s sys 0m0.136s sert@elite:~/workspace/Haskell-1/bin$ time ./theResult bromage 1000001 real 0m1.959s user 0m1.580s sys 0m0.116s Best Regards, Cetin Sert On 21/02/2008, ajb@spamcop.net wrote: > > G'day all. > > Quoting Cetin Sert : > > > > It is astonishing to see that your version actually performs the worst > (at > > least on my machine). > > > On your example, I'm not surprised: > > > > plong 0 = Var 0 > > plong n | even n = Or (Var n) (plong (n-1)) > > | otherwise = And (Var n) (plong (n-1)) > > > This is effectively a singly linked list. I would expect my (well, I > didn't invent it) to work better on something that didn't have this > unique structure, such as: > > test 0 = Var 0 > test n | even n = Or (Var n) (test (n-1)) > | otherwise = And (test (n-1)) (Var n) > > > Cheers, > Andrew Bromage > _______________________________________________ > 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/20080221/b57397b5/attachment.htm From jeff1.61803 at gmail.com Thu Feb 21 01:48:12 2008 From: jeff1.61803 at gmail.com (=?ISO-8859-7?Q?Jeff_=F6?=) Date: Thu Feb 21 01:46:24 2008 Subject: [Haskell-cafe] Selecting Array type In-Reply-To: <2f9b2d30802191839m3c8aaf7aw789250a99a8e2254@mail.gmail.com> References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> <2f9b2d30802191839m3c8aaf7aw789250a99a8e2254@mail.gmail.com> Message-ID: <7665bf90802202248n568647f6y74e58d3be7f10144@mail.gmail.com> On 2/19/08, Ryan Ingram wrote: > > Oleg's done a lot of work here; there's a bunch of magic that can be > done with TypeCast. I took my inspiration from here: > http://okmij.org/ftp/Haskell/typecast.html#ambiguity-resolution > . . . > > The trick is to represent whether a type is boxed or not via a > type-level boolean, which you can then use to affect the instance > selecton. > . . . > > -- Magic toolbox that solves everything! Thanks Oleg! > > data HTrue > data HFalse > > class TypeCast a b | a -> b, b->a where typeCast :: a -> b > class TypeCast' t a b | t a -> b, t b -> a where typeCast' :: t->a->b > class TypeCast'' t a b | t a -> b, t b -> a where typeCast'' :: t->a->b > instance TypeCast' () a b => TypeCast a b where typeCast x = typeCast' () > x > instance TypeCast'' t a b => TypeCast' t a b where typeCast' = typeCast'' > instance TypeCast'' () a a where typeCast'' _ x = x > Thanks for showing me this technique. I studied your code for several hours. And, I've read Oleg's "Strongly Typed Heterogeneous Collections." As a learning exercise, I modified your code. I managed to shorten it a bit, but I had a couple of surprises. Please see my comments in the code below. {-# OPTIONS_GHC -fglasgow-exts -fbreak-on-exception -fallow-undecidable-instances -fallow-overlapping-instances #-} module SmartArray where import IO import Data.Ix import Data.Array.Unboxed import Data.Complex type SmartArray i e = (Ix i, SmartArraySelector a e) => (a i e) -- smartArray is similar to array function from Data.Array. But, -- it will return a UArray if e can be unboxed. Otherwise, it -- returns an Array. smartArray :: (i, i) -> [(i, e)] -> SmartArray i e smartArray bnd eLst = array bnd eLst class ArrTypeCast a b | a -> b, b->a where arrTypeCast :: a i e -> b i e instance ArrTypeCast x x where arrTypeCast = id -- SURPRISE 1: If function, arrTypeCast, is removed, (from both -- the class and instance) GHC assumes the kind of a and b are *, -- instead of * -> * -> * and produce . . . -- -- report3.hs:37:24: -- `UArray' is not applied to enough type arguments -- Expected kind `*', but `UArray' has kind `* -> * -> *' -- In the type `(ArrTypeCast a UArray, IArray a Bool) => -- SmartArraySelector a Bool' -- In the instance declaration for `SmartArraySelector a Bool' -- -- It appears that functions defined in a class can constrain the -- type variables of the class. To me, this seems a bit magical -- and unexpected. class (IArray a e) => SmartArraySelector a e | e -> a -- instances of SmartArraySelector for all boxed types (For -- breivity, not all unboxed types are listed.) instance (ArrTypeCast a UArray, IArray a Bool) => SmartArraySelector a Bool instance (ArrTypeCast a UArray, IArray a Char) => SmartArraySelector a Char instance (ArrTypeCast a UArray, IArray a Double) => SmartArraySelector a Double instance (ArrTypeCast a UArray, IArray a Float) => SmartArraySelector a Float instance (ArrTypeCast a UArray, IArray a Int) => SmartArraySelector a Int -- SURPRISE 2: The class SmartArraySelector has the type -- assertion, (IArray a e). It seems like adding an additional -- IArray assertion to each instance is redundant. However, -- if I remove the assertion (IArray a Int) above, GHC -- reports . . . -- -- report3.hs:37:24: -- `UArray' is not applied to enough type arguments -- Expected kind `*', but `UArray' has kind `* -> * -> *' -- In the type `(ArrTypeCast a UArray, IArray a Bool) => -- SmartArraySelector a Bool' -- In the instance declaration for `SmartArraySelector a Bool' -- -- Why is this second type assertion required? instance (ArrTypeCast a Array, IArray a b) => SmartArraySelector a b test :: SmartArraySelector a e => e -> a Int e test e = smartArray (0,10) [ (i,e) | i <- [0..10]] I'd love to find a good article that describes the ins and outs of multi parameter types, functional dependencies, and type assertions, in enough detail to resolve these surprises. A step-by-step walk through showing how the compiler resolve a type and selects an instance would be awesome. Usually, when I'm having trouble getting Haskell's type system to do what I want, I resort to trial and error tactics. I wish I had a better foundation so I could take a more intelligent approach to type hacking. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080221/b047391f/attachment.htm From dave at zednenem.com Thu Feb 21 02:05:46 2008 From: dave at zednenem.com (David Menendez) Date: Thu Feb 21 02:03:56 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: <20080220224655.hh0duqpts0cgo8ss@webmail.spamcop.net> References: <20080220154437.GA22454@soi.city.ac.uk> <404396ef0802200831r533a4f31gcfbb96e9bcc15611@mail.gmail.com> <20080220224655.hh0duqpts0cgo8ss@webmail.spamcop.net> Message-ID: <49a77b7a0802202305x73b6fc50i480c11e269e28089@mail.gmail.com> On Wed, Feb 20, 2008 at 10:46 PM, wrote: > Quoting Neil Mitchell : > > > Yes, its the projection onto another type: > > > > [] = Nothing > > (x:xs) = Just (x, xs) > > Also known as msplit: > > http://www.haskell.org/haskellwiki/New_monads/MonadSplit Almost. The projection has type f a -> Maybe (a, f a), but msplit has type f a -> f (Maybe (a, f a)). -- Dave Menendez From johan.tibell at gmail.com Thu Feb 21 04:06:55 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Feb 21 04:05:06 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: Message-ID: <90889fe70802210106o541e81cfx7bebc5d43c74bf91@mail.gmail.com> Hi John! On Wed, Feb 20, 2008 at 3:39 PM, John Goerzen wrote: > 3) Would it make sense to base as much code as possible in the Haskell > core areound ListLike definitions? Here I think of functions such > as lines and words, which make sense both on [Char] as well as > ByteStrings. I don't think the examples you gave (i.e. lines and words) make much sense on ByteStrings. You would have to assume that the sequence of bytes are in some particular Unicode encoding and thus words and lines will break if they get passed a ByteString using a different encoding. I don't think either of those two functions make sense on anything but sequence of character types like String. -- Johan From duncan.coutts at worc.ox.ac.uk Thu Feb 21 05:21:50 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 05:20:11 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <200802201901.46890.jgoerzen@complete.org> References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> Message-ID: <1203589310.3076.31.camel@localhost> On Wed, 2008-02-20 at 19:01 -0600, John Goerzen wrote: > On Wednesday 20 February 2008 5:13:34 pm Duncan Coutts wrote: > > On Wed, 2008-02-20 at 08:39 -0600, John Goerzen wrote: > > > * The iconv library works only on lazy ByteStrings, and does not > > > handle Strings or strict ByteStrings > > > > There is a very good reason for this. The right solution in this > > particular example is not to overload every internal string operation in > > the iconv lib (which would be far far too slow) but to convert to/from > > I guess the first question here is: in general, why? If one is stitching together coarse grained operations then it doesn't matter too much that we pass in a dictionary and indirect every operating through that. When we're using very fine grained operations the overhead per-operation is more significant. If we do not specialise to the list type we get all the extra overhead and we loose out on all the static optimisations. If we do specialise we get N copies of the code. Iconv is a weird example because it is calling out to a foreign lib that requires blocks of elements. A more convincing example might be an xml parser. I conjecture that it is faster and uses less code to make a single implementation on the best string representation and convert at the boundaries than to overload all the operations inside the parser by the string type. My guess is that a well written xml parser over lazy bytestring will be about the same speed as one written one over String *even* if we have to initially convert from a String input and certainly faster than an xml parser that takes a StringLike dictionary at runtime. So I'm claiming that the single impl with boundary conversion gives us the best of both worlds, no code bloat due to specialisation and working with whichever string type you like, by converting it at the beginning and end. Of course only an experiment can say either way. > Let's say you were using something like ListLike (or StringLike, see below). > If a library used these operations exclusively, you could make it work on > most any type of list by simply changing your imports. (Hide the regular > functions from Prelude, and import ListLike). For types such as ByteStrings > or lists, that already have a very rich native implementation of these > functions, the native implementation is used. You should be getting greater > compatibility essentially for free. ListLike is an exhaustive mapping over > these native functions. This would be great for anything from sort > algorithms to parsers, etc. I even have a ListLikeIO typeclass[2] to > facilitate this. [2] > > Now in your iconv case, you have a special case because you are doing > manipulation specifically upon 8-bit binary data. It may not make sense for > you to support a [Char] or even a Char8 ByteString because it does not lend > itself to those very well. You could, perhaps, support a [Word8] as well as > a ByteString when using ListLike. That is, you may have a function like > this: > > head :: ListLike full Word8 => full -> Word8 > > You could still use this with a ByteString at native speeds, and a [Word8] at > its native speed. Only if we definitely eliminate the type class dictionary statically and pay the code bloat cost of having several implementations around. > But this doesn't buy us the ability to use this library interchangably with a > Word8-based ByteString and a [Char]. That is a scenario ListLike is not > designed to help with. ListLike is designed to make the container > interchangable, but does not address making the contents interchangable. > > I think this is what you are pointing out? Not really. The iconv example would work with any ListLike(withCString) whose contents are Word8. > > your favourite representation on the edge. So in this case those > > conversions would be pack/unpack or the similar equivalents for strict > > <-> lazy bytestrings. > > > > If we want it to be generic then we want a class of string like things > > that provides conversions only, not operations. > > > > For example we could export iconv as: > > > > iconv :: StringLike string => Encoding -> Encoding -> string -> string > > iconv to from = (convertStringRep :: Lazy.ByteString -> string) > > . theRealIconv > > . (convertStringRep :: string -> Lazy.ByteString) > > > > class StringLike string where > > ... > > > > convertStringRep :: (StringLike s1, StringLike s2) => s1 -> s2 > > -- analogous to fromIntegral > > ListLike has something along these lines, too: [1] > > class StringLike s where > toString :: s -> String > fromString :: String -> s > lines :: ListLike full s => s -> full > words :: ListLike full s => s -> full > unlines :: ListLike full s => full -> s > unwords :: ListLike full s => full -> s > > The last four functions are there as a way to provide a universal interface > to optimized native functions, where available. The minimal complete > definition is just toString and fromString. > > Technically, you could make every function look like: > > iconv data = fromString . toString $ realIConv (fromString . toString $ data) > That can be made simpler for the programmer with a helper function, but is > not necessarily very efficient. With an MPTC, we could do: > > class StringConvertable s1 s2 where > convertString :: s1 -> s2 > withString :: s1 -> (s2 -> a) -> a > withString x func = func (convertString x) > > interactString :: s1 -> (s2 -> s2) -> s1 > interactString x func = convertString (func (convertString x) We can do something similar to fromIntegral so that we don't need a general StringConvertable class. -- | general coercion from integral types fromIntegral :: (Integral a, Num b) => a -> b fromIntegral = fromInteger . toInteger > which ought to make easy conversions (String to ByteString, for instance) > easily doable for a library such as iconv. What do you think? I think it needs some performance and code size experiments. Duncan From duncan.coutts at worc.ox.ac.uk Thu Feb 21 05:37:16 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 05:37:37 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <90889fe70802210106o541e81cfx7bebc5d43c74bf91@mail.gmail.com> References: <90889fe70802210106o541e81cfx7bebc5d43c74bf91@mail.gmail.com> Message-ID: <1203590236.3076.43.camel@localhost> On Thu, 2008-02-21 at 10:06 +0100, Johan Tibell wrote: > Hi John! > > On Wed, Feb 20, 2008 at 3:39 PM, John Goerzen wrote: > > 3) Would it make sense to base as much code as possible in the Haskell > > core areound ListLike definitions? Here I think of functions such > > as lines and words, which make sense both on [Char] as well as > > ByteStrings. > > I don't think the examples you gave (i.e. lines and words) make much > sense on ByteStrings. You would have to assume that the sequence of > bytes are in some particular Unicode encoding and thus words and lines > will break if they get passed a ByteString using a different encoding. > I don't think either of those two functions make sense on anything but > sequence of character types like String. That's exactly what the Data.ByteString[.Lazy].Char8 modules provide, a Char8 view of a Bytestring. Those modules provide functions like words, lines etc that assume an ASCII compatible 8bit encoding. One day we'll have a separate type that does Unicode with a similar fast packed representation. Duncan From duncan.coutts at worc.ox.ac.uk Thu Feb 21 05:40:45 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 05:40:24 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: <47BCE530.2030607@cse.unsw.edu.au> Message-ID: <1203590445.3076.46.camel@localhost> On Thu, 2008-02-21 at 05:07 +0100, Henning Thielemann wrote: > As long as it is only about speeding up list processing, one might also > consider this as optimization problem. This could be handled without > adapting much List based code in applications to a generic sequence class. > That is, if I convert the result of a composition of list functions to a > lazy ByteString, I tell the compiler that I don't need full laziness and > the compiler can optimize, say > ByteString.fromList . List.func1 . List.func2 . List.build > to > ByteString.func1 . ByteString.func2 . ByteString.build > or even better > ByteString.fusedFunc1Func2Build > by some clever fusion framework. I think that a type class is easier to > justify if it unifies data structures that are more different than just > providing the same API with different efficiency. This is orthogonal I think. This could be done with stream fusion without any common class. It requires that the types use stream fusion, then conversions between types (eg list/array) could be done with streams too. Duncan From duncan.coutts at worc.ox.ac.uk Thu Feb 21 05:59:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 05:59:38 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: References: Message-ID: <1203591599.3076.60.camel@localhost> On Wed, 2008-02-20 at 16:43 -0800, Conal Elliott wrote: > There was a chat today on #haskell (15:08 to 16:10) about evolving > haddock. I'd like to get comments. > > The goal is to get the full functionality of a general purpose, > programmer-friendly markup language like markdown. One example is > image embedding. Another is friendly links (no visible URL). To be honest I like the fact that haddock's markup is really simple and perhaps somewhat restrictive. A great improvement though would be to make it easy to extract the docs from haddock in a nice format so that the could be re-used in other contexts rather than just generating html api documentation. Haddock does have support for multiple backends, someone just needs to define and write a generic backend that spits out the info that haddock gathers in a machine readable format. Then people could feed that into whatever other system they like. > Since the old and new doc languages would be quite incompatible, we > might want to specify in a .cabal file which language to use. That's the main thing that worries me. Currently we have the rather nice situation that we have a single standardised markup format that everyone understands. So I very much support the idea of making the markup easier to extract but I think we should be very careful about changing the markup format. The haddock markup format has always been very lightweight and does not assume much about the capabilities of the backend (paper, web, whatever). Duncan From luke.haskell-cafe at la.id.au Thu Feb 21 06:58:05 2008 From: luke.haskell-cafe at la.id.au (Luke Andrew) Date: Thu Feb 21 06:56:19 2008 Subject: [Haskell-cafe] Can't seem to get `par` working appropriately with lists Message-ID: <47BD674D.1080508@la.id.au> Hopefully an easy one here; after reading Don Stewart's blog posts about parallel Haskell and with a shiny new quad-core cpu begging for a workout, i thought I'd give Haskell a try. I've also been meaning to write a ray-tracer, so I started with that. I've got the initial ray-tracer working, and am now looking to parallize it. I tried using the `par` function to evaluate things in parallel, but I couldn't get it to work with lists. I simplified my problem down into the following 2 test cases: (there are two fibonacci functions to ensure haskell treats them as 2 independent computations to be spread across 2 cores) test1.hs: import Control.Parallel fib1 n = if n == 0 then 0 else if n == 1 then 1 else fib1 (n-1) + fib1 (n-2) fib2 n = if n == 0 then 0 else if n == 1 then 1 else fib2 (n-1) + fib2 (n-2) main = do print $ (fib2 37 `par` fib1 37) + (fib2 37) compilation & testing: luke@Sonata:~/mcls$ ghc -O2 -threaded --make test1 [1 of 1] Compiling Main ( test1.hs, test1.o ) Linking test1 ... luke@Sonata:~/mcls$ time ./test1 +RTS -N1 48315634 real 0m5.856s user 0m5.816s sys 0m0.004s luke@Sonata:~/mcls$ time ./test1 +RTS -N2 48315634 real 0m3.450s user 0m6.734s sys 0m0.024s As expected, running it with 2 cores is substantially faster. Doing almost the same thing, but with lists, doesn't seem to have any significant speed difference: test2.hs: import Control.Parallel fib1 n = if n == 0 then 0 else if n == 1 then 1 else fib1 (n-1) + fib1 (n-2) fib2 n = if n == 0 then 0 else if n == 1 then 1 else fib2 (n-1) + fib2 (n-2) fiblist1 n = [fib1 x| x <- [1..n]] fiblist2 n = [fib2 x| x <- [1..n]] main = do print $ zipWith (+) (fiblist2 37 `par` fiblist1 37) (fiblist2 37) compilation & testing: luke@Sonata:~/mcls$ ghc -O2 -threaded --make test2 luke@Sonata:~/mcls$ time ./test2 +RTS -N1 [2,2,4,6,10,16,26,42... ...405774,18454930,29860704,48315634] real 0m15.294s user 0m15.196s sys 0m0.013s luke@Sonata:~/mcls$ time ./test2 +RTS -N2 [2,2,4,6,10,16,26,42... ...405774,18454930,29860704,48315634] real 0m15.268s user 0m15.169s sys 0m0.013s I've tried using bang patterns in various places, but to no avail. Any ideas? Luke Andrew. From jules at jellybean.co.uk Thu Feb 21 07:17:29 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Thu Feb 21 07:15:41 2008 Subject: [Haskell-cafe] Can't seem to get `par` working appropriately with lists In-Reply-To: <47BD674D.1080508@la.id.au> References: <47BD674D.1080508@la.id.au> Message-ID: <47BD6BD9.4010004@jellybean.co.uk> Luke Andrew wrote: > import Control.Parallel > > fib1 n = if n == 0 then 0 else if n == 1 then 1 else fib1 (n-1) + > fib1 (n-2) > fib2 n = if n == 0 then 0 else if n == 1 then 1 else fib2 (n-1) + > fib2 (n-2) > > main = do print $ (fib2 37 `par` fib1 37) + (fib2 37) "fib2 37" won't be shared. You're telling ghc to calculate fib2 37 once, in parallel, throw it away, and then calculate it again. Try: let f1 = fib1 37 f2 = fib2 37 in print $ (f2 `par` f1) + f2 Jules From bulat.ziganshin at gmail.com Thu Feb 21 05:24:06 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 21 07:31:22 2008 Subject: [Haskell-cafe] A little toy of Haskell Trivia In-Reply-To: <200802210045.43570.g9ks157k@acme.softbase.org> References: <200802210045.43570.g9ks157k@acme.softbase.org> Message-ID: <216437586.20080221132406@gmail.com> Hello Wolfgang, Thursday, February 21, 2008, 2:45:43 AM, you wrote: >> I proudly announce a little toy that lists the frequency of modules >> being imported by other modules. Do you know Control.Monad is the most >> frequently imported module? I did not! > This doesn?t surprise me very much. What surprises me more is that OpenGL > stuff is that popular. :-) perhaps opengl library just contains too many modules that imports each other :))) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From lemming at henning-thielemann.de Thu Feb 21 07:34:00 2008 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 21 07:32:29 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <1203590445.3076.46.camel@localhost> References: <47BCE530.2030607@cse.unsw.edu.au> <1203590445.3076.46.camel@localhost> Message-ID: On Thu, 21 Feb 2008, Duncan Coutts wrote: > On Thu, 2008-02-21 at 05:07 +0100, Henning Thielemann wrote: > > > As long as it is only about speeding up list processing, one might also > > consider this as optimization problem. This could be handled without > > adapting much List based code in applications to a generic sequence class. > > That is, if I convert the result of a composition of list functions to a > > lazy ByteString, I tell the compiler that I don't need full laziness and > > the compiler can optimize, say > > ByteString.fromList . List.func1 . List.func2 . List.build > > to > > ByteString.func1 . ByteString.func2 . ByteString.build > > or even better > > ByteString.fusedFunc1Func2Build > > by some clever fusion framework. I think that a type class is easier to > > justify if it unifies data structures that are more different than just > > providing the same API with different efficiency. > > This is orthogonal I think. This could be done with stream fusion > without any common class. It requires that the types use stream fusion, > then conversions between types (eg list/array) could be done with > streams too. I suppose we mean the same. My question is: Why do we use ByteString instead of [Word8] ? Entirely because of efficiency, right? So if we could stick to List code and only convert to ByteString at the end and the compiler all rewrites it to ByteString code, then we would not need libraries that are specialised to ByteString, but they can use [Word8] instead. From johan.tibell at gmail.com Thu Feb 21 07:37:48 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Feb 21 07:35:57 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <1203590236.3076.43.camel@localhost> References: <90889fe70802210106o541e81cfx7bebc5d43c74bf91@mail.gmail.com> <1203590236.3076.43.camel@localhost> Message-ID: <90889fe70802210437o24928265i13803e0d1dacce7@mail.gmail.com> On Thu, Feb 21, 2008 at 11:37 AM, Duncan Coutts wrote: > > > On Thu, 2008-02-21 at 10:06 +0100, Johan Tibell wrote: > > Hi John! > > > > On Wed, Feb 20, 2008 at 3:39 PM, John Goerzen wrote: > > > 3) Would it make sense to base as much code as possible in the Haskell > > > core areound ListLike definitions? Here I think of functions such > > > as lines and words, which make sense both on [Char] as well as > > > ByteStrings. > > > > I don't think the examples you gave (i.e. lines and words) make much > > sense on ByteStrings. You would have to assume that the sequence of > > bytes are in some particular Unicode encoding and thus words and lines > > will break if they get passed a ByteString using a different encoding. > > I don't think either of those two functions make sense on anything but > > sequence of character types like String. > > That's exactly what the Data.ByteString[.Lazy].Char8 modules provide, a > Char8 view of a Bytestring. Those modules provide functions like words, > lines etc that assume an ASCII compatible 8bit encoding. I would be very happy if people didn't use the .Char8 versions of ByteString except for being able to write byte literals using pack. (I would be even happier if Haskell had byte literals.) If people start using ByteString in their library interfaces instead of String I'll be really miserable because I can't really use their libraries for writing applications that need to be internationalized because their libraries would be limited to ASCII. Data.ByteString and Data.ByteString.Char8 uses the same ByteString type so I can take some bytes in UTF-32 which I read from the network and use Data.ByteString.Char8 functions on them which will fail. I prefer that a type that represent characters is guarded by encode and decode functions. If that's not the case it's easy to mix data in different encodings by mistake when e.g. writing web applications which involve data in several different encodings. > One day we'll have a separate type that does Unicode with a similar fast > packed representation. That will be a good day. :) -- Johan From alistair at abayley.org Thu Feb 21 08:12:04 2008 From: alistair at abayley.org (Alistair Bayley) Date: Thu Feb 21 08:10:15 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <1203591599.3076.60.camel@localhost> References: <1203591599.3076.60.camel@localhost> Message-ID: <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> On 21/02/2008, Duncan Coutts wrote: > > To be honest I like the fact that haddock's markup is really simple and > perhaps somewhat restrictive. A great improvement though would be to > make it easy to extract the docs from haddock in a nice format so that > the could be re-used in other contexts rather than just generating html > api documentation. Haddock does have support for multiple backends, > someone just needs to define and write a generic backend that spits out > the info that haddock gathers in a machine readable format. I have probably misunderstood both of you, but I think that Conal proposed that Haddock *input* syntax is largely unchanged; Haddock should be able to *output* markdown, for consumption by pandoc. (Which I think is also what you're suggesting.) Alistair From gale at sefer.org Thu Feb 21 08:23:44 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 21 08:21:54 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> Message-ID: <2608b8a80802210523v55dd8588n7b10511a1e25d74a@mail.gmail.com> Cale Gibbard wrote: > I woke up rather early, and haven't much to do, so I'll turn this into > a tutorial. :) Cale, this is fantastic, as always. I often find myself searching for material like this when introducing people to Haskell. Would you be willing to put this on the wiki? Thanks, Yitz From ross at soi.city.ac.uk Thu Feb 21 08:42:00 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 21 08:40:12 2008 Subject: [Haskell-cafe] A little toy of Haskell Trivia In-Reply-To: References: Message-ID: <20080221134200.GA28549@soi.city.ac.uk> On Wed, Feb 20, 2008 at 09:22:58PM +0000, Steve Lihn wrote: > I proudly announce a little toy that lists the frequency of modules > being imported by other modules. Do you know Control.Monad is the most > frequently imported module? I did not! > > Currently it only includes GHC 6.8 core library. If you have any idea > how to parse through HackageDB code, please let me know. There's a link on the HackageDB Introduction page that gets you the latest versions of all packages (30MB). From ahey at iee.org Thu Feb 21 09:03:07 2008 From: ahey at iee.org (Adrian Hey) Date: Thu Feb 21 09:01:19 2008 Subject: [Haskell-cafe] Gobbler Benchmarks Message-ID: <47BD849B.7090501@iee.org> Hello Folks, There's been some discussions recently about the pros and cons of various coding styles, particularly whether stack greedy or heap greedy is best, and how (if) ghcs stack management in particular should affect all this. In particular, the problem of implementing an eager take function. Here's some real numbers measured with ghc 6.8.2 under windowsxp using AMD Athlon 64 1.8 GHz. The source code can be found here.. http://homepages.nildram.co.uk/~ahey/Test1.zip There are 4 possible implementations that have been tested: -- Uses O(n) stack stackGobbler :: Int -> [x] -> [x] stackGobbler 0 _ = [] stackGobbler _ [] = [] stackGobbler n (x:xs) = let xs' = stackGobbler (n-1) xs in xs' `seq` (x:xs') -- Uses O(n) heap instead, O(1) stack heapGobbler :: Int -> [x] -> [x] heapGobbler = heapGobbler' [] where heapGobbler' rxs 0 _ = reverse rxs heapGobbler' rxs _ [] = reverse rxs heapGobbler' rxs n (x:xs) = heapGobbler' (x:rxs) (n-1) xs -- Neils O(n) heap version, O(1) stack neilGobbler :: Int -> [x] -> [x] neilGobbler n xs = length res `seq` res where res = take n xs -- Continuation passing O(n) heap version, O(1) stack cpGobbler :: Int -> [x] -> [x] cpGobbler = f id where f c 0 _ = c [] f c _ [] = c [] f c n (x:xs) = f (\xs' -> c (x:xs')) (n-1) xs There are 16 tests for each, parameterised by p=0..15. Each test takes 63*(2^p) elements from a test list of the same length, and is repeated 2^(25-p) times. So in total, 63*(2^25) elements are processed in each case (independent of p). Here are the results in "myCpuTimePrecision = 15625000000" units (the figure exported by System.CPUTime is wrong for me). To convert these to actual time per element figures you need to multiply each by 7.4 pS (I think :-). All tests were run with fixed stack and heap sizes of 16 and 256 MiB respectively. p stack heap neil cp ---------------------------- 0 - 1793 2684 4937 2593 1 - 1860 2673 4897 2584 2 - 1910 2673 4825 2578 3 - 1927 2659 4819 2575 4 - 1946 2657 4813 2574 5 - 1950 2656 5048 2578 6 - 1960 2711 5036 2627 7 - 1976 2730 5126 2643 8 - 2072 2900 5197 2813 9 - 2439 3044 5153 2974 10 - 2685 3275 5371 3199 11 - 2760 3384 5466 3321 12 - 2930 3487 5525 3444 13 - 3181 3648 5813 3698 14 - 3698 3973 6417 4031 15 - 4727 4987 7964 5224 So pretty much as I expected. For smallish lists, stackGobbler is easily the fastest, heapGobbler and cpGobbler are pretty similar, and neilGobbler is the slowest (sorry Neil:-). The performance of all is degraded as p increases. I guess this is not too surprising, but stackGobbler seems to degrade faster so that at p=15 there's not much difference between it and heapGobbler/cpGobbler. I'm not sure what it is that causes stackGobbler to be "unfairly" penalised this way, but I'm reminded of this post from John Meacham.. http://haskell.org/pipermail/glasgow-haskell-users/2007-May/012470.html The other big problem with stackgobbler in practice is the risk of stack overflow. For p=15 it would not work at all for ghc default stack limit. Regards -- Adrian Hey From me at twifkak.com Thu Feb 21 09:26:41 2008 From: me at twifkak.com (Devin Mullins) Date: Thu Feb 21 09:24:52 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <1203589310.3076.31.camel@localhost> References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> <1203589310.3076.31.camel@localhost> Message-ID: <20080221142638.GA6011@twifkak.com> On Thu, Feb 21, 2008 at 10:21:50AM +0000, Duncan Coutts wrote: > So I'm claiming that the single impl with boundary conversion gives us > the best of both worlds, no code bloat due to specialisation and working > with whichever string type you like, by converting it at the beginning > and end. Of course only an experiment can say either way. I think his point is that if I'm using three libraries, each of which uses a different String type, that's a lot of boundaries. Perhaps worse yet, if I'm a library author and I want to be a good citizen, I have to write three versions of my code (or create my own StringLike typeclass). I know of an example off-hand: http://nominolo.blogspot.com/2007/05/networkhttp-bytestrings.html (Of course, as I read that, I see that the lazy code is different from the strict code, but I'll just ignore that for the sake of, uh, argument.) (Sorry if this is a dupe; long thread, and I have to go to work.) From david.waern at gmail.com Thu Feb 21 09:54:43 2008 From: david.waern at gmail.com (David Waern) Date: Thu Feb 21 09:53:11 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: References: Message-ID: 2008/2/21, Conal Elliott : > There was a chat today on #haskell (15:08 to 16:10) about evolving haddock. > I'd like to get comments. > > The goal is to get the full functionality of a general purpose, > programmer-friendly markup language like markdown. One example is image > embedding. Another is friendly links (no visible URL). Haddock already supports image embedding since version 0.8. I don't think it works properly in version 2 (because of merge errors), but it probably will in the next version. Use <> for including images. David From allbery at ece.cmu.edu Thu Feb 21 10:20:21 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Feb 21 10:18:32 2008 Subject: [Haskell-cafe] A little toy of Haskell Trivia In-Reply-To: <216437586.20080221132406@gmail.com> References: <200802210045.43570.g9ks157k@acme.softbase.org> <216437586.20080221132406@gmail.com> Message-ID: On Feb 21, 2008, at 5:24 , Bulat Ziganshin wrote: > Hello Wolfgang, > > Thursday, February 21, 2008, 2:45:43 AM, you wrote: >>> I proudly announce a little toy that lists the frequency of modules >>> being imported by other modules. Do you know Control.Monad is the >>> most >>> frequently imported module? I did not! > >> This doesn?t surprise me very much. What surprises me more is >> that OpenGL >> stuff is that popular. :-) > > perhaps opengl library just contains too many modules that imports > each other :))) I have seen (demo) programs import the OpenGL modules just to get (:=). Wonder if that goes on in the real world? -- 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 ben at bridesmere.com Thu Feb 21 10:58:13 2008 From: ben at bridesmere.com (Ben Butler-Cole) Date: Thu Feb 21 10:56:22 2008 Subject: [Haskell-cafe] Repeated function application Message-ID: <640461.89929.qm@web30808.mail.mud.yahoo.com> Hello I was surprised to be unable to find anything like this in the standard libraries: times :: (a -> a) -> Int -> (a -> a) times f 0 = id times f n = f . (times f (n-1)) Am I missing something more general which would allow me to repeatedly apply a function to an input? Or is this not useful? I thought this looked a bit like a fold, so I tried expressing it like this: times f n x = foldl (flip ($)) x (replicate n f) ... which horrifies me, but I can't help feeling that there must be a way to get rid of the explicit recursion. How would you implement times? Ben From jerzy.karczmarczuk at info.unicaen.fr Thu Feb 21 11:06:58 2008 From: jerzy.karczmarczuk at info.unicaen.fr (jerzy.karczmarczuk@info.unicaen.fr) Date: Thu Feb 21 11:05:08 2008 Subject: [Haskell-cafe] Repeated function application In-Reply-To: <640461.89929.qm@web30808.mail.mud.yahoo.com> References: <640461.89929.qm@web30808.mail.mud.yahoo.com> Message-ID: Ben Butler-Cole writes: > times :: (a -> a) -> Int -> (a -> a) > times f 0 = id > times f n = f . (times f (n-1)) > > Am I missing something more general > ...I can't help feeling that there must be a way to get rid of the > explicit recursion. > > How would you implement times? Anything against (apart an auxiliary list, and "x" not curried away) times n f x = (iterate f x)!!n Jerzy Karczmarczuk From g9ks157k at acme.softbase.org Thu Feb 21 11:07:11 2008 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 21 11:05:56 2008 Subject: [Haskell-cafe] Repeated function application In-Reply-To: <640461.89929.qm@web30808.mail.mud.yahoo.com> References: <640461.89929.qm@web30808.mail.mud.yahoo.com> Message-ID: <200802211707.12054.g9ks157k@acme.softbase.org> Am Donnerstag, 21. Februar 2008 16:58 schrieb Ben Butler-Cole: > Hello > > I was surprised to be unable to find anything like this in the standard > libraries: > > times :: (a -> a) -> Int -> (a -> a) > times f 0 = id > times f n = f . (times f (n-1)) times f n = (!! n) . iterate f > [?] Best wishes, Wolfgang From nominolo at googlemail.com Thu Feb 21 11:51:41 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Feb 21 11:49:59 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <20080221142638.GA6011@twifkak.com> References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> <1203589310.3076.31.camel@localhost> <20080221142638.GA6011@twifkak.com> Message-ID: On 21 feb 2008, at 15.26, Devin Mullins wrote: > On Thu, Feb 21, 2008 at 10:21:50AM +0000, Duncan Coutts wrote: >> So I'm claiming that the single impl with boundary conversion >> gives us >> the best of both worlds, no code bloat due to specialisation and >> working >> with whichever string type you like, by converting it at the >> beginning >> and end. Of course only an experiment can say either way. > > I think his point is that if I'm using three libraries, each of which > uses a different String type, that's a lot of boundaries. Perhaps > worse > yet, if I'm a library author and I want to be a good citizen, I > have to > write three versions of my code (or create my own StringLike > typeclass). > I know of an example off-hand: > http://nominolo.blogspot.com/2007/05/networkhttp-bytestrings.html > (Of course, as I read that, I see that the lazy code is different from > the strict code, but I'll just ignore that for the sake of, uh, > argument.) Yes it does use different implementations, but the lazy interface has it's problems (leakage of handles, unclosed connections, and more). But what we really want is, as Duncan and Roman suggested, *one* standard, optimizable representation and conversions from and to it. This would work perfectly well with sockets. / Thomas From bulat.ziganshin at gmail.com Thu Feb 21 11:00:04 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 21 11:51:51 2008 Subject: [Haskell-cafe] question about STM and IO In-Reply-To: <2f9b2d30802201802s6a602d4bu3de92a8d4c58e1fe@mail.gmail.com> References: <9979e72e0802121028hb5356d1u11d9558b394c2224@mail.gmail.com> <346903926.20080221001444@gmail.com> <2f9b2d30802201802s6a602d4bu3de92a8d4c58e1fe@mail.gmail.com> Message-ID: <1456319804.20080221190004@gmail.com> Hello Ryan, Thursday, February 21, 2008, 5:02:52 AM, you wrote: > values, determine that x >= y, and just return (), but it's too late, > the missiles have already been launched. it seems that "asymmetrical answer" of mr.Putin is just to hire a bit more Haskell Hackers :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu Feb 21 11:46:47 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 21 11:52:11 2008 Subject: [Haskell-cafe] Haskell + Windows Mobile? Message-ID: <259725041.20080221194647@gmail.com> Hello haskell-cafe, is there any haskell implementation for Windows Mobile? does they are support creation of GUI apps and internet networking features? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From jgbailey at gmail.com Thu Feb 21 12:02:45 2008 From: jgbailey at gmail.com (Justin Bailey) Date: Thu Feb 21 12:00:55 2008 Subject: [Haskell-cafe] Selecting Array type In-Reply-To: <7665bf90802202248n568647f6y74e58d3be7f10144@mail.gmail.com> References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> <2f9b2d30802191839m3c8aaf7aw789250a99a8e2254@mail.gmail.com> <7665bf90802202248n568647f6y74e58d3be7f10144@mail.gmail.com> Message-ID: 2008/2/20 Jeff ? : > I'd love to find a good article that describes the ins and outs of multi > parameter types, functional dependencies, and type assertions, in enough > detail to resolve these surprises. A step-by-step walk through showing how > the compiler resolve a type and selects an instance would be awesome. The research paper "Strong Types for Relational Databases" linked on the page below has an excellent introductory section on type-level programming: http://wiki.di.uminho.pt/twiki/bin/view/Research/PURe/CoddFish A recent issue of "The Monad Reader" had a great article on type-level programming to solve the "Instant Insanity" game. I did not track down a link but I'm sure you can find it easily. Justin From johan.tibell at gmail.com Thu Feb 21 12:35:14 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Feb 21 12:33:26 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> <1203589310.3076.31.camel@localhost> <20080221142638.GA6011@twifkak.com> Message-ID: <90889fe70802210935k5080840ey7b2e1a407e9c08e9@mail.gmail.com> On Thu, Feb 21, 2008 at 5:51 PM, Thomas Schilling wrote: > > I know of an example off-hand: > > http://nominolo.blogspot.com/2007/05/networkhttp-bytestrings.html > > (Of course, as I read that, I see that the lazy code is different from > > the strict code, but I'll just ignore that for the sake of, uh, > > argument.) > > Yes it does use different implementations, but the lazy interface has > it's problems (leakage of handles, unclosed connections, and more). > But what we really want is, as Duncan and Roman suggested, *one* > standard, optimizable representation and conversions from and to it. > This would work perfectly well with sockets. I switched from lazy bytestrings to a left fold in my networking code after reading what Oleg wrote about streams vs folds. No problems with handles, etc. anymore. -- Johan From gale at sefer.org Thu Feb 21 12:54:04 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 21 12:52:13 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> Message-ID: <2608b8a80802210954rb164189oa265cf5a23f2f468@mail.gmail.com> Duncan Coutts wrote: >> To be honest I like the fact that haddock's markup is really simple and >> perhaps somewhat restrictive. A great improvement though would be... >> a generic backend that spits out >> the info that haddock gathers in a machine readable format. Alistair Bayley wrote: > I have probably misunderstood both of you, but I think that Conal > proposed that Haddock *input* syntax is largely unchanged; Haddock > should be able to *output* markdown, for consumption by pandoc. Perhaps, but I don't think "markdown", or any other presentation format, is right for that. I'm sure that there are many presentation formats needed by many different people. I think Duncan's point is that haddock only really needs to produce one *generic* output. It should faithfully preserve all of the information that haddock knows how to produce, in a format that is easy to parse. That could then be transformed by other existing tools into whatever you want, including the current HTML/CSS, markdown, or anything else. XML is what people usually use nowadays for that sort of thing, but it doesn't have to be XML. The haddock web site mentions that some work has already been done on DocBook XML; that could work. DITA would perhaps be a better fit. Or we could use our own set of tags. Regards, Yitz From nominolo at googlemail.com Thu Feb 21 12:58:58 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu Feb 21 12:57:18 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <90889fe70802210935k5080840ey7b2e1a407e9c08e9@mail.gmail.com> References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> <1203589310.3076.31.camel@localhost> <20080221142638.GA6011@twifkak.com> <90889fe70802210935k5080840ey7b2e1a407e9c08e9@mail.gmail.com> Message-ID: <7BFF453C-67EB-4243-ADFD-D384B7BA870C@googlemail.com> On 21 feb 2008, at 18.35, Johan Tibell wrote: > > I switched from lazy bytestrings to a left fold in my networking code > after reading what Oleg wrote about streams vs folds. No problems with > handles, etc. anymore. > Do you fold over chunks? Can you continue to use Parsek or other utilities that need a stream-abstraction, and if so, how do you handle the end of a chunk. This is the kind of callback interface where lazy evaluation really abstracts things nicely. From chad.scherrer at gmail.com Thu Feb 21 13:16:48 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Thu Feb 21 13:14:58 2008 Subject: [Haskell-cafe] stream/bytestring questions In-Reply-To: <47BCD984.1040703@cse.unsw.edu.au> References: <20080218010123.GA3817@scytale.galois.com> <1203300416.5522.5.camel@derek-laptop> <47BCD984.1040703@cse.unsw.edu.au> Message-ID: On Wed, Feb 20, 2008 at 5:53 PM, Roman Leshchinskiy wrote: > In general, I don't see why programming directly with streams is > something that should be avoided. You do have to be quite careful, > though, if you want to get good performance (but GHC's simplifier is > becoming increasingly robust in this respect). Hmm. I was taking the approach of getting something working, given what is currently exported from Data.Stream. How would you deal with this? Should there be a Data.Stream.Internal or something that exports streams and unlifted types? If I'm understanding this correctly, these things were not exported in the first place because this fusion framework provides an approximation, but not an isomorphism, so partial bottoms don't always behave nicely. I was hoping to get around this by programming instead to Step and then hoping rules could be constructed to translate to Streams. Do you think there's a better way around it? > > extract ns xs == [xs !! n | n <- ns] > > Note that in contrast to your function, this doesn't assume that ns is > sorted and hence, there is no way to implement this without producing an > intermediate list. Oh yes, good point. It's so easy to forget about assumptions like that. Chad From chad.scherrer at gmail.com Thu Feb 21 13:23:16 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Thu Feb 21 13:21:28 2008 Subject: [Haskell-cafe] Re: The Proliferation of List-Like Types In-Reply-To: References: <694519c50802201057s298ec17rdbb26de12836eb35@mail.gmail.com> Message-ID: On Wed, Feb 20, 2008 at 7:57 PM, Henning Thielemann wrote: > I think there can also be problems simply because the element type is no > longer fixed to Word8 but also not entirely free, but restricted to > Storable. E.g. you cannot simply replace > SV.fromList . List.map f by SV.map f . SV.fromList > because in the second form not only the result type of 'f' must be > Storable, but the input type of 'f' must be Storable, too. Hmm, interesting. But would we really need this? If we have [a] rewritten as a stream and SV rewritten as a stream, couldn't they still fuse? Loosely speaking, SV.fromList . List.map f -> (SV.unstream . List.stream) . (List.unstream . mapS f . List.stream) -> SV.unstream . mapS f . List.stream Chad From vandijk.roel at gmail.com Thu Feb 21 13:55:55 2008 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Thu Feb 21 13:54:05 2008 Subject: [Haskell-cafe] Problem with Python AST In-Reply-To: References: Message-ID: Your solutions allows a bit more but fails with the equivalent of def foo(): for i in range(10): if i == 6: return None The loop context 'overwrites' the function context which makes the return statement illegal. I think I need a type level list. From westondan at imageworks.com Thu Feb 21 14:20:31 2008 From: westondan at imageworks.com (Dan Weston) Date: Thu Feb 21 14:18:51 2008 Subject: [Haskell-cafe] Repeated function application In-Reply-To: <640461.89929.qm@web30808.mail.mud.yahoo.com> References: <640461.89929.qm@web30808.mail.mud.yahoo.com> Message-ID: <47BDCEFF.1010500@imageworks.com> Ben Butler-Cole wrote: > Hello > > I was surprised to be unable to find anything like this in the standard libraries: > > times :: (a -> a) -> Int -> (a -> a) > times f 0 = id > times f n = f . (times f (n-1)) > > Am I missing something more general which would allow me to repeatedly apply a function to an input? Or is this not useful? Invariably, this seems to invite a stack overflow when I try this (and is usually much slower anyway). Unless f is conditionally lazy, f^n and f will have the same strictness, so there is no point in keeping nested thunks. If you apply f immediately to x, there is no stack explosion and faster runtime: times :: (a -> a) -> Int -> (a -> a) times f !n !x | n > 0 = times f (n-1) (f x) | otherwise = x Dan From dave at zednenem.com Thu Feb 21 14:28:32 2008 From: dave at zednenem.com (David Menendez) Date: Thu Feb 21 14:26:41 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <2608b8a80802210954rb164189oa265cf5a23f2f468@mail.gmail.com> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> <2608b8a80802210954rb164189oa265cf5a23f2f468@mail.gmail.com> Message-ID: <49a77b7a0802211128i30014c17pd61141eaea072da2@mail.gmail.com> On Thu, Feb 21, 2008 at 12:54 PM, Yitzchak Gale wrote: > Duncan Coutts wrote: > >> To be honest I like the fact that haddock's markup is really simple and > >> perhaps somewhat restrictive. A great improvement though would be... > > >> a generic backend that spits out > >> the info that haddock gathers in a machine readable format. > > > Alistair Bayley wrote: > > I have probably misunderstood both of you, but I think that Conal > > proposed that Haddock *input* syntax is largely unchanged; Haddock > > should be able to *output* markdown, for consumption by pandoc. > > Perhaps, but I don't think "markdown", or any other > presentation format, is right for that. Markdown is not really a presentation format. It's an authoring format which "allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML)." (from ) Pandoc apparently generalizes this, allowing you to use the Markdown syntax to produce other forms of output. I'm not sure what it does with embedded XHTML, which Markdown allows (and which is necessary if you want to do things like tables). Markdown is more powerful than Haddock, and (for me, at least) easier to read. I'd love to see it used for Haskell code documentation, but I don't see it happening. -- Dave Menendez From gale at sefer.org Thu Feb 21 15:24:39 2008 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 21 15:22:48 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <49a77b7a0802211128i30014c17pd61141eaea072da2@mail.gmail.com> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> <2608b8a80802210954rb164189oa265cf5a23f2f468@mail.gmail.com> <49a77b7a0802211128i30014c17pd61141eaea072da2@mail.gmail.com> Message-ID: <2608b8a80802211224p5a860276q5d53feb82540c019@mail.gmail.com> David Menendez wrote: > Markdown is not really a presentation format. > It's an authoring format Its primary design goal is to be easy to read, not easy to parse. That's why I consider it a presentation format, Anyway, it's not suitable for use as API markup. The whole point is that you want to add metadata indicating how various pieces of your content relate to various pieces of Haskell syntax. You would have to add special markup, in which case you would get, well, Haddock. Or you could extend markdown's embedded HTML facility to accept other tags for that purpose - but then your content would be less readable than Haddock, not more readable. (Though that is the direction taken by C#.) I'm happy with Haddock's input syntax. It's quite readable, and simple enough. And it's similar to many other API markup systems for other languages, so many people feel comfortable with it right from the start. Regards, Yitz From ryani.spam at gmail.com Thu Feb 21 17:15:09 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Feb 21 17:13:27 2008 Subject: [Haskell-cafe] Selecting Array type In-Reply-To: <7665bf90802202248n568647f6y74e58d3be7f10144@mail.gmail.com> References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> <2f9b2d30802191839m3c8aaf7aw789250a99a8e2254@mail.gmail.com> <7665bf90802202248n568647f6y74e58d3be7f10144@mail.gmail.com> Message-ID: <2f9b2d30802211415w6f15cbcexa24f026b0fe5053d@mail.gmail.com> On 2/20/08, Jeff ? wrote: > -- SURPRISE 1: If function, arrTypeCast, is removed, (from both > -- the class and instance) GHC assumes the kind of a and b are *, > -- instead of * -> * -> * and produce . . . > -- > -- report3.hs:37:24: > -- `UArray' is not applied to enough type arguments > -- Expected kind `*', but `UArray' has kind `* -> * -> *' > -- In the type `(ArrTypeCast a UArray, IArray a Bool) => > -- SmartArraySelector a Bool' > -- In the instance declaration for `SmartArraySelector a Bool' > -- > -- It appears that functions defined in a class can constrain the > -- type variables of the class. To me, this seems a bit magical > -- and unexpected. That's correct; GHC is doing "kind inference" but defaults to * if it can't decide otherwise. Try this instead: > class ArrTypeCast (a :: * -> * -> *) (b :: * -> * -> *) | a -> b, b->a > instance ArrTypeCast x x You can do the same for SmartArraySelector but then you need the IArray constraint elsewhere; otherwise, smartArray can't call array. > I'd love to find a good article that describes the ins and outs of multi > parameter types, functional dependencies, and type assertions, in enough > detail to resolve these surprises. A step-by-step walk through showing how > the compiler resolve a type and selects an instance would be awesome. Me too. I don't really know how this code works either :) It seems like the functional dependency is still broken by ALL of the declarations; remember that the instance head determines what instances it defines, and we are specifying that ANY type a can be specified as SmartArraySelector a Bool, as long as we introduce the additional constraint of ArrTypeCast a UArray. This is in contrast to the functional dependency which states that the element type (Bool) uniquely determines the array type (some type a?). Here's an even smaller version of this file, using GHC 6.8.2 and type equality constraints: {-# LANGUAGE UndecidableInstances, OverlappingInstances, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, TypeFamilies #-} module SmartArray where import Data.Array.Unboxed class IArray a e => SmartArraySelector a e | e -> a instance a ~ UArray => SmartArraySelector a Bool instance a ~ UArray => SmartArraySelector a Char instance a ~ UArray => SmartArraySelector a Double instance a ~ UArray => SmartArraySelector a Float instance a ~ UArray => SmartArraySelector a Int instance a ~ Array => SmartArraySelector a b test :: SmartArraySelector a e => e -> a Int e test e = array (0,10) [ (i,e) | i <- [0..10]] I wouldn't be surprised if using these features together somehow makes the type checker inconsistent! -- ryan From duncan.coutts at worc.ox.ac.uk Thu Feb 21 17:44:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 17:42:39 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <90889fe70802210437o24928265i13803e0d1dacce7@mail.gmail.com> References: <90889fe70802210106o541e81cfx7bebc5d43c74bf91@mail.gmail.com> <1203590236.3076.43.camel@localhost> <90889fe70802210437o24928265i13803e0d1dacce7@mail.gmail.com> Message-ID: <1203633869.3076.77.camel@localhost> On Thu, 2008-02-21 at 13:37 +0100, Johan Tibell wrote: > I would be very happy if people didn't use the .Char8 versions of > ByteString except for being able to write byte literals using pack. (I > would be even happier if Haskell had byte literals.) If people start > using ByteString in their library interfaces instead of String I'll be > really miserable because I can't really use their libraries for > writing applications that need to be internationalized because their > libraries would be limited to ASCII. > > Data.ByteString and Data.ByteString.Char8 uses the same ByteString > type so I can take some bytes in UTF-32 which I read from the network > and use Data.ByteString.Char8 functions on them which will fail. I > prefer that a type that represent characters is guarded by encode and > decode functions. If that's not the case it's easy to mix data in > different encodings by mistake when e.g. writing web applications > which involve data in several different encodings. The intention of allowing both views on one data type was to support the myriad of mixed ascii / binary protocols with a minimum of fuss (there are loads of network protocols like this). The intention was never to support Unicode like String does. That's why we called it Char8, not Char. I do accept that because the Unicode version has not appeared yet people have been tempted to use ByteString for text, which is not appropriate. Duncan From johan.tibell at gmail.com Thu Feb 21 17:35:59 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu Feb 21 18:01:48 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <7BFF453C-67EB-4243-ADFD-D384B7BA870C@googlemail.com> References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> <1203589310.3076.31.camel@localhost> <20080221142638.GA6011@twifkak.com> <90889fe70802210935k5080840ey7b2e1a407e9c08e9@mail.gmail.com> <7BFF453C-67EB-4243-ADFD-D384B7BA870C@googlemail.com> Message-ID: <90889fe70802211435g4b3d2fa0o346eb385916c649e@mail.gmail.com> On Thu, Feb 21, 2008 at 6:58 PM, Thomas Schilling wrote: > > On 21 feb 2008, at 18.35, Johan Tibell wrote: > > > > I switched from lazy bytestrings to a left fold in my networking code > > after reading what Oleg wrote about streams vs folds. No problems with > > handles, etc. anymore. > > > > Do you fold over chunks? Yes. > Can you continue to use Parsek or other > utilities that need a stream-abstraction, and if so, how do you > handle the end of a chunk. I don't think so. I'm writing an incremental bytestring parser. > This is the kind of callback interface > where lazy evaluation really abstracts things nicely. Streams are a nice abstraction however they don't work well in a server. -- Johan From duncan.coutts at worc.ox.ac.uk Thu Feb 21 18:34:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 18:32:47 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: References: <47BCE530.2030607@cse.unsw.edu.au> <1203590445.3076.46.camel@localhost> Message-ID: <1203636855.3076.113.camel@localhost> On Thu, 2008-02-21 at 13:34 +0100, Henning Thielemann wrote: > I suppose we mean the same. My question is: Why do we use ByteString > instead of [Word8] ? Entirely because of efficiency, right? So if we could > stick to List code and only convert to ByteString at the end and the > compiler all rewrites it to ByteString code, then we would not need > libraries that are specialised to ByteString, but they can use [Word8] > instead. Yeah if we could do that it'd be great. I've suggested similar things as extensions of our work on streams. If we know the list is being used fully strictly then we could have replaced it with a stricter data structure. Even if we could do that I'm not sure we'll ever get to the situation where it's fully automatic because some operations on array like things are slower than lists, like consing, so even if we discover that we're using our lists strictly it does not follow that we could get any benefit from converting to arrays. I think we'll be stuck with separate list and stricter array types for some time to come. Duncan From duncan.coutts at worc.ox.ac.uk Thu Feb 21 18:57:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 18:55:48 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> Message-ID: <1203638260.3076.124.camel@localhost> On Thu, 2008-02-21 at 13:12 +0000, Alistair Bayley wrote: > On 21/02/2008, Duncan Coutts wrote: > > > > To be honest I like the fact that haddock's markup is really simple and > > perhaps somewhat restrictive. A great improvement though would be to > > make it easy to extract the docs from haddock in a nice format so that > > the could be re-used in other contexts rather than just generating html > > api documentation. Haddock does have support for multiple backends, > > someone just needs to define and write a generic backend that spits out > > the info that haddock gathers in a machine readable format. > > I have probably misunderstood both of you, but I think that Conal > proposed that Haddock *input* syntax is largely unchanged; Haddock > should be able to *output* markdown, for consumption by pandoc. > > (Which I think is also what you're suggesting.) Yes, I misunderstood, I though Conal was suggesting we extend the haddock input format to allow all the markdown notations. I'd rather not see different packages using different documentation dialects as it makes it much easier for people to contribute if we're all using the same language. I know there is a tension between richer markup for nicer presentation and keeping simple markup for ease of understanding and to present on limited medium like ghci or IDE tooltips. So IMHO we should consider syntactic extensions rather carefully. Though on that topic, we have no consensus as a community about what to use for tutorials or user guides. Consequently there is no support in Cabal etc for those kinds of documentation. GHC, Cabal and c2hs amongst others use docbook but it's a horrible format to write and the tools to process it are very finicky (we apparently have to hard code paths to specific versions of xslt stylesheets). Duncan From ben.franksen at online.de Thu Feb 21 19:13:10 2008 From: ben.franksen at online.de (Ben Franksen) Date: Thu Feb 21 19:14:57 2008 Subject: [Haskell-cafe] Re: Can't seem to get `par` working appropriately with lists References: <47BD674D.1080508@la.id.au> Message-ID: Luke Andrew wrote: > main = do print $ zipWith (+) (fiblist2 37 `par` fiblist1 37) > (fiblist2 37) > > compilation & testing: > > luke@Sonata:~/mcls$ ghc -O2 -threaded --make test2 > > luke@Sonata:~/mcls$ time ./test2 +RTS -N1 > [2,2,4,6,10,16,26,42... ...405774,18454930,29860704,48315634] > > real 0m15.294s > user 0m15.196s > sys 0m0.013s > > luke@Sonata:~/mcls$ time ./test2 +RTS -N2 > [2,2,4,6,10,16,26,42... ...405774,18454930,29860704,48315634] > > real 0m15.268s > user 0m15.169s > sys 0m0.013s This is due to lazyness: 'fiblist2 37' does not evaluate the whole resulting list, so the thread spawned by 'par' will almost immediately return. Take a look at Control.Parallel.Strategies, the 'parList' combinator is probably what you need here. To get a feel what this 'strategies' stuff is all about, it is a good idea to read (or at least skim over) the accompanying paper, just google for "Algorithm + Strategy = Parallelism". Cheers Ben From dons at galois.com Thu Feb 21 19:46:01 2008 From: dons at galois.com (Don Stewart) Date: Thu Feb 21 19:44:10 2008 Subject: [Haskell-cafe] Re: Can't seem to get `par` working appropriately with lists In-Reply-To: References: <47BD674D.1080508@la.id.au> Message-ID: <20080222004601.GB20384@scytale.galois.com> ben.franksen: > Luke Andrew wrote: > > main = do print $ zipWith (+) (fiblist2 37 `par` fiblist1 37) > > (fiblist2 37) > > > > compilation & testing: > > > > luke@Sonata:~/mcls$ ghc -O2 -threaded --make test2 > > > > luke@Sonata:~/mcls$ time ./test2 +RTS -N1 > > [2,2,4,6,10,16,26,42... ...405774,18454930,29860704,48315634] > > > > real 0m15.294s > > user 0m15.196s > > sys 0m0.013s > > > > luke@Sonata:~/mcls$ time ./test2 +RTS -N2 > > [2,2,4,6,10,16,26,42... ...405774,18454930,29860704,48315634] > > > > real 0m15.268s > > user 0m15.169s > > sys 0m0.013s > > This is due to lazyness: 'fiblist2 37' does not evaluate the whole resulting > list, so the thread spawned by 'par' will almost immediately return. > > Take a look at Control.Parallel.Strategies, the 'parList' combinator is > probably what you need here. To get a feel what this 'strategies' stuff is > all about, it is a good idea to read (or at least skim over) the > accompanying paper, just google for "Algorithm + Strategy = Parallelism". or 'rnf' on the result. rnf x `par` y is the basic "fully strict" strategy. From conal at conal.net Thu Feb 21 19:54:59 2008 From: conal at conal.net (Conal Elliott) Date: Thu Feb 21 19:53:09 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> Message-ID: I guess there was some confusion about the haddock-as-preprocessor idea. Here's another try: Pare the Haddock markup language down to very few markup directives, say just 'foo' and "Foo.Bar". (Of course, Haddock continues to read and process type signatures and module import & export specs.) Compose this slimmed down Haddock with a more mainstream and powerful markup language/processor like markdown/pandoc. How to compose? By having Haddock translate its markdown extensions into markdown and pass through all the rest. The goal redesigning for composability is that we get more for less. Haddock can focus on its speciality, namely hyperlinked Haskell code documentation, and pandoc on its, namely human-writable and -readable prose with modern features (images, friendly hyperlinks, smart quotes & dashes, footnotes, super- and subscripts, pretty math, bibliography-style link specs, etc). Haddock development can focus its resources on Haskell-specific functionality, and we library writers can still use a full-featured mark-up language. I love Haddock's Haskell-smarts, and I love (extended) markdown's features and usability. Currently, I have to choose between them, and I'd rather get both at once. We can take this composability idea further and plug in other nifty tools like hscolour and lhs2TeX. And a new tool that hyperlinks and annotates source code in a variety of ways. For instance, hover over an identifier to see its type and doc string in a pop-up, or click to jump to the source code (also annotated with type, doc, and source links). And other tools we haven't yet thought of. Cheers, - Conal On Thu, Feb 21, 2008 at 5:12 AM, Alistair Bayley wrote: > On 21/02/2008, Duncan Coutts wrote: > > > > To be honest I like the fact that haddock's markup is really simple and > > perhaps somewhat restrictive. A great improvement though would be to > > make it easy to extract the docs from haddock in a nice format so that > > the could be re-used in other contexts rather than just generating html > > api documentation. Haddock does have support for multiple backends, > > someone just needs to define and write a generic backend that spits out > > the info that haddock gathers in a machine readable format. > > I have probably misunderstood both of you, but I think that Conal > proposed that Haddock *input* syntax is largely unchanged; Haddock > should be able to *output* markdown, for consumption by pandoc. > > (Which I think is also what you're suggesting.) > > Alistair > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080221/ad3c2b9a/attachment.htm From duncan.coutts at worc.ox.ac.uk Thu Feb 21 20:37:54 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 21 20:36:02 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> Message-ID: <1203644274.3076.148.camel@localhost> On Thu, 2008-02-21 at 16:54 -0800, Conal Elliott wrote: > I guess there was some confusion about the haddock-as-preprocessor > idea. Here's another try: > > Pare the Haddock markup language down to very few markup directives, > say just 'foo' and "Foo.Bar". (Of course, Haddock continues to read > and process type signatures and module import & export specs.) > Compose this slimmed down Haddock with a more mainstream and powerful > markup language/processor like markdown/pandoc. How to compose? By > having Haddock translate its markdown extensions into markdown and > pass through all the rest. So the advantage of passing the rest through uninterpreted is that markdown then interprets it and we get lots of cool markup for free, the disadvantage is that we get lots more markup that I don't understand! :-) There really is something to be said for being able to download a random package, read the code at the documentation markup and be able to understand it and modify it. If it's a simple common language like we have at the moment we can do that. I worry about loosing that property. So yes we could make haddock not care so much and pass everything through and then people could do whatever they liked with new markup formats but I wonder if we cannot find a common language that we can all agree on. Are there any particularly cool things in markdown that lots of haskell developers want to use in their api documentation? Duncan From conal at conal.net Thu Feb 21 22:23:30 2008 From: conal at conal.net (Conal Elliott) Date: Thu Feb 21 22:21:38 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <1203644274.3076.148.camel@localhost> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> <1203644274.3076.148.camel@localhost> Message-ID: On Thu, Feb 21, 2008 at 5:37 PM, Duncan Coutts wrote: > So the advantage of passing the rest through uninterpreted is that > markdown then interprets it and we get lots of cool markup for free, the > disadvantage is that we get lots more markup that I don't > understand! :-) Thanks for this summary, Duncan. > There really is something to be said for being able to download a random > package, read the code at the documentation markup and be able to > understand it and modify it. If it's a simple common language like we > have at the moment we can do that. I worry about loosing that property. Have you looked at markdown? It's a popular and well-documented format and based on common conventions. I bet you'd have no trouble learning it, and I bet many other Haskell programmers *already* know it. (BTW, I just noticed that this mail message is in written in markdown.) > So yes we could make haddock not care so much and pass everything > through and then people could do whatever they liked with new markup > formats but I wonder if we cannot find a common language that we can all > agree on. Are there any particularly cool things in markdown that lots > of haskell developers want to use in their api documentation? My previous note listed some (pandoc-extended) markdown features I use regularly (while blogging) that are missing in Haddock. If I could, I'd use them in my code documentation. I'd like to hear from others about what markup features you'd like to have in your code documentation but aren't supported by Haddock. Cheers, - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080221/f24ebb35/attachment.htm From ryani.spam at gmail.com Thu Feb 21 22:36:34 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Thu Feb 21 22:34:43 2008 Subject: [Haskell-cafe] Selecting Array type In-Reply-To: <7665bf90802211722t39dcff6h702eed68fbab656@mail.gmail.com> References: <7665bf90802190749g7fa67fcdhb40e7117fd79d12b@mail.gmail.com> <2f9b2d30802191839m3c8aaf7aw789250a99a8e2254@mail.gmail.com> <7665bf90802202248n568647f6y74e58d3be7f10144@mail.gmail.com> <2f9b2d30802211415w6f15cbcexa24f026b0fe5053d@mail.gmail.com> <7665bf90802211722t39dcff6h702eed68fbab656@mail.gmail.com> Message-ID: <2f9b2d30802211936n4bf5004n4d20cd32b36355b3@mail.gmail.com> On 2/21/08, Jeff ? wrote: > Thanks again. I'm not familiar with type equality constraints. I could not > find information on this in the GHC users guide. Is it documented > somewhere? Section 7.3 here talks about equality constraints. http://www.haskell.org/haskellwiki/GHC/Indexed_types There's an extremely good paper talking about the low-level mechanisms for equality constraints in GHC Core here: http://research.microsoft.com/%7Esimonpj/papers/ext%2Df/ GHC Core -is- System Fc as described in that paper; the type equality constraints amount to a "coercion" function that is passed around the core language to convert between the types and which is statically guaranteed to be the identity function. > It is interesting that you were able to drop the IArray > constraint from the instances of SmartArraySelector. During compilation from Haskell to Core, the compiler implicitly adds calls to any available conversion functions it knows about as required to convert between types. This is why the IArray declaration can be dropped; the compiler looks at the coercions currently available, finds (a ~ UArray), and inserts a call that converts the existing "IArray UArray Bool" declaration into an "IArray a Bool" declaration. Determining that such a path exists is a search problem and much of the work with associated types and type equality constraints involves proving that the search is decidable. -- ryan From mpj at cs.pdx.edu Fri Feb 22 01:26:25 2008 From: mpj at cs.pdx.edu (Mark P Jones) Date: Fri Feb 22 01:24:32 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing In-Reply-To: References: <965491992.20080205132858@gmail.com> <8087A09F-3DA5-449A-A6DE-FEE67B177B10@ntlworld.com> <3d96ac180802050421x2795f633o48b4bbe2f336a851@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3183270FCF6@EA-EXMSG-C334.europe.corp.microsoft.com> <9CFEEB19-FCA9-46D2-B26A-15F4581697E2@ntlworld.com> <6AF00433-1BA0-4F85-B434-F094DC47C037@ntlworld.com> Message-ID: <47BE6B11.7060204@cs.pdx.edu> [Redirecting to haskell-cafe] Ben Franksen wrote: > TREX seems to be generally agreed to be too complicated to implement and > explain. What evidence do you have for this? Speaking as somebody who implemented Trex for Hugs (and who also witnessed Ben Gaster build an independent implementation), I'd have to disagree about the first part of this. As I recall, the implementation was reasonably straightforward, and wasn't any more complicated than other common type system extensions that I've worked on. I'm also not sure why you think it is complicated to explain, but I suppose that's even more subjective. One of the most difficult things about the Trex implementation was finding a syntax that meshed nicely with the rest of the Haskell syntax. This is likely to be a problem for any record system extension of Haskell---unless you're prepared to accept a more unconventional syntax---because many of the symbols that you might want to use ({, }, ., |, \, for example) have already been adopted for other purposes. Ah, syntax! All the best, Mark From jules at jellybean.co.uk Fri Feb 22 02:18:03 2008 From: jules at jellybean.co.uk (Jules Bean) Date: Fri Feb 22 02:16:14 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <7BFF453C-67EB-4243-ADFD-D384B7BA870C@googlemail.com> References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> <1203589310.3076.31.camel@localhost> <20080221142638.GA6011@twifkak.com> <90889fe70802210935k5080840ey7b2e1a407e9c08e9@mail.gmail.com> <7BFF453C-67EB-4243-ADFD-D384B7BA870C@googlemail.com> Message-ID: <47BE772B.7080608@jellybean.co.uk> Thomas Schilling wrote: > > On 21 feb 2008, at 18.35, Johan Tibell wrote: >> >> I switched from lazy bytestrings to a left fold in my networking code >> after reading what Oleg wrote about streams vs folds. No problems with >> handles, etc. anymore. >> > > Do you fold over chunks? Can you continue to use Parsek or other > utilities that need a stream-abstraction, and if so, how do you handle > the end of a chunk. This is the kind of callback interface where lazy > evaluation really abstracts things nicely. You can't call a stream-abstraction utility using a left-fold-enumerator without cheating (unsafeInterleave), because the stream-abstraction is incompatible (and leaky! even though it is convenient). You can convert in the other direction fine. Chunk are no problem, and convertible: you can build an element fold from a chunk fold, and a chunk fold from an element fold (as long as there is an 'end-of-input' marker). Jules From luke.haskell-cafe at la.id.au Fri Feb 22 03:06:45 2008 From: luke.haskell-cafe at la.id.au (Luke Andrew) Date: Fri Feb 22 03:04:57 2008 Subject: [Haskell-cafe] Can't seem to get `par` working appropriately with lists In-Reply-To: References: <47BD674D.1080508@la.id.au> Message-ID: <47BE8295.6040100@la.id.au> Felipe Lessa wrote: > On Thu, Feb 21, 2008 at 8:58 AM, Luke Andrew wrote: > >> test2.hs: >> >> import Control.Parallel >> >> fib1 n = if n == 0 then 0 else if n == 1 then 1 else fib1 (n-1) + >> fib1 (n-2) >> fib2 n = if n == 0 then 0 else if n == 1 then 1 else fib2 (n-1) + >> fib2 (n-2) >> fiblist1 n = [fib1 x| x <- [1..n]] >> fiblist2 n = [fib2 x| x <- [1..n]] >> >> main = do print $ zipWith (+) (fiblist2 37 `par` fiblist1 37) >> (fiblist2 37) >> > > Besides what Jules Bean said, note also that 'par' works a bit like > 'seq', only evaluating until WHNF. So even if you said > > main = > let f1 = fiblist1 37 > f2 = fiblist2 37 > in print $ zipWith (+) (f2 `par` f1) f2 > > you still wouldn't get what you want. Why? It only evaluates f1 and f2 > until it reaches [] or (_:_), and nothing more, it doesn't even try to > figure out that f2 is _:_:_:_:???:[] nor it tries to see that f2 is > 1:_, but you wanted that the parallel computation went until f2 was > 1:1:2:3:???:[]. > > To do that, force the list (i.e. do a "deep seq"). There's > Control.Parallel.Strategies to help you doing this, but if you want to > reimplement it, try > > force [] = () > force (x:xs) = x `seq` force xs > > main = > let f1 = fiblist1 37 > f2 = fiblist2 37 > in print $ zipWith (+) (force f2 `par` f1) f2 > > 'par' will try to see that 'force f2' is really (), but to do that > 'force' will go all the way down thru the list forcing its spine and > its values. > > HTH, > > Thanks Felipe, works as advertised. Guest I'm going to have to read up on WHNF, I just ignored it after my initial success & hoped it would continue to work. Guess I should have RTFM :) From nominolo at googlemail.com Fri Feb 22 03:31:06 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Fri Feb 22 03:29:16 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <47BE772B.7080608@jellybean.co.uk> References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> <1203589310.3076.31.camel@localhost> <20080221142638.GA6011@twifkak.com> <90889fe70802210935k5080840ey7b2e1a407e9c08e9@mail.gmail.com> <7BFF453C-67EB-4243-ADFD-D384B7BA870C@googlemail.com> <47BE772B.7080608@jellybean.co.uk> Message-ID: <48BB8144-D8A4-43E0-92C1-EDC414AC1DF3@googlemail.com> On 22 feb 2008, at 08.18, Jules Bean wrote: > Thomas Schilling wrote: >> On 21 feb 2008, at 18.35, Johan Tibell wrote: >>> >>> I switched from lazy bytestrings to a left fold in my networking >>> code >>> after reading what Oleg wrote about streams vs folds. No problems >>> with >>> handles, etc. anymore. >>> >> Do you fold over chunks? Can you continue to use Parsek or other >> utilities that need a stream-abstraction, and if so, how do you >> handle the end of a chunk. This is the kind of callback interface >> where lazy evaluation really abstracts things nicely. > > You can't call a stream-abstraction utility using a left-fold- > enumerator without cheating (unsafeInterleave), because the stream- > abstraction is incompatible (and leaky! even though it is convenient). > > You can convert in the other direction fine. > > Chunk are no problem, and convertible: you can build an element > fold from a chunk fold, and a chunk fold from an element fold (as > long as there is an 'end-of-input' marker). Hm, thinking about it, parsers just need to be able to return a continuation instead of fail at the end of the input. This continuation can then be invoked with the next chunk as input. From johan.tibell at gmail.com Fri Feb 22 03:59:49 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri Feb 22 03:57:55 2008 Subject: [Haskell-cafe] The Proliferation of List-Like Types In-Reply-To: <48BB8144-D8A4-43E0-92C1-EDC414AC1DF3@googlemail.com> References: <1203549214.3076.4.camel@localhost> <200802201901.46890.jgoerzen@complete.org> <1203589310.3076.31.camel@localhost> <20080221142638.GA6011@twifkak.com> <90889fe70802210935k5080840ey7b2e1a407e9c08e9@mail.gmail.com> <7BFF453C-67EB-4243-ADFD-D384B7BA870C@googlemail.com> <47BE772B.7080608@jellybean.co.uk> <48BB8144-D8A4-43E0-92C1-EDC414AC1DF3@googlemail.com> Message-ID: <90889fe70802220059p79d2df5cg6153d702f18a1e59@mail.gmail.com> On Fri, Feb 22, 2008 at 9:31 AM, Thomas Schilling wrote: > On 22 feb 2008, at 08.18, Jules Bean wrote: > > > > You can't call a stream-abstraction utility using a left-fold- > > enumerator without cheating (unsafeInterleave), because the stream- > > abstraction is incompatible (and leaky! even though it is convenient). > > > > You can convert in the other direction fine. > > > > Chunk are no problem, and convertible: you can build an element > > fold from a chunk fold, and a chunk fold from an element fold (as > > long as there is an 'end-of-input' marker). > > Hm, thinking about it, parsers just need to be able to return a > continuation instead of fail at the end of the input. This > continuation can then be invoked with the next chunk as input. This is what I'll do and it is also what binary-strict's [1] IncrementalGet parser does. 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict-0.3.0 -- Johan From gale at sefer.org Fri Feb 22 06:25:29 2008 From: gale at sefer.org (Yitzchak Gale) Date: Fri Feb 22 06:23:38 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <1203644274.3076.148.camel@localhost> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> <1203644274.3076.148.camel@localhost> Message-ID: <2608b8a80802220325q118e97e7x6d7ed48f1c707ac8@mail.gmail.com> Conal Elliott wrote: > Pare the Haddock markup language down to > very few markup directives, say just 'foo' and > "Foo.Bar". Other critical ones: -- | This shows which syntax this text describes. -- ^ So does this. Less critical, but usually not provided by general markup languages: -- $doc A movable documentation chunk. If Haddock itself does not parse any other markup, we must make sure to use markup that does not lock up its information. It should be something we have a parser for, or something that has good tools for turning it into some robust machine-readable format in a lossless way. The reason is that I may want to use a bit of Haskell in a much larger project that uses some other markup system for its API documentation. So, for example, if I want to integrate the output into a larger DITA project, there should be an easy way to do that. Or Doxygen, or whatever else. Then Haddock would need to have some way of outputting its own information nicely, with embedded chunks of markup. You would read that, passing each chunk of markup through its parser. Truth is, I don't see any such parser for "markdown". Do you know of one? Maybe we would have to write one. I think that improving the markup capabilities of Haddock is a minor issue. The main value of Haddock is its API metadata. Haddock currently keeps most of that in its bellly, using it secretly to create its own presentation output. The biggest improvement would be getting meaningful machine-readable output. Your idea of abstracting out the markup could actually make that easier, if we keep that goal in mind as well. Thanks, Yitz From tom.davie at gmail.com Fri Feb 22 07:22:37 2008 From: tom.davie at gmail.com (Thomas Davie) Date: Fri Feb 22 07:20:58 2008 Subject: [Haskell-cafe] Doubting Haskell In-Reply-To: <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> References: <56a54d4d0802161405l774ff97djada856fbccdb8b08@mail.gmail.com> <89ca3d1f0802190648s230c67cet40a9612397dd482f@mail.gmail.com> <56a54d4d0802191727h4a2a64a3xcd532ccf86e5a9a@mail.gmail.com> <89ca3d1f0802200158g5f1b884eua5b4ea5634471d9b@mail.gmail.com> Message-ID: <04BBD82D-E663-410E-9F5E-09A2B0129405@gmail.com> A quick note here. This is a *really* excellent tutorial on a variety of subjects. It shows how monad operators can be used responsibly (to clarify code, not obfuscate it), it shows how chosing a good data structure and a good algorithm can work wonders for your code, and on a simplistic level, it shows how to build a database in Haskell. Would it be possible to clean this up and put it in the wiki somewhere? Thanks Bob On 20 Feb 2008, at 09:58, Cale Gibbard wrote: > (I'm copying the list on this, since my reply contains a tutorial > which might be of use to other beginners.) > > On 19/02/2008, Alan Carter wrote: >> Hi Cale, >> >> On Feb 19, 2008 3:48 PM, Cale Gibbard wrote: >>> Just checking up, since you haven't replied on the list. Was my >>> information useful? Did I miss any questions you might have had? If >>> you'd like, I posted some examples of using catch here: >> >> Thanks for your enquiry! My experiment continues. I did put a >> progress >> report on the list - your examples together with a similar long an >> short pair got me over the file opening problem, and taught me some >> things about active whitespace :-) I couldn't get withFile working >> (says out of scope, maybe 'cos I'm ghc 6.6 on my Mac) > > Make sure to put: > > import System.IO > > at the top of your source file, if you haven't been. This should > import everything documented here: > http://www.haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html > >> but it turned out the line I was looking for (collapsed from the >> examples) >> was: >> >> text <- readFile "data.txt" `catch` \_ -> return "" >> >> This ensures the program never loses control, crashing or becoming >> unpredictable by attempting to use an invalid resource, by yielding >> an >> empty String if for any reason the file read fails. Then an empty >> String makes it very quickly through parsing. I guess that's quite >> "functiony" :-) >> >> Amazing how easy once I knew how. Even stranger that I couldn't >> find a >> "bread and butter" example of it. >> >> Then I was going very quickly for a while. My file is dumped from a >> WordPress MySql table. Well formed lines have 4 tab separated fields >> (I'm using pipes for tabs here): >> >> line id | record id | property | value >> >> Line IDs are unique and don't matter. All lines with the same record >> ID give a value to a property in the same record, similar to this: >> >> 1|1|name|arthur >> 2|1|quest|seek holy grail >> 3|1|colour|blue >> 4|2|name|robin >> 5|2|quest|run away >> 6|2|colour|yellow >> >> Organizing that was a joy. It took minutes: > > let cutUp = tail (filter (\fields -> (length fields) == 4) > (map (\x -> split x '\t') > (lines text))) > > This should almost certainly be a function of text: > > cutUp text = tail (filter (\fields -> (length fields) == 4) > (map (\x -> split x '\t') (lines > text))) > >> I found a split on someone's blog (looking for a library tokenizer), >> but I can understand it just fine. I even get to chuck out ill-formed >> lines and remove the very first (which contains MySql column names) >> on >> the way through! > > Sadly, there's no general library function for doing this. We have > words and lines (and words would work here, if your fields never have > spaces), but nobody's bothered to put anything more general for simple > splitting into the base libraries (though I'm sure there's plenty on > hackage -- MissingH has a Data.String.Utils module which contains > split and a bunch of others, for example). However, for anything more > complicated, there are also libraries like Parsec, which are generally > really effective, so I highly recommend looking at that at some point. > >> I then made a record to put things in, and wrote some lines to play >> with it (these are the real property names): >> >> data Entry = Entry >> { occupation :: String >> , iEnjoyMyJob :: Int >> , myJobIsWellDefined :: Int >> , myCoworkersAreCooperative :: Int >> , myWorkplaceIsStressful :: Int >> , myJobIsStressful :: Int >> , moraleIsGoodWhereIWork :: Int >> , iGetFrustratedAtWork :: Int >> } >> ... >> let e = Entry{occupation = "", iEnjoyMyJob = 0} >> let f = e {occupation = "alan"} >> let g = f {iEnjoyMyJob = 47} >> putStrLn ((occupation g) ++ " " ++ (show (iEnjoyMyJob g))) >> >> Then I ran into another quagmire. I think I have to use Data.Map to >> build a collection of records keyed by record id, and fill them in by >> working through the list of 4 item lists called cutUp. As with the >> file opening problem I can find a few examples that convert a list of >> tuples to a Data.Map, one to one. I found a very complex example that >> convinced me a map from Int to a record is possible, but gave me no >> understanding of how to do it. I spent a while trying to use foldl >> before I decided it can't be appropriate (I need to pass more >> values). >> So I tried a couple of recursive functions, something like: >> >> type Entries = M.Map Int Entry >> ... >> let entries = loadEntries cutUp >> ... >> loadEntries :: [[String]] -> Entries >> loadEntries [] = M.empty Entries >> loadEntries [x : xs] = loadEntry (loadEntries xs) x > -- Possible common beginner error here: [x:xs] means the list with one > element which is a list whose first element is x and whose tail is xs. > Your type signature and the type of cutUp seems to confirm that this > is the right type, but you don't seem to have a case to handle a > longer list of lists. If you want just a list with first entry x, and > with tail xs, that's just (x:xs). If you want to handle lists of lists > recursively, you'll generally need two cases: ([]:xss) and > ((x:xs):xss). We'll end up doing something different instead of > recursion in a moment. >> >> loadEntry entries _ rid fld val = entries >> >> Trying to create an empty map at the bottom of the recursion so later >> I can try to fiddle about checking if the key is present and >> crating a >> new record otherwise, then updating the record with a changed one (a >> big case would be needed deep in to do each property update). If I'm >> on the right track it's not good enough to get better, so now I'm >> just >> throwing bits of forest animals into the pot at random again :-( >> >> So I certainly would be grateful for a clue! The bits I can do (I got >> a non-trivial wxHaskell frame sorted out quite easily, the tokenizing >> and record bit were OK) I think show I'm not *totally* stupid at >> this, >> I'm putting loads of time investment in (it's an experiement in >> itself) but there do seem to be certain specific things that would be >> ubiquitous patterns in any production or scripting environment, which >> are not discussed at all and far from obvious. The more I see of >> Haskell the more I suspect this issue is the gating one for popular >> uptake. >> >> I couldn't help thinking of this bit, from the Wikipedia entry on the >> Cocteau Twins: >> >> "The band's seventh LP, Four-Calendar Caf?, was released in late >> 1993. >> It was a departure from the heavily-processed, complex and layered >> sounds of Blue Bell Knoll and Heaven or Las Vegas, featuring clearer >> and more minimalistic arrangements. This, along with the record's >> unusually comprehensible lyrics, led to mixed reviews for the album: >> Some critics accused the group of selling out and producing an >> 'accessible album,' while others praised the new direction as a >> felicitous development worthy of comparison with Heaven or Las >> Vegas." >> >> Best wishes, >> >> Alan > > I woke up rather early, and haven't much to do, so I'll turn this into > a tutorial. :) > > Okay. The most common ways to build a map are by using the fromList, > fromListWith, or fromListWithKey functions. You can see them in the > documentation here: > > http://www.haskell.org/ghc/docs/latest/html/libraries/containers/Data-Map.html#v%3AfromList > > The types are: > > fromList :: (Ord k) => [(k,a)] -> Map k a > > fromListWith :: (Ord k) => (a -> a -> a) -> [(k,a)] -> Map k a > > fromListWithKey :: (Ord k) => (k -> a -> a -> a) -> [(k,a)] -> Map k a > > They take a list of (key,value) pairs, and build a map from it. > Additionally, the fromListWith function takes a function which > specifies how the values should be combined if their keys collide. > There is also a fromListWithKey function which allows the means of > combination to depend on the key as well. > > At this point we realise something interesting about the way the data > is being represented: if there is a field in someone's record with no > row in the database, what should the resulting field contain? In C, > they often use some integer which is out of range, like -1 for this. > > How about for a missing occupation field? Well, that's a String, you > could use some generic failure string, or an empty string, but I'll > show you another possibility that just might be convenient. > > If t is any type, then the type (Maybe t) consists of the values > Nothing, and Just x, whenever x is a value of type t. This is another > convenient way to represent the idea that a computation might fail. > > Let's start by changing your record type so that each field is a Maybe > value, that is, either the value Nothing, or the value Just x, where x > is the value it would have been. > > data Entry = Entry > { occupation :: Maybe String > , iEnjoyMyJob :: Maybe Int > , myJobIsWellDefined :: Maybe Int > , myCoworkersAreCooperative :: Maybe Int > , myWorkplaceIsStressful :: Maybe Int > , myJobIsStressful :: Maybe Int > , moraleIsGoodWhereIWork :: Maybe Int > , iGetFrustratedAtWork :: Maybe Int > } > > There's a very general function in the module Control.Monad which I'd > like to use just for the Maybe type here. It's called mplus, and for > Maybe, it works like this: > > mplus (Just x) _ = Just x > mplus Nothing y = y > > So if the first parameter isn't Nothing, that's what you get, > otherwise, you get the second parameter. Of course, this operation has > an identity element which is Nothing. > > So this lets you combine partial information expressed by Maybe types, > in a left-biased way. > > It's about to become obvious that record types are less convenient > than perhaps they could be in Haskell, and this is absolutely true -- > I'd actually probably use a somewhat different representation myself > (possibly something involving a Map from Strings (field names) to Int > values), but I can't really be sure what you intend with this data, > and how much type safety you want. > > I'll elide the field names just because I can here. It's not > necessarily good style. > > combine :: Entry -> Entry -> Entry > combine (Entry a1 a2 a3 a4 a5 a6 a7 a8) (Entry b1 b2 b3 b4 b5 b6 b7 > b8) > = Entry (a1 `mplus` b1) (a2 `mplus` b2) (a3 `mplus` b3) (a4 > `mplus` b4) > (a5 `mplus` b5) (a6 `mplus` b6) (a7 `mplus` b7) (a8 > `mplus` b8) > > Even with all the shorthand, this is pretty ugly (and I'll show how > I'd represent the data in a moment), but what this does is to combine > two partial entries, favouring the information in the > first, but filling the holes in the first with data from the second. > This operation has an identity element, which is: > > emptyEntry = Entry Nothing Nothing Nothing Nothing Nothing Nothing > Nothing Nothing > > Let's try a different representation, which is a little more flexible, > but expresses less in the type system. > > data Entry = Entry { occupation :: Maybe String, survey :: M.Map > String Int } > deriving (Eq, Ord, Show) > > So now, instead of a bunch of separate Maybe Int fields, we have just > one Map from String to Int. If we don't have information for a field, > we simply won't have that key in the Map. Of course, this means we'll > have to use strings for field labels. If that seems unhappy, you could > always define a type like: > > data SurveyQuestion = IEnjoyMyJob > | MyJobIsWellDefined > | MyCoworkersAreCooperative > | MyWorkplaceIsStressful > | MyJobIsStressful > | MoraleIsGoodWhereIWork > | IGetFrustratedAtWork > deriving (Eq, Ord, Show) > > to be used in place of the String type. > > Let's see how combine will look now: > > combine :: Entry -> Entry -> Entry > combine (Entry o1 s1) (Entry o2 s2) = Entry (o1 `mplus` o2) (s1 > `M.union` s2) > > Or, using the record syntax more: > > combine :: Entry -> Entry -> Entry > combine e1 e2 = Entry { occupation = (occupation e1 `mplus` > occupation e2), > survey = (survey e1 `M.union` survey e2) } > > Again, this new version has an identity with respect to combine, > which is: > > emptyEntry = Entry {occupation = Nothing, survey = (M.empty)} > > Now, we just need a way to take one of your rows, and turn it into a > (key,value) pair, where the value is a partial entry. > > readRow :: [String] -> (Int, Entry) > readRow [n, k, "occupation", v] = (read k, emptyEntry { occupation = > Just v }) > readRow [n, k, f, v] = (read k, emptyEntry { survey = M.singleton f > (read v) }) > readRow xs = error "failure case, should never happen!" > > There is actually a failure case that I'm not handling here, which is > what happens when the value or key fails to parse as an Int. For that > we'd use reads instead of read, but let's ignore it for now. > > We can then map this function over our cut up rows, something along > the lines of: > > map readRow (cutUp text) > > at which point we'll have a list of (Int, Entry) pairs. > > We then want to fill up our Entries Map with those, and we want to > combine them as we go using the combine function: > > entryMap text = M.fromListWith combine (map readRow (cutUp text)) > > Some final changes we could consider would be putting more of the > error handling into readRow itself: if it was to return a singleton > Map rather than an (Int, Entry) pair, then it could return the empty > Map on failure, and the results would then be combined using the > function M.unionsWith combine. We could move the length 4 test out of > cutUp then, and just make it the fall-through case in readRow. I'll > also use reads, which returns a list of (parse,rest-of-string) pairs, > to handle the failure cases where the numbers don't parse, by just > treating those rows as nonexistent: > > readRow :: [String] -> M.Map Int Entry > readRow [n, k, f, v] = > case reads k of > [] -> M.empty -- the key didn't parse > (k',_):_ -> > if f == "occupation" > then M.singleton k' (emptyEntry { occupation = Just v }) > else case reads v of > [] -> M.empty -- the value didn't parse > (v',_):_ -> M.singleton k' > (emptyEntry { survey = > M.singleton f v' }) > readRow xs = M.empty -- this handles the case when the list is any > length but 4 > > cutUp text = tail (map (\x -> split x '\t') (lines text)) -- which > allows cutUp to be simpler > > entryMap text = M.unionsWith combine (map readRow (cutUp text)) > > Anyway, I hope this tutorial gives some idea of how things progress, > and what sort of thinking is generally involved. Note that the focus > here was more on finding the right combining operations, and then > using pre-existing higher-order functions to collapse the structure, > than it was on recursion. From topekarem at gmail.com Fri Feb 22 08:47:58 2008 From: topekarem at gmail.com (TOPE KAREM) Date: Fri Feb 22 08:46:04 2008 Subject: [Haskell-cafe] Tips of Conditional Expression Message-ID: <3717bcc50802220547s551d0b02i8c36df88b3bc0a18@mail.gmail.com> I know the following: [1] That the general form of conditional expression is: if * Boolean_expression* then *exp1* else *exp2 *[2] That a conditional expression must always have both a then and an elseexpression. [3] That both *exp1* and *exp2* must have the same type, which is the type of the entire conditional expression. [4] That *exp1* must be and *exp2* must be Reference: Discrete Mathematics Using Computer by John O'Donnell and et al. (Second Edition) My question: Is it possible that exp1 and exp 2 be different function calls of another functions (separately) elsewhere within the same program? Note: My Boolean_expression is Boolean My *exp1* is a function call elsewhere within the same program (more like a subroutine) My *exp2* is another function call also elsewhere within the same program. Tope South Africa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080222/c8316b1e/attachment.htm From Christian.Maeder at dfki.de Fri Feb 22 09:04:30 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Feb 22 09:02:38 2008 Subject: [Haskell-cafe] Re: Tips of Conditional Expression In-Reply-To: <3717bcc50802220547s551d0b02i8c36df88b3bc0a18@mail.gmail.com> References: <3717bcc50802220547s551d0b02i8c36df88b3bc0a18@mail.gmail.com> Message-ID: <47BED66E.1020001@dfki.de> TOPE KAREM wrote: > I know the following: > > [1] That the general form of conditional expression is: if > *Boolean_expression* then /exp1/ else /exp2 > /[2] That a conditional expression must always have both a then and an > else expression. > [3] That both /exp1/ and /exp2/ must have the same type, which is the > type of the entire conditional expression. > [4] That /exp1/ must be and /exp2/ must be > > Reference: Discrete Mathematics Using Computer by John O'Donnell and et > al. (Second Edition) > > My question: Is it possible that exp1 and exp 2 be different function > calls of another functions (separately) elsewhere within the same program? > Note: My Boolean_expression is Boolean > My /exp1/ is a function call elsewhere within the same program > (more like a subroutine) > My /exp2/ is another function call also elsewhere within the > same program. I'm not sure what you're asking, but exp1 and exp2 may have (the same) function type: if then map else filter :: (Bool -> Bool) -> [Bool] -> [Bool] HTH Christian From jefferson.r.heard at gmail.com Fri Feb 22 09:15:43 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Fri Feb 22 09:13:50 2008 Subject: [Haskell-cafe] Tutorial for using the state monad or a better suggestion? Message-ID: <4165d3a70802220615s5799339ex30d4c71d0f1916c4@mail.gmail.com> So the reason I keep pinging the list so much of late is I'm currently writing a GLUT program to visualize a heirarchical clustering of 18,000+ protein-protein interaction pairs (and associated gene-ontology terms). Thanks for the help on reading CSVs, those who wrote me back... my program intitializes and displays its first image within 6 seconds, about 10 times faster and in 10 times less memory than the Java program the guy was using. Now I'm to the point of making this thing interactive, and I I'm trying to figure out the Haskell way of doing this. Last time I wrote a program like this, I made a record data type with all the state and placed it into an IORef and curried it into the GLUT callback functions. I'm going to do the same thing now if there aren't cringes and wailings from people with a better sense of pure-functional aesthetics out there on the list with a willingness to either point me towards a tutorial that would help me do this better. Keep in mind that Graphics.UI.GLUT callbacks all want to return an IO (), and thus leftover state monads at ends of functions aren't going to be acceptable to the standard library... Any ideas? Oh, currently my program state includes: The geometry I'm rendering (Ptr GLfloat vertex and color arrays), The same geometry as a display list for rendering into the selection buffer An indexed and named tree that represents the clustering A tree of text containing tooltips to display The previous current mouse position (for dragging purposes) A couple of histograms as Array.IArray.Diff.DiffArrays Various parameters for constructing rendered data out of the indexed tree (for reconstruction after a node is collapsed/expanded) So I'm carrying around some pretty bulky state; should give you some understanding as to why I thougt the record data type would be the sanest way to do this without polluting my parameter list with individual IORrefs. Oh, and again, it's not that I don't know that I can make the IORef solution work, I can and I've done it before. It's just that I thought there might be a prettier way to do this. Thanks in advance! -- Jeff From topekarem at gmail.com Fri Feb 22 09:22:51 2008 From: topekarem at gmail.com (TOPE KAREM) Date: Fri Feb 22 09:20:58 2008 Subject: [Haskell-cafe] Re: Tips of Conditional Expression In-Reply-To: <47BED66E.1020001@dfki.de> References: <3717bcc50802220547s551d0b02i8c36df88b3bc0a18@mail.gmail.com> <47BED66E.1020001@dfki.de> Message-ID: <3717bcc50802220622o3e2456b8n7e8dd2460d4dd3ea@mail.gmail.com> Thanks. My question is whether it can call a function (say map) previously defined elsewhere in the program. Same goes for filter. Tope On Fri, Feb 22, 2008 at 6:04 AM, Christian Maeder wrote: > TOPE KAREM wrote: > > I know the following: > > > > [1] That the general form of conditional expression is: if > > *Boolean_expression* then /exp1/ else /exp2 > > /[2] That a conditional expression must always have both a then and an > > else expression. > > [3] That both /exp1/ and /exp2/ must have the same type, which is the > > type of the entire conditional expression. > > [4] That /exp1/ must be and /exp2/ must be > > > > Reference: Discrete Mathematics Using Computer by John O'Donnell and et > > al. (Second Edition) > > > > My question: Is it possible that exp1 and exp 2 be different function > > calls of another functions (separately) elsewhere within the same > program? > > Note: My Boolean_expression is Boolean > > My /exp1/ is a function call elsewhere within the same program > > (more like a subroutine) > > My /exp2/ is another function call also elsewhere within the > > same program. > > I'm not sure what you're asking, but exp1 and exp2 may have (the same) > function type: > > if then map else filter :: (Bool -> Bool) -> [Bool] -> [Bool] > > HTH Christian > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080222/407a1fcb/attachment.htm From daniel.is.fischer at web.de Fri Feb 22 09:43:30 2008 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Fri Feb 22 09:40:04 2008 Subject: [Haskell-cafe] Re: Tips of Conditional Expression In-Reply-To: <3717bcc50802220622o3e2456b8n7e8dd2460d4dd3ea@mail.gmail.com> References: <3717bcc50802220547s551d0b02i8c36df88b3bc0a18@mail.gmail.com> <47BED66E.1020001@dfki.de> <3717bcc50802220622o3e2456b8n7e8dd2460d4dd3ea@mail.gmail.com> Message-ID: <200802221543.30205.daniel.is.fischer@web.de> Am Freitag, 22. Februar 2008 15:22 schrieb TOPE KAREM: > Thanks. My question is whether it can call a function (say map) previously > defined elsewhere in the program. Same goes for filter. > > Tope Like oddlyMakeEven [] = [] oddlyMakeEven ks@(k:_) = if odd k then map (*2) ks else filter even ks ? Sure, each branch can be an arbitrarily complex expression. HTH, Daniel From bit at mutantlemon.com Fri Feb 22 09:42:05 2008 From: bit at mutantlemon.com (Bit Connor) Date: Fri Feb 22 09:40:15 2008 Subject: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL In-Reply-To: <87wsp3x8rn.wl%jeremy.shaw@linspireinc.com> References: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com> <7ca3f0160802171726o789f61a1u2af22f270fd64127@mail.gmail.com> <87wsp3x8rn.wl%jeremy.shaw@linspireinc.com> Message-ID: <6205bd290802220642x2e3b1e5cq4c4622d7edfdcbc3@mail.gmail.com> I also have made haskell bindings to FreeType, including support for extracting glyph outlines. I haven't had time to publish it yet. Hopefully I'll get around to it soon. On Mon, Feb 18, 2008 at 5:07 AM, Jeremy Shaw wrote: > At Mon, 18 Feb 2008 01:26:17 +0000, > > Luke Palmer wrote: > > > I have an immature, but precise and picky implementation that renders text in > > a ttf font to an OpenGL texture (using SDL-ttf) here: > > http://svn.luqui.org/svn/misc/luke/work/code/haskell/frp/Fregl/Draw.hs > > (It may have some dependencies in the same directory). Text support is > > way at the bottom. > > Along the same lines, I have an imcomplete, but direct binding to > freetype and an incomplete binding to GLX which can be used to draw > text to opengl textures: > > http://n-heptane.com/nhlab/repos/haskell-freetype/ > http://n-heptane.com/nhlab/repos/haskell-glx/ > > This file contains an example of drawing text using GLX+FreeType: > > http://n-heptane.com/nhlab/repos/haskell-freetype/FreeTypeTest.hs > > This code has not been touched in a few years, so it probably needs > some updates to work with ghc 6.8. Also, I believe the X11 package now > has builtin support for ClientMessage, so that module can go away. > > j. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From aslatter at gmail.com Fri Feb 22 09:44:09 2008 From: aslatter at gmail.com (Antoine Latter) Date: Fri Feb 22 09:42:15 2008 Subject: [Haskell-cafe] Tutorial for using the state monad or a better suggestion? In-Reply-To: <4165d3a70802220615s5799339ex30d4c71d0f1916c4@mail.gmail.com> References: <4165d3a70802220615s5799339ex30d4c71d0f1916c4@mail.gmail.com> Message-ID: <694519c50802220644g28df0766wea1fbc3071367fc9@mail.gmail.com> I was trying to solve a similar problem while learning the FastCGI package. The regular CGI package allows the use of ReaderT to hold config data. Because FastCGI does the running of the passed in CGI action within a few calls to alloca :: (Ptr a -> IO b) -> IO b, I couldn't figure out a way to use monad transformers. I settled on the top-level IORef trick I've seen elsewhere: > bigBallOfState_ :: IORef MyState > bigBallOfState_ = unsafePerformIO $ newIORef emptyState > {-# NOINLINE bigBallOfState_ #-} With a few accessors: > setState :: MyState -> IO () > setState = ... > getState :: IO MyState > getState = ... I'm not going to pretend it's good style, and it assumes you only ever need one copy of the state everywhere in your program. -Antoine On Fri, Feb 22, 2008 at 8:15 AM, Jefferson Heard wrote: > So the reason I keep pinging the list so much of late is I'm currently > writing a GLUT program to visualize a heirarchical clustering of > 18,000+ protein-protein interaction pairs (and associated > gene-ontology terms). Thanks for the help on reading CSVs, those who > wrote me back... my program intitializes and displays its first image > within 6 seconds, about 10 times faster and in 10 times less memory > than the Java program the guy was using. > > Now I'm to the point of making this thing interactive, and I I'm > trying to figure out the Haskell way of doing this. Last time I wrote > a program like this, I made a record data type with all the state and > placed it into an IORef and curried it into the GLUT callback > functions. I'm going to do the same thing now if there aren't cringes > and wailings from people with a better sense of pure-functional > aesthetics out there on the list with a willingness to either point me > towards a tutorial that would help me do this better. Keep in mind > that Graphics.UI.GLUT callbacks all want to return an IO (), and thus > leftover state monads at ends of functions aren't going to be > acceptable to the standard library... > > Any ideas? Oh, currently my program state includes: > > The geometry I'm rendering (Ptr GLfloat vertex and color arrays), > The same geometry as a display list for rendering into the selection buffer > An indexed and named tree that represents the clustering > A tree of text containing tooltips to display > The previous current mouse position (for dragging purposes) > A couple of histograms as Array.IArray.Diff.DiffArrays > Various parameters for constructing rendered data out of the indexed > tree (for reconstruction after a node is collapsed/expanded) > > So I'm carrying around some pretty bulky state; should give you some > understanding as to why I thougt the record data type would be the > sanest way to do this without polluting my parameter list with > individual IORrefs. > > Oh, and again, it's not that I don't know that I can make the IORef > solution work, I can and I've done it before. It's just that I > thought there might be a prettier way to do this. > > Thanks in advance! > > -- Jeff > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From claus.reinke at talk21.com Fri Feb 22 10:13:46 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Fri Feb 22 10:11:57 2008 Subject: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL References: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com><7ca3f0160802171726o789f61a1u2af22f270fd64127@mail.gmail.com><87wsp3x8rn.wl%jeremy.shaw@linspireinc.com> <6205bd290802220642x2e3b1e5cq4c4622d7edfdcbc3@mail.gmail.com> Message-ID: <00cb01c87565$8665e2f0$71257ad5@cr3lt> [cc-ed to hopengl list; are there many haskell opengl users not on that list, btw?] a standard package for easy-to-use, high-quality, portable font support would make a great addition to haskell's otherwise nice opengl bindings! is there a reason for going directly to freetype? from the old opengl font survey at http://www.opengl.org/resources/features/fontsurvey/ i got the impression that accessing freetype2 via ftgl might make things slightly easier, while also offering more options (geometry instead of texture fonts), or did I misread? http://ftgl.wiki.sourceforge.net/ the source doesn't seem to have changed since the end of 2004, which might imply some issues with newer compilers, etc? has anyone tried to bind to ftgl? any comments on that route? and to what extent to the haskell gui libs with opengl support allow their fonts to be used for text geometry or textures in opengl? claus ----- Original Message ----- From: "Bit Connor" To: "Jeremy Shaw" Cc: "Haskell-cafe Cafe" Sent: Friday, February 22, 2008 2:42 PM Subject: Re: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL >I also have made haskell bindings to FreeType, including support for > extracting glyph outlines. > > I haven't had time to publish it yet. Hopefully I'll get around to it soon. > > On Mon, Feb 18, 2008 at 5:07 AM, Jeremy Shaw wrote: >> At Mon, 18 Feb 2008 01:26:17 +0000, >> >> Luke Palmer wrote: >> >> > I have an immature, but precise and picky implementation that renders text in >> > a ttf font to an OpenGL texture (using SDL-ttf) here: >> > http://svn.luqui.org/svn/misc/luke/work/code/haskell/frp/Fregl/Draw.hs >> > (It may have some dependencies in the same directory). Text support is >> > way at the bottom. >> >> Along the same lines, I have an imcomplete, but direct binding to >> freetype and an incomplete binding to GLX which can be used to draw >> text to opengl textures: >> >> http://n-heptane.com/nhlab/repos/haskell-freetype/ >> http://n-heptane.com/nhlab/repos/haskell-glx/ >> >> This file contains an example of drawing text using GLX+FreeType: >> >> http://n-heptane.com/nhlab/repos/haskell-freetype/FreeTypeTest.hs >> >> This code has not been touched in a few years, so it probably needs >> some updates to work with ghc 6.8. Also, I believe the X11 package now >> has builtin support for ClientMessage, so that module can go away. >> >> j. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From Christian.Maeder at dfki.de Fri Feb 22 10:17:37 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Feb 22 10:15:48 2008 Subject: [Haskell-cafe] Re: Tips of Conditional Expression In-Reply-To: <3717bcc50802220622o3e2456b8n7e8dd2460d4dd3ea@mail.gmail.com> References: <3717bcc50802220547s551d0b02i8c36df88b3bc0a18@mail.gmail.com> <47BED66E.1020001@dfki.de> <3717bcc50802220622o3e2456b8n7e8dd2460d4dd3ea@mail.gmail.com> Message-ID: <47BEE791.2040406@dfki.de> TOPE KAREM wrote: > Thanks. My question is whether it can call a function (say map) > previously defined elsewhere in the program. Same goes for filter. I'm still not sure what to answer. If map and filter were user defined functions they may occur anywhere in your current module (or must be imported) and you can apply any argument in scope (of proper type). You could i.e. apply "(if then map else filter)" to "id" which is the same as "if then map id else filter id" C. > On Fri, Feb 22, 2008 at 6:04 AM, Christian Maeder > > wrote: > I'm not sure what you're asking, but exp1 and exp2 may have (the same) > function type: > > if then map else filter :: (Bool -> Bool) -> [Bool] -> [Bool] From keith at oreilly.com Fri Feb 22 10:21:56 2008 From: keith at oreilly.com (Keith Fahlgren) Date: Fri Feb 22 10:20:05 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <1203638260.3076.124.camel@localhost> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> <1203638260.3076.124.camel@localhost> Message-ID: <47BEE894.7010508@oreilly.com> On 2/21/08 3:57 PM, Duncan Coutts wrote: > Consequently there is no support in > Cabal etc for those kinds of documentation. GHC, Cabal and c2hs amongst > others use docbook but it's a horrible format to write and the tools to > process it are very finicky (we apparently have to hard code paths to > specific versions of xslt stylesheets). Hi, DocBook authoring tools have progressed tremendously in the past few years, and I disagree that the "tools to process it are very finicky". If there are specific questions about making DocBook more palatable for GHC, Cabal, c2hs, others, please send them to me directly or the docbook-apps list: http://www.docbook.org/help Thanks, Keith From dainichi at gmail.com Fri Feb 22 10:55:54 2008 From: dainichi at gmail.com (dainichi@gmail.com) Date: Fri Feb 22 10:54:01 2008 Subject: [Haskell-cafe] Graphical graph reduction Message-ID: <46477eae0802220755g110828a9tc1ac97541f933bf@mail.gmail.com> Hi Haskell-Cafe, I'm relatively new to Haskell, but have a background with SML. One of the things that amaze me about Haskell is lazy graph reduction, e.g. how the graph unfolds during the evaluation of, say, let fibs = 1 : 1 : zipWith (+) fibs (tail fibs) in take 10 fibs Lazy lists can be simulated in SML too, but unless I do something clever with references, I end up taking exponential time to compute the n'th Fibonacci number. Now to the point: Wouldn't it be great if I had a visual tool that visually showed me the graph while the above evaluation unfolded? I could use it to show some of my co-workers to whom laziness is a mystery, what it's all about. Does anybody know if such a tool exists? I'd be grateful for pointers if it does. I very much doubt that I'm the first person who has thoughts like this, but then again, who knows. People who really know Haskell might think this is too trivial a task to really be worth spending time on. If nothing similar exists, I was thinking about creating such a tool (i.e. an interpreter with additional graph-displaying features) for a very, very small subset/dialect of Haskell. I would probably be lazy (no pun intended) and start right away with abstract syntax trees to avoid lexing and parsing and such. My language of implementation would be SML, using references as the edges of the graph. Any ideas/comments would be welcome. Kai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080223/4a4e249a/attachment.htm From topekarem at gmail.com Fri Feb 22 11:18:23 2008 From: topekarem at gmail.com (TOPE KAREM) Date: Fri Feb 22 11:16:29 2008 Subject: [Haskell-cafe] Re: Tips of Conditional Expression In-Reply-To: <47BEE791.2040406@dfki.de> References: <3717bcc50802220547s551d0b02i8c36df88b3bc0a18@mail.gmail.com> <47BED66E.1020001@dfki.de> <3717bcc50802220622o3e2456b8n7e8dd2460d4dd3ea@mail.gmail.com> <47BEE791.2040406@dfki.de> Message-ID: <3717bcc50802220818y1da47142wa46b542931828912@mail.gmail.com> Thank you all. I am satisfied with all your inputs. Tope On Fri, Feb 22, 2008 at 7:17 AM, Christian Maeder wrote: > TOPE KAREM wrote: > > Thanks. My question is whether it can call a function (say map) > > previously defined elsewhere in the program. Same goes for filter. > > I'm still not sure what to answer. If map and filter were user defined > functions they may occur anywhere in your current module (or must be > imported) and you can apply any argument in scope (of proper type). > > You could i.e. apply "(if then map else filter)" to "id" > which is the same as "if then map id else filter id" > > C. > > > On Fri, Feb 22, 2008 at 6:04 AM, Christian Maeder > > > wrote: > > I'm not sure what you're asking, but exp1 and exp2 may have (the > same) > > function type: > > > > if then map else filter :: (Bool -> Bool) -> [Bool] -> [Bool] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080222/31f44b9e/attachment.htm From svein.ove at aas.no Fri Feb 22 11:33:28 2008 From: svein.ove at aas.no (Svein Ove Aas) Date: Fri Feb 22 11:31:35 2008 Subject: [Haskell-cafe] Graphical graph reduction In-Reply-To: <46477eae0802220755g110828a9tc1ac97541f933bf@mail.gmail.com> References: <46477eae0802220755g110828a9tc1ac97541f933bf@mail.gmail.com> Message-ID: <221b53ab0802220833n4552453cv1659398f2c88964b@mail.gmail.com> 2008/2/22 : > Does anybody know if such a tool exists? I'd be grateful for pointers if it > does. I very much doubt that I'm the first person who has thoughts like > this, but then again, who knows. People who really know Haskell might think > this is too trivial a task to really be worth spending time on. > > If nothing similar exists, I was thinking about creating such a tool (i.e. > an interpreter with additional graph-displaying features) for a very, very > small subset/dialect of Haskell. I would probably be lazy (no pun intended) > and start right away with abstract syntax trees to avoid lexing and parsing > and such. My language of implementation would be SML, using references as > the edges of the graph. > > Any ideas/comments would be welcome. > Rather than spending time on a project specifically to do this, it seems like a great addition to GHCi's still mostly theoretical debugger. I'll understand if you don't want to take on such a project right now, though. I'm not aware of any program that does exactly what you're asking for, but I'm attaching a lambdabot interaction for your reading pleasure. I believe it will speak for itself. < Baughn> > let fibs = 1 : 1 : zipWith (+) fibs (tail fibs) in fibs :: [Expr] < lambdabot> [1,1,1 + 1,1 + (1 + 1),1 + 1 + (1 + (1 + 1)),1 + (1 + 1) + (1 + 1 + (1 + (1 ... 1 -- In a demon-haunted world, science is a candle in the dark http://dresdencodak.com/ From vandijk.roel at gmail.com Fri Feb 22 11:31:17 2008 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Fri Feb 22 11:36:33 2008 Subject: [Haskell-cafe] Problem with Python AST In-Reply-To: <5D28224A-155C-4709-8C17-C6DEBC4866E0@dc.uba.ar> References: <5D28224A-155C-4709-8C17-C6DEBC4866E0@dc.uba.ar> Message-ID: On Fri, Feb 22, 2008 at 2:42 PM, Daniel Gor?n wrote: > > On Feb 21, 2008, at 7:55 PM, Roel van Dijk wrote: > > > Your solutions allows a bit more but fails with the equivalent of > > > > def foo(): > > for i in range(10): > > if i == 6: > > return None > > > > The loop context 'overwrites' the function context which makes the > > return statement illegal. I think I need a type level list. > > i see. how about this? > > if_ = If [(IntLit 6, Suite [] [Break])] (Just $ Suite [] [Return]) > while_ = While (IntLit 6) (Suite [] [if_]) Nothing > while2_ = While (IntLit 6) (Suite [] [Return]) Nothing > foo = FunDecl $ Suite [] [while_, while2_] > > p = Program [foo] > > > newtype Ident = Id String > > data BinOp = Add > | Sub > > data Exp = IntLit Integer > | BinOpExp BinOp Exp Exp > > data Ctx reqloop reqfun > data True > data False > > data Statement ctx where > If :: [(Exp, Suite (Ctx reqloop reqfun))] > -> Maybe (Else (Ctx reqloop reqfun)) > -> Statement (Ctx reqloop reqfun) > While :: Exp > -> (Suite (Ctx True reqfun)) > -> Maybe (Else (Ctx True reqfun)) > -> Statement (Ctx reqloop reqfun) > Pass :: Statement (Ctx reqloop reqfun) > Break :: Statement (Ctx True reqfun) > Return :: Statement (Ctx reqloop True) > FunDecl :: Suite (Ctx False reqfun) -> Statement (Ctx False False) > > newtype Global = Global [Ident] > > data Suite ctx = Suite [Global] [Statement ctx] > > type Else ctx = Suite ctx > > newtype Program = Program [Statement (Ctx False False)] Ah, you set a specific context when needed. Very nice. Although I had to remove the Ctx type. Otherwise I need pattern matching at the type level to bind the reqLoop and reqFun type variables (is such a thing even possible?): data Statement (Ctx reqLoop reqFun) where .... Now I simple pass 2 type variables to my statements: data Statement reqLoop reqFun where .... I now have a complete Python AST and pretty printer. Onwards towards a parser! Thanks again, Roel From bulat.ziganshin at gmail.com Fri Feb 22 11:28:33 2008 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 22 11:54:33 2008 Subject: [Haskell-cafe] Graphical graph reduction In-Reply-To: <46477eae0802220755g110828a9tc1ac97541f933bf@mail.gmail.com> References: <46477eae0802220755g110828a9tc1ac97541f933bf@mail.gmail.com> Message-ID: <135465896.20080222192833@gmail.com> Hello dainichi, Friday, February 22, 2008, 6:55:54 PM, you wrote: > If nothing similar exists, I was thinking about creating such a > tool (i.e. an interpreter with additional graph-displaying features) not exactly this, but now i'm reading introduction into Q language [1] which says on p.11 "The interpreter has a built-in symbolic debugger which allows you to execute a reduction sequence step by step: ...", so you may use it to demonstrate how reductions work. Q by itself is rather interesting language - haskell-like syntax, dynamic, eager with good support for laziness. btw, this manual is probably better than we have for Haskell, i've seen programmers who thinks that Haskell is hard to learn and Q is simple and may be it's just due to its manual which takes into account typical learning problems and explains "obvious" things (which are really obvious only for seasoned FP programmers) [1] http://switch.dl.sourceforge.net/sourceforge/q-lang/qnutshell-0.5.pdf -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From apfelmus at quantentunnel.de Fri Feb 22 12:05:50 2008 From: apfelmus at quantentunnel.de (apfelmus) Date: Fri Feb 22 12:04:11 2008 Subject: [Haskell-cafe] Re: Graphical graph reduction In-Reply-To: <46477eae0802220755g110828a9tc1ac97541f933bf@mail.gmail.com> References: <46477eae0802220755g110828a9tc1ac97541f933bf@mail.gmail.com> Message-ID: Kai wrote: > Wouldn't it be great if I had a visual tool that visually > showed me the graph while the above evaluation unfolded? > > Does anybody know if such a tool exists? I don't know of such a tool, the closest one to that is probably the new ghci debugger. There is also a paper and accompanying website Peter Sestoft. "Demonstrating Lambda Calculus Reduction". http://www.dina.kvl.dk/~sestoft/lamreduce/ but graph reduction with sharing is not covered. Slightly off topic, Twan's blog post http://twan.home.fmf.nl/blog/haskell/ simple-reflection-of-expressions.details demonstrates a neat way to figure out how (polymorphic) higher-order functions like foldr or foldl work. It would be really cool if there was a similar embedded approach for graph reduction, but I don't think that's possible. > If nothing similar exists, I was thinking about creating such a tool (i.e. > an interpreter with additional graph-displaying features) for a very, very > small subset/dialect of Haskell. The Haskell wikibook would greatly benefit from such a tool for the chapters about graph reduction, so I'd be a potential user :) > I would probably be lazy (no pun intended) > and start right away with abstract syntax trees to avoid lexing and parsing > and such. My language of implementation would be SML, using references as > the edges of the graph. Of course, I'd prefer Haskell as the implementation language and since you want to learn Haskell anyway ... :) Concerning the graph representation, using references is probably a bad idea anyway since they're not purely functional in style. There is Martin Erwig's Functional Graph Library (Data.Graph.Inductive) shipping with ghc: Martin Erwig. Inductive Graphs and Functional Graph Algorithms. http://web.engr.oregonstate.edu/~erwig/papers/abstracts.html#JFP01 There is also Norman Ramsey, Jo?o Dias. "An Applicative Control-Flow Graph Based on Huet?s Zipper". which uses a zipper to represent a control-flow graph. I'm mentioning this paper for the following quote: "the mutable flow graph was big and complex, and it led to many bugs. We have replaced it by a smaller, simpler, applicative flow graph based on Huet?s (1997) zipper. The new flow graph is a success." In other words: forget mutable references :) Moreover, it's not clear whether a graph should be used at all. Well, at least concerning the _presentation_. A todo-note at the beginning of lists the possible choices, I'm currently leaning in favor of a let .. in statements in the spirit of John Maraist, Martin Odersky and Philip Wadler. "The call-by-need lambda calculus". http://homepages.inf.ed.ac.uk/wadler/topics/ call-by-need.html#need-journal Overall, the main problem for a graph reduction demonstration tool to solve is not how to perform graph reduction but how to present it. The point is: the tool is unnecessary for very simple examples since those are better done by hand. But an unsophisticated tool is useless for the more complicated cases too, since no one can make sense of the output anymore! Regards, apfelmus From allbery at ece.cmu.edu Fri Feb 22 12:11:39 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Feb 22 12:09:49 2008 Subject: [Haskell-cafe] Tutorial for using the state monad or a better suggestion? In-Reply-To: <4165d3a70802220615s5799339ex30d4c71d0f1916c4@mail.gmail.com> References: <4165d3a70802220615s5799339ex30d4c71d0f1916c4@mail.gmail.com> Message-ID: On Feb 22, 2008, at 9:15 , Jefferson Heard wrote: > Now I'm to the point of making this thing interactive, and I I'm > trying to figure out the Haskell way of doing this. Last time I wrote > a program like this, I made a record data type with all the state and > placed it into an IORef and curried it into the GLUT callback > functions. I'm going to do the same thing now if there aren't cringes > and wailings from people with a better sense of pure-functional > aesthetics out there on the list with a willingness to either point me > towards a tutorial that would help me do this better. Keep in mind > that Graphics.UI.GLUT callbacks all want to return an IO (), and thus > leftover state monads at ends of functions aren't going to be > acceptable to the standard library... What I do (with gtk2hs) is visible at http://hpaste.org/3137 --- MWPState is a fairly large record. I will note that this code stores the mutable data in separate IORefs, whereas I'm told that it's better to use a single IORef with all the mutable state inside it. (For some reason I had assumed that the overhead would be higher.) That said, the wrappers make it fairly easy to refactor it. Since the IORef(s) and much of the remaining state is read-only, I use a ReaderT IO instead of StateT IO; this also turned out to be convenient for what turned out to be a significant optimization (in response to a timer firing, it collects a bunch of data and feeds it into a TreeView, and it turned out to be useful to collect it all at the front and use local to roll a modified record with the cached values). (The code in that paste is rather out of date, probably I should update it.) -- 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 jefferson.r.heard at gmail.com Fri Feb 22 12:13:30 2008 From: jefferson.r.heard at gmail.com (Jefferson Heard) Date: Fri Feb 22 12:11:36 2008 Subject: [Haskell-cafe] Tutorial for using the state monad or a better suggestion? In-Reply-To: References: <4165d3a70802220615s5799339ex30d4c71d0f1916c4@mail.gmail.com> Message-ID: <4165d3a70802220913h771a20e3nc340bc8042f91076@mail.gmail.com> Thanks. There seems to be some consensus developing around using IORefs to hold all the program state. -- Jeff On Fri, Feb 22, 2008 at 12:11 PM, Brandon S. Allbery KF8NH wrote: > > On Feb 22, 2008, at 9:15 , Jefferson Heard wrote: > > > Now I'm to the point of making this thing interactive, and I I'm > > trying to figure out the Haskell way of doing this. Last time I wrote > > a program like this, I made a record data type with all the state and > > placed it into an IORef and curried it into the GLUT callback > > functions. I'm going to do the same thing now if there aren't cringes > > and wailings from people with a better sense of pure-functional > > aesthetics out there on the list with a willingness to either point me > > towards a tutorial that would help me do this better. Keep in mind > > that Graphics.UI.GLUT callbacks all want to return an IO (), and thus > > leftover state monads at ends of functions aren't going to be > > acceptable to the standard library... > > What I do (with gtk2hs) is visible at http://hpaste.org/3137 --- > MWPState is a fairly large record. > > I will note that this code stores the mutable data in separate > IORefs, whereas I'm told that it's better to use a single IORef with > all the mutable state inside it. (For some reason I had assumed that > the overhead would be higher.) That said, the wrappers make it > fairly easy to refactor it. Since the IORef(s) and much of the > remaining state is read-only, I use a ReaderT IO instead of StateT > IO; this also turned out to be convenient for what turned out to be a > significant optimization (in response to a timer firing, it collects > a bunch of data and feeds it into a TreeView, and it turned out to be > useful to collect it all at the front and use local to roll a > modified record with the cached values). > > (The code in that paste is rather out of date, probably I should > update it.) > > -- > 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 > > > -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards From wildgoose at operamail.com Fri Feb 22 12:19:17 2008 From: wildgoose at operamail.com (David B.Wildgoose) Date: Fri Feb 22 12:17:41 2008 Subject: [Haskell-cafe] Re: Haskell + Windows Mobile? References: <259725041.20080221194647@gmail.com> Message-ID: Bulat Ziganshin gmail.com> writes: > > Hello haskell-cafe, > > is there any haskell implementation for Windows Mobile? does they are > support creation of GUI apps and internet networking features? > Hugs is available for Windows CE, (I have it on my Jornada 720), but I've only used it for non-GUI work. However with Windows Mobile 5 Microsoft decided to unilaterally remove the console drivers, instantly breaking a large number of useful Windows CE programs. From conal at conal.net Fri Feb 22 12:26:03 2008 From: conal at conal.net (Conal Elliott) Date: Fri Feb 22 12:24:09 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <2608b8a80802220325q118e97e7x6d7ed48f1c707ac8@mail.gmail.com> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> <1203644274.3076.148.camel@localhost> <2608b8a80802220325q118e97e7x6d7ed48f1c707ac8@mail.gmail.com> Message-ID: Hi Yitzchak, About "-- |", "-- ^", and "-- $doc", we might call them "markup meta-directives", since they delimit the text to be preprocessed and then produced as markup. The meta-directives and the "-- " line prefixes would be removed in the process. As for producing machine-readable API metadata, I hadn't been thinking along those lines, and I enthusiastically agree with you. Further factor haddock into a metadata extractor and a documentation generator. Cheers, - Conal On Fri, Feb 22, 2008 at 3:25 AM, Yitzchak Gale wrote: > Conal Elliott wrote: > > Pare the Haddock markup language down to > > very few markup directives, say just 'foo' and > > "Foo.Bar". > > Other critical ones: > > -- | This shows which syntax this text describes. > -- ^ So does this. > > Less critical, but usually not provided by general > markup languages: > > -- $doc A movable documentation chunk. > > If Haddock itself does not parse any other markup, > we must make sure to use markup that does not > lock up its information. It should be something we > have a parser for, or something that has good > tools for turning it into some robust machine-readable > format in a lossless way. > > The reason is that I may want to use a bit of > Haskell in a much larger project that uses some > other markup system for its API documentation. > > So, for example, if I want to integrate the output > into a larger DITA project, there should be an easy > way to do that. Or Doxygen, or whatever else. > > Then Haddock would need to have some way > of outputting its own information nicely, with > embedded chunks of markup. You would read that, > passing each chunk of markup through its parser. > > Truth is, I don't see any such parser for "markdown". > Do you know of one? Maybe we would have to > write one. > > I think that improving the markup capabilities of > Haddock is a minor issue. The main value of > Haddock is its API metadata. Haddock currently > keeps most of that in its bellly, using it secretly > to create its own presentation output. The biggest > improvement would be getting meaningful > machine-readable output. > > Your idea of abstracting out the markup could > actually make that easier, if we keep that goal > in mind as well. > > Thanks, > Yitz > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080222/ef49ed6d/attachment.htm From dons at galois.com Fri Feb 22 13:53:51 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 22 13:52:01 2008 Subject: [Haskell-cafe] Tutorial for using the state monad or a better suggestion? In-Reply-To: <4165d3a70802220615s5799339ex30d4c71d0f1916c4@mail.gmail.com> References: <4165d3a70802220615s5799339ex30d4c71d0f1916c4@mail.gmail.com> Message-ID: <20080222185351.GA23836@scytale.galois.com> jefferson.r.heard: > So the reason I keep pinging the list so much of late is I'm currently > writing a GLUT program to visualize a heirarchical clustering of > 18,000+ protein-protein interaction pairs (and associated > gene-ontology terms). Thanks for the help on reading CSVs, those who > wrote me back... my program intitializes and displays its first image > within 6 seconds, about 10 times faster and in 10 times less memory > than the Java program the guy was using. Wonderful. I'm glad you're making progress. Be sure to lean on the friendly Haskell "consultants" of -cafe@ for help as you need it. From tux_rocker at reinier.de Fri Feb 22 13:57:27 2008 From: tux_rocker at reinier.de (Reinier Lamers) Date: Fri Feb 22 13:55:36 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> Message-ID: Op 22-feb-2008, om 1:54 heeft Conal Elliott het volgende geschreven: > The goal redesigning for composability is that we get more for > less. Haddock can focus on its speciality, namely hyperlinked > Haskell code documentation, and pandoc on its, namely human- > writable and -readable prose with modern features (images, friendly > hyperlinks, smart quotes & dashes, footnotes, super- and > subscripts, pretty math, bibliography-style link specs, etc). > Haddock development can focus its resources on Haskell-specific > functionality, and we library writers can still use a full-featured > mark-up language. While I like the idea of a very powerful authoring system, I doubt that we should mix the documentation code with the source code. It seems much clearer to me to separate such heavily-formatted documentation from the source into separate files. Of course, the source code includes comments that specify what functions do, and so provide a bit of API documentation. But such comments should contain as little formatting as possible to keep them readable in a text editor. Reinier From dons at galois.com Fri Feb 22 13:57:40 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 22 13:55:51 2008 Subject: [Haskell-cafe] Rendering TTF fonts in Haskell and OpenGL In-Reply-To: <6205bd290802220642x2e3b1e5cq4c4622d7edfdcbc3@mail.gmail.com> References: <4165d3a70802171613q3b08f931h163fb98756a4be5b@mail.gmail.com> <7ca3f0160802171726o789f61a1u2af22f270fd64127@mail.gmail.com> <87wsp3x8rn.wl%jeremy.shaw@linspireinc.com> <6205bd290802220642x2e3b1e5cq4c4622d7edfdcbc3@mail.gmail.com> Message-ID: <20080222185740.GB23836@scytale.galois.com> bit: > I also have made haskell bindings to FreeType, including support for > extracting glyph outlines. > > I haven't had time to publish it yet. Hopefully I'll get around to it > soon. Do you need a place to host the repository? code.haskell.org is available if you want to host there. Just visit community.haskell.org and request an account. -- Don From tphyahoo at gmail.com Fri Feb 22 14:50:39 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Fri Feb 22 14:48:45 2008 Subject: Fwd: [Haskell-cafe] Repeated function application In-Reply-To: <910ddf450802221149x4c32f097y4994015362826081@mail.gmail.com> References: <640461.89929.qm@web30808.mail.mud.yahoo.com> <47BDCEFF.1010500@imageworks.com> <910ddf450802221149x4c32f097y4994015362826081@mail.gmail.com> Message-ID: <910ddf450802221150t380be84bu51728168d61537fe@mail.gmail.com> This was easier for me to understand when written so, with the start value explicit times3 :: (a -> a) -> Int -> (a -> a) times3 f n !start | n == 0 = start | otherwise = times3 f (n-1) (f start) -- no stack overflow :) tTimes3 = times3 (+1) 1000000 0 Here, only the third arg, the start value, needs to be "bangified/strictified", and it's pretty clear why. Without the bang pattern, it stack overflows. What I'm not sure of is whether this version is in fact completely equivalent to Dan's version above. I hope it is. 2008/2/21, Dan Weston : > Ben Butler-Cole wrote: > > Hello > > > > I was surprised to be unable to find anything like this in the standard libraries: > > > > times :: (a -> a) -> Int -> (a -> a) > > times f 0 = id > > times f n = f . (times f (n-1)) > > > > Am I missing something more general which would allow me to repeatedly apply a function to an input? Or is this not useful? > > > Invariably, this seems to invite a stack overflow when I try this (and > is usually much slower anyway). Unless f is conditionally lazy, f^n and > f will have the same strictness, so there is no point in keeping nested > thunks. > > If you apply f immediately to x, there is no stack explosion and faster > runtime: > > > times :: (a -> a) -> Int -> (a -> a) > > times f !n !x | n > 0 = times f (n-1) (f x) > | otherwise = x > > > Dan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From tphyahoo at gmail.com Fri Feb 22 14:59:50 2008 From: tphyahoo at gmail.com (Thomas Hartman) Date: Fri Feb 22 14:57:56 2008 Subject: [Haskell-cafe] Repeated function application In-Reply-To: <910ddf450802221150t380be84bu51728168d61537fe@mail.gmail.com> References: <640461.89929.qm@web30808.mail.mud.yahoo.com> <47BDCEFF.1010500@imageworks.com> <910ddf450802221149x4c32f097y4994015362826081@mail.gmail.com> <910ddf450802221150t380be84bu51728168d61537fe@mail.gmail.com> Message-ID: <910ddf450802221159m5a64c792lff681eb519704274@mail.gmail.com> On second thought... never mind. The only thing of (somewhat marginal) interest that my latest comment adds is that the second argument doesn't need to be strict. Otherwise my code is exactly identical to Dan's. 2008/2/22, Thomas Hartman : > This was easier for me to understand when written so, with the start > > value explicit > > times3 :: (a -> a) -> Int -> (a -> a) > times3 f n !start | n == 0 = start > | otherwise = times3 f (n-1) (f start) > > -- no stack overflow :) > tTimes3 = times3 (+1) 1000000 0 > > Here, only the third arg, the start value, needs to be > > "bangified/strictified", and it's pretty clear why. Without the bang > pattern, it stack overflows. > > > What I'm not sure of is whether this version is in fact completely > equivalent to Dan's version above. > > I hope it is. > > 2008/2/21, Dan Weston : > > > Ben Butler-Cole wrote: > > > Hello > > > > > > I was surprised to be unable to find anything like this in the > standard libraries: > > > > > > times :: (a -> a) -> Int -> (a -> a) > > > times f 0 = id > > > times f n = f . (times f (n-1)) > > > > > > Am I missing something more general which would allow me to > repeatedly apply a function to an input? Or is this not useful? > > > > > > Invariably, this seems to invite a stack overflow when I try this (and > > is usually much slower anyway). Unless f is conditionally lazy, f^n and > > f will have the same strictness, so there is no point in keeping nested > > thunks. > > > > If you apply f immediately to x, there is no stack explosion and faster > > runtime: > > > > > > times :: (a -> a) -> Int -> (a -> a) > > > > times f !n !x | n > 0 = times f (n-1) (f x) > > | otherwise = x > > > > > > Dan > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > From westondan at imageworks.com Fri Feb 22 15:12:22 2008 From: westondan at imageworks.com (Dan Weston) Date: Fri Feb 22 15:10:34 2008 Subject: [Haskell-cafe] Repeated function application In-Reply-To: <910ddf450802221159m5a64c792lff681eb519704274@mail.gmail.com> References: <640461.89929.qm@web30808.mail.mud.yahoo.com> <47BDCEFF.1010500@imageworks.com> <910ddf450802221149x4c32f097y4994015362826081@mail.gmail.com> <910ddf450802221150t380be84bu51728168d61537fe@mail.gmail.com> <910ddf450802221159m5a64c792lff681eb519704274@mail.gmail.com> Message-ID: <47BF2CA6.7070000@imageworks.com> Actually, the second argument is already strict, and the ! doesn't make it any stricter (and is therefore gratuitous): when you evaluate the conditional (n == 0), n is evaluated. Dan Thomas Hartman wrote: > On second thought... never mind. > > The only thing of (somewhat marginal) interest that my latest comment > adds is that the second argument doesn't need to be strict. > > Otherwise my code is exactly identical to Dan's. > > 2008/2/22, Thomas Hartman : >> This was easier for me to understand when written so, with the start >> >> value explicit >> >> times3 :: (a -> a) -> Int -> (a -> a) >> times3 f n !start | n == 0 = start >> | otherwise = times3 f (n-1) (f start) >> >> -- no stack overflow :) >> tTimes3 = times3 (+1) 1000000 0 >> >> Here, only the third arg, the start value, needs to be >> >> "bangified/strictified", and it's pretty clear why. Without the bang >> pattern, it stack overflows. >> >> >> What I'm not sure of is whether this version is in fact completely >> equivalent to Dan's version above. >> >> I hope it is. >> >> 2008/2/21, Dan Weston : >> >> > Ben Butler-Cole wrote: >> > > Hello >> > > >> > > I was surprised to be unable to find anything like this in the >> standard libraries: >> > > >> > > times :: (a -> a) -> Int -> (a -> a) >> > > times f 0 = id >> > > times f n = f . (times f (n-1)) >> > > >> > > Am I missing something more general which would allow me to >> repeatedly apply a function to an input? Or is this not useful? >> > >> > >> > Invariably, this seems to invite a stack overflow when I try this (and >> > is usually much slower anyway). Unless f is conditionally lazy, f^n and >> > f will have the same strictness, so there is no point in keeping nested >> > thunks. >> > >> > If you apply f immediately to x, there is no stack explosion and faster >> > runtime: >> > >> > >> > times :: (a -> a) -> Int -> (a -> a) >> > >> > times f !n !x | n > 0 = times f (n-1) (f x) >> > | otherwise = x >> > >> > >> > Dan >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From taralx at gmail.com Fri Feb 22 15:46:30 2008 From: taralx at gmail.com (Taral) Date: Fri Feb 22 15:44:39 2008 Subject: [Haskell-cafe] Haskell w/ delimited continuations Message-ID: My understanding of these things is limited, but what would stop me, theoretically speaking, of making a version of ghc with these primitives added: type Prompt r reset :: (Prompt r -> r) -> r shift :: Prompt r -> ((a -> _) -> r) -> a (Where _ is either r or forall b. b) -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From ryani.spam at gmail.com Fri Feb 22 16:15:48 2008 From: ryani.spam at gmail.com (Ryan Ingram) Date: Fri Feb 22 16:13:55 2008 Subject: [Haskell-cafe] Haskell w/ delimited continuations In-Reply-To: References: Message-ID: <2f9b2d30802221315v5d58fec7ge7aa18c5415941a3@mail.gmail.com> You might want to take a look at http://www.haskell.org/pipermail/haskell/2007-December/020034.html which shows an implementation of delimited continuations in Haskell98 and possibly gets rid of any requirement of implementing primitives. -- ryan On 2/22/08, Taral wrote: > My understanding of these things is limited, but what would stop me, > theoretically speaking, of making a version of ghc with these > primitives added: > > type Prompt r > > reset :: (Prompt r -> r) -> r > shift :: Prompt r -> ((a -> _) -> r) -> a > > (Where _ is either r or forall b. b) > > -- > Taral > "Please let me know if there's any further trouble I can give you." > -- Unknown > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dons at galois.com Fri Feb 22 16:21:25 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 22 16:19:33 2008 Subject: [Haskell-cafe] Haskell w/ delimited continuations In-Reply-To: <2f9b2d30802221315v5d58fec7ge7aa18c5415941a3@mail.gmail.com> References: <2f9b2d30802221315v5d58fec7ge7aa18c5415941a3@mail.gmail.com> Message-ID: <20080222212125.GA28255@scytale.galois.com> See also, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CC-delcont "An implementation of multi-prompt delimited continuations based on the paper, A Monadic Framework for Delimited Continuations, by R. Kent Dybvig, Simon Peyton Jones and Amr Sabry" reset :: MonadDelimitedCont p s m => (p a -> m a) -> m a shift :: MonadDelimitedCont p s m => p b -> ((m a -> m b) -> m b) -> m a ryani.spam: > You might want to take a look at > http://www.haskell.org/pipermail/haskell/2007-December/020034.html > > which shows an implementation of delimited continuations in Haskell98 > and possibly gets rid of any requirement of implementing primitives. > > -- ryan > > On 2/22/08, Taral wrote: > > My understanding of these things is limited, but what would stop me, > > theoretically speaking, of making a version of ghc with these > > primitives added: > > > > type Prompt r > > > > reset :: (Prompt r -> r) -> r > > shift :: Prompt r -> ((a -> _) -> r) -> a > > > > (Where _ is either r or forall b. b) > > > > -- > > Taral > > "Please let me know if there's any further trouble I can give you." > > -- Unknown > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From conal at conal.net Fri Feb 22 16:28:39 2008 From: conal at conal.net (Conal Elliott) Date: Fri Feb 22 16:26:46 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> Message-ID: On Fri, Feb 22, 2008 at 10:57 AM, Reinier Lamers wrote: > [...] > Of course, the source code includes comments that specify what > functions do, and so provide a bit of API documentation. But such > comments should contain as little formatting as possible to keep them > readable in a text editor. Hi Reinier, Do you know about the [Markdown] format and the [Pandoc] processor? [Markdown] is designed for *readability* in text editors and based on common text conventions. >From the [markdown] home page: > The overriding design goal for Markdown's formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it's been marked up with tags or formatting instructions. While Markdown's syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown's syntax is the format of plain text email. Don't take their word for it or mine. You can copy and paste this message into the [Try Pandoc] page. Regards, - Conal [Markdown]: http://daringfireball.net/projects/markdown "The markdown project page" [Pandoc]: http://johnmacfarlane.net/pandoc/try "The Pandoc project page" [Try Pandoc]: http://johnmacfarlane.net/pandoc/try "Try out Pandoc for yourself" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080222/f69ba7cc/attachment.htm From vigalchin at gmail.com Fri Feb 22 16:56:40 2008 From: vigalchin at gmail.com (Galchin Vasili) Date: Fri Feb 22 16:54:46 2008 Subject: [Haskell-cafe] Support for Transaction Memory by Sun Microsystems .. Message-ID: <5ae4f2ba0802221356n803a7c9r2c67acc27b9947e9@mail.gmail.com> Hello, Found this: http://www.theregister.co.uk/2007/08/21/sun_transactional_memory_rock/ http://research.sun.com/spotlight/2007/2007-08-13_transactional_memory.html vasya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080222/25772b41/attachment.htm From taralx at gmail.com Fri Feb 22 17:27:12 2008 From: taralx at gmail.com (Taral) Date: Fri Feb 22 17:25:17 2008 Subject: [Haskell-cafe] Re: Haskell w/ delimited continuations In-Reply-To: References: Message-ID: On 2/22/08, Taral wrote: > reset :: (Prompt r -> r) -> r > shift :: Prompt r -> ((a -> _) -> r) -> a The point of the question is about shift/reset with *these types*. I know there are implementations with other types. -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From derek.a.elkins at gmail.com Fri Feb 22 16:45:02 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Feb 22 17:44:13 2008 Subject: [Haskell-cafe] Re: Haskell w/ delimited continuations In-Reply-To: References: Message-ID: <1203716703.5522.13.camel@derek-laptop> On Fri, 2008-02-22 at 14:27 -0800, Taral wrote: > On 2/22/08, Taral wrote: > > reset :: (Prompt r -> r) -> r > > shift :: Prompt r -> ((a -> _) -> r) -> a > > The point of the question is about shift/reset with *these types*. I > know there are implementations with other types. Nothing but sanity is stopping you. If you make a new language, you can do whatever you like. However, with shift and reset you can represent any effect, so you would utterly lose purity. From taralx at gmail.com Fri Feb 22 18:13:30 2008 From: taralx at gmail.com (Taral) Date: Fri Feb 22 18:11:38 2008 Subject: [Haskell-cafe] Re: Haskell w/ delimited continuations In-Reply-To: <1203716703.5522.13.camel@derek-laptop> References: <1203716703.5522.13.camel@derek-laptop> Message-ID: On 2/22/08, Derek Elkins wrote: > Nothing but sanity is stopping you. If you make a new language, you can > do whatever you like. However, with shift and reset you can represent > any effect, so you would utterly lose purity. Can you give an example of an impure function created using these primitives? -- Taral "Please let me know if there's any further trouble I can give you." -- Unknown From derek.a.elkins at gmail.com Fri Feb 22 18:04:40 2008 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri Feb 22 19:03:49 2008 Subject: [Haskell-cafe] Re: Haskell w/ delimited continuations In-Reply-To: References: <1203716703.5522.13.camel@derek-laptop> Message-ID: <1203721480.5522.18.camel@derek-laptop> On Fri, 2008-02-22 at 15:13 -0800, Taral wrote: > On 2/22/08, Derek Elkins wrote: > > Nothing but sanity is stopping you. If you make a new language, you can > > do whatever you like. However, with shift and reset you can represent > > any effect, so you would utterly lose purity. > > Can you give an example of an impure function created using these primitives? shift and reset but see these slides http://cs.ioc.ee/mpc-amast06/msfp/filinski-slides.pdf and/or one or both of http://citeseer.ist.psu.edu/filinski94representing.html http://citeseer.ist.psu.edu/filinski99representing.html From ben.franksen at online.de Fri Feb 22 20:17:46 2008 From: ben.franksen at online.de (Ben Franksen) Date: Fri Feb 22 20:19:28 2008 Subject: [Haskell-cafe] Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing References: <965491992.20080205132858@gmail.com> <8087A09F-3DA5-449A-A6DE-FEE67B177B10@ntlworld.com> <3d96ac180802050421x2795f633o48b4bbe2f336a851@mail.gmail.com> <638ABD0A29C8884A91BC5FB5C349B1C3183270FCF6@EA-EXMSG-C334.europe.corp.microsoft.com> <9CFEEB19-FCA9-46D2-B26A-15F4581697E2@ntlworld.com> <6AF00433-1BA0-4F85-B434-F094DC47C037@ntlworld.com> <47BE6B11.7060204@cs.pdx.edu> Message-ID: Mark P Jones wrote: > Ben Franksen wrote: >> TREX seems to be generally agreed to be too complicated to implement and >> explain. > > What evidence do you have for this? Not much, I have to admit that. It basically seems to be SPJ's opinion, as he writes in his proposal that he "never got around to implementing [TREX] in GHC. Why not? Mainly because the implementation cost turned out to be relatively high" and further claims his new proposal "is considerably simpler to implement, and [...] it is rather simpler to explain." I also had the impression from earlier discussions that there are few people who support the TREX idea. I could be completely wrong, though. > Speaking as somebody who > implemented Trex for Hugs (and who also witnessed Ben Gaster > build an independent implementation), I'd have to disagree > about the first part of this. As I recall, the implementation > was reasonably straightforward, and wasn't any more complicated > than other common type system extensions that I've worked on. > I'm also not sure why you think it is complicated to explain, > but I suppose that's even more subjective. I did not say, nor did I want to imply, that this is my own opinion. I would be extremely happy to have TREX in ghc and all the other implementations, I just fear that it is not going to happen, at least not any time soon. In fact I am almost completely un-biased as to which record system Haskell gets, as long as DOES get one and preferably IN MY LIFETIME. I'd give up a serious amount of expressive power if it brings us nearer to this goal. Maybe this is just me being short-sighted and egotistical. > One of the most difficult things about the Trex implementation > was finding a syntax that meshed nicely with the rest of the > Haskell syntax. This is likely to be a problem for any record > system extension of Haskell---unless you're prepared to accept > a more unconventional syntax---because many of the symbols that > you might want to use ({, }, ., |, \, for example) have already > been adopted for other purposes. Ah, syntax! Oh yes, that is indeed quite hard. One more reason for me to a prefer a simpler system. Cheers Ben From duncan.coutts at worc.ox.ac.uk Fri Feb 22 20:28:33 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 22 20:26:38 2008 Subject: [Haskell-cafe] haddock as a markdown preprocessor In-Reply-To: <47BEE894.7010508@oreilly.com> References: <1203591599.3076.60.camel@localhost> <79d7c4980802210512v32f6aefegf34f42c90bb31326@mail.gmail.com> <1203638260.3076.124.camel@localhost> <47BEE894.7010508@oreilly.com> Message-ID: <1203730113.3076.210.camel@localhost> On Fri, 2008-02-22 at 07:21 -0800, Keith Fahlgren wrote: > On 2/21/08 3:57 PM, Duncan Coutts wrote: > > Consequently there is no support in > > Cabal etc for those kinds of documentation. GHC, Cabal and c2hs amongst > > others use docbook but it's a horrible format to write and the tools to > > process it are very finicky (we apparently have to hard code paths to > > specific versions of xslt stylesheets). > > Hi, > > DocBook authoring tools have progressed tremendously in the past few years, and > I disagree that the "tools to process it are very finicky". If there are > specific questions about making DocBook more palatable for GHC, Cabal, c2hs, > others, please send them to me directly or the docbook-apps list: > http://www.docbook.org/help I admit to knowing rather little about it but I've noticed that these three projects are using xsltproc directly as their docbook processor (the other two just copied GHC). Because xsltproc is a general purpose tool they have to supply a large number of parameters including a hard coded location of an xslt script (and xsltproc seems to always want to go to the network to download a dtd when it already has a version it can use offline). Currently Cabal uses: xsltproc --param use.id.as.file