On Wed, Sep 1, 2010 at 1:00 PM, Daniel Fischer daniel.is.fisc...@web.dewrote:
I'm not keen on subscribing to libraries@ to follow the official proposal
process, any takers?
I'll take it up.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On Tue, 03 Aug 2010 16:36:33 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
- If there is no class instance for function types, then those problems
go away, of course. But it is doubtful whether that would be a viable
solution. Quite a few programs
Nicolas Pouillard schrieb:
Actually I think we can keep the old generic seq, but cutting its full
polymorphism:
seq :: Typeable a = a - b - b
I guess I don't know enough about Typeable to appreciate that.
Basically the Typeable constraints tells that we dynamically know the identity
of the
On Wed, 04 Aug 2010 15:41:54 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
Actually I think we can keep the old generic seq, but cutting its full
polymorphism:
seq :: Typeable a = a - b - b
I guess I don't know enough about Typeable to
Nicolas Pouillard schrieb:
However the rule is still the same when using an unsafe function you are on
your own.
Clearer?
Almost. What I am missing is whether or not you would then consider your
genericSeq (which is applicable to functions) one of those unsafe
functions or not.
Ciao,
Janis.
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
However the rule is still the same when using an unsafe function you are on
your own.
Clearer?
Almost. What I am missing is whether or not you would then consider your
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
However the rule is still the same when using an unsafe function you are on
your own.
Clearer?
Almost. What I am missing is whether or not you would
On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
However the rule is still the same when using an unsafe
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
However the rule is still the
On Wed, 04 Aug 2010 18:04:13 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:47:12 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Nicolas Pouillard schrieb:
On Wed, 04 Aug 2010 17:27:01 +0200, Janis Voigtländer
Nicolas Pouillard schrieb:
Right let's make it more explicit, I actually just wrote a Control.Seq
module and a test file:
module Control.Seq where
genericSeq :: Typeable a = a - b - b
genericSeq = Prelude.seq
class Seq a where
seq :: a - b - b
instance (Typeable a,
On Mon, 02 Aug 2010 17:41:02 +0200, Janis Voigtländer
j...@informatik.uni-bonn.de wrote:
Hi,
I am late to reply in this thread, but as I see Stefan has already made
what (also from my view) are the main points:
- Putting seq in a type class makes type signatures more verbose, which
one
Nicolas,
OK, I better understand now where we disagree. You want to see in the type
whether or not the free theorem apply, I want them to always apply when
no call to unsafe function is made.
Implementing your suggestion would make me feel uncomfortable. Turning seq into
an unsafe operations
Nicolas Pouillard schrieb:
- If there is no class instance for function types, then those problems
go away, of course. But it is doubtful whether that would be a viable
solution. Quite a few programs would be rejected as a consequence. (Say,
you want to use the strict version of foldl. That will
Hi again,
Maybe I should add that, maybe disappointingly, I do not even have a
strong opinion about whether seq should be in Haskell or not, and in
what form. Let me quote the last paragraph of an extended version of our
paper referred to earlier:
Finally, a natural question is whether or not
On Tue, 3 Aug 2010 16:24:54 +0200, Stefan Holdermans ste...@vectorfabrics.com
wrote:
Nicolas,
OK, I better understand now where we disagree. You want to see in the type
whether or not the free theorem apply, I want them to always apply when
no call to unsafe function is made.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/3/10 10:24 , Stefan Holdermans wrote:
Implementing your suggestion would make me feel uncomfortable. Turning seq
into an unsafe operations effectively places it outside the language, like
unsafePerformIO isn't really part of the language (in
Hi,
I am late to reply in this thread, but as I see Stefan has already made
what (also from my view) are the main points:
- Putting seq in a type class makes type signatures more verbose, which
one may consider okay or not. In the past (and, as it seems, again in
every iteration of the language
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/2/10 11:41 , Janis Voigtländer wrote:
alright that we don't know more about where (==) is used. But for a
function of type f :: Eval (a - Int) = (a - Int) - (a - Int) -
Int, in connection with trying to find out whether uses of seq are
Brandon,
Hm. Seems to me that (with TypeFamilies and FlexibleContexts)
h :: (x ~ y, Eval (y - Int)) = (x - Int) - (y - Int) - Int
should do that, but ghci is telling me it isn't (substituting Eq for Eval
for the nonce):
Prelude let h :: (x ~ y, Eq (y - Int)) = (x - Int) - (y - Int) -
Brandon,
h :: (x ~ y, Eval (y - Int)) = (x - Int) - (y - Int) - Int
But actually if you push the constraint inward, into the type so to say, you
actually get quite close to Janis' and David's solution.
Sorry, I was thinking out loud there. I meant the Eval constraint, not the
equality
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/2/10 17:18 , Stefan Holdermans wrote:
Brandon,
h :: (x ~ y, Eval (y - Int)) = (x - Int) - (y - Int) - Int
But actually if you push the constraint inward, into the type so to say,
you actually get quite close to Janis' and David's
Brandon,
Sorry, I was thinking out loud there. I meant the Eval constraint, not the
equality constraint. But, right now, I guess my comment only makes sense to
me, so let's pretend I kept quiet. ;-)
The point of this discussion is that the Eval constraint needs to be on one
of the
Hi Daniel,
Thank you very much for the explanation of this issue.
While I understand the parts about rewrite rules and the big thunk, it
is still not clear why it is the way it is.
Please could you explain which Nums are not strict? The ones I am aware
about are all strict.
Also, why doesn't
On Tuesday 15 June 2010 16:52:04, Denys Rtveliashvili wrote:
Hi Daniel,
Thank you very much for the explanation of this issue.
While I understand the parts about rewrite rules and the big thunk, it
is still not clear why it is the way it is.
Please could you explain which Nums are not
On 14.06.10 17:25, Serge D. Mechveliani wrote:
lng [1 .. n] =
lng (1 : (list 2 n)) = 1 + (lng $ list 2 n) =
1 + (lng (2: (list 3 n))) = 1 + 1 + (lng $ list 3 n) = {- !!! -}
2 + (lng (3: (list 4 n))) -- because this + is of Integer
= 2 + 1 + (lng $ list 4 n) = {- !!! -}
3 + (lng $
On Monday 14 June 2010 16:25:06, Serge D. Mechveliani wrote:
Dear people and GHC team,
I have a naive question about the compiler and library of ghc-6.12.3.
Consider the program
import List (genericLength)
main = putStr $ shows (genericLength [1 .. n]) \n
where
n =
Marcin Kosiba wrote:
Hi,
To illustrate what I meant I'm attaching two examples. In example_1.py I've
written code the way I think would be elegant (but it doesn't work). In
example_2.py I've written code so that it works, but it isn't elegant.
I know I'm abusing Python iterators here. Also,
On Friday 10 July 2009, Gleb Alexeyev wrote:
Marcin Kosiba wrote:
Hi,
To illustrate what I meant I'm attaching two examples. In example_1.py
I've written code the way I think would be elegant (but it doesn't work).
In example_2.py I've written code so that it works, but it isn't
Achim Schneider wrote:
You don't come across space-leaks in strict programs often because
data is usually allocated statically even if execution is non-strict.
Piping /dev/zero into a program that just sleeps does leak space,
though.
It only leaks 8K or whatever size your system buffers
Albert Y. C. Lai [EMAIL PROTECTED] writes:
I haven't heard the terms laziness leak and strictness leak
before
Leak refers to a surprise.
I the meaning of leak is in a bit of flux. Originally, I believe it
refers to a memory leak, where the programmer forgot to call free()
before losing the
2008/6/4 apfelmus [EMAIL PROTECTED]:
[...]
But it can waste space (- space leak), for instance by
accumulating a big expression like
(..) - ((..)+1) - (((..) + 1) + 1) - etc.
instead of evaluating x+1 immediately
5 - 6- 7- etc.
So, it is called a space leak
Jules Bean [EMAIL PROTECTED] wrote:
Achim Schneider wrote:
You don't come across space-leaks in strict programs often because
data is usually allocated statically even if execution is
non-strict.
Piping /dev/zero into a program that just sleeps does leak space,
though.
It
Ketil Malde wrote:
I the meaning of leak is in a bit of flux. Originally, I believe
it refers to a memory leak, where the programmer forgot to call
free() before losing the pointer, thus making the program consume
memory it can't recover, and can't use.
With automatic memory management,
Achim Schneider wrote:
There won't ever be a space leak without a time leak nor a time leak
without a space leak. I'd just call it a leak.
Actually I think you can have a space leak without a time leak. For
instance if every time around the main loop I cons data onto a linked
list that
Paul Johnson [EMAIL PROTECTED] wrote:
Achim Schneider wrote:
There won't ever be a space leak without a time leak nor a time leak
without a space leak. I'd just call it a leak.
Actually I think you can have a space leak without a time leak. For
instance if every time around the main
Ronald Guida wrote:
So I just thought of something. If laziness leads to laziness leaks,
then is there such a thing as a strictness leak? I realized that the
answer is yes.
A lazy leak is a situation where I'm wasting resources to delay a
sequence of calculations instead of just doing them
apfelmus wrote:
I haven't heard the terms laziness leak and strictness leak before,
imho they sound a bit spooky because it's not clear to me what the
situation without leak would be. (Time vs Space? Is an O(n) algorithm a
strictness leak compared to an O(log n) algorithm?)
Leak refers to a
On 6/4/08, apfelmus [EMAIL PROTECTED] wrote:
Note that lazy evaluation never wastes time; evaluating a term with lazy
evaluation will always take less reduction steps than doing so eagerly or
partly eagerly.
True, but you can still have a time leak; this is particularily
relevant in
Ryan Ingram [EMAIL PROTECTED] wrote:
On 6/4/08, apfelmus [EMAIL PROTECTED] wrote:
Note that lazy evaluation never wastes time; evaluating a term with
lazy evaluation will always take less reduction steps than doing so
eagerly or partly eagerly.
True, but you can still have a time leak;
Scott Dillard wrote:
Simon, Don,
You're right. -fno-state-hack fixed it. I've opened a trac ticket.
Program and test data are there.
http://hackage.haskell.org/trac/ghc/ticket/2284
Ok, but do we really need two tickets for this? Why open a new ticket
rather than adding the information to
Dillard
| Cc: Simon Peyton-Jones; Don Stewart; glasgow-haskell-users@haskell.org
| Subject: Re: laziness, memoization and inlining
|
| Scott Dillard wrote:
| Simon, Don,
|
| You're right. -fno-state-hack fixed it. I've opened a trac ticket.
| Program and test data are there.
|
| http
Scott
| I'm experiencing some undesirable performance behavior, I suspect from
| inlining things that shouldn't be, defeating my memoization attempts.
This is bad, very bad. I think Don is right. I believe the following is
happening. In your main program you have
do let mesh = memoMesh
Simon, Don,
You're right. -fno-state-hack fixed it. I've opened a trac ticket.
Program and test data are there.
http://hackage.haskell.org/trac/ghc/ticket/2284
Scott
On Wed, May 14, 2008 at 1:48 AM, Simon Peyton-Jones
[EMAIL PROTECTED] wrote:
Scott
| I'm experiencing some undesirable
sedillard:
Hi Everybody,
I'm experiencing some undesirable performance behavior, I suspect from
inlining things that shouldn't be, defeating my memoization attempts.
I've been experimenting with purely functional 3D modeling code, so a
mesh is (initially) something like
type Mesh = Map
John Goerzen wrote:
On Mon April 21 2008 3:26:04 pm Magnus Therning wrote:
In order to allow lazy decoding I ended up exporting decode' as well:
decode' :: String - [Maybe Word8]
I take it that in a situation like this, you'd have either:
[] -- success with empty result
a list full of
On Wed, Apr 23, 2008 at 01:12:16PM +0200, apfelmus wrote:
I think that using [Maybe a] for this purpose is too fine-grained, I
would use a custom list type
data River a = a : (River a) | Done | Error
(I didn't want to call it Stream because that name is too overloaded
already and
On Sun, Oct 14, 2007 at 11:54:54PM +0200, ntupel wrote:
On Sat, 2007-10-13 at 09:56 -0400, Brandon S. Allbery KF8NH wrote:
Now you need to start forcing things; given laziness, things tend to
only get forced when in IO, which leads to time being accounted to
the routine where the
On Mon, 2007-10-15 at 10:48 -0400, David Roundy wrote:
I have no idea if this example will help your actual code, but it
illustrates that at least in this example, it's pretty easy to gain an
order of magnitude in speed. (That func is a weird function, by the
way.)
Thanks for your reply
On Oct 14, 2007, at 17:54 , ntupel wrote:
Now my problem still is, that I don't know how to speed things up. I
tried putting seq and $! at various places with no apparent
improvement.
Maybe I need to find a different data structure for my random
module and
lazy lists are simply not
On Sun, 2007-10-14 at 18:14 -0400, Brandon S. Allbery KF8NH wrote:
On Oct 14, 2007, at 17:54 , ntupel wrote:
Now my problem still is, that I don't know how to speed things up. I
tried putting seq and $! at various places with no apparent
improvement.
Maybe I need to find a different
On 2003-08-02 at 14:36PDT Dominic Steinitz wrote:
Could someone explain to me why this doesn't work
test l =
hs
where
hs = map (\x - [x]) [0..abs(l `div` hLen)]
hLen = length $ head hs
whereas this does
test l =
hs
where
hs = map (\x
Hal's solution reminds me of the paper by
Levent Erkök and John Launchbury:
Recursive monadic Bindings: Technical Development and Details.
http://www.cse.ogi.edu/PacSoft/projects/rmb/mfixTR.pdf
One of their examples uses MonadRec and IOExts.
webpage:
Value recursion in Monadic Computations
The following works for me:
import IOExts
main = do xs - unsafeInterleaveIO getStrings
putStrLn (head xs)
getStrings = do
x - getLine
if x == stop
then return []
else do xs - unsafeInterleaveIO getStrings; return (x:xs)
in this particular case, the unsafeInterleaveIO on
I don't think you can do what you want to using standard lists,
not without some dirty trickery...
But you can define a datatype for such a purpose which would essentially
have to put the tail into the Monad.
Disadvantage: you would have to redo lots of the list stuff yourself.
I had once
On 18 Feb 2002, Ketil Z. Malde wrote:
Hi,
I'm a bit puzzled by this observatio that I made. I have a function
that, pseudocoded, lookes somewhat like
f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs)
where ins i = manipulates the first element of the
On Mon, 18 Feb 2002, Jay Cox wrote:
On 18 Feb 2002, Ketil Z. Malde wrote:
Hi,
I'm a bit puzzled by this observatio that I made. I have a function
that, pseudocoded, lookes somewhat like
f i as bs cs = ins i (f (i+1) as) ++ ins i (f (i+1) bs) ++ ins i (f (i+1) cs)
where
Jay Cox [EMAIL PROTECTED] writes:
where ins i = manipulates the first element of the list
if you mean that (ins i) :: [a] - [a] manipulates the first element of
the list it takes then of course it is strict. because in
It is strict in the head of the list, yes. I.e. it is defined
The paper says:
"We are working on a distributed implementation of Concurrent Haskell.
Once nice property of MVars is that they seem relatively easy to implement
in a distributed setting..."
I assume that they are not referring to GPH here.
(I was surprised that at this statement given
1. What implementations are supporting concurrent Haskell?
AFAIK only GHC and Hugs.
What modules do I have to import to use it?
Read the Hugs-GHC documentation in hugs/doc
Hugs claims to support it, but I can't figure out how to engage it.
It's on all the time. The implementation cost
On Wed, 17 Jun 1998, Hans Aberg wrote:
But I found it rather difficult to implement this style with POSIX (Java)
threads: It is hard to guarantee that the computations does not hang. What
I needed was to be able to guarantee that certain sequences in the
implementation cannot the halted in
On Thu, 18 Jun 1998, Alastair Reid wrote:
What modules do I have to import to use it?
Read the Hugs-GHC documentation in hugs/doc
Can you give me a more direct pointer? I am not finding it in my docs.
Also, if you are using system
threads then you get the additional benefit that
Alex,
main = do input - getContents
putStr $ addTwo $ makeLines input
addTwo lines = ask1++(ask2 (Strict x)) ++ (result (Strict y))
where x:y:xs = map read lines
ask1 = "Enter an Integer: "
ask2 _ = "Enter another Integer: "
At 07:54 +0100 98/06/17, Simon L Peyton Jones wrote:
Ideally, I would like to write cgifunctions of type:
myCGIFunction:: [HTTPRequest]-[DatabaseVersion]-
([HTTPResponse],[DatabaseChanges])
HTTPRequests come from _middleware_ that recieves http requests from the
httpd
64 matches
Mail list logo
