- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Haskell's overlooked object system: was OO idioms redux
by oleg＠pobox.com 14 Oct '04

14 Oct '04

Just to clarify: the intent of the OOHaskell paper is to show that Haskell, *as it is*, already has an OO system that is at least as powerful as that found in C++, Java, Eiffel, OCaml. Actually, it is strictly more powerful than the OO systems of C++, Java, Eiffel. In OCaml, the Object system is an extension, with its own extensive syntax and _quite non-trivial_ type system. We show that we can do the same in Haskell without any extensions, and roughly in the same syntax (that is, modulo the usual syntactic differences between non-OO OCaml and Haskell). It is not our intent to pass judgment as to whether an implementation inheritance or multiple inheritance are good or bad. We merely want to show: - if you want implementation inheritance, here's how you do it in Haskell, roughly in the same syntax as in other OO languages, and with the same semantics as in other OO languages - if you want interface inheritance, here's how you do it in Haskell, roughly in the same syntax and with the same semantics - if you want multiple inheritance, here's .... - if you want open recursion and selective closing of open recursion, here's ... Ditto for virtual and private methods, objects in ST monad, overriding, polymorphic classes and methods. I'd really like to hear if there are OO buzzwords we have missed... Again, we do *not* propose to extend Haskell in any way. We do not need to introduce special subclassing and subtyping judgments into the type system, deal with co- and contra-variance and the implicit weirdly-typed 'this', etc. The existing typechecker does all this for us. Our aim is to clarify the relation between object systems and typeclasses, to clarify various, often quite baroque, OO type systems, and provide a lightweight library and a set of guidelines to let one play with an OO of their preference using existing Haskell implementations. You can use as many or as few OO features in Haskell as you wish.

1 0

Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
by J.Garrett.Morris＠Dartmouth.EDU 13 Oct '04

13 Oct '04

--- Ketil Malde wrote: Or, what if String were one? Could we have painless read/show with arrays of Char, as well as lists, for instance? --- end of quote --- I think with a decent set of type classes for collections, better handling of strings would come for free. If any list function could be made implementation independent, then strings could still be treated as lists of chars, but the underlying implementation could be completely different (arrays, PackedStrings, etc.) /gXm

1 0

RE: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
by Simon Marlow 13 Oct '04

13 Oct '04

On 07 October 2004 18:23, Ketil Malde wrote: > Couldn't readFile et al. provide the standard interface, but use > hGetBuf tricks (e.g. from your 'wc' entry) behind the curtains? readFile does do buffering behind the scenes, that's not the problem. The problem is doing the computation on a [Char] instead of a raw buffer of bytes. There are various known techniques that could be used to speed up GHC's implementation of lists, none of which we've ever tried. This might be a good area for experimentation, if anyone's looking for something to do in GHC. Cheers, Simon

10 13

RE: [Haskell] is $ a no-op?
by Graham Klyne 13 Oct '04

13 Oct '04

[Switched to haskell-cafe] At 13:24 13/10/04 -0400, Jacques Carette wrote: > > > -- It's kind of like an converse map. > > > > I have attempted, unsuccessfully, to write flist above in a point-free > > manner. Is it possible? > > > Of course it is, but why? > > flist = flip (map . flip ($)) > >Some functions are simpler point-free, others are simpler with points. I >was curious about this one (I like the pointwise version better). > >Also, the statement "It's kind of like a converse map" becomes quite clear >from the point-free way to write it, while still not so obvious in the >pointwise version. The point-free form can be deduced thus, I think: flist fs a = map ($ a) fs (flip flist) a fs = map ($ a) fs -- swap flist args (flip flist) a = map ($ a) -- redundant arg (flip flist) a = map ((flip ($)) a) -- expand section (flip flist) a = (map . (flip ($))) a -- definition of . (flip flist) = map . (flip ($)) -- redundant arg flist = flip (map . (flip ($))) -- move flip to RHS #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Re: [Haskell] lazy constructors
by Serge D. Mechveliani 13 Oct '04

13 Oct '04

On Wed, Oct 13, 2004 at 10:06:44AM +0200, Sander Evers wrote: > > >Question 2 > >---------- > >How to arrange the above `lazy' output? > > > > > Your function addToSPair > > addToSPair :: Char -> (String, String) -> (String, String) > addToSPair c (xs, ys ) = (c:xs, ys ) > > does a strict pattern match on the pair constructor. It needs to know > that its second argument is a pair before it produces anything of its > result. If you use a lazy pattern match > > addToSPair :: Char -> (String, String) -> (String, String) > addToSPair c ~(xs, ys ) = (c:xs, ys ) > > instead, it doesn't need to evaluate this argument immediately. !! This is great, thank you. This improves a lot. I never recalled of the tilda for several years. Excuse me for the stupidity, but I have a next naive question. As the types are resolved before the computation, as the above program shows, how can addToSPair expect anything besides a string pair? Why tilda is not a default? --------------------------------------------- repeating: bottomStr :: String bottomStr = let xs = xs in xs bottomSPair :: (String, String) bottomSPair = let p = p in p longToReach = 10^8 :: Int f1, f2, g1, g2 :: Char f1 = head ('a' : (if last [1 .. longToReach] > 0 then "b" else "c")) f2 = head ('a' : bottomStr) addToSPair :: Char -> (String, String) -> (String, String) addToSPair c (xs, ys ) = (c:xs, ys ) g1 = head $ fst $ addToSPair 'a' (if last [1 .. longToReach] > 0 then ("b", "") else ("c", "")) g2 = head $ fst $ addToSPair 'a' bottomSPair ----------------------------------------------------------------- The only doubt may be the matching of (xs, ys) against bottom :: (String, String) Is not this natural to have a result as (bottom :: String, bottom :: String) -- = xs = ys and compute further? What will occur if all the Haskell programmers set `~' before each data constructor in each pattern in their existing programs? As the types are recognized before the computation, the programs will remain safe and will become considerably faster. For example, the above program of g1 becomes a billion times faster. I wonder. Copy, please, the answer to mechvel(a)botik.ru ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Re: [Haskell-cafe] Re: [Haskell] lazy constructors
by MR K P SCHUPKE 13 Oct '04

13 Oct '04

>addToSPair :: Char -> (String, String) -> (String, String) What about: addToSPair :: Char -> String -> String -> (String,String) so that the pattern match is: addToSPair c xs ys = (c:xs,ys) This is irrefutable? Keean.

1 0

Re: [Haskell] lazy constructors
by Serge D. Mechveliani 13 Oct '04

13 Oct '04

On Wed, Oct 13, 2004 at 09:23:43AM +0100, MR K P SCHUPKE wrote: > You can only return a list of pair's lazily, not > a pair of lists. If the two strings are independant, then > generate each in a separate function, and pair off the > results lazily. No, I have several labeled fields in a record, which are very dependent. As people teach, the costruct of ~(..,..) helps for the Pair. Maybe, the labeled record can also be handled ... ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: [Haskell-cafe] RE: [Haskell] lazy constructors
by MR K P SCHUPKE 13 Oct '04

13 Oct '04

>addToSPair c ~(xs, ys ) =3D (c:xs, ys ) I thought pattern bindings had an implicit "~"? Keean.

1 0

RE: [Haskell] lazy constructors
by Simon Peyton-Jones 13 Oct '04

13 Oct '04

[I think this thread would be more appropriate on haskell-café, so I'm redirecting it] | addToSPair :: Char -> (String, String) -> (String, String) | addToSPair c (xs, ys ) = (c:xs, ys ) | | --------------------------------------------------------------- | | g1 is similar to f1, g2 similar to f2. | | f1 and f2 are evaluated immediately to 'a'; | | g1 evaluates to 'a' after a long computation; | g2 evaluates to Fail: <<loop>> | | As g2 is similar to f2, should it have a value 'a' ? | In | head $ fst $ addToSPair 'a' bottomSPair Try using lazy pattern matching, thus addToSPair :: Char -> (String, String) -> (String, String) addToSPair c ~(xs, ys ) = (c:xs, ys ) The only change is the "~" in the defn of addToSPair. Now g2 will have value 'a'. Simon

1 0

strictness and the simple continued fraction
by William Lee Irwin III 13 Oct '04

13 Oct '04

So, I discovered that simple continued fractions are supposed to be spiffy lazy lists and thought I'd bang out some continued fraction code. But then I discovered ContFrac.hs and couldn't really better it. Of course, I went about trying to actually do things relying on their laziness, and discovered they weren't as lazy as I hoped they'd be. Simple uses of approximations at the ghci command line such as: instance Ord ContFrac where (ContFrac (x:xs)) `compare` (ContFrac (y:ys)) = case x `compare` y of LT -> LT GT -> GT EQ -> (ContFrac ys) `compare` (ContFrac xs) (ContFrac []) `compare` cf = case cf of ContFrac (x:_) -> 0 `compare` x ContFrac [] -> EQ cf `compare` (ContFrac []) = case cf of ContFrac (x:_) -> x `compare` 0 ContFrac [] -> EQ x = expCF (1/2) where expCF x | x < 0 = recip . expCF $ negate x | x == 0 = 1 | x == 1 = let ContFrac es = ecf in ContFrac (take 100 es) | otherwise = case x of ContFrac [y] -> (expCF 1)^y ContFrac (y:ys) -> if y /= 0 then ((expCF 1)^y) *(expCF (ContFrac (0:ys))) else (1+x+x^2/2+x^3/6+x^4/24+x^5/120) ContFrac [] -> expCF 0 where the instance was added to ContFrac.hs seems to fail to terminate, where manually reducing things a bit appears to restore termination. So, what hit me? -- wli

3 5