Re: [Haskell-cafe] Proposal: Non-recursive let

[AntC]

>  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 the fragment like the
> above and the only problem was my messing up the numbering (at one
> place I used s2 where I should've used s3). ...

Oleg, I hope you are not saying that in production code you use names like 
x, y, z, s1, s2, s3, s4, ...

It leads to opaque code. If even you can mess up, what hope for us with 
only nano-Oleg brain capacity?

Next you'll be wanting GOTO and destructive assignment.

Who knows: one day somebody modifying your code might need to insert a 
line. (That 'somebody' might be your future self.)

Just don't do that! Use long_and_meaningful names.

50-100 near-identical lines of code sounds like an opportunity for an 
algorithm.

AntC


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[oleg]

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.

Richard A. O'Keefe wrote
> >> 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.
> ...
> I find that that when the same name gets reused like
> that I get very confused indeed about which one I am
> looking at right now.
> ...
> If each instance of the variable is labelled with a
> sequence number, I don't get confused because each
> variable has a different name and I can *see* which
> one this is.
>
> Yes, sequence numbering variable states is a chore for
> the person writing the code, but it's a boon for the
> person reading the code.

Let me point out the latest Report on the programming language Clean
http://clean.cs.ru.nl/download/doc/CleanLangRep.2.2.pdf
specifically PDF pages 38-40 (Sec 3.5.4 Let-Before Expression). Let me
quote the relevant part:

Many of the functions for input and output in the CLEAN I/O library
are state transition functions. Such a state is often passed from one
function to another in a single threaded way (see Chapter 9) to force
a specific order of evaluation. This is certainly the case when the
state is of unique type. The threading parameter has to be renamed to
distinguish its different versions. The following example shows a
typical example: Use of state transition functions. The uniquely typed
state file is passed from one function to another involving a number
of renamings: file, file1, file2)

readchars:: *File -> ([Char], *File)
readchars file
| not ok   = ([],file1)
| otherwise = ([char:chars], file2)
where
  (ok,char,file1) = freadc file
  (chars,file2)   = readchars file1

This explicit renaming of threaded parameters not only looks very
ugly, these kind of definitions are sometimes also hard to read as
well (in which order do things happen? which state is passed in which
situation?). We have to admit: an imperative style of programming is
much easier to read when things have to happen in a certain order such
as is the case when doing I/O. That is why we have introduced
let-before expressions.

It seems the designers of Clean have the opposite view on the explicit
renaming (that is, sequential numbering of unique variables).

Let-before expressions have a special scope rule to obtain an
imperative programming look. The variables in the left- hand side of
these definitions do not appear in the scope of the right-hand side of
that definition, but they do appear in the scope of the other
definitions that follow (including the root expression, excluding
local definitions in where blocks.

Notice that a variable defined in a let-before expression cannot be
used in a where expression. The reverse is true however: definitions
in the where expression can be used in the let before expression.  Use
of let before expressions, short notation, re-using names taking use
of the special scope of the let before)

readchars:: *File -> ([Char], *File)
readchars file
#(ok,char,file)   = freadc file
|not ok   = ([],file)
#(chars,file) = readchars file
=([char:chars], file)

The code uses the same name 'file' all throughout, shadowing it
appropriately. Clean programmers truly do all IO in this style, see
the examples in
http://clean.cs.ru.nl/download/supported/ObjectIO.1.2/doc/tutorial.pdf

[To be sure I do not advocate using Clean notation '#' for
non-recursive let in Haskell. Clean is well-known for its somewhat
Spartan notation.]

State monad is frequently mentioned as an alternative. But monads are
a poor alternative to uniqueness typing. Granted, if a function has
one unique argument, e.g., World, then it is equivalent to the ST (or
IO) monad. However, a function may have several unique arguments. For
example, Arrays in Clean are uniquely typed so they can be updated
destructively. A function may have several argument arrays. Operations
on one array have to be serialized (which is what uniqueness typing
accomplishes) but the relative order among operations on distinct
arrays may be left unspecified, for the compiler to determine.

Monads, typical of imperative programs, overspecify the order. For
example,
do
  x <- readSTRef ref1
  y <- readSTRef ref2
  writeSTRef ref2 (x+y)

the write to ref2 must happen after reading ref2, but ref1 could be
read either before or after ref2. (Assuming ref2 and ref1 are distinct
-- the uniqueness typing will make sure of it.)  Alas, in a monad we
cannot leave the order 

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[oleg]

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.

Let's take pure the simply-typed lambda-calculus, or System F, or
System Fomega. Or the Calculus of Inductive Constructions. These
calculi are pure in the sense that the result of evaluation of each
expression does not depend on the evaluation strategy. One can use
call-by-name, call-by-need, call-by-value, pick the next redex at
random or some other evaluation strategy -- and the result will be
just the same. Although the simply-typed lambda-calculus is quite
limited in its expressiveness, already System F is quite powerful
(e.g., allowing for the list library), to say nothing of CIC. In all
these systems, the non-recursive let

let x = e1 in e2
is merely the syntactic sugar for
(\x. e2) e1

OTH, the recursive let is not expressible. (Incidentally, although
System F and above express self-application (\x.x x), a fix-point
combinator is not typeable.) Adding the recursive let introduces
general recursion and hence the dependence on the evaluation
strategy. There are a few people who say non-termination is an
effect. The language with non-termination is no longer pure.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]

[Richard A. O'Keefe]

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



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]

[Richard A. O'Keefe]

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 position to prove me wrong?

I have a copy of nhc98 running (v1.16 of 2003-03-08).
Program:

main = let ones = 1 : ones in print $ take 10 $ ones

Output:

[1,1,1,1,1,1,1,1,1,1]

So no, nhc98's rules were _not_ different.
It would have been no use as a Haskell98 compiler if they had been.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[Richard A. O'Keefe]

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
small heads many years ago -- long enough to forget the
actual title, sorry -- I realised that I too was a Bear
of Very Little Brain and Get Confused Very Easily.

I find that that when the same name gets reused like
that I get very confused indeed about which one I am
looking at right now.

If the variable is hidden (as by the DCG transformation
in Prolog, or a state monad, I don't get confused about
the variable because it isn't visible.

If each instance of the variable is labelled with a
sequence number, I don't get confused because each
variable has a different name and I can *see* which
one this is.

Yes, sequence numbering variable states is a chore for
the person writing the code, but it's a boon for the
person reading the code.

Me, I'd be perfectly happy with

setup (x,s) = state (\_ -> (x,s))

(setup $ foo 1 []) >>= \x ->
bar x >>= \y ->
baz x y >>= \z ->
...

One reason for this is that it makes refactorings like
extracting bar ... >>= ... baz ... thinkable.  A long
sequence of updates is probably crying out for such a
refactoring.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correct way to "catch all exceptions"

[John Lato]

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 user code.  You can
use the async package or similar to wrap this, so it doesn't even add any
LOCs.

What I think is particularly niche is not being able to afford the cost of
another fork, but I strongly doubt that's the case for Warp.

The reason I think this is a bad design is twofold: first maintaining a
list of exclusions like this (whether it's consolidated in a function or
part of the exception instance) seems rather error-prone and increases the
maintenance burden for very little benefit IMHO.

Besides, it's still not correct.  What if you're running arbitrary user
code that forks its own threads?  Then that code's main thread could get a
BlockedIndefinitelyOnMVar exception that really shouldn't escape the user
code, but with this approach it'll kill your worker thread anyway.  Or even
malicious/brain-damaged code that does myThreadId >>= killThread?

I like Ertugrul's suggestion though.  It wouldn't fix this issue, but it
would add a lot more flexibility to exceptions.


On Wed, Jul 10, 2013 at 6:44 PM, Michael Snoyman wrote:

>
>
>
> 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 much more
>>> sense than
>>> > excluding certain operations.  Some common whitelists, e.g. filesystem
>>> > exceptions or network exceptions, might be useful to have.
>>>
>>> You'd think that, but there are common use cases. For example, if you
>>> have a queue of work items, and a thread (or threads) processing them,
>>> it is useful to catch all exceptions of these threads. You can then
>>> log the exception, remove the item from the queue and put it in some
>>> error bucket, and continue on to the next item. The same goes for e.g.
>>> socket listening threads etc.
>>>
>>> The thing here is that you are *not* actually handling the specific
>>> exception, but instead failing gracefully. But you still want to be
>>> able to kill the worker threads, and you don't want to handle
>>> exceptions that you cannot recover from even by moving on to the next
>>> work item.
>>>
>>
>> I think that's a particularly niche use case.  We have some similar code,
>> and our approach is to have the thread re-throw (or terminate) after
>> logging the exception.  There's a separate thread that monitors the thread
>> pool, and when threads die new ones are spawned to take their place (unless
>> the thread pool is shutting down, of course).  Spawning a new thread only
>> happens on an exception and it's cheap anyway, so there's no performance
>> issue.
>>
>> As Haskell currently stands trying to sort out thread-control and
>> fatal-for-real exceptions from other exceptions seems rather fiddly,
>> unreliable, and prone to change between versions, so I think it's best
>> avoided.  If there were a standard library function to do it I might use
>> it, but I wouldn't want to maintain it.
>>
>>
> Maybe I'm just always working on niche cases then, because I run into this
> problem fairly regularly. Almost any time you want to write a library that
> will run code it doesn't entirely trust, this situation arises. Examples
> include:
>
>- Writing a web server (like Warp) which can run arbitrary user code.
>Warp must fail gracefully if the user code throws an exception, without
>bringing down the entire server thread.
>- Writing some kind of batch processing job which uses any library
>which may throw an exception. A white list approach would not be sufficient
>here, since we want to be certain that any custom exception types have been
>caught.
>- A system which uses worker threads to do much of its work. You want
>to make certain the worker threads don't unexpectedly die because some
>exception was thrown that you were not aware could be thrown. I use this
>technique extensively in Keter, and in fact some work I'm doing on that
>code base now is what triggered this email.
>
> I think that, overall, Ertugrul's suggestion is probably the right one: we
> should be including richer information in the `Exception` typeclass so that
> there's no guessing involved, and any custom exception types can explicitly
> state what their recovery preference is. In the meanwhile, I think we could
> get pretty far by hard-coding some rules about standard exception types,
> and making an assumption about all custom exception types (e.g., they *
> should* be caught by a "catch all exceptions" call).
>
> If we combine these two ideas, we could have a new package on Hackage
> which d

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]

[Donn Cave]

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 right, anyway,
probably something else - maybe unambiguous nested shadowing?

  let x = t + 1 in
  let y = x in
  let x = y + 1 in x

GHC allows this, and of course there's no recursion.

Donn

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[Andreas Abel]

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.]


How can you think this if we say we WANT shadowing?!


Also if you are serious about this, you would have to make non-recursive
let the default to get OCaml-style behavior, which would be an extremely
invasive change.  We would have to fix pretty much all packages, all
tutorials, all books, all wiki pages, etc.  Otherwise just like you may
forget to renumber your variables, you may just as well forget to add
the "norec" keyword or whatever the syntax would be.


Wow, this is getting really dramatic now.  Don't be afraid, now one will 
force you to shadow any of your identifiers...


--
Andreas Abel  <><  Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]

[Andreas Abel]

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-expression to be two expressions at the same
time. The recursiveness is buildt-in. It comes from its pure nature.


@Alberto: you must have misunderstood my proposal.


I'm surprised that it would come down to purity.  It looks to me like
simply a question of scope.  I had to write an example program to see
what actually happens, because with me it isn't "intuitive" at all that
the name bound to an expression would be "visible" from within the
expression itself.  I suppose this is considered by some to be a feature,
obviously to others it's a bug.


Value-recursion *is* useful in a lazy language, e.g.

  let xs = 0 : xs

builds an infinite (in fact, circular) list of 0s.  But it is not always 
meaningful, e.g.


  let x = x + 1

simply loops.  I would like to be in the position to tell Haskell what I 
mean, whether I want recursion or not.



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 position to prove me wrong?


I would doubt that nhc98 would interpret  let xs = 0 : xs  differently 
than ghc if it implemented anything close to the Haskell 98 standard. 
But I am not in a position to prove you wrong.


Cheers,
Andreas

--
Andreas Abel  <><  Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Non-recursive let

[Andreas Abel]

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 monad, you lose if-then-else and 
direct use of case, instead of


  case me of {branches }

you need to write

   e <- me; case e of { branches }

This gets a bit better with the new \case, if you can afford to only 
compile on the newest ghc.


  me >>= \case { branches }



On Wed, Jul 10, 2013 at 1:49 PM, Ertugrul Söylemez mailto:e...@ertes.de>> wrote:

"Ezra e. k. Cooper" mailto: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 shadowing in either case.


 >   let x =! expr in body  -- The explosive bang gives an imperative
 >   flavor.

(=!) is a valid operator name.


 > Other suggestions would be welcome.

My suggestion:  Don't add a non-recursive let.  See my other post about
general recursion and totality checking.


Greets,
Ertugrul

--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.



--
Andreas Abel  <><  Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]

[Andreas Abel]

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 termination checking, you can over-approximate the 
control-flows and just scream if you find a *potential* control flow 
that *might* lead to non-termination.  If you do not find such a control 
flow you can be sure things are terminating.  This is how Agda does it.


To be sure that something is definitely non-terminating, you need to 
show it is non-terminating on all *actual* control flows.  But usually 
you cannot statically tell whether in "if c then d else e" d or e is 
evaluated, so a non-termination analysis without false positives seems 
very restricted.  Still it might be could useful.


Having said this, having a termination analysis is not the "proper 
solution" to the lack of a non-recursive let, it does not establish 
shadowing behavior I want.


Cheers,
Andreas

On 10.07.13 7:44 PM, Ertugrul Söylemez wrote:

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 the
same time. The recursiveness is buildt-in. It comes from its pure
nature.


I'm surprised that it would come down to purity.  It looks to me like
simply a question of scope.  I had to write an example program to see
what actually happens, because with me it isn't "intuitive" at all
that the name bound to an expression would be "visible" from within
the expression itself.  I suppose this is considered by some to be a
feature, obviously to others it's a bug.


In a non-strict-by-default language like Haskell it's certainly a
feature.  A sufficiently smart compiler can figure out whether a
definition is recursive or not and apply the proper transformation, so
from a language-theoretic standpoint there is really no reason to have a
non-recursive let.

I think the proper solution is to identify the underlying problem:
general recursion.  Haskell does not enforce totality.  I'd really love
to see some optional totality checking in Haskell.  If Oleg decides not
to use a state monad, he will still have to be careful not to confuse
the numbers, but if he does, then the compiler will reject his code
instead of producing <>ing code.


Greets,
Ertugrul



--
Andreas Abel  <><  Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Netwire bouncing ball

[Ertugrul Söylemez]

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 simple way to do this is to use integralLim_ instead of
integral_.  It allows the ball itself to handle the bouncing.  A less
invasive way (i.e. you can add it to your example) is to use the (-->)
combinator:

ball = integral_ 0 . integral_ 40 . (-9.8)

aboveGround = require (>= 0)

bouncingBall = aboveGround . ball --> bouncingBall

While this gives you a bouncing ball, the ball will not follow real
physics.  Once the ball hits the ground, it will just start over with
its original velocity.  integralLim_ is the correct solution.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Netwire bouncing ball

[Jason Dagit]

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've never used netwire (although I've used yampa and
recative-banana), so I can't give you help with the code, but maybe I
can help with the concepts.

I think I see what is wrong. You need to keep applying forces to the
ball. Right now, the code says, once the ball falls below a certain
point, stop applying the force (eg., clamp the output of the
integral). Instead, you could apply an upward force at the point of
impact. You can get this from newton's third law (equal and opposite
reaction). The easiest way to see a bounce would be to simply negate
the velocity when you detect a collision with the ground. A more
accurate way might involve some calculations to figure out the
impulse, but then you'll need more things like the mass of the ball.

I hope that helps,
Jason

>
> How can I make the ball bounce?
>
>
> Here is the code:
>
> {-# LANGUAGE Arrows #-}
>
> module Main where
>
> import Control.Wire
> import Prelude hiding ((.), id)
> import Control.Concurrent
>
> type Pos = Double
> type Vel = Double
> type ObjState = (Pos, Vel)
>
> testApp :: Pos -> Vel -> WireP () ObjState
> testApp p0 v0 = proc _ -> do
> v <- integral_ v0 -< -9.81
> p <- integral1_ p0 -< v
> when (>= 0) -< p
> returnA -< (p, v)
>
> main :: IO ()
> main = loop' (testApp 0 30) clockSession
> where
> loop' w' session' = do
> threadDelay 100
> (mx, w, session) <- stepSessionP w' session' ()
> case mx of
> Left ex -> putStrLn ("Inhibited: " ++ show ex)
> Right x -> putStrLn ("Produced: " ++ show x)
> loop' w session
>
> Thanks in advance!
>
> ___
> 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

[Haskell-cafe] Netwire bouncing ball

[Just]

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:

{-# LANGUAGE Arrows #-}

module Main where

import Control.Wire
import Prelude hiding ((.), id)
import Control.Concurrent

type Pos = Double
type Vel = Double
type ObjState = (Pos, Vel)

testApp :: Pos -> Vel -> WireP () ObjState
testApp p0 v0 = proc _ -> do
v <- integral_ v0 -< -9.81
p <- integral1_ p0 -< v
when (>= 0) -< p
returnA -< (p, v)

main :: IO ()
main = loop' (testApp 0 30) clockSession
where
loop' w' session' = do
threadDelay 100
(mx, w, session) <- stepSessionP w' session' ()
case mx of
Left ex -> putStrLn ("Inhibited: " ++ show ex)
Right x -> putStrLn ("Produced: " ++ show x)
loop' w session

Thanks in advance!

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: MFlow 3.0

[Alberto G. Corona]

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
application since the state in a continuation is big and can not be
synchronized fast enough. In other languages these states are not even
portable between machines.


2013/7/10 Alexander Kjeldaas 

> 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 often
> makes it possible to isolate failures.  However, it seems to me that it is
> be possible to solve this in Haskell where state can be serialized and
> synchronized between multiple machines using Cloud Haskell, something that
> is error-prone or impossible in other languages.  But that step has never
> been taken.
>
> Alexander
>
>
> On Wed, Jul 10, 2013 at 4:48 PM, Alberto G. Corona wrote:
>
>> 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 same page. See for example this:
>>
>> [PDF] *Seaside* – A *Multiple* Control *Flow* Web Application 
>> Framework
>>
>> There is also other: Apache Coccoon that run in a special kind of
>> JavaScript. The continuation-based frameworks have the reputation of
>> storing a lot of application state and to be non  scalable. MFlow
>> uses backtracking and It does not have these problems.
>>
>>
>> 2013/7/10 Adrian May 
>>
>>> 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 <** submitButton 
>>> "enter" <++ br
>>>
>>>
>>>
>>>
>>>
>>>   n2 <- p << "Enter second number" ++> getInt Nothing <** submitButton 
>>> "enter" <++ br
>>>
>>>
>>>
>>>
>>>
>>>   n3 <- p << "Enter third number"  ++> getInt Nothing <** submitButton 
>>> "enter" <++ br
>>>
>>>
>>>
>>>
>>>
>>>   p <<  ("The result is: "++show (n1 + n2 + n3))  ++>  wlink () << b << 
>>> " menu"
>>>
>>>
>>>
>>>
>>>
>>>   <++ p << "you can change the numbers in the boxes to see how the 
>>> result changes"
>>>
>>> Is that pretty or what? That's the code for this:
>>>
>>> http://mflowdemo.herokuapp.com/noscript/fviewmonad
>>>
>>> To me that's a real technological step over and above the usual servlets
>>> paradigm and I'd love to see more people getting involved. It seems like
>>> Yesod and Happstack have a lot more manpower behind them, but unless I've
>>> missed something, MFlow is going somewhere new and should be helped along.
>>>
>>> Adrian.
>>>
>>> PS. Besides Seaside, Racket is playing with the same ideas. They (Jay
>>> McCarthy) have something to say about performance but I didn't quite
>>> understand it.
>>>
>>>
>>>
>>> On 10 July 2013 06:41, Alberto G. Corona  wrote:
>>>
 The third version of MFlow is out.

 http://hackage.haskell.org/package/MFlow

 MFlow is an all-heterodox web application framework, but very
 haskellish.

 Now MFlow support restful URLs.  It is the first stateful web framework
 to my knowledge that supports it. The type safe routes are implicitly
 expressed as normal monadic code within a navigation monad. The application
 look as a normal imperative console application, but the navigation monad
 goes back and forth to match the path of the URL. The user has control of
 the state, that can roll-back or not when the navigation goes back
 depending on the application needs. The state is in the form of normal
 Haskell variables In a monadic computation, with the weird addition of
 backtracking.

 The menu of the application below is implemented as an imperative-like
 syntax, but the application navigate forward and backward to synchronize
 with the requests of the web browser:
 http://mflowdemo.herokuapp.com/

 This version support  in-page flows.
  What is that? look at this example:

 http://mflowdemo.herokuapp.com/noscript/fviewmonad

 These flows are implemented as formlets with a monad instance, and
 ca

Re: [Haskell-cafe] Proposal: Non-recursive let

[Carter Schonwald]

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 = 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 either case.
>
>
> >   let x =! expr in body  -- The explosive bang gives an imperative
> >   flavor.
>
> (=!) is a valid operator name.
>
>
> > Other suggestions would be welcome.
>
> My suggestion:  Don't add a non-recursive let.  See my other post about
> general recursion and totality checking.
>
>
> Greets,
> Ertugrul
>
> --
> Not to be or to be and (not to be or to be and (not to be or to be and
> (not to be or to be and ... that is the list monad.
>
> ___
> 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] Music / MIDI help

[Brent Yorgey]

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 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 short sequences and play them immediately, preferrably in ghci,
> -- but 'runHaskell Foo.hs | barPlayer' would be acceptable
> 2) generate MIDI files
> 
> I'm on OS X.
> 
> So far what I've found is: Haskore, the midi package, and the jack package
> - and then I'd need some MIDI software synth for the Mac, and Jack based
> patcher Or perhaps I want SuperCollider, and the Haskell bindings - but
> that seems rather low level for my needs here (I don't really need to patch
> together my instruments, and I don't want to have re-write the whole timing
> framework from scratch.)
> 
> So - What's a quick easy path here?
> 
> - Mark

> ___
> 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] ANNOUNCE: MFlow 3.0

[Alexander Kjeldaas]

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 often
makes it possible to isolate failures.  However, it seems to me that it is
be possible to solve this in Haskell where state can be serialized and
synchronized between multiple machines using Cloud Haskell, something that
is error-prone or impossible in other languages.  But that step has never
been taken.

Alexander


On Wed, Jul 10, 2013 at 4:48 PM, Alberto G. Corona wrote:

> 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 same page. See for example this:
>
> [PDF] *Seaside* – A *Multiple* Control *Flow* Web Application 
> Framework
>
> There is also other: Apache Coccoon that run in a special kind of
> JavaScript. The continuation-based frameworks have the reputation of
> storing a lot of application state and to be non  scalable. MFlow
> uses backtracking and It does not have these problems.
>
>
> 2013/7/10 Adrian May 
>
>> 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 <** submitButton 
>> "enter" <++ br
>>
>>
>>
>>   n2 <- p << "Enter second number" ++> getInt Nothing <** submitButton 
>> "enter" <++ br
>>
>>
>>
>>   n3 <- p << "Enter third number"  ++> getInt Nothing <** submitButton 
>> "enter" <++ br
>>
>>
>>
>>   p <<  ("The result is: "++show (n1 + n2 + n3))  ++>  wlink () << b << 
>> " menu"
>>
>>
>>
>>   <++ p << "you can change the numbers in the boxes to see how the 
>> result changes"
>>
>> Is that pretty or what? That's the code for this:
>>
>> http://mflowdemo.herokuapp.com/noscript/fviewmonad
>>
>> To me that's a real technological step over and above the usual servlets
>> paradigm and I'd love to see more people getting involved. It seems like
>> Yesod and Happstack have a lot more manpower behind them, but unless I've
>> missed something, MFlow is going somewhere new and should be helped along.
>>
>> Adrian.
>>
>> PS. Besides Seaside, Racket is playing with the same ideas. They (Jay
>> McCarthy) have something to say about performance but I didn't quite
>> understand it.
>>
>>
>>
>> On 10 July 2013 06:41, Alberto G. Corona  wrote:
>>
>>> The third version of MFlow is out.
>>>
>>> http://hackage.haskell.org/package/MFlow
>>>
>>> MFlow is an all-heterodox web application framework, but very
>>> haskellish.
>>>
>>> Now MFlow support restful URLs.  It is the first stateful web framework
>>> to my knowledge that supports it. The type safe routes are implicitly
>>> expressed as normal monadic code within a navigation monad. The application
>>> look as a normal imperative console application, but the navigation monad
>>> goes back and forth to match the path of the URL. The user has control of
>>> the state, that can roll-back or not when the navigation goes back
>>> depending on the application needs. The state is in the form of normal
>>> Haskell variables In a monadic computation, with the weird addition of
>>> backtracking.
>>>
>>> The menu of the application below is implemented as an imperative-like
>>> syntax, but the application navigate forward and backward to synchronize
>>> with the requests of the web browser:
>>> http://mflowdemo.herokuapp.com/
>>>
>>> This version support  in-page flows.
>>>  What is that? look at this example:
>>>
>>> http://mflowdemo.herokuapp.com/noscript/fviewmonad
>>>
>>> These flows are implemented as formlets with a monad instance, and
>>> callbacks which change the look. I call them "widgets":
>>>
>>>
>>> http://haskell-web.blogspot.com.es/2013/06/the-promising-land-of-monadic-formlets.html
>>>
>>>
>>> Each page may have many  of these active widgets, each one running their
>>> own flow. These widgets refresh themselves trough Ajax if they are enclosed
>>> in the primitive "autoRefresh". If there is no Ajax or JavaScript
>>> available, they gracefully degrade by refreshing the entire page:
>>>
>>> http://mflowdemo.herokuapp.com/noscript/combination
>>>
>>>
>>> http://haskell-web.blogspot.com.es/2013/06/and-finally-widget-auto-refreshing.html
>>>
>>> The page flows and the multif

Re: [Haskell-cafe] Proposal: Non-recursive let

[Ertugrul Söylemez]

"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 either case.


>   let x =! expr in body  -- The explosive bang gives an imperative
>   flavor.

(=!) is a valid operator name.


> Other suggestions would be welcome.

My suggestion:  Don't add a non-recursive let.  See my other post about
general recursion and totality checking.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]

[Ertugrul Söylemez]

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 the
> > same time. The recursiveness is buildt-in. It comes from its pure
> > nature.
>
> I'm surprised that it would come down to purity.  It looks to me like
> simply a question of scope.  I had to write an example program to see
> what actually happens, because with me it isn't "intuitive" at all
> that the name bound to an expression would be "visible" from within
> the expression itself.  I suppose this is considered by some to be a
> feature, obviously to others it's a bug.

In a non-strict-by-default language like Haskell it's certainly a
feature.  A sufficiently smart compiler can figure out whether a
definition is recursive or not and apply the proper transformation, so
from a language-theoretic standpoint there is really no reason to have a
non-recursive let.

I think the proper solution is to identify the underlying problem:
general recursion.  Haskell does not enforce totality.  I'd really love
to see some optional totality checking in Haskell.  If Oleg decides not
to use a state monad, he will still have to be careful not to confuse
the numbers, but if he does, then the compiler will reject his code
instead of producing <>ing code.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Non-recursive let

[Ezra e. k. Cooper]

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 gives an imperative
  flavor.

Other suggestions would be welcome.

Ezra

On Wed, Jul 10, 2013, at 01:47 AM, o...@okmij.org wrote:
> 
> I have also had problems with non-termination, unintended recursion. 
> The problem is not caught statically and leads to looping, which may
> be quite difficult to debug. Andreas should tell his story.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Music / MIDI help

[Anton Kholomiov]

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 Mark Lentczner 

> 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 short sequences and play them immediately, preferrably in ghci,
> -- but 'runHaskell Foo.hs | barPlayer' would be acceptable
> 2) generate MIDI files
>
> I'm on OS X.
>
> So far what I've found is: Haskore, the midi package, and the jack package
> - and then I'd need some MIDI software synth for the Mac, and Jack based
> patcher Or perhaps I want SuperCollider, and the Haskell bindings - but
> that seems rather low level for my needs here (I don't really need to patch
> together my instruments, and I don't want to have re-write the whole timing
> framework from scratch.)
>
> So - What's a quick easy path here?
>
> - Mark
>
>
> ___
> 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] Is the following implemented by a sparse matrix representation? type Graph n w = Array (n, n) (Maybe w)

[KC]

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
> (IntMap w)" or "Map (n,n) w" or "Array n (IntMap w)". Each of these
> representations is slightly different, and there will be different
> trade-offs.
>
>
> Twan
>
> On 09/07/13 23:26, KC wrote:
> > Is the following implemented by a sparse matrix representation?
>
>  type Graph n w = Array (n,n) (Maybe w)
>>
>> --
>> --
>> Regards,
>> KC
>>
>
>
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>



-- 
--
Regards,
KC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guardsloops]

[Donn Cave]

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 same
> time. The recursiveness is buildt-in. It comes from its pure nature.

I'm surprised that it would come down to purity.  It looks to me like
simply a question of scope.  I had to write an example program to see
what actually happens, because with me it isn't "intuitive" at all that
the name bound to an expression would be "visible" from within the
expression itself.  I suppose this is considered by some to be a feature,
obviously to others it's a bug.

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 position to prove me wrong?

thanks,
Donn

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Is the following implemented by a sparse matrix representation? type Graph n w = Array (n, n) (Maybe w)

[Twan van Laarhoven]

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 slightly 
different, and there will be different trade-offs.



Twan

On 09/07/13 23:26, KC wrote:
> Is the following implemented by a sparse matrix representation?

type Graph n w = Array (n,n) (Maybe w)

--
--
Regards,
KC




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Music / MIDI help

[Mark Lentczner]

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 short sequences and play them immediately, preferrably in ghci,
-- but 'runHaskell Foo.hs | barPlayer' would be acceptable
2) generate MIDI files

I'm on OS X.

So far what I've found is: Haskore, the midi package, and the jack package
- and then I'd need some MIDI software synth for the Mac, and Jack based
patcher Or perhaps I want SuperCollider, and the Haskell bindings - but
that seems rather low level for my needs here (I don't really need to patch
together my instruments, and I don't want to have re-write the whole timing
framework from scratch.)

So - What's a quick easy path here?

- Mark
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: MFlow 3.0

[Alberto G. Corona]

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 same page. See for example this:

[PDF] *Seaside* – A *Multiple* Control *Flow* Web Application
Framework

There is also other: Apache Coccoon that run in a special kind of
JavaScript. The continuation-based frameworks have the reputation of
storing a lot of application state and to be non  scalable. MFlow
uses backtracking and It does not have these problems.


2013/7/10 Adrian May 

> 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 <** submitButton 
> "enter" <++ br
>
>   n2 <- p << "Enter second number" ++> getInt Nothing <** submitButton 
> "enter" <++ br
>
>   n3 <- p << "Enter third number"  ++> getInt Nothing <** submitButton 
> "enter" <++ br
>
>   p <<  ("The result is: "++show (n1 + n2 + n3))  ++>  wlink () << b << " 
> menu"
>
>   <++ p << "you can change the numbers in the boxes to see how the result 
> changes"
>
> Is that pretty or what? That's the code for this:
>
> http://mflowdemo.herokuapp.com/noscript/fviewmonad
>
> To me that's a real technological step over and above the usual servlets
> paradigm and I'd love to see more people getting involved. It seems like
> Yesod and Happstack have a lot more manpower behind them, but unless I've
> missed something, MFlow is going somewhere new and should be helped along.
>
> Adrian.
>
> PS. Besides Seaside, Racket is playing with the same ideas. They (Jay
> McCarthy) have something to say about performance but I didn't quite
> understand it.
>
>
>
> On 10 July 2013 06:41, Alberto G. Corona  wrote:
>
>> The third version of MFlow is out.
>>
>> http://hackage.haskell.org/package/MFlow
>>
>> MFlow is an all-heterodox web application framework, but very haskellish.
>>
>> Now MFlow support restful URLs.  It is the first stateful web framework
>> to my knowledge that supports it. The type safe routes are implicitly
>> expressed as normal monadic code within a navigation monad. The application
>> look as a normal imperative console application, but the navigation monad
>> goes back and forth to match the path of the URL. The user has control of
>> the state, that can roll-back or not when the navigation goes back
>> depending on the application needs. The state is in the form of normal
>> Haskell variables In a monadic computation, with the weird addition of
>> backtracking.
>>
>> The menu of the application below is implemented as an imperative-like
>> syntax, but the application navigate forward and backward to synchronize
>> with the requests of the web browser:
>> http://mflowdemo.herokuapp.com/
>>
>> This version support  in-page flows.
>>  What is that? look at this example:
>>
>> http://mflowdemo.herokuapp.com/noscript/fviewmonad
>>
>> These flows are implemented as formlets with a monad instance, and
>> callbacks which change the look. I call them "widgets":
>>
>>
>> http://haskell-web.blogspot.com.es/2013/06/the-promising-land-of-monadic-formlets.html
>>
>>
>> Each page may have many  of these active widgets, each one running their
>> own flow. These widgets refresh themselves trough Ajax if they are enclosed
>> in the primitive "autoRefresh". If there is no Ajax or JavaScript
>> available, they gracefully degrade by refreshing the entire page:
>>
>> http://mflowdemo.herokuapp.com/noscript/combination
>>
>>
>> http://haskell-web.blogspot.com.es/2013/06/and-finally-widget-auto-refreshing.html
>>
>> The page flows and the multiflow idea was inspired in 
>> Seaside,
>> a great Smalltalk web framework and adapted to the pure recursive nature of
>> Haskell and the formlets.
>>
>> It also support some JQuery widgets integrated: modal and not modal
>> dialogs, datePicker and other active widgets that handle other widgets.
>>
>> It also support the older features: persistent state, WAI, blaze-html and
>> others integration, server process timeouts, Ajax, requirements,
>>  content management, caching of widget rendering and all the other
>> previous stuff.
>>
>> I wish to thank some people for their feedback. Specially Adrian May for
>> his feedback and interest
>>
>>
>> --
>> Alberto.
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/ma

Re: [Haskell-cafe] Parsec error message not making any sense

[David McBride]

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 to save its location at every possible branch point).

When you go many1 (interval name), it will parse the five intervals
[n] lines, and then try to parse a 6th one.  Well it turns out the
next atom begins with an 'i' character.  When it hits the t afterword,
that was wrong, it was expecting "intervals [", not an i followed by a
t.  That error message is exactly right.  At that point it fails,
which is fine, it is supposed to fail, but it unfortunately does not
move its place in the text stream back up to the i, it stays at the
't' character, then tries to parse more item blocks starting there.

The fix is to change interval to: "interval tierName = try $ do".
That means if it fails anywhere in the interval block, it will move
the parser back to where it was when the try was hit and then try to
parse it in some other manner.

I think that the rest of your code is pretty good, but you will have
to fix a few more things to completely parse your file.

On Tue, Jul 9, 2013 at 4:23 PM, Fredrik Karlsson  wrote:
> Hi,
>
> Sorry, that was a careless extraction of code - I should have made sure that
> it was complete.
> Please, have a look again. When downloading and running the gist
> (https://gist.github.com/dargosch/5955045) , I still get the error:
>
> Main> let testFile =
> "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid"
> *Main> parseFromFile textgridfile testFile
> Left
> "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid"
> (line 35, column 5):
> unexpected "t"
> expecting "intervals ["
>
> on the attached testfile. The "tier" parser works once, but then I get an
> error that I cant understand, given the input.
> How come the parser finds the "unexpected "t"" when the expected thing is
> what is in the input at that point?
>
> Thankful for any help I can get on this.
>
>
> On Tue, Jul 9, 2013 at 10:22 PM, Fredrik Karlsson 
> wrote:
>>
>> Hi,
>>
>> Sorry, that was a careless extraction of code - I should have made sure
>> that it was complete.
>> Please, have a look again. When downloading and running the gist, I still
>> get the error:
>>
>> Main> let testFile =
>> "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid"
>> *Main> parseFromFile textgridfile testFile
>> Left
>> "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid"
>> (line 35, column 5):
>> unexpected "t"
>> expecting "intervals ["
>>
>> on the attached testfile. The "tier" parser works once, but then I get an
>> error that I cant understand, given the input.
>> How come the parser finds the "unexpected "t"" when the expected thing is
>> what is in the input at that point?
>>
>> Thankful for any help I can get on this.
>>
>>
>> /Fredrik
>>
>>
>> On Tue, Jul 9, 2013 at 9:37 AM, Roman Cheplyaka  wrote:
>>>
>>> Please check your code.
>>>
>>> I had two problems with it: mixed tabs and spaces, and undefined
>>> 'quotedChar'. After defining quotedChar = anyChar, I get a different
>>> error message from yours:
>>>
>>>   *Main> parseFromFile textgridfile "testdata.TextGrid"
>>>   Left "testdata.TextGrid" (line 137, column 1):
>>>   unexpected end of input
>>>   expecting quote at end of cell
>>>
>>> Roman
>>>
>>> * Fredrik Karlsson  [2013-07-09 08:07:24+0200]
>>> > Hi Roman,
>>> >
>>> > I'm using parsec-3.1.3
>>> >
>>> > I put the code in a gist here - sorry about that.
>>> >
>>> > https://gist.github.com/dargosch/5955045
>>> >
>>> > Fredrik
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Jul 9, 2013 at 12:08 AM, Roman Cheplyaka 
>>> > wrote:
>>> >
>>> > > Hi Fredrik,
>>> > >
>>> > > First, do you use the latest parsec version (3.1.3)? If not, can you
>>> > > try
>>> > > the same with 3.1.3?
>>> > >
>>> > > Second, please upload your code to hpaste.org or a similar service
>>> > > and
>>> > > give us the link. It's not much fun to extract code from an html
>>> > > email.
>>> > >
>>> > > Roman
>>> > >
>>> > > * Fredrik Karlsson  [2013-07-08 23:54:17+0200]
>>> > > > Dear list,
>>> > > >
>>> > > > I have a Parsec parser that fails and gives the following error
>>> > > > message:
>>> > > >
>>> > > > *Main> parseFromFile textgridfile testFile
>>> > > > Left
>>> > > >
>>> > >
>>> > > "/Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid"
>>> > > > (line 35, column 5):
>>> > > > unexpected "t"
>>> > > > expecting "intervals ["
>>> > > >
>>> > > > Now, this is perfectly understandable, but line 35, col 5 in the
>>> > > > file
>>> > > being
>>> > > > parsed looks like the supplies image - there is no 't' there.
>>> > > >
>>> > > > Any ideas on what is going on?
>>> > > >
>>> > > > The parser I am using is:
>>> > > >
>>> > > > data VariableLine = 

Re: [Haskell-cafe] ANNOUNCE: MFlow 3.0

[Adrian May]

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 <**
submitButton "enter" <++ br
  n2 <- p << "Enter second number" ++> getInt Nothing <**
submitButton "enter" <++ br
  n3 <- p << "Enter third number"  ++> getInt Nothing <**
submitButton "enter" <++ br
  p <<  ("The result is: "++show (n1 + n2 + n3))  ++>  wlink () <<
b << " menu"
  <++ p << "you can change the numbers in the boxes to see how the
result changes"

Is that pretty or what? That's the code for this:

http://mflowdemo.herokuapp.com/noscript/fviewmonad

To me that's a real technological step over and above the usual servlets
paradigm and I'd love to see more people getting involved. It seems like
Yesod and Happstack have a lot more manpower behind them, but unless I've
missed something, MFlow is going somewhere new and should be helped along.

Adrian.

PS. Besides Seaside, Racket is playing with the same ideas. They (Jay
McCarthy) have something to say about performance but I didn't quite
understand it.



On 10 July 2013 06:41, Alberto G. Corona  wrote:

> The third version of MFlow is out.
>
> http://hackage.haskell.org/package/MFlow
>
> MFlow is an all-heterodox web application framework, but very haskellish.
>
> Now MFlow support restful URLs.  It is the first stateful web framework to
> my knowledge that supports it. The type safe routes are implicitly
> expressed as normal monadic code within a navigation monad. The application
> look as a normal imperative console application, but the navigation monad
> goes back and forth to match the path of the URL. The user has control of
> the state, that can roll-back or not when the navigation goes back
> depending on the application needs. The state is in the form of normal
> Haskell variables In a monadic computation, with the weird addition of
> backtracking.
>
> The menu of the application below is implemented as an imperative-like
> syntax, but the application navigate forward and backward to synchronize
> with the requests of the web browser:
> http://mflowdemo.herokuapp.com/
>
> This version support  in-page flows.
>  What is that? look at this example:
>
> http://mflowdemo.herokuapp.com/noscript/fviewmonad
>
> These flows are implemented as formlets with a monad instance, and
> callbacks which change the look. I call them "widgets":
>
>
> http://haskell-web.blogspot.com.es/2013/06/the-promising-land-of-monadic-formlets.html
>
>
> Each page may have many  of these active widgets, each one running their
> own flow. These widgets refresh themselves trough Ajax if they are enclosed
> in the primitive "autoRefresh". If there is no Ajax or JavaScript
> available, they gracefully degrade by refreshing the entire page:
>
> http://mflowdemo.herokuapp.com/noscript/combination
>
>
> http://haskell-web.blogspot.com.es/2013/06/and-finally-widget-auto-refreshing.html
>
> The page flows and the multiflow idea was inspired in 
> Seaside,
> a great Smalltalk web framework and adapted to the pure recursive nature of
> Haskell and the formlets.
>
> It also support some JQuery widgets integrated: modal and not modal
> dialogs, datePicker and other active widgets that handle other widgets.
>
> It also support the older features: persistent state, WAI, blaze-html and
> others integration, server process timeouts, Ajax, requirements,
>  content management, caching of widget rendering and all the other
> previous stuff.
>
> I wish to thank some people for their feedback. Specially Adrian May for
> his feedback and interest
>
>
> --
> Alberto.
>
> ___
> 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

[Haskell-cafe] Engineering position at Vector Fabrics

[Stefan Holdermans]

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 for growing into the rôle 
of an architect.

Interested? Please contact us at jobs  vectorfabrics.com.

Cheers,

  Stefan


--

Vector Fabrics is growing the team: we are looking for a top-notch
programmer to extend our program-analysis and parallelization
products. You design and implement algorithms to assist programmers in
creating parallel designs from sequential C or C++ programs. You work
with our international team of world-class computer scientists and
experts in the Haskell / OCaml functional programming languages.

Your work is at the forefront of technology, giving you the
opportunity to publish your work in major conferences and directly
cooperate with processor design companies and domain-specific
application vendors.

As we are a startup company, you will quickly have a major impact on
our products and get to know all aspects of product creation. You will
be part of a strongly committed development team and contribute to our
agile development process and automated test suites. Interested? Send
your CV, GitHub account or other proof of what you can do to
j...@vectorfabrics.com.


RESPONSIBILITIES

* Design and implement software optimization (e.g. parallelization)
 algorithms for CPUs and GPUs;

* Thoroughly test your code, create automated test suites;

* Contribute to our agile development planning and process;

* Analyze complex customer applications for optimization opportunities
 and translate this to new analysis algorithms.


PROFILE

* Your friends and colleagues describe you as a superb programmer;
 your programming ability is way above average;

* Demonstrable experience in design and implementation of complex
 software applications; prior experience in functional programming
 languages is preferred;

* You continuously surprise us with your creative yet pragmatic
 solutions for complex software problems;

* You are strongly committed to deliver working software as early as
 possible;

* You work against very high quality standards. Refactoring is your
 bread and butter, pair-programming is how you prefer to review your
 code;

* Whatever technologies, languages, or development environments
 you've been using, we expect you have mastered them in depth, and we
 expect that you will be able to master any technology, language, or
 development environment that we need in the future;

* Excellent command of written and spoken English.


EDUCATION

MSc, MEng, or PhD in Computer Science or significant relevant
experience.


ABOUT VECTOR FABRICS

Vector Fabrics is a high-tech software company, developing tools for
embedded multicore programming. Its technology and expertise is
getting widespread recognition in the industry as being innovative and
unique in their ability to address heterogeneous multicore
application-specific silicon platforms. Due to the advanced nature of
its tools, Vector Fabrics operates at the forefront of the next
generation of embedded platforms for diverse markets ranging from
supercomputers to automotive to cell phones.

Vector Fabrics puts absolute priority on hiring top class individuals
in key positions. Vector Fabrics’ team profile is exceptional and its
ambition is to hire only individuals that match or surpass that
profile. The company pays top salary and offers a challenging,
engaging and stimulating work environment with a high degree of
responsibility.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correct way to "catch all exceptions"

[Ertugrul Söylemez]

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,
> including a library proposal.

Just a minor note:  Add both `hasTag` and `tagsOf` to the type class,
because `hasTag` may use something much more efficient than `elem` like
pattern matching or `Data.Set.member`.  I'm not even sure we really need
`tagsOf`.


Greets,
Ertugrul

-- 
Key-ID: E5DD8D11 "Ertugrul Soeylemez "
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Is the following implemented by a sparse matrix representation? type Graph n w = Array (n, n) (Maybe w)

[Thomas Horstmeyer]

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 in the graph.


But perhaps I misunderstood your question.

Thomas


Am 09.07.2013 23:26, schrieb KC:

type Graph n w = Array (n,n) (Maybe w)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correct way to "catch all exceptions"

[kudah]

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: 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 perfectly valid, except that it catches a number of
> exceptions which seemingly should *not* be caught. In particular, it
> catches the async exceptions used by both killThread and timeout.
> 
> I think it's fair to say that there's not going to be a single
> function that solves all cases correctly, but it is a common enough
> situation that people need to write code that resumes work in the
> case of an exception that I think we need to either have some
> guidelines for the right approach here, or perhaps even a utility
> function along the lines of:
> 
> 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 to take here?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correct way to "catch all exceptions"

[Michael Snoyman]

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 much more sense
>> than
>> > excluding certain operations.  Some common whitelists, e.g. filesystem
>> > exceptions or network exceptions, might be useful to have.
>>
>> You'd think that, but there are common use cases. For example, if you
>> have a queue of work items, and a thread (or threads) processing them,
>> it is useful to catch all exceptions of these threads. You can then
>> log the exception, remove the item from the queue and put it in some
>> error bucket, and continue on to the next item. The same goes for e.g.
>> socket listening threads etc.
>>
>> The thing here is that you are *not* actually handling the specific
>> exception, but instead failing gracefully. But you still want to be
>> able to kill the worker threads, and you don't want to handle
>> exceptions that you cannot recover from even by moving on to the next
>> work item.
>>
>
> I think that's a particularly niche use case.  We have some similar code,
> and our approach is to have the thread re-throw (or terminate) after
> logging the exception.  There's a separate thread that monitors the thread
> pool, and when threads die new ones are spawned to take their place (unless
> the thread pool is shutting down, of course).  Spawning a new thread only
> happens on an exception and it's cheap anyway, so there's no performance
> issue.
>
> As Haskell currently stands trying to sort out thread-control and
> fatal-for-real exceptions from other exceptions seems rather fiddly,
> unreliable, and prone to change between versions, so I think it's best
> avoided.  If there were a standard library function to do it I might use
> it, but I wouldn't want to maintain it.
>
>
Maybe I'm just always working on niche cases then, because I run into this
problem fairly regularly. Almost any time you want to write a library that
will run code it doesn't entirely trust, this situation arises. Examples
include:

   - Writing a web server (like Warp) which can run arbitrary user code.
   Warp must fail gracefully if the user code throws an exception, without
   bringing down the entire server thread.
   - Writing some kind of batch processing job which uses any library which
   may throw an exception. A white list approach would not be sufficient here,
   since we want to be certain that any custom exception types have been
   caught.
   - A system which uses worker threads to do much of its work. You want to
   make certain the worker threads don't unexpectedly die because some
   exception was thrown that you were not aware could be thrown. I use this
   technique extensively in Keter, and in fact some work I'm doing on that
   code base now is what triggered this email.

I think that, overall, Ertugrul's suggestion is probably the right one: we
should be including richer information in the `Exception` typeclass so that
there's no guessing involved, and any custom exception types can explicitly
state what their recovery preference is. In the meanwhile, I think we could
get pretty far by hard-coding some rules about standard exception types,
and making an assumption about all custom exception types (e.g., they *
should* be caught by a "catch all exceptions" call).

If we combine these two ideas, we could have a new package on Hackage which
defines the right set of tags and provides a `tagsOf` function which works
on any instance of Exception, which uses the assumptions I mentioned in the
previous paragraph. If it's then decided that this is generally useful
enough to be included in the Exception typeclass, we have a straightforward
migration path:

   1. Add the new method to the Exception typeclass, with a default
   implementation that conforms with our assumptions.
   2. For any of the special standard exception types (e.g.,
   AsyncException), override that default implementation.
   3. Modify the external package to simply re-export the new method when
   using newer versions of base, using conditional compilation.
   4. Any code written against that external package would work with both
   current and future versions of base.
   5. The only incompatibility would be if someone writes code which
   overrides the typeclass method; that code would only work with newer bases,
   not current ones.

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, including a library proposal.

Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimization flag changing result of code execution

[kudah]

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 tries to
> > replicate one directory structure in another directory, while
> > replacing filenames and file contents with random data. When
> > compiled with -O1 or -O2 resulting file and directory names are
> > composed only of a's and b's, but file contents seem properly
> > randomized.
> >
> No luck. On my computer script works correctly with and without 
> optimizations. My best guess that uniformR is problematic. Does
> 
>  > (\g -> randName g 20) =<< create
> 
> show different behavior with and without optimizations?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correct way to "catch all exceptions"

[John Lato]

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.  Some common whitelists, e.g. filesystem
> > exceptions or network exceptions, might be useful to have.
>
> You'd think that, but there are common use cases. For example, if you
> have a queue of work items, and a thread (or threads) processing them,
> it is useful to catch all exceptions of these threads. You can then
> log the exception, remove the item from the queue and put it in some
> error bucket, and continue on to the next item. The same goes for e.g.
> socket listening threads etc.
>
> The thing here is that you are *not* actually handling the specific
> exception, but instead failing gracefully. But you still want to be
> able to kill the worker threads, and you don't want to handle
> exceptions that you cannot recover from even by moving on to the next
> work item.
>

I think that's a particularly niche use case.  We have some similar code,
and our approach is to have the thread re-throw (or terminate) after
logging the exception.  There's a separate thread that monitors the thread
pool, and when threads die new ones are spawned to take their place (unless
the thread pool is shutting down, of course).  Spawning a new thread only
happens on an exception and it's cheap anyway, so there's no performance
issue.

As Haskell currently stands trying to sort out thread-control and
fatal-for-real exceptions from other exceptions seems rather fiddly,
unreliable, and prone to change between versions, so I think it's best
avoided.  If there were a standard library function to do it I might use
it, but I wouldn't want to maintain it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[Ertugrul Söylemez]

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 there have been other cases where State monad was better
> avoided. For instance, functions like foo and bar are already written
> and they are not in the state monad.

It's fine to use `state` or the StateT constructor here.


> For example, foo may take a non-empty Set and return the minimal
> element and the set without the minimal element. There are several
> such handy functions in Data.Set and Data.Map. Injecting such
> functions into a Set monad for the sake of three lines seems overkill.

Not a Set monad, but a state monad.  Other examples include 'random' and
'randomR', where you can just apply 'state':

getRandom  = state random
getRandomR = state . randomR

I do this a lot.


> Also, in the code above s's don't have to have the same type.

For this purpose we have indexed state monads.


> I particularly like repeated lets when I am writing the code to apply
> transformations to it. Being explicit with state passing improves the
> confidence. It is simpler to reason with the pure code.

Really?  I'm more confident that I got the "updates" right when I use a
state monad, possibly together with lenses.  The idea is to disallow
`get` and only allow `modify` and `put`.

The thing is, your code is really imperative, and it exhibits all the
usual effects of imperative programming:  If you mess up the order of
things, you get wrong results.  In fact the let-style makes things worse
by requiring you to renumber your variables all the time.  A
non-recursive let would really just cover up this problem by imposing an
arbitrary constraint on you.  I think we are all aware that shadowing is
a bad idea, no matter whether you do it through Identity or
non-recursive let.

Also if you are serious about this, you would have to make non-recursive
let the default to get OCaml-style behavior, which would be an extremely
invasive change.  We would have to fix pretty much all packages, all
tutorials, all books, all wiki pages, etc.  Otherwise just like you may
forget to renumber your variables, you may just as well forget to add
the "norec" keyword or whatever the syntax would be.

State monads are actually a nice abstraction to limit the number of
things that could go wrong in this setting.  I suggest using them
instead of changing the language.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correct way to "catch all exceptions"

[Alberto G. Corona]

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=  [SomeException (u :: AsyncException), SomeException (u
::ArithException)]

sample= expr `catchExcept` excluded $ do




2013/7/10 Erik Hesselink 

> 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-recoverable: restarting whatever the thread was
> doing is not the right thing to do.
>
> Erik
>
> On Wed, Jul 10, 2013 at 8:28 AM, Michael Snoyman 
> wrote:
> > 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 perfectly valid, except that it catches a number of exceptions
> > which seemingly should not be caught. In particular, it catches the async
> > exceptions used by both killThread and timeout.
> >
> > I think it's fair to say that there's not going to be a single function
> that
> > solves all cases correctly, but it is a common enough situation that
> people
> > need to write code that resumes work in the case of an exception that I
> > think we need to either have some guidelines for the right approach
> here, or
> > perhaps even a utility function along the lines of:
> >
> > 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 to take here?
> >
> > ___
> > 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
>



-- 
Alberto.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[Alfredo Di Napoli]

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 fragmented, correct? :(

A.


On 10 July 2013 08:25, Bas van Dijk  wrote:

> 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-bytestring
> >
> >
> > That's interesting Bas. What bothers me about ByteStrings is that they
> need
> > to be "pinned" inside the heap,
> > preventing the GC from collecting them.
>
> Being "pinned" doesn't prevent an object from being garbage collected.
> It just means that the GC won't move the object around so that foreign
> code can reliably reference the object while the GC is running:
>
> http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned
>
> > I assume that working with vector remove the problem, correct?
>
> There wasn't a problem in the first but note that a Storable Vector is
> implemented in the same way as a ByteString: a ForeignPtr and a
> length*
>
> I hope I have now improved your sleep quality ;-)
>
> Cheers,
>
> Bas
>
> * A ByteString also contains an offset but vector modifies the pointer
> in the ForeignPtr instead so we safe an Int there.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[oleg]

> 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 where State monad was better
avoided. For instance, functions like foo and bar are already written
and they are not in the state monad. For example, foo may take a
non-empty Set and return the minimal element and the set without the
minimal element. There are several such handy functions in Data.Set
and Data.Map. Injecting such functions into a Set monad for the sake
of three lines seems overkill. 

Also, in the code above s's don't have to have the same type.

I particularly like repeated lets when I am writing the code to apply
transformations to it. Being explicit with state passing improves the
confidence. It is simpler to reason with the pure code.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correct way to "catch all exceptions"

[Erik Hesselink]

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 exceptions, might be useful to have.

You'd think that, but there are common use cases. For example, if you
have a queue of work items, and a thread (or threads) processing them,
it is useful to catch all exceptions of these threads. You can then
log the exception, remove the item from the queue and put it in some
error bucket, and continue on to the next item. The same goes for e.g.
socket listening threads etc.

The thing here is that you are *not* actually handling the specific
exception, but instead failing gracefully. But you still want to be
able to kill the worker threads, and you don't want to handle
exceptions that you cannot recover from even by moving on to the next
work item.

Erik

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[Alberto G. Corona]

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 possible for a variable-expression to be two expressions at the same
time. The recursiveness is buildt-in. It comes from its pure nature.

For a non recursive version of let, it would be necessary to create a new
closure on each line, to create a new variable-expression with the same
name, but within the new closure. A different variable after all. That is
what the example with the Identity (and the state monad) does.

So I think that the ugly return example or the more elegant state monad
alternative is the right thing to do.


2013/7/10 Ertugrul Söylemez 

> 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
> > let (z,s3)  = baz x y s2 in ...
>
> This isn't a case for non-recursive let.  It is one of the rare cases
> where you might actually consider using a state monad.
>
>
> Greets,
> Ertugrul
>
> --
> Not to be or to be and (not to be or to be and (not to be or to be and
> (not to be or to be and ... that is the list monad.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Alberto.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Proposal: Non-recursive let

[oleg]

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://www.haskell.org/pipermail/haskell-cafe/2013-July/109116.html

and repeat the example:

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
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 the fragment like the
above and the only problem was my messing up the numbering (at one
place I used s2 where I should've used s3). In the chain of lets, it
becomes quite a chore to use different variable names -- especially as
one edits the code and adds new let statements.

I have also had problems with non-termination, unintended recursion. 
The problem is not caught statically and leads to looping, which may
be quite difficult to debug. Andreas should tell his story.

In my OCaml experience, I don't ever remember writing let rec by
mistake. Occasionally I write let where let rec is meant, and the type
checker very quickly points out a problem (an unbound identifier).
No need to debug anything.

Incidentally, time and again people ask on the Caml list why 'let' in
OCaml is by default non-recursive. The common answer is that the
practitioners find in their experience the non-recursive let to be a
better default. Recursion should be intended and explicit -- more
errors are caught that way.

Let me finally disagree with the uniformity principle. It may be
uniform to have equi-recursive types. OCaml has equi-recursive types;
internally the type checker treats _all_ types as (potentially)
equi-recursive. At one point OCaml allowed equi-recursive types in
user programs as well. They were introduced for the sake of objects;
so the designers felt uniformly warrants to offer them in all
circumstances. The users vocally disagreed. Equi-recursive types mask
many common type errors, making them much more difficult to find. As
the result, OCaml developers broke the uniformity. Now, equi-recursive
types may only appear in surface programs in very specific
circumstances (where objects or their duals are involved). Basically,
the programmer must really intend to use them.

Here is an example from the natural language, English. Some verbs go from
regular (uniform conjugation) to irregular:
http://en.wiktionary.org/wiki/dive


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[Andreas Abel]

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)  = foo 1 [] in
 let (y,s2)  = bar x s1 in
 let (z,s3)  = baz x y s2 in ...


This isn't a case for non-recursive let.  It is one of the rare cases
where you might actually consider using a state monad.


Except when you are implementing the state monad (giggle):


http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#state


--
Andreas Abel  <><  Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Correct way to "catch all exceptions"

[Erik Hesselink]

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-recoverable: restarting whatever the thread was
doing is not the right thing to do.

Erik

On Wed, Jul 10, 2013 at 8:28 AM, Michael Snoyman  wrote:
> 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 perfectly valid, except that it catches a number of exceptions
> which seemingly should not be caught. In particular, it catches the async
> exceptions used by both killThread and timeout.
>
> I think it's fair to say that there's not going to be a single function that
> solves all cases correctly, but it is a common enough situation that people
> need to write code that resumes work in the case of an exception that I
> think we need to either have some guidelines for the right approach here, or
> perhaps even a utility function along the lines of:
>
> 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 to take here?
>
> ___
> 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] Correct way to "catch all exceptions"

[John Lato]

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 suggestion a lot, however it seems a bit more invasive.
 If we want to do that work, we could also restructure the wired-in
exceptions so they're more hierarchical.  There are some top-level
exceptions we can get by type, such as ArithException, but sadly many
interesting and useful exceptions are lumped together under IOException.


On Wed, Jul 10, 2013 at 4:29 PM, Ertugrul Söylemez  wrote:

> 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 to take here?
>
> I think there is no one right approach.  However, if you add such a
> function to the exception library, it really belongs into the Exception
> type class with the following type:
>
> shouldBeCaught :: (Exception e) => e -> Bool
>
> However, a better approach is to have exception tags.  In most cases you
> don't want to catch killThread's or timeout's exception, but you do want
> to catch all error exceptions:
>
> data Tag = Error | Abort | TryAgain | {- ... -} | Other String
> deriving (Data, Eq, Ord, Read, Show, Typeable)
>
> instance IsString Tag where
> fromString t = Other t
>
> This could then manifest in the following two functions in the Exception
> type class:
>
> hasTag :: (Exception e) => Tag -> e -> Bool
> tagsOf :: (Exception e) => e -> [Tag]
>
> Then exception catchers (functions that risk swallowing important
> exceptions) could filter by type and tag.
>
>
> Greets,
> Ertugrul
>
> --
> Not to be or to be and (not to be or to be and (not to be or to be and
> (not to be or to be and ... that is the list monad.
>
> ___
> 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] Correct way to "catch all exceptions"

[Ertugrul Söylemez]

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 to take here?

I think there is no one right approach.  However, if you add such a
function to the exception library, it really belongs into the Exception
type class with the following type:

shouldBeCaught :: (Exception e) => e -> Bool

However, a better approach is to have exception tags.  In most cases you
don't want to catch killThread's or timeout's exception, but you do want
to catch all error exceptions:

data Tag = Error | Abort | TryAgain | {- ... -} | Other String
deriving (Data, Eq, Ord, Read, Show, Typeable)

instance IsString Tag where
fromString t = Other t

This could then manifest in the following two functions in the Exception
type class:

hasTag :: (Exception e) => Tag -> e -> Bool
tagsOf :: (Exception e) => e -> [Tag]

Then exception catchers (functions that risk swallowing important
exceptions) could filter by type and tag.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[Ertugrul Söylemez]

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
> let (z,s3)  = baz x y s2 in ...

This isn't a case for non-recursive let.  It is one of the rare cases
where you might actually consider using a state monad.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[Edward Z. Yang]

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 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.

Clearly this will not work in all cases, but it goes pretty far,
in my experience.

Edward

Excerpts from Andreas Abel's message of Wed Jul 10 00:47:48 -0700 2013:
> 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 
> sometimes now.
> 
> Cheers,
> Andreas
> 
> On 10.07.2013 09:34, o...@okmij.org wrote:
> > 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) 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
> >  let (z,s3)  = baz x y s2 in ...
> >
> > and re-number them if I insert a new statement. BASIC comes to mind. I
> > tried to lobby Simon Peyton-Jones for the non-recursive let a couple
> > of years ago. He said, write a proposal. It's still being
> > written... Perhaps you might want to write it now.
> >
> > In the meanwhile, there is a very ugly workaround:
> >
> >  test = runIdentity $ do
> >   (x,s) <- return $ foo 1 []
> >   (y,s) <- return $ bar x s
> >   (z,s) <- return $ baz x y s
> >   return (z,s)
> >
> > After all, bind is non-recursive let.
> >
> >
> >
> 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[Andreas Abel]

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 
sometimes now.


Cheers,
Andreas

On 10.07.2013 09:34, o...@okmij.org wrote:

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) 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
 let (z,s3)  = baz x y s2 in ...

and re-number them if I insert a new statement. BASIC comes to mind. I
tried to lobby Simon Peyton-Jones for the non-recursive let a couple
of years ago. He said, write a proposal. It's still being
written... Perhaps you might want to write it now.

In the meanwhile, there is a very ugly workaround:

 test = runIdentity $ do
  (x,s) <- return $ foo 1 []
  (y,s) <- return $ bar x s
  (z,s) <- return $ baz x y s
  return (z,s)

After all, bind is non-recursive let.






--
Andreas Abel  <><  Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.a...@ifi.lmu.de
http://www2.tcs.ifi.lmu.de/~abel/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Non-recursive let [Was: GHC bug? Let with guards loops]

[oleg]

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) 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
let (z,s3)  = baz x y s2 in ...

and re-number them if I insert a new statement. BASIC comes to mind. I
tried to lobby Simon Peyton-Jones for the non-recursive let a couple
of years ago. He said, write a proposal. It's still being
written... Perhaps you might want to write it now.

In the meanwhile, there is a very ugly workaround:

test = runIdentity $ do
 (x,s) <- return $ foo 1 []
 (y,s) <- return $ bar x s
 (z,s) <- return $ baz x y s
 return (z,s)

After all, bind is non-recursive let.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[Bas van Dijk]

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-bytestring
>
>
> That's interesting Bas. What bothers me about ByteStrings is that they need
> to be "pinned" inside the heap,
> preventing the GC from collecting them.

Being "pinned" doesn't prevent an object from being garbage collected.
It just means that the GC won't move the object around so that foreign
code can reliably reference the object while the GC is running:

http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned

> I assume that working with vector remove the problem, correct?

There wasn't a problem in the first but note that a Storable Vector is
implemented in the same way as a ByteString: a ForeignPtr and a
length*

I hope I have now improved your sleep quality ;-)

Cheers,

Bas

* A ByteString also contains an offset but vector modifies the pointer
in the ForeignPtr instead so we safe an Int there.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Array, Vector, Bytestring

[Alfredo Di Napoli]

> 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 ByteStrings is that they need
to be "pinned" inside the heap,
preventing the GC from collecting them. This is more than an issue, I
think, if a program uses them massively
and they needs to be allocated persistently (example: a long-life
constant). I know is still a marginal case, but
knowing that a part of my heap is pinned makes my sleep quality degrade :(
I assume that working with vector remove the problem, correct?

A.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe