Re: [Haskell-cafe] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators

[Eugene Kirpichov]

Sounds just terrific! Thanks!



06.05.2011, в 8:15, David Mazieres  
написал(а):

> Hi, everyone.  I'm pleased to announce the release of a new iteratee
> implementation, iterIO:
> 
>http://hackage.haskell.org/package/iterIO
> 
> IterIO is an attempt to make iteratees easier to use through an
> interface based on pipeline stages reminiscent of Unix command
> pipelines.  Particularly if you've looked at iteratees before and been
> intimidated, please have a look at iterIO to see if it makes them more
> accessible.
> 
> Some aspects of iterIO that should simplify learning and using
> iteratees are:
> 
>   * Every aspect of the library is thoroughly document in haddock
> including numerous examples of use.
> 
>   * Enumerators are easy to build out of iteratees.
> 
>   * There is no difference between enumerators and "enumeratees"
> (i.e., inner pipeline stages).  The former is just a
> type-restricted version of the latter.
> 
>   * Parsing combinators provide detailed error reporting and support
> LL(*) rather than LL(1) parsing, leading to fewer non-intuitive
> parsing failures.  A couple of tricks avoid consuming excessive
> memory for backtracking.
> 
>   * Super-fast LL(1) parsing is also available through seamless
> integration with attoparsec.
> 
>   * A universal exception mechanism works across invocations of mtl
> monad transformers, thereby unifying error handling.
> 
>   * All pipe operators have uniform semantics, eliminating corner
> cases.  In particular, if the writing end of a pipe fails, the
> reading end always gets EOF, allowing it to clean up resources.
> 
>   * One can catch exceptions thrown by any contiguous subset of
> stages in a pipeline.  Moreover, enumerator exception handlers
> can resume downstream stages that haven't failed.
> 
>   * The package is full of useful iteratees and enumerators,
> including basic file and socket processing, parsec-like
> combinators, string search, zlib/gzip compression, SSL, HTTP, and
> "loopback" enumerator/iteratee pairs for testing a protocol
> implementation against itself.
> 
> Please enjoy.  I'd love to hear feedback.
> 
> David
> 
> ___
> 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] ANNOUNCE: iterIO-0.1 - iteratee-based IO with pipe operators

[David Mazieres]

Hi, everyone.  I'm pleased to announce the release of a new iteratee
implementation, iterIO:

http://hackage.haskell.org/package/iterIO

IterIO is an attempt to make iteratees easier to use through an
interface based on pipeline stages reminiscent of Unix command
pipelines.  Particularly if you've looked at iteratees before and been
intimidated, please have a look at iterIO to see if it makes them more
accessible.

Some aspects of iterIO that should simplify learning and using
iteratees are:

   * Every aspect of the library is thoroughly document in haddock
 including numerous examples of use.

   * Enumerators are easy to build out of iteratees.

   * There is no difference between enumerators and "enumeratees"
 (i.e., inner pipeline stages).  The former is just a
 type-restricted version of the latter.

   * Parsing combinators provide detailed error reporting and support
 LL(*) rather than LL(1) parsing, leading to fewer non-intuitive
 parsing failures.  A couple of tricks avoid consuming excessive
 memory for backtracking.

   * Super-fast LL(1) parsing is also available through seamless
 integration with attoparsec.

   * A universal exception mechanism works across invocations of mtl
 monad transformers, thereby unifying error handling.

   * All pipe operators have uniform semantics, eliminating corner
 cases.  In particular, if the writing end of a pipe fails, the
 reading end always gets EOF, allowing it to clean up resources.

   * One can catch exceptions thrown by any contiguous subset of
 stages in a pipeline.  Moreover, enumerator exception handlers
 can resume downstream stages that haven't failed.

   * The package is full of useful iteratees and enumerators,
 including basic file and socket processing, parsec-like
 combinators, string search, zlib/gzip compression, SSL, HTTP, and
 "loopback" enumerator/iteratee pairs for testing a protocol
 implementation against itself.

Please enjoy.  I'd love to hear feedback.

David

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

Re: [Haskell-cafe] Usage of rewrite rule specialization in Hackage

[wren ng thornton]

On 5/5/11 10:36 AM, Scott Kilpatrick wrote:

I'm looking for "real" code that uses the kind of GHC rewrite rule
that specializes a polymorphic function with another one, as described
here.  Can anyone point me to any popular packages in
Hackage that make use of this?


Perhaps not the easiest example to look through, but just check out the 
base package. In particular, there are a number of functions which get 
specialized implementations for Int, Int#, Word, etc.


--
Live well,
~wren

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

[Haskell-cafe] lambdabot install error

[epsilonhalbe]

hey haskellers,
i'm fresh into haskell and love it. so to do faster easier haskell i
wanted to install lambdabot but had to face some errors - i don't
understand them at all
here is some error output from zsh:

http://hpaste.org/46401/bot_install_error

can anyone help me - i'm working on a debian (crunchbang)
y.t epsilonhalbe (ε/2)



signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: unordered-container 0.1.3.0

[Johan Tibell]

Hi all,

I've just uploaded a new version of the unordered-containers package,
a package of fast hashing-based container types. Version
0.1.3.0 [1] adds:

* the ability to take the union of two maps,
* lower memory overhead per key/value pair (contributed by Jan-Willem
  Maessen), and
* the beginning of a `Data.HashSet` module (contributed by Bryan
  O'Sullivan).

If you want to contribute, you can get the source from the git
repository:

git clone https://github.com/tibbe/unordered-containers.git

Alternatively, just fork the project on GitHub [2].

1. http://http://hackage.haskell.org/package/unordered-containers-0.1.3.0
2. https://github.com/tibbe/unordered-containers

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

Re: [Haskell-cafe] Can't build Gtk2hs on Windows

[Andrew Coppin]

On 05/05/2011 01:32 AM, Albert Y. C. Lai wrote:

Just 5 weeks ago,

http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456

Did anyone see it?


Right. So the problem might be GTK+ v3?

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

[Haskell-cafe] Usage of rewrite rule specialization in Hackage

[Scott Kilpatrick]

I'm looking for "real" code that uses the kind of GHC rewrite rule
that specializes a polymorphic function with another one, as described
here .  Can anyone point me to any popular packages in
Hackage that make use of this?

Thanks,
Scott

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

Re: [Haskell-cafe] Can't build Gtk2hs on Windows

[Daniel Kahlenberg]

Ryan,

thanks for adopting party.

Daniel

2011/5/5 Ryan Yates :
> Daniel,
>
> Nice summery.  I think one of the difficult issues is my "patch" in
> http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is something worthy
> of scare quotes.  I'm not a Cabal developer and I have no clue what
> the implications of that change are.  For all I know things would
> cease working on Linux with the patch applied.  I think it is sane,
> but to verify that would require me to know a lot more about Cabal's
> workings then I have time to do.  Cabal-dev addresses this nicely in
> that it isolates the unknowns.  The global workaround is bad because
> it is even less isolated but has the benefit that you do not have to
> patch the setups.
>
> Another issue is that the gtk2hs Trac makes you login as guest.  As
> such, I can't add myself to the CC list and this makes it is hard to
> tell how many people are running into this issue.  Similarly the
> gtk2hs website being down makes it look like gtk2hs is dead.  I know
> that it is in all likelihood down due to the server switch
> (http://www.haskell.org/pipermail/haskell-cafe/2011-February/088829.html).
>  The Trac issue is probably due to an updated version of Trac changing
> how CC field is set.
>
> All of these little (very understandable) things compound the issue
> and frustrate people.  It is a good sign that people are expecting
> things to work and the issues in the way are small.  There are just
> too few people with the means to fix those small issues, but I'm glad
> they do the work they do.
>
> I'm also sending this to the gtk2hs list to see if it can get some
> traction there.
>
> Ryan
>
> On Thu, May 5, 2011 at 4:25 AM, Daniel Kahlenberg
>  wrote:
>> Hi,
>>
>> I have no spaces in my GTK installation path (h:\gtk+ there is no
>> other gtk+, zlib1.dll etc. in my search path). The "patch"
>> http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is easier handled
>> when using the cab/cabal-dev combination as I described here:
>> http://article.gmane.org/gmane.comp.lang.haskell.cafe/88022, although
>> this is no long-term solution, I agree.
>>
>> (I don't agree to let users require to install more or less arbitrary
>> packages globally as long as a separation of permissions is reasonable
>> for complex systems. Don't get me wrong: I would respect the advice if
>> I had other information but I'm even not convinced.)
>>
>> The problem persists anyhow - with all backend gtk versions I tried -
>> that building certain packages depending on the bundled cairo package,
>> fail with a "unknown symbol `_cairo_image_surface_get_data'" error
>> message
>> The full description and bug tracing so far I described here:
>> http://groups.google.com/group/haskell-charts/msg/9c8e4420b517c4f7
>> (also here 
>> http://osdir.com/ml/glasgow-haskell-us...@haskell.org/2011-04/msg7.html).
>>
>> All in all I even thought about replacing/augmenting the gtk+ calls in
>> e. g. timeplot code by wx calls or something like that to have a
>> chance to use these nice tools on windows too, to circumvent
>> regression on parallel installs of legacy ghc versions, have no idea
>> either ;) Maybe an API comparison table in the WIKI might help here.
>>
>> GTK versions I sampled (all three with ghc-7.0.3, the first one also
>> with ghc-7.0.2), yielding overall the same results:
>>
>> http://ftp.acc.umu.se/pub/GNOME/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.1-20101227_win32
>>
>> http://ftp.acc.umu.se/pub/gnome/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe
>>
>> http://ftp.acc.umu.se/pub/gnome/binaries/win32/gtk+/2.24/ with the
>> bundled tools manually installed using the components.lst file from
>> the -2.22.1-* bundle as a reference.
>>
>> The http://hackage.haskell.org/trac/gtk2hs/ticket/1209 issue is valid
>> for older gtk versions (until around 2.16) only and can be bypassed by
>> adding -f-have-gio, enabling the non-gio build at least.
>>
>> I agree that it is possibly a windows only specific issue. Might even
>> relate to my mingw+msys setup, although I explicitly used the
>> mingw-get tool to install the whole build environment. Possibly the
>> patching hack (http://hackage.haskell.org/trac/gtk2hs/ticket/1203) is
>> an issue factor itself if it lead to incompatible situation.
>>
>> Greets
>> Daniel
>>
>> 2011/5/5 Albert Y. C. Lai :
>>> Just 5 weeks ago,
>>>
>>> http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456
>>>
>>> Did anyone see it?
>>>
>>> ___
>>> 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How often is the planet updated?

[Magnus Therning]

On Thu, May 5, 2011 at 14:12, Malcolm Wallace  wrote:
>
> On 28 Apr 2011, at 11:26, Magnus Therning wrote:
>
>> I see that Planet Haskell hasn't been updated since April 26.  Is
>> something wrong with it, or does it really not update more often than
>> that?
>
> Just to note: there was a configuration problem with planet, which has now 
> been sorted out.  The usual schedule of updates has resumed.

Thanks, I noticed that it picked up speed again a few days ago :-)

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

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

Re: [Haskell-cafe] Can't build Gtk2hs on Windows

[Ryan Yates]

Daniel,

Nice summery.  I think one of the difficult issues is my "patch" in
http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is something worthy
of scare quotes.  I'm not a Cabal developer and I have no clue what
the implications of that change are.  For all I know things would
cease working on Linux with the patch applied.  I think it is sane,
but to verify that would require me to know a lot more about Cabal's
workings then I have time to do.  Cabal-dev addresses this nicely in
that it isolates the unknowns.  The global workaround is bad because
it is even less isolated but has the benefit that you do not have to
patch the setups.

Another issue is that the gtk2hs Trac makes you login as guest.  As
such, I can't add myself to the CC list and this makes it is hard to
tell how many people are running into this issue.  Similarly the
gtk2hs website being down makes it look like gtk2hs is dead.  I know
that it is in all likelihood down due to the server switch
(http://www.haskell.org/pipermail/haskell-cafe/2011-February/088829.html).
 The Trac issue is probably due to an updated version of Trac changing
how CC field is set.

All of these little (very understandable) things compound the issue
and frustrate people.  It is a good sign that people are expecting
things to work and the issues in the way are small.  There are just
too few people with the means to fix those small issues, but I'm glad
they do the work they do.

I'm also sending this to the gtk2hs list to see if it can get some
traction there.

Ryan

On Thu, May 5, 2011 at 4:25 AM, Daniel Kahlenberg
 wrote:
> Hi,
>
> I have no spaces in my GTK installation path (h:\gtk+ there is no
> other gtk+, zlib1.dll etc. in my search path). The "patch"
> http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is easier handled
> when using the cab/cabal-dev combination as I described here:
> http://article.gmane.org/gmane.comp.lang.haskell.cafe/88022, although
> this is no long-term solution, I agree.
>
> (I don't agree to let users require to install more or less arbitrary
> packages globally as long as a separation of permissions is reasonable
> for complex systems. Don't get me wrong: I would respect the advice if
> I had other information but I'm even not convinced.)
>
> The problem persists anyhow - with all backend gtk versions I tried -
> that building certain packages depending on the bundled cairo package,
> fail with a "unknown symbol `_cairo_image_surface_get_data'" error
> message
> The full description and bug tracing so far I described here:
> http://groups.google.com/group/haskell-charts/msg/9c8e4420b517c4f7
> (also here 
> http://osdir.com/ml/glasgow-haskell-us...@haskell.org/2011-04/msg7.html).
>
> All in all I even thought about replacing/augmenting the gtk+ calls in
> e. g. timeplot code by wx calls or something like that to have a
> chance to use these nice tools on windows too, to circumvent
> regression on parallel installs of legacy ghc versions, have no idea
> either ;) Maybe an API comparison table in the WIKI might help here.
>
> GTK versions I sampled (all three with ghc-7.0.3, the first one also
> with ghc-7.0.2), yielding overall the same results:
>
> http://ftp.acc.umu.se/pub/GNOME/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.1-20101227_win32
>
> http://ftp.acc.umu.se/pub/gnome/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe
>
> http://ftp.acc.umu.se/pub/gnome/binaries/win32/gtk+/2.24/ with the
> bundled tools manually installed using the components.lst file from
> the -2.22.1-* bundle as a reference.
>
> The http://hackage.haskell.org/trac/gtk2hs/ticket/1209 issue is valid
> for older gtk versions (until around 2.16) only and can be bypassed by
> adding -f-have-gio, enabling the non-gio build at least.
>
> I agree that it is possibly a windows only specific issue. Might even
> relate to my mingw+msys setup, although I explicitly used the
> mingw-get tool to install the whole build environment. Possibly the
> patching hack (http://hackage.haskell.org/trac/gtk2hs/ticket/1203) is
> an issue factor itself if it lead to incompatible situation.
>
> Greets
> Daniel
>
> 2011/5/5 Albert Y. C. Lai :
>> Just 5 weeks ago,
>>
>> http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456
>>
>> Did anyone see it?
>>
>> ___
>> 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How often is the planet updated?

[Malcolm Wallace]

On 28 Apr 2011, at 11:26, Magnus Therning wrote:

> I see that Planet Haskell hasn't been updated since April 26.  Is
> something wrong with it, or does it really not update more often than
> that?

Just to note: there was a configuration problem with planet, which has now been 
sorted out.  The usual schedule of updates has resumed.

Regards,
Malcolm

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

Re: [Haskell-cafe] Crypto-api performance

[Vincent Hanquez]

On Thu, May 05, 2011 at 11:56:42AM +0200, Peter Simons wrote:
> Hi Matthew,
> 
>  > While I haven't investigated myself, from seeing haskell build processes
>  > in the past this is almost certainly not crypto-api's fault and is in
>  > fact your linker's fault. If you are not using it already, try switching
>  > to gold over ld, it may help.
> 
> well, memory consumption sky-rockets while compiling "Crypto.CPoly".
> That behavior is probably not related to the linker.

That's more than likely linked to the huge dispatch table related to cpoly.
It would probably helps to build a vector with the data instead of this.

-- 
Vincent

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

Re: [Haskell-cafe] Crypto-api performance

[Peter Simons]

Hi Matthew,

 > While I haven't investigated myself, from seeing haskell build processes
 > in the past this is almost certainly not crypto-api's fault and is in
 > fact your linker's fault. If you are not using it already, try switching
 > to gold over ld, it may help.

well, memory consumption sky-rockets while compiling "Crypto.CPoly".
That behavior is probably not related to the linker.

Take care,
Peter


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

Re: [Haskell-cafe] Can't build Gtk2hs on Windows

[Daniel Kahlenberg]

Hi,

I have no spaces in my GTK installation path (h:\gtk+ there is no
other gtk+, zlib1.dll etc. in my search path). The "patch"
http://hackage.haskell.org/trac/gtk2hs/ticket/1203 is easier handled
when using the cab/cabal-dev combination as I described here:
http://article.gmane.org/gmane.comp.lang.haskell.cafe/88022, although
this is no long-term solution, I agree.

(I don't agree to let users require to install more or less arbitrary
packages globally as long as a separation of permissions is reasonable
for complex systems. Don't get me wrong: I would respect the advice if
I had other information but I'm even not convinced.)

The problem persists anyhow - with all backend gtk versions I tried -
that building certain packages depending on the bundled cairo package,
fail with a "unknown symbol `_cairo_image_surface_get_data'" error
message
The full description and bug tracing so far I described here:
http://groups.google.com/group/haskell-charts/msg/9c8e4420b517c4f7
(also here 
http://osdir.com/ml/glasgow-haskell-us...@haskell.org/2011-04/msg7.html).

All in all I even thought about replacing/augmenting the gtk+ calls in
e. g. timeplot code by wx calls or something like that to have a
chance to use these nice tools on windows too, to circumvent
regression on parallel installs of legacy ghc versions, have no idea
either ;) Maybe an API comparison table in the WIKI might help here.

GTK versions I sampled (all three with ghc-7.0.3, the first one also
with ghc-7.0.2), yielding overall the same results:

http://ftp.acc.umu.se/pub/GNOME/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.1-20101227_win32

http://ftp.acc.umu.se/pub/gnome/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe

http://ftp.acc.umu.se/pub/gnome/binaries/win32/gtk+/2.24/ with the
bundled tools manually installed using the components.lst file from
the -2.22.1-* bundle as a reference.

The http://hackage.haskell.org/trac/gtk2hs/ticket/1209 issue is valid
for older gtk versions (until around 2.16) only and can be bypassed by
adding -f-have-gio, enabling the non-gio build at least.

I agree that it is possibly a windows only specific issue. Might even
relate to my mingw+msys setup, although I explicitly used the
mingw-get tool to install the whole build environment. Possibly the
patching hack (http://hackage.haskell.org/trac/gtk2hs/ticket/1203) is
an issue factor itself if it lead to incompatible situation.

Greets
Daniel

2011/5/5 Albert Y. C. Lai :
> Just 5 weeks ago,
>
> http://thread.gmane.org/gmane.comp.lang.haskell.cafe/86738/focus=87456
>
> Did anyone see it?
>
> ___
> 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] Can't build Gtk2hs on Windows

[jutaro]

I just installed gtk2hs on Windows last week (for Leksah development).

I downloded and unzipped the following files to a gtk folder:
gtk+-bundle_2.22.1-20101227_win32.zip
gtksourceview-2.10.0.zip
gtksourceview-dev-2.10.0.zip
libxml2_2.7.7-1_win32.zip
libxml2-dev_2.7.7-1_win32.zip
I added the bin of the gtk folder to my path.

Then just installed gtk2hs the usual way 
(cabal install gtk2hs-buildtools,
cabal install gtksourceview2)

It failed then with linker errors, until I realised, that I 
had other gtk installations in the path (Pidgin, ghostview).
After I took them out all went fine.

Jürgen

--
View this message in context: 
http://haskell.1045720.n5.nabble.com/Can-t-build-Gtk2hs-on-Windows-tp4371091p4372181.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

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

[Haskell-cafe] 2nd CFP: ACM SIGPLAN 7th Workshop on Generic Programming (WGP 2011)

[Shin-Cheng Mu]

==
 CALL FOR PAPERS

WGP 2011

   7th ACM SIGPLAN Workshop on Generic Programming
  Tokyo, Japan
   Sunday, September 18th, 2011

 http://flolac.iis.sinica.edu.tw/wgp11/

Collocated with the International Conference on Functional Programming
(ICFP 2011)
==

Goals of the workshop
-

Generic programming is about making programs more adaptable by making
them more general. Generic programs often embody non-traditional kinds
of polymorphism; ordinary programs are obtained from them by suitably
instantiating their parameters. In contrast with normal programs, the
parameters of a generic program are often quite rich in structure; for
example they may be other programs, types or type constructors, class
hierarchies, or even programming paradigms.

Generic programming techniques have always been of interest, both to
practitioners and to theoreticians, and, for at least 20 years,
generic programming techniques have been a specific focus of research
in the functional and object-oriented programming communities. Generic
programming has gradually spread to more and more mainstream
languages, and today is widely used in industry. This workshop brings
together leading researchers and practitioners in generic programming
from around the world, and features papers capturing the state of the
art in this important area.

We welcome contributions on all aspects, theoretical as well as
practical, of

   * generic programming,
   * programming with (C++) concepts,
   * meta-programming,
   * programming with type classes,
   * programming with modules,
   * programming with dependent types,
   * polytypic programming,
   * adaptive object-oriented programming,
   * component-based programming,
   * strategic programming,
   * aspect-oriented programming,
   * family polymorphism,
   * object-oriented generic programming,
   * and so on.

Organizers
--

Co-Chair
 Jaakko Järvi, Texas A&M University, USA
Co-Chair
 Shin-Cheng Mu, Academia Sinica, Taiwan

Programme Committee
---

Dave Abrahams, BoostPro Computing, USA
Magne Haveraaen, Universitetet i Bergen, Norway
Akimasa Morihata, Tohoku University, Japan
Pablo Nogueira, Universidad Politécnica de Madrid, Spain
Ulf Norell, Chalmers University of Technology and University of Gothenberg, 
Sweden
Ross Paterson, City University London, UK
Rinus Plasmeijer, Radboud University Nijmegen, The Netherlands
Sibylle Schupp, Technische Universität Hamburg-Harburg, Germany
Andrew Sutton, Kent State University, USA
Tarmo Uustalu, Institute of Cybernetics, Estonia

Important Information
-

We plan to have formal proceedings, published by the ACM.

Submission details
Deadline for submission: Monday2011-06-06
Notification of acceptance:  Tuesday   2011-07-01
Final submission due:Monday2011-07-25
Workshop:Sunday2011-09-18

Authors should submit papers, in postscript or PDF format, formatted
for A4 paper, to the WGP11 EasyChair instance by the above deadline.
The length should be restricted to 12 pages in standard
(two-column, 9pt) ACM format. Accepted papers are published by the ACM
and will additionally appear in the ACM digital library.

History of the Workshop on Generic Programming
--

This year:

 * Tokyo, Japan 2011 (affiliated with ICFP11)

Earlier Workshops on Generic Programming have been held in

 * Baltimore, Maryland, US 2010 (affiliated with ICFP10)
 * Edinburgh, UK 2009 (affiliated with ICFP09)
 * Victoria, BC, Canada 2008 (affiliated with ICFP),
 * Portland 2006 (affiliated with ICFP),
 * Ponte de Lima 2000 (affiliated with MPC),
 * Marstrand 1998 (affiliated with MPC).

Furthermore, there were a few informal workshops

 * Utrecht 2005 (informal workshop),
 * Dagstuhl 2002 (IFIP WG2.1 Working Conference),
 * Nottingham 2001 (informal workshop),

There were also (closely related) DGP workshops in Oxford (June
3-4 2004), and a Spring School on DGP in Nottingham (April 24-27
2006, which had a half-day workshop attached).
Additional information:

The WGP steering committee consists of J. Gibbons, R. Hinze, P. Jansson,
J. Järvi, J. Jeuring, B. Oliveira, S. Schupp, and M. Zalewski

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