[Haskell-cafe] Re: [wxhaskell-users] FW: Reviving wxHaskell
Sorry, I used wrong e-mail address to post Haskell-Cafe. So, I send this mail again. On Wed, 02 Aug 2006 06:03:46 +0900, Eric Y. Kow <[EMAIL PROTECTED]> wrote: On Tue, Aug 01, 2006 at 13:03:52 -0700, Daan Leijen wrote: One potential challenge is to find a group of testers that are willing to help compiling wxHaskell on different target systems: Windows, MacOS X, and Unix/GTK variations. I volunteer to help test on MacOS X I voluteer to help test on Windows, too. Why don't we make the switch to darcs while we're at it? Revision control may be the least of our worries, but I think that darcs would have been helpful specifically for our case (multiple revisions of my Unicode patch, Shelarcy's patches for Windows stuff, Mac Makefile stuff, the new DB-related issues). Keeping track of patch-on-patch-on-patch has gottten to be tricky. Having a truly patch-oriented system would 1. make it easier for outsiders to submit modifications 2. make us more resistant to the busy-ness of our project leaders So, should we go ahead and do this? I agree with you. -- shelarcy http://page.freett.com/shelarcy/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Future Edison directions
Brian Hulley wrote: splitWith :: (v -> Bool) -> c -> (c,c) splitWith p t | isEmpty t = (empty, empty) | p (measure t) = let (l,x,r) = splitWithInternal p mempty t in (l, pushL x r) | otherwise = (empty, empty) Sorry it should be: | otherwise = (t, empty) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Parsec] Backtracking with try does not work for me?
Stephane Bortzmeyer wrote: > > The first would be to test whether "bb" is followed by "eof" or > > "comma" before accepting it. > > notFollowedBy actually does the opposite (checking that there are no > more letters). Are you sure that you don't actually want *> many1 letter `sepBy1` comma ? Just asking, because somehow I have a feeling that the next step is to accept 'a,c,b'... Udo. -- The Force is what holds everything together. It has its dark side, and it has its light side. It's sort of like cosmic duct tape. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A program which never crashes (even when a function calls "error")
Stephane Bortzmeyer wrote: [It is a philosophical question, not a practical programming problem.] I'm used, in imperative programming languages with exceptions (like Python) to call any function without fear of stopping the program because I can always catch the exceptions with things like (Python): while not over: try: code which may raise an exception... except Exception e: do something clever How to do it in Haskell? How can I call functions like Prelude.head while being sure my program won't stop, even if I call head on an empty list (thus calling "error")? Here's another way of looking at it, that I've grown fond of. If your program is a total function, then there should be no exceptions. That is, if you properly model the world, in all its messiness, then you can write a function that maps every instance of the world to some valid output, even if that output is ``Sorry.'' It might seem a daunting task, but liberal use of the Maybe class from the ground up helps. We have suffered through quite a bit of this with our hardware detector, where unexpected situations are the norm. My colleague David Fox has spent considerable time computing reasonable answers in seemingly impossible situations, to the point where you cannot turn around without bumping into a Maybe construct. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Future Edison directions
Jared Updike wrote: This page: http://jaortega.wordpress.com/2006/03/17/programmers-go-bananas/ lists some references at the bottom. Perhaps they would be useful. Thanks! That page looks really interesting and useful, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [wxhaskell-users] FW: Reviving wxHaskell
On Tue, Aug 01, 2006 at 13:03:52 -0700, Daan Leijen wrote: > One potential challenge is to find a group of testers that are > willing to help compiling wxHaskell on different target systems: > Windows, MacOS X, and Unix/GTK variations. I volunteer to help test on MacOS X > I am happy to give volunteers administrator privileges on the > sourceforge site and help out with the initial transition and building > the initial new release (which is generally a lot of careful work in > compiling and packaging correctly). Why don't we make the switch to darcs while we're at it? Revision control may be the least of our worries, but I think that darcs would have been helpful specifically for our case (multiple revisions of my Unicode patch, Shelarcy's patches for Windows stuff, Mac Makefile stuff, the new DB-related issues). Keeping track of patch-on-patch-on-patch has gottten to be tricky. Having a truly patch-oriented system would 1. make it easier for outsiders to submit modifications 2. make us more resistant to the busy-ness of our project leaders So, should we go ahead and do this? Would hackage be the place to host this? How do we go about getting something set up on hackage? I really don't mean to evangelise, but I was just getting sick of keeping track of patches by hand. -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpRWXqfMuuig.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Future Edison directions
Robert Dockins wrote: [snip] 7) Finally, I somehow feel like there should be a nice categorical formulation of these datastructure abstractions which would help to drive a refactoring of the API typeclasses in a principled way, rather than on an ad-hoc I-sort-of-think-these-go-together sort of way. For the last few months (!!!) I've been thinking about the relationship between measured sequences and plain sequences and also whether or not every sequence should by indexable by Int. I'm wondering if something like the following might be a possible factoring of the ops relating to indexing/measurements: -- from http://www.soi.city.ac.uk/~ross/papers/FingerTree.html class Monoid v => Measured v a where measure :: a -> v instance Measured () a where measure _ = () -- then (also based mostly on FingerTree ideas) class (Monoid v, Ord i) => IndexMeasure v i where -- no fundep index :: v -> i class BasicSeq c a | c -> a where length :: c -> Int empty :: c isEmpty :: c -> Bool atL :: c -> a atR :: c -> a pushL :: a -> c -> c viewL :: Monad m => c -> m (a, c) -- pushR, viewR class (Measured v a, Measured v c, BasicSeq c a) => Measurable c v a | c -> v where -- precondition: pred is True for v `mappend` (measure c) splitWithInternal :: (v -> Bool) -> v -> c -> (c, a, c) splitWith :: (v -> Bool) -> c -> (c,c) splitWith p t | isEmpty t = (empty, empty) | p (measure t) = let (l,x,r) = splitWithInternal p mempty t in (l, pushL x r) | otherwise = (empty, empty) splitAt :: IndexMeasure v i => i -> c -> (c,c) splitAt i = splitWith (\v -> i < index v) size :: IndexMeasure v i => c -> i size c = index (measure c) -- take, drop, takeWith, dropWith, in terms of split and splitWith atWith :: (v -> Bool) -> c -> a atWith p t = (\(_,x,_)->x) (splitWithInternal p mempty t) at :: IndexMeasure v i => i -> c -> a at i = atWith (\v -> i < index v) where splitWith p s returns (l,r) such that the measure of l `mappend` the measure of the first element of r satisfies p (FingerTree paper has explanation of this - I assume monotonic p for any useful use). The idea of the above design would be to allow multiple indexes for the same sequence (though the element type is the same in each case so possibly this could be confusing though could be prevented by using a fundep in the IndexMeasure class), as well as allowing sequences with an arbitrary measure that isn't an index (just by having no instances of IndexMeasure) eg: data TextBuffer = ... newtype Line = Line Int newtype CharPos = CharPos Int data TextBufferMeasure = ... instance IndexMeasure TextBufferMeasure Line where ... instance IndexMeasure TextBufferMeasure CharPos where ... instance Measureable TextBuffer TextBufferMeasure Char where ... Line lineCount = size textbuf CharPos charCount = size textbuf (before, after) = splitAt (CharPos 56) textbuf Of course this doesn't solve the problem of using nested sequences, but it at least allows general measurement with predicate search to coexist with simple indexing and size-with-respect-to-index where these are applicable to the relevant concrete sequence. Anyway just a very rough idea at the moment. I'm looking forward to seeing a nice categorical factoring ;-) Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Parsec] Backtracking with try does not work for me?
On Tue, Aug 01, 2006 at 09:41:40AM +0100, Chris Kuklewicz <[EMAIL PROTECTED]> wrote a message of 105 lines which said: > The problem is mentioned here: > > http://www.cs.uu.nl/people/daan/download/parsec/parsec.html#notFollowedBy notFollowedBy seems to work for me and is quite simple, even for my brain. Thanks. > The first would be to test whether "bb" is followed by "eof" or > "comma" before accepting it. notFollowedBy actually does the opposite (checking that there are no more letters). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
FW: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell)
Dear wxHaskell users, First of all, I apologize for not being responsive on the wxHaskell users mailing list. I recently changed jobs and countries and didn’t properly take care of older email aliases. Anyway, even though I am motivated to support wxHaskell, practice proves that the project is too large for me to do alone. It would be great if someone or a group of people feel motivated enough to take over the project and release new versions that are compatible with the latest Ghc versions. One potential challenge is to find a group of testers that are willing to help compiling wxHaskell on different target systems: Windows, MacOS X, and Unix/GTK variations. I am happy to give volunteers administrator privileges on the sourceforge site and help out with the initial transition and building the initial new release (which is generally a lot of careful work in compiling and packaging correctly). All the best, -- Daan Leijen. Ps. Include me on the reply list as I am not subscribed properly to either mailing list at the moment. From: Simon Peyton-Jones Sent: Tuesday, August 01, 2006 4:46 AM To: Daan Leijen Subject: FW: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell) Daan Have you seen this thread? Would you care to respond to it? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy O'Donoghue Sent: 01 August 2006 09:37 Cc: haskell-cafe@haskell.org; [EMAIL PROTECTED] Subject: Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Troublecompiling wxhaskell) Hi list, Apologies for continuing with the cross-posting, but wxhaskell-users is not exactly active. It seems like there may be enough interest in wxHaskell to justify trying to revive the project. At present, from what I can tell, Daan Leijen, the principal developer of wxHaskell, no longer has much interest in the project - the CVS log shows little activity for about 15 months now - and using wxHaskell with newer wxWidgets versions or on Unicode systems requires the application of various patches (for which the interested potential user must search diligently). Ideally, it would be best Daan for to enable new CVS committers to the project (or even to hand over project administration), but if this is not an option, is there a possibility of hosting a fork on hackage.haskell.org (I think there's a benefit in hosting Haskell-specific projects in a Haskell-friendly location). I don't have the time to nurture huge ambitions for wxHaskell, but I think it is realistic to aim for the following in the short term: * Patches to ensure that wxHaskell compiles against latest wxWidgets versions on Mac, Linux and Windows (exists today) * Add Eric Kow's Unicode patches (exist today) * Produce suitable binary packages for whatever targets we can get maintainers for, compatible with up-to-date versions of both GHC and wxWidgets. * Improve samples and documentation. In the longer term, we could look at: * Fixing operation with sash windows (a personal gripe ;-) - easy * Wrapping some of the more complex widgets - easy. * Subclassing of widgets in Haskell ( i.e. allow C++ virtual methods to be redefined in Haskell) - moderately hard * Move from the Eiffel wxc bindings to wxC project to give better maintained interface to wxWidgets - time consuming, but easy * Porting to other Haskell implementations (Hugs, YHC etc) Taking on a project like this is a very significant commitment, and only makes sense if there are a number of willing contributors. I'm happy to kick this off and try to cover some of the boring 'administrative' bits, as well as contributing on documentation and smaller bug fixes, but I don't have time to save wxHaskell from permanent bit-rot. If there's enough interest, I'll push ahead with trying to organize this. Regards Jeremy On 01/08/06, shelarcy <[EMAIL PROTECTED]> wrote: > On 7/31/06, David F. Place <[EMAIL PROTECTED]> wrote: >> Hi: >> >> I'm having trouble compiling wxhaskell 0.9.4 under both ghc 6.4.2 and >> ghc 6.5. Does anyone know where I should direct my queries? If you use ghc 6,4,2 under Windows platform, you can use my patched version of wxHaskell. And you can get my patch from Kamiariduki's source. http://www.haskell.org/pipermail/haskell/2006-June/018043.html https://sourceforge.net/project/showfiles.php?group_id=168626 I also know Eric Y. Kow's unicode patch doesn't include db problems fix. These problems has not only wxWidgets 2.6.x change, but also unicode change. I try to fix latter case, use attached after unicode patch, this fixes compile problem ... but it has another problem that can't use non-ascii characters correctly. So, if want to accesss DB by wxHaskell's ODBC, data is garbled and cause problems. I don't know how to fix that. Attached is already sent wxhaskell-user's list, but you can't get this file. So I send again. http://sourceforge.net/mailarchive/message.php?msg_
Re: [Haskell-cafe] Future Edison directions
This page: http://jaortega.wordpress.com/2006/03/17/programmers-go-bananas/ lists some references at the bottom. Perhaps they would be useful. Jared. On 8/1/06, Brian Hulley <[EMAIL PROTECTED]> wrote: Robert Dockins wrote: [snip other points] > 7) Finally, I somehow feel like there should be a nice categorical > formulation of these datastructure abstractions which would help to > drive a refactoring of the API typeclasses in a principled way, > rather than on an ad-hoc I-sort-of-think-these-go-together sort of > way. Unfortunately, my category-fu is quite weak, so all I have is > this vague intuition that I can't substantiate. I'm sort of familiar > with initial algebras, but I think they may be too concrete. I'm > looking for some way to classify algebras that have, eg, the property > of having folds, or of being set-like, etc. If anybody can point me > in the right direction wrt this, that would be great. I'd love to find out more about these categorical abstractions also, since Monads and Monoids (the only ones I know about) are an incredible source of power and expressiveness in Haskell programming, so I've got the feeling that I'm wasting tremendous amounts of time reinventing the wheel when other abstractions that may be equally useful are just waiting to be used... Can anyone recommend a good book or web tutorial about category theory that's not too difficult? I'm thinking about something which would have lots of diagrams and discussion about the relevance of the concepts to practical computing problems but not something loaded with complicated proofs or LaTeX symbols :-) Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://www.updike.org/~jared/ reverse ")-:" ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Future Edison directions
Robert Dockins wrote: [snip other points] 7) Finally, I somehow feel like there should be a nice categorical formulation of these datastructure abstractions which would help to drive a refactoring of the API typeclasses in a principled way, rather than on an ad-hoc I-sort-of-think-these-go-together sort of way. Unfortunately, my category-fu is quite weak, so all I have is this vague intuition that I can't substantiate. I'm sort of familiar with initial algebras, but I think they may be too concrete. I'm looking for some way to classify algebras that have, eg, the property of having folds, or of being set-like, etc. If anybody can point me in the right direction wrt this, that would be great. I'd love to find out more about these categorical abstractions also, since Monads and Monoids (the only ones I know about) are an incredible source of power and expressiveness in Haskell programming, so I've got the feeling that I'm wasting tremendous amounts of time reinventing the wheel when other abstractions that may be equally useful are just waiting to be used... Can anyone recommend a good book or web tutorial about category theory that's not too difficult? I'm thinking about something which would have lots of diagrams and discussion about the relevance of the concepts to practical computing problems but not something loaded with complicated proofs or LaTeX symbols :-) Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The difficulty of designing a sequence class
John Meacham wrote: On Tue, Aug 01, 2006 at 02:56:21AM +0100, Brian Hulley wrote: Now the problem is that person C may come along and notice that there is a useful abstraction to be made by inheriting both from ClassA and ClassB. But both of these define "foo" and there is no mechanism in the language to resolve this. This is not true at all. every name in haskell can be uniquely specified. module ClassA where class ClassA a where foo :: a -> Int module ClassB where class classB a where foo :: a -> String import ClassA import ClassB class (ClassA a, ClassB a) => ClassC a where bar :: a -> (Int, String) bar x = (ClassA.foo x, ClassB.foo x) Hi John - Thanks for pointing this out. The only thing that I find slightly uneasy about it is that you have to keep the module names and class names in sync so that "ClassA.foo" which means "the value foo exposed by the module ClassA" is in truth the same as "the foo method of class ClassA". The language doesn't enforce this correspondence (indeed perhaps such a correspondence would be undesirable but it's difficult to get used to this need to keep different entities in sync instead of just being able to name the concept once in one place). I'm also wondering if it would be a good idea to be able to declare some class methods as final, so they don't clutter up the dictionary at runtime, and so that we could end the dubious practice of declaring some functions which are conceptually part of a class as top level functions outside the class just to save space/time in the dictionary and therefore needing the physical module to create the conceptual grouping instead of using the language level grouping provided by the class name. I think a fundamental thing you are missing is that Haskell classes are not like C# or Java or other OO classes. Not because of implementation, but rather they are actually fundamentally different things. The reasons people don't place certain functions in classes has nothing to do with the size of class dicionaries. Heck, jhc doesn't even use dictionaries at all, there is no cost for adding methods to a class. People place them in top level functions because it makes more sense. of course, sometimes it is gotten wrong, and something would have been better off as a class method, but in general there are different concerns when dealing with haskell classes than OO classes. An OO class could be considered equivalent to a triplet of a Haskell data type, a Haskell existential with a class constraint, and a class with the resriction the class type can _only_ appear as the first argument to each method. In haskell all of these things are separate independent tools and are much more general and powerful than the limited and conjoined form that OO programming provides. I think the transition from OOP to Haskell is difficult because although OOP is less powerful for the reasons you've mentioned, many of the decisions you have to make when writing Haskell code just don't exist in OOP eg in C# there are no modules to worry about, every class belongs to a file with the same name, you don't need to decide where to put the object argument and there are no top level functions or values. In contrast, in Haskell you have to juggle class declarations, instance declarations, types, values which may or may not be part of a class, and decide which combinations of the above should go into which modules and what the names of the modules should be and manually remember to keep some module names and class names (or type names eg Data.Set and data Set a = ...) in sync. Anyway these are probably more long term ideas but I mentioned them now just to hopefully start the ball rolling (the above should not be taken as a criticism of Haskell, I'm just saying that at some point we need all the normal mechanisms that everyone else (Java, C#) takes for granted because there's no point waiting till we encounter the same well-known software engineering problems that already have well established good solutions). It is best to think of haskell primitives as something completely new, they reuse some naming conventions from OO programming, but that doesn't mean they suffer from the same limitations. Hopefully my neural pathways will reconnect themselves soon to take advantage of all this new power!!! :-) It took me a few trys to wrap my brain around it. I liken learning haskell to tipping over a vending machine. you can't just push it, you gotta rock it back and forth a few times building up momentum until bam! suddenly the flash of insight hits and it all makes sense. Great image! We need a film or video of "a day in the life of Haskell" with these kind of things in it eg camera cutting from scene of vending machine satori to animated folds rippling through space gathering structure like a new planet forming, then another cut to a silent robed figure casting objects fr
Re: [Haskell-cafe] Memoizing longest-common-subsequence
On 8/1/06, Mark T.B. Carroll <[EMAIL PROTECTED]> wrote: I wanted a longest common subsequence function and a bit of Googling failed to turn up a functional one, except for in a scary bit of darcs. I saw a thread from back in the day about this when I was looking for a good implementation of sdiff (or diff) in Haskell (thank Googleness for Google): http://www.haskell.org/pipermail/haskell/2002-November/010731.html all message in thread: http://www.haskell.org/pipermail/haskell/2002-November/thread.html#10726 Jared. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] The difficulty of designing a sequence class
On Tue, 2006-08-01 at 14:37 +0400, Bulat Ziganshin wrote: > Hello Brian, > > Tuesday, August 1, 2006, 4:23:53 AM, you wrote: > > >> That's a tough call to make. Changing the kind of Sequence to * from * > >> -> * means losing the Functor, Monad, and MonadPlus superclasses and > >> all the various maps and zips. > > > But there's no option if you want to be able to support non-polymorphic > > sequences like Data.ByteString etc. I think the Functor class is just > > fundamentally too limited - it assumes the whole world is polymorphic and it > > isn't. > > it's possible, at least in principle, to make ByteString parametric > class: > > data PlainSequence a = ... > > type ByteString = PlainSequence Word8 > > and then rewrite all ByteString functions so that they will work with > elements of any type, not just Word8 Much of the performance advantages that we can get are due to the special representation and knowing the types involved. This would not work for arbitrary types. For one thing all the performance advantages of using a packed representation would be lost as we would have to use pointers to boxed objects rather than flat arrays of bytes. We can use low level standard C functions like memchr because we know the representation. There is certainly a place for a general strict sequence type but there is also a need for efficient handling of big chunks of bytes. It'd be even better if the special case representation collections could fit into a general framework. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] The difficulty of designing a sequence class
Bulat Ziganshin wrote: Hello Brian, Tuesday, August 1, 2006, 4:43:23 AM, you wrote: As you've pointed out, there are 2 separate issues that are in danger of being confused: 1) Forcing all sequence instances to support all operations 2) Bundling all the ops into a single huge class Collections library (darcs get --partial http://darcs.haskell.org/packages/collections/) defines good hierarchy of collection classes Hi Bulat - Thanks for the link to the collections repository. I've at last taken the plunge and installed darcs and managed to get this onto my computer (although with a strange warning from darcs: 'plink: unknown option "-O" '). I'll have to have a proper look into it. On superficial inspection, there are some unusual choices - for example putting (size) and (null) into Foldable instead of Collection, and calling "null" "null" instead of "isEmpty" (considering that Collection has a method called "isSingleton" which follows the usual convention of starting unary predicates with "is"). In any case it's interesting to see another possible factoring of the concept of collections to compare with Edison and the existing base collections. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Memoizing longest-common-subsequence
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] (Mark T.B. Carroll) writes: > > > I wanted a longest common subsequence function and a bit of Googling > > failed to turn up a functional one, except for in a scary > bit of darcs. > > The code in darcs is a translation of the example code in the > Eugene Myers > paper mentioned in the comments and the C code in GNU diff. I > didn't try > much to simplify it because I first wanted to see how close I > could come > to the perfomance of the C code. > > [..] > > > Take this as your cue to point out the much better LCS > algorithm that > > already exists in the standard libraries, that I couldn't find. (-: > > There is a nice implementation of the Hunt-Szymanski algorithm by > Ian Lynagh at http://urchin.earth.li/darcs/ian/lcs/. > > Benedikt I also had a go at this a while ago, using this Eugene Myers' paper as the specification: http://www.cs.arizona.edu/~gene/PAPERS/np_diff.ps which claims improvement over the one you mention above: http://www.cs.arizona.edu/~gene/PAPERS/diff.ps and also ended up with an STArray based implementation. I can send the code if you're interested. I have no idea how well it performs compared to Ian's, or the one in darcs (which uses PackedStrings). There's some kind of summary/comparison of LCS algorithms (including Hunt-Szymanski) here: http://www-math.mit.edu/~lippert/18.417/papers/mye:1991.pdf also by Eugene Myers. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble compiling wxhaskell
Hi, You can post wxHaskell related questions to the wxHaskell mailing list ([EMAIL PROTECTED]). I had problems when compiling wxhaskell 0.9.4 using wxWidgets 2.6.3. And I found out that in wxWidgets 2.6.3, some DB-related field names have changed: columnSize --> columnLength bufferLength --> bufferSize So I modified the file "db.cpp" (wxc/src/db.cpp), and succeeded to compile. I'm attaching the modified file. Cheers, On 8/1/06, David F. Place <[EMAIL PROTECTED]> wrote: Hi: I'm having trouble compiling wxhaskell 0.9.4 under both ghc 6.4.2 and ghc 6.5. Does anyone know where I should direct my queries? Thanks. David F. Place mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Jinwoo Lee Always remember that you are unique. Just like everyone else. db.cpp Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Memoizing longest-common-subsequence
[EMAIL PROTECTED] (Mark T.B. Carroll) writes: > I wanted a longest common subsequence function and a bit of Googling > failed to turn up a functional one, except for in a scary bit of darcs. The code in darcs is a translation of the example code in the Eugene Myers paper mentioned in the comments and the C code in GNU diff. I didn't try much to simplify it because I first wanted to see how close I could come to the perfomance of the C code. [..] > Take this as your cue to point out the much better LCS algorithm that > already exists in the standard libraries, that I couldn't find. (-: There is a nice implementation of the Hunt-Szymanski algorithm by Ian Lynagh at http://urchin.earth.li/darcs/ian/lcs/. Benedikt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Future Edison directions
Hello all, There has been very recently a thread discussing the design decisions involved in creating a sequence abstraction. This was naturally of interest to me as the current Edison maintainer, and generated a fair bit of interesting discussion. I'd like to kick off a new thread here to talk about future directions for the Edison API in particular. 1) Regarding Sequence, I have become convinced by the discussion that the Edison Sequence class should be broken down into smaller classes. Furthermore, it would be very nice to make these smaller classes shared across the various families of data structure abstractions in Edison (Sequences, Collections and Associative Collections). The formulation of Sequence of kind * -> * may need to be sacrificed to this end. I am not convinced that losing the maps and zips would be a major blow; however there are a couple of strategies for retaining them in some form. 2) The associated collection API is in a similar situation, except there are no zips. 3) I am reluctant to undertake a major overhaul of the Edison API while the future of type classes in Haskell' is so hazy. I haven't heard any news from the Haskell' type classes focus group in quite some time, and last I was aware, discussion was somewhat stalled. I there any hope for a coherent story here in the nearish future? 4) I am on the verge of deciding that nobody wants non-observable collections (ie, collections in which the element values are not available for inspection). Currently Edison has no implementations which are non-observable, and I am not aware of anyone else creating a datastructure implementation in Haskell which is non-observable. Therefore, I am considering removing this feature of the Edison typeclass hierarchy to reduce complexity. Shout if you think this would be a terrible mistake. 5) OTOH, something people DO seem to want is collection "views", or the ability to treat a datastructure as though it were something else. For example, it would be nice to transparently treat the keys of a finite map as a set, or to treat a nested sequence as a single flattened sequence. Such uses require the separation of operations which can create datastructures from those which merely inspect them (or some fancy bidirectional stuff I don't think I want to get into). 6) Edison 1.2 has now been out for a couple of months. If you've used or looked at the new Edison, I'd love to hear what you think. I think the next development cycle will involve pretty substantial changes, and if you want to get your gripes addressed, now is a good time to voice them. Alternately, if you think there are some aspects that are very important to keep, that's also good information. 7) Finally, I somehow feel like there should be a nice categorical formulation of these datastructure abstractions which would help to drive a refactoring of the API typeclasses in a principled way, rather than on an ad-hoc I-sort-of-think-these-go-together sort of way. Unfortunately, my category-fu is quite weak, so all I have is this vague intuition that I can't substantiate. I'm sort of familiar with initial algebras, but I think they may be too concrete. I'm looking for some way to classify algebras that have, eg, the property of having folds, or of being set-like, etc. If anybody can point me in the right direction wrt this, that would be great. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memoizing longest-common-subsequence
Mark T.B. Carroll wrote: Take this as your cue to point out the much better LCS algorithm that already exists in the standard libraries, that I couldn't find. (-: I don't know of a version in the libraries, but since you mentioned you were unsuccessful looking for any functional algorithms solving this problem: I would be very surprised if none could be found in some paper of Richard Bird's. Also, something like the memoizing implementation you give should be easily in reach using Giegerich and Kurtz' "algebraic dynamic programming" approach that I recently mentioned here. Of course, it would then be less straightforward to apply subsequent optimizations (like strictifying and unboxing), as the details of the implementation would be hidden inside their DSL. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Memoizing longest-common-subsequence
I wanted a longest common subsequence function and a bit of Googling failed to turn up a functional one, except for in a scary bit of darcs. So, I tried making a memoized functional version of the LCS delta algorithm on the problem's Wikipedia page. It's not the fastest, but it's simple and should be polynomial, growing with the product of input sequence lengths. I've not played with unboxing or strictness here yet, but with the help of Data.Array I have: longestCommonSubsequence xs ys = let lastIndex = (length xs, length ys) memo = array ((0, 0), lastIndex) [ ((xi, yi), deltaLCS (xi, x) (yi, y)) | (xi, x) <- zip [0..] (undefined : xs), (yi, y) <- zip [0..] (undefined : ys) ] deltaLCS (0, _) _ = (0, []) deltaLCS _ (0, _) = (0, []) deltaLCS (xl, x) (yl, y) = if (x == y) then let (xylShrunk, xysShrunk) = memo ! (xl-1, yl-1) in (xylShrunk + 1, x : xysShrunk) else let xaShrunk@(xlShrunk, _) = memo ! (xl-1, yl) yaShrunk@(ylShrunk, _) = memo ! (xl, yl-1) in if xlShrunk > ylShrunk then xaShrunk else yaShrunk in reverse (snd (memo ! lastIndex)) I haven't looked much at optimizing this further so there are probably yet some easy wins to be had - I'd be interested to see what they are. Still, I thought it worth sharing as an example of laziness making memoization easy in a simple functional longest common subsequence example. Take this as your cue to point out the much better LCS algorithm that already exists in the standard libraries, that I couldn't find. (-: -- Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] The difficulty of designing a sequence class
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Meacham > > I liken learning haskell to tipping over a > vending machine. you can't just push it, you gotta rock it back and > forth a few times building up momentum until bam! suddenly > the flash of insight hits and it all makes sense. > > John This reminds me of the Simpson's episode where Homer attacks a vending machine and it falls on him, crushing him while at the same time spewing chocolate into his mouth. He falls into a coma. Haskell can be like that too, some days. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The difficulty of designing a sequence class
On Jul 31, 2006, at 10:27 PM, John Meacham wrote: [snip] It is best to think of haskell primitives as something completely new, they reuse some naming conventions from OO programming, but that doesn't mean they suffer from the same limitations. It took me a few trys to wrap my brain around it. I liken learning haskell to tipping over a vending machine. you can't just push it, you gotta rock it back and forth a few times building up momentum until bam! suddenly the flash of insight hits and it all makes sense. Do you have a lot of personal experience attaining zen-like insight by tipping over vending machines? I'll have to try that some time ;-) *chucke* Thanks for making me laugh this morning. John Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] The difficulty of designing a sequence class
Hello Einar, Tuesday, August 1, 2006, 1:58:30 PM, you wrote: > class ElementType c a | c -> a > class Foldable c where > fold :: ElementType c a => (a -> b -> b) -> b -> c -> b i love it! will it be possible to write smth like this: class Stream m h | h->m data T h = (Stream m h) => C (m Int) ? currently, i need to pass 'm' parameter to T type constructor too, because GHC can't guess what 'm' is determined by 'h' -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A program which never crashes (even when a function calls "error")
Hello Stephane, Tuesday, August 1, 2006, 10:52:06 AM, you wrote: >except Exception e: don't look at anything except than "Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell" http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/marktoberdorf.ps.gz -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] The difficulty of designing a sequence class
Hello John, Tuesday, August 1, 2006, 6:27:29 AM, you wrote: > It is best to think of haskell primitives as something completely new, > they reuse some naming conventions from OO programming, but that doesn't > mean they suffer from the same limitations. It took me a few trys to > wrap my brain around it. I liken learning haskell to tipping over a > vending machine. you can't just push it, you gotta rock it back and > forth a few times building up momentum until bam! suddenly the flash of > insight hits and it all makes sense. btw, http://homepages.cwi.nl/~ralf/gpce06/ can help on this way. i think that there is also other papers that can help too but i also agree with Brian - there is some constraints in Haskell comparing to C++ and vice versa. while developing Streams library i was many times bitten by these restrictions -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] The difficulty of designing a sequence class
Hello Brian, Tuesday, August 1, 2006, 4:43:23 AM, you wrote: > As you've pointed out, there are 2 separate issues that are in danger of > being confused: > 1) Forcing all sequence instances to support all operations > 2) Bundling all the ops into a single huge class Collections library (darcs get --partial http://darcs.haskell.org/packages/collections/) defines good hierarchy of collection classes -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] The difficulty of designing a sequence class
Hello Brian, Tuesday, August 1, 2006, 4:23:53 AM, you wrote: >> That's a tough call to make. Changing the kind of Sequence to * from * >> -> * means losing the Functor, Monad, and MonadPlus superclasses and >> all the various maps and zips. > But there's no option if you want to be able to support non-polymorphic > sequences like Data.ByteString etc. I think the Functor class is just > fundamentally too limited - it assumes the whole world is polymorphic and it > isn't. it's possible, at least in principle, to make ByteString parametric class: data PlainSequence a = ... type ByteString = PlainSequence Word8 and then rewrite all ByteString functions so that they will work with elements of any type, not just Word8 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The difficulty of designing a sequence class
On 31.07 16:27, Brian Hulley wrote: > None of the above type classes would be compatible with Data.ByteString! > (You mentioned this issue before wrt Data.Edison.Seq but it just clicked > with me now for the above refactoring.) For compatibility, the element type > would need to appear also thus: > > class Foldable f_a a | f_a -> a where >fold :: (a -> b -> b) -> b -> f_a -> b > With the new System FC (when it is merged) we could make these classes nicer. class ElementType c a | c -> a instance ElementType [a] a instance ElementType ByteString Char instance IArray a e => ElementType (a i e) e class Foldable c where fold :: ElementType c a => (a -> b -> b) -> b -> c -> b This won't work at the moment due to limitations in GHC, but seems like a cleaner solution. - Einar Karttunen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A program which never crashes (even when a function calls "error")
On Tue, 1 Aug 2006, Stephane Bortzmeyer wrote: > [It is a philosophical question, not a practical programming problem.] > > I'm used, in imperative programming languages with exceptions (like > Python) to call any function without fear of stopping the program > because I can always catch the exceptions with things like (Python): > > while not over: >try: > code which may raise an exception... >except Exception e: > do something clever > > How to do it in Haskell? How can I call functions like Prelude.head > while being sure my program won't stop, even if I call head on an > empty list (thus calling "error")? Catching errors is quite a hack. If the head of an empty list is requested, then this is considered a programming error, not a user error. Thus the best is to stop the program. Don't mix programming errors with problems caused by users (that is, exceptions). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Parsec] Backtracking with try does not work for me?
Stephane Bortzmeyer wrote:
On Mon, Jul 31, 2006 at 06:51:27PM +0100,
Chris Kuklewicz <[EMAIL PROTECTED]> wrote
a message of 102 lines which said:
minilang = do
char 'a'
optional (try (do {comma ; char 'b'}))
optional (do {comma ; char 'c'})
eof
return "OK"
I now have a new problem which was hidden beneath. If the language
authorizes "a,bb" and "a,bbc", "a,bbc" is not accepted by my parser
since it already accepted "a,bb" and the "c" which is left triggers a
syntax error.
This time, "try" believes it succeeded but should not. I need more
look-ahead but I'm not sure how?
The problem is mentioned here:
http://www.cs.uu.nl/people/daan/download/parsec/parsec.html#notFollowedBy
Your whole parser is indeed failing, and again it is because of the "failing
after consuming some input" issue. For "a,bbc" your "bb" token parser consumes
the "bb" and then the dangling "c" causes the error.
So you cannot commit to consuming the "bb" unless you know the rest of the
string is okay. There are a few ways to accomplish this. The first would be to
test whether "bb" is followed by "eof" or "comma" before accepting it. Another
solution is to try and parse what follows "bb" before accepting "bb".
A small fix would look like:
minilang' = do
string "a"
optional (try $ do {comma ; string "bb"; endToken})
optional (do {comma ; string "bbc"})
eof
return "OK"
where endToken = eof <|> lookAhead (comma >> return ())
A more general fix looks like this:
stringLang :: [String] -> GenParser Char st [String]
stringLang items = polyLang comma (map string items)
listLang :: [Char] -> GenParser Char st [Char]
listLang items = polyLang comma (map char items)
The first version of polyLang uses the "test eof or comma before accepting"
strategy:
polyLang :: (Show element,Show token) => GenParser element state ignore
-> [GenParser element state token] -> GenParser element state [token]
polyLang _ [] = eof >> return []
polyLang separator input = (use input) <|> polyLang separator (tail input)
where use (opX:xs) = do
(x,test) <- try (do x <- opX
test <- more
when test (separator >> return ())
return (x,test))
rest <- if test then (loop xs <|> unexpected ("(problem after "++show x++")"))
else return []
return (x:rest)
more = option True (eof >> return False)
loop [] = (unexpected "cannot parse")
loop input' = use input' <|> loop (tail input')
The second version polyLang' uses the "test rest of input before accepting"
strategy:
polyLang' :: (Show element,Show token) => GenParser element state ignore
-> [GenParser element state token] -> GenParser element state [token]
polyLang' _ [] = eof >> return []
polyLang' separator input = (use input) <|> polyLang' separator (tail input)
where use (opX:xs) = try (do x <- opX
test <- more
rest <- if test
then separator >> (loop xs <|> unexpected ("(problem
after "++show x++")"))
else return []
return (x:rest))
more = option True (eof >> return False)
loop [] = (unexpected "cannot parse")
loop input' = use input' <|> loop (tail input')
It works:
*Main> run (stringLang ["a","bb","bbc"]) "a,bbc"
["a","bbc"]
The error reporting gets a bit strange, and is different between the two
versions of polyLang'
*Main> run (polyLang comma (map string ["a","bb","bbc","dd"])) "a,bbc,bb"
parse error at (line 1, column 7):
unexpected cannot parse or (problem after "bbc")
expecting "dd"
*Main> run (polyLang' comma (map string ["a","bb","bbc","d"])) "a,bbc,bb"
parse error at (line 1, column 1):
unexpected "c", cannot parse, (problem after "bbc"), (problem after "a") or "a"
expecting end of input, ",", "dd", "bb" or "bbc"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reviving wxHaskell (was: Re: [wxhaskell-users] [Haskell-cafe] Trouble compiling wxhaskell)
Hi list,Apologies for continuing with the cross-posting, but wxhaskell-users is not exactly active.It seems like there may be enough interest in wxHaskell to justify trying to revive the project.At present, from what I can tell, Daan Leijen, the principal developer of wxHaskell, no longer has much interest in the project - the CVS log shows little activity for about 15 months now - and using wxHaskell with newer wxWidgets versions or on Unicode systems requires the application of various patches (for which the interested potential user must search diligently). Ideally, it would be best Daan for to enable new CVS committers to the project (or even to hand over project administration), but if this is not an option, is there a possibility of hosting a fork on hackage.haskell.org (I think there's a benefit in hosting Haskell-specific projects in a Haskell-friendly location).I don't have the time to nurture huge ambitions for wxHaskell, but I think it is realistic to aim for the following in the short term: * Patches to ensure that wxHaskell compiles against latest wxWidgets versions on Mac, Linux and Windows (exists today)* Add Eric Kow's Unicode patches (exist today)* Produce suitable binary packages for whatever targets we can get maintainers for, compatible with up-to-date versions of both GHC and wxWidgets. * Improve samples and documentation.In the longer term, we could look at:* Fixing operation with sash windows (a personal gripe ;-) - easy* Wrapping some of the more complex widgets - easy.* Subclassing of widgets in Haskell ( i.e. allow C++ virtual methods to be redefined in Haskell) - moderately hard* Move from the Eiffel wxc bindings to wxC project to give better maintained interface to wxWidgets - time consuming, but easy * Porting to other Haskell implementations (Hugs, YHC etc) Taking on a project like this is a very significant commitment, and only makes sense if there are a number of willing contributors. I'm happy to kick this off and try to cover some of the boring 'administrative' bits, as well as contributing on documentation and smaller bug fixes, but I don't have time to save wxHaskell from permanent bit-rot. If there's enough interest, I'll push ahead with trying to organize this. RegardsJeremyOn 01/08/06, shelarcy <[EMAIL PROTECTED]> wrote: > On 7/31/06, David F. Place <[EMAIL PROTECTED]> wrote:>> Hi: I'm having trouble compiling wxhaskell 0.9.4 under both ghc 6.4.2 and>> ghc 6.5. Does anyone know where I should direct my queries?If you use ghc 6,4,2 under Windows platform, youcan use my patched version of wxHaskell.And you can get my patch from Kamiariduki's source. http://www.haskell.org/pipermail/haskell/2006-June/018043.htmlhttps://sourceforge.net/project/showfiles.php?group_id=168626 I also know Eric Y. Kow's unicode patch doesn'tinclude db problems fix. These problems has notonly wxWidgets 2.6.x change, but also unicodechange.I try to fix latter case, use attached after unicode patch, this fixes compile problem ... but it hasanother problem that can't use non-ascii characterscorrectly. So, if want to accesss DB by wxHaskell'sODBC, data is garbled and cause problems.I don't know how to fix that. Attached is already sent wxhaskell-user's list, butyou can't get this file. So I send again.http://sourceforge.net/mailarchive/message.php?msg_id=16222530 My patch where I put Kamiariduki's project page doesn'tinclude unicode support that I noticed above Mailng-List'slog.Don't worry about this. You can use both my patch andunicode patch, if you want. These cause conflict message but this is not problem.On Tue, 01 Aug 2006 08:18:27 +0900, Jason Dagit<[EMAIL PROTECTED]> wrote:> I've done this recently. I put my notes on the wiki: > http://www.haskell.org/haskellwiki/WxHaskell/Install#WindowsI don't know this problem when I made patch.So, my patch doesn't fix this problem. --shelarcy capella.freemail.ne.jp>http://page.freett.com/shelarcy/- Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___wxhaskell-users mailing list [EMAIL PROTECTED]https://lists.sourceforge.net/lists/listinfo/wxhaskell-users ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A program which never crashes (even when a function calls "error")
On Tue, Aug 01, 2006 at 08:52:06AM +0200, Stephane Bortzmeyer wrote: > To: haskell-cafe@haskell.org > From: Stephane Bortzmeyer <[EMAIL PROTECTED]> > Date: Tue, 1 Aug 2006 08:52:06 +0200 > Subject: [Haskell-cafe] A program which never crashes (even when a function > calls "error") > > [It is a philosophical question, not a practical programming problem.] > > I'm used, in imperative programming languages with exceptions (like > Python) to call any function without fear of stopping the program > because I can always catch the exceptions with things like (Python): > > while not over: >try: > code which may raise an exception... >except Exception e: > do something clever > > How to do it in Haskell? How can I call functions like Prelude.head > while being sure my program won't stop, even if I call head on an > empty list (thus calling "error")? in haskell98, you can't. if you cannot prove a list will always be non-empty, you should use pattern matching instead of head. one disadvantage of exceptions is that the byte code tends to be slow and ugly and hard to generate, in particular in pure lazy languages. but admittedly sometimes exceptions are cool. therefore ghc comes with a quite sophisticated and mature exception handling library. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html looks a little different from python, but should do the trick. cheers, matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A program which never crashes (even when a function calls "error")
On 8/1/06, Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote:
How to do it in Haskell? How can I call functions like Prelude.head
while being sure my program won't stop, even if I call head on an
empty list (thus calling "error")?
Try looking at Control.Exception. For example:
module Test where
import Control.Exception
import Prelude hiding (catch)
example =
(do print (head (tail "a"))
return "ok")
`catch` (\e -> do putStrLn ("Caught exception: " ++ show e)
return "error")
produces:
*Test> z <- example
Caught exception: Prelude.head: empty list
*Test> z
"error"
This might be the beginning of what you want.
/g
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
