hi,
this is one of those situations that always make scheme and perl
hackers laugh at me: i have written a piece of code that is
intuitively clear, and now i am trying to turn it into something that
compiles. and here it goes.
i have a type class that looks something like this:
class
Title: RE: [Haskell-cafe] how would this be done? type classes? existentialtypes?
Try using a GADT:
data Rs where
Rs :: Resource a = a - Rs
class Resource a where
resourceName :: a - String
instance Resource String where
resourceName x = String
instance Resource Int where
this be done? type classes?
existentialtypes?
Try using a GADT:
data Rs where
Rs :: Resource a = a - Rs
class Resource a where
resourceName :: a - String
instance Resource String where
resourceName x = String
instance Resource Int where
resourceName x = Int
On Thu, Mar 16, 2006 at 12:40:00PM +, Chris Kuklewicz wrote:
(Why isn't it resourceName :: String ?)
because i am too clumsy. (-:
when i am trying this, ghc complains that the type of resourceName
doesn't have any occurrance of 'a', and i feel that it must be harder
for the type engine to
Alexandra Silva [EMAIL PROTECTED] wrote:
http://homepages.cwi.nl/~ralf/HList/
this looks like it might address my problems with Read / Eq
instantiation? will read.
thanks again to everybody.
m.
signature.asc
Description: Digital signature
___
[still talking to myself..?]
all confluence problems in the FD-CHR paper, as far as they were
not due to instances inconsistent with the FDs, seem to be due to
conflicts between improvement and inference rules. we restore
confluence by splitting these two constraint roles, letting inference
On 3/13/06, Claus Reinke [EMAIL PROTECTED] wrote:
[still talking to myself..?]
This is all wonderful stuff! Are you perhaps planning to put it all
together into a paper?
What effect do you think this can have on existing algorithms to resolve FDs?
--
Taral [EMAIL PROTECTED]
Computer science is
PM
Subject: Re: alternative translation of type classes to CHR(was:relaxedinstance
rules spec)
On 3/13/06, Claus Reinke [EMAIL PROTECTED] wrote:
[still talking to myself..?]
This is all wonderful stuff! Are you perhaps planning to put it all
together into a paper?
What effect do you think
a second oversight, in variation B: CHR rules are selected by matching,
not by unification (which is quite essential to modelling the way type
class inference works). this means that the idea of generating memo_
constraints for the instance fdis and relying on the clas fdi rules to
use that
Hi All,
I have been developing a type inference system which is very similar to type
classes' (by Wadler and Blott). However, I cannot find a detailed
description of the algorithm. In Type Classes in Haskell, implementation
issues are discussed briefly. However, it is too brief for me
robert wong writes (in the Haskell Cafe):
I have been developing a type inference system which is very similar to
type classes' (by Wadler and Blott). However, I cannot find a detailed
description of the algorithm. In Type Classes in Haskell,
implementation issues are discussed briefly
Ralf Lammel wrote:
What you can do is define a dedicated *type code* for composition.
comp = hFoldr (undefined::Comp) (id::Int - Int) test
data Comp
instance Apply Comp (x - y,y - z) (x - z)
where
apply _ (f,g) = g . f
That does it!
Thanks,
Greg Buchholz
On 11/6/05, Klaus Ostermann [EMAIL PROTECTED] wrote:
instance Node Person where isConnectedTo g n (p1,p2) = (p1 == n) || (p2 == n)
At this point, isConnectedTo knows nothing about the third argument
except that it is an edge, and there's no reason to think that an Edge
is a tuple. All you can say
all,
I am not a Haskell expert, and I am currently exploring type classes and
need some advice.
I want to define a family of mutually recursive types
as a collection of type classes and then I want to be able
to map these collections of types to a set of other types
using instance
Daniel Fischer schrieb:
I'd prefer (very strongly) something like
class Graph g n e | g - n, g - e where
isConnectedTo :: g - n - e - Bool -- or perhaps rather without g
startNode, endNode :: e - n
. . . -- other Methods of interest like nodes, edges, components . . .
with,
Am Sonntag, 6. November 2005 17:30 schrieb Klaus Ostermann:
Daniel Fischer schrieb:
I'd prefer (very strongly) something like
class Graph g n e | g - n, g - e where
isConnectedTo :: g - n - e - Bool -- or perhaps rather without
g startNode, endNode :: e - n
. . . -- other
Klaus Ostermann wrote:
I am not a Haskell expert, and I am currently exploring type classes
and need some advice.
The most important advice is probably to point out that a `class' in
Haskell is roughly comparable to an `interface' in Java, but not to a
`class'.
class Node n where
I was playing around with the HList library from the paper...
Strongly typed heterogeneous collections
http://homepages.cwi.nl/~ralf/HList/
...and I thought I'd try to fold the composition function (.) through a
heterogeneous list of functions, using hFoldr...
{-# OPTIONS
-Original Message-
From: [EMAIL PROTECTED] [mailto:haskell-cafe-
[EMAIL PROTECTED] On Behalf Of Greg Buchholz
Sent: Sunday, November 06, 2005 7:01 PM
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Type classes and hFoldr from HList
I was playing around with the HList library from
On 11/06/2005, at 11:18 PM, Thomas Sutton wrote:
In Java (C#, Python, etc) I'd do this by writing an interface
Formula and have a bunch of abstract classes (PropositionalFormula,
ModalFormula, PredicateFormula, etc) implement this interface, then
extend them into the connective classes
: [Haskell-cafe] Re: Using type classes for polymorphism of
dataconstructors
On 11/06/2005, at 11:18 PM, Thomas Sutton wrote:
In Java (C#, Python, etc) I'd do this by writing an interface
Formula and have a bunch of abstract classes (PropositionalFormula,
ModalFormula, PredicateFormula, etc
On 13/06/2005, at 8:29 PM, Henning Thielemann wrote:
On Sat, 11 Jun 2005, Thomas Sutton wrote:
The end goal in all of this is that the user (perhaps a logician
rather than a computer scientist) will describe the calculus they
wish to use in a simple DSL. This DSL will then be translated into
On Sat, 11 Jun 2005, Thomas Sutton wrote:
The end goal in all of this is that the user (perhaps a logician
rather than a computer scientist) will describe the calculus they
wish to use in a simple DSL. This DSL will then be translated into
Haskell and linked against some infrastructure
Hi all,
I've just started working on a theorem prover (labelled tableaux in
case anyone cares) in Haskell. In preparation, I've been attempting
to define some data types to represent logical formulae. As one of
the requirements of my project is generality (i.e. it must be easily
Alistair Bayley wrote:
There's a small problem: how to write a factory function that returns values
of various subtypes. The makeSubType function below won't compile, obviously
because the returns types are different (they're not the same 'm').
Indeed, expressions in both branches of an `if'
Hi Alistair!
Just a quick reply (I didn't had time to look at Ralf's technique).
Looking at your code, it seems to me that you are missing the notion of a
supertype (perhaps, that's the intended thing with BaseClass?).
I would use an existencial type to capture this notion:
===
data
Hi Bryn Keller,
The solution for your problem is very simple. You just have to fetch
all values as strings. In this way the library will do all required
conversions for you.
printRow stmt = do
id - getFieldValue stmt ID
code - getFieldValue stmt Code
name - getFieldValue stmt Name
My Advanced Programming course is quickly approaching the lectures on type
classes, and I am interested in finding a little more (beyond what's in SOE)
in the way of examples that illustrate nice uses (especially of more
advanced aspects of the class system). I'd be most grateful for pointers
syntax for this...
Some sort of operator for turning one or several type classes into an
interface datatype.
So you could write something like something like...
f :: Show,Num - [Show,Eq] - Eq,Num
f a xs = ...
So the first parameter is just a value of the interface datatype
data ShowNum = forall
syntax for this...
Some sort of operator for turning one or several type classes into an
interface datatype.
So you could write something like something like...
f :: Show,Num - [Show,Eq] - Eq,Num
f a xs = ...
So the first parameter is just a value of the interface datatype
data ShowNum = forall
See the HList library (http://www.cwi.ni/~ralf/HList) and use an HList
constrained by your interface.
Keean.
John Goerzen wrote:
Hi,
I often have a situation where I'm designing specialized components to
do a more general task. Examples could include mail folder code (maildir,
mbox, etc),
On the other hand, it's difficult or impossible to make a list of a
bunch of different types of things that have nothing in common save
being members of the class.
I've recently been playing with making, for each class C, a
interface datatype IC (appropriately universally and
Hi,
I often have a situation where I'm designing specialized components to
do a more general task. Examples could include mail folder code (maildir,
mbox, etc), configuration file parsing, protocol handlers for URL
accesses, logging backends, etc.
For some of these, I've used a data object
Major apologies for this repeated plug for HList.
Anyway, HLists [1] are *exactly* designed for this sort of problem.
Well, one can also use existential quantification + bounded polymorphism;
with the shapes benchmark providing a good example [2]. The trade-offs are
explored a little bit on the
On the other hand, it's difficult or impossible to make a list of a
bunch of different types of things that have nothing in common save
being members of the class.
I've recently been playing with making, for each class C, a
interface datatype IC (appropriately universally and existentially
Hi,
Daan said:
Personally, I feel that this problem might be better solved by
making a lot of the implicit assumptions (and semantics) of type
classes more explicit, and bring them under user control. Of course,
I do have not have any idea of how this should be done concretely
Hi,
Take a look at the following program, making use of
derivable type classes.
module Bug where
import Data.Generics
class Foo a where
foo :: a - Int
foo{| Unit |}_ = 1
foo{| a :*: b |} _ = 2
foo{| a :+: b |} _ = 3
instance Foo [a]
GHC 6.2.2 produces the following error
] On Behalf Of Koen Claessen
| Sent: 16 November 2004 17:17
| To: [EMAIL PROTECTED]
| Subject: Derivable type classes bug?
|
| Hi,
|
| Take a look at the following program, making use of
| derivable type classes.
|
|
| module Bug where
|
| import Data.Generics
|
| class Foo a where
| foo :: a - Int
Have been playing with the idea of a list class like
the one I posted earlier... but now a bit streamlined.
I have implemented wc using this class and a nice buffer
list. The result is something 4 times slower than the
current language-shootout code, but is rather neater.
The restriction on
Of course when I say it's neater - I mean if the List class
were defined in the libraries, so only the short definition
of 'wc' given at the beginning of my last post would be required!
Keean.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
I've been trying to put together a type-class based serialization (XML)
for types in GHC. Essentially the serializer class takes the form
class Seriliazer a where
serialize :: a - XmlFilter
This works very well, but I then wanted to make this system extensible,
so that for example for types
[redirected to Haskell-cafe from ghc...]
I think the point is not to define your class Seriliazer,
but to define it as a generic function instead. After all,
it is kind of show (because it is serialisation).
Reading your
earlier emails, it seems a remaining problem is to keep
this function
karczma wrote:
Actually, I would like to know what was the purpose of all
that...
I was writing some new code and wanted to break it into two parts,
they should have very little knowledge of each other other than what
methods are available in each (hence the classes). The actual types
of the
On Thu, 19 Aug 2004, Sam Mason wrote:
class Foo t where
encode :: String - t
decode :: t - String
test = decode . encode
This currently fails, because the type checker insists on trying
to figure out what its type should be - even though it shouldn't
be needed.
In
Hi,
I've been getting into Haskell over the past few months and have just
come up against a bit of a brick wall when trying to encapsulate
some of the data structures in my code nicely. Basically what I
want to have, is a type class where one of the intermediate values
is opaque with respect to
On Thu, Aug 19, 2004 at 05:42:10PM +0100, Sam Mason wrote:
Hi,
I've been getting into Haskell over the past few months and have just
come up against a bit of a brick wall when trying to encapsulate
some of the data structures in my code nicely. Basically what I
want to have, is a type
Hi,
I've been getting into Haskell over the past few months and have just
come up against a bit of a brick wall when trying to encapsulate
some of the data structures in my code nicely. Basically what I
want to have, is a type class where one of the intermediate values
is opaque with
Sam Mason writes:
Jon Cast wrote:
The intermediate type /is/ needed---it's a (hidden) parameter to your
`encode' and `decode' functions. Why do you think it shouldn't be?
Because I couldn't see the woods for the trees. I think I had
almost figured out what I was asking (the impossible) before
karczma wrote:
Don't forget that this is the toplevel business, not a universal
disease. GHCi says
Prelude :t (show . read)
(show . read) :: String - String
and doesn't complain. But if you define
bz = show . read
the attempt to load this definition (file: ctest.hs) results in:
Arjun,
AG This class definition is giving me a lot of problems
AG with the successor function:
class (Ord st) = MinimaxState st where
successors :: st - [(action, st)]
terminal :: st - Bool
instance MinimaxState Int where
terminal i = i == 0
successors i = [(1,i+1),
Arjan,
AG I'm curious as to why my class declaration
AG compiles in GHC, as there doesn't seem to
AG be any way to use it.
class (Ord st) = MinimaxState st where
successors :: forall a . st - [(a, st)]
terminal :: st - True
Any implementation of the successors method needs to produce
Arjun,
AG This class definition is giving me a lot of problems
AG with the successor function:
class (Ord st) = MinimaxState st where
successors :: st - [(action, st)]
terminal :: st - Bool
instance MinimaxState Int where
terminal i = i == 0
successors i = [(1,i+1), (-1,i-1)]
I'd rather not do that, but even if I did, the type-variable action
would not be reachable in the terminal function. I could specify a
functional dependency st - action (though I've never used it, it would
be a fun to learn). I'm curious as to why my class declaration
compiles in GHC, as
Arjan,
AG I'm curious as to why my class declaration
AG compiles in GHC, as there doesn't seem to
AG be any way to use it.
class (Ord st) = MinimaxState st where
successors :: forall a . st - [(a, st)]
terminal :: st - True
Any implementation of the successors method needs to produce
How about inserting one more parameter, action, in your class
definition:
class (Ord st) = MinimaxState st action where
successors:: st - [(action,st)]
terminal:: st - Bool
instance MinimaxState Int Int where
terminal i = i == 0
successors i = [(1,i+1), (-1,i-1)]
I'd rather
This class definition is giving me a lot of problems with the successor
function:
class (Ord st) = MinimaxState st where
successors:: st - [(action,st)]
terminal:: st - Bool
A trivial example would be:
instance MinimaxState Int where
terminal i = i == 0
successors i = [(1,i+1), (-1,i-1)]
one should be able to define two instances having the same signature, as
long as they are in different namespaces
[snip]
But now, ghc complains about two instances of Foo Integer, although
there should be none in the namespace main.
It's a Haskell problem, not a ghc one.
Class instances
Hi all,
I am pretty new to haskell, but while exploring the haskell module
system, I came along some questions. As far as I found out, haskell
supports separated namespaces, i.e. every module has its own symbol
space. Thus, when defining a class in one module like
module A(Foo(f)) where
class
Stephan Herhut [EMAIL PROTECTED] writes:
module B(bar) where
instance Foo Integer where
module C(tango)
instance Foo Integer where
import B(bar)
import C(tango)
But now, ghc complains about two instances of Foo Integer, although
there should be none in the namespace main.
I suspect
Duncan Coutts writes (to the Haskell Mailing list):
I'm trying to write a generic curry ( uncurry) function that works for
functions of any arity.
See http://www.haskell.org/pipermail/haskell/2003-April/011720.html
where oleg presents a (ghc-specific) solution.
Cheers,
Ronny Wichers Schreur
Hi All,
I'm trying to write a generic curry ( uncurry) function that works for
functions of any arity. I have a couple solutions that nearly work, both
involving type classes.
Here's the first one:
class Curry tupled curried where
genericCurry :: tupled - curried
genericUncurry :: curried
Duncan Coutts [EMAIL PROTECTED] writes:
So I thought that functional dependencies might help because the curried
type should uniquely determine the uncurried type (and vice versa).
However if I change the class declaration to:
class Curry tupled curried | tupled - curried, curried - tupled
In message [EMAIL PROTECTED], Duncan Coutts writes:
I'm trying to write a generic curry ( uncurry) function that works for
functions of any arity. I have a couple solutions that nearly work, both
involving type classes.
[SNIP]
Any insight or suggestions would be interesting.
Here's one solution
that's what
Keeane is suggesting.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of MR K P SCHUPKE
| Sent: 02 February 2004 11:48
| To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
| Subject: Re: Generics and type classes
Hi,
I'm trying to use type classes and suspect I've got confused somewhere
down the line, because I've got to an error message that I don't
understand and can't remove.
I have a class that works like a hash table, mapping from String to some
type. I have two instances, one that is case
Ah. I just need to drop the context from the data type declaration.
Sorry,
Andrew
andrew cooke said:
Hi,
I'm trying to use type classes and suspect I've got confused somewhere
down the line, because I've got to an error message that I don't
understand and can't remove.
I have a class
Robert Will wrote:
Note that in an OO programming language with generic classes ...
(We shouldn't make our functional designs more different from the OO ones,
than they need to be.)
why should *we* care :-)
more often than not, OO design is resticted and misleading.
you see how most OO
expressive than real polymorphism), I can write
class MAP[A, B] inherit COLLECTION[TUPLE[A, B]]
which has exactly the desired effect (and that's what I do in the
imperative version of my little library).
There seems to be no direct way to achieve the same thing with Haskell
type classes (or any
--- Robert Will [EMAIL PROTECTED] wrote:
-- Here
-- is a quesion for the
-- most creative of thinkers: which is the design
(in
-- proper Haskell or a
-- wide-spread extension) possibly include much
-- intermediate type classes and
-- other stuff, that comes nearest to my desire?
Hello
type constructor to the element type). The
classes with functional dependencies say just that, our collection type
provides certain methods (involving the element types).
Collections were one of the examples in Mark Jones' paper on
functional dependencies (Type Classes with Functional Dependencies
, absolutely. See
http://research.microsoft.com/~simonpj/Papers/derive.htm
Section 7, and Trifanov's paper at the Haskell Workshop 2003
Thanks for the pointers! I am now thinking about encoding SML-style
module systems into Haskell using type classes with functional
dependencies. For this purpose
In article [EMAIL PROTECTED],
Ken Shan [EMAIL PROTECTED] wrote:
Just today (and not
only today) I wanted to write instance definitions like
instance (forall a. C a = D a) = E [a] where ...
I've wanted this for awhile, in both class and instance declarations.
--
Ashley Yakeley,
a = D a) = E [a] where ...
This is analogous to wanting to write a rank-2 dictionary constructor
(forall a. C a - D a) - E [a]
at the term level, but with type classes, this dictionary constructor
should be applied automatically, in a type-directed fashion, at compile
time. The theory
| To: [EMAIL PROTECTED]
| Subject: Hypothetical reasoning in type classes
|
| Hello,
|
| Has anyone thought about adding hereditary Harrop formulas, in other
| words hypothetical reasoning and universal quantification, to the
| instance contexts in the Hsakell type class system? Just today
class Thing t where
thing :: t
[..]
Can someone please explain why
fst (1,thing)
...gets an 'ambiguous type variable' error, but
fst (1,undefined)
...doesn't? And is there anything I can change to make the former work
as well? Even modifying fst doesn't work:
This kind of
Jared Warren wrote:
Consider:
class Thing t where
thing :: t
instance Thing Int where
thing = 0
instance Thing Char where
thing = 'a'
Can someone please explain why
fst (1,thing)
...gets an 'ambiguous type variable' error, but
fst (1,undefined)
...doesn't?
Perhaps
Consider:
class Thing t where
thing :: t
instance Thing Int where
thing = 0
instance Thing Char where
thing = 'a'
Can someone please explain why
fst (1,thing)
...gets an 'ambiguous type variable' error, but
fst (1,undefined)
...doesn't? And is there anything I can change to
Title: Type classes question
Hello,
I am trying to define class Dual and few instances as follows:
===
class Dual a where
dual :: a - a
instance Dual Bool where
dual = not
instance (Dual a, Dual b) = Dual (a - b) where
dual f = dual . f . dual
instance Dual a = Dual
I had a discussion with someone over the type class mechanism and would like
to clarify something.
When I compile this trivial program:
module Main where
main = putStrLn (show (1 + 2))
with ghc -Wall, the compiler says:
Main.lhs:3:
Warning: Defaulting the following constraint(s) to type
the type(s) of its arguments are also known. This is a
good thing because it tends to reduce the cost of overloading at runtime.
More aggresive forms of specialisation are also possible and discussed in
the literature.
I think if you look up the papers on implementing type classes your
questions should
Alistair Bayley writes:
Warning: Defaulting the following constraint(s) to type `Integer'
`Num a' arising from the literal `2' at Main.lhs:3
This implies to me that the compiler is generating the code for (+) for the
particular instance, rather than using a run-time dispatch
Is there
some way of preventing the type mechanism from generating
code for the
instance type, as opposed to the class?
I don't understand this question - does the explanation above help?
I could have been clearer with my questions. What I was wondering was: is
there some situation
Bayley, Alistair wrote:
When it's applied, the compiler will know the types of the arguments, won't
it?. Which means that you would generate a version of double for each
(applied) instance of Num. I don't doubt that there's a good reason this is
not done: code bloat? or are there simply some
Does this also mean that a dictionary class is created for every class, and
a dictionary created for every instance?
Yes, exactly. Every class is translated to a data type declaration,
and every instance is translated to an element of that data type - a
dictionary. (Note that you can't
(Moved to the Cafe)
Yes, exactly. Every class is translated to a data type declaration,
and every instance is translated to an element of that data type - a
dictionary. (Note that you can't actually write those declarations in
Haskell 98 in general, because they can have polymorphic
You need to change the first line to this:
data C a = C { pair :: forall b. b - (b,a) }
and then it works fine (with -fglasgow-exts). But you've now stepped
outside the bounds of Haskell 98.
(oops, replying to myself... sure sign of madness! :) )
I hasten to add that this is *not* the
inference can't deduce much about the result type of the
application because type classes only specify relations over types. In
your case, ClassB is a binary relation over types. Hence, you could
easily imagine having two instances for ClassB
instance ClassB Int Bool
instance ClassB Int Char
putting
G'day.
On Mon, Feb 17, 2003 at 01:44:07AM -0500, Mike T. Machenry wrote:
I was wondering if it's better to define them as type classes with the
operations defined in the class. What do haskellian's do?
I can't speak for other Haskellians, but on the whole, it depends.
Here's the common
- PlayerState
move DetectiveState ... =
move FugitivieState ... =
I was wondering if it's better to define them as type classes with the
operations defined in the class. What do haskellian's do? Oh and if I say
Instance Foo Baz where
...
and only define a few of the operations in Foo... bdoes
This is a somewhat older thread, but I ask you to enlighten me.
Norman Ramsey wrote:
A fact that I know but don't understand the implication of is that
Haskell dispatches on the static type of a value, whereas OO languages
dispatch on the dynamic type of a value. But I suspect I'll leave
that
On Tuesday, February 4, 2003, at 03:46 PM, Jerzy Karczmarczuk wrote:
I would say that - unless I am dead wrong, the OO languages such as
Smalltalk
do not dispatch on dynamic types of a value. The receiver is known, so
its vir.
f. table (belonging to the receiver's class) is known as well, the
On 26-Jan-2003, John H?rnkvist [EMAIL PROTECTED] wrote:
On Saturday, January 25, 2003, at 04:14 AM, Andrew J Bromage wrote:
G'day all.
On Fri, Jan 24, 2003 at 06:13:29PM -0500, Norman Ramsey wrote:
In a fit of madness, I have agreed to deliver a 50-minute lecture
on type classes
On 26-Jan-2003, Dean Herington [EMAIL PROTECTED] wrote:
On Sun, 26 Jan 2003, Norman Ramsey wrote:
A fact that I know but don't understand the implication of is that
Haskell dispatches on the static type of a value, whereas OO languages
dispatch on the dynamic type of a value. But I
On 24-Jan-2003, Norman Ramsey [EMAIL PROTECTED] wrote:
In a fit of madness, I have agreed to deliver a 50-minute lecture
on type classes to an audience of undergraduate students. These
students will have seen some simple typing rules for F2 and will
have some exposure to Hindley-Milner type
On 26-Jan-2003, Norman Ramsey [EMAIL PROTECTED] wrote:
In a fit of madness, I have agreed to deliver a 50-minute lecture
on type classes to an audience of undergraduate students. These
students will have seen some simple typing rules for F2 and will
have some exposure to Hindley
On Mon, Jan 27, 2003 at 08:37:06PM +1100, Fergus Henderson wrote:
I agree. The above characterization is highly misleading. It would be
more accurate and informative to say that both Haskell and OO languages
dispatch on the dynamic type of a value.
What is the dynamic type of a value in
On Mon, Jan 27, 2003 at 12:25:52PM +0200, Lauri Alanko wrote:
On Mon, Jan 27, 2003 at 08:37:06PM +1100, Fergus Henderson wrote:
I agree. The above characterization is highly misleading. It would be
more accurate and informative to say that both Haskell and OO languages
dispatch on the
Now that I have made it abundantly clear that my understanding of type
classes is highly imperfect, perhaps I will repeat my plea:
* Can you recommend any interesting, elementary examples?
* Of all the many articles on the topic, which few might you
recommend for beginners? Would
Hi Norman,
| [looking for papers about type classes ...]
| * Of all the many articles on the topic, which few might you
| recommend for beginners?
I wonder if my notes on Functional Programming with Overloading and
Higher-Order Polymorphism will be useful? You can find them
In a fit of madness, I have agreed to deliver a 50-minute lecture
on type classes to an audience of undergraduate students. These
students will have seen some simple typing rules for F2 and will
have some exposure to Hindley-Milner type inference in the context
of ML
501 - 600 of 676 matches
Mail list logo
