I've just read the post Destroying Performance with Strictness by Neil
Mitchell [1].
One of the comments from an Anonymous says:
How hard would it be to lift strictness annotations to type-level? E.g.
instead of
f :: Int - Int
f !x = x + 1
write
f :: !Int - Int
f x = x + 1
which would have
On Thu, Aug 22, 2013 at 12:51:24PM -0300, Thiago Negri wrote:
How hard would it be to lift strictness annotations to type-level? E.g.
instead of
f :: Int - Int
f !x = x + 1
write
f :: !Int - Int
f x = x + 1
which would have the same effect. At least it would be transparent
I think Scala has this optional laziness too.
The problem with default-strictness is that libraries that are built with
no laziness in mind turn up to be too strict.
Going from lazy to strict is possible in the client side, but the other way
is impossible.
2013/8/22 Tom Ellis tom-lists-haskell
On 2013-08-22 18:19, Thiago Negri wrote:
I think Scala has this optional laziness too.
Indeed, but it's _not_ apparent in types (which can be an issue).
Due to the somewhat weird constructor semantics of the JVM it also means
you can have immutable values which start out(!) as null and end up
#7271: Panic with strictness annotation
-+--
Reporter: acowley | Owner:
Type: bug | Status: closed
Priority: normal
#7271: Panic with strictness annotation
+---
Reporter: acowley | Owner:
Type: bug | Status: new
Priority: normal
#7271: Panic with strictness annotation
+---
Reporter: acowley | Owner:
Type: bug | Status: new
Priority: normal
#6087: Join points need strictness analysis
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal
#6087: Join points need strictness analysis
-+--
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal
#5915: Code using seq has wrong strictness when unoptimised (too strict)
--+-
Reporter: michal.palka | Owner:
Type: bug | Status
#5915: Code using seq has wrong strictness when unoptimised (too strict)
-+--
Reporter: michal.palka | Owner:
Type: bug | Status
#5915: Code using seq has wrong strictness when unoptimised (too strict)
--+-
Reporter: michal.palka | Owner:
Type: bug | Status
-
| users-boun...@haskell.org] On Behalf Of Johan Tibell
| Sent: 07 March 2012 23:42
| To: j...@repetae.net
| Cc: glasgow-haskell-users
| Subject: Re: Interpreting the strictness annotations output by ghc --show-
| iface
|
| Edward, I have looked at that file before and it didn't make me much
| I'm not sure but the trailing m in g's signature.
That says that the result has the CPR property.
S
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hi,
If someone could clearly specify the exact interpretation of these
LLSL(ULL) strictness/demand annotations shown by ghc --show-iface I'd
like to try to write a little tool that highlights the function
argument binding in an IDE (e.g. Emacs) with this information. Anyone
care to explain
modeled the jhc strictness analyzer after the ghc one
(with minor hindsight improvements) so pored over the ghc one for
quite a while once upon a time.
John
On Wed, Mar 7, 2012 at 3:21 PM, Johan Tibell johan.tib...@gmail.com wrote:
Hi,
If someone could clearly specify the exact interpretation
argument is not used at all. I have a paper that describes it
somewhere. I modeled the jhc strictness analyzer after the ghc one
(with minor hindsight improvements) so pored over the ghc one for
quite a while once upon a time.
Oh, and the (..) works for all CPR types, not just tuples.
John
Check out compiler/basicTypes/Demand.lhs
Cheers,
Edward
Excerpts from Johan Tibell's message of Wed Mar 07 18:21:56 -0500 2012:
Hi,
If someone could clearly specify the exact interpretation of these
LLSL(ULL) strictness/demand annotations shown by ghc --show-iface I'd
like to try to write
Ah, looks like it got a bit more complicated since I looked at it
last... time to update jhc :)
Actually. not sure if the Eval/Box split is relevant to my core. hmm
John
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Edward, I have looked at that file before and it didn't make me much
wiser, because I cannot map it to the output.
I find it's the parenthesis that confuses me the most. What does this mean?
C(U(LU(L)))
what about this?
U(SLLAA)LL
-- Johan
___
the original type signature is needed to figure it out. In the
earlier example it indicated ghc drilling down into the type (a tuple) and
determining the strictness of the constituents.
--
brandon s allbery allber...@gmail.com
wandering unix systems administrator
On Wed, Mar 7, 2012 at 4:38 PM, Brandon Allbery allber...@gmail.com wrote:
I think the original type signature is needed to figure it out. In the
earlier example it indicated ghc drilling down into the type (a tuple) and
determining the strictness of the constituents.
I parenthesis were
) and
determining the strictness of the constituents.
I parenthesis were for tuples I would never expect to see e.g. U(L).
They are for all CPR types, not just tuples. so that could be
data Foo = Foo Int
It also may omit values for which is has no information for, I can't
recall if ghc does
)
and
determining the strictness of the constituents.
I parenthesis were for tuples I would never expect to see e.g. U(L).
Right, the tuple was just that example.
Data F = F Int
would give you something that could produce U(L), the U for the F
constructor, the L for the contained Int
:: Int - Int
f x = x
g :: Int - Int
g x = x + 1
gives this core
Test.f :: Int - Int
Test.f = \ (x :: Int) - x
Test.g :: Int - Int
Test.g =
\ (x :: Int) -
case x of _ { I# x# -
I# (+# x# 1)
}
and these strictness annotations
f
This is the important bit of code in the file:
instance Outputable Demand where
ppr Top = char 'T'
ppr Abs = char 'A'
ppr Bot = char 'B'
ppr (Defer ds) = char 'D' ppr ds
ppr (Eval ds) = char 'U' ppr ds
ppr (Box (Eval ds)) =
Thanks Edward. I'll try to summarize this in human readable form and
publish it on the wiki.
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Arguably, what should happen is we redo the format for machine-parseability
and use that in future versions of GHC.
Edward
Excerpts from Johan Tibell's message of Wed Mar 07 23:38:06 -0500 2012:
Thanks Edward. I'll try to summarize this in human readable form and
publish it on the wiki.
--
#5915: Code using seq has wrong strictness when unoptimised (too strict)
-+--
Reporter: michal.palka | Owner:
Type: bug | Status
#2078: INLINE and strictness
--+-
Reporter: simonpj | Owner: simonpj
Type: bug | Status: closed
Priority: lowest
).
In fact, only
sum [4,5,6,8,2,90,_|_,_|_ ...] is always _|_.
Which shows they don't have the same level of strictness.
So can you say things like all these functions are strict, but some are *more
*than other, or sum is *deeply strict* ...?
What terms can you use to compare those functions
There are some terms for these cases, but they are a bit ad hoc.
length is what we might call spine-strict; head is head-strict.
Projection analysis takes the approach that we can more precisely
characterize the strictness only by considering both what is passed
to the function as input, as well
Yves Parès yves.pa...@gmail.com writes:
I had for long thought that data and newtype were equivalent, but then I
spotted some differences when it comes to strictness.
data Test = Test Int
newtype TestN = TestN Int
Interesting. I'd thought that
data Test = Test !Int
and
newtype Test
On Tue, Jan 24, 2012 at 11:25, Ketil Malde ke...@malde.org wrote:
Yves Parès yves.pa...@gmail.com writes:
I had for long thought that data and newtype were equivalent, but then I
spotted some differences when it comes to strictness.
data Test = Test Int
newtype TestN = TestN Int
Interesting
On Sun, Jan 22, 2012 at 5:25 PM, David Barbour dmbarb...@gmail.com wrote:
The laws for monads only apply to actual values and combinators of the monad
algebra
You seem to argue that, even in a lazy language like Haskell,
equational laws should be considered only for values, as if they where
Thanks for the reference. I base my opinion on my own observations - e.g.
the repeated failures of attempting to model stream processing with
infinite lists, the relative success of modeling exceptions explicitly with
monads compared to use of `fail` or SomeException, etc..
On Mon, Jan 23, 2012
On Mon, Jan 23, 2012 at 10:45 AM, David Barbour dmbarb...@gmail.com wrote:
the repeated failures of attempting to model stream processing with infinite
lists,
I'm curious about what failures you're talking about.
- Jake
___
Haskell-Cafe mailing list
Space leaks, time leaks, resource leaks, subtle divergence issues when
filtering lists, etc.
On Mon, Jan 23, 2012 at 11:57 AM, Jake McArthur jake.mcart...@gmail.comwrote:
On Mon, Jan 23, 2012 at 10:45 AM, David Barbour dmbarb...@gmail.com
wrote:
the repeated failures of attempting to model
Hello,
I had for long thought that data and newtype were equivalent, but then I
spotted some differences when it comes to strictness.
Those can be summed up as:
data Test = Test Int
newtype TestN = TestN Int
pm (Test _) = 12 -- Strict (pm undefined = undefined)
pm2 t = t `seq` 12 -- Strict
* Yves Parès yves.pa...@gmail.com [2012-01-22 11:32:30+0100]
These make me think that pattern matching against a newtype is always lazy
(irrefutable). Am I right?
Yes.
Is there some litterature expliciting in a less empiric way than I did the
differences like this between data and newtype?
Yves Parès wrote:
Is there some litterature expliciting in a less empiric way than I did the
differences like this between data and newtype? I've never come against
such documentation through all my learning of Haskell, yet I think it's an
important point.
Roman Cheplyaka wrote:
See the
Thanks, that's clearer to me now.
It confirmed my thoughts:
Matching the pattern con pat against a value, where con is a constructor
defined by newtype, depends on the value:
- If the value is of the form con v, then pat is matched against v.
- If the value is ⊥, then pat is matched against ⊥.
Big sum up of everything:
If TestN is a newtype constructor, then
'TestN undefined' and 'undefined' are exactly the same thing.
2012/1/22 Yitzchak Gale g...@sefer.org
Yves Parès wrote:
Is there some litterature expliciting in a less empiric way than I did
the
differences like this
* Yves Parès yves.pa...@gmail.com [2012-01-22 15:23:51+0100]
Big sum up of everything:
If TestN is a newtype constructor, then
'TestN undefined' and 'undefined' are exactly the same thing.
To be precise, the former is a type-restricted version of the latter.
--
Roman I. Cheplyaka ::
On Sat, Jan 21, 2012 at 8:09 PM, David Barbour dmbarb...@gmail.com wrote:
In any case, I think the monad identity concept messed up. The property:
return x = f = f x
Logically only has meaning when `=` applies to values in the domain.
`undefined` is not a value in the domain.
We can
observably different from `undefined`
If we understand `undefined` as meaning a computation that never ends, then
you cannot ever observe whether one `undefined` is or is not equivalent to
another. In strict languages, this is especially obvious.
In any case, I don't accept a concept of
Отправлено с iPad
22.01.2012, в 20:25, David Barbour dmbarb...@gmail.com написал(а):
Attempting to shoehorn `undefined` into your reasoning about domain algebras
and models and monads is simply a mistake.
No. Using the complete semantics — which includes bottoms aka undefined — is a
2012/1/22 MigMit miguelim...@yandex.ru
Отправлено с iPad
22.01.2012, в 20:25, David Barbour dmbarb...@gmail.com написал(а):
Attempting to shoehorn `undefined` into your reasoning about domain
algebras and models and monads is simply a mistake.
No. Using the complete semantics — which
The do notation translates
do {x - a;f} into
a=(\x - f)
However when we're working in the IO monad the semantics we want requires that
the lambda expression be strict in its argument. So is this a special case for
IO? If I wanted this behavior in other monads is there a way to specify
On 21 Jan 2012, at 21:29, Victor S. Miller wrote:
The do notation translates
do {x - a;f} into
a=(\x - f)
However when we're working in the IO monad the semantics we want requires
that the lambda expression be strict in its argument. So is this a special
case for IO? If I wanted
* Victor S. Miller victorsmil...@gmail.com [2012-01-21 12:29:32-0500]
The do notation translates
do {x - a;f} into
a=(\x - f)
However when we're working in the IO monad the semantics we want
requires that the lambda expression be strict in its argument.
I'm not aware of any semantics
As noted, IO is not strict in the value x, only in the operation that
generates x. However, should you desire strictness in a generic way, it
would be trivial to model a transformer monad to provide it.
E.g.
data StrictT m a = StrictT (m a)
runStrictT :: StrictT m a - m a
runStrictT (StrictT op
in other monads is there a way to specify that?
IO is a special case, but strictness isn't the issue.
The value x cannot be evaluated in concrete form (I think the technical
term is head normal form) until the IO action a has been executed.
However, evaluating to head normal form isn't really
* David Barbour dmbarb...@gmail.com [2012-01-21 10:01:00-0800]
As noted, IO is not strict in the value x, only in the operation that
generates x. However, should you desire strictness in a generic way, it
would be trivial to model a transformer monad to provide it.
Again, that wouldn't
On 21/01/2012 18:08, Steve Horne wrote:
Even so, to see that strictness isn't the issue, imagine that (=)
were rewritten using a unary executeActionAndExtractResult function.
You could easily rewrite your lamba to contain this expression in
place of x, without actually evaluating
On Sat, Jan 21, 2012 at 10:08 AM, Roman Cheplyaka r...@ro-che.info wrote:
* David Barbour dmbarb...@gmail.com [2012-01-21 10:01:00-0800]
As noted, IO is not strict in the value x, only in the operation that
generates x. However, should you desire strictness in a generic way, it
would
x. However, should you desire strictness in a generic way, it
would be trivial to model a transformer monad to provide it.
Again, that wouldn't be a monad transformer, strictly speaking, because
monads it produces violate the left identity law.
It meets the left identity law in the same
On Sat, Jan 21, 2012 at 10:51 AM, David Menendez d...@zednenem.com wrote:
The Eval monad has the property: return undefined = const e = e.
You can't write `const e` in the Eval monad.
From what I can tell, your proposed monads do not.
You can't write `const e` as my proposed monad,
* David Barbour dmbarb...@gmail.com [2012-01-21 11:02:40-0800]
On Sat, Jan 21, 2012 at 10:51 AM, David Menendez d...@zednenem.com wrote:
The Eval monad has the property: return undefined = const e = e.
You can't write `const e` in the Eval monad.
Why not?
ghci runEval $ return
Oops, I was misreading. You have `e` here as the next monad.
In any case, I think the monad identity concept messed up. The property:
return x = f = f x
Logically only has meaning when `=` applies to values in the domain.
`undefined` is not a value in the domain.
We can define monads - which
On Sat, Jan 21, 2012 at 11:08 AM, Roman Cheplyaka r...@ro-che.info wrote:
* David Barbour dmbarb...@gmail.com [2012-01-21 11:02:40-0800]
On Sat, Jan 21, 2012 at 10:51 AM, David Menendez d...@zednenem.com
wrote:
The Eval monad has the property: return undefined = const e = e.
You
* David Barbour dmbarb...@gmail.com [2012-01-21 11:09:43-0800]
Logically only has meaning when `=` applies to values in the domain.
`undefined` is not a value in the domain.
We can define monads - which meet monad laws - even in strict languages.
In strict languages 'undefined' is not a
`undefined` is not a value in any domain. It isn't a value at all. It's
certainly not part of my monad language or algebra. Up to the semantic
level of comparing observable and legally defined behaviors, we can have
the identity law. That's sufficient for the letter of the law, even if not
ideal
* David Barbour dmbarb...@gmail.com [2012-01-21 12:18:09-0800]
`undefined` is not a value in any domain. It isn't a value at all. It's
certainly not part of my monad language or algebra. Up to the semantic
level of comparing observable and legally defined behaviors, we can have
the identity
itself - not the
representation in Haskell, and certainly not the representation of Haskell
on a Von Neumann machine. Since strictness does not affect the *values* of
any elements in the monad's algebra, it is trivial to meet the monad laws.
My argument did switch from denotational to operational
at 10:08 AM, Roman Cheplyaka r...@ro-che.infowrote:
* David Barbour dmbarb...@gmail.com [2012-01-21 10:01:00-0800]
As noted, IO is not strict in the value x, only in the operation that
generates x. However, should you desire strictness in a generic way, it
would be trivial to model
...@gmail.com [2012-01-21 10:01:00-0800]
As noted, IO is not strict in the value x, only in the operation that
generates x. However, should you desire strictness in a generic way, it
would be trivial to model a transformer monad to provide it.
Again, that wouldn't be a monad transformer, strictly
* Johan Tibell johan.tib...@gmail.com [2011-11-17 21:21:47-0800]
Hi all,
Data.Map is getting split into Data.Map.Lazy and Data.Map.Strict (with
Data.Map re-exporting the lazy API). I want to better document the
strictness properties of the two new modules. Right now the
documentation
Johan Tibell wrote:
map (\ v - undefined) == undefined
mapKeys (\ k - undefined) == undefined
Not really related to the question but I don't really understand how these
properties can possibly hold. Shouldn't it be:
map (\v - undefined) x = undefined
And even then, does
On 18 November 2011 06:44, Johan Tibell johan.tib...@gmail.com wrote:
Here are some examples:
insertWith (+) k undefined m == undefined
delete undefined m == undefined
map (\ v - undefined) == undefined
mapKeys (\ k - undefined) == undefined
Any ideas for further
for strictness?
* All key and value arguments passed to functions are
evaluated to WHNF before the function body is evaluated
* keys and values returned by high-order function arguments are
evaluated to WHNF before they are inserted into the map.
Keys and values not returned by higher
On Fri, Nov 18, 2011 at 12:09 AM, Roman Cheplyaka r...@ro-che.info wrote:
Is it mentioned anywhere that Map is spine-strict?
It's not and we should probably mention it.
I was mulling this over last night. My initial thought was that it
shouldn't matter as long as the algorithmic complexity of
On Fri, Nov 18, 2011 at 1:58 AM, Roman Leshchinskiy r...@cse.unsw.edu.au
wrote:
Johan Tibell wrote:
map (\ v - undefined) == undefined
mapKeys (\ k - undefined) == undefined
Not really related to the question but I don't really understand how these
properties can possibly
to functions or function arguments. Also before the
function body is evaluated says something about evaluation order, does that
really matter for strictness?
It is a bit redundant. I will remove it.
* keys and values returned by high-order function arguments are
evaluated to WHNF before
Here's an attempt at an improved version:
Strictness properties
=
This module satisfies the following properties:
1. Key and value arguments are evaluated to WHNF;
2. Keys and values are evaluated to WHNF before they are stored in
the map.
Here are some examples
* Johan Tibell johan.tib...@gmail.com [2011-11-18 08:06:29-0800]
On Fri, Nov 18, 2011 at 12:09 AM, Roman Cheplyaka r...@ro-che.info wrote:
Is it mentioned anywhere that Map is spine-strict?
It's not and we should probably mention it.
Hm. Perhaps I'm missing something, but
data Map k a =
On Fri, Nov 18, 2011 at 12:16, Roman Cheplyaka r...@ro-che.info wrote:
* Johan Tibell johan.tib...@gmail.com [2011-11-18 08:06:29-0800]
On Fri, Nov 18, 2011 at 12:09 AM, Roman Cheplyaka r...@ro-che.info
wrote:
Is it mentioned anywhere that Map is spine-strict?
It's not and we should
* Brandon Allbery allber...@gmail.com [2011-11-18 12:20:33-0500]
On Fri, Nov 18, 2011 at 12:16, Roman Cheplyaka r...@ro-che.info wrote:
* Johan Tibell johan.tib...@gmail.com [2011-11-18 08:06:29-0800]
On Fri, Nov 18, 2011 at 12:09 AM, Roman Cheplyaka r...@ro-che.info
wrote:
Is it
On Fri, Nov 18, 2011 at 9:16 AM, Roman Cheplyaka r...@ro-che.info wrote:
* Johan Tibell johan.tib...@gmail.com [2011-11-18 08:06:29-0800]
On Fri, Nov 18, 2011 at 12:09 AM, Roman Cheplyaka r...@ro-che.info wrote:
Is it mentioned anywhere that Map is spine-strict?
It's not and we should
On Fri, 18 Nov 2011 06:58:41 +0100, Evan Laforge qdun...@gmail.com wrote:
Any ideas for further improvements?
I feel like there should be a canonical what is WHNF page on
haskell.org that docs like this can link to. Namely, what it is
theoretically, what that means for various examples of
Hi all,
Data.Map is getting split into Data.Map.Lazy and Data.Map.Strict (with
Data.Map re-exporting the lazy API). I want to better document the
strictness properties of the two new modules. Right now the
documentation for Data.Map.Strict reads:
Strictness properties
works at a high level.
Ideas?
This reads a bit better to me:
Strictness properties
=
This module is strict in keys and values. In particular,
* key and value function arguments passed to functions are
evaluated to WHNF before the function body is evaluated, and
* keys
information), assuming that the reader already knows how
lazy evaluation works at a high level.
Ideas?
This reads a bit better to me:
Strictness properties
=
This module is strict in keys and values. In particular,
* key and value function arguments passed to functions
Any ideas for further improvements?
I feel like there should be a canonical what is WHNF page on
haskell.org that docs like this can link to. Namely, what it is
theoretically, what that means for various examples of thunks (i.e.
show how a sample graph would get reduced), and what that means
#5625: Code using seq has wrong strictness when unoptimised (too lazy)
---+
Reporter: michal.palka|Owner: simonpj
Type: bug | Status
#5625: Code using seq has wrong strictness when unoptimised (too lazy)
-+--
Reporter: michal.palka | Owner:
Type: bug | Status: new
#5625: Code using seq has wrong strictness when unoptimised (too lazy)
-+--
Reporter: michal.palka | Owner:
Type: bug | Status: new
#5625: Code using seq has wrong strictness when unoptimised (too lazy)
---+
Reporter: michal.palka|Owner: simonpj
Type: bug | Status
#5587: Code using seq has wrong strictness (too lazy) when optimised
---+
Reporter: michal.palka|Owner: simonpj
Type: bug | Status: new
#5557: Code using seq has wrong strictness (too lazy)
--+-
Reporter: michal.palka | Owner:
Type: bug | Status: closed
#5587: Code using seq has wrong strictness (too lazy) when optimised
-+--
Reporter: michal.palka | Owner:
Type: bug | Status: new
#5557: Code using seq has wrong strictness (too lazy)
---+
Reporter: michal.palka|Owner:
Type: bug | Status: new
#5557: Code using seq has wrong strictness (too lazy)
--+-
Reporter: michal.palka | Owner:
Type: bug | Status: closed
#5557: Code using seq has wrong strictness (too lazy)
-+--
Reporter: michal.palka | Owner:
Type: bug | Status: new
Priority
#5557: Code using seq has wrong strictness (too lazy)
-+--
Reporter: michal.palka | Owner:
Type: bug | Status: new
Priority
#5557: Code using seq has wrong strictness (too lazy)
---+
Reporter: michal.palka|Owner:
Type: bug | Status: new
#4267: Strictness analyser is to conservative about passing a boxed parameter
-+--
Reporter: tibbe |Owner:
Type: bug | Status: new
Priority
#4267: Strictness analyser is to conservative about passing a boxed parameter
-+--
Reporter: tibbe |Owner:
Type: bug | Status: new
Priority
Hello Alexey,
sorry for my slow response.
On Thu, Aug 4, 2011 at 7:10 AM, Alexey Khudyakov
alexey.sklad...@gmail.comwrote:
On 02.08.2011 08:16, Sebastian Fischer wrote:
Data.Foldable also provides the monoidal fold function foldMap. It is
left unspecified whether the elements are
On 02.08.2011 08:16, Sebastian Fischer wrote:
Data.Foldable also provides the monoidal fold function foldMap. It is
left unspecified whether the elements are accumulated leftwards,
rightwards or in some other way, which is possible because the combining
function is required to be associative.
1 - 100 of 559 matches
Mail list logo
