Re: [Haskell] Better Exception Handling
On Tue, 23 Nov 2004, John Goerzen wrote: (snip) > I've been using Haskell for 1-2 months now, and feel fairly comfortable (snip) > catchJust :: (Exception -> Maybe b) -> (c -> a) -> c -> (b -> a) -> a (snip) Yes, this was one of the first things that bothered me, too, when I started actually writing much Haskell code: I wanted a non-monadic version of try/catch. Because a pure function should always return the same value given the same arguments, the behaviour of such a try/catch must be made quite deterministic: for example, perhaps it should only return exceptions generated in its own execution thread (to make it entirely synchronous), and perhaps all the exceptions that could be generated in its evaluation should be generated (so we don't learn anything about evaluation order - after the first exception, we may need to carry on evaluating other parts of the expression to find what other exceptions there are). I seem to have learned to live with the lack of such non-monadic exceptions: often I use monads for this sort of error propagation thing, but not the standard try/catch in the IO monad because I avoid the IO monad wherever possible because functions in the IO monad are so unconstrained by the type system with regard to what effects they could have. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] IO, exceptions and error handling
On Mon, 14 Jun 2004, Keith Wansbrough wrote: (snip) > to lose referential transparency. What is the value of > > catchExcept (show (makeExcept "E1" + makeExcept "E2")) (\x -> x) > > ? Haskell wouldn't be "purely functional" any more. (snip) We've already had these issues raised on haskell-cafe when I've been wanting non-monadic synchronous exceptions. (-: The answer is that you evaluate all branches sufficiently to discover all the exceptions raised, and maybe have an ordering on exceptions such that you can return "answers" deterministically (as a list of ones that occurred or something). I'll be happy to follow discussion of this on haskell-cafe but will be reluctant to say much that I've already said (e.g. in December 2002's "Error Handling") for fear of boring everyone silly. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell and Artificial Intelligence
On Wed, 21 Apr 2004, GAYLE, Orrett Orville wrote: > I am having great difficulty finding resources with AI sysytems > implemented in Haskell. If anyones knows of a book or site which covers > AI techniques implemented using haskell, could you please help me. Ask me in a year or two, if you're still interested. This summer my company will start trying to implement stuff inspired by Josephson's "Abductive Inference" (Cambridge University Press) in Haskell. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Haskell job (OH, USA)
Aetion Technologies LLC seeks another high-quality programmer. Development is mostly in Haskell, with some Java, mostly under Linux. An ideal candidate is excellent at acquiring, applying, and writing about new knowledge. Additional background in disciplines like mathematics, science, engineering, etc. is also attractive. Aetion's main customers are in defense and finance, so we prefer to hire people who can likely get a security clearance, and who do not object to developing military applications. Telecommuting isn't really an option, but Columbus, Ohio is a nice enough city, and the work tends to be varied and interesting - more challenging than mundane. Although we work to build useful software, a lot of our activities are at the leading edge of research, keeping us far ahead of competitors. The vacancy has not yet been advertised more formally through the usual HR channels. Aetion is most definitely an equal-opportunity employer. It would be fine to direct questions and resumes directly to me; I can pass them on to the right people where necessary. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Why are strings linked lists?
On Sat, 29 Nov 2003 [EMAIL PROTECTED] wrote: (snip) > Interesting that you mention this. I've also been thinking about this > lately in the context of the discussion on collections and the left-fold > combinator both here and on LtU. When people say "I want String to be > [Char]", what I'm actually hearing is "I want String to be a collection > of Char". I may be mishearing. It did strike me that it would be interesting if you could make various things instances of a List sort of class and then take, reverse, etc. would work on them. How this relates to your comment, I'm not sure. Things like map, of course, could work on unordered bags of things too, but I suppose that's what Functors are for. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Question About lists
On Mon, 30 Dec 2002, Cesar Augusto Acosta Minoli wrote: > Hello! I'm Working with Lists in Haskell, I´m a Beginner in Functional > Programming and I would like to know if there is a way to write a more > efficient function that return the length of a list, I wrote this one: > > long :: [a]->Int > long p = longitud p 0 > where > longitud [] s=s > longitud (x:xs) s=longitud xs (s+1) > > but I think that it have a lineal grow O(n). Yes, it's O(n), but you can't do any better for calculating the length of a list. Your second parameter seems to be an accumulator which is the sort of thing you'd make explicit in an imperative approach but can often be eliminated in functional code - e.g., long [] = 0 long (x:xs) = 1 + long xs A decent optimizing compiler will probably turn that code into something that uses an accumulator. This code probably isn't any more efficient than yours, it's just shorter. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: SUGGESTION: haskell-announce mailing list
On Sat, 11 May 2002, Jorge Adriano wrote: (snip) > I like the actual haskell/haskell-cafe situation. At least it seemed reasonable to me that many more people would be interested in discussing proposed changes to the Haskell 98 spec. than there are in wading through various newbie questions. I think the current haskell/haskell-cafe distinction allows this quite well, separating "important discussion" from other discussion. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: reading from file
On Tue, 22 Jan 2002, S.D.Mechveliani wrote: > Who would tell me, please, what is the simplest way to read a > string from a file? > Namely, what has one to set in place of `...' in the program > > main = putStr (...) > > to obtain instead of `...' a string contained in the file > "foo.txt" ? main = readFile "foo.txt" >>= putStr -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: not naming modules Main
On Fri, 16 Nov 2001, Iavor S. Diatchki wrote: (snip) > having said all that, there seems to be a bug in ghc (or perhaps > an implementation restriction), which requires that "main" is defined > in the module "Main". the only other haskell implementation i have (snip) Actually, what would be nice in ghci is to be able to :load modules that don't have "main" defined. Followups should probably go to one of the GHC lists though, I guess. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: suggestion
On Tue, 23 Oct 2001, Andre W B Furtado wrote: > What do you all think about activating the mechanism that automatically > includes the name of the list before the subject of a mailing list email? I like the idea. > For example: > "[hugs-users] Installation problems" or "[haskell] newbie question". I think > this would be a nice way to make massages more organized and help people who > sign multiple lists. I heard somewhere that this is possible, isn't it > Simon? Yes, this list is run through mailman - one of the general list configuration options should be the prefix for the subject line of list postings. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: read-ing scientific notation
On Fri, 12 Oct 2001, Simon Peyton-Jones wrote: > | GHC is oddly particular about decimal points in "read"-ing in > | of Doubles in scientific notation. It seems that read > | "3.0e-06" is acceptable but read "3e-06" is not (both read > | "3" and read "3.0" work fine as Doubles). It's the same in (snip) > It's an unforced change and therefore to be regarded with > deep suspicion. I'd be interested in people's views about this. I was actually recently caught out by this - I'd assumed that 3e-06 would work (as it does in Modula-3, etc.), and it didn't. Personally, my preference would be for it to mean just the same as 3.0e-06 - it's annoying having to go through my physical constants now adding the rather-redundant ".0"'s everywhere. (-: But, with the sort of parsing I'm doing, "terms" are largely separated by whitespace anyway; maybe if they weren't I'd want things different. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Namespaces (was Re: GUI Library Task Force)
On Wed, 10 Oct 2001, Hal Daume III wrote: (snip) > least) is that the Java compiler knows how to interpret the "."s and > will use them to navigate directory structure. (snip) Yes, that's certainly an interesting idea. I'd like to fall short of mandating anything about location of source files in any language spec, though: although I can see that people probably find Java's imposed semantics useful, personally I find them irritating and wouldn't want to shackle everyone to them. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: RFC: GUI Library Task Force
On Mon, 24 Sep 2001, Ashley Yakeley wrote: > At 2001-09-24 05:44, Manuel M. T. Chakravarty wrote: (snip) > >* The library focuses on graphical *user interfaces* (ie, > > buttons, menus, scrollbars, selection lists, etc) as > > opposed to drawing and animation routines. > > Java has APIs for both, I believe. It does indeed, at least enough for my purposes. (snip) > >* We will not design a "purely functional GUI": > > Same. Pity; the idea does sound intriguing. (-: (I know nothing about them though, hence the smiley.) > >The Plan > > > >* Handling of state altered by both the application and by > > GUI widgets: > > I'm not sure what the issue is here. (snip) I guess the point is that the application needs to be able to drive GUI events itself, and it also has to be able to respond to actions by the user. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: RFC: GUI Library Task Force
On Mon, 24 Sep 2001, Ch. A. Herrmann wrote: (snip) > Many applications where GUIs are used require a canvas/scribble field > with the following basic functionality: (snip) Absolutely. The only reason I've found Java usable is that I can make my own Canvases and LayoutManagers and 'implement' many GUI components myself - its standard offering is adequate for the sorts of thing you'd use VisualBasic for, but not for wierder stuff. (-: -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
Mike - I hope you don't mind passing this to the list - but it's a great, simple explanation of a big problem with my approach. On 14 Sep 2001, Mike Gunter wrote: > The problem is not a loss of referential transparency but the > requirement that evaluation order must be specified. E.g. > what should > > raise "left" + raise "right" > > return? (snip) Ah! Yes, I see what you mean - this explains what Andy Moran was thinking, probably. (-: Moreover, if we have a pseudo-Haskell code snippet like, try f (a 1) (b 2) catch error-1 -> 1 error-2 -> 2 where a _ = raise error-1 b _ = raise error-2 ... then is the return value of this 1 or 2? AFAICS a simple way to get out of this is to only have one exception type that carries no information instead of different ones so we can't distinguish one exception from another, but that's obviously not great. One other thing you could do, which might mean a bit more evaluating than you otherwise would have done, is to evaluate enough to find out what the different possible "first exception"s are, gather them all up, and the handler that operates is the first applicable one if you list the higher-level 'catch' statements before the lower ones (so there's a total order on the handlers for exceptions arising from any particular expression within an evaluation). So, in this case, we detect that error-1 and error-2 were both thrown, but we return '1' because the error-1 handler was listed before the error-2 handler, just as we do with pattern matching IYSWIM. So, maybe we do have a way to resolve this that doesn't reveal evaluation order, with the penalty that we have to evaluate enough to discover which possible exceptions get thrown so that we really do use the 'first' applicable handler. I'm also subscribe to haskell-cafe if people think this discussion should migrate to there. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On 14 Sep 2001, Jeffrey Palmer wrote: (snip) [ good stuff ] > Thoughts? A shortage of volunteers? I get the impression that there's a reasonable consensus on what needs to be done; it's just that too few of us have the time and expertise to execute it. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On Fri, 14 Sep 2001, Bill Halchin wrote: > Probably this question has been brought before. Besides the Preludes, > why doesn't > > Haskell have libraries like Java, Squeak (Smalltalk). I found this: (snip) I'm puzzled - it does! - see http://www.haskell.org/libraries/ for some of them. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
I may as well send my reply to the list too, then! (-: On Fri, 14 Sep 2001 [EMAIL PROTECTED] wrote: > Mark Carroll wrote: (snip) > > Oh, certainly, but couldn't the compiler do all the rewriting for you, > > though, so existing code would still work and new code would still look > > nice? > > I'm not sure how this would interact with type inference; what's the > difference between a function that I mean to be rewritten and one that I > don't? Perhaps what you're wanting is that every type implicitly has an > exception constructor tacked on. This is in effect what one gets with the > exception extension. Yes, I suppose you're correct, although I'd add that I'd expect that the compiler could often do lots of optimisation so that it only needs to check for the exceptional condition when checking the result of a function from which exceptions can arise, and in that case it can go right up to the handler, so in practice I bet that you could implement this without every single calculation being tainted by such overhead even though there's no semantic difference. > > (Although, the main point of my Succeeded/Exception example is just > > to show that for much exception stuff monads needn't be necessitated.) > > I'm not sure what you mean here. For hand-written exception code, monads make > the code easier to read in most cases. But I don't think you mean that; it > sounds like you mean "exceptions can be expressed already, so there's no need > for new stuff". I don't buy that in general (since otherwise, why not just > use the raw lambda calculus, or Turing machines), or in this specific case, > since the encoding is a lot of work, and needs to be done for almost > everything you might use (including things one usually doesn't have access to, > like the Prelude and library code). But maybe you don't mean that. I sort of do mean that, with the compiler doing the work you mention. There would be "new stuff" in how the "throws/catch" stuff the programmer would write would interact with how the compiler would implement the synchronous exceptions, but it would look reasonable to the programmer and not require them to catch such exceptions from within monads. (snip) > Well, if you can deal with only catching in the IO monad, then what you want > is avilable now, with the extension (GHC only at the moment I think). > Otherwise, you're stuck encoding it. Now, you may well be able to structure > your code better if you employed an exception monad (not the IO monad, just an > ordainary monad), or perhaps a continuation monad. (Aside: it seems as though > you're lumping general monads, usable anywhere without affecting the rest of > the program, together with the IO monad, which is the top-level > put-impure-things-here monad. It's important to see that there's a > difference. I apologise if you do; if you don't, feel free to ask probing > questions.) (-: Really, I just want to be able to use exceptions that behave more or less as I've suggested without having to catch them from within monads. It would indeed be especially irritating to have to catch them all within the IO monad, as I would now if I wasn't doing the ugly manual encoding that I currently have to that I figure could easily be done behind the scenes with some much nicer syntactic sugar on top. I may not understand monads enough, though. I think of them being inextricably linked with actions, probably sequenced ones, and I'm wanting to use exceptions in purely declarative code where actions shouldn't be relevant concept. Perhaps I should be writing this code in a monadic style, though, and thinking in terms of actions. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
On Fri, 14 Sep 2001, Mark Carroll wrote: (snip) > simplistic (but adequate for my immediate needs, which are currently > being served with lots of ifs and Maybes!). Oh - and I should add, lots of two-tuple return values which are basically of the form (Maybe a, error details). ): -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
On Fri, 14 Sep 2001 [EMAIL PROTECTED] wrote: (snip) > Further clarification: the extension allows you to _raise_ exceptions in pure > functions, but you may only catch them in the IO monad. > > This asymmetry is very important for Haskell, since otherwise evaluation order > would be observable. This would break many important equalities and render > almost any optimizations unsafe (i.e., GHC would be crippled). ML allows one > to catch exceptions in pure functions with impunity, and can do so because > evaluation order is fixed. The story is similar for imperative languages. (snip) For the sort of exception where the function you're calling either returns successfully or throws an exception, I'm not sure why things can't be done entirely referentially transparently. One would do it in just the same way that something might return a 'Succeeded a' or 'Exception String' or something as aspects of an algebraic data type. The function, whenever it does something that might cause an exception, if it gets a 'Succeeded a' returned it goes ahead and returns something based on the a, or else it returns the Exception String, except if there's a 'catch' which specifies some other value to return if there was an exception. Basically, such simple exceptions can have a 'try', 'catch' construct simply being syntactic sugar around existing Haskell using algebraic types, pattern matching and 'if' statements, so I don't see why monads need to be brought in. Evaluation is done exactly as usual - when you decide to do something predicated on whether or not there was an exception thrown, we evaluate enough to find out if an error condition happened. However, there is a lot I don't know about Haskell! I assume you're talking about some more exciting sort of exception, like things with multiple threads or something, and I'm thinking of something more simplistic (but adequate for my immediate needs, which are currently being served with lots of ifs and Maybes!). -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote: (snip) > wxWindows is quite C++ centric and AFAIK nobody has made a > serious effort at a C++ FFI yet. One of the big advantages (snip) Of course, wxPython also exists - I assume that the emphasis on object orientation is the problem? -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On Thu, 13 Sep 2001, S. Alexander Jacobson wrote: (snip) > As such, I would like to see a focus on making Haskell great for web > application and web service development. Some of the the pieces required > are application level, some are libraries, and some are language features. > Here is my quick take: (snip) > I know this is a lot of work, but it was what you get from Python, Perl, > and Java. If Haskell wants to compete in this arena, it needs to provide > this level of service. Also, I think a lot of these exist in pieces, so > the real work is in compiling it all into a good usable package. I am not (snip) For what little it's worth, I'm encouraged just to see people talking like this lately: such things would make a lot of difference in making me much more comfortable about using Haskell for non-trivial commercial projects. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
It seems like a common thread is a shortage of willing programming effort so that things may be maintained and improved. Would it be worth thinking about how to promote Haskell in communities where people might be willing and able to contribute to the work? (Much thanks to the people who are already part of it.) -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
STRAW POLL: comp.lang.haskell (fwd)
People should be aware of this article that was recently posted to the newsgroup comp.lang.functional. --- start of forwarded message --- From: [EMAIL PROTECTED] (Jeffrey M. Vinocur) Newsgroups: comp.lang.functional,news.groups Subject: STRAW POLL: comp.lang.haskell Date: Thu, 19 Jul 2001 15:31:05 + (UTC) Message-ID: <9j6ufp$fil$[EMAIL PROTECTED]> I'm volunteering to take a straw poll to see whether we should try proposing comp.lang.haskell as a new newsgroup, possibly gatewayed to a mailing list. Currently Haskell-related traffic is in comp.lang.functional, and some people feel that it is a sufficiently-large portion of the traffic there to warrant a separate group. Opinions should be sent to <[EMAIL PROTECTED]>. What we're really trying to determine is how many people would respond to an eventual Call For Votes in news.groups. There would first be a discussion period to hash out the details of things like mailing list gatewaying. (There is some discussion going on in comp.lang.haskell at the moment, feel free to join in there.) Reasonable choices for opinions are "Yes", "No", "Yes, provided it's gatewayed to a mailing list", "Yes, provided it's not gatewayed to a mailing list", "Will abstain from voting but don't want it gatewayed to the mailing list", etc. Note that a perfectly rational justification for wanting a separate group is because you read comp.lang.functional and want the Haskell traffic elsewhere; you need not be interested in reading a Haskell-only group. I'll post a summary of results, mmm, early next week, perhaps. So please reply promptly. -- Jeffrey M. Vinocur [EMAIL PROTECTED] --- end of forwarded message --- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Notation question
On Mon, 28 May 2001, Juan Carlos Arevalo Baeza wrote: > > Just a very naive question, because I'm really curious. I've seen in > previous messages here discussions about type systems using this kind of > notation: > > > G |- f :: all x::S . T G |- s :: S > >-- > > G |- f s :: [s/x]T > > I'd never seen it before, and a few searches I've launched over the net > have turned up just a couple more examples of this notation, but without a > single reference to how it works or what it means, or even what it's > called, for that matter. > >I'd appreciate any pointers. (snip) I'm far from the right person to have a go, but while we're waiting for someone who knows what they're talking about: I bet that |- is 'entails'. My impression of it is rather like 'implies', but clearly that's not quite right or we wouldn't need a different term for it. The . might be 'such that'. The thing below the - might be a consequence of the two things above it. The [s/x]T means, probably, "T with s substituted for any occurrence of x". (Did I get that the right way around?) I hope that's a start. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Existential Type Declarations in Hugs
On Thu, 3 May 2001 [EMAIL PROTECTED] wrote: (snip) > BTW, what is this "Skolem constant" that's referred to in the error message > that I received? A combination of http://www.sdsc.edu/~tbailey/teaching/cse151/lectures/chap09a.html and http://cs.wwc.edu/~aabyan/Logic/normal.html may answer that for you. (-: (It was too long ago now for me to remember much, and I'm not sure where my notes are, so I daren't attempt an explanation myself!) -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
