I should clarify my comment:
> If Clean has faster arrays than monadic arrays in
> Haskell, it is probably due to other issues, such as laziness.
I did not mean to imply that Haskell directly supports monadic arrays.
But it would be easy to add them in a library, and I believe one is
floating a
> So maybe, as you say, uniqueness typing would be useful in Haskell.
> It seems to give Clean a speed advantage for number/array crunching at
> present (or so I've heard, though I must confess I've never tried it
> in either language).
Unique types do not provide any efficiency advantage over a
On Tue 12 Oct, Kevin Atkinson wrote:
> I have been meaning to bring this up for quite some time. I think
> Haskell could really benefit from a uniqueness typing system as it would
> really simplify many things, such as fast array updates.
I have mixed feelings about uniqueness typing. The idea o
On 07-Oct-1999, Michael T. Richter <[EMAIL PROTECTED]> wrote:
> At 05:12 PM 10/7/99 , you wrote:
> > Sorry that I really can't explain well why I think that this concept
> > does not fit into Haskell. I must have heard that such "typecase"
> > is most often a bad design.
>
> In most situations, t
Lars Lundgren wrote:
>
> On Mon, 11 Oct 1999, Adrian Hey wrote:
>
> > On Mon 11 Oct, Lars Lundgren wrote:
> > > I'm sure a lot of poeple have gotten this wrong. I would be surprised if
> > > not all the experienced haskellers has this view though.
> >
> > Probably so, but this view seems in comp
On Mon 11 Oct, Lars Lundgren wrote:
> They also wrote "[The monadic IO approach] over determines order of
> evaluation". I'm a bit puzzled about that statement. Is it true? Comments
> anyone?
I think (but could be wrong) that it was a reference to the the
multiple environments approach, where the
On Mon, 11 Oct 1999, Adrian Hey wrote:
> On Mon 11 Oct, Lars Lundgren wrote:
> > I'm sure a lot of poeple have gotten this wrong. I would be surprised if
> > not all the experienced haskellers has this view though.
>
> Probably so, but this view seems in complete contradiction to
> that of the
On Mon 11 Oct, Lars Lundgren wrote:
> I'm sure a lot of poeple have gotten this wrong. I would be surprised if
> not all the experienced haskellers has this view though.
Probably so, but this view seems in complete contradiction to
that of the Clean world. So I'm still confused :-)
Regards
--
On Fri, 8 Oct 1999, Adrian Hey wrote:
> On Fri 08 Oct, Lars Lundgren wrote:
> > A value (IO a) *denotes* a program possibly interacting with the world.
> > *That* program is of course not referentially transparent. A haskell
> > program generating an (IO a) on the other hand *is* referetially
> >
Thu, 07 Oct 1999 19:13:34 -0400, Kevin Atkinson <[EMAIL PROTECTED]> pisze:
> One think I really think it needs is the ability to group a
> collection of functions with a tag. And then when importing a
> module you can ask to only import that tag. For example:
>
> module A
> list: head tail f
On Fri 08 Oct, Lars Lundgren wrote:
> A value (IO a) *denotes* a program possibly interacting with the world.
> *That* program is of course not referentially transparent. A haskell
> program generating an (IO a) on the other hand *is* referetially
> transparent.
So a value of type (IO a) is _not
On 08-Oct-1999, Adrian Hey <[EMAIL PROTECTED]> wrote:
> I think it's important
> to understand whether or not we really do have referential transparency
> with monadic IO, if other models of interaction between program and
> outside world are (like those in Concurrent Haskell) going to be rejected
On 08-Oct-1999, Adrian Hey <[EMAIL PROTECTED]> wrote:
> Reaction to my recent suggestion regarding IO (a concurrent non-deterministic
> machine) on the Clean discussion list was somewhat less than enthusiastic.
> One of the reasons was that apparently this would result in loss of
> referential tra
On 07-Oct-1999, Adrian Hey <[EMAIL PROTECTED]> wrote:
> This is another reason I'm sceptical about referential transparency in
> any functional system of IO (streams, monads, continuations, world as value..)
> It is hard to sensibly define interaction between a timeless universe
> of pure function
> -Original Message-
> From: Lars Lundgren [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 08, 1999 3:45 AM
> To: Adrian Hey
> Cc: [EMAIL PROTECTED]
> Subject: Re: OO in Haskell
>
> ...
>
> I'm really confused about all the fuzz about The IO m
On 07-Oct-1999, Adrian Hey <[EMAIL PROTECTED]> wrote:
> On Thu 07 Oct, Michael Hobbs wrote:
> > Michael Hobbs wrote:
> > > > Consider this:
> > > > > type IO a = StateOfUniverse -> (a, StateOfUniverse)
> > > > > -- Not syntactically correct, but you know what I mean.
> > > >
> > > > So anything th
On 07-Oct-1999, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Tue, 5 Oct 1999 14:10:26 -0400 (EDT), Kevin Atkinson <[EMAIL PROTECTED]> pisze:
>
> > 1) Dynamic types. You can't cast up. That is you can't recover the
> > original type from an object in a existential collection. You need
On Thu, 7 Oct 1999, Adrian Hey wrote:
> On Thu 07 Oct, Manuel M. T. Chakravarty wrote:
> > Check out the type signatures of the `MVar'-related
> > operations and you will find that they are all nicely
> > encapsulated in the `IO' monad.
>
> This is true, but I think the point of contention is
On Fri 08 Oct, Fergus Henderson wrote:
> > It is hard to sensibly define interaction between a timeless universe
> > of pure functions and values and a real universe which continually evolves
> > in real time. A state transformer method is about as good as you'll
> > get, but this requires that so
Hello again Fergus,
For some reason you have sent this message to me despite the fact that
all the words you appear to disagree with are those of Michael Hobbs:-)
However, I assume you also disagree with my words so I'll try to respond.
Unfortunately we've been over this ground before on another
On Thu 07 Oct, I wrote:
> On Wed 06 Oct, Johan Nordlander wrote:
> > Just to avoid any unfortunate misconceptions: O'Haskell definitely
> > preserves the property we commonly refer to as referential transparency,
> > and so does Concurrent Haskell, or any other sound monadic extension of
> > the l
On Thu 07 Oct, Jan Skibinski wrote:
> I think that the monadic IO provides us with such a
> simplification. As long as we realize what are its limitations
> and as long as we stay within reasonable limits of the concept
> we should be fine here. The operative word here is "realize".
> Do we really
On Thu 07 Oct, Joe English wrote:
> The way I understand the term "referntially transparent",
> it means that if you have
>
> let x = y in z
>
> then you can substitute all free occurrences of 'x' in 'z'
> with 'y', or vice versa, without changing the meaning of
> the expression. This is true i
On Thu 07 Oct, Marcin 'Qrczak' Kowalczyk wrote:
> In Haskell a `variable' can be meant to be either a name introduced
> by a let/where/lambda/case binding, or one of IORef/STRef/MVar (or
> even something in a custom monad). The first concept is referentially
> transparent, the second is not if we
On Thu 07 Oct, Michael Hobbs wrote:
> Michael Hobbs wrote:
> > > Consider this:
> > > > type IO a = StateOfUniverse -> (a, StateOfUniverse)
> > > > -- Not syntactically correct, but you know what I mean.
> > >
> > > So anything that is declared, say `IO Int', means that it is actually a
> > > func
On Thu 07 Oct, Manuel M. T. Chakravarty wrote:
> Check out the type signatures of the `MVar'-related
> operations and you will find that they are all nicely
> encapsulated in the `IO' monad.
This is true, but I think the point of contention is does the IO monad
itself provide referential transp
Tue, 5 Oct 1999 14:10:26 -0400 (EDT), Kevin Atkinson <[EMAIL PROTECTED]> pisze:
> 1) Dynamic types. You can't cast up. That is you can't recover the
> original type from an object in a existential collection. You need to
> use a dynamic type library for that. And the library proved with hugs
Marcin 'Qrczak' Kowalczyk wrote:
>
> Tue, 5 Oct 1999 14:10:26 -0400 (EDT), Kevin Atkinson <[EMAIL PROTECTED]> pisze:
>
> > 1) Dynamic types. You can't cast up. That is you can't recover the
> > original type from an object in a existential collection. You need to
> > use a dynamic type librar
At 05:12 PM 10/7/99 , you wrote:
> Sorry that I really can't explain well why I think that this concept
> does not fit into Haskell. I must have heard that such "typecase"
> is most often a bad design.
In most situations, type-casting is a symptom of bad design. The only C++
situation, for examp
Fri, 8 Oct 1999 01:22:43 +0100 (BST), Adrian Hey <[EMAIL PROTECTED]> pisze:
> I've read this paper, and it is good, but I still see no reason
> to change my opinion regarding referential transparency and IO.
> But I am terribly confused about this issue, there seems to be
> no real consensus abou
Adrian Hey writes:
> On Wed 06 Oct, Johan Nordlander wrote:
> > Just to avoid any unfortunate misconceptions: O'Haskell definitely
> > preserves the property we commonly refer to as referential transparency,
> > and so does Concurrent Haskell, or any other sound monadic extension of
> > the l
<[EMAIL PROTECTED]> wrote,
> Adrian Hey writes:
> > On Wed 06 Oct, Johan Nordlander wrote:
> > > Just to avoid any unfortunate misconceptions: O'Haskell definitely
> > > preserves the property we commonly refer to as referential transparency,
> > > and so does Concurrent Haskell, or any other
Here are some comments about the prevailing view that the
concept of the World or the Universe is safe to use in
any kind of arguments related to referential transparency.
I would be quite cautious here. I am not an expert on
these issues in relation to FP,
On Wed 06 Oct, Johan Nordlander wrote:
> Just to avoid any unfortunate misconceptions: O'Haskell definitely
> preserves the property we commonly refer to as referential transparency,
> and so does Concurrent Haskell, or any other sound monadic extension of
> the language.
Hmm, I obviously don't u
Michael Hobbs wrote:
> > Consider this:
> > > type IO a = StateOfUniverse -> (a, StateOfUniverse)
> > > -- Not syntactically correct, but you know what I mean.
> >
> > So anything that is declared, say `IO Int', means that it is actually a
> > function that reads in the state of the universe, pote
Michael Hobbs wrote:
>
> Adrian Hey wrote:
> > I've read this paper, and it is good, but I still see no reason to
> > change my opinion regarding referential transparency and IO.
> > But I am terribly confused about this issue, there seems to be no real
> > consensus about this in the FP world. I
Adrian Hey wrote:
> I've read this paper, and it is good, but I still see no reason to
> change my opinion regarding referential transparency and IO.
> But I am terribly confused about this issue, there seems to be no real
> consensus about this in the FP world. I just can't see how if the
> resul
On Wed 06 Oct, Alex Ferguson wrote:
> Me:
> > > Your 'partial' list would appear, from a initial
> > > inspection, to leave little left of either type safety or referential
> > > transparency.
>
> KA:
> > I can not see how State encapsulation will
> > weaken any type system.
>
> No, that's be
Kevin Atkinson wrote:
> Ok here is my partial list.
> [ . snip snip]
> - A solution to the abilities arising from multi parameter type classes.
Yes some kind of cooking guide for multi parameter type classes would be
nice. Where to use and where *not*. Sometimes I think multiple paramete
Kevin Atkinson wrote:
> Java is an evern cleaner language for OO as
questionable. Every *new* language should try to recycle the experience
gained from its predecessors. In the field of OO one thing springs to
my mind: The ability to extend/restrict the signature of a member function
in deri
Kevin Atkinson wrote:
> I don't like
> languages that try to stay simple because doing complex things in simple
> languages in well, frustrating. Can you agree with me here?
What exactly do you mean ? I can put together simple things to get
a complex tool that I can view again as a simple th
On 06-Oct-1999, Frank A. Christoph <[EMAIL PROTECTED]> wrote:
> Kevin Atkinson wrote:
> > Ok here is my partial list.
> >
> > - True ad-doc polymorphism
> > - Built in dynamic typing system.
> > - State Encapsulation
> > - A solution to the abilities arising from multi parameter type classes.
> >
Kevin Atkinson wrote:
> Ok here is my partial list.
>
> - True ad-doc polymorphism
> - Built in dynamic typing system.
> - State Encapsulation
> - A solution to the abilities arising from multi parameter type classes.
> - Syntactic sugar for supporting OO programming styles
What is the significan
On Wed, 6 Oct 1999, Simon Peyton-Jones wrote:
> Kevin writes:
>
I think it would be in Carlos interest to modify Marks sample
implantation of the type system to support this. Then we can really
see if his system will indeed work with the rest of Haskell.
Personally, I'm aga
On Wed, 6 Oct 1999, Simon Peyton-Jones wrote:
> Kevin writes:
>
> | I strongly agree that Haskell can become a *much* more
> | powerful language
> | with out losing any of clean syntax or semantics. However,
> | when ever I
> | bring up limitations of Haskell type system on this list I either
Adrian Hey writes:
> Hmm, I obviously don't understand what 'referential transparency' means.
> I must say I'm puzzled by statements like this. If the presence of
> mutable variables (and MVars in Concurrent Haskell) preserve referential
> transparency, then why _don't_ we have referential transp
Kevin Atkinson wrote:
>
> On Tue, 5 Oct 1999, George Russell wrote:
>
> > Perhaps I'm being stupid. (It certainly wouldn't be the first time!)
> > But what does OO give me that I can't get with existential types (in
> > datatype definitions) and multiparameter type classes? The latter seem
> >
Adrian Hey writes:
> Is referential transparency really such a sacred cow? Sometimes
> side effects are useful IMHO e.g. for IO. (Though the Cleaners regard
> IO as being referentially transparent for technical reasons which I
> don't quite understand.)
>
> I've been looking at Concurrent Haskell
Kevin writes:
| I strongly agree that Haskell can become a *much* more
| powerful language
| with out losing any of clean syntax or semantics. However,
| when ever I
| bring up limitations of Haskell type system on this list I either get
| ignorance or resistance.
I strongly agree that Haskel
Me:
> > Your 'partial' list would appear, from a initial
> > inspection, to leave little left of either type safety or referential
> > transparency.
KA:
> Could explain how they could. There is a very nice paper written up on
> True ad-hoc polymorphism. By a build in build in dynamic type s
Kevin Atkinson:
> I have a generic mutable array class which has a few basic methods:
>
> class MArray ... where
> newArray :: Int -> m (mutArray st el)
> write :: mutArray st el -> Int -> el -> m ()
> read :: mutArray st el -> Int -> m el
> freeze :: m mutArray st el -> m array el
>
; Neither of them will. Sorry if I implied a connection. What I DO need
> is a solution is a better solution to multi parameter classes.
> Yes MPC is too limiting. I have tried. See my post "Limititions of
> Haskell Type System (was Re: OO in Haskell)".
I did, but I'
Kevin Atkinson:
> I never, ever, said that I would like Haskell to be able to do
> everything C++ can.
No, that was my inference from the general drift of your comments.
I also never said that I want Haskell to become a
> more type unsafe language. If it was implied I'm sorry. What I did s
Kevin Atkinson and I argue about C++'s 'Cleaner more natural syntax':
> I would like to be able to do the things in Haskell that I can do in C++
> but currently Haskell's type system is too simple to allow me to do
> them. There are also some things I can't do in C++ but really wish I
> could, I
Kevin Atkinson <[EMAIL PROTECTED]> wrote:
> God NO, I like C++ because it is powerful but adding more features on an
> already ugly (but powerful languge) will make matters worse my making it
> more powerful but so ugly with so many pitfalls that no one will want to
> use it.
Some would say this
Alex Ferguson wrote:
>
> Kevin Atkinson:
>
> > I have a generic mutable array class which has a few basic methods:
> >
> > class MArray ... where
> > newArray :: Int -> m (mutArray st el)
> > write :: mutArray st el -> Int -> el -> m ()
> > read :: mutArray st el -> Int -> m el
> > freez
Jacob B Schwartz wrote:
> > - Built in dynamic typing system.
>
> Huh? Typing in Haskell is static. Liek I said, this removes a lot
> of run time errors. It also has performance benefits!! You don't have
> to store tags on all your data objects! And you don't have to spend
> time checking th
Theo Norvell writes:
>
>On Tue, 5 Oct 1999, Kevin Atkinson wrote:
>
>> In case you have not figured out a couple of months ago I posted the
>> beginnings of a generic container and algorithm collection for
>> Haskell.
>
> This is exactly the sort of thing that OOP tends to be rather bad at.
> How
Alex Ferguson wrote:
>
> Kevin Atkinson, replying to me...
>
> > > > - True ad-doc polymorphism
> > > > - Built in dynamic typing system
> > > > - State Encapsulation
> > > > - A solution to the abilities arising from multi parameter type classes.
> > > > - Syntactic sugar for supporting OO prog
Kevin Atkinson:
> > > 3) Encapsulation. You can't have private and protected members. Some
> > > of this can be done using modules. However it is more work.
> >
> > What exactly can't be done with classes, and how, substantively, is
> > it more work?
> class Foo
> private: -- only members
Kevin Atkinson wrote:
> Even through most problems don't truly fit in the OO paradigm, OO
> still is extremely useful. GUI are a prime example of what OO is good
> for.
point given. GUI are an area where OO is good.
> ... [OO] can greatly
> simplify complex problems into something manageable.
p
ocument, and some other papers, examine relaxing/generalising
> the rules for class defaults and overlapping instances, in many
> reasonable-seeming, though also technically tricky, directions.
> It may be worth looking at least, if you're certain existing MPC
> implentations don't allo
Kevin Atkinson:
> 2) More specific types, you can't _easilly_ call the more general type.
> For example in OO this is very commen:
>
> class Base
> virtual foo()
> do stuff
>
> class Derived, extends Base
> foo()
> call Base::foo()
> doo stuff
You can certainly do this in H
Alex Ferguson wrote:
>
> Kevin Atkinson and I argue about C++'s 'Cleaner more natural syntax':
> > I would like to be able to do the things in Haskell that I can do in C++
> > but currently Haskell's type system is too simple to allow me to do
> > them. There are also some things I can't do in C
Perhaps I'm being stupid. (It certainly wouldn't be the first time!)
But what does OO give me that I can't get with existential types
(in datatype definitions) and multiparameter type classes? The latter
seem to me much more powerful, since I can add dancing and singing methods
to objects without
Alex Ferguson wrote:
> > > > 4) Cleaner more natural syntax.
> > >
> > > More like C++, you mean?
> >
> > Or Java. Although many OO things can be done in Haskell C++ and Java
> > syntax is more natural more doing OO.
>
> If I sound a tad skeptical about some of your suggestions, it may be
> bec
"Hamilton Richards Jr." wrote:
>
> One of the more clear-eyed (IMHO) and successful authors of C++ texts is
> Cay Horstmann. A feature of his text, "Mastering C++" (Wiley, 1991), which
> I like is the section, appearing at the end of each chapter, entitled
> "Pitfalls" (the idea comes from Andrew
Kevin,
| In case you have not figured out a couple of months ago I posted the
| beginnings of a generic container and algorithm collection for
| Haskell. Duren the process of doing that I discovered the many
| limitations of Haskell current type system. I simply could not do what
| I wanted to
Kevin Atkinson wrote:
> Do you not like OO at all?
what good is OO for ? ;) OO gives me a framework/language to talk
about objects (read entities) and claims that with objects programmers
have the right tool to model real-world entities.
But the main thing in the real-world are *not* entities, th
Alex Ferguson wrote:
> That C++ has a very poor type system.
and Kevin Atkinson wrote in response:
> You are going to have to justify it as I thing C++ and Java has a VERY
> good type system minus the implicit typing system. In fact I *like* the
> C++ typeing system better than I do Haskell's in
On Tue, 5 Oct 1999, Kevin Atkinson wrote:
> In case you have not figured out a couple of months ago I posted the
> beginnings of a generic container and algorithm collection for
> Haskell.
This is exactly the sort of thing that OOP tends to be rather bad at.
How many times have I written in Java
At 2:01 PM -0500 10/5/1999, Kevin Atkinson wrote:
...
>And I can't not agree with you more.
Delightful!
It's in the same league as Dwight Eisenhower's response (to a
press-conference question):
"I couldn't help failing to agree with you less."
--HR
--
At 2:33 PM -0500 10/5/1999, Alex Ferguson wrote:
>... I'm unaware of any way in which C++ syntax is 'more natural',
>other than in the sense of 'for a C++ programmer', or 'cleaner' -- at all.
Having taught both C++ and Haskell for several years (each) to many
hundreds of undergraduate students fr
On Tue, 5 Oct 1999, Alex Ferguson wrote:
> > 3) Encapsulation. You can't have private and protected members. Some
> > of this can be done using modules. However it is more work.
>
> What exactly can't be done with classes, and how, substantively, is
> it more work?
class Foo
private: -- on
On Tue, 5 Oct 1999, Juergen Pfitzenmaier wrote:
> Kevin Atkinson wrote:
> > Even through most problems don't truly fit in the OO paradigm, OO
> > still is extremely useful. GUI are a prime example of what OO is good
> > for.
> point given. GUI are an area where OO is good.
>
> > ... [OO] can gr
On Tue, 5 Oct 1999, Theo Norvell wrote:
> On Tue, 5 Oct 1999, Kevin Atkinson wrote:
>
> > If there is enough interest I could repost this code as well as an
> > explanation of the many "hacks" I had to due to get around ambiguity
> > arising fro the use of multiple parameter classes and other
>
On Tue, 5 Oct 1999, George Russell wrote:
> Perhaps I'm being stupid. (It certainly wouldn't be the first time!)
> But what does OO give me that I can't get with existential types (in
> datatype definitions) and multiparameter type classes? The latter seem
> to me much more powerful, since I can
On Tue, 5 Oct 1999, George Russell wrote:
> Perhaps I'm being stupid. (It certainly wouldn't be the first time!)
> But what does OO give me that I can't get with existential types
> (in datatype definitions) and multiparameter type classes? The latter
> seem to me much more powerful, since I can
On Tue, 5 Oct 1999, Juergen Pfitzenmaier wrote:
> Alex Ferguson wrote:
> > That C++ has a very poor type system.
>
> and Kevin Atkinson wrote in response:
> > You are going to have to justify it as I thing C++ and Java has a VERY
> > good type system minus the implicit typing system. In fact I *
On Tue, 5 Oct 1999, Juergen Pfitzenmaier wrote:
> Kevin Atkinson wrote:
> > Do you not like OO at all?
>
> what good is OO for ? ;) OO gives me a framework/language to talk
> about objects (read entities) and claims that with objects programmers
> have the right tool to model real-world entities
Juergen Pfitzenmaier wrote:
>
> Kevin Atkinson wrote:
> > Do you not like OO at all?
>
> what good is OO for ? ;) OO gives me a framework/language to talk
> about objects (read entities) and claims that with objects programmers
> have the right tool to model real-world entities.
> But the main t
On 28-Sep-1999, Andreas C. Doering <[EMAIL PROTECTED]> wrote:
> > The trickier part is putting different types into a heterogenous
> > collection, and then manipulating according to their _individual_ types.
>
> If we are already at this point, a naive question:
>
> Assume we add the type of all
> The trickier part is putting different types into a heterogenous
> collection, and then manipulating according to their _individual_ types.
If we are already at this point, a naive question:
Assume we add the type of all types. Hence we can declare a
function, say from type to string, we can
> From [EMAIL PROTECTED] Mon Sep 27 18:50:33 1999
> X-Authentication-Warning: sun00pg2.wam.umd.edu: kevina owned process doing -bs
> Date: Mon, 27 Sep 1999 13:50:59 -0400 (EDT)
Kevin Atkinson:
> You have a collection of Shapes. Some of these shapes are circles,
> however, others are rectangl
Alex Ferguson wrote:
>
> Kevin Atkinson:
> > You have a collection of Shapes. Some of these shapes are circles,
> > however, others are rectangle. Occasionally you will need to extract
> > these specific shapes form the collection of generic shapes as there is no
> > way to find the length and
85 matches
Mail list logo
