Re: [Haskell-cafe] Re: [Haskell-beginners] map question
> [snip] > Not a hack, a solution. A consistent one. Look: > > (`foldl` 0) > (`-` 2) > > Don't they look exactly the same? > [snip] These look the same too (and *are* consistent): (f a b) (+ a b) But it's not Haskell.. IMO conflating binary minus and unary minus is not consistent. Something I wonder from time to time if it would be a good thing or not is to allow a `f g` b to mean f g a b (so map (`f g` b) as would legal too). Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell-beginners] map question
On Sun, Oct 18, 2009 at 5:31 PM, Will Ness wrote: > Luke Palmer gmail.com> writes: > >> >> Or you could use the "subtract" function. >> >> >>> map (subtract 2) [3,4,5] >> [1,2,3] > > I don't want to. I think at about this point, this stopped being an intellectual discussion. Preparing for academic flame war... >> >> I don't think syntax sugar is worth it in this case. > > > I do. Operators are great because they make our intent visible, immediately > apparent. Long words' meaning, like subtract's, is not immediately apparent, > and they break consistency. Not everyone's first language in life was English, > you see. > > (`foldl`2) works. > > (`-`2) should too. > > I'll settle for (+(-2)) for now, but it ain't that pretty. > > > ___ > 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
Re: [Haskell-cafe] Problems with Haskell
Hello Philippos
> I received a lot of furious and offensive private emails for suggesting the
> Clean programmer to stick with Clean.
I don't get why some people think it's OK to be disrespectful just
because they're on the internet...
Regarding the code, I find it hard to follow without some high level
comments explaining the flow. I haven't used mutable arrays yet so I
won't be any help there, but here are some minor things I noticed in
your do blocks:
Where you write code like:
> do
> ...
> a <- return exp1
> b <- return exp2
i think it's better to write
> do
> ...
> let a = exp1
> b = exp2
also "else do writeArray v i g" could be "else writeArray v i g" since
you don't need the implicit >> that "do" gives you
Could you highlight the line(s) of code that are different in the 2
versions of mutate?
-Keith
On Sun, Oct 18, 2009 at 11:07 PM, Philippos Apolinarius
wrote:
>
> Before anything else, I want to point out that I have no intention to
> confront your community, or denigrate Haskell. A few days ago I answered an
> email from a Clean programmer on something related to Clean. He was worried
> that Clean team could give up its good work, and Clean could disappear;
> therefore, he was thinking about switching to Haskell. Since I thought that
> my email could be of interest for the Clean community, I posted it in the --
> small-- Clean list :-(Clean is not as popular as Haskell). I received a lot
> of furious and offensive private emails for suggesting the Clean programmer
> to stick with Clean. However, I also received a very polite, humorous, and
> illuminating private email from a person who seems to work at Microsoft. His
> name is Simon Peyton-Jones. He
> urged me to post my comments on a Haskell cafe. He also filed one of my
> comments as a bug in a Haskell bug track. Here is a couple of snippets from
> his email:
>
> --- I think it's v bad that a straightforward program runs so slowly, and
> it's certainly true
> that this is an area we could pay more attention to.
>
> --- Meanwhile, I'm curious: are the arrays in Philippos's program strict? Or
> lazy? If strict,
> that's a pretty big difference.
>
> Therefore, here are my comments, with a lot of code.
>
> A few months ago I came accross an unpublished article about a novel genetic
> programming system. The system was coded in Larceny Scheme. I translated it
> to Clean and to Haskell. Unhappily, I cannot post the program here because it
> is very large, and the authors of the original Lisp program don't want me to
> divulge it before they see in in a printed page of a Journal. Therefore, I
> wrote an empty genetic programming framework, just to compare languages.
> Comparing Clean and Haskell, I noticed:
>
> 1 -- Clean compiler almost never let me do very stupid things, like trying to
> unbox a tree, or to write in a closed file (I will post an example of this in
> a near future). For instance, Clean compiler would never swallow something
> like the code below:
>
>
> import Control.Monad.ST
> import Data.Array.ST
> import Data.Array.Base
> import System.Random
>
> data Op = AND | OR | NOT;
> data Tree= L Double | T Op [Tree]
>
> main = print $ runST
> (do arr <- newArray (1,200) (L 0.0) :: ST s (STArray s Int
> Tree)
>
> go arr 200 0.0 )
>
> go :: STArray s Int Tree -> Int -> Double -> ST s Double
> go a i acc
> | i < 1 = return acc
> | otherwise=do
> b <- unsafeRead a i {- readArray a i -}
> writeArray a i (setDouble ((getDouble b)+3.0))
> c <- readArray a i
> go a (i-1) (acc+ (getDouble c))
>
> -- What I really need is a random index in Haskell.
>
> getDouble (L r)= r
> getDouble _ = 0.0
>
> setDouble r= L r
>
> 2 -- Safety does not cost much in Clean. For instance, removing array
> boundary check does not seem to affect Clean. I believe that it does not
> affect Haskell either, but I have not verified this point.
>
> 3 -- Haskell seems to loop more often than Clean. For instance, Haskell may
> loop if I change function mutate to
>
> mutate e (L i) xs = (e, xs)
> mutate e t (y:ys) = ins t (rnLen t y, ys) where
> ins (T p (L i:xs)) (0, st)=(T p (e:xs), st)
> ins (T p (t:xs)) (n,(r1:rs)) | n > 0=
> let (T p mt, s2)= ins (T p xs)(n-1, rs)
> in (T p (t:mt), s2)
> ins (T p (t:xs)) (n,(r1:rs))
> | rn 2 r1== 0= (T p (e:xs), rs)
> | rn 2 r1== 1= let (xpr, st)= mutate e t rs
> in (T p (xpr:xs), st)
>
> This might be a bug in my implementation of show Tree. It would be great if
> you people could "show" me what I did wrong.
>
> 4 -- On the plus side, there are libraries in Haskell that seem to behave
> better than the Clean equivalent libraries. This could be explained by the
> fact that there are a lot of people coding Haskell libraries, while Clean
> team seems to be reluctant in accepting libraries from outsiders. For
> instance, lethevert ma
Re: [Haskell-cafe] Re: [Haskell-beginners] map question
On Mon, Oct 19, 2009 at 5:53 PM, Will Ness wrote: > Tom Tobin korpios.com> writes: > > > On Mon, Oct 19, 2009 at 5:34 PM, Will Ness yahoo.com> > wrote: > > > This syntax already exists. The '`' symbol is non-collating already, so > > > using it for symbol chars doesn't change anything (it's not that it > > > can be a part of some name, right?). To turn an infix op into an infix > op > > > is an id operation, made illegal artificially at the scan phase after a > > > successful lex (or whatever). > > > > If I've accidentally applied syntax meant for a prefix operator to an > > infix operator, *I want the compiler to tell me*, and not to silently > > accept my mistake. > > You don't apply sytax, you write it. > > You think of functions, where domain matters (for purists?). In syntax only > the > result matter, does it read? Does it have an intended meaning? > > How is it a mistake if it expresses what I intended? > > Both 3 `-` 2 and curry fst `foldl` 0 are exactly the same - expressions > with > infix operator, read in the same way, interpreted in the same way. In the > first > case the backticks are made superfluous by Haskell reader for our > convinience; > but they shouldn't be made illegal. Why should they be? I truly don't > understand the resistance to this idea. :) > Don't you mean 3 `(-)` 2? I'm pretty sure -, without the parens is infix and (-) is prefix. So it seems to me that you need the brackets for this to be consistent. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell-beginners] map question
Will Ness wrote: wren ng thornton writes: Attack the underlying problem, don't introduce hacks to cover up broken hacks. This isn't C++. The underlying problem is a broken scanner where it can't distinguish between a binary op and a number read syntax. The underlying problem is that (1) people don't want "normal" whitespace to change the meaning of code, (2) they don't want to disallow negative literals, and (3) they want to use the same symbolic operator for negation and subtraction, but these three goals cannot all be satisfied simultaneously. The current resolution is to hack at the parser in order to make things mostly work. But this hack is insufficient, as argued by the OP. The proposed solution was to introduce new syntax complicating the language by explaining how 1-2 and 1`-`2 are the same thing (either repeated for all other symbolic operators, or exceptional to the subtraction operator, and ugly by either approach). But why should we introduce all this syntactic complexity which needs explaining to newbies and only makes the wart more visible? The proper solution is not to introduce syntactic hackery on top of the parser hackery, the proper solution is to either come up with a better parser hack or to sacrifice one of the three incompatible goals. Not a hack, a solution. A consistent one. Look: (`foldl` 0) (`-` 2) Don't they look exactly the same? Not to me they don't. Symbolic and lexical operators are treated differently in Haskell. Considering all the places where they're treated differently, I see no compelling reason to think they should be considered similar here. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell-beginners] map question
Tom Tobin korpios.com> writes: > On Mon, Oct 19, 2009 at 5:34 PM, Will Ness yahoo.com> wrote: > > This syntax already exists. The '`' symbol is non-collating already, so > > using it for symbol chars doesn't change anything (it's not that it > > can be a part of some name, right?). To turn an infix op into an infix op > > is an id operation, made illegal artificially at the scan phase after a > > successful lex (or whatever). > > If I've accidentally applied syntax meant for a prefix operator to an > infix operator, *I want the compiler to tell me*, and not to silently > accept my mistake. You don't apply sytax, you write it. You think of functions, where domain matters (for purists?). In syntax only the result matter, does it read? Does it have an intended meaning? How is it a mistake if it expresses what I intended? Both 3 `-` 2 and curry fst `foldl` 0 are exactly the same - expressions with infix operator, read in the same way, interpreted in the same way. In the first case the backticks are made superfluous by Haskell reader for our convinience; but they shouldn't be made illegal. Why should they be? I truly don't understand the resistance to this idea. :) > > Why wouldn't it be made legal? Show me one inconsistency it introduces. > > You've said that you want to be able to do this for the sole case of > the - (minus-sign) operator: This is not an inconsistence. Plus, if we were to take this idea of using backticks as names delimeters to the extreme, it could even allow us to use such identifiers as `left-fold` or `right-fold` in infix position, and (`left-fold`) by itself. Although that seems not such a good idea. > > Operators are great because they make our intent visible, immediately > > apparent. Long words' meaning, like subtract's, is not immediately apparent, > > and they break consistency. Not everyone's first language in life was > > English, you see. > > I don't buy this rationale. Haskell has plenty of English words as > function names all over the place; if you can't handle "subtract", how > are you handling Haskell at all? Sure, the minus-sign issue is a > wart, but it's less awkward than the solution you propose for a > problem I doubt you really have. When I see `++` I don't need to think _at_all_. When I see `concatenate` or some such, I do - even if for a briefest of moments. It is _less_ convinient both to read and _write_, don't you agree? I don't see my proposal as awkward at all. On the contrary, to me it looks natural and consistent with the other uses of this device in the language. It is this asymmetry that bothers me with the (-) issue, I just want the balance restored. But it is a matter of taste of course. Or obsessing over minutiae. :) Oh well. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell-beginners] map question
On Mon, Oct 19, 2009 at 5:34 PM, Will Ness wrote: > This syntax already exists. The '`' symbol is non-collating already, so using > it for symbol chars doesn't change anything (it's not that it can be a part of > some name, right?). To turn an infix op into an infix op is an id operation, > made illegal artificially at the scan phase after a successful lex (or > whatever). If I've accidentally applied syntax meant for a prefix operator to an infix operator, *I want the compiler to tell me*, and not to silently accept my mistake. > Not a hack, a solution. A consistent one. Look: > > (`foldl` 0) > (`-` 2) > > Don't they look exactly the same? No, because the latter is applying prefix-to-infix syntax to an infix operator. It's understood that non-alphanumerics are infix by default, and I want the compiler to scream at me if I try to use one where it expected a prefix op. > Why wouldn't it be made legal? Show me one inconsistency it introduces. You've said that you want to be able to do this for the sole case of the - (minus-sign) operator: > Operators are great because they make our intent visible, immediately > apparent. Long words' meaning, like subtract's, is not immediately apparent, > and they break consistency. Not everyone's first language in life was English, > you see. I don't buy this rationale. Haskell has plenty of English words as function names all over the place; if you can't handle "subtract", how are you handling Haskell at all? Sure, the minus-sign issue is a wart, but it's less awkward than the solution you propose for a problem I doubt you really have. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell-beginners] map question
wren ng thornton freegeek.org> writes: > > Will Ness wrote: > > > (`foldl`2) works. > > > > (`-`2) should too. > > The `` syntax is for converting lexical identifiers into infix > operators. Symbolic identifiers are already infix, which is why `` So it would be a no-op then. Why make it illegal? Just because it makes writing the scanner easier is no answer. > doesn't work for them. If we introduced this then those striving for > consistency would be right in requesting that this pattern be allowed > for all symbolic operators. I for one am opposed to introducing > superfluous syntax for duplicating the current ability to write things > in the same ways. This syntax already exists. The '`' symbol is non-collating already, so using it for symbol chars doesn't change anything (it's not that it can be a part of some name, right?). To turn an infix op into an infix op is an id operation, made illegal artificially at the scan phase after a successful lex (or whatever). Finally enabling the missing functionality which is a common stumbling block for every beginner is hardly "duplicating". > Attack the underlying problem, don't introduce hacks to cover up broken > hacks. This isn't C++. The underlying problem is a broken scanner where it can't distinguish between a binary op and a number read syntax. Op names are collated symbol chars, and one of the symbols, -, is also a valid number prefix. So, allow for a clues from programmer to detach it from the number: backticks separate it from the following numeric chars, preventing it from "sticking" to them. And by itself, it forms an op, a binary one. Not a hack, a solution. A consistent one. Look: (`foldl` 0) (`-` 2) Don't they look exactly the same? Why wouldn't it be made legal? Show me one inconsistency it introduces. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Documentation (was: ANN: text 0.5, a major revision of the Unicode text library)
On Mon, Oct 19, 2009 at 4:32 PM, Kyle Murphy wrote: > If they have to spend three hours trying to track down some obscure > research paper that's referenced in your documentation a half dozen times > in as many functions, you're not providing enough detail and assuming too > great a knowledge of the domain. Even just a paragraph or two giving some background information and example use cases would help immensely here; sometimes I just want to quickly assess whether a library might be useful for solving a particular problem, and "go read this paper" stops me cold. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Documentation (was: ANN: text 0.5, a major revision of the Unicode text library)
On a somewhat related note, I think the Haskell documentation in general is rather patchy and hard to follow for most things. Part of that I think is because of the confusion between the different forms of documentation. In general as a programmer I expect to find three kinds of documentation available, preferably in a centralized location, but at least in a handful of standardized locations. The first kind, is what Haskell has in abundance, and what is hosted in Hackage, which is API documentation. API documentation is written to be terse, to assume you already know how library Foo works (and probably library Bar and Baz too), and you just need to refresh yourself on exactly what the signature of function wibble was exactly. Really good API documentation also fills the role of some of the other kinds of documentation and has some quick examples sprinkled around the most commonly used functions and maybe a nice intro paragraph with even more examples and some suggestions for further information. The second kind of documentation which is very nearly non-existant for most Haskell packages is a user manual that documents in detail all the functions and data types of a package, how you use them, and the ideas and concepts they're based on. Given only this documentation, a firm understanding of the language, and a basic knowledge of the problem domain, anyone should be able to write an application using your library. If they have to spend three hours trying to track down some obscure research paper that's referenced in your documentation a half dozen times in as many functions, you're not providing enough detail and assuming too great a knowledge of the domain. The last kind of documentation which is fortunately somewhat more prevalent then the previous kind is the classic tutorial, which documents and thoroughly explains the most commonly used functions in your library (not to be confused with thoroughly explaining your library which is the job of the user manual). There are quite a few good tutorials on Haskell in general, Monads specifically, and a lot of random bits and pieces floating around on the net, and thankfully collected for reference on the Haskell wiki. On the whole, the Haskell API docs are decent (although most of them are not what I would call "Good"), and the tutorials are also rather plentiful, but the user manuals are practically non-existent. What would be ideal is if the hackage entry for each package also included a link to the user manual for that package if it exists (and hopefully most of them would exist) in addition to the links to the API docs and homepage it already has (I suppose in theory the homepage link can serve this purpose and in some cases it currently does, but an actual "manual" link would be nice). (All of the following were chosen at random) For reference, here is a good example of an API doc: http://hackage.haskell.org/package/zlib Average API docs (but with links to good user manual and tutorial): http://hackage.haskell.org/package/DeepArrow Bad API docs (but once again with a link to average manual/tutorial): http://hackage.haskell.org/package/actor -R. Kyle Murphy -- Curiosity was framed, Ignorance killed the cat. On Mon, Oct 12, 2009 at 16:29, John Lato wrote: > > From: Derek Elkins > > > > On Sun, Oct 11, 2009 at 8:55 AM, Iain Barnett > wrote: > >> > >> On 11 Oct 2009, at 13:58, John Lato wrote: > >> > >>> For anyone writing introductions to generic programming, take this as > >>> a plea from Haskellers everywhere. If one of the RWH authors can't > >>> understand how to make use of these techniques, what hope do the rest > >>> of us have? > >>> > >>> John Lato > >>> > >>> P.S. Some might wryly note that I'm the maintainer of a package which > >>> is also known for incomprehensible documentation. To which I would > >>> reply that our effort is much newer, I consider it a problem, and it's > >>> being worked on, contrasted to the state of GP where similarly > >>> impenetrable documentation has been and continues to be the norm. > >>> > >> > >> You could say that about most documentation (for Haskell and beyond). > >> Apparently, programmers like programming better than documenting. The > effect > >> of this is that less people use their programming, making their efforts > >> redundant. > >> > >> Silly really, considering programmers are (allegedly:) intelligent. > > > > Apparently, programmers like programming better than reading as > > well... in my experience. > > I won't disagree. But I think the real difficulty is that the > intersection of programmers who can come up with really good ways to > solve problems (not even all programmers, unfortunately) and people > who are good at writing documentation is vanishingly small. > > It seems to me that when someone works in a problem domain (e.g. > Generic Programming), they gain a very deep understanding of that area > and are used to working at a certain level within it. When > introducing the topic
[Haskell-cafe] ANNOUNCE: cereal-0.2
Hello Everyone, cereal is a variation on the binary package that provides strict parsing, handleable exceptions with a named call stack, and a new parsing isolation feature. The major differences from binary are a new class called Serialize replacing the Binary class, getting and putting using strict ByteStrings and a number of combinators for parsing lists, arrays and other containers. Version 0.2 is available from hackage: * http://hackage.haskell.org/package/cereal-0.2 --trevor signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage down
On Monday 19 October 2009 10:30:55 am Dougal Stanton wrote: > Has not been responding for at least the last 12 hours. > > Is there somewhere to look for status reports on sysadmin details like > this, so we can tell if > > - it's a scheduled down time > - it's a problem but the admins know about it > - etc etc. > > D > Yay, it seems to be working again. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] systemtimmetypeable: Workaround for lack of deriveable data instance in either System.Time or Data.Time.
At http://osdir.com/ml/haskell-cafe@haskell.org/2009-10/msg00197.html I griped that the lack of Data-Derivable time values was causing me headache in happstack. In the proposed cabal package http://patch-tag.com/r/tphyahoo/systemtimetypeable/snapshot/current/content/pretty/systemtimetypeable.cabal I submit a workaround that, while probably not the ideal thing, has proved helpful to me. Basically, I use the type MyTime, which is data-deriveable, when working with Macid in happstack; and convert from System.Time and/or Data.Time with the accompanying utility functions when necessary. Perhaps the utility functions are useful on their own as well. I found it surprisingly hard to get from Data.Time values to System.Time values. Anyways, I am interested in what others think and, of course, patches and suggestions welcome. thomas. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] debugtracehelpers Re: traceM and traceShowM
I have this and a couple other handy functions in DebugTraceHelpers: http://patch-tag.com/r/tphyahoo/DebugTraceHelpers/snapshot/current/content/pretty hackage: http://hackage.haskell.org/packages/archive/DebugTraceHelpers/0.12/doc/html/Debug-Trace-Helpers.html 2009/10/16 Martijn van Steenbergen : > Hello, > > I propose the addition of the following two functions to module Debug.Trace: > >> traceM :: Monad m => String -> m () >> traceM msg = trace msg (return ()) >> >> traceShowM :: (Show a, Monad m) => a -> m () >> traceShowM = traceM . show > > These functions allow tracing in any do-block. I often define them myself; I > think they are useful in general. > > Deadline: 23 October 2009. > > Martijn. > ___ > Libraries mailing list > librar...@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use "bracket" properly ?
On Sun, Oct 18, 2009 at 11:50 PM, zaxis wrote: > > The original code is: > > winSSQ count noRed noBlue = do > let yesRed = [1..33] \\ noRed > let yesBlue = [1..16] \\ noBlue > bracket (openFile "ssqNum.txt" WriteMode) (hClose) (\hd1 -> pickSSQ > count yesRed yesBlue hd1) > > It works very well. However, as i am used to C style so i want convert it > into In the long run it is probably easier to just get used to haskell style. Putting in fewer braces and semicolons will be the least of the adjustments to make from C. I've seen some brace-ful code out there (notably ghc) but it tends not to be in C style even so, e.g. with leading ;s instead of trailing ones. Even though haskell style is already all over the map, using layout and omitting the punctuation seems most widespread to me. Or maybe it's just my bias since I prefer that style myself. It might be interesting to have a few "standard" styles documented, not to try to enforce anything, but have a couple self-consistent systems up there with rationale for otherwise undecided people to look at. E.g. after seeing the leading comma style around I tried it out myself and eventually adopted it, even though it looked weird at first. But it was only after seeing code in that style and guessing for myself why it was that way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error handling package
On Mon, Oct 19, 2009 at 3:39 PM, Jose Iborra wrote: > You may want to take a look at anoother option in Hackage, the > control-monad-exception package. > > http://pepeiborra.github.com/control-monad-exception/ > > The control-monad-exception library provides the building blocks for > > * Explicitly Typed exceptions (checked or not) > * which are composable > * and even provide stack traces (experimental feature) Jose, Thank you very much, thinks looks like just the thing I was looking for. The only thing that slightly concerns me is the transformers dependency, but it's not a serious worry. I'd love to try out the package right now, but with hackage being down I can't get the dependencies yet ;). I'll try it out as soon as I can. > > > > On 19/10/2009, at 01:00, Michael Snoyman wrote: > > (Sorry, accidently took off cafe.) >> >> On Mon, Oct 19, 2009 at 12:44 AM, Henning Thielemann < >> lemm...@henning-thielemann.de> wrote: >> >> On Mon, 19 Oct 2009, Michael Snoyman wrote: >> >> Does the explicit-exception package provide what you need? >> >> http://hackage.haskell.org/package/explicit-exception >> >> >> I don't think so, but correct me if I'm wrong. I want to make it easy to >> chain together >> computations which could fail in different ways. For example, something >> like this: >> >> attemptReadInt :: String -> Attempt Int >> attemptLookup :: String -> [(String, String)] -> Attempt String >> attemptLookupInt :: String -> [(String, String)] -> Attempt Int >> attemptLookupInt k m = attemptLookup k m >>= attemptReadInt >> >> Now, in the explicit-exception package, I could- in this simple example- >> define >> something like: >> >> data MyErrors = KeyNotFound | InvalidInt >> >> >> type Attempt = Exceptional MyErrors >> >> True; that's what I meant by I could do this in my simple example. >> >> >> But this solution would not scale. >> >> You want to add other exceptions? The idea of my package is to make >> exceptions explicit in the type. Otherwise you would use >> extensible-exceptions. Or you could define MyErrors using an existential >> type. >> >> Which is my point. I'm trying to provide a package for non-explicit >> exceptions. To compare to other programming languages, I think your package >> is providing the equivalent of Java checked exceptions, while mine is >> providing (safe) unchecked exceptions. I say safe because you still need to >> explicitly decide to turn an Attempt into a possible runtime exception which >> will bring down your program. >> >> Defining MyErrors using an existential type would essentially recreate the >> entire attempt package; I don't see that purpose in everyone wanted >> unchecked exceptions needing to reinvent the wheel in non-compatible ways. >> If multiple libraries use attempt, they can easily have their >> possible-error-returning functions chain together safely. >> >> > I believe that control-monad-exception solves this tension between > composability and explicit exceptions. > You can have explicit exceptions which are composable: > > > data DivideByZero = DivideByZero deriving (Show, Typeable) > > data SumOverflow = SumOverflow deriving (Show, Typeable) > > > instance Exception DivideByZero > > instance Exception SumOverflow > > > data Expr = Add Expr Expr | Div Expr Expr | Val Double > > > eval (Val x) = return x > > eval (Add a1 a2) = do > >v1 <- eval a1 > >v2 <- eval a2 > >let sum = v1 + v2 > >if sum < v1 || sum < v2 then throw SumOverflow else return sum > > eval (Div a1 a2) = do > >v1 <- eval a1 > >v2 <- eval a2 > >if v2 == 0 then throw DivideByZero else return (v1 / v2) > > GHCi infers the following types > > > :t eval > > eval :: (Throws DivideByZero l, Throws SumOverflow l) => Expr -> EM l > Double > > > :t eval `catch` \ (e::DivideByZero) -> return (-1) > > :: Throws SumOverflow l => Expr -> EM l Double > > > :t runEM(eval `catch` \ (e::SomeException) -> return (-1)) > > : Expr -> Double > > >> Additionally, there's two immediate features I think I would miss from my >> package: >> >> 1) fail works properly, so an Attempt would be a valid monad response from >> people who >> use that function. >> >> As far as I understand, 'fail' is used/abused for reporting failed pattern >> matches in do notation. If a failed pattern match indicates a programming >> error, it should be a really error, and not something that must be handled >> at run-time. >> >> That's a lot of very debateable statements you just made. It might be that >> it's strongly encouraged to only use fail for failed pattern matching, but >> in practice you could use it for any monadic failure. Also, there's nothing >> stopping a user from re-throwing pattern match exceptions received in an >> Attempt. >> > > I am with Henning on 'fail'. > It must not be used as a replacement for throw, only for failed pattern > matches which are programming errors and thus unchecked exceptions. > I'm not arguing how it *should* be u
Re: [Haskell-cafe] Hackage down
sfvisser:
> On Oct 19, 2009, at 12:18 PM, Ross Paterson wrote:
>> On Mon, Oct 19, 2009 at 09:30:55AM +0100, Dougal Stanton wrote:
>>> Has not been responding for at least the last 12 hours.
>>>
>>> Is there somewhere to look for status reports on sysadmin details
>>> like
>>> this, so we can tell if
>>>
>>> - it's a scheduled down time
>>> - it's a problem but the admins know about it
>>> - etc etc.
>>
>> {hackage,darcs,cvs}.haskell.org has been up continuously for 6 days
>> and
>> is still working via ssh, but Apache isn't responding.
>
>
> Anyone any clue how to get the thing running again? We're trying to
> install a new Haskell-development machine here which is near impossible
> without the wonderful Hackage.
We're working on getting monk back in service. More news to follow
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] \Statically checked binomail heaps?
Hi Maciej, insTree t [] = [t] insTree t ts@(t':ts') | rank t < rank t' = t : ts | otherwise = insTree (link t t') ts' In a way, it's unsurprising that this is where your code breaks. What you're doing here is using a boolean guard to determine where to insert. The problem is that ghc's type checker doesn't learn anything from these boolean guards. In contrast to pattern matching on a GADT, you can always exchange the two branches of an if-than-else without breaking type correctness. To get the code to work the type checker needs learn something about the ranks of t and t' after comparing them. Have anyone an idea how make this code working? Use a different language. In particular, you might want to have a look at Agda - a programming language and proof assistand based on dependent types that has a very similar look-and-feel to Haskell. If you're interested, you may want to have a look at similar developments by some of our students at Chalmers: http://web.student.chalmers.se/groups/datx02-dtp/ They've given verified implementations in Agda of some fairly advanced data structures. Hope this helps, Wouter PS - There may be a way around this by writing even more type-level programs in Haskell, basically reflecting (<) on the type-level and doing some really hard work to relate the type level numbers to the value level numbers. Brace yourself for a world of pain. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage down
On Mon, Oct 19, 2009 at 3:30 AM, Dougal Stanton wrote: > Has not been responding for at least the last 12 hours. > > Is there somewhere to look for status reports on sysadmin details like > this, so we can tell if Or even better, might it be possible to look into setting up a fallback mirror of Hackage? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error handling package
You may want to take a look at another option in Hackage, the control- monad-exception package. http://pepeiborra.github.com/control-monad-exception/ The control-monad-exception library provides the building blocks for * Explicitly Typed exceptions (checked or not) * which are composable * and even provide stack traces (experimental feature) On 19/10/2009, at 01:00, Michael Snoyman wrote: (Sorry, accidently took off cafe.) On Mon, Oct 19, 2009 at 12:44 AM, Henning Thielemann > wrote: On Mon, 19 Oct 2009, Michael Snoyman wrote: Does the explicit-exception package provide what you need? http://hackage.haskell.org/package/explicit-exception I don't think so, but correct me if I'm wrong. I want to make it easy to chain together computations which could fail in different ways. For example, something like this: attemptReadInt :: String -> Attempt Int attemptLookup :: String -> [(String, String)] -> Attempt String attemptLookupInt :: String -> [(String, String)] -> Attempt Int attemptLookupInt k m = attemptLookup k m >>= attemptReadInt Now, in the explicit-exception package, I could- in this simple example- define something like: data MyErrors = KeyNotFound | InvalidInt type Attempt = Exceptional MyErrors True; that's what I meant by I could do this in my simple example. But this solution would not scale. You want to add other exceptions? The idea of my package is to make exceptions explicit in the type. Otherwise you would use extensible- exceptions. Or you could define MyErrors using an existential type. Which is my point. I'm trying to provide a package for non-explicit exceptions. To compare to other programming languages, I think your package is providing the equivalent of Java checked exceptions, while mine is providing (safe) unchecked exceptions. I say safe because you still need to explicitly decide to turn an Attempt into a possible runtime exception which will bring down your program. Defining MyErrors using an existential type would essentially recreate the entire attempt package; I don't see that purpose in everyone wanted unchecked exceptions needing to reinvent the wheel in non-compatible ways. If multiple libraries use attempt, they can easily have their possible-error-returning functions chain together safely. I believe that control-monad-exception solves this tension between composability and explicit exceptions. You can have explicit exceptions which are composable: > data DivideByZero = DivideByZero deriving (Show, Typeable) > data SumOverflow = SumOverflow deriving (Show, Typeable) > instance Exception DivideByZero > instance Exception SumOverflow > data Expr = Add Expr Expr | Div Expr Expr | Val Double > eval (Val x) = return x > eval (Add a1 a2) = do >v1 <- eval a1 >v2 <- eval a2 >let sum = v1 + v2 >if sum < v1 || sum < v2 then throw SumOverflow else return sum > eval (Div a1 a2) = do >v1 <- eval a1 >v2 <- eval a2 >if v2 == 0 then throw DivideByZero else return (v1 / v2) GHCi infers the following types > :t eval > eval :: (Throws DivideByZero l, Throws SumOverflow l) => Expr -> EM l Double > :t eval `catch` \ (e::DivideByZero) -> return (-1) > :: Throws SumOverflow l => Expr -> EM l Double > :t runEM(eval `catch` \ (e::SomeException) -> return (-1)) > : Expr -> Double Additionally, there's two immediate features I think I would miss from my package: 1) fail works properly, so an Attempt would be a valid monad response from people who use that function. As far as I understand, 'fail' is used/abused for reporting failed pattern matches in do notation. If a failed pattern match indicates a programming error, it should be a really error, and not something that must be handled at run-time. That's a lot of very debateable statements you just made. It might be that it's strongly encouraged to only use fail for failed pattern matching, but in practice you could use it for any monadic failure. Also, there's nothing stopping a user from re-throwing pattern match exceptions received in an Attempt. I am with Henning on 'fail'. It must not be used as a replacement for throw, only for failed pattern matches which are programming errors and thus unchecked exceptions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage down
On Oct 19, 2009, at 12:18 PM, Ross Paterson wrote:
On Mon, Oct 19, 2009 at 09:30:55AM +0100, Dougal Stanton wrote:
Has not been responding for at least the last 12 hours.
Is there somewhere to look for status reports on sysadmin details
like
this, so we can tell if
- it's a scheduled down time
- it's a problem but the admins know about it
- etc etc.
{hackage,darcs,cvs}.haskell.org has been up continuously for 6 days
and
is still working via ssh, but Apache isn't responding.
Anyone any clue how to get the thing running again? We're trying to
install a new Haskell-development machine here which is near
impossible without the wonderful Hackage.
Thanks,
--
Sebastiaan Visser
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use "bracket" properly ?
On Mon, Oct 19, 2009 at 6:10 AM, Roel van Dijk wrote:
> On Mon, Oct 19, 2009 at 1:44 PM, zaxis wrote:
>> oh! thanks! But why ?
>
> A let can introduce multiple declarations.
>
> So this
>
> foo = do
> let x = 3
> let y = 4
> return $ x+ y
>
> can also be written like
>
> foo = do
> let x = 3
> y = 4 -- no let
> return $ x + y
To be clear, the reason this breaks is because this is a valid let syntax:
let x = 1 ; y = 2 in x + y
See the semicolon? So when you put a let in a block, and it sees the
semicolon at the end of the line, it is expecting another let binding.
If there's a newline, then the layout rule applies and the next line
is considered the start of a new layout block, even though it's at the
same level.
So, basically, everything gets borked up.
> With explicit blocks:
>
> foo = do {
> let {x = 3; y = 4;};
> return $ x + y;
> }
> ___
> 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
Re: [Haskell-cafe] Documentation (was: ANN: text 0.5, a major revision of the Unicode text library)
Hi, While I agree that the documentation of Data.Generics is not perfect, I do not think it is possible to have the haddock documentation be self-contained. For a thorough understanding of syb, a user has to read the two initial papers, which are linked from the haddock documentation. I also do not think it's reasonable to explain all the details beyond monads in the Control.Monad haddock, for instance. For the problem at hand (a Data instance for Text), I can only say that generic programming and abstract datatypes do not mix too well (although there is work on the area, see [1]). Generics work by exploiting the structure of types, and if that structure is explicitly kept hidden then (rather ad hoc) workarounds have to be used. See, for example, the Data instance for Array: -- The Data instance for Array preserves data abstraction at the cost of > -- inefficiency. We omit reflection services for the sake of data > abstraction. > instance (Typeable a, Data b, Ix a) => Data (Array a b) > where > gfoldl f z a = z (listArray (bounds a)) `f` (elems a) > toConstr _ = error "toConstr" > gunfold _ _ = error "gunfold" > dataTypeOf _ = mkNorepType "Data.Array.Array" > Cheers, Pedro [1] http://www.comlab.ox.ac.uk/publications/publication1385-abstract.html On Sun, Oct 11, 2009 at 14:58, John Lato wrote: > For anyone writing introductions to generic programming, take this as > a plea from Haskellers everywhere. If one of the RWH authors can't > understand how to make use of these techniques, what hope do the rest > of us have? > > John Lato > > P.S. Some might wryly note that I'm the maintainer of a package which > is also known for incomprehensible documentation. To which I would > reply that our effort is much newer, I consider it a problem, and it's > being worked on, contrasted to the state of GP where similarly > impenetrable documentation has been and continues to be the norm. > > > > > From: "Bryan O'Sullivan" > > > > I think maybe someone else will have to take a crack at a Data instance > for > > Text, because the documentation for Data.Data is not written in English. > In > > its syntax and structure, it closely hews to what we think of as English, > > but it is the kind of documentation that can only be understood by > someone > > who already knows what it is going to say. > > > > This is an exemplar of my experience with the cottage industry of generic > > programming in Haskell: I'd really quite like to use the stuff, but for > > goodness's sake, o beloved researchers, please aim your expository papers > at > > non-specialists once in a while. An endless chain of papers of the form > "my > > technique, which you won't understand, is better than this other > technique, > > which you haven't read about and won't anyway understand, in subtle ways > > that you won't understand" does not feel to me like progress. > > > > Yours in some misery and frustration, > > Bryan. > ___ > 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
Re: [Haskell-cafe] How to use "bracket" properly ?
On Mon, Oct 19, 2009 at 1:44 PM, zaxis wrote:
> oh! thanks! But why ?
A let can introduce multiple declarations.
So this
foo = do
let x = 3
let y = 4
return $ x+ y
can also be written like
foo = do
let x = 3
y = 4 -- no let
return $ x + y
With explicit blocks:
foo = do {
let {x = 3; y = 4;};
return $ x + y;
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use "bracket" properly ?
oh! thanks! But why ?
Heinrich Apfelmus wrote:
>
> zaxis wrote:
>> It works very well. However, as i am used to C style so i want convert it
>> into
>>
>> winSSQ count noRed noBlue = do {
>> let yesRed = [1..33] \\ noRed;
>> let yesBlue = [1..16] \\ noBlue;
>> bracket (openFile "ssqNum.txt" WriteMode) (hClose) (\hd1 -> pickSSQ
>> count yesRed yesBlue hd1);
>> }
>
> You need to put brackets around the declarations in a let as well:
>
> winSSQ count noRed noBlue = do {
> let { yesRed = [1..33] \\ noRed };
> let { yesBlue = [1..16] \\ noBlue };
> bracket (openFile "ssqNum.txt" WriteMode) (hClose)
> (\hd1 -> pickSSQ count yesRed yesBlue hd1);
> }
>
>
> Regards,
> apfelmus
>
> --
> http://apfelmus.nfshost.com
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
--
View this message in context:
http://www.nabble.com/How-to-use-%22bracket%22-properly---tp25953522p25956932.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage down
On Mon, Oct 19, 2009 at 09:30:55AM +0100, Dougal Stanton wrote:
> Has not been responding for at least the last 12 hours.
>
> Is there somewhere to look for status reports on sysadmin details like
> this, so we can tell if
>
> - it's a scheduled down time
> - it's a problem but the admins know about it
> - etc etc.
{hackage,darcs,cvs}.haskell.org has been up continuously for 6 days and
is still working via ssh, but Apache isn't responding.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage down
2009/10/19 Dougal Stanton : > Has not been responding for at least the last 12 hours. > > Is there somewhere to look for status reports on sysadmin details like > this, so we can tell if > > - it's a scheduled down time > - it's a problem but the admins know about it > - etc etc. > > D > The explanations I heard were: * "The Galois guys got their math wrong and folded monk's disk into R^0 space." * "Might be concerned with CERN." * "lambdabot hacked Hackage and uses it to plot her plans for world-domination, faster." All from the same person, incidentally! -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage down
Has not been responding for at least the last 12 hours. Is there somewhere to look for status reports on sysadmin details like this, so we can tell if - it's a scheduled down time - it's a problem but the admins know about it - etc etc. D -- Dougal Stanton dou...@dougalstanton.net // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use "bracket" properly ?
Ketil Malde writes: > Didn't you just ... Oh, dear. Sorry about that. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use "bracket" properly ?
Ketil Malde wrote:
winSSQ count noRed noBlue = do {
let yesRed = [1..33] \\ noRed;
^^^ ^
Didn't you just comment out your semicolons?
That was my initial reaction. Until I remembered that Haskell has a
different comment style.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use "bracket" properly ?
On Mon, Oct 19, 2009 at 9:18 AM, Ketil Malde wrote:
> zaxis writes:
>
>> winSSQ count noRed noBlue = do
>> let yesRed = [1..33] \\ noRed
>> let yesBlue = [1..16] \\ noBlue
>> bracket (openFile "ssqNum.txt" WriteMode) (hClose) (\hd1 -> pickSSQ
>> count yesRed yesBlue hd1)
>
>> It works very well. However, as i am used to C style so i want convert it
>> into
>
>> winSSQ count noRed noBlue = do {
>> let yesRed = [1..33] \\ noRed;
>
> ^^^ ^
> Didn't you just comment out your semicolons?
Hi Ketil,
That's the first thing I thought when I read this code, then I
realised those aren't comment delimiters in Haskell! :-)
D
--
Dougal Stanton
dou...@dougalstanton.net // http://www.dougalstanton.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use "bracket" properly ?
zaxis writes:
> winSSQ count noRed noBlue = do
> let yesRed = [1..33] \\ noRed
> let yesBlue = [1..16] \\ noBlue
> bracket (openFile "ssqNum.txt" WriteMode) (hClose) (\hd1 -> pickSSQ
> count yesRed yesBlue hd1)
> It works very well. However, as i am used to C style so i want convert it
> into
> winSSQ count noRed noBlue = do {
> let yesRed = [1..33] \\ noRed;
^^^ ^
Didn't you just comment out your semicolons?
> let yesBlue = [1..16] \\ noBlue;
> bracket (openFile "ssqNum.txt" WriteMode) (hClose) (\hd1 -> pickSSQ
> count yesRed yesBlue hd1);
> }
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: How to use "bracket" properly ?
zaxis wrote:
> It works very well. However, as i am used to C style so i want convert it
> into
>
> winSSQ count noRed noBlue = do {
> let yesRed = [1..33] \\ noRed;
> let yesBlue = [1..16] \\ noBlue;
> bracket (openFile "ssqNum.txt" WriteMode) (hClose) (\hd1 -> pickSSQ
> count yesRed yesBlue hd1);
> }
You need to put brackets around the declarations in a let as well:
winSSQ count noRed noBlue = do {
let { yesRed = [1..33] \\ noRed };
let { yesBlue = [1..16] \\ noBlue };
bracket (openFile "ssqNum.txt" WriteMode) (hClose)
(\hd1 -> pickSSQ count yesRed yesBlue hd1);
}
Regards,
apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
