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.
On 28-Sep-1999, Alex Ferguson [EMAIL PROTECTED] wrote:
It would be interesting to investigate adding 'dynamic classes' to
Haskell, but it introduces the issue of what type to give the resulting
function: I think I'd want to clearly distinguish between a genuine
(boundedly) polymorphic
On 27-Sep-1999, Alex Ferguson [EMAIL PROTECTED] wrote:
Kevin Atkinson:
Yes but often putting things in type classes is tedious to do. I also
want to be able to overload not only on the TYPE of parameters but also
on the NUMBER of parameters. It IS possible to do these things and it
On 27-Sep-1999, Alex Ferguson [EMAIL PROTECTED] wrote:
Fergus Henderson, replying to me:
That's far from clear. Certainly, I don't think it's likely to be
reasonably possible a conversative extension.
[...]
Ad-hoc overloading and type inference don't mix so well, because
you can
On 27-Sep-1999, Alex Ferguson [EMAIL PROTECTED] wrote:
Fergus Henderson, replying to me:
ghc does not offer any facility for type class casts.
I'm not clear what's meant by this; are we speaking of some sort of
conversion to a common _type_, in some manner?
Well, roughly speaking, I'm
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, Frank A. Christoph wrote:
I must admit that I don't like the idea of determining a value based on its
type, at least in a language like Haskell. For me, functional programming is
about how to write programs combinatorially, and justifying your hypotheses
by encoding their
On 27-Sep-1999, Alex Ferguson [EMAIL PROTECTED] 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,
Fergus Henderson:
One example is the case where you already have existing code that
creates a heterogenous collection, and you want to extract an
element from that heterogenous collection, and then if it is
a member of a particular type class perform action A otherwise
perform action B,
Here is a laundry list of things I think Haskell still needs. By
Haskell here I mean Haskell plus extension that are found in both hugs
and ghc.
...
4) Being able to write
do a - getLine
b - getLine
proc a b
as
proc getLine getLine
and the like. I don't know the number
Oops, I left out the type context:
liftM2' :: (Monad m) = (a - b - m c) - (m a - m b - m c)
liftM2' proc m1 m2 = do
v1 - m1
v2 - m2
proc v1 v2
Oh, and here is a nicer definition:
import Monad
liftM2' :: (Monad m) = (a - b - m c) - (m a - m b - m c)
liftM2' proc m1 m2 = join $
Arthur Gold wrote:
Though I am _not_ exactly a Haskell expert, I could not avoid
commenting...
Kevin Atkinson wrote:
Here is a laundry list of things I think Haskell still needs. By
Haskell here I mean Haskell plus extension that are found in both hugs
and ghc.
1) Support for
Kevin Atkinson wrote:
[snip]
1) Support for true ad-hoc overloading.
[snip]
2) Support for TRUE OO style programming.
[snip]
4) Being able to write
do a - getLine
b - getLine
proc a b
as
proc getLine getLine
[snip]
AAARRRGGH no. I don't like overloading. For one thing it
"Frank A. Christoph" wrote:
Here is a laundry list of things I think Haskell still needs. By
Haskell here I mean Haskell plus extension that are found in both hugs
and ghc.
...
4) Being able to write
do a - getLine
b - getLine
proc a b
as
proc getLine getLine
For bigger things which
you want to identify, you can either use qualified module identifiers, or
Haskell's type classes which at least let you establish and codify a
motivation for using the same name for distinct things (namely, that their
types are equivalent under a particular relation).
I find that if you make liberal use of higher-order constructs and
modularize your code, then the need to do explicit binding is
not so much of
a problem. Then again, I am the sort of person who uses "let"
and "where"
whenever he can to name subexpressions as well...
But the point is
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
sure if it's with the same generality.)
On Mon, 27 Sep 1999, George Russell wrote:
Kevin Atkinson wrote:
[snip]
1) Support for true ad-hoc overloading.
[snip]
2) Support for TRUE OO style programming.
[snip]
4) Being able to write
do a - getLine
b - getLine
proc a b
as
proc getLine getLine
[snip]
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
Kevin Atkinson:
Yes but often putting things in type classes is tedious to do. I also
want to be able to overload not only on the TYPE of parameters but also
on the NUMBER of parameters. It IS possible to do these things and it
DOES make sense in a curing system.
That's far from clear.
On Mon, 27 Sep 1999, Alex Ferguson wrote:
* edited*
2) Support for TRUE OO style programming.
No. I mean being able to do things such as.
Have a collection of object of a common base class AND be able to up
cast them when necessary.
If I understand you correctly, then the
On Mon, 27 Sep 1999, Alex Ferguson wrote:
2) Support for TRUE OO style programming.
No. I mean being able to do things such as.
Have a collection of object of a common base class AND be able to up
cast them when necessary.
If I understand you correctly, then the best way of
Can some one please fill me in on why existential types are not
part of Haskell 98? Probably this is answered in some paper/statement
that I can read some where? I sort of understand them (* I am still
learning haskell. WOrking through S.T's book right now *) but
not enough perhaps to
On Tue, 28 Sep 1999, Fergus Henderson wrote:
That's far from clear. Certainly, I don't think it's likely to be
reasonably possible a conversative extension.
I think it could be.
However, whether it is in "the spirit of Haskell" is another question.
Mercury supports both type classes
Fergus Henderson, replying to me:
That's far from clear. Certainly, I don't think it's likely to be
reasonably possible a conversative extension.
[...]
Ad-hoc overloading and type inference don't mix so well, because
you can easily get ambiguities which the compiler cannot resolve.
Doesn't it also make it easier on new users that things with
different semantics have different names?
The main benefit of overloading is (in my view) to support constrained
polymorphism: an operation (or value) can be used for all types for
which there are certain (other) operations (or
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
Here is a laundry list of things I think Haskell still needs. By
Haskell here I mean Haskell plus extension that are found in both hugs
and ghc.
1) Support for true ad-hoc overloading. I am a *strong* believer that
if the context is clear for a human than it should be clear to the
computer.
29 matches
Mail list logo
