Re: URI handling code in Haskell available
On Wed, 5 Mar 2003, Graham Klyne wrote: > I've released a first version of some URI parsing and handling code at: >http://www.ninebynine.org./Software/HaskellURI.zip but this library is already in ghc: http://www.haskell.org/ghc/docs/latest/html/network/Network.URI.html best regards -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/207 -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: int to float problem
> I agree with what you said, > but I think you may have missed my point. Sounds likely on both counts. The same thing annoys me, but my work is in exact or symbolic: -- I don't claim this is a practical example -- I'm just saying that it is logically plausible denominator 2 % 3 == 3 denominator 23 == 1 --- only works because 23 might mean 23%1 denominator (floor (23 % 45)) == type error in application. So now I have to say ... denominator $ fromInteger (floor (23 % 45)) Is this the same malarkey that you are complaining about? I don't like using the conversions, so I generally try to find some way to rephrase the problem at a higher level. So, you want some way to define a default manner in which other types can be mapped to the type that is used in the definition of the function? (Do I understand correctly)? I can see merit in this, someone might use, floor xor ceiling, to shoehorn a float into and integer function. Getting different answers. On the other hand, it looks like ad-hoc polymorphism. I mean you are requesting that we can write a function myIntFn :: Integer -> Integer and then define a default mapping for each type into integers. So what if I define functions myFloatInt, myRatioIntInt, etc, to be used by default when the "wrong" type is presented as argument. Such that the range of each of these is distinct. In this way myIntFn can actually map Floats and Ratio Ints in totally different ways. That is, such a mechanism is very close to the ad-hoc polymorphism C++ style ... myIntFn :: Integer -> Integer myIntFn x = 2*x myIntFn :: Float -> Float myIntFn x = x*x and so on. Don't get me wrong, I am not fundamentally opposed to ad-hoc polymorphism, in fact ... (Ok, don't get me onto the subject of polymorphism). > In the definition of w, the fromIntegrals serve no purpose > other than to make everything type. This seems to go > against the merits of declarative programming. I feel were you are coming from here ... but I wonder if the issue is more the problem that Int is not a subset of Float. That is, the matter that (1 :: Integer) and (1 :: Float) are not represented the same in the computer means that they really are not in a subset hierarchy. A conversion is a non trivial operation (not just a projection) I just don't feel we can miss out this point. We (as programmers) are pretending that the Floats and Integers are a model of reals and integers. But, they are not, so we have to write our program in such a way that we make up for the sense in which they are not. Ultimately, float is what it is ... not a real number. The fact that we can write programs to get a good approximation to certain real results, using floats, shows that we are good at compensating for the distinction. I don't think that it goes against the merits of declarative programming, rather (once again) declarative programming is causing us to have to recognise the reality of the situation. (In this case that real arithmetic is non computable). Mind you, maybe having to recognise the reality is a form of demerit. Regards Bruce. ps: Parametric polymorphism only works because other operators available are ad-hoc polymorphic :p ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: int to float problem (resend with addendum)
[EMAIL PROTECTED] wrote: > Basically, from the algebraic perspective, the float type is > a messy fudge, and does not fit in nicely with any of the > "pure" types. In general the containment I agree with what you said, but I think you may have missed my point. In numeric programming, at least what I am currently working on, numeric types are very often mixed. With all of the syntactic sugar that Haskell has to make the progarmmer's life easier, and programs easier to read, I find it odd that there is no mechanism to control implicit type coersion. The two biggest examples I can think of are Int to Float (or Double) and Float to Complex Float. Consinder a direct translation of a discrete Fourier transform > dft :: Array Int (Complex Double) -> Array Int (Complex Double) > dft a = dft' a w n > where w = listArray (0,n-1) [ cis (-2 * pi * fromIntegral i / fromIntegral n) | > i <- [0..(n-0)] ] > n = snd (bounds a) + 1 > dft' :: Array Int (Complex Double) -> Array Int (Complex Double) -> Int -> Array Int > (Complex Double) > dft' a w n = listArray (0,n-1) [ sum [ a!k * wik i k | k <- [0..(n-1)] ] | i <- > [0..(n-1)] ]) > where wik i k = w!(i*k `mod` n) In the defintion of w, the fromIntegrals serve no purpose other than to make everything type. This seems to go against the merits of declarative programming. Also consider the multiplication of a Complex Double by a Double. There are two ways to do this. One is to make the scalar a complex, but this turns what should be two multiplications into four mults and two adds if the zero valued imaginary term doesn't get optimized out. > scale1 :: Complex Double -> Double -> Complex Double > scale1 z x = z * (x :+ 0) The second way to handle this is to expand the complex term into real and imaginary parts, and do the multiplication. > scale2 :: Complex Double -> Double -> Complex Double > scale2 (zr :+ zi) x = (zr * x) :+ (zi * x) Again, these two methods are needed only to make the functions type. I am not advocating C / FORTRAN style type coersion. What I am wishing for is a per module or per function mechanism for giving the programmer a way to state how coersion should take place, with the default being none. A new language feature would be great, but I would settle for a pragma. -- Matthew Donadio ([EMAIL PROTECTED]) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Function wows
Hello, > frombin :: [Bit] -> Int > > frombin [] = 0 > > frombin (n:ns) = sum (n:( frombin (map (*2) ns))) frombin takes a list of Bits and returns an Int, but (:) needs a list as its second argument. Try something like > frombin (n:ns) = n + 2*(frombin ns) or >frombin = foldr (\x y->x+2*y) 0 Ciao, Steffen ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
(no subject)
To <[EMAIL PROTECTED]> Subject: Re: int to float problem In-Reply-To: <[EMAIL PROTECTED]> Yo, > Haskell Integers are not a proper subset of Haskell Floats or > Doubles. Haskell does not support real numbers. I'd just like to add ... Real numbers are not implementable on a digital computer. This is not a "practical" matter of resources, or a design decision in by the language designer, but the fact that any data type each of whose elements are represented in a finite number of bytes can't have more than a countable number of data elements. Integers, and Rationals can be represented. Even the so-called computable-real-numbers, (still countable) don't work as well as you would want, since things such as "is this number bigger than that one" can't always be computed. Add to this the fact that the generic float type does not satisfy algebraic constraints such as associativity, and so can't, from the axiomatic point of view, be considered to be a representation of rational numbers (let alone reals). Basically, from the algebraic perspective, the float type is a messy fudge, and does not fit in nicely with any of the "pure" types. In general the containment Complex ---> Real --> Rational ---> integer ---> whatever. Does not apply in this simple way to numerical types on a computer, because data types are often constructed on the basis of not just what they represent, but also how they represent these things. The computable world (constructive mathematics) is a lot more complicated and open ended than the existential approach. Regards, Bruce. ps: I've made previous comments about this sort of thing: ``Algebraic Conversions'', A mathematical paper introducing a generalisation of homomorphism of universal algebras. In Research Letters in the Information and Mathematical Sciences Vol 2, May 2001. (pub by Massey University New Zealand). see also, \verb|http://www.massey.ac.nz/~wwiims/rlims| ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Conway's Life
I'm implementing Conway's Life in Haskell; my basic implementation is attached. Does anyone have suggestions for optimizations (or alternative representations)? It's interesting to note that the difference between this with no ghc optimization, -O, and -O2 is pretty striking; on my computer, it's about seven seconds, two seconds, and one second runtime, respectively. Abe module Main where import Data.Array.IArray import Data.Array.Unboxed import Data.Ix import System.Random type Grid = UArray (Int, Int) Int randomGrid :: (RandomGen g) => g -> Int -> Grid randomGrid g s = listArray b $ map (\x -> if x then 1 else 0) $ take (rangeSize b) $ randoms g where b = ((0,0),(s-1,s-1)) getCell :: Grid -> (Int, Int) -> Int getCell g c@(x,y) = if (x < xmin) || (x > xmax) || (y < ymin) || (y >= ymax) then 0 else g ! c where ((xmin, ymin), (xmax, ymax)) = bounds g update :: Grid -> Grid update g = array (bounds g) $ map aux $ assocs g where aux (c@(x,y),e) = let around = map (getCell g) $ filter (/= (x,y)) $ range ((x-1,y-1),(x+1,y+1)) in (c,rule (sum around) e) rule 2 e = e rule 3 e = 1 rule _ _ = 0 printGrid :: Grid -> IO () printGrid g = do let ((xmin, ymin), (xmax, ymax)) = bounds g mapM_ aux $ map (\x -> range ((x,ymin),(x,ymax))) [xmin..xmax] putStrLn "" where aux ixs = do mapM_ (putStr . show) $ map (g!) ixs putStrLn "" main :: IO () main = printGrid $ (iterate update (randomGrid (mkStdGen 0) 50)) !! 100
Re: fundeps for extended Monad definition
Ashley Yakeley wrote: > If this were allowed, it would effectively allow type-lambda > class C a b | a -> b > instance C Int Bool > instance C Bool Char > newtype T a = MkT (forall b.(C a b) => b) > helperIn :: (forall b.(C a b) => b) -> T a > helperIn b = MkT b; -- currently won't work > helperOut :: T a -> (forall b.(C a b) => b) > helperOut (MkT b) = b And it does work (based on the code shown here previously): > class C a b | a -> b > instance C Int Bool > instance C Bool Char > instance C Char Float > instance C Float (Int->()) > instance (C a b) => C (a->()) (b->()) > newtype T a = T (forall b.(C a b) => b) > data T1 a = T1 a (T a) > xx b = case (T1 b (T undefined)) of T1 _ (T x) -> x Ok, modules loaded: Main. *Main> :type xx$(1::Int) Bool *Main> :type xx$ xx$ (1::Int) Char *Main> :type xx$ xx$ xx$ (1::Int) Float *Main> :type xx$ xx$ xx$ xx$ (1::Int) Int -> () *Main> :type xx$ xx$ xx$ xx$ xx$ (1::Int) Bool -> () *Main> :type xx$ xx$ xx$ xx$ xx$ xx$ (1::Int) Char -> () *Main> :type xx$ xx$ xx$ xx$ xx$ xx$ xx$ (1::Int) Float -> () *Main> :type xx$ xx$ xx$ xx$ xx$ xx$ xx$ xx$ (1::Int) (Int -> ()) -> () *Main> :type xx$ xx$ xx$ xx$ xx$ xx$ xx$ xx$ xx$ (1::Int) (Bool -> ()) -> () *Main> :type xx$ xx$ xx$ xx$ xx$ xx$ xx$ xx$ xx$ xx$ (1::Int) (Char -> ()) -> () It seems it does compute The principle was to use constraints to force the "evaluation" of the type "lambda". Obtaining the type "lambda" was the thrust behind the exercise with existential and useless types. Perhaps I neglected to mention that point. We can use the Coerce type function (aka class) mentioned in the thread on first-class types to convert from the types computed by 'xx' to values. Incidentally, the class D was already a type function: the function 'meet'. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: int to float problem (resend with addendum)
I just fluffed the To: field in the header, so my previous message was bounced, I'm resending this ... sorry if it turns up twice. (I also took the opportunity to make an addendum). Yo, > Haskell Integers are not a proper subset of Haskell Floats or > Doubles. Haskell does not support real numbers. I'd just like to add ... Real numbers are not implementable on a digital computer. This is not a "practical" matter of resources, or a design decision in by the language designer, but the fact that any data type each of whose elements are represented in a finite number of bytes can't have more than a countable number of data elements. Integers, and Rationals can be represented. Even the so-called computable-real-numbers, (still countable) don't work as well as you would want, since things such as "is this number bigger than that one" can't always be computed. Add to this the fact that the generic float type does not satisfy algebraic constraints such as associativity, and so can't, from the axiomatic point of view, be considered to be a representation of rational numbers (let alone reals). Basically, from the algebraic perspective, the float type is a messy fudge, and does not fit in nicely with any of the "pure" types. In general the containment Complex ---> Real --> Rational ---> integer ---> whatever. Does not apply in this simple way to numerical types on a computer, because data types are often constructed on the basis of not just what they represent, but also how they represent these things. The computable world (constructive mathematics) is a lot more complicated and open ended than the existential approach. Regards, Bruce. ps: I've made previous comments about this sort of thing: ``Algebraic Conversions'', A mathematical paper introducing a generalisation of homomorphism of universal algebras. In Research Letters in the Information and Mathematical Sciences Vol 2, May 2001. (pub by Massey University New Zealand). see also, \verb|http://www.massey.ac.nz/~wwiims/rlims| Addendum: Personally I think that lattices of extension fields of the rationals give a good model for understanding what is going on with pure numerical types on digital computers, but maybe that's just me? ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Function wows
As part of a larger program I have created the following functions to convert a list of bits into the integer represents, also to simplify things the order of the bits is reversed [1,1,0,1] represents 1011 (or 13). At the moment the frombin function below works fine. type Bit = Int frombin :: [Bit] -> Int frombin xs = sum (tonum xs) tonum :: [Bit] -> [Bit] tonum [] = [] tonum (n:ns) = (n:(tonum (map (*2) ns))) However why when I try the function below does it not work in Hugs? frombin :: [Bit] -> Int frombin [] = 0 frombin (n:ns) = sum (n:( frombin (map (*2) ns))) Is this surely not just a combination of the two? Any help would be much appreciated Thanks, Rob --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.456 / Virus Database: 256 - Release Date: 18/02/2003
URI handling code in Haskell available
I've released a first version of some URI parsing and handling code at: http://www.ninebynine.org./Software/HaskellURI.zip With a (very) few words of write-up at: http://www.ninebynine.org./Software/ReadMe-URI-Haskell.txt The URI parser code is based very closely on the syntax specification given in Roy Fielding's current revision of the URI specification [1]. The unit tests are based substantially on Dan Connolly's Python code [2]. The code is a bit scrappy, as I'm new to Haskell, but it does pass a fairly comprehensive array of unit tests (also included with the software). Error handling is in the range of weak-to-non-existent. #g -- [1] http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html [2] http://www.w3.org/2000/10/swap/uripath.py --- Graham Klyne <[EMAIL PROTECTED]> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell Web Server Was Re: HTTP protocol libraries
"Bayley, Alistair" <[EMAIL PROTECTED]> writes: > On a related note, what happened to the source code for the Haskell Web > Server? > > http://research.microsoft.com/~simonmar/hws.tar.gz > > Is it no longer suitable for public consumption? (I have a copy at home > somewhere, though). There's also a neat version called HWS-WP (with plugins) that allows for apache-style plugin loading that uses Andre Pang's runtime loader for GHC. You can get it from the CVS tree of http://sf.net/projects/haskell-libs/ -- Shae Matijs Erisson - 2 days older than RFC0226 #haskell on irc.freenode.net - We Put the Funk in Funktion 10 PRINT "HELLO" 20 GOTO 10 ; mapM_ putStrLn $ hello = "HELLO" : hello ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: HTTP protocol libraries
> From: Bayley, Alistair [mailto:[EMAIL PROTECTED] > > On a related note, what happened to the source code for the > Haskell Web > Server? > > http://research.microsoft.com/~simonmar/hws.tar.gz > > Is it no longer suitable for public consumption? (I have a > copy at home somewhere, though). It's in GHC's CVS repository, under fptools/hws. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: HTTP protocol libraries
On a related note, what happened to the source code for the Haskell Web Server? http://research.microsoft.com/~simonmar/hws.tar.gz Is it no longer suitable for public consumption? (I have a copy at home somewhere, though). -Original Message- From: Johannes Waldmann [mailto:[EMAIL PROTECTED] Sent: 05 March 2003 13:42 To: [EMAIL PROTECTED] Subject: HTTP protocol libraries Dear all, I am looking for a Haskell library for the HTTP/1.1 protocol, i. e. data types for Requests and Responses, and functions to read chunked bodies etc. Is there such a thing? -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/207 -- * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
HTTP protocol libraries
Dear all, I am looking for a Haskell library for the HTTP/1.1 protocol, i. e. data types for Requests and Responses, and functions to read chunked bodies etc. Is there such a thing? -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/207 -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
AW: Parsec: GHC /= Hugs?
> Try the November release of Hugs with the +N option.
Well, now Hugs and ghc show the same behaviour for my program:
they don't parse my doc, even with the same error.
But the +N does not work: it says
"New hierarchical libraries not found along search path; ignoring +N
toggle."
I tried adding {Hugs}\libraries to the Options, but after a restart, it
is missing again. How can I change that?
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Parsec: GHC /= Hugs?
On Tue, Mar 04, 2003 at 04:00:53PM +0100, [EMAIL PROTECTED] wrote: > My program has a different behaviour under hugs and ghc. > > I wrote a very simple parser with Parsec and it parses a file quite easily - > as long as > I use hugs to run it. But when I compile it with ghc, the parse fails. > (I'm currently working on WinNT with cygwin). > > Something else, but related: how do I avoid writing different Code for Hugs > and ghc? Try the November release of Hugs with the +N option. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI for Windows
Hi Markus, I use FranTk with ghc 5.04.2 on windows, and it works just fine. It provides a high level of abstraction, which is what I find particularly compelling. To build it with ghc 5.04 I had to patch it a little. Only trivial things like: in src/FRPSrc/StaticTypes/Compatibility.ghc.hs, you have to define fromInt and toInt in terms of fromIntegral. in src/FranTkSrc/FranTkConc.lhs and src/TclHaskellSrc/ConcTcl.hs, you have to import CVar (I think that's all.) I could send you my patches if you like. cheers, Simon > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 03 March 2003 15:21 > To: [EMAIL PROTECTED] > Subject: GUI for Windows > > > What User Interface Library would you recommend for use under Windows? > I tried FranTk but it crashes as soon as I run the display > function (under > hugs) > and with ghc it won't even compile (I already tinkered with > the makefiles, > so > finally I could make the package, but then the demos won't compile). > > Any ideas, suggestions? > > Markus > > > ___ > Haskell mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, Berkshire. RG12 8FZ The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship.
Re: fundeps for extended Monad definition
In article
<[EMAIL PROTECTED]
ft.com>,
"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote:
> Here's a less complicated variant of the same problem:
>
> class C a b | a -> b where {}
>
> instance C Int Int where {}
>
> f :: (C Int b) => Int -> b
> f x = x
>
> Is the defn of f legal? Both GHC and Hugs reject it because the
> inferred type of f is more like
> C Int Int => Int -> Int
If this were allowed, it would effectively allow type-lambda. For
instance, I have a type function T that maps Int to Bool and Bool to
Char:
class C a b | a -> b
instance C Int Bool
instance C Bool Char
newtype T a = MkT (forall b.(C a b) => b)
helperIn :: (forall b.(C a b) => b) -> T a
helperIn b = MkT b; -- currently won't work
helperOut :: T a -> (forall b.(C a b) => b)
helperOut (MkT b) = b;
Here T is a type-constructor that does that. If I like, I can represent
Char as "T (T Int)", though of course I need to use the helper functions
to actually use it as a Char.
--
Ashley Yakeley, Seattle WA
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: First-class types
| 1) Coerce a a can be defined as coerce=id for all a. However, this |may of course lead to overlap in the type structure, so we must |write a separate instance definition for Coerce Int Int, Coerce |Double Double, etc. if we want types to be decidable. I'd love for |some clever person to solve this little difficulty. Indeed so. And instance Coerce a a where coerce = id does not overlap with instance Coerce Int Bool where ... instance Coerce Bool Int where ... There's no overlap here. (Overlap = there is a Coerce t1 t2, which matches more than one instance decl.) Furthermore, it works fine; I just tried it. | 2) When we define D a b c, we know that D b a c is also allowed. |Again, decidability prevents us from asserting this directly. |Again, a clever solution could save us a lot of code and even more |debugging. I suspect this may be a marginally easier nut to crack |than the previous one. Much harder, I think. Commutativity is always tricky! Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: big lambda in class declarations
Big lambda is in terms. You mean a "lambda at the type level", which is
usually written as a small lambda. Confusing, I know.
There's an ICFP02 paper on the subject, by Thiemann et al. Worth a
read.
Problem with inference is that the type checker can't guess lambdas.
Suppose we need to unify
m Int
with
ST Int Int
One possibility is
m = ST
Another is
m = \t. ST t Int
Another is
m = \t. ST Int t
One solution is to restrict what lambdas are allowable, and that is what
Thiemann et al do. Another is to declare the typechecker should never
guess a lambda; instead the programmer has to specify what lambda to use
whenever there is doubt. That is the approach that we're ruminating on
here. Stay tuned, but don't hold your breath.
Simon
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]
| Sent: 04 March 2003 16:34
| To: Haskell Mailing List
| Subject: big lambda in class declarations
|
| So the word on the street is that allowing big lambda makes type
inference
| undecidable. This makes sense to me since allowing big lambda
essentially
| allows you to program at the type level and thus of course you'll get
| undecidability.
|
| However, I'm having difficulty understanding where the undecidability
| sneaks in if you allow big lambda in class declarations. I suppose
the
| cannonical example is when you want to write something like:
|
| > class Set s where { ... }
| > instance Set (/\ a. FiniteMap a ()) where { ... }
|
| but now you have to write:
|
| > data FMSet a = FMSet (FiniteMap a ())
| > instance Set FMSet where { ... }
|
| The big lambda is of course equivalent to not applying type synonyms
| completely, somethign like:
|
| > type FM a = FiniteMap a ()
| > instance Set FM where { ... }
|
| will of course also be rejected (since this would give us a way to do
big
| lambda).
|
| Could some one help my intuition a bit here and explain to me how you
| could use big lambdas in class declarations to write programs?
|
| Thanks!
|
| - Hal
|
| --
| Hal Daume III | [EMAIL PROTECTED]
| "Arrest this man, he talks in maths." | www.isi.edu/~hdaume
|
| ___
| Haskell mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
