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

2008-12-13 Thread Ori Avtalion
Hi all,

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:

import A -- This comment isn't highlighted
import B {- Neither is this -}
import C {- and
this -}

I'm using this version of the syntax file: (the only version)
http://vim.svn.sourceforge.net/viewvc/vim/vim7/runtime/syntax/haskell.vim?revision=1296&view=markup

Thanks,
Ori

___
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

2008-12-13 Thread brian
On Sat, Dec 13, 2008 at 9:10 AM, Ori Avtalion  wrote:
> Comments on the same line as import declarations don't get highlighted:
> import A -- This comment isn't highlighted
> import B {- Neither is this -}
> import C {- and
>this -}

I think the way vim tries to do syntax highlighting is fundamentally
busted. That's why there are the problems like the ones you're talking
about and a million others. I plan to use vim and work on my yi
configs until I can switch. It's sad.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Data.List.Split

2008-12-13 Thread Brent Yorgey
Today yet another newbie in #haskell asked about a 'split' function
for lists, and I got fed up with saying 'no one can agree on the right
interface so it doesn't exist, just write it yourself', because it's a
really dumb answer, even if it's true.

Instead of trying to get a 'split' function added to Data.List (which
will never ever happen), I thought, why not create a module
Data.List.Split which contains implementations of every conceivable
way to split a list?  Of course, people will probably still argue over
what should go in such a module, what to name the various functions,
etc., but hopefully we can converge on something useful.

I've created a Data.List.Split page on the wiki:

  http://haskell.org/haskellwiki/Data.List.Split

Please add code to it!  Once something useful is hashed out we can
upload it to hackage.  Perhaps eventually some of it can be folded
into the standard libraries, but this seems like a much more
lightweight way to get started.

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


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

2008-12-13 Thread Gianfranco Alongi
A very nice initiative I must say; although the page should contain
the usual explanation for why such a split method can't be universal.
That is, add the same explanation you give every time; but to the
page.

/Gianfranco

On Sat, Dec 13, 2008 at 5:30 PM, Brent Yorgey  wrote:
> Today yet another newbie in #haskell asked about a 'split' function
> for lists, and I got fed up with saying 'no one can agree on the right
> interface so it doesn't exist, just write it yourself', because it's a
> really dumb answer, even if it's true.
>
> Instead of trying to get a 'split' function added to Data.List (which
> will never ever happen), I thought, why not create a module
> Data.List.Split which contains implementations of every conceivable
> way to split a list?  Of course, people will probably still argue over
> what should go in such a module, what to name the various functions,
> etc., but hopefully we can converge on something useful.
>
> I've created a Data.List.Split page on the wiki:
>
>  http://haskell.org/haskellwiki/Data.List.Split
>
> Please add code to it!  Once something useful is hashed out we can
> upload it to hackage.  Perhaps eventually some of it can be folded
> into the standard libraries, but this seems like a much more
> lightweight way to get started.
>
> -Brent
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Patience is the last resort for those unable to take action
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


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

2008-12-13 Thread Brent Yorgey
On Sat, Dec 13, 2008 at 05:39:55PM +0100, Gianfranco Alongi wrote:
> A very nice initiative I must say; although the page should contain
> the usual explanation for why such a split method can't be universal.
> That is, add the same explanation you give every time; but to the
> page.

Good idea; I've added a list of possible ways to split, both to give
people ideas for code to write, and to demonstrate why it's impossible
to come up with one 'best' split function.

vixey has already added some code, but we need more!

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


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

2008-12-13 Thread Gianfranco Alongi
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.

On Sat, Dec 13, 2008 at 5:47 PM, Brent Yorgey  wrote:
> On Sat, Dec 13, 2008 at 05:39:55PM +0100, Gianfranco Alongi wrote:
>> A very nice initiative I must say; although the page should contain
>> the usual explanation for why such a split method can't be universal.
>> That is, add the same explanation you give every time; but to the
>> page.
>
> Good idea; I've added a list of possible ways to split, both to give
> people ideas for code to write, and to demonstrate why it's impossible
> to come up with one 'best' split function.
>
> vixey has already added some code, but we need more!
>
> -Brent
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Patience is the last resort for those unable to take action
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Haskell Weekly News: Issue 97 - December 13, 2008

2008-12-13 Thread Brent Yorgey
---
Haskell Weekly News
http://sequence.complete.org/hwn/20081213
Issue 97 - December 13, 2008
---

   Welcome to issue 97 of HWN, a newsletter covering developments in the
   [1]Haskell community.

   Lots of neat blog posts and funny quotes this week. Don't forget to
   keep adding [2]haiku to the wiki, and don't miss Alex McLean (yaxu)'s
   [3]streaming livecoding performance tonight!

Announcements

   Spam on HaskellWiki. Ashley Yakeley [4]asked what people would like to
   do about the increasing amounts of spam on the Haskell wiki, and
   offered some suggestions.

   The Timber compiler 1.0.2. Johan Nordlander [5]announced the first
   public release of the [6]Timber compiler. Timber is a modern language
   for building event-driven systems, based around the notion of reactive
   objects. It is also a purely functional language derived from Haskell,
   although with a strict evaluation semantics. To try it out, just grab
   the [7]timberc package on Hackage.

   Retrospective on 2008?. Don Stewart [8]proposed the idea of a 2008
   retrospective. How would you choose the 10 best new libraries,
   applications, blog posts, etc. of 2008?

   a haskell_proposals subreddit. Jason Dusek [9]announced a [10]subreddit
   for Haskell library proposals. The idea is that Web 2.0 will help us to
   allocate our collective talents more efficiently when it comes to
   extensions (and perhaps clue us in when our pet project is something
   people really want).

   permutation-0.2. Patrick Perry [11]announced a [12]new version of the
   permutation library, which includes data types for storing
   permutations. It implements pure and impure types, the latter which can
   be modified in-place. The main utility of the library is converting
   between the linear representation of a permutation to a sequence of
   swaps. This allows, for instance, applying a permutation or its inverse
   to an array with O(1) memory use.

   Data.List.Split. Brent Yorgey [13]announced the creation of a wiki page
   for [14]Data.List.Split, a hypothetical module containing
   implementations of every conceivable way of splitting lists known to
   man, so we no longer have to (1) argue about the 'one true' interface
   for a 'split' function, or (2) be embarrassed when people ask why there
   isn't a split function in the standard libraries. Please add code or
   comments! At some point it will be uploaded as a new module to Hackage.

   Announcing Haskell protocol-buffers version 1.2.2. Chris Kuklewicz
   [15]announced new versions of [16]protocol-buffers,
   [17]protocol-buffers-descriptor, and [18]hprotoc.

Discussion

   A curious monad. Andrew Coppin [19]exhibited an interesting Storage
   monad, which (it turns out) is similar to ST. An enlightening
   discussion if you want to understand how ST works and the motivation
   behind it.

   Origins of '$'. George Pollard [20]asked about the origins of the $
   operator (low-precedence function application) in the standard
   libraries, leading to some interesting history and general discussion
   about notation.

Blog noise

   [21]Haskell news from the [22]blogosphere.
 * Jamie Brandon: [23]Zombified GMap. Jamie is determined to get his
   SoC generalized map library released!
 * Philip Wadler: [24]Informatics 1 - Fancy Dress and Competition.
 * >>> Eduard - Gabriel Munteanu: [25]Learning Haskell, part 2.
 * Martin Sulzmann: [26]Equality, containment and intersection among
   regular expressions via symbolic manipulation.
 * Neil Mitchell: [27]mapM, mapM_ and monadic statements.
 * Alson Kemp: [28]A HAML parser for Haskell.
 * Chris Done: [29]More Haskell blogging.
 * Twan van Laarhoven: [30]Knight in n, part 4: tensors. Part four of
   Twan's enlightening series on computing knight moves.
 * Alex McLean: [31]Saturday night stream. All the cool kids will be
   watching Alex's streaming livecoding performance TONIGHT, using
   (among other things) a tool implemented in Haskell.
 * David Sankel: [32]Synchronous Events.
 * Lennart Augustsson: [33]The OCaml code again.
 * Lennart Augustsson: [34]Abstracting on, suggested solutions.
 * Lennart Augustsson: [35]The abstraction continues.
 * Conal Elliott: [36]Functional interactive behavior.
 * Conal Elliott: [37]Trimming inputs in functional reactive
   programming.
 * Mikael Vejdemo Johansson (Syzygy-): [38]J, or how I learned to stop
   worrying and love the matrix.
 * Conal Elliott: [39]Why classic FRP does not fit interactive
   behavior.
 * Clifford Beshers: [40]Functional Programming Marketing.
 * Lennart Augustsson: [41]A somewhat failed adventure in Haskell
   abstraction.
 * >>> Joey Hess: [42]hask

[Haskell-cafe] Parsec and type level numerals

2008-12-13 Thread Nathan Bloomfield
Hello all. I've got a puzzling Parsec problem. Perhaps the collective wisdom
of haskell-cafe can point me in the right direction.

I want to be able to parse a string of digits to a type level numeral as
described in the Number parameterized
typespaper.
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. :) My
first (simplified) approximation is as follows:

> data Zero = Zero
> data Succ a = Succ a

> class Card t
> instance Card Zero
> instance (Card a) => Card (Succ a)

> parseP :: (Card a) => Parser a
> parseP = do { char '1'
> ; rest <- parseP
> ; return $ Succ rest
> }
>  <|> return Zero

I'd like for this to parse, for example, "111" into Succ Succ Succ Zero. Of
course this doesn't work because parseP is ill-typed, but I'm not sure how
to fix it. It seems that what I'm asking for is a function whose type is forall
a. (Card a) => String -> a, which is problematic.

Has anyone tried this before? I'm new to using Parsec and to parsing in
general, so I apologize if this is a silly question. (Parsec is very
impressive, by the way.)

Thanks-

Nathan Bloomfield
University of Arkansas, Fayetteville
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


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

2008-12-13 Thread brian
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.

Hi, I'm at UA too (bsl04). Here's a quick try. Sorry if I'm not
getting what you're doing.

import Text.Parsec
import Text.Parsec.String

data PeanoNumber = Zero | Succ PeanoNumber
  deriving Show

parseP :: Parser PeanoNumber
parseP = do
  char '1'
  rest <- parseP
  return $ Succ rest
  <|> return Zero

test = parseTest parseP "111"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] A curios monad

2008-12-13 Thread Ryan Ingram
2008/12/11 Luke Palmer :
> If you could guarantee that the ID of a key is globally unique, even through
> different invocations of the monad (using eg. unsafePerformIO newUnique),
> then you could ensure type safety and allow transport of keys between
> different monads.

Well, for type-safety you don't need the entire ID of the key; you
just need a globally unique type tag.  This is, of course, what
Data.Typeable provides.  But you can also roll your own using Uniques:

newtype TKey a = TKey Unique deriving Eq

newTKey :: IO (TKey a)
newTKey = fmap TKey newUnique

castTKey :: TKey a -> TKey b -> Maybe (a -> b)
castTKey (TKey u1) (TKey u2)
| u1 == u2 = Just unsafeCoerce
| otherwise = Nothing

data Key a = Key Int (TKey a) deriving (Eq, Ord)
data StoredValue = forall a. Stored (TKey a) a
type StorageMap = IntMap StoredValue

You then split up the program; one part generates TKeys for the types
in IO; then you can use those throughout the pure rest of the program
to index the types:

newKey :: TKey a -> Storage (Key a)
newKey ta = do
ik <- getNextFreeInt
return $ Key ik ta

-- using MaybeT:
-- newtype MaybeT m a = MaybeT { runMaybeT :: m (Maybe a) }
-- with the appropriate Monad instance
readKey :: Key a -> Storage (Maybe a)
readKey (Key i t) = runMaybeT $ do
Stored tx x <- MaybeT $ lookupMap i
f <- MaybeT $ return (castTKey tx t)
return (f x)

-- exercises for the reader
lookupMap :: Int -> Storage StoredValue
getNextFreeInt :: Storage Int
writeKey :: a -> Key a -> Storage ()

If you're willing to be *slightly* non-referentially transparent, you
can generate the type keys at global scope:

intTKey :: TKey Int
intTKey = unsafePerformIO newTKey
{-# NOINLINE intTKey #-}

(There have been many arguments about "top level IO actions"; I don't
want to get into that here!)

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


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

2008-12-13 Thread Ryan Ingram
You're almost there, but you have correctly determined the problem;
you need to know the type of the parse result in order to parse.

However, it is possible to hide the type from the parser; try writing
this function instead:

{-# LANGUAGE ExistentialQuantification #-}
data AnyCard = forall t. Card t => AnyCard t

parseP :: Parser AnyCard

Now the type-level numeral is hidden in the "AnyCard" existential
type.  In order to use it, you need to be able to use operations that
work on any instance of Card, which means the class/instance
declarations you have so far aren't that useful.  Emulating dependent
types using existentials in Haskell is never pretty!

Another option is to use a GADT to hold the type:

{-# LANGUAGE GADTs, ExistentialQuantification #-}

data GADTNum t where
GZero :: GADTNum Zero
GSucc :: GADTNum a -> GADTNum (Succ a)
data AnyCard = forall t. AnyCard (GADTNum t)

Now, after the parse, you can use the structure of the GADT to
determine things about the existential type:

isTwo :: AnyCard -> Maybe (Succ (Succ Zero))
isTwo (AnyCard (GSucc (GSucc GZero))) = Succ (Succ Zero)
isTwo _ = Nothing

  -- ryan

2008/12/13 Nathan Bloomfield :
> Hello all. I've got a puzzling Parsec problem. Perhaps the collective wisdom
> of haskell-cafe can point me in the right direction.
>
> 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. :) My first (simplified)
> approximation is as follows:
>
>> data Zero = Zero
>> data Succ a = Succ a
>
>> class Card t
>> instance Card Zero
>> instance (Card a) => Card (Succ a)
>
>> parseP :: (Card a) => Parser a
>> parseP = do { char '1'
>> ; rest <- parseP
>> ; return $ Succ rest
>> }
>>  <|> return Zero
>
> I'd like for this to parse, for example, "111" into Succ Succ Succ Zero. Of
> course this doesn't work because parseP is ill-typed, but I'm not sure how
> to fix it. It seems that what I'm asking for is a function whose type is
> forall a. (Card a) => String -> a, which is problematic.
>
> Has anyone tried this before? I'm new to using Parsec and to parsing in
> general, so I apologize if this is a silly question. (Parsec is very
> impressive, by the way.)
>
> Thanks-
>
> Nathan Bloomfield
> University of Arkansas, Fayetteville
>
> ___
> 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] Parsec and type level numerals

2008-12-13 Thread David Menendez
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


Re: [Haskell-cafe] A curios monad

2008-12-13 Thread David Menendez
On Thu, Dec 11, 2008 at 1:48 PM, Andrew Coppin
 wrote:
>
> BTW, does anybody know how rank-N types are different from existential
> types?

You mean the Haskell extensions?

ExistentialQuantification lets you define types such as,

data SomeNum = forall a. Num a => SomeNum a

RankNTypes lets you nest foralls arbitrarily deep in type signatures,

callCC :: ((forall b. a -> m b) -> m a) -> m a   -- this is rank-3

RankNTypes implies ExistentialQuantification (among others).

-- 
Dave Menendez 

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


[Haskell-cafe] Small haskell practical course

2008-12-13 Thread Marco Túlio Gontijo e Silva
Hello,

I've presented a small practical course[0] in EMSL[1].  Any comments are
welcome.

0: http://marcot.iaaeee.org/mini-curso.pdf (Portuguese only)
1: http://emsl.softwarelivre.org/

Greetings.

-- 
marcot
http://marcot.iaaeee.org/


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


Re: [Haskell-cafe] Small haskell practical course

2008-12-13 Thread Don Stewart
marcot:
> Hello,
> 
> I've presented a small practical course[0] in EMSL[1].  Any comments are
> welcome.
> 
> 0: http://marcot.iaaeee.org/mini-curso.pdf (Portuguese only)
> 1: http://emsl.softwarelivre.org/
> 

Wonderful. Maybe you can add it to the .pt section of the Haskell wiki?

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


Re: [Haskell-cafe] Small haskell practical course

2008-12-13 Thread Marco Túlio Gontijo e Silva
Em Sáb, 2008-12-13 às 13:07 -0800, Don Stewart escreveu:
> marcot:
> > Hello,
> > 
> > I've presented a small practical course[0] in EMSL[1].  Any comments are
> > welcome.
> > 
> > 0: http://marcot.iaaeee.org/mini-curso.pdf (Portuguese only)
> > 1: http://emsl.softwarelivre.org/
> > 
> 
> Wonderful. Maybe you can add it to the .pt section of the Haskell wiki?

Done, thanks for the suggestion.

http://haskell.org/haskellwiki/Livros_e_tutoriais

-- 
marcot
http://marcot.iaaeee.org/


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


Re: [Haskell-cafe] A curios monad

2008-12-13 Thread Andrew Coppin

David Menendez wrote:

On Thu, Dec 11, 2008 at 1:48 PM, Andrew Coppin
 wrote:
  

BTW, does anybody know how rank-N types are different from existential
types?



You mean the Haskell extensions?

ExistentialQuantification lets you define types such as,

data SomeNum = forall a. Num a => SomeNum a

RankNTypes lets you nest foralls arbitrarily deep in type signatures,

callCC :: ((forall b. a -> m b) -> m a) -> m a   -- this is rank-3

RankNTypes implies ExistentialQuantification (among others).
  


So how is

 foo :: ((forall b. a -> m b) -> m a) -> m a

different from

 bar :: forall b. ((a -> m b) -> m a) -> m a

then?

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


Re: [Haskell-cafe] A curios monad

2008-12-13 Thread Daniel Fischer
Am Sonntag, 14. Dezember 2008 00:00 schrieb Andrew Coppin:
> David Menendez wrote:
> > On Thu, Dec 11, 2008 at 1:48 PM, Andrew Coppin
> >
> >  wrote:
> >> BTW, does anybody know how rank-N types are different from existential
> >> types?
> >
> > You mean the Haskell extensions?
> >
> > ExistentialQuantification lets you define types such as,
> >
> > data SomeNum = forall a. Num a => SomeNum a
> >
> > RankNTypes lets you nest foralls arbitrarily deep in type signatures,
> >
> > callCC :: ((forall b. a -> m b) -> m a) -> m a   -- this is rank-3
> >
> > RankNTypes implies ExistentialQuantification (among others).
>
> So how is
>
>   foo :: ((forall b. a -> m b) -> m a) -> m a

Here, the argument of foo's argument must be a polymorphic function, capable 
of returning an (m b) whatever b is.

>
> different from
>
>   bar :: forall b. ((a -> m b) -> m a) -> m a

Here, the argument of bar's argument can have any monomorphic type (a -> m b)

>
> then?
>

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


Re: [Haskell-cafe] A curios monad

2008-12-13 Thread Ryan Ingram
On Sat, Dec 13, 2008 at 3:00 PM, Andrew Coppin
 wrote:
> So how is
>  foo :: ((forall b. a -> m b) -> m a) -> m a
> different from
>  bar :: forall b. ((a -> m b) -> m a) -> m a

Lets use a simpler example:
> foo :: (forall a. a -> a) -> (Int, String)
> bar :: forall a. (a -> a) -> (Int, String)

> -- this compiles
> foo f = (f 1, f "hello")

> -- this does not compile
> -- bar f = (f 1, f "hello")

> -- but this does
> bar f = (1, "hello")

The difference is that the *caller* of bar chooses how to instantiate
a, whereas the caller of foo must pass in a polymorphic function that
foo can instantiate at whatever type it wants... even multiple
different types!

> ident x = x
> plus1 x = x + 1 :: Int

> -- legal
> useFoo = foo ident
> -- not legal, not polymorphic
> -- useFoo = foo plus1

> -- legal
> useBar = bar ident
> -- also legal, instantiate "a" in the type of "bar" with "Int"
> useBar2 = bar plus1

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


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

2008-12-13 Thread Adam Vogt
* 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.

Making groups by comparing with the previous element, or the first element 
of the current group is occasionally useful: (this does the former)

> groupIncDiff :: (a -> a -> Bool) -> [a] -> [[a]]
> groupIncDiff p = uncurry (:) . foldr w ([],[])
> where w n ([],a) = ([n],a)
>   w n ((x:xs),a) | p x n = (n:x:xs,a)
>  | otherwise = ([n],(x:xs):a)

(in case somebody feels like assembling the apparently numerous was to 
group)

On another note, is there much use of such simple library functions: does 
concatMap, for instance, save anything other than a couple parantheses, or 
does (concat . map) not necessarily get optimized into the same thing?

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


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

2008-12-13 Thread George Pollard
On Sun, 2008-12-14 at 00:35 -0500, Adam Vogt wrote:
> On another note, is there much use of such simple library functions: does 
> concatMap, for instance, save anything other than a couple parantheses, or 
> does (concat . map) not necessarily get optimized into the same thing

Bart Massey’s results suggest very little difference:
http://wiki.cs.pdx.edu/forge/concatmap.html

(Yellow blobs + green crosses.)

- George


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] Data.List.Split

2008-12-13 Thread George Pollard
On Sun, 2008-12-14 at 19:46 +1300, George Pollard wrote:
> On Sun, 2008-12-14 at 00:35 -0500, Adam Vogt wrote:
> > On another note, is there much use of such simple library functions: does 
> > concatMap, for instance, save anything other than a couple parantheses, or 
> > does (concat . map) not necessarily get optimized into the same thing
> 
> Bart Massey’s results suggest very little difference:
>   http://wiki.cs.pdx.edu/forge/concatmap.html
> 
> (Yellow blobs + green crosses.)

I should have said that, on the other hand, with stream fusion enabled,
(concat . map) outperforms (concatMap) :)

- George


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] A curios monad

2008-12-13 Thread David Menendez
On Sat, Dec 13, 2008 at 6:00 PM, Andrew Coppin
 wrote:
> David Menendez wrote:
>>
>> On Thu, Dec 11, 2008 at 1:48 PM, Andrew Coppin
>>  wrote:
>>
>>>
>>> BTW, does anybody know how rank-N types are different from existential
>>> types?
>>>
>>
>> You mean the Haskell extensions?
>>
>> ExistentialQuantification lets you define types such as,
>>
>>data SomeNum = forall a. Num a => SomeNum a
>>
>> RankNTypes lets you nest foralls arbitrarily deep in type signatures,
>>
>>callCC :: ((forall b. a -> m b) -> m a) -> m a   -- this is rank-3
>>
>> RankNTypes implies ExistentialQuantification (among others).
>>
>
> So how is
>
>  foo :: ((forall b. a -> m b) -> m a) -> m a
>
> different from
>
>  bar :: forall b. ((a -> m b) -> m a) -> m a
>
> then?

Daniel Fischer already gave the short answer, I'll try explaining why
someone might *want* a rank-3 signature for callCC. It involves a
continuation monad, but hopefully nothing headache-inducing.

The type for callCC in Control.Monad.Cont.Class is,

callCC :: forall m a b. (MonadCont m) => ((a -> m b) -> m b) -> m b

You can use callCC to do very complicated things, but you can also use
it as a simple short-cut escape, like the way "return" works in C.

foo = callCC (\exit -> do
...
x <- if something
then return 'a'
else exit False
...
return True)

The type of exit is Bool -> m Char, which is fine in this example, but
it means that we can only use exit to escape from computations that
are producing characters. For example, we cannot write,

bar = callCC (\exit -> do
...
x <- if something then return 'a' else exit False
y <- if something then return 42 else exit False
...
return True)

Because exit would need to have the type Bool -> m Char the first time
and Bool -> m Int the second time. But, if callCC had a rank-3 type,

callCC :: forall m a. (MonadCont m) => ((forall b. a -> m b) -> m a) -> m a

then exit would have the type "forall b. Bool -> m b", and bar would
compile just fine.

-- 
Dave Menendez 

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