There's a pattern that arises fairly often: catching every exception thrown
by code. The naive approach is to do something like:
result - try someCode
case result of
Left (e :: SomeException) - putStrLn $ It failed: ++ show e
Right realValue - useRealValue
This seems
Thanks guys,
lots of interesting material I wasn't aware of!
A.
On 22 June 2013 14:42, Mihai Maruseac mihai.marus...@gmail.com wrote:
On Wed, Jun 19, 2013 at 3:03 AM, Carlo Hamalainen
ca...@carlo-hamalainen.net wrote:
On 18/06/13 04:23, Mihai Maruseac wrote:
I was wondering if we have
To make the transition easier I have an experimental library which
defines a ByteString as a type synonym of a Storable.Vector of Word8
and provides the same interface as the bytestring package:
https://github.com/basvandijk/vector-bytestring
That's interesting Bas. What bothers me about
On 10 July 2013 08:57, Alfredo Di Napoli alfredo.dinap...@gmail.com wrote:
To make the transition easier I have an experimental library which
defines a ByteString as a type synonym of a Storable.Vector of Word8
and provides the same interface as the bytestring package:
Andreas wrote:
The greater evil is that Haskell does not have a non-recursive let.
This is source of many non-termination bugs, including this one here.
let should be non-recursive by default, and for recursion we could have
the good old let rec.
Hear, hear! In OCaml, I can (and often do)
Hi Oleg,
just now I wrote a message to haskell-pr...@haskell.org to propose a
non-recursive let. Unfortunately, the default let is recursive, so we
only have names like let' for it. I also mentioned the ugly workaround
(- return $) that I was shocked to see the first time, but use myself
In my opinion, when you are rebinding a variable with the same name,
there is usually another way to structure your code which eliminates
the variable.
If you would like to write:
let x = foo input in
let x = bar x in
let x = baz x in
instead, write
baz . bar . foo $ input
If
o...@okmij.org wrote:
Hear, hear! In OCaml, I can (and often do) write
let (x,s) = foo 1 [] in
let (y,s) = bar x s in
let (z,s) = baz x y s in ...
In Haskell I'll have to uniquely number the s's:
let (x,s1) = foo 1 [] in
let (y,s2) = bar x s1 in
Michael Snoyman mich...@snoyman.com wrote:
shouldBeCaught :: SomeException - Bool
One first stab at such a function would be to return `False` for
AsyncException and Timeout, and `True` for everything else, but I'm
not convinced that this is sufficient. Are there any thoughts on the
I think 'shouldBeCaught' is more often than not the wrong thing. A
whitelist of exceptions you're prepared to handle makes much more sense
than excluding certain operations. Some common whitelists, e.g. filesystem
exceptions or network exceptions, might be useful to have.
I like Ertugrul's
Hi Michael,
We do this as well. In addition to AsyncException, we ignore
BlockedIndefinitelyOnSTM, BlockedIndefinitelyOnMVar and Deadlock. I'm
not sure you can ignore Timeout, since the type is not exported from
System.Timeout. I'm not sure how to classify these, though. They are
in some sense
On 10.07.2013 10:16, Ertugrul Söylemez wrote:
o...@okmij.org wrote:
Hear, hear! In OCaml, I can (and often do) write
let (x,s) = foo 1 [] in
let (y,s) = bar x s in
let (z,s) = baz x y s in ...
In Haskell I'll have to uniquely number the s's:
let (x,s1) =
Jon Fairbairn wrote:
It just changes forgetting to use different variable names because of
recursion (which is currently uniform throughout the language) to
forgetting to use non recursive let instead of let.
Let me bring to the record the message I just wrote on Haskell-cafe
I think that a non-non recursive let could be not compatible with the pure
nature of Haskell.
Let is recursive because, unlike in the case of other
languages, variables are not locations for storing values, but the
expressions on the right side of the equality themselves. And obviously it
is not
On Wed, Jul 10, 2013 at 10:39 AM, John Lato jwl...@gmail.com wrote:
I think 'shouldBeCaught' is more often than not the wrong thing. A
whitelist of exceptions you're prepared to handle makes much more sense than
excluding certain operations. Some common whitelists, e.g. filesystem
exceptions
If you would like to write
let (x,s) = foo 1 [] in
let (y,s) = bar x s in
let (z,s) = baz x y s in
instead, use a state monad.
Incidentally I did write almost exactly this code once. Ironically, it
was meant as a lead-on to the State monad.
But there have been other cases
Hello Bas,
sorry for being unclear. What you say is correct, I was referring (and I
realised this after posting :D ) that the real
annoying thing is fragmentation in memory. Due to the fact the GC can't
move those objects, if we have long running
processes our memory will become more and more
Don´t tried it and probably it does not even compile, but a possibility
could be along these lines:
catchExcept excepts handle e= do
if not . null $ filter ( \(SomeException e') - typeOf e= typeOf e')
excepts
then throw e
else handle e
use:
u= undefined
excluded=
o...@okmij.org wrote:
If you would like to write
let (x,s) = foo 1 [] in
let (y,s) = bar x s in
let (z,s) = baz x y s in
instead, use a state monad.
Incidentally I did write almost exactly this code once. Ironically, it
was meant as a lead-on to the State monad.
But
On Wed, Jul 10, 2013 at 5:02 PM, Erik Hesselink hessel...@gmail.com wrote:
On Wed, Jul 10, 2013 at 10:39 AM, John Lato jwl...@gmail.com wrote:
I think 'shouldBeCaught' is more often than not the wrong thing. A
whitelist of exceptions you're prepared to handle makes much more sense
than
Yes, it does. Without optimizations the result is
ndgorsfesnywaiqraloa, while with optimizations the result is always
aabb.
On Wed, 10 Jul 2013 02:21:10 +0400 Aleksey Khudyakov
alexey.sklad...@gmail.com wrote:
On 10.07.2013 01:38, kudah wrote:
I've attached the script that I
On Wed, Jul 10, 2013 at 1:01 PM, John Lato jwl...@gmail.com wrote:
On Wed, Jul 10, 2013 at 5:02 PM, Erik Hesselink hessel...@gmail.comwrote:
On Wed, Jul 10, 2013 at 10:39 AM, John Lato jwl...@gmail.com wrote:
I think 'shouldBeCaught' is more often than not the wrong thing. A
whitelist of
I think that new SomeAsyncException type in base is supposed to make
it possible to ignore all asynchronous exceptions.
https://github.com/ghc/packages-base/blob/master/GHC/IO/Exception.hs#L113
On Wed, 10 Jul 2013 09:28:12 +0300 Michael Snoyman
mich...@snoyman.com wrote:
There's a pattern that
Looks like the graph is represented by an adjacency matrix, where the
element at (a, b) tells you whether there is an edge from node a to node
b with weight x or not by having the value (Just x) or Nothing,
respectively.
Whether the matrix is sparse depends on the data, i.e. how many edges
are
Michael Snoyman mich...@snoyman.com wrote:
Any thoughts on this? I'm not sure exactly what would be the right
method to add to the Exception typeclass, but if we can come to
consensus on that and there are no major objections to my separate
package proposal, I think this would be something
Vector Fabrics has another position open for a functional programmer. See below
and http://www.vectorfabrics.com/company/career/functional_programmer for
details.
This time, we particularly welcome applications from experienced developers,
the position providing a fair share of opportunities
Oh how nice!
I have been looking at MFlow a lot lately and I think it's got something
quite special that Yesod, Happstack, etc don't seem to have, at least, not
as far as I know. I mean, look at this:
sumWidget= pageFlow sum $ do
n1 - p Enter first number ++ getInt Nothing **
First, I want to say you'd have a lot better luck with these questions
by posting to stackoverflow. This really isn't the right place for
it.
As for why your parser is not working, you need to realize that parsec
does not backtrack by default. It does this to conserve memory (so it
doesn't have
Thanks Adrian. The racket people where pioneers in this idea I think.
There is another web framework in Ocaml, Osigen that it is also
continuation based. MFlow is not continuation-based but it also define the
navigation as a sequence. But only Seaside (and now MFlow) supports many
flows in the
I'm a little lost in the bewildering array of music packages for Haskell,
and need some help.
I'm looking to recreate one of my algorithmic music compositions from the
1980s. I can easily code the logic in Haskell.
I'm looking for a the right set of packages and SW so that I can:
a) generate
The standard array types, such as Array (n,n) (Maybe w) will be implemented as
a dense array. If you want to use a sparse matrix, you will explicitly have to
ask for it. For instance by using something like IntMap (IntMap w) or Map
(n,n) w or Array n (IntMap w). Each of these representations is
quoth Alberto G. Corona,
Let is recursive because, unlike in the case of other
languages, variables are not locations for storing values, but the
expressions on the right side of the equality themselves. And obviously it
is not possible for a variable-expression to be two expressions at the
Thank you :)
On Wed, Jul 10, 2013 at 8:33 AM, Twan van Laarhoven twa...@gmail.comwrote:
The standard array types, such as Array (n,n) (Maybe w) will be
implemented as a dense array. If you want to use a sparse matrix, you will
explicitly have to ask for it. For instance by using something
For midi you can try my packages: temporal-music-notation and
temporal-music-notation-demo (and maybe temporal-music-notation-western).
It looks like Haskore but different inside. It tries to be clear, minimal,
more efficient and documented (as far as my english goes though).
Anton
2013/7/10
I support Oleg's proposal. A shadowing, non-recursive let would be a
useful tool.
As starter suggestions for the keyword or syntax, I submit:
let new x = expr in body -- Not the old x!
let shadowing x = expr in body
shadow x = expr in body
let x =! expr in body -- The explosive
Donn Cave d...@avvanta.com wrote:
Let is recursive because, unlike in the case of other languages,
variables are not locations for storing values, but the expressions
on the right side of the equality themselves. And obviously it is
not possible for a variable-expression to be two
Ezra e. k. Cooper e...@ezrakilty.net wrote:
As starter suggestions for the keyword or syntax, I submit:
let new x = expr in body -- Not the old x!
It's not the old x in either case (recursive and non-recursive).
let shadowing x = expr in body
shadow x = expr in body
It's
Here are some common-lisp web frameworks using continuations:
http://common-lisp.net/project/cl-weblocks/
http://common-lisp.net/project/ucw/features.html
What always worried me with these frameworks is how they could be made
robust in case of failures. Storing all state in a database backend
Maybe Euterpea?
http://haskell.cs.yale.edu/euterpea/download/
On Wed, Jul 10, 2013 at 08:20:08AM -0700, Mark Lentczner wrote:
I'm a little lost in the bewildering array of music packages for Haskell,
and need some help.
I'm looking to recreate one of my algorithmic music compositions from
theres a very simple way to do non recursive let already! do notation in
the identity monad. I use it quite a lot lately.
On Wed, Jul 10, 2013 at 1:49 PM, Ertugrul Söylemez e...@ertes.de wrote:
Ezra e. k. Cooper e...@ezrakilty.net wrote:
As starter suggestions for the keyword or syntax, I
My plan is to synchronize MFlow servers using cloud Haskell since the state
serialization is small. I´m working on it. However continuation based
frameworks can not synchronize state. There is swarm in scala that
generate portable continuations but this is not used in the context of web
Hello,
I'm trying to get a grasp of netwire by implementing a bouncing ball
simulation and I'm failing.
The ball starts from the ground with a given velocity and when hitting
the ground the wire inhibits successfully. Now I'm kinda stuck.
How can I make the ball bounce?
Here is the code:
On Wed, Jul 10, 2013 at 2:15 PM, Just hask...@justnothing.org wrote:
Hello,
I'm trying to get a grasp of netwire by implementing a bouncing ball
simulation and I'm failing.
The ball starts from the ground with a given velocity and when hitting the
ground the wire inhibits successfully. Now
Just hask...@justnothing.org wrote:
I'm trying to get a grasp of netwire by implementing a bouncing ball
simulation and I'm failing.
The ball starts from the ground with a given velocity and when hitting
the ground the wire inhibits successfully. Now I'm kinda stuck.
How can I make the ball
Totality checking will generate a lot of false positives.
One would like an analysis that prints an error message if an expression
is *definitely* looping in all cases. While I have studied termination,
I have not studied non-termination analyses. It is harder than
termination. For
On 10.07.13 9:31 PM, Carter Schonwald wrote:
theres a very simple way to do non recursive let already! do notation in
the identity monad. I use it quite a lot lately.
Yeah, the hack
x - return $ e
instead of
let x = e
has been discussed already.
If you put everything into the Identity
On 10.07.13 6:00 PM, Donn Cave wrote:
quoth Alberto G. Corona,
Let is recursive because, unlike in the case of other
languages, variables are not locations for storing values, but the
expressions on the right side of the equality themselves. And obviously it
is not possible for a
On 10.07.13 11:42 AM, Ertugrul Söylemez wrote:
I think we are all aware that shadowing is
a bad idea, no matter whether you do it through Identity or
non-recursive let.
WHAT??
[This is Richard Bird's WHAT?? when someone said that using folds is
like programming in assembly language.]
quoth Andreas Abel andreas.a...@ifi.lmu.de,
...
I would doubt that nhc98 would interpret let xs = 0 : xs differently
than ghc if it implemented anything close to the Haskell 98 standard.
What I (so vaguely) remember was a compile error, for some reuse of
an identifier where GHC permitted
Hi Michael,
I don't think those are particularly niche cases, but I still think this is
a bad approach to solving the problem. My reply to Erik explicitly covers
the worker thread case, and for running arbitrary user code (as in your top
line) it's even simpler: just fork a new thread for the
On 10/07/2013, at 8:42 PM, Andreas Abel wrote:
Hear, hear! In OCaml, I can (and often do) write
let (x,s) = foo 1 [] in
let (y,s) = bar x s in
let (z,s) = baz x y s in ...
I really wish you wouldn't do that.
After reading Dijkstra's paper on the fact that we have
On 11/07/2013, at 4:00 AM, Donn Cave wrote:
I've gone to some trouble to dig up an nhc98 install (but can't seem to
find one among my computers and GHC 7 won't build the source thanks to
library re-orgs etc.) Because, I vaguely recall that nhc98's rules
were different here? Anyone in a
On 11/07/2013, at 11:09 AM, Donn Cave wrote:
let x = t + 1 in
let y = x in
let x = y + 1 in x
Still no cigar.
nhc98 v1.16
Program:
main = print $ (let t = 0 in let x = t + 1 in let y = x in let x = y + 1 in x)
Output:
2
___
Alberto G. Corona wrote:
I think that a non-non recursive let could be not compatible with the pure
nature of Haskell.
I have seen this sentiment before. It is quite a mis-understanding. In
fact, the opposite is true. One may say that Haskell is not quite pure
_because_ it has recursive let.
54 matches
Mail list logo
