Re: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 | Stop | forall a . (Show a, Eq a) = State a ? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Verbosity of imperative code (was: Learning Haskell)
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 you have to specify the type of the function explicitly. Would you want seqPair written with $= to still have a type involving the Monad class? That's the idea, yes. The type of the function does not change, only the way you write it changes when you use $= (again, this is all just a proposal at present). This is not referentially transparent because it is not equivalent to seqPair x y $= swap (y, x) where swap (a, b) = (b, a) (can you see why not?) Only guessing, because I am not sure what $= is supposed to do, but is it because y would be evaluated before x? Yup. Well, that's one possible semantics of $=. A better semantics might reject the above expression as ambiguous. Anyway, I didn't think my initial statement was so controversial. I even said may, not will. Sure, I take your point. But I just jumped on my latest hobby-horse: verbosity of imperative code is not that necessary. -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 instances for type `State' I do not want to do it the way Tomasz and John are suggesting below. I need the user of my library to supply their own a and be able to pattern match on it. In the library itself I just need Show and Eq a. The following does the trick (compiles, works) but sucks in its verbosity: data State a = Start | Stop | (Show a, Eq a) = State a instance Eq a = Eq (State a) where (State a) == (State b) = a == b Start == Start = True Stop == Stop = True _ == _ = False instance Show a = Show (State a) where show (State a) = show a show Start = Start show Stop = Stop On Dec 8, 2005, at 8:36 AM, 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. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mixing C++ and Haskell, OpenSSL thread safety, and using mmap
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 OpenSLL functions with FFI, have to set locking hooks for it, or else spurious crashes with useless stack trace will result. Higher level of concurrency, more likely crash will happen. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mixing C++ and Haskell, OpenSSL thread safety, and using mmap
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 works without extra locking. I do not use bound (OS) threads, though. If code executes concurrently that means you have a problem with OpenSSL for sure. Probably it works now because SSL calls are not concurrent or so, but I wouldn't risk about it as I am sure that you would have problems with that if calls to SSL functions are concurrent. Also, I think that original problem of gethostbyname just hides real SSL problem as you've probably locked around that too, but you can't be really sure. so either lock around every SSL call with global mutex or set locks in C module then call Haskell or setup callbacks from Haskell, whichever way you prefer. Greetings, Bane. 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 OpenSLL functions with FFI, have to set locking hooks for it, or else spurious crashes with useless stack trace will result. Higher level of concurrency, more likely crash will happen. -- http://wagerlabs.com/ _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 $ w { stack = (state, dispatcher):s }
data State a
= Start
| Stop
| (Show a, Eq a) = State a
instance Eq a = Eq (State a) where
(State a) == (State b) = a == b
Start == Start = True
Stop == Stop = True
_ == _ = False
instance Show a = Show (State a) where
show (State a) = show a
show Start = Start
show Stop = Stop
This version does not. Why does it require Eq in the ++ context? And
why doesn't the other version?
data (Show a, Eq a) = State a
= Start
| Stop
| State a
deriving (Eq, Show)
Could not deduce (Eq b) from the context (Show b)
arising from use of `show' at ./Script/Engine.hs:86:38-41
Probable fix: add (Eq b) to the type signature(s) for `push'
In the first argument of `(++)', namely `show state'
In the second argument of `(++)', namely `(show state) ++ onto the
stack'
--
http://wagerlabs.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mixing C++ and Haskell, OpenSSL thread safety, and using mmap
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 with this so far but I might have just been lucky. I will put some locks around. On Dec 8, 2005, at 9:28 AM, Branimir Maksimovic wrote: Also, I think that original problem of gethostbyname just hides real SSL problem as you've probably locked around that too, but you can't be really sure. so either lock around every SSL call with global mutex or set locks in C module then call Haskell or setup callbacks from Haskell, whichever way you prefer. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 PROTECTED] wrote: 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 instances for type `State' I do not want to do it the way Tomasz and John are suggesting below. I need the user of my library to supply their own a and be able to pattern match on it. In the library itself I just need Show and Eq a. The following does the trick (compiles, works) but sucks in its verbosity: data State a = Start | Stop | (Show a, Eq a) = State a instance Eq a = Eq (State a) where (State a) == (State b) = a == b Start == Start = True Stop == Stop = True _ == _ = False instance Show a = Show (State a) where show (State a) = show a show Start = Start show Stop = Stop On Dec 8, 2005, at 8:36 AM, 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. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 matches against data constructors
of the new State type result in that class context being added to the
type of a function. The derived instance of show pattern matches
against values of the state type, and there you have it. Here's an
excerpt from:
http://www.haskell.org/onlinereport/decls.html#user-defined-datatypes
For example, the declaration
data Eq a = Set a = NilSet | ConsSet a (Set a)
introduces a type constructor Set of kind *-*, and constructors
NilSet and ConsSet with types
NilSet :: forall a. Set a
ConsSet :: forall a. Eq a =a -Set a -Set a
In the example given, the overloaded type for ConsSet ensures that
ConsSet can only be applied to values whose type is an instance of the
class Eq. Pattern matching against ConsSet also gives rise to an Eq a
constraint. For example:
f (ConsSet a s) = a
the function f has inferred type Eq a = Set a - a. The context in
the data declaration has no other effect whatsoever.
This doesn't happen in the strangely existential version (which isn't
really making full use of the existential quantification) since such a
pattern matching rule doesn't apply there.
It's actually probably best to just leave the context off the type
altogether. Though this makes the type of the data constructors more
general, it probably won't cause any further trouble.
- Cale
On 08/12/05, Joel Reymont [EMAIL PROTECTED] wrote:
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 $ w { stack = (state, dispatcher):s }
data State a
= Start
| Stop
| (Show a, Eq a) = State a
instance Eq a = Eq (State a) where
(State a) == (State b) = a == b
Start == Start = True
Stop == Stop = True
_ == _ = False
instance Show a = Show (State a) where
show (State a) = show a
show Start = Start
show Stop = Stop
This version does not. Why does it require Eq in the ++ context? And
why doesn't the other version?
data (Show a, Eq a) = State a
= Start
| Stop
| State a
deriving (Eq, Show)
Could not deduce (Eq b) from the context (Show b)
arising from use of `show' at ./Script/Engine.hs:86:38-41
Probable fix: add (Eq b) to the type signature(s) for `push'
In the first argument of `(++)', namely `show state'
In the second argument of `(++)', namely `(show state) ++ onto the
stack'
--
http://wagerlabs.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] fptools mirror in darcs ready for testing
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 the repos specified a default 'darcs send' email address so that people do not have to guess where to send their patches. Yes, they will. Simon is thinking of having that be the appropriate [EMAIL PROTECTED] list. Right now, this isn't happening because there is no good place to send them. I think the cvs-* lists are fine. Speaking of which: how long do we want to keep this interim arrangement before switching to darcs completely? I'm not sure yet! So far I haven't used it in anger enough, though as Duncan points out it's hard to really use it until we can commit darcs changes using darcs. Certainly performance of the --partial tree seems good enough, though I don't like that I can't see the history for individual files. I can't get browsing to work using Trac: with the full darcs repository it takes too long to do anything (like 10 seconds to bring up a directory), and with the --partial one it can't browse propely, presumably because there isn't per-file history. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] String to Hash ?
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 structure. What would be the easiest way ? PS. Can anyone point me to a source/link where I can see more examples of using Hash-like structures ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 can (need?) completely avoid function types declarations, as i do -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 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 can (need?) completely avoid function types declarations, as i do -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 existentially quantified type? Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Verbosity of imperative code (was: Learning Haskell)
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 like the sequence function, but for pairs instead of lists). In this case, I believe it is as simple as import Control.Monad (liftM2) seqPair = liftM2 (,) seqPair = uncurry (liftM2 (,)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Differences in optimisiation with interactive and compiled mode
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 and load those instead. You'll see
something like:
Skipping Main ( search.hs, search.o )
Also note that your 'infinite' function is in the prelude. It's called 'cycle'.
- Cale
On 08/12/05, Branimir Maksimovic [EMAIL PROTECTED] wrote:
It seems that compiled programs run better then interactive ones.
Following program with GHC works with pretty good performance in comparison
to C++
one with similar but non recursive algorithm and beats it in memory
consumtion. It only takes
about 2mb of ram somehow when running compiled. I'm really amased.
But in interactive mode both GHC and Hugs fail due heap exhaustion and
running
takes ages.Please can someone explain why?
I intent to use only compiled Haskell anyway so GHC satisfies.
Greetings, Bane.
program performs search replace on a String
module Main where
import IO
main = do
hSetBuffering stdout LineBuffering
let sr = search
rp = replace
str= able search sea baker search charlie \
out = searchr sr rp (take (100*(length str)) $ infinite
str)
out1 = searchr sr rp (take (101*(length str)) $ infinite
str)
putStrLn $ Working: ++ sr ++ ++ rp ++ ++ str
putStrLn $ (show (out == out1)) ++ \n ++ \nDone\n
{- search replace able search baker search charlie -}
---
infinite xs = xs ++ infinite xs
searchr :: String-String-String - String
searchr [] _ xs = xs
searchr _ [] xs = xs
searchr _ _ [] = []
searchr sr rp xs | fst fnd = rp ++ searchr sr rp (snd $ snd fnd)
| otherwise = (reverse $ fst $ snd fnd) ++
searchr sr rp (snd $ snd fnd)
where fnd = searchr' sr xs
searchr' :: String-String-String - (Bool,(String,String))
searchr' (sr:srs) xs fndSoFar = searchr'' (sr:srs) xs fndSoFar sr
searchr'' :: String-String-String-Char - (Bool,(String,String))
searchr'' [] xs fnd _ = (True,(fnd,xs))
searchr'' _ [] fnd _ = (False,(fnd,[]))
searchr'' (sr:srs) (x:xs) fndSoFar s | sr == x = searchr'' srs xs xxs s
| otherwise = (False,searchr''' s xs
xxs) -- (False,(xxs,xs))
where xxs = x:fndSoFar
searchr''' :: Char-String-String - (String,String)
searchr''' sr [] fndSoFar = (fndSoFar,[])
searchr''' sr (x:xs) fndSoFar | sr /= x = searchr''' sr xs (x:fndSoFar)
| otherwise = (fndSoFar,x:xs)
---
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-conflicts] how to nicely implement phantom type coersion?
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 if this is possible in Haskell, and if it is, then it
definitely requires some sort of tricky extension that I'm not familiar
with...
I'm a bit confused, but if you have:
sc :: p a b - p a c
sc = unsafeCoerce#
then (with Either standing in for Patch, PatchList etc and some concrete
types as parameters to simplify things)
sc (undefined :: Either Int Char) :: Either Int Bool
is well-typed but
sc (undefined :: Either Int Char) :: Either String Char
isn't. Is that what you want?
Thanks
Ian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String to Hash ?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] String to Hash ?
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/ listToPair is probably not worth giving a name to, as it's so specific (it only works on lists of length 2) and such a short lambda term anyway. - Cale On 08/12/05, raptor [EMAIL PROTECTED] wrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Verbosity of imperative code (was: Learning Haskell)
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 non-monadic functions. Personally, I think that automatic lifting is unnecessary. Multi-parameter type classes for the numeric prelude, combined with occasional usage of LiftMn, should handle almost all the lifting without needing to extend the language (further). /g -- We have lingered in the chambers of the sea By sea-girls wreathed with seaweed red and brown Till human voices wake us, and we drown. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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 run-time overhead than GC does, unless the data structures involved are large. Why? I think the point with uniqueness typing/analysis is that this is done at *compile-time*. But the email asked if there were some other way of doing this using run-time techniques in the absence of such a type system (or at least, that was the way I understood it, and the spirit of my answer). 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 types but the compiler would infer uniqueness types internally and use the uniqueness information it gets from this. -Jan [...] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- 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 types but the compiler would infer uniqueness types internally and use the uniqueness information it gets from this. Right, that's what I was having in mind. See also http://www.haskell.org/pipermail/haskell-cafe/2005-December/012625.html Regards, zooloo -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- 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 more fragile and sensitive then current Haskell's space problems arising from laziness? ;-) Maybe it's just my lacking insight, but why should uniqueness inferring be all that fragile? 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 not work well the dumb way, like, trying every single combination out of n^2 possibilities, where n is the total node count.) Whatever suggestion gets through the uniqueness checker, the resulting code can't be consuming more space, slower, or otherwise worse than the one without reusing unique nodes, can it? On the other hand, performance gains thereby seem likely to me. It might be possible to get extremely fast code out of ghc, but as an overall impression, it's not easy, whilst Clean sort of gives it for granted (well, struggeling with wrongly assigned uniqueness attributes aside). Well, C sort of gives it for granted too, because it is very difficult to write inefficient, simple, specification-like code. I want to be able to write simple and elegant code, even if it is inefficient! errr..., could you give me some clue how you'd expect automatically uniqueness detection to deteriorate your coding style? I, for one, don't define elegance in terms of not running too fast. ;) I don't feel very comfortable either with the impact _explicit_ uniqueness attributing has on the ease of coding. Anyway, I am not arguing pro Clean but pro compile time sharing analysis here. To be honest, your reply feels like a counterpart to the likewise questionable monad avoidance in Clean. Regards, zooloo p. s.: Anyone knows what makes your cited mail appear in the list archive as beeing sent from my address? The copy I got to my mailbox is ok. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Differences in optimisiation with interactive and compiled mode
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 http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- 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 more fragile and sensitive then current Haskell's space problems arising from laziness? ;-) Why should inferring uniqueness be all that fragile? A uniqueness checker can be rather robust, as is demonstrated by the Clean one. Maybe I'm lacking insight, but to me it seems that 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 not work well the dumb way, like, trying every single combination out of n^2 possibilities, where n is the total node count.) Whatever suggestion gets through the uniqueness checker, the resulting code can't be consuming more space, slower, or otherwise worse than the one without reusing unique nodes, can it? On the other hand, performance gains thereby seem likely to me. It might be possible to get extremely fast code out of ghc, but as an overall impression, it's not easy, whilst Clean sort of gives it for granted (well, struggeling with wrongly assigned uniqueness attributes aside). Well, C sort of gives it for granted too, because it is very difficult to write inefficient, simple, specification-like code. I want to be able to write simple and elegant code, even if it is inefficient! errr..., could you give me some clue how you'd expect automatically uniqueness detection to deteriorate your coding style? I, for one, don't define elegance in terms of not running too fast. ;) I don't feel very comfortable either with the impact _explicit_ uniqueness attributing has on the ease of coding. Anyway, I am not arguing pro Clean but pro compile time sharing analysis here. To be honest, your reply feels like a counterpart to the likewise questionable monad avoidance in Clean. Regards, zooloo p.s.: Anyone knows what makes your (Tomasz's) cited mail appear in the list archive as beeing sent from my address? The copy I got to my mailbox correctly shows you as the sender. 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. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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 not work well the dumb way, like, trying every single combination out of n^2 possibilities, where n is the total node count.) You mean we need a way to detect which expressions are unique and which are not? This shouldn't be much of a problem. A uniqueness type system along the lines of Clean's one allows not only type checking but also type inference. For example, Clean is able to infer all the possible uniqueness annotations for you. One could build a similar thing into a Haskell compiler. [...] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] fptools mirror in darcs ready for testing
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 frontends might be a better performer? If one of you knows a web frontend which provides similar features as Trac does (and maybe more) but is more darcs-friendly, please tell me. (By the way, I think there is also a bit of work under way to make Tracs work (better) with other systems than Subversion.) [...] -- John Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Indenting issue with Haskell mode
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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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, automatically inferred uniqueness typing - something that would be even more fragile and sensitive then current Haskell's space problems arising from laziness? ;-) Why should inferring uniqueness be all that fragile? It's just that I automatically thought about how uniqueness typing is used in Clean, expecially as a way to achieve O(1) array update. It would be nice if Haskell could infer that an *immutable* array given as parameter to an update operation (like. //) can be reused to create the result effectively. But if you wrote code with such an optimisation in mind, you could be very disappointed with performance if the compiler didn't perform the optimisation. I think that in the case of arrays I would still prefer to use mutable arrays to be sure that my program has the desired asymptotic complexity. Maybe you didn't intend to propose it for arrays? It would be fine to use your idea for smaller, constant-size things, like records, etc, just to reduce the constant factor. A uniqueness checker can be rather robust, as is demonstrated by the Clean one. In Clean there is no surprise, because this optimisation is part of the type system, it's part of the language definition. Whatever suggestion gets through the uniqueness checker, the resulting code can't be consuming more space, slower, or otherwise worse than the one without reusing unique nodes, can it? It can be slower than the programmer expects, in terms of asymptotic complexity. So this feature could be difficult to use to create reliable, efficient code. Of course, unpredictabile efficiency of Haskell programs is not a new problem. It might be possible to get extremely fast code out of ghc, but as an overall impression, it's not easy, whilst Clean sort of gives it for granted (well, struggeling with wrongly assigned uniqueness attributes aside). Well, C sort of gives it for granted too, because it is very difficult to write inefficient, simple, specification-like code. I want to be able to write simple and elegant code, even if it is inefficient! errr..., could you give me some clue how you'd expect automatically uniqueness detection to deteriorate your coding style? I, for one, don't define elegance in terms of not running too fast. ;) I was referring to UT as in Clean, not to automatic UT you propose. You said Clean sort of gives it for granted, with it = extremely fast code. I don't yet know a language which _grants_ extremely fast code without being more low-level. OK, I am nitpicking ;-) To be honest, your reply feels like a counterpart to the likewise questionable monad avoidance in Clean. My english understanding skills failed me here. Could you expand this sentence using simpler words? Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: syntactic sugar for comonads
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 interested in comonads as well, but coming from a different perspective. Has anyone built a sufficiently large set of examples of instances of the Comonad typeclass yet? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Indenting issue with Haskell mode
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 seen yet. I don't have time to look into right now, but I've added it to the indent.hs file in the mean time. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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 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 enormous impact on the runtime of the code because you unknowningly changed a value from being used uniquely to being used non-uniquely. In clean, the annotations allow you to enforce the uniqueness, so this change would be caught by the type-checker. But, if the uniqueness is *only* inferred, then the user has to be very careful about ensuring uniqueness if they want performance gains associated with it -- and they have to do it without the help of the type-checker. Having written a bit of clean code, I can say that it is very easy to accidently un-uniquify things. Jeremy Shaw. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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 have a enormous impact on the runtime of the code because you unknowningly changed a value from being used uniquely to being used non-uniquely. In clean, the annotations allow you to enforce the uniqueness, so this change would be caught by the type-checker. But, if the uniqueness is *only* inferred, then the user has to be very careful about ensuring uniqueness if they want performance gains associated with it -- and they have to do it without the help of the type-checker. Having written a bit of clean code, I can say that it is very easy to accidently un-uniquify things. That's exactly my point, but I probably didn't express it as clearly as you did. Thanks! Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] busting up a structured binary file
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 determined. So I need to move along a number of bytes, take a few chunks of so many more bytes and grab the string and move on to the next record, dumping the contents - ultimately dumping it to XML. It'll need to run on windows so I guess I had better use Hugs. So a sample and any advice would be an excellent start for me, and would be greatly appreciated. Thanks Brian McQueen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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 enormous impact on the runtime of the code because you unknowningly changed a value from being used uniquely to being used non-uniquely. In clean, the annotations allow you to enforce the uniqueness, so this change would be caught by the type-checker. But, if the uniqueness is *only* inferred, then the user has to be very careful about ensuring uniqueness if they want performance gains associated with it -- and they have to do it without the help of the type-checker. Having written a bit of clean code, I can say that it is very easy to accidently un-uniquify things. This is an example of what I call clever compiler syndrome where the potential speed benefit of an optimisation is rendered much less useful. If you need the speed gained by the optimisation kicking in then you need to be able to guarantee it, or at least accurately check that is is kicking in. So if it can be lost by simple and non-obvious code changes then you cannot rely on the optimisation and so it is not useful. 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 optimisation it in the first place. We already have this issue in Haskell with strictness. I think what we need is better performance and source code analysis tools, which might simply be viewers for information produced by the compiler about what it's optimisation analysis algorithms are actually coming up with. 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. So if it were easy to find out the uniqueness that the compiler was inferring then it might actually be useful to people that it did such an inference. Since in that case they would be able to check that it was actually kicking in and modify their code if it were not. You would also want to be able to ask the questions why is it not unique here when I expect it to be, just like the compiler currently answers our question of why the type is not what we expect it to be at some place in the program. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] preffered 'map'
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. tia. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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 if we had better strictness annotations available more generally, too. So if it were easy to find out the uniqueness that the compiler was inferring then it might actually be useful to people that it did such an inference. 'twould be nice for type checking in general, although it's more the typing than just the types that's useful. -- [EMAIL PROTECTED] My religion says so explains your beliefs. But it doesn't explain why I should hold them as well, let alone be restricted by them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] preffered 'map'
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 use Hugs, 'cause error messages are more understandable. The recommended way to use Data.Map is like so: import qualified Data.Map as Map then ordinary map still refers to Prelude.map. All Data.Map operations then need to be qualified with Map. For example: Map.empty, Map.insert, etc. So that you don't have to say Map.Map for the type name some people also add: import Data.Map (Map) so that the type name is imported unqualified. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Existentially-quantified constructors, Eq and Show
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 Thursday, December 08, 2005, 3:43:56 PM, you wrote: JR Doesn't this have an effect on performance? JR Is GHC still able to optimize things properly? JR 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 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 can (need?) completely avoid function types declarations, as i do JR -- JR http://wagerlabs.com/ -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
- 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 optimisation it in the first place. If you prefer consistently slower code to accidentilly faster one, you can still turn off the optimisations of your choice. :) We already have this issue in Haskell with strictness. This holds for nearly every automatical optimisation, doesn't it? So if it were easy to find out the uniqueness that the compiler was inferring then it might actually be useful to people that it did such an inference. Since in that case they would be able to check that it was actually kicking in and modify their code if it were not. You would also want to be able to ask the questions why is it not unique here when I expect it to be, just like the compiler currently answers our question of why the type is not what we expect it to be at some place in the program. Duncan I couldn't agree more. Regards, zooloo p.s.: Strangely, Tomasz's reply again appears as being sent from my address in the archive. Anyone knows why? p.p.s: At least as weirdly, the first version of my duplicated mail unexpectedly _has_ shown up again (after more than 5 hours), whilst another, later message of mine was posted within minutes! Sorry everyone for the inconvenience. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to nicely implement phantom type coersion?
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 a a
(=//=) :: Patch a b - Patch c d - MaybeEq b c
Patch _ x =//= Patch y _
| x == y= unsafeCoerce# IsEq
| otherwise = NotEq
sequenceIfPossible :: Patch a b - Patch c d - Maybe (Sequential a d)
sequenceIfPossible p q
| IsEq - p =//= q = Just $ Sequential p q
| otherwise= Nothing
Notice the usefulness of pattern guards. EqContext could be defined as
data EqContext :: * - * - * where
EqWitness :: EqContext a a
(though I ususally prefer to just call both the data type and the
constructor 'E'.)
Thomas
On Thu, 2005-12-08 at 09:23 -0500, David Roundy wrote:
The trickiness is that we need to be able to check for equality of two
patches, and if they are truly equal, then we know that their ending states
are also equal. We do this with a couple of operators:
(=\/=) :: Patch a b - Patch a c - Maybe (EqContext b c)
(=/\=) :: Patch a z - Patch b z - Maybe (EqContext a b)
data EqContext a b =
EqContext { coerce_start :: Patch a z - Patch b z,
coerce_end :: Patch z a - Patch z b,
backwards_coerce_start :: Patch b z - Patch a z,
backwards_coerce_end :: Patch z b - Patch z a
}
where we use the EqContext to encapsulate unsafeCoerce so that it can only
be used safely. The problem is that it's tedious figuring out whether to
use coerce_start or coerce_end, or backwards_coerce_end, etc. Of course,
the huge advantage is that you can't use these functions to write buggy
code (at least in the sense of breaking the static enforcement of patch
ordering).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] STM reference?
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 Scherrer Computational Mathematics Group Pacific Northwest National Laboratory Time flies like an arrow; fruit flies like a banana. -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
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 Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-conflicts] how to nicely implement phantom type coersion?
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 phantom types: http://www.informatik.uni-bonn.de/~ralf/publications/With.pdf The first (in section 2.4) explains a limitation of :=: I highly recommend both papers. Jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] STM reference?
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 language, but monads are fairly comfortable for me. STM is just additional instrument, you can completely avoid it (as we had do until 6.4 release). Below is a list of papers related to imperative programming in Haskell. first contains pragmatic introduction in this world, including all concurrency stuffs, second is about an real high-concurrency application designed by GHC team. other papers is of more theoretical (and more strict) character Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell [http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/marktoberdorf.ps.gz] Writing High-Performance Server Applications in Haskell, Case Study: A Haskell Web Server, [http://www.haskell.org/~simonmar/papers/web-server.ps.gz] [http://www.haskell.org/ghc/docs/papers/concurrent-haskell.ps.gz] [http://www.haskell.org/~simonmar/papers/conc-ffi.pdf] The Concurrent Haskell Foreign Function Interface [http://www.haskell.org/ghc/docs/papers/threads.ps.gz] Asynchronous Exceptions in Haskell [http://www.haskell.org/~simonmar/papers/async.ps.gz] [http://research.microsoft.com/~simonpj/papers/stm/stm.pdf] [http://www.haskell.org/ghc/docs/papers/except_ps.gz] Imperative Functional Programming [http://www.haskell.org/ghc/docs/papers/imperative.ps.gz] -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
