Re: [Haskell] Top Level <-

[Edward Kmett]

On Sun, Aug 24, 2008 at 7:12 PM, Ashley Yakeley <[EMAIL PROTECTED]> wrote:

> Is there any interest in implementing a top level "<-" to run monadic code?
>

This is actually implemented in jhc. See the 'top level actions' section of
http://repetae.net/computer/jhc/manual.html

-Edward Kmett
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Abusing quickcheck to check existential properties

[Edward Kmett]

The answer is that QuickCheck can't correctly constructively verify an
existential condition without a constructive mechanism to generate the
existential (i.e. the Skolem function mentioned before).

If you think about it from a plausible reasoning and constructive logic
sense, QuickCheck should not be able to answer the question you
desire. After all it runs a bounded number of tests, if it didn't find your
case in that number of checks its not definitive. It may have been looking
in the wrong spots at the wrong cases.
A QuickCheck merely provides support for the plausibility of a universally
quantified statement, much like how an experiment can't prove a model in
physics, it can merely provide support for it. (see Polya's Mathematics and
Plausible Reasoning). The scientific method can never prove anything.
QuickCheck never gives you a false negative, but that one-sided error dooms
your quest.

You can assert that something doesn't exist with QuickCheck, but asserting
that something always holds is the domain of mathematics, not experiment,
unless you can exhaustively enumerate the universe of discourse, which is
why SmallCheck _can_ handle existential claims.

Now that said, if you can strengthen the existential to a probabalistic
claim about the odds of a random sample satisfying a given property are
greater than some fixed known positive real number, then you can abuse the
known QuickCheck sample size to say something about the odds of your
'expectFailure' style trick failing to substantiate your claim, but
unfortunately this costs you the invariant that when quickcheck says
something is wrong that something really is wrong.

And to me at least the value of QuickCheck is that it never cries wolf.

-Ed

On Tue, Oct 14, 2008 at 6:36 PM, Norman Ramsey <[EMAIL PROTECTED]> wrote:

>  > > But how do I use QuickCheck to check an existential?
>  >
>  > The "standard" method in QuickCheck is to be constructive, and
>  > actually implement the function that constructs for the value. So,
>  > instead of
>  >
>  >   forAll x . exists y . P(x,y)
>  >
>  > you write
>  >
>  >   forAll x . P(x, find_y(x))
>
>
> Interesting.  For A-E properties I can see where this approach would
> be helpful, especially if it's not too hard to think of a good skolem
> function.  In my case x is empty and so I'm left with
>
>  'find a y such that P(y)'
>
> or a bit more exactly
>
>  'find an x in the four-dimensional unit cube such that 0.9 < f(x)'
>
> I've already written f and I'd really rather not write f-inverse;
> I want the computer to do some of the work for me.  So perhaps
> SmallCheck would be a better way to go.
>
> It does seem a pity, as almost all the QuickCheck machinery would be
> useful in such a search.  On the other hand there are similar
> scenarios on which I've already given up in despair, such as writing a
> generator for creating well-typed terms in a nontrivial language.
>
> Anyway, thanks for suggesting a skolem function---I'm sure I'll find
> use for one sooner or later.
>
>
> Norman
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] string type class

[Edward Kmett]

I'd be more interested in a kitchen-sink "List" class. ByteString,
ByteString.Lazy, Text, [a], and the pending Text.Lazy all support the basic
operations of lists of a particular type. It'd be a fairly huge dictionary
by the current API design of those however. Its just a reiteration of the
classic "Collection" class example.

The biggest problem is that it requires either MPTCs/fundeps or type aliases
to make it work, which makes less progressive folks queasy about its
inclusion as a standard library.

On the other hand, if you're going that far, it'd be nice to factor out a
superclass or two for things like lookup/insert functionality, so you can
eliminate a major reason why Data.Map has to be imported qualified as well.

-Edward Kmett
On Fri, Mar 6, 2009 at 11:16 AM, minh thu  wrote:

> 2009/3/6 Wolfgang Jeltsch :
> > Am Freitag, 6. März 2009 13:33 schrieb Matthew Pocock:
> >> Hi,
> >>
> >> It seems every time I look at hackage there is yet another stringy
> >> datatype. For lots of apps, the particular stringy datatype you use
> matters
> >> for performance but not algorithmic reasons. Perhaps this is a good time
> >> for someone to propose a stringy class?
> >>
> >> Matthew
> >
> > There is already the class IsString which was introduced for overloaded
> string
> > literals.
> >
> > However, the name is terrible. No other Haskell class I know of has an
> “Is” at
> > its beginning. Classes don’t name properties (IsNum, IsMonoid, Has…).
>
> LLVM bindings use it a lot...
>
> Cheers,
> Thu
>  ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Re: [Haskell-cafe] ANNOUNCE: fad 1.0 -- Forward Automatic Differentiation library

[Edward Kmett]

Very nice to have!

FYI- there is at least one more quantification-based automatic
differentiation implementation in Hackage:

http://comonad.com/haskell/monoids/dist/doc/html/monoids/Data-Ring-Module-AutomaticDifferentiation.html

My implementation is/was focused upon use with monoids and other
more-limited-than-Num classes and only included the equivalent of your
'lift' and 'diffUU' operations, however.

-Edward Kmett

On Thu, Apr 2, 2009 at 10:28 PM, Bjorn Buckwalter <
bjorn.buckwal...@gmail.com> wrote:

> I'm pleased to announce the initial release of the Haskell fad
> library, developed by Barak A. Pearlmutter and Jeffrey Mark Siskind.
> Fad provides Forward Automatic Differentiation (AD) for functions
> polymorphic over instances of 'Num'. There have been many Haskell
> implementations of forward AD, with varying levels of completeness,
> published in papers and blog posts[1], but alarmingly few of these
> have made it into hackage -- to date Conal Elliot's vector-spaces[2]
> package is the only one I am aware of.
>
> Fad is an attempt to make as comprehensive and usable a forward AD
> package as is possible in Haskell. However, correctness is given
> priority over ease of use, and this is in my opinion the defining
> quality of fad. Specifically, Fad leverages Haskell's expressive
> type system to tackle the problem of _perturbation confusion_,
> brought to light in Pearlmutter and Siskind's 2005 paper "Perturbation
> Confusion and Referential Transparency"[3]. Fad prevents perturbation
> confusion by employing type-level "branding" as proposed by myself
> in a 2007 post to haskell-cafe[4]. To the best of our knowledge all
> other forward AD implementations in Haskell are susceptible to
> perturbation confusion.
>
> As this library has been in the works for quite some time it is
> worth noting that it hasn't benefited from Conal's ground-breaking
> work[5] in the area. Once we wrap our heads around his beautiful
> constructs perhaps we'll be able to borrow some tricks from him.
>
> As mentioned already, fad was developed primarily by Barak A.
> Pearlmutter and Jeffrey Mark Siskind. My own contribution has been
> providing Haskell infrastructure support and wrapping up loose ends
> in order to get the library into a releasable state. Many thanks
> to Barak and Jeffrey for permitting me to release fad under the BSD
> license.
>
> Fad resides on GitHub[6] and hackage[7] and is only a "cabal install
> fad" away! What follows is Fad's README, refer to the haddocks for
> detailed documentation.
>
> Thanks,
> Bjorn Buckwalter
>
>
> [1] http://www.haskell.org/haskellwiki/Functional_differentiation
> [2] http://www.haskell.org/haskellwiki/Vector-space
> [3]:  http://www.bcl.hamilton.ie/~qobi/nesting/papers/ifl2005.pdf
> [4]: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/22308/
> [5]: http://conal.net/papers/beautiful-differentiation/
> [6] http://github.com/bjornbm/fad/
> [7] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fad
>
>
> 
>
>   Copyright  : 2008-2009, Barak A. Pearlmutter and Jeffrey Mark Siskind
>   License: BSD3
>
>   Maintainer : bjorn.buckwal...@gmail.com
>   Stability  : experimental
>   Portability: GHC only?
>
> Forward Automatic Differentiation via overloading to perform
> nonstandard interpretation that replaces original numeric type with
> corresponding generalized dual number type.
>
> Each invocation of the differentiation function introduces a
> distinct perturbation, which requires a distinct dual number type.
> In order to prevent these from being confused, tagging, called
> branding in the Haskell community, is used.  This seems to prevent
> perturbation confusion, although it would be nice to have an actual
> proof of this.  The technique does require adding invocations of
> lift at appropriate places when nesting is present.
>
> For more information on perturbation confusion and the solution
> employed in this library see:
> <http://www.bcl.hamilton.ie/~barak/papers/ifl2005.pdf>
> <http://thread.gmane.org/gmane.comp.lang.haskell.cafe/22308/>
>
>
> Installation
> 
> To install:
>cabal install
>
> Or:
>runhaskell Setup.lhs configure
>runhaskell Setup.lhs build
>runhaskell Setup.lhs install
>
>
> Examples
> 
> Define an example function 'f':
>
> > import Numeric.FAD
> > f x = 6 - 5 * x + x ^ 2  -- Our example function
>
> Basic usage of the differentiation operator:
>
> > y   = f 2  -- f(2) = 0
> > y'  = di

[Haskell] Re: [Haskell-cafe] ANNOUNCE: fad 1.0 -- Forward Automatic Differentiation library

[Edward Kmett]

A somewhat tricky concern is that that the extra functionality in question
depends on a bunch of primitive definitions that lie below this in the
package and the AD engine is used by a layer on top.

So moving it out would introduce a circular dependency back into the package
or require me to stratify into two packages.  When I looked into
partitioning the package for another reason I found that I couldn't do so
without introducing some orphan instances, so it'll probably be a tricky bit
of surgery to split out. That said, it's probably still worth doing.

I also agree that I should be somewhat more pedantic about the name. =)
-Edward Kmett

On Fri, Apr 3, 2009 at 10:49 AM, Barak A. Pearlmutter wrote:

> I feel silly, did not even notice that!  Thanks for the pointer.
>
> Would be sensible to merge the functionalities; will try to import
> functionality in Data.Ring.Module.AutomaticDifferentiation currently
> missing from Numeric.FAD.
>
> (One pedantic note: should really be named
> Data.Ring.Module.AutomaticDifferentiation.Forward, since it is doing
> forward-mode accumulation automatic differentiation; reverse is
> an adjoint kettle of fish.)
> --
> Barak A. Pearlmutter
>  Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
>   http://www.bcl.hamilton.ie/~barak/
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] deriving Show for GADT?

[Edward Kmett]

I seem to recall Matt Morrow having some code lying around for automatically
generating such instances using haskell-src-exts. I wonder how hard it would
be to adapt to Template Haskell.
-Edward Kmett


On Tue, Apr 14, 2009 at 2:03 AM, Ryan Ingram  wrote:

> You might be able to write some Template Haskell to derive the Show
> instance.
>
> It's a bit tricky, because there are some types which can't have Show
> derived, such as:
>
> data Foo where
>Broken :: a -> Foo
>
> What should
>show (Broken id)
> do?
>
>  -- ryan
>
> On Mon, Apr 13, 2009 at 9:28 PM, Norman Ramsey  wrote:
> > I've got a fairly large GADT for which I wished to use
> >   deriving (Show)
> > but I got a mysterious error message:
> >
> > Exp.hs:13:11:
> >Can't make a derived instance of `Show (Exp a)'
> >  (`Exp' has non-Haskell-98 constructor(s))
> >In the data type declaration for `Exp'
> >
> >
> > This is from GHC.  Does anybody know a compiler option or other trick
> > that will coax the compiler into producing a Show instance.
> > (I know I can write one by hand, but I'd rather not bother.)
> >
> >
> > Norman
> > ___
> > Haskell mailing list
> > Haskell@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell
> >
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] memory management

[Edward Kmett]

Meacham's JHC was headed towards region inference for a while (and may still
be), and I spent some time trying to use region inference in a research
compiler of my own, and I think both projects effectively came to that same
conclusion -- regions and laziness don't mix. Finding useful regions in a
lazy language is hard.

You can't effectively annotate them in the source due to laziness decoupling
object lifetimes from that of your source stack frames, so you need to infer
them once you've translated into some strict intermediate representation,
and the regions you can infer are finicky and brittle at best. Region-based
code optimization in ML tends to center around identifying which region is
leaking and why, and without any sort of source code tie for the region
system, that becomes a seriously black box. Thunks tend to hold onto lots of
context, so minor source changes yield vastly different region profiles.
Finally, all of the effort is called into question by the fact that regions
alone can't even handle a lot of interesting cases, so you need a collector
to boot.

Tofte et al. wrote a retrospective at some point basically talking about the
now-known limitations of region based memory management [
http://portal.acm.org/citation.cfm?id=993040 , pre-print:
http://www.elsman.com/retro.pdf], which I think has the right balance of
optimism and pragmatism where it comes to region-based memory management and
talks about many of these issues.

-Edward Kmett


On Thu, Aug 6, 2009 at 3:22 AM, Simon Peyton-Jones wrote:

> Also region inference is likely to be much less effective in a lazy
> language, because (I think that) data escapes the lifetime of its allocating
> procedure much more often.  I don't know of any work that has even tried it.
>
> Simon
>
> | -Original Message-
> | From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org]
> On
> | Behalf Of Simon Marlow
> | Sent: 04 August 2009 14:50
> | To: Sam Martin
> | Cc: Colin Runciman; Haskell@haskell.org
> | Subject: Re: [Haskell] memory management
> |
> | On 04/08/2009 13:33, Sam Martin wrote:
> | >> Sounds like region inference to me.
> | >> (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference)
> | >
> | > Thanks, yes, that's exactly what I had in mind.
> | >
> | > Is anything like this is done in GHC?
> |
> | Not at the moment, no.
> |
> | Bear in mind that with generational GC, allocating memory that quickly
> | becomes garbage is quite cheap.
> |
> | Cheers,
> |   Simon
> | ___
> | Haskell mailing list
> | Haskell@haskell.org
> | http://www.haskell.org/mailman/listinfo/haskell
>
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Re: [Haskell-cafe] Work on Video Games in Haskell

[Edward Kmett]

On Wed, May 26, 2010 at 5:51 AM, Ryan Trinkle
wrote:

> Hi guys,
>
> I don't think this licensing issue will be a problem for us.  It's not
> clear to me that our game violates this new term, and we certainly don't
> violate any of the principles Steve Jobs used to justify it.  If Apple wants
> to reject our app, they already have a variety of excuses at their disposal,
> as they've demonstrated on many occasions.  Frankly, it'd be their loss;
> Android is now the fastest-growing smartphone market, and we'll be more than
> happy to focus on it (and other friendlier markets) if Apple's not
> interested in having our product on their platform.
>

Steve Jobs has been quite clear that apps written in other languages, even
ones that are interpreted in, compiles down to or otherwise generate
objective c source code, don't comply with the changes in section 3.3.1 of
their license, so I'm not sure that you have much of a case.

> “We’ve been there before, and intermediate layers between the platform and
> the developer ultimately produces sub-standard apps and hinders the progress
> of the platform.”
>
Read more:
http://techcrunch.com/2010/04/10/steve-jobs-responds-to-iphone-sdk-complaints-intermediate-layers-produce-sub-standard-apps/#ixzz0p3gfoNZI

Haskell definitely qualifies as an 'intermediate layer', just like
MonoTouch, and just like the Flash-to-Objective-C compiler that provoked the
original response from Apple.

http://www.taoeffect.com/blog/2010/04/steve-jobs-response-a-brief-followup/

Heck, even libraries that may contain scripting and modeling utilities like
Unity3d are in jeopardy, due to this cockamamie restriction, which threatens
to send the art of level design and game programming for the iphone
technologically clear back into the early 90s, though at least there they
appear to be treading lightly, since Unity has been useful in providing the
iphone with a lot of high end content.

http://answers.unity3d.com/questions/7408/is-unity3d-banned-by-new-apple-sdk-licence

But, there are other numerous discussions floating around in the blogosphere
involving previously approved applications written in scheme (even compiled
via objective c), c#, or other middleware languages having their
applications removed from the app store.

So, sadly, I think your chances of shipping your a title written in Haskell
on the iPhone are shot to hell.

-Edward Kmett
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: incremental-parser library package

[Edward Kmett]

2011/3/22 Mario Blažević 

>
>  This seems very interesting. One question:
>>
>> > The MonadPlus and the Alternative instance differ: the former's mplus
>> > combinator equals the asymmetric <<|> choice.
>>
>> Why?
>>
>
>
> Good question. Basically, I see MonadPlus as a union of Monad and
> Alternative. The class should not exist at all. But as long as it does, I
> figured I should provide an instance, and I made it different from the
> Monoid+Alternative combination because otherwise it would be useless. My
> second choice would be to remove the instance completely.
>

I have to admit I really do not like having Applicative and MonadPlus with
different behavior. Yes, one is redundant, but that is more an artifact of
language evolution, than an intentional opportunity for diverging behavior.

Every library I am aware of to date, save of course this one, has maintained
their compatibility.

If the instance for Alternative satisfies the underspecified MonadPlus laws,
I'd just as soon have the 'useless redundant' instance. The power of
MonadPlus is in the combinators that are built on top of it. Not in the
primitives themselves.

If the Alternative instance would not be a legal MonadPlus instance, then
I'd feel much less queasy with your second scenario, and it simply removed.

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

[Haskell] ANNNOUNCE: lens 3.7 released

[Edward Kmett]

Greetings!

I am happy to announce the release of version 3.7 of the lens package,
which provides "Lenses, Folds, and Traversals" for working with arbitrary
data types.

In its simplest form, a lens is a getter/setter pair, that can be composed
and reasoned about with common sense laws that you can also derive from the
Functor and Traversable laws you already know or even derive by reasoning
in terms of comonad coalgebras for the even more theoretically inclined.

The lens package provides lenses along with a surprisingly powerful set of
generalizations and specializations of this idea, in a manner that subsumes
the notion of a "semantic editor combinator", allowing you to enrich them
with the ability to read back from the targets. In the form taken by the
lenses in this package, lenses are empowered to safely change the types of
the fields that they edit in a manner that not only can you still reason
about, but where the changes in types helps you to reason about what they
can or cannot do.

One of the major design goals of lens has been that you should be able to
pick up lens combinators and apply them meaningfully to a mishmash of
lenses, traversals, isomorphisms, getters, and setters, etc. even without
fully understanding all of the types. This encourages active exploration
and users who are pleasantly surprised rather than frustrated and angry. To
this end we've actively stocked the haddocks for the project with types it
may be easier to think about each combinator as having, which can serve as
training wheels that will help you make your way around.

Most interestingly from a package maintainer perspective, unlike previous
packages that provided lenses, it is possible to provide lenses (and
traversals) that are compatible with the lens library without incurring any
dependency for your package at all. For instance the simplest Traversal is
traverse from Data.Traversable. traverse . traverse is also a valid
Traversal, and it can be composed with other lenses and traversals without
any casting or coercion.

A large number of combinators are provided that automatically 'do the right
thing' when presented with the various generalizations and specializations
of the concept of a lens, e.g. when supplied a Traversal instead of a Lens,
a combinator that returned a result based on the target of the Lens, may
now return a monoidal summary of all of the results targered by the
Traversal.

Major Features:

* Lenses, getters, setters, isomorphisms, folds, "prisms", monadic actions,
and indexed versions of these constructions that can all be composed with
(.) from the Prelude in a manner that they read quite naturally to an
imperative programmer who expects (.) to be field access and to compose in
the 'wrong' direction, while still retaining the ability to reason about
the resulting code.

* Type-safe zippers into arbitrary user data structures, where you can move
down into a lens or laterally through a traversal and can come back up,
following a breadcrumb trail in the type.

* Lens contains a generalized version of Neil Mitchell's uniplate in such a
way that the uniplate combinators themselves that many people already know
how to use can be used on an arbitrary traversal, and uniplate/biplate
simply act as a Traversal, and are often ~35% or more faster than the
original.

* Lens comes "batteries included" with classes and combinators for working
with many common libraries that fall within the Haskell Platform. No
dependencies are incurred that fall outside of the platform, unless those
dependencies are needed to implement lens itself.

* We provide configurable template-haskell generators for producing lenses,
isomorphisms and traversals for your own data types.

New in this release:

* Prisms are categorically dual to Lenses and provide a form of first class
pattern. They can be used directly as a Traversal. Many operations that
formerly required an isomorphism can be used directly on a Prism, and every
Isomorphism can be used as a Prism.

* With this latest release we've incorporated a large amount of community
feedback into the API design and have vastly expanded the documentation
with hundreds of additional examples and test cases.

* We've renamed a number of operations to reduce naming conflicts with
third party libraries to a minimum, and improve consistency. in particular
we no longer conflict with Control.Arrow.

* We've overhauled the zipper API to permit easier use of multiple
simultaneous zippers, and to make zipper movements more compositional.

Resources:

* Wiki : We have a
FAQ,
which includes a number of links to source material, a quick
getting-started guide,
a discussion of the Derivation,
and even a UML diagram  distributed
among the other content of the wiki. If you find something missi

Re: [Haskell] ANNNOUNCE: lens 3.7 released

[Edward Kmett]

On Sun, Dec 9, 2012 at 10:14 PM, Ashley Yakeley  wrote:

> On 07/12/12 02:19, Edward Kmett wrote:
>
>  I am happy to announce the release of version 3.7 of the lens package,
>> which provides "Lenses, Folds, and Traversals" for working with
>> arbitrary data types.
>>
>
> Do you use types to index the fields of tuples? It's a good general
> mechanism to represent the "tupleness" of certain types. I had a quick look
> and it didn't seem you were doing this.
>
> For instance, consider this type:
>
>  data P = MkP Int Bool Char




> There are classes for Field1..Field9 used for the combinators _1.._9.


If you wanted to make instances of them for your type. You could very well
do

instance Field1 P P Int Int where
...
instance Field3 P P Char Char where
  _3 f (P a b c) = P a b <$> f c

This lets you use the positional field accessors for monomorphic or
polymorphic types, that may or may not allow field types to change.

If one wants to consider the three fields as separate items, one can
> construct a type that's an index to them:
>  data PInd :: * -> * where
>PFirst :: PInd Int
>PSecond :: PInd Bool
>PThird :: PInd Char
> It's then straightforward to construct an isomorphism between P and
> "forall a. PInd a -> a". You can also use it to build lenses for the
> fields, etc.
>

Er, I rather misinterpreted above, (I'll keep it in this reply just in case
it is handy for someone else.)

We do have something rather more limited available, which is that
Control.Lens.Representable let you implement corepresentable endofunctors
in terms of their polymorphic lenses.

e.g.

import Control.Lens

data V2 a = V2 { __x, __y :: a }
makeLenses ''V2

instance Representable V2 where
  tabulate f = V2 (f _x) (f _y)

then you can get a number of instances for free

instance Monad V2 where
  return = pureRep
  (>>=) = bindRep

instance Applicative V2 where
  pure = pureRep
  ap = apRep

instance Functor V2 where
  fmap = fmapRep

etc...

However, the form of representation we use are lenses into the structure
instead of  a GADT like index type. This currently limits us to handling
functors.

This is used to good effect in the 'linear' package, which uses
representable functors for all of its vector spaces. This works because, at
least classically, all vector spaces are free vector spaces, and those are
isomorphic to a function from a basis, so we can use a representable
functor with a representation equivalent to that basis as a way to memoize
the vector space.

Since it gets comparatively little use relative to the rest of the API and
now that the rest of lens has matured around it, it feels somewhat
different than the rest of lens, we may want to split this part off into a
separate package eventually.

That said, even if we were to add the extra GADT-like index guiding
tabulate, it could only do product-like constructions.

If you use IRC, the #haskell-lens channel on freenode would be a good place
to dive into this deeper.

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

Re: [Haskell] Google Summer of Code | Haskell.org

[Edward Kmett]

That is the plan.

We won't know officially until Google gets back to us about our org
application in a couple of weeks.

-Edward


On Mon, Feb 10, 2014 at 8:08 AM, Narendra Joshi wrote:

> Hi there!
> Is haskell.org participating in this year's GSoC?
> -- narendra
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] CUFP 2014: Call for Presentations

[Edward Kmett]

Commercial Users of Functional Programming 2014: Call for Presentations

   COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING 2014
  CUFP 2014
   http://cufp.org/conference
CALL FOR PRESENTATIONS
   Gothenburg, Sweden
   Sep 4-6
  Co-located with ICFP 2014
 Sponsored by SIGPLAN
Talk Proposal Submission Deadline 27 June 2014
Submission Form: http://goo.gl/5BJLul

The annual CUFP workshop is a place where people can see how others
are using functional programming to solve real world problems; where
practitioners meet and collaborate; where language designers and users
can share ideas about the future of their favorite language; and where
one can learn practical techniques and approaches for putting
functional programming to work.

Giving a CUFP Talk
==

If you have experience using functional languages in a practical
setting, we invite you to submit a proposal to give a talk at the
workshop. We're looking for two kinds of talks:

Experience reports are typically 25 minutes long, and aim to inform
participants about how functional programming plays out in real-world
applications, focusing especially on lessons learned and insights
gained. Experience reports don't need to be highly technical;
reflections on the commercial, management, or software engineering
aspects are, if anything, more important.

Technical talks are also 25 minutes long, and should focus on teaching
the audience something about a particular technique or methodology,
from the point of view of someone who has seen it play out in
practice. These talks could cover anything from techniques for
building functional concurrent applications, to managing dynamic
reconfigurations, to design recipes for using types effectively in
large-scale applications. While these talks will often be based on a
particular language, they should be accessible to a broad range of
programmers.

We strongly encourage submissions from people in communities that are
underrepresented in functional programming, including but not limited
to women; people of color; people in gender, sexual and romantic
minorities; people with disabilities; people residing in Asia, Africa,
or Latin America; and people who have never presented at a conference
before. We recognize that inclusion is an important part of our mission
to promote functional programming. So that CUFP can be a safe
environment in which participants openly exchange ideas, we abide by
the SIGPLAN Conference Anti-Harassment Policy
( http://www.sigplan.org/Resources/Policies/Anti-harassment ).

If you are interested in offering a talk, or nominating someone to do
so, please submit your presentation before 27 June 2014 via the form at

http://goo.gl/5BJLul

You do not need to submit a paper, just a short proposal for
your talk! There will be a short scribe's report of the presentations and
discussions but not of the details of individual talks, as the meeting
is intended to be more a discussion forum than a technical
interchange.

Nevertheless, presentations will be video taped and
presenters will be expected to sign an ACM copyright release
form.

Note that we will need all presenters to register for the
CUFP workshop and travel to Gothenburg at their own expense.

Program Committee
=====

    Edward Kmett (McGraw Hill Financial), co-chair
Marius Eriksen (Twitter, Inc.), co-chair
Ozgun Ataman (Soostone, Inc.)
Tim Chevalier (AlephCloud)
Derek Elkins (Now Business Intelligence)
Matthew Might (University of Utah)
Richard Minerich (Bayard Rock)
Audrey Tang (Apple, Inc.)
Jason Zaugg (Typesafe)

More information


For more information on CUFP, including videos of presentations from
previous years, take a look at the CUFP website at
http://cufp.org. Note that presenters, like other attendees, will need
to register for the event. Acceptance and rejection letters will be sent
out by July 16th.

Guidance on giving a great CUFP talk


Focus on the interesting bits: Think about what will distinguish your
talk, and what will engage the audience, and focus there. There are a
number of places to look for those interesting bits.

Setting: FP is pretty well established in some areas, including
formal verification, financial processing and server-side
web-services. An unusual setting can be a source of interest. If
you're deploying FP-based mobile UIs or building servers on oil
rigs, then the challenges of that scenario are worth focusing
on. Did FP help or hinder in adapting to the setting?

Technology: The CUFP audience is hungry to learn about how FP
techniques work in practice. What design patterns have you
applied, and to what areas? Did you use functional reactive
programming for user interfaces, or DSLs for playing chess, or
fault-tolerant actors for large scale geological data proc

[Haskell] [Haskell.org GSoC] Accepted Proposals

[Edward Kmett]

I'm pleased to announce the list of accepted student proposals for
haskell.org for the Google Summer of Code 2014.

   Title Student Mentor  Adding profiling support to GHCJS -- JavaScript
backend for GHC Ömer Sinan Aǧacan Luite Stegeman  Concurrent Lock-Free Hash
Map for Haskell Mathias Bartl Ryan Newton  Darcs: Hashed Files and Cache Marcio
Díaz Eric Kow  HDBC Improvements Edisach Nicolas Wu  Darcs: History
reordering: performance and features Ale Gadea Guillaume Hoffmann  Implement
Constraint-Based Layout in Diagrams Allan Gardner Daniel Bergey  Lensify
Diagrams Niklas Haas Brent Yorgey  An Efficient Computational Algebra and
Symbolic Linear Algebra Library in Haskell Hiromi ISHII Edward Kmett  Complete
plugins-ng "low-level", "filewatch", and "cabal" packages Kẏra Greg
Weber  Build
Interactive Websites with GHCJS and Sodium Kyle Raftogianis Luite
Stegeman  Pandoc
improvements: Embedded base64 images and EPUB 3.0 reader Matthew Pickering John
MacFarlane  Agda-like Interaction Mode for Emacs Alejandro Serrano David
Raymond Christiansen  Debugging tool for GHCJS Nathan van Doorn Luite
Stegeman  Flesh out features of Hackage 2 Chris Wong Duncan Coutts
You can explore the abstracts of the accepted proposals at

http://www.google-melange.com/gsoc/org2/google/gsoc2014/haskell

I would like to take a moment to offer congratulations to all of the
students we were able to accept into the program this year.

That said, I would also like to offer my condolences to those students whom
we were not able to bring into the program. We received 14 slots in total
this year - more than we ever received in past years - yet still not nearly
enough to accept all of the excellent proposals we received this time
around. Please consider applying again next year.

I am looking forward to working with you on another Summer of Code, and I
hope we can all make an effort as a community to be welcoming and to help
you in your projects.

If you have any questions or concerns about the process, please feel free
to email me or chase me down on #haskell-gsoc on irc.freenode.net.

-Edward Kmett
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] [Haskell.org GSoC] Accepted Proposals

[Edward Kmett]

The abstracts get published publicly.

The details of the proposal milestones are only displayed to the pool of
mentors though.

This is what Melange does by default. However, I'm not sure what Google's
official policy is on revealing more information.

Often by the end of the proposal process the project the student has
ultimately agreed to bears little resemblance to their original proposal,
so I'm not sure it'd be a good idea to show the original submissions in
their full glory, even if we had the option.

-Edward


On Mon, Apr 21, 2014 at 9:56 PM, Conrad Parker  wrote:

> Hi,
>
> are there long descriptions somewhere? the trac page linked from melange
> seems to have not been updated since 2012:
>
> https://ghc.haskell.org/trac/summer-of-code/report/1
>
> I'd be interested to see the milestones and expected outcomes for some of
> the projects :)
>
> Conrad.
>
> On 22 April 2014 06:56, Edward Kmett  wrote:
>
>> I'm pleased to announce the list of accepted student proposals for
>> haskell.org for the Google Summer of Code 2014.
>>
>>Title Student Mentor  Adding profiling support to GHCJS -- JavaScript
>> backend for GHC Ömer Sinan Aǧacan Luite Stegeman  Concurrent Lock-Free
>> Hash Map for Haskell Mathias Bartl Ryan Newton  Darcs: Hashed Files and
>> Cache Marcio Díaz Eric Kow  HDBC Improvements Edisach Nicolas Wu  Darcs:
>> History reordering: performance and features Ale Gadea Guillaume Hoffmann  
>> Implement
>> Constraint-Based Layout in Diagrams Allan Gardner Daniel Bergey  Lensify
>> Diagrams Niklas Haas Brent Yorgey  An Efficient Computational Algebra
>> and Symbolic Linear Algebra Library in Haskell Hiromi ISHII Edward Kmett  
>> Complete
>> plugins-ng "low-level", "filewatch", and "cabal" packages Kẏra Greg Weber  
>> Build
>> Interactive Websites with GHCJS and Sodium Kyle Raftogianis Luite
>> Stegeman  Pandoc improvements: Embedded base64 images and EPUB 3.0 reader 
>> Matthew
>> Pickering John MacFarlane  Agda-like Interaction Mode for Emacs Alejandro
>> Serrano David Raymond Christiansen  Debugging tool for GHCJS Nathan van
>> Doorn Luite Stegeman  Flesh out features of Hackage 2 Chris Wong Duncan
>> Coutts
>> You can explore the abstracts of the accepted proposals at
>>
>> http://www.google-melange.com/gsoc/org2/google/gsoc2014/haskell
>>
>> I would like to take a moment to offer congratulations to all of the
>> students we were able to accept into the program this year.
>>
>> That said, I would also like to offer my condolences to those students
>> whom we were not able to bring into the program. We received 14 slots in
>> total this year - more than we ever received in past years - yet still not
>> nearly enough to accept all of the excellent proposals we received this
>> time around. Please consider applying again next year.
>>
>> I am looking forward to working with you on another Summer of Code, and I
>> hope we can all make an effort as a community to be welcoming and to help
>> you in your projects.
>>
>> If you have any questions or concerns about the process, please feel free
>> to email me or chase me down on #haskell-gsoc on irc.freenode.net.
>>
>> -Edward Kmett
>>
>> ___
>> Haskell mailing list
>> Haskell@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell
>>
>>
>
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Core libraries committee seeking self-nominations

[Edward Kmett]

The first year of the Haskell Core Libraries Committee
<http://www.haskell.org/haskellwiki/Core_Libraries_Committee> is winding
down, and we are seeking self-nominations to replace two outgoing committee
members.

Doug Beardsley and Brent Yorgey have offered to be the first two members of
the committee to have their slots come up for renewal.

To nominate yourself, please send an email to
core-libraries-commit...@haskell.org by June 30th and include any
information that you think will help us reach a decision.

The core libraries committee acts as the collective maintainer of many
packages that glue together the Haskell Platform, but which otherwise do
not have an individual maintainer. See Library Submissions
<http://www.haskell.org/haskellwiki/Library_submissions> for more details
about which packages fall to the committee for maintenance.

As we are now talking on more of the implementation effort for the
Applicative-Monad Proposal, bringing Foldable and Traversable into Prelude,
performing active maintenance on vector, etc., you should be forewarned
that these are becoming increasingly active positions now that GHC 7.8 has
shipped and we are ramping up for more active participation in the GHC
release process.

Regards,
Edward Kmett
Haskell Core Libraries Committee Chair
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] CUFP 2014: Call For Participation

[Edward Kmett]

**


CALL FOR PARTICIPATION


Commercial Users of Functional Programming (CUFP) 2014 at ICFP 2014;

Gothenburg, Sweden, Sep 4-6.


**


Overview




Functional programming has been at the forefront of a new generation

of programming technologies: Companies employing functional

programming use it to enable more effective, robust, and flexible

software development.


The annual CUFP workshop is designed to serve the growing community of

commercial users of functional programming: Practitioners meet and

collaborate; language designers and users can share ideas about the

future of their languages; experts share their expertise on practical

functional programming.


CUFP 2014 begins with two days of tutorials by top-notch

language experts including advanced tutorials on special topics,

followed by a day of talks about industrial applications of

functional programming.


More information about CUFP 2014 is available on the CUFP web site at


http://cufp.org/2014/


Registration is available at:


https://regmaster4.com/2014conf/ICFP14/register.php


TUTORIALS, SEPTEMBER 4

==


T1: Programming with Dependent Types

Ulf Norell


T2: Haskell in the Real World

Stefan Wehr


T3: Intro to Elm: a field guide for functional front-end programming (Part
1)

Evan Czaplicki & Spiros Eliopoulos


T4: Elm-d3: Front-end Development without Frameworks (Part 2)

Spiros Eliopoulos


T5: Idris: Practical Software Verification with Dependent Types

Edwin Brady


T6: Lens

Edward Kmett


TUTORIALS, SEPTEMBER 5

==


T7: Introduction to OCaml

Leo White & Jeremy Yallop


T8: Programming in Rust

Felix Klock & Lars Bergstrom


T9: Tinkering with the Raspberry Pi using Erlang

Torben Hoffmann


T10: Hands-on Functional Web Development in F# with WebSharper

Adam Granicz


T11: Batteries Included: Generative Programming with Scala and LMS

Tiark Rompf & Nada Amin


T12: Introduction to testing with QuickCheck

John Hughes


TALKS, SEPTEMBER 6

==


Keynote: Making Money From FP

Joe Armstrong, Ericsson and Royal Institute of Technology in Stockholm


Functional Programming at Verizon OnCue

Timothy Perrett, Verizon


Adopting Functional Programming with OCaml at Bloomberg LP

Maxime Ransan, Bloomberg LP


MBrace: large-scale programming in F#

Eirik Tsarpalis, Nessos


Probabilistic Synchronization of State Between Independent Nodes

Erlend Hamberg


Towards "annex", a Fact Based Dependency System

Mark Hibberd


Building data and time-series analytics tools for F#

Tomas Petricek & Howard Mansell


Haskell in the Misson Control Domain

Michael Oswald


Haskell tools for satellite operations

Björn Buckwalter


F# For Fun and Games

Anthony Brown


Some usages of functional programming for FO and quants

Renaud Bechade


Reactive I/O with Scala, Akka, and Play

Kenneth Owens, Comcast


If your server is a function, is your company a library?

Andrew Cowie
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] [haskell.org Google Summer of Code] Call for Mentors

[Edward Kmett]

We have had a rather large pool of potential students apply for this year's
Google Summer of Code, but, ultimately, Google won't let us ask for a slot
unless we have a potential mentor assigned in advance.

On top of that, one thing we try to do with each project is wherever
possible, assign both a primary and a backup mentor, so the available
mentoring pool is drawn a little thin. Many hands make for light work,
though: If you've mentored or thought about mentoring in years past, I'd
encourage you to sign up on google-melange for the Google Summer of Code at:

https://www.google-melange.com/gsoc/homepage/google/gsoc2015

and request a connection to haskell.org as a Mentor.

Once you've done this you can help us vote on proposals, and should
something seem appropriate to you, you can flag yourself as available as a
potential mentor or backup mentor for one (or more) of the projects.

We have a couple of weeks left to rate proposals and request slots, but
it'd be good to make as much progress as we can this week.

If you have any questions, feel free to reach out to me, or to Shachaf
Ben-Kiki or Gershom Bazerman who have been helping out with organizational
issues this year. We also have a #haskell-gsoc channel on irc.freenode.net
if you have questions about what is involved.

Thank you for your time and consideration,
-Edward Kmett
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] [haskell.org Google Summer of Code] 18 Projects Accepted

[Edward Kmett]

I'd like to thank everyone for helping us to get the largest Google Summer
of Code we've ever had for haskell.org off the ground! We have 18 accepted
projects this year, spanning the entire ecosystem. You can find the
official list on:

https://www.google-melange.com/gsoc/org2/google/gsoc2015/haskell

The most notable change this year is that in addition to the usual stable
full of cabal tweaks (3 projects this year), and other infrastructure and
library changes and the odd darcs project here and there (1 project), we
also took it upon ourselves to act as an umbrella organization for
purescript (2 projects). *

I'd like to thank Johan Tibell for helping us get our ideas organized, and
the /r/haskell moderators for leaving the brainstorming page "stickied" for
the duration. It rather dramatically improved both the quantity and the
quality of proposals we received.

After I put out a call for additional mentoring help, we had 44 mentors
step up to offer to help this time around, showing that we still have
capacity to grow in years to come. Thank you all for putting in the time to
help rank proposals and for your continued efforts over this summer.

I'd also like to thank Shachaf Ben-Kiki and Gershom Bazerman for helping
out with the administration side of things.

Now we are entering what Google calls the "Community Bonding" period.
Students officially start coding May 25th.

Please feel free to reach out to me if you have any questions or concerns.

-Edward Kmett
haskell.org Google Summer of Code Administrator

* Purescript and Darcs proposals went into the same pool as everyone else
this year without earmarking.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] Haskell Summer of Code

[Edward Kmett]

I'm sorry to announce that this year haskell.org was not accepted for the
2016 Google Summer of Code.

There has been a lot of turnover over the last 3 years as they have rotated
in and out new organizations, including many that have been in the program
as long as us, so while this isn't entirely unexpected, it is
disheartening. As this comes on the tail of our most successful year in the
program, the news was particularly devastating to all involved.

We do not expect this to be a permanent condition. Many organizations
rotate back in and out of the Summer of Code each year.

Operationally, this raises two main concerns:

The first is that there will be a rather sharp dip in income for the next
year for haskell.org. Last year's GSoC accounted for $9500 worth of income
towards managing servers and the like, but we will not receive such a
booster shot this year.

The second is that we absolutely do not want the infrastructure we have in
place around the Summer of Code to fall away. We had 50 mentors register
last year!

To address both of these concerns, we are exploring running our own
self-funded *Haskell Summer of Code *this year*. *In December, we
incorporated haskell.org as a 501(c)(3) non-profit. This now enables us to
pay for work directly. We should be able to fund at least one slot out of
pocket from existing haskell.org funds and fund additional slots with
donations.

https://wiki.haskell.org/Donate_to_Haskell.org

More information will be forthcoming as we work out the details.

Please feel free to contact me if you think you can help or if you have any
questions or concerns.

-Edward Kmett
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] Summer of Haskell Mentors

[Edward Kmett]

If you are interesting in helping out as a possible mentor for this
year's Summer of Haskell, please email me, and include MENTOR in the
title.

Thank you!
-Edward
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] LiftA2 over fmap

[Edward Kmett]

> In particular, if fmap

 is an expensive operation, it is likely better to use liftA2

 than to (fmap

 over the structure *and then use <*>
)*
. (emphasis and parens added).

Consider any data constructor that has a strict spine and look at

f <$> m <*> n

This has to walk `m` twice. Once for the fmap on the first argument, and
once for the <*>, but the liftA2 version can walk `m` once fusing things
together.

-Edward

On Tue, Jan 30, 2018 at 4:42 AM, Damien BIHEL  wrote:

> In the documentation here
> 
> it's written that for some functors liftA2 has better performance than
> fmap. Does anyone have any examples ?
>
> Regards,
>
> --
> Damien Bihel
> R&D (Research & Development) Engineer at ELRA (European Language Resources
> Association)
> E-Mail: biheldam...@gmail.com
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
>
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell