> -- Původní zpráva --
> Od: Corentin Dupont
> Datum: 25. 12. 2012
> Předmět: Re: [Haskell-cafe] multi-thread and lazy evaluation
>
> "
>
> Great, with me compiled with ghc -threaded the bug shows up.
>
> However, runnning "main" in ghci do
aviour has been confirmed?
Tim
-- Původní zpráva --
Od: Corentin Dupont
Datum: 25. 12. 2012
Předmět: Re: [Haskell-cafe] multi-thread and lazy evaluation
"
Great, with me compiled with ghc -threaded the bug shows up.
However, runnning "main" in ghci doesn't show t
. I've
> narrowed this down and filed a bug report here:
>
> http://hackage.haskell.org/trac/ghc/ticket/7528
>
> Timothy
>
> -- Původní zpráva --
> Od: Yuras Shumovich
>
> Datum: 24. 12. 2012
> Předmět: Re: [Haskell-cafe] multi-thread and
Hi Brandon,
indeed in my example if you add:
*b <- evaluate a*
after the definition of "a" it works.
However, in my original program it doesn't work, I suppose because I
interpret the user submitted code (here "*let (a::String) = a" *
for the example) via Hint and Hint-server, and the interpretati
multi-thread and lazy evaluation
"On Mon, 2012-12-24 at 16:16 +0100, timothyho...@seznam.cz wrote:
> The real question is, does this mean that GHC is stopping the world every
> time it puts an MVar?
No, GHC rts only locks the MVar itself.
See here:
http://hackage.haskell.org/trac
On Mon, 2012-12-24 at 16:16 +0100, timothyho...@seznam.cz wrote:
> The real question is, does this mean that GHC is stopping the world every
> time it puts an MVar?
No, GHC rts only locks the MVar itself.
See here:
http://hackage.haskell.org/trac/ghc/browser/rts/PrimOps.cmm#L1358
Yuras
___
The real question is, does this mean that GHC is stopping the world every
time it puts an MVar?
Tim
-- Původní zpráva --
Od: Brandon Allbery
Datum: 24. 12. 2012
Předmět: Re: [Haskell-cafe] multi-thread and lazy evaluation
"
On Mon, Dec 24, 2012 at 8:45 AM, Corentin D
On Mon, Dec 24, 2012 at 8:45 AM, Corentin Dupont
wrote:
> *execBlocking :: MVar (Maybe MyData) -> IO ()
> execBlocking mv = do
>let (a::String) = a
>--If you uncomment the next line, it will work
>--putStrLn $ show a
>putMVar mv (Just $ MyData a "toto")*
>
It's laziness, yes; you
Hint. The user-submitted programs are used to modify
> a state held in a TVar.
> As of course those user-submitted programs can't be trusted, I'm trying to
> protect them, like in Mueval.
> I installed a watchdog to monitor and kill the user's thread if it doesn't
&g
installed a watchdog to monitor and kill the user's thread if it doesn't
finish. However it doesn't work properly, due to lazy evaluation I believe.
I made a little exemple to illustrate the problem.
-> The following program doesn't terminate, but if you uncomment the
&quo
Hello Haskellers!
I wonder if you know of benchmarks that attempt to compare,
empirically, lazy vs. eager evaluation. Pointers to papers and/or
code would be most appreciated.
Our group (at UMD) is working on a paper that develops some technology
for lazy programs, and we would like to choose be
in the mean time I suggest using Hmatrix then :)
On Wed, Sep 5, 2012 at 4:10 PM, KC wrote:
> The REPA package/library doesn't have LU factorization, eigenvalues, etc.
>
>
> On Wed, Sep 5, 2012 at 12:59 PM, Carter Schonwald
> wrote:
> > Hello KC,
> > you should check out the Repa library then an
The REPA package/library doesn't have LU factorization, eigenvalues, etc.
On Wed, Sep 5, 2012 at 12:59 PM, Carter Schonwald
wrote:
> Hello KC,
> you should check out the Repa library then and see how it works for you.
> Cheers
> -Carter
>
> On Wed, Sep 5, 2012 at 12:46 PM, KC wrote:
>>
>> separ
Hello KC,
you should check out the Repa library then and see how it works for you.
Cheers
-Carter
On Wed, Sep 5, 2012 at 12:46 PM, KC wrote:
> separates control from computation.
>
> It seems as if Haskell would be better for iterative matrix methods
> rather than direct calculation.
>
> --
> --
separates control from computation.
It seems as if Haskell would be better for iterative matrix methods
rather than direct calculation.
--
--
Regards,
KC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/ha
On a tangent, not doing IO, but food for thought:
{-# LANGUAGE FlexibleContexts #-}
import Control.Monad.State.Lazy as N
import Control.Monad.State.Strict as S
gen :: (MonadState [()] m) => m ()
gen = do
gen
modify (() :)
many = take 3 (N.execState gen [])
none = take 3 (S.execState gen []
On Tue, May 31, 2011 at 6:10 PM, Antoine Latter wrote:
>
> You could use a different type:
>
>> type IOStream a = (a, IO (IOStream a))
>
>> unfold :: ([a] -> IO a) -> IO (IOStream a)
>> unfold f =
>> let go prev = do
>> next <- f prev
>> return (next, go (next:prev))
>>
On Tue, May 31, 2011 at 2:49 PM, Scott Lawrence wrote:
> I was under the impression that operations performed in monads (in this
> case, the IO monad) were lazy. (Certainly, every time I make the
> opposite assumption, my code fails :P .) Which doesn't explain why the
> following code fails to ter
Apparently:
Prelude> let r = (fmap (1:) r) :: IO [Integer]
Prelude> fmap (take 5) r
*** Exception: stack overflow
Thanks - I'll just have to stay out of IO for this, then.
On Tue, May 31, 2011 at 17:05, Stephen Tetley wrote:
> 2011/5/31 Scott Lawrence :
>
>> Evaluation here also doesn't termina
2011/5/31 Scott Lawrence :
> Evaluation here also doesn't terminate (or, (head $ unfoldM (return .
> head)) doesn't), although I can't figure out why. fmap shouldn't need to
> fully evaluate a list to prepend an element, right?
I'm afriad fmap doesn't get to choose - if the monad is strict then
b
On Tuesday 31 May 2011 22:35:26, Yves Parès wrote:
> He intended to show that, indeed, it is not, or else side-effects would
> never be performed
On the other hand, IO is lazy in the values it produces.
Going with the IO a = State RealWorld a fiction, IO is state-strict but
value-lazy. The side-e
On 05/31/2011 04:48 PM, Artyom Kazak wrote:
>
> Oh, sorry. I was unclear. I have meant "assuming IO is lazy", as Yves
> wrote.
Ah, ok. That makes more sense.
>
> And saying "some hacks" I meant unsafeInterleaveIO, which lies beneath
> the laziness of, for example, getContents.
Which explains w
On 5/31/11 12:49 PM, Scott Lawrence wrote:
I was under the impression that operations performed in monads (in this
case, the IO monad) were lazy.
Whether they are lazy or not depends entirely on the definition of the
monad. For example, if you look up the ST and State monads you will
find th
Scott Lawrence писал(а) в своём письме Tue, 31 May 2011
23:29:49 +0300:
On 05/31/2011 04:20 PM, Artyom Kazak wrote:
Suppose iRecurse looks like this:
iRecurse = do
x <- launchMissiles
r <- iRecurse
return 1
As x is never needed, launchMissiles will never execute. It obviously
No, I think Artyom meant "assuming IO is lazy".
He intended to show that, indeed, it is not, or else side-effects would
never be performed
2011/5/31 Scott Lawrence
> On 05/31/2011 04:20 PM, Artyom Kazak wrote:
> > Suppose iRecurse looks like this:
> > iRecurse = do
> > x <- launchMissiles
On Tue, May 31, 2011 at 3:49 PM, Scott Lawrence wrote:
> I was under the impression that operations performed in monads (in this
> case, the IO monad) were lazy. (Certainly, every time I make the
> opposite assumption, my code fails :P .) Which doesn't explain why the
> following code fails to ter
On 05/31/2011 04:20 PM, Artyom Kazak wrote:
> Suppose iRecurse looks like this:
> iRecurse = do
> x <- launchMissiles
> r <- iRecurse
> return 1
>
> As x is never needed, launchMissiles will never execute. It obviously is
> not what is needed.
Prelude> let launchMissiles = putStrLn
Suppose iRecurse looks like this:
iRecurse = do
x <- launchMissiles
r <- iRecurse
return 1
As x is never needed, launchMissiles will never execute. It obviously is
not what is needed.
But in Haskell, standart file input|output is often lazy. It's a
combination of buffering and
I was under the impression that operations performed in monads (in this
case, the IO monad) were lazy. (Certainly, every time I make the
opposite assumption, my code fails :P .) Which doesn't explain why the
following code fails to terminate:
iRecurse :: (Num a) => IO a
iRecurse = do
recur
On Thursday 17 March 2011 13:05:33, Tillmann Rendel wrote:
> Looks like I need an email client with ghc integration.
That would be awesome.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi,
Daniel Fischer wrote:
Let's look at the following code:
countdown n = if n == 0 then 0 else foo (n - 1)
s/foo/countdown/
presumably
if' c t e = if c then t else e
countdown' n = if' (n == 0) 0 (foo (n - 1))
s/foo/countdown'/
Yes to both substitutions. Looks like I need
On Wednesday 16 March 2011 22:03:51, Yves Parès wrote:
> Can a type signature give you a hint about whether a function evaluates
> some/all of its arguments (i.e. is strict/partially strict/lazy), or do
> you have to look at the implementation to know?
Cheating, with GHC, a magic hash tells you it
On Wednesday 16 March 2011 21:44:36, Tillmann Rendel wrote:
> My point is that the call to map is in tail position, because it is
> the last thing the function (\_ -> map f xs ()) does. So it is not a
> tail-recursive call, but it is a tail call.
Mmmm, okay, minor terminology mismatch, then. M
> And that's what, to my knowledge, is impossible with tail recursion. A
tail
> recursive map/fmap would have to traverse the entire list before it could
return anything.
Now that you say it, yes, you are right. Tail recursion imposes strictness,
since only the very last call can return something
Hi,
Daniel Fischer wrote:
data EvaluatedList a
= Cons a (List a)
| Empty
type List a
= () -> EvaluatedList a
map :: (a -> b) -> (List a -> List b)
map f xs
= \_ -> case xs () of
Cons x xs -> Cons (f x) (\_ -> map f xs ())
On Wednesday 16 March 2011 20:02:54, Yves Parès wrote:
> > Yes, and a tail-recursive map couldn't run in constant space
>
> Yes, I meant "if you are consuming it just once immediately".
>
And that's what, to my knowledge, is impossible with tail recursion. A tail
recursive map/fmap would have t
On Wed, 16 Mar 2011, Daniel Fischer wrote:
Tail recursion is good for strict stuff, otherwise the above pattern - I
think it's called guarded recursion - is better, have the recursive call as
a non-strict field of a constructor.
In
http://haskell.org/haskellwiki/Tail_recursion
it is also
2011/3/16 Daniel Fischer
> On Wednesday 16 March 2011 18:31:00, Yves Parès wrote:
> > Hello,
> >
> > A question recently popped into my mind: does lazy evaluation reduce the
> > need to "proper" tail-recursion?
> > I mean, for instance :
> >
>
On Wednesday 16 March 2011 18:31:00, Yves Parès wrote:
> Hello,
>
> A question recently popped into my mind: does lazy evaluation reduce the
> need to "proper" tail-recursion?
> I mean, for instance :
>
> fmap f [] = []
> fmap f (x:xs) = f x : fmap f xs
>
&
Hi,
Yves Parès wrote:
A question recently popped into my mind: does lazy evaluation reduce the
need to "proper" tail-recursion?
I mean, for instance :
fmap f [] = []
fmap f (x:xs) = f x : fmap f xs
Here fmap is not tail-recursive, but thanks to the fact that operator (:) is
lazy, I
Hello,
A question recently popped into my mind: does lazy evaluation reduce the
need to "proper" tail-recursion?
I mean, for instance :
fmap f [] = []
fmap f (x:xs) = f x : fmap f xs
Here fmap is not tail-recursive, but thanks to the fact that operator (:) is
lazy, I think that it may
> Have you seen Potential
> (http://intoverflow.wordpress.com/2010/05/21/announcing-potential-x86-64-assembler-as-a-haskell-edsl/)?
> Quote:
>
> "The language’s goal is to provide a solid foundation for the development of
> a useful (multi-tasked, multi-processor, etc) microkernel"
>
> Which sounds
On 06/10/10 11:00, C K Kashyap wrote:
My ultimate aim it to
write an EDSL for x86 - as in, describe a micro-kernel in haskell,
compiling and running which would generate C code ( not sure if it's
even possible - but I am really hopeful).
Have you seen Potential
(http://intoverflow.wordpress.
On Tue, Oct 5, 2010 at 9:19 PM, steffen wrote:
> Don't be to disappointed. One can always kinda fake lazy evaluation
> using mutable cells.
> But not that elegantly. In the example given above, all being used is
> iterators as streams... this can also be expressed using lazy l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/5/10 10:52 , C K Kashyap wrote:
> And I had built up this impression that laziness distinguished Haskell
> by a huge margin ... but it seems that is not the case.
> Hence the disappointment.
Haskell is lazy-by-default and designed ar
Don't be to disappointed. One can always kinda fake lazy evaluation
using mutable cells.
But not that elegantly. In the example given above, all being used is
iterators as streams... this can also be expressed using lazy lists,
true. But one big difference between e.g. lazy lists and iterato
ment was not on a serious note ... the thing is, I
> constantly run into discussions about "why fp" with my colleagues - in
> a few of such discussions, I had mentioned that Haskell is the only
> well known language with lazy evaluation (IIRC, I read it somewhere or
> heard it in
, I
constantly run into discussions
about "why fp" with my colleagues - in a few of such discussions, I
had mentioned that Haskell is the
only well known language with lazy evaluation (IIRC, I read it
somewhere or heard it in one of the videos)
And I had built up this impression that la
>
> I see ... I think I understand now.
> hmmm ... I am little disappointed though - does that mean that "all
> the laziness" cool stuffs can actually be done using
> iterators(generators)?
> As in, but for the inconvenient syntax, you can do it all in - say java?
Yes. It would slightly easier in
= nextVal
> > }
> > }
> >
> > I have not tested it but I think this is a fair translation of the code.
> > (For instance, by using an appropriate implementation of IBoundsCheck, I
> > will be able to implement the 'relativeSqrt' functionality of
de.
> (For instance, by using an appropriate implementation of IBoundsCheck, I
> will be able to implement the 'relativeSqrt' functionality of the example).
> But this IS still a lazy evaluation. By passing an iterator instead of a
> list as the third argument of the static method, I a
will be able to implement the 'relativeSqrt' functionality of the example).
But this IS still a lazy evaluation. By passing an iterator instead of a
list as the third argument of the static method, I achieved 'laziness'.
In the example, the laziness is in the way we are iterati
Hi All,
I was going through the paper's "lazy evaluation" section where the
square root example is given. It occurred to me that one could
implement it in a modular way with just higher order functions
(without the need for lazy evaluation that is).
function f (within, eps, next
On Sunday 27. December 2009 14.16.15 michael rice wrote:
> I've seen the terms "lazy evaluation" and "lazy function." Is this just
> lazy language or are both these terms valid?
In some languages, like Oz, one can have lazy functions even though the
default is
Lazy evaluation is an evaluation strategy that gives non-strict semantics.
A lazy function I'm not sure how to define. It may be lazy language meaning
a function which is non-strict in one of it's arguments.
Bob
On Sun, Dec 27, 2009 at 1:16 PM, michael rice wrote:
> I've se
I've seen the terms "lazy evaluation" and "lazy function." Is this just lazy
language or are both these terms valid?
Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Tue, 2009-02-10 at 08:03 +0100, Thomas Davie wrote:
> On 10 Feb 2009, at 07:57, Max Rabkin wrote:
>
> > On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki
> > wrote:
> >> I 0 * _ = I 0
> >> I x * I y = I (x * y)
> >
> > Note that (*) is now non-commutative (w.r.t. _|_). Of course, that'
On 10 Feb 2009, at 07:57, Max Rabkin wrote:
On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki
wrote:
I 0 * _ = I 0
I x * I y = I (x * y)
Note that (*) is now non-commutative (w.r.t. _|_). Of course, that's
what we need here, but it means that the "obviously correct"
transformation o
On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki
wrote:
> I 0 * _ = I 0
> I x * I y = I (x * y)
Note that (*) is now non-commutative (w.r.t. _|_). Of course, that's
what we need here, but it means that the "obviously correct"
transformation of
> foo x = if x == 0 then 0 else foo (x -
Hi,
Just for fun, here is the code that does this:
newtype Int' = I Int deriving Eq
instance Show Int' where
show (I x) = show x
instance Num Int' where
I x + I y = I (x + y)
I 0 * _ = I 0
I x * I y = I (x * y)
I x - I y = I (x - y)
abs (I x) = I (abs x)
s
Peter Padawitz wrote:
> A simplied version of Example 5-16 in Manna's classical book
> "Mathematical Theory of Computation":
>
> foo x = if x == 0 then 0 else foo (x-1)*foo (x+1)
>
> If run with ghci, foo 5 does not terminate, i.e., Haskell does not look
> for all outermost redices in parallel. Why
On Mon, 09 Feb 2009 15:10:22 +0100
Peter Padawitz wrote:
> A simplied version of Example 5-16 in Manna's classical book
> "Mathematical Theory of Computation":
>
> foo x = if x == 0 then 0 else foo (x-1)*foo (x+1)
>
> If run with ghci, foo 5 does not terminate, i.e., Haskell does not
> look fo
Hello Peter,
Monday, February 9, 2009, 5:10:22 PM, you wrote:
> If run with ghci, foo 5 does not terminate, i.e., Haskell does not look
> for all outermost redices in parallel. Why? For efficiency reasons?
of course. if you will create new thread for every cpu instruction
executed, you will defi
A simplied version of Example 5-16 in Manna's classical book
"Mathematical Theory of Computation":
foo x = if x == 0 then 0 else foo (x-1)*foo (x+1)
If run with ghci, foo 5 does not terminate, i.e., Haskell does not look
for all outermost redices in parallel. Why? For efficiency reasons?
It'
Just use 'rnf', from the Control.Parallel namespace.
ryani.spam:
> This is the classic "exception embedded in pure value" problem with
> lazy languages. There's no need for the "a" returned by "return" to
> be evaluated.
>
> Even using "seq" isn't quite good enough:
>
> > boom2 = [1 `div` 0]
>
This is the classic "exception embedded in pure value" problem with
lazy languages. There's no need for the "a" returned by "return" to
be evaluated.
Even using "seq" isn't quite good enough:
> boom2 = [1 `div` 0]
ghci> doTinIO (boom2 `seq` return boom2)
Right [*** Exception: divide by zero
If
On 2008 Jul 7, at 11:14, Tim Bauer wrote:
My problem is that I control `doTinIO', but someone else provides
the computation (T a). I cannot force callers to strictly evaluate
their computations.
try (Control.Exception.evaluate ...) -- ?
--
brandon s. allbery [solaris,freebsd,perl,pugs,haske
The file below models a problem I have been trying to figure out.
This file simplifies my original code, while still illustrating
the problem.
> import Prelude hiding (catch)
> import Control.Monad.Reader
> import Control.Monad.Error
> import Control.Exception
> import System.IO(readFile)
> impor
@ Miguel: Thanks for carrying out the fixpoint computation I was too
lazy to do! I see: lazy evaluation programmers must not be lazy ;-)
@ Josef: Oh yes, I mixed up x and y! In fact, I was confused about the
semantical difference between eqrev and eqrev', although eqrev is just
an iter
On Feb 6, 2008 3:06 PM, Miguel Mitrofanov <[EMAIL PROTECTED]> wrote:
>
> On 6 Feb 2008, at 16:32, Peter Padawitz wrote:
>
> > Can anybody give me a simple explanation why the second definition
> > of a palindrome checker does not terminate, although the first one
> > does?
> >
> > pal :: Eq a => [a
On 6 Feb 2008, at 16:32, Peter Padawitz wrote:
Can anybody give me a simple explanation why the second definition
of a palindrome checker does not terminate, although the first one
does?
pal :: Eq a => [a] -> Bool
pal s = b where (b,r) = eqrev s r []
eqrev :: Eq a => [a] -> [a] -> [a] ->
On Wed, 6 Feb 2008, Peter Padawitz wrote:
> Can anybody give me a simple explanation why the second definition of a
> palindrome checker does not terminate, although the first one does?
Just another question, what about
x == reverse x
? - You can still optimize for avoiding duplicate equalit
Can anybody give me a simple explanation why the second definition of a
palindrome checker does not terminate, although the first one does?
pal :: Eq a => [a] -> Bool
pal s = b where (b,r) = eqrev s r []
eqrev :: Eq a => [a] -> [a] -> [a] -> (Bool,[a])
eqrev (x:s1) ~(y:s2) acc = (x==y&&b,r) whe
Ronald Guida wrote:
> Can anyone tell me if I've got this right?
Yes, you got. The let-statement you introduce that embodies the sharing
of the argument n = 12 probably should be present in the first parts,
too. But this doesn't really matter, the formalities of graph reduction
vary with the
I'm trying to understand lazy evaluation as well. I created an
example for myself and I'm wondering if I've got it right.
> let adder n = \x -> n + x in (map (adder 12) [1,2,3]) !! 1
So the first thing I did is draw a graph to represent my expression.
(map (ad
Stefan O'Rear <[EMAIL PROTECTED]> writes:
> Indeed, you've caught on an important technical distinction.
>
> Lazy: Always evaluating left-outermost-first.
I think most people would rather use the term "normal order¨
for that; lazy means evaluating in normal order /and/ not
evaluating the same ex
Stefan O'Rear wrote:
> As is usual for mathematical things, there are many equivalent
> definitions. My two favorites are:
>
> 1. Normal order reduction
>
> In the λ-calculus, lazy evaluation can be defined as the (unique up to
> always giving the same answer) evaluat
Hello Xavier,
Thursday, August 23, 2007, 3:08:25 AM, you wrote:
> I am learning Haskell with "Programming in Haskell" (an excellent
> book BTW).
scheme of lazy evaluation called "graph reduction"
you may consider it as repetitive replacing right parts of function
d
On Thu, Aug 23, 2007 at 10:00:00AM +0200, Xavier Noria wrote:
> You people rock. Responses were really helpful and I understand how the
> computation goes now.
>
> I see I need to reprogram my eyes to expect lazy evaluation in places where
> I am used to one-shot results. I see
You people rock. Responses were really helpful and I understand how
the computation goes now.
I see I need to reprogram my eyes to expect lazy evaluation in places
where I am used to one-shot results. I see lazy evaluation is all
around in Haskell builtins.
From a formal point of view
) = x == y && xs == ys
[] == [] = True
_ == _ = False
All other functions used are primitives.
Exercise: Write out a full execution trace for n == 3 and n == 4 with the
desugaring and Prelude functions given above.
On 8/22/07, Xavier Noria <[EMAIL PROTECTED]> wrote:
>
> I am learn
>
> > [*] Which notation do you use for functions in text? is f() ok?
>
> Sure, although a little unusual for Haskell where f() means f applied
> to the empty tuple. Some people use |f| (generally those who use
> latex), but generally it can be inferred from the context what is a
> function
Nei
.
Hughes' paper "Why Functional Programming Matters" is a must-read for more on
this.
Lazy evaluation can be very tricky to wrap your head around, and there are lots
of subtle issues
that crop up where you think something is lazy but it's not, or you think
something is strict but
particular evaluation of
> factors, in particular step puzzles me. Can anyone explain how lazy
> evaluation fits there? I suspect the key is the implementation of ==
> together with the fact that list comprehensions are lazy themselves,
> is that right?
Everything is lazy, to all subparts
I am learning Haskell with "Programming in Haskell" (an excellent
book BTW).
I have background in several languages but none of them has lazy
evaluation. By now I am getting along with the intuitive idea that
things are not evaluated until needed, but there's an
On Tue, 27 Feb 2007, Chris Kuklewicz wrote:
> For an infinite number of equations you have to generate them as data at run
> time. Your notation above only works for a finite set of equations known at
> compile time.
>
> So you have a stream of equations, and each equation depends on some subset
Nothing, Nothing, Nothing, Just 1, ...
y = [Nothing, Nothing, Just 2, ...
z = [Nothing, Just 3, ...
@
Features:
* free choice of types of values and static type checking
* free choice of rules
* lazy evaluation of solutions,
thus infinitely many variables and rules are possible
(alth
- times 2 x2 x3
> ...
>
> Accessing variable values by integer identifiers means that the garbage
> collector cannot free values that are no longer needed.
That will always be true for potentially non-finite lists of equations.
>
> Thus I thought about how to solve the equations
On Tue, 27 Feb 2007, Ulf Norell wrote:
> On 2/27/07, Henning Thielemann <[EMAIL PROTECTED]> wrote:
> >
> > I suspect that someone has already done this: A Haskell library which
> > solves a system of simple equations, where it is only necessary to derive
> > a value from an equation where all but
On 2/27/07, Henning Thielemann <[EMAIL PROTECTED]> wrote:
I suspect that someone has already done this: A Haskell library which
solves a system of simple equations, where it is only necessary to derive
a value from an equation where all but one variables are determined. Say
You might want to c
.
Thus I thought about how to solve the equations by lazy evaluation. Maybe
it is possible to ty the knot this way
let (_,_,x0) = add 1 2 x
(y0,z0,_) = times y z 20
(x1,y1,_) = add x y 5
x = alternatives [x0,x1]
y = alternatives [y0,y1]
z = alternatives [z0]
in (solve x, solve y
Andrew Wagner wrote:
> Hi all,
>
> An interesting question came up in #haskell the other day, and I took
> the resulting discussion and wrapped it up into a simple tutorial for
> the wiki. Since I'm quite a newbie to haskell myself, I'd appreciate
> any double-checking of my logic and, of course,
Hi all,
An interesting question came up in #haskell the other day, and I took
the resulting discussion and wrapped it up into a simple tutorial for
the wiki. Since I'm quite a newbie to haskell myself, I'd appreciate
any double-checking of my logic and, of course, any other
comments/suggestions.
Hi
On 9/6/06, David Roundy <[EMAIL PROTECTED]> wrote:
Fortunately, the undefined behavior in this case is unrelated to the
lazy IO. On windows, the removal of the file will fail, while on
posix systems there won't be any failure at all. The same behavior
would show up if you opened the file fo
On Fri, Sep 01, 2006 at 11:47:20PM +0100, Duncan Coutts wrote:
> On Fri, 2006-09-01 at 17:36 -0400, Robert Dockins wrote:
> > Well, AFAIK, the behavior is officially undefined, which is my
> > real beef. I agree that it _should_ throw an exception.
>
> Ah, I had thought it was defined to simply t
Quoth Julien Oster <[EMAIL PROTECTED]>:
...
| But what happens when two processes use the same file and one process is
| writing into it using lazy IO which didn't happen yet? The other process
| wouldn't see its changes yet.
That's actually a much more general problem, one that I imagine applies
Duncan Coutts wrote:
Hi,
> In practise I expect that most programs that deal with file IO strictly
> do not handle the file disappearing under them very well either. At best
> the probably throw an exception and let something else clean up.
And at least in Unix world, they just don't disappear.
On Fri, 2006-09-01 at 17:36 -0400, Robert Dockins wrote:
> Perhaps I should be more clear. When I said "advanced" above I meant "any
> use
> whereby you treat a file as random access, read/write storage, or do any kind
> of directory manipulation (including deleting and or renaming files)". L
On Friday 01 September 2006 18:01, Donn Cave wrote:
> On Fri, 1 Sep 2006, Robert Dockins wrote:
> > On Friday 01 September 2006 16:46, Duncan Coutts wrote:
>
> ...
>
> >> Note also, that with lazy IO we can write really short programs that are
> >> blindingly quick. Lazy IO allows us to save a copy
On Fri, 1 Sep 2006, Robert Dockins wrote:
> On Friday 01 September 2006 16:46, Duncan Coutts wrote:
...
>> Note also, that with lazy IO we can write really short programs that are
>> blindingly quick. Lazy IO allows us to save a copy through the Handle
>> buffer.
(Never understood why some people
1 - 100 of 112 matches
Mail list logo
