Benjamin Franksen wrote:
I still have problems. They are probably due to a wrong definition of the
operator (#). Note that (#) is nowhere defined inside the HList sources, so I
assumed an inverse application aoperator. This is my program now:
No, # is the record selection operator from the
On Monday 29 November 2004 21:47, Keean Schupke wrote:
Benjamin Franksen wrote:
I still have problems. They are probably due to a wrong definition of the
operator (#). Note that (#) is nowhere defined inside the HList sources,
so I assumed an inverse application operator. This is my program
Benjamin Franksen wrote:
Of course, stupid me. Ok, I changed that. Still won't compile. I post
only the
first of four type errors (they are all about 40 lines long; note that the
inferred type below is almost longer than the complete test program).
You'd probably need this as well:
{-#
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 of
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,
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
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
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 complete
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 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 Clean
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
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
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, 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, 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 language.
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 that is declared, say `IO
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
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
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 does the
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 functions and
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 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
function that reads in
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_ a
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 foldr
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
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 language.
[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 sound
[EMAIL PROTECTED] wrote,
Manuel M. T. Chakravarty writes:
[EMAIL PROTECTED] wrote,
I'm not surprised you are puzzled. Concurrent Haskell, as
implemented in ghc, does NOT preserve referential
transparency, nor could it.
Of course it does! If it wouldn't many of the
Manuel M. T. Chakravarty writes:
[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
Tim [EMAIL PROTECTED] wrote:
For example, consider a program where one thread prints a value from an MVar,
while another thread modifies it. The output of the program will vary from one
run to another, even though its input (none) is unchanged.
This is not a result of using concurrency.
You
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
result of
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 just
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 about
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, potentially
On Thu 07 Oct, [EMAIL PROTECTED] wrote:
See the paper "Concurrent Haskell" by Simon Peyton Jones, Andrew Gordon and
Sigbjorn Finne, which states:
"forkIO :: IO () - IO () forkIO a is an action which takes an action, a, as
its argument and spawns a concurrent process to perform that action.
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 library for
s, passing by value / by reference / by name, deep and shallow
copying, evaluation of arguments of and ||, uninitialized variables.
And now you come and propose things to make Haskell more OO, changing
the things I like the most and adding exactly what I think that OO
gets wrong :-)
I don't say t
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
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
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 system I
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, and
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.
- Syntactic
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
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 significance of
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
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
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 get
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
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
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,
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
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 Haskell;
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
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 many times
"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
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
because you do seem
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++ but
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 of the Foo
technically tricky, directions.
It may be worth looking at least, if you're certain existing MPC
implentations don't allow everything you want to do with containers.
Yes MPC is too limiting. I have tried. See my post "Limititions of
Haskell Type System (was Re: OO in Haskell)".
Ok
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 programming styles
...
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 has
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 types.
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 rectangle.
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
On Mon, 27 Sep 1999, Alex Ferguson wrote:
Kevin Atkinson, replying to me:
If I understand you correctly, then the best way of doing this would be
with existentially (boundedly) quantified data types, currently a
non-standard extention present in hbc (and I think, ghc, these days, not
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 width of
66 matches
Mail list logo
