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
22 matches
Mail list logo
