[Haskell-cafe] ANNOUNCE: uvector-algorithms 0.1

[Dan Doel]

Hello,

I've been sitting on this for a while, waiting for some changes to uvector to 
go in, but finally decided I should just release it, and fix it up if and when 
said changes go in. So, I'm announcing the first release of uvector-
algorithms.

What it is is a library of algorithms (mostly sorting) for the mutable arrays 
defined in uvector. It has several varieties of sorting, including introsort 
(quicksort which falls back on heapsort in bad cases), heapsort, a simple top-
down merge sort and a radix sort (as well as insertion sort, and optimal 
sorting for length<=4 arrays, which probably won't get much use outside of the 
implementation of the other sorts). All modules attempt to export as uniform 
an interface as possible, so that one can substitute between them freely, say 
when trying to determine which algorithm is best suited for your particular 
datasets.

Also exposed are the operations that allow you to use the arrays as heaps 
(which is the basis for implementing heapsort), and partial sorts and selects 
in heap and intro variety. Lastly, there is a combinator for safely using 
these mutable array algorithms to sort immutable arrays.

All of these algorithms have been painstakingly profiled, and their generated 
core examined to do as little heap allocation and as much unboxing as 
possible, and to inline and specialize for maximum performance (unless, of 
course, I've managed to miss anything). I've been running a relatively simple 
benchmarking suite that tests various kinds of inputs, and in my experience, 
the sorts herein tend to beat glibc's sort, and do relatively well compared to 
GNU's STL sorts over vector<>s (taking 50% or so more time at present, 
although this library may well be better at heapsorting random arrays, if you 
want something to brag about :)).

For future work, I've been working on an implementation of Python's timsort 
(which is a very fancy bottom-up merge sort), but it's not ready yet. I'd also 
like to introduce some combinators for easy Schwartzian transforms, but that 
again requires modifications to uvector. I may also look at moving some of my 
benchmark program into the package.

Suggestions for other algorithms people would like to see are of course 
welcome (especially if accompanied by papers/references on how to implement 
them if they're not well known).

The hackage page is here:
 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector-algorithms

Enjoy, and please let me know of any issues.
-- Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Data.List.Split

[Matti Niemenmaa]

Adam Vogt wrote:
> * On Saturday, December 13 2008, Gianfranco Alongi wrote:
>> I have actually been thinking about a similar thing, but on the "group" 
>> subject.
>> One can actually group things in many ways, such as groupBy (==) , so
>> that groupBy (==) [1,2,1,2] should give
>> [[1,1],[2,2]]. Of course other ideas are possible.
> 
> That result happens with:
> 
>> sortedGroups = group . sort
> 
> That composition is pretty, unlike those splitting functions. I don't know 
> if manually fusing sort and group helps performance at all though.

Sorting requires an Ord instance, though. Here's a relatively simple but slow
way which doesn't:

fullGroupBy :: (a -> a -> Bool) -> [a] -> [[a]]
fullGroupBy rel xs = map (\a -> filter (rel a) xs) (nubBy rel xs)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Missing comment highlighting in vim syntax script

[Claus Reinke]

The Haskell syntax script for vim mentions this mailing list as the
maintainer. Perhaps one of you could fix this bug.
Comments on the same line as import declarations don't get highlighted:


I don't know how this list-as-maintainer idea is going to work,
but the fix seems straightforward: find the line in 
$VIMRUNTIME/syntax/haskell.vim that says


   syn match hsImport  "\.*"he=s+6 contains=hsImportMod

and change it to

   syn match hsImport  "\.*"he=s+6 
contains=hsImportMod,hsLineComment,hsBlockComment

See :help syn-contains. 


Claus

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Time for a new logo?

[Don Stewart]

I noticed a new haskell logo idea on a tshirt today, 


http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png

Simple, clean and *pure*.

Instead of the "we got lots going on" of the current logo.

Any graphic designers want to try some variations on this theme of
purity? 

A new year, and a new mature logo...

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Johan Tibell]

On Sun, Dec 14, 2008 at 10:15 PM, Don Stewart  wrote:
> I noticed a new haskell logo idea on a tshirt today,
>
>
> http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png
>
> Simple, clean and *pure*.

I like it. I prefer the thick lambda over the script one and the
circle provides nice framing.

I'm no graphics designer though.

Cheers,

Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[George Pollard]

?

<>

signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[sam lee]

http://i35.tinypic.com/mjon83.png
used this: http://www.simwebsol.com/ImageTool/Default.aspx

2008/12/14 George Pollard :
> ?
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[brian]

On Sun, Dec 14, 2008 at 3:15 PM, Don Stewart  wrote:
> I noticed a new haskell logo idea on a tshirt today,
>
> http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png

I'd buy one, but I'm not seeing it on spreadshirt.net.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Don Stewart]

brianchina60221:
> On Sun, Dec 14, 2008 at 3:15 PM, Don Stewart  wrote:
> > I noticed a new haskell logo idea on a tshirt today,
> >
> > http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png
> 
> I'd buy one, but I'm not seeing it on spreadshirt.net.

http://haskell.org/haskellwiki/Merchandise

?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Ketil Malde]

Don Stewart  writes:

> I noticed a new haskell logo idea on a tshirt today, 
>
> 
> http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png
>
> Simple, clean and *pure*.

Nice.  For some more hubris, replace 'A' with 'The'.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Don Stewart]

ketil:
> Don Stewart  writes:
> 
> > I noticed a new haskell logo idea on a tshirt today, 
> >
> > 
> > http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png
> >
> > Simple, clean and *pure*.
> 
> Nice.  For some more hubris, replace 'A' with 'The'.

I had the very same thought :)

Stamp it home.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Brandon S. Allbery KF8NH]

On 2008 Dec 14, at 16:50, sam lee wrote:

http://i35.tinypic.com/mjon83.png
used this: http://www.simwebsol.com/ImageTool/Default.aspx



Win from the "visually interesting" angle, but massive lose from the  
"legibility" angle.


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[J. Garrett Morris]

On Sun, Dec 14, 2008 at 2:38 PM, Don Stewart  wrote:
> ketil:
>> Nice.  For some more hubris, replace 'A' with 'The'.
>
> I had the very same thought :)

It certainly wouldn't do to let, say, the existence of Concurrent
Clean get in the way of our self-promotion.

 /g

-- 
I am in here
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: typehash version 1.3

[Lennart Augustsson]

The typehash library allows you to produce a unique identifier (a
cryptographic hash) for a type.
This is useful if you save values of some type to a file (text,
binary, whatever format you wish)
and then when you read it back in again you want to verify that the
type you want to read is the
one you actually wrote.
The type hash takes into account both the actual name of the type and
the structure of the type.
The type hash is a compact value that only allows comparing for equality.

The library also supports type codes.  A type code encodes the
complete structure of a type and
can be used for finer comparison than just equality, e.g., will the
read function be able to read
what show produced (in this case renaming types and adding
constructors is allowed).

The library is on hackage, of course.

  -- Lennart
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Origins of '$'

[Derek Elkins]

On Mon, 2008-12-08 at 23:15 +0100, Joachim Breitner wrote:
> Hi,
> 
> Am Montag, den 08.12.2008, 15:59 -0600 schrieb Nathan Bloomfield:
> 
> > Slightly off topic, but the A^B notation for hom-sets also makes the
> > natural isomorphism we call currying expressable as A^(BxC) = (A^B)^C.
> 
> So A^(B+C) = A^B × A^C ?
> 
> Oh, right, I guess that’s actually true:
> 
> uncurry either:: (a -> c, b -> c)  -> (Either a b -> c)
> (\f -> (f . Left, f . Right)) :: (Either a b -> c) -> (a -> c, b -> c)
> 
> It’s always nice to see that I havn’t learned the elementary power
> calculation rules for nothing :-)

I want to point out a quick categorical way of proving this (and almost
all the other "arithmetic" laws follow similarly.)  This is just
continuity of right adjoints.  The interesting thing is the adjunction,
one that is commonly neglected in discussions of Cartesian closed
categories.

A^- is a function C^{op} -> C and it is adjoint to itself on the right,
i.e. (A^-)^{op} -| A^-.  As an isomorphism of hom functors that is,
Hom(=,A^-) ~ Hom(-,A^=) or in Haskell notation there is an isomorphism
flip :: (a -> b -> c) -> (b -> a -> c) (it is it's own inverse.)  This
is induced by the swap operation on pairs and is why for enriched
categories usually they talk about -symmetric- monoidally closed
categories.  Symmetric monoidally closed categories validate all the
arithmetic laws as well.

So B+C is BxC in the opposite category and so A^- takes (BxC)^op to A^B
x A^C.

And that's not all, every adjunction gives rise to a monad namely,
A^(A^-) or in Haskell notation (b -> a) -> a and indeed if you work out
the details this is the continuation monad.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Origins of '$'

[Richard O'Keefe]

On 15 Dec 2008, at 12:52 pm, Derek Elkins wrote:
I want to point out a quick categorical way of proving this (and  
almost

all the other "arithmetic" laws follow similarly.)  This is just
continuity of right adjoints.  The interesting thing is the  
adjunction,

one that is commonly neglected in discussions of Cartesian closed
categories.


December buds swell.
Categories unlimit
Haskell I once knew.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Eelco Lempsink]

On 14 dec 2008, at 22:15, Don Stewart wrote:

I noticed a new haskell logo idea on a tshirt today,

   
http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png

Simple, clean and *pure*.

Instead of the "we got lots going on" of the current logo.

Any graphic designers want to try some variations on this theme of
purity?



I'm not a graphic designer, but that doesn't prevent me giving a try.

<>


(Transparant PNG, for best results view on a white background.)

By the way, the font used (Kautiva) is not free.  You might recognize  
it from Tupil's logo ;)


--
Regards,

Eelco Lempsink



PGP.sig
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Don Stewart]

eelco:
> On 14 dec 2008, at 22:15, Don Stewart wrote:
> >I noticed a new haskell logo idea on a tshirt today,
> >
> >   
> > http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png
> >
> >Simple, clean and *pure*.
> >
> >Instead of the "we got lots going on" of the current logo.
> >
> >Any graphic designers want to try some variations on this theme of
> >purity?
> 
> 
> I'm not a graphic designer, but that doesn't prevent me giving a try.
> 


> 
> 
> (Transparant PNG, for best results view on a white background.)
> 
> By the way, the font used (Kautiva) is not free.  You might recognize  
> it from Tupil's logo ;)
> 

Could you attach it to the web page,

http://haskell.org/haskellwiki/Haskell_logos/New_logo_ideas

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Derek Elkins]

On Mon, 2008-12-15 at 02:57 +0100, Eelco Lempsink wrote:
> On 14 dec 2008, at 22:15, Don Stewart wrote:
> > I noticed a new haskell logo idea on a tshirt today,
> >
> >
> > http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png
> >
> > Simple, clean and *pure*.
> >
> > Instead of the "we got lots going on" of the current logo.
> >
> > Any graphic designers want to try some variations on this theme of
> > purity?
> 
> 
> I'm not a graphic designer, but that doesn't prevent me giving a try.
> 
> 
> (Transparant PNG, for best results view on a white background.)
> 
> By the way, the font used (Kautiva) is not free.  You might recognize  
> it from Tupil's logo ;)

Someone would pay for that font?  It literally hurts my eyes.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Corey O'Connor]

I like the proposed logo even more now that you've pointed out the
similarity. :-)
-Corey O'Connor



2008/12/14 George Pollard :
> ?
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: ghc on CentOS 5 ?

[Thomas Fee]

> Jeff Heard  gmail.com> writes:
> 
> I had luck building the latest GHC from source using the ghc 6.6
> binary build to bootstrap.  The 6.8+ binary builds run into a timer
> issue, at least on 64 bit CentOS that causes them to bork out during
> the configure script.
> 
> 2008/12/12 Steve Lihn  gmail.com>:
> > I recently got a CentOS server, but noticed that ghc rpm is not available
> > from CentOS yum. After investigation, I found ghc is in Fedora repository,
> > but does not make its way to EPEL, which yum on CentOS can use.
> > (http://download.fedora.redhat.com/pub/epel/5/x86_64/)
> >
> > Is there any plan to get it to EPEL? Or is there any missing piece
> > preventing it?
> > Thanks, Steve

I don't understand this. I went to
http://download.fedora.redhat.com/pub/epel/5/x86_64/ and did not see ghc. I
thought ghc is there for fedora but not for centos. And Jeff is saying that one
may as well just build it from source?


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Multi-parameter type class woes

[Mario Blažević]

I have, for a change, a relatively simple problem with type classes. Can 
somebody explain to me, or point me to an explanation of the behaviour I see?

Here is a short and useless example:

  {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}

   import Data.Maybe

   class Container x y where
  wrapper :: x -> Bool
  unwrap :: x -> y
  rewrap :: y -> x

   liftWrap :: Container x y => (y -> y) -> (x -> x)
   liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x

   instance Container (Maybe x) x where
  wrapper = isJust
  unwrap = fromJust
  rewrap = Just

   main = print (liftWrap (succ :: Int -> Int) (Just 1 :: Maybe Int))

GHC 6.10.1 refuses to typecheck the 'wrapper' function in definition of 
'liftWrap', with the following error message:

Could not deduce (Container x y) from the context (Container x y1)
  arising from a use of `wrapper' at Test.hs:11:22-30
Possible fix:
  add (Container x y) to the context of
the type signature for `liftWrap'
In the expression: wrapper x
In the expression:
(if wrapper x then rewrap . f . unwrap else id) x
In the definition of `liftWrap':
liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x

Let me clarify that I'm aware that in this particular example a functional 
dependecy should be used. Also, I can think of a few workarounds for my actual 
problem, so I'm not asking for any solutions. I'm looking for an explanation. 
It bugs me that my intuition of how this type class should have worked is 
completely wrong. The error message does not help, to put it mildly. Where 
should I go, what should I read?



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Multi-parameter type class woes

[Christopher Lane Hinson]

I'll take a swing at this one:

instance Container (Maybe x) [x] where
wrapper = isNothing
. . .

That isn't a sensible definition of 'wrapper', but I believe without 
trying to compile it is completely legal.  Which wrapper do you use?


You /don't/ have a different matching Container instance, but without the 
functional dependency you /might/, and ghc barfs.


--L

On Sun, 14 Dec 2008, Mario Bla?evi? wrote:


I have, for a change, a relatively simple problem with type classes. Can 
somebody explain to me, or point me to an explanation of the behaviour I see?

Here is a short and useless example:

 {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}

  import Data.Maybe

  class Container x y where
 wrapper :: x -> Bool
 unwrap :: x -> y
 rewrap :: y -> x

  liftWrap :: Container x y => (y -> y) -> (x -> x)
  liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x

  instance Container (Maybe x) x where
 wrapper = isJust
 unwrap = fromJust
 rewrap = Just

  main = print (liftWrap (succ :: Int -> Int) (Just 1 :: Maybe Int))

GHC 6.10.1 refuses to typecheck the 'wrapper' function in definition of 
'liftWrap', with the following error message:

   Could not deduce (Container x y) from the context (Container x y1)
 arising from a use of `wrapper' at Test.hs:11:22-30
   Possible fix:
 add (Container x y) to the context of
   the type signature for `liftWrap'
   In the expression: wrapper x
   In the expression:
   (if wrapper x then rewrap . f . unwrap else id) x
   In the definition of `liftWrap':
   liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x

Let me clarify that I'm aware that in this particular example a functional 
dependecy should be used. Also, I can think of a few workarounds for my actual 
problem, so I'm not asking for any solutions. I'm looking for an explanation. 
It bugs me that my intuition of how this type class should have worked is 
completely wrong. The error message does not help, to put it mildly. Where 
should I go, what should I read?



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re: [Haskell-cafe] Multi-parameter type class woes

[Mario Blažević]

> I'll take a swing at this one:
> 
> instance Container (Maybe x) [x] where
> wrapper = isNothing
> . . .
> 
> That isn't a sensible definition of 'wrapper', but I believe without 
> trying to compile it is completely legal.  Which wrapper do you use?
> 
> You /don't/ have a different matching Container instance, but without the 
> functional dependency you /might/, and ghc barfs.


But liftWrap doesn't require any particular instance, it's a 
generic function accepting any pair of types for which there is 
an instance of Container. Instance selection (as I understand it)
shouldn't come into play until one applies liftWrap to a
particular type, and indeed it does cause problems there: note
the type annotations on the last line. That part I understand
and accept, or at least have learned to live with.


> On Sun, 14 Dec 2008, Mario Bla?evi? wrote:
> 
>> I have, for a change, a relatively simple problem with
>> type classes. Can somebody explain to me, or point me to an explanation of
>> the behaviour I see?
>>
>> Here is a short and useless example:
>>
>>  {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-}
>>
>>   import Data.Maybe
>>
>>   class Container x y where
>>  wrapper :: x -> Bool
>>  unwrap :: x -> y
>>  rewrap :: y -> x
>>
>>   liftWrap :: Container x y => (y -> y) -> (x -> x)
>>   liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x
>>
>>   instance Container (Maybe x) x where
>>  wrapper = isJust
>>  unwrap = fromJust
>>  rewrap = Just
>>
>>   main = print (liftWrap (succ :: Int -> Int) (Just 1 :: Maybe Int))
>>
>> GHC 6.10.1 refuses to typecheck the 'wrapper' function
>> in definition of 'liftWrap', with the following error message:
>>
>>Could not deduce (Container x y) from the context (Container x y1)
>>  arising from a use of `wrapper' at Test.hs:11:22-30
>>Possible fix:
>>  add (Container x y) to the context of
>>the type signature for `liftWrap'
>>In the expression: wrapper x
>>In the expression:
>>(if wrapper x then rewrap . f . unwrap else id) x
>>In the definition of `liftWrap':
>>liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x
>>
>> Let me clarify that I'm aware that in this particular
>> example a functional dependecy should be used. Also, I can think of a few
>> workarounds for my actual problem, so I'm not asking for any solutions. I'm
>> looking for an explanation. It bugs me that my intuition of how this type
>> class should have worked is completely wrong. The error message does not
>> help, to put it mildly. Where should I go, what should I read?
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re: [Haskell-cafe] Multi-parameter type class woes

[Alexander Dunlap]

On Sun, Dec 14, 2008 at 8:10 PM, Mario Blažević  wrote:
>> I'll take a swing at this one:
>>
>> instance Container (Maybe x) [x] where
>> wrapper = isNothing
>> . . .
>>
>> That isn't a sensible definition of 'wrapper', but I believe without
>> trying to compile it is completely legal.  Which wrapper do you use?
>>
>> You /don't/ have a different matching Container instance, but without the
>> functional dependency you /might/, and ghc barfs.
>
>
>But liftWrap doesn't require any particular instance, it's a
> generic function accepting any pair of types for which there is
> an instance of Container. Instance selection (as I understand it)
> shouldn't come into play until one applies liftWrap to a
> particular type, and indeed it does cause problems there: note
> the type annotations on the last line. That part I understand
> and accept, or at least have learned to live with.

The problem is that y is not mentioned in the signature of wrapper.
When you call wrapper x, there could be many different instances of
Container x y with the same x, so GHC doesn't know which version to
call. You can fix this problem either by adding a functional
dependency or by splitting wrapper out into its own class (Wrapper x,
e.g.) so all of the type variables in the class head are mentioned in
its type and the instance can be determined by the call.

Thanks for asking this question, by the way. I had known about this
issue but had never really realized why it happened. Now that I have
thought about it, I understand it too. :)

Hope that helps,
Alex
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Re: [Haskell-cafe] Multi-parameter type class woes

[Christopher Lane Hinson]

On Sun, 14 Dec 2008, Mario Bla?evi? wrote:


I'll take a swing at this one:

instance Container (Maybe x) [x] where
wrapper = isNothing
. . .

That isn't a sensible definition of 'wrapper', but I believe without
trying to compile it is completely legal.  Which wrapper do you use?

You /don't/ have a different matching Container instance, but without the
functional dependency you /might/, and ghc barfs.



   But liftWrap doesn't require any particular instance, it's a
generic function accepting any pair of types for which there is
an instance of Container. Instance selection (as I understand it)
shouldn't come into play until one applies liftWrap to a
particular type, and indeed it does cause problems there: note
the type annotations on the last line. That part I understand
and accept, or at least have learned to live with.


Yes, that is an intuitive understanding to us humans, but the instance 
selection applies seperately for 'wrapper' and 'listWrap'; ghc doesn't 
automatically prefer a particular instance just because it is in the 
context of the calling function.


--L
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Clifford Beshers]

On Sun, Dec 14, 2008 at 6:27 PM, Don Stewart  wrote:

>
> Could you attach it to the web page,
>
>http://haskell.org/haskellwiki/Haskell_logos/New_logo_ideas
>
>
I tossed up a quickie candidate there as well.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Time for a new logo?

[Ketil Malde]

"J. Garrett Morris"  writes:

>>> Nice.  For some more hubris, replace 'A' with 'The'.

>> I had the very same thought :)

> It certainly wouldn't do to let, say, the existence of Concurrent
> Clean get in the way of our self-promotion.

Well, they get to make T-shirts with "Clean - the /other/ purely
functional language".

Seriously though - thet text can be interpreted as Haskell, the purely
functional language to distinguish it from Haskell, the county in
Texas, or Haskell, the Indian Nations Universityor for that matter
Haskell, the logician. 

To avoid any hard feelings, I suggest either putting "Haskell the
logician" (with a picture of same) on the back of the shirt, or
replacing the text with just "purely functional" or similar.

At any rate, "A" is to weak, and suggests just one of the crowd.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Parsec and type level numerals

[Reiner Pope]

On Sun, Dec 14, 2008 at 6:54 AM, David Menendez  wrote:
> 2008/12/13 Nathan Bloomfield :
>> I want to be able to parse a string of digits to a type level numeral as
>> described in the Number parameterized types paper. After fiddling with the
>> problem for a while, I'm not convinced it's possible- it seems as though one
>> would need to know the type of the result before parsing, but then we
>> wouldn't need to parse in the first place. :)
>
> This can be done with existential types. I think Oleg Kiselyov has an
> example somewhere of a parser that determines the type of its output
> from its input, but here's the basic idea:
>
> data SomeCard = forall a. (Card a) => SomeCard a
>
> Now you can define parseP :: Parser SomeCard
>
> Unfortunately, all you know about the value inside the SomeCard is
> that it's a member of the class Card, which may not be very helpful.
> Depending on how general you want to be, you can bundle more
> operations with SomeCard, or you can return a GADT that reflects the
> type-level natural at the value level.
>
> --
> Dave Menendez 
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

Depending on what you actually want to do, you may be looking for Oleg
Kiselyov's reifyIntegral function, which he defines in the paper
"Functional Pearl: Implicit Configurations -- or Type Classes Reflect
the Value of Types" (at
http://www.cs.rutgers.edu/~ccshan/prepose/prepose.pdf ). It has type
something like

reifyIntegral :: forall a. Int -> (forall n. Numeral n => n -> a) -> a

encoding n's existential type with continuation passing style.

Cheers,
Reiner
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe