[ Apologies for multiple postings ]
==
TYPES 2023: Call for Contributions -- Deadline extension
==
* Submission of abstract 13 March 2023 AoE **NEW
* Author
[ Apologies for multiple postings ]
=
Call for Contributions
TYPES 2023
29th International Conference on
Types for
Imperial College London has two open positions on session types and
programming languages (see details below). If you have any questions,
do not hesitate to contact Prof. Nobuko Yoshida on
n.yosh...@imperial.ic.ac.uk
The programming languages group at University of Freiburg, Germany, has an
opening for a research assistant to work on a DFG-funded project to create a
version of OCaml with linear types and session types to start on July 1, 2018.
The project entails work on the theory and on an implementation
DEADLINES EXTENDED by 2 weeks:
* abstract deadline: 30 October
* paper deadline: 6 November
Open call for papers
Post-proceedings of the
23rd International Conference on Types for Proofs and
DEADLINES EXTENDED by 2 weeks:
* abstract deadline: 30 October
* paper deadline: 6 November
---
Open call for papers
Post-proceedings of the
23rd International Conference on Types for Proofs and
Abstract deadline in 6 days!
Open call for papers
Post-proceedings of the
23rd International Conference on Types for Proofs and Programs
TYPES 2017
TYPES is a major forum for the presentation of
Abstract submission deadline 16 October 2017
Open call for papers
Post-proceedings of the
23rd International Conference on Types for Proofs and Programs
TYPES 2017
TYPES is a major forum for
Paper submission deadline 23 October 2017
Open call for papers
Post-proceedings of the
23rd International Conference on Types for Proofs and Programs
TYPES 2017
TYPES is a major forum for the
* registration is open
* invited talks: Sara Negri, Edwin Brady, Jakob Rehof
* 51 contributed talks
CALL FOR PARTICIPATION
23rd International Conference on Types for Proofs and Programs,
TYPES 2017
and
[Submission deadline extended by a week to 20 March 2017.
Consider contributing!]
CALL FOR CONTRIBUTIONS
23rd International Conference on Types for Proofs and Programs,
TYPES 2017
and
Reminder: abstracts (2 pp easychair.cls) due by 13 March 2017.
CALL FOR CONTRIBUTIONS
23rd International Conference on Types for Proofs and Programs,
TYPES 2017
and
EUTYPES Cost Action
CALL FOR CONTRIBUTIONS
23rd International Conference on Types for Proofs and Programs,
TYPES 2017
and
EUTYPES Cost Action CA15123 meeting
Budapest, Hungary, 29 May - 1 June
Reminder: Call for Papers, Presentations and Participation
Workshop on
Coalgebra, Horn Clause Logic Programming and Types
28-29 November 2016, Edinburgh, UK
https://ff32.host.cs.st-andrews.ac.uk/coalpty16/
Abstract submission:15 October, 2016
Registration deadline: 1 November, 2016
We have an opening for a PhD student in dependent type theory and
functional programming at Chalmers. Here is an excerpt from the ad:
"The PhD student will join the Programming Logic group and contribute
to its research on dependent type theory and functional programming.
Topics of interest
[Selection of talks based on abstracts (2 pp easychair.cls)
due 13 March 2015!
A post-proceedings volume in LIPIcs, with an open call.]
CALL FOR CONTRIBUTIONS
21st International Conference on Types for Proofs and Programs,
TYPES 2015
Reminder:
Abstracts (2 pp easychair.cls) due by 13 March 2015
News:
Tutorials by Joachim Kock and Peter LeFanu Lumsdaine.
Post-proceedings volume in LIPIcs confirmed.
CALL FOR CONTRIBUTIONS
21st International Conference on Types for Proofs and Programs
| To: Dan Doel
| Cc: haskell@haskell.org
| Subject: Re: [Haskell] Rank-N types with (.) composition
|
| On February 10, 2015 16:28:56 Dan Doel wrote:
| > Impredicativity, with regard to type theories, generally refers to
| > types being able to quantify over the collection of types th
On Tue, 10 Feb 2015, Tyson Whitehead wrote:
I came across something that seems a bit strange to me. Here is a
simplified version (the original was trying to move from a lens
ReifiedFold to a lens-action ReifiedMonadicFold)
You are on Haskell@haskell.org here. Could you please move to
haske
On February 10, 2015 17:44:54 Dan Doel wrote:
> Really, I think the least ad-hoc solution (other than a hypothetical
> best-of-both-worlds inference algorithm) would be to allow code like:
>
> runST do ...
>
> where you can apply expressions directly to certain syntactic constructs
> without
ave a similar rule, like:
Whenever you see: f Prelude.. g
instead try to type check: \x -> f (g x)
-- Dan
On Tue, Feb 10, 2015 at 6:19 PM, Tyson Whitehead
wrote:
> On February 10, 2015 16:28:56 Dan Doel wrote:
> > Impredicativity, with regard to type theories, generall
at can represent more types than can be written in
source code. That said, you can probably examine generated Core to see what
it looks like in System Fc.
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb..
On February 10, 2015 16:28:56 Dan Doel wrote:
> Impredicativity, with regard to type theories, generally refers to types
> being able to quantify over the collection of types that they are then a
> part of. So, the judgment:
>
> (forall (a :: *). a -> a) :: *
>
> is i
Well, that might also be surprising, unless ($) is also magically made to
work like a standard operator (just off the top of my head; there may be
other confusing aspects).
Really, I think the least ad-hoc solution (other than a hypothetical
best-of-both-worlds inference algorithm) would be to all
On Tue, Feb 10, 2015 at 4:28 PM, Dan Doel wrote:
> Also, I think ($) is the way it is specifically because 'runST $ ...' is
> considered useful and common enough to warrant an ad-hoc solution. There
> have been other ad-hoc solutions in the past, but redesigning inference to
> not be ad-hoc about
Impredicativity, with regard to type theories, generally refers to types
being able to quantify over the collection of types that they are then a
part of. So, the judgment:
(forall (a :: *). a -> a) :: *
is impredicative, because we have a type in * that quantifies over all
types in *, wh
The problem is that GHC's type system is (almost entirely)
predicative. I couldn't tell you just what that means, but to a first
approximation, it means that type variables cannot be instantiated to
polymorphic types. You write
trip = Wrap . extract
which means
(.) Wrap extract
I came across something that seems a bit strange to me. Here is a simplified
version (the original was trying to move from a lens ReifiedFold to a
lens-action ReifiedMonadicFold)
{-# LANGUAGE RankNTypes #-}
import Control.Applicative
newtype Wrap = Wrap { extract :: forall f. Functor f =>
CALL FOR CONTRIBUTIONS
21st International Conference on Types for Proofs and Programs,
TYPES 2015
Tallinn, Estonia, 18-21 May 2015
http://cs.ioc.ee/types15/
Background
The TYPES meetings are a forum to
This package provides some support for dealing with polytypic data. It lets
you escape from the generics world and work with a homogeneous rose tree,
which can sometimes be convenient.
I realise a more experienced programmer would probably do this differently,
but anyhow it was useful to me and I'
==
VACANCY : 1x Phd position in dependent types, testing & hardware design
==
The research group of Software Technology is part of the Software
Systems division of in
Yes, I agree at inclusion in base. I opted for this solution, as it allows
me to test it in anger at my daily work at Erudify. If we're going to add
more strict modules to base, then I'd do it in a two step process.
1. Include strict versions of core types, i.e., the modules from
s
Johan Tibell wrote:
> For what it's worth, I think we need Data.Maybe.Strict,
> Data.Tuple.Strict, and Data.Either.Strict in base. Only then will they
> be accessible enough that we can start using them in APIs in core
> packages. This will also make it easier to provide type class
> instances (e.
On Wed, May 8, 2013 at 11:01 AM, Bas van Dijk wrote:
> Good stuff Simon!
>
> It would be great if either strict-base-types, strict or a merger of
> the two will find its way into the Haskell Platform. Even better if it
> also merged with strict-concurrency and strict-io so that w
Good stuff Simon!
It would be great if either strict-base-types, strict or a merger of
the two will find its way into the Haskell Platform. Even better if it
also merged with strict-concurrency and strict-io so that we have one
go-to package for strict types and operations.
Cheers,
Bas
On 8
Dear fellow haskellers,
the strict-base-types package makes it easy to get rid of the unnecessary
laziness (and the resulting space leaks) in your applications; i.e., no more
data AppState = AppState
{ _field :: !(Maybe T.Text)
, ...
}
as the alternative
import qualified
The London Haskell user group has a talk next week:
The Algebra of Algebraic Data Types
Speaker: Chris Taylor
Haskell's types are "algebraic data types". But what's so 'algebraic'
about algebraic types? This talk explains what types have to do with
algebra, s
Hi all, I'm pleased to give you adt.js - algebraic data types for JavaScript.
* https://github.com/rehno-lindeque/adt.js (The source code & README)
* https://groups.google.com/forum/#!forum/adtjs (A place to chat)
adt.js is an unusual take on algebraic data types for JavaScript, that
On 22 April 2012 21:39, Christian Höner zu Siederdissen
wrote:
> * Julian Gilbey [22.04.2012 09:22]:
>> On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote:
>> > On 21/04/2012, Andreas Abel wrote:
>> > > to avoid silly "return ()" statements like in
>> > >
>> > > when cond $ do
>> > >
* Julian Gilbey [22.04.2012 09:22]:
> On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote:
> > On 21/04/2012, Andreas Abel wrote:
> > > to avoid silly "return ()" statements like in
> > >
> > >when cond $ do
> > > monadicComputationWhoseResultIWantToDiscard
> > > return ()
> >
>
On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote:
> On 21/04/2012, Andreas Abel wrote:
> > to avoid silly "return ()" statements like in
> >
> >when cond $ do
> > monadicComputationWhoseResultIWantToDiscard
> > return ()
>
> (when cond ∘ void) monadicComputationWhoseResultIWan
On 21/04/2012, Andreas Abel wrote:
> to avoid silly "return ()" statements like in
>
>when cond $ do
> monadicComputationWhoseResultIWantToDiscard
> return ()
(when cond ∘ void) monadicComputationWhoseResultIWantToDiscard
or
when cond $ () <$ monadicComputationWhoseResultIWantToDisc
Yes, this has always bothered me too.
John
On Sat, Apr 21, 2012 at 2:51 AM, Andreas Abel wrote:
> In Control.Monad, when has type
>
> when :: Monad m => Bool -> m () -> m ()
>
> I think this type should be generalized to
>
> when :: Monad m => Bool -> m a -> m ()
>
> to avoid silly "return
In Control.Monad, when has type
when :: Monad m => Bool -> m () -> m ()
I think this type should be generalized to
when :: Monad m => Bool -> m a -> m ()
to avoid silly "return ()" statements like in
when cond $ do
monadicComputationWhoseResultIWantToDiscard
return ()
Cheers,
A
Two PhD and postdoc positions are available at DIKU, the Department of
Computer Science at the University of Copenhagen, in the Project *Kleene
Meets Church (KMC): Regular Expressions and Types*.
The overall objective of KMC is to investigate the type-theoretical
foundations for the prevalent use
radeoff.
Simon
| -Original Message-
| From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org] On
| Behalf Of Barney Hilken
| Sent: 05 March 2012 12:22
| To: haskell@haskell.org
| Subject: [Haskell] Higher types in contexts
|
| Is there any deep reason why
Is there any deep reason why I can't write a polymorphic type in a context? I
think the record update problem can be (sort of) solved if you could write:
class Has r Rev (forall a. [a] -> [a]) => HRClass r where
setHRClass :: (forall a.[a] -> [a]) -> r -> r
but polym
Hi list,
I was wondering why GHC doesn't allow usage of polymorphic types in
the right-hand side of type instance declarations for type families.
The GHC user guide states: "The right-hand side of a type instance
must be a monotype (i.e., it may not include foralls) [...]", but i
Dear Haskellers
CUFP should be a lot of fun this year. Do consider going.
Simon
Commercial Users of Functional Programming Workshop
(CUFP) 2010
Call for Participation
Sponsored by SIGPLAN
Co-located with ICF
Often times QuickCheck properties are polymophic/overloaded without
giving a monomorphic type signature. But there can be several types
that you are interested. You can write scripts that check all the types
you are interested annotating the generic property for each different
monotype, which is
type system. Obviously, when types of data in your domain you work with
grow — all declarations grow, and it becomes hard to grasp all
dependencies, to change them and to remove them deliberately.
graphtype was developed to visualise type declarations in you Haskell
source files. It produces
Dear list members,
The Types 2009 meeting will be held in Aussois, at the "centre Paul
Langevin" managed by the CNRS. This centre will supply everything:
conference room, accommodation, meals, etc. It should provide very good
conditions for profitable work.
Early registration is
Dear list members,
Tomorow Monday is the last day to register on the TYPES 2009 website if
you want to pay reduced fee. Later registration is still possible and
talk submission to. We will probably (as every year) publish post
proceedings with good referee.
The TYPES workshop cover theory
mawercer.de/vxml; git checkout fc160ab # is master branch )
you see that it actually works quite fine
-- helper function:
vxmlSeqPlus_ (f,fl) = f `vxmlgtgt` (foldr1 vxmlgtgt fl)
-- usage example from testSimple.hs, note that both (d e) have different types
vxmlSeqPlus_ ((d e), replicate
(#-), (#*), (#/) :: (MakeAExp a s, MakeAExp b s) => a -> b -> AExp s
> (#+) = parseArgs Addition
> (#-) = parseArgs Subtraction
> (#*) = parseArgs Multiplication
> (#/) = parseArgs IntegerDivision
>
> This code works if only one operator is applied:
>
> *FD> :type
Michael Marte <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in
gmane.comp.lang.haskell.general:
> *FD> :type let x = (1::Int) in x #+ x #+ x
> let x = (1::Int) in x #+ x #+ x :: (MakeAExp (AExp s) s1) => AExp s1
>
> It appears to me that ghci generates
:: AExp s
but
*FD> :type let x = (1::Int) in x #+ x #+ x
let x = (1::Int) in x #+ x #+ x :: (MakeAExp (AExp s) s1) => AExp s1
It appears to me that ghci generates two phantom types s and s1 and fails to
unify them.
Only the extensive use of type constraints seems to help like in the fo
Folks,
ICFP is growing a Functional Programming Developer Conference! It'll sit
back-to-back with ICFP, with the Commercial Users of Functional Programming
workshop as part of it.
As well as CUFP, though, there'll be tutorials and presentations about
libraries
tools
pro
2008/2/6, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>
> Ki Yung Ahn posed a problem of first-order syntactic unification
> over GADTs.
>
> There posted code seem to exhibit two problems: one deals with kind
> equality, and the other with unification.
Thanks for pointing out my mistake in the unificat
istentially
quantified, there is no reason they must always be equal. So, we have
to use intensional equality.
> data Star = Star deriving (Show,Eq) -- the kind *
> data k1 :~> k2 = k1 :~> k2 deriving (Show,Eq)
Well, deriving Eq is not useful here: we can't actually compare Star
with
' :: Ty v (k2' :~> k)) (t2' :: Ty v k2')) =
let x = unify t1 t1'
y = unify t2 t2'
in undefined
You've stated your unification algorithm so that it works on two types
of the same kind. However, each time you invert the application rule,
wh
I was writing a type inference algorithm for let-polymorphic type system
with parametrized types. (That is, the type system as type constructors
such as `Maybe'.) Things work out nicely except for one equation in the
unification function. I will illustrate my problem with the definition
In the frame of the extended EU FP6-funded TYPES project, we are
organizing an ad hoc "small workshop" on integration of effects into
type-theoretic programming/reasoning.
This is an informal event and attendance is not confined to people
involved in TYPES. On the contrary, atte
- the modality a is a phantom type for this
deriving (Read, Show, Eq)
-- Actually I never use the data constructors, just the types, so you could
leave them out.
data NullModality = NullModality
deriving (Read, Show, Eq)
data KModality a = KModality a
der
Hi there,
This is a question about combining data types in a generic way.
I am using Haskell to write a first implementation of a new generic
algorithm to decide a fairly large class of modal logics. Type classes
provide an excellent way to generically define a modal language. In
particular
Am Samstag, 14. Juli 2007 23:04 schrieb Vivian McPhail:
> […]
> They say that haskell programmers are normally averse to dependent types.
So I’m far away from being normal.
> […]
> What are peoples' thoughts on adding dependent types to haskell as a
> non-incremental e
kell programmers are normally
> averse
> to dependent types. Is this true? It seems to me that one of the appeals
> of Haskell is the ability to program in a "prove perfect, write once"
> (elegant) style. Is not dependent typing a good move towards this goal?.
> It addresses
Hello,
As the authors point out [1], coal-face time needs to be expended before
real world adoption of Dependently-Typed functional programming. But let's
get the ball rolling. They say that haskell programmers are normally averse
to dependent types. Is this true? It seems to me that o
I am pleased to announce the first release of package strict which
provides strict versions of standard Haskell types. At the moment,
pairs, Maybe and Either are defined. For instance, strict Maybe is
defined as
data Maybe a = Nothing | Just !a
Package homepage:
http://www.cse.unsw.edu.au
=
> let maybelong = cast num
> in if isNothing maybelong
> then
> 0
> else
> fromJust maybeLong
>
> (It always returns 0)
>
> Could anyone give me a hint as to what the problem is?
cast has very li
Hello,
I want to convert a Haskell Integer (Data.Int.Int32) to a C long
(Foreign.C.Types.CLong), but it seems this code here doesn't work:
intToLong :: Int32 -> Clong
intToLong num =
let maybelong = cast num
in if isNothing maybelong
then
0
els
The following code took me several hours to work out.
I post it here, so perhaps other can avoid the difficulties of working out
how to use existential types.
Improvements welcome.
If anyone thinks it is worth it I could add it to the wiki under existential
types (I didn't find the exa
Supposing a polymorphic value (of type, say, forall a . ExpT a t) is
stored inside an existential package (of type, say, forall a . Exp a),
I wonder how to recover a polymorphic value when eliminating the
existential. The ``natural way'' to write this doesn't work:
{-# OPTIONS -fglasgow-exts #-
Dear Haskell Folks
This is to announce the availability of indexed data types, a modest
extension of our earlier proposal for associated data types[1], in GHC's
development version. Detailed information on where to get the right GHC
and how to use indexed types is available from the Haskell
[ posting on behalf of George Necula <[EMAIL PROTECTED]> ]
===
Read the html version of this CFP at
http://www.cs.berkeley.edu/~necula/tldi07/cfp.html
The ACM SIGPLAN Workshop on Types in Language Design and Implementation
Affiliated with ACM SIGPLAN-SIGACT Symposium on Prin
the applications of computable
types, to ascribe signatures to terms and to drive the selection of
overloaded functions. We can compute the type of a tree of the depth
fib(N) or a complex XML type, and instantiate the read function to
read the trees of only that shape.
A telling example of the
This is the first message in a series on arbitrary type/kind-level
computations in the present-day Haskell, and on using of so computed
types to give signatures to terms and to drive the selection of
overloaded functions. We can define the type TD N to be the type of a
tree fib(N)-level deep, and
haskell-cafe@haskell.org is usually a better venue for these sorts of
questions. People there love helping people learn Haskell.
And when I try to load it to GHCi I get an error (there is also plenty of
others but they look the same):
couldn't match Int against t t1
This error occurs because
Szymon Ząbkiewicz wrote:
> Hi!
> I'm new to Haskell and FP so i've got some problems. I wrote this code :
>
> getNr :: Int -> Int
> getNr x = do
> putStrLn ("enter " ++ x ++ " number:")
> nr <- getLine
> return nr
>
> And when I try to load it to GHCi I get an error (there is also ple
Hi!I'm new to Haskell and FP so i've got some problems. I wrote this code :getNr :: Int -> IntgetNr x = do putStrLn ("enter " ++ x ++ " number:") nr <- getLine return nr
And when I try to load it to GHCi I get an error (there is also plenty of others but they look the same):couldn't match
Sorry if people are really bored with this thread, but I thought of
another advantage of this approach.
Trex (and similar systems) have a limitation that stops you using
them to define functions with default values. In systems like R (the
stats package) most functions have a huge number of
gh, because in Odersky and
> Laufer's original paper, they do not do "local type inference" (they
> don't specify a bidirectional version), which would make type (*)
> impossible to specify in their original system?
No this has nothing to do with the OL type s
Hi,
I am currently studying the paper "Practical Type Inference for
Arbitrary Rank Types" by Simon Peyton Jones and Mark Shields, and I've
been wondering about the final version of the typing rules (figure 7,
"Bidirectional version of Odersky-Laufer") (although I suppose
Manuel M T Chakravarty:
This is problematic as the instance heads are distinguished only by
the
context; ie, both instances are for `Lacks m (N a r)'. Haskell's
instance selection mechanism (with or without associated types)
selects
instances purely by looking at the arguments of
b (N a r)
> >extend mm y (N x t) = mm y (N x t)
This is problematic as the instance heads are distinguished only by the
context; ie, both instances are for `Lacks m (N a r)'. Haskell's
instance selection mechanism (with or without associated types) selects
i
The implementation of records using types data N a r = N a r might
well be inefficient, and I don't know enough about the workings of
the compiler to see whether it could be improved by unboxing and
strictness. But the real point of my post was the classes Contains,
Lacks and Dis
Of course, under Usage, I should have written:
The record {N1 = x1, ... Nn = xn} should be constructed as (extend N1
x1 $ ... $ extend Nn xn $ Empty).
Sorry about any confusion!
Barney.
___
Haskell mailing list
Haskell@haskell.org
http://www.haske
n -> r -> Project n r
> delete :: Constructor n -> r -> Delete n r
There are two associated types: Project n r is the type of the n
field, and Delete n r is the type of the rest of the record. The
functions project and delete give the corresponding values.
The class Lacks
An earlier message showed an example of writing code with non-trivial
static guarantees in the present-day Haskell (i.e., Haskell98 + rank-2
types).
http://pobox.com/~oleg/ftp/Haskell/types.html#branding
Although this approach obviously falls short of the genuine dependent
typing, we
Registration for TYPES 2006 is now open.
Early registration until 15/3/2006.
Cheers,
The TYPES06 Team
--
TYPES 2006
Main Conference of the Types Project
Nottingham, UK, 18-21 April 2006
Well spotted!
Yes, I changed this some time ago. Handling polymorphic subsumption
when matching patterns just turned to be a lot of hassle, with little
obvious payoff. Types in patterns must now match exactly.
I could conceivably back-pedal on this, but you are the first person to
even notice
Hello,
The following function is a valid function in ghc6.2.2:
> func :: (forall a . [a]) -> [b]
> func [] = []
However, in ghc6.4.1 it does not work anymore:
Iterators4.lhs:56:6:
Couldn't match `forall a. [a]' against `[a]'
When checking the pattern: []
In the definition of `func':
TYPES 2006
Main Conference of the Types Project
Nottingham, UK, 18-24 April 2006
http://www.cs.nott.ac.uk/types06/
This is the latest meeting in a series that started 1992, the last
conference was in December
Am Freitag, 16. September 2005 14:19 schrieb Adam Wyner:
> [...]
> But, what I don't understand or like is that the type of the whole
> is given as [[Char]], not what I thought it would be, namely PropList.
> Nor is it [String].
These three are essentially the same type. So a Haskell system may
> Any ideas, pointers, comments?
Hacle: http://www-users.cs.york.ac.uk/~mfn/hacle/
It transforms from Haskell to Clean, so I would have thought it has a
transformation to convert certainly the IO Monad to uniqueness types.
Neil
___
Haskell mailing l
After looking at the language Clean (http://www.cs.ru.nl/~clean/) I
wonder why there does not seem to be the desire to integrate uniquness
typing into Haskell.
Any ideas, pointers, comments?
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 60
On 27/04/2005, at 9:35 PM, Andreas Rossberg wrote:
The difference really shows up when you *use* (deconstruct) them:
g (RankNEq f) = (f 4 5, f True False)
This allows the embedded function to be used polymorphically. But:
h (ExistsEq f) = ???
Here, you cannot use f at all (well, except with und
(==) and f.
Cheers,
Krasimir
On 4/27/05, Andre Pang <[EMAIL PROTECTED]> wrote:
> On 27/04/2005, at 9:26 PM, Krasimir Angelov wrote:
>
> > RankN and Exists are completelly different. The types of RankNEq and
> > ExistsEq constructors are:
> >
> > RankNEq :: (
On 27/04/2005, at 9:26 PM, Krasimir Angelov wrote:
RankN and Exists are completelly different. The types of RankNEq and
ExistsEq constructors are:
RankNEq :: (forall a. Eq a => a -> a -> Bool) -> RankN
ExistsEq :: forall a. Eq a => (a -> a -> Bool) -> Exists
i.e. RankN
nkN type uses rank-2 polymorphism to "hide" the expression
inside the type, whereas the Exists type uses existentially quantified
types instead. The two seem pretty equivalent to me, since the data
constructors have the same type. However, I can't help but feel that
I'm
1 - 100 of 591 matches
Mail list logo
