RE: ANN: mute-unmute-0.2.0.0

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: stringsearch 0.3.1, fast searching, splitting and replacing of ByteStrings

Changes vs. 0.3.0:
- fixed a space leak in the splitting of lazy ByteStrings

Changes of the 0.3 series vs. 0.2.*:
- improved performance of the searching functions
- new functionality:
  - breaking of ByteStrings at the first occurrence of a substring
  - splitting a ByteString at each occurrence of a substring
  - replacing all occurrences of a substring with another string

Where bytestring provides the same functionality 
(Data.ByteString.breakSubstring, Data.ByteString.findSubstrings), the 
implementations in stringsearch are typically much faster.
By default, stringsearch uses an enhanced Boyer-Moore algorithm to locate a 
pattern, but it also provides other algorithms which may be better in 
special cases (Knuth-Morris-Pratt; DFA).

Proposal: Form a haskell.org committee

Dear Haskellers,

In recent years, haskell.org has started to receive assets, e.g. money
from Google Summer Of Code, donations for Hackathons, and a Sparc
machine for use in GHC development. We have also started spending this
money: on the community server, on a server to take over hosting
haskell.org itself, and on the haskell.org domain name. There is also
interest in running fundraising drives for specific things such as
Hackathon sponsorship and hosting fees.

However, it is not currently clear who is responsible for determining
what the haskell.org money should be spent on, or what are and are not
acceptable uses of the domain name and hardware.

To fix this problem, we propose that we create a "haskell.org
committee", which is responsible for answering these sorts of questions,
although for some questions they may choose to poll the community at
large if they think appropriate.

We suggest that the committee be composed of 5 representatives from the
community, with committee members standing down after at most 3 years.
Each year the committee will appoint one of their members to be the chair.

As membership of "the Haskell community" is not well-defined, and voting
would potentially be open to abuse if anyone were able to vote, we
propose that the committee should choose their replacements from open
nominations.

Unfortunately, this gives us a bootstrapping problem, so we suggest that
the initial committee be chosen from open nominations by some of the
people who currently de-facto end up making the decisions currently:
Duncan Coutts, Isaac Jones, Ian Lynagh, Don Stewart and Malcolm Wallace.
These 5 would still be elligible to nominate themselves. Two of the
initial members will stand down after one year, and two after two years,
in order to bootstrap rolling membership turnover.

    We would love to hear feedback from you about this proposal,
    so that we can see whether the proposal, or something similar,
    has consensus amongst the community!

A related issue is that haskell.org does not currently exist as a legal
entity. We also hope to solve that problem, but we are still gathering
information so that the community can make an informed decision, so I
won't say more about that for now.

Thanks
Ian

Re: [Haskell-cafe] Re: Proposal: Form a haskell.org committee

2010/9/6 Manuel M T Chakravarty <chak <at> cse.unsw.edu.au>:
> Ian Lynagh:
>> To fix this problem, we propose that we create a "haskell.org
>> committee", which is responsible for answering these sorts of questions,
>> although for some questions they may choose to poll the community at
>> large if they think appropriate.
> [..]
>> Unfortunately, this gives us a bootstrapping problem, so we suggest that
>> the initial committee be chosen from open nominations by some of the
>> people who currently de-facto end up making the decisions currently:
>> Duncan Coutts, Isaac Jones, Ian Lynagh, Don Stewart and Malcolm Wallace.
>> These 5 would still be elligible to nominate themselves. Two of the
>> initial members will stand down after one year, and two after two years,
>> in order to bootstrap rolling membership turnover.
>
> Good plan!
>
> Manuel

Seems very good,

Thu

ANNOUNCE: LibZip 0.1, BSD library to read and write zip archives

Dear Haskellers,

I am glad to announce that LibZip, a major remake of Haskell bindings
to libzip library, is now available [1].

As far as I know, LibZip the only non-GPL library for Haskell to
manipulate zip archives (zip-archive library is GPLv2, LibZip is BSD).
LibZip is also reasonably fast with large on-disk archives (more about
it in the blog post, see a link below [2]).

New LibZip covers almost all features of the corresponding C library:

* creating, reading, updating, renaming, and deleting files in zip archives
* reading and writing file and archive comments
* support of various data sources: from a buffer, from a file, from
another archive and from a pure function

With respect to the old LibZip 0.0, there is a new monadic interface
[3], more tests, examples and documentation. Users of LibZip 0.0 may
still use the old API by importing Codec.Archive.LibZip.LegacyZeroZero
instead of Codec.Archive.LibZip. However, the old API is deprecated
and will not be supported in the future.

Links:

[1] Hackage page: http://hackage.haskell.org/package/LibZip
[2] Blog post: http://nix-tips.blogspot.com/2010/09/libzip-01-read-and-write-zip-archives.html
[3] Documentation: http://sovety.org.ru/doc/LibZip/Codec-Archive-LibZip.html

Best regards,
Sergey Astanin

Re: ANNOUNCE: countable-0.1

On Mon, 2010-09-06 at 03:54 -0700, Ashley Yakeley wrote: 
> countable: Countable, Searchable, Finite, Empty classes.
> 
>    class Countable, for countable types
>    class AtLeastOneCountable, for countable types that have at least one 
> value
>    class InfiniteCountable, for infinite countable types
>    class Searchable, for types that can be searched over
>    class Finite, for finite types
>    class Empty, for empty types
>    data Nothing, an empty type
> 
> Also includes these orphan instances:
> 
>    instance (Searchable a,Eq b) => Eq (a -> b)
>    instance (Finite a) => Foldable ((->) a)
>    instance (Finite a) => Traversable ((->) a)
>    instance (Show a,Finite a,Show b) => Show (a -> b)
> 
> It turns out Searchable includes some infinite types. Specifically, 
> countable implements this:
> 
>    instance (Countable c,Searchable s) => Searchable (c -> s)
> 
> using the algorithm described here:
> 
> http://math.andrej.com/2007/09/28/seemingly-impossible-functional-programs/
> 
> I would welcome improvements.
> 
> http://hackage.haskell.org/package/countable-0.1
> cabal install countable
> darcs get http://code.haskell.org/countable/
> 
> See also this thread:
> http://thread.gmane.org/gmane.comp.lang.haskell.cafe/73275
> 

Hmm.

1. Code formatting is very C#-like. At least for me it is hard to read
the code that way (it IS matter of preference however)

2. countMaybeNext seems to need documentation. If I understand it
correctly:

countMaybeNext Nothing = 'minimalValue'
countMaybeNext (Just x) = x + 1

Wouldn't be split it to:

countNext :: a -> Maybe a
initial :: Maybe a

3. 

Regards 

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: reference 0.1

Reference is class which generalizes references and monads they exists
in. It means that IORef, STRef and others can be accessed by common
interface.

Currently it is of form:

class Reference r m where

1. There was a proposal to rename the class to MonadRef or
MonadReference. IMHO it would imply m -> r functional dependency and
therefore disallow the instances for both MVar IO and IORef IO

2. Should the functional dependencies or type famillies be introduced?
Personally I don't think so as I would like to allow all of the
following:

 - IORef IO
 - MVar IO
 - IORef (ContT IO)
 - MVar (ContT IO)

Any feedback mostly welcome. 

Regards
PS. Darcs repository will be available soon 

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: ANNOUNCE: reference 0.1

On Mon, Sep 6, 2010 at 11:55 PM, Maciej Piechotka <uzytkownik2 <at> gmail.com> wrote:
> Reference is class which generalizes references and monads they exists
> in. It means that IORef, STRef and others can be accessed by common
> interface.
>
> Currently it is of form:
>
> class Reference r m where
>
> 1. There was a proposal to rename the class to MonadRef or
> MonadReference. IMHO it would imply m -> r functional dependency and
> therefore disallow the instances for both MVar IO and IORef IO
>
> 2. Should the functional dependencies or type famillies be introduced?
> Personally I don't think so as I would like to allow all of the
> following:
>
>  - IORef IO
>  - MVar IO
>  - IORef (ContT IO)
>  - MVar (ContT IO)
>
> Any feedback mostly welcome.
>
> Regards
> PS. Darcs repository will be available soon
>
> _______________________________________________
> Haskell mailing list
> Haskell <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>

I've played with a somewhat similar idea:

darcs get http://code.haskell.org/~basvandijk/code/only-read-or-write-vars

API Docs + Hyperlinked source:
http://code.haskell.org/~basvandijk/code/only-read-or-write-vars/doc/html/only-read-or-write-vars/

This is not released (yet) because I'm unsure about the design.

Especially, I'm unsure whether parameterizing Readable with α is a good idea:

class Readable v m α | v → m where read ∷ v → m α

and whether parameterizing Writable with α and β is a good idea:

class Writable v α m β | v → m where write ∷ v → α → m β

They do allow some

Regards,

Bas

TLDI 2011: 2nd Call For Papers

                            TLDI 2011

                         2nd CALL FOR PAPERS

	        The Sixth ACM SIGPLAN Workshop on
            Types in Language Design and Implementation

	               Austin, Texas, USA
                     Tuesday, January 25, 2011
                    (Co-located with POPL 2011)

	     http://www.mpi-sws.org/~dreyer/tldi2011/

               Submission Deadline: October 11, 2010

The role of types and proofs in all aspects of language design,
compiler construction, and software development has expanded greatly
in recent years.  Type systems, type-based analyses and type-theoretic
deductive systems have been central to advances in compilation
techniques for modern programming languages, verification of safety
and security properties of programs, program transformation and
optimization, and many other areas.  The ACM SIGPLAN Workshop on Types
in Language Design and Implementation brings researchers together to
share new ideas and results concerning all aspects of types and
programming, and is now an annual event.  TLDI 2011 is the sixth
workshop in the series and will be co-located with POPL in Austin,
Texas in January 2011.

Submissions for TLDI 2011 are invited on all interactions of types
with language design, implementation, and programming methodology.
This includes both practical applications and theoretical aspects.
TLDI 2011 specifically encourages papers from a broad field of
programming language and compiler researchers, including those working
on object-oriented or dynamic languages, systems programming,
mobile-code or security, as well as traditional fully-static type
systems.  Topics of interest include:

    * Typed intermediate languages and type-directed compilation
    * Type-based language support for safety and security
    * Types for interoperability
    * Type systems for system programming languages
    * Type-based program analysis, transformation, and optimization
    * Dependent types and type-based proof assistants
    * Types for security protocols, concurrency, and distributed  
computing
    * Type inference and type reconstruction
    * Type-based specifications of data structures and program  
invariants
    * Type-based memory management
    * Proof-carrying code and certifying compilation
    * Types and objects

This is not meant to be an exhaustive list; papers on novel
utilizations of type information are welcome.  Authors concerned about
the suitability of a topic are encouraged to inquire via electronic
mail to the program chair prior to submission.

Submission Guidelines:

Authors should submit a full paper of no more than 12 pages (including
bibliography and appendices) by Monday, October 11, 2010.  The
submission deadline and length limitations are firm.  Submissions that
do not meet these guidelines will not be considered.

All submissions should be in standard ACM SIGPLAN conference format:
two columns, nine-point font on a ten-point baseline.  Detailed
formatting guidelines are available on the SIGPLAN Author Information
page, along with a LaTeX class file and template.

Papers must be submitted electronically via the workshop website
(http://www.mpi-sws.org/~dreyer/tldi2011/) in Adobe Portable Document
Format (PDF) and must be formatted for US Letter size (8.5"x11")
paper.  Authors for whom this is a hardship should contact the program
chair before the deadline.

Submitted papers must adhere to the SIGPLAN Republication Policy.
Submissions should contain original research not published or
submitted for publication elsewhere.

Publication:

As in previous years, accepted papers will be published by the ACM and
appear in the ACM digital library.  A printed proceedings will be
available at the workshop.

Important Dates:

- Submission deadline: October 11, 2010 (Monday), 21:00 Samoa-Apia Time
- Notification:        November 8, 2010 (Monday)
- Final versions due:  November 22, 2010 (Monday)
- Workshop:            January 25, 2011 (Tuesday)

General Chair:

   Stephanie Weirich
   University of Pennsylvania
   sweirich at cis dot upenn dot edu

Program Chair:

   Derek Dreyer
   Max Planck Institute for Software Systems (MPI-SWS)
   dreyer at mpi-sws dot org

Program Committee:

   Thorsten Altenkirch (University of Nottingham)
   Fritz Henglein (University of Copenhagen)
   Michael Hicks (University of Maryland, College Park)
   Limin Jia (Carnegie Mellon University)
   Mark Jones (Portland State University)
   Neel Krishnaswami (Microsoft Research, Cambridge)
   Paul-André Melliès (CNRS & Université Paris Diderot)
   Aleks Nanevski (IMDEA Software, Madrid)
   Benjamin Pierce (University of Pennsylvania)
   Tachio Terauchi (Tohoku University)
   Sam Tobin-Hochstadt (Northeastern University)

Steering Committee:

   Amal Ahmed (Indiana University)
   Nick Benton (Microsoft Research, Cambridge)
   Derek Dreyer (MPI-SWS)
   Robert Harper (Carnegie Mellon University, chair)
   Andrew Kennedy (Microsoft Research, Cambridge)
   Francois Pottier (INRIA Rocquencourt)
   Zhong Shao (Yale University)
   Stephanie Weirich (University of Pennsylvania)

Re: [Haskell-cafe] Re: Re: ANNOUNCE: reference 0.1

On Wed, 2010-09-08 at 09:53 +0200, Alberto G. Corona wrote:
> Ah, ok. I though that your intention was to restrict the class
> definition for the IO monad . Goood.
> 
> 
> Maybe in the long term, it make sense to include this type class in
> some  monad related package such is mtl, since  references are part of
> many user monads. I think also that some default instances can be
> defined for transformed monads.
> 

Yes - they can. 

In fact:

instance (MonadTrans t, Monad (t m),
          Reference r m) => Reference r (t m) where
    newRef = lift . newRef
    readRef = lift . readRef
    writeRef r = lift . writeRef r

instance (MonadIO m, Reference r IO) => Reference r m where
    newRef = liftIO . newRef
    readRef = liftIO . readRef
    writeRef r = liftIO . writeRef r

> 
> It is pleasant for me to read and write something like
> 
> 
> x <- readRef rx
> 
> 
> rather than
> 
> 
> x<- readMyMonadRef sx
> 
> 
> Such generalizatiopns may be also good for extracting more common
> patterns among different monads. 

Actually the primary need was to create mutable single-linked list for
iteratee-parsec. I didn't wanted to restrict myself to ST or IO so I
choose to add class for them.

Regards

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell