On Wed, Dec 07, 2005 at 04:09:31PM -0800, John Meacham wrote:
you arn't using existential types here. an example with an existential
type would be (in ghc syntax)
data forall a . State
= Start
| Stop
| (Show a, Eq a) = State a
Shouldn't it be:
data State
= Start
On Thu, Dec 08, 2005 at 09:13:10AM +0100, Tomasz Zielonka wrote:
Shouldn't it be:
data State
= Start
| Stop
| forall a . (Show a, Eq a) = State a
ah. you are right. my bad.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
On Thursday 08 December 2005 07:33, you wrote:
seqPair $= (,)
or (the slightly less cryptic version)
seqPair x y $= (x, y)
Wouldn't they be different, the first one forcing (,) to WHNF (NOP), and
the second one forcing x and y to WHNF?
No. Oh, $= also breaks type inferencing :) So
Did someone actually try compiling this? Here are the results:
data State a
= Start
| Stop
| (Show a, Eq a) = State a
deriving Show
foo.hs:1:5:
Can't make a derived instance of `Show (State a)'
(`State' has existentially-quantified constructor(s))
When deriving
On Dec 8, 2005, at 12:09 AM, John Meacham wrote:
if you are okay with a being an argument then
data State a
= Start
| Stop
| State a
deriving(Show,Eq)
will do what you want I believe.
This does the trick! Thank you!
--
http://wagerlabs.com/
I use OpenSSL in a heavily threaded environment. It works without
extra locking. I do not use bound (OS) threads, though.
On Dec 8, 2005, at 7:06 AM, Branimir Maksimovic wrote:
First I want to say about OpenSSL thread safety. It is not thread
safe by default.
Who wants to import and use
From: Joel Reymont [EMAIL PROTECTED]
To: Branimir Maksimovic [EMAIL PROTECTED]
CC: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Mixing C++ and Haskell, OpenSSL thread safety,
and using mmap
Date: Thu, 8 Dec 2005 09:21:08 +
I use OpenSSL in a heavily threaded environment. It
Here is something else that I don't quite understand...
Original version compiles:
push :: Show b = State b - Dispatcher b a - (ScriptState a b) ()
push state dispatcher =
do w - get
trace 95 $ push: Pushing ++ show state ++ onto the stack
let s = stack w
putStrict $
I only lock around the connectTo to avoid the gethostbyname issue.
After that I set up two memory BIOs and hook them to go through a
handshake. Encryption is done through the BIOs afterwards since I
need to wrap the encrypted data in a header of my own (don't ask).
I haven't had a problem
data (Eq a, Show a) = State a = Start | Stop | State a deriving Show
Putting the class context on the data constructor like that wasn't
doing you any more good than this way, and was causing ghc to think
that the constructor was existentially quantified.
- Cale
On 08/12/05, Joel Reymont [EMAIL
Okay, so here you *did* get something from the existential typing :)
The type of show, restricted to State in the original version is:
show :: Show a = State a - String
Now, in the new version, you get the type:
show :: (Eq a, Show a) = State a - String
because what happens is that pattern
On 07 December 2005 13:06, John Goerzen wrote:
On Wed, Dec 07, 2005 at 11:02:29AM +, Duncan Coutts wrote:
Also please note that these repos are READ ONLY for now. Nobody
will be accepting darcs patches until Simon (or someone) gives the
word.
When that does happen, it'd be great if
I have made a simple Split function, here is how it works :
str = k1=v1|k2=v2|k3=v3
map (sSplit '=') (sSplit '|' str)
[[k1,v1],[k2,v2],[k3,v3]]
Now what I want to do is to return listOfPairs (instead listOflists) so that I
can
give this as parameter to Data.Map.fromList and build hash-like
Hello Joel,
Thursday, December 08, 2005, 12:26:52 PM, you wrote:
JR I was also hoping that something like this would let me avoid
JR quantifying a in functions downstream but alas, it does not happen. I
JR have to use (Eq a, Show a) = a ... everywhere else.
to avoid context declarations you
Doesn't this have an effect on performance?
Is GHC still able to optimize things properly?
On Dec 8, 2005, at 10:20 AM, Bulat Ziganshin wrote:
Hello Joel,
Thursday, December 08, 2005, 12:26:52 PM, you wrote:
JR I was also hoping that something like this would let me avoid
JR quantifying a
On Thursday 08 December 2005 09:36, John Meacham wrote:
On Thu, Dec 08, 2005 at 09:13:10AM +0100, Tomasz Zielonka wrote:
Shouldn't it be:
data State
= Start
| Stop
| forall a . (Show a, Eq a) = State a
ah. you are right. my bad.
But this is a rank-2 type, not an
On Wed, 7 Dec 2005, J. Garrett Morris wrote:
On 12/7/05, Robin Green [EMAIL PROTECTED] wrote:
Let's say you want to write a function
seqPair :: (Monad m) = (m a, m b) - m (a, b)
which returns a computation which does the left computation followed by the
right computation (i.e. it's
GHCi does things with optimisations off. Note the line on startup which says:
Compiling Main ( search.hs, interpreted )
You'll have better luck if you compile the code with optimisations and
keep the .o files around when running the program in ghci -- it will
notice the compiled copies
On Thu, Dec 08, 2005 at 09:23:22AM -0500, David Roundy wrote:
data EqContext a b = EqContext { safe_coerce :: f(a,b) - f(b,a) }
where f(a,b) is a function of two types that returns a type, so the value
of f(a,b) might be (Patch a b) or (Patch x b) or something like that.
But I'm not sure
Is there in standard libraries functions that do
structure transformations ?
just curious...
|Write a function:
|
|list_to_pair :: [a] - (a,a)
|
|and then map it over the list of lists:
|
|map list_to_pair your_resulting_list_of_lists
|
|HTH,
|Ben
___
Not this one in particular, but there are various functions throughout
the libraries which do all sorts of structural transformations on
lists and other types. Have a look at the Prelude and Data.List module
in the libraries documentation at
http://www.haskell.org/ghc/docs/latest/html/libraries/
On 12/8/05, Robin Green [EMAIL PROTECTED] wrote:
Sure, I take your point. But I just jumped on my latest hobby-horse: verbosity
of imperative code is not that necessary.
There was a discussion along these lines some time ago, started by
Frederik Eaton with the subject line Mixing monadic and
Am Donnerstag, 8. Dezember 2005 04:00 schrieb Jan-Willem Maessen:
On Dec 7, 2005, at 9:58 AM, Wolfgang Jeltsch wrote:
Am Mittwoch, 7. Dezember 2005 14:21 schrieb Jan-Willem Maessen:
[...]
The principle obstacles are the same as for any reference counting
scheme: It imposes more
- Original Message -
From: Wolfgang Jeltsch - [EMAIL PROTECTED]
Sent: Thursday, December 08, 2005 6:13 PM
I thought that the original question was about using some kind of uniqueness
type system at an intermediate stage during compiling. Haskell would still
have no uniqueness
- Original Message -
From: Tomasz Zielonka - [EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 8:53 PM
Clean-like _explicit_ uniqueness typing is not what I'm asking for in
Haskell.
So you want implicit, automatically inferred uniqueness typing -
something that would be
On Thu, 8 Dec 2005, Branimir Maksimovic wrote:
program performs search replace on a String
http://www.haskell.org/pipermail/haskell-cafe/2005-April/009692.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
- Original Message -
From: Tomasz Zielonka - [EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 8:53 PM
Clean-like _explicit_ uniqueness typing is not what I'm asking for in
Haskell.
So you want implicit, automatically inferred uniqueness typing -
something that would be even
Am Donnerstag, 8. Dezember 2005 13:08 schrieb
[EMAIL PROTECTED]:
[...]
A uniqueness checker can be rather robust, as is demonstrated by the Clean
one, so all we'd have to worry about is how to find a good set of supposedly
unique node candidates to suggest to the checker. (It certainly would
Am Donnerstag, 8. Dezember 2005 18:38 schrieb
[EMAIL PROTECTED]:
[...]
p.p.s.: I've sent this mail a second time because the first one got lost
somehow - hopefully, it doesn't show up again.
Concerning me, your first mail wasn't lost. I got this mail two times.
Best wishes,
Wolfgang
Am Donnerstag, 8. Dezember 2005 16:56 schrieb John Goerzen:
[...]
I have never worked much with these web front-ends. My understanding is
that Trac is probably not the most efficient front-end to darcs, as it
tries to put things in a more svn-like model. I wonder if one of the
other
I believe the following is not indented correctly. It only happens
with (x:xs) when you use nested cases, I think.
case foo of
[] -
case bar of
[] -
return ()
(x:xs) -
--
http://wagerlabs.com/
___
Haskell-Cafe
On Thu, Dec 08, 2005 at 06:38:53PM +0100, [EMAIL PROTECTED] wrote:
- Original Message -
From: Tomasz Zielonka - [EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 8:53 PM
Clean-like _explicit_ uniqueness typing is not what I'm asking for in
Haskell.
So you want implicit,
Scherrer, Chad wrote:
I'm wondering about a syntactic sugar for comonads. These are still very
new to me, but it seems like their usage will become much more common
once manipulations are more convenient (I believe this was the case with
monads and arrows, correct?).
I'm actually rather
I believe the following is not indented correctly. It only happens with
(x:xs) when you use nested cases, I think.
case foo of
[] -
case bar of
[] -
return ()
(x:xs) -
Thanks. The indentation indeed works particularly poorly here in ways that
I hadn't
Clean-like _explicit_ uniqueness typing is not what I'm asking for in
Haskell.
So you want implicit, automatically inferred uniqueness typing -
something that would be even more fragile and sensitive then current
Haskell's space problems arising from laziness? ;-)
Why should
On Thu, Dec 08, 2005 at 11:29:44AM -0800, Jeremy Shaw wrote:
Why should inferring uniqueness be all that fragile? A uniqueness checker
can be
rather robust, as is demonstrated by the Clean one.
Fragile could refer to the fact that a relatively small looking change
to your code could
Can someone point me to a sample so I can get started? This will be
my first Haskkel project, after reading about it for some months now.
I need to extract text from a structed binary file. Its a local
database for a commercial app of proprietary structure, though the
structure has been
On Thu, 2005-12-08 at 11:29 -0800, Jeremy Shaw wrote:
Why should inferring uniqueness be all that fragile? A uniqueness checker
can be
rather robust, as is demonstrated by the Clean one.
Fragile could refer to the fact that a relatively small looking change
to your code could have a
hi,
I imported :
import Data.Map as Map
but now anywhere when I want ot use map it complains for
name clashes, so I have to specifiy Prelude.map all the time.
Is there a way to specify that i mean Prelude not Data 'map' (but not fqn)
I use Hugs, 'cause error messages are more understandable.
On Thu, 8 Dec 2005, Duncan Coutts wrote:
For example it's not currently convenient to find out the strictness
that ghc infers for functions (though it is possible). Ideally an IDE or
something would be able to present this sort of information along with
the inferred type etc.
It'd be nice
On Fri, 2005-12-09 at 00:24 +0200, raptor wrote:
hi,
I imported :
import Data.Map as Map
but now anywhere when I want ot use map it complains for
name clashes, so I have to specifiy Prelude.map all the time.
Is there a way to specify that i mean Prelude not Data 'map' (but not fqn)
I
Hello Joel,
better to ask Simon. if automatically determined type is more generic
than you really need, this can something slow program. but i think that
generally this have no big impact, because many functions are just
inlined and, theoretically, can be specialized just at inlining place
- Original Message -
From: Duncan Coutts - [EMAIL PROTECTED]
Sent: Thursday, December 08, 2005 9:09 PM
On Thu, 2005-12-08 at 11:29 -0800, Jeremy Shaw wrote:
The only case it is a benefit is when it accidentally happens and it's just
a bonus, but in that case you never needed the
Hello,
Since you're already using GADTs, why not also use them to witness type
equality:
import GHC.Exts
data Patch a b = Patch Int Int
data Sequential a c where
Sequential :: Patch a b - Patch b c - Sequential a c
data MaybeEq :: * - * - * where
NotEq :: MaybeEq a b
IsEq :: MaybeEq
Hi,
Can anyone suggest some references to learn how to program using GHC
with threads? I've read a little bit about STM, but it's still pretty
mysterious to me. Is this the best approach to take? I've never used
threads in any language, but monads are fairly comfortable for me.
Thanks!
Chad
On Thu, Dec 08, 2005 at 09:59:25PM +0100, [EMAIL PROTECTED] wrote:
p.s.: Strangely, Tomasz's reply again appears as being sent from my address
in the archive. Anyone knows why?
Maybe mailman is somehow confused by this weird address:
xoxy = haskell-cafe [EMAIL PROTECTED]
?
Best regards
Ralf Hinze wrote:
the type a :=: b defined below
goes back to Leibniz's principle of substituting equals for equals:
If you like this, check out two of Ralf's papers:
First-class phantom types:
http://techreports.library.cornell.edu:8081/Dienst/UI/1.0/Display/cul.cis/TR2003-1901
Fun with
Hello Chad,
Friday, December 09, 2005, 3:09:29 AM, you wrote:
SC Can anyone suggest some references to learn how to program using GHC
SC with threads? I've read a little bit about STM, but it's still pretty
SC mysterious to me. Is this the best approach to take? I've never used
SC threads in any
48 matches
Mail list logo
