Vector Fabrics has another position open for a functional programmer. See below
and http://www.vectorfabrics.com/company/career/functional_programmer for
details.
This time, we particularly welcome applications from experienced developers,
the position providing a fair share of opportunities
Hi all,
The last days, some spam was added to the GHC developer wiki
(http://hackage.haskell.org/trac/ghc) .
I have removed some of it, but I could not get rid of the bits that were added
through attachments; see for example the bottom of
http://hackage.haskell.org/trac/ghc/wiki/Building.
[Apologies for multiple postings.]
Vector Fabrics is hiring: we are looking for a top-notch programmer to
extend our program-analysis and parallelization products. You design
and implement algorithms to assist the programmer to create a parallel
design from a sequential C or C++ program. You
Simon wrote:
I’m sure that any solution will involve (as it did in earlier stages)
motivated individuals who are willing to take up leadership roles in
developing Haskell’s language definition. I’m copying this to the main
Haskell list, in the hope of attracting volunteers!
I, for one,
I am almost sure this is a known issue, but I noticed some erroneous (?)
interaction between datatype promotion and existential quantification. Consider
the following program:
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE GADTs
Romildo,
How should an instance of (Functor ExprF) be defined? It is not shown in
the thesis.
It's actually quite straigtforward:
instance Functor ExprF where
fmap _ (Num n) = Num n
fmap _ (Var x) = Var x
fmap f (Bin op l r) = Bin op (f l) (f r)
As expected you get:
Romildo,
I could write the (Functor ExprF) instance:
instance Functor ExprF where
fmap f expr = case expr of
Num n - Num n
Var v - Var v
Bin op x y - Bin op (f x) (f y)
Yes, excellent. That'll do.
Cheers,
Stefan
Wren, Sjoerd,
This is not just about map, but it also a problem for the Monoid instance.
You are basically adding an extra identity element, 0, to the max monoid,
which works but is weird.
Still that's how union is typically defined for hybrid sets. It's what
happens if want union and
Sjoerd,
I am sorry, as I already wrote, I decided to deprecate the package.
[3] defines the union as h(u) = max(f(u), g(u)) where f, g and h are
multiplicity functions.
Which is the same, as [3] is about multisets, not signed multisets.
[...] and this is also what your implementation does.
Sjoerd,
[3] defines the union as h(u) = max(f(u), g(u)) where f, g and h are
multiplicity functions.
Which is the same, as [3] is about multisets, not signed multisets.
Chapter 3 of [3] is about Hybrid Sets.
And there the union is defined by taking the *minimum* of multiplicities, which
Sjoerd,
I have a hard time believing you have implemented the semantics that people
have agreed on to be a sensible semantics for hybrid sets.
Noted.
Cheers,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Sjoerd,
For a specific example, I haven't the faintest intuition about
what 'map' should do. Suppose we have
{(k1)x1, (k2)x2}
and f x1 == f x2 = y. Should the value of map f {...} be
{(k1+k2)y} or {(k1`max`k2)y} or what?
I don't think max would be a good choice, as that would mean
Sjoerd,
This is not just about map, but it also a problem for the Monoid instance.
You are basically adding an extra identity element, 0, to the max monoid,
which works but is weird.
Still that's how union is typically defined for hybrid sets. It's what happens
if want union and empty to
Sjoerd,
This is not just about map, but it also a problem for the Monoid instance.
You are basically adding an extra identity element, 0, to the max monoid,
which works but is weird.
Still that's how union is typically defined for hybrid sets. It's what
happens if want union and empty to
Sjoerd,
Then why would you want that?
You don't have to. (SignedMultiset a, additiveUnion, empty) gives you the
Monoid that you seem to have a preference for. The library supplies it
through the Additive wrapper. The point is that you have a choice: different
applications may ask for
Richard,
Thanks for your excellent feedback! Very helpful!
Signed multisets are unfamiliar to most of us, and I for one found the paper
a little fast-paced. Can you put a bit more into the documentation?
Definitely. That's what weekends are for... :) I'll add some sections to the
Wren,
For a specific example, I haven't the faintest intuition about
what 'map' should do. Suppose we have
{(k1)x1, (k2)x2}
and f x1 == f x2 = y. Should the value of map f {...} be
{(k1+k2)y} or {(k1`max`k2)y} or what?
Good question. I'd suppose that they should be parametrized by
Release early, release often. Here's a second version:
http://hackage.haskell.org/package/signed-multiset-0.2
Changes:
* Added the functions Data.SignedMultiset.isPositive and
Data.SignedMultiset.isNegative, which return whether all elements in a
signed multiset have respectively
Jacques,
In the literature, we have found [1] that these are sometimes also called
'hybrid sets'.
They also go by the name of 'shadow sets', which also has a cool ring to it. ;)
PS: the Haddock did not work for 0.2, but did for 0.1, you might want to look
into that.
As I just uploaded
Ivan,
This package provides an efficient implementation of so-called
signed multisets, which generalise multisets by allowing for
negative membership.
That is, elements in a signed multiset can have negative multiplicities.
Wait, something can be not in the multiset more than once? :o
Johannes,
This package provides an efficient implementation of so-called
signed multisets, which generalise multisets by allowing for
negative membership.
SignedMultiset a = Data.Map.Map a Integer
Indeed.
so what do I gain by using your library?
(what is the API difference?)
The library
I am pleased to announce the first release of signed-multiset, which implements
an abstract datatype for multisets with negative membership.
The package can be obtained from
http://hackage.haskell.org/package/signed-multiset-0.1
As always, feedback is welcome.
Cheers,
Stefan
Lauri wrote:
Sorts are typically constants, and there are usually a finite amount of them,
each presenting a level of the type system.
Indeed. The literature on generic programming sometimes uses the term
superkind to refer to the sort of BOX; see, for example,
Ralf Hinze and Johan
Duncan,
Just of out curiosity, what would be a compelling use case for singleton and
unit unboxed tuples?
For singleton unboxed tuples, any situation where you want to return a
single value but not force its evaluation. This occurs for example
with some low level functions in the
Here are the kinds of the type constructors:
(,,) :: * - * - * - *
(,) :: * - * - *
() :: *
(# ,, #) :: * - * - * - #
(# , #) :: * - * - #
BUT
(# #) :: * - #
Just of out curiosity, what
Martin,
importFile :: Editor - String - IO ()
importFile ed path = do
s - readFile path
ps - mapM (\x - makePair (x, )) (lines s)
es - return $ V.fromList ps
writeIORef ed es
loadFile :: Editor - String - IO ()
loadFile ed path = do
s - readFile path
ps - mapM makePair
Martin,
(The trick with `flip` is tempting, but again at the
cost of having to peer rather too closely at the implementation of
processFile when reading the code).
That trick is of course completely orthogonal. One could just as well write:
processFile :: (String - [a]) - (a - (String,
Martin,
Quick question: what's the difference between
importFile ed = readfile = fromRawFile = setEditor ed
and
importFile = readfile = fromRawFile = setEditor
that the former compiles but the latter doesn't?
Note that, in Haskell, function application has higher priority then any
Simon, Tom,
I hit this type-error message in GHC 7.0.3:
Cannot deal with a type function under a forall type:
forall e. El e u
Is there a fundamental reason why type functions under a forall type are a bad
idea? Of is it just something that hasn't been implemented/thought about yet?
Simon,
Regarding the note you attached to the Trac ticket on the pretty-printing of
kind ascriptions (http://hackage.haskell.org/trac/ghc/ticket/5141#comment:2):
Note, though, that it's likely that we're considering making operators
like '*' into type ''constructors'' rather that type
David,
Conor wrote:
But the news is not all bad. It is possible to add some eta-rules
without breaking the Geuvers property (for functions it's ok; for
pairs and unit it's ok if you make their patterns irrefutable).
Note that, in Haskell, for functions it's only ok if you leave seq and the
Mark,
Whether a variable is bound or free depends on the scope under consideration. In
(\x. x) (\y. x)
the variable x is bound in \x. x, but free in \y. x; hence, it's free in (\x.
x) (\y. x) as a whole. However, in
\x. (\x. x) (\y. x)
it's bound...
HTH,
Stefan
Chris,
I'm not a native English speaker and recently I was wondering about the two
words order and ordering (the main reason why I write this to the Haskell
mailing list, is that the type class Ordering does exist).
Irrelevant to your struggle, but note that the *type class* is dubbed Ord,
David,
Ryan Ingram wrote:
Haskell doesn't have true type functions; what you are really saying
is
instance Monad (\v - Vect k (Monomial v))
Daniel Fischer wrote:
I think there was a theoretical reason why that isn't allowed (making type
inference undecidable? I don't remember, I don't
Wolfgang,
We should definitely get rid of these Is* class identifiers like
IsString and IsList. We also don’t have IsNum, IsMonad, etc.
I see your point. For strings, however, there was of course never the
possibility to dub the class String as that name is already taken by the type
synonym.
Bulat,
btw, i also had proposal to automatically convert typeclasses used in
type declarations into constraints, [...]
Together with proposals i mentioned previously, it will allow to treat
existing code dealing with lists/strings as generic code working
with any sequential container type
Janis,
So, basically, we are annotating function
types, what is IIRC exactly what Janis and David are doing. (I hope
Janis corrects me if I'm wrong here).
Wrong only in that David's name is Daniel. :-)
Ah, I am terribly sorry. I just shouldn't type e-mails after having no more
than a
Nicolas,
OK, I better understand now where we disagree. You want to see in the type
whether or not the free theorem apply, I want them to always apply when
no call to unsafe function is made.
Implementing your suggestion would make me feel uncomfortable. Turning seq into
an unsafe operations
types in Eval would indeed make parametricity
less of an issue, but I do not quite agree that the cases in which one may
need seq on values of function type are insignificant.
Cheers,
Stefan
[*] Stefan Holdermans and Jurriaan Hage. Making “stricterness” more relevant.
In John P. Gallagher
Brandon,
Hm. Seems to me that (with TypeFamilies and FlexibleContexts)
h :: (x ~ y, Eval (y - Int)) = (x - Int) - (y - Int) - Int
should do that, but ghci is telling me it isn't (substituting Eq for Eval
for the nonce):
Prelude let h :: (x ~ y, Eq (y - Int)) = (x - Int) - (y - Int) -
Brandon,
h :: (x ~ y, Eval (y - Int)) = (x - Int) - (y - Int) - Int
But actually if you push the constraint inward, into the type so to say, you
actually get quite close to Janis' and David's solution.
Sorry, I was thinking out loud there. I meant the Eval constraint, not the
equality
Brandon,
Sorry, I was thinking out loud there. I meant the Eval constraint, not the
equality constraint. But, right now, I guess my comment only makes sense to
me, so let's pretend I kept quiet. ;-)
The point of this discussion is that the Eval constraint needs to be on one
of the
Nicolas,
I would deeply in favor of renaming seq to unsafeSeq, and introduce a
type class to reintroduce seq in a disciplined way.
There is a well-documented [1] trade-off here: Often, calls to seq are
introduced late in a developing cycle; typically after you have discovered a
space leak
Jason,
There is one case where you can break out of a monad without knowing which
monad it is. Well, kind of. It's cheating in a way because it does force
the use of the Identity monad. Even if it's cheating, it's still very clever
and interesting.
How is this cheating? Or better, how
Martijn,
In fact, I would argue that a monad which you cannot escape from is not very
useful at all. IO is the only exception I know of.
And that's only because, at least the runtime system allows for execution of a
computation inside the IO monad at top-level.
Cheers,
Stefan
Alexey,
There is one case where you can break out of a monad without knowing which
monad it is. Well, kind of. It's cheating in a way because it does force
the use of the Identity monad. Even if it's cheating, it's still very
clever and interesting.
How is this cheating? Or better, how
Ivan,
in `size` function, what does the `~` mean ?
A lazy pattern match: http://en.wikibooks.org/wiki/Haskell/Laziness
(there is a better name for it, but I can't remember).
Irrefutable pattern? ;-)
Cheers,
Stefan
___
Haskell-Cafe mailing list
Martijn,
Ryan wrote:
Unfortunately, this makes things like
infinite_xs - sequence (repeat arbitrary)
no longer work, since the state never comes out the other side.
You replied:
You're asking to execute an infinite number of monadic actions. How
can this ever terminate at all?
There
Dan,
class C a where
foo :: a - String
instance C a where
foo _ = universal
instance C Int where
foo _ = Int
[...]
Now, IncoherentInstances is something most people would suggest you
don't use
(even people who are cool with OverlappingInstances). However, it
turns out
that
Daniel,
A while ago we were at a presentation of Feldspar, a
Embedded Domain Specific Language, and one of the negative points of
using haskell was that the error messages could be cryptic due to the
various ways it was implemented.
Incidentally, but actually by no means surprisingly, this
Patrick,
It seems that I need to distinguish between a theory for Haskell and a
given implementation (GHCi).
What do you mean by this?
Obviously I get two different types
Wrong. You get exactly the same type, it's just that GHCi detected
that you have a fancy name for this type, so it
Dear Patrick,
From the responses to my query, it seems that I cannot rely totally on
the compiler for my research question which is concerned with the
meaning of Haskell constructs I will have to consult the Haskell
Report.
For both practical and theoretical matters, GHC provides a very
Stephen,
oo f g = (f .) . g
ooo f g = ((f .) .) . g
Why are these also called blackbird and bunting?
Thanks,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Simon,
Regarding distinguishing between type indices and parameters, you
suggested:
type family T3 f !e :: * -- The ! indicates a type parameter
(not
an index)
I'd rather have indices, rather than parameters, explicated by mean of
syntax. This seems more consistent with
Simon,
type family T3 {|f|} e :: *
Indeed. But do you want to use that syntax for class parameters
too? That would be a big change
class C {|a|} where
Well... That would be the most consistent then. But... it looks weird.
And it breaks code, of course. One could argue
John,
It might be better to go about it in a fashion similar to how one
would use Haskell to create a new language using Happy, but instead
of making a full fledged language create a language that makes only
minor adjustments to the official language where most of the
original source
Eugene,
Consider the type: (forall a . a) - String.
It's of rank 2.
What is the definition of rank of a polymorphic type?
The minimal rank of a type is given by
rank (forall a. t) = 1 `max` rank t
rank (t - u) = (if rank t == 0 then 0 else rank t + 1) `max`
rank u
rank _
Eugene,
1) Does there exist an authoritative source saying the same? Not that
I'm doubting, just supposing that the source would have other
interesting information, too :)
You may want to have a look at the already mentioned JFP-article by
Peyton Jones et al. and perhaps the work of Kfoury
John, Miguel (and others),
Don Stewart wrote, the guarantees of purity the type system
provides are extremely
useful for verification purposes. My response to this is in
theory. This is what caught my attention initially, but the
language lacks polish and does not appear to be going in a
To feed, or not to feed: that is the question:
Whether 'tis nobler in the mind to suffer
The quips and ramblings of outrageous trolling,
Or to take arms against a sea of nonsense,
And by opposing end them?
Brilliant. Just brilliant.
+1
Cheers,
Stefan
So long as we bastardize the bard, we best bastardize him fully! :)
If only we could claim:
Though this be madness, yet there is method in 't.
Cheers,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Tom,
I was wondering whether there are any universities that teach about
Haskell type families or GADTs?
I'm quite sure at least GADTs are covered in INFOMAFP, the graduate
course on Advanced Functional Programming at UU:
http://www.cs.uu.nl/docs/vakken/afp
Cheers,
Stefan
Answers to spec.
You didn't answered the homework question:
I don't know if this is homework.
I'm a bit suspicious: http://www.dcs.shef.ac.uk/intranet/teaching/modules/level2/com2010.html
.
See http://www.haskell.org/haskellwiki/Homework_help .
Cheers,
Stefan
Luke,
This is the typical bottled response to people asking for homework
help. But spot135 has done a good job so far: stated his problems,
shown his work so far, asking for guidance not answers. And the
community has done a good job helping: no answers, but hints and
leading questions. I
that the old version of the data will never be needed again,
and hence update it in-place. Making this kind of thing more
automatic could be interesting theoretically and practically.
[Warning: shameless plug follows.]
Have you had a look at our 2008 PEPM paper?
Jurriaan Hage and Stefan Holdermans
Erik,
http://people.cs.uu.nl/stefan/pubs/hage08heap.html
Getting connection refused on that.
Don't know: it still works for me.
Cheers,
Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Manuel, Simon,
I've spotted a hopefully small but for us quite annoying bug in GHC's
type checker: it loops when overloading resolving involves a circular
constraint graph containing type-family applications.
The following program (also attached) demonstrates the problem:
{-# LANGUAGE
Dear Martin,
Your example must loop because as you show below
the instance declaration leads to a cycle.
By black-holing you probably mean co-induction. That is,
if the statement to proven appears again, we assume it must hold.
However, type classes are by default inductive, so there's no
Dear Martin,
By black-holing you probably mean co-induction. That is,
if the statement to proven appears again, we assume it must hold.
However, type classes are by default inductive, so there's no
easy fix to offer to your problem.
A propos: are there fundamental objections to coinductive
Manuel, Simon,
I've spotted a hopefully small but for us quite annoying bug in GHC's
type checker: it loops when overloading resolving involves a circular
constraint graph containing type-family applications.
The following program (also attached) demonstrates the problem:
{-# LANGUAGE
Dear Martin,
Your example must loop because as you show below
the instance declaration leads to a cycle.
By black-holing you probably mean co-induction. That is,
if the statement to proven appears again, we assume it must hold.
However, type classes are by default inductive, so there's no
Dear Martin,
By black-holing you probably mean co-induction. That is,
if the statement to proven appears again, we assume it must hold.
However, type classes are by default inductive, so there's no
easy fix to offer to your problem.
A propos: are there fundamental objections to coinductive
Conor,
I'm scared. What about this?
data EQ :: * - * - * where
Refl :: EQ x x
class Public x where
blah :: EQ x Fred
instance Public Fred where
blah = Refl
What happens when I say
newtype Jim = Hide Fred deriving Public
? I tried it. I get
blah :: EQ Jim Fred
It's clear that
Conor,
What happens when I say
newtype Jim = Hide Fred deriving Public
? I tried it. I get
blah :: EQ Jim Fred
Thinking of it; this *does* make sense in System FC. The newtype-
declaration gives you as an axiom
Hide :: Jim ~ Fred
To give an instance of Public for Jim, we have to
Kashyap,
Can someone please send me a working example based on the contents
posted in the URL below?
There's a small typo in the post: the definition of Proto should read
data Proto = Proto {a :: A, b :: B, c :: C}
The rest seems fine to me. (See below for an excerpt).
Cheers,
Stefan
Andrew,
That seems simple enough (although problematic to implement).
However, the Report seems to say that it matters whether or not the
bindings are muturally recursive [but I'm not sure precisely *how*
it matters...]
It means that functions can only be used monomorphically within
Christopher,
Wouldn't it be great if pattern variables could be used more than once
in a pattern? Like so:
foo [x,x,_,x] = The values are the same!
foo _ = They're not the same!
These are called nonlinear patterns. I think Miranda (a precursor of
Haskell, sort of) used to have
Petr,
If I want to make it a functor in the last type variable (b), I can
just define
instance Functor (X a) where
fmap f (X a b) = X a (f b)
But how do I write it if I want X to be a functor in its first type
variable?
Short answer: you can't. Easiest way to workaround is to define
Petr,
Short answer: you can't. Easiest way to workaround is to define a
newtype wrapper around your original datatype:
newtype X' b a = X' {unX' :: X a b}
instance Functor (X' b) where
fmap g (X' (X a b)) = X' (X b (g a))
Err
fmap g (X' (X a b)) = X' (X (g a) b)
Cheers,
Stefan
can be derived in Haskell:
Alexey Rodriguez, Stefan Holdermans, Andres Löh, and Johan Jeuring.
Generic programming with fixed points for mutually recursive
datatypes, 2009. To appear in the proceedings of the 14th ACM SIGPLAN
International Conference on Functional Programming, ICFP 2009
Niklas,
My rationale is as follows. With the introduction of GADTs, we now
have two ways to write datatype declarations, the old simple way and
the GADTs way. The GADTs way fits better syntactically with Haskell's
other syntactic constructs, in all ways. The general style is
(somewhat
Niklas,
In other words, in your 2x3 grid of syntactic x expressiveness, I want
the two points corresponding to classic syntax x {existential
quantification, GADTs} to be removed from the language. My second
semi-proposal also makes each of the three points corresponding to the
new cool syntax a
Niklas,
What you really want or mean when you use
the classic syntax with existential quantification is
data Foo = Foo (exists a . (Show a) = a)
Having that would make a lot more sense, and would fit well together
with the intuition of the classic syntax.
How would you then define
data
Niklas,
My rationale is as follows. With the introduction of GADTs, we now
have two ways to write datatype declarations, the old simple way and
the GADTs way. The GADTs way fits better syntactically with Haskell's
other syntactic constructs, in all ways. The general style is
(somewhat
Niklas,
I am opposed since
a) it requires the addition of extra syntax to the language, and
b) we have another, better, way to do it.
Somewhat pointed, I don't think the C++ way of putting all imaginable
ways to do the same thing into the language is a sound design
principle. If we have two
Paul,
Did you mean to say that const is strict in its first param and
lazy in its second (since const _|_ y = _|_)? Also, can you explain
your notation, how does a - {S} - b -{L} a indicate the
strictness? Why not just {S} a - {L} b - a?
I'm sorry for the confusion. Indeed, const, as the
Dear Paul,
This thread as well as your blog post is very interesting. Hopefully I
can add something more or less valuable to it.
On your blog, you mention that your scheme for run-time strictness
analysis doesn't work out because it'll have you force a function
first before you can find
Ryan,
Also, partial application + seq throws a wrench in things: [...]
You're absolutely right. I did not take into account the effects of
seq in my previous post. However, this is exactly the subject of a
paper I presented at TFP, two weeks ago. A revised version of the
paper will be
Paul,
In trying to follow your email I got a bit confused by your notation -
const :: a - b - a const x y = x could read a - {S} - b -
{L} a
Here, we have annotated the function-space constructor (-) with
information about whether the corresponding function is strict or
lazy in
Henry,
Jason pointed out:
You'd get fromEnum and toEnum. Which I think, would give you the
int mapping that you are after.
fromEnum :: Enum a = a - Int
toEnum :: Enum a = Int - a
To me, this would indeed seem the way to go for your particular example.
Moreover, as for generic producer
Henry,
Ah, pressed send way to early. Of course, the definition should change
a little as well:
convert :: Data a = Int - a
convert i = xwhere
x = fromConstr ( dataTypeConstrs (dataTypeOf x) !! (i - 1) )
Cheers,
Stefan
___
Jochem,
rationals n = (putStr . unlines . map show) (take n (nub [x % y |
y -
[1..], x - [1..y], x y]))
rationals n :: Integer - [Ratio]
I meant Integer - String obviously.
Er... what about
rationals :: Int - IO ()
? ;-)
To the original poster: next time, just leave the function
I'm sorry, there is no such animal as safe global installation,
in the sense of download this one package and do what it says.
Well I have been doing that for more then 10 years, it is one of the
functions any decent package management systems is designed to do.
Time to adopt another goodie
If we had been interested in raising fierce discussions about n+k
patterns or how and where cabal installs things, we could have easily
achieved the same effect with much less effort.
you mean that we should shoot up? :)
If the release of UHC contributes to whatever discussion regarding
Chris,
In the inferred type, there should be IxMap l instead of IxMap i,
does anybody know what I'm doing wrong?
Your calls to empty are just ambiguous.
Let's say I want to get a hold of an empty map for A :|: B for some
types A and B. And let's say that you've instance for A hanging
Peter,
I've run into a bug that looks to be the same as the one described
here:
http://hackage.haskell.org/trac/ghc/ticket/1897
It does not seem like a bug, although the type-error message may be a
bit confusing as is the fact that GHC happily infers a type for the
signature-less
Isaac,
Does anyone know if it is possible to specify a default definition
for an
associated type synonym?
According to http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus
defaults for associated types is still a TODO.
Cheers,
Stefan
Isaac,
Does anyone know if it is possible to specify a default definition
for an
associated type synonym?
According to http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus
defaults for associated types is still a TODO.
Cheers,
Stefan
Manuel,
Should I report this a bug? Or is it perhaps already been taken
care of in the head?
Probably the latter.
But really as, Bulat wrote, type families in 6.8 are unsupported.
Please test your code with a HEAD snapshot. If that goes wrong, a
bug report on Trac would be most
I've written this cute ;-) piece of code involving an associated type
synonym,
{-# OPTIONS_GHC -fglasgow-exts #-}
class ZipWithA a where
type Elem a :: *
zipWithA:: [Elem a] - a
instance ZipWithA [a] where
type Elem [a] = a
zipWithA xs = xs
instance ZipWithA b
1 - 100 of 242 matches
Mail list logo
