Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Gregory Crosswhite]

On Dec 19, 2011, at 4:45 PM, Gregory Crosswhite wrote:

> First, there needs to be lots of [STRUCTURE] that makes it easy for people to 
> skim through and pick out the specific information that they want to find out 
> about [...]

Grr!  I have no idea why that word got dropped out, since it was kinda 
important... writing too many words at once puts my brain in a fog.  :-)

Also, just to clarify I don't necessarily mean structure as in explicit 
headlines so much as any kind of structure --- including implicit structure 
from paragraph breaks and careful choice of presentation and ordering --- that 
makes it easy to pick up on how a text is broken into logical parts, what each 
part is roughly about, and how the parts are related.

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

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Gregory Crosswhite]

On Dec 19, 2011, at 3:49 PM, Richard O'Keefe wrote:

> On 19/12/2011, at 5:46 PM, Gregory Crosswhite wrote:
> [improved Monoid documentation]

Thank you.  :-)


> I would go so far as to point out that "mappend is a generalisation of
> Data.List.sum, Data.List.product, Data.List.and, and Data.List.or,
> where the initial value and combining rule are implied by the type.

Inspired by the idea behind your suggestion, I modified the documentation as 
follows:



The Monoid typeclass provides a standard interface for specifying how pairs of 
values of a given type can be combined to form new values of that type, as well 
as an identity value for that type that when combined with any value x produces 
x.  The Monoid class typically appears in higher-order functions that produce a 
list of values that need to be summarized into a single result, such as in 
Data.Foldable.foldMap function or the Writer monad.

Formally, an instance of Monoid provides a binary associative operator with an 
identity element;  to do this one must specify (at a minimum) the methods 
mempty and mappend such that they obey following properties:

(*) mempty is the identity:
mempty `mappend` x = x `mappend` mempty = x
(*) mappend is associative:
x `mappend` (y `mappend` z) = (x `mappend` y) `mappend` z

Note that this structure is very generic; it includes addition with the 
identity element 0 (i.e. mappend = (+), mempty = 0), multiplication with the 
identity element 1 (i.e. mappend = (*), mempty = 1), list concatenation with 
the identity element [] (i.e. mappend = (++), mempty = []), logical and with 
the identity element True (i.e., mappend = (&&), mempty = True), logical or 
with the identity element False (i.e., mappend = (||), mempty = False), etc.  
Unfortunately, sometimes this very generality results in there being multiple 
equally sensible ways to define a Monoid instance for a type.  For example, for 
numeric values addition and multiplication work equally well, and for boolean 
values logical and and logical or work equally well.  In such cases, it is a 
good idea to define newtype wrappers for these types so that we can make it 
explicit which operation we are using.  In the case of the Int type, for 
example, we define the Sum and Product newtypes and make these instances of 
Monoid using the corresponding mathematical operator; see also Any, All, First, 
and Last for other examples of this.

Although not strictly necessary, for reasons of performance the Monoid 
typeclass also includes the method mconcat which combines all the elements in a 
list, i.e. it is a method which obeys the property

(*) mconcat = foldr mappend mempty

The above is the default definition of mconcat if no other is supplied, but for 
some times users may wish to override it when it can be performed more 
efficiently.  Regardless, the minimal complete definition for an instance of 
the Monoid typeclass is mempty and mappend.




>> This additional information unfortunately makes the documentation more 
>> verbose,
> 
> One man's "more verbose" is another man's "less cryptic".

Don't get me wrong, I completely agree with you that adding more words for the 
sake of making a subject less cryptic is a net win.  :-)  There are two dangers 
that lurk, however.  First, there needs to be lots of that makes it easy for 
people to skim through and pick out the specific information that they want to 
find out about, and in particular the information that is most important/most 
urgently needed needs to be placed first so that it is the first thing that  
reader sees. Second, if you take too long to explain a point then you risk 
having your reader get fatigued so that all that effort you put in to make 
things clear just ends up getting going in one eye and out the other.  :-)

> I really don't like the emphasis on Num, as if it was a bizarre feature of
> Num that there's more than one Monoid reading for it.  This is a *common*
> property of data types.  For example, Sets can be seen as monoids with
> empty and union; and Sets with a universe can also be seen as monoids with
> universe and intersection.

In the revised version above, added Booleans as another example.

> The more I think about it, the less idea I have _what_ to expect for _any_
> instance of Monoid.


This is an inherent weakness of typeclasses, and why languages like Agda use 
record systems where instance declarations are records that you can either pass 
in explicitly or import explicitly to use implicitly within a particular scope.

I think, though, that for many types, though, there really is a sort of "most 
intuitive"/"most natural" Monoid operation.  For lists and sequences, for 
example, I think that the most intuitive operation is concatenation, rather 
than say taking the intersection of the elements of the two arguments.  
Likewise when you are accumulati

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Richard O'Keefe]

On 19/12/2011, at 5:46 PM, Gregory Crosswhite wrote:
[improved Monoid documentation]

I would go so far as to point out that "mappend is a generalisation of
Data.List.sum, Data.List.product, Data.List.and, and Data.List.or,
where the initial value and combining rule are implied by the type.


> 
> This additional information unfortunately makes the documentation more 
> verbose,

One man's "more verbose" is another man's "less cryptic".

I really don't like the emphasis on Num, as if it was a bizarre feature of
Num that there's more than one Monoid reading for it.  This is a *common*
property of data types.  For example, Sets can be seen as monoids with
empty and union; and Sets with a universe can also be seen as monoids with
universe and intersection.

The more I think about it, the less idea I have _what_ to expect for _any_
instance of Monoid.


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

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Gregory Crosswhite]

On Dec 19, 2011, at 1:01 PM, Richard O'Keefe wrote:

> Documentation for a library module needs to start by telling people what
> it is for.  For a particular function, someone needs to know very quickly
> "is this what I am looking for? is this the kind of thing I _should_ have
> been looking for?"

As I said before, some of this information really belongs in the Monoid 
typeclass itself, so here is my attempt at adding more information in this vein 
to the Monoid typeclass:



The Monoid typeclass provides a standard interface for specifying how pairs of 
values of a given type can be combined to form new values of that type, as well 
well as an identity value for that type that when combined with any value x 
produces x.  The Monoid class typically appears in higher-order functions that 
produce a list of values that need to be summarized into a single result, such 
as in Data.Foldable.foldMap function or the Writer monad.

Formally, an instance of Monoid provides a binary associative operator with an 
identity element;  to do this one must specify (at a minimum) the methods 
mempty and mappend such that they obey following properties:

(*) mempty is the identity:
mempty `mappend` x = x `mappend` mempty = x
(*) mappend is associative:
x `mappend` (y `mappend` z) = (x `mappend` y) `mappend` z

Although not strictly necessary, for reasons of performance the Monoid 
typeclass also includes the method mconcat which combines all the elements in a 
list, i.e. it is a method which obeys the property

(*) mconcat = foldr mappend mempty

The above is the default definition of mconcat if no other is supplied, but for 
some times users may wish to override it when it can be performed more 
efficiently.  Regardless, the minimal complete definition for an instance of 
the Monoid typeclass is mempty and mappend.

For many types there are multiple equally sensible ways to combine pairs of 
values;  for example, for the Int type one could use either addition or 
multiplication.  In such cases where there is no single "natural" way to 
combine values, we often (though not always) define newtype wrappers for these 
types so that we can make it explicit which operation we are using.  In the 
case of the Int type, for example, we define the Sum and Product newtypes and 
make these instances of Monoid using the corresponding mathematical operator.



This additional information unfortunately makes the documentation more verbose, 
but the hope was to try to explain as much as possible the "whys" and "whens" 
of the Monoid class (to a non-mathematician audience) in addition to the 
"whats", since as you point out often the most important part of the 
documentation is where it explains why something exists and when you would need 
it.

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

[Haskell-cafe] PEPM12: Second Call For Participation

[oleg]

ACM SIGPLAN 2012 Workshop on Partial Evaluation and Program Manipulation
  http://www.program-transformation.org/PEPM12
January 23-24, 2012. Philadelphia, PA, USA (co-located with POPL'12)
  Second Call For Participation


   Program is now available
   http://www.program-transformation.org/PEPM12/Program

   Online registration is open at 
   https://regmaster3.com/2012conf/POPL12/register.php
   Early registration deadline is December 24, 2011


The PEPM Symposium/Workshop series brings together researchers
and practitioners working in the broad area of program
transformation, which spans from refactoring, partial evaluation,
supercompilation, fusion and other metaprogramming to model-driven
development, program analyses including termination, inductive
programming, program generation and applications of machine learning 
and probabilistic search. PEPM focuses on techniques, supporting
theory, tools, and applications of the analysis and manipulation of
programs. 

In addition to the presentations of regular research papers, the PEPM
program includes tool demonstrations and `short paper' presentations
of exciting if not fully polished research.

PEPM has established a Best Paper award. The winner will be 
announced at the workshop.


INVITED TALKS

Compiling Math to High Performance Code
  Markus Pueschel (ETH Zuerich, Switzerland)
  http://www.inf.ethz.ch/~markusp/index.html


Specification and verification of meta-programs
  Martin Berger (University of Sussex, UK)
  http://www.informatics.sussex.ac.uk/users/mfb21/

VENUE

The conference is co-located with POPL and will be held at
the Sheraton Society Hill Hotel in Philadelphia's historic district.
For hotel rate details and booking please see the POPL webpage:
  http://www.cse.psu.edu/popl/12/


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

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Gregory Crosswhite]

On Dec 19, 2011, at 1:01 PM, Richard O'Keefe wrote:

> 
> On 19/12/2011, at 3:44 PM, Gregory Crosswhite wrote:
>> So what do you all think about my own suggestion for the documentation?
> 
> It is an improvement.
> 
> Documentation for a library module needs to start by telling people what
> it is for.  For a particular function, someone needs to know very quickly
> "is this what I am looking for? is this the kind of thing I _should_ have
> been looking for?"

I agree, though really much of that kind of information should be in the Monoid 
typeclass rather than in the Maybe instance in particular.

> The point is not that your proposed documentation doesn't say that, but it
> doesn't say that the MonadPlus reading is a *LEGITIMATE* way to view Maybe
> as a Monoid, which happens not to have been the one chosen; also that this
> possibility that the Monoid instance you WANT might not be the one you GET
> is to me the first thing you need to understand about it.  Yes, there is a
> blanket warning about this, but it specifically mentions Num.  Whenever it
> is possible for a reasonable person to want a Monoid instance and get one
> that is not the instance s/he wanted, it's worth highlighting in the docs.

I understand what you are getting at here, but the reason why think that the 
word "warning" needs to appear somewhere is to get users' attention long enough 
to let them know that this instance might break their expectations since it is 
inconsistent with MonadPlus and Alternative.

Nonetheless, I agree that it is a good idea to let users know that the 
alternative behavior might be the most useful one in their own case, so how 
about the following (including changes listed in an earlier e-mail), which I 
will call Version 5:



This instance satisfies the property that, for all x any y:
(1) Nothing `mappend` Nothing = Nothing
(2) Just x `mappend` Nothing = Just x
(3) Nothing `mappend` Just y = Just y
(4) Just x `mappend` Just y = Just (x `mappend` y)

Put in formal terms, this instance performs the standard procedure of 
turning an arbitrary semigroup into a monoid by simply adding a new element to 
the semigroup to serve as the identity element, where in this case the identity 
element is the Nothing value of Maybe;  unfortunately, since the base libraries 
do not come with a Semigroup typeclass, this process is expressed in code as 
lifting from the Monoid typeclass.

CAVEAT:  Note that rule (4) here is different from the case of the 
MonadPlus/Alternative instances where the Just y value is discarded so that 
Just x `mplus` Just y = Just x <|> Just y = Just x;  if this is alternative 
behavior is what you were looking for, then try those typeclasses instead.



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

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Gregory Crosswhite]

On Dec 19, 2011, at 1:03 PM, Alexander Solla wrote:

> The "incidental" comment is significantly more clear than an English 
> description.

That is only true for someone who has already seen a sentence like that one 
before and so can immediately pick up what it is getting at.  :-)  In 
particular, if one has never heard of a semigroup then the sentence is not very 
helpful.

> I would rather see commutative diagrams (or what amounts to the same, usage 
> examples) that describe the behavior than a "plain English" description.

I find it amusing that anyone would consider commutative diagram to be the same 
thing as usage examples for anyone other than a mathematician.  :-)  
Nonetheless, I see your point that examples may be clearer than English, so how 
about:



This instance satisfies the property that, for all x any y:
(1) Nothing `mappend` Nothing = Nothing
(2) Just x `mappend` Nothing = Just x
(3) Nothing `mappend` Just y = Just y
(4) Just x `mappend` Just y = Just (x `mappend` y)

(Warning: Note that rule (4) for this instance is different from the 
case of the MonadPlus/Alternative instances where the Just y value is discarded 
so that Just x `mplus` Just y = Just x <|> Just y = Just x.)

Formally, this instance performs the standard procedure of turning an 
arbitrary semigroup into a monoid by simply adding a new element to the 
semigroup to serve as the identity element, where in this case the identity 
element is the Nothing value of Maybe;  unfortunately, since the base libraries 
do not come with a Semigroup typeclass, this process is expressed in code as 
lifting from the Monoid typeclass.

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

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Alexander Solla]

On Sun, Dec 18, 2011 at 6:44 PM, Gregory Crosswhite
wrote:

>
> On Dec 19, 2011, at 12:39 PM, Brandon Allbery wrote:
>
> On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe  wrote:
>
>> No.  Not by a country mile.
>> It's better than "non-existent".
>> It's better than "misleading".
>> But it's not even on the same *continent* as "adequate".
>>
>
> +1
>
>
>
> So what do you all think about my own suggestion for the documentation?
>  The following is the same as what I've posted before, but with some tweaks
> such as swapping the last two paragraphs.
>
> 
>
> The Monoid instance for Maybe has the property that, for all x and y,
> (Just x) wins when combined (on either side) with Nothing values, and when
> (Just x) is combined with (Just y) then the result is (Just (x `mappend`
> y)).
>
> Note that the behavior of the Monoid instance of Maybe is *different* from
> the behavior of the MonadPlus and Alternative instance of Maybe.  For the
> latter two typeclasses, the behavior is that when (Just x) is combined with
> (Just y) the x and y values themselves are not combined but rather y is
> discarded so (Just x) simply wins;  put another way, for all x and z, we
> have that (Just x) `mappend` z is *always* equal to (Just x), regardless of
> whether z is equal to Nothing or whether it is equal to (Just y) for some
> y.  For this reason, unlike the instance for Monoid, the instances for
> these MonadPlus and Alternative place no additional constraints on the type
> lifted into Maybe.
>
> Incidentally, for the more mathematically inclined, you may think of this
> as being equivalent to the standard practice of turning an arbitrary
> semigroup into a monoid by simply adding a new element to the semigroup to
> serve as the identity element, where in this case the identity element is
> the Nothing value of Maybe;  unfortunately, since the base libraries do not
> come with a Semigroup typeclass, this process is expressed in code as
> lifting from the Monoid typeclass.
>
> 
>
> I welcome any feedback that you all have to offer.  If some iteration of
> the above is considered an improvement, then I would be happy to submit a
> patch using whatever process someone is kind enough to point me towards.
>  :-)
>
>
The "incidental" comment is significantly more clear than an English
description.

As somebody else has said in these threads, the problem is that
syntactically equivalent but semantically distinct types have been
collapsed into Maybe.  That complicates the reading of the source code,
since it is much harder to figure out which interpretation is intended, and
so which theorems we get from the types.  In other words, they are not free
theorems (since those are true in any interpretation).  We have to work for
them.

I would rather see commutative diagrams (or what amounts to the same, usage
examples) that describe the behavior than a "plain English" description.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Richard O'Keefe]

On 19/12/2011, at 3:44 PM, Gregory Crosswhite wrote:
> So what do you all think about my own suggestion for the documentation?

It is an improvement.

Documentation for a library module needs to start by telling people what
it is for.  For a particular function, someone needs to know very quickly
"is this what I am looking for? is this the kind of thing I _should_ have
been looking for?"

One important thing about the Monoid instance for Maybe is that

There is more than one way to turn Maybe into a Monoid.
One way treats Maybe a as a truncated [a] and does not
depend on any properties of a, it takes
mappend (Just x) _ = Just x

The other requires a itself to be a Monoid, and lift's
a's operations to Maybe a:
mappend (Just x) (Just y) = mappend x y
The latter, more interesting, case is the one implemented here.

(In the same way, bounded integers like Int can be viewed as Monoids in
at least 4 ways, only two of which are predefined in Data.Monoid.
   mempty = minBound
   mappend = max

   mempty = maxBound
   mappend = min
are the other two.  In fact these apply to anything that is Bounded and Ord.)

The point is not that your proposed documentation doesn't say that, but it
doesn't say that the MonadPlus reading is a *LEGITIMATE* way to view Maybe
as a Monoid, which happens not to have been the one chosen; also that this
possibility that the Monoid instance you WANT might not be the one you GET
is to me the first thing you need to understand about it.  Yes, there is a
blanket warning about this, but it specifically mentions Num.  Whenever it
is possible for a reasonable person to want a Monoid instance and get one
that is not the instance s/he wanted, it's worth highlighting in the docs.



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

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Gregory Crosswhite]

On Dec 19, 2011, at 12:39 PM, Brandon Allbery wrote:

> On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe  wrote:
> No.  Not by a country mile.
> It's better than "non-existent".
> It's better than "misleading".
> But it's not even on the same *continent* as "adequate".
> 
> +1


So what do you all think about my own suggestion for the documentation?  The 
following is the same as what I've posted before, but with some tweaks such as 
swapping the last two paragraphs.



The Monoid instance for Maybe has the property that, for all x and y, (Just x) 
wins when combined (on either side) with Nothing values, and when (Just x) is 
combined with (Just y) then the result is (Just (x `mappend` y)).

Note that the behavior of the Monoid instance of Maybe is *different* from the 
behavior of the MonadPlus and Alternative instance of Maybe.  For the latter 
two typeclasses, the behavior is that when (Just x) is combined with (Just y) 
the x and y values themselves are not combined but rather y is discarded so 
(Just x) simply wins;  put another way, for all x and z, we have that (Just x) 
`mappend` z is *always* equal to (Just x), regardless of whether z is equal to 
Nothing or whether it is equal to (Just y) for some y.  For this reason, unlike 
the instance for Monoid, the instances for these MonadPlus and Alternative 
place no additional constraints on the type lifted into Maybe.

Incidentally, for the more mathematically inclined, you may think of this as 
being equivalent to the standard practice of turning an arbitrary semigroup 
into a monoid by simply adding a new element to the semigroup to serve as the 
identity element, where in this case the identity element is the Nothing value 
of Maybe;  unfortunately, since the base libraries do not come with a Semigroup 
typeclass, this process is expressed in code as lifting from the Monoid 
typeclass.



I welcome any feedback that you all have to offer.  If some iteration of the 
above is considered an improvement, then I would be happy to submit a patch 
using whatever process someone is kind enough to point me towards.  :-)

Cheers,
Greg

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

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Brandon Allbery]

On Sun, Dec 18, 2011 at 20:42, Richard O'Keefe  wrote:

> No.  Not by a country mile.
> It's better than "non-existent".
> It's better than "misleading".
> But it's not even on the same *continent* as "adequate".
>

+1

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Richard O'Keefe]

On 17/12/2011, at 3:35 PM, Matthew Farkas-Dyck wrote:

> On 15/12/2011, Gregory Crosswhite  wrote:
>> 1) Documentation really needs to be improved
>> 2) some/many cannot be physically separated from Alternative, but there
>> *might* be an advantage to creating a subclass for them anyway purely for
>> the sake of conveying more information about a type to users
>> 3) Maybe and [] are sensible instances of Alternative, even if many/some
>> often enters an infinite loop.
>> 4) It is possible to provide special instance of many/some that satisfy the
>> equations of many/some, with the slight disadvantage that these solutions
>> are no longer the "least" solutions.
>> 
>> Based on all of this, at this moment in time it seems to me that the most
>> sensible way forward is to fix the documentation, tweak the definition of
>> Alternative to no longer require the least solutions of the equations, and
>> then to adopt the new instances for Maybe and [].
>> 
>> Thoughts?
> 
> (1) If we do (4), then the documentation ought to be adequate as-is.

No.  Not by a country mile.
It's better than "non-existent".
It's better than "misleading".
But it's not even on the same *continent* as "adequate".

A lot of Haskell packages have pretty much the same level of documentation.
And I didn't pay one single cent for it, so I can't scream too loudly.
But let's not kid ourselves.


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

Re: [Haskell-cafe] [Alternative] summary of my understanding so far

[Sebastian Fischer]

On Thu, Dec 15, 2011 at 9:13 AM, Gregory Crosswhite
wrote:

> To quote Ross Paterson's proposals:
>
> instance Alternative [] where
>...
>some [] = []
>some (x:xs) = repeat (repeat x)
>
>many [] = [[]]
>many (x:xs) = repeat (repeat x)
>

Isn't this instance conflating the ZipList notion and the nondeterministic
list notion?


> • some v = (:) <$> v <*> many v
> • many v = some v <|> pure []
>

Is there a motivation for writing the second law like this and not like

many v = pure [] <|> some v

other than "parsers should try longest match first"? Because apart from
that, I find the version with flipped arguments to <|> more natural (base
case first). Incidentally, it would lead to terminating definitions of
'some' and 'many' for lists:

ghci> take 5 . map (take 5) $ some [1,2]
[[1],[1,1],[1,1,1],[1,1,1,1],[1,1,1,1,1]]
ghci> take 5 . map (take 5) $ many [1,2]
[[],[1],[1,1],[1,1,1],[1,1,1,1]]

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

Re: [Haskell-cafe] Type checker for haskell-src-exts (was: Typechecking Using GHC API)

[Thomas Schilling]

On 17 December 2011 05:39, Gregory Crosswhite  wrote:

>
> On Dec 17, 2011, at 9:58 AM, Thomas Schilling wrote:
>
> Wll... I've gotten a little bit of a different perspective on this
> since working at a company with very high code quality standards (at
> least for new code).  There is practically no observable code review
> happening.  I'm sure Dimitrios and Simon PJ review most of each
> other's code every now and then, but overall there is very little code
> review happening (and no formal, recorded code review whatsoever).
> Cleaning up the GHC code base is a huge task -- it uses lots of dirty
> tricks (global variables, hash tables, unique generation is
> non-deterministic, ...) which often complicate efforts tremendously (I
> tried).  The lack of a unit tests doesn't help (just rewriting code so
> that it can be tested would help quite a bit).
>
>
> So in other words, would it be helpful it we recruited GHC janitors?  That
> is, similar to how we have the Trac which gives people bug reports to pick
> out and work on, would it make sense to have a Trac or some other process
> which gives people chunks of code to clean up and/or make easier to test?
>
> (I am of course inspired in suggesting this by the Linux kernel janitors,
> though it doesn't look like the project has survived, and maybe that
> portends ill for trying to do the same for GHC...)
>

I'm not sure that would work too well.  GHC is a bit daunting to start with
(it gets better after a while) and just cleaning up after other people is
little fun.  I would be more interested in setting up a process that
enables a clean code base (and gradually cleans up existing shortcomings).
 Of course, I'd prefer to do rather than talk, so I'm not pushing this at
this time.  At the moment, I think we should:

 1. Find a plan to get rid of the existing bigger design issues, namely:
the use of global variables for static flags (may require extensive
refactorings throughout the codebase), the use of nondeterministic uniques
for symbols (may cost performance)

 2. Build up a unit test suite (may include QuickCheck properties).  The
idea is that if our code needs to be tested from within Haskell (and not
the just the command line) then that encourages a design that can be used
better as a library.  It may also catch some bugs earlier and make it
easier to change some things.  (Note: the high-level design of GHC is
indeed very modular, but the implementation isn't so much.)

 3. Set up a code review system.  Every commit should have to go through
code review -- even by core contributors.  Even experienced developers
don't produce perfect code all the time.  Currently, we have some
post-commit review.  A possible code review system for Git is Gerrit.

Of course, the GHC developers would need to get on board with this.  As I
said, I currently don't have the time to pursue this any further, but I'm
planning to apply this to my projects as much as possible.

 / Thomas
-- 
Push the envelope. Watch it bend.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Adding state to a library

[Kevin Jardine]

By upgrading, I meant move a function from an IO monad with a config
parameter to a state monad without one.

On Dec 18, 10:52 pm, Bas van Dijk  wrote:
> On 18 December 2011 22:26, Kevin Jardine  wrote:
>
> > I have a library of functions that all take a config parameter (and usually
> > others) and return results in the IO monad.
>
> > It is sometimes useful to drop the config parameter by using a state-like
> > monad..
>
> If you're not modifying the configuration, a reader monad transformer
> is probably enough:
>
> http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/...
>
> You probably want to define your own monad transformer for your library:
>
> newtype MyMonad m a = M {unM :: ReaderT Config m a}
>   deriving (Functor, Applicative, Monad, MonadTrans, MonadIO)
>
> getConfig :: MyMonad m Config
> getConfig = M ask
>
> > I have found that I can wrap all my functions like so:
>
> > withLibrary cfg f = f cfg
>
> This can now be defined as:
>
> withLibrary :: Config -> MyMonad m a -> m a
> withLibrary cfg m = runReaderT (unM m) cfg
>
> > stateF a b c d =
> >    getConfig >>= \cfg -> liftIO $ withLibrary cfg
> >    libraryF a b c d
>
> > notice that I need stateF and libraryF lines, each with n parameters.
>
> > Upgrading my library like this is rather tedious.
>
> > I would prefer to just write something like
>
> > stateF = upgrade libraryF
>
> > but I can find no way to define the function upgrade in Haskell.
>
> > This must be a fairly common problem. Is there a simple solution?
>
> What do you mean by "upgrading"?
>
> Cheers,
>
> Bas
>
> ___
> Haskell-Cafe mailing list
> Haskell-C...@haskell.orghttp://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] ANNOUNCE: Anansi 0.4.2 (literate programming pre-processor)

[Magnus Therning]

On Sun, Dec 18, 2011 at 01:05:06PM +0100, Magnus Therning wrote:
> On Tue, Dec 13, 2011 at 12:36:44PM -0800, John Millikin wrote:
>> On Tue, Dec 13, 2011 at 03:39, Magnus Therning  wrote:
>>> 1. What to call files?  I understand (C)WEB suggests using .w, and
>>> that noweb uses .nw, what should I call anansi files?
>> 
>> I usually use .anansi, but it doesn't matter. You can use whatever
>> extensions you like, or even none at all.
> 
> I'll stick to .anansi as well then, it's rather descriptive :-)
> 
>>> 2. Combining anansi and pandoc works quite well for HTML, but it
>>> fails miserably when trying to use the generated LaTeX:
>>>
>>>    > markdown2pdf: ! LaTeX Error: Command \guillemotleft
>>>  unavailable in encoding OT1.
>>>
>>>    Is there any good way to get around that?
>> 
>> The LaTeX loom is designed to output basic markup that can be turned
>> into a PDF with minimum fuss. It probably won't work as-is for more
>> advanced cases, such as when a user wants to use custom templates, or
>> has to inter-operate with pseudo-LaTeX parsers like Pandoc.
> 
> I was probably unclear, I *really* would like to use the markdown loom
> and then pass the weave through pandoc to be able to create html/latex
> from the same source.  So I suspect the problem I ran into is more
> related to pandoc than anansi, but I was hoping that someone among the
> anansi users had run into and solved it already :-)

I just thought I'd mention that I've solved this particular issue now.
All that was needed was to make sure that

\usepackage{aeguill}

was added to the generated LaTeX.  Personally I did that by putting
the line in a file and then use the -H argument to `markdown2pdf`
which pandoc provides.

/M

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

Most software today is very much like an Egyptian pyramid with
millions of bricks piled on top of each other, with no structural
integrity, but just done by brute force and thousands of slaves.
 -- Alan Kay


pgpFJGRBrVTBr.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Announce: The Haskell Platform 2011.4

[Peter Simons]

Hi guys,

 > We're pleased to announce the release of the Haskell Platform: a
 > single, standard Haskell distribution for everyone.

Haskell Platform 2011.4 is fully supported on NixOS .

Take care,
Peter


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

Re: [Haskell-cafe] Adding state to a library

[Bas van Dijk]

On 18 December 2011 22:26, Kevin Jardine  wrote:
> I have a library of functions that all take a config parameter (and usually
> others) and return results in the IO monad.
>
> It is sometimes useful to drop the config parameter by using a state-like
> monad..

If you're not modifying the configuration, a reader monad transformer
is probably enough:

http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-Reader.html#t:ReaderT

You probably want to define your own monad transformer for your library:

newtype MyMonad m a = M {unM :: ReaderT Config m a}
  deriving (Functor, Applicative, Monad, MonadTrans, MonadIO)

getConfig :: MyMonad m Config
getConfig = M ask

> I have found that I can wrap all my functions like so:
>
> withLibrary cfg f = f cfg

This can now be defined as:

withLibrary :: Config -> MyMonad m a -> m a
withLibrary cfg m = runReaderT (unM m) cfg

> stateF a b c d =
>    getConfig >>= \cfg -> liftIO $ withLibrary cfg
>    libraryF a b c d
>
> notice that I need stateF and libraryF lines, each with n parameters.
>
> Upgrading my library like this is rather tedious.
>
> I would prefer to just write something like
>
> stateF = upgrade libraryF
>
> but I can find no way to define the function upgrade in Haskell.
>
> This must be a fairly common problem. Is there a simple solution?

What do you mean by "upgrading"?

Cheers,

Bas

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

Re: [Haskell-cafe] Adding state to a library

[Kevin Jardine]

My apologies. My last message was sent prematurely.

I have a library of functions that all take a config parameter (and usually
others) and return results in the IO monad.

It is sometimes useful to drop the config parameter by using a state-like
monad..

I have found that I can wrap all my functions like so:

withLibrary cfg f = f cfg

stateF a b c d =
   getConfig >>= \cfg -> liftIO $ withLibrary cfg
   libraryF a b c d

notice that I need stateF and libraryF lines, each with n parameters.

Upgrading my library like this is rather tedious.

I would prefer to just write something like

stateF = upgrade libraryF

but I can find no way to define the function upgrade in Haskell.

This must be a fairly common problem. Is there a simple solution?

On Sun, Dec 18, 2011 at 10:20 PM, Kevin Jardine wrote:

> I have a library of functions that all take cfg parameter (and usually
> others) and return results in the IO monad.
>
> It is sometimes useful to drop the config parameter by using a state-like
> monad..
>
> I have found that I can wrap all my functions like so:
>
> withLibrary cfg f = f cfg
>
> stateF a b c d =
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Adding state to a library

[Kevin Jardine]

I have a library of functions that all take cfg parameter (and usually
others) and return results in the IO monad.

It is sometimes useful to drop the config parameter by using a state-like
monad..

I have found that I can wrap all my functions like so:

withLibrary cfg f = f cfg

stateF a b c d =
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How hard is it to start a web startup using Haskell?

[Yves Parès]

Bryan O' Sullivans's company and Scrive may not be relevant examples, as
they employ respectively people like, well... ^^ Bryan O'Sullivan and
Magnus Carlsson (the Haskeller, not the singer).
So you can expect such people to do wonders.
But for instance I personnaly have one or two ideas of web developement
(and I'd love to carry them out using Yesod), but since I've simply been
using Haskell for 2~3 years (and only as a hobby) and since the only guy I
personnaly know who is the closest to a Haskeller is a friend who is
beginning to read RWH.


2011/12/18 Carlos López Camey 

> > The question 'How hard is it to start a technical startup with Haskell?'
> > happened a couple of times on this list. Sometimes it was in the form
> 'How hard
> > is to find Haskell programmers?' or 'Are there any Haskell jobs?'.
> >
> > I'd like to provide one data point as an answer:
> >
> >
> http://www.reddit.com/r/haskell/comments/ngbbp/haskell_only_esigning_startup_closes_second_angel/
> >
>
> Hi Gracjan, here is Bryan O' Sullivan's "Running a Startup on Haskell"
> in case you haven't seen it:
> http://www.infoq.com/presentations/Running-a-Startup-on-Haskell
>
> ___
> 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 hard is it to start a web startup using Haskell?

[Michael Snoyman]

On Sun, Dec 18, 2011 at 6:57 PM, Gracjan Polak  wrote:
>
> Hi all,
>
> The question 'How hard is it to start a technical startup with Haskell?'
> happened a couple of times on this list. Sometimes it was in the form 'How 
> hard
> is to find Haskell programmers?' or 'Are there any Haskell jobs?'.
>
> I'd like to provide one data point as an answer:
>
> http://www.reddit.com/r/haskell/comments/ngbbp/haskell_only_esigning_startup_closes_second_angel/
>
> Full disclosure: I'm one of two that founded this startup.
>
> How are others doing businesses using Haskell doing these days?

I don't run a startup myself, but I know of at least three startups
using Haskell for web development (through Yesod), and my company is
basing its new web products on Yesod as well. I think there are plenty
of highly qualified Haskell programmers out there, especially if
you're willing to let someone work remotely.

Michael

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

Re: [Haskell-cafe] How hard is it to start a web startup using Haskell?

[Carlos López Camey]

> The question 'How hard is it to start a technical startup with Haskell?'
> happened a couple of times on this list. Sometimes it was in the form 'How 
> hard
> is to find Haskell programmers?' or 'Are there any Haskell jobs?'.
>
> I'd like to provide one data point as an answer:
>
> http://www.reddit.com/r/haskell/comments/ngbbp/haskell_only_esigning_startup_closes_second_angel/
>

Hi Gracjan, here is Bryan O' Sullivan's "Running a Startup on Haskell"
in case you haven't seen it:
http://www.infoq.com/presentations/Running-a-Startup-on-Haskell

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

[Haskell-cafe] How hard is it to start a web startup using Haskell?

[Gracjan Polak]

Hi all,

The question 'How hard is it to start a technical startup with Haskell?'
happened a couple of times on this list. Sometimes it was in the form 'How hard
is to find Haskell programmers?' or 'Are there any Haskell jobs?'.

I'd like to provide one data point as an answer:

http://www.reddit.com/r/haskell/comments/ngbbp/haskell_only_esigning_startup_closes_second_angel/

Full disclosure: I'm one of two that founded this startup.

How are others doing businesses using Haskell doing these days?

-- 
Gracjan



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

Re: [Haskell-cafe] ANNOUNCE: Anansi 0.4.2 (literate programming pre-processor)

[Magnus Therning]

On Tue, Dec 13, 2011 at 12:36:44PM -0800, John Millikin wrote:
> On Tue, Dec 13, 2011 at 03:39, Magnus Therning  wrote:
>> 1. What to call files?  I understand (C)WEB suggests using .w, and
>> that noweb uses .nw, what should I call anansi files?
> 
> I usually use .anansi, but it doesn't matter. You can use whatever
> extensions you like, or even none at all.

I'll stick to .anansi as well then, it's rather descriptive :-)

>> 2. Combining anansi and pandoc works quite well for HTML, but it
>> fails miserably when trying to use the generated LaTeX:
>>
>>    > markdown2pdf: ! LaTeX Error: Command \guillemotleft
>>  unavailable in encoding OT1.
>>
>>    Is there any good way to get around that?
> 
> The LaTeX loom is designed to output basic markup that can be turned
> into a PDF with minimum fuss. It probably won't work as-is for more
> advanced cases, such as when a user wants to use custom templates, or
> has to inter-operate with pseudo-LaTeX parsers like Pandoc.

I was probably unclear, I *really* would like to use the markdown loom
and then pass the weave through pandoc to be able to create html/latex
from the same source.  So I suspect the problem I ran into is more
related to pandoc than anansi, but I was hoping that someone among the
anansi users had run into and solved it already :-)

> You could try copying the LaTeX loom into your own code, modifying
> it to generate the custom output format you want, and then running
> it as a #!runhaskell script.

I might try that, but then use the markdown loom as the basis instead.
It would be nice to have a specific pandoc loom that makes use of its
extensions to markdown, where that makes sense.

>> 3. Is there any editor support for anansi, syntax highlihgting etc?
> 
> Not that I know of. Note that Anansi's syntax itself is very
> minimal, so what you need is an editor that can support formatting a
> file using multiple syntaxes. I don't know enough about editor
> modification to figure out which editors support such a feature, or
> how to enable it.

It's rather easy to do in vim, e.g. by setting the filetype to
something line 'markdown.haskell'.  I haven't tried putting together
three filetypes, but I suspect it just works :-)  If I get around to
putting together an anansi syntax file for vim I'll make sure to share
it.

/M

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


Perl is another example of filling a tiny, short-term need, and then
being a real problem in the longer term.
 -- Alan Kay


pgpiZL3X6TwAu.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: hxournal-0.5.0.0 - A pen notetaking program written in haskell

[Ian-Woo Kim]

To anyone who is interested,

I just uploaded a new release of hxournal 0.6 which has pdf annotation
functionality. (It's still at very early stage now though. You can
think this as a tech preview release)

The following is the message I posted on hxournal google group. (
http://groups.google.com/group/hxournal )
All small release announcements will be posted there.

Thanks.

best,
IW

--

Dear hxournal Users,
I uploaded the new version of hxournal with pdf annotation
functionality to hackage so that one can easily test the new version.
The new version is accompanied with new releases of xournal-render and
xournal-parser and with new package xournal-types and xournal-builder,
which are data type declaration package for xournal and xournal file
constructing library using blaze-builder.
For installation, you just need to type
> cabal install hxournal

This hxournal version needs poppler-0.12.* which is a part of gtk2hs.
I found that the installation of poppler package is a little difficult
in some system.  So you may encounter some problem in installation.
Later, I will make a compilation option to choose whether one will use
poppler or not.

Happy hxournaling then!

best regards,
Ian-Woo Kim


On Fri, Dec 16, 2011 at 7:51 AM, Ivan Perez
 wrote:
> Thanks :)
>
> It's working now. I tried it with XInput and without it. Lines seem
> smoother when XInput is activated.
>
> On 16 December 2011 11:33, Ian-Woo Kim  wrote:
>> Hi, all,
>>
>> I just uploaded hxournal-0.5.1 which is implemented with .hxournal
>> config file, "Use X Input" menu enabled, and a fix for compilation
>> problem of gdkconfig.h by Custom build during cabal configure using
>> "pkg-config --cflags gtk+-2.0"
>>
>> Please try the new version by
>>> cabal update
>>> cabal install hxournal
>>
>> I have made a google group of hxournal : hxour...@googlegroups.com
>> Any issues on hxournal will be welcome and discussed there.
>>
>> Currently, I branched 0.5.1 version for stabilization and now started
>> to focus on pdf background rendering (which is most relevant for my
>> purpose)  in the master branch.
>>
>> Thank you for your interest and reports.
>> best,
>>
>> On Thu, Dec 15, 2011 at 4:33 PM, Edward Z. Yang  wrote:
>>> When I attempt to build on Ubuntu, I get:
>>>
>>> ezyang@javelin:~$ cabal install hxournal
>>> Resolving dependencies...
>>> Configuring hxournal-0.5.0.0...
>>> Preprocessing library hxournal-0.5.0.0...
>>> In file included from /usr/include/gtk-2.0/gdk/gdkscreen.h:32:0,
>>>                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
>>>                 from /usr/include/gtk-2.0/gdk/gdk.h:32,
>>>                 from /usr/include/gtk-2.0/gtk/gtk.h:32,
>>>                 from Device.hsc:3:
>>> /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No 
>>> such file or directory
>>> compilation terminated.
>>> compiling dist/build/Application/HXournal/Device_hsc_make.c failed (exit 
>>> code 1)
>>> command was: /usr/bin/gcc -c 
>>> dist/build/Application/HXournal/Device_hsc_make.c -o 
>>> dist/build/Application/HXournal/Device_hsc_make.o -fno-stack-protector 
>>> -fno-stack-protector 
>>> -Wl,--hash-style=both,--no-copy-dt-needed-entries,--as-needed 
>>> -D__GLASGOW_HASKELL__=700 -Dlinux_BUILD_OS -Dlinux_HOST_OS 
>>> -Di386_BUILD_ARCH -Di386_HOST_ARCH -Icsrc -I/usr/include/glib-2.0 
>>> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/atk-1.0 
>>> -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
>>> -I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 
>>> -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm 
>>> -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 
>>> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include 
>>> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 
>>> -I/usr/include/libpng12 -I/usr/include/glib-2.0 
>>> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/glib-2.0 
>>> -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/cairo 
>>> -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include 
>>> -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 
>>> -I/usr/lib/ghc-7.0.3/process-1.0.1.5/include 
>>> -I/usr/lib/ghc-7.0.3/directory-1.1.0.0/include 
>>> -I/usr/lib/ghc-7.0.3/old-time-1.0.0.6/include 
>>> -I/usr/lib/ghc-7.0.3/unix-2.4.2.0/include 
>>> -I/usr/lib/ghc-7.0.3/time-1.2.0.3/include 
>>> -I/usr/lib/ghc-7.0.3/bytestring-0.9.1.10/include 
>>> -I/usr/lib/ghc-7.0.3/base-4.3.1.0/include -I/usr/lib/ghc-7.0.3/include 
>>> -I/usr/lib/ghc-7.0.3/include/
>>> cabal: Error: some packages failed to install:
>>> hxournal-0.5.0.0 failed during the building phase. The exception was:
>>> ExitFailure 1
>>>
>>> This may be of interest:
>>>
>>> ezyang@javelin:~$ locate gdkconfig.h
>>> /home/ezyang/Dev/gtk+/gdk/gdkconfig.h.win32
>>> /usr/include/gtk-3.0/gdk/gdkconfig.h
>>> /usr/lib/i386-linux-gnu/gtk-2.0/include/gdkconfig.h
>>>
>>> Edward
>>>
>