> okmij.org> writes:
> ...
> In Haskell I'll have to uniquely number the s's:
>
> let (x,s1) = foo 1 [] in
> let (y,s2) = bar x s1 in
> let (z,s3) = baz x y s2 in ...
>
> and re-number them if I insert a new statement.
>
> I once wrote about 50-100 lines of code with
I'd like to emphasize that there is a precedent to non-recursive let
in the world of (relatively pure) lazy functional programming.
The programming language Clean has such non-recursive let and uses
it and the shadowing extensively. They consider shadowing a virtue,
for uniquely typed data.
Richa
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.
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
___
Ha
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 p
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 f
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 use
quoth Andreas Abel ,
...
> 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 it. I suppose you're ri
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.]
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 variable-exp
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
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 terminat
Just 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 bounce?
A very s
On Wed, Jul 10, 2013 at 2:15 PM, Just 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 I'm kinda stuck.
I
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:
{
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
applica
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 wrote:
> "Ezra e. k. Cooper" wrote:
>
> > As starter suggestions for the keyword or syntax, I submit:
> >
> > let new x
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 fro
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 of
"Ezra e. k. Cooper" 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 shadowing in eithe
Donn Cave 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 expressions at
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 bang
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 Mar
Thank you :)
On Wed, Jul 10, 2013 at 8:33 AM, Twan van Laarhoven wrote:
> 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
>
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 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 representat
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 shor
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 sam
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
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 <**
sub
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 fo
Michael Snoyman 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 moving forward on,
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
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
wrote:
> There's a pattern that arises fairly often
On Wed, Jul 10, 2013 at 1:01 PM, John Lato wrote:
> On Wed, Jul 10, 2013 at 5:02 PM, Erik Hesselink wrote:
>
>> On Wed, Jul 10, 2013 at 10:39 AM, John Lato wrote:
>> > I think 'shouldBeCaught' is more often than not the wrong thing. A
>> > whitelist of exceptions you're prepared to handle makes
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
wrote:
> On 10.07.2013 01:38, kudah wrote:
> > I've attached the script that I had trouble with. It
On Wed, Jul 10, 2013 at 5:02 PM, Erik Hesselink wrote:
> On Wed, Jul 10, 2013 at 10:39 AM, John Lato 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.
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 St
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= [SomeExce
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 frag
> 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 ca
On Wed, Jul 10, 2013 at 10:39 AM, John Lato 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 or network e
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
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
http:/
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) =
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 non
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 sugge
Michael Snoyman 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
> right approach t
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) = ba
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 y
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
s
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
On 10 July 2013 08:57, Alfredo Di Napoli 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:
>>
>> https://github.com/basvandijk/vector-b
> 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 abou
54 matches
Mail list logo
