When I was last on the best rooftop in the Mid Upper West Side of
Manhattan I was told of the work on logical relations. I did not
know of this three decades old line of work. I have grabbed
http://homepages.inf.ed.ac.uk/gdp/publications/Par_Poly.pdf
To me, the style is comfortable and the mat
On Wed, 15 Aug 2012, wren ng thornton wrote:
On 8/13/12 5:42 PM, Jay Sulzberger wrote:
One difficulty which must impede many who study this stuff is
that just getting off the ground seems to require a large number
of definitions of objects of logically different kinds. (By
"logic" I mean rea
On 8/13/12 5:42 PM, Jay Sulzberger wrote:
One difficulty which must impede many who study this stuff is
that just getting off the ground seems to require a large number
of definitions of objects of logically different kinds. (By
"logic" I mean real logic, not any particular formalized system.)
We
On Thu, 9 Aug 2012, wren ng thornton wrote:
On 8/8/12 9:41 PM, Jay Sulzberger wrote:
Haskell's type classes look to me to be a provision for declaring
a signature in the sense of the above article.
Just to clarify this in the context of my previous post, type classes define
signatures in
On Thu, 9 Aug 2012, Patrick Browne wrote:
On 09/08/12, Jay Sulzberger wrote:
Here we are close to the distinction between a class of "objects
which satisfy a condition" vs "objects with added structure",
for
which see:
? http://math.ucr.edu/home/baez/qg-spri
On 8/8/12 9:41 PM, Jay Sulzberger wrote:
Haskell's type classes look to me to be a provision for declaring
a signature in the sense of the above article.
Just to clarify this in the context of my previous post, type classes
define signatures in two significantly different ways.
(1) The first
Hello,
On Thu, Aug 9, 2012 at 1:52 PM, Tillmann Rendel <
ren...@informatik.uni-marburg.de> wrote:
Note that many type classes in Haskell have equations annotated as
> comments. For example, the monad laws are mentioned in the documentation of
> the Monad type class:
>
One of the reasons why I ch
Hi,
Patrick Browne wrote:
Haskell type classes seem to be signature only (no equations, ignoring
default methods) so in general they provide an empty theory with no
logical consequences.
Note that many type classes in Haskell have equations annotated as
comments. For example, the monad laws a
On 09/08/12, Jay Sulzberger wrote:Here we are close to the distinction between a class of "objectswhich satisfy a condition" vs "objects with added structure", forwhich see: http://math.ucr.edu/home/baez/qg-spring2004/discussion.html http://ncatlab.org/nlab/show/stuff,+structure,+propertyoo--JS
On Wed, 8 Aug 2012, Ertugrul S??ylemez wrote:
Patrick Browne wrote:
Gast [1] describes a 3 level hierarchy of Haskell objects using
elementOf from set theory:
value?? *elementOf*?? type?? *elementOf*?? class
This hierarchy is pretty arbitrary and quickly runs into problems with
some typ
On 9/08/2012, at 11:11 AM, wren ng thornton wrote:
>
> Notably, a type class instantiated with all its arguments is not itself a
> type!
All the comparisons of Haskell typeclasses with Java classes answered
in one brief lucid sentence.
___
Haskell-
On 8/8/12 3:36 PM, Patrick Browne wrote:
On 08/08/12, *Ertugrul Söylemez * wrote:
So you basically just mean
class (Functor f) => Applicative f
Yes, but I want to know if there is a simple mathematical relation between the
classes and/or their types
Let us introduce the notion of "
On 08/08/12, Ertugrul Söylemez wrote:So you basically just mean class (Functor f) => Applicative fYes, but I want to know if there is a simple mathematical relation between the classes and/or their typesBut from your emails the original hierarchy seems to have been superseded, and my expectat
Patrick Browne wrote:
> > > If we include super-classes would the following be an appropriate
> > > mathematical representation?
> >
> > What is a superclass? What are the semantics?
>
> I assume that like a normal class a super-class *defines* a set
> operations for types, but it is not *a set*
On 08/08/12, Ertugrul Söylemez wrote:> If we include super-classes would the following be an appropriate> mathematical representation?What is a superclass? What are the semantics?I assume that like a normal class a super-class *defines* a set operations for types, but it is not *a set* of types.
Patrick Browne wrote:
> Gast [1] describes a 3 level hierarchy of Haskell objects using
> elementOf from set theory:
>
> value *elementOf* type *elementOf* class
This hierarchy is pretty arbitrary and quickly runs into problems with
some type system extensions. You can find out whether the
Gast [1] describes a 3 level hierarchy of Haskell objects using elementOf from set theory:value *elementOf* type *elementOf* classQuestionIf we include super-classes would the following be an appropriate mathematical representation?value *elementOf* type *elementOf* class *subSet* super-clas
17 matches
Mail list logo