I wrote:
[1] Balancing can be done with the information in the blueprint, and
mapping back is easily done by doing the transformation on the tree
in reverse.
I should add that this possibility was the main reason for dealing with
blueprints at all. As Ross Paterson's solution shows, it's possib
Bertram Felgenhauer wrote:
>> splitSeq' :: Ord a => Map a () -> [(a,b)] -> ([(a,[b])], Map a [b])
>> splitSeq' bp [] = ([], map (const []) bp)
>> splitSeq' bp ((a,b):xs) = case lookup a bp bp of
>> Just _ -> let (l, m) = splitSeq' bp xs in (l, update a (b:) bp m)
>> _ -> let (
Ross Paterson wrote:
> On Thu, Sep 14, 2006 at 05:22:05PM +0200, Bertram Felgenhauer wrote:
>> [much subtle code]
>> We can now build the splitStream function, using the following helper
>> function:
>>
>>> splitSeq' :: Ord a => Map a () -> [(a,b)] -> ([(a,[b])], Map a [b])
>
> This works for infi
[EMAIL PROTECTED] wrote:
> type BiMap a b = (Map.Map a b, Map.Map b a)
Actually BiMap is not needed at all, it suffices to have
> splitStreams :: Ord a => [(a,b)] -> [(a,[b])]
> splitStreams xs =
> takeWhile (not . null . snd) $ toList $ splitStreams' Map.empty xs
>
> splitStreams' :: Ord a =
Ross Paterson wrote:
> How embarrassing. Still, your code is quite subtle. As penance, here's
> my explanation, separating the main idea from the knot-tying.
>
> The ingredients are a map type with an insertion function
> [...]
> insert :: Ord k => k -> a -> Map k a -> Map k a
>
> with a
Ross Paterson wrote:
> On Sun, Sep 17, 2006 at 01:08:04PM +0200, [EMAIL PROTECTED] wrote:
>> Ross Paterson wrote:
>>> It's interesting that these composed transformations don't seem to cost
>>> too much.
>> That the composed transformations are indeed cheap is not necessarily
>> disturbing.
>
> I
Conor McBride wrote:
> Just imagine
>
>> data Eq a b where Refl :: Eq a a
>
>> coerce :: Eq a b -> a -> b
Robert Dockins wrote:
>>> coerce ~Refl x = x
>
> coerce undefined True :: String
>
> Bang you're dead. Or rather... Twiddle you're dead.
Mom, he's scaring me! ;)
Who says this functio
Thanks Bertran for your solution. I have difficulty understanding it so I
can't comment on it right now but I'll try to have a look at it. Do you
know of any article that explains this technique, starting from very
simple examples?
/Magnus
On Thu, 14 Sep 2006, Bertram Felgenhauer wrote:
I w
Magnus Jonsson wrote:
> Thanks Bertran for your solution. I have difficulty understanding it so I
> can't comment on it right now but I'll try to have a look at it. Do you
> know of any article that explains this technique, starting from very
> simple examples?
Not really. It's a result of thin
On Thu, 14 Sep 2006, Bertram Felgenhauer wrote:
> Magnus Jonsson wrote:
> > Thanks Bertran for your solution. I have difficulty understanding it so I
> > can't comment on it right now but I'll try to have a look at it. Do you
> > know of any article that explains this technique, starting from v
On Thu, Sep 14, 2006 at 07:51:59PM +0200, Bertram Felgenhauer wrote:
> It's a result of thinking about lazy evaluation, and
> especially lazy patterns (and let bindings) for some time. A wiki article
> that helped me a lot to understand these is
>
> http://www.haskell.org/hawiki/TyingTheKnot
>
ross:
> On Thu, Sep 14, 2006 at 07:51:59PM +0200, Bertram Felgenhauer wrote:
> > It's a result of thinking about lazy evaluation, and
> > especially lazy patterns (and let bindings) for some time. A wiki article
> > that helped me a lot to understand these is
> >
> > http://www.haskell.org/hawik
On Sun, Sep 17, 2006 at 01:08:04PM +0200, [EMAIL PROTECTED] wrote:
> Ross Paterson wrote:
> > It's interesting that these composed transformations don't seem to cost
> > too much.
>
> That the composed transformations are indeed cheap is not necessarily
> disturbing.
I meant the composition of th
On Mon, Sep 18, 2006 at 12:23:11AM +0100, Ross Paterson wrote:
> To prove that (even for partial and infinite lists ps)
>
> splitSeq ps = [(a, seconds a ps) | a <- nub ps]
>
> [...] we can establish, by induction on the input list,
>
> (1) fst (splitSeq' s ps) =
> [(a, seco
On Tue, Sep 19, 2006 at 01:41:51PM +0200, [EMAIL PROTECTED] wrote:
> Btw, why are there no irrefutable patterns for GADTs?
Not GADTs, but existential types (whether done with GADTs or not).
They can't be analysed with irrefutable patterns, of which let bindings
are a special case:
http://www.hask
Hi folks
[EMAIL PROTECTED] wrote:
Btw, why are there no irrefutable patterns for GADTs? I mean, such a sin
should be shame for a non-strict language...
Just imagine
> data Eq a b where Refl :: Eq a a
> coerce :: Eq a b -> a -> b
> coerce ~Refl a = b
coerce undefined True :: String
Bang
On Sep 19, 2006, at 8:52 AM, Conor McBride wrote:
Hi folks
[EMAIL PROTECTED] wrote:
Btw, why are there no irrefutable patterns for GADTs? I mean, such
a sin
should be shame for a non-strict language...
Just imagine
> data Eq a b where Refl :: Eq a a
> coerce :: Eq a b -> a -> b
> coer
Robert Dockins wrote:
On Sep 19, 2006, at 8:52 AM, Conor McBride wrote:
Hi folks
[EMAIL PROTECTED] wrote:
Btw, why are there no irrefutable patterns for GADTs? I mean, such a
sin
should be shame for a non-strict language...
Just imagine
> data Eq a b where Refl :: Eq a a
> coerce :: E
On Tue, Sep 19, 2006 at 08:06:07PM +0200, [EMAIL PROTECTED] wrote:
> For our optimization problem, it's only a matter of constructors on the
> right hand side. They should pop out before do not look on any
> arguments, so it's safe to cry "so you just know, i'm a Just".
It seems the appropriate en
On Tue, Sep 19, 2006 at 01:52:02PM +0100, Conor McBride wrote:
> [EMAIL PROTECTED] wrote:
> >Btw, why are there no irrefutable patterns for GADTs?
>
> Just imagine
>
> > data Eq a b where Refl :: Eq a a
>
> > coerce :: Eq a b -> a -> b
> > coerce ~Refl a = a
>
> coerce undefined True :: String
| Does anything go wrong with irrefutable patterns for existential
types?
Try giving the translation into System F.
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Thu, Sep 28, 2006 at 03:22:25PM +0100, Simon Peyton-Jones wrote:
> | Does anything go wrong with irrefutable patterns for existential
> types?
>
> Try giving the translation into System F.
Hmm, that's not quite as satisfying as Conor's answer for GADTs.
___
22 matches
Mail list logo
