In other words, the API is only changed in that an additional binding
has been exported for each top-level definition to which you can write
(only of the correct type) a new definition. This is something that
you could do manually, write it by hand, but I want it automatic for
any module I load into GHCi
The abstract-par class has used multi-parameter type classes with fundeps:
http://hackage.haskell.org/package/abstract-par-0.3.1/docs/Control-Monad-Par-Class.html#g:1
And I'm trying to port it to use type families. But the following
combination seems to be completely unusable for me right now
Oops, right after I sent I realized the answer ;-). I needed to delete one
character to uncurry the type function. That is:
type Future m
instead of
type Future m a
The fixed version is here:
https://github.com/iu-parfunc/lvars/blob/2b733d3044fde861e9c9b181258e7f9865afa204/haskell/par
Christopher Done wrote:
It's very easy to state this problem without enough details and mislead
people into providing a solution for a different problem, so I'll try to
include all the information and use-case. I need a function that can
store a value in a concrete opaque type. I know the type
On 4 October 2013 10:56, Heinrich Apfelmus apfel...@quantentunnel.de wrote:
In particular, the Locker stores arbitrary values like Dynamic , except
that values are extracted and removed with the help of a Key . This gets
rid of the Typeable constraint.
lock :: Key a - a - Locker
I can't
:: Key a - a - Locker
I can't pass anything with class constraints to that.
I don't know what something with a class constraint means. But I guess
you want to pass a value with a *polymorphic* type? This is no problem,
but requires impredicative polymorphism:
a = (forall b. Show b = b - IO
| However, I want to write this as a core-to-core
| translation as a ghc-plugin. I want the definition go = putStrLn Hello
| World! to be translated to what I wrote above. Core cannot generate new
| names to be exported from a module, so go_ is now gone.
Wait... what do you mean Core cannot
Hi Chris,
Maybe this package (from Edward Kmett, surprisingly) could help:
http://hackage.haskell.org/package/constraints-0.3.3/docs/Data-Constraint.html?
Considering it kind of reifies the type class constraints, I'm wondering
whether you could use this to carry the constraints along the value
It's very easy to state this problem without enough details and mislead
people into providing a solution for a different problem, so I'll try to
include all the information and use-case. I need a function that can
store a value in a concrete opaque type. I know the type of the value
when I store
TP wrote:
But I have still a question: is the behavior of GHC correct in the example
of my initial post?
See here:
http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/type-class-extensions.html#instance-overlap
When matching, GHC takes no account of the context of the instance
On Sun, Sep 22, 2013 at 11:07 AM, TP paratribulati...@free.fr wrote:
My misunderstanding came from a confusion between a context and a
constraint. The context is what is before the =, and the constraint is
what is after, i.e. the main part of the instance declaration.
Hi TP,
I think context
Constraint. In other words:
instance Context = InstanceHead
instance (Constraint, Constraint2) = InstanceHead
This is indeed more in accordance with what I believe to be a context or a
constraint. But, it seems that in this page
http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/type
.
file:///usr/share/doc/ghc-doc/html/users_guide/type-class-
extensions.html#instance-overlap
How to make GHC realize that in the second instance below, the instance
context is not satisfied, such that the first instance has to be used?
(Indeed, a Scalar is a `Tensor 'Zero`, so the strict
-doc/html/users_guide/type-class-
extensions.html#instance-overlap
How to make GHC realize that in the second instance below, the instance
context is not satisfied, such that the first instance has to be used?
(Indeed, a Scalar is a `Tensor 'Zero`, so the strict inequality `'Zero : n
FlexibleInstances #-}
{-# LANGUAGE OverlappingInstances #-}
import Prelude hiding ((*))
data Nat = Zero | Succ Nat
deriving ( Show, Eq, Ord )
data Tensor :: Nat - * where
Tensor :: Tensor order
Mult :: Scalar - Tensor order - Tensor order
deriving instance Show (Tensor order)
type
a) }
data Id a = Id { name :: a }
from Expr String to, say, Expr Int where Int names may represent some
keys in the hash map?
Regards,
Sergey
[1] -
http://stackoverflow.com/questions/5434889/is-it-possible-to-use-syb-to-transform-the-type
PS sclv suggested to use synthesize from SYB to solve
Brent Yorgey byorgey at seas.upenn.edu writes:
On Tue, Sep 03, 2013 at 11:33:46AM +, AntC wrote:
I want an instance and type improvement constraint of the form
instance (f ~ (- Bool)) = C Foo (f b) where ...
There is no operator section syntax for types. Moreover
I'm probably being dumb, but Hoogle nor the wiki are helping me.
I want an instance and type improvement constraint of the form
instance (f ~ (- Bool)) = C Foo (f b) where ...
The first arg to C is driving type improvement, for example:
instance (f ~ []) = C Bar (f b) where
On Tue, Sep 03, 2013 at 11:33:46AM +, AntC wrote:
I'm probably being dumb, but Hoogle nor the wiki are helping me.
I want an instance and type improvement constraint of the form
instance (f ~ (- Bool)) = C Foo (f b) where ...
The first arg to C is driving type improvement
] Extending Type Classes
|
|
| The problem of refinement of type classes annoys me from time to time
| when I work on the NumericPrelude. It is an experimental type class
| hierarchy for mathematical types. Sometimes a new data type T shall be
| implemented and it turns out that you can implement
The problem of refinement of type classes annoys me from time to time
when I work on the NumericPrelude. It is an experimental type class
hierarchy for mathematical types. Sometimes a new data type T shall be
implemented and it turns out that you can implement only a part of all
methods
GHC tries to typecheck quotations. In this case it's trying to typecheck the
declaration
type Bar = FooT $t
Part of type checking is rejecting recursive type synonyms. Here GHC is
rejecting it because it *might* be recursive, depending on how $t is filled in.
The trouble is that we
This file gives me the error Cycle in type synonym declarations Can
anyone tell me why? I'm just trying to write a function to create a
type that is a FooT with the type parameter fixed.
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH (Q, Dec, TypeQ)
data FooT a = FooT a
foo
Hi,
In this case, you have two 'FooT' names: one is the Type and the other
is the Constructor. Perhaps Template Haskell is capturing the wrong
one inside the quote (probably the constructor). When you have name
shadowing, you should always use a lookup function. You can find
these lookup
On Tue, Aug 20, 2013 at 5:00 PM, David Fox d...@seereason.com wrote:
This file gives me the error Cycle in type synonym declarations Can
anyone tell me why? I'm just trying to write a function to create a
type that is a FooT with the type parameter fixed.
{-# LANGUAGE TemplateHaskell
On Tue, Aug 20, 2013 at 2:35 PM, adam vogt vogt.a...@gmail.com wrote:
On Tue, Aug 20, 2013 at 5:00 PM, David Fox d...@seereason.com wrote:
This file gives me the error Cycle in type synonym declarations Can
anyone tell me why? I'm just trying to write a function to create a
type
:: IO [Int])
or give hello a monomorphic type signature, such as
hello :: IO [Int]
Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sun, Aug 18, 2013 at 10:16:06PM +0200, Hartmut Pfarr wrote:
I played a bit with your suggestion, and it is running now :-)
But instead of IO [Int] I think we need IO [Only Int] because
of the 1-element-tupel problem?
Yes you're right. I had forgotten that postgresql-simple dealt with
Hello,
I've a problem connecting to my postgresql database.
Can You help me fix the ambigious type signature?
(The example is identical to the first 5-liner-example in the package
documentation)
http://hackage.haskell.org/packages/archive/postgresql-simple/0.3.5.0/doc/html/Database
On Sat, Aug 17, 2013 at 1:35 PM, Hartmut Pfarr
hartmut0...@googlemail.comwrote:
(The example is identical to the first 5-liner-example in the package
documentation)
As I read it, the example has a typo: it should be using `query_` instead
of `query`. See
Thx, I changed now from query to query_
Now the coding is like that:
{-# LANGUAGE OverloadedStrings #-}
import Database.PostgreSQL.Simple
import Database.PostgreSQL.Simple.FromRow
hello :: (FromRow a) = IO [a]
hello = do
main = print = (hello :: IO [Int])
or give hello a monomorphic type signature, such as
hello :: IO [Int]
Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sat, Aug 17, 2013 at 5:59 PM, Hartmut Pfarr
hartmut0...@googlemail.comwrote:
query_ conn select 2 + 2
I've no errors any more.
But: I don't see any result (for sure, it is not coeded yet)
Yes, because you're not capturing it; it's the return value from `query_`,
which you are throwing
... thx all for helping. Now the coding works: it puts the following out.
Kind regards
Hartmut
*Main main
Only {fromOnly = 4}
--
Only {fromOnly = 101}
Only {fromOnly = 102}
Only {fromOnly = 103}
--
blub 101 51
blub 102 52
blub 103 53
The
I'm using the TypeFamilies extension to generate types that are quite
large. GHC can handle these large types fine when they are created
manually, but when type families get involved, GHC's performance dies.
It's doing in quadratic time what looks to me like it should be linear
time. I don't
I don't know much about type families, but I recall this:
http://ghc.haskell.org/trac/ghc/ticket/5321
The bug is marked as fixed, but perhaps behaviour you observed shows that there
are other cases
where constraqint solver is slow. I'd consider reporting this as GHC bug.
Janek
Thanks for pointing to that ticket. At first after reading through it, I
thought my mistake was not using tail call recursion. But I updated the
type families and they actually ran slower!
I've gone ahead and reported a bug:
http://ghc.haskell.org/trac/ghc/ticket/8095
On Fri, Jul 26, 2013
On 07/20/2013 04:49 PM, adam vogt wrote:
Hi Michael,
It's fairly straightforward to generate the new data with template
haskell [1], and on the same page, section 10.7 'generic' zipWith is
likely to be similar to your merging code.
[1]
On Sat, Jul 20, 2013 at 12:14 AM, Michael Orlitzky mich...@orlitzky.com wrote:
For posterity, I report failure =)
Hi Michael,
It's fairly straightforward to generate the new data with template
haskell [1], and on the same page, section 10.7 'generic' zipWith is
likely to be similar to your
On 07/16/2013 04:57 PM, Michael Orlitzky wrote:
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
default = Cfg False
The user can override the defaults one
On Tue, Jul 16, 2013 at 04:57:59PM -0400, Michael Orlitzky wrote:
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields
On 07/16/2013 09:57 PM, Michael Orlitzky wrote:
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
a Cfg and create a new type
with Cfg's fields wrapped in Maybe?
You can always try
data Cfg f = Cfg { verbose :: f Bool }
and set f to Maybe or Identity depending on what you use it for. It will be
slightly notationally cumbersome to extract values from the Identity functor
though
The suggestion of parameterizing on a functor would be good, however
there's another approach I've often seen (although it's not quite what
you've asked for). You can leave your config datatype alone, but instead
of making it a monoid have your configuration parsers return functions with
the type
often seen (although it's not quite what
you've asked for). You can leave your config datatype alone, but instead
of making it a monoid have your configuration parsers return functions with
the type (Cfg - Cfg). You can wrap these functions in Endo to get a
monoid, combine them together
configuration parsers return
functions with the type (Cfg - Cfg). You can wrap these functions in
Endo to get a monoid, combine them together, and then apply that
function to the default configuration.
I'm using cmdargs for the command-line parsing, and I think (if I don't
want to abandon its magic
Hello,
I know there are many haskellers interested in dependent type theory so I
wanted to mention that there is now an IRC channel on freenode for
discussing Homotopy Type Theory (HoTT), e.g., the recent book, possible
implementations, dependent type theory in general, etc.
The channel
Hello everyone,
Is there a way to automatically reify a type ?
In other words, to do the following:
reifyType (LitT ...) = ConT ''LitT ...
I am using Template Haskell and I want the generated code to have
access to Type datatypes that were available to the Template Haskell
code.
Cheers,
Jose
Hello!
I'm not sure if this is what you're asking for, as it doesn't fit that line
of code. 'LitT' is a data constructor not a type constructor. So instead
it'd be
reifyType (LitT ...) = ConE 'LitT ...
If this is what you're looking for, then 'lift' is what you want:
http
That's exactly what I mean!
I'll give it a try.
Thanks Michael,
Jose
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello,
I am getting the following error message:
No instance for (Lift Type)
arising from a use of `lift'
Possible fix: add an instance declaration for (Lift Type)
I have imported Language.Haskell.TH.Instances.
Is there anything else I have to do ?
Regards,
Jose
wrote:
Hello,
I am getting the following error message:
No instance for (Lift Type)
arising from a use of `lift'
Possible fix: add an instance declaration for (Lift Type)
I have imported Language.Haskell.TH.Instances.
Is there anything else I have to do ?
Regards,
Jose
are in the graph.
But perhaps I misunderstood your question.
Thomas
Am 09.07.2013 23:26, schrieb KC:
type Graph n w = Array (n,n) (Maybe w)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
is slightly
different, and there will be different trade-offs.
Twan
On 09/07/13 23:26, KC wrote:
Is the following implemented by a sparse matrix representation?
type Graph n w = Array (n,n) (Maybe w)
--
--
Regards,
KC
___
Haskell-Cafe mailing
like IntMap
(IntMap w) or Map (n,n) w or Array n (IntMap w). Each of these
representations is slightly different, and there will be different
trade-offs.
Twan
On 09/07/13 23:26, KC wrote:
Is the following implemented by a sparse matrix representation?
type Graph n w = Array (n,n) (Maybe w
type Graph n w = Array (n,n) (Maybe w)
--
--
Regards,
KC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Fri, Jul 5, 2013 at 11:03 PM, Ömer Sinan Ağacan omeraga...@gmail.comwrote:
There's an implicit quantifier in type of `f`, like this: `f :: forall
a. a - ListF a a`. When I add `ScopedTypeVariables` and `forall a.
...` in top level definition, it's like all `a`s in scope of top level
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/07/13 19:50, Chaddaï Fouché wrote:
On Fri, Jul 5, 2013 at 11:03 PM, Ömer Sinan A?acan
omeraga...@gmail.comwrote:
There's an implicit quantifier in type of `f`, like this: `f ::
forall a. a - ListF a a`. When I add `ScopedTypeVariables
Hi Vlatko.
On 2 July 2013 16:03, Vlatko Basic vlatko.ba...@gmail.com wrote:
Is there a nicer way to extract the 'IO String' from 'IOS',
without 'case' or without pattern matching the whole 'P'?
You might enjoy the newtype package.
http://hackage.haskell.org/package/newtype
Hope this helps,
Hello all,
I was looking for my master thesis topic and my supervisor suggested an
idea of extending class system so it enables refactoring Type Class
hierarchy without affecting client source code which is using
refactored classes.
One example is Functor - Applicative - Monad problem
Hi all,
I came across an interesting type checker error, a function is
accepted in top level, but rejected by type checker when moved to
`where ...` clause.
I moved required code to a new module for demonstration purposes:
module Bug where
fix :: (a - a) - a
fix f = let x = f x
If you remove the type signature from f in the where clause it will
work. The reason is because the type signature listed there, the a is
a different a than in the top level signature. If you change it from
a to x, it says it should be the a that you can't seem to specify.
If you add the pragma
understand, the problem is because in this definition:
where
f :: a - ListF a a
f a = ConsF a (fn a)
There's an implicit quantifier in type of `f`, like this: `f :: forall
a. a - ListF a a`. When I add `ScopedTypeVariables` and `forall a.
...` in top level definition, it's like all `a`s
of
IOS a - a
getC_IO (P _ _ (IOS a)) = a
Original Message
Subject: Re: [Haskell-cafe] Casting newtype to base type?
From: Malcolm Wallace malcolm.wall...@me.com
To: vlatko.ba...@gmail.com
Cc: Haskell-Cafe haskell-cafe@haskell.org
Date: 01.07.2013 17:24
On 1 Jul 2013, at 16:07
On Tue, Jul 02, 2013 at 03:03:08PM +0200, Vlatko Basic wrote:
Is there a nicer way to extract the 'IO String' from 'IOS',
without 'case' or without pattern matching the whole 'P'?
newtype IOS = IOS (IO String)
data P = P {
getA :: String,
getB :: String,
getC :: IOS
} deriving
Original Message
Subject: Re: [Haskell-cafe] Casting newtype to base type?
From: Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk
To: haskell-cafe@haskell.org
Date: 02.07.2013 15:25
On Tue, Jul 02, 2013 at 03:03:08PM +0200, Vlatko Basic wrote:
Is there a nicer way
You could always just put it into your newtype:
newtype IOS = IOS {
unIOS :: IO String
}
On Tue, Jul 2, 2013 at 9:31 AM, Vlatko Basic vlatko.ba...@gmail.com wrote:
Original Message
Subject: Re: [Haskell-cafe] Casting newtype to base type?
From: Tom Ellis tom-lists
I try to set 'c' field in
fun :: FilePath - P - IO P
fun path p = do
b - doesFileExist path
...
return $ p {c = readFile path}
I get error
Couldn't match expected type `IOS' with actual type `IO String'
which is correct.
So, the question is:
Is it possible to somehow cast
.
data P = P {
a :: String,
b :: String,
c :: IOS
} deriving (Show, Eq)
but now when I try to set 'c' field in
fun :: FilePath - P - IO P
fun path p = do
b - doesFileExist path
...
return $ p {c = readFile path}
I get error
Couldn't match expected type `IOS
On Mon, Jul 01, 2013 at 05:07:00PM +0200, Vlatko Basic wrote:
Hello Cafe!
I had a (simplified) record
data P = P {
a :: String,
b :: String,
c :: IO String
} deriving (Show, Eq)
but to get automatic deriving of 'Show' and 'Eq' for 'data P' I have
created 'newtype
' instances
newtype IOS = IO String
Not quite! That is a newtype'd String, not a newtype's (IO String). Try this:
newtype IOS = IOS (IO String)
but now when I try to set 'c' field in
return $ p {c = readFile path}
I get error
Couldn't match expected type `IOS' with actual type `IO
Hi Wallace,
yes, indeed. Now I see I mixed newtype with type in declaration, and forgot the
first one is a constructor.
Original Message
Subject: Re: [Haskell-cafe] Casting newtype to base type?
From: Malcolm Wallace malcolm.wall...@me.com
To: vlatko.ba...@gmail.com
Cc
I'm experimenting. The IO field is just a helper field, so it shouldn't have any
consequences.
Original Message
Subject: Re: [Haskell-cafe] Casting newtype to base type?
From: Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk
To: haskell-cafe@haskell.org
Date: 01.07.2013
It seems very interesting, but I have not currently the time to make a
detailed comparison with vector/tensor algebra. Moreover I have not
I would suggest the freely available
Oersted Medal Lecture 2002
by David Hestenes
on how it is to be run.
best, b
On Jun 25, 2013, at 1:03 PM, Ben wrote:
hello cafe --
by now i'm sure you have heard that the homotopy type theory folks have just
written up a free introductory book on their project.
http://homotopytypetheory.org/2013/06/20/the-hott-book/
gabriel
/
Geigen seems like a nice DSL that could well be embedded in Haskell.
Anyway, the reason I pointed out Vectro is that it answers your
question about reifying and reflecting type-level integers (by means
of a type class).
___
Haskell-Cafe mailing list
hello cafe --
by now i'm sure you have heard that the homotopy type theory folks have just
written up a free introductory book on their project.
http://homotopytypetheory.org/2013/06/20/the-hott-book/
gabriel gonzalez and i are starting up a small reading group for the book. the
level
I have not your
level of knowledge in Haskell/Standard ML and type theory, so I have already
a lot of work. However, for sure this is something I will do in the few next
years, because I think that notations are very important in physics and
mathematics: it is of huge interest to have
Thank you guys.
I cannot use a explicit type for there are quite a few of them. But from
MigMit, I understand why my original cannot work.
On Sat, Jun 22, 2013 at 4:46 AM, Vincent Ambo taz...@gmail.com wrote:
Is there a reason why you can't use an explicit type variable?
{-# LANGUAGE
already offered. For example, the Vectro library has been described
back in 2006:
http://ofb.net/~frederik/vectro/draft-r2.pdf
http://ofb.net/~frederik/vectro/
The paper also talks about reifying type-level integers to value-level
integers, and reflecting them back. Recent GHC
data ActionData = AD { oldData :: (FromJSON j, ToJSON j) = j
, newData :: (FromJSON j, ToJSON j) = j}
instance ToJSON ActionData where
toJSON (AD o n) = object [ oldData .= o
, newData .= n ]
instance FromJSON ActionData where
parseJSON
have to decide what j to use when serializing. Haskell won't
automagically substitute some suitable type for you.
So, that's a classic mismatch: for serializing (ToJSON) you need your j type
to be known to the AD value (meaning: it should be quantified existentially),
but for deserializing you
Is there a reason why you can't use an explicit type variable?
{-# LANGUAGE OverloadedStrings, ExistentialQuantification #-}
import Data.Aeson
import Control.Applicative
import Control.Monad (mzero)
data ActionData j
= (FromJSON j, ToJSON j) = AD j j
instance ToJSON (ActionData j) where
) is still requried on the first to fix the type there. How else
could the compiler know that you mean 0.0 to be a GLdouble and not a
GLfloat?
it's curious that
(0.0::GLdouble) 0.0 0.0
is good enough and that
(0.0::GLdouble) (0.0::GLdouble) (0.0::GLdouble)
is not required. I
, the Vectro library has been described
back in 2006:
http://ofb.net/~frederik/vectro/draft-r2.pdf
http://ofb.net/~frederik/vectro/
The paper also talks about reifying type-level integers to value-level
integers, and reflecting them back. Recent GHC extensions (like
DataKinds) make
() and using
(0.0::GLdouble) fixes it, and I'm not clear on why it's not automagic. There
are many times I see the compiler doing type conversion an numerican arguments
although sometimes the occasional fracSomethingIntegralorOther is required.
I was hoping for some enlightenment.
Thank you.
Brian
; if it expects GLdouble,
it expects GLdouble. Pretending it's Double will not work. It would in
the specific case that GLdouble were actually a type synonym for Double;
however, for performance reasons it is not. Haskell Double is not directly
usable from the C-based API used by OpenGL, so GLdouble
.
There are many times I see the
Haskell never automagics types in that context; if it expects GLdouble,
it expects GLdouble. Pretending it's Double will not work. It would in
the specific case that GLdouble were actually a type synonym for Double;
however, for performance reasons
a type synonym for Double;
however, for performance reasons it is not. Haskell Double is not
directly
usable from the C-based API used by OpenGL, so GLdouble is a type synonym
for CDouble which is.
compiler doing type conversion an numerican arguments although sometimes
the occasional
it
Vertex3 takes three arguments, all of which must be of the same instance of
VertexComponent. Specifying GLdoubles in the signature of wireframe
specifies the types in the last three calls to Vertex3, but (0.0 ::
GLdouble) is still requried on the first to fix the type there. How else
could
::GLdouble) fixes it, and I'm not clear on why it's not automagic.
There are many times I see the
I presume the reason the type specification for numeric literals is
because
there is no defaulting (and probably can't be without introducing other
strange type issues) for GLdouble.
What I
.
-- Forwarded message --
From: L Corbijn aspergesoe...@gmail.com
Date: Mon, Jun 17, 2013 at 12:07 AM
Subject: Re: [Haskell-cafe] opengl type confusion
To: bri...@aracnet.com
On Sun, Jun 16, 2013 at 11:10 PM, L Corbijn aspergesoe...@gmail.com wrote:
On Sun, Jun 16, 2013 at 10:42 PM, bri
three calls to Vertex3, but (0.0 ::
GLdouble) is still requried on the first to fix the type there. How else
could the compiler know that you mean 0.0 to be a GLdouble and not a
GLfloat?
Tom
it's curious that
(0.0::GLdouble) 0.0 0.0
is good enough and that
(0.0::GLdouble) (0.0
Richard Eisenberg wrote:
without ScopedTypeVariables, the n that you would put on your annotation
is totally unrelated to the n in the instance header, but this is benign
becau
se GHC can infer the type anyway. With ScopedTypeVariables, the `n`s are
the same, which luckily agrees
Hi all,
Following a discussion on Haskell-Cafe, Richard E. made the following
proposition of a Singleton to make a correspondance between type-level
integers and value-level integers:
data SNat :: Nat - * where
SZero :: SNat 'Zero
SSucc :: SNat n - SNat ('Succ n)
(found at [1
Hi TP,
Here is slightly edited code that works:
{-# LANGUAGE GADTs #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE StandaloneDeriving #-}
{-# LANGUAGE ScopedTypeVariables #-}
-- type level integers
data Nat = Zero | Succ Nat
deriving ( Show, Eq, Ord
of passing an
argument, as you were trying, you set the type of a proxy using an
explicit type annotation.
Indeed I did not realize that I could use `P::Proxy n`, and so that n does
not need to be argument of the data constructor `P`.
- I added the extension ScopedTypeVariables, which allows
.
This is because my code was (unintentionally) slightly redundant.
Here is the relevant code:
instance MkSNat n = MkSNat (Succ n) where
mkSNat _ = SSucc (mkSNat ???)
What could possibly go in `???`? As in, what is the required type of that
expression? We know
mkSNat :: forall m. MkSNat m
Hi,
On Wed, Jun 5, 2013 at 11:21 PM, TP paratribulati...@free.fr wrote:
José Pedro Magalhães wrote:
Oh, it should probably be simply
deriving instance Typeable 'Zero
deriving instance Typeable 'Succ
Yes, that's how it should be. Please let me know if that
doesn't work.
1 - 100 of 4707 matches
Mail list logo
