Call For Participation
WFLP2010
19th International Workshop on Functional
and (Constraint) Logic Programming
Madrid, Spain
[Deadlines extended: Abstract due Nov 18; Full paper due Nov 25]
Final Call For Papers
19th International Workshop on Functional
and (Constraint) Logic Programming
Second Call For Papers
19th International Workshop on Functional
and (Constraint) Logic Programming
Madrid, Spain, January 17, 2010
http://bab
[Apologies for multiple receptions of this message]
Preliminary Call For Papers
19th International Workshop on Functional
and (Constraint) Logic Programming
Ma
> [0] [EMAIL PROTECTED]:~/test $ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.8.2
I have an older version and wonder what goes wrong. Now that I think
of it, other stuff that I coudn't compile might actually work in 6.8
It does make sense that |b| is resolved to |B| b
>> But if you have actual values rather than just unit types, note that this
>> won't work:
>>
>> > instance DeriveType A B where
>> > someDestructor (SomeConstructor _ b) = b
>
> I couldn't understand the sentence "actual values rather than unit
> types". What do you have in mind?
I didn't
Wren ng thornton wrote:
> It compiles just fine with (DeriveType A b => b -> b) after all, which
> resolves directly to (B -> B)
That's not the case:
simpleNarrow :: DeriveType A b => b -> b
simpleNarrow = id
Couldn't match expected type `b' (a rigid variable)
against inferred type
I prefer Bruno's approach, though. It allows meta-level type-checking
of expressions and there's the possibility of closing the extension
with a wrapper:
(References: "Generics as a Library" and his PhD thesis)
- GADT as a type class (or encode the type as it's fold):
class Exp e where
lit
> I myselft don't understand why GHCi doesn't accept the type it
> infered as an explicit signature ...
I think it has to do with the following:
Looking at the type errors, they seem to indicate that the type
checker is being general and does not assume the |From| and |To|
"relations" are betwe
I find this interesting,
GHCi accepts a function |dmap| which I show below and infers its type,
but if I annotate the function with the inferred type, GHCi's
type-checker rejects it.
I'm trying to generalise the datatype-generic dmap:
< dmap :: Bifunctor s => (a -> b) -> Fix s a -> Fix s b
< dma
> This has certainly been taken into account when comparing approaches to
> generic programming. I quote from page 18/19 from the work you and Bulat
Indeed I was not aware of it. Missed that. Thanks for pointing it out!
> Thus, full reflexivity of an approach is taken into account. This suggest
On 12/04/2008, Thomas van Noort <[EMAIL PROTECTED]> wrote:
> That's a good question. Unfortunately, only Haskell98 types are currently
> supported by the Generic Haskell compiler.
I thought constrained types were Haskell 98, but now I'm in doubt...
> But at first sight, implementing support fo
On 12/04/2008, Thomas van Noort <[EMAIL PROTECTED]> wrote:
> Generic Haskell includes the following features:
>
> * type-indexed values -- generic functions that can be
>instantiated on all Haskell data types.
^^^
I have perused the manual and wonder if parame
I believe the exercise is about understanding folds.
There are two references that are related to the exercise:
A tutorial on the universality and expressiveness of fold, by Graham Hutton.
Dealing with large bananas, by Ralf Lammel, etc.
The last paper motivates well the need to gather all t
Hasn't Ryan raised an interesting point, though?
Bottom is used to denote non-termination and run-time errors. Are they
the same thing? To me, they're not. A non-terminating program has
different behaviour from a failing program.
When it comes to strictness, the concept is defined in a particular
> > mapBox :: forall a b. (a -> b) -> Box -> Box
> > --:: forall a b. (a -> b) -> (exists a.a) -> (exists a.a)
> > mapBox f (B x) = B (f x)
> >
> > However, at first sight |f| is polymorphic so it could be applied to
> > any value, included the value hidden in |Box|.
>
> f is not polym
Stupid of me:
> Isn't the code for mapBox :: forall a. (a -> a) -> Box -> Box
> encoding the proof:
>
> Assume forall a. a -> a
> Assume exists a.a
> unpack the existential, x :: a = T for some T
> apply f to x, we get (f x) :: a
> pack into existential, B (f x) :: exists a.a
> Disc
A question about existential quantification:
Given the existential type:
data Box = forall a. B a
in other words:
-- data Box = B (exists a.a)
-- B :: (exists a.a) -> Box
I cannot type-check the function:
mapBox :: forall a b. (a -> b) -> Box -> Box
--:: forall a b. (a -> b)
Another opinion in case you need more:
TAPL is excellent for self-study. There are solutions for most
interesting exercises. And every type system presented comes with a
downloadable implementation. You can practice with it and change it.
Do not hesitate to get it. I also recommend Cardelli's pape
On 16/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
There is a wide-spread opinion that one ought not to give context to a
data type declaration (please search for `restricted datatypes
Haskell'). Someone said that in GHC typechecker such contexts called
stupidctx. There has been a proposal
Aha, of course, Sorry, I misunderstood you.
P.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Bruno,
Now we modify thin to take an extra Nat n (not needed, but just to
show the duality with thickening):
I'm puzzled by the "not needed" bit. Isn't the introduction of Fin's
indices reflected as values in the GADT , and the fact that the GADT
makes that reflection, what makes it work?
P
-- Forwarded message --
From: Pablo Nogueira <[EMAIL PROTECTED]>
Date: 31-Jan-2007 12:04
Subject: Re: [Haskell-cafe] GADTs: the plot thickens?
To: Conor McBride <[EMAIL PROTECTED]>
I haven't tried this yet, but would declaring the class Nat be a starting po
23 matches
Mail list logo