StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
15126375
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2013-02-28T02:22:26.233
FavoriteCount
0
LastActivityDate
2013-02-28T02:44:27.933
LastEditDate
2013-02-28T02:44:27.933
LastEditorUserId
745903
OwnerUserId
745903
ParentId
15125522
PostTypeId
2
Score
12
ViewCount
0
LastEditorDisplayName
text
Body
This is something that's easy to get wrong. What you have in the signature of <code>optimize</code> is not an existential, but a universal. ...since existentials are somewhat outdated anyway, let's rewrite your data to GADT form, which makes the point clearer as the syntax is essentially the same as for polymorphic functions: <pre><code>data Container a where (:/->) :: Ord v => -- come on, you can't call this `Cons`! OptiF a v -> (a->Int) -> Container a </code></pre> Observe that the <code>Ord</code> constraint (which implies that here's the <code>forall v...</code>) stands outside of the type-variable–parameterised function signature, i.e. <code>v</code> is a parameter we can dictate from the outside when we want to construct a <code>Container</code> value. In other words, <blockquote> For all <code>v</code> in <code>Ord</code> there exists the constructor <code>(:/->) :: OptiF a v -> (a->Int) -> Container a</code> </blockquote> which is what gives rise to the name "existential type". Again, this is analog to an ordinary polymorphic function. On the other hand, in the signature <pre><code>optimize :: (forall v. (Ord v) => a -> v) -> Container a -> Int </code></pre> you have a <code>forall</code> inside the signature term itself, which means that what concrete type <code>v</code> may take on will be determined by the callee, <code>optimize</code>, internally – all we have control over from the outside is that it be in <code>Ord</code>. Nothing "existential" about that, which is why this signature won't actually compile with <code>XExistentialQuantification</code> or <code>XGADTs</code> alone: <pre><code><interactive>:37:26: Illegal symbol '.' in type Perhaps you intended -XRankNTypes or similar flag to enable explicit-forall syntax: forall <tvs>. <type> </code></pre> <code>val = (*3)</code> obviously doesn't fulfill <code>(forall v. (Ord v) => a -> v)</code>, it actually requires a <code>Num</code> instance which not all <code>Ord</code>s have. Indeed, <code>optimize</code> shouldn't need the rank2 type: it should work for any <code>Ord</code>-type <code>v</code> the caller might give to it. <pre><code>optimize :: Ord v => (a -> v) -> Container a -> Int </code></pre> in which case your implementation doesn't work anymore, though: since <code>(:/->)</code> is really an existential constructor, it needs to contain only any <code>OptiF</code> function, for some unknown type <code>v1</code>. So the caller of optimize has the freedom to choose the opti-function for any particular such type, and the function to be optimised for any possibly other fixed type – that can't work! The solution that you want is this: <code>Container</code> shouldn't be existential, either! The opti-function should work for any type which is in <code>Ord</code>, not just for one particular type. Well, as a GADT this looks about the same as the universally-quantified signature you originally had for <code>optimize</code>: <pre><code>data Container a where (:/->) :: (forall v. Ord v => OptiF a v) -> (a->Int) -> Container a </code></pre> With that now, optimize works <pre><code>optimize :: Ord v => (a -> v) -> Container a -> Int optimize val (opti :/-> result) = result (opti val) </code></pre> and can be used as you wanted <pre><code>callOptimize :: Int callOptimize = optimize val cont where val = (*3) opti val' = if val' 1 > val' 0 then 100 else -100 cont = opti :/-> (*2) </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POExistential type in higher order function
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USleftaroundabout
UserOwnerUserId
1. USleftaroundabout
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POExistential type in higher order function
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COYou made my day and probably the next few ones :) What do you mean by 'existentials are outdated'? That they are subsumed by GADTs as said in http://en.wikibooks.org/wiki/Haskell/GADT#Existential_types ? But I shouldn't replace ADTs by GADTs where not needed, right?
 singulars
 PostPostId
 PO
 UserUserId
 USchs
2. COFor simple constructors (but possibly many different ones) the old `data` syntax is arguably more readable, so: no, you shouldn't replace those with GADTs (there's nothing wrong with it, though!). For anything that involves type variables not mentioned in the data head, I would use GADT syntax.
 singulars
 PostPostId
 PO
 UserUserId
 USleftaroundabout

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.