Re: Reference types

At 2002-02-05 15:10, John Hughes wrote: >Oh no, please don't do this! I use the RefMonad class, but *without* the >dependency r -> m. Why not? Because I want to manipulate (for example) STRefs >in monads built on top of the ST monad via monad transformers. So I use the >same reference type with *

Re: Reference types

The basic bind operations etc are overloaded for IO and ST, but to overload the Ref operations one needs to add class RefMonad r m | r -> m, m -> r where newRef :: a -> m (r a) readRef :: r a -> m a writeRe

Re: Simpler Fibonacci function

On Tuesday, February 5, 2002, at 02:16 , Jeffrey R Lewis wrote: > On Tuesday 05 February 2002 09:40 am, Brian Berns wrote: >> I am new to functional programming and teaching myself Haskell. The >> canonical Haskell "fib" function (e.g. as presented in the "Gentle" >> tutorial) is: >> >>fib

Re: Reference types

At 2002-02-05 07:50, Simon Peyton-Jones wrote: > data Ref m a-- References in monad m, values of type a etc. You might be interested in: data Ref m a

Re: Implicit Parameters

> > My questiona are: Were the designers of the implicit > parameters paper aware of this problem when they wrote the > paper? If so, they probably did not think this was a big > problem. Do people in general think this is a problem? We certainly were aware. It is a problem, and a big one. The

Re: Simpler Fibonacci function

On Tuesday 05 February 2002 09:40 am, Brian Berns wrote: > I am new to functional programming and teaching myself Haskell. The > canonical Haskell "fib" function (e.g. as presented in the "Gentle" > tutorial) is: > >fib = 1 : 1 : [ a+b | (a,b) <- zip fib (tail fib) ] > > This seems, to be pol

Re: RFC: Syntax for implicit parameter bindings

As one of the authors let me give some responses. First of all, note that the implicit parameters paper did not attempt to give an account of implicit parameters that would fit seamlessly into Haskell. It was language feature within a hypothetical lambda calculus with its own type system etc. Ind

Re: Simpler Fibonacci function

> In any case, as a newbie, I can tell you that I found the fib > function puzzling as stated. > > > ...and not to show a "canonical" version of Fibonacci > > Nonetheless, it seems to have become the canonical version. For > example, see the list of references to this version on Google: > http:

RE: Simpler Fibonacci function

> The only reason the first version of fib was used in the Gentle Intro was to > demonstrate recursive stream processing... Thank you for the explanation. For reference, the fib example occurs in a section (3.4) titled "'Infinite' Data Structures", of which I believe the simpler function is also

Re: Simpler Fibonacci function

The only reason the first version of fib was used in the Gentle Intro was to demonstrate recursive stream processing, and not to show a "canonical" version of Fibonacci. Indeed, the sentence preceeding it says: "For another example of the use of circularity, the Fibonacci sequence can be computed

Simpler Fibonacci function

I am new to functional programming and teaching myself Haskell. The canonical Haskell "fib" function (e.g. as presented in the "Gentle" tutorial) is: fib = 1 : 1 : [ a+b | (a,b) <- zip fib (tail fib) ] This seems, to be polite, a bit overly complex. By comparison, here is a simpler version:

Re: Reference types

Hi Simon On Tue, 5 Feb 2002, Simon Peyton-Jones wrote: > 2. I'd be interested to know of any other examples you have of > *bi-directional* functional depenencies. The above simplification > nukes my only convincing example. (Usually one set of > type variables determines another,

RE: Reference types

Hi Simon, The one parameter scheme that you've described breaks down if you want to generalize further and allow something like: class RefMonad r m where new :: a -> m (r a) read :: r a -> m a write :: r a -> a -> m () instance RefMonad IORef IO where ... instance RefMonad

Re: Reference types

I applaud the simplification. Getting rid of multi parameter classes and functional dependencies is a Good Thing. Unfortunately I am worried about the extensibility of the new scheme. You replace two types, IORef a and STRef s a by a single type: > data Ref m a-- References in monad

Reference types

For some time now, GHC and Hugs have had the following families of types and operations: data IO a data IORef a newIORef :: a -> IO (IORef a) readIORef :: IORef a -> IO a writeIORef :: IORef a -> a -> IO () data ST s a data STRef s a

RE: Another Implicit Parameter Infelicity

GHC treats implicit parameters as a type scheme, not a type. As it happens, John Hughes's message to the list today discusses exactly this point. Simon | -Original Message- | From: Ashley Yakeley [mailto:[EMAIL PROTECTED]] | Sent: 04 February 2002 21:14 | To: Simon Peyton-Jones; Haskel

ANNOUNCE: GHC 5.03.20020204 snapshot release

There have been a number of significant improvements made to GHC since the 5.02 sources were branched off the main GHC development tree, but we're not quite ready to make a full 5.04 release yet. However, we're keen to get feedback on the new features from people that don't have easy access t

Re: Re: XSLT, Perl, Haskell, & a word on language design

On Tuesday 15 January 2002, 21:58:06, Eray Ozkural (exa) wrote: > On Wednesday 16 January 2002 04:35, Manuel M. T. Chakravarty wrote: > > > > The really bad thing is that the designers of XSLT [1.0] > > made the language free of side effects but then failed to > > include fundamental suppor

Re: why is this legal

On Sat, Feb 02, 2002 at 10:03:20AM -0500, Antony Courtney wrote: ||f x = f' 0 x ||where f' acc [] = acc || f acc (x:xs) = f' (x+acc) xs || Yes, these are all valid uses, which is why I would favor having the || compiler emit a warning in such circumstances. || || Inte

Re: Implicit Parameters

On Monday 04 February 2002 02:25 am, John Hughes wrote: > Not so fast! Proposing a "solution" means this is regarded as a "problem"! > But what is to say that the first behaviour is "right" in any general > sense? > > The important thing is that the