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
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
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
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
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
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
Ian,
We are pleased to announce the Release Candidate phase for GHC 6.8.1.
That's 6.8, right? Or have I missed something?
Cheers,
Stefan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Hi,
Is there any data available on how often, in GHC-generated code,
closures are being updated in-place as opposed to and in comparison
with being replaced by indirections to their results?
How is it decided whether an in-place or an indirecting update is
performed?
Thanks,
Stefan
I noticed that the makefile in ghc/libraries is changed recently---
could it be broken? When building GHC HEAD on Mac OS X (Darwin, Power
PC), I got:
...
make -C libraries boot
rm -f -rf bootstrapping.Cabal
cp -R Cabal bootstrapping.Cabal
bootstrapping.Cabal \( -name *.o -o -name
I'm trying to build GHC HEAD on Mac OS 10.4.8 (PowerPC), but end up
with a linker error:
../compiler/stage1/ghc-inplace -o stage2/ghc-6.7.20070228 -H16m -O
-package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -
I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI
Dear all,
Does GHC (still) perform sharing analysis as described in 'Once Upon
a Polymorphic Type' [2] and/or Keith Wansbrough's PhD thesis [1]? If
so, how does one inspect the results of the analysis?
Thanks in advance,
Stefan
-
[1] Keith Wansbrough. Simple Polymorphic Usage
Hi all,
I have to admit that I haven't checked if this is a known issue...
The following is tested with both GHC 6.4.1 and 6.4.2; I have not
checked the HEAD.
Let me define a simple GADT |F|,
-- a simple GADT
data F :: * - * where F :: Int - F ()
and a more or less trivial function
Simon,
Yes, it's quite deliberate. See 5.4 of
http://research.microsoft.com/%7Esimonpj/papers/gadt/gadt-icfp.pdf
The alternative design choice is to reject both programs, but in
Haskell
(because of laziness) the evaluation order is prescribed, so accepting
the former seems right.
Brian,
Also, the rule would not be quite as simple as you make it out to
be,
since
forall a. (forall b. Foo a b = a - b) - Int
is a legal type, for example.
Is it? GHCi gives me an error if I try typing a function like that.
{-# OPTIONS -fglasgow-exts #-}
class Foo a b
f ::
Wukaichen,
data People = A | B | C | D | E | F deriving (Show, Eq, Ord, Enum)
data Pair a = Pair a a deriving Eq
instance Show (Pair People) where
show (Pair x y) = ++ show x ++ , ++ show y ++
GHC is right, actually. Haskell 98 requires instance declarations to
have the form
Wolfgang,
Another Mac OS X installer:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050308.pkg.zip
Works great for me. The double-clickable icons for GHCi are great, too
I second that.
How much effort did take to construct the installer? Is it a process
that could easily be automated? Would
Jim,
Why is
gfindtype :: (Data x, Data y) = x - Maybe y
and not
gfindtype :: (Data x, Typeable y) = x - Maybe y
?
Because you're not always interested in a subterm of the same type as
the parent node.
gfindtype abc :: Maybe Char -- yields Just 'a'
gfindtype abc :: Maybe String -- yields Just bc
Jim,
Why is
gfindtype :: (Data x, Data y) = x - Maybe y
and not
gfindtype :: (Data x, Typeable y) = x - Maybe y
?
Because you're not always interested in a subterm of the same type as
the parent node.
Ouch, answered your question before I really read it, i.e., before a
first cup of coffee.
28 matches
Mail list logo
